HTTP یک یک پروتکل برای دریافت منابع از جمله اسناد HTML است. این پروتکل بنیان هر نوع تبادل داده در سطح وب بوده و یک پروتکل کلاینت-سرور است، که یعنی در آن درخواست‌ها توسط دریافت‌کننده (به طور معمول مرورگر وب)  آغاز می‌شوند. یک سند کامل در واقع بازسازی شده چند سند کوچک‌تر، مانند متن، عکس‌ها، ویدیوها، اسکریپت‌ها و… است. 

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

HTTP که اوایل دهه ۹۰ میلادی طراحی شده است، یک پروتکل قابل توسعه بوده و به مرور زمان رشد کرده است. همچنین HTTP یک پروتکل لایه اپلیکیشن است که روی ارتباطات TCP یا TLS ارسال می‌شود؛ هرچند که از نظر تئوری هر پروتکل تبادل قابل اتکاء می‌تواند برای ارسال درخواست و دریافت پاسخ HTTP مورد استفاده قرار بگیرد.

اجزای سیستم‌های مبتنی بر HTTP

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

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

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

کلاینت: عامل کاربر

عامل کاربر (User-agent) هر ابزاری است که به نیابت از کاربر عمل می‌کند. این نقش بیشتر در اختیار مرورگر قرار دارد اما ممکن است برنامه‌هایی که مهندسین و توسعه‌دهنده‌های وب برای دیباگ کردن اپلیکیشن خود استفاده می‌کنند نیز این نقش را بازی کنند.

همواره این مرورگر است که درخواست را آغاز می‌کند. برای نمایش یک صفحه وب، مرورگر یک درخواست را ارسال و سند HTML که نماینده صفحه وب است را دریافت می‌کند. سپس مرورگر پاسخ دریافتی را تجزیه کرده و درخواست‌های دیگری مربوط به اسکریپت‌ها، ظاهر صفحه و سایر ریسور‌س‌ها داخل صفحه (عکس‌ها و ویدیوها و…) ارسال می‌کند. سپس مرورگر این ریسورس‌ها را با یکدیگر ترکیب کرده و سند (صفحه وب) را نمایش می‌دهد. اسکریپت‌های اجراشده توسط مرورگر می‌توانند ریسورس‌های بیشتری در مراحل بعدی دریافت کنند و مرورگر صفحه را با توجه به این ریسورس‌ها به‌روزرسانی می‌کند.

سند فرامتنی

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

وب‌سرور

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

پراکسی‌ها

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

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

ویژگی‌های عمومی HTTP

HTTP ساده است

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

HTTP قابل توسعه است

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

HTTP بدون وضعیت است اما بدون سشن نیست

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

HTTP و کانکشن‌ها

یک کانکشن در سطح لایه انتقال کنترل شده است و از این رو خارج از حیطه HTTP است. HTTP نیازی ندارد که لایه انتقال زیری مبتنی بر ارتباط باشد، بلکه تنها لازم است قابل اتکاء باشد یا به عبارتی پیام‌ها را از دست ندهد (یا حداقل در صورت وقوع چنین حالتی یک خطا نمایش دهد). در بین دو پروتکل انتقال محبوب در سطح اینترنت، TCP قابل اتکاء بوده و UPD نیست. از این رو HTTP از TCP که قابل اتکا‌ء است استفاده می‌کند.

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

برای رفع این مشکل، در نسخه HTTP/1.1 پایپ‌لاینینگ (که پیاده‌سازی آن سخت بود) و کانکشن متداوم معرفی شد که در آن کانکشن TCP می‌تواند تا حدودی توسط هدر کانکشن کنترل شود. HTTP/2 با تسهیم پیام‌ها روی یک کانکشن و کمک به باز نگه داشتن کانکشن یک گام فراتر رفت.

در حال حاضر آزمایش‌هایی برای طراحی یک پروتکل انتقال مناسب‌تر برای HTTP در حال انجام است. برای مثال گوگل در حال آزمایش QUIC است که که روی بستر UDP ساخته شده و یک پروتکل انتقال کارآمدتر و قابل اتکاءتر ارائه می‌دهد.

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

ماهیت توسعه‌پذیری HTTP به مرور زمان اجازه کنترل بیشتری روی وب داده است. برای مثال ویژگی‌هایی نظیر متد‌های کش و احراز هویت از اولین نسخه‌های HTTP وجود داشته‌اند اما قابلیت‌های دیگری مانند کاهش محدودیت مبدا (Relaxing the origin constraint) بعدها به این پروتکل اضافه شده‌اند. در ادامه لیستی از ویژگی‌های قابل کنترل توسط HTTP را مشاهده می‌کنید:

کش کردن:

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

کاهش محدودیت مبدا:

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

احراز هویت:

پروتکل HTTP می‌تواند امکانات لازم برای احراز هویت ساده را فراهم کند تا تنها کاربرانی که مجوز دارند به صفحات خاصی دسترسی داشته باشند.

پراکسی و تونل زدن:

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

سشن‌ها:

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

APIهای مبتنی بر HTTP

معمول‌ترین کاربرد HTTP در API درخوسات‌های XMLHTTP هستند که در تبادل داده بین عامل کارربر و سرور استفاده می‌شوند. APIهای نوین همین ویژگی‌ها را با امکانات منعطف‌تر و قدرتمندتر فراهم می‌کنند. 

APIهای ارسال ایونت از سرور یک مسیر یک طرفه است که به سرور اجازه می‌دهد ایونت‌ها را با استفاده از HTTP به عنوان وسیله انتقال داده، به کلاینت ارسال کنند. 

تا وب هست HTTP هم هست

HTTP یک پروتکل قابل توسعه بوده و کاربرد آن آسان است. ترکیب ساختار کلاینت-سرور به همراه قابلیت اضافه کردن هدرها، به HTTP اجازه می‌دهد تا هم‌گام با پیشرفت وب، توسعه پیدا کند. هرچند HTTP/2 با تعبیه کردن پیام‌های HTTP در فریم‌ها کمی آن را پیچیده‌تر کرده، اما ساختار اصلی پیام از اولین نسخه HTTP تا کنون ثابت مانده است. به همین دلیل APIهای مبتنی بر HTTP به طور عمومی فارق از زمان (Timeless) هستند.