پروتکل HTTP چیست

در مقاله قبلی معرفی پروتکل HTTP، برخی از اصول اولیه HTTP، مانند ساختار URL، کد وضعیت (status codes) و header های درخواست/پاسخ را پوشش دادیم. با شناختی که از این مفاهیم پیدا کردیم، اینجا توضیح می دهیم که جنبه‌های ظریف‌تر پروتکل HTTP چیست ، مانند کنترل اتصال (connection handling)، تأیید اعتبار (authentication) و HTTP کشینگ می اندازیم. این موضوعات نسبتاً گسترده هستند، اما مهم‌ترین بخش‌ها آن را پوشش خواهیم داد.

HTTP Connections

اتصال بین کلاینت و سرور باید قبل از برقراری ارتباط با یکدیگر ایجاد شود، و HTTP از پروتکل قابل‌اعتماد TCP transport برای ایجاد این اتصال استفاده می‌کند. به طور پیش‌فرض، ترافیک وب از پورت TCP 80 استفاده می‌کند. یک جریان TCP/IP که تضمین می‌کند که این بسته‌ها به ترتیب صحیح و بدون شکست ارسال می‌شوند. HTTP یک پروتکل لایه برنامه (application layer) بر روی TCP/IP است.

HTTPS نسخه امن شده HTTP است و یک‌لایه اضافی بین HTTP و TCP به نام TLS یا SSL ایجاد می‌کند (به ترتیب Transport Layer Security یا Secure Sockets Layer). به طور پیش‌فرض HTTP از طریق پورت 443 ارتباط برقرار می‌کند و ما بعداً در این مقاله به HTTPS خواهیم پرداخت.

اتصال HTTP با <source-IP, source-port> و <destination-IP, destination-port> شناخته می‌شود. در کلاینت، یک برنامه HTTP با <IP, port> شناسایی می‌شود. برقراری ارتباط بین دو نقطه پایانی یک فرآیند چندمرحله‌ای است و که شامل موارد زیر است :

• عملیات IP resolve از طرف‌ host name به‌واسطه DNS (پیدا کردن IP آدرس)
• ایجاد ارتباط با سرور
• ارسال یک درخواست
• انتظار برای پاسخ
• بستن ارتباط

سرور همیشه مسئول پاسخ دادن، با هدر و پاسخ‌های صحیح می‌باشد.

در HTTP/1.0  همه اتصالات بعد از یک تراکنش بسته می‌شدند؛ بنابراین، اگر یک مشتری می‌خواست سه تصویر جداگانه را از همان سرور درخواست کند، سه اتصال جداگانه به هاست ایجاد می‌شد. همان‌طور که در نمودار بالا مشاهده میکنید، این موضوع منجر به تأخیر در شبکه می‌شود. برای بهبود این موضوع راه‌حل پایین پیشنهاد می‌شود.

برای کاهش تأخیر برقراری ارتباط، HTTP/1.1 ارتباطات مداوم (persistent connections) و ارتباطات طولانی را معرفی کرد که تا زمانی که مشتری آن‌ها را ببندد باز می‌ماند. اتصالات پایدار (Persistent connections) در HTTP/1.1 به طور پیش‌فرض قرار دارند و ایجاد یک اتصال مشترک نیاز به تنظیم Connection: close توسط کلاینت در هدر درخواست می‌باشد. این به سرور می‌گوید که اتصال را بعد از ارسال پاسخ ببندد.

علاوه بر اتصالات مداوم، مرورگرها / کلاینت‌ها از تکنیکی به نام اتصالات موازی (parallel connections) نیز استفاده می‌کنند تا تأخیر شبکه را به حداقل برساند. مفهوم قدیمی ارتباطات موازی شامل ایجاد مجموعه ای از اتصالات (عموماً پوشش در شش اتصال است). اگر شش منبع وجود دارد که کلاینت باید از یک وب‌سایت بارگیری کند، مشتری شش اتصال موازی (parallel connections) را برای دانلود آنها ایجاد می‌کند و نتیجه تحول در سرعت است. این یک پیشرفت عظیم در ارتباطات سریال است که در آن کلاینت فقط پس از اتمام دانلود منبع قبلی یک، یک منبع جدید دانلود می‌کند.

