1️⃣کلا HTTP ساده است (HTTP is simple)
به طور کلی طوری طراحی شده است که برای انسان‌ها قابل خواندن باشد، حتی با پیچیدگی‌های اضافه شده در HTTP/2 از طریق کپسوله‌سازی پیام‌های HTTP در Frameها. 📖
پیام‌های HTTP را می‌توان توسط انسان خواند و درک کرد، که آزمایش را برای توسعه‌دهندگان آسان‌تر کرده و پیچیدگی را برای تازه‌واردها کاهش می‌دهد.
2️⃣ HTTP قابل توسعه است (HTTP is extensible)
با معرفی HTTP Headers در HTTP/1.0، این پروتکل به راحتی قابل توسعه و آزمایش است. 🛠 عملکرد جدید حتی می‌تواند از طریق توافق بین یک کلاینت و یک سرور در مورد معناشناسی (semantics) یک هدر جدید معرفی شود.
3️⃣ و HTTP بدون وضعیت است، اما بدون Session نیست (HTTP is stateless, but not sessionless)بدون وضعیت (Stateless) است: هیچ ارتباطی بین دو درخواستی که به طور متوالی روی یک اتصال انجام می‌شوند، وجود ندارد.
اما در حالی که هسته HTTP خودش بدون وضعیت است، کوکی‌های HTTP اجازه استفاده از Sessionهای با وضعیت (Stateful Sessions) را می‌دهند. با استفاده از قابلیت توسعه هدر، کوکی‌های HTTP به گردش کار اضافه می‌شوند و امکان ایجاد Session در هر درخواست HTTP را برای به اشتراک گذاشتن زمینه (Context) یا همان وضعیت (State) فراهم می‌کنند. 🍪
4️⃣حالا نوبت HTTP و اتصالات (HTTP and connections)
اتصال در لایه انتقال کنترل می‌شود و بنابراین اساساً خارج از حوزه HTTP است. HTTP نیاز ندارد که پروتکل انتقال زیرین مبتنی بر اتصال باشد؛ بلکه تنها نیازمند این است که قابل اعتماد (reliable) باشد، یا پیام‌ها را از دست ندهد (حداقل در چنین مواردی خطا ارائه دهد).
از بین دو پروتکل انتقال رایج در اینترنت، TCP قابل اعتماد است و UDP نیست. بنابراین HTTP بر استاندارد TCP تکیه دارد که مبتنی بر اتصال است. 🌐
⚙️ بهینه‌سازی اتصالات
قبل از اینکه یک کلاینت و سرور بتوانند یک جفت درخواست/پاسخ HTTP را تبادل کنند، باید یک اتصال TCP ایجاد کنند، فرآیندی که نیاز به چندین رفت و برگشت (round-trips) دارد. 🐢
رفتار پیش‌فرض HTTP/1.0 این بود که یک اتصال TCP مجزا برای هر جفت درخواست/پاسخ HTTP باز کند. این کار در هنگام ارسال درخواست‌های متعدد در فاصله زمانی کوتاه، کارایی کمتری دارد.
برای کاهش این نقص، HTTP/1.1 پایپ‌لاینینگ (pipelining) (که پیاده‌سازی آن دشوار بود) و اتصالات پایدار (persistent connections) را معرفی کرد: اتصال TCP زیرین می‌تواند با استفاده از هدر Connection تا حدی کنترل شود.
بعد HTTP/2 یک گام فراتر رفت و با Multiplexing پیام‌ها روی یک اتصال واحد، به گرم نگه داشتن اتصال و کارایی بیشتر کمک کرد.
آزمایش‌هایی برای طراحی یک پروتکل انتقال بهتر که مناسب‌تر برای HTTP باشد، در حال انجام است. برای مثال، Google در حال آزمایش QUIC است که بر پایه UDP ساخته شده تا یک پروتکل انتقال قابل اعتمادتر و کارآمدتر را فراهم کند.