پروتکل انتقال ابرمتن

پروتکل انتقال ابرمتن

استاندارد بین المللی	RFC 1945 HTTP/1.0 (۱۹۹۶) RFC 2068 HTTP/1.1 (۱۹۹۷) RFC 2616 HTTP/1.1 (۱۹۹۹) HTTP/1.1: نحو پیام و مسیریابی (۲۰۱۴) RFC 7231 HTTP/1.1: معانی و محتوا (۲۰۱۴) RFC 7232 HTTP/1.1: درخواست‌های شرطی (۲۰۱۴) RFC 7233 HTTP/1.1: درخواست‌های دامنه‌ای (۲۰۱۴) RFC 7234 HTTP/1.1: کشینگ (۲۰۱۴) RFC 7235 HTTP/1.1: تعیین اعتبار (۲۰۱۴) RFC 7540 HTTP/2:‏(۲۰۱۵) RFC 7541 HTTP/2: فشرده‌سازی سرآیند HPACK ‏(۲۰۱۵) RFC 8164 HTTP/2: امنیت فرصت طلبانه برای HTTP/2 ‏(۲۰۱۷) RFC 8336 HTTP/2: قاب ORIGIN ‏HTTP/2 ‏(۲۰۱۸) RFC 8441 HTTP/2: بوت استرپینگ سوکت‌های وب با HTTP/2 ‏(۲۰۱۸) RFC 8740 HTTP/2: استفاده از TLS 1.3 با HTTP/2 ‏(۲۰۲۰) RFC 9114 HTTP/3
توسعه یافته توسط	در ابتدا CERN؛ IETF،‏ W3C
تاریخ معرفی	۱۹۹۱ (۱۹۹۱-}})
وبگاه	httpwg.org/specs/

پروتکل انتقال ابرمتن (به انگلیسی: Hypertext Transfer Protocol)‏ (HTTP)، یک پروتکل لایه کاربرد در مدل مجموعه پروتکل اینترنت برای سامانه‌های اطلاعاتی توزیع‌شده، مشارکت‌گرا و ابررسانه است.‏ HTTP شالودهٔ ارتباط اطلاعاتی برای وب جهان‌گستر است که در آن مستندات ابرمتن شامل ابرپیوند به سایر منابعی اند که کاربر به راحتی می‌تواند به عنوان مثال با یک کلیک ماوس یا با تپ بر روی صفحه نمایش در یک مرورگر وب به آن‌ها دسترسی داشته باشد.

توسعه HTTP توسط تیم برنرز-لی در ۱۹۸۹ میلادی در سرن کلید خورد و در یک سند ساده رفتار کلاینت و سرور را با استفاده از اولین نسخه از پروتکل HTTP که نام نسخه ۰٫۹ بر آن نهاده شد توصیف نمود.

HTTP/3 آخرین نسخه از این پروتکل است که در ۲۰۲۲ میلادی منتشر شده و تا کنون در حدود %۲۵ از وبسایت‌های پیشگام در استانداردسازی به کار رفته‌است. HTTP/3 برای صفحات وب جهان واقعی تأخیر پایین‌تری داشته و اگر بر روی سرور فعال گردد سریع تر از HTTP/2 و حتی سریع‌تر از HTTP/1.1 خواهد بود و در برخی از موارد سرعت آن سه برابر HTTP/1.1 است (که اغلب تنها نسخه فعال است). یکی از دلایل آن این است که دیگر همچون استانداردهای قدیمی‌تر در این استاندارد از TCP (از TCP/IP) استفاده نشده.

اولین نسخه از پروتکل HTTP خیلی زود به نسخه‌های پیشرفته‌تری تکامل یافت که نقش اولین پیش‌نویس برای نسخهٔ ۱٫۰ که در آیندهٔ دور ایجاد شد را داشت.

توسعه اولین درخواست توضیحات (RFCهای) HTTP چند سال بعد شروع شد که تلاشی هماهنگ از سوی کارگروه مهندسی اینترنت (IETF) و ائتلاف وب جهان‌گستر (W3C) بود که بعدها کارگروه به IETF منتقل شد.