اتصالات موازی، همراه با اتصالات مداوم، بهترین راه‌حل برای حداقل رساندن تأخیر شبکه و ایجاد یک تجربه روان برای کلاینت است. برای مطالعه دقیق تر میتوانید به این سایت مراجعه کنید

Connection Handling سمت سرور

سرور، غالباً اتصالات ورودی را گوش می‌دهد و بعد از دریافت درخواست، آنها را پردازش می‌کند. این عملیات شامل:

• ایجاد سوکت برای شروع گوش‌دادن پورت 80 (یا پورتهای دیگر)
• دریافت درخواست و تجزیه‌وتحلیل پیام
• پردازش پاسخ
• تنظیم هدر پاسخ
• ارسال پاسخ به مشتری
• بستن ارتباط در صورت پیدا کردن Connection: close در هدر درخواست

البته لیست بالا یک لیست جامع از عملیات نیست. برای ایجاد پاسخ‌های سفارشی‌تر، بیشتر برنامه‌ها و وب‌سایت‌ها باید بدانند چه کسی درخواست می‌کند که این مربوط به حوزه شناسایی (identification) و احراز هویت (identification) است.

کاربرد شناسایی و احراز هویت در پروتکل HTTP چیست

HTTP یک پروتکل لایه application  بروی TCP/IP می‌باشد

لازم هست که بدانید چه کسی برای ردیابی استفاده از برنامه یا سایت و الگوهای تعامل کلی کاربران به یک سرور متصل می‌شود. فرض شناسایی ، فرض شناسایی این است که پاسخ را به ‌منظور فراهم‌ کردن یک تجربه شخصی آماده کنیم. طبیعتاً ، سرور باید بداند که کاربر چه کسی است تا این قابلیت را فراهم کند.

چندراه مختلف وجود دارد که یک سرور می‌تواند این اطلاعات را جمع‌آوری کند، و بیشتر وب‌سایت‌ها از روش‌های ترکیبی برای دستیابی به این هدف استفاده می‌کنند:

• Request headers : ما هدر هایFrom, Referer, User-Agent را در بخش اول دیدیم.
• IP address – Client-IP کلاینت
• Fat Urls – ذخیره کردن وضعیت کاربر فعلی با تغییر نشانی اینترنتی (URL) و تغییر مسیر (redirecting) به یک نشانی اینترنتی متفاوت با هر کلیک، هر کلیک اساساً این حالت را در کنار هم ذخیره می‌کند.
• Cookies – محبوب‌ترین رویکرد، بدون ایجاد مزاحمت.

کوکی‌ها به سرور اجازه می‌دهند تا اطلاعات دلخواه را برای پاسخ‌های خروجی از طریق هدر پاسخ Set-Cookie ضمیمه کند. هر کوکی با یک چند جفت name=value که با سمی‌کالن (;) از هم جدا می‌شوند مانند: Set-Cookie: session-id=12345ABC; username=nettuts.

یک سرور همچنین می‌تواند کوکی‌ها را در یک domainو pathمحدود کند، و آنها را با یک مقداردهی expires ماندگار کند. کوکی‌ها به طور خودکار برای هر درخواستی که برای یک سرور ایجاد می‌شود توسط مرورگر ارسال می‌شوند و مرورگر اطمینان می‌دهد که فقط domain - و path هر کوکی‌های خاص، با درخواست ارسال شوند. هدر درخواستCookie: name=value [; name2=value2] برای ارسال این کوکی ها به سرور مورد استفاده قرار میگیرد.

بهترین راه برای شناسایی یک کاربر این است که از آن‌ها بخواهیم که sign up و log in بکنند، اما اجرای این ویژگی نیازمند به‌زحمت انداختن دولوپر و کاربر است.

تکنیک‌هایی مانند OAuth این نوع ویژگی را ساده‌تر می‌کنند، اما به رضایت کاربر برای کارکردش نیاز دارد، احراز هویت در اینجا نقش بزرگی را ایفا می‌کند و احتمالاً تنها راه شناسایی و تأیید کاربر است.

احراز هویت(Authentication)

منظور از احراز هویت در پروتکل HTTP چیست ؟ از یک فرم ساده احراز هویت به نام Basic Authentication پشتیبانی می‌کند، همین‌طور از Digest Authentication به ‌منظور امنیت بیشتر استفاده می‌کند.

در تأیید Basic Authentication ، سرور در ابتدا درخواست مشتری را با عنوان پاسخ WWW - Authenticate و کد وضعیت401 Unauthorized را تکذیب می‌کند. بعد از دیدن این هدر، مرورگر یک login dialog را نمایش می‌دهد که برای نام کاربری و رمز عبور ایجاد می‌شود. این اطلاعات در قالب کدگذاری base-64 رمزنگاری شده و در هدر Authentication ارسال می‌شوند. این سرور اکنون می‌تواند درخواست را تأیید کرده و اجازه دسترسی به اسناد معتبر را بدهد. برخی از سرورها همچنین ممکن است یک هدرد Authentication-Info که حاوی جزئیات بیشتر احراز هویت هست را ارسال کنند.

Basic-Authentication نتیجه Proxy Authentication است. با تفاوت اینکه جای یک وب سرور، challenge احراز هویت توسط یک پروکسی میانی درخواست می‌شود. پروکسی یک هدر Proxy-Authenticate با یک کد وضعیت 407 Unauthorized در پاسخ ارسال می‌کند. مشتری اعتبارنامه را از طریق هدر درخواست Proxy-Authorization ارسال می‌کند.

Digest Authentication شبیه نوع Basic است و از همان تکنیک handshake (فرایند شروع عملیات ارتباطی بین دو سیستم ) با عنوان WWW-Authentication و Autorizationاستفاده می‌کند، اما Digest از یک عملکرد hashing مطمئن‌تر برای رمزگذاری نام کاربری و رمز عبور استفاده می‌کند (معمولاً با فانکشن های MD5 یا KD digest). اگرچه تصور می‌شود تأیید هویت Digest از امنیت نوع Basic بیشتر باشد، اما وب‌سایت‌ها معمولاً از Basic Authentication به خاطر پیاده سازی راحتش استفاده میکنند. برای کاهش نگرانی‌های امنیتی، از Basic Auth در کنار SSL استفاده می‌شود.

HTTP امن

آیا می دانید تفاوت بین HTTPS و پروتکل HTTP چیست ؟ پروتکل HTTPS اتصال ایمن را در وب فراهم می‌کند. ساده‌ترین راه برای اطلاع از اینکه یک وب‌سایت از HTTPS استفاده می‌کند بررسی نوار آدرس مرورگر است. مؤلفه امن HTTP شامل قرار دادن لایه رمزگذاری / رمزگشایی بین HTTP و TCP است و این مؤلفه اضافی SSL) Secure Sockets Layer) یا TLS) Transport Layer Security) است.

SSLها از یک فرم قدرتمند رمزنگاری با استفاده از RSA و رمزنگاری کلید عمومی (public-key) استفاده می‌کند. ازآنجاکه تراکنش (دریافت و انتقال) امن از اهمیت ویژه‌ای در وب برخوردار است و Public-Key Infrastructure به عنوان یک استاندار همه جا در حال اجرا میباشد.

کلاینت/سرورهای موجود مجبور نیستند نحوه برخورد با پیام‌ها را تغییر دهند زیرا سخت‌ترین کارها در لایه SSL اتفاق می‌افتد؛ بنابراین، می‌توانید برنامه وب خود را با استفاده از Authentication Basic توسعه دهید و به طور خودکار از مزایای SSL با انتقال به پروتکل https:// بهره‌مند شوید. بااین‌حال، برای اینکه برنامه وب روی HTTPS کار کند، باید یک گواهی دیجیتالی روی سرور ایجاد کنید.

Certificates

دقیقاً همان‌طور که برای نشان‌دادن هویت خود به کارت‌های شناسایی (ID cards) نیاز دارید، یک وب سرور برای شناسایی خود به یک گواهی دیجیتال احتیاج دارد. گواهینامه‌ها (یا “گواهی ها”) توسط یک مرجع صدور گواهینامه (CA) صادر می‌شود و هویت شما را در وب ضمانت می‌کند. CAها محافظان PKI هستند. رایج‌ترین نوع گواهینامه‌ها استاندارد X.509 v3 است که شامل اطلاعاتی از قبیل:

• صادرکنندهcertificate 
• الگوریتم استفاده شده برای certificate
• نام نهاد یا سازمانی که گواهینامه برای آنها صادر شده است
• اطلاعات مربوط به کلیدی عمومی (public key) برای هر نهاد
• امضای مرجع صدور گواهینامه (Certification Authority Signature) ، با استفاده از الگوریتم‌های امضای مشخص

هنگامی‌که یک کلاینت درخواستی را از طریق HTTPS ایجاد می‌کند، ابتدا سعی می‌کند تا یک گواهینامه را روی سرور پیداکند. اگر گواهی را یافت، سعی در تأیید صحت‌وسقم آن با لیست مورد تأیید CA دارد. اگر هیچ موردی در لیست CA یافت نشد، ممکن است صفحه مربوط به هشدار گواهی وب‌سایت نمایش داده بشود.

پس از تأیید گواهینامه، handshake SSL پایان‌یافته و انتقال ایمن در نتیجه آن ایجاد می‌شود.

 کشینگ در HTTP

منظوراز کشینگ در پروتکل HTTP چیست ؟ همه موافق هستند که دوباره‌کاری یک عمل بیهوده است. این یک قاعده کلی برای محقق کردن ساختار کشینگ در HTTP و یکی از ارکان اساسی در زیرساخت شبکه HTTP می‌باشد.

ازآنجاکه بیشتر عملیات‌ها تحت شبکه هستند، کش به صرفه‌جویی در وقت، هزینه و پهنای باند و همچنین به ارائه یک تجربه بکر در وب کمک می‌کند.

مطالب مرتبط: کش وب سایت چیست

کش در مکان‌های مختلف در زیرساخت شبکه، از مرورگر گرفته تا سرور مبدأ مورد استفاده قرار می‌گیرد. بسته به مکانی که قرار دارد، می‌توان کش را طبقه‌بندی کرد:

• Private (خصوصی): در مرورگر، نام‌های کاربری، گذرواژه‌ها، آدرس‌های اینترنتی، سابقه مرور و محتوای وب را ذخیره می‌کند. آنها به‌طورکلی کوچک و مختص یک کاربر خاص است.

• Public (عمومی): به‌عنوان یک پروکسی کشینگ (caching proxies) بین سرور و کلاینت مستقر شده است. اینها بسیار بزرگ‌تر هستند زیرا به چندین کاربر خدمات ارائه می‌کنند و یک روش معمول نگه‌داشتن چندین پروکسی کشینگ بین کلاینت و سرور مبدأ است. این کار به استفاده مکرر از محتوا کمک می‌کند، درحالی‌که به‌ندرت اجازه دریافت منابع از سرور اصلی را می‌دهد.

پردازش کش در پروتکل HTTP چیست

صرف‌نظر از اینکه کش کجا قرار دارد، فرایند پردازش کش کاملاً مشابه است:

• دریافت پیغام‌های درخواست.
• تجزیه‌وتحلیل URL و هدرها.
• جستو جوی نسخه محلی، در غیر این صورت، دریافت کردن و ذخیره کردن محلی.
• برسی تازگی به‌منظور چک کردن سن محتوای کش کشده ، ارسال درخواست به‌منظور تازه کردن refresh) ) منابع در صورت نیاز.
• ایجاد یک پاسخ از بنده کش و به‌روزرسانی هدرها.
• ارسال پاسخ به کلاینت.
• ثبت کردن تراکنش، در صورت علاقه.

البته سرور همیشه مسئول پاسخ دادن، با هدرها و پاسخ‌های صحیح میباشد. اگر سندی تغییر نکرده باشد، سرور باید با304 Not Modified پاسخ دهد. اگر نسخه ذخیره شده کش منقضی شده باشد، باید یک پاسخ جدید با هدر پاسخ به‌روز شده، ایجاد کند و 200 OK را بازگرداند. اگر منبع حذف شود، باید 404 Not Found را برگرداند. این پاسخ‌ها به تنظیم کش کمک می‌کنند و اطمینان می‌دهد که محتوای منقضی شده به مدت طولانی باقی نماند.

کش کنترل هدر

