پروتکل HTTP چیست؟

پروتکل HTTP مخفف Hypertext Transfer Protocol یا «پروتکل انتقال اَبَرمتن» است و یکی از پروتکل‌های اصلی اینترنت است که مشخص می‌کند داده‌ها چگونه میان کلاینت و سرور در وب ردوبدل شوند. این پروتکل که پایه اصلی انتقال داده در وب است، امکان ارتباط میان مرورگرهای وب و وب‌سرورها را فراهم می‌کند. همچنین، HTTP قواعد درخواست و تحویل داده میان سیستم‌ها را نیز تعریف می‌کند.

باید دقت داشت که پروتکل HTTP یک پروتکل لایه کاربرد (Application Layer) در مدل OSI است که مرورگرها برای انتقال متن، تصویر و محتوای چندرسانه‌ای در سیستم‌های توزیع‌شده مبتنی بر وب از آن استفاده می‌کنند.

ویژگی‌های پروتکل HTTP

HTTP یک سازوکار استاندارد برای ارتباط فراهم می‌کند تا کلاینت‌ها و سرورها بتوانند منابع وب را به‌شکلی هماهنگ با یکدیگر مبادله کنند. مهمترین ویژگی‌های HTTP عبارتند از:

• بدون حالت (Stateless): هر درخواست HTTP مستقل از درخواست‌های دیگر است و خود پروتکل الزام نمی‌کند که سرور اطلاعات تعامل‌های قبلی را برای درخواست بعدی نگه دارد.
• مدل Client-Server: کلاینت منابع موردنیاز خود را درخواست می‌کند و سرور به این درخواست‌ها پاسخ می‌دهد.
• Request-Response: ارتباط HTTP بر چرخه «درخواست و پاسخ» استوار است.
• متدهای مختلف: متدهایی مانند GET و POST و PUT و DELETE نوع عملیات موردنظر روی یک منبع را مشخص می‌کنند.
• قابلیت توسعه: هدرها و دیگر نقاط توسعه HTTP اجازه می‌دهند قابلیت‌های جدید بدون تغییر معنای اصلی پروتکل به آن اضافه شوند.

تاریخچه HTTP

HTTP از یک پروتکل ساده برای انتقال اسناد به یکی از استانداردهای اصلی ارتباط در وب تبدیل شده است. توسعه اولیه پروتکل HTTP به همراه زبان HTML و فناوری‌های مرتبط با وب‌سرور و مرورگرها را به Tim Berners-Lee و تیمش در آزمایشگاه CERN نسبت داده‌اند. HTTP اولیه در آغاز دهه ۱۹۹۰ برای درخواست اسناد ابرمتن طراحی شد.

نسخه 1.0 این پروتکل یا همان HTTP/1.0 در سال ۱۹۹۶ و در قالب استاندارد RFC 1945 منتشر شد. سال بعد، استاندارد RFC 2068 اقدام به معرفی HTTP/1.1 نمود که در سال ۱۹۹۹، این نسخه مورد بازنگری قرار گرفت. HTTP/2 در سال ۲۰۱۵ با RFC 7540 استاندارد شد و نهایتاً HTTP/3 که مبتنی بر QUIC است در سال ۲۰۲۲ و در قالب استاندارد RFC 9114 منتشر شد.

استاندارد فعلی HTTP Semantics توضیح می‌دهد که HTTP از سال ۱۹۹۰ پروتکل اصلی انتقال اطلاعات در WWW بوده است. این استاندارد همچنین تأکید می‌کند که نسخه‌های اصلی HTTP صرفاً یکدیگر را «منسوخ» نکرده‌اند؛ هرکدام با توجه به شرایط استفاده مزایا و محدودیت‌های خود را دارند.

تفاوت نسخه‌های مختلف HTTP

یکی از نکاتی که برای درک HTTP امروزی اهمیت دارد، تفاوت میان معنای HTTP و نحوه انتقال پیام‌ها در نسخه‌های مختلف آن است. متدهایی مانند GET و POST و مفاهیمی مانند کدهای وضعیت، در نسخه‌های اصلی HTTP معنای مشترکی دارند، اما شیوه انتقال پیام متفاوت است. HTTP/1.1 از قالب پیام مبتنی بر متن استفاده می‌کند. HTTP/2 یک لایه framing باینری و قابلیت multiplexing را اضافه کرد تا چند جریان HTTP بتوانند به شکل کارآمدتری روی یک اتصال مدیریت شوند.

