🔁 جریان HTTP :
هنگامی که یک کلاینت می‌خواهد با یک سرور (چه سرور نهایی و چه یک پروکسی میانی) ارتباط برقرار کند، مراحل زیر را طی می‌کند: 👇
1️⃣ باز کردن اتصال TCP
اتصال TCP برای ارسال یک یا چند درخواست و دریافت پاسخ استفاده می‌شود. کلاینت ممکن است یک اتصال جدید باز کند، از یک اتصال موجود مجدداً استفاده کند، یا چندین اتصال TCP به سرورها باز کند. 🔗
2️⃣ ارسال پیام HTTP
پیام‌های HTTP (قبل از HTTP/2) قابل خواندن توسط انسان هستند. در HTTP/2، این پیام‌ها در Frameها کپسوله‌سازی می‌شوند که خواندن مستقیم آن‌ها را غیرممکن می‌سازد، اما اصل کار یکسان باقی می‌ماند.
📌مثال درخواست (Request):
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
3️⃣ خواندن پاسخ سرور
پاسخ ارسال شده توسط سرور خوانده می‌شود، مانند:
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!doctype html>… (در اینجا 29769 بایت از صفحه وب درخواستی قرار می‌گیرد)
4️⃣ بستن یا استفاده مجدد از اتصال
اتصال برای درخواست‌های بعدی بسته یا مجدداً استفاده می‌شود. 🔄
⚠️ ملاحظه Pipelining
اگر پایپ‌لاینینگ HTTP فعال باشد، چندین درخواست می‌توانند بدون انتظار برای دریافت کامل اولین پاسخ ارسال شوند. با این حال، پیاده‌سازی پایپ‌لاینینگ HTTP در شبکه‌های موجود که بخش‌های قدیمی نرم‌افزار با نسخه‌های مدرن همزیستی دارند، دشوار است. پایپ‌لاینینگ HTTP در HTTP/2 با Multiplexing قوی‌تر درخواست‌ها در یک Frame جایگزین شده است.
📝 پیام‌های HTTP (HTTP Messages)
پیام‌های HTTP، همانطور که در HTTP/1.1 و نسخه‌های قبلی تعریف شده‌اند، قابل خواندن توسط انسان هستند. در HTTP/2، این پیام‌ها در یک ساختار دودویی، یعنی Frame، جاسازی می‌شوند که امکان بهینه‌سازی‌هایی مانند فشرده‌سازی هدرها و Multiplexing را فراهم می‌کند. حتی اگر تنها بخشی از پیام اصلی HTTP در این نسخه ارسال شود، معناشناسی هر پیام بدون تغییر باقی می‌ماند و کلاینت درخواست اصلی HTTP/1.1 را (به صورت مجازی) بازسازی می‌کند. بنابراین، درک پیام‌های HTTP/2 در قالب HTTP/1.1 مفید است.
دو نوع پیام HTTP وجود دارد: درخواست‌ها (Requests) و پاسخ‌ها (Responses) که هر کدام قالب خاص خود را دارند.
🔹️ درخواست‌ها (Requests) 📤
درخواست‌ها شامل عناصر زیر هستند:
• متد HTTP: معمولاً یک فعل مانند GET، POST یا یک اسم مانند OPTIONS یا HEAD که عملیاتی را که کلاینت می‌خواهد انجام دهد، تعریف می‌کند. به طور معمول، کلاینت می‌خواهد یک منبع را واکشی کند (با استفاده از GET) یا مقدار یک فرم HTML را ارسال کند (با استفاده از POST).
• مسیر منبع: URL منبع که عناصر واضح از زمینه، مانند پروتکل (https://)، دامنه (مانند developer.mozilla.org) یا پورت TCP (مانند 80) از آن حذف شده است.
• نسخه پروتکل HTTP.
• هدرها (Headers) اختیاری: که اطلاعات اضافی را برای سرورها منتقل می‌کنند.
• بدنه (Body): برای برخی متدها مانند POST، مشابه پاسخ‌ها، که منبع ارسال شده را شامل می‌شود.
🔹️ پاسخ‌ها (Responses) 📥
پاسخ‌ها شامل عناصر زیر هستند:
• نسخه پروتکل HTTP: که از آن پیروی می‌کنند.
• کد وضعیت (Status Code): نشان می‌دهد که آیا درخواست موفقیت‌آمیز بوده یا خیر، و چرا. 🔢
• پیام وضعیت (Status Message): یک توضیح کوتاه غیررسمی از کد وضعیت.
• هدرهای HTTP: مانند هدرهای درخواست‌ها.
• بدنه (Body) اختیاری: که منبع واکشی شده را شامل می‌شود.
📝 نتیجه‌گیری
فهمیدیم HTTP یک پروتکل قابل توسعه (Extensible) است که استفاده از آن آسان می‌باشد. ساختار کلاینت-سرور، همراه با قابلیت افزودن هدرها، به HTTP اجازه می‌دهد تا همگام با قابلیت‌های گسترده وب پیشرفت کند. 📈
اگرچه HTTP/2 با جاسازی پیام‌های HTTP در Frameها برای بهبود عملکرد، مقداری پیچیدگی اضافه می‌کند، ساختار اصلی پیام‌ها از زمان HTTP/1.0 یکسان باقی مانده است. جریان Session همچنان اساسی است و امکان بررسی و Debug کردن آن را با یک HTTP network monitor فراهم می‌کند. 🔍
🔖 هشتگ‌ها:
#HTTP #RequestResponse #Networking #CORS #WebSecurity #Session #TCP #QUIC