موضوع مقاله: پروتکل انتقال ابرمتن | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # پروتکل انتقال ابرمتن | مقدمه: پروتکل انتقال ابرمتن (HTTP)، یک پروتکل لایه کاربرد در مدل مجموعه پروتکل اینترنت برای سامانه‌های اطلاعاتی توزیع‌شده، مشارکت‌گرا و ابررسانه است. | ## بخش 1: پروتکل انتقال ابرمتن | توسعه HTTP توسط تیم برنرز-لی در ۱۹۸۹ میلادی در سرن کلید خورد و در یک سند ساده رفتار کلاینت و سرور را با استفاده از اولین نسخه از پروتکل HTTP که نام نسخه ۰٫۹ بر آن نهاده شد توصیف نمود. HTTP/3 آخرین نسخه از این پروتکل است که در ۲۰۲۲ میلادی منتشر شده و تا کنون در حدود %۲۵ از وبسایت‌های پیشگام در استانداردسازی به کار رفته‌است. HTTP/3 برای صفحات وب جهان واقعی تأخیر پایین‌تری داشته و اگر بر روی سرور فعال گردد سریع تر از HTTP/2 و حتی سریع‌تر از HTTP/1.1 خواهد بود و در برخی از موارد سرعت آن سه برابر HTTP/1.1 است (که اغلب تنها نسخه فعال است). یکی از دلایل آن این است که دیگر همچون استانداردهای قدیمی‌تر در این استاندارد از TCP (از TCP/IP) استفاده نشده. اولین نسخه از پروتکل HTTP خیلی زود به نسخه‌های پیشرفته‌تری تکامل یافت که نقش اولین پیش‌نویس برای نسخهٔ ۱٫۰ که در آیندهٔ دور ایجاد شد را داشت. این پروتکل در ۱۹۹۷ میلادی به نسخه ۱٫۱ تکامل یافت و سپس مشخصات آن در ۱۹۹۹ و ۲۰۱۴ بروزرسانی شدند. HTTP/2 تجلی کارآمدتری از معانی «روی سیم بودن» HTTP است که در ۲۰۱۵ میلادی منتشر شد و توسط بیش از %۴۶ درصد وبسایت‌ها استفاده شده و اکنون تقریباً توسط تمامی مرورگرها (%۹۶ کاربران) و اکثریت سرورهای وب روی امنیت لایه انتقال (TLS) با استفاده از پروتکل توسعه دهندهٔ «مذاکره پروتکل لایه کاربرد» (ALPN) حمایت شده که در آن به TLS 1.2 یا نسخه جدیدتر آن نیاز است. HTTP/3 خلف و جانشین HTTP/2 است که در ۲۰۲۲ میلادی منتشر شد و توسط %۲۵ وبسایت‌ها استفاده شده و اکنون توسط بسیاری از مرورگرها (%۷۳ کاربران) حمایت می‌شود. اختراع اصل HTTP همراه با HTML و فناوری‌های مرتبط با آن برای سرور وب و یک رابط کاربری کلاینت به نام مرورگر وب را به تیم برنرز-لی و تیمش در سرن می‌دهند. پروتکلی که مورد استفاده قرار گرفت فقط یک متد داشت که نام آن GET بود و کارش درخواست یک صفحه از یک سرور بود. ساختار کلی پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل کلاینت–سرور می‌باشد. برای مثال یک مرورگر وب می‌تواند یک کلاینت و نرم‌افزار موجود بر روی سرویس‌دهندهٔ وبسایت، یک سرور باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفتگو را آغاز می‌کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‌گذارد یا عملیات خاصی را انجام می‌دهد. از دیگر عوامل کاربر می‌توان به خزندهٔ وب، نرم‌افزارهای تلفن‌های همراه و نرم‌افزارهای دیگری که به وب متصل شده و از اطلاعات آن استفاده یا صفحه‌ای را نمایش می‌دهند، اشاره کرد. پروتکل انتقال ابرمتن یک پروتکل لایهٔ کاربرد است که در مجموعه پروتکل اینترنت طراحی شده و مورد استفاده قرار می‌گیرد. | ## بخش 2: پروتکل انتقال ابرمتن | با این حال از این پروتکل بر روی لایه‌های غیرقابل اطمینان نیز استفاده می‌شود؛ مثلاً در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی پروتکل داده‌نگار کاربر (یک پروتکل غیر امن) مورد استفاده قرار می‌گیرد. از این آدرس‌ها در زبان نشانه‌گذاری ابرمتن به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‌گردد و از آن تحت عنوان پیوند یا لینک یاد می‌شود. نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال برای چندین درخواست را دارد؛ مثلاً می‌تواند عکس‌ها، فایل‌های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند؛ لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته‌است. جلسه در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه گفته می‌شود. کلاینت با ایجاد یک اتصال هدایت انتقال (TCP) بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ۸۰؛ فهرست عددهای درگاه تی‌سی‌پی و یودی‌پی)، جلسه را آغاز می‌کند. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود. یک نمونه از خط وضعیت در پاسخ به یک درخواست مجاز: HTTP/1.1 200 OK روش‌های درخواست پروتکل انتقال ابرمتن روش‌هایی را برای درخواست تعریف کرده‌است که هر کدام از آن‌ها باعث انجام عمل خاص در سمت سرور می‌شوند. از آنجایی که عملکرد این روش‌ها به‌طور کامل تعریف و شرح داده شده‌است، لذا تمامی مرورگرها و سرورها به راحتی می‌توانند این روش‌ها را پیاده‌سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. این نکته باعث می‌شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‌ها فعلی آن آسیبی نرساند و آن‌ها را تغییر ندهد. سرور با توجه به نشانی وب (URL) درخواست شده و اطلاعات ارسال شده، منبع مورد نظر را در بستهٔ پاسخ برمی‌گرداند. این اطلاعات ارسالی می‌تواند نامِ‌کاربری و کلمهٔ‌عبور، یک نظر بر روی یک مطلب یا اطلاعات هر فرم دیگری که توسط کاربر وارد شده‌است، باشد.[بخش ۹٫۵] PUT در این روش منبعی به همراه بستهٔ درخواست ارسال شده و از سرور تقاضا می‌شود که این منبع را در آدرس موجود در بسته بارگذاری کند. اگر در محلِ درخواست شده قبلاً منبع دیگری قرار داشته باشد، منبع جدید جایگزین خواهد شد. (برای بررسی تغییراتی که واسط‌های شبکه بر روی بسته می‌گذارند، از این روش استفاده می‌شود) OPTIONS از سرور تقاضا می‌کند تا روش‌های درخواستِ موجود برای نشانی فرستاده شده را اعلام نماید. برای گرفتن تمامی روش‌های درخواست قابل اجرا بر روی سرور می‌توان از نشانی '*' استفاده کرد. | ## بخش 3: پروتکل انتقال ابرمتن | این عمل معمولاً برای برقراری ارتباط امن (HTTPS) بر روی یک پراکسی سرور ناامن استفاده می‌شود. به‌طور مثال، سرور وب هیچگاه نمی‌تواند به یاد بیاورد که شما در این وبسایت لاگین کرده‌اید یا نه! اما به دلیل نیاز شدید نرم‌افزارهای تحت وب به ثبت وضعیت، با استفاده از تکنیک‌ها زیر این عمل انجام می‌گیرد: کوکی استفاده از متغیرهای پنهان در فرم‌های وب استفاده از متغیرهای موجود در رشتهٔ درخواست. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان کد وضعیت شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان علت وضعیت شناخته می‌شود، می‌باشد. نحوهٔ برخورد عامل کاربر با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد؛ زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند.[بخش ۶٫۱] کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند: کدهای 1xx یا اطلاعاتی: این کدها با عدد ۱ آغاز می‌شوند. کدهای 2xx یا موفقیت: این کدها با عدد ۲ آغاز می‌شوند؛ یعنی «درخواستِ ارسالی دریافت شده، درک شده، پذیرفته شده و با موفقیت انجام شده‌است». کدهای 3xx یا تغییر مسیر: این کدها با عدد ۳ آغاز می‌شوند؛ یعنی «کلاینت برای کامل شدن درخواست نیازمند انجام عملیات اضافی است». این گروه از کدها مشخص می‌کنند که «کلاینت در درخواست خود اشتباه کرده یا باعث بروز خطا شده‌است». با این مفهوم که «سرور در انجام عملیات مربوط به یک بستهٔ درخواستِ ظاهراً صحیح، ناموفق بوده و با خطا مواجه شده‌است». علت وضعیتهایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید توسعه دهنده، تغییر پیدا کنند. این عبارت می‌تواند توسط عامل کاربر به عنوان توضیحات اضافی به کاربر نمایش داده شود. از خط دوم هر خط حاوی یک فیلد سرآیند می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. | ## جمع‌بندی | در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.