نحوه راه اندازی گوشی های هوشمند و رایانه های شخصی. پرتال اطلاعاتی
  • خانه
  • مشاوره
  • پروتکل اینترنت http چیست. همه چیز درباره پروتکل های انتقال داده http و https

پروتکل اینترنت http چیست. همه چیز درباره پروتکل های انتقال داده http و https

02.07.2019 مشاوره

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

همانطور که از نام آن پیداست، HTTP در ابتدا برای انتقال به اصطلاح هایپرتکست بین برنامه ها در نظر گرفته شده بود که نوع خاصی از داده ایجاد شده مطابق با استاندارد HTML (زبان نشانه گذاری ابرمتن) است. یک سند فرامتن شامل داده‌هایی است که با استفاده از تگ‌های HTML علامت‌گذاری شده‌اند و ترکیبی از متن، تصاویر، لینک‌ها و سایر ابزارهای ارائه داده است. هایپرلینک ها، یکی از مهم ترین اجزای یک سند HTML، حوزه های تعاملی هستند که در صورت عمل کردن، داده های مرتبط با هایپرلینک تولید می کنند. این به کاربر اجازه می دهد که با اطلاعات فرامتن کار کند تا در مجموعه ای از اسناد یا حتی کل اینترنت حرکت کند و اطلاعات مورد علاقه را با استفاده از پیوندهای متنی به دست آورد.

پروتکل HTTP یک افزونه برای پروتکل TCP است و وسیله ای برای کنترل محتوای داده های ارسالی است. برخلاف TCP که ساختار بسته‌های ارسالی را در نظر نمی‌گیرد، HTTP فرااطلاعات را در داده‌ها تعبیه می‌کند و به گیرنده اجازه می‌دهد تا داده‌های دریافتی را به درستی تفسیر کند. اینترنت جهانی (که وب جهانی یا WWW نیز نامیده می شود) بر اساس HTTP عمل می کند. اولین نسخه پروتکل - HTTP/0.9 - دارای قابلیت های نسبتاً محدودی بود ، اما با توسعه فعال شبکه جهانی وب ، نسخه های جدیدی ظاهر شد: HTTP/1.0 و HTTP/1.1 که امکان کنترل انتقال نه تنها را فراهم می کند. اطلاعات فرامتن بر روی شبکه های کامپیوتری، اما همچنین فایل های باینری دلخواه: صدا، گرافیک، آرشیو و غیره.

با توجه به این واقعیت که HTTP یک روبنا بر پروتکل TCP است، انتقال داده نیز دو جنبه دارد: مشتری و سرور.

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

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

به دست آوردن اطلاعات مورد نظر کاربر توسط کاربر شامل مراحل زیر است:

کاربر آدرس منبع مورد نظر خود را در خط مرورگر وارد می کند.

مرورگر بر اساس اطلاعات دریافتی از کاربر و همچنین با در نظر گرفتن تنظیمات و پیکربندی سیستم عامل خود، یک درخواست ایجاد می کند.

مرورگر به سروری که احتمالاً در یک رایانه راه دور قرار دارد متصل می شود و درخواستی را به آن ارسال می کند.

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

سرور پاسخ را به مرورگر ارسال می کند.

مرورگر پاسخ را تجزیه می کند و داده های به دست آمده را در یک فایل ذخیره می کند یا در مورد یک سند ابرمتن، تگ های HTML را تجزیه می کند و سند را روی صفحه نمایش می دهد.

لازم به ذکر است که برنامه کلاینت نه تنها می تواند یک مرورگر باشد، بلکه تمام مراحل، به استثنای احتمالی مورد اول، در هر صورت انجام می شود.

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

سرورهای پروکسی (پروکسی-سرور) یک برنامه واسطه است که عملکردهای یک کلاینت و یک سرور را به منظور ایجاد درخواست از طرف سایر مشتریان انجام می دهد. درخواست‌ها توسط یک سرور پراکسی ارائه می‌شوند یا با تغییراتی که در آن‌ها ایجاد شده است (در این صورت سرور پراکسی مات نامیده می‌شود) یا بدون تغییر (در این صورت سرور پراکسی شفاف نامیده می‌شود) به آن ارسال می‌شود. یک سرور پروکسی به گروهی از رایانه ها اجازه می دهد تا به عنوان یک کلاینت عمل کنند که اغلب هنگام اتصال شبکه های محلی به اینترنت استفاده می شود.

دروازه - مانند یک سرور پروکسی، درخواست ها را پخش می کند، اما من آنها را تغییر نمی دهم. دروازه یک درخواست از مشتری دریافت می کند که گویی یک سرور حاوی منبع درخواستی است. بنابراین، مشتری نمی تواند تعیین کند که آیا از طریق دروازه یا مستقیماً به سرور حاوی منبع متصل می شود.

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

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

درخواست ارسال شده توسط مشتری به سرور برای شناسایی دقیق منبع درخواستی و همچنین حاوی اطلاعات لازم برای پردازش صحیح درخواست است.

ساختار درخواست شامل سه بخش است:

رشته پرس و جو

بلوک هدر

خط درخواست شامل سه فیلد است که با کاراکترهای فاصله (کد ASCII 20h، از این پس SP) از هم جدا شده‌اند، و با ترکیبی از دو کاراکتر پایان می‌یابد: بازگشت بار (کد ASCII 0Dh، از این پس CR) و تغذیه خط (کد ASCII 0Ah، از این پس LF) . عناصر رشته کوئری با فیلدهای زیر نمایش داده می شوند:

روش - روش پردازش اعمال شده بر روی منبع درخواستی را تعریف می کند. بسته به روش مشخص شده، فرمت درخواست ممکن است متفاوت باشد. روش های معتبر:

در طول توسعه برنامه، پشتیبانی از تنها روش GET معرفی شد، به این دلیل که این روش است که مرورگر در درخواست ایجاد شده به طور پیش فرض مشخص می کند.

منبع URI (شناسه منبع جهانی) (URI منبع) - محل منبع درخواستی را در قالب استاندارد شده نشان می دهد، یعنی آدرس منبع است. هنگام استفاده از روش GET، این رشته ممکن است شامل مجموعه‌ای از پارامترها باشد که به شکل رشته‌هایی با فرمت "parameter_name = parameter_value" به سرور ارسال می‌شوند که با کاراکترهای آمپر و "&" از هم جدا شده‌اند. بلوک پارامتر در انتهای آن قرار دارد. رشته URI و با کاراکتر علامت سوال «؟» از آدرس جدا می شود.

نسخه پروتکل HTTP - در طول توسعه برنامه، پشتیبانی از دریافت درخواست های مربوط به نسخه های 1.0 و 1.1 اجرا شد که به ترتیب با خطوط "HTTP/1.0" و "HTTP/1.1" مطابقت دارد.

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

هدر درخواست - شامل فیلدهایی است که به عنوان اصلاح کننده درخواست عمل می کنند و حاوی اطلاعاتی در مورد درخواست و پیکربندی ماشین مشتری هستند.

سرصفحه شی - اگر درخواست شامل تعدادی شی (مجموعه دلخواه از داده ها) باشد، فیلدهای این هدر شی را توصیف می کند و فرمت، رمزگذاری و سایر پارامترها را نشان می دهد.

هدر عمومی - شامل پارامترهای سرویس لازم برای اطمینان از صحت انتقال و فعال کردن خدمات اضافی مانند ذخیره سازی است.

بخش هدر با دو جفت کاراکتر CR و LF به پایان می رسد، که تشخیص اینکه درخواست دریافت شده است را آسان می کند زیرا خود درخواست نمی تواند چنین ترکیبی از کاراکترها را داشته باشد.

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

ساختار پاسخ شامل بخش های زیر است:

نوار وضعیت

بلوک هدر

خط وضعیت شامل سه فیلد است که با کاراکترهای SP از هم جدا شده اند و شامل دنباله ای از کاراکترهای CR، LF در انتها است. عناصر نوار وضعیت:

نسخه پروتکل HTTP - برنامه توسعه یافته همیشه از رشته "HTTP/1.1" استفاده می کند.

کد وضعیت یک کد عددی سه کاراکتری است که نتیجه درخواست را مشخص می کند. اگرچه استاندارد مجموعه نسبتاً بزرگی از کدهای وضعیت را تعریف می کند، کدهای زیر در برنامه استفاده می شود:

  • 200 - اجرای موفقیت آمیز؛
  • 400 - درخواست نامعتبر
  • 401 - دسترسی غیرمجاز؛
  • 404 - منبع یافت نشد.
  • 405 - روش غیر قابل اجرا؛
  • 505 - نسخه HTTP پشتیبانی نشده.

عبارت دلیل - عبارت کوتاهی که کد وضعیت اجرای درخواست را توضیح می دهد. استاندارد مجموعه ای استاندارد از عبارات را ارائه می دهد، اما در برنامه این مجموعه کمی اصلاح شده است.

بلوک هدر زیر خط وضعیت ممکن است از یک یا چند سرصفحه تشکیل شده باشد:

هدر درخواست

عنوان شی

عنوان کلی

سرفصل ها به تفصیل در بخش 2.2.3.3 مورد بحث قرار گرفت.

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

ما کتاب جدیدی منتشر کرده‌ایم، بازاریابی محتوای رسانه‌های اجتماعی: چگونه به درون سر دنبال‌کنندگان خود وارد شوید و آنها را عاشق برند خود کنید.

اشتراک در

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

مخفف عبارت «پروتکل انتقال ابرمتن» است که ترجمه شده به معنای «پروتکل انتقال» است. HTTP بر اساس مشخصات مورد استفاده توسط OSI به گروه لایه برنامه تعلق دارد.

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

HTTP برای چیست؟

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

بنابراین، پروتکل HTTP به شما امکان تبادل اطلاعات بین برنامه های کاربردی مختلف کاربر و سرورهای وب خاص و همچنین اتصال به منابع وب (معمولا مرورگرها) را می دهد. امروزه پروتکل شرح داده شده عملکرد کل شبکه را تضمین می کند. پروتکل انتقال داده HTTP همچنین برای انتقال اطلاعات روی دیگر پروتکل های سطح پایین تر، به عنوان مثال، WebDAV یا SOAP استفاده می شود. در این حالت پروتکل وسیله حمل و نقل است. بسیاری از برنامه ها نیز بر HTTP به عنوان ابزار اصلی برای تبادل اطلاعات متکی هستند. داده ها در قالب های مختلفی ارائه می شوند، به عنوان مثال، JSON یا XML.

HTTP پروتکلی برای تبادل اطلاعات از طریق اتصال IP/TCP است. به طور معمول، سرور برای این منظور از پورت TCP 80 استفاده می کند. اگر پورت مشخص نشده باشد، نرم افزار سرویس گیرنده به طور پیش فرض از پورت 80 نوع TCP استفاده می کند. در برخی موارد ممکن است از پورت های دیگری استفاده شود.

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

تفاوت بین HTTP و HTTPS چیست؟

تفاوت را می توان حتی از رمزگشایی اختصارات تشخیص داد. HTTPS مخفف Hypertext Transfer Protocol Security است. بنابراین، HTTP یک پروتکل مستقل است و HTTPS یک افزونه برای محافظت از آن است. HTTP اطلاعات را بدون محافظت ارسال می کند، در حالی که HTTPS حفاظت رمزنگاری را فراهم می کند. این امر به ویژه برای منابعی که دارای مجوز مسئول هستند صادق است. اینها می توانند شبکه های اجتماعی یا سایت های سیستم پرداخت باشند.

خطرات انتقال داده های محافظت نشده چیست؟ یک برنامه رهگیر می تواند آنها را در هر زمان به مهاجمان منتقل کند. HTTPS دارای یک سازمان فنی پیچیده است که به شما امکان می دهد به طور قابل اعتماد از اطلاعات محافظت کنید و امکان دسترسی غیرمجاز به آن را از بین ببرید. تفاوت در پورت ها نهفته است. HTTPS معمولا روی پورت 443 کار می کند.

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

عملکرد اضافی

HTTP از نظر عملکرد غنی است و با برنامه های افزودنی مختلف سازگار است. مشخصات 1.1 که امروزه استفاده می شود به هدر Upgrade اجازه می دهد تا هنگام تبادل داده ها از طریق پروتکل های دیگر سوئیچ و کار کند. برای این کار کاربر باید با این هدر درخواستی را به سرور ارسال کند. اگر سرور نیاز دارد با استفاده از پروتکل دیگری به یک صرافی خاص سوئیچ کند، درخواستی را به مشتری برمی‌گرداند که وضعیت "426 ارتقاء لازم است" را نشان می‌دهد.

این ویژگی مخصوصاً برای تبادل اطلاعات از طریق WebSocket (دارای مشخصات RFC 6455 است که به شما امکان می دهد در هر زمان و بدون درخواست های HTTP غیرضروری تبادل اطلاعات کنید) مرتبط است. برای انتقال به WebSocket، یک کاربر درخواستی را با هدر Upgrade و مقدار "websocket" ارسال می کند. در مرحله بعد، سرور با "101 پروتکل سوئیچینگ" پاسخ می دهد. پس از این لحظه، انتقال اطلاعات از طریق WebSocket آغاز می شود.

