فصل اول - مروری بر پروتکل HTTP

مرورگرهای وب جهان، سرورها و برنامه‌های وب مرتبط، همگی از طریق HTTP، یعنی پروتکل انتقال ابرمتن [Hypertext Transfer Protocol]، با یکدیگر ارتباط برقرار می‌کنند. HTTP زبان مشترک اینترنت جهانیِ مدرن است.

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

• نحوهٔ ارتباط کلاینت‌های وب و سرورها
  
• منبعِ منابع (محتوای وب) از کجا تأمین می‌شود
  
• چگونگی انجام تراکنش‌های وب
  
• قالب پیام‌هایی که برای ارتباط HTTP به کار می‌روند
  
• لایهٔ زیرین انتقال شبکه یعنی TCP
  
• گونه‌ها و نسخه‌های مختلف پروتکل HTTP
  
• تعدادی از اجزای معماری متنوع HTTP که در سراسر اینترنت نصب شده‌اند
  

مطالب زیادی برای پرداختن داریم، پس بیایید سفر خود در دنیای HTTP را آغاز کنیم.

HTTP: The Internet’s Multimedia Courier

میلیاردها تصویر JPEG، صفحهٔ HTML، فایل متنی، فیلم‌های MPEG، فایل‌های صوتی WAV، برنامه‌های کوچک Java applet و بسیاری موارد دیگر، هر روز در اینترنت جریان دارند. HTTP بخش اعظم این اطلاعات را به‌سرعت، راحت و قابل اعتماد، از وب‌سرورهای سراسر جهان به مرورگرهای وب روی دسکتاپ‌های کاربران منتقل می‌کند.

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

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

حالا بیایید با دقت بیشتری ببینیم HTTP چگونه ترافیک وب را منتقل می‌کند.

Web Clients and Servers - کلاینت و وب سرور ها

محتوای وب بر روی وب‌سرورها قرار دارد. وب‌سرورها با پروتکل HTTP صحبت/کار می‌کنند، به همین دلیل اغلب « HTTP Server» نامیده می‌شوند. این سرورها داده‌های موجود در اینترنت را ذخیره کرده و هنگام درخواست، آن‌ها را در اختیار کلاینت‌های HTTP قرار می‌دهند.

کلاینت‌ها درخواست‌های HTTP را به سرورها می‌فرستند و سرورها داده‌های درخواستی را در قالب پاسخ‌های HTTP بازمی‌گردانند، همان‌طور که در شکل ۱-۱ نشان داده شده است. در کنار هم، کلاینت‌های HTTP و سرورهای HTTP اجزای اصلی تشکیل‌دهندهٔ شبکه جهانی وب (World Wide Web) هستند.

شما احتمالاً هر روز از کلاینت‌های HTTP استفاده می‌کنید. رایج‌ترین کلاینت، یک مرورگر وب است؛ مانند Microsoft Internet Explorer یا Netscape Navigator. مرورگرهای وب اشیای HTTP را از سرورها درخواست کرده و آن‌ها را روی صفحهٔ شما نمایش می‌دهند.

وقتی به صفحه‌ای مانند ‎https://www.w-riter.com/index.html‎ مراجعه می‌کنید، مرورگر شما یک درخواست HTTP به سرور www.w-riter.com می‌فرستد (به شکل ۱-۱ نگاه کنید). سرور تلاش می‌کند شیء درخواستی را پیدا کند (در این مثال، ‎/index.html‎) و اگر موفق شود، آن شیء را همراه با نوع آن، طول آن و سایر اطلاعات، در قالب یک پاسخ HTTP به کلاینت ارسال می‌کند.

منابع - Resources

وب‌سرورها میزبان منابع وب هستند. یک منبع وب، منبع اصلی تولید محتوای وب است. ساده‌ترین نوع منبع وب، یک فایل ایستا (static file) در سیستم فایل وب‌سرور است. این فایل‌ها می‌توانند هر چیزی را شامل شوند: ممکن است فایل متنی باشند، فایل HTML، فایل Microsoft Word، فایل Adobe Acrobat، تصاویر JPEG، فیلم‌های AVI یا هر قالب دیگری که به ذهن شما برسد.

