HTTP/1.0 থেকে HTTP/3, আর অন্যান্য Application Protocol

এই Lesson শেষে তুমি পারবে

• প্রতিটা HTTP Version কী বদলাল আর কেন, সেটা বোঝাতে: প্রতি Request-এ নতুন Connection (১.০), Persistent Connection, Host আর Chunking (১.১), Binary Framing আর Multiplexing (২), QUIC Stream (৩)।
• চারটা Version-এর মধ্য দিয়ে Head-of-line Blocking-কে অনুসরণ করতে, আর ঠিক বলতে কোন Version কোন ধরনের Blocking সরাল আর কোনটা থেকে গেল।
• Interview-এ যা জিজ্ঞেস করে, HTTP/2-এর সেই ভেতরের কথা বলতে: Frame, Stream, প্রতি Stream-এর Flow Control, HPACK, Priority, Connection Coalescing, GOAWAY।
• QUIC-এর ওপর HTTP/3 কী যোগ করে বোঝাতে: QPACK, 0-RTT আর তার Replay-এর ঝুঁকি, Connection Migration, Alt-Svc আর DNS HTTPS Record দিয়ে খুঁজে পাওয়া, আর UDP বন্ধ থাকলে Fallback।
• Client আর Server কীভাবে Version-এ একমত হয় (ALPN), Server Push কেন মরল আর তার জায়গায় 103 Early Hints কী করে, সেটা বলতে।
• অন্য Application Protocol-এর মাঝে HTTP-কে বসাতে: Port, Email-এর পথ (Submission, MX, Relay, IMAP) আর SPF/DKIM/DMARC, SSH বনাম Telnet, FTP বনাম SFTP, NTP, SNMP, TLS/HTTPS-এর ওপর DNS।
• এসব থেকে Design-এর সিদ্ধান্ত নিতে: কোন ধাপে কোন Version, দীর্ঘজীবী Connection-এর Load Balancing, আর প্রতিটা Version-এর সাথে আসা ব্যর্থতা।

#এই Lesson কোথায় বসে

Web-এর সব যোগাযোগের মূল ভিত্তি হলো HTTP (Hypertext Transfer Protocol)। এটা Application Layer-এর (Layer 7) একটা Protocol, যেটা ঠিক করে Client, মানে সাধারণত Browser বা কোনো App, Server-এর সাথে কীভাবে তথ্য আদান-প্রদান করবে। Web Application-কে দ্রুত, নিরাপদ আর দক্ষ বানাতে চাইলে বুঝতে হবে HTTP কীভাবে বদলেছে, তারপর তার Method, Status Code, Header, Caching আর Compression। এই Lesson-এ বিবর্তনের গল্প; বাকিটা পরের তিন Lesson-এ:

• Lesson ২.২: Method আর Status Code।
• Lesson ২.৩: Header, Keep-alive-এর Setting, Compression আর CORS।
• Lesson ২.৪: Caching।

নিচের টুকরোগুলো তুমি আগেই জানো। Lesson ১.১-এ দেখেছ HTTP Message দেখতে কেমন, আর Version-গুলোর প্রথম একটা তালিকা। Lesson ১.৯-এ শিখেছ TCP, TLS 1.3, 0-RTT আর QUIC, আর Lesson ১.১০-এ দেখেছ নতুন TCP Connection কেন ধীর (Handshake, তার ওপর Slow Start)। সেগুলো আবার পড়াব না; এখানে দেখব প্রতিটা HTTP Version ওগুলোকে কীভাবে কাজে লাগায়।

পুরো ইতিহাসে একটা কথা বারবার ফিরে আসে: HTTP-র মানে কখনো বদলায়নি, বদলেছে শুধু তারের ওপর তার চেহারা। Accept: application/json সহ একটা GET /cart, উত্তরে 200 OK, এর মানে HTTP/1.0-তে যা, HTTP/3-তেও তাই। ২০২২ সালে IETF এই হিসেবেই Standard ভাগ করেছে: RFC 9110 একবারই মানে (Semantics) লিখে দেয়, আর RFC 9112, 9113 আর 9114 বলে HTTP/1.1, HTTP/2 আর HTTP/3 সেটা কীভাবে বয়ে নেয়। ১৯৯৬ থেকে প্রতিটা Version আসলে একই দুটো প্রশ্নের উত্তর: নতুন Connection-এর দাম কীভাবে এড়ানো যায়, আর একটা ধীর বা হারানো জিনিস যেন বাকি সবাইকে আটকে না দেয়, সেটা কীভাবে করা যায়?

#HTTP/1.0: এক Request, এক Connection

HTTP/1.0-এর আগে ছিল HTTP/0.9 (১৯৯১): এক লাইন, GET /page.html, আর Server কাঁচা HTML পাঠিয়ে লাইন কেটে দিত। Header নেই, Status Code নেই, Image নেই। HTTP/1.0 (RFC 1945, ১৯৯৬) লিখে রাখল Browser আর Server ততদিনে যা করতে শিখেছিল: Version সহ Request Line, Header, Status Code, Content-Type, যাতে Response শুধু HTML না, Image-ও হতে পারে।

দুর্বল জায়গা ছিল তার Connection মডেল। প্রতিটা Resource-এর (HTML, প্রতিটা CSS File, প্রতিটা Image) জন্য নতুন একটা TCP Connection, আর Response-এর পর Server সেটা বন্ধ করে দিত। বন্ধ করাটা শুধু গোছানোর ব্যাপার ছিল না: দৈর্ঘ্যের Header না থাকলে Connection বন্ধ হওয়া দেখেই Client বুঝত Body শেষ।

Browser এর সাথে লড়েছিল একসাথে কয়েকটা Connection খুলে (তখন দুই থেকে চারটা), আর কিছু Server একটা অনানুষ্ঠানিক Extension বুঝত: Client পাঠাত Connection: keep-alive, Server রাজি থাকলে Connection খোলা রাখত। HTTP/1.1-এর বীজ এই Extension-টাই।

#HTTP/1.1: Persistent Connection আর তার সীমা

HTTP/1.1 (১৯৯৭-এ RFC 2068, ১৯৯৯-এ সংশোধিত, ২০২২-এ আবার RFC 9112 হিসেবে) এখনো সবখানে: curl-এ, Load Balancer আর Backend-এর মাঝে, অগণিত API-তে। এর পাঁচটা বদল গুরুত্বপূর্ণ।

#Default-ভাবেই Persistent

Response-এর পরেও Connection খোলা থাকে, আর পরের Request সেটাই আবার ব্যবহার করে, নতুন Handshake ছাড়া, TCP-র Congestion Window আগে থেকেই গরম অবস্থায়। Persistence হলো Default; শুধু Connection: close এটা শেষ করে। (তাই “Keep-alive এনেছে HTTP/1.1” কথাটা পুরো ঠিক না: HTTP/1.0-এ এটা ছিল চাইলে চালু করার একটা Extension; HTTP/1.1 এটাকে নিয়ম বানিয়েছে।)