ما شرحی از جنبه های اصلی پروتکل HTTP را به شما ارائه می دهیم - یک پروتکل شبکه که از اوایل دهه 90 تا به امروز به مرورگر شما اجازه می دهد صفحات وب را بارگیری کند. این مقاله برای کسانی نوشته شده است که تازه شروع به کار با شبکه های کامپیوتری و توسعه برنامه های کاربردی شبکه کرده اند و هنوز خواندن مشخصات رسمی به تنهایی برایشان مشکل است.

HTTP- یک پروتکل انتقال داده که به طور گسترده مورد استفاده قرار می گیرد، که در اصل برای انتقال اسناد فرامتن در نظر گرفته شده است (یعنی اسنادی که ممکن است حاوی پیوندهایی باشد که امکان پیمایش به اسناد دیگر را فراهم می کند).

مخفف HTTP مخفف عبارت است پروتکل انتقال ابرمتن، "پروتکل انتقال ابرمتن". طبق مشخصات OSI، HTTP یک پروتکل لایه کاربردی (بالا، هفتم) است. نسخه فعلی پروتکل، HTTP 1.1، در مشخصات RFC 2616 توضیح داده شده است.

پروتکل HTTP شامل استفاده از ساختار انتقال داده مشتری-سرور است. اپلیکیشن کلاینت درخواستی را تولید کرده و به سرور ارسال می کند، پس از آن نرم افزار سرور درخواست را پردازش می کند، پاسخی تولید می کند و آن را برای مشتری ارسال می کند. سپس برنامه مشتری می تواند به ارسال درخواست های دیگر ادامه دهد که به همین ترتیب پردازش می شوند.

وظیفه ای که به طور سنتی با استفاده از پروتکل HTTP حل می شود، تبادل داده بین یک برنامه کاربردی کاربر است که به منابع وب (معمولاً یک مرورگر وب) دسترسی دارد و یک وب سرور. در حال حاضر، به لطف پروتکل HTTP است که شبکه جهانی وب کار می کند.

HTTP همچنین اغلب به عنوان یک پروتکل انتقال برای سایر پروتکل های لایه کاربردی مانند SOAP، XML-RPC و WebDAV استفاده می شود. در این مورد، گفته می شود که پروتکل HTTP به عنوان یک "حمل و نقل" استفاده می شود.

API بسیاری از محصولات نرم افزاری همچنین به استفاده از HTTP برای انتقال داده اشاره دارد - خود داده ها می توانند در هر قالبی باشند، به عنوان مثال، XML یا JSON.

به طور معمول، انتقال داده HTTP از طریق اتصالات TCP/IP انجام می شود. در این مورد، نرم افزار سرور معمولاً از پورت TCP 80 استفاده می کند (و اگر پورت به طور صریح مشخص نشده باشد، نرم افزار مشتری معمولاً از پورت 80 به طور پیش فرض برای باز کردن اتصالات HTTP استفاده می کند)، اگرچه می تواند از هر یک دیگر استفاده کند.

چگونه درخواست HTTP ارسال کنیم؟

ساده ترین راه برای درک پروتکل HTTP، تلاش برای دسترسی دستی به برخی از منابع وب است. تصور کنید که شما یک مرورگر هستید و کاربری دارید که واقعاً می خواهد مقالات آناتولی علیزار را بخواند.

فرض کنید او عبارت زیر را در نوار آدرس وارد کرده است:

http://alizar.habrahabr.ru/

بر این اساس، شما به عنوان یک مرورگر وب، اکنون باید به وب سرور به آدرس alizar.habrahabr.ru متصل شوید.

برای انجام این کار، می توانید از هر ابزار خط فرمان مناسب استفاده کنید. به عنوان مثال، telnet:

Telnet alizar.habrahabr.ru 80

اجازه دهید بلافاصله توضیح دهم که اگر ناگهان نظر خود را تغییر دادید، Ctrl + "]" را فشار دهید و سپس وارد کنید - این به شما امکان می دهد اتصال HTTP را ببندید. علاوه بر telnet، می توانید nc (یا ncat) را امتحان کنید - بسته به سلیقه شما.

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

برای ایجاد یک درخواست HTTP، باید یک خط شروع بنویسید، و همچنین حداقل یک هدر را تنظیم کنید - این هدر Host است که اجباری است و باید در هر درخواست وجود داشته باشد. واقعیت این است که تبدیل یک نام دامنه به یک آدرس IP در سمت مشتری انجام می شود، و بر این اساس، هنگامی که یک اتصال TCP را باز می کنید، سرور راه دور هیچ اطلاعاتی در مورد آدرسی که برای اتصال استفاده شده است ندارد: این می تواند به عنوان مثال آدرس alizar.habrahabr.ru، habrahabr.ru یا m.habrahabr.ru باشد - و در همه این موارد پاسخ ممکن است متفاوت باشد. با این حال، در واقع، در همه موارد اتصال شبکه با گره 212.24.43.44 باز می شود و حتی اگر در ابتدا در هنگام باز کردن اتصال، این آدرس IP مشخص نشده باشد، بلکه برخی از نام های دامنه، سرور از این موضوع مطلع نمی شود. به هر حال - و به همین دلیل است که این آدرس در هدر Host ضروری است.

خط درخواست شروع (اولیه) برای HTTP 1.1 بر اساس طرح زیر تشکیل شده است:

به عنوان مثال (چنین خط شروع ممکن است نشان دهد که صفحه اصلی سایت در حال درخواست است):

و البته، فراموش نکنید که هر فناوری زمانی که واقعاً شروع به استفاده از آن می‌کنید، بسیار ساده‌تر و واضح‌تر می‌شود.

موفق باشید و یادگیری پربار!

برچسب ها: اضافه کردن برچسب

HTTP(پروتکل انتقال ابرمتن - "پروتکل انتقال ابرمتن") یک پروتکل در سطح برنامه برای انتقال داده ها (در ابتدا به شکل اسناد فرامتن) است. اساس HTTP فناوری مشتری-سرور است، یعنی وجود مصرف کنندگان (مشتریان) را فرض می کند که اتصال را آغاز می کنند و درخواست ارسال می کنند و ارائه دهندگان (سرورها) که منتظر اتصال برای دریافت درخواست هستند، اقدامات لازم را انجام می دهند. اقدامات و پیامی با نتیجه را برگردانید.

HTTP همچنین به عنوان یک "انتقال" برای پروتکل های لایه کاربردی دیگر مانند SOAP، XML-RPC، WebDAV استفاده می شود.