با این حال، منابع الزاماً فایل‌های ایستا نیستند. منابع می‌توانند برنامه‌های نرم‌افزاری نیز باشند که محتوای درخواستی را به‌صورت پویا تولید می‌کنند. این منابع محتوای پویا می‌توانند بر اساس هویت شما، اطلاعاتی که درخواست کرده‌اید یا حتی زمان روز محتوا ایجاد کنند. آن‌ها می‌توانند تصویری زنده از یک دوربین به شما نشان دهند، امکان معاملهٔ سهام را فراهم کنند، اجازه دهند در پایگاه‌های دادهٔ املاک جستجو کنید یا از فروشگاه‌های اینترنتی هدیه بخرید (به شکل ۱-۲ نگاه کنید).

خلاصه اینکه، منبع (Resource) هر نوع منبع تولید محتوا است. یک فایل که شامل صفحه‌گستردهٔ پیش‌بینی فروش شرکت شما باشد، یک منبع(Resource) است. یک درگاه وب برای جست‌وجوی قفسه‌های کتابخانهٔ عمومی محل شما، یک منبع است. یک موتور جست‌وجوی اینترنتی هم یک منبع به شمار می‌آید.

انواع رسانه - Media Types

از آنجا که اینترنت میزبان هزاران نوع داده‌ی متفاوت است، HTTP با دقت هر شیء منتقل‌شده از طریق وب را با یک برچسب فرمت داده که نوع MIME نام دارد، علامت‌گذاری می‌کند.
MIME (مخفف Multipurpose Internet Mail Extensions یا «افزونه‌های چندمنظورهٔ پست اینترنتی») در ابتدا طراحی شد تا مشکلات موجود در انتقال پیام‌ها میان سیستم‌های مختلف پست الکترونیک را حل کند. MIME آن‌قدر برای ایمیل خوب کار کرد که HTTP نیز آن را برای توصیف و برچسب‌گذاری محتوای چندرسانه‌ای خودش به کار گرفت.

سرورهای وب یک MIME Type را به تمام داده‌های شیءهای HTTP متصل می‌کنند (شکل ۱-۳ را ببینید). هنگامی که مرورگر وب یک شیء را از سرور دریافت می‌کند، نوع MIME مرتبط با آن را بررسی می‌کند تا ببیند آیا می‌داند چگونه باید آن شیء را پردازش کند یا نه. بیشتر مرورگرها می‌توانند صدها نوع شیء پرکاربرد را مدیریت کنند: نمایش فایل‌های تصویری، تجزیه(Parsing) و قالب‌بندی (Formatting) فایل‌های HTML، پخش فایل‌های صوتی از طریق بلندگوهای رایانه، یا اجرای نرم‌افزارهای جانبی (plug-in) برای پردازش فرمت‌های ویژه.

نوع MIME Type یک برچسب متنی است که به‌صورت یک نوع شیء اصلی (primary object type) و یک زیرنوع (subtype) خاص نمایش داده می‌شود که با یک علامت اسلش (/) از هم جدا می‌شوند. برای مثال:

• یک سند متنی با قالب‌بندی HTML با نوع text/html برچسب‌گذاری می‌شود.
  
• یک سند متنی ساده به فرمت ASCII با نوع text/plain برچسب‌گذاری می‌شود.
  
• یک تصویر با فرمت JPEG دارای برچسب image/jpeg خواهد بود.
  
• یک تصویر با فرمت GIF دارای برچسب image/gif خواهد بود.
  
• یک فیلم Apple QuickTime با نوع video/quicktime مشخص می‌شود.
  
• یک ارائهٔ Microsoft PowerPoint با نوع application/vnd.ms-powerpoint برچسب‌گذاری می‌شود.
  