HTTP/3 همان معناشناسی اصلی HTTP را روی QUIC اجرا می‌کند. QUIC نیز قابلیت‌هایی مانند multiplexing جریان‌ها و کنترل جریان در سطح هر stream را فراهم می‌کند. HTTP/3 به QUIC متکی است و QUIC برای برقراری امنیت ارتباط از TLS 1.3 یا نسخه‌های بعدی آن در handshake خود استفاده می‌کند.

متدهای پروتکل HTTP

متدهای پروتکل HTTP مشخص می‌کنند کلاینت می‌خواهد چه عملیاتی روی منبعی که سرور ارائه می‌کند انجام دهد.

معنا و رفتار متدهای اصلی HTTP در استاندارد HTTP Semantics تعریف شده است.

درخواست و پاسخ در پروتکل HTTP

HTTP از مدل Request-Response یا همان درخواست و پاسخ استفاده می‌کند. به‌طور ساده، کلاینت درخواستی می‌فرستد و سرور پس از پردازش آن، پاسخی برمی‌گرداند. فرآیند معمول به این شکل است:

1. کلاینت درخواست را ارسال می‌کند: درخواست می‌تواند شامل متد، آدرس منبع، هدرها و در صورت نیاز محتوا یا بدنه درخواست باشد.
2. سرور درخواست را پردازش می‌کند: سرور درخواست را بررسی کرده و عملیات لازم را انجام می‌دهد.
3. سرور پاسخ می‌دهد: پاسخ معمولاً شامل کد وضعیت، هدرها و در صورت نیاز محتوا است.
4. کلاینت پاسخ را پردازش می‌کند: مرورگر یا نرم‌افزار کلاینت، داده دریافت‌شده را نمایش می‌دهد یا از آن استفاده می‌کند.

برای مثال، یک صفحه وب معمولاً فقط یک فایل نیست. مرورگر ممکن است ابتدا سند HTML را دریافت کند و سپس برای CSS، تصاویر، جاوا اسکریپت و سایر منابع درخواست‌های جداگانه‌ای ارسال کند.

چرخه درخواست در HTTP

وقتی یک صفحه وب را باز می‌کنید، مرورگر ممکن است انواع مختلفی از منابع را از سرور درخواست کند.

در این فرآیند:

• منبع درخواستی: محتوایی را مشخص می‌کند که کلاینت درخواست کرده است؛ مانند HTML یا CSS یا تصویر و …
• نوع منبع: فرمت محتوای موردنظر را مشخص می‌کند؛ مانند HTML یا CSS یا تصویر و JS یا JSON یا XML.
• پاسخ سرور: سرور فایل یا داده متناسب با درخواست را برمی‌گرداند.

دقت کنید که منظور از «چرخه درخواست HTTP» در اینجا این است که مرورگر برای منابع مختلف صفحه درخواست ارسال می‌کند و سرور فایل یا داده مربوط به هر درخواست را در پاسخ برمی‌گرداند.

اجزای درخواست و پاسخ در HTTP

یک نمونه ساده از درخواست و پاسخ

برای ملموس‌تر شدن ساختار HTTP، یک درخواست ساده در HTTP/1.1 می‌تواند به این شکل باشد:

GET /index.html HTTP/1.1
Host: example.com
Accept: text/html

و پاسخ سرور ممکن است مشابه نمونه زیر باشد:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

<html>
...
</html>

در HTTP/1.1، پیام از یک خط آغازین، مجموعه‌ای از فیلدهای هدر، یک خط خالی و در صورت وجود، بدنه پیام یا Message Body تشکیل می‌شود. این ساختار در RFC 9112 تعریف شده است.

کدهای وضعیت HTTP

کد وضعیت (HTTP Status Code) به کلاینت می‌گوید نتیجه پردازش درخواست چه بوده است که پنج گروه اصلی برای آن وجود دارد:

کد وضعیت بخشی از معنای پاسخ HTTP است و تعریف رسمی دسته‌های کد وضعیت در استاندارد HTTP Semantics قرار دارد.

تفاوت HTTP و HTTPS

