رفتن به مطلب
جامعه‌ی برنامه‌نویسان مُدرن ایران

جستجو در تالارهای گفتگو

در حال نمایش نتایج برای برچسب های 'server'.



تنظیمات بیشتر جستجو

  • جستجو بر اساس برچسب

    برچسب ها را با , از یکدیگر جدا نمایید.
  • جستجو بر اساس نویسنده

نوع محتوا


وبلاگ‌ها

چیزی برای نمایش وجود ندارد

چیزی برای نمایش وجود ندارد

تالارهای گفتگو

  • انجمن‌های آی او استریم
    • اخبار و اعلامیه‌های سایت
    • اسناد و قوانین مرجع
    • رویداد‌ها و جلسات
    • معرفی محصولات نوشته شده‌ بومی
    • مرکز نظرسنجی جامعه‌ی برنامه‌نویسان
    • مقالات و اسناد مشاوره‌ای
    • مرکز چالش برانگیز برنامه‌نویسان
    • رمز‌های موفقیت
    • ابزار‌ها و نرم‌افزارهای کاربردی برنامه‌نویسان حرفه‌ای
  • استارتاپی و کسب‌و‌کار
    • استارتاپ‌ها
    • سرمایه گذاری
    • شتاب دهنده‌ها
    • پارک‌های علم و فناوری و مراکز رشد
    • مصاحبه با استارت‌آپ‌ها
    • قوانین حقوقی
    • داستان‌های موفقیت
    • کارآفرینان و متخصصین
    • مشاوره اجرای کسب‌وکار
    • اخبار حوزه‌ی استارتا‌پی
    • آگهی‌های استخدامی
  • زبان‌های برنامه نویسی
    • برنامه نویسی در C و ‏++C
    • برنامه نویسی با Java
    • برنامه نویسی با JavaScript
    • برنامه نویسی با Go
    • برنامه نویسی با Python
    • برنامه نویسی با Delphi
    • برنامه نویسی با Ruby
    • برنامه نویسی با VB6
  • طراحی و توسعه وب
    • برنامه نویسی در PHP
    • برنامه نویسی با Node.JS
  • طراحی و توسعه وب اپلیکیشن‌ها
    • طراحی و توسعه در Angular
    • طراحی و توسعه در React.JS
    • طراحی و توسعه در Vue.JS
  • طراحی و توسعه موبایل و اِمبِد‌ها و تلوزیون‌ها
    • برنامه نویسی تحت محصولات اپل
    • برنامه نویسی تحت محصولات گوگل
    • طراحی و توسعه تحت محصولات دیگر
  • برنامه‌نویسی سطح پایین و سیستم عامل‌ها
    • سیستم عامل‌های آزاد
    • سیستم عامل‌های تجاری
    • مباحث آموزشی مرتبط با سیستم‌عامل
  • شبکه و اینترنت
    • مباحث و منابع آموزشي
    • سوالات و مشکلات
  • بانک‌های اطلاعاتی
    • پایگاه داده MySQL
    • پایگاه داده PostgreSQL
    • پایگاه داده SQLite
    • پایگاه داده MongoDB
    • پایگاه داده SQL Server
    • دیگر پایگاه‌های داده
  • برنامه نویسی تحت محصولات اپل
    • محیط توسعه Xcode
    • برنامه نویسی با Objective-C
    • برنامه نویسی با Swift
  • برنامه نویسی تحت محصولات مایکروسافت
    • محیط توسعه Visual Studio
    • برنامه نویسی در ASP.NET MVC
    • برنامه نویسی با #C
    • برنامه نویسی با Visual Basic.Net
    • طراحی و توسعه تحت Wpf
    • طراحی و توسعه تحت Universal و Fluent
  • طراحی و توسعه تجربه کاربری (UX) و رابط کاربری (UI)
    • طراحی رابط کاربری (UI)
    • طراحی تجربه کاربری (UX)
  • درخواست انجام پروژه (ویژه)
    • پروژه‌های منبع‌باز
  • سوالات و مباحث عامیانه
    • سوالات دانشجویی
    • فناوری و سخت افزار
    • سوالات مشاوره‌ای و تخصصی مرتبط با حوزه‌ی برنامه‌نویسی
  • سطل آشغال
    • سطل آشغال