هدف اصلی دستکاری در HTTP منبعی است که توسط URI (شناسه منبع یکسان) در درخواست مشتری به آن اشاره شده است. معمولاً این منابع فایل‌هایی هستند که روی سرور ذخیره می‌شوند، اما می‌توانند اشیاء منطقی یا چیزی انتزاعی باشند. یکی از ویژگی های پروتکل HTTP این است که در درخواست و پاسخ، روش نمایش همان منبع را با توجه به پارامترهای مختلف: قالب، رمزگذاری، زبان و غیره مشخص می کند. این به لطف امکان تعیین روش رمزگذاری یک پیام است. که کلاینت و سرور می توانند داده های باینری را مبادله کنند، اگرچه این پروتکل متنی است.

HTTP یک پروتکل لایه کاربردی است که مشابه آن FTP و SMTP - Simple Mail Transfer Protocol هستند. پیام ها طبق طرح معمول درخواست-پاسخ رد و بدل می شوند. HTTP از URI های جهانی برای شناسایی منابع استفاده می کند. بر خلاف بسیاری از پروتکل های دیگر، HTTP بدون حالت است. این بدان معناست که بین جفت‌های درخواست-پاسخ حالت میانی وجود ندارد. مؤلفه هایی که از HTTP استفاده می کنند می توانند به طور مستقل اطلاعات وضعیت مرتبط با درخواست ها و پاسخ های اخیر را حفظ کنند. مرورگری که درخواست ها را ارسال می کند می تواند تاخیرهای پاسخ را ردیابی کند. سرور می تواند آدرس های IP را ذخیره کرده و هدرهای آخرین مشتریان را درخواست کند. با این حال، خود پروتکل از درخواست ها و پاسخ های قبلی آگاه نیست، پشتیبانی داخلی ایالتی را ارائه نمی دهد و چنین الزاماتی بر آن تحمیل نمی شود.

    توسعه پذیری

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

    HTTP/1.1- نسخه پروتکل فعلی حالت جدید در این نسخه حالت "اتصال مداوم" بود: یک اتصال TCP می تواند پس از ارسال پاسخ به یک درخواست باز بماند، و اجازه می دهد چندین درخواست در یک اتصال ارسال شوند. اکنون مشتری باید اطلاعاتی را در مورد نام میزبانی که به آن دسترسی دارد ارسال کند، که این امر سازماندهی میزبانی مجازی را آسانتر می کند.

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

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

روش HTTP- دنباله ای از هر کاراکتر، به جز کنترل ها و جداکننده ها، که عملیات اصلی روی منبع را نشان می دهد. به طور معمول روش یک کلمه انگلیسی کوتاه است که با حروف بزرگ نوشته می شود. لطفاً توجه داشته باشید که نام روش به حروف کوچک و بزرگ حساس است.

هر سرور باید حداقل از متدهای GET و HEAD پشتیبانی کند. اگر سرور روش مشخص شده توسط کلاینت را تشخیص ندهد، باید وضعیت 501 را برگرداند (عدم اجرا). اگر سرور روش را بداند، اما برای یک منبع خاص قابل اجرا نباشد، پیامی با کد 405 (Method Not Allowed) برگردانده می شود. در هر دو مورد، سرور باید یک هدر Allow را در پیام پاسخ به همراه فهرستی از روش‌های پشتیبانی شده قرار دهد.

