(به : )‏ ( )، یک پروتکل در مدل برای سامانه‌های اطلاعاتی توزیع‌شده، مشارکت‌گرا و است. ‏ HTTP شالودهٔ ارتباط اطلاعاتی برای است که در آن مستندات شامل به سایر منابعی اند که کاربر به راحتی می‌تواند به عنوان مثال با یک کلیک یا با تپ بر روی صفحه نمایش در یک مرورگر وب به آن‌ها دسترسی داشته باشد.
 توسعه HTTP توسط در ۱۹۸۹ میلادی در کلید خورد و در یک سند ساده رفتار کلاینت و سرور را با استفاده از اولین نسخه از پروتکل HTTP که نام نسخه ۰٫۹ بر آن نهاده شد توصیف نمود. 
 آخرین نسخه از این پروتکل است که در ۲۰۲۲ میلادی منتشر شده و تا کنون در حدود %۲۵ از وبسایت‌های پیشگام در استانداردسازی به کار رفته‌است. HTTP/3 برای صفحات وب جهان واقعی تأخیر پایین‌تری داشته و اگر بر روی سرور فعال گردد سریع تر از HTTP/2 و حتی سریع‌تر از HTTP/1.1 خواهد بود و در برخی از موارد سرعت آن سه برابر HTTP/1.1 است (که اغلب تنها نسخه فعال است). یکی از دلایل آن این است که دیگر همچون استانداردهای قدیمی‌تر در این استاندارد از TCP (از TCP/IP) استفاده نشده.
 اولین نسخه از پروتکل HTTP خیلی زود به نسخه‌های پیشرفته‌تری تکامل یافت که نقش اولین پیش‌نویس برای نسخهٔ ۱٫۰ که در آیندهٔ دور ایجاد شد را داشت. 
 توسعه اولین (RFCهای) HTTP چند سال بعد شروع شد که تلاشی هماهنگ از سوی (IETF) و (W3C) بود که بعدها کارگروه به IETF منتقل شد.
 HTTP/1 در ۱۹۹۶ میلادی به عنوان نسخه ۱٫۰ نهایی‌سازی و کاملاً مستندسازی شد. این پروتکل در ۱۹۹۷ میلادی به نسخه ۱٫۱ تکامل یافت و سپس مشخصات آن در ۱۹۹۹ و ۲۰۱۴ بروزرسانی شدند. 
 گونهٔ امن آن به نام توسط بیش از %۷۹ وبسایت‌ها مورد استفاده واقع شده‌اند. 
 تجلی کارآمدتری از معانی «روی سیم بودن» HTTP است که در ۲۰۱۵ میلادی منتشر شد و توسط بیش از %۴۶ درصد وبسایت‌ها استفاده شده و اکنون تقریباً توسط تمامی مرورگرها (%۹۶ کاربران) و اکثریت سرورهای وب روی (TLS) با استفاده از پروتکل توسعه دهندهٔ «مذاکره پروتکل لایه کاربرد» ‏ (ALPN)‏ حمایت شده که در آن به TLS 1.2 یا نسخه جدیدتر آن نیاز است. 
 خلف و جانشین HTTP/2 است که در ۲۰۲۲ میلادی منتشر شد و توسط %۲۵ وبسایت‌ها استفاده شده و اکنون توسط بسیاری از مرورگرها (%۷۳ کاربران) حمایت می‌شود. ‏ HTTP/3 از QUIC به جای به عنوان پروتکل انتقال زیربنایی خود استفاده می‌کند. این پروتکل همچون HTTP/2، نسخه‌های اصلی قبلی خود را منسوخ نمی‌کند. پشتیبانی از HTTP/3 ابتدا به و و سپس افزوده شد.
 اصطلاح توسط در ۱۹۶۵ میلادی در پروژه زاندو خلق شد که آن هم به نوبه خود از رؤیاپردازی‌های بازیابی و مدیریت اطلاعات میکروفیلم-مبنای سامانه «ممکس» دهه ۱۹۳۰ الهام گرفته شده بود که آن را در مقاله ۱۹۴۵ خود با عنوان « » توصیف شده بود. اختراع اصل HTTP همراه با HTML و فناوری‌های مرتبط با آن برای و یک کلاینت به نام را به و تیمش در می‌دهند. برنرز لی HTTP را به منظور کمک برای شکل‌گیری ایدهٔ دیگرش یعنی پروژه «WorldWideWeb» می‌خواست، پروژه‌ای که اولین بار در ۱۹۸۹ میلادی پیشنهاد شد و اکنون به آن می‌گویند.
 اولین وب سرور در ۱۹۹۰ میلادی زنده شد. پروتکلی که مورد استفاده قرار گرفت فقط یک متد داشت که نام آن GET بود و کارش درخواست یک صفحه از یک سرور بود. پاسخ این درخواست از سرور همیشه یک صفحه HTML بود. 
 پروتکل انتقال ابرمتن یک پروتکل درخواست و پاسخ در مدل می‌باشد. برای مثال یک می‌تواند یک و نرم‌افزار موجود بر روی سرویس‌دهندهٔ وبسایت، یک باشد. شروع این پروتکل از طرف کلاینت است که با ارسال یک درخواست HTTP به سمت سرور گفتگو را آغاز می‌کند. سرور بر اساس درخواست ارسالی یا منبعی مانند یک فایل را در اختیار کلاینت می‌گذارد یا عملیات خاصی را انجام می‌دهد. نتیجهٔ این عملِ سرور در بستهٔ پاسخ HTTP برای کلاینت ارسال می‌شود. بستهٔ پاسخ شامل اطلاعات وضعیت و احتمالاً محتویات منبع درخواست شده می‌باشد.
 مرورگر وب یک نمونه از (به : ) است. از دیگر عوامل کاربر می‌توان به ، نرم‌افزارهای و نرم‌افزارهای دیگری که به وب متصل شده و از اطلاعات آن استفاده یا صفحه‌ای را نمایش می‌دهند، اشاره کرد.
 پروتکل انتقال ابرمتن یک پروتکل است که در طراحی شده و مورد استفاده قرار می‌گیرد. این پروتکل با فرض اینکه زیرین آن قابل اعتماد است طراحی شده و معمولاً از به عنوان لایهٔ زیرین استفاده می‌کند. با این حال از این پروتکل بر روی لایه‌های غیرقابل اطمینان نیز استفاده می‌شود. مثلاً در پروتکل SSDP، پروتکل انتقال ابرمتن بر روی (یک پروتکل غیر امن) مورد استفاده قرار می‌گیرد.
 منابع HTTP همگی با یک یا به‌طور مشخص‌تر با یک آدرس‌دهی و مشخص می‌شوند. تمامی این آدرس‌ها با نشانهٔ http یا https آغاز می‌گردد. از این آدرس‌ها در به صورت گسترده برای انتقال بین صفحات مختلف استفاده می‌گردد و از آن تحت عنوان یاد می‌شود.
 نسخهٔ ۱٫۱ این پروتکل برخلاف نسخهٔ ۱٫۰ قابلیت استفاده از یک اتصال (به : ) برای چندین درخواست را دارد. مثلاً می‌تواند عکس‌ها، فایل‌های اسکریپت و … موجود در یک صفحه را با همان اتصال اولیه دریافت کند؛ لذا سرعت آن به دلیل حذف شدن برقراری ارتباط مجدد TCP نسبت به نسخهٔ ۱٫۰ افزایش یافته‌است.
 در پروتکل انتقال ابرمتن به دنباله‌ای از درخواست‌ها و پاسخ‌ها جلسه (به : ) گفته می‌شود. کلاینت با ایجاد یک اتصال بر روی یک درگاهِ از پیش تعیین شده بر روی سرور (معمولاً درگاه شماره ۸۰؛ )، جلسه را آغاز می‌کند. سرور وب همواره بر روی درگاه در انتظار درخواست‌های کلاینت‌ها می‌باشد. بعد از دریافت درخواست ارسال شده، سرور با ارسال یک خط وضعیت (به : ) و بدنه، پاسخ کلاینت را به او بازمی‌گرداند. بدنه بستهٔ پاسخ معمولاً حاوی منبع درخواست شده‌است؛ با این حال از آن برای ارسال خطا و اطلاعات دیگر نیز استفاده می‌شود.
 یک نمونه از در پاسخ به یک درخواست مجاز:
 
 
 پروتکل انتقال ابرمتن روش‌هایی را برای درخواست تعریف کرده‌است (به : )که هر کدام از آن‌ها باعث انجام عمل خاص در سمت سرور می‌شوند. نسخهٔ ۱٫۰ روش‌های درخواست GET, POST و HEAD را دارا بود. 
در نسخهٔ ۱٫۱ پنج روش جدید افزوده شد : OPTIONS, PUT, DELETE, TRACE و CONNECT. از آنجایی که عملکرد این روش‌ها به‌طور کامل تعریف و شرح داده شده‌است، لذا تمامی و سرورها به راحتی می‌توانند این روش‌ها را پیاده‌سازی و استفاده نمایند. اگر روشی برای سرور تعریف نشده باشد، با آن به عنوان یک روش غیرِامن برخورد خواهد کرد. در تعداد روش‌ها هیچ محدودیتی وجود ندارد. این نکته باعث می‌شود که گسترش احتمالی این پروتکل در آینده به زیرساخت‌ها فعلی آن آسیبی نرساند و آن‌ها را تغییر ندهد. برای مثال در حال حاضر هفت روش جدید درخواست را تعریف کرده‌است. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 سرورهای وب موظف هستند حداقل روش‌های GET و HEAD را پیاده‌سازی نمایند. 
 پروتکل انتقال ابرمتن یک پروتکل Stateless می‌باشد. بدین معنی که سرور در یک جلسه هیچ ردی از کاربر ذخیره نمی‌کند. به‌طور مثال، اما به دلیل نیاز شدید نرم‌افزارهای تحت وب به ثبت وضعیت، با استفاده از تکنیک‌ها زیر این عمل انجام می‌گیرد:
 
 
 از نسخهٔ ۱٫۰ پروتکل انتقال ابرمتن به بعد، خطِ اولِ پاسخِ سرور تحت عنوان شناخته شده‌است. این خط حاوی یک کد عددی (مانند ۴۰۴) که به عنوان شناخته می‌شود و یک پیام متنی (مانند "یافت نشد" یا "Not Found") که با عنوان شناخته می‌شود، می‌باشد. نحوهٔ برخورد با پاسخ، بستگی کامل به کد وضعیت و فیلدهای سرآیند بستهٔ پاسخ دارد. با این حال استفاده از کدهای سفارشی (که در پروتکل اصلی موجود نیستند) نیز بلامانع می‌باشد. زیرا عوامل کاربر در برخورد با کدهای تعریف نشده، از رقم اول عدد آن‌ها برای شناسایی نوع کلی کد استفاده می‌کنند. 
 کدهای وضعیت پروتکل انتقال ابرمتن به ۵ دستهٔ کلی تقسیم می‌شوند:
 
 
 
 
 هایی که در متن تعریف پروتکل آمده‌اند پیشنهادی بوده و می‌توانند با متون دیگر، به صلاحِ دید ، تغییر پیدا کنند. این عبارت می‌تواند توسط به عنوان توضیحات اضافی به کاربر نمایش داده شود.
 در زیر مثالی از یک بین یک کلاینت HTTP و یک سرور HTTP که بر روی www.wikipedia.com قرار دارد، ارائه شده‌است.
 
 