Product Groups

  • کتاب‌ها و مقالات آموزشی

دسته ها

  • علمی
  • استارتاپی
  • برنامه‌نویسی
    • زبان‌های برنامه نویسی
    • معماری‌ها
  • کامپایلر و مفسر
  • محیط‌های توسعه
  • پلتفرم‌های توسعه
  • مجوز‌های نرم‌افزاری
  • فناوری‌ها
    • پردازش تصویر
    • اینترنت اشیاء
    • پردازش ابری (Cloud Computing)
    • چند سکویی (Cross-Platform)
    • بیگ دیتا (Big Data)
    • هوش مصنوعی (AI)
    • سخت افزار
    • نرم‌افزار و اپلیکیشن
    • اینترنت و شبکه
    • رمزنگاری
    • امبد‌ها (Embedded)
  • طراحی
    • تجربه کاربری
    • رابط کاربری

دسته ها

  • عمومی
  • گرافیکی
  • شبکه و ارتباطات

دسته ها

  • کامپایلر‌ها
  • محیط‌های توسعه
  • کتابخانه‌ها
  • ماژول‌ها و پلاگین‌ها
  • محصولات بومی
  • کتاب‌ها و مقالات
  • زبان‌ها و ابزار‌ها
  • طراحی و گرافیک

جستجو در ...

نمایش نتایجی که شامل ...


تاریخ ایجاد

  • شروع

    پایان


آخرین بروزرسانی

  • شروع

    پایان


فیلتر بر اساس تعداد ...

تاریخ عضویت

  • شروع

    پایان


گروه


شناسه گیت‌هاب


شناسه لینکدین


شهر

