L4 vs L7 Load Balancing

গল্পে বুঝি

সমরকন্দের বড় ডাকঘরে দুজন বাছাইকারী কাজ করেন। আল-খোয়ারিজমি বসেন সামনের টেবিলে। তাঁর নিয়ম সহজ — প্রতিটা পার্সেলের বাইরে লেখা পোস্টকোড দেখেই তিনি ঠিক করে দেন কোন থলেতে ফেলবেন। বাক্স তিনি কখনো খোলেন না, ভেতরে কী আছে তাতে তাঁর কিছুই যায়-আসে না। শুধু পোস্টকোড মিলিয়ে ছুড়ে দেন — তাই তাঁর হাত অবিশ্বাস্য দ্রুত, দিনে হাজার হাজার পার্সেল সামলে ফেলেন। কিন্তু কেউ যদি জিজ্ঞেস করে “এই বাক্সে চিঠি না ছবি?”, তিনি কাঁধ ঝাঁকিয়ে বলেন — জানি না, বাইরে যা লেখা তা-ই কেবল দেখেছি।

পাশের টেবিলে বসেন ফাতিমা আল-ফিহরি। তাঁর কাজ আলাদা — তিনি প্রতিটা পার্সেল আসলে খুলে ভেতরের জিনিসটা পড়েন, তারপর বিষয় বুঝে পাঠান: “সব হিসাবপত্র যাবে হিসাব বিভাগে, সব ছবি যাবে আর্কাইভে, চিঠিগুলো পাঠাগারে।” এতে রুটিং অনেক বুদ্ধিমান হয় — একই পোস্টকোডের পার্সেলও ভেতরের বিষয় অনুযায়ী আলাদা জায়গায় যায়। কিন্তু প্রতিটা বাক্স খুলে পড়তে সময় লাগে, তাই তাঁর গতি আল-খোয়ারিজমির চেয়ে ধীর।

এই দুই বাছাইকারীই হলো L4 আর L7 load balancing। আল-খোয়ারিজমি বাইরের পোস্টকোড দেখেই পাঠান — এটাই L4, যে শুধু IP আর port দেখে route করে, দ্রুত কিন্তু ভেতরের content সম্পর্কে অন্ধ। ফাতিমা বাক্স খুলে ভেতরের বিষয় পড়েন — এটাই L7, যে পুরো HTTP request-এর path, host, header পড়ে content অনুযায়ী route করে, বুদ্ধিমান কিন্তু বেশি খাটুনির কারণে ভারী। বাস্তবে ঠিক এ কারণেই edge-এ দ্রুত L4 (যেমন AWS NLB) traffic ধরে অ্যাপের কাছে থাকা L7-এ (nginx বা HAProxy) পাঠায় — যেখানে path/host দেখে সিদ্ধান্ত নেওয়া দরকার।

OSI Model, সংক্ষেপে

Load balancer network stack-এর বিভিন্ন layer-এ কাজ করে:

Layer 7 — Application  (HTTP, gRPC, WebSocket — reads headers, URLs, cookies)
Layer 4 — Transport    (TCP, UDP — reads IP:port only, never sees content)

Layer-টাই ঠিক করে balancer কী inspect করতে পারবে আর কীসের উপর ভিত্তি করে কাজ করবে।

L4 Load Balancing

L4 balancer শুধু IP address আর port-এর ভিত্তিতে route করে। এরা কখনো HTTP payload parse করে না — raw TCP/UDP stream forward করে দেয়। HTTP method, path, cookie বা hostname সম্পর্কে balancer-এর কোনো ধারণা থাকে না।

Client → [L4 LB: TCP :443] → Backend server (raw stream forwarded)

বৈশিষ্ট্য:

• অত্যন্ত দ্রুত — প্রতিটা connection-এ ন্যূনতম processing
• যেকোনো TCP/UDP protocol-এর সাথে কাজ করে (database, SMTP, custom binary protocol)
• Backend, source হিসেবে LB-র IP দেখে (যদি না PROXY protocol enable থাকে)
• HTTP path বা hostname-এর ভিত্তিতে route করতে পারে না
• TLS হয় pass-through হয়, নয়তো backend-এ terminate হয়

উদাহরণ — AWS NLB (Network Load Balancer) হলো L4:

• TCP connection target-এ route করে
• HTTP header inspect করতে পারে না
• non-HTTP workload-এর জন্য বা যখন সর্বোচ্চ throughput দরকার তখন ব্যবহার হয়

HAProxy L4 mode:

frontend tcp_in
    bind *:5432
    mode tcp
    default_backend postgres_backends

backend postgres_backends
    mode tcp
    balance roundrobin
    server db1 10.0.0.10:5432 check
    server db2 10.0.0.11:5432 check

এটা PostgreSQL connection proxy করে — HAProxy জানে না যে এটা একটা database; সে শুধু TCP forward করছে।

L7 Load Balancing

L7 balancer connection terminate করে আর পুরো HTTP request parse করে। তারা এইসবের ভিত্তিতে routing সিদ্ধান্ত নিতে পারে:

• Host header — api.example.com vs app.example.com
• URL path — /api/* vs /static/*
• HTTP method — POST-কে GET থেকে আলাদাভাবে route করা
• Header — X-User-ID, Authorization, custom header
• Cookie — session affinity
• Request body (বিরল, ব্যয়বহুল)

Client → [L7 LB: TLS termination + HTTP parse] → Backend server (new connection)

উদাহরণ — nginx L7 routing:

upstream api_servers {
    server 10.0.0.10:3000;
    server 10.0.0.11:3000;
}

upstream static_servers {
    server 10.0.0.20:80;
}

server {
    listen 443 ssl;
    server_name example.com;

    location /api/ {
        proxy_pass http://api_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /static/ {
        proxy_pass http://static_servers;
    }

    location / {
        proxy_pass http://api_servers;
    }
}

HAProxy L7 mode:

frontend http_in
    bind *:80
    mode http
    acl is_api path_beg /api/
    use_backend api_servers if is_api
    default_backend web_servers

backend api_servers
    mode http
    balance leastconn
    server api1 10.0.0.10:3000 check
    server api2 10.0.0.11:3000 check

backend web_servers
    mode http
    balance roundrobin
    server web1 10.0.0.20:3000 check

তুলনা

	L4	L7
যা inspect করে	IP + port	পুরো HTTP request
TLS	Pass-through বা backend	LB-তে terminate হয়
Routing rule	শুধু IP/port	Path, host, header, cookie
গতি	খুব দ্রুত	দ্রুত (সামান্য overhead)
Protocol	যেকোনো TCP/UDP	HTTP, gRPC, WebSocket
Observability	Connection count	Request rate, status code, latency

কোনটা কখন বেছে নেবেন

L4 ব্যবহার করুন যখন:

• Protocol-টা HTTP নয় (database, SMTP, custom TCP)
• ন্যূনতম overhead-এ সর্বোচ্চ throughput দরকার
• আপনি TLS একদম backend পর্যন্ত pass করতে চান (LB plaintext না দেখেই end-to-end encryption)

L7 ব্যবহার করুন যখন:

• path-based বা host-based routing দরকার
• আপনি load balancer-এ TLS termination চান (সহজ cert management)
• header যোগ/পরিবর্তন করতে হবে
• per-request metric দরকার (শুধু connection count নয়)
• আপনি microservice বানাচ্ছেন যেখানে ভিন্ন ভিন্ন path ভিন্ন ভিন্ন service-এ যায়

বাস্তবে: বেশিরভাগ web application L7 ব্যবহার করে। L4 edge-এ দেখা যায় (data center-এ AWS NLB বা hardware load balancer) যেটা traffic-কে application-এর কাছাকাছি থাকা L7-এ (nginx বা HAProxy) পাঠায়।

PROXY Protocol

L4 balancer আসল client IP লুকিয়ে ফেলে — backend, balancer-এর IP দেখে। PROXY protocol এটার সমাধান করে TCP stream-এর আগে connection metadata যোগ করে দিয়ে:

PROXY TCP4 192.168.0.1 10.0.0.1 56324 443\r\n

HAProxy-তে enable করুন:

backend api_servers
    server api1 10.0.0.10:3000 send-proxy check

Backend-কে এটা parse করার জন্য configure করুন:

server {
    listen 3000 proxy_protocol;
    set_real_ip_from 10.0.0.0/8;
    real_ip_header proxy_protocol;
}

এখন backend X-Real-IP আর access log-এ আসল client IP দেখতে পায়।