HTTP/2 سریع ولی پیچیده

یکی از مهم‌ترین بهبودهایی که در بستر یک پلتفرم میکروسرویس تجربه کرده‌ام، مهاجرت از پروتکل قدیمی HTTP/1.1 به HTTP/2 بود. این انتقال باعث افزایش چشم‌گیر عملکرد و کاهش زمان پاسخ‌دهی شد؛ اما هم‌زمان چالش‌هایی را نیز به‌خصوص در زمینه مدیریت زیرساخت و ترافیک به همراه داشت.

چرا HTTP/2 سریع‌تر است؟ 🚀

در HTTP/1.1، ارتباط بین کلاینت و سرور به صورت هم‌زمان (synchronous) و ترتیبی انجام می‌شود. به‌عبارت دیگر:

• برای هر درخواست، معمولاً یک اتصال TCP جدید باز می‌شود.
• حتی در صورت پشتیبانی از Keep-Alive، تنها یک درخواست در هر لحظه روی یک اتصال می‌تواند فعال باشد (blocking I/O).
• اگر چندین درخواست هم‌زمان وجود داشته باشد، باید در صف بمانند (head-of-line blocking).

اما در HTTP/2، این محدودیت‌ها برطرف شده‌اند. ویژگی‌های کلیدی HTTP/2 عبارت‌اند از:

1. Multiplexing (چندگانگی)

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

2. Header Compression

استفاده از الگوریتم HPACK برای فشرده‌سازی هدرها که باعث کاهش حجم داده‌های ارسالی و بهبود سرعت می‌شود.

3. Stream Prioritization

در HTTP/2 می‌توان اولویت‌بندی روی جریان‌های مختلف اعمال کرد، تا منابع مهم‌تر سریع‌تر ارسال شوند.

4. Connection Reuse

با توجه به استفاده از یک اتصال واحد، دیگر نیازی به ایجاد مکرر TCP و TLS Handshake نیست که باعث کاهش چشمگیر زمان‌های تأخیر (latency) می‌شود.

چالش‌های HTTP/2 در موازنه بار (Load Balancing)

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

در HTTP/1.1، وقتی درخواست‌ها هرکدام اتصال جداگانه داشتند، یک Load Balancer در لایه ۴ (مثل Kube-proxy یا iptables در Kubernetes) به راحتی می‌توانست ترافیک را بین سرورها پخش کند، چراکه هر اتصال معادل یک درخواست بود.

اما در HTTP/2، تمام درخواست‌ها می‌توانند از یک اتصال واحد عبور کنند. بنابراین اگر موازنه‌گر بار فقط اتصال‌ها را مدیریت کند (Connection-based Load Balancing)، همه‌ی درخواست‌ها به یک سرویس پشت‌صحنه ارسال می‌شوند که موجب Overload شدن آن سرویس می‌شود.

مثال:

فرض کنید ۱۰۰ درخواست REST از یک کلاینت می‌آید. در HTTP/1.1، احتمالاً این درخواست‌ها بین ۳ یا ۴ پاد مختلف تقسیم می‌شدند. ولی در HTTP/2، اگر فقط از لایه ۴ استفاده کنید، همه آن‌ها به یک پاد می‌رسند!

راه‌حل: استفاده از Load Balancer در لایه ۷ (Application Layer)

برای حل این مشکل، می‌توان از موازنه بار در لایه ۷ استفاده کرد. برخلاف لایه ۴ که فقط IP و Port را بررسی می‌کند، در لایه ۷، خود درخواست (مثل مسیر URL، نوع عملیات، هدرها و …) بررسی و براساس آن تصمیم‌گیری می‌شود.

ابزارهای رایج برای لایه ۷:

• Istio
• Linkerd
• NGINX Ingress Controller
• Envoy Proxy

این ابزارها معمولاً در قالب Service Mesh پیاده‌سازی می‌شوند که علاوه‌بر Load Balancing، قابلیت‌هایی مثل:

• مشاهده‌پذیری (Observability)
• کنترل ترافیک
• Retry و Timeout
• Circuit Breaker
• امنیت درون‌خوشه‌ای (mTLS)
  را نیز ارائه می‌دهند.

اما باید توجه داشت که پیاده‌سازی Service Mesh خود به منابع، آموزش و زمان نگهداری نیاز دارد.

جمع‌بندی: مزایا و معایب HTTP/2

راه‌حل‌های حل چالش Load Balancing در HTTP/2

1. استفاده از Load Balancer در لایه ۷ (Application Layer)

HTTP/2 چون درخواست‌ها رو از طریق یک اتصال واحد multiplex می‌کنه، دیگه load balancing در لایه ۴ (مثل Kube-proxy) جواب نمی‌ده. در عوض، باید از load balancerهایی استفاده کنیم که محتویات HTTP (مثل مسیر URL، هدرها، متدها) رو بررسی می‌کنن.

ابزارهای معروف:

• NGINX / NGINX Ingress Controller
• HAProxy
• Envoy Proxy
• Traefik

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

2. پیاده‌سازی Service Mesh

وقتی بخوای کنترل خیلی دقیق‌تری روی ترافیک بین سرویس‌ها داشته باشی، سرویس مش بهترین گزینه‌ست.

ویژگی‌های مهم:

• Load balancing سطح بالا بر اساس درخواست (Request-Level)
• Retry، Timeout، Circuit Breaker
• ترافیک هوشمند (Canary Release، Traffic Shifting)
• امنیت بین سرویس‌ها (mTLS)

معروف‌ترین سرویس مش‌ها:

• Istio (با Envoy)
• Linkerd
• Consul Connect
• Kuma

سرویس مش‌ها معمولاً در قالب Sidecar Proxy برای هر پاد اجرا می‌شن، که ترافیک خروجی و ورودی هر سرویس رو کنترل می‌کنه.

3. فعال‌سازی Connection Pooling و HTTP/2 Prioritization در کلاینت‌ها

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

راه‌حل:

• استفاده از کلاینت‌هایی که از HTTP/2-aware load balancing پشتیبانی می‌کنن (مثل gRPC، یا Istio-aware SDKs)
• تنظیم Connection Pool برای اجبار پخش ترافیک روی چند اتصال به چند پاد

4. استفاده از Gateway هوشمند بین Client و Cluster

وقتی کاربران نهایی یا API Gateway شما از بیرون ترافیک می‌فرستن، بهتره یه لایه میانی مثل Envoy یا API Gateway هوشمند قرار بدی که ترافیک رو قبل از رسیدن به داخل کلاستر مدیریت کنه.

مثل:

• Kong
• Apigee
• Amazon API Gateway
• Ambassador

نتیجه نهایی:

اگرچه HTTP/2 از نظر عملکردی پیشرفت بزرگی نسبت به HTTP/1.1 به‌شمار می‌رود، اما باید با درک دقیق معماری زیرساخت، به سمت آن حرکت کرد. مخصوصاً در معماری‌های میکروسرویس، که پیچیدگی‌ها در مقیاس بالا بیشتر خود را نشان می‌دهند، نیاز به استفاده از سرویس مش‌ها و Load Balancerهای هوشمند، امری اجتناب‌ناپذیر است.