পরের Response খুঁজে পেতে প্রতিটা Response-কে বলতে হয় তার Body কোথায় শেষ: হয় Content-Length, নয় Chunked Encoding (নিচে)। অনেকক্ষণ অলস পড়ে থাকা Connection Server বন্ধ করে দেয় (প্রায়ই ৫ থেকে ৭৫ সেকেন্ড পরে), Memory বাঁচাতে। Keep-alive-এর Header আর Timeout-এর খুঁটিনাটি Lesson ২.৩-এ।

#Pipelining, আর সেটা কেন ব্যর্থ হলো

HTTP/1.1 Pipelining-ও অনুমোদন দিয়েছিল: Response 1-এর অপেক্ষা না করেই Client Request 2 আর 3 পাঠায়। শুনতে Multiplexing-এর মতো, কিন্তু HTTP/1.1-এর Message-এ কোনো Request ID নেই। কোন Response কোন Request-এর, মেলানোর একমাত্র উপায় ক্রম, তাই Request যে ক্রমে এসেছে Server-কে ঠিক সেই ক্রমেই উত্তর দিতে হয়। Request 1 ধীর হলে (একটা Database Query, একটা বড় File), Response 2 আর 3 এক Millisecond-এ তৈরি হলেও তার পেছনে অপেক্ষা করে। এটাই HTTP পর্যায়ের Head-of-line (HoL) Blocking।

তার ওপর অনেক Proxy আর Server Pipeline করা Request ঠিকমতো সামলাতে পারত না, আর Connection ভেঙে গেলে Pipeline করা একটা Non-idempotent Request নিরাপদে আবার পাঠানোও যায় না। তাই কোনো বড় Browser কখনো Default-ভাবে Pipelining চালু করেনি। বাস্তবে HTTP/1.1 মানে প্রতি Connection-এ একবারে একটা Request, আর তাতে প্রতিটা Connection-এ একই আটকে যাওয়া ঘটে।

#ছয়টা Connection, আর তার থেকে জন্মানো কৌশল

তবু একসাথে আনতে Browser এক Host-এ সর্বোচ্চ ছয়টা Connection খোলে। প্রত্যেকটা নিজের Handshake আর Slow Start-এর দাম দেয়, আর ৮০টা File-এর Page-এর জন্য ছয়টা তবুও কম। Web Developer-রা কিছু কৌশল বের করেছিল, যেগুলো পুরোনো Code-এ এখনো পাবে:

#Host Header আর Virtual Hosting

HTTP/1.1 Host Header বাধ্যতামূলক করেছে: Host: shop.example.com। এতে একটা IP Address অনেক Domain চালাতে পারে (নামভিত্তিক Virtual Hosting): Server Host পড়ে ঠিক Site-টা বেছে নেয়। এটা না থাকলে প্রতিটা Website-এর আলাদা IPv4 Address লাগত, যেটা পৃথিবী কখনো জোগাতে পারত না। Host ছাড়া Request পায় 400 Bad Request। HTTPS-এ নামটা আরও আগে যায়, TLS ClientHello-তে SNI হিসেবে, যাতে কোনো HTTP পড়ার আগেই Server ঠিক Certificate বাছতে পারে। HTTP/2 আর HTTP/3 একই মান বয়ে নেয় :authority Pseudo-header হিসেবে।

#Chunked Transfer Encoding

Server যখন এমন কিছু Stream করে যার মাপ এখনো জানে না (সারি ধরে ধরে বানানো Report, Server-এ আঁকা Page, একটা AI উত্তর), তখন সে Content-Length দিতে পারে না। HTTP/1.1 যোগ করেছে Transfer-Encoding: chunked: প্রতিটা Chunk-এর আগে Hexadecimal-এ তার মাপ, আর একটা শূন্য মাপের Chunk Body শেষ করে, চাইলে তারপর Trailer Header। এরপরেও Connection ব্যবহারযোগ্য থাকে।

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

1a
first twenty-six bytes....
400
…1024 more bytes…
0

HTTP/1.1 আরও এনেছে 100 Continue (বড় Body Upload করার আগে জিজ্ঞেস করে নেওয়া), Range Request (Download আবার চালু করা, Video-তে লাফ দেওয়া) আর Cache-Control ও ETag সহ পূর্ণ একটা Caching মডেল (Lesson ২.৪)।

#Production-এ HTTP/1.1 কোথায় ভোগায়

• Keep-alive-এর দৌড়। Backend যে মুহূর্তে অলস Connection বন্ধ করছে, ঠিক তখনই Load Balancer Pool থেকে সেটা আবার ব্যবহার করে, আর User পায় এলোমেলো একটা 502। নিয়ম: Backend-এর Keep-alive Timeout Proxy-র Idle Timeout-এর চেয়ে বড় রাখো।
• Request Smuggling। Text Protocol-এ Body কোথায় শেষ, সেটা বলার একাধিক উপায় আছে (Content-Length, Transfer-Encoding)। সামনের Proxy আর Backend দ্বিমত করলে Attacker প্রথম Request-এর ভেতরে দ্বিতীয় একটা লুকিয়ে ফেলে। সমাধান: দুটো Header একসাথে থাকলে বাতিল করো, Edge-এ এক নিয়মে আনো, Backend-এর সাথে HTTP/2 বলো।
• প্রতি Connection-এ Head-of-line Blocking, যার চাপে Client অনেক Connection খোলে, আর তাতে Server-এর Memory আর File Descriptor খরচ হয়।

#HTTP/2: এক Connection, অনেক Stream

HTTP/2 (২০১৫-তে RFC 7540, এখন RFC 9113) এসেছে Google-এর SPDY পরীক্ষা থেকে। এটা প্রতিটা Method, Status Code আর Header রেখে দেয়, বদলায় শুধু তারের ওপরের Text চেহারা।

#Binary Framing

HTTP/2-এর Message কেটে বানানো হয় Binary Frame। প্রতিটা Frame শুরু হয় একই রকম ৯ Byte-এর Header দিয়ে:

+-----------------------------------------------+
|                 Length (24 bits)              |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31 bits)                 |
+=+=============================================================+
|                   Frame Payload (0 … Length bytes)            |
+---------------------------------------------------------------+

Binary Framing পড়তে দ্রুত আর দ্ব্যর্থহীন: প্রতিটা Frame নিজের দৈর্ঘ্য বলে দেয়, তাই Message কোথায় শেষ তা আন্দাজ করতে হয় না, আর পরস্পরবিরোধী দৈর্ঘ্যের Header দিয়ে Smuggling-ও চলে না। দাম হলো, telnet দিয়ে Protocol আর পড়া যায় না; লাগে curl -v, nghttp বা Wireshark।

#Stream আর Multiplexing