35.545325,51.238591 در درخواست کلاینت، خط اول روش، و نسخهٔ پروتکل استفاده شده در درخواست را مشخص می‌کند. از خط دوم هر خط حاوی یک (به : ) می‌باشد و این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط در این پروتکل با ۲ حرف Carriage Return و Line Feed پشتِ‌سرهم مشخص می‌شود. (r\n\)
 
 
 
 در پاسخ سرور، خط اول، که خط وضعیت نامیده می‌شود، یکی از وضعیت‌های تعریف شده در پروتکل را مشخص می‌کند. در اینجا کد وضعیت ۲۰۰ به معنای صحیح و مجاز بودن درخواست می‌باشد. از خط دوم، هر خط حاوی یک فیلد سرآیند (به : ) پاسخ است. این فیلدها با یک خط خالی به پایان می‌رسند. پایان هر خط نیز مانند بستهٔ درخواست با ۲ حرف Carriage Return و Line Feed پشتِ‌سرِهم مشخص می‌شود. بعد از یک خط خالی (که به معنای پایان فیلدهای سرآیند است)، بدنه پاسخ آغاز می‌شود. طول بدنهٔ پاسخ معمولاً در فیلد سرآیند Content-Length توسط سرور مشخص می‌شود. در صورتی که این فیلد مشخص نشود، اطلاعات ارسالی تا بسته شدن کامل ارتباط، بدنهٔ پاسخ محسوب خواهند شد.
{"title": "پروتکل انتقال ابرمتن", "link": "https://fa.wikipedia.org//w/index.php?title=%D9%BE%D8%B1%D9%88%D8%AA%DA%A9%D9%84_%D8%A7%D9%86%D8%AA%D9%82%D8%A7%D9%84_%D8%A7%D8%A8%D8%B1%D9%85%D8%AA%D9%86&oldid=35034225", "language": "fa"}