TCP, UDP, TLS ও QUIC: Connection ও নিরাপত্তা

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

• IP-এর ওপর Transport Layer কী যোগ করে তা ব্যাখ্যা করতে, এবং কোনো কাজের জন্য TCP না UDP তা বেছে নিতে।
• আসল Sequence Number দিয়ে TCP Three-Way Handshake ধাপে ধাপে বলতে, এবং SYN হারালে, Port বন্ধ থাকলে বা Server-এ Flood হলে কী ঘটে তা ব্যাখ্যা করতে।
• TCP কীভাবে Delivery নির্ভরযোগ্য করে তা ব্যাখ্যা করতে: Sequence Number, ACK, পুনঃপ্রেরণ (Timeout ও Fast Retransmit), ক্রম সাজানো, Flow Control ও Congestion Control।
• Connection কীভাবে বন্ধ হয় (FIN, TIME_WAIT, RST) এবং বড় পরিসরে Connection আবার ব্যবহার কেন জরুরি তা বলতে।
• Head-of-line Blocking ব্যাখ্যা করতে, এবং HTTP/1.1, HTTP/2 ও HTTP/3-এর পার্থক্য বলতে।
• TLS 1.3 Handshake ধাপে ধাপে বলতে, Certificate কী প্রমাণ করে তা বলতে, এবং প্রতিটি Certificate Error চিনতে।
• QUIC ও HSTS কী যোগ করে তা ব্যাখ্যা করতে, এবং প্রতিটি পদ্ধতিতে কত Round Trip লাগে তা গুনতে।

#Transport Layer কেন দরকার

DNS থেকে IP Address পাওয়ার পরও Browser-এর একটি সমস্যা থেকে যায়। IP এক মেশিন থেকে আরেক মেশিনে Packet পৌঁছায়, Best-effort ভিত্তিতে: Packet হারাতে পারে, দুবার আসতে পারে, দেরি হতে পারে বা ভিন্ন ক্রমে পৌঁছাতে পারে, আর IP কাউকে কিছু জানায় না। তাছাড়া IP শুধু মেশিন চেনে, Program নয়।

Transport Layer IP-এর ওপরে বসে দুটো সমস্যারই সমাধান করে:

• Port দিয়ে Program চেনা যায়। Server-এর Web Server 443 (HTTPS) বা 80 (HTTP) Port-এ শোনে; তোমার Browser একটি অস্থায়ী (Ephemeral) Port ব্যবহার করে, যেমন 53000। Source IP, Source Port, Destination IP, Destination Port, এই চারটি মান মিলে একটি কথোপকথন চেনায়।
• Delivery-র নিশ্চয়তা, যদি তুমি চাও। এখানেই দুটি প্রধান Protocol আলাদা:
  • TCP (Transmission Control Protocol) Sequence ঠিক রেখে নির্ভরযোগ্যভাবে ও ক্রমানুসারে Data আদান-প্রদান করে।
  • UDP (User Datagram Protocol) দ্রুত কিন্তু Connection ছাড়া এবং কোনো নিশ্চয়তা ছাড়াই Data পাঠায়। এটি QUIC-এরও ভিত্তি।

এর যেকোনোটির ওপর TLS (Transport Layer Security) Network Traffic এনক্রিপ্ট করে তথ্য সুরক্ষিত রাখে এবং Server কে তা প্রমাণ করে। HTTPS হলো আসলে TLS-এর ভেতরে চলা HTTP।

#TCP বনাম UDP

সহজ নিয়ম: যদি প্রতিটি Byte পৌঁছাতেই হবে এবং ক্রমানুসারে (Web Page, Bank Transfer, File), তাহলে TCP। যদি সম্পূর্ণ Data-র চেয়ে টাটকা Data বেশি জরুরি (Game-এ খেলোয়াড়ের অবস্থান, Voice Call-এর পরের ২০ ms), অথবা আদান-প্রদানটি একটি ছোট প্রশ্ন ও উত্তর (DNS), তাহলে UDP।

#একটি TCP Connection খোলা

Server-এর IP Address পাওয়ার পর Browser Google-এর মতো Server-এর সঙ্গে যোগাযোগের জন্য Transport Connection তৈরি করে বা আগের Connection পুনরায় ব্যবহার করে। পুনরায় ব্যবহার খুবই সাধারণ: Browser কিছুক্ষণ Connection খোলা রাখে ঠিক এই কারণে, যাতে নিচে যে প্রস্তুতির খরচ দেখবে তা বারবার দিতে না হয়।

#Three-Way Handshake

TCP-ভিত্তিক HTTPS হলে নতুন Connection তিনটি Segment দিয়ে শুরু হয়:

1. ১. SYN: Client → Server

   Client Connection শুরু করতে চায়, উদাহরণস্বরূপ Client Port 53000 থেকে Server Port 443। সে SYN (Synchronize) Flag দেয় এবং একটি এলোমেলো Initial Sequence Number (ISN) বেছে নেয়, ধরো ১০০০।

2. ২. SYN-ACK: Server → Client

   Server অনুরোধের উত্তর দেয়। সে SYN দেয় (নিজের ISN-সহ, ধরো ৫০০০) এবং ACK (Acknowledgment) দেয় ack=1001 দিয়ে: “তোমার SYN পেয়েছি; এরপর ১০০১ নম্বর Byte আশা করছি।” Client NAT-এর পেছনে থাকলে এই উত্তর আসলে Router-এর Public IP ও Mapping-করা Port-এ আসে, আর Router তা ভেতরে পাঠিয়ে দেয়।

3. ৩. ACK: Client → Server

   Client ack=5001 দিয়ে Server-এর নম্বর নিশ্চিত করে। এখন দুই দিকই Synchronized এবং TCP Connection প্রতিষ্ঠিত। কোনো Data-র আগে এতে একটি পূর্ণ Round Trip (RTT) খরচ হলো।

এরপর HTTPS Connection-এ সাধারণত TLS Handshake হয়, যা প্রয়োজনীয় নিরাপত্তা ও এনক্রিপশন ব্যবস্থা প্রতিষ্ঠা করে, এবং তবেই HTTP Request পাঠানো হয়।

তিনটি বার্তা কেন, দুটি নয়? প্রতিটি পক্ষকে নিজের শুরুর নম্বর জানাতে হয় এবং অন্য পক্ষের কাছ থেকে তার নিশ্চয়তা শুনতে হয়। Server-এর SYN আর Client-এর SYN-এর ACK একই Segment-এ একসঙ্গে যায়, তাই চারটি যৌক্তিক বার্তা তিনটি Segment-এ এঁটে যায়। এলোমেলো ISN থাকায় Attacker-এর পক্ষে নম্বর অনুমান করে অন্যের Connection-এ জাল Data ঢোকানো কঠিন।

Handshake-এর সময় দুই পক্ষ কিছু Option-ও ঠিক করে: সর্বোচ্চ Segment Size (MSS), Window Scaling (বড় Window সম্ভব করে), এবং Selective Acknowledgment (SACK) সমর্থিত কি না।

#Handshake ভুল হলে

ওপরের Animation-এর অন্য পরিস্থিতিগুলো চালিয়ে দেখো:

• SYN হারালে। Client কোনো উত্তর পায় না, প্রায় ১ সেকেন্ড অপেক্ষা করে আবার পাঠায়। প্রতিবার অপেক্ষার সময় দ্বিগুণ হয় (১, ২, ৪, ৮ সে.…), একে বলে Exponential Backoff। মোটামুটি পাঁচ-ছয়বার চেষ্টার পর OS জানায় Connection Timed Out। যে Page “কয়েক সেকেন্ড আটকে থেকে তারপর Load হয়”, তার কারণ প্রায়ই একটি হারানো SYN।
• Port বন্ধ থাকলে। মেশিন চালু কিন্তু ওই Port-এ কেউ না শুনলে তার OS SYN-এর উত্তরে RST (Reset) পাঠায়। Application সঙ্গে সঙ্গে Connection Refused পায়। আর যদি Firewall চুপচাপ SYN ফেলে দেয়, তাহলে RST আসে না, শুধু পুনঃপ্রেরণ আর শেষে Timeout। অর্থাৎ দ্রুত প্রত্যাখ্যান মানে “Host চালু, Port বন্ধ”, আর ধীর Timeout মানে “Filtered বা পৌঁছানো যায় না”।
• SYN Flood। একজন Attacker জাল Address থেকে অজস্র SYN পাঠায় এবং শেষ ACK কখনো পাঠায় না। প্রতিটি SYN Server-এর Half-open Connection Queue-তে একটি জায়গা দখল করে, আর আসল ব্যবহারকারীরা ফিরে যায়: এটি Denial of Service (DoS), অনেক মেশিন যোগ দিলে DDoS। প্রচলিত প্রতিরক্ষা হলো SYN Cookie: Server কিছুই জমা রাখে না, বরং Connection-এর তথ্য একটি গোপন Hash-সহ নিজের ISN-এর ভেতরে লিখে দেয়। শুধু যে আসল Client SYN-ACK পেয়েছে সে-ই সঠিক নম্বর ফেরত দিতে পারে। বড় সাইটগুলো Flood CDN বা Load Balancer-এও শুষে নেয়।