صدها نوع MIME پرکاربرد وجود دارد و تعداد بسیار بیشتری هم برای استفاده‌های آزمایشی یا محدود تعریف شده‌اند. یک فهرست بسیار کامل از انواع MIME در پیوست D ارائه شده است.

URIs

هر منبع (resource) روی یک سرور وب یک نام دارد تا کلاینت‌ها بتوانند مشخص کنند به کدام منابع مورد علاقه خود اشاره می کند. این نام منبع سرور را شناسهٔ یکنواخت منبع یا URI (Uniform Resource Identifier) می‌نامند. URIها مانند آدرس‌های پستی اینترنت هستند که منابع اطلاعاتی را به‌طور یکتا در سراسر جهان شناسایی و مکان‌یابی می‌کنند.

در اینجا یک نمونه URI برای یک منبع تصویری روی سرور وب فروشگاه Joe’s Hardware آمده است:

http://www.joes-hardware.com/specials/saw-blade.gif

شکل ۱-۴ نشان می‌دهد که چگونه این URI پروتکل HTTP را برای دسترسی به منبع تصویری (GIF) اره‌بر روی سرور فروشگاه Joe مشخص می‌کند. با داشتن این URI، HTTP می‌تواند شیء را بازیابی کند.

این URIها در دو نوع عرضه می‌شوند که URL و URN نام دارند. بیایید نگاهی به هر یک از این انواع شناسه‌های منبع بیندازیم.

URLs

نشانی یکنواخت منبع یا URL (Uniform Resource Locator) رایج‌ترین شکل شناسهٔ منبع است.
URLها مکان دقیق یک منبع را روی یک سرور مشخص توصیف می‌کنند. آن‌ها دقیقاً به شما می‌گویند که چگونه یک منبع را از یک مکان مشخص و ثابت دریافت کنید.

شکل ۱-۴ نشان می‌دهد که چگونه یک URL به‌طور دقیق بیان می‌کند یک منبع کجا قرار دارد و چگونه باید به آن دسترسی پیدا کرد. جدول ۱-۱ نیز چند نمونه از URLها را نشان می‌دهد.

جدول 1-1

بیشتر URLها از یک قالب استاندارد با سه بخش اصلی پیروی می‌کنند:

• بخش اول URL که scheme نامیده می‌شود، پروتکلی را توصیف می‌کند که برای دسترسی به منبع استفاده می‌شود. این پروتکل معمولاً HTTP است (مانند http://).
• بخش دوم آدرس اینترنتی سرور را مشخص می‌کند (برای مثال: www.joes-hardware.com).
• بخش سوم نام منبع موجود روی سرور وب را تعیین می‌کند (برای مثال: /specials/saw-blade.gif).

امروزه تقریباً هر URI در واقع یک URL است.

URNs

نوع دوم از URI، نام یکتای منبع یا URN (Uniform Resource Name) است. یک URN به‌عنوان یک نام یکتا برای یک محتوای خاص عمل می‌کند، بدون توجه به این‌که منبع در حال حاضر کجا قرار دارد. این URNهای مستقل از مکان، امکان جابه‌جایی منابع از جایی به جای دیگر را فراهم می‌کنند. همچنین URNها اجازه می‌دهند یک منبع از طریق چندین پروتکل دسترسی شبکه مورد استفاده قرار گیرد، در حالی که همان نام ثابت باقی می‌ماند.

برای نمونه، URN زیر ممکن است برای نام‌گذاری سند استاندارد اینترنتی «RFC 2141» به کار رود، فارغ از این‌که در کجا قرار داشته باشد (حتی ممکن است در چندین مکان کپی شده باشد):

urn:ietf:rfc:2141

این URNها هنوز در مرحلهٔ آزمایشی هستند و به‌طور گسترده مورد پذیرش قرار نگرفته‌اند. برای این‌که URNها به‌طور مؤثر کار کنند، به یک زیرساخت پشتیبان نیاز دارند تا مکان منبع را پیدا کند؛ نبود چنین زیرساختی نیز روند پذیرش آن‌ها را کند کرده است. با این حال، URNها نویدهای هیجان‌انگیزی برای آینده در خود دارند. ما در فصل دوم کمی بیشتر دربارهٔ URNها بحث خواهیم کرد، اما بیشتر بخش‌های باقی‌ماندهٔ این کتاب تقریباً منحصراً بر URLها تمرکز دارد.

مگر این‌که خلاف آن ذکر شده باشد، ما اصطلاحات متداول را می‌پذیریم و در ادامهٔ کتاب URI و URL را به‌جای یکدیگر به‌کار می‌بریم.

تراکنش‌ها - Transactions

بیایید با جزئیات بیشتری بررسی کنیم که چگونه کلاینت‌ها از HTTP برای انجام تراکنش با وب‌سرورها و منابع آن‌ها استفاده می‌کنند. یک تراکنش HTTP شامل یک فرمان درخواست (request command که از کلاینت به سرور فرستاده می‌شود) و یک نتیجهٔ پاسخ (response result که از سرور به کلاینت بازگردانده می‌شود) است.

این ارتباط با بلوک‌های قالب‌بندی‌شدهٔ داده، که پیام‌های HTTP (HTTP messages) نام دارند، انجام می‌شود؛ همان‌طور که در شکل 1-5 نشان داده شده است.

متدها

پروتکل HTTP از چندین فرمان درخواست مختلف پشتیبانی می‌کند که به آن‌ها متدهای HTTP (HTTP methods) گفته می‌شود. هر پیام درخواست HTTP دارای یک متد است. این متد به سرور اعلام می‌کند که چه عملی باید انجام دهد (برای مثال: واکشی یک صفحهٔ وب، اجرای یک برنامهٔ Gateway، حذف یک فایل و غیره).

جدول 1-2 پنج متد رایج HTTP را فهرست کرده است.

ما در فصل سوم به‌طور مفصل دربارهٔ متدهای HTTP بحث خواهیم کرد.

کدهای وضعیت - Status Codes

هر پیام پاسخ HTTP همراه با یک کد وضعیت (status code) بازگردانده می‌شود. کد وضعیت یک عدد سه‌رقمی است که به کلاینت اعلام می‌کند آیا درخواست موفق بوده است یا این‌که اقدامات دیگری لازم است.

چند نمونه از کدهای وضعیت رایج در جدول 3-1 نشان داده شده‌اند.

همچنین HTTP همراه با هر کد عددی وضعیت، یک عبارت متنی توضیحی (reason phrase) ارسال می‌کند (به پیام پاسخ در شکل 1-5 نگاه کنید). این عبارت متنی صرفاً برای توضیحات درج می‌شود؛ پردازش‌ها همگی بر اساس کد عددی انجام می‌گیرند.

کدهای وضعیت و عبارت‌های متنی زیر، همگی توسط نرم‌افزار HTTP به‌طور یکسان تفسیر می‌شوند:

200 OK
200 Document attached
200 Success
200 All’s cool, dude

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

صفحات وب می‌توانند از چندین شیء تشکیل شوند

Web Pages Can Consist of Multiple Objects

یک برنامه اغلب برای انجام یک وظیفه چندین تراکنش HTTP صادر می‌کند. برای نمونه، یک مرورگر وب مجموعه‌ای از تراکنش‌های HTTP را به‌صورت زنجیره‌ای اجرا می‌کند تا یک صفحهٔ وب غنی از گرافیک را واکشی و نمایش دهد. مرورگر ابتدا یک تراکنش برای واکشی اسکلت HTML که چیدمان صفحه را توصیف می‌کند انجام می‌دهد، سپس برای هر تصویر جاسازی‌شده، پنل گرافیکی، اپلت جاوا و غیره، تراکنش‌های HTTP اضافی صادر می‌کند.

این منابع جاسازی‌شده حتی ممکن است روی سرورهای متفاوتی قرار داشته باشند، همان‌طور که در شکل 6-1 نشان داده شده است. بنابراین، یک «صفحهٔ وب» اغلب مجموعه‌ای از منابع است، نه یک منبع واحد.

پیام‌ها - Messages

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

پیام‌های HTTP ساده‌اند و از دنباله‌ای از کاراکترها به‌صورت خط‌محور تشکیل می‌شوند. از آن‌جا که این پیام‌ها متن ساده (plain text) هستند و نه دودویی (binary)، خواندن و نوشتن آن‌ها برای انسان‌ها آسان است.

شکل 7-1 پیام‌های HTTP مربوط به یک تراکنش ساده را نشان می‌دهد.

پیام‌های HTTP که از کلاینت‌های وب به وب‌سرورها فرستاده می‌شوند، پیام‌های درخواست (request messages) نامیده می‌شوند. پیام‌هایی که از سرورها به کلاینت‌ها ارسال می‌شوند، پیام‌های پاسخ (response messages) نامیده می‌شوند. هیچ نوع دیگری از پیام‌های HTTP وجود ندارد.

قالب پیام‌های درخواست و پاسخ HTTP بسیار شبیه به یکدیگر است.

پیام‌های HTTP از سه بخش تشکیل می‌شوند:

۱. خط آغازین (Start line)
اولین خط پیام، خط آغازین است که در پیام درخواست مشخص می‌کند چه عملی باید انجام شود، و در پیام پاسخ نشان می‌دهد چه اتفاقی رخ داده است.

۲. فیلدهای سرآیند (Header fields)
پس از خط آغازین، صفر یا چند فیلد سرآیند قرار می‌گیرد. هر فیلد سرآیند از یک نام و یک مقدار تشکیل شده است که با علامت دونقطه (:) از هم جدا می‌شوند تا پردازش آن ساده باشد. سرآیندها با یک خط خالی به پایان می‌رسند. افزودن یک فیلد سرآیند به‌سادگی اضافه کردن یک خط جدید است.

۳. بدنه (Body)
پس از خط خالی، یک بدنهٔ اختیاری پیام قرار دارد که می‌تواند شامل هر نوع داده‌ای باشد. بدنهٔ درخواست داده‌ها را به وب‌سرور منتقل می‌کند؛ بدنهٔ پاسخ داده‌ها را به کلاینت بازمی‌گرداند. برخلاف خط آغازین و سرآیندها که متنی و ساختاریافته هستند، بدنه می‌تواند شامل داده‌های دودویی دلخواه باشد (مانند تصاویر، ویدیوها، فایل‌های صوتی یا نرم‌افزارها). البته بدنه می‌تواند شامل متن نیز باشد.

نمونهٔ سادهٔ پیام - Simple Message Example

شکل 8-1 پیام‌های HTTP را نشان می‌دهد که ممکن است به‌عنوان بخشی از یک تراکنش ساده ارسال شوند. مرورگر منبع http://www.joes-hardware.com/tools.html را درخواست می‌کند.

در شکل 8-1، مرورگر یک پیام درخواست HTTP ارسال می‌کند. این درخواست در خط آغازین(Request start line) دارای متد GET است و منبع محلی آن /tools.html می‌باشد. درخواست مشخص می‌کند که از نسخهٔ 1.0 پروتکل HTTP استفاده می‌کند. پیام درخواست بدنه‌ای ندارد، زیرا برای دریافت (GET) یک سند ساده از سرور، نیازی به دادهٔ اضافی در بدنه نیست.

سرور در پاسخ، یک پیام پاسخ HTTP بازمی‌گرداند. این پاسخ شامل شمارهٔ نسخهٔ HTTP (HTTP/1.0)، یک کد وضعیت موفقیت (200)، یک عبارت توضیحی (OK) و مجموعه‌ای از فیلدهای سرآیند پاسخ (response header fields) است. پس از آن، بدنهٔ (Response body) پاسخ قرار دارد که شامل سند درخواست‌شده است. طول بدنهٔ پاسخ در سرآیند Content-Length ذکر می‌شود و نوع MIME سند نیز در سرآیند Content-Type مشخص می‌گردد.