اتصال سمج (پروتکل انتقال ابرمتن): تفاوت میان نسخه‌ها
بدون خلاصۀ ویرایش برچسب‌ها: برگردانده‌شده ویرایشگر دیداری ویرایش همراه ویرایش از وبگاه همراه |
بدون خلاصۀ ویرایش برچسب‌ها: برگردانده‌شده ویرایشگر دیداری ویرایش همراه ویرایش از وبگاه همراه |
||
| خط ۳: | خط ۳: | ||
== نحوه عملکرد == |
== نحوه عملکرد == |
||
=== HTTP 1.0 === |
|||
=== کدر پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. === |
|||
در نسخهٔ اول از [[پروتکل انتقال ابرمتن]] هیچ تعریف رسمی برای استفاده از اتصال پایا وجود نداشت. این تعریف بعدها به این پروتکل افزوده شد. تمامی [[عامل کاربر|عوامل کابری]] که قابلیت اتصال پایا را دارا بودند، سرآیند زیر را به بستهٔ پاسخ می‌افزودند: |
|||
در نسخهٔ اول از پروتکل انتقال ابرمتن هیچ تعریف رسمی برای استفاده از اتصال پایا وجود نداشت. این تعریف بعدها به این پروتکل افزوده شد. تمامی در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. دیگر نیز استفاده می‌شود. کابری که قابلیت اتصال پایا را دارا بودند، سرآیند زیر را به بستهٔ پاسخ می‌افزودند: |
|||
{{چپ‌چین}} |
|||
Connection: Keep-Alive |
|||
| ⚫ | |||
{{پایان چپ‌چین}} |
|||
| ⚫ | |||
=== HTTP 1.1 === |
=== HTTP 1.1 === |
||
نسخهٔ ۸ نوامبر ۲۰۲۰، ساعت ۰۶:۴۶
| HTTP |
|---|
 |