একটা Stream হলো একটা Request/Response আদান-প্রদান, নম্বর দেওয়া: Client-এর খোলা Stream বিজোড় (১, ৩, ৫…), Server-এর খোলা জোড়, আর 0 মানে পুরো Connection। আলাদা Stream-এর Frame একটা TCP Connection-এ মিশে মিশে চলে, আর প্রতিটা Frame নিজের Stream-এর নাম বলে বলে Stream-গুলোর মধ্যে ক্রম লাগে না। এতে HTTP পর্যায়ের Head-of-line Blocking চলে যায়: ধীর একটা Response আর দ্রুতগুলোকে আটকায় না।

Design-এর জন্য যা গুরুত্বপূর্ণ:

• প্রতি Origin-এ একটা Connection-ই যথেষ্ট। একটাই Handshake, আর ছয়টা ঠান্ডা Congestion Window-এর বদলে একটা ভালোমতো গরম Window।
• Server একসাথে কতগুলো Stream চলবে তার সীমা দেয় (SETTINGS_MAX_CONCURRENT_STREAMS, প্রায়ই ১০০ থেকে ২৫০)। বাড়তি Request Client-এর দিকে লাইনে দাঁড়ায়।
• বাতিল করা সস্তা: RST_STREAM একটা Response থামায়। HTTP/1.1-এ পুরো Connection বন্ধ করতে হতো।

#প্রতি Stream-এর Flow Control

TCP-র তো Flow Control আছেই, তবে আরেকটা স্তর কেন? কারণ অনেক Stream একটা TCP Connection ভাগ করে: Video Player যদি Stream 9 পড়া বন্ধ করে, TCP-র Receive Window ভরে যাবে আর সব Stream থেমে যাবে। তাই HTTP/2 প্রতিটা Stream আর পুরো Connection-কে একটা Send Window দেয় (Default ৬৫,৫৩৫ Byte), যেটা Receiver Data খরচ করার সাথে সাথে WINDOW_UPDATE দিয়ে ভরে দেয়। Window যদি Bandwidth-delay Product-এর চেয়ে ছোট হয়, Throughput আটকে যায় (Lesson ১.১০); এজন্যই Browser কয়েক Megabyte-এর Window ঘোষণা করে, আর ৬৪ KB Default-এ ফেলে রাখা একটা Proxy বড় Download রহস্যজনকভাবে ধীর করে দিতে পারে।

#HPACK Header Compression

HTTP Header একঘেয়ে: একটা Site-এ প্রতিটা Request-এ একই :authority, user-agent, accept-* আর প্রায়ই বড় একটা cookie। ৮০টা Request-এর Page-এ সেটা কয়েক দশ Kilobyte একই Text, যায় Upload-এর দিকে, যেখানে Bandwidth সবচেয়ে কম আর শুরুর Congestion Window মাত্র ১০টা Segment। HPACK (RFC 7541) তিনটা উপায়ে এদের চাপে:

1. ৬১টা প্রচলিত Header-এর একটা Static Table (:method: GET হলো Entry ২, :path: / Entry ৪, :status: 200 Entry ৮)। মিলে গেলে খরচ এক Byte।
2. Connection নিজেই যে Dynamic Table বানায়: নতুন একটা Header Literal হিসেবে গেলে দুই পাশই সেটা যোগ করে রাখে। পরের বার সেটা এক Byte। Table-টা FIFO, মাপের সীমা আছে (Default ৪,০৯৬ Byte; প্রতিটা Entry-র খরচ নাম + মান + ৩২ Byte), আর সবচেয়ে পুরোনোগুলো বের করে দেওয়া হয়।
3. Literal String-এর জন্য Huffman Coding, যেটা মোটামুটি ২০–৩০% বাঁচায়।

HPACK বানানো হয়েছে ২০১২ সালের সেই হামলার পরে, যেখানে একটা গোপন মানের পাশে Attacker-এর দেওয়া Text কতটা ভালো চাপা যায় দেখে Cookie বের করে ফেলা হতো (এ কারণেই TLS আর SPDY Compression বন্ধ করা হয়েছিল)। HPACK শুধু পুরো Header মান মেলায়, আর একটা Never-indexed Flag authorization-এর মতো গোপন মানকে পথের সব Table-এর বাইরে রাখে। Server-কে Decode করা Header-এর মাপেও সীমা রাখতে হয় (SETTINGS_MAX_HEADER_LIST_SIZE), কারণ ছোট একটা চাপা Block ফুলে Megabyte হয়ে যেতে পারে।

#Priority: Dependency Tree থেকে RFC 9218

সব যখন একটা Connection-এ, Server-কে ঠিক করতে হয় কোনটা আগে পাঠাবে: Page আঁকা আটকে রাখা CSS আগে, নিচের দিকের একটা Photo পরে। HTTP/2 এনেছিল Weight সহ জটিল একটা Dependency Tree। খুব কম Server এটা ঠিকমতো বানিয়েছিল, আর প্রতিটা Browser আলাদা আলাদা Tree বানাত, তাই RFC 9113 এটা বাতিল করেছে। তার জায়গায় Extensible Priorities (RFC 9218) সহজ, আর HTTP/3-তেও চলে: একটা Priority Header (আর একটা PRIORITY_UPDATE Frame), যেখানে ০ (সবচেয়ে জরুরি) থেকে ৭ পর্যন্ত একটা Urgency (Default ৩) আর ধাপে ধাপে দেখানো Image-এর মতো জিনিসের জন্য একটা Incremental Flag, যেমন CSS-এর জন্য Priority: u=0 আর একটা Image-এর জন্য Priority: u=5, i।

#Connection Coalescing

www.example.com আর static.example.com যদি একই IP Address-এ Resolve হয় আর Server-এর Certificate দুটো নামই ঢাকে, তাহলে Browser দুটোর Request-ই একটা HTTP/2 Connection-এ পাঠাতে পারে। এটাই Connection Coalescing: বিনা খরচে Domain Sharding-কে উল্টে দেয়। গোলমাল হলে (দুটো নাম একই IP আর একটা Wildcard Certificate ভাগ করে, কিন্তু চালায় আলাদা Backend), Server উত্তর দেয় 421 Misdirected Request, আর Browser আলাদা একটা Connection খোলে।

#TLS: Browser-এর শর্ত, Standard-এর না

নোটে আছে HTTP/2-এ TLS বাধ্যতামূলক। Specification তা বলে না: সেখানে আছে h2 (TLS-এর ওপর) আর h2c (Cleartext)। Browser শুধু TLS-এর ওপর h2 বানিয়েছে। Cleartext h2c চলে Data Centre-এর ভেতরে, যেমন একটা Proxy আর একটা gRPC Backend-এর মাঝে, “আগে থেকে জানা” (Prior Knowledge) ভিত্তিতে: Client সোজা HTTP/2 Preface দিয়ে শুরু করে। HTTP/1.1 Connection-কে h2c-তে Upgrade করার পুরোনো পথ RFC 9113-এ বাতিল হয়েছে।