#নির্ভরযোগ্য Delivery: Sequence Number ও ACK

TCP প্রতিটি দিকের Data-কে একটি দীর্ঘ Byte Stream হিসেবে দেখে এবং প্রতিটি Byte-এ নম্বর দেয়। প্রতিটি Segment তার প্রথম Byte-এর নম্বর বহন করে (seq); Receiver উত্তরে পরের প্রত্যাশিত Byte-এর নম্বর পাঠায় (ack)।

ওপরের Handshake থেকে একটি হাতে-কলমে উদাহরণ (Client ISN ১০০০, Server ISN ৫০০০):

Interviewer-দের পছন্দের তিনটি খুঁটিনাটি:

• ACK ক্রমযোজিত (Cumulative)। ack=7001 ৭০০১-এর আগের সবকিছু নিশ্চিত করে, তাই একটি ACK কয়েকটি Segment ঢাকতে পারে। Packet বাঁচাতে Receiver প্রায়ই প্রতি দ্বিতীয় Segment-এ ACK দেয় (Delayed ACK)।
• Sender প্রতিটি ACK-এর অপেক্ষা করে না। সে তার Window পর্যন্ত একসঙ্গে কয়েকটি Segment পথে রাখে। প্রতিটি ACK-এর অপেক্ষা করলে ১০০ ms-এর Link হামাগুড়ি দিত।
• SYN ও FIN প্রত্যেকে এক Byte হিসেবে গোনা হয়, এজন্যই প্রথম Data Byte হলো ISN + ১।

#একটি Segment হারালে

TCP দুইভাবে হারানো টের পায়:

১. Retransmission Timeout (RTO)। Data পাঠানোর সময় Sender একটি Timer চালু করে, যা মাপা Round Trip সময় থেকে ঠিক হয় (এক RTT-এর একটু বেশি, Linux-এ অন্তত ২০০ ms)। সময়মতো ACK না এলে সে আবার পাঠায়। এটি ধীর পথ, আর TCP একে গুরুতর Congestion ধরে নেয়: Timeout দ্বিগুণ হয় এবং পাঠানোর গতি একদম নিচে নামে।

২. Fast Retransmit। Segment ২ হারালো কিন্তু Segment ৩, ৪ ও ৫ পৌঁছালো, তখন Receiver প্রতিটির উত্তরে একই ack=6001 পাঠায় (“আমি এখনো ৬০০১ চাই”)। এগুলো Duplicate ACK। তিনটি Duplicate ACK-এর পর Sender বোঝে Network চলছে কিন্তু একটি Segment নেই, এবং Timer-এর অপেক্ষা না করে সঙ্গে সঙ্গে সেটি আবার পাঠায়।

#ক্রম ভেঙে আসা ও পুনর্গঠন (Reassembly)

Internet-এ Packet ভিন্ন ভিন্ন পথে যেতে পারে, তাই কিছু না হারালেও Segment ৩ Segment ২-এর আগে পৌঁছাতে পারে। Receiver ক্রম ভেঙে আসা Segment তার Buffer-এ রাখে, Application-কে শুধু ক্রমানুসারে থাকা Byte দেয়, এবং ফাঁক পূরণ হওয়ামাত্র বাকিটা ওপরে দিয়ে দেয়। Application কখনো ক্রমভঙ্গ দেখে না। উল্টো দিকটা হলো: একটি Segment না থাকা পর্যন্ত তার পেছনের সবকিছু অপেক্ষা করে। এটা মনে রাখো; একে বলে Head-of-line Blocking।

#Response কীভাবে তোমার Browser-এ ফিরে আসে

Notes থেকে পুরো ফেরার পথ: Server উত্তর দেয়, বাসার Router Address অনুবাদ করে, তারপর TCP, TLS ও Browser প্রত্যেকে নিজের কাজ করে।

Router তার NAT Mapping-এ Port 62001 দেখে Response সঠিক Computer-এ পাঠায়। Computer-এ পৌঁছানোর পর TCP Data-কে সঠিক ক্রমে সরবরাহ করে, TLS তা Decrypt করে (এবং যাচাই করে কিছু বদলানো হয়নি), আর Browser HTTP Response Process করে Page প্রদর্শন করে।

#Flow Control ও Congestion Control

একজন দ্রুত Sender দুটি আলাদা জিনিসকে ডুবিয়ে দিতে পারে: Receiver-কে, এবং মাঝের Network-কে। TCP-তে প্রতিটির জন্য আলাদা Brake আছে।

