Skip to content
Search

Transmission Control Protocol

lastmod 2026-08-23created 2015-07-1666 edits

Transmission Control Protocol (TCP; North Korean term: jeonsong jojong gyuyak) is one of the core protocols of the Internet protocol suite (IP), and together with IP it is widely known as TCP/IP. TCP lets programs running on computers connected to a local area network, an intranet, or the Internet exchange a series of octets reliably, in order, and without errors. TCP sits in the transport layer. As a protocol that controls the delivery of information over a network and one of the core protocols that make up the Internet, it is described in RFC 793 of the Internet Engineering Task Force (IETF).

TCP is used when web browsers connect to servers on the World Wide Web, and it is also used for email and file transfer.

Applications that do not need TCP's reliability generally use the connectionless User Datagram Protocol instead of TCP. It has no error checking or delivery confirmation, but has the advantages of low overhead and low latency.

Categories

Origin

In May 1974, the Institute of Electrical and Electronics Engineers (IEEE) published a paper titled "A Protocol for Packet Network Intercommunication." In the paper, its authors Vint Cerf and Bob Kahn proposed a packet-switched internetworking protocol for sharing information between nodes. The central control component of this model was the Transmission Control Program, which covered both connection-oriented links and datagram services between hosts. The communication control program, at that time a single component, was later split into a modular architecture: the communication control protocol (TCP) at the connection-oriented layer and the Internet Protocol (IP) at the internetworking (datagram) layer. For convenience this model is often called TCP/IP, combining the two, and its official name is the Internet protocol suite.

TCP segment structure

TCP takes data from a data stream, divides it into chunks, and adds a TCP header to create TCP segments. TCP segments are encapsulated in IP datagrams and exchanged with the other side.

The term TCP packet is often used, but it is not accurate. Segment is the correct term for the TCP protocol data unit (PDU); datagram means the IP PDU, and frame means the data link layer PDU.

A process transmits data by passing a data buffer as an argument to TCP. TCP packages these buffers into segments and sends each segment through the internet module (IP, etc.) to the destination TCP.

A TCP segment consists of two sections: the segment header and the data. The TCP header contains 10 mandatory fields and optional extension fields (the orange part at the bottom of the table).

The data section follows the header. Its contents are the application's payload data. The length of the data section is not specified in the TCP segment header; it is calculated by subtracting the lengths of the TCP header and the encapsulating IP header from the total IP datagram length. In other words, the length of the data section is determined by the IP header.

TCP Header

Offsets

Octet

0

1

2

3

Octet

Bit

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0

0

Source port

Destination port

4

32

Sequence number

8

64

Acknowledgment number (if ACK set)

12

96

Data offset

Reserved
0 0 0

N
S

|C
W
R

|E
C
E

|U
R
G

|A
C
K

|P
S
H

|R
S
T

|S
Y
N

|F
I
N

Window Size

16

128

Checksum

Urgent pointer (if URG set)

20
...

160
...

Options (if data offset > 5. Padded at the end with "0" bytes if necessary.)
...

Congestion control (Network congestion)

Congestion control means regulating the amount of traffic entering a telecommunications network to keep the network from becoming congested. For example, detecting excessive traffic and sending fewer packets can prevent congestion collapse.

Head-of-line blocking

See that page.

In computer networking, head-of-line blocking (HOL blocking) is a performance-limiting phenomenon that occurs when the first packet holds up the line of packets. Examples include input-buffered network switches, out-of-order delivery, and multiple requests in HTTP pipelining.

Packet loss issue

TCP Friendly Rate Control (TFRC)

Status

Socket_status_sequence.png

3 way handshake

4 way handshake

Socket options

See Network socket#Socket options for details.

Tcp flags

TCP (Transmission Control Protocol) starts communication by establishing a session between two endpoints through the 3-WAY Handshake, and ends communication by terminating the session through the 4-WAY Handshake. Besides establishing and tearing down sessions, functions such as sending or refusing data and terminating sessions depend on the packet's FLAG values; TCP FLAGs basically consist of six types.

FLAG Order

The flag order is as follows. 