HTTP/1 در ۱۹۹۶ میلادی به عنوان نسخه ۱٫۰ نهایی‌سازی و کاملاً مستندسازی شد. این پروتکل در ۱۹۹۷ میلادی به نسخه ۱٫۱ تکامل یافت و سپس مشخصات آن در ۱۹۹۹ و ۲۰۱۴ بروزرسانی شدند.

گونهٔ امن آن به نام HTTPS توسط بیش از %۷۹ وبسایت‌ها مورد استفاده واقع شده‌اند.

HTTP/2 تجلی کارآمدتری از معانی «روی سیم بودن» HTTP است که در ۲۰۱۵ میلادی منتشر شد و توسط بیش از %۴۶ درصد وبسایت‌ها استفاده شده و اکنون تقریباً توسط تمامی مرورگرها (%۹۶ کاربران) و اکثریت سرورهای وب روی امنیت لایه انتقال (TLS) با استفاده از پروتکل توسعه دهندهٔ «مذاکره پروتکل لایه کاربرد»‏ (ALPN)‏ حمایت شده که در آن به TLS 1.2 یا نسخه جدیدتر آن نیاز است.

HTTP/3 خلف و جانشین HTTP/2 است که در ۲۰۲۲ میلادی منتشر شد و توسط %۲۵ وبسایت‌ها استفاده شده و اکنون توسط بسیاری از مرورگرها (%۷۳ کاربران) حمایت می‌شود.‏ HTTP/3 از QUIC به جای TCP به عنوان پروتکل انتقال زیربنایی خود استفاده می‌کند. این پروتکل همچون HTTP/2، نسخه‌های اصلی قبلی خود را منسوخ نمی‌کند. پشتیبانی از HTTP/3 ابتدا به کلودفلر و گوگل کروم و سپس فایرفاکس افزوده شد.

تاریخچه

تیم برنرز-لی

اصطلاح ابرمتن توسط تئودور هولم نلسون در ۱۹۶۵ میلادی در پروژه زاندو خلق شد که آن هم به نوبه خود از رؤیاپردازی‌های بازیابی و مدیریت اطلاعات میکروفیلم-مبنای سامانه «ممکس» دهه ۱۹۳۰ ونیوار بوش الهام گرفته شده بود که آن را در مقاله ۱۹۴۵ خود با عنوان «آنگونه که ما فکر می‌کنیم» توصیف شده بود. اختراع اصل HTTP همراه با HTML و فناوری‌های مرتبط با آن برای سرور وب و یک رابط کاربری کلاینت به نام مرورگر وب را به تیم برنرز-لی و تیمش در سرن می‌دهند. برنرز لی HTTP را به منظور کمک برای شکل‌گیری ایدهٔ دیگرش یعنی پروژه «WorldWideWeb» می‌خواست، پروژه‌ای که اولین بار در ۱۹۸۹ میلادی پیشنهاد شد و اکنون به آن وب جهان‌گستر می‌گویند.

اولین وب سرور در ۱۹۹۰ میلادی زنده شد. پروتکلی که مورد استفاده قرار گرفت فقط یک متد داشت که نام آن GET بود و کارش درخواست یک صفحه از یک سرور بود. پاسخ این درخواست از سرور همیشه یک صفحه HTML بود.

ساختار کلی

پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل کلاینت–سرور می‌باشد. برای مثال یک مرورگر وب می‌تواند یک کلاینت و نرم‌افزار موجود بر روی سرویس‌دهندهٔ وبسایت، یک سرور باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفتگو را آغاز می‌کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‌گذارد یا عملیات خاصی را انجام می‌دهد. نتیجهٔ این عملِ سرور در بستهٔ پاسخ HTTP برای کلاینت ارسال می‌شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‌باشد.

مرورگر وب یک نمونه از عامل کاربر (به انگلیسی: User Agent) است. از دیگر عوامل کاربر می‌توان به خزندهٔ وب، نرم‌افزارهای تلفن‌های همراه و نرم‌افزارهای دیگری که به وب متصل شده و از اطلاعات آن استفاده یا صفحه‌ای را نمایش می‌دهند، اشاره کرد.