HTTP و HTTPS دو اسکیم مختلف URI مرتبط با HTTP هستند. در یک ارتباط HTTPS، ارتباط HTTP به‌شکل امن برقرار می‌شود تا محرمانگی (Confidentiality) و یکپارچگی (Integrity) داده‌ها تأمین و هویت سرور برای کلاینت احراز شود. استاندارد RFC 9110 این ویژگی‌ها را بخشی از تعریف ارتباط امن برای URIهای https می‌داند. به همین دلیل، عبارت قدیمی «HTTPS یعنی HTTP روی SSL» دیگر توصیف مناسبی برای فناوری‌های امروزی نیست. برای نمونه، HTTP/3 از QUIC استفاده می‌کند و امنیت QUIC با TLS 1.3 یکپارچه شده است.

به‌طور خلاصه، ارسال اطلاعات حساس از طریق HTTP رمزنگاری‌نشده می‌تواند داده را در مسیر ارتباط در معرض مشاهده یا دست‌کاری قرار دهد؛ برای وبسایت‌های واقعی، باید از ارتباط امن HTTPS استفاده شود.

سازوکار کش در HTTP

یکی از قابلیت‌های مهم پروتکل HTTP، قابلیت HTTP Caching است. کش می‌تواند پاسخ قبلی را ذخیره کند و در صورت مجاز بودن، برای درخواست بعدی دوباره از آن استفاده کند. این کار می‌تواند زمان پاسخ و مصرف پهنای باند شبکه را کاهش دهد. رفتار کش از طریق هدرهایی مانند Cache-Control کنترل می‌شود. برای مثال، یک پاسخ تازه (Fresh) ممکن است بدون مراجعه مجدد به سرور منبع از کش ارائه شود. اگر پاسخ دیگر تازه نباشد، در شرایط مناسب می‌توان اعتبار آن را دوباره با سرور بررسی کرد.

این قابلیت یکی از دلایلی است که HTTP در عمل بسیار فراتر از یک چرخه ساده «درخواست و دریافت فایل» عمل می‌کند.

مزایای پروتکل HTTP

HTTP مزایای متعددی دارد که می‌توان به موارد زیر اشاره کرد:

• مستقل از پلتفرم: HTTP به یک سیستم عامل خاص محدود نیست.
• سازگاری گسترده: در مرورگرها، وب‌سرورها، APIها، پراکسی‌ها و زیرساخت‌های مختلف وب قابل استفاده است.
• قابلیت توسعه: هدرها و سازوکارهای توسعه، امکان افزودن قابلیت‌های جدید را فراهم می‌کنند.
• مدل ارتباطی ساده و عمومی: مدل Request-Response رابط مشترکی برای تعامل با منابع مختلف ایجاد می‌کند.
• پشتیبانی از کش: ذخیره و استفاده مجدد از پاسخ‌ها می‌تواند latency و مصرف پهنای باند را کاهش دهد.
• امکان ارتباط امن: HTTP می‌تواند از طریق HTTPS با محافظت رمزنگاری‌شده استفاده شود.

معایب و محدودیت‌های HTTP

HTTP در کنار همه مزایا و کاربردهایش، محدودیت‌هایی نیز دارد:

• HTTP بدون رمزنگاری امن نیست: اطلاعاتی که از طریق ارتباط HTTP عادی منتقل می‌شوند، حفاظت محرمانگی و یکپارچگی HTTPS را ندارند.
• محدودیت‌های نسخه‌های قدیمی‌تر: HTTP/1.1 برای مدیریت تعداد زیادی درخواست هم‌زمان محدودیت‌هایی دارد که نسخه‌های جدیدتر با روش‌هایی مانند multiplexing بهبودشان داده‌اند.
• Stateless بودن: برنامه‌هایی که نیاز دارند وضعیت کاربر را میان درخواست‌ها حفظ کنند، باید از سازوکارهای دیگری برای مدیریت آن استفاده کنند.
• پیچیدگی عملکرد واقعی وب: عملکرد HTTP به عواملی مانند نسخه پروتکل، کشینگ، شبکه، TLS، سرور، پراکسی‌ها و الگوی درخواست‌ها وابسته است؛ بنابراین نمی‌توان HTTP را به‌طور کلی «سریع» یا «کند» توصیف کرد.

سوالات متداول