2 نتیجه پیدا شد

  1. الهه انصاری

    تکنولوژی REST

    تکنولوژی REST (REpresentational State Transfer)، یک سبک معماری برای توسعه‌ی وب سرویس‌ها است. معماری REST به دلیل سادگی و استواری بر پایه سیستم‌های موجود و ویژگی‌های HTTP به منظور دستیابی به اهداف آن، بر خلاف ایجاد استانداردها، چارچوب‌ها و فناوری‌های جدید، محبوب است. مزایای معماری REST یکی از مزیت‌های اصلی استفاده از این معماری، هم از جنبه‌ی سرویس گیرنده و هم از جنبه‌ی سرور، تعاملات مبتنی بر REST است که برای هر فردی که با پروتکل HTTP آشنایی دارد، بسیار ساده است. برای مثال، تعاملات مبتنی بر REST وضعیت خود را با استفاده از کدهای وضعیت HTTP استاندارد اعلام می‌کنند. بنابراین، 404 به معنای «منبع درخواست شده یافت نشد»، کد 401 به معنای «درخواست مجاز نیست»، کد 200 به این معنی است که «همه چیز خوب است» و کد 500 بدان معنی است که «یک خطای نرم افزار غیر قابل برگشت در سرور وجود دارد». به طور مشابه اعمالی مانند رمزنگاری و یکپارچگی انتقال داده بدون اضافه کردن چارچوب یا تکنولوژی خاصی و صرفا با رمز نگاری SSL و TLS پیاده سازی می‌شوند. معماری REST همچنین یک معماری مستقل از زبان است. برنامه‌های مبتنی بر REST می‌توانند به کمک هر زبانی از جمله Java، Kotlin، AngularJS و یا JavaScript نوشته شوند. تا زمانی که یک زبان برنامه نویسی می‌تواند درخواست‌های مبتنی بر وب را با استفاده از HTTP انجام دهد، این زبان قادر خواهد بود که برای فراخوانی RESTful API یا وب سرویس استفاده شود. به طور مشابه، وب سرویس‌های RESTful می‌توانند با استفاده از هر زبانی نوشته شوند، بنابراین توسعه دهندگان با اجرای آن‌ها می‌توانند تکنولوژی‌هایی را انتخاب کنند که بهترین کارایی را در شرایط موجود داشته باشند. مزیت دیگر استفاده از این معماری، فراگیر بودن آن است. در سمت سرور، انواع چارچوب‌های مبتنی بر REST از جمله RESTlet و Apache CXF وجود دارد که به توسعه دهندگان برای ایجاد وب سرویس‌های RESTful کمک می‌کنند. در سمت سرویس گیرنده، تمام چارچوب‌های جدید جاوا اسکریپت، مانند JQuery، Node.js، Angular و EmberJS، همه‌ی کتابخانه‌های استاندارد در API های خود ساخته شده‌اند که وب سرویس‌های RESTful را فراخوانی کرده و از داده‌های XML یا JSON استفاده می‌کنند. معایب معماری REST مزایای استفاده از REST با استفاده از ساختارهای HTTP همچنین محدودیت‌هایی را ایجاد می‌کند. بسیاری از محدودیت‌های HTTP نیز به نقص سبک معماری REST تبدیل می‌شوند. به عنوان مثال، HTTP اطلاعات مبتنی بر وضعیت را بین چرخه‌های درخواست - پاسخ ذخیره نمی‌کند، که بدین معنی است که برنامه‌های مبتنی بر REST باید بی‌ثمر باشند و تمام وظایف مدیریت وضعیت باید توسط خود سرویس گیرنده انجام شوند. به طور مشابه، از آن جا که HTTP هیچ مکانیزمی برای ارسال اعلان‌ها از سرور به سرویس گیرنده ندارد، پیاده سازی هر نوع سرویسی که سرور، کلاینت را بدون رای‌ گیری از جانب آن (client-side polling) و یا انواع مختلف قلاب وب (web hook) به روز رسانی کند سخت است. از دیدگاه پیاده سازی، یک مشکل رایج با REST این واقعیت است که توسعه دهندگان با معنای دقیق REST-based مخالفت می‌کنند. برخی از توسعه دهندگان نرم افزار به اشتباه هر چیزی را که مبتنی بر SOAP نیست، RESTful در نظر می‌گیرند. چیزی که سبب این تصور غلط رایج می‌شود این واقعیت است که REST یک سبک معماری است، بنابراین هیچ پیاده سازی مرجع یا استاندارد قطعی وجود ندارد که تأیید کند آیا یک طراحی خاص، RESTful است یا خیر. در نتیجه، بر سر اینکه آیا یک API داده شده مطابق با اصول مبتنی بر REST است یا خیر بحث وجود دارد. جایگزین‌هایی برای REST فناوری‌های جایگزین برای ایجاد سیستم‌های مبتنی بر SOA (معماری مبتنی بر سرویس، Service-oriented architecture) و یا ایجاد API برای فراخوانی سرویس‌های میکرو از راه دور شامل XML روی HTTP (معروف به XML-RPC)، همچنین CORBA و پروتکل SOAP (پروتکل دسترسی ساده به object) است. هر تکنولوژی مجموعه‌ای از مزایا و معایب خود را دارد، اما ویژگی مهیج REST که آن را شاخص می‌کند، این است که به جای اینکه از یک توسعه دهنده بخواهد با مجموعه‌ای از پروتکل‌های سفارشی کار کند یا یک فرمت داده‌ی خاص برای تبادل پیام بین یک سرویس دهنده و یک سرور داشته باشد، REST باور دارد که بهترین راه برای پیاده سازی یک سرویس وب مبتنی بر شبکه این است که به راحتی از ساختار اصلی پروتکل شبکه‌ی خود استفاده کند که در مورد اینترنت، HTTP است. این یک نکته مهم است، زیرا REST فقط برای اعمال به اینترنت در نظر گرفته نشده است؛ بلکه هدف آن است که اصول آن به تمام پروتکل‌ها از جمله WEBDAV، FTP و غیره اعمال شود. REST در مقابل SOAP دو سبک رقیب برای اجرای خدمات وب REST و SOAP است. تفاوت اساسی بین این دو، رویکرد فلسفی است که باید به فراخوانی از راه دور بپردازند. REST یک رویکرد مبتنی بر منابع را برای تعاملات مبتنی بر وب اتخاذ می‌کند. با REST، شما یک منبع را بر روی سرور قرار می‌دهید و انتخاب می‌کنید که این منبع را به روزرسانی کنید، پاک کنید یا اطلاعاتی را در مورد آن دریافت کنید. در SOAP، کلاینت تصمیم نمی‌گیرد به طور مستقیم با یک منبع ارتباط برقرار کند، بلکه به جای آن یک سرویس را فراخوانی می‌کند و این سرویس دسترسی به اشیا و منابع مختلف پشت صحنه را کاهش میدهد. SOAP همچنین تعداد زیادی از چارچوبها و APIها را در بالای لایه‌ی پروتکل HTTP را ایجاد کرده است، از جمله زبان توصیف سرویس وب (Web Services Description Language, WSDL)، که ساختار داده‌هایی را که بین کلاینت و سرور رد و بدل می‌شوند، تعریف می‌کند. گاهی بهترین نتیجه با تعریف دقیق فرمت پیام حاصل می‌شود و یا میتوان از APIهای مرتبط با SOAP مانند WS-Eventing، WS-Notification و WS-Security بهره برد. در بعضی مواقع شرایطی پیش می‌آید که HTTP نمی‌تواند سطح کارایی را که یک برنامه ممکن است نیاز داشته باشد، فراهم کند. در این موارد، استفاده از SOAP ترجیح داده میشود. REST URIها و URLها اکثر مردم با شیوه‌ی عملکرد URLها (Uniform Resource Locator) و URIها (Uniform Resource Identifier) در وب آشنا هستند. رویکرد RESTful برای برنامههای کاربردی ادعا میکند که درخواست اطلاعات در مورد یک منبع باید به اندازه‌ی فراخوانی URL آن ساده باشد. به عنوان مثال، اگر یک کلاینت بخواهد یک سرویس وب را که تمام آزمونها را در TechTarget در دسترس قرار داده است، به URL مراجعه کند. URLای که به سرویس وب خواهد رسید بدین ترتیب است: www.techtarget.com/restfulapi/quizzes هنگام فراخوانی، سرویس وب ممکن است با رشته JSON زیر، لیست تمام آزمون‌های موجود را پاسخ دهد که یکی از آن‌ها درباره‌ی DevOps است: { "quizzes" : [ "Java", "DevOps", "IoT"] } برای دریافت آزمون DevOps، سرویس وب ممکن است با استفاده از URL زیر فراخوانی شود: www.techtarget.com/restfulapi/quizzes/DevOps با فراخوانی این URL یک رشته‌ی JSON که لیستی از سوالات در آزمون DevOps را فهرست کرده است، بازگردانده می‌شود. برای دریافت یک سوال مشخص از آزمون، شماره‌ی سوال به URL اضافه خواهد شد. بنابراین، برای دریافت سوال سوم در آزمون، URL RESTful زیر استفاده می‌شود: www.techtarget.com/restfulapi/quizzes/DevOps/3 فراخوانی این URL ممکن است یک رشته‌ی JSON مانند زیر را برگرداند: { "Question" : {"query":"What is your DevOps role?", "optionA":"Dev", "optionB":"Ops"} } همان طور که می‌بینید، URLهای REST در این مثال به گونهای منطقی و معنی دار هستند که منابع دقیق درخواست شده را مشخص می‌کنند. فرمتهای داده‌ی JSON و XML REST مثال بالا نشان میدهد JSON به عنوان فرمت تبادل اطلاعات برای تعامل RESTful استفاده می‌شود. رایج ترین فرمت تبادل دادهها JSON و XML هستند و بسیاری از خدمات وب RESTful میتوانند تا زمانی که کلاینت بتواند تعامل را در XML یا JSON انجام دهد، از هر دو فرمت به طور متناوب استفاده کنند. توجه داشته باشید با وجود اینکه JSON و XML فرمتهای رایج تبادل داده هستند، خود REST هیچگونه محدودیتی در مورد آنچه که فرمت باید باشد قرار نمیدهد. در واقع، برخی از خدمات وب RESTful به منظور بهره وری، دادههای باینری را مبادله می‌کنند. این یکی دیگر از مزایای کار با خدمات وب مبتنی بر REST است، زیرا معمار نرم افزار از نظر نحوه‌ی اجرای بهترین خدمات، از آزادی زیادی برخوردار است. REST و رویه‌های HTTP مثال بالا فقط دسترسی به داده‌ها را بررسی می‌کند. عملیات پیش فرض HTTP، رویه‌ی GET است که در هنگام دریافت داده‌ها از سرور مورد استفاده قرار می‌گیرد. با این حال، HTTP تعدادی از رویه‌های دیگر از جمله PUT، POST و DELETE را تعریف میکند.REST ادعا می‌کند که برای حذف داده‌ای در سرور، به سادگی از URL برای دسترسی به منبع استفاده کنید و روش DELETE از HTTP را اعمال کنید. برای ذخیره‌ی داده‌ها در سرور، یک URL و رویه‌ی PUT استفاده میشود. همچنین برای عملیاتی که فراتر از ذخیره سازی، خواندن و یا حذف اطلاعات هستند، می توان از روش POST استفاده کرد. تاریخچه‌ی REST REST برای اولین بار توسط دانشمند علم کامپیوتر Roy Fielding در طول انجام پایان‌ نامه‌ی تحصیلات دوره‌ی دکترای وی در دانشگاه کالیفرنیا با عنوان «سبک‌های معماری و طراحی معماری نرم افزار مبتنی بر شبکه» ابداع شد. فصل 5 پایان نامه ادعاهای Fielding در مورد چگونگی بهینه سازی معماری سیستمهای توزیعی hypermedia را توصیف می‌کند. وی تعدادی از شرایط مرزی را توصیف می‌کند که سیستم‌های مبتنی بر REST باید چگونه رفتار کنند. این شرایط به عنوان محدودیت‌های REST یاد می‌شوند. چهار مورد از محدودیت‌های کلیدی در زیر شرح داده شده اند: استفاده از رابط کاربری یکنواخت (Uniform Interface, UI): همانطور که قبلا ذکر شد، منابع در سیستم‌های مبتنی بر REST باید از طریق یک URL قابل شناسایی باشند و تنها با استفاده از روشهایی مانند DELETE، PUT و GET در HTTP با منبع در تعامل باشند. سیستم‌های مبتنی بر رابطه‌ی کلاینت، سروری: در سیستم‌های مبتنی بر REST، باید تعریف مشخصی از کلاینت و سرور داشته باشیم. UI و نگرانی‌های حاصل از درخواست‌ها، در حوزه‌ی کلاینت هستند. در همین حال، دسترسی به داده‌ها، مدیریت بار کاری و امنیت، در دامنه‌ی سرور است. این جداسازی‌ها اتصال بین کلاینت و سرور را برقرار می‌کند و هر کدام میتوانند مستقل از دیگری توسعه یابند. عملیات مجزا (Stateless operations): تمام عملیات بین کلاینت و سرور باید مجزا و مستقل از هم باشند و هر مدیریت حالتی (State) که مورد نیاز است نه بر روی سرور، بلکه باید بر روی کلاینت پیاده سازی شود. کَش کردن منابع RESTful: توانایی کَش کردن منابع بین فراخوانی‌های انجام شده توسط کلاینت نسبت به کاهش تاخیر و بهبود عملکرد اولویت بالاتری دارد. علاوه بر این تمامی منابع باید اجازه ی کَش کردن را داشته باشند، مگر اینکه یک نشانه‌ی صریح برای عدم امکان انجام این عمل یافت شود. توسعه‌ی APIهای REST‌ در جاوا در راستای محبوبیت رو به رشد سیستمهای مبتنی بر REST، تعدادی از چارچوبها برای کمک به توسعه دهندگان در ایجاد خدمات وب RESTful به وجود آمده اند. برخی از چارچوب‌های منبع باز محبوب برای ایجاد سرویسهای وب مبتنی بر جاوا عبارتند از Apache CXF، Jersey، Restlet، Apache Wink، Spring Data و JBoss' RESTeasy. رویکرد کلی هر یک از این چارچوبها این است که به توسعه دهندگان کمک کنند تا خدمات وب RESTful خود را با استفاده از الگوهای معنایی جاوا که با آن آشنا هستند، از جمله Java Platform (نسخه سازمانی)، Servlet API بسازند، در عین حال که کلاس‌های از پیش آماده و روش‌هایی به آن‌ها ارائه‌ می‌شوند تا با شروط اساسی REST بیشترین مطابقت را داشته باشند. پی‌نوشت: مطلبی تحت عنوان فریم ورک REST‌ در زبان سی پلاس پلاس نیز به طور مجزا به این مقاله اضافه خواهد شد.
  2. الهه انصاری

    آشنایی با CDN

    «بخش اول» CDN مخفف Content Delivery Network یک شبکه‌ی تحویل محتوا است که به گروه توزیع شده‌ی سرورها اشاره دارد که با یکدیگر همکاری می‌کنند تا محتوای اینترنت را به صورت سریعی ارائه دهند. CDN امکان انتقال سریع بسته‌های مورد نیاز برای بارگذاری محتوای اینترنتی از جمله صفحات HTML، فایلهای جاوا اسکریپت، شیوه نامهها، تصاویر و فیلمها را فراهم می‌کند. محبوبیت سرویس‌های CDN همچنان در حال رشد است و امروزه اکثر ترافیک وب سایتهای بزرگ چون Facebook، Netflix و Amazon از طریق CDN‌ها جا به جا می‌شوند. CDNهایی که به درستی پیکربندی شده‌ اند همچنین ممکن است به حفاظت از وب سایتها در برابر برخی از حملات مخرب رایج مانند حملات انکار سرویس توزیع شده (DDOS) کمک کنند. آیا CDN مشابه میزبان وب است؟ در حالی که یک CDN محتوا را میزبانی نمی‌کند و نمی‌تواند جایگزینی برای نیاز به میزبانی وب مناسب باشد، محتوای cache در لبه‌ی شبکه کمک می‌کند که عملکرد وب سایت را بهبود بخشد. بسیاری از وب سایت‌ها تلاش می‌کنند که نیازهای عملکرد آن‌ها توسط خدمات میزبانی سنتی برآورده شود، به همین دلیل آن‌ها CDNها را انتخاب می‌کنند. با استفاده از ذخیره سازی برای کاهش پهنای باند میزبانی و کمک به جلوگیری از وقفه در سرویس و بهبود امنیت، CDNها انتخاب محبوبی برای از بین بردن برخی از نقاط بحرانی میزبانی سنتی وب هستند. مزایای استفاده از CDN‌ چیست؟ اگرچه مزایای استفاده از CDN بسته به اندازه و نیازهای یک مالکیت اینترنتی متفاوت است، مزایای اولیه برای اکثر کاربران را میتوان به 4 بخش مختلف تقسیم کرد: بهبود زمان بارگذاری وب سایت: با توزیع محتوای نزدیک به بازدید کنندگان وب سایت با استفاده از سرور CDN نزدیک (در میان دیگر بهینه سازیها)، بازدید کنندگان بارگذاری سریع‌تر صفحه را تجربه می‌کنند. هنگامی که بازدید کنندگان بیش‌تر مایل به کلیک کردن در یک سایت با بارگیری کُند هستند، یک CDN میتواند سبب کاهش نرخ جست و جو و افزایش زمان سپری شده توسط افراد در سایت شود. به عبارت دیگر، یک وب سایت سریع‌تر به این معنی است که بازدید کنندگان بیش‌تر در آن جا ماندگار شوند. کاهش هزینه‌های پهنای باند: هزینه‌ی مصرف پهنای باند برای میزبانی وب سایت هزینه‌ی اصلی برای وب سایت‌ها است. از طریق ذخیره سازی و بهینه سازی‌های دیگر، CDNها قادر به کاهش میزان داده‌هایی هستند که یک سرور مبدا باید ارائه دهد. بنابراین هزینه‌های میزبانی وب برای صاحبان وب سایت‌ها کاهش می‌یابد. افزایش میزان دسترسی و افزونگی: مقدار زیاد ترافیک و یا خرابیهای سخت افزاری می‌تواند کارکرد وب سایت را مختل سازد. به لطف ساختار توزیع شده، یک CDN می‌تواند ترافیک بیشتری را اداره کند و از خرابی و شکست سخت افزاری بهتر از بسیاری از سرورهای مبدا جلوگیری کند. بهبود امنیت وب سایت: CDN می‌تواند امنیت را با تضمین کاهش DDoS، بهبود گواهی‌های امنیتی و سایر بهینه سازی‌ها بهبود بخشد. CDN چگونه کار می‌کند؟ هسته‌ی یک CDN شبکه‌ای از سرورها است که با هدف ارائه‌ی محتوا به صورت سریع، ارزان، قابل اعتماد و ایمن است. به منظور بهبود سرعت و قابلیت اتصال CDN، سرورها را در نقاط مبادله‌ی بین شبکه‌های مختلف قرار می‌دهد. این نقاط مبادله‌‌ی اینترنت (IXP, Internet Exchange Point) مکان‌های اصلی هستند که سرویس دهندگان مختلف اینترنت برای دسترسی به ترافیک ناشی از شبکه‌های مختلف خود به یکدیگر دسترسی دارند. با اتصال به این مکان‌های با سرعت و قدرت اتصال بالا، ارائه دهنده‌ی CDN می‌تواند هزینه‌ها و زمان حمل و نقل را در تحویل داده‌های با سرعت بالا کاهش دهد. علاوه بر قرار دادن سرورها در IXPها، یک CDN برخی از بهینه سازی‌ها را در انتقال داده‌های استاندارد بین سرویس گیرنده و سرور انجام می‌دهد. CDNها مراکز داده را در مکان‌های استراتژیک و با افزایش امنیت در سراسر جهان قرار داده و به گونه‌ای طراحی شده اند تا انواع مختلف خرابی‌ها و جابجایی ترافیک اینترنت را مدیریت کنند. تاخیر - CDN چگونه زمان بارگذاری وب سایت را بهبود می‌بخشد؟ هنگام بارگذاری محتوا، با کاهش سرعت وب سایت تعداد کاربران نیز کم‌تر می‌شود. سرویس‌های CDN می‌توانند با روش‌های زیر به کاهش زمان بارگذاری کمک کنند: ماهیت توزیع شده‌ی CDN به صورت جهانی به معنای کاهش فاصله‌ی بین کاربران و منابع وب سایت است. به جای اجبار برای اتصال مستیم به سرور مبدا وب سایت، CDN به کاربران اجازه می‌دهد تا به یک مرکز داده‌ی نزدیک‌تر از لحاظ جغرافیایی متصل شوند. زمان اتصال به سرور کم‌تر، به معنی خدمات سریع‌تر است. بهینه سازی سخت افزاری و نرم افزاری مانند متعادل سازی کارآمد بار و درایوهای سخت حالت جامد (Solid-state hard drives) می‌توانند به کاربران کمک کنند تا داده‌ها را سریع‌تر دریافت کنند. CDNها میتوانند میزان داده‌هایی را که با کاهش اندازه‌ی فایل‌ها با استفاده از تکنیک‌هایی مانند کمینه سازی و فشرده سازی فایل انتقال مییابند، کاهش دهند. اندازه‌ی فایلهای کوچک‌تر به معنی زمان بارگذاری سریع‌تر است. CDNها همچنین می‌توانند سایت‌هایی را که از گواهینامه‌های TLS/SSL استفاده می‌کنند با بهینه سازی استفاده‌ی مجدد اتصال‌ها و فعال سازی TLS false start (با کاهش زمان Handshaking به یک RTT)، سرعت بخشند. قابلیت اطمینان و افزونگی - آیا CDN وب سایت را همیشه آنلاین نگه می‌دارد؟ Uptime مولفه‌ی مهمی برای هر کسی است که دارای مالکیت اینترنتی دارد. خرابی‌های سخت افزاری و تکانهای ترافیکی، به عنوان یک نتیجه از حملات مخرب و یا فقط افزایش محبوبیت، پتانسیل پایین آوردن کارایی وب سرور و جلوگیری از دسترسی کاربران به سایت یا سرویس را دارند. CDN متعادل داراي چندين ويژگي است که باعث کمینه شدن مدت از کار افتادگی می‌شود: متعادل سازی بار با توزیع ترافیک شبکه به طور مساوی بین سرورهای مختلف انجام می‌شود و باعث می‌شود سرعت جابجایی ترافیک افزایش یابد. شکست هوشمند (Intelligent failover) خدمات بدون وقفه را فراهم می‌کند حتی اگر یک یا چند سرور CDN به دلیل خرابی سخت افزاری غیر فعال شوند؛ Failover می‌تواند مجددا ترافیک را به سرورهای عملیاتی دیگر توزیع کند. در صورتی که کل یک مرکز داده دارای مشکلات فنی باشد، مسیریابی Anycast (یک به چند) ترافیک را به یک مرکز داده‌ی دسترسی دیگر منتقل می‌کند و اطمینان حاصل می‌کند که هیچ یک از کاربران دسترسی به وب سایت را از دست نمی‌دهند. امنیت داده‌ها - چگونه CDN از داده‌ها محافظت می‌کند؟ امنیت اطلاعات بخشی جدایی ناپذیر از CDN است. CDN می‌تواند یک سایت را با گواهینامههای TLS/SSL به روز امن نگه دارد که استانداردهای بالا را برای احراز هویت، رمزنگاری و یکپارچگی تضمین می‌کند. برای اطلاعات بیشتر در این زمینه، نگرانی‌های امنیتی در مورد CDNها را بررسی کنید و تحقیق کنید چه کارهایی می‌تواند برای ارائه‌ی ایمن محتوا انجام شود. همچنین در مورد امنیت در SSL/TLS نیز اطلاعات بیشتری کسب کنید. هزینه‌ی پهنای باند - CDN چگونه هزینه‌های پهنای باند را کاهش می‌دهد؟ هر بار که سرور اصلی به درخواست پاسخ می‌دهد، پهنای باند مصرف می‌شود. خواهیم دید که چگونه یک CDN هزینه‌ی درخواست‌های مبدا را کاهش می‌دهد. (به زودی در ادامه با جزییات بیشتر توضیح خواهیم داد) مقاله‌ی بعدی در رابطه با کارایی CDNها خواهد بود، با ما همراه باشید.
×