پیام های HTTP

پیام های HTTP نحوه تبادل داده ها بین سرور و مشتری است. دو نوع پیام وجود دارد: درخواست های ارسال شده توسط مشتری برای اقدام بر روی سرور و پاسخ ها ، پاسخ سرور.

پیام های HTTP از اطلاعات متنی رمزگذاری شده در ASCII تشکیل شده و از چندین خط استفاده می شود. در HTTP/1. 1 و نسخه های قبلی پروتکل ، این پیام ها به طور آشکار از طریق اتصال ارسال می شدند. در HTTP/2 ، پیام یک بار قابل خواندن انسانی اکنون به فریم های HTTP تقسیم می شود و بهینه سازی و بهبود عملکرد را ارائه می دهد.

توسعه دهندگان وب ، یا مأمورین وب ، به ندرت این پیام های HTTP متنی را به خود اختصاص می دهند: نرم افزار ، یک مرورگر وب ، پروکسی یا سرور وب ، این عمل را انجام می دهند. آنها پیام های HTTP را از طریق فایلهای پیکربندی (برای پروکسی ها یا سرورها) ، API (برای مرورگرها) یا سایر رابط ها ارائه می دهند.

مکانیسم قاب بندی باینری HTTP/2 به گونه ای طراحی شده است که نیازی به تغییر در API یا پرونده های پیکربندی اعمال شده نداشته باشد: این به طور گسترده برای کاربر شفاف است.

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

1. خط شروع به توصیف درخواست های اجرا شده یا وضعیت آن در مورد موفقیت یا عدم موفقیت. این خط شروع همیشه یک خط واحد است.
2. مجموعه ای اختیاری از هدرهای HTTP که درخواست را مشخص می کند ، یا توصیف بدن موجود در پیام.
3. یک خط خالی که نشان دهنده تمام اطلاعات متا برای درخواست است ارسال شده است.
4. یک بدنه اختیاری حاوی داده های مرتبط با درخواست (مانند محتوای فرم HTML) یا سند مرتبط با پاسخ. حضور بدن و اندازه آن توسط هدر خط شروع و HTTP مشخص شده است.

عنوان های شروع و HTTP پیام HTTP در مجموع به عنوان رئیس درخواست ها شناخته می شوند ، در حالی که بار آن به عنوان بدن شناخته می شود.

درخواست های HTTP

خط شروع

درخواست های HTTP پیام هایی است که توسط مشتری برای شروع یک عمل روی سرور ارسال می شود. خط شروع آنها شامل سه عنصر است:

1. یک روش HTTP ، یک فعل (مانند دریافت ، قرار دادن یا ارسال) یا یک اسم (مانند سر یا گزینه ها) ، که عملکردی را که باید انجام شود توصیف می کند. به عنوان مثال ، GET نشان می دهد که یک منبع باید از بین برود یا ارسال شود به این معنی است که داده ها به سرور منتقل می شوند (ایجاد یا اصلاح یک منبع یا ایجاد یک سند موقت برای ارسال).
2. هدف درخواست ، معمولاً یک URL یا مسیر مطلق پروتکل ، پورت و دامنه معمولاً با زمینه درخواست مشخص می شود. قالب این هدف بین روشهای مختلف HTTP متفاوت است. میتونه باشه
   • یک مسیر مطلق که در نهایت با یک "؟" دنبال می شود. و رشته پرس و جواین رایج ترین شکل است که به فرم مبدا معروف است و با روش های GET، POST، HEAD و OPTIONS استفاده می شود.
     • POST / HTTP/1. 1
     • GET /background. png HTTP/1. 0
     • HEAD /test. html? query=alibaba HTTP/1. 1
     • OPTIONS /anypage. html HTTP/1. 0
   • یک URL کامل، که به عنوان فرم مطلق شناخته می شود، بیشتر در هنگام اتصال به یک پروکسی با GET استفاده می شود. دریافت https://developer. mozilla. org/en-US/docs/Web/HTTP/Messages HTTP/1. 1
   • مؤلفه اعتبار یک URL، که از نام دامنه و در صورت اختیاری پورت (با پیشوند ':' ) تشکیل شده است، فرم مرجع نامیده می شود. این فقط با CONNECT هنگام راه اندازی یک تونل HTTP استفاده می شود. CONNECT developer. mozilla. org:80 HTTP/1. 1
   • شکل ستاره، یک ستاره ساده ('*') با OPTIONS استفاده می شود، که سرور را به عنوان یک کل نشان می دهد. گزینه ها * HTTP/1. 1
