HTTP چیست ؟

HTTP که مخفف عبارت  Hypertext Transfer Protocol (پروتکل ارسال ابر متن) می‌باشد، پروتكلی است كه برای ارتباط كاربران با سرورها طراحی شده است. طرز کار آن به این شکل است که معمولاً کلاینت درخواست خود را به سرور می فرستد و سرور آن را دریافت می کند، عملیاتی را انجام می دهد و پاسخی را به مشتری ارسال می کند. پاسخ معمولاً شامل اطلاعات وضعیت مربوط به درخواست است و می تواند حاوی سایر اطلاعات اضافی نیز باشد.

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

پروتکل‌های اینترنتی به عنوان مهم‌‌ترین و پرکاربردترین استاندارد برای تبادل اطلاعات در شبکه‌‌های اینترنتی شناخته می‌شوند. پروتکل HTTP یا Hyper Text Transfer Protocol یکی از استانداردهای پرکاربرد تعریف شده برای شبکه‌های اینترنتی است که مدتی بعد از ساخت اولین سایت‌ها ایجاد شد. این استاندارد به تدریج توسعه پیدا کرد و کنسرسیوم جهانی وب (W3C) وظیفه توسعه و نظارت این پروتکل را بر عهده گرفت.

پروتکل Http چگونه کار می‌کند؟

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

سپس بار دیگر از طرف کلاینت پیامی مبنی بر درخواست داده‌های اطلاعاتی به سرور فرستاده می‌شود. در این مرحله سرور پیام را دریافت کرده و داده‌های درخواست شده را در بسته‌های اطلاعاتی کوچک‌تری تقسیم می‌کند. در نهایت این بسته‌ها توسط پروتکل Handshaking پشت سر هم و به ترتیب برای شخص ارسال می‌شوند. لازم به ذکر است که در این فرآیند از پروتکل های TCP/IP به منظور افزایش امنیت و تضمین ارسال داده‌ها استفاده می‌شود. ارتباط بین کلاینت و سرور در این پروتکل معمولا از طریق پورت ۸۰ انجام می‌شود. همچنین به مجموعه اطلاعات تبادل شده بین دو کلاینت و سرور در این فذآیند، نشست یا session گفته می‌شود.

متدهای HTTP

به طور کلی متدهای http به ۹ نوع تقسیم می شود:

۱-Get

۲-Put

۳-Patch

۴-Delete

۵-Post

۶-Head

۷-Options

۸-Connect

۹-Trace

۱- متد GET

این متد از نوع Idempotent است. و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.

این متد عمدتا برای خواندن اطلاعات از یک سورس مشخص استفاده می شود و فرمت response به صورت json/xml می باشد.

درخواست های از نوع متد get بدنه یا body ندارند چرا که عمدتا برای درخواست اطلاعات استفاده می شود.

گاهی برای فرمت کردن داده ای که از قبل json یا xml نیست هم از این متد استفاده می شود.

این متد پارامتر های ورودی را با فرمت زیر معمولا ارسال می کند؛ کد زیر query Params پیش فرض سرچ در cms وردپرس می باشد.

webshift.ir/?s=Search-Term

رشته هایی که space در میان واژگان دارند از طریق ” کاراکتر – ” از هم جدا می شوند.

پارامتر ها با ? شروع میشوند و هر property میتواند value داشت باشد یا نداشته باشد.(بسته به برنامه نویسی سمت back-end)

مقادیر با & از هم جدا می شوند. به عنوان مثال:

webshift.ir/?name=Mohammad &user-age=&user-id=1

در کد بالا name  و user-id هرکدام دارای مقداری هستند ولی user-age مقداری ندارد.

مزایا و معایب GET

• برای ارسال اطلاعات مهم نظیر پسورد ها یا اطلاعات کارت های بانکی نمی توان(نباید) از این متد استفاده کرد چون تمام مقادیر ارسالی در هر درخواست در address bar مرورگر قابل مشاهده هستند.
• داده ها می توانند bookmark بشوند (امکان به اشتراک گذاری لینک حاوی این query params وجود دارد)
• متد get دارای محدودیت طول می باشد یعنی مقادیر بسیاری را نمی توان در هر request ارسال کرد (max length = 2048 chars in url).
• عموما درخواست های از نوع Get قابل کش شدن هستند و توی لاگ سرور(عمدتا یک سری اسکریپت وجود دارد که هزاران رکورد از تمام اتفاقاتی که می افتد (سمت کاربر یا سمت سرور) لاگ می گیرند) هم ذخیره می شوند.
• در درخواست های این نوع تنها کاراکتر های ASCII قابل ارسال هستند.

۲- متد PUT

این متد از نوع Idempotent است. و اجرای چند باره ی این درخواست نتیجه یکسانی خواهد داشت.

ماهیت این متد در ظاهر برای آپدیت یک رکورد از اطلاعات استفاده می شود ولی در عمل به این صورت است که اول رکورد مورد نظر را پاک می کند و (در همان مکان) یک رکورد جدید با استفاده از پارامتر های ارسالی جدید ایجاد می کند که عملا دیتای ما Replace می شود.

حالا اینجا سوال این هست که اگر فیلد هایی که در سرور موجود است جایگزینی در ارسال درخواست put ما نداشته باشند چه اتفاقی برای آنها می افتد؟؟!

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

۳- متد PATCH

این متد هم از نوع Idempotent است و و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.

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

در اصل فقط مقادیری که باید نغییر کنند تغییر می کنند.

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

ولی در متد Patch فقط پسورد عوض می شود و باقی فیلد ها مقادیرشان دست نخورده باقی می ماند.

۴- متد DELETE

این متد برخلاف متد Post از نوع Idempotent است و  اجرای چند باره ی این درخواست نتیجه یکسانی خواهد داشت.

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

ممکن است این requestها body داشته باشند.

Responseهای موفقیت آمیز هم ممکن است body داشته باشد.

این نوع درخواست ها در مرورگر cache نمی شوند.

عموما وقتی درخواستی موفقیت آمیز ارسال می شود Response ها با http message های متفاوتی ممکن است دریافت شوند.

برای مثال درخواست زیر فایلی به نام badfile.html رو از سرور حذف می کند.

DELETE /badFile.htm HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Host: www.webshift.ir

Accept-Language: en-us

Connection: Keep-Alive

و در پاسخ چنین چیزی دریافت می شود:

HTTP/1.1 200 OK

Date: Mon, 27 Jul 2019 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Content-type: text/html

Content-length: 30

Connection: Closed

که با توجه به message code 200 که به منزله ok است می گوید که این کار انجام شده است.

۵- متد  POST

این متد برای ساخت یا ایجاد رکوردی جدید در منبع (میتواند DB باشد) استفاده می شود. پارامتر های ارسالی این نوع متدها از طریق نوار url قابل خواندن نیست.

این متد از نوع غیر Idempotent است و اجرای چندباره این نوع درخواست باعث بوجود آمدن رکورد های متعددی از پارامتر های تکراری خواهد بود.

امنیت داده ی ارسالی در درخواست نسبتا بالاست (به قول بچه های تست نفوذ و امنیت no system is safe)  و بازه انواع درخواست های ارسالی شامل:

• رشته ها (داده های متنی)
• داده های باینری (آپلود فایل)

تمامی دیتاهای ارسالی در بدنه درخواست قرار می گیرد.

مزایا و معایب متد Post

• امنیت نسبتا بالاتری نسبت به متد Get دارد و اطلاعات ارسالی در Address bar مرورگر قابل مشاهده نیستند.
• سرعت درخواست های post (به مقدار خیلی خیلی کمی) کمتر از درخواست های متد Get هستند.
• محدودیت کمتری (هم به لحاظ نوع مقادیر ارسالی و هم به لحاظ طول url) نسبت به Get دارد.(در برخی منابع گفته شده است که طول محدودی برای url ندارد.)
• هرگز در history مرورگر ذخیره نمی شود.
• به هیچ وجه قابل cache شدن هم نیست.

۶- متد HEAD

این متد هم همانند متد get عمل می کند با این تفاوت که فقط head درخواست return می شود که این head شامل یک سری اطلاعات از پارامتر های ارسالی و … است.

Body درخواست return نمی شود؛ در عمل بیشتر برای چک کردن مقدار برگشتی هر Get Request  استفاده می شود.

۷- متد OPTIONS

این متد عمدتا زمانی استفاده می شود که می خواهیم بدانیم چه متد هایی در وب سرور مد نظر ما پشتیبانی می شود که می توانیم url خاصی را به آنها بدهیم یا اینکه از کاراکتر  Astrisk (*) جلوی OPTIONS استفاده کنیم تا ببینیم در کل سرور چه متد هایی ساپورت می شود.

برای مثال اینجا داریم که :

OPTIONS * HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

و درصورت موفقیت آمیز بودن درخواست نتیجه به شکل زیر خواهد بود :

HTTP/1.1 200 OK

Date: Mon, 27 Jul 2019 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Allow: GET,HEAD,POST,OPTIONS,TRACE

Content-Type: httpd/unix-directory

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

۸- متد TRACE

این متد معمولا برای دیباگ کردن و در پروسه ی Development استفاده می شود.

به این شکل که وقتی درخواستی از نوع TRACE برای سرور از سمت کلاینت ارسال می شود سرور برای کلاینت درخواستی که کلاینت فرستاده بود را مجدد می فرستد تا کلاینت بتواند Content درخواستی که ارسال کرده بوده را مشاهده کند.

مثال:

TRACE / HTTP/1.1

Host: www. webshift.ir

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

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

HTTP/1.1 200 OK

Date: Mon, 27 Jul 2019 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Connection: close

Content-Type: message/http

Content-Length: 39 TRACE / HTTP/1.1

Host: www.webshift.ir

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

۹- متد CONNECT

با استفاده از این متد می شود یک اتصال یا connection بین کلاینت و وب سرور که در مثال ما Apache است را برقرار می کنیم:

برای مثال در درخواست زیر قرار است که به سرور فرضا camelcase درخواست کانکشن بدهیم:

CONNECT www.webshift.ir HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

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

 HTTP/1.1 200 Connection established

Date: Mon, 27 Jul 2019 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

HTTP چه چیزهایی را می‌تواند کنترل کند؟

ماهیت بسط‌پذیر پروتکل HTTP در طی زمان به ما این امکان را داده است که کنترل و کارکردهای بیشتری روی وب داشته باشیم. متدهای کش یا احراز هویت، کارکردهایی هستند که در ابتدا از سوی HTTP مدیریت می‌شدند. به طور عکس توانایی رهایی از قید origin تنها در دهه ۲۰۱۰ میلادی به این پروتکل اضافه شده است. در ادامه فهرستی از قابلیت‌های متداولی را مشاهده می‌کنید که از سوی HTTP کنترل می‌شوند.

کش کردن

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

رهایی از قید Origin

مرورگرهای وب برای جلوگیری از سرقت اطلاعات و دیگر مداخلات در حریم خصوصی کاربران، یک جداسازی الزامی بین وب‌سایت‌ها ایجاد می‌کنند، به این ترتیب تنها صفحه‌هایی با منشأ (Origin) یکسان می‌توانند به همه اطلاعات صفحه وب دسترسی داشته باشند. با این که چنین قیدی یک مزاحمت برای سرور محسوب می‌شود، اما هدرهای HTTP می‌توانند این جداسازی صریح را در سمت سرور آزاد سازند و به سند امکان دهند که یک لحاف چهل تکه از اطلاعات باشد که از دامنه‌های مختلف تأمین می‌شوند. حتی ممکن است برخی دلایل امنیتی برای انجام این کار وجود داشته باشد.

احراز هویت

برخی صفحه‌های وب را می‌توان محافظت کرد، به طوری که تنها کاربران خاصی بتوانند به آن‌ها دسترسی داشته باشند. فرایند ابتدایی احراز هویت می‌تواند از سوی HTTP ارائه شود، که این کار یا از طریق WWW-Authenticate و هدرهای مشابه یا با تعیین یک نشست خاص با استفاده از کوکی‌های HTTP انجام می‌یابد.

پراکسی و تونلینگ

سرورها یا کلاینت‌ها غالباً روی اینترانت قرار دارند و نشانی IP واقعی‌شان را از دیگر رایانه‌ها پنهان می‌کنند. سپس درخواست‌های HTTP از طریق واسطه‌ها عبور می‌کنند تا از این موانع شبکه رد شوند. البته همه پراکسی‌ها، پراکسی‌های HTTP نیستند. برای نمونه پروتکل SOCKS در سطح پایین‌تری عمل می‌کند و پروتکل‌های دیگر مانند FTP نیز می‌توانند از سوی این واسطه‌ها مدیریت شوند.

نشست‌ها

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