علاوه بر روش های GET و HEAD، اغلب از روش POST استفاده می شود.

  • درخواست HTTP، پاسخ، سرصفحه های موجودیت (پارامترها)

    تمام هدرها در پروتکل HTTP به چهار گروه اصلی تقسیم می شوند (توصیه می شود هدرها را به ترتیب زیر برای گیرنده ارسال کنید):

      سربرگ های عمومی(هدرهای اصلی) - باید در هر پیام مشتری و سرور گنجانده شود.

      سرصفحه های درخواستی(سربرگ درخواست) - فقط در درخواست های مشتری استفاده می شود.

      سرصفحه های پاسخ(سرصفحه های پاسخ) - فقط برای پاسخ های سرور.

      سرصفحه های موجودیت(Entity Headers) - هر موجودیت پیام را همراهی کنید. سرصفحه های موجودیت به یک کلاس جداگانه جدا می شوند تا در هنگام انتقال چندین محتوی (MIME) با سرصفحه درخواست یا سرصفحه پاسخ اشتباه نشوند.

    تمام هدرهای لازم برای عملکرد HTTP در RFCهای اصلی توضیح داده شده است. در صورت لزوم، می توانید سرفصل های خود را ایجاد کنید. به طور سنتی، نام چنین هدرهای اضافی با پیشوند "X-" قرار می گیرد تا از تضاد نام با هدرهای احتمالاً موجود جلوگیری شود.

    خطوط بعد از خط درخواست اصلی (GET /index.html HTTP/1.1) فرمت زیر را دارند: پارامتر: مقدار. به این ترتیب پارامترهای درخواست تنظیم می شوند. این اختیاری است، تمام خطوط بعد از خط پرس و جو اصلی ممکن است گم شده باشند. در این حالت، سرور مقدار آنها را به طور پیش فرض یا بر اساس نتایج درخواست قبلی (هنگام کار در حالت Connection: Keep-Alive) می پذیرد.

      پارامتر ارتباط(اتصال) - می تواند مقادیر Keep-Alive را بگیرد و ببندد. در HTTP 1.0، انتقال داده‌های درخواستی توسط سرور با قطع ارتباط از کلاینت دنبال می‌شود و تراکنش کامل در نظر گرفته می‌شود مگر اینکه هدر Connection: Keep Alive ارسال شود. در HTTP 1.1 سرور به طور پیش فرض اتصال را نمی بندد و کلاینت می تواند درخواست های دیگری ارسال کند. از آنجایی که بسیاری از اسناد دارای اسناد دیگری هستند - تصاویر، فریم‌ها، اپلت‌ها و غیره - این باعث صرفه‌جویی در زمان و هزینه مشتری می‌شود، که در غیر این صورت باید چندین بار به یک سرور متصل شود تا فقط یک صفحه داشته باشد. بنابراین، در HTTP 1.1، یک تراکنش می تواند تا زمانی که کلاینت یا سرور صریحاً اتصال را ببندد، حلقه بزند.

      پارامتر عامل کاربر- مقدار "کد" مرورگر است.

      پارامتر تایید کنید- لیستی از انواع محتوای پشتیبانی شده توسط مرورگر به ترتیب اولویت آنها برای این مرورگر.

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

      پارامتر آخرین تغییر(آخرین تغییر) (W3C Last-Modified) - تاریخ و زمان آخرین اصلاح سند. با استفاده از آن، کلاینت، مشابه مورد ETag، می‌تواند با درخواست «If-Modified-Since» با سرور تماس بگیرد - در این حالت، سرور باید آخرین تاریخ اصلاح نسخه ذخیره شده در مشتری را با تاریخ واقعی مقایسه کند. آخرین تاریخ اصلاح اگر مطابقت داشته باشند، به این معنی است که کپی در حافظه پنهان مشتری قدیمی نیست و نیازی به بارگیری مجدد نیست (کد پاسخ "304 اصلاح نشده است"). Last-Modified همچنین برای پردازش صحیح سایت توسط ربات ها ضروری است که از اطلاعات مربوط به تاریخ اصلاح صفحات برای مرتب سازی نتایج جستجو بر اساس تاریخ و همچنین تعیین تعداد دفعات به روز رسانی سایت شما استفاده می کنند.

    برای اسناد SSI، اگر دستورالعمل "XBitHack full" مشخص شده باشد (مثلاً در فایل htaccess.) آپاچی "Last-Modified" را صادر می کند.

      پارامتر ETag(برچسب شی) - در HTTP 1.1 (W3C ETag) معرفی شده است. ETag برای اختصاص دادن به هر صفحه یک شناسه منحصر به فرد استفاده می شود که با تغییر صفحه (سند) مقدار آن تغییر می کند. ETag یک هش ("اثر انگشت") از بایت های سند است؛ اگر حتی یک بایت در سند تغییر کند، ETag تغییر خواهد کرد. ETag هنگام ذخیره یک سند استفاده می شود. این هدر روی کلاینت ذخیره می‌شود و در صورت دسترسی مکرر به سند، به مرورگر اجازه می‌دهد تا با درخواست «If-None-Match» با سرور تماس بگیرد و سرور باید با مقدار تگ ETag تعیین کند که آیا سند (صفحه) تغییر کرده است، و در غیر این صورت، با کد '304 Not Modified' پاسخ دهید.

      پارامتر منقضی می شود(انقضا) (W3C منقضی می شود) - به مرورگر می گوید که چه مدت زمانی می تواند فرض کند که کپی صفحه در حافظه نهان تازه است و به هیچ وجه با درخواست ها با سرور تماس نگیرد. این برای فایل‌هایی که مطمئناً می‌دانید تا ساعت/روز/ماه آینده تغییر نخواهند کرد مناسب است: برای مثال، تصویر پس‌زمینه یک صفحه.

    سایر هدرهای HTTP:

      HTTP_X_FORWARDED_FOR

      HTTP_X_FORWARDED

      HTTP_FORWARDED_FOR

    • HTTP_X_COMING_FROM

      HTTP_COMING_FROM

    • HTTP_X_CLUSTER_CLIENT_IP

    • HTTP_XROXY_CONNECTION

      HTTP_PROXY_CONNECTION

      HTTP_USERAGENT_VIA - پروکسی

    نمونه ای از تجزیه و تحلیل درخواست HTTP

    یک درخواست HTTP از سه بخش تشکیل شده است: یک خط درخواست (پاسخ)، یک بخش سرصفحه، و به دنبال آن یک بدنه اختیاری. سرصفحه ها متن ساده هستند و هر سرصفحه با یک کاراکتر خط جدید (\r\n) از سرصفحه بعدی جدا می شود، در حالی که متن می تواند متن یا داده باینری باشد. بدنه با دو خط جدید از سرصفحه ها جدا می شود.

    هدر درخواست شامل خط اصلی (اول) درخواست و خطوط بعدی است که درخواست را در خط اصلی روشن می کند. خطوط بعدی نیز ممکن است از دست رفته باشند.

    مشتری یک معامله را به صورت زیر آغاز می کند:

      مشتری با شماره پورت اختصاص داده شده با سرور ارتباط برقرار می کند، شماره پورت پیش فرض رسمی 80 است. سپس مشتری یک درخواست سند ارسال می کند که روش، آدرس سند و شماره نسخه HTTP را مشخص می کند. به عنوان مثال، در خط درخواست اصلی GET /index.html HTTP/1.1

      روش GET برای درخواست سند index.html با استفاده از HTTP نسخه 1.1 استفاده می شود.

      کلاینت اطلاعات سرصفحه را ارسال می کند (اختیاری؛ هدر میزبان مورد نیاز است) تا اطلاعات پیکربندی و اطلاعات مربوط به فرمت های سندی را که می تواند بپذیرد به سرور بگوید. تمام اطلاعات هدر خط به خط فهرست شده است و هر خط حاوی نام و مقدار است. به عنوان مثال، هدر زیر ارسال شده توسط یک کلاینت حاوی نام و شماره نسخه آن و همچنین اطلاعاتی در مورد برخی از انواع سند ترجیحی مشتری است: میزبان: list.mail.ru عامل کاربر: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

      سربرگ با یک خط خالی به پایان می رسد.

      پس از ارسال یک درخواست و هدر، مشتری می تواند داده های اضافی، به عنوان مثال، برای اسکریپت های CGI ارسال کند.

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

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

      نشان می دهد که سرور از HTTP نسخه 1.1 برای پاسخگویی استفاده می کند. کد وضعیت 304 به این معنی است که مشتری سند را با استفاده از روش GET درخواست کرده است، از هدر If-Modified-Since یا If-None-Match استفاده کرده است و سند از لحظه مشخص شده تغییر نکرده است.

      بعد از خط وضعیت، سرور اطلاعات سرصفحه حاوی اطلاعات مربوط به خود سرور و سند درخواستی را برای مشتری ارسال می کند. در زیر یک عنوان مثال وجود دارد: تاریخ: پنجشنبه، 15 دسامبر 2011، 09:34:15 به وقت گرینویچ سرور: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 انقضا: پنجشنبه، 19 نوامبر 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-alidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Keep - Alive: timeout = 5، حداکثر = 100 اتصال: Keep-Alive Content-نوع: text/html. charset=utf-8

      سربرگ با یک خط خالی به پایان می رسد.

      اگر درخواست مشتری موفقیت آمیز باشد، داده های درخواستی ارسال می شود. این می تواند یک کپی از یک فایل یا نتیجه یک برنامه CGI باشد. اگر درخواست مشتری برآورده نشود، داده های اضافی در قالب توضیح کاربر پسند از دلایلی که سرور قادر به انجام درخواست نیست، منتقل می شود.

    کد وضعیت HTTP

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

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

      1xx: اطلاعاتی کدهای وضعیت اطلاعاتی که به مشتری می گوید که سرور در حال پردازش یک درخواست است. واکنش مشتری به این کدها لازم نیست.

      2xx: موفقیت

      1. 200 باشه(خوب). در HTTP/1.0 معرفی شده است. درخواست منبع موفقیت آمیز اگر مشتری درخواست داده باشد، در سربرگ و/یا متن پیام یافت می شود.

      3xx: تغییر مسیر. کدهای کلاس 3xx به مشتری می گویند که برای موفقیت عملیات باید درخواست متفاوتی (معمولاً به یک URI متفاوت) ارائه شود. از این کلاس، پنج کد 301، 302، 303، 305 و 307 به طور مستقیم به ریدایرکت ها (redirect) مربوط می شوند. آدرسی که مشتری باید به آن درخواست بدهد توسط سرور در هدر Location نشان داده می شود. بسیاری از مشتریان هنگام تغییر مسیر با کدهای 301 و 302 به اشتباه روش GET را به منبع دوم اعمال می کنند، علیرغم اینکه درخواست به منبع اول با روش دیگری بوده است. برای جلوگیری از سوء تفاهم، در نسخه HTTP/1.1 کدهای 303 و 307 به جای 302 معرفی شدند. فقط در صورتی که سرور با 303 پاسخ داده است، باید روش درخواست را تغییر دهید. در موارد دیگر، درخواست بعدی را با استفاده از روش اصلی انجام دهید.

      1. 302 پیدا شد(پیدا شد). در HTTP/1.0 معرفی شده است. سند درخواستی به طور موقت در یک URI دیگر مشخص شده در سرصفحه فیلد مکان در دسترس است.

      4xx: خطای مشتری. کلاس کد 4xx برای نشان دادن خطاها در سمت مشتری در نظر گرفته شده است. هنگام استفاده از همه روش ها به جز HEAD، سرور باید توضیحی فرامتنی را در متن پیام به کاربر برگرداند.

      1. 404 پیدا نشد. در HTTP/1.0 معرفی شده است. سرور درخواست را درک کرد، اما منبع مربوطه را در URI مشخص شده پیدا نکرد.

      5xx: خطای سرور

    پیوندهای مرتبط HTTP 1.1

    HTTP/2

    HTTP/2 (در اصل HTTP/2.0) دومین نسخه اصلی پروتکل شبکه HTTP است. این پروتکل بر اساس SPDY (پروتکل سازگار با HTTP توسعه یافته توسط Google) است.

    پروتکل HTTP/2 باینری است. در مقایسه با استاندارد قبلی، روش های شکستن داده ها به قطعات و انتقال آنها بین سرور و کلاینت تغییر کرده است.

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

