ভূমিকা: TCP আসলে কী?
ইন্টারনেটে আমরা সাধারণত খুব সহজভাবে বলি:
“Client সার্ভারকে একটা request পাঠালো, server response দিল।”
কিন্তু operating system এবং networking stack-এর নিচে ঘটনাটা অনেক বেশি সংগঠিত।
তুমি browser-এ একটি URL লিখলে application layer থেকে শুরু করে TCP, IP, Data Link এবং physical medium পর্যন্ত একাধিক ধাপে data encapsulate হয়। TCP এই পুরো যাত্রায় connection-oriented, ordered এবং reliable byte-stream communication দেওয়ার জন্য গুরুত্বপূর্ণ ভূমিকা পালন করে।
দেওয়া ক্লাস-নোটে এই ধারণাটা খুব practicalভাবে বোঝানো হয়েছে: application layer শুধু বলে “আমি data পাঠাতে চাই”; transport layer সেই data-কে TCP segment-এ সাজিয়ে নিচের layer-এ পাঠায়।
বাস্তব TCP বোঝার জন্য আমাদের কয়েকটি জিনিস গভীরভাবে বুঝতে হবে:
- Port
- TCP segment ও header
- Sequence Number
- Acknowledgment Number
- SYN / ACK / FIN / RST
- Three-Way Handshake
- Flow Control ও Window
- Checksum
- Retransmission
- MSS ও TCP Options
- Four-Step Connection Termination
- Full duplex communication
1. প্রথমে একটি mental model তৈরি করি
ধরো দুইটি computer:
+------------------+ +------------------+
| CLIENT | | SERVER |
| | | |
| Browser / App | | Web Server |
| TCP | <---------------------> | TCP |
| IP | | IP |
+------------------+ +------------------+
Client বলছে:
“আমি তোমার কাছে data পাঠাতে চাই।”
Server বলছে:
“ঠিক আছে, আমি শুনছি।”
তারপর data exchange হবে।
কিন্তু TCP সরাসরি “Hello World” পাঠিয়ে দেয় না। Data-এর সঙ্গে metadata যোগ করে একটি TCP segment তৈরি করা হয়।
2. Application Data থেকে TCP Segment
Application layer-এর কাছে:
Hello World
TCP layer-এর কাছে এটা শুধু application data। TCP এই data-এর সঙ্গে TCP header যোগ করে:
+--------------------------------------+
| TCP HEADER |
+--------------------------------------+
| APPLICATION DATA |
+--------------------------------------+
অর্থাৎ:
TCP Segment = TCP Header + Data
এখানে একটি গুরুত্বপূর্ণ distinction:
HTTP request ≠ TCP request
HTTP হলো application-layer protocol। TCP হলো transport-layer protocol।
উদাহরণ:
HTTP
↓
TCP
↓
IP
↓
Ethernet / Wi-Fi
↓
Physical medium
বাস্তবে HTTP data TCP byte stream-এর অংশ হিসেবে যায়; HTTP request-এর boundary এবং TCP segment boundary এক জিনিস নয়।
3. OSI Layer-এর সঙ্গে TCP-এর সম্পর্ক
Networking নিয়ে আলোচনা করতে OSI model ব্যবহার করলে TCP থাকে Transport Layer / Layer 4-এ।
একটি simplified view:
Layer 7 Application
HTTP / HTTPS / SMTP / DNS application usage
│
▼
Layer 4 Transport
TCP / UDP
│
▼
Layer 3 Network
IP
│
▼
Layer 2 Data Link
Ethernet / Wi-Fi
│
▼
Layer 1 Physical
Bits / electrical / radio / optical signals
এখানে mental model হিসেবে বলা যায়:
Application data পাঠাতে চায় → TCP তার delivery semantics যোগ করে → IP addressing/routing-এর ব্যবস্থা করে → lower layers actual transmission করে।
4. Encapsulation: Data কীভাবে বড় packet structure-এর মধ্যে ঢোকে?
TCP/IP encapsulation-এর visual overview — Wikimedia Commons.
ধরো application data:
Hello World
TCP layer যোগ করলো:
+-------------------+
| TCP Header |
+-------------------+
| Hello World |
+-------------------+
তারপর IP layer TCP segment-কে payload হিসেবে নেয়:
+-------------------+
| IP Header |
+-------------------+
| TCP Header |
| Hello World |
+-------------------+
তারপর Data Link layer নিজের header/trailer যোগ করতে পারে:
+-------------------+
| Ethernet/Wi-Fi |
| Header |
+-------------------+
| IP Header |
| TCP Header |
| Hello World |
+-------------------+
| Link Trailer |
+-------------------+
এটাই encapsulation।
Receiver side-এ উল্টো প্রক্রিয়া:
Physical
↓
Data Link header/trailer remove
↓
IP header remove
↓
TCP header process
↓
Application data
এটাকে decapsulation বলা যায়।
5. TCP কেন দরকার?
IP packet delivery-এর দায়িত্ব নেয়, কিন্তু application-এর প্রয়োজনীয় সব reliability guarantee IP দেয় না।
TCP মূলত কয়েকটি গুরুত্বপূর্ণ কাজ করে:
5.1 Ordered delivery
Data যে order-এ পাঠানো হয়েছে, application যেন সেই order-এ byte stream পায়।
5.2 Reliable delivery
Data হারিয়ে গেলে TCP loss detect করে এবং প্রয়োজন হলে retransmission করে।
5.3 Flow control
Receiver যতটুকু data নিতে পারে, sender যেন তার capacity-এর বাইরে চাপিয়ে না দেয়।
5.4 Connection management
Connection establish ও close করার জন্য TCP state machine ব্যবহার করে।
5.5 Full-duplex communication
একই established connection-এর দুই দিকেই একই সময়ে data চলতে পারে।
TCP-এর connection-oriented nature, sequencing এবং acknowledgment সম্পর্কে RFC 9293-এ বিস্তারিত specification দেওয়া হয়েছে।
6. Port কী?
একটি IP address তোমাকে সাধারণত কোন host-এর কাছে যেতে হবে তা বুঝতে সাহায্য করে।
কিন্তু একটি host-এর মধ্যে অনেক process/application একসঙ্গে network communication করতে পারে।
তাই দরকার:
Port Number
IP Address = কোন computer?
Port = সেই computer-এর কোন network service/process?
ধরো:
203.0.113.10:443
এখানে:
203.0.113.10 = IP address
443 = destination port
TCP header-এ:
- Source Port = 16 bits
- Destination Port = 16 bits
দুটো field-ই RFC 9293-এ 16-bit হিসেবে সংজ্ঞায়িত।
7. 16-bit Port মানে সর্বোচ্চ কত?
16 bits দিয়ে মোট:
2^16 = 65,536
টি numeric value represent করা যায়।
Range:
0 → 65,535
তবে “সব 65,536 port-ই বাস্তবে application-এর জন্য সমানভাবে usable” — এভাবে বলা ঠিক নয়। Port 0 বিশেষ-purpose/reserved context-এ থাকে, এবং কোন process কোন port bind করবে তা operating system ও protocol ব্যবহারের উপর নির্ভর করে।
8. Port-এর তিনটি IANA range
IANA port registry অনুযায়ী port range তিনভাবে ভাগ করা হয়:
| Range | IANA নাম |
|---|---|
| 0–1023 | System Ports |
| 1024–49151 | User Ports |
| 49152–65535 | Dynamic and/or Private Ports |
IANA বর্তমানে এই range-গুলোকেই ব্যবহার করে।
System / Well-Known Ports
সাধারণ উদাহরণ:
HTTP → 80
HTTPS → 443
SSH → 22
DNS → 53
SMTP → 25
Telnet → 23
এগুলো service identification-এর জন্য widely recognized port assignments।
Registered / User Ports
1024 → 49151
কিছু application/service নির্দিষ্ট port register করতে পারে।
Dynamic / Private / Ephemeral Ports
49152 → 65535
এই range client-side outgoing connections-এর temporary source port হিসেবে খুব commonly ব্যবহৃত হয়।
গুরুত্বপূর্ণ: “Ephemeral port range মানেই সব operating system-এ সবসময় 49152–65535” — এটা বলা যাবে না। IANA range একটি registry classification; operating system নিজস্ব ephemeral allocation range ব্যবহার করতে পারে।
9. Browser-এর source port কোথা থেকে আসে?
ধরো browser যাচ্ছে:
https://example.com
Server:
198.51.100.20:443
Browser-এর জন্য client-side TCP endpoint হতে পারে:
192.0.2.50:52000
তখন connection-এর একটি ধারণাগত 4-tuple:
Source IP = 192.0.2.50
Source Port = 52000
Destination IP = 198.51.100.20
Destination Port = 443
TCP connection matching-এর জন্য এই endpoint information গুরুত্বপূর্ণ।
দেওয়া লেকচারে browser-এর জন্য operating system-এর মাধ্যমে dynamic/ephemeral source port নেওয়ার উদাহরণটি বিশেষভাবে বোঝানো হয়েছে।
10. “এক computer সর্বোচ্চ 16,384 connection পাঠাতে পারবে”—এটা কেন ঠিক নয়?
লেকচারের উদাহরণে:
65535 - 49152 + 1 = 16384
করা হয়েছে। এটি IANA Dynamic/Private range-এর সংখ্যক port value।
কিন্তু এখান থেকে সরাসরি বলা যাবে না:
“একটি computer সর্বোচ্চ 16,384 TCP connection করতে পারবে।”
কারণ TCP connection শুধু source port দিয়ে identify হয় না। সাধারণভাবে connection-এর endpoint pair:
source IP + source port
+
destination IP + destination port
দিয়ে flow distinguish করা হয়।
একই client-side source port ভিন্ন destination endpoint-এর সঙ্গে ভিন্ন TCP connection-এর অংশ হতে পারে। উপরন্তু:
- OS ephemeral port range পরিবর্তন করতে পারে
- IPv4 ও IPv6 আলাদা address space তৈরি করতে পারে
- একই host-এ বহু local IP থাকতে পারে
- NAT/PAT middlebox আলাদা mappings তৈরি করতে পারে
তাই 16,384-কে “maximum total simultaneous TCP connections” হিসেবে মুখস্থ করা উচিত নয়।
11. TCP Segment-এর Anatomy
TCP header-এর প্রধান field-গুলোর visual diagram — Wikimedia Commons.
এখন TCP-এর আসল “ব্লকের” ভিতরে ঢুকি।
+-------------------------------+-------------------------------+
| Source Port (16) | Destination Port (16) |
+-------------------------------+-------------------------------+
| Sequence Number (32) |
+---------------------------------------------------------------+
| Acknowledgment Number (32) |
+------+----------+--------------------------------------------+
| Data | Reserved | Flags | Window |
|Offset| | | |
+------+----------+--------------------------------------------+
| Checksum | Urgent Pointer |
+---------------------------------------------------------------+
| Options (optional) |
+---------------------------------------------------------------+
| Padding (as needed) |
+---------------------------------------------------------------+
| Data / Payload |
+---------------------------------------------------------------+
এটি RFC 9293-এর TCP header format-এর সঙ্গে মিলিয়ে দেখা উচিত।
12. TCP Header-এর গুরুত্বপূর্ণ Field
| Field | Size | কাজ |
|---|---|---|
| Source Port | 16 bits | sender-side port |
| Destination Port | 16 bits | receiver-side port |
| Sequence Number | 32 bits | byte stream-এর sequence tracking |
| Acknowledgment Number | 32 bits | next expected sequence number |
| Data Offset | 4 bits | TCP header কত বড় |
| Reserved | 4 bits | future use |
| Control Flags | 8 bits বর্তমানে assigned core header flags; RFC diagram-এ control bits field | connection/control state |
| Window | 16 bits | receiver কত data accept করতে পারে |
| Checksum | 16 bits | error detection |
| Urgent Pointer | 16 bits | URG ব্যবহারের ক্ষেত্রে urgent data সম্পর্কিত তথ্য |
| Options | variable | MSS, Window Scale, SACK ইত্যাদি |
| Data | variable | application payload |
বিশেষ technical correction: অনেক পুরনো TCP diagram-এ Reserved 3 bits এবং flags 9 bits দেখা যায়। আধুনিক RFC 9293-এর header layout-এ Reserved অংশ 4 bits এবং assigned control bits 8 bits: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN।
13. Data Offset কী?
Data Offset হলো 4-bit field।
এর অর্থ:
TCP header কতগুলো 32-bit word দীর্ঘ।
অর্থাৎ:
Header Size = Data Offset × 4 bytes
কারণ:
1 word = 32 bits = 4 bytes
Minimum:
Data Offset = 5
5 × 4 = 20 bytes
Maximum:
Data Offset = 15
15 × 4 = 60 bytes
অতএব:
Minimum TCP Header = 20 bytes
Maximum TCP Header = 60 bytes
RFC 9293-ও Data Offset-কে 32-bit words-এর সংখ্যা হিসেবে সংজ্ঞায়িত করেছে।
14. Data Offset-এর practical example
ধরো:
Data Offset = 5
তাহলে:
Header = 5 × 4
= 20 bytes
আর ধরো:
Data Offset = 10
তাহলে:
Header = 10 × 4
= 40 bytes
এতে receiver বুঝতে পারে TCP data কোথা থেকে শুরু হয়েছে।
15. Sequence Number — TCP বোঝার সবচেয়ে গুরুত্বপূর্ণ ধারণা
ধরো client server-এ data পাঠাচ্ছে:
HELLOWORLD
TCP byte stream-কে sequence number-এর মাধ্যমে track করে।
ধরা যাক client-এর Initial Sequence Number:
ISN = 1000
SYN-এর ক্ষেত্রে sequence number 1000 হলে, SYN নিজে sequence space-এ 1 unit consume করে।
তাই established data-এর প্রথম byte-এর sequence number হবে:
1001
RFC 9293 স্পষ্টভাবে বলে: SYN set থাকলে segment-এর sequence number হলো ISN, এবং প্রথম data octet-এর sequence number হবে ISN+1।
16. “Sequence number মানে packet number”—এটা ঠিক নয়
এটি খুব common ভুল।
TCP sequence number মূলত byte sequence space-এর সঙ্গে যুক্ত।
ধরো:
Sequence = 1001
Payload Length = 5 bytes
তাহলে পরের expected sequence:
1001 + 5 = 1006
অর্থাৎ ACK সাধারণত:
ACK = 1006
এর মানে:
“1005 পর্যন্ত bytes পেয়েছি; এখন 1006 থেকে চাই।”
RFC 9293 acknowledgment number-কে “next sequence number expected to be received” হিসেবে সংজ্ঞায়িত করে।
17. Acknowledgment Number কী?
ধরো sender পাঠালো:
SEQ = 1001
LEN = 5
Receiver data পেল:
1001
1002
1003
1004
1005
তাহলে receiver বলবে:
ACK = 1006
এখানে একটি অসাধারণ mental rule:
ACK number = “next byte I want”
এটা মনে রাখতে পারলে TCP-এর অনেক অংশ সহজ হয়ে যায়।
18. Three-Way Handshake
TCP three-way handshake-এর visual sequence — Wikimedia Commons.
TCP connection শুরু হওয়ার সময় সাধারণভাবে তিনটি control segment exchange হয়:
Client Server
| |
| -------- SYN, Seq = X ----------> |
| |
| <---- SYN + ACK, Seq = Y, |
| ACK = X + 1 -------------- |
| |
| -------- ACK = Y + 1 ------------>|
| |
| CONNECTION READY |
Cloudflare-এর explanation-ও তিনটি ধাপকে SYN → SYN/ACK → ACK হিসেবে দেখায়।
19. Step 1 — Client sends SYN
Client বলছে:
আমি connection establish করতে চাই।
এখানে:
SYN = 1
SEQ = Client ISN
ধরি:
Client ISN = 1000
তাহলে:
Client → Server
SYN = 1
SEQ = 1000
20. Step 2 — Server sends SYN + ACK
Server client-এর SYN পেয়ে:
- Client-এর SYN acknowledge করে
- নিজের initial sequence number জানায়
ধরি:
Server ISN = 2000
তাহলে:
Server → Client
SYN = 1
ACK = 1001
SEQ = 2000
কেন:
ACK = 1001?
কারণ:
Client-এর SYN sequence = 1000
SYN consumes one sequence number
Next expected = 1001
21. Step 3 — Client sends final ACK
Client এখন server-এর SYN acknowledge করে:
Client → Server
ACK = 2001
SEQ = 1001
এখন handshake complete।
Client Server
| |
| SYN, SEQ=1000 ------------------> |
| |
| <----------- SYN, SEQ=2000 ------ |
| <----------- ACK=1001 ------------|
| |
| ACK=2001 ------------------------>|
| |
| ESTABLISHED |
22. কেন Three-Way Handshake দরকার?
কারণ দুই side-ই নিজেদের sequence number establish করতে চায়।
Client-এর জন্য:
My ISN = 1000
Server must know it
Server-এর জন্য:
My ISN = 2000
Client must know it
শেষ ACK-এর মাধ্যমে client server-এর sequence space সম্পর্কে confirmation দেয়।
এই handshake থেকেই TCP-এর connection-oriented nature স্পষ্ট হয়।
24. TCP-তে Data Transfer শুরু হয় Handshake-এর পর
Handshake:
SYN
SYN/ACK
ACK
এরপর:
ESTABLISHED
এখন application data flow শুরু হতে পারে।
ধরো client পাঠাচ্ছে:
HELLO
এবং:
Client SEQ = 1001
Payload = 5 bytes
তাহলে receiver-এর ACK:
ACK = 1006
25. Client ও Server—দুই দিকেই data পাঠাতে পারে
TCP full-duplex।
অর্থাৎ শুধু:
Client → Server
নয়।
একই সময়ে:
Client → Server
Server → Client
দুই দিকেই independent byte stream চলতে পারে।
তাই দুই side-এর নিজস্ব:
- Sequence number
- Acknowledgment number
- Sending state
- Receiving state
থাকে।
26. Full-Duplex Example
Client Server
| |
| -------- SEQ=1001, "HELLO" -------->|
| |
| <--------- ACK=1006 ---------------- |
| |
| <------ SEQ=2001, "WELCOME" --------|
| |
| ---------- ACK=2008 --------------->|
Client-এর data sequence এবং server-এর data sequence আলাদা।
এটি TCP বোঝার আরেকটি গুরুত্বপূর্ণ mental model।
27. TCP Flags
TCP header-এর control bits-এর মাধ্যমে connection state/control behavior signal করা হয়।
RFC 9293-এর assigned control bits:
CWR
ECE
URG
ACK
PSH
RST
SYN
FIN
28. SYN Flag
SYN = Synchronize
Connection establishment-এ sequence space synchronize করতে ব্যবহৃত হয়।
Three-way handshake:
SYN
SYN + ACK
ACK
29. ACK Flag
ACK = Acknowledgment field is significant
ACK flag set থাকলে TCP acknowledgment field meaningful।
Established connection-এ ACK সাধারণত ongoing traffic-এর অংশ হিসেবেই আসে; “প্রতিটি ACK অবশ্যই আলাদা আলাদা packet হবে”—এটা ঠিক নয়।
একটি data-bearing TCP segment-ই simultaneously data পাঠাতে এবং আগের data acknowledge করতে পারে।
30. FIN Flag
FIN = No more data from sender
এক side বলছে:
“আমার sending direction-এর আর data নেই।”
FIN graceful close-এর অংশ।
গুরুত্বপূর্ণ:
FIN মানে পুরো connection মুহূর্তেই দুই দিক থেকে বন্ধ হয়ে গেল — এমন নয়।
TCP full-duplex হওয়ায় এক direction close হওয়ার পর অন্য direction কিছুক্ষণের জন্য চলতে পারে।
RFC 9293 FIN-কে “No more data from sender” হিসেবে সংজ্ঞায়িত করে।
31. RST Flag
RST = Reset
এটি connection-কে abruptly reset করতে ব্যবহৃত হয়।
FIN হলো graceful close-এর ধারণার সঙ্গে সম্পর্কিত।
RST হলো hard reset।
Cloudflare-ও FIN-based graceful close এবং RST-এর abrupt reset-এর পার্থক্য উল্লেখ করে।
32. PSH, URG, ECE, CWR
PSH
Push function-এর সঙ্গে সম্পর্কিত।
URG
Urgent Pointer field significant হলে URG set হয়।
ECE
ECN-এর signalling-এর সঙ্গে সম্পর্কিত।
CWR
Congestion Window Reduced-এর signalling-এর সঙ্গে সম্পর্কিত।
Beginner হিসেবে প্রথমে:
SYN
ACK
FIN
RST
এই চারটি ভালোভাবে বুঝলেই সবচেয়ে বেশি লাভ হবে।
RFC 9293 সব assigned control bits-এর precise definition দেয়।
33. Window Size — TCP কীভাবে একসঙ্গে অনেক data manage করে?
Sliding window ও acknowledgment-এর relationship — Wikimedia Commons.
ধরো sender প্রতিটি segment পাঠিয়ে আবার reply পাওয়ার জন্য থেমে থাকলে throughput ভয়াবহ কমে যেতে পারে।
তাই TCP একাধিক unacknowledged byte/segment “in flight” রাখতে পারে।
এখানে window গুরুত্বপূর্ণ।
RFC 9293 অনুযায়ী Window field receiver কত data গ্রহণ করতে প্রস্তুত তা advertise করে।
34. Simple Window Example
ধরো receiver বললো:
Window = 10,000 bytes
Mental model:
“আমি এখন পর্যন্ত প্রায় 10,000 bytes পর্যন্ত নতুন data accept করতে প্রস্তুত।”
তখন sender প্রতিটি segment-এর পর stop না করে multiple segment পাঠাতে পারে, যতক্ষণ advertised receive window এবং অন্যান্য TCP constraints তা allow করে।
উদাহরণ:
Sender
|
| Segment 1
| Segment 2
| Segment 3
| Segment 4
| Segment 5
|
+---- ACKs arrive later ---->
এটাই reliable high-throughput communication-এর ভিত্তিগুলোর একটি।
35. Flow Control বনাম Congestion Control
এ দুটোকে এক করে ফেললে TCP বোঝায় সমস্যা হবে।
Flow Control
Receiver-এর capacity কেন্দ্রিক।
প্রশ্ন:
Receiver আর কত data নিতে পারবে?
এখানে receive window গুরুত্বপূর্ণ।
Congestion Control
Network-এর congestion কেন্দ্রিক।
প্রশ্ন:
পুরো network path এখন কত traffic handle করতে পারছে?
Congestion control-এর জন্য sender-side congestion window (cwnd) গুরুত্বপূর্ণ।
বাস্তব TCP throughput সাধারণভাবে একাধিক constraint-এর উপর নির্ভর করে:
usable sending window ≈ min(rwnd, cwnd)
এখানে:
-
rwnd= receiver advertised window -
cwnd= congestion control limit
এটি একটি practical mental model; exact implementation আরও complex।
36. Checksum — Data বদলে গেছে কিনা কীভাবে বোঝে?
TCP header-এ:
Checksum = 16 bits
এটি transmission corruption/error detect করতে ব্যবহৃত হয়।
RFC 9293 অনুযায়ী TCP checksum one's-complement ভিত্তিক calculation ব্যবহার করে এবং header ও data-এর ওপর checksum computation হয়।
37. Checksum কি “ভুল data ঠিক করে”?
না।
Checksum নিজে corrupted data repair করে না।
এটি mainly detect করে:
“আমি যা পেয়েছি, সেটা expected integrity check pass করছে কি?”
Error detect হলে segment গ্রহণ না-ও করা হতে পারে, এরপর TCP recovery mechanisms—যেমন retransmission—দিয়ে sender আবার data পাঠাতে পারে।
অর্থাৎ:
Checksum
↓
Error detected
↓
Bad segment discarded / recovery needed
↓
Retransmission mechanisms
↓
Correct data arrives
38. Retransmission — Packet হারিয়ে গেলে কী হয়?
ধরো:
Segment 1 → পৌঁছালো
Segment 2 → হারিয়ে গেল
Segment 3 → পৌঁছালো
Receiver cumulative ACK দিয়ে missing point signal করতে পারে।
ধরো receiver-এর next expected byte:
5000
কিন্তু পরের data sequence শুরু হলো:
6000
তাহলে sender বুঝতে পারে stream-এর মাঝখানে কিছু missing থাকতে পারে।
TCP loss recovery-এর অংশ হিসেবে timeout, duplicate acknowledgment এবং আধুনিক ব্যবহারে SACK-এর মতো mechanisms ব্যবহার করতে পারে।
39. Duplicate ACK — সহজ mental model
ধরো receiver আশা করছিল:
SEQ = 1006
কিন্তু পেল:
SEQ = 1106
অর্থাৎ মাঝখানে data missing।
Receiver repeated ACK করতে পারে:
ACK = 1006
কারণ:
“আমার 1006 থেকেই missing; এর পরেরটা আগে এসেছে।”
Repeated duplicate ACK sender-কে loss-এর সম্ভাবনা signal করতে পারে।
40. Retransmission মানে সবসময় “ACK না আসা পর্যন্ত resend”
এটা অতিরিক্ত simplistic model।
বাস্তবে TCP loss detection বিভিন্ন mechanism ব্যবহার করে, যেমন:
- Retransmission Timeout (RTO)
- Duplicate ACK-based fast retransmit
- SACK-based recovery
- modern congestion-control/recovery behavior
তাই:
No ACK → blindly resend
এই model-কে exact TCP behavior হিসেবে মনে রাখা উচিত নয়।
41. SACK
SACK = Selective Acknowledgment
এটি TCP-কে আরও efficiently জানাতে পারে কোন কোন block পাওয়া গেছে এবং কোন block missing।
উদাহরণ:
Received:
1001–2000
3001–4000
Missing:
2001–3000
SACK থাকলে receiver sender-কে more precise information দিতে পারে।
এটি retransmission efficiency বাড়াতে সাহায্য করে।
42. TCP Options
TCP header সবসময় শুধু fixed 20 bytes নয়।
Options থাকলে header বড় হতে পারে:
20 bytes → minimum
up to 60 bytes → maximum
Common options:
- MSS
- Window Scale
- SACK Permitted
- SACK
- Timestamp
TCP Options-এর কারণে Data Offset field দরকার।
43. MSS — Maximum Segment Size
একটি TCP connection-এ endpoint-গুলো প্রায়ই জানায় তারা একটি TCP segment-এ কত application data গ্রহণ করতে চায়।
এটিকে:
MSS = Maximum Segment Size
বলা হয়।
এখানে “segment size” বললে অনেক সময় মানুষ পুরো IP packet size-এর সঙ্গে গুলিয়ে ফেলে।
প্র্যাকটিক্যালি:
TCP payload ≈ MSS
এবং:
IP packet size
≈ IP header + TCP header + TCP payload
Ethernet path-এ 1500-byte MTU হলে এবং TCP/IP header normal হলে 1460-byte MSS-এর উদাহরণ খুব common:
1500 - 20 IP header - 20 TCP header = 1460
তবে options, IPv6 এবং path-এর actual MTU অনুযায়ী effective numbers পরিবর্তিত হতে পারে।
44. “Hello World” কি একাধিক TCP segment হবেই?
না।
এটি data size এবং TCP stack-এর segmentation-এর উপর নির্ভর করে।
ছোট data:
Hello World
একটি TCP segment-এর payload-এ সহজেই থাকতে পারে।
বড় data:
Large JSON
Large file
Large response
অনেক TCP segment-এ ভাগ হয়ে যেতে পারে।
তাই:
1 HTTP request = 1 TCP segment
এটি guaranteed নয়।
আবার:
1 TCP segment = 1 complete HTTP message
এটিও guaranteed নয়।
TCP হলো byte stream, message protocol নয়।
45. TCP byte stream-এর সবচেয়ে গুরুত্বপূর্ণ শিক্ষা
ধরো application দুইবার write করলো:
write("HELLO")
write("WORLD")
TCP receiver-side application-এর কাছে network packet boundary preserve করার promise দেয় না।
Receiver দেখতে পারে:
HELLOWORLD
অথবা implementation/application buffering অনুযায়ী read boundaries অন্যরকম হতে পারে।
তাই application protocol-কে নিজের message framing দরকার হতে পারে।
HTTP, WebSocket, custom binary protocol—প্রতিটির framing semantics আলাদা।
46. Four-Step TCP Connection Termination
FIN/ACK দিয়ে TCP connection termination-এর visual diagram — Wikimedia Commons.
Connection close সাধারণভাবে চার ধাপের exchange হিসেবে শেখানো হয়।
Client Server
| |
| -------- FIN -------------------> |
| |
| <-------- ACK ------------------- |
| |
| <-------- FIN ------------------- |
| |
| -------- ACK -------------------> |
| |
| CLOSED |
একে beginner-friendlyভাবে:
FIN
ACK
FIN
ACK
মনে রাখা যায়।
Cloudflare-ও graceful close-এ FIN ব্যবহারের কথা বলে।
47. কেন চার ধাপ?
কারণ TCP full duplex।
প্রতিটি side-এর sending direction independently close হতে পারে।
ধরো Client বলে:
FIN
এর অর্থ:
“আমার আর data পাঠানোর নেই।”
Server:
ACK
দিয়ে Client-এর FIN acknowledge করে।
কিন্তু Server-এর নিজের sending direction তখনও data পাঠাতে পারে।
শেষে Server:
FIN
পাঠায়।
Client:
ACK
পাঠায়।
এরপর connection পুরোপুরি শেষ হয়।
48. গুরুত্বপূর্ণ: সব connection-এ exact “FIN, ACK, FIN, ACK” packet pattern দেখা যাবে না
Network captures-এ ACK সঙ্গে অন্য data/FIN-এর সঙ্গে combine হতে পারে।
উদাহরণ:
FIN + ACK
একটি segment-এই থাকতে পারে।
তাই “চারটি segment না হলে TCP close হয়নি”—এটা ঠিক নয়।
“Four-way termination” হলো conceptual state transition model।
49. Simultaneous Close
দুই side কাছাকাছি সময়ে FIN পাঠাতেও পারে।
TCP state machine-এর কারণে real packet trace textbook diagram-এর মতো perfectly symmetric নাও হতে পারে।
Networking শেখার সময় diagram-কে:
“Conceptual sequence”
হিসেবে দেখো; real packet capture-এর প্রতিটি flow exact একই হবে—এটা ধরে নিও না।
50. RST দিয়ে Connection বন্ধ হওয়া বনাম FIN
FIN
Graceful close
RST
Abrupt reset
যদি application abruptly socket destroy করে বা remote endpoint-এর state invalid হয়, RST দেখা যেতে পারে।
Packet capture debugging-এ FIN বনাম RST দেখে connection lifecycle সম্পর্কে গুরুত্বপূর্ণ clues পাওয়া যায়।
51. TCP Header-এর field-by-field deep explanation
Source Port
Sender-এর local transport endpoint-এর port।
Destination Port
Receiver-side transport endpoint-এর port।
Sequence Number
এই segment-এর data-এর sequence space position।
SYN segment-এ এটি ISN।
Acknowledgment Number
পরবর্তী expected sequence number।
Data Offset
TCP header-এর actual length, 32-bit word-এ।
Reserved
Future protocol evolution-এর জন্য reserved bits।
RFC 9293 অনুযায়ী generated segments-এ এগুলো zero হওয়া উচিত।
Flags
Control/state signaling।
Window
Receiver কত data accept করতে পারবে তার advertised receive capacity।
Checksum
Integrity/error detection।
Urgent Pointer
URG flag ব্যবহৃত হলে relevant urgent pointer field।
Options
Additional TCP capabilities/parameters।
Data
Application payload।
52. TCP Header-এর একটা visual memory trick
এভাবে মনে রাখতে পারো:
PORT
↓
আমি কার সঙ্গে কথা বলছি?
SEQUENCE
↓
আমার data কোথায়?
ACK
↓
আমি পরের কোন byte চাই?
WINDOW
↓
আমি কতটা receive করতে পারি?
CHECKSUM
↓
Data corrupt হয়েছে?
FLAGS
↓
Connection-এর control instruction কী?
OPTIONS
↓
আর কী capability/parameter negotiated?
53. Complete Example: Client → Server
ধরো:
Client IP = 192.0.2.10
Client Port = 52000
Server IP = 198.51.100.20
Server Port = 443
Step 1
Client → Server
Src Port = 52000
Dst Port = 443
SEQ = 1000
SYN = 1
Step 2
Server → Client
Src Port = 443
Dst Port = 52000
SEQ = 2000
ACK = 1001
SYN = 1
ACK = 1
Step 3
Client → Server
Src Port = 52000
Dst Port = 443
SEQ = 1001
ACK = 2001
ACK = 1
এখন established।
54. এবার data পাঠাই
ধরো client পাঠালো:
HELLO
5 bytes।
SEQ = 1001
LEN = 5
Server-এর acknowledgement:
ACK = 1006
কারণ:
1001 + 5 = 1006
এটাই “next byte expected” rule।
55. Server reply দিলে
ধরো server পাঠালো:
OK
2 bytes।
Server-এর প্রথম data sequence:
2001
তাহলে:
Server → Client
SEQ = 2001
LEN = 2
Client ACK:
ACK = 2003
কারণ:
2001 + 2 = 2003
56. Data হারিয়ে গেলে
ধরো client পাঠালো:
SEQ=1001, LEN=100
SEQ=1101, LEN=100
SEQ=1201, LEN=100
কিন্তু দ্বিতীয় segment হারিয়ে গেল।
Server পেতে পারে:
1001–1200
তারপর 1201-এর segment out-of-order হিসেবে আসতে পারে।
Receiver cumulative ACK দিয়ে missing sequence point signal করতে পারে:
ACK = 1101
এখানে:
1001–1100 পেয়েছি, এখন 1101 চাই।
এটি loss recovery-এর একটি core mental model।
57. TCP কি packets reorder করে?
IP network-এ packets বিভিন্ন path দিয়ে যেতে পারে।
ফলে arrival order বদলে যেতে পারে।
TCP sequence number ব্যবহার করে:
Out-of-order data
↓
Sequence tracking
↓
Reassembly / buffering
↓
Application sees ordered byte stream
Cloudflare-এর TCP/IP explanation-এও IP packet ordering guarantee না দেওয়ার এবং TCP sequence-based reassembly/reliability handling-এর practical explanation দেওয়া হয়েছে।
58. TCP reliability-এর formula মনে রাখো
একটি সহজ mental model:
Sequence
+
Acknowledgment
+
Checksum
+
Retransmission
+
Window
+
Congestion Control
↓
Reliable transport behavior
এগুলো আলাদা feature হলেও একসঙ্গে TCP-এর transport behavior তৈরি করে।
59. TCP বনাম UDP
TCP:
Connection-oriented
Reliable
Ordered byte stream
ACK
Retransmission
Flow control
Congestion control
UDP:
Connectionless datagram transport
No TCP-style connection establishment
No TCP-style ordered reliable byte-stream semantics
Cloudflare-এর UDP overview-তেও TCP-এর handshake/reliability/ordering-এর সঙ্গে UDP-এর lightweight datagram behavior তুলনা করা হয়েছে।
60. Application layer থেকে TCP পর্যন্ত full picture
ধরো browser:
POST /login
Application layer:
HTTP request
Transport layer:
TCP segment
Network layer:
IP packet
Data Link:
Ethernet/Wi-Fi frame
Physical:
bits / signals
Receiver side:
signals
↓
frame
↓
IP packet
↓
TCP segment
↓
HTTP bytes
↓
Application
এই layered abstraction-ই software engineer হিসেবে networking বোঝার জন্য শক্তিশালী mental model।
61. “TCP সরাসরি server-এ data পাঠায়” — কতটা ঠিক?
Conceptual context-এ:
Client TCP → Server TCP
বলা হয়।
এটা শেখার জন্য ভালো abstraction।
কিন্তু physical reality:
Client TCP
↓
Client IP
↓
Data Link
↓
Physical
↓
Router(s)
↓
Physical/Data Link
↓
Server IP
↓
Server TCP
TCP নিজে router-by-router forwarding করে না।
TCP endpoint-to-endpoint transport behavior manage করে।
62. Socket কোথায় আসে?
একটি TCP communication endpoint-কে practical programming context-এ socket হিসেবে দেখা যায়।
Conceptually:
Socket ≈ local address + local port + transport protocol
Established connection-কে identify করতে remote endpoint-ও গুরুত্বপূর্ণ।
Programming-এ সাধারণত developer socket API ব্যবহার করে:
connect()
send()
recv()
close()
এবং kernel TCP implementation নিচের protocol mechanics manage করে।
দেওয়া লেকচারে application developer-এর perspective-এ operating system TCP handling-এর এই abstraction জোর দিয়ে বোঝানো হয়েছে।
63. Operating System আসলে কী করে?
Application যখন socket API দিয়ে communication চায়, তখন kernel:
- TCP state maintain করে
- Sequence tracking করে
- ACK process করে
- Retransmission manage করে
- Receive window maintain করে
- Congestion control চালায়
- TCP headers তৈরি/parse করে
- IP stack-এর সঙ্গে কাজ করে
- NIC-এর মাধ্যমে network I/O-তে অংশ নেয়
তাই software engineer হিসেবে:
You write:
send(data)
Kernel does:
TCP + IP + driver + NIC machinery
64. Wireshark-এ TCP দেখতে গেলে কী দেখবে?
একটি TCP packet capture-এ সাধারণত এগুলো দেখতে পারো:
Transmission Control Protocol
Source Port
Destination Port
Sequence Number
Acknowledgment Number
Header Length
Flags
Window Size
Checksum
Options
সবচেয়ে beginner-friendly filter:
tcp
আর নির্দিষ্ট handshake খুঁজতে:
tcp.flags.syn == 1
ACK-related analysis-এর জন্য:
tcp.flags.ack == 1
FIN:
tcp.flags.fin == 1
RST:
tcp.flags.reset == 1
65. Wireshark-এ 3-Way Handshake চিনবে কীভাবে?
Pattern:
1. SYN
2. SYN, ACK
3. ACK
যদি capture-এ sequence এমন হয়:
Client → Server [SYN]
Server → Client [SYN, ACK]
Client → Server [ACK]
তাহলে connection establishment successfully দেখতে পাচ্ছ।
66. SYN Flood কেন TCP-এর সঙ্গে সম্পর্কিত?
TCP server SYN পাওয়ার পর connection establishment-এর state maintain করে এবং SYN/ACK response পাঠায়।
একজন attacker অনেক SYN পাঠিয়ে দিলে server-এর pending connection state resource consume হতে পারে।
এটাকে SYN flood attack-এর সঙ্গে দেখা যায়।
Cloudflare-এর SYN flood explanation-এ SYN → SYN/ACK → final ACK sequence এবং incomplete handshakes-এর resource impact ব্যাখ্যা করা হয়েছে।
67. TCP State Machine-এর খুব সংক্ষিপ্ত map
সব implementation detail না ধরে একটি simplified model:
CLOSED
|
| connect / active open
v
SYN-SENT
|
| SYN+ACK
v
ESTABLISHED
|
| FIN
v
FIN-related states
|
v
CLOSED
Server-side connection establishment-এ LISTEN, SYN-RECEIVED ইত্যাদি states-ও থাকে।
TCP debugging-এর জন্য state machine পরে আরও গভীরভাবে শেখা খুব উপকারী।
68. Common ভুলগুলো
ভুল ১: TCP packet বলে শেষ
Technicalভাবে TCP transport-এর data unit-কে সাধারণত segment বলা হয়।
IP layer-এ সেটা packet context পায়।
Data Link layer-এ frame হতে পারে।
ভুল ২: Sequence number = packet number
না।
TCP sequence number byte-oriented sequence space track করে।
ভুল ৩: ACK = “এই packet পেলাম”
আরও নির্ভুলভাবে:
ACK = next sequence number expected
ভুল ৪: SYN-এর data sequence X হলে next data X
না।
SYN sequence space-এর 1 unit consume করে।
তাই:
SYN SEQ = X
first data SEQ = X + 1
ভুল ৫: প্রতি data segment-এর জন্য আলাদা ACK packet লাগেই
না।
ACK অন্য data-bearing segment-এর সঙ্গেও piggyback হতে পারে।
ভুল ৬: HTTP request = one TCP segment
না।
TCP byte stream।
ভুল ৭: TCP checksum ভুল data fix করে
না।
Checksum error detect করতে সাহায্য করে; recovery retransmission mechanisms দিয়ে হয়।
ভুল ৮: Ephemeral ports সব OS-এ 49152–65535
IANA registry range এবং OS-এর actual ephemeral allocation policy এক জিনিস নয়।
ভুল ৯: 16384 source ports = 16384 total TCP connections
এটি সরাসরি বলা ঠিক নয়।
Connection uniqueness-এর জন্য endpoint tuple, address selection এবং OS/network behavior গুরুত্বপূর্ণ।
ভুল ১০: FIN মানে সঙ্গে সঙ্গে পুরো connection shutdown
না।
TCP full-duplex বলে direction-wise shutdown হয়।
69. সবচেয়ে গুরুত্বপূর্ণ সংখ্যাগুলো
Port field = 16 bits
Port numeric space = 0–65535
Sequence Number = 32 bits
Acknowledgment Number = 32 bits
Data Offset = 4 bits
TCP header = 20–60 bytes
Window = 16 bits
Checksum = 16 bits
Urgent Pointer = 16 bits
RFC 9293-এর TCP header specification-এর সঙ্গে এই field sizes মিলিয়ে দেখা উচিত।
70. এক পাতায় পুরো TCP
APPLICATION
|
| data
v
TCP
|
+----------+----------+
| |
Ports Sequence
| |
| ACK number
| |
| Window
| |
| Checksum
| |
| Flags
+----------+----------+
|
Segment
|
v
IP
|
Packet
|
v
Ethernet / Wi-Fi
|
Frame
|
v
Physical
|
Bits
আর connection lifecycle:
START
|
v
SYN
|
v
SYN + ACK
|
v
ACK
|
v
ESTABLISHED
|
v
DATA TRANSFER
|
v
FIN/ACK
|
v
FIN/ACK
|
v
CLOSED
71. TCP বোঝার জন্য একটি “five question” framework
যেকোনো TCP packet দেখলে নিজেকে পাঁচটি প্রশ্ন করো:
1. কে পাঠাচ্ছে?
Source IP + Source Port
2. কার কাছে যাচ্ছে?
Destination IP + Destination Port
3. কোন byte থেকে শুরু?
Sequence Number
4. Receiver পরের কোন byte চায়?
Acknowledgment Number
5. Control situation কী?
SYN / ACK / FIN / RST / ...
এগুলো ধরতে পারলে Wireshark-এর একটি TCP packet অনেক কম scary লাগবে।
72. Software Engineer-এর জন্য TCP-এর practical mental model
Browser-এ তুমি লিখলে:
https://example.com
তোমার application logic সাধারণত এভাবে ভাববে:
request পাঠাও
response নাও
কিন্তু নিচে TCP ভাবছে:
আমার local port কী?
remote port কী?
connection established?
আমার sequence space কী?
receiver কত data নিতে পারবে?
কোন bytes acknowledged?
কোন bytes missing?
retransmission দরকার?
connection close হবে?
এই difference-টাই abstraction।
73. শেষ কথা: TCP-কে কীভাবে মনে রাখবে?
TCP মনে রাখার সবচেয়ে ভালো উপায় শুধু সংজ্ঞা মুখস্থ করা নয়।
এই flow-টা মাথায় রাখো:
Application Data
↓
TCP Segment
↓
Ports
↓
Sequence Number
↓
ACK Number
↓
Flags
↓
Window
↓
Checksum
↓
Options
↓
IP
↓
Network
Connection-এর lifecycle:
SYN
↓
SYN + ACK
↓
ACK
↓
DATA
↓
ACK / WINDOW / RETRANSMISSION
↓
FIN
↓
ACK
↓
FIN
↓
ACK
আর সবচেয়ে গুরুত্বপূর্ণ তিনটি mental rule:
Sequence number বলে data stream-এর কোন জায়গায় আছি।
ACK number বলে receiver পরের কোন sequence number আশা করছে।
Window বলে receiver বর্তমানে কত data গ্রহণ করতে প্রস্তুত।
এই তিনটি ভালোভাবে আয়ত্ত করতে পারলে TCP-এর বাকি অংশ অনেক বেশি logical হয়ে যাবে।
74. Quick Revision Sheet
TCP
├── Layer 4
├── Connection-oriented
├── Reliable
├── Ordered byte stream
├── Full duplex
│
├── Header
│ ├── Source Port
│ ├── Destination Port
│ ├── Sequence Number
│ ├── ACK Number
│ ├── Data Offset
│ ├── Reserved
│ ├── Flags
│ ├── Window
│ ├── Checksum
│ ├── Urgent Pointer
│ ├── Options
│ └── Data
│
├── Connection Start
│ ├── SYN
│ ├── SYN+ACK
│ └── ACK
│
├── Data Transfer
│ ├── SEQ
│ ├── ACK
│ ├── Window
│ ├── Checksum
│ └── Retransmission
│
└── Connection Close
├── FIN
├── ACK
├── FIN
└── ACK
75. References ও Further Reading
Primary technical specification
RFC 9293 — Transmission Control Protocol (TCP)
https://www.rfc-editor.org/rfc/rfc9293.htmlRFC Editor — RFC 9293 information page
https://www.rfc-editor.org/info/rfc9293/
Port registry
- IANA — Service Name and Transport Protocol Port Number Registry https://www.iana.org/assignments/service-names-port-numbers
Online diagrams
Wikimedia Commons — TCP Header.png
https://commons.wikimedia.org/wiki/File:TCP_Header.pngWikimedia Commons — TCP Protocol Diagram.png
https://commons.wikimedia.org/wiki/File:TCP_Protocol_Diagram.pngWikimedia Commons — Tcp-handshake.png
https://commons.wikimedia.org/wiki/File:Tcp-handshake.png
Practical explanations
Cloudflare — What is TCP/IP?
https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/Cloudflare — SYN Flood DDoS Attack
https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/
Top comments (0)