| روش‌های درخواست |
| زمینه‌های سرآیند |
| کدهای وضعیت |
در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.
نحوه عملکرد
کدر پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.
در نسخهٔ اول از پروتکل انتقال ابرمتن هیچ تعریف رسمی برای استفاده از اتصال پایا وجود نداشت. این تعریف بعدها به این پروتکل افزوده شد. تمامی در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال () بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. دیگر نیز استفاده می‌شود. کابری که قابلیت اتصال پایا را دارا بودند، سرآیند زیر را به بستهٔ پاسخ می‌افزودند:
با ارسال این درخواست، در صورت پشتیبانی سرور از این نوع اتصال، در بستهٔ پاسخ نیز همین سرآیند افزوده می‌شود. این عمل به معنای موافقت سرور برای برقرار نگاه داشتن اتصال می‌باشد. به‌این‌ترتیب، کلاینت بدون از بین بردن اتصال گ می‌توانست درخواست بعدی خود را ارسال نماید.
HTTP 1.1
در نسخهٔ ۱٫۱ تمامی اتصال‌ها پایا محسوب می‌شوند مگر اینکه خلاف آن در بسته مشخص گردد.[۱] اتصال‌های پایا در این نسخه از پیام Keep-Alive که در نسخهٔ قبلی استفاده می‌شد، استفاده نمی‌کنند. البته مهلتِ ارسالِ درخواست بر روی اتصال قبلی نیز کم شده است. مثلاً در سرور آپاچی نسخهٔ ۲٫۰ این زمان ۱۵ ثانیه[۲] و در نسخهٔ ۲٫۲ تنها ۵ ثانیه[۳] تعریف شده است.
مزیت‌ها
- امکان استفاده از لوله‌کشی HTTP فراهم می‌شود.
- نیازی به انجام عمل Handshaking نیست
- امکان گزارش خطاها بدون نیاز به بستن اتصال
براساس متن تعریف پروتکل انتقال ابرمتن (RFC 2616)[صفحه ۴۶] هیچ کاربری نباید بیش از ۲ اتصال همزمان به یک وب سرور یا پراکسی سرور ایجاد نماید. یک سرور پراکسی نیز تنها می‌تواند 2N اتصال به پراکسی سرور دیگر ایجاد نماید که N تعداد کاربران پراکسی سرور می‌باشد. این امر برای افزایش کارایی پروتکل انتقال ابرمتن لازم است تا جلوی ایجاد شلوغی در شبکه را بگیرد. در صورت پیاده‌سازی و استفاده صحیح از لوله‌کشی HTTP، اتصال‌های بیشتر هیچ تأثیری در افزایش کارایی شبکه نخواهند داشت.
معایب
- امروزه با توجه به گسترش شبکه‌های پرسرعت، باز نگاه داشتن اتصال وب‌سرور (مثلاً به مدت ۵ ثانیه در آپاچی) بیشتر باعث کاهش کارایی شبکه می‌شود تا افزایش آن.[۴]
- برای سرویس‌هایی که تک‌منبعی می‌باشند مانند سرویس میزبانی عکس بازنگاه‌داشتن اتصال بعد از ارسال منبع تنها هدر دادن توان سرور است.
- در حالت ارتباط‌دهنده سمج، برنامه‌می‌تواند این امکان را به‌دست‌آورد که به طور مداوم گزارشات خود را باتوجه به بسته نشدن اتصال، ارسال نماید.[۵]
استفاده در مرورگرها
مرورگر نت اسکیپ (از نسخهٔ ۴٫۰۵ به بعد) و مرورگر اینترنت اکسپلورر (از نسخهٔ ۴٬۰۱ به بعد) از اتصال پایا پشتیبانی می‌کنند.
مرورگر اینترنت اکسپلورر در نسخه‌های ۶ و ۷ از ۲ اتصال پایا استفاده می‌کند. اما از نسخهٔ ۸ تعداد اتصالات پایای استفاده شده به ۶ رسیده است.[۶] اتصالات پایا بعد از ۶۰ ثانیه عدمِ فعالیت بسته خواهند شد. این مقدار از طریق رجیستری ویندوز قابل تنظیم است.
مرورگر فایرفاکس نیز از این نوع اتصال پشتیبانی می‌کند. تعداد اتصالات قابل تنظیم است. (برای هر سرور یا پراکسی سرور یا در کل) اتصالات پایا بعد از ۱۱۵ ثانیه عدمِ فعالیت بسته خواهند شد که البته این مقدار نیز قابل تنظیم است.[۷]
مروگر اپرا از نسخهٔ ۴ از اتصالات پایا پشتیبانی می‌کند. تعداد اتصالات همزمان در این مرورگر قابل تنظیم می‌باشد. (برای هر سرور یا در کل)
جستارهای وابسته
منابع
- مشارکت‌کنندگان ویکی‌پدیا. «HTTP Persistent Connection». در دانشنامهٔ ویکی‌پدیای انگلیسی، بازبینی‌شده در ۱۳ اردیبهشت ۱۳۹۲.
- ↑ «RFC 2616 - HTTP/1.1 Definition». IETF. تاریخ وارد شده در
|تاریخ=را بررسی کنید (کمک) - ↑ . Apache 2 Documentation https://web.archive.org/web/20130503121401/http://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout. بایگانی‌شده از اصلی در ۳ مه ۲۰۱۳. پارامتر
|عنوان= یا |title=ناموجود یا خالی (کمک) - ↑ . Apache 2.2 Documentation http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout. پارامتر
|عنوان= یا |title=ناموجود یا خالی (کمک) - ↑ «HTTP Keep Alive is now considered harmful». بایگانی‌شده از اصلی در ۲۶ اوت ۲۰۱۱.
- ↑ http://javabyab.com/7762/قابلیت-persistent-connection-پروتکل-http-چیست-مزایایی-دارد؟
- ↑ «IE8 Speeds things up».
- ↑ http://kb.mozillazine.org/Network.http.keep-alive.timeout. پارامتر
|عنوان= یا |title=ناموجود یا خالی (کمک)
 | این یک مقالهٔ خرد علوم رایانه است. می‌توانید با گسترش آن به ویکی‌پدیا کمک کنید. |