3. نسخه HTTP که ساختار پیام باقیمانده را تعریف می کند و به عنوان نشانگر نسخه مورد انتظار برای استفاده برای پاسخ عمل می کند.

سرصفحه ها

سرصفحه های HTTP از یک درخواست از همان ساختار اصلی سرآیند HTTP پیروی می کنند: رشته ای که به حروف بزرگ و کوچک و بزرگ و بزرگ و کوچک و بزرگ و کوچک و بزرگ و کوچک و بزرگ و کوچک و بزرگ دنبال می شود و مقداری که ساختار آن به هدر بستگی دارد. کل هدر، از جمله مقدار، از یک خط تشکیل شده است که می تواند بسیار طولانی باشد.

هدرهای مختلفی می توانند در درخواست ها ظاهر شوند. آنها را می توان به چند گروه تقسیم کرد:

• سرصفحه های عمومی، مانند Via، در کل پیام اعمال می شوند.
• سرصفحه های درخواست، مانند User-Agent یا Accept، درخواست را با مشخص کردن بیشتر آن (مانند Accept-Language)، با دادن زمینه (مانند Referer)، یا با محدود کردن شرطی آن (مانند If-None) تغییر می دهند.
• سرصفحه های نمایشی مانند Content-Type که قالب اصلی داده های پیام و هرگونه رمزگذاری اعمال شده را توصیف می کنند (فقط در صورتی وجود دارد که پیام دارای متن باشد).

بدن

قسمت پایانی درخواست بدنه آن است. همه درخواست ها یکی ندارند: درخواست هایی که منابع واکشی می کنند، مانند GET، HEAD، DELETE یا OPTIONS، معمولاً به یکی نیاز ندارند. برخی از درخواست ها داده ها را به سرور ارسال می کنند تا آن ها را به روزرسانی کنند: اغلب در مورد درخواست های POST (شامل داده های فرم HTML) اتفاق می افتد.

اجسام را می توان به طور کلی به دو دسته تقسیم کرد:

• بدنه های تک منبعی، متشکل از یک فایل واحد، که توسط دو سربرگ تعریف شده است: Content-Type و Content-Length.
• بدنه های چند منبعی، متشکل از بدنه ای چند بخشی، که هر کدام حاوی بیت متفاوتی از اطلاعات است. این معمولاً با فرم های HTML مرتبط است.

پاسخ های HTTP

خط وضعیت

خط شروع پاسخ HTTP ، به نام خط وضعیت ، حاوی اطلاعات زیر است:

1. نسخه پروتکل ، معمولاً http/1. 1.
2. یک کد وضعیت ، نشانگر موفقیت یا عدم درخواست درخواست. کدهای وضعیت مشترک 200 ، 404 یا 302 است
3. یک متن وضعیتشرح مختصری ، صرفاً اطلاع رسانی ، متنی از کد وضعیت برای کمک به یک انسان در درک پیام HTTP.

یک خط وضعیت معمولی به نظر می رسد: HTTP/1. 1 404 یافت نشد.

سرصفحه ها

هدرهای HTTP برای پاسخ ها از همان ساختار هر عنوان دیگر پیروی می کنند: یک رشته حساس به مورد و به دنبال آن یک روده بزرگ (':') و مقداری که ساختار آن به نوع هدر بستگی دارد. کل هدر ، از جمله مقدار آن ، به عنوان یک خط واحد ارائه می شود.

بسیاری از هدرهای مختلف می توانند در پاسخ ها ظاهر شوند. اینها را می توان به چندین گروه تقسیم کرد:

• هدرهای عمومی ، مانند VIA ، برای کل پیام اعمال می شوند.
• عنوان های پاسخ ، مانند Wary و Traking دامنه ، اطلاعات بیشتری در مورد سرور ارائه می دهند که در خط وضعیت قرار نمی گیرد.
• سرصفحه های نمایشی مانند Content-Type که قالب اصلی داده های پیام و هرگونه رمزگذاری اعمال شده را توصیف می کنند (فقط در صورتی وجود دارد که پیام دارای متن باشد).

بدن

قسمت آخر پاسخ بدن است. همه پاسخ ها دارای یک مورد نیستند: پاسخ هایی با کد وضعیت که به اندازه کافی به درخواست پاسخ می دهد بدون نیاز به بارگذاری مربوطه (مانند 201 ایجاد شده یا 204 محتوا) معمولاً این کار را نمی کنند.

اجساد را می توان به طور گسترده ای به سه دسته تقسیم کرد:

• اجسام تک منبع ، متشکل از یک پرونده واحد با طول شناخته شده ، تعریف شده توسط دو هدر: نوع محتوا و طول محتوا.
• بدنهای تک منبع ، متشکل از یک پرونده واحد با طول ناشناخته ، رمزگذاری شده توسط تکه هایی با تنظیم رمزگذاری انتقال به صورت خرد شده.
• بدنهای با منابع چندگانه ، متشکل از یک بدنه چند جانبه ، هر کدام حاوی بخش دیگری از اطلاعات هستند. اینها نسبتاً نادر هستند.

فریم HTTP/2

پیام های HTTP/1. x چند اشکال برای عملکرد دارند:

• هدرها بر خلاف اجساد فشرده نشده اند.
• هدرها اغلب از یک پیام به پیام بعدی بسیار شبیه هستند ، اما هنوز هم در بین اتصالات تکرار می شوند.
• چند برابر نمی تواند انجام شود. چندین اتصالات نیاز به باز کردن در همان سرور دارند: و اتصالات TCP گرم از سرماخوردگی کارآمدتر است.

HTTP/2 یک مرحله اضافی را معرفی می کند: پیام های HTTP/1. x را به قاب هایی که در یک جریان تعبیه شده اند تقسیم می کند. داده ها و قاب های هدر از هم جدا شده اند که امکان فشرده سازی هدر را فراهم می کند. چندین جریان را می توان با هم ترکیب کرد ، فرآیندی به نام Multiplexing ، که امکان استفاده کارآمدتر از اتصالات TCP اساسی را فراهم می کند.

فریم های HTTP اکنون برای توسعه دهندگان وب شفاف هستند. این یک مرحله اضافی در HTTP/2 ، بین پیام های HTTP/1. 1 و پروتکل حمل و نقل اساسی است. در API های مورد استفاده توسعه دهندگان وب برای استفاده از فریم های HTTP هیچ تغییری لازم نیست. در صورت موجود در هر دو مرورگر و سرور ، HTTP/2 روشن شده و استفاده می شود.

نتیجه

پیام های HTTP کلید استفاده از HTTP هستند. ساختار آنها ساده است و بسیار گسترده است. مکانیسم قاب بندی HTTP/2 یک لایه واسطه جدید بین نحو HTTP/1. x و پروتکل حمل و نقل اساسی ، بدون اینکه اساساً آن را اصلاح کند ، اضافه می کند: بنا بر مکانیسم های اثبات شده.

با این صفحه مشکل محتوا پیدا کرده اید؟

• صفحه را در GitHub ویرایش کنید.
• گزارش محتوا را گزارش دهید.
• منبع را در GitHub مشاهده کنید.

این صفحه آخرین بار در تاریخ 3 مارس 2023 توسط همکاران MDN اصلاح شد.< Pan> فریم های HTTP اکنون برای توسعه دهندگان وب شفاف هستند. این یک مرحله اضافی در HTTP/2 ، بین پیام های HTTP/1. 1 و پروتکل حمل و نقل اساسی است. در API های مورد استفاده توسعه دهندگان وب برای استفاده از فریم های HTTP هیچ تغییری لازم نیست. در صورت موجود در هر دو مرورگر و سرور ، HTTP/2 روشن شده و استفاده می شود.