ویدیو پروتکل http چیست؟ آشنایی با بخش های مختلف پروتکل http

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

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

محتویات این صفحه:

لایه های مدل OSI چیست؟

در اینترنت از چه پروتکل‌هایی استفاده میشود؟

پروتکل Http چیست؟

نحوه تبادل اطلاعات در پروتکل Http

متدهای پروتکل Http

هدرهای پروتکل Http

کدهای وضعیت پروتکل Http

تفاوت پروتکل‌های Http و Https

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

پروتکل ها این توابع شبکه را ممکن می کنند. به عنوان مثال، پروتکل اینترنت (IP) مسئول مسیریابی داده‌ها است که نشان می‌دهد بسته‌های داده از کجا آمده‌اند و مقصدشان چیست. IP ارتباطات شبکه به شبکه را ممکن می سازد. از این رو، IP یک پروتکل لایه شبکه (لایه 3) در نظر گرفته می شود.

به عنوان مثال دیگر، پروتکل کنترل انتقال (TCP) تضمین می کند که انتقال بسته های داده در سراسر شبکه ها به راحتی انجام می شود. بنابراین، TCP یک پروتکل لایه انتقال (لایه 4) در نظر گرفته می شود.

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

+ پروتکل TCP: یک لایه انتقال است که تحویل داده های قابل اعتماد را تضمین می کند. منظور از TCP برای استفاده با IP است و این دو پروتکل اغلب با هم به عنوان TCP/IP ارجاع داده می شوند.

+ پروتکل HTTP: پروتکل انتقال ابرمتن (HTTP) پایه و اساس شبکه جهانی وب است، اینترنتی که اکثر کاربران با آن تعامل دارند. از http برای انتقال داده ها بین دستگاه ها استفاده می شود. HTTP متعلق به لایه application (لایه 7) است، زیرا داده ها را در قالبی قرار می دهد که برنامه ها (به عنوان مثال یک مرورگر) می توانند مستقیماً بدون تفسیر بیشتر از آن استفاده کنند. لایه‌های پایین‌تر مدل OSI توسط سیستم عامل رایانه مدیریت می‌شود، نه برنامه‌های کاربردی.

+ پروتکل HTTPS: مشکل HTTP این است که رمزگذاری نشده است - هر مهاجمی که پیام HTTP را رهگیری کند می تواند آن را بخواند. HTTPS این مورد را با رمزگذاری پیام‌های HTTP تصحیح می‌کند.

+ پروتکل TLS/SSL: امنیت لایه حمل و نقل (TLS) پروتکلی است که HTTPS برای رمزگذاری استفاده می کند. TLS قبلاً لایه سوکت های امن (SSL) نامیده می شد.

+ پروتکل UDP: پروتکل Datagram کاربر (UDP) یک جایگزین سریعتر اما کمتر قابل اعتماد برای TCP در لایه انتقال است. اغلب در خدماتی مانند پخش ویدئو و بازی استفاده می شود، جایی که تحویل سریع داده ها در اولویت است.

پروتکل HTTP مخفف کلمه HyperText Transfer Protocol به معنی پروتکل انتقال ابرمتن است. پروتکل HTTP که در لایه application مدل OSI قرار میگیرد، پایه و اساس شبکه جهانی وب است و برای بارگذاری صفحات وب استفاده می شود. HTTP پروتکلی برای دریافت منابعی مانند اسناد HTML است. این پروتکل پایه و اساس هر تبادل داده در وب است و یک پروتکل client-server است، به این معنی که درخواست ها توسط کلاینت، معمولاً مرورگر وب، آغاز می شوند.

در این پروتکل معمولا کاربر یک درخواست را ارسال کرده و سرور هم پاسخ مناسب را برمیگرداند. در HTTP کاربر و سرور اطلاعات را براساس پیغام های تکی مبادله میکنند. به درخواستی که کاربر ارسال میکند Request و به پاسخی که سرور برمیگرداند Response گفته میشود.