.) به لطف توانایی تعیین نحوه رمزگذاری یک پیام است که سرویس گیرنده و سرور می توانند داده های باینری را مبادله کنند، اگرچه این پروتکل مبتنی بر متن است.

سرورهای پروکسی

تاریخ توسعه

HTTP/0.9

علاوه بر روش معمول GET، یک تمایز نیز وجود دارد. درخواست‌های GET مشروط شامل هدرهای If-Modified-Since، If-Match، If-Range و مشابه هستند. GET های جزئی شامل محدوده در درخواست هستند. روش اجرای چنین درخواست هایی به طور جداگانه توسط استانداردها تعریف شده است.

سر

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

هدرهای پاسخ ممکن است در حافظه پنهان شوند. اگر ابرداده یک منبع با اطلاعات مربوطه در حافظه پنهان مطابقت نداشته باشد، کپی منبع به‌عنوان قدیمی علامت‌گذاری می‌شود.

پست

برای انتقال داده های کاربر به یک منبع مشخص استفاده می شود. به عنوان مثال، در وبلاگ‌ها، بازدیدکنندگان معمولاً می‌توانند نظرات پست‌ها را در یک فرم HTML وارد کنند، پس از آن به سرور پست شده و در صفحه قرار می‌گیرند. در این حالت، داده های ارسال شده (در مثال با وبلاگ ها، متن نظر) در متن درخواست گنجانده می شود. به همین ترتیب، با استفاده از روش POST، فایل ها معمولاً در سرور آپلود می شوند.

بر خلاف روش GET، روش POST بدون قدرت در نظر گرفته نمی شود، به این معنی که تکرار چندین درخواست POST یکسان ممکن است نتایج متفاوتی را به همراه داشته باشد (مثلاً پس از ارسال هر نظر، یک کپی از آن نظر ظاهر می شود).

اگر نتیجه اجرا 200 باشد (Ok)، باید پیامی مبنی بر تکمیل درخواست در بدنه پاسخ درج شود. اگر منبعی ایجاد شده باشد، سرور باید یک پاسخ 201 (ایجاد شده) را با URI منبع جدید در هدر Location برگرداند.

پیام پاسخ سرور به روش POST ذخیره نمی شود.

قرار دادن

برای بارگیری محتوای درخواست در URI مشخص شده در درخواست استفاده می شود. اگر منبعی در URI داده شده وجود نداشته باشد، سرور آن را ایجاد می کند و وضعیت 201 (ایجاد شده) را برمی گرداند. اگر منبع تغییر کرده باشد، سرور 200 (Ok) یا 204 (بدون محتوا) را برمی‌گرداند. سرور نباید هدرهای Content-* نامعتبر ارسال شده توسط مشتری همراه با پیام را نادیده بگیرد. اگر هر یک از این سرصفحه‌ها قابل شناسایی نیستند یا در شرایط فعلی معتبر نیستند، باید کد خطای 501 (عدم اجرا) برگردانده شود.

تفاوت اساسی بین روش های POST و PUT درک هدف URI منبع است. روش POST فرض می کند که URI مشخص شده محتوای ارسال شده توسط مشتری را پردازش می کند. با استفاده از PUT، مشتری فرض می‌کند که محتوای دانلود شده با منبعی که در URI داده شده مطابقت دارد.

پیام های پاسخ سرور به روش PUT ذخیره نمی شوند.

پچ

مشابه PUT است، اما فقط برای بخشی از منبع اعمال می شود.

حذف

منبع مشخص شده را حذف می کند.

پی گیری

درخواست دریافت شده را برمی گرداند تا مشتری بتواند ببیند سرورهای میانی چه اطلاعاتی را در درخواست اضافه یا تغییر می دهند.

ارتباط دادن

ارتباطی بین منبع مشخص شده و سایر منابع برقرار می کند.

لغو پیوند

ارتباط منبع مشخص شده با دیگران را حذف می کند.

اتصال

یک اتصال درخواست را به یک تونل TCP/IP شفاف تبدیل می کند، معمولاً برای تسهیل ایجاد یک اتصال SSL امن از طریق یک پروکسی رمزگذاری نشده.

کدهای وضعیت

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

201 صفحه وب ایجاد شد 403 دسترسی فقط برای کاربران ثبت نام شده مجاز است 507 فضای ذخیره کافی نیست

مشتری از کد پاسخ در مورد نتایج درخواست خود می آموزد و تعیین می کند که در مرحله بعد چه اقداماتی را انجام دهد. مجموعه کدهای وضعیت یک استاندارد است و در RFCهای مربوطه توضیح داده شده است. معرفی کدهای جدید باید تنها پس از توافق با IETF انجام شود. مشتری ممکن است همه کدهای وضعیت را نداند، اما باید مطابق با کلاس کد پاسخ دهد.

در حال حاضر پنج کلاس از کدهای وضعیت وجود دارد.

1xx اطلاعاتی (روسی) اطلاعاتی)

این کلاس حاوی کدهایی است که روند انتقال را به شما اطلاع می دهد. در HTTP/1.0، پیام هایی با چنین کدهایی باید نادیده گرفته شوند. در HTTP/1.1، کلاینت باید آماده پذیرش این دسته از پیام ها به عنوان یک پاسخ عادی باشد، اما نیازی به ارسال چیزی به سرور ندارد. خود پیام‌های سرور فقط شامل خط شروع پاسخ و در صورت لزوم، چند فیلد سرصفحه خاص پاسخ هستند. سرورهای پروکسی باید چنین پیام هایی را از سرور به مشتری ارسال کنند.

2xx موفقیت (روسی) موفقیت)

پیام های این کلاس از موارد پذیرش و پردازش موفقیت آمیز درخواست مشتری خبر می دهد. بسته به وضعیت، سرور ممکن است سرصفحه ها و متن پیام را نیز ارسال کند.

تغییر مسیر 3xx (روسی) تغییر مسیر )

کدهای کلاس 3xx به مشتری می گویند که برای تکمیل موفقیت آمیز عملیات، باید درخواست دیگری (معمولاً به یک URI دیگر) ارسال شود. از این کلاس، پنج کد، , و مستقیماً به تغییر مسیرها (redirect) مربوط می شوند. سرور آدرسی را که مشتری باید به آن درخواست کند در سربرگ Location مشخص می کند. با این حال، امکان استفاده از قطعات در URI مورد نظر وجود دارد.

خطای مشتری 4xx (روسی) خطای مشتری)

کلاس کد 4xx برای نشان دادن خطاها در سمت مشتری در نظر گرفته شده است. هنگام استفاده از همه روش ها به جز HEAD، سرور باید توضیحی فرامتنی را در متن پیام به کاربر برگرداند.

برای به خاطر سپردن مقادیر کدهای 400 تا 417، تکنیک‌های یادگاری گویا وجود دارد.

خطای سرور 5xx (روسی) خطای سرور)

کدهای 5xx برای موارد عملکرد ناموفق به دلیل خطای سرور اختصاص داده می شود. برای همه شرایط به غیر از استفاده از روش HEAD، سرور باید در متن پیام توضیحی را درج کند که کلاینت به کاربر نمایش دهد.

سرفصل ها

بدنه ی پیام

بدنه پیام HTTP (متن پیام)، در صورت وجود، برای انتقال بدنه شی مرتبط با درخواست یا پاسخ استفاده می شود. متن پیام (متن پیام) تنها زمانی که رمزگذاری انتقال اعمال می شود، با نهاد-بدنه متفاوت است، همانطور که در قسمت سرصفحه Transfer-Encoding نشان داده شده است.

پیام - بدن = نهاد - بدن |

فیلد Transfer-Encoding باید برای نشان دادن هر گونه رمزگذاری انتقال اعمال شده توسط برنامه استفاده شود تا اطمینان حاصل شود که پیام به طور ایمن و صحیح منتقل می شود. فیلد Transfer-Encoding یک ویژگی پیام است نه شیء، و بنابراین می تواند توسط هر برنامه کاربردی در زنجیره درخواست/پاسخ اضافه یا حذف شود.

قواعد حاکم بر اینکه آیا یک بدنه پیام در پیام قابل قبول است برای درخواست ها و پاسخ ها متفاوت است.

وجود یک متن پیام در یک درخواست با افزودن فیلد هدر Content-Length یا Transfer-Encoding به سرصفحه های درخواست نشان داده می شود. یک متن پیام (متن پیام) ممکن است تنها زمانی به یک درخواست اضافه شود که روش درخواست اجازه یک نهاد-بدن را بدهد.

اینکه بدنه پیام در پیام پاسخ گنجانده شود یا نه بستگی به روش درخواست و کد وضعیت پاسخ دارد. تمام پاسخ‌های درخواستی با متد HEAD نباید شامل بدنه پیام باشد، حتی اگر فیلدهای سرآیند موجودیت وجود داشته باشد تا فرد باور کند که موجودیت موجود است. هیچ پاسخی با کد وضعیت 1xx (اطلاعاتی)، 204 (بدون محتوا) و 304 (تغییر نشده) نباید حاوی متن پیام باشد. تمام پاسخ های دیگر حاوی یک متن پیام هستند، حتی اگر طول آن صفر باشد.

مثال های گفتگوی HTTP

درخواست GET منظم

دو نوع اصلی تأیید وجود دارد:

  • مدیریت سرور سرور محور).
  • مشتری مدیریت می شود عامل محور).

هر دو نوع یا هر کدام به طور جداگانه می توانند به طور همزمان استفاده شوند.

مشخصات پروتکل اصلی (RFC 2616) همچنین به اصطلاح مذاکره شفاف را برجسته می کند. مذاکره شفاف) به عنوان گزینه ترجیحی برای ترکیب هر دو نوع. مکانیسم دوم نباید با فناوری مستقل مذاکره محتوای شفاف (TCN، روسی) اشتباه گرفته شود. مذاکره محتوای شفاف ، RFC 2295 را ببینید)، که بخشی از پروتکل HTTP نیست، اما می تواند با آن استفاده شود. هر دو تفاوت قابل توجهی در اصل عملکرد و معنای کلمه "شفاف" دارند. در مشخصات HTTP، شفافیت به این معنی است که فرآیند برای مشتری و سرور نامرئی است و در فناوری TCN، شفافیت به معنای در دسترس بودن لیست کاملی از گزینه های منابع برای همه شرکت کنندگان در فرآیند تحویل داده است.

مدیریت سرور

اگر چندین نسخه از یک منبع وجود داشته باشد، سرور می تواند سرصفحه های درخواست مشتری را تجزیه و تحلیل کند تا آنچه را که معتقد است مناسب ترین نسخه است تولید کند. هدرهای اصلی تجزیه و تحلیل شده عبارتند از Accept، Accept-Charset، Accept-Encoding، Accept-Languages ​​و User-Agent. توصیه می شود که سرور یک هدر Vary را در پاسخ قرار دهد که نشان دهنده پارامترهایی است که محتوای URI درخواستی با آن تفاوت دارد.

موقعیت جغرافیایی مشتری را می توان با آدرس IP راه دور تعیین کرد. این امر به دلیل این واقعیت امکان پذیر است که آدرس های IP، مانند نام دامنه، در یک شخص یا سازمان خاص ثبت شده است. هنگام ثبت نام، منطقه ای را که در آن از فضای آدرس مورد نظر استفاده می شود، مشخص می کنید. این داده ها به صورت عمومی در دسترس هستند و در اینترنت می توانید پایگاه داده های آزادانه توزیع شده مربوطه و ماژول های نرم افزار آماده برای کار با آنها را بیابید (شما باید روی کلمات کلیدی "Geo IP" تمرکز کنید).

لازم به یادآوری است که این روش قابلیت تعیین مکان حداکثر یک شهر را دارد (از اینجا کشور مشخص می شود). در این صورت، اطلاعات فقط در زمان ثبت نام فضای آدرس مرتبط است. برای مثال، اگر یک ارائه‌دهنده مسکو طیفی از آدرس‌ها را ثبت کند که نشان‌دهنده مسکو است و شروع به ارائه دسترسی به مشتریان از نزدیک‌ترین منطقه مسکو کند، ممکن است مشترکان آن در برخی از سایت‌ها مشاهده کنند که از مسکو هستند و نه از کراسنوگورسک یا دزرژینسکی.

مذاکره سرور محور چندین معایب دارد:

  • سرور فقط فرض می کند که کدام گزینه برای کاربر نهایی ترجیح داده می شود، اما نمی تواند دقیقا بداند که در حال حاضر چه چیزی مورد نیاز است (به عنوان مثال، یک نسخه به زبان روسی یا انگلیسی).
  • تعداد زیادی هدر گروه Accept ارسال شده است، اما منابع کمی با چندین گزینه وجود دارد. به همین دلیل، تجهیزات بار بیش از حد را تجربه می کنند.
  • حافظه پنهان مشترک در توانایی خود برای ایجاد پاسخ یکسان به درخواست های یکسان از کاربران مختلف محدود است.
  • عبور از هدرهای Accept ممکن است برخی از اطلاعات را در مورد ترجیحات آن، مانند زبان های مورد استفاده، مرورگر، کدگذاری نشان دهد.

مشتری محور

در این حالت نوع محتوا فقط در سمت مشتری تعیین می شود. برای انجام این کار، سرور با کد وضعیت 300 (چند گزینه) یا 406 (غیر قابل قبول) لیستی از گزینه ها را برمی گرداند که کاربر از بین آنها گزینه مناسب را انتخاب می کند. آشتی مبتنی بر مشتری زمانی خوب است که محتوا به روش‌های رایج متفاوت باشد (مانند زبان و رمزگذاری) و از حافظه پنهان عمومی استفاده شود.

نقطه ضعف اصلی بار اضافی است، زیرا برای دریافت محتوای مورد نظر باید یک درخواست اضافی ارائه دهید.

تایید شفاف

این مذاکره برای مشتری و سرور کاملاً شفاف است. در این مورد، از یک کش مشترک استفاده می شود که حاوی لیستی از گزینه ها است، شبیه به مذاکره مبتنی بر مشتری. اگر حافظه پنهان همه این گزینه ها را درک کند، مانند مذاکرات مبتنی بر سرور، خودش انتخاب می کند. این باعث کاهش بار روی سرور مبدا و حذف درخواست اضافی از مشتری می شود.

مشخصات اصلی HTTP مکانیسم مذاکره شفاف را با جزئیات توصیف نمی کند.

مطالب متعدد

پروتکل HTTP از انتقال چندین موجودیت در یک پیام واحد پشتیبانی می کند. علاوه بر این، موجودیت ها می توانند نه تنها در قالب یک دنباله تک سطحی، بلکه در قالب یک سلسله مراتب با تودرتوی عناصر در یکدیگر منتقل شوند. انواع رسانه multipart/* برای نشان دادن محتوای چندگانه استفاده می شود. کار با چنین انواعی طبق قوانین کلی شرح داده شده در RFC 2046 انجام می شود (مگر اینکه توسط یک نوع رسانه خاص مشخص شده باشد). اگر گیرنده نمی داند که چگونه نوع را کنترل کند، آن را به همان روشی که چند قسمتی/مختلط انجام می دهد رفتار می کند.

پارامتر مرزی به معنای جداکننده بین انواع مختلف پیام های در حال ارسال است. به عنوان مثال، پارامتر DestAddress که از فرم ارسال می شود، مقدار آدرس ایمیل را ارسال می کند و عنصر AttachedFile1 که به دنبال آن است، محتوای باینری تصویر را با فرمت jpg ارسال می کند.

در سمت سرور، پیام‌هایی با محتوای چندگانه می‌توانند در پاسخ به درخواست‌های چند منبع ارسال شوند. در این حالت از نوع رسانه multipart/byteranges استفاده می شود.

در سمت مشتری، هنگام ارسال فرم HTML، روش POST بیشتر مورد استفاده قرار می گیرد. یک مثال معمولی: صفحات ارسال ایمیل با پیوست فایل. هنگام ارسال چنین نامه ای، مرورگر پیامی از نوع داده چندبخشی/فرم ایجاد می کند و به عنوان بخش های جداگانه وارد شده توسط کاربر، موضوع نامه، آدرس گیرنده، خود متن و فایل های پیوست شده در آن ادغام می شود:

POST /send-message.html HTTP/1.1 میزبان: mail.example.com ارجاع دهنده: http://mail.example.com/send-message.html عامل کاربر: BrowserForDummies/4.67b نوع محتوا: چندبخشی/فرم- داده ها؛ boundary="Asrf456BGe4h" Content-Length: (حجم کل شامل سرصفحه های فرزند) اتصال: keep-alive Keep-Alive: 300 (خط خالی) (مقدمه مفقود شده) --Asrf456BGe4h Content-Disposition: form-data; name="DestAddress" (خط خالی) [ایمیل محافظت شده]--Asrf456BGe4h Content-Disposition: form-data; name="MessageTitle" (خط خالی) من خشمگین هستم --Asrf456BGe4h Content-Disposition: form-data; name="MessageText" (خط خالی) سلام واسیلی! شیر حیوان خانگی شما که هفته گذشته با من گذاشتید، تمام مبل من را پاره کرد. لطفا زود او را انتخاب کنید! دو عکس با عواقب پیوست شده است. --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg" نوع محتوا: image/jpeg (خط خالی) (محتوای باینری عکس اول) --Asrf456BGe4h Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg" نوع محتوا: image/jpeg (خط خالی) (محتوای باینری عکس دوم) --Asrf456BGe4h-- (پاسخ نامه گم شده)

در مثال در هدرهای Content-Disposition، پارامتر name با ویژگی نام در تگ های HTML مطابقت دارد. و