+-----+-----+-----+----+-----+----+
| URG  | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+----+-----+----+

Each is 1 bit, defined as a cONTROL BIT or FLAG BIT within the TCP segment field.

List of TCP Flags

SYN(Synchronization) - S (connection request flag)
The first packet sent when establishing a session in TCP; it is used to establish the session by setting an arbitrary sequence number, and carries the initial sequence number.
ACK(Acknowledgement) - Ack (response)
A packet that tells the other side a packet was received; it may also appear together with other flags. The receiver sends an ACK equal to the sender's sequence number plus the length or amount of data at the TCP layer. (Usually sent as +1) Based on the ACK response, the sender judges whether the sent packet succeeded or failed, and either retransmits or sends the next packet.
RST(Reset) - R (reset and terminate connection)
The process of resetting; an abort that happens in both directions at the same time. It corresponds to an abnormal session disconnection. It is used when the sender wants to immediately disconnect from the peer it is currently connected to.
PSH(Push) - P (push)
For protocols where interaction matters, such as TELNET, fast responses are important; this FLAG makes the received data be passed immediately to its destination, the Application layer of the OSI 7 Layer model. Used for interactive traffic, it delivers data without waiting for the buffer to fill. The data is passed directly, without buffering, to the layer-7 application rather than to the layer immediately above.
URG(Urgent) - U (urgent data)
Indicates whether the Urgent pointer is valid. The Urgent pointer is used when part of the data being sent must be delivered urgently. Urgent data should have higher priority than other data.
ex) Pressing Ctrl+c while the ping command is running
FIN(Finish) - F (connection termination request)
Used to terminate a session connection; indicates that there is no more data to send.
Placeholder
This flag is set when none of the SYN, FINISH, RESET, PUSH, etc. flags are set on the packet. This flag is sometimes used together with the ACK flag.

CSMA/CD

Carrier sense multiple access with collision detection (CSMA/CD) is a method in computer networking that partly modifies the earlier carrier sense multiple access (CSMA) method to improve performance.

The CSMA/CD method has the following characteristics.

  • It uses a carrier sensing technique.
  • When sender 'A', who wants to send data, detects that receiver 'B' is already communicating with another sender 'C', it immediately stops communicating and sends a jam signal (Jam Signal). It then waits for a random amount of time and prepares to retransmit.

Once a jam signal occurs, it is delivered not only to sender 'A' but to every node on the network that wants to send data to receiver 'B'. This blocks unnecessary transmissions in advance and reduces traffic.

The CSMA/CD method belongs to layer 2 of the OSI layers, but it is not a protocol of the OSI 7-layer model.

TCP_NODELAY

  • When debugging latency problems in distributed systems, the first thing to check is the TCP_NODELAY setting
  • The Nagle algorithm, proposed in RFC896 in 1984, was designed to reduce TCP header overhead when sending small packets
  • However, combined with the delayed ACK mechanism, data transmission is held back until an ACK is received, degrading the performance of latency-sensitive applications
  • In modern datacenter environments, RTTs are very short and most systems already send large messages, so the benefits of the Nagle algorithm have almost disappeared
  • Therefore, modern distributed systems should enable TCP_NODELAY by default; the Nagle algorithm is no longer needed

Background of the Nagle algorithm

  • John Nagle's RFC896 (1984) was proposed to solve the 4000% overhead of a 40-byte header for 1 byte of data when sending small data such as keyboard input
    • The problem at the time was that a small packet was sent every time a user typed a character, lowering network efficiency
    • The solution was to restrict sending new segments while earlier data had not yet been ACKed
  • This approach was effective in the network environment of the time, but it is unsuitable for modern systems where latency matters

Interaction between the Nagle algorithm and Delayed ACK

  • Delayed ACK (RFC813, RFC1122) is a scheme in which the receiver does not send an ACK immediately, but delays it until there is response data or a timer expires
  • The Nagle algorithm stops sending while waiting for an ACK, and delayed ACK holds back the ACK, so a deadlock arises in which both sides wait for each other
  • John Nagle himself called this combination "a terrible combination," pointing out that the two features were introduced independently but cause latency when used together