پروتکل انتقال ابرمتن یک پروتکل لایهٔ کاربرد است که در مجموعه پروتکل اینترنت طراحی شده و مورد استفاده قرار می‌گیرد. این پروتکل با فرض اینکه لایهٔ حمل (Transport Layer) زیرین آن قابل اعتماد است طراحی شده و معمولاً از پروتکل هدایت انتقال (TCP) به عنوان لایهٔ زیرین استفاده می‌کند. با این حال از این پروتکل بر روی لایه‌های غیرقابل اطمینان نیز استفاده می‌شود؛ مثلاً در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی پروتکل داده‌نگار کاربر (یک پروتکل غیر امن) مورد استفاده قرار می‌گیرد.

منابع HTTP همگی با یک شناسانهٔ یکنواخت منبع (URI) یا به‌طور مشخص‌تر با یک نشانی وب (URL) آدرس‌دهی و مشخص می‌شوند. تمامی این آدرس‌ها با نشانهٔ http یا https آغاز می‌گردد. از این آدرس‌ها در زبان نشانه‌گذاری ابرمتن به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‌گردد و از آن تحت عنوان پیوند یا لینک یاد می‌شود.

نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال (به انگلیسی: Connection) برای چندین درخواست را دارد؛ مثلاً می‌تواند عکس‌ها، فایل‌های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند؛ لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته‌است.

جلسه

در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه (به انگلیسی: Session) گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال (TCP) بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ۸۰؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت (به انگلیسی: Status Line) و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.

یک نمونه از خط وضعیت در پاسخ به یک درخواست مجاز:

HTTP/1.1 200 OK

روش‌های درخواست

پروتکل انتقال ابرمتن روش‌هایی را برای درخواست تعریف کرده‌است (به انگلیسی: Request Method)که هر کدام از آن‌ها باعث انجام عمل خاص در سمت سرور می‌شوند. نسخهٔ ۱٫۰ روش‌های درخواست GET, POST و HEAD را دارا بود.^{[بخش ۸]} در نسخهٔ ۱٫۱ پنج روش جدید افزوده شد^{[بخش ۹]}: OPTIONS, PUT, DELETE, TRACE و CONNECT. از آنجایی که عملکرد این روش‌ها به‌طور کامل تعریف و شرح داده شده‌است، لذا تمامی مرورگرها و سرورها به راحتی می‌توانند این روش‌ها را پیاده‌سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. در تعداد روش‌ها هیچ محدودیتی وجود ندارد. این نکته باعث می‌شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‌ها فعلی آن آسیبی نرساند و آن‌ها را تغییر ندهد. برای مثال در حال حاضر پروتکل WebDAV هفت روش جدید درخواست را تعریف کرده‌است.

GET

درخواست نمایش منبعِ درخواست‌داده‌شده را می‌دهد. (این منبع معمولاً یک فایل یا پرونده می‌باشد) این روش فقط اطلاعات را از سرور دریافت می‌کند و نباید هیچ تأثیری بر روی منابع سرور بگذارد.

HEAD

این روش دقیقاً مانند روش GET عمل می‌کند با این تفاوت که بدنه پاسخ را نمی‌خواهد. از این روش برای به‌دست‌آوردن فراداده‌های موجود در سرآیند (به انگلیسی: Header) استفاده می‌شود. یکی از استفاده‌های رایج این نوع درخواست، بررسی تغییر یافتن یک منبع است.

POST

در این روش به همراه بستهٔ درخواست اطلاعاتی نیز فرستاده می‌شود. سرور با توجه به نشانی وب (URL) درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‌گرداند. این اطلاعات ارسالی می‌تواند نامِ‌کاربری و کلمهٔ‌عبور، یک نظر بر روی یک مطلب یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده‌است، باشد.^{[بخش ۹٫۵]}

PUT

در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‌شود که این منبع را در آدرس موجود در بسته بارگذاری کند. اگر در محلِ درخواست شده قبلاً منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد.

DELETE

از سرور درخواست می‌کند که آدرس فرستاده شده را حذف نماید.

TRACE

در این روش سرور اطلاعات ارسال شده را عیناً به کلاینت بازمی‌گرداند. (برای بررسی تغییراتی که واسط‌های شبکه بر روی بسته می‌گذارند، از این روش استفاده می‌شود)

OPTIONS

از سرور تقاضا می‌کند تا روش‌های درخواستِ (به انگلیسی: Request Method) موجود برای نشانی فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‌های درخواست قابل اجرا بر روی سرور می‌توان از نشانی '*' استفاده کرد.