• Flow Control (Receiver-কে রক্ষা করে)। প্রতিটি ACK একটি Receive Window (rwnd) বহন করে: Receiver-এর Buffer এই মুহূর্তে আর কত Byte নিতে পারবে। Application ধীরে পড়লে Window ছোট হয়, এমনকি শূন্য-ও হতে পারে, তখন Window আবার না খোলা পর্যন্ত Sender-কে থামতে হয় (শুধু ছোট Window Probe পাঠায়)।
• Congestion Control (Network-কে রক্ষা করে)। Sender একটি Congestion Window (cwnd)-ও রাখে, পথ কতটা বইতে পারবে সে সম্পর্কে তার নিজের অনুমান। সে cwnd ও rwnd-এর মধ্যে যেটি ছোট, তার বেশি পাঠাতে পারে না।
  • Slow Start: ছোট দিয়ে শুরু (আধুনিক Stack-এ ১০টি Segment) এবং প্রতিটি ACK-এ একটি Segment যোগ, ফলে প্রতি Round Trip-এ cwnd দ্বিগুণ। নাম যা-ই হোক, বৃদ্ধিটা Exponential।
  • Congestion Avoidance: একটি সীমায় (ssthresh) পৌঁছানোর পর প্রতি Round Trip-এ মাত্র একটি Segment বাড়ে।
  • হারালে: তিনটি Duplicate ACK-এর পর cwnd অর্ধেক করে চালিয়ে যায়; Timeout হলে একদম নিচে নেমে আবার Slow Start।

ফলাফল একটি “করাতের দাঁত”: কোনো Router-এর Queue উপচে না পড়া পর্যন্ত গতি বাড়ে, অর্ধেক হয়, আবার বাড়ে। এভাবেই লক্ষ লক্ষ Connection একই Link ন্যায্যভাবে ভাগ করে। CUBIC (Linux, Windows ও macOS-এর ডিফল্ট) ও Google-এর BBR-এর মতো আধুনিক Algorithm বক্ররেখাটি ভিন্নভাবে গড়ে, কিন্তু মূল ধারণা একই।

এসবের খুঁটিনাটি খুলে দেখানো হয়েছে Lesson ১.১০-এ: Header-এর প্রতিটা Field, Timeout কীভাবে হিসাব হয়, SACK, Zero Window আর Window Scaling, Slow Start আর AIMD-র ঠিক নিয়ম, CUBIC বনাম BBR, আর Bandwidth-delay Product।

#Connection বন্ধ করা

• স্বাভাবিক বন্ধ (FIN)। প্রতিটি দিক আলাদাভাবে বন্ধ হয়। যে পক্ষের কাজ শেষ সে FIN পাঠায়; অন্য পক্ষ তা ACK করে এবং নিজেও FIN না পাঠানো পর্যন্ত Data পাঠাতে পারে, তারপর সেটিও স্বীকৃত হয়: চারটি Segment (দ্বিতীয় FIN ACK-এর সঙ্গে গেলে প্রায়ই তিনটি)।
• TIME_WAIT। যে পক্ষ প্রথমে বন্ধ করেছে সে Connection ভুলে যাওয়ার আগে প্রায় এক মিনিট অপেক্ষা করে (সর্বোচ্চ Segment আয়ুর দ্বিগুণ; Linux-এ ৬০ সে.)। এতে যে FIN-এর ACK হারিয়েছে তার আবার ACK দেওয়া যায়, আর দেরিতে আসা পুরনো Packet একই Port-এর নতুন Connection-এর বলে ভুল হয় না।
• RST (হঠাৎ বন্ধ)। Reset FIN আদান-প্রদান ও TIME_WAIT ছাড়াই সঙ্গে সঙ্গে Connection ভেঙে দেয়; না-পাঠানো Data হারিয়ে যায়। RST দেখা যায় যখন Port বন্ধ, Application Crash বা Abort করে, Server Reboot-এর পরে (অচেনা Connection-এর Packet), এবং কিছু Firewall থেকে। Application একে Connection Reset by Peer হিসেবে জানায়।

যে ব্যস্ত Client প্রতিটি Request-এ Connection খোলে আর বন্ধ করে, তার হাজার হাজার Socket TIME_WAIT-এ জমে Local Port ফুরিয়ে যেতে পারে। প্রতিকার আগের মতোই: Connection আবার ব্যবহার করো।

#Head-of-line Blocking ও HTTP-এর Version

Head-of-line Blocking মানে একটি ধীর বা হারানো জিনিস তার পেছনে সারিতে থাকা সবকিছু আটকে দেয়, যেমন এক লেনের রাস্তায় সামনের একটি বিকল গাড়ি। এটি দুই স্তরে দেখা যায়।