Problems in modern environments

  • RTT within a datacenter is very short: about 500μs, and only a few milliseconds even within the same region
  • In such environments, delaying transmission by one RTT translates into lost performance
  • Also, modern distributed systems already send sufficiently large messages because of TLS, serialization, protocol overhead, and so on, so the single-byte packet problem barely exists
  • Small-message optimization is now handled at the application layer

Why TCP_NODELAY is needed

  • In latency-sensitive distributed systems, enabling TCP_NODELAY to disable the Nagle algorithm is recommended
    • This is not an "inefficient" or "wrong setting," but a choice suited to modern hardware and traffic characteristics
  • The author argues that TCP_NODELAY should be the default
    • Some code that "sends on every write() call" may get slower, but such code should be fixed at its root
  • The TCP_QUICKACK option reduces ACK delay, but it is not a fundamental solution because of portability issues and inconsistent behavior
  • The core problem is the kernel holding data longer than the application intended; data should be sent immediately on a write() call

Conclusion

  • The Nagle algorithm was a great invention for improving network efficiency in the past,
  • but in modern high-speed networks and distributed systems it is an outdated feature that actually causes latency
  • Therefore, always enabling TCP_NODELAY is presented as a basic principle of modern system design

TCP Fast Open

TFO TL;DR

  • TCP Fast Open (TFO) allows clients to send data in the initial SYN request, without waiting for a full handshake to occur. This removes an entire round trip almost transparently from the application.
  • Cookies are included in the TCP options header.
  • It’s available in Linux 3.7+, nginx and HAProxy has support already. Client support is lacking with only Chrome/Chromium on Linux, ChromeOS and Android 5.0 (Lollipop), and only if enabled manually.
  • There’s some potential issues with delivering duplicate data to the server’s application, which wouldn’t occur in normal TCP, although it is unlikely, some applications may not be compatible.
    • It’s perfect for static content (CDNs),
    • Every website which uses TLS (it’ll reduce that handshake time).

Why Time-wait exists

There are mainly two reasons.

  1. To prepare for the case where a request sent by the client is lost.
  2. When the client exchanges data with the server, closes, and immediately opens a new connection, if it uses the same port number as the previous connection, the server has no way to tell the previous connection's data from the new connection's data when they get mixed.
    • With Time wait, the old port is still in use even when a new connection is made, so the client assigns a new port number and the connections can be told apart.

ACK transmission scenarios

Sending only an ACK before the 3-way handshake is complete gets it treated as an abnormal packet:

Sending ACK directly without SYN 

클라이언트 → [ACK] → 서버
클라이언트 ← [RST] ← 서버  (연결 거부)
  • The server has no state information for that connection
  • Responds with an RST (Reset) packet → connection forcibly terminated

Sending ACK without receiving SYN-ACK 

정상: SYN → SYN-ACK → ACK
비정상: SYN → [패킷 손실] → ACK (잘못된 ACK 번호)
  • The server receives an unexpected ACK number
  • Handled with RST or ignored
  • The server waits for the SYN-ACK retransmission timeout

ACK with an invalid sequence number 

# 서버 입장에서의 검증
if received_ack_num != expected_seq_num + 1:
    # Invalid ACK
    send_RST()  # or ignore

Security perspective

Difference from a SYN Flood attack:

  • Sending only SYN and no ACK → server resource exhaustion
  • Sending only ACK → little impact, since the server immediately rejects it with RST

Firewall/IDS detection:

  • Detected as an abnormal TCP packet pattern
  • Blocked as possibly spoofed packets

Conclusion

An ACK that is not in the TCP connection state table is treated as an invalid packet, and no connection is established. The server sends an RST or ignores it.

Common types of TCP failures

Packet loss (Packet Loss)

A phenomenon in which data disappears because of network infrastructure problems or packet filtering by security equipment (firewalls)

  • Security issue - packet-filtering firewall

Reordering (Out-of-Order)

A phenomenon in which packets arrive in a mixed-up order while traveling along the transmission path.

Retransmission and Dup ACK

The concepts of retransmission and duplicate acknowledgement in TCP transmission are as follows.

Retransmission
When a packet is lost or arrives out of order during data transmission, the sender sends the data again. When the receiver signals that it did not receive the data properly, or when no acknowledgement (ACK) arrives within a certain time, the data is sent again for reliable communication
Dup ACK (Duplicate Acknowledgement)
A signal that occurs when the data in the expected order does not arrive and later data arrives first. For example, if the receiver is waiting for packet 6 and packet 7 arrives first, the receiver repeatedly sends an ACK saying it received everything up to 6 (in effect, signaling that 6 is missing), meaning "please resend packet 6". The sender detects packet loss from these duplicate ACKs

These phenomena are typical indicators that appear when packets are lost or reordered (Out-of-order), mainly because of network congestion or infrastructure problems.

Zero Window

A state in which the receiver's operating system buffer is full and cannot accept any more data. The root cause is usually processing delay in the application.

  • Buffer problem in the operating system's TCP implementation - very unlikely.
  • Clearly, it is very, very, very likely a logic error in the application.

How TCP sending/receiving works

  • Data processing flow: When a server and client exchange files, data is read from the file system into memory (buffers), then copied into TCP buffers, and passes through the network layers, split into segments for delivery
  • Encapsulation and decapsulation: Data travels packed in packets (parcel boxes), and at the L2 layer it is carried in frames (trucks). The receiver performs this process in reverse and reassembles the data
  • TCP control and latency: The receiver sends an 'ACK (Acknowledgement)' to confirm receipt, and through the window size (Window Size) it tells the sender how much free space is left in its receive buffer
  • Causes of performance problems: In many cases, rather than a problem with the network itself, the application reads data more slowly than the network receives it, so the window size runs out and data transmission is delayed

In conclusion, when a network failure occurs, you should not just check the network settings, but check whether the receiving program is processing data fast enough.

On the illusion of a TCP connection

Digs into the ambiguity and the reality of TCP's concept of being connection-oriented.

The essence of a TCP connection

TCP is called a 'connection-oriented' protocol, but no physical line is actually connected. The speaker defines this as an 'illusion' and explains that it is really just a procedure for exchanging policies and information with the other side

Using a phone call as an example, the speaker points out that a connection made without knowing for certain who the other side is can be vulnerable from a security standpoint

What the 3-Way Handshake means

The 3-Way Handshake performed for a TCP connection does not simply establish a connection; it is a process of exchanging the following essential information

  • Sequence Number: exchanging numbers used to reassemble data in order
  • Maximum Segment Size (MSS): agreeing on the maximum size of data that can be sent at once
  • Network congestion control and policies: confirming settings for responding to network conditions (e.g., whether SACK is used)

Conclusion

A TCP connection does not guarantee absolute safety; it is a procedure with vulnerabilities that can lead to security incidents. The speaker therefore stresses the importance of deeply understanding the basis of connections and how they work

Documentation

RFC 793
TRANSMISSION CONTROL PROTOCOL - RFC Documentation.

See also

Favorite site

Guide

FAQ

References

  1. Evans_Tech_Blog_-_header_of_tcp.pdf ↩

  2. Overview_of_TCP_flow_control_and_error_control_and_congestion_control_concepts.pdf ↩

  3. TCP_flow_control_and_error_control_and_congestion_control_example_scenarios.pdf ↩

  4. KLDP_-TCP_packet_loss-_64kb_large_data_write.pdf ↩

  5. RFC 5348 ↩

  6. Hellow_world-TCP_IP_Network_stack.pdf ↩

  7. Understanding TCP/IP Network Stack & Writing Network Apps ↩

  8. Kernel_Parameter_Decisions_for_TCP_Network_Performance_on_Linux_Servers_-Part_1-Meetup-_TOAST_Cloud.pdf ↩

  9. Kernel_Parameter_Decisions_for_TCP_Network_Performance_on_Linux_Servers_-Part_2-Meetup-_TOAST_Cloud.pdf ↩

  10. Kernel_Parameter_Decisions_for_TCP_Network_Performance_on_Linux_Servers_-Part_3-Meetup-_TOAST_Cloud.pdf ↩

author Zer0 sitemap