توسعه HTTP توسط تیم برنرز لی در CERN در سال 1989 آغاز شد و در یک سند ساده که رفتار کلاینت و سرور را با استفاده از اولین نسخه پروتکل HTTP توصیف کرد. پروتکل HTTP در سال 1996 به عنوان نسخه 1.0 نهایی و به طور کامل مستند شد. در سال 1997 به عنوان نسخه 1.1 تکامل یافت و سپس مشخصات آن در سال 1999 و در سال 2014 به روز شد. نوع امن آن به نام HTTPS توسط بیش از 79٪ وب سایت ها استفاده می شود.

پروتکل HTTP/2 نسخه کارآمدتر HTTP است که در سال 2015 منتشر شد و اکنون تقریباً توسط تمام مرورگرهای وب پشتیبانی می شود. پروتکل HTTP/3 جانشین پیشنهادی HTTP/2 است و در حال استاندارد شدن است که در حال حاضر توسط 25٪ وب سایت ها استفاده شده و در بسیاری از مرورگرهای وب (73٪) پشتیبانی می شود.

اولین وب سرور در سال 1990 راه اندازی شد. پروتکل مورد استفاده تنها یک متد داشت، یعنی GET، که یک صفحه را از یک سرور درخواست می کرد. پاسخ سرور همیشه یک صفحه HTML بود.

پروتکل HTTP به یک اتصال شبکه قابل اعتماد برای تبادل داده بین مشتری و سرور نیاز دارد. در پیاده سازی HTTP، اتصالات TCP/IP با استفاده از پورت های شناخته شده استفاده می شوند (معمولاً پورت 80 اگر اتصال رمزگذاری نشده باشد یا پورت 443 اگر اتصال رمزگذاری شده است). در HTTP/2، یک اتصال TCP/IP به همراه چندین کانال پروتکل استفاده می شود. در HTTP/3 از پروتکل انتقال برنامه QUIC روی UDP استفاده می شود.

داده ها از طریق دنباله ای از درخواست ها(request) و پاسخ ها(response) که توسط یک اتصال لایه session رد و بدل می شوند، مبادله می شوند. یک سرویس گیرنده HTTP در ابتدا سعی می کند به سروری متصل شود که یک اتصال (واقعی یا مجازی) برقرار می کند. سرور HTTP(S) که به آن پورت گوش می دهد، اتصال را می پذیرد و سپس منتظر درخواست کاربر می ماند. کاربر درخواست خود را به سرور ارسال می کند. پس از دریافت درخواست، سرور یک پاسخ HTTP ارسال می کند. متن این پیام معمولاً منبعی است که کاربر درخواست کرده، اگرچه ممکن است پیام خطا یا اطلاعات دیگری نیز برگردانده شود. در هر زمان (به دلایل زیادی) کاربر یا سرور می تواند اتصال را ببندد. بستن یک اتصال معمولاً از قبل با استفاده از یک یا چند هدر HTTP در آخرین درخواست یا پاسخ ارسال شده به سرور یا کاربر منتقل می‌شود.

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

پروتکل HTTP متدهایی را تعریف می‌کند برای نشان دادن عمل مورد نظر که باید روی منبع شناسایی‌شده انجام شود. آنچه این منبع نشان می‌دهد، به اجرای سرور بستگی دارد. اغلب، منبع مربوط به یک فایل یا خروجی یک فایل اجرایی موجود در سرور است. پروتکل HTTP/1.0 متدهای GET، HEAD و POST را تعریف کرد و پروتکل HTTP/1.1 پنج روش جدید دیگر اضافه کرد: PUT، DELETE، CONNECT، OPTIONS و TRACE.

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

نام متدها به حروف بزرگ و کوچک حساس هستند. مهم ترین متدهای http به شرح زیر هستند:

+ متد GET

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

GET / HTTP/1.1
Host: mongard.ir
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate

+ متد POST

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

POST /echo/post/json HTTP/1.1
Authorization: Bearer mt0dgHmLJMVQhvjpNXDyA83vA_Pxh33Y
Accept: application/json
Content-Type: application/json
Content-Length: 85
Host: mongard.ir

{
   "Id": 12345,
   "Customer": "John Smith",
   "Quantity": 1,
   "Price": 10.00
}

+ متد HEAD

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

HEAD /echo/head/json HTTP/1.1
Accept: application/json
Host: mongard.ir

+ متد PUT

متد PUT برای به روز رسانی یا جایگزینی یک منبع موجود در سرور استفاده می شود، در حالی که متد POST برای افزودن یک منبع در سرور استفاده می شود. وقتی یک درخواست PUT ارسال می‌کنید، و Request-URI به یک منبع موجود اشاره می‌کند، سرور باید به طور کامل آن منبع را با داده‌های محصور شده در بدنه درخواست PUT جایگزین کند. اگر Request-URI به یک منبع موجود اشاره نکند، سرور مبدا ممکن است یک منبع جدید با آن URI اضافه کند. به عنوان مثال، یک نمونه از درخواست HEAD به شکل زیر است:

PUT /echo/put/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 85
Host: mongard.ir

{
  "Id": 12345,
  "Customer": "John Smith",
  "Quantity": 1,
  "Price": 10.00
}

+ متد PATCH

متد PATCH یکی از 9 متد رایج پروتکل HTTP است که برای اصلاح جزئی یک منبع موجود استفاده می شود. تفاوت اصلی با متد PUT این است که متد  PATCH اصلاح جزئی منبع را انجام می دهد، در حالی که متد PUT به طور کامل جایگزین منبع می شود. بر خلاف متدهای GET و HEAD، روش PATCH ممکن است وضعیت سرور را تغییر دهد. یک متد PATCH ممکن است به شکل زیر باشد:

PATCH /echo/patch/json HTTP/1.1
Host: mongard.ir
Accept: application/json
Content-Type: application/json
Content-Length: 85

{PATCH DATA}

+ متد DELETE

متد DELETE برای حذف یک منبع از سرور استفاده می شود. برخلاف درخواست‌های GET و HEAD، درخواست‌های DELETE ممکن است وضعیت سرور را تغییر دهند. ارسال متن پیام در یک درخواست DELETE ممکن است باعث شود برخی از سرورها درخواست را رد کنند. اما همچنان می توانید با استفاده از پارامترهای URL داده ها را به سرور ارسال کنید. این معمولاً شناسه منبعی است که می خواهید حذف کنید.  یک متد PATCH ممکن است به شکل زیر باشد:

DELETE /echo/delete/json HTTP/1.1
Authorization: Bearer mt0dgHmLJMVQhvjpNXDyA83vA_PxH23Y
Accept: application/json
Content-Type: application/json
Content-Length: 19
Host: mongard.ir

+ متد OPTIONS

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

OPTIONS /echo/options HTTP/1.1
Host: reqbin.com
Origin: mongard.ir

+ متد CONNECT

متد CONNECT برای ایجاد یک تونل HTTP از طریق یک سرور پراکسی استفاده می شود. با ارسال یک درخواست CONNECT، کلاینت از سرور پروکسی می خواهد که اتصال TCP را به مقصد مورد نظر ارسال کند. پروکسی سرور از طرف کلاینت با سرور مورد نظر ارتباط برقرار می کند و پس از برقراری ارتباط، سرور پروکسی به پروکسی جریان TCP به و از کلاینت ادامه می دهد. یک متد PATCH میتواند به شکل زیر باشد:

CONNECT reqbin.com:443 HTTP/1.1
Host: mongard.ir:443

+ متد TRACE

متد TRACE برای اشکال زدایی اتصالات وب سرور با بازگرداندن درخواست HTTP کامل به کاربر برای اهداف اشکال زدایی پروکسی استفاده می شود. به طور معمول، گیرنده درخواست سرور مبدا است. اگر مقدار هدر درخواست Max-Forwards صفر باشد، پیام TRACE نیز به سمت مشتری باز می گردد. یک درخواست TRACE به شکل زیر میباشد:

TRACE /echo HTTP/1.1
Host: mongard.ir

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

هدرها میتوانند براساس محتویاتشان دسته بندی شوند:

• Request Headers حاوی اطلاعات بیشتری در مورد منبعی است که باید واکشی شود یا در مورد کلاینت درخواست کننده منبع.
• Response Headers اطلاعات بیشتری در مورد پاسخ، مانند موقعیت مکانی آن یا سرور ارائه‌دهنده آن، دارند.
• Representation headers حاوی اطلاعاتی درباره بدنه منبع، مانند نوع MIME آن، یا کدگذاری/فشرده سازی اعمال شده است.
• Payload headers حاوی اطلاعات مستقل از نمایش در مورد داده‌ها، از جمله طول محتوا و رمزگذاری مورد استفاده برای حمل و نقل هستند.

کدهای وضعیت یا status code های پروتکل http مشخص میکنند که درخواست های ارسال شده چطور به پایان رسیدند. کدهای وضعیت در پنج دسته بندی قرار میگیرند که با اعداد 1 تا 5 مشخص میشوند. کدهای وضعیت به شکل زیر هستند:

• کدهای 1xx: این کدها خبری(informational) بوده و برای اطلاع رسانی استفاده میشوند.
• کدهای 2xx: کدهای این بخش از نوع موفق(successful) بوده و خبر از پایان رسیدن موفقیت آمیز درخواست ها میدهند.
• کدهای 3xx: این کدها برای مشخص کردن ریدایرکت ها(redirection) استفاده میشوند و مشخص میکنند که درخواست به آدرس دیگری منتقل شده است.
• کدهای 4xx: کدهایی که با عدد 4 شروع میشوند به معنی خطای کلاینت(client error) بوده و مشخص میکنند که در سمت کاربر مشکلی وجود دارد.
• کدهای 5xx: این کدها به معنای خطای سرور(server error) بوده و مشخص میکنند که سرور به مشکل خورده است.

حالا که با دسته بندی های کدها وضعیت در http آشنا شدید میتوانیم چند نمونه از پرکاربردترین آنها را ببینیم:

• کد 102 به معنی Processing بوده و مشخص میکند که درخواست کاربر دریافت شده اما هنوز پاسخی داده نشده است.
• کد 200 به معنی OK بوده و نشان میدهد که درخواست کاربر به درستی دریافت و پاسخ داده شد.
• کد 201 به معنی Created بوده و مشخص میکند که درخواست کاربر به درستی دریافت شده و یک منبع جدید در سرور ایجاد شده است.
• کد 301 به معنی Moved Permanently بوده و نشان میدهد که منبع درخواست شده به طور دائم جا به جا شده است.
• کد 400 به معنی Bad Request بوده و نشان میدهد که درخواست کاربر مشکل داشته و سرور نمیتواند درخواست را پردازش کند.
• کد 404 به معنی Not Found بوده و مشخص میکند که منبع درخواستی در سرور وجود ندارد.
• کد 403 به معنی Forbidden بوده و مشخص میکند که کاربر حق دسترسی به منبع درخواستی را ندارد.
• کد 500 به معنی Internal Server Error بوده و نشان میدهد که سرور با شرایطی مواجه شده که نمیداند چطور آن را کنترل کند.

پروتکل HTTPS نسخه امن تر HTTP است. تنها تفاوت بین http و https اینست که در https از TLS برای رمزگذاری درخواست و پاسخ استفاده میشود. به همین دلیل https بسیار امن تر از http است و حرف s به معنی secure یا امن است. وبسایت هایی که از http استفاده میکنند در ابتدای آدرس وبسایت کلمه //:http وجود دارد اما وبسایت هایی که از پروتکل https استفاده میکنند کلمه //:https وجود دارد.