Keep-alive ও Connection পুনঃব্যবহার তিনটি আধুনিক Version-এরই ভিত্তি: Handshake-এর খরচ একবার দিয়ে অনেক Request-এ ভাগ করা হয়। HTTP/2 আরও এগিয়ে প্রতি সাইটে মাত্র একটি Connection চায়, ফলে একটিই Congestion Window ঠিকমতো গরম হয়। এর দুর্বলতা ধরা পড়ে Packet হারানো Network-এ (Mobile, ভিড়ের Wi-Fi), যেখানে একটি হারানো Packet পুরো Page জমিয়ে দেয়; HTTP/3 ঠিক এটিই সারাতে তৈরি।

#TLS: Connection সুরক্ষিত করা

TLS (Transport Layer Security) যোগাযোগ এনক্রিপ্ট করে তথ্য সুরক্ষিত রাখে এবং Server-এর পরিচয় যাচাই করতে সাহায্য করে। এর পূর্বসূরি SSL বাতিল হয়ে গেছে, যদিও মানুষ এখনো “SSL Certificate” বলে। TLS তিনটি নিশ্চয়তা দেয়:

১. গোপনীয়তা (Confidentiality): পথের কেউ Data পড়তে পারে না (Encryption)।

২. অখণ্ডতা (Integrity): ধরা না পড়ে কেউ Data বদলাতে পারে না (প্রতিটি Record-এ একটি Integrity Tag থাকে)।

৩. পরিচয় প্রমাণ (Authentication): তুমি সত্যিই www.example.com-এর সঙ্গে কথা বলছ, কোনো ভণ্ডের সঙ্গে নয় (Certificate)।

#দুই ধরনের Cryptography

• Symmetric Encryption-এ তালা দেওয়া ও খোলার জন্য একটিই Shared Key (যেমন AES)। এটি খুব দ্রুত, তাই আসল সব Data এভাবেই এনক্রিপ্ট হয়। সমস্যা: যে Network-এ যে কেউ শুনতে পারে, সেখানে দুই অপরিচিত কীভাবে একটি Key-তে একমত হবে?
• Asymmetric (Public-key) Cryptography-তে থাকে একটি Key Pair: একটি Public Key যা সবাই জানতে পারে, আর একটি Private Key যা কখনো মালিকের কাছ ছাড়া কোথাও যায় না (যেমন RSA বা Elliptic-curve Key)। এটি অনেক ধীর, তাই TLS একে শুধু Handshake-এ ব্যবহার করে: একটি Shared Key-তে একমত হতে (Diffie-Hellman Key Exchange, ECDHE) এবং স্বাক্ষর করতে (Certificate, CertificateVerify)।

#TLS 1.3 Handshake

1. ১. ClientHello (Client → Server)

   Client তার সমর্থিত TLS Version ও Cipher Suite, একটি Random মান, এবং আগেভাগেই একটি Key Share (Key Exchange-এর নিজের অর্ধেক) পাঠায়। দুটি গুরুত্বপূর্ণ Extension: SNI (Server Name Indication), যা জানায় কোন সাইট চাই, যাতে অনেক সাইট চালানো Server সঠিক Certificate বেছে নেয়; আর ALPN (Application-Layer Protocol Negotiation), যা h2 বা http/1.1 প্রস্তাব করে।

2. ২. ServerHello (Server → Client)

   Server Version ও Cipher Suite বেছে নেয় এবং নিজের Key Share পাঠায়। এখন দুই পক্ষই একই Shared Secret হিসাব করতে পারে, যা কখনো Network পার হয়নি। এর পরের সবকিছু এনক্রিপ্টেড।

3. ৩. Certificate, CertificateVerify, Finished (Server → Client)

   Server বেছে নেওয়া ALPN Protocol, তার Certificate Chain, Certificate-এর Private Key দিয়ে Handshake-এর ওপর করা CertificateVerify Signature (Certificate-এর মালিকানার প্রমাণ), এবং Finished পাঠায়, যা পুরো Handshake-এর Key-ভিত্তিক Hash এবং যেকোনো কারসাজি ধরে ফেলে।

4. ৪. Finished + প্রথম Request (Client → Server)

   Client Certificate যাচাই করে, নিজের Finished পাঠায় এবং একই সঙ্গে প্রথম HTTP Request। TLS 1.3-এ লাগে এক Round Trip (1-RTT); TLS 1.2-এ লাগত দুটি।

#Session Resumption ও 0-RTT