CONNECT

بستهٔ پروتکل ابرمتن را به یک تونل TCP/IP تبدیل می‌کند. این عمل معمولاً برای برقراری ارتباط امن (HTTPS) بر روی یک پراکسی سرور ناامن استفاده می‌شود.

PATCH

این روش که در سال ۲۰۱۰ به پروتکل افزوده شد، برای ایجاد تغییرات جزیی بر روی منابع استفاده می‌شود.

سرورهای وب موظف هستند حداقل روش‌های GET و HEAD را پیاده‌سازی نمایند.^{[بخش ۵٫۱٫۱]}

وضعیت جلسه

پروتکل انتقال ابرمتن یک پروتکل Stateless می‌باشد. بدین معنی که سرور در یک جلسه هیچ ردی از کاربر ذخیره نمی‌کند. به‌طور مثال، سرور وب هیچگاه نمی‌تواند به یاد بیاورد که شما در این وبسایت لاگین کرده‌اید یا نه! اما به دلیل نیاز شدید نرم‌افزارهای تحت وب به ثبت وضعیت، با استفاده از تکنیک‌ها زیر این عمل انجام می‌گیرد:

• کوکی
• استفاده از متغیرهای پنهان در فرم‌های وب
• استفاده از متغیرهای موجود در رشتهٔ درخواست. مانند: index.php?session_id=some_unique_id

کدهای وضعیت

از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان خط وضعیت شناخته شده‌است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان کد وضعیت شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان علت وضعیت شناخته می‌شود، می‌باشد. نحوهٔ برخورد عامل کاربر با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد؛ زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند.^{[بخش ۶٫۱]}

کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند:

• کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‌شوند. این گروه، این پیام کلی را مشخص می‌کنند: «درخواست شما دریافت شد، ادامه دهید».
• کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‌شوند؛ یعنی «درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده‌است».
• کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‌شوند؛ یعنی «کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است».
• کدهای 4xx یا خطای کلاینت: این کدها با عدد ۴ آغاز می‌شوند. این گروه از کدها مشخص می‌کنند که «کلاینت در درخواست خود اشتباه کرده یا باعث بروز خطا شده‌است».
• کدهای 5xx یا خطای سرور: این کدها با عدد ۵ آغاز می‌شوند. با این مفهوم که «سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده‌است».

علت وضعیتهایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید توسعه دهنده، تغییر پیدا کنند. این عبارت می‌تواند توسط عامل کاربر به عنوان توضیحات اضافی به کاربر نمایش داده شود.

مثال

در زیر مثالی از یک جلسه بین یک کلاینت HTTP و یک سرور HTTP که بر روی www.wikipedia.com قرار دارد، ارائه شده‌است.

درخواست کلاینت

GET /index.html HTTP/1.1
Host: www.wikipedia.com

35.545325,51.238591

در درخواست کلاینت، خط اول روش، نشانی و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‌کند. از خط دوم هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‌سرهم مشخص می‌شود. (r\n\)

پاسخ سرور

HTTP/1.1 200 OK
Date: Mon, ۲۳ مه ۲۰۰۵ ۲2:38:34 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, ۰۸ ژانویه ۲۰۰۳ ۲3:11:55 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 131
Connection: close

<html>
<head>
 <title>An Example Page</title>
</head>
<body>
 Hello World, this is a very simple HTML document.
</body>
</html>

در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‌باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند (به انگلیسی: Header Field) پاسخ است. این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‌سرِهم مشخص می‌شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‌شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.

جستارهای وابسته

• اف‌تی‌پی
• گوفر
• مجموعه پروتکل اینترنت
• خطای ۴۰۴
• فهرست سرآیندهای پروتکل انتقال ابرمتن

پیوند به بیرون

• وبگاه رسمی
• IETF HTTP Working Group در گیت‌هاب

• «تاریخ تغییرات HTTP‏». W3.org. دریافت‌شده در ۲۰۱۰-۰۸-۰۱. تاریخچه مفصل فنی از HTTP.
• «مسائل طراحی برای HTTP‏». W3.org. دریافت‌شده در ۲۰۱۰-۰۸-۰۱. مسائل طراحی توسط برنرز-لی، هنگامی که او در حال طراحی این پروتکل بود.