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 দেখতে পায়।