একটি Handshake-এর পর Server Client-কে একটি Session Ticket দিতে পারে। পরের বার Client সেটি Pre-shared Key (PSK) হিসেবে দেখায় এবং Handshake Certificate বাদ দেয়। 0-RTT-তে Client প্রথম Flight-এর ভেতরেই তার প্রথম Request (Early Data) পাঠিয়ে দেয়, তাই অপেক্ষায় কোনো Round Trip খরচ হয় না।

সমস্যা হলো Replay: যে Attacker সেই প্রথম Flight রেকর্ড করেছে সে আবার পাঠাতে পারে, আর Server পার্থক্য বুঝতে পারে না। GET /home-এর জন্য ক্ষতিহীন, POST /transfer-money-র জন্য বিপজ্জনক। তাই Server শুধু নিরাপদ, Idempotent Request-এ 0-RTT গ্রহণ করে, অথবা এটি বন্ধ রাখে।

#Certificate ও আস্থার শিকল (Chain of Trust)

একটি Certificate বলে: “এই Public Key www.example.com-এর, তারিখ A থেকে তারিখ B পর্যন্ত বৈধ”, এবং এতে স্বাক্ষর করে একটি Certificate Authority (CA)। সাধারণত সাইটের Certificate (Leaf)-এ স্বাক্ষর করে একটি Intermediate CA, আর তাতে স্বাক্ষর করে একটি Root CA। তোমার OS বা Browser প্রায় ১৫০টি Root CA-র একটি Trust Store নিয়েই আসে। আগে থেকে থাকা একটি Root থেকে Chain বেয়ে আস্থা নিচে নামে।

Browser যা যাচাই করে:

১. নাম: তুমি যে Hostname লিখেছ তা Certificate-এ আছে (*.example.com ঢাকে www.example.com, কিন্তু example.com বা a.b.example.com নয়)।

২. তারিখ: আজকের তারিখ “Not Before” আর “Not After”-এর মাঝে। ১৫ মার্চ ২০২৬ থেকে দেওয়া Public Certificate সর্বোচ্চ ২০০ দিন টেকে; ২০২৭-এ সেটা নামবে ১০০ দিনে, ২০২৯-এ ৪৭ দিনে। তাই নবায়ন স্বয়ংক্রিয় হতেই হবে (Let’s Encrypt, Cloud Certificate Manager; দেখো lesson ২.৭)।

৩. Signature Chain: প্রতিটি Certificate পরেরটি দিয়ে স্বাক্ষরিত, একটি বিশ্বস্ত Root পর্যন্ত।

৪. Revocation: Certificate আগেভাগে বাতিল হয়নি, যা যাচাই হয় OCSP (প্রায়ই Server Staple করে দেয়) বা বাতিল তালিকা (CRL) দিয়ে।

৫. মালিকানা: CertificateVerify প্রমাণ করে Server-এর কাছে Private Key আছে।

প্রতিটি ক্ষেত্রে Browser তোমার Request, Cookie বা Password পাঠানোর আগেই থেমে যায়। ক্যাফের Wi-Fi-তে একজন Man-in-the-middle (MITM) তোমার Packet পাচার করতে পারে, কিন্তু অন্যের সাইটের জন্য বৈধ Certificate দেখাতে পারে না, কারণ তার কাছে ওই সাইটের Private Key নেই। ব্যবহারকারী সতর্কবার্তা উপেক্ষা করে এগোলেই শুধু আক্রমণটি সফল হয়।

#QUIC ও HTTP/3

QUIC (মূলত Quick UDP Internet Connections) হলো আধুনিক UDP-ভিত্তিক দ্রুত ও সুরক্ষিত Transport Protocol, আর HTTP/3 এর ওপরই চলে। TCP যা করে (Acknowledgment, পুনঃপ্রেরণ, Flow ও Congestion Control) QUIC তা নতুন করে তৈরি করে, এবং TCP যা পারত না তা যোগ করে:

• ভেতরেই TLS 1.3। Transport ও Encryption একসঙ্গে তৈরি হয়: নতুন Connection-এ 1-RTT, Resumption-এ 0-RTT। এমনকি Transport Header-এর বেশিরভাগও এনক্রিপ্টেড।
• স্বাধীন Stream। Data প্রতিটি Stream-এ আলাদাভাবে ক্রমে সাজানো হয়, তাই একটি হারানো Packet শুধু নিজের Stream-কে দেরি করায়: TCP স্তরের Head-of-line Blocking নেই।
• Connection Migration। একটি QUIC Connection চেনা হয় Connection ID দিয়ে, IP ও Port দিয়ে নয়। তোমার ফোন Wi-Fi থেকে Mobile Data-তে গেলে IP বদলায়, কিন্তু Connection চলতেই থাকে; TCP Connection ভেঙে যেত এবং আবার শুরু করতে হতো।
• User Space-এ চলে। এটি Browser ও Server-এর ভেতরেই থাকে, তাই OS আপডেটের অপেক্ষা ছাড়াই উন্নত হয়।