#HTTP/2 যা সারাতে পারেনি: TCP-র Head-of-line Blocking

সব Stream তবুও একটাই TCP Byte Stream-এর Byte। একটা TCP Segment হারালে TCP তার পরের সবকিছু আটকে রাখে, এমনকি সেই Stream-এর Frame-ও যাদের হারানো Data-র সাথে কোনো সম্পর্ক নেই, যতক্ষণ না আবার পাঠানো Segment আসে। পরিষ্কার Network-এ এটা চোখে পড়ে না; ১–২% Packet Loss-এ (ভিড়ের Wi-Fi, Mobile) একটা Connection প্রায় প্রতিটা Page-এ আটকে যায়, আর ছয়টা HTTP/1.1 Connection, যারা আলাদা আলাদা আটকায়, তারা আসলে দ্রুতও হতে পারে। HTTP/3 ঠিক এই সমস্যার সমাধানেই বানানো।

#HTTP/3: QUIC-এর ওপর HTTP

HTTP/3 (RFC 9114, জুন ২০২২) HTTP-কে বসায় QUIC-এর (RFC 9000, ২০২১) ওপর, সেই UDP-ভিত্তিক Transport যেটা তুমি Lesson ১.৯-এ দেখেছ। ২০১২-র দিকে Google QUIC-এর প্রথম Version বানায় আর নাম দেয় “Quick UDP Internet Connections”; IETF-এর Version আলাদা, মানক করা একটা Protocol, আর QUIC এখন শুধুই একটা নাম, কোনো Acronym না।

#QUIC HTTP-কে কী দেয়

• স্বাধীন Stream। Stream QUIC নিজেই দেয়; Data-র ক্রম রাখা হয় প্রতি Stream-এ, তাই একটা হারানো Packet শুধু সেই Stream-কে দেরি করায় যার Data সে বইছিল। TCP পর্যায়ের HoL Blocking শেষ।
• দ্রুত Setup। Transport আর TLS 1.3-এর Handshake একসাথে: নতুন Connection-এ ২-এর (TCP + TLS 1.3) বদলে ১ RTT, আর Session Ticket নিয়ে ফিরে এলে ০ RTT।
• 0-RTT-এর একটা শর্ত আছে: Replay। Early Data কেউ রেকর্ড করে আবার পাঠাতে পারে, তাই Server এটা নেয় শুধু নিরাপদ, Idempotent Request-এর জন্য, বাকিগুলো ফিরিয়ে দেয় বা 425 Too Early বলে; একটা CDN Origin-কে Early-Data: 1 জানিয়ে দেয়, যাতে Origin সিদ্ধান্ত নিতে পারে।
• Connection Migration। Connection চেনা হয় Connection ID দিয়ে, IP Address আর Port দিয়ে না, তাই Network বদলালেও টিকে থাকে।
• Encrypt করা Transport Header আর User Space-এ বানানো: মাঝের যন্ত্র একে জমিয়ে স্থির করে ফেলতে পারে না, আর নতুন Congestion Control আসে একটা Browser Update-এর সাথেই।

QUIC নিজেই Stream আর Flow Control দেয় বলে HTTP/3 HTTP/2-এর চেয়ে পাতলা: প্রতিটা Request ব্যবহার করে Client-এর খোলা একটা দ্বিমুখী QUIC Stream (ID ০, ৪, ৮…); HEADERS, DATA, SETTINGS আর GOAWAY Frame থেকে যায়, আর WINDOW_UPDATE, RST_STREAM আর PING বাদ, কারণ ওই কাজগুলো QUIC নিজেই করে।

#QPACK: Stream-এর মাঝে আটকানো ছাড়া Compression

HPACK ধরে নেয় Header Block যে ক্রমে Encode হয়েছে সেই ক্রমেই Decode হবে, যেটা TCP নিশ্চিত করত। QUIC-এর Stream যেকোনো ক্রমে আসে, তাই “Dynamic Entry 62”-এর কথা বলা একটা Request সেই Request-এর আগেই পৌঁছে যেতে পারে, যেটা Entry 62 বানিয়েছে। QPACK (RFC 9204) এটা সারায়: Table-এ যোগ করা যায় আলাদা একটা Encoder Stream-এ, প্রতিটা Header Block বলে দেয় তার কতগুলো যোগ লাগবে (তার Required Insert Count), আর অপেক্ষা করে শুধু সেই Stream, যার Entry এখনো আসেনি। কতগুলো Stream এভাবে আটকে থাকতে পারবে Decoder সেটা সীমিত করে (SETTINGS_QPACK_BLOCKED_STREAMS, Default ০), আর যে Encoder কখনো আটকাতে চায় না সে শুধু স্বীকৃত Entry বা Literal পাঠায়। এর Static Table-এ ৯৯টা Entry।

#Connection Migration

যে খুঁটিনাটির জন্য এটা কাজ করে, আর যেভাবে এটা ব্যর্থ হয়:

• পথ যাচাই। নতুন Address-কে বিশ্বাস করার আগে Server পাঠায় PATH_CHALLENGE আর অপেক্ষা করে PATH_RESPONSE-এর, আর ততক্ষণ যা পেয়েছে তার তিনগুণের বেশি পাঠায় না, যাতে কেউ Migration দিয়ে Traffic কোনো নিরীহ লোকের দিকে তাক করতে না পারে।
• প্রতিটা পথে নতুন Connection ID, আগেভাগে দেওয়া, যাতে বাইরের কেউ তোমার Wi-Fi আর Mobile-এর Traffic মিলিয়ে ফেলতে না পারে।
• NAT Rebinding, মানে কিছুক্ষণ চুপ থাকার পর বাসার Router চুপচাপ তোমার Public Port বদলে দেওয়া, একইভাবে সামলানো হয়। TCP-র জন্য এটা মারাত্মক।
• Load Balancer-কে Connection ID দেখে Route করতে হয়, Address-এর ৪-tuple দেখে না। Server নিজের ID লিখে দেয় তার দেওয়া Connection ID-র ভেতরে (QUIC-LB-এর ধারণা); যে Load Balancer ৪-tuple Hash করে, সে সরে যাওয়া Connection-কে এমন Server-এ পাঠায় যে তাকে চেনে না, আর সে উত্তর দেয় একটা Stateless Reset দিয়ে।
• নিজে থেকে সরে শুধু Client, আর Server চাইলে এটা নিষেধও করতে পারে।

#HTTP/3 খুঁজে পাওয়া: Alt-Svc আর HTTPS Record

Browser সব Site-এ UDP চেষ্টা করে দেখতে পারে না, তাই তাকে জানতে হয় যে HTTP/3 আছে:

1. Alt-Svc। প্রথম ভিজিট হয় TCP-তে (HTTP/2), আর Response-এ থাকে Alt-Svc: h3=":443"; ma=86400: “এই Origin UDP 443-এ HTTP/3-ও বলে, একদিন মনে রেখো।” পরের Connection হয় HTTP/3-তে।
2. DNS HTTPS Record (Type 65, RFC 9460)। Site প্রকাশ করে example.com. HTTPS 1 . alpn="h3,h2" ipv4hint=…; Browser A/AAAA-র সাথে সমান্তরালে এটা চায়, তাই প্রথম ভিজিটও HTTP/3 হতে পারে (এই Record Encrypted Client Hello-র Key-ও বইতে পারে)।

আর যখন UDP বন্ধ (অনেক অফিস আর হোটেলের Network UDP 443 ফেলে দেয়), Browser Timeout-এর অপেক্ষা করে না: সে একটা TCP Connection-এর সাথে দৌড় করায়, HTTP/2 ব্যবহার করে, আর কিছুক্ষণের জন্য ওই Network-এ HTTP/3-কে নষ্ট বলে চিহ্নিত করে। তাই প্রতিটা HTTP/3 Deployment TCP-র ওপর HTTP/2 আর HTTP/1.1-ও চালু রাখে।

#HTTP/3-এর দাম

HTTP/3 বিনা পয়সায় আসে না। User Space-এ প্রতিটা Packet Encrypt আর Acknowledge করতে, Hardware Offload সহ Kernel-এর TCP-র চেয়ে প্রতি Byte-এ বেশি CPU লাগে (Batching আর Segmentation Offload দিয়ে ফারাকটা কমেছে)। কিছু Network UDP-র গতি সীমিত করে বা বন্ধ রাখে। Load Balancer, Firewall আর DDoS সুরক্ষাকে QUIC বুঝতে হয়। পর্যবেক্ষণ কঠিন, কারণ যে Header আগে তারে পড়া যেত সেগুলো এখন Encrypt করা। আর Latency-র লাভ সত্যি, কিন্তু সীমিত: HTTP/3 Handshake-এর Round Trip আর Loss-এর আটকে যাওয়া বাঁচায়; User আর Server-এর মাঝে আলোর গতিকে হারাতে পারে না, তাই “HTTP/3 Latency প্রায় শূন্যে নামিয়ে আনে” (নোটের একটা কথা) বাড়িয়ে বলা। লাভ সবচেয়ে বেশি দেরি আর Loss-ওয়ালা Network-এ: Server থেকে দূরের Mobile User।

#Version বাছাই: ALPN

TCP Port 443-এ প্রথম কয়েকটা Byte-এর আগে HTTP/1.1 আর HTTP/2 দেখতে একই রকম, তাই Version ঠিক হয় TLS Handshake-এর ভেতরে, ALPN (Application-Layer Protocol Negotiation) দিয়ে:

1. ClientHello পছন্দের ক্রমে Protocol-এর তালিকা দেয়: h2, http/1.1।
2. Server একটা বেছে ফেরত পাঠায় (TLS 1.3-এ তার উত্তরের Encrypt করা অংশে)।
3. উত্তর না থাকলে HTTP/1.1। প্রস্তাবিত কোনোটাই Server না বুঝলে সে no_application_protocol Alert দিয়ে থামিয়ে দিতে পারে।

এতে বাড়তি কোনো Round Trip লাগে না। HTTP/3 চেনা যায় QUIC Handshake-এর ভেতরে ALPN h3 দিয়ে। কাজের কিছু ফলাফল:

• প্রতিটা ধাপ আলাদা দর-কষাকষি করে। Browser → CDN হতে পারে HTTP/3, CDN → Load Balancer HTTP/2, Load Balancer → Backend HTTP/1.1। Browser-এ যে Version দেখছ, তাতে Backend সম্পর্কে কিছুই বোঝা যায় না।
• gRPC-র HTTP/2 লাগবেই। যে TLS-শেষ-করা Proxy Backend-এর সাথে শুধু HTTP/1.1 বলে, বা Client-কে h2 প্রস্তাব করে না, সে gRPC ভেঙে দেয়, অথচ Web Browsing চলতেই থাকে।
• Cleartext HTTP/2 (h2c)-এ TLS নেই, তাই ALPN-ও নেই; Private Network-এর ভেতরে আগে থেকে জেনে এটা ব্যবহার হয়।

#Server Push, আর সেটা কেন মরল

HTTP/2 Server-কে এমন Response ঠেলে দিতে (Push) দিত, যা Client এখনো চায়নি: index.html পাঠাও, আর একটা PUSH_PROMISE দিয়ে সাথে style.css-ও, এক Round Trip বাঁচাতে। বাস্তবে এটা ব্যর্থ হলো:

• Browser-এর Cache-এ কী আছে, Server জানতে পারে না। Cache-এ থাকা File ঠেলে দিলে যে Bandwidth HTML-এর দরকার ছিল সেটা নষ্ট হয়।
• Browser যখন RST_STREAM দিয়ে বাতিল করে, ততক্ষণে বেশিরভাগ Byte রাস্তায়।
• Configure করা কঠিন ছিল, Priority-র সাথে খারাপভাবে জড়াত, আর মেপে দেখা গেছে কালেভদ্রে কাজে লাগে।

Chrome ২০২২-এ (Version 106) Push সরিয়ে দিয়েছে, Firefox ২০২৪-এ, Nginx-এর মতো Server তাদের সমর্থন তুলে নিয়েছে, আর HTTP/3-এর Push কোনো Browser কখনো বানায়নি। (নোটে Push এখনো HTTP/2-এর একটা Feature হিসেবে আছে; কার্যত এটা মৃত।)

যা এর জায়গা নিয়েছে, সেটা সিদ্ধান্তের ভার আবার Browser-কে ফিরিয়ে দেয়:

• preload আর preconnect ইঙ্গিত (<link rel="preload" href="/style.css" as="style">) Browser-কে আগেভাগে জানায় কী লাগবে; Browser আগে নিজের Cache দেখে নেয়।
• 103 Early Hints (RFC 8297) এই ইঙ্গিত পাঠায় আসল Response-এর আগেই: Origin যখন ৪০০ ms ধরে Page বানাচ্ছে, CDN সাথে সাথে Link: </style.css>; rel=preload সহ 103 দিয়ে উত্তর দেয়, আর Browser অলস সময়টা কাজে লাগিয়ে CSS আনে আর Connection খোলে। বিভিন্ন Site Largest Contentful Paint-এ কয়েকশো Millisecond কমার কথা জানিয়েছে। Browser এতে সাড়া দেয় HTTP/2 আর HTTP/3-এ; উপেক্ষিত বা অব্যবহৃত হলে কিছুই ভাঙে না।

#চার Version পাশাপাশি

#আজ কতটা চলে

