TCP Unveiled: A Journey into the Protocol’s Core
Introduction:
TCP Unveiled: A Journey into the Protocol’s Core

Introduction:
TCP has been a foundation for unnecessary higher-level protocols such as HTTP and web sockets due to its data integrity guarantee. Imagine querying a database table and missing a few routes of data; that would be catastrophic, yet we make database calls without concern about missing data, thanks to TCP’s integrity guarantees. In networking, balancing data integrity with latency is a challenge, especially given the unpredictable nature of the Internet. We never know how many routers our network calls top through, and despite many routers or switches potentially dropping packets, data loss is not an issue. This blog, we believe, will clarify your understanding of TCP and dispel misconceptions about this enduring protocol that has stood the test of time for over the past four decades.
IP Packet Header:
A TCP segment, along with its header, gets stuffed inside the IP Packet data and gets sent. To fully understand the subsequent sections, it is important to familiarize ourselves with the IP packet header. Below is a diagram illustrating the IP packet header structure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source : REC791
- Version: Specifies the IP protocol version, either IPv4 or IPv6.
- IHL : Indicates the length of the header, including any options.
- Type of Service: Defines aspects like priority and quality of service.
- Total Length: Specifies the packet’s total length, including the header and data.
- Identification, Flags, Fragment Offset: These fields are used for packet fragmentation and reassembly if needed.
- Time to Live: Limits the lifespan of a packet by defining the maximum number of hops it can make before being discarded. Each router decrements this value by one.
- Protocol: Specifies the protocol used in the data portion (e.g., ICMP, TCP, UDP).
- Header Checksum: Used to verify the integrity of the header data in IPv4 packets.
- Source and Destination IP Address: Specifies the sender’s and receiver’s IP addresses. At Layer 3, only these IP addresses are involved in routing.
Understanding these fields will aid in navigating the complexities of network packet handling in further discussions.
TCP Connection:
The transmission controls protocol focuses on controlling data transmission, unlike the more lenient UDP. TCP is methodical about initiating, maintaining, and terminating data transmission A crucial aspect is the TCP connection. A TCP connection id bidirectional, enabling protocols like HTTP and WebSocket to operate effectively. It is initiated by the client and accepted by the server. A client is typically an application used directly by the user to initiate operations. The server is a continuously available application that handles client requests. Therefore, it is more practical for clients to identify the server rather than vice versa, aligning with software architecture, not any inherent TCP directionally. TCP, a layer 4 protocol with port visibility, requires an established connection for data transmission. A TCP connection resembles an agreement between a client and server, identified by :
- Client IP.
- Client Port.
- Destination IP.
- Destination Port.
Establishing a TCP connection involves a three-way handshake: SYN, SYN-ACK, and ACK. TCP segments are sequenced, and acknowledgement triggers a transmission, which will be explored shortly. Multiple connections can exist between the same client and server connection .h TCP segments are multiplexed into a single stream. This stream is then demultiplexed and routed to the appropriate programs listening on relevant ports.
Connection Establishing :

TCP connection establishment consists of three handshakes:
- The sender sends a SYN request.
- The receiver responds with a SYN/ACK message.
- The initiator sends back an ACN message. Both the sender and receiver now have a socket and file descriptor, signifying an established connection.
Transmission of Data:
segments are acknowledged by the receiver upon receipt.

The receiver may acknowledge multiple segments with a single acknowledgement. For instance, in the given scenario, the sender might send three segments numbered based on the initial SYN connection request sequence. The receiver acknowledges the last segment, implicitly acknowledging the segment as well.
Re-transmission of Data :

For illustration :
- The segment with the third sequence number is dropped.
- The sender waits for acknowledgement and receives acknowledgement only for sequence 2.
- After a timeout, the sender retransmits the segment marked with sequence 3.
- The receiver then acknowledges sequence 3.
You might be thinking that would happen if sequence 2 got dropped while sequence 3 went through. Well, that would result in line of Head blocking and we will explore that in the last section of the article.
Connection Closure and connection state :

While a TCP connection is established via a three-way handshake, closing it involves a four-way handshake. The connection state transition is as follows.
- The sender initiates closure by sending a FIN request, entering the FIN WAIT state.
- The receiver of the FIN sends back an ACK and moves to the CLOSE-WAIT state.
- The sender receives the ACK, moving to the FIN WAIT 2 state.
- The receiver enters the LAST ACK state, sending a FIN back.
- The sender, on receiving the FIN, moves to the TIME WAIT state, sending a final ACK.
- On receiving the last ACK, the receiver transitions the connection to the CLOSED state and waits to ensure no more messages are incoming before finally moving to the CLOSED state.
The responsibility for waiting and closing the connection fully on the initiator, hence the recommendation for the client to initiate the connection. Additionally, the removal of sockets and file descriptors continues even after the connection is closed, as the OS independently manages resource disposal.
Anatomy of TCP Segments:
The TCP format is as follows :
Note: Each tick mark represents one bit position
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window Size |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source : REC793
The header consists of 5*4=20 bytes. Additionally headers maybe included as options . The source port and destination port fields specify the ports for the source and destination. The acknowledgement Number is only relevant if the ACK flag is set. The window size field indicates the amount of data the receiver can handle.
Notable are the 9 bit flags :
- FIN: Indicates a connection closer request.
- SYN: Indicates a sequence number of the initial handshake.
- RST: Reset the connection.
- ACK: Acknowledges received data
- URG: Marks urgent data.
- ECE: Signals congestion window reduction.
- CWR: Indicates congestion window reduction.
- NA: Notification anomalies.
The relevance of these flags will become clearer as we explore more aspects of TCP.
Flow Control :


Consider a scenario where the sender wants to transmit segments 1,2, and 3 to the receiver. Receiving a single acknowledgment for multiple segments is more efficient. However, the sender must have a way to know how many segments to send before waiting for an acknowledgment. Sending too many segments cloud overwhelm the receiver’s buffer, leading to dropped segments. This is why where the window sized comes into play. Each acknowledgement from the receiver includes the current window size, informing the sender of how many packets can be sent.
Receiver Window:

The sliding window is a critical mechanism in TCP used by the sender. As illustrated, assume the sender wants to transmit six segments to the receiver.
- The sender transmits segments 1,2, and 3.
- The receiver acknowledges Segment 2.
- The sender realizes segment 3 is either still in transit or lost.
- The window slides to include Segments 4 and 5, keeping Segment 3 within the window.
- Segments 1 and 2 are excluded from the sender’s window as they have moved out of this window and may be dropped.
- The sender transmits segment 3, the window slides further to include Segment 6, and efficient use of network resources.
But what should be the size of this window?
Clearly, the number of segments that are to be sent to the receiver are to be included in the window. This size of the window gets set with every acknowledgement that comes back.
Congestion Control:
The flow data from sender to receiver in TCP is not solely managed by flow control. Although flow control ensures that the receiver is not overwhelmed. The data must traverse several immediate devices, such as routers and switches. These network elements might not support rapid data flow even if the receiver can handle it. Therefore, TCP also incorporates congestion control to manage data transmission effectively. IN addition to the receiver window, TCP utilizes a congestion window, which plays a crucial role in congestion control. It’s important to note that the CWND can never exceed the RWND. There are two primary algorithms for determining the size of the CWND.
- TCP slow start: This algorithm gradually increases the CWND size to identify the capacity of the network without causing.
- Congestion Avoidance: This aims to optimize data flow by adjusting the CWND size to avoid congestion once the initial capacity has been identified. Let’s explore each of these algorithms in detail.
TCP slow start:
Ironically, despite its name, TCP slow start is the fastest among the congenital control algorithms.

In the example illustrated above :
- The congestion window begins with a capacity of 1 segment. Accordingly, only one segment is sent initially.
- Upon receiving acknowledgement from the receiver, the CWND is increased by 1.
- The sender then transmits two segments: segments 2 and 3.
- In response, the receiver sends back acknowledgements for both segments, increasing the CWND by 2.
- With the CWND now allowing for larger transmission, the sender proceeds to send segments 4,5, and 7.
Congestion Avoidance:
The Congestion avoidance algorithm also increases the CWND but at a slower rate than TCP slow start.

In the above diagram
- The congestion window begins with the capacity for 1 segment, so only one segment is initially sent.
- Upon receiving an acknowledgement from the receiver, the CWND is increased by 1
- The sender then transmits two segments: segments 2 and 3.
- The receiver sends back acknowledgments for both segments. The CWND is increased by 1 for the entire round trip as it pertains to the single window of data sent.
- With the update CWND, the sender now sends segments 4,5, and 6.
Congestion Notification:
Routers operate at Layer 3 of the OSI model, providing them visibility into IP packet. IP packets include a field unknown on ECN. When routers detect that their buffers are becoming full, they mark the ECN field in the IP packets and forward them to the receiver. Upon receiving these packets, the receiver notes the ECN marking in the IP headers and communicates this information back to the transmission role to alleviate congestion.
Nagesl’s Algorithm:
Nagel’s algorithm specifies that if there are in-flight segments- meaning segments that have been sent but for which an acknowledgement has not yet been received an IP packet will only be transmitted if it is completely filled. Conversely, if there are no in-flight segments, a packet will be sent even if it is only partially filled.

In the diagram example provided :
- Three filled IP packets are sent, while a partially filled packet is held back.
- Once the acknowledgments for three packets are received, the partially filled packets are received, the partially filled packets are received, and the partially filled packet is then transmitted.
Nageles algorithm is often disabled in modern networking practices because it can introduce additional latency.
Delayed Acknowledgement Algorithm:
The delayed acknowledgement algorithm is implemented on the receiver’s side. This algorithm suggests that the receiver should wait to receive multiple packets before sending an acknowledgement sent is reduced, which can help decrease overall latency in the communication process.

A problem arises when Nagle’s algorithm and the delayed algorithm are used simultaneously. Nagel’s algorithm, which operates on the sender’s side, holds back a packet until an acknowledgement algorithm, implemented on the receiver’s side, waits to receive multiple segments before sending back an ACK. This combination can create a deadlock-like situation where the sender is waiting for an ACK that is not being sent because the receiver is receiving additional segments, retransmission impacting network performance.
TCP Head of Line Blocking:
TCP ensures that segments are delivered in the order they are sent. line of Head blocking occurs when the sequence gets dropped, which particularly impacts HTTP requests because they often use the same connection to send multiple requests.

Consider the diagram example illustrated above :
- Request 1 is divided into segments 1 and 2.
- Request 2 is divided into segments 3 and 4.
If segments 2,3, and 4 are successfully transmitted but segment. 1 is dropped, the server will not send acknowledgments for segments 2, 3, and 4 until segment 1 is retransmitted. As a result, Request 2 suffers delays even though it was fully transmitted because it is dependent on the status of Request 1. This scenario exemplifies the line of Head Blocking where the processing of one request is held up due to the loss of an earlier packet.
Conclusion:
In this comprehensive blog, we built upon the foundation established in a previous piece and delved into the internals of TCP Communication. We began by examining the anatomy of IP packers and then explored the mechanism involved in TCP connection creation and closure. We discussed various mechanisms, such as flow control and congestion control, that TCP employs to ensure smooth and reliable data transmission. The sliding window technique facilitates controlled data flow, allowing for efficient management of both flow and congestion. Additionally, we reviewed Nagel’s algorithm and the delayed acknowledgement algorithm, both designated to reduce transmissions for improved efficiency. However, we noted that their combined use can lead to counterproductive outcomes. Finally, we addressed the concept of line of Head blocking, illustrating its impact on data transmission. We trust that this blog contributed to your understanding and provided valuable insights into the intricacies of TCP internals.
If you like my post so please follow and subscribe me on medium.
If you want to support me :
UPI : kaustavdutta3985@okaxis
Buy me a coffee: https://www.buymeacoffee.com/kaustavdutP .
Paypal: paypal.me/kaustav10
Contact: kaustavdutta3985@gmail.com
Thank you for being a part of the community
Before you go:
- Be sure to clap and follow the writer ️👏️️
- Follow us: **X | [LinkedIn](https://www.linkedin.com/company/inplainenglish/) | [YouTube](https://www.youtube.com/@InPlainEnglish) | [Newsletter](https://newsletter.plainenglish.io/) | [Podcast](https://open.spotify.com/show/7qxylRWKhvZwMz2WuEoua0) | [Differ](https://differ.blog/inplainenglish) | [Twitch](https://twitch.tv/inplainenglish)**
- **Check out CoFeed, the smart way to stay up-to-date with the latest in tech 🧪**
- **Start your own free AI-powered blog on Differ** 🚀
- **Join our content creators community on Discord** 🧑🏻💻
- For more content, visit **plainenglish.io + [stackademic.com](https://stackademic.com/)**
메타데이터
- post_id
- fb4111c41ec0
- slug
- tcp-unveiled-a-journey-into-the-protocols-core-fb4111c41ec0
- url
- https://blog.stackademic.com/tcp-unveiled-a-journey-into-the-protocols-core-fb4111c41ec0
- canonical_url
- https://blog.stackademic.com/tcp-unveiled-a-journey-into-the-protocols-core-fb4111c41ec0
- author_url
- https://medium.com/@kaustavdutta3985
- status
- ok
- fetched_at
- 2026-06-11 15:16:29