দুটি বাস্তব সতর্কতা। কিছু Network (অফিস, হোটেল) UDP Port 443 Block করে; তখন Browser TCP + TLS + HTTP/2-তে ফিরে যায়, তাই প্রতিটি HTTP/3 Server-কে TCP-ও দিতে হয়। আর Browser HTTP/3 সমর্থনের কথা জানে Alt-Svc Response Header বা DNS-এর HTTPS Record থেকে, তাই একদম প্রথম ভিজিট প্রায়ই TCP-তেই হয়।

#Round Trip-এর হিসাব

প্রথম Request-এর আগের প্রতিটি Round Trip হলো খাঁটি অপেক্ষা। ৫০ ms-এর পথে (মোটামুটি ঢাকা থেকে Singapore):

এর সবকিছুর ওপরে যোগ হয় DNS Lookup-এর সময়, আর HTTP থেকে HTTPS-এ একটি Redirect-এর সময়ও, যা HSTS-এর একটি কারণ।

#HSTS: HTTPS বাধ্যতামূলক করা

HSTS (HTTP Strict Transport Security) Browser-কে কোনো সাইটের জন্য সর্বদা নিরাপদ HTTPS Protocol ব্যবহারে বাধ্য করে। সাইট এটি HTTPS-এর মাধ্যমে একটি Response Header হিসেবে পাঠায়:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

এরপর max-age সেকেন্ড ধরে (এখানে এক বছর) Browser যেকোনো http:// Link নিজেই https://-এ বদলে দেয়, তোমার মেশিন থেকে কিছু বের হওয়ার আগেই, এবং Certificate Error-কে এমন কঠোর ব্যর্থতায় পরিণত করে যেখানে “Proceed Anyway” Button থাকে না।

দুর্বলতা হলো প্রথম ভিজিট: Browser Header-টি কখনো দেখার আগে example.com লিখলে শুরু হয় সাধারণ HTTP দিয়ে, আর Network-এর একজন Attacker তোমাকে HTTP-তেই আটকে রাখতে পারে (SSL Stripping)। সমাধান হলো HSTS Preload List: যোগ্য সাইটগুলো নিজেদের Domain জমা দেয়, আর Browser তালিকাটি ভেতরেই নিয়ে আসে, ফলে প্রথম ভিজিটও সরাসরি HTTPS-এ যায়। .dev ও .app-এর মতো পুরো TLD-ই Preload করা।

#System Design-এ TCP, UDP ও TLS

• TLS Termination। Load Balancer ও CDN সাধারণত TLS Terminate করে: Certificate তাদের কাছে থাকে, তারা Decrypt করে এবং Private Network-এ Backend-এর সঙ্গে কথা বলে (বা আবার এনক্রিপ্ট করে)। এতে Certificate এক জায়গায় থাকে আর Crypto-র কাজ App Server থেকে সরে যায়। ব্যবহারকারীর কাছের CDN Edge-এ Terminate করলে RTT ছোট হওয়ায় Handshake-ও দ্রুত হয়।
• Service-গুলোর মধ্যে ও Database-এ Connection Pooling ও Keep-alive Handshake, Slow Start ও TIME_WAIT-এ Port ফুরিয়ে যাওয়া এড়ায়।
• দীর্ঘস্থায়ী Connection (WebSocket, Streaming API) NAT Timeout পেরিয়ে টিকে থাকতে Keep-alive চায়, আর Load Balancer-এর Idle Timeout Keep-alive-এর ব্যবধানের চেয়ে বড় রাখতে হয়।
• Transport বেছে নেওয়া। যা সম্পূর্ণ পৌঁছাতেই হবে তার জন্য TCP (বা QUIC)। Real-time Media, Game State ও Discovery-র জন্য UDP, আর মেনে নাও যে হারানো Application-ই সামলাবে।
• Edge-এ HTTP/2 ও HTTP/3 চালু করো; Packet হারানো Network-এর Mobile ব্যবহারকারীদের এতে সবচেয়ে বেশি উপকার।
• Certificate স্বয়ংক্রিয় করো এবং মেয়াদের তারিখ Monitor করো: মেয়াদোত্তীর্ণ Certificate সবচেয়ে সাধারণ এবং সবচেয়ে সহজে এড়ানো যায় এমন Outage-গুলোর একটি।

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

# TCP Connect, TLS Handshake, Certificate ও HTTP আদান-প্রদান দেখো
curl -v https://example.com -o /dev/null
#   * Connected to example.com (...) port 443
#   * SSL connection using TLSv1.3 / ...      <- ঠিক হওয়া Version ও Cipher
#   * ALPN: server accepted h2                <- ALPN দিয়ে HTTP/2 বেছে নেওয়া
#   * Server certificate: subject: CN=www.example.org ...

# প্রতিটি ধাপের সময়: DNS, TCP Connect, TLS Handshake, প্রথম Byte
curl -so /dev/null -w "dns %{time_namelookup}  tcp %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}\n" https://example.com

# সরাসরি Certificate Chain ও TLS-এর খুঁটিনাটি দেখো
openssl s_client -connect example.com:443 -servername example.com
# HTTP/3 চেষ্টা করো (HTTP/3 সমর্থিত curl লাগবে)
curl --http3 -I https://cloudflare.com

# খোলা TCP Connection ও তাদের State দেখো (ESTABLISHED, TIME_WAIT...)
netstat -an          # Windows, macOS, Linux
ss -tan              # Linux: State-সহ TCP Socket
ss -uan              # Linux: UDP Socket

Wireshark-এ কোনো সাইট খোলার সময় Capture চালাও এবং Display Filter tcp.flags.syn==1 দিয়ে শুধু Handshake (SYN ও SYN-ACK) দেখো। আবার পাঠানো Segment খুঁজতে tcp.analysis.retransmission, TLS Handshake-এর জন্য tls.handshake, আর HTTP/3 Traffic-এর জন্য quic ব্যবহার করো। লক্ষ করো, ServerHello-র পরে TLS 1.3 শুধু “Application Data” দেখায়: এমনকি Certificate-ও এনক্রিপ্টেড।

#সারসংক্ষেপ

মূল শিক্ষা

• IP Best-effort ভিত্তিতে একটি মেশিনে Packet পৌঁছায়; Transport Layer যোগ করে Port (কোন Program) এবং TCP-তে নির্ভরযোগ্য, ক্রমানুসারে Delivery।
• TCP: Connection-ভিত্তিক, নির্ভরযোগ্য, ক্রমানুসারে, Flow ও Congestion Control-সহ। UDP: Connection ছাড়া, ৮ Byte Header, কোনো নিশ্চয়তা নেই; DNS, Call, Game এবং QUIC-এর ভিত্তি হিসেবে আদর্শ।
• Three-Way Handshake (SYN, SYN-ACK, ACK) এলোমেলো ISN বিনিময় করে এবং এক RTT খরচ করে। হারানো SYN Backoff-সহ আবার পাঠানো হয়; বন্ধ Port RST দিয়ে উত্তর দেয়; SYN Flood ঠেকানো হয় SYN Cookie দিয়ে।
• seq Byte-এ নম্বর দেয় আর ack পরের প্রত্যাশিত Byte বলে। হারানো মেরামত হয় Timeout (ধীর) বা ৩টি Duplicate ACK-এর পর Fast Retransmit দিয়ে; ক্রম ভেঙে আসা Data Buffer-এ রেখে পুনর্গঠিত হয়।
• Flow Control (Receive Window) Receiver-কে রক্ষা করে; Congestion Control (Slow Start, Avoidance, হারালে cwnd অর্ধেক) Network-কে রক্ষা করে। নতুন Connection ধীরে শুরু করে, তাই Connection আবার ব্যবহার করো।
• Connection বন্ধ হয় FIN দিয়ে (চারটি Segment, তারপর প্রথম বন্ধকারীর TIME_WAIT) অথবা RST দিয়ে হঠাৎ।
• Head-of-line Blocking: HTTP/1.1-এ HTTP স্তরে, HTTP/2-তে TCP স্তরে, QUIC-এর ওপর HTTP/3 দুটোই এড়ায়।
• TLS দেয় গোপনীয়তা, অখণ্ডতা ও পরিচয় প্রমাণ। TLS 1.3-এ লাগে 1 RTT (Key Share, SNI, ALPN-সহ ClientHello; ServerHello; Certificate, CertificateVerify, Finished); Resumption 0-RTT সম্ভব করে, তবে Replay ঝুঁকিসহ। Browser যাচাই করে নাম, তারিখ, বিশ্বস্ত Root পর্যন্ত Chain ও Revocation।
• QUIC = UDP + ভেতরে TLS 1.3 + স্বাধীন Stream + Connection Migration; UDP Block থাকলে TCP-তে ফিরে যায়। HSTS HTTPS বাধ্যতামূলক করে; Preload List প্রথম ভিজিটও ঢাকে।

নিজেকে যাচাই করো: TCP, UDP, TLS আর QUIC৩০টি প্রশ্ন