২০২৬-এ প্রতিটা বড় Browser HTTP/2 আর HTTP/3 সমর্থন করে, আর বড় CDN-গুলো (Cloudflare, Google, Akamai, Fastly, CloudFront) HTTP/3 দেয় Default-ভাবে বা এক Switch-এ। Cloudflare Radar আর HTTP Archive-এর মতো প্রকাশ্য মাপ বছরের পর বছর একই মোটা ছবি দেখায়: Browser Traffic-এর সবচেয়ে বড় ভাগ HTTP/2-এর, HTTP/3-এর বড় আর বাড়তে থাকা একটা অংশ (মোটামুটি পাঁচ ভাগের এক থেকে তিন ভাগের এক Request), আর HTTP/1.1 মূলত Bot, Script, API Client, পুরোনো যন্ত্র আর Server থেকে Server-এর ধাপ। ঠিক ভাগগুলো প্রতি বছর নড়ে, তাই সংখ্যা লাগলে ওই উৎসগুলো দেখে নিও। Edge-এর পেছনে ছবিটা আলাদা: CDN থেকে Origin আর Load Balancer থেকে Backend-এর ধাপ এখনো প্রায়ই HTTP/1.1, আর ভেতরের Service-এর ডাক HTTP/2 (gRPC)।

#System Design-এ HTTP Version

• Edge-এ সবচেয়ে নতুন Version শেষ করো। Mobile আর Wi-Fi-র User সবচেয়ে বেশি লাভ পায় HTTP/3 আর HTTP/2 থেকে; CDN বা Load Balancer-এ এগুলো চালু করো, আর Fallback-এর জন্য TCP রেখে দাও।
• Backend-এর Protocol আলাদা করে বাছো। অনেক Backend-এর জন্য Keep-alive Pool সহ HTTP/1.1 যথেষ্ট; একটা Client যখন একসাথে অনেক Request পাঠায় (gRPC, API Gateway), তখন HTTP/2 কাজে দেয়, আর Request Smuggling-এর বিরুদ্ধেও বেশি নিরাপদ।
• দীর্ঘজীবী HTTP/2 Connection Connection-ভিত্তিক Load Balancing অকেজো করে দেয়। Layer 4-এর Balancer ছড়ায় Connection; একটা HTTP/2 Client ঘণ্টার পর ঘণ্টা তার সব Traffic একটা Connection দিয়ে একটা Backend-এ পাঠাতে পারে। gRPC-র জন্য Layer 7-এর (Request ধরে) Balancer ব্যবহার করো, Connection-এর বয়সে সীমা দাও, আর GOAWAY দিয়ে খালি করো।
• সীমাগুলোর দিকে চোখ রাখো। SETTINGS_MAX_CONCURRENT_STREAMS Client-এর দিকে Request লাইনে দাঁড় করায়; ছোট Flow-control Window লম্বা পথে Throughput আটকায়; Idle Timeout-এর ক্রম ঠিক রাখতে হয় (Client < Load Balancer < Backend Keep-alive)।
• HTTP/2-তে যাওয়ার পর HTTP/1.1-এর কৌশল সরাও: Domain Sharding আর বিশাল Bundle এখন ক্ষতি করে।
• Protocol পর্যায়ের অপব্যবহার থেকে বাঁচো। HTTP/2-এর “Rapid Reset” হামলা (অক্টোবর ২০২৩, Google-এর বিরুদ্ধে সেকেন্ডে রেকর্ড ৩৯.৮ কোটি Request) সস্তায় Stream বাতিলের সুযোগ নিয়েছিল; Server Update রাখো, আর প্রতি Connection-এ Reset আর Stream-এর সীমা দাও।
• নিজের Infrastructure-এ QUIC-এর পরিকল্পনা করো: Firewall আর Security Group-এ UDP 443 খোলা, Migration চাইলে Connection ID দেখে Route করা Load Balancer, আর এমন Metric যা Packet পড়ার ওপর নির্ভর করে না।

#অন্য Application Protocol-এর মাঝে HTTP

HTTP অনেক Application Layer Protocol-এর একটা। Application Layer হলো OSI মডেলের সপ্তম আর সবচেয়ে ওপরের Layer, User-এর সবচেয়ে কাছের: এটা Application-কে Network Service দেয়। তুমি যখন Website দেখো, Email পাঠাও, File নামাও, একটা নাম খোঁজো বা দূরের Server-এ Login করো, তখন কাজটা করে কোনো একটা Application Layer Protocol। একটা জরুরি কথা: Application Layer মানে Application Software নিজে না (Chrome না, Outlook না), বরং ওই Program-গুলো Network-এ কথা বলতে যেসব Protocol আর Service ব্যবহার করে। এর Data-র একক (PDU)-কে সোজা বলা হয় Data বা Message।

এই Layer যা দেয়, আর কোন Protocol কোন কাজ করে:

#যে Port-গুলো জানা দরকার

#DNS আর DHCP, সংক্ষেপে

দুটোই অধ্যায় ১-এ পড়ানো হয়েছে, তাই এখানে শুধু সারকথা। DNS www.google.com-এর মতো একটা Domain Name-কে IP Address-এ Resolve করে, সাধারণত UDP 53-এ, আর বড় Response ও Zone Transfer-এর জন্য TCP 53-এ; এর Record-এর ধরন (A, AAAA, CNAME, MX, NS, TXT, PTR, SOA, SRV) আর Caching আছে Lesson ১.৮-এ। নোটে যা নেই: DNS Encrypt-ও করা যায়, TLS-এর ওপর DNS (DoT, TCP 853), HTTPS-এর ওপর DNS (DoH, 443) আর QUIC-এর ওপর DNS (DoQ, UDP 853) হিসেবে। DHCP একটা যন্ত্রকে দেয় তার IP Address, Subnet Mask, Default Gateway, DNS Server আর Lease Time, চারটা DORA ধাপে (Discover, Offer, Request, Acknowledge), UDP 67/68-এ; দেখো Lesson ১.৬।

#Email: SMTP, IMAP আর POP3

Email-এ লাগে তিনটা Protocol আর DNS, আর নামের চেয়ে কার কী ভূমিকা সেটাই বেশি জরুরি:

1. Submission (জমা দেওয়া)। Alice-এর Mail App (MUA, Mail User Agent) Message-টা দেয় তার নিজের Provider-এর Submission Server-কে (MSA), Port 587-এ SMTP দিয়ে (STARTTLS-এ TLS-এ উঠে) বা 465-এ (প্রথম Byte থেকেই TLS, RFC 8314-এর পর থেকে এটাই সুপারিশ)। Submission-এ সবসময় Login লাগে।
2. Relay (পৌঁছে দেওয়া)। Provider-এর Mail Server (MTA) DNS-এ প্রাপকের Domain-এর MX Record খোঁজে, সবচেয়ে ছোট Priority নম্বরটা বাছে, আর Port 25-এ SMTP দিয়ে Server থেকে Server-এ পৌঁছায়, সুযোগ পেলে TLS সহ। SMTP হলো জমা রেখে পাঠানোর (Store-and-forward) ব্যবস্থা: যে Server 250 OK বলে সে দায়িত্ব নেয়, আর পরের ধাপ বন্ধ থাকলে Message Queue-তে অপেক্ষা করে, দিনের পর দিন আবার চেষ্টা হয়।
3. পড়া। Bob পড়ে IMAP দিয়ে (143, বা TLS সহ 993), যেটা Mail Server-এই রাখে আর Folder ও পড়া-না-পড়ার অবস্থা সব Device-এ মিলিয়ে রাখে, অথবা POP3 দিয়ে (110 / 995), যেটা নামিয়ে নেয়, সাধারণত একটা Device-এ।

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -quiet
250-smtp.example.com
EHLO laptop.example.com
AUTH PLAIN …                     (after TLS: log in)
MAIL FROM:<alice@example.com>
RCPT TO:<bob@example.net>
DATA
Subject: Hello
…
.
250 2.0.0 Ok: queued

SMTP কখনো যাচাই করেনি প্রেরক কে: যে কেউ লিখতে পারে From: ceo@example.com। DNS-এ প্রকাশ করা তিনটা ব্যবস্থা এটা সারায়, আর ২০২৪ থেকে Gmail আর Yahoo বেশি পরিমাণে পাঠানো প্রেরকদের কাছে তিনটাই চায়:

Developer-রা প্রায়ই যে দুটো জায়গায় হোঁচট খায়: বাসার ISP আর বেশিরভাগ Cloud বাইরের দিকে Port 25 বন্ধ রাখে (AWS EC2-তে Default-ভাবে), তাই Application পাঠায় Amazon SES-এর মতো কোনো Provider দিয়ে, 587/465-এ; আর MX Record ছাড়া একটা Domain থাকলে প্রেরক তার A Record-এ চলে যায়, তারপর দিনের পর দিন চেষ্টা করে, যদি না Domain-টা একটা Null MX (MX 0 .) প্রকাশ করে বলে, “আমি কোনো Mail নিই না”।

#দূর থেকে Access: Telnet না, SSH

Telnet (TCP 23) দূরের একটা Terminal দেয়, কিন্তু সবকিছু পাঠায়, Password সহ, খোলা Text-এ; পথের যে কেউ পড়ে ফেলতে পারে। এর জায়গা নিয়েছে SSH (TCP 22): Key Exchange আর Encryption, Server-এর পরিচয় প্রমাণ করা Host Key (প্রথমবার known_hosts-এ মনে রাখা, বদলালে জোরালো সতর্কতা), আর Password-এর বদলে Key Pair দিয়ে Login। একটা SSH Connection File পাঠানো (SFTP, scp), Port Forwarding আর Tunnel-ও বইতে পারে। Telnet টিকে আছে পুরোনো Network যন্ত্রে, আর “এই TCP Port কি খোলা?” দ্রুত যাচাইয়ে (telnet host 443), যেটা Lesson ১.১০-এ ব্যবহার করেছি।

#File পাঠানো: FTP, FTPS, SFTP আর SMB

FTP (১৯৭১, Port 21 আর 20) দুটো Connection ব্যবহার করে: 21-এ একটা Control Connection, আর আলাদা একটা Data Connection। Active Mode-এ Server Port 20 থেকে Client-এর দিকে ফিরে Connect করে, যেটা NAT আর Client-এর Firewall আটকে দেয়; Passive Mode-এ Client Connect করে Server-এর জানানো বড় নম্বরের একটা Port-এ, যেটা NAT পার হয় কিন্তু Server-এর Firewall-এ একটা পুরো পরিসর খুলতে বাধ্য করে। FTP-তে নিজে কোনো Encryption নেই। নিরাপদ বিকল্পগুলো আসলে আলাদা Protocol:

• FTPS হলো TLS সহ FTP (21-এ Explicit বা 990-এ Implicit): তবুও দুটো Connection, এখন Encrypt করা, তাতে Firewall আর NAT আরও কঠিন হয়।
• SFTP FTP না: এটা Port 22-এ SSH-এর ভেতরে চলা একটা File Protocol, এক Connection, Key দিয়ে যাচাই। এটাই নাও।
• SMB (TCP 445) Windows Network-এ File আর Printer ভাগ করে (Linux-এ Samba দিয়েও)। 445 কখনো Internet-এ খুলে রেখো না: পুরোনো SMB Version 1 ছিল ২০১৭-র Ransomware Worm-গুলোর ঢোকার পথ; আজ এটা Default-ভাবে বন্ধ।

Browser ২০২১-এ FTP সমর্থন তুলে নিয়েছে। নতুন System-এ File বিনিময় মানে SFTP, অথবা আরও বেশি করে, Pre-signed URL দিয়ে Object Storage-এ HTTPS Upload।

#সময় আর Monitoring: NTP আর SNMP

NTP (UDP 123) ঘড়ি মিলিয়ে রাখে। Client সময় লেখা একটা Request পাঠায়; চারটা সময় (পাঠানো, Server-এ পৌঁছানো, উত্তর দেওয়া, ফেরত পাওয়া) থেকে সে Network-এর দেরি আর নিজের ঘড়ির পার্থক্য দুটোই বের করে, তারপর লাফ না দিয়ে আস্তে আস্তে ঘড়ি ঠিক করে (Slew)। Internet-এ এটা ঘড়িকে কয়েক Millisecond-এর মধ্যে রাখে; Data Centre-এর ভেতরে আরও কাছাকাছি (Finance আর Telecom-এর জন্য PTP আরও এগিয়ে)। Server-গুলো Stratum-এ সাজানো: Stratum 1 সরাসরি একটা Atomic বা Satellite ঘড়ির সাথে যুক্ত, Stratum 2 মেলায় Stratum 1 থেকে, এভাবে চলে। System Designer-দের কেন মাথাব্যথা: ঘড়ির গরমিল TLS Certificate যাচাই (“এখনো বৈধ না”), JWT আর Cookie-র মেয়াদ, Kerberos (৫ মিনিটের ছাড়), আর কোনো সমস্যার সময় Log-এর ক্রম ভেঙে দেয়। ঘড়ির পার্থক্য Monitor করো, তোমার Cloud-এর নিজস্ব সময় Service ব্যবহার করো, আর যেখানে কোনো Attacker তোমার ঘড়ি সরাতে পারে সেখানে NTS ব্যবহার করো। (Distributed System কেন ক্রম ঠিক করতে দেয়ালঘড়ির ওপর একদমই ভরসা করতে পারে না, সেটা অধ্যায় ৩৮-এ।)

SNMP (প্রশ্নের জন্য UDP 161, Trap-এর জন্য 162) একটা Monitoring System-কে Router, Switch, Printer আর Server থেকে Counter আর অবস্থা পড়তে দেয়। মানগুলো থাকে একটা MIB-এ, আর প্রতিটার সংখ্যাভিত্তিক একটা নাম (Object Identifier)। Manager জিজ্ঞেস করে (Poll, যেমন প্রতি ৬০ সেকেন্ডে) আর Counter-এর পার্থক্য থেকে হার বের করে; কিছু ঘটলে যন্ত্র Trap পাঠায়, কিন্তু Trap হলো Acknowledgment ছাড়া UDP, হারিয়ে যেতে পারে, তাই নিরাপত্তার জাল হিসেবে Poll থেকেই যায়। SNMP Version 1 আর 2c যাচাই করে খোলা Text-এর একটা “Community String” দিয়ে (প্রায়ই public রেখে দেওয়া); Authentication আর Encryption সহ SNMPv3 ব্যবহার করো, আর এটা কখনো Internet-এ খুলে রেখো না।

#RTP: সরাসরি Media

RTP সরাসরি Audio আর Video বয়ে নেয়, সাধারণত UDP-র ওপর, Sequence Number আর Timestamp সহ, যাতে Receiver Packet সাজাতে পারে, Jitter মাপতে পারে আর মসৃণভাবে চালাতে পারে; দেরিতে আসা Packet স্রেফ বাদ যায়। RTP নিজে Call শুরু করে না: সেটা করে SIP বা WebRTC-র Signalling, আর WebRTC Media সবসময় SRTP হিসেবে Encrypt করে। WebRTC আছে Lesson ২.৬-এ।

#বাস্তব উদাহরণ: YouTube খোলা

#Application Layer-এ গোলমাল হলে

#নিজে করে দেখো

# Which HTTP version did you get? (-I: headers only)
curl -sI --http1.1 https://www.example.com | head -1     # HTTP/1.1 200 OK
curl -sI --http2   https://www.example.com | head -1     # HTTP/2 200
curl -sI --http3   https://cloudflare.com  | head -1     # HTTP/3 200 (needs a curl built with HTTP/3)

# Watch ALPN and the version in a verbose request
curl -sv -o /dev/null https://www.google.com 2>&1 | grep -Ei 'alpn|using http'

# Does the site advertise HTTP/3?
curl -sI https://www.google.com | grep -i alt-svc       # alt-svc: h3=":443"; ma=2592000
dig +short HTTPS cloudflare.com                         # 1 . alpn="h3,h2" ipv4hint=…

# ALPN by hand: offer only h2 and see what the server picks
openssl s_client -connect www.example.com:443 -alpn h2 </dev/null 2>/dev/null | grep -i alpn

# HTTP/2 frames up close (nghttp2 client)
nghttp -nv https://nghttp2.org | head -40

# Chunked response: see the raw chunk sizes
curl -s --raw --http1.1 https://httpbin.org/stream/3 | head -6

# Email: MX records, SPF/DMARC policies, and a submission server
dig +short MX gmail.com
dig +short TXT _dmarc.gmail.com
openssl s_client -starttls smtp -connect smtp.gmail.com:587 -quiet </dev/null

# Remote access and time
ssh -v user@server.example.com 2>&1 | grep -i 'host key'
chronyc tracking            # or: timedatectl timesync-status / w32tm /query /status on Windows
snmpwalk -v3 -l authPriv -u monitor -a SHA -A '…' -x AES -X '…' 192.0.2.1 IF-MIB::ifInOctets

Browser-এ Developer Tools → Network খোলো, কোনো Column-এর মাথায় Right-click করে Protocol চালু করো: প্রতিটা Request-এর পাশে দেখবে h2, h3 বা http/1.1। কয়েকবার Reload করো; অনেক Site প্রথমবার h2 দেখায়, আর তার Alt-Svc Header দেখার পরে h3। Wireshark-এ http2 Filter Decrypt করা একটা HTTP/2 Capture-এর Frame দেখায় (Wireshark-কে Decrypt করতে দিতে Browser-এ SSLKEYLOGFILE সেট করো), আর quic দেখায় QUIC Packet।

#সারসংক্ষেপ

মূল কথাগুলো

• HTTP-র মানে (Method, Status Code, Header) সব Version-এ একই; প্রতিটা Version বদলেছে শুধু তারের ওপরের চেহারা, যাতে Connection আরও ভালোভাবে আবার ব্যবহার হয় আর Head-of-line Blocking কমে।
• HTTP/1.0: প্রতি Request-এ নতুন TCP Connection, Response-এর পরে বন্ধ; ৫০টা Image মানে ৫০ বার Handshake।
• HTTP/1.1: Default-ভাবে Persistent Connection, Host Header (Virtual Hosting), Chunked Transfer, Range। Pipelining ক্রমমতো Response-এ বাধ্য করত আর কোনো Browser এটা চালু করেনি, তাই Client এক Host-এ ৬টা Connection খোলে; Keep-alive-এর দৌড় আর Request Smuggling-এর দিকে নজর রাখো।
• HTTP/2: ৯ Byte Header-ওয়ালা Binary Frame, একটা Connection-এ Multiplexed Stream, প্রতি Stream-এ Flow Control, HPACK (Static Table, Dynamic Table, Huffman), RFC 9218 Priority, Connection Coalescing, GOAWAY। HTTP পর্যায়ের HoL গেছে, TCP পর্যায়ের HoL রয়ে গেছে। TLS বাধ্যতামূলক Browser-এর জন্য, Standard-এর জন্য না (h2c)।
• QUIC-এর ওপর HTTP/3: স্বাধীন Stream, ১ RTT Setup আর ০ RTT ফিরে আসা (Replay-এর ঝুঁকি: শুধু Idempotent Request, 425 Too Early), QPACK, Connection ID দিয়ে Connection Migration (Connection ID বোঝে এমন Load Balancer লাগে)। খুঁজে পাওয়া যায় Alt-Svc বা DNS HTTPS Record দিয়ে; UDP বন্ধ থাকলে TCP-তে নেমে আসে।
• ALPN TLS Handshake-এর ভেতরেই বিনা খরচে h2 বা http/1.1 বাছে; প্রতিটা ধাপ আলাদা দর-কষাকষি করে; gRPC-র h2 লাগে।
• Server Push মৃত (Chrome ২০২২, Firefox ২০২৪); তার জায়গায় 103 Early Hints আর preload।
• অন্য Application Protocol: SMTP 587/465 Submission আর MX হয়ে 25-এ Relay, IMAP 993 / POP3 995, নকল প্রেরকের বিরুদ্ধে SPF/DKIM/DMARC; Telnet 23-এর বদলে SSH 22; FTP 21/20-এর বদলে SFTP (SSH-এর ভেতরে); NTP 123 ঘড়ি ঠিক রাখে; SNMP 161/162 যন্ত্র Monitor করে; SMB 445; UDP-র ওপর RTP; DNS Encrypt করা যায় DoT/DoH/DoQ দিয়ে।

নিজেকে যাচাই করো: HTTP Version আর Application Protocol৩৫টি প্রশ্ন