پروتکل HTTP
پیش از آشنایی با پروتکل HTTP ابتدا به تاریخچه ای در مورد وب می پردازیم. 12 مارس سال 1989 نقطه عطفی در تاریخ اینترنت بود. در آن روز World Wide Web یا همان WWW متولد شد. Sir Timothy John Berners-Lee دوازدهم مارس ۱۹۸۹ در مرکز تحقیقات هسته‌ای اروپا در ژنو (CERN) راه حلی ارائه کرد که هدف اصلی آن پایان بخشیدن به هرج و مرج ارتباطی در این مرکز بود. این محقق بریتانیایی در گزارش خود تأکید کرد که در شرایط موجود “نتایج تحقیقات در مورد مسائل پیچیده” از دست می‌روند.
او برای حل مشکل طرحی مبتنی بر “هایپرتکست” پیشنهاد کرد. این پیشنهاد در واقع سنگ بنای وب بود و به طراحی بخشی از اینترنت انجامید که امروز بیشترین کاربر را در سراسر جهان دارد.
با طرح برنرز-لی نتایج تحقیقات پژوهشگران از حالت جزایر پراکنده خارج و به هم متصل می‌شدند و امکان دسترسی دانشمندان به دستاوردهای دیگر محققان فراهم می‌شد. “لینک” دادن که امروز به امری بدیهی تبدیل شده، آن روز انقلابی به پا کرد.
این پژوهشگر بریتانیایی با وجود اینکه می‌توانست از ایده خود میلیاردها دلار درآمد کسب کند، از این امکان چشم پوشید. تیم برنرز-لی از ابتدا معتقد بود که باید بستری رایگان، فراگیر و قابل توسعه ایجاد کرد. او می‌گفت باید استانداردی یگانه برای آدرس‌دهی و استانداردی یگانه برای انتقال اطلاعات تعریف کرد تا هر صفحه موجود در شبکه از هر نقطه متصل به شبکه در هر نقطه از جهان در دسترس باشد.
برنرز-لی که فیزیک خوانده بود، کار روی این طرح را ادامه داد و بر بستر امکانات موجود زبان علامت‌گذاری متن‌های هایپر (اچ‌تی‌ام‌ال) و ابزار انتقال اطلاعات در شبکه (پروتکل “اچ‌تی‌تی‌پی”) را هم ارائه کرد. از این استانداردها هنوز هم استفاده می‌شود.
شما می توانید اطلاعات بیشتر را در لینک زیر مطالعه نمایید:
https://www.nngroup.com/articles/hypertext-history/
به عبارت ساده تر زبان HTML به منظور ارائه داده ها و پروتکل HTTP به منظور انتقال آن استفاده شد. در سال 1991 با انتشار اولین نسخه از پروتکل HTTP، استفاده از وب در خارج از مجموعه CERN نیز شروع شد.
تصویر بالا مربوط به اولین وب سایت ایجاد شده می باشد که در موسسه Cern آرشیو شده است. در ابتدا مرورگرهای وب مبتنی بر متن بوده و داده ها اغلب به صورت عمومی ارائه شده و هیچ احراز هویتی و رمزنگاری برای آن ها در نظر گرفته نمی شد. همچنین تنها یک وب سرور بر روی یک سرور قرار می گرفت و مفهوم vitual host که امروزه مورد استفاده قرار می گیرد، در آن زمان بکار گرفته نمی شد.
پروتکل HTTP/0.9
اولین پروتکل HTTP که متد GET را پشتبیانی می نمود، پروتکل HTTP/0.9 بود. هدر دیگری در این پروتکل وجود نداشت.
پروتکل HTTP/1.0
این پروتکل متدهای دیگر مانند PUT، DEL و POST را علاوه بر GET پشتیبانی می نمود. همچنین در پروتکل HTTP/0.9 سرورها تنها HTML را ارسال می کردند ولی در پروتکل HTTP/1.0 علاوه بر آن داده های دیگری مانند متن، تصویر، فایل های باینریر و موارد دیگر نیز پشتیبانی می شد. اطلاعات مربوط به این پروتکل در RFC 1945 تشریح داده شده است.
پروتکل HTTP/1.1
این پروتکل در ژوئن سال 1999 منتشر گردید و RFC 2616,2014 به تشریح این پروتکل می پردازند. در این پروتکل پشتیبانی از Virtual Host اضافه گردید. همچنین Host Header برای درخواست های کلاینت اجباری شد و ارسال چندین درخواست از طریق یک جفت سوکت TCP/IP امکان پذیر گردید. از موارد دیگر در این پروتکل، می توان به اضافه شدن متد OPTIONS و پشتیبانی بهتر از قابلیت Caching، Proxy و فشرده سازی اشاره نمود.
پروتکل HTTP/2
این پروتکل در RFC 7450.1 تشریح شده است و بیشتر در آن به افزایش Performance پرداخته شده است. پروتکل HTTP/1.1 که در سال 1999 ایجاد شده بود، پیش از نفوذ Stream های تصویری و شبکه های اجتماعی به خوبی فعالیت خود را انجام می داد. (به عنوان مثال تا سال 2004 هنوز شبکه اجتمای فیس بوک تاسیس نشده بود) این پروتکل با بهبود عملکرد و ارتقای سطوح ارتباطی در مرروگر ها و سرورها موجب امکان استفاده از شبکه های اجتماعی، ارسال داده های ویدئویی و موارد مشابه را میسر ساخت.
پشتیبانی از Push Promise هم قابلیت دیگری است که به سرور اجازه می دهد تا قبل از اینکه کلاینت درخواست خود را ارسال نماید، محتوا را برای وی ارسال نماید.
پروتکل HTTP/2 به جای اینکه از Pipeline استفاده نماید به صورت Multiplexed عمل می کند. Pipeline به منظور حل یک مشکل عمده در پروتکل HTTP/1.0 معرفی شده بود. مسئله این بود که اگر در پروتکل HTTP/1.0 صفحه ما دارای 50 منبع مختلف مانند تصاویر، کدهای CSS و مواردی از این قبیل بود، مرورگر می بایست 50 درخواست مختلف را ایجاد می کرد.
پروتکل HTTP/1.1 با استفاده از Pipelining تلاش می شد تا این مشکل توسط اجازه دادن به درخواست های HTTP چندگانه فرستاده شده در همان اتصال حل شود. تاثیر عملکرد Pipelining در پروتکل HTTP/1.1 نسبت به HTTP/1.0 بسیار چشمگیر بود ولی با این حال هنوز ضعف هایی در آن وجود داشت.
اگرچه درخواست های HTTP چندگانه، می تواند ارسال شود، ولی مرورگر هنوز مجبور است که پاسخ ها را دریافت و پردازش نماید. شما شاید این موضوع را تجربه کرده باشید که مدت زمانی زیادی را باید برای بارگذاری تمام اجزای گرافیکی آن منتظر بمانید ولی ناگهان موارد گرافیکی بارگذاری می شود به گونه ای که گویی فردی یک سوییچ را تغییر داده است چراکه تمام تصاویر به سرعت بارگذاری می شوند. در این حالت ترافیک پاسخ مربوط به بک تصویر بزرگ با وضوح بالا، Pipeline را اشغال می نماید.
موارد مختلفی برای رسیدگی به این موضوع در طول سال ها وجود داشت اما پروتکل HTTP/2.0 با کنار گذاشتن Pipeline و به جای آن به راحتی می تواند تمام ترافیک های HTTP را بر روی یک اتصال TCP برقرار کند. با استفاده از پروتکل HTTP/2 درخواست ها می توایند به صورت موازی ارسال شده و پاسخ ها نیز می توانند به صورت موازی دریافت و تجزیه شوند.
در واقع HTTP برای مدت طولانی است که از فشرده سازی داده ها پشتیبانی می کند. اما Header ها به صورت فشرده نشده و در قالب متن ارسال می شوند. HTTP/2 قابلیت جدیدی با نام HPACK را معرفی کرده است، این قابلیت یک طرح کلی برای هدرهای HTTP است که درخواست های متعدد را کاهش می دهد.
فشرده سازی به تسهیم نمودن درخواست ها کمک می کند، زیرا درخواست ها کوچکتر می باشند. این امر کاربران را قادر می سازد تا تعداد درخواست های زیادی را در اولین پکت های ارسالی خود به سرور ارسال نمایند، در حالیکه پنجره کنترل جریان TCP هنوز کوچک می باشد.
نمونه ای از درخواست HTTP/1.1
GET /search HTTP/1.1
Accept: /
Accept-Language: en-us
User-Agent: Mozila/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) Like Gecko
Host: www.google.com
Proxy-Connection: Keep-Alive
Cookie:SESSIONID=abcdef1234567890; ANSWER=42;
Content-Length: 0
همانطور که در بالا قابل مشاهده می باشد، سرویس گیرنده وب درخواستی برای یک منبع خاصر را ارسال می کند. روشی که در این مثال از آن برای ارسال اطلاعات استفاده می شود، روش GET می باشد. همچنین نسخه پروتکل مورد استفاده نیز در این درخواست مشخص می گردد.
User-Agent، نام Host، کوکی تنظیم شده و طول محتوا نیز در این درخواست مشخص می شوند. همانطور که در بالا مشاهده می کنید، درخواست ارسالی، شامل تعدادی از فیلدهای مختلف Header می باشد که اکثر این فیلدها اختیاری بوده و توسط مشتری یا برنامه اضافه می گردند.
توجه داشته باشید که User-Agent یک شناسه است که کلاینت آن را تنظیم می کند و سرور می تواند از این اطلاعات برای تغییر منطق خود و انطباق آن با کلاینت استفاده نماید. این شناسه در طی درخواست توسط کلاینت ارسال شده و اطلاعاتی از خود که شامل نوع مرورگر، سیستم عامل میزبان و زبان کلاینت را مشخص می کند. این موضوع باعث می شود تا سرور وب، صفحات مختلف را با فرمت مناسب برای کلاینت ارسال نماید.
اگرچه رشته مربوط به User-Agent معمولا به صورت پیش فرض به درستی تنظیم می شود اما این عبارت می تواند توسط کاربر نهایی تغییر یا جعل شود. امکان تغییر در User-Agent موجب می شود تا کاربر مواردی را که برای مرورگرهای دیگر تنظیم شده است دریافت نماید. همچنین با توجه به اینکه سرور از User-Agent به منظور تهیه آمارهای مختلف نیز بهره می برد، تغییر در آن می تواند موجب دریافت آمار نادرست برای سرور شود.
بسیاری از موارد مختلف نیز می توانند موجب تغییر در User-Agent شوند که ابزارهای جاسوسی یا Spyware ها نمونه ای از این موارد هستند. البته با استفاده از افزونه هایی که برای مرورگرها طراحی شده است نیز امکان تغییر در User-Agent وجود دارد.
نمونه ای از پاسخ پروتکل HTTP 1.1
HTTP/1.1 200 OK
Content-Type: text/html
Charset=UTF-8
Server: Apache/2.2.3 (Red Hat)
Date : Tue. 01 Apr 2018 23:48:13 GMT
Content-Length: 6243
پس از اینکه سرور، اطلاعات Request را از کلاینت دریافت نمود، باید به آن پاسخ دهد. این پاسخ با یک کد وضعیت یا Status Code انجام می شود. مورد دیگری که در پاسخ قرار داده می شود، Content-Type می باشد. این بخش مشخص می کند که کلاینت باید منتظر چه نوع داده ای باشد و همچنین طول آن چه مقدار است. علاوه بر این، سرور تاریخ و نام سرور را نیز ارسال می کند که این موضوع موجب افشای اطلاعات مربوط به سرور و نوع ماژول های مورد استفاده در آن می گردد. در این مثال نام وب سرور به همراه نسخه آن و نوع سیستم عامل افشا گردیده است.
منابع این بخش:
