Connection:keep-alive یعنی چه؟

[[younes]]

وقت بخیر
Connection:keep-alive یعنی چه؟ مگر نه اینه که پرتکل http به صورت در خواست و پاسخه؟

[negative60]

يعنی زنده نگاه داشتن کانکشن که برای رد و بدل کردن درخواست و پاسخ جای ديگه بدون برقراری مجدد ارتباط کاربرد داره, نمونه بسيار کاربردی از اين امکان رو در برنامه های پيام رسان ميشه مشاهده کرد

[-سیّد-]

يعنی زنده نگاه داشتن کانکشن که برای رد و بدل کردن درخواست و پاسخ جای ديگه بدون برقراری مجدد ارتباط کاربرد داره, نمونه بسيار کاربردی از اين امکان رو در برنامه های پيام رسان ميشه مشاهده کرد
البته برنامه‌های پیام‌رسان معمولاً از tcp استفاده می‌کنن و پروتوکل خودشون رو روی tcp پیاده‌سازی می‌کنن، بعید می‌دونم از http برای این کار استفاده کنن. یه دلیلش یه طرفه بودن پروتوکل http هست که توی یه برنامه‌ی پیام‌رسان خیلی چیز جالبی نیست (البته ممکنه از روش‌های خاصی برای این کار استفاده بشه: http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push ).


اما سؤال اصلی:
توی header های HTTP، در صورتی که client بگه:

Connection: keep-alive
یعنی داره به سرور می‌گه من این قابلیت رو دارم که روی همین connection که با تو برقرار کردم، بعد از این که این درخواست رو جواب دادی، یه تعداد درخواست دیگه هم بفرستم.
سرور هم که این رو می‌بینه، اگه اون هم این قابلیت رو داشته باشه، دقیقاً همین رو توی header های جواب برمی‌گردونه. در این صورت بعد از ارسال جواب توسط سرور، نه client و نه سرور، هیچ کدوم connection رو نمی‌بندن و client می‌تونه درخواست بعدیش رو روی همون connection بفرسته.
کاربرد اصلیش، توی گرفتن اطلاعات مرتبط با یه صفحه‌ی HTML هست، یعنی عکس‌ها و css و js و ....

۲ تا نکته:
۱. توی HTTP نسخه‌ی 1.0 این پیش‌فرض نیست و باید client برای سرور توی درخواستش بفرسته. ولی توی HTTP/1.1 این قضیه به صورت پیش‌فرض هست.
۲. در این حالت، نمی‌تونیم به صورت همزمان چند درخواست رو برای سرور بفرستیم. یعنی باید درخواست‌ها یکی پس از دیگری فرستاده بشن. مثلاً اگه یه صفحه ۵ تا css داشته باشه و ۲ تا js و ۲۰ تا عکس، اینها یکی یکی load می‌شن و در نتیجه کاربر پیر می‌شه! :)
برای این موضوع دو راهکار وجود داره:
یکی این که بی‌خیال keep-alive بشین و برای دریافت عکس‌ها، برای هر کدوم یه connection جدید به سرور باز کنید. البته در این حالت حتماً باید یه محدودیتی روی تعداد connection همزمان بذارید، وگرنه به جای کاربر، سرور پیر می‌شه! مرورگرها معمولاً از این روش استفاده می‌کنن.
دوم این که از HTTP نسخه‌ی 2 استفاده کنید که فرستادن چند درخواست همزمان روی یک connection رو پشتیبانی می‌کنه.

توضیحات کامل در ویکیپدیا:
http://en.wikipedia.org/wiki/HTTP_persistent_connection

[negative60]

البته برنامه‌های پیام‌رسان معمولاً از tcp استفاده می‌کنن و پروتوکل خودشون رو روی tcp پیاده‌سازی می‌کنن، بعید می‌دونم از http برای این کار استفاده کنن. یه دلیلش یه طرفه بودن پروتوکل http هست که توی یه برنامه‌ی پیام‌رسان خیلی چیز جالبی نیست (البته ممکنه از روش‌های خاصی برای این کار استفاده بشه: http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push ).



منظور بنده پيام رسانهای تحت وب بود حتماً ميدونيد که پرتوکل HTTP (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) خودش روی TCP کار ميکنه! و هر ارتباطی که از بروزر با وب سرور سايتی برقرار ميشه تحت پروتکل HTTP هست و زمانی که از سرويس پيام رسانی در سايتی استفاده ميکنيد در واقع روی HTTP فعاليت ميکنيد نه پروتکول خصوصی روی TCP





کاربرد اصلیش، توی گرفتن اطلاعات مرتبط با یه صفحه‌ی HTML هست، یعنی عکس‌ها و css و js و ....



فرقی نميکنه کانکشن keep-alive باشه يا Close در هر صورت درخواست و پاسخ کامل انجام خواهد شد و عکس ها و فايل ها کامل لود ميشن، قابليت keep-alive اين امکان رو فراهم ميکنه بعد از اتمام کار يک درخواست و پاسخ کانکشن همچنان برای درخواست های ديگه باز ميمونه.
يکی ديگه از دلايل اينکه چرا از keep-alive استفاده ميکنند اين هست که خود برقراری مجدد ارتباط TCP جهت ارسال يک درخواست ديگه زمان بر و همچنين ترافيک بيشتری روی کلاينت/سرور اعمال ميکند.




In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request. Such persistent connections reduce request latency perceptibly, because the client does not need to re-negotiate the TCP 3-Way-Handshake connection after the first request has been sent. Another positive side effect is that in general the connection becomes faster with time due to TCP's slow-start-mechanism.






دوم این که از HTTP نسخه‌ی 2 استفاده کنید که فرستادن چند درخواست همزمان روی یک connection رو پشتیبانی می‌کنه.


امکان چند درخواستی در ورژن 1.1 هم وجود داره:


HTTP pipelining further reduces lag time, allowing clients to send multiple requests before waiting for each response. Another improvement to the protocol was byte serving, where a server transmits just the portion of a resource explicitly requested by a client.

[-سیّد-]

منظور بنده پيام رسانهای تحت وب بود حتماً ميدونيد که پرتوکل HTTP (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) خودش روی TCP کار ميکنه! و هر ارتباطی که از بروزر با وب سرور سايتی برقرار ميشه تحت پروتکل HTTP هست و زمانی که از سرويس پيام رسانی در سايتی استفاده ميکنيد در واقع روی HTTP فعاليت ميکنيد نه پروتکول خصوصی روی TCP

بله در مورد پیام‌رسان‌های تحت وب صحیح می‌فرمایید.




فرقی نميکنه کانکشن keep-alive باشه يا Close در هر صورت درخواست و پاسخ کامل انجام خواهد شد و عکس ها و فايل ها کامل لود ميشن، قابليت keep-alive اين امکان رو فراهم ميکنه بعد از اتمام کار يک درخواست و پاسخ کانکشن همچنان برای درخواست های ديگه باز ميمونه.

من جمله‌ام رو بد نوشتم و نتونستم منظورم رو برسونم. درستش می‌شه این:

کاربرد اصلیش، توی گرفتن اطلاعات مرتبط با یه صفحه‌ی HTML به صورت همزمان هست که باعث می‌شه سرعت load شدن صفحه بالا بره، یعنی عکس‌ها و css و js و ....
یعنی همونطور که شما گفتید، در هر دو صورت صفحه کامل load می‌شه و تأثیری توی functionality سیستم نخواهد داشت.



امکان چند درخواستی در ورژن 1.1 هم وجود داره:
حق با شماست، این رو نمی‌دونستم.
ولی طی بررسی‌هایی که کردم، متوجه شدم که pipelining توی ۱.۱ یه مقدار محدودیت داره و اون اینه که جواب‌ها باید به ترتیب دریافت شدن درخواست‌ها فرستاده بشن:
http://en.wikipedia.org/wiki/HTTP_pipelining

The speedup is less apparent on broadband connections, as the limitation of HTTP 1.1 still applies: the server must send its responses in the same order that the requests were received — so the entire connection remains first-in-first-out[1] (http://en.wikipedia.org/wiki/HTTP_pipelining#cite_note-pipeline-1) and HOL blocking (http://en.wikipedia.org/wiki/Head-of-line_blocking) can occur.