اتصالات موازی، همراه با اتصالات مداوم (persistent connections) بهترین راهکار این روزها برای به حداقل رساندن تأخیر شبکه می‌باشد.

اکنون‌که ما به درکی از نحوه عملکرد حافظه نهان رسیده‌ایم، زمان آن است که به هدر درخواست و پاسخ، که زیرساخت‌های کشینگ را فعال می‌کنند، نگاه کنیم. تازه بودن محتوا و به‌روز بودن مطالب یکی از اصلی‌ترین مسئولیت‌های کش است. برای حفظ کش کپی شده و سازگار با سرور, HTTP مکانیسم‌های ساده‌ای مانند انقضای اسناد (Document Expiration) و اعتبار دهی مجدد سرور (Server Revalidation) را فراهم کرده است. در ادامه توضیح داده می شوند منظور از این مفاهیم در پروتکل HTTP چیست .

انقضای اسناد (Document Expiration)

منظور از انقضای اسناد در پروتکل HTTP چیست ؟ به سرور مبدأ اجازه اتصال Cache-Control و Expires را به هدر هر سند می‌دهد. این به کلاینت و سایر سرورهای کش کمک می‌کند تا بدانند چه مدت یک سند معتبر و تازه است. کش می‌تواند نسخه کپی شده را تا زمانی که سن آن سند کمتر از تاریخ انقضا باشد، ارائه دهد و زمانی که یک سند منقضی شد، کش باید نسخه جدیدتر آن سند را با سرور بررسی کند و به همین ترتیب نسخه محلی آن را به‌روز کند.

Expires یک هدر پاسخ HTTP / 1.0 قدیمی است که مقدار را به برابر یک تاریخ مشخص قرار می‌دهد. این مکانیسم تنها در صورتی مفید است که ساعت‌های سرور با کلاینت همگام (sync) باشد که یک فرض وحشتناک است. این هدر در مقایسه با هدر نسخهٔ جدید Cache-Control: max-age=<s> که در HTTP/1.1 معرفی شده کمتر مورد استفاده قرار می‌گیرد که در اینجا max-age سن نسبی از زمان ایجاد پاسخ به ثانیه می‌باشد . پس اگر می‌خواهید سندی داشته باشید که بعد از 1 روز منقضی شود. هدر انقضا می‌بایست Cache-Control: max-age=86400 باشد.

اعتبار دهی سرور در HTTP

پس از انقضاء یک کش، سند کش شده مجدداً با سرور اعتباربخشی می‌شود تا بررسی کند که آیا این سند تغییر کرده است یا خیر. به این روش اعتباردهی مجدد سرور (Server Revalidation) گفته می‌شود و به‌عنوان مکانیسم پرس‌وجو برای بررسی بی‌اعتبار بودن (stale-ness) یک سند عمل می‌کند. لازم به ذکر است که منقضی شدن کش یک سند، به این معنی نیست که محتوای سند در سرور تغییر کرده است. Revalidation فقط وسیله‌ای برای اطمینان از تازه بودن کش است. به دلیل زمان انقضا (که از قبل توسط سرور تعیین شده است) ، کش نیازی به بررسی هر درخواست با سرور را ندارد، بنابراین در مصرف پهنای باند، زمان و ترافیک شبکه صرفه‌جویی می‌شود.

ترکیب انقضای اسناد (Document Expiration) و اعتباردهی سرور (Server Revalidation) یک مکانیسم بسیار مؤثر می‌باشد، و به سیستم‌های توزیع شده اجازه نگهداری کپی محتوا به همراه تاریخ انقضا را می‌دهد.

اگر فکر میکنید که محتوا به طور مکرر تغییر پیدا میکند ، می‌توانید زمان انقضا را کاهش داهید – این کار به سیستم اجازه می‌دهد تا همگام‌سازی به‌ طور مکرر صورت پذیرد.

مرحله تأیید مجدد می‌تواند با دو نوع هدر درخواست انجام شود: If-Modified-From و If-None-Match. مورد اول برای اعتبارسنجی مبتنی بر تاریخ است درحالی‌که دومی از هش(Hash) محتوا در Entity-Tags یا ETag استفاده می‌کند. این هدرها از تاریخ یا مقادیر ETag پاسخ قبلی سرور به‌دست‌آمده است. در صورت If-Modified-Since ، از هدر پاسخ Last-Modified استفاده می‌شود و برای If-None-Match ، هدر پاسخ Etag مورد استفاده قرار می‌گیرد.

کنترل قابلیت کشینگ در پروتکل HTTP چیست

مدت اعتبار یک سند باید توسط سرور تولیدکننده سند تعریف شود. اگر سند یک وب‌سایت روزنامه باشد، صفحه اصلی باید بعد از یک روز (یا در کشور ما حتی هر ساعت!) منقضی شود. HTTP با تدارک Cache-Control و Expires در هدر پاسخ انقضای هر سند را مشخص می‌کند. همان‌طور که قبلاً ذکر شد، Expires بر اساس تاریخ‌های دقیق است و یک راه‌حل مطمئن برای کنترل کش نیست.

هدر Cache-Control به نسبت هدر Expires بسیار مفیدتر است و دارای مقادیر مختلفی برای وادارکردن کلاینت‌ها به چگونگی ذخیره پاسخ‌ها می‌باشد:

• Cache-Control: no-cache : کلاینت مجاز به ذخیره سند است. بااین‌حال، برای هر درخواست باید عملیات اعتبار سنجی مجدد صورت بگیرد (محتوا از قبل دانلود شده است، تنها اعتبارسنجی صورت می‌گیرد). یک هدر سازگار با HTTP / 1.0 به نام Pragma: no-cache وجود دارد که به همین روش کار می‌کند.

• Cache-Control: no-store : یک دستورالعمل بالقوه که به کلاینت، به‌هیچ‌عنوان اجازه ذخیره کردن اسناد را نمی‌دهد.

• Cache-Control: must-revalidate : این دستورالعمل به کلاینت می‌گوید تا محاسبات مربوط به تازه بودن محتوا را کنار بگذارد و همیشه اعتبارسنجی (revalidate) را انجام دهد. درصورتی‌که سرور در دسترس نباشد، کش اجازه ارائه محتوا را ندارد.

• Cache-Control: max-age : این دستورالعمل یک زمان نسبی (به ثانیه) به‌منظور انقضا کش از زمانی که پاسخ تولید می‌شود را ایجاد می‌کند.

گذشته از این، اگر سرور هیچ Cache-Control ای ارسال نکند، کلاینت می‌تواند از الگوریتم انقضا اکتشافی خاص خود برای تعیین تازگی استفاده کند.

محدود کردن تازگی (Freshness) از سمت مشتری

• Cache-Control: min-fresh=<s> : حداقل برای <s> ثانیه باید سند تازه باشد.
• Cache-Control: max-stale یا Cache-Control: max-stale=<s> : درصورتی‌که سند بیشتر از <s> ثانیه منقضی شده باشد، سند از طریق کش قابل‌ارائه نباشد.
• Cache-Control: max-age=<s> : کش نمی‌تواند سندی را که بیش از <s> ثانیه ذخیره شده است را برگرداند.
• Cache-Control: no-cache یا Pragma: no-cache : کلاینت یک کش ذخیره شده را نمی‌پذیرد، مگر اینکه تجدید اعتبار صورت گیرد.

HTTP Caching در واقع یک موضوع بسیار جالب است و الگوریتم‌های بسیار پیچیده‌ای برای مدیریت محتوای ذخیره شده وجود دارد. برای نگاهی عمیق‌تر به این موضوع، به بخش کشینگ HTTP مراجعه کنید.

خلاصه

در این مطلب توضیح داده شد که مفاهیم اولیه پروتکل HTTP چیست و کاربرد های آن ها معرفی شد. سیاحت HTTP ما با اصول کلی بنیادی ساختار URL، کدهای وضعیت، و هدرهای درخواست/ پاسخ شروع شد و با تکیه بر این مفاهیم، ما به برخی از قسمت‌های موشکافانه‌تر HTTP ، مانند کنترل اتصال، شناسایی و احراز هویت و کش نگاه کردیم. امیدوارم توانسته باشم افق نگاه شما را به این کران بی‌پایان (HTTP) بازکرده باشم تا خودتان در آن شیرجه بزنید و بیشتر بیاموزید.