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

قصد داریم طی مقاله ای دو قسمتی در دریای HTTP تنی به آب بزنیم و با مبانی آن آشنا شویم. پس اگر به این موضوع علاقمند هستید ادامه مطلب را از دست ندهید.

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

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

ارتباط «اچ تی تی پی» معمولا روی پورت ۸۰ برقرار می شود اما می توان از هر روش انتقالی دیگری هم استفاده نمود و پورت مورد استفاده هم قابل تغییر است.

همانطور که گفتیم ارتباط بین هاست (سرور) و کلاینت (مثلا کامپیوتر کاربر) معمولا به صورت یک جفت درخواست/پاسخ صورت می گیرد. به این معنی که کلاینت یک «درخواست اچ تی تی پی» ارسال می کند و یک «پاسخ اچ تی تی پی» دریافت می نماید.

نسخه فعلی «اچ تی تی پی» که در حال حاضر مورد استفاده قرار می گیرد HTTP/1.1 است که نسبت به نسخه ۱٫۰ تعدادی خصوصیت ویژه به آن اضافه شده است.

 

URL ها

همانطور که گفتیم آغاز ارتباط از یک «درخواست اچ تی تی پی» شروع می شود. این در خواست از طریق Uniform Resource Locators ارسال می شود که به طور خلاصه به آن URL می گویند. چیزی که قطعا با آن آشنا هستید و به صورت روزانه از آن استفاده می کنید.

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

پروتوکل معمولا «اچ تی تی پی» است اما گاهی اوقات هم HTTPS را می بینید که نشان دهنده ارتباط رمز نگاری شده است. برای اطلاعات بیشتر در این مورد این مطلب نگهبان را بخوانید: اس اس ال چیست و چرا توجه به آن بسیار مهم است؟

پورت مورد استفاده معمولا ۸۰ است اما می بینید که در صورت نیاز می توان پورت را تغییر داد.

 

Verb ها

همانطور که خواندید URL ها مشخص می کنند که قرار است با کدام سرور تبادل اطلاعات کنیم. اما خود درخواست ما چیست؟ درخواست های کلاینت از طریق HTTP verb ها مشخص می شوند. این درخواست ها از هاست (سرور میزبان) می خواهد تا کاری را برایشان انجام دهد. برای مثال یک فایل یا یک صفحه وب را برایشان ارسال کند.

کلاینت ممکن است درخواست های متنوعی از هاست داشته باشد اما در «اچ تی تی پی» این Verb ها به تعدادی محدود شده اند که تقریبا در همه جا از همین ها استفاده می شود. و مشهورترین آنها به این شرح هستند:

– GET : منبع موجود را میگیرد. (در این مقاله هر جا از منبع صحبت کردیم منظور ما چیزهایی مانند فایل، صفحه وب و… است.) در این حالت URL حاوی تمام اطلاعات مورد نیاز برای آقای سرور است تا منبع مورد نیاز را پیدا و آن را ارسال کند.

– POST : یک منبع جدید ایجاد می کند. درخواست های POST معمولا حاوی اطلاعاتی هستند که سبب ایجاد منبعی جدید می شوند.

– PUT : منبع موجود را به روز می کند.

– DELETE : منبع موجود را پاک می کند.

 

اینها مشهورترین Verb های «اچ تی تی پی» به حساب می آیند. گاهی اوقات PUT و DELETE هم به صورت نسخه های ویژه ای از POST به حساب می آیند و ممکن است در یک درخواست POST قرار گرفته باشند.

 

در کنار آنها، Verbهای کم مصرف تر اینها به شمار می آیند:

– HEAD : شبیه به GET است. اما بدنه پیام را به همراه ندارد. از آن برای دریافت هدرهای سرور استفاده می شود. برای مثال زمانی که قرار است چک شود منبعی روی سرور تغییر یافته یا نه. (از طریق چک کردن Timestamp یعنی زمان دستکاری شدن منبع)

– Trace : برای پیدا کردن نقاطی است که میان کلاینت و سرور قرار گرفته اند (مثلا کامیپوترها، پروکسی ها و… واقع شده در مسیر) هر کدام از آنها می توانند IP یا DNS خودشان را به هدر ما تزریق کنند. و از آن بیشتر برای عیب یابی استفاده می شود.

– OPTIONS : برای گرفتن مشخصات سرور مورد استفاده قرار میگیرد. کلاینت می تواند با دریافت این اطلاعات درخواستش را به گونه ای تنظیم کند تا توسط سرور پشتیبانی شود.

 

کدهای وضعیت:

تا اینجا دانستیم که با استفاده از URL ها و Verb ها کلاینت می تواند درخواست خودش را به سرور ارسال کند. در پاسخ آقای سرور یک «کد وضعیت» (status code) را به همراه خود پاسخ ارسال می کند.

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

۱xx- پیام های اطلاعاتی: این گروه از کدها که با عدد ۱ شروع می شوند فقط حاوی اطلاعاتی برای کلاینت و سرور هستند. برای مثال سرور ممکن است این کد را برای کلاینت ارسال کند: ۱۰۰-continue message و این کد به کلاینت می گوید که درخواستش را دوباره ارسال کند.

۲xx – موفق: این کد به کلاینت اعلام می کند که درخواست با موفقیت اجرا شده است. مشهور ترین آن کد: ۲۰۰ OK است. که در پاسخ به یک درخواست GET ارسال میشود. در بدنه پیام هم سرور پاسخ را ارسال می کند.

برخی کدهای دیگر در این خانواده به این شرح هستند:

- ۲۰۲: پذیرفته شده. درخواست پذیرفته شده اما ممکن است در بدنه پاسخ حاوی منبع درخواستی نباشد.

- ۲۰۴: بدون محتوا. بدنه پیام خالی است و محتوایی در آن قرار ندارد.

- ۲۰۵: بازنگری در محتوا. به کلاینت می گوید که وضعیت نمایش داکیومنت را ریست کند.

- ۲۰۶: بخشی از محتوا. به کلاینت می گوید که پاسخ، فقط بخشی از محتوا را به همراه دارد.

۳xx – ریدایرکت: این به کلاینت می گوید که باید حرکت بعدی را انجام بدهد. معمول ترین آن رفتن به یک URL دیگر است تا منبع مورد نظر را دریافت کند. مشهورترین آنها به این شرح اند:

- ۳۰۱: منبع مورد نظر به طور دایمی جابجا شده و در یک URL جدید قرار دارد.

- ۳۰۳: به جای دیگری مراجعه کنید. منبع مورد نظر به طور موقت در یک URL جدید قرار گرفته.

- ۳۰۴: سرور می گوید که منبع مورد نظر تغییر نکرده و کلاینت می تواند از نسخه کش شده خودش استفاده کند. این پاسخ در واقع از تبادل ETag ها مشخص می شود. Enttity Tag در واقع نسخه Hash شده محتوا به حساب می آیند. برای اطلاعات بیشتر در این مورد، دو مقاله نگهبان را مطالعه کنید:

آشنایی با Checksum و کاربردهای آن
همه چیز درباره MD5 یا الگوریتم گوارش پیام

سرور این رقم را با Etag محتوایی خودش مقایسه می کند و اگر تغییری وجود نداشته باشد این کد را صادر می کند.

 

4xx: خطای کلاینت

این کدها وقتی ایجاد می شوند که سرور فکر می کند خطا از طرف کلاینت ناشی می شود. مثلا یک درخواست که به منبعی اشتباه ختم می شود. مشهورترین آنها ۴۰۴ است که می گوید منبع مورد نظر وجود ندارد. اما دیگر کدهای مهم این دسته به این شرح هستند:

- ۴۰۰: فرمت درخواست صحیح نیست.
- ۴۰۱: نیاز به تایید هویت با رمز عبور وجود دارد.
- ۴۰۳: سرور اجازه دسترسی به منبع مورد نظر را نمی دهد.
- ۴۰۵: از Verb صحیح در ارسال درخواست استفاده نشده یا سرور از آن پشتیبانی نمی کند.
- ۴۰۹: تداخل. کلاینت سعی می کند منبعی را دستکاری کند که نسبت به زمان کلاینت، جدیدتر به حساب می آید. این پیام را معمول در درخواست های PUT می بینیم. زمانی که چند نفر روی یک منبع کار می کنند.

 

5xx: خطای سرور

این گروه از کدها خطا در سرور را هنگام بررسی درخواست نشان می دهد. رایج ترین آن ۵۰۰ Internal Server Error است و دو پیام رایج دیگر اینها است:

- ۵۰۱: سرور از این درخواست پشتیبانی نمی کند.
- ۵۰۳: زمانی که سرور متحمل فشاری بیش از حد توانایی اش باشد یا به هر علت داخلی دچار مشکل شده است. معمولا در این شرایط سرور قادر به چنین پاسخی هم نمیشود و درخواست با timeout مواجه می شود.

 

فرمت درخواست و پاسخ

تا اینجا متوجه شدیم که «URLها» «Verbها» و «کدهای وضعیت» بخش های اساسی یک درخواست و پاسخ «اچ تی تی پی» را تشکیل می دهند و تصویر بالا هم به خوبی آن را نشان می دهد.

حالا بیایید نگاهی بیاندازیم به درون این پیام ها. در «اچ تی تی پی» هر یک از پیام های درخواست و پاسخ از یک ساختار کلی پیروی می کند که به این شکل است:

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

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

- هدرهای کلی (general headers)
- هدرهای مخصوص «درخواست»
- هدرهای مخصوص «پاسخ»
- هدرهای وجودی (Entity headers) که حاوی اطلاعاتی در مورد پیام هستند.

 

هدرهای کلی (General Headers)

اینها هدرهایی هستند که به طور مشترک در «درخواست» و «پاسخ» تبادل شده وجود دارند. که برخی از مهمترین آنها به این شرح هستند:

- Via: این هدر در پیام های TRACE استفاده می شود و اطلاعات نقاط موجود در مسیر را به همراه دارد.
- Pragma: این هدری است که می تواند برای ساخت هدرهای دستی مورد استفاده قرار گیرد و یکی از کاربردهای مثال آن هدر Pragma: no-cache است. در مورد این هدر، در قسمت دوم مطلب بیشتر صحبت می کنیم.
- Date: کار این هدر مشخص است و حاوی برچسب زمانی درخواست/پاسخ است.
- Upgrade: برای سوییچ کردن بین پروتوکل ها مورد استفاده قرار میگیرد.
- Transfer-Encoding: این هدر به طور معمول برای شکستن پاسخ به قطعات کوچکتر مورد استفاده قرار میگیرد. (Transfer-Encoding: chunked value) این هدر در نسخه ۱٫۱ اچ تی تی پی اضافه شده و اجازه می دهد که پاسخ های بزرگ در قالب یک استریم اطلاعاتی به کلاینت ارسال شود.

 

هدر های وجودی (Entity headers)

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

این هدرها حاوی اطلاعات مهمی در مورد ساختار پیام، encoding، اندازه و… هستند. در این میان به هدر Expires دقت کنید که نشان می دهد این پیام چه زمانی منقضی می شود و Last-Modified header نشان دهنده آخرین تغییرات اعمال شده روی بسته است.

همانطور که گفتیم در اچ تی تی پی می توان هدرهای مخصوص به خودمان را بسازیم و از آنها استفاده کنیم در این صورت آنها جزو گروه Entity headers در نظر گرفته خواهند شد.

 

فرمت درخواست:

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

SP در واقع جدا کننده هر یک از بخش ها به حساب می آید و بعد از آن یک خط جدید اضافه می شود. بنابراین یک «درخواست» معمول اچ تی تی پی به شکل ظاهری زیر خواهد بود:

توجه کنید که بعد از این خط درخواست هدرهای زیادی اضافه می شود. ضمن اینکه هدر Host در اچ تی تی پی نسخه ۱٫۱ اختیاری به حساب می آید و درخواست های از نوع GET دارای بدنه پیام نیستند. اما درخواست های POST دارای دیتا درون بدنه پیام هستند.

تصویر زیر لیست کامل هدرهای شناخته شده مربوط به «درخواست» را نشان می دهد. و همانطور که گفتیم اگر هدری به جز آنها به درخواست اضافه شود، به عنوان Entity Header شناخته می شود.

در میان آنها User-Agent اطلاعات جالبی در مورد کلاینت به همراه دارد و هدرهایی که دارای If هستند، می توانند به عنوان شرطی عمل نموده و سرور در پاسخ به آنها جوابی را ارسال می کند که با شرط مشخص شده برآورده شود. در غیر این صورت پیام ۳۰۴ Not Modified را ارسال می کند.

این شرط می تواند بر اساس زمان ایجاد یا Etag به وجود آید. مثلا کلاینت در خواست دانلود یک فایل تصویر را می دهد و سرور چک می کند و اگر فایل تغییر نکرده باشد دیگر فایل مجددا دانلود نخواهد شد و از کش موجود مرورگر استفاده خواهد شد.

 

فرمت پاسخ

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

در این فرمت HTTP/1.1 در جای نسخه اچ تی تی پی قرار میگیرد و در جای Status-Code شما یکی از کدهای وضعیتی را می بینید که کمی بالاتر در موردشان به صورت مفصل صحبت کردیم و Reason-Phrase هم توضیحی در مورد کد وضعیت است تا توسط انسان راحت تر درک شود.

بنابراین یک پاسخ نمونه به این شکل خواهد بود:

هدرهای «پاسخ» هم تقریبا محدود هستند و تصویر پایین لیست کامل آنها را نشان می دهد:

در این هدرها Age زمان را بر حسب ثانیه نمایش می دهد (از زمانی که پاسخ در سرور ایجاد شده است.) Etag نسخه هش شده Md5 اطلاعات است تا تغییرات را بررسی کند و Location وقتی مورد استفاده قرار میگیرد که ریدایرکتی انجام شود و حاوی URL جدید است.

 

چگونه ترافیک HTTP را ببینیم؟

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

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

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

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

در کنار آن ابزارهای تخصصی تری هم برای مانیتورینگ ترافیک اچ تی تی پی وجود دارند که به صورت یک پروکسی روی کامپیوتر شما عمل می کنند. Fiddler برای ویندوز و Charles برای مک دو ابزار قابل توجه به حساب می آیند و اگر جزو علاقمندان به کامندلاین به حساب می آیید، می توانید سراغ Curl ، TCPDump یا tShark بروید.

 

وقتش رسیده تا با این ابزارها نکاتی که در این مطلب یادگرفته اید را امتحان کنید و در بخش نظرات به ما بگویید که این مقاله چقدر برایتان مفید بوده است؟