TCP works by establishing a connection between two devices and delivering data as a reliable, ordered stream of bytes. It divides outgoing data into segments, tracks which bytes have been sent, uses acknowledgments to confirm reception, and retransmits missing data when necessary.
TCP also controls how much unacknowledged data can be in transit. This helps prevent a fast sender from overwhelming a slower receiver or contributing excessive traffic to a congested network.
When you load a website using HTTP/1.1 or HTTP/2 over TCP, these mechanisms help the browser and server exchange information despite packet loss, variable network delays, and changing connection conditions.
TCP does not determine the route packets take across the internet. Instead, it works with the Internet Protocol (IP), which carries TCP segments between network endpoints.
What Is TCP?
TCP stands for Transmission Control Protocol.
It is a transport-layer protocol used to exchange data between applications running on devices connected through IP networks.
According to RFC 9293, the IETF’s TCP specification, TCP provides applications with a reliable, in-order byte-stream service.
This description contains three important ideas.
Reliable: TCP detects missing or corrupted data and uses retransmission and other mechanisms to recover when possible.
In order: TCP presents received bytes to an application in the correct sequence, even if the underlying packets arrive out of order.
Byte stream: TCP carries a continuous sequence of bytes rather than preserving separate application-message boundaries.
TCP also uses port numbers to identify the applications or services involved in communication.
For example, a browser might establish a TCP connection to a server accepting HTTPS connections on port 443.
The browser and server can then exchange application data through that connection.
TCP is one part of the larger communication system explained in How Does the Internet Work?.
How Does TCP Work Step by Step?
Imagine opening a website that uses HTTP/2 over HTTPS.
Your browser needs to communicate with a remote server, and the connection uses TCP as its transport protocol.
Here is how TCP supports that communication.
Step 1: The Application Requests a Connection
When you enter a website address, your web browser identifies the destination and obtains the necessary network addressing information.
The browser then asks the operating system to establish a TCP connection to the remote endpoint.
A TCP connection is identified by the combination of its source and destination IP addresses and port numbers.
For example:
| Connection Detail | Illustrative Value |
|---|---|
| Client IP address | 192.0.2.10 |
| Client port | 52341 |
| Server IP address | 198.51.100.20 |
| Server port | 443 |
The IP addresses in this example belong to ranges reserved for documentation.
The source port helps distinguish the connection from other network conversations on the client.
The destination port identifies the server-side service.
The IP addressing system supports delivery between network endpoints, while TCP manages the communication between the corresponding transport endpoints.
Step 2: TCP Establishes the Connection
Before ordinary application data transfer begins, TCP typically establishes a connection using a three-way handshake.
The handshake uses three exchanges:
- The client sends a SYN segment.
- The server responds with a SYN-ACK segment.
- The client sends an ACK segment.
SYN stands for synchronize, while ACK stands for acknowledgment.
These exchanges synchronize initial sequence numbers and confirm that the endpoints can communicate.
They can also carry TCP options used to establish connection parameters.
A successful handshake places the connection into a state in which normal bidirectional data transfer can occur.
The handshake process is defined in RFC 9293.
Step 3: TCP Divides Data into Segments
After the connection is established, the application can provide data to TCP.
Suppose the browser needs to send an HTTP request.
TCP treats the application data as a sequence of bytes.
It packages portions of this byte stream into TCP segments.
Each segment includes a TCP header containing information needed to manage the connection.
The header can include sequence numbers, acknowledgment numbers, port numbers, control flags, and a receive-window value.
The operating system places the TCP segment inside an IP packet for transmission across the network.
The important relationship is:
Application Data → TCP Segment → IP Packet → Network Transmission
The segment is the TCP-layer unit. The IP packet carries it through the network.
A TCP segment is not necessarily the same size as an application request or response.
Step 4: IP Carries Segments Across the Network
Once the segment has been prepared, IP handles network-layer delivery.
The packet may travel through a home router, an internet service provider, and several other routers before reaching the destination.
Each router uses IP addressing and routing information to decide where to forward the packet.
This process is explained in How Does a Router Work?.
TCP does not normally instruct every intermediate router which route to select.
Nor does TCP require every segment to follow the same network path.
Different packets can encounter different delays, and some may arrive out of order.
Others may be lost because of congestion, transmission errors, or network failures.
TCP is designed to manage many of the consequences of this imperfect delivery environment.
Step 5: The Receiver Acknowledges Data
When the server receives valid TCP data, it tracks which bytes have arrived.
TCP uses acknowledgment numbers to communicate reception progress.
For example, suppose the server receives 500 bytes beginning at sequence number 1001.
Those bytes occupy sequence numbers 1001 through 1500.
The server can acknowledge that continuous sequence by indicating:
ACK = 1501
This means the receiver expects byte 1501 next.
The acknowledgment does not mean that the server must send a separate ACK for every byte or every segment.
TCP can acknowledge multiple bytes cumulatively.
The application receives the byte stream in sequence as the TCP implementation makes the data available.
Step 6: TCP Retransmits Missing Data
Network delivery is not perfect.
Suppose a TCP segment fails to reach its destination.
The receiver cannot acknowledge data it has not received.
The sender can detect suspected loss through mechanisms such as retransmission timeouts or acknowledgment feedback.
It then retransmits the missing data when appropriate.
This is one of the main reasons TCP is considered reliable.
For example, if bytes 1001–1500 arrive but bytes 1501–2000 are missing, the sender can retransmit the missing range.
TCP does not need the application to manually recreate the request simply because an individual network packet was lost.
However, the connection can still fail if communication cannot be restored.
TCP provides reliable delivery behavior while the connection remains usable; it does not guarantee that every transfer will finish successfully under all circumstances.
Step 7: TCP Adjusts the Sending Rate
TCP cannot simply send unlimited data as quickly as the application produces it.
The receiver has finite buffer space, and the network has finite transmission capacity.
TCP therefore uses two related mechanisms:
- Flow control: Prevents the sender from exceeding the receiver’s advertised capacity.
- Congestion control: Limits the amount of outstanding data to reduce the risk of overloading the network.
These mechanisms determine how much data the sender can transmit before receiving additional feedback.
The sender can adjust its transmission behavior as acknowledgments arrive and network conditions change.
This helps TCP operate across connections ranging from local networks to long-distance internet paths.
Step 8: TCP Closes the Connection
When the application has finished using the connection, TCP can close it in an orderly manner.
A normal shutdown commonly uses FIN and ACK control information.
FIN indicates that an endpoint has finished sending data in one direction.
Because TCP supports bidirectional communication, the two directions can close separately.
After the necessary exchanges and state transitions, the connection’s resources can be released.
A connection may also terminate abruptly through a reset or failure.
TCP therefore includes mechanisms for both ordinary shutdown and exceptional termination.
How Does the TCP Three-Way Handshake Work?
The TCP three-way handshake is one of the protocol’s defining mechanisms.
It allows two endpoints to synchronize connection state before normal data transfer.
Consider this simplified exchange.
| Exchange | Client Sends | Server Sends |
|---|---|---|
| 1 | SYN, Seq = 1000 | — |
| 2 | — | SYN-ACK, Seq = 5000, Ack = 1001 |
| 3 | ACK, Seq = 1001, Ack = 5001 | — |
These sequence numbers are illustrative. Real TCP connections select initial sequence numbers through implementation-defined mechanisms subject to the protocol’s requirements.
First Message: SYN
The client sends a segment with the SYN flag set.
It includes the client’s initial sequence number.
In the example, that number is 1000.
The SYN consumes one position in TCP’s sequence space.
Therefore, the first ordinary data byte from the client would begin at sequence number 1001.
Second Message: SYN-ACK
The server replies with a segment containing both SYN and ACK.
The ACK acknowledges the client’s SYN.
The server also provides its own initial sequence number.
In the example, the server uses sequence number 5000 and acknowledges the client with 1001.
The server’s SYN likewise consumes one sequence number.
Third Message: ACK
The client acknowledges the server’s SYN.
It sends:
Ack = 5001
The endpoints can now proceed with the established connection.
Why Does TCP Need Three Messages?
The handshake allows both endpoints to synchronize sequence numbering and exchange relevant connection information.
It also helps protect against confusion caused by delayed or duplicate connection attempts.
A two-message exchange would not provide the same confirmation that both endpoints have received the required synchronization information.
The standard three-way handshake also allows TCP options such as Maximum Segment Size, window scaling, and SACK permission to be negotiated where supported.
In a typical new connection, the handshake costs approximately one network round-trip time before normal application data can begin.
Special extensions and implementation behaviors can modify this timeline, but the three-way exchange remains the conventional TCP connection-establishment mechanism.
How Do TCP Sequence Numbers Work?
Sequence numbers allow TCP to track positions within a transmitted byte stream.
This is essential for detecting gaps, recognizing duplicate data, and reassembling information in the correct order.
A common misconception is that TCP assigns one sequence number to each packet.
TCP sequence numbers identify positions in a byte stream, not simply packet counts.
For example, suppose a sender begins transmitting application data at sequence number 1001.
| Segment | Starting Sequence Number | Data Length | Byte Range |
|---|---|---|---|
| A | 1001 | 500 bytes | 1001–1500 |
| B | 1501 | 500 bytes | 1501–2000 |
| C | 2001 | 500 bytes | 2001–2500 |
If all three segments arrive correctly and continuously, the receiver can acknowledge the data with:
ACK = 2501
This indicates that the next expected byte is 2501.
What Happens If Segments Arrive Out of Order?
Suppose the network delivers segment A, then segment C, while segment B is delayed.
The receiver has bytes 1001–1500 and 2001–2500.
However, bytes 1501–2000 are still missing.
The receiver’s cumulative acknowledgment therefore cannot advance beyond the missing region.
It can continue acknowledging:
ACK = 1501
A receiver may temporarily buffer the out-of-order data, depending on its implementation and available resources.
Once the missing bytes arrive, TCP can make the continuous stream available to the application.
The resulting application data is ordered even though the packets did not arrive in order.
Does TCP Preserve Application Messages?
No.
TCP presents applications with a byte stream.
Suppose an application sends two separate pieces of data.
The receiver might obtain both pieces through one read operation or receive one piece across several reads.
TCP does not promise that application write boundaries will be preserved.
Applications therefore need their own message-framing mechanisms when they must distinguish individual messages.
For example, an application protocol may use length fields, delimiters, or another structured format.
How Do TCP Acknowledgments Work?
TCP acknowledgments tell the sender how far the receiver has progressed through the ordered byte stream.
A conventional cumulative ACK identifies the next sequence number expected by the receiver.
For example:
ACK = 5001
means that all preceding bytes in the continuous sequence up to 5000 have been acknowledged.
It does not necessarily mean the receiver has finished processing those bytes at the application level.
The TCP implementation may have accepted them into its receive buffer.
What Are Duplicate ACKs?
A duplicate acknowledgment occurs when the receiver sends an ACK that does not advance the cumulative acknowledgment number.
This can happen when data arrives beyond a missing region.
Repeated acknowledgments can provide the sender with evidence that some data may be missing.
Traditional TCP loss-recovery mechanisms can use this feedback to retransmit data before a retransmission timer expires.
However, duplicate acknowledgments do not always mean a packet was lost.
Network reordering can sometimes produce similar behavior.
TCP implementations therefore use established algorithms and additional information to interpret loss signals.
What Is Selective Acknowledgment?
Selective Acknowledgment, or SACK, extends TCP’s acknowledgment capabilities.
Ordinary cumulative acknowledgments communicate the highest continuously received portion of the byte stream.
SACK allows a receiver to describe additional blocks of data that arrived successfully beyond a gap.
For example, the receiver might indicate that it has received bytes 2001–2500 even though bytes 1501–2000 are missing.
The sender can use this information to make better retransmission decisions.
The mechanism is specified in RFC 2018: TCP Selective Acknowledgment Options.
SACK is particularly valuable when several segments are lost within one transmission window.
It can help avoid unnecessary retransmission of data that has already arrived.
How Does TCP Detect and Recover from Packet Loss?
TCP uses acknowledgments, sequence numbers, timers, and loss-recovery algorithms to identify data that may not have reached the receiver.
Two important mechanisms are retransmission timeouts and acknowledgment-based loss detection.
Retransmission Timeout
TCP maintains a retransmission timer.
If the sender does not receive suitable acknowledgment feedback within the expected interval, it may retransmit outstanding data.
The retransmission timeout (RTO) is not simply one fixed value used for every connection.
TCP estimates network round-trip timing and adjusts the timer according to the applicable algorithm.
The IETF’s RFC 6298 specifies a method for computing and managing TCP retransmission timers.
A timer that is too short could cause unnecessary retransmissions.
A timer that is too long could delay recovery from genuine loss.
TCP therefore needs to balance responsiveness with the risk of interpreting ordinary delay as failure.
Fast Retransmission and Modern Loss Recovery
Some loss-recovery algorithms can infer missing data from patterns in acknowledgment feedback.
This allows retransmission before the RTO expires.
Traditional fast retransmit commonly uses repeated duplicate acknowledgments as an indication that data may have been lost.
Modern TCP implementations may also use more advanced recovery mechanisms and SACK information.
The exact algorithm varies by operating system and TCP implementation.
Does TCP Guarantee That No Data Will Be Lost?
TCP attempts to deliver a complete, ordered byte stream, but a TCP connection can fail.
For example, a persistent network outage can prevent recovery.
An endpoint may close unexpectedly, or the connection may be reset.
TCP cannot force an unreachable server to receive data.
Applications therefore still need appropriate error handling, timeouts, and recovery procedures.
TCP’s reliability means it uses mechanisms to detect problems and recover from recoverable loss—not that every communication is guaranteed to complete.
How Does TCP Flow Control Work?
Flow control prevents a sender from transmitting more unacknowledged data than the receiver is prepared to accept.
A receiving system has limited memory available for incoming TCP data.
If the sender transmits faster than the receiver can process or buffer information, the receive buffer could become overwhelmed.
TCP addresses this problem through a receive window, commonly abbreviated as rwnd.
The receiver advertises how much additional data it is willing to accept.
The sender uses that information when deciding how much data may remain outstanding.
Example of TCP Flow Control
Suppose a receiver advertises that it can accept 16,000 additional bytes.
The sender must respect that receive-window limit.
As the receiver acknowledges data and frees buffer capacity, it can advertise additional space.
If the receiver’s available window becomes zero, the sender generally stops transmitting ordinary new data until permitted to continue.
TCP includes window-probing mechanisms to handle the possibility that a window-opening update is lost.
This prevents a connection from remaining stalled solely because the sender did not receive a window update.
What Is TCP Window Scaling?
The basic TCP window field is 16 bits.
Without an extension, this limits the directly advertised receive window to 65,535 bytes.
Such a limit can restrict throughput on high-bandwidth, high-latency paths.
The TCP Window Scale option allows compatible endpoints to represent much larger receive windows.
Window scaling is negotiated during connection establishment.
The mechanism is defined in RFC 7323: TCP Extensions for High Performance.
Window scaling is especially useful when a connection needs to keep large amounts of data in flight to use available network capacity efficiently.
How Does TCP Congestion Control Work?
Flow control protects the receiver.
Congestion control protects the network from excessive sending rates.
These mechanisms solve different problems.
A receiver might have enough memory to accept a large amount of data, while an intermediate network link has limited available capacity.
If the sender transmits too aggressively, routers and network equipment may experience growing queues and packet loss.
TCP uses congestion-control algorithms to adjust how much data can be outstanding.
What Is the Congestion Window?
The sender maintains a congestion window, commonly called cwnd.
It represents a limit on the amount of data that can remain unacknowledged according to the congestion-control algorithm.
Unlike the advertised receive window, the congestion window is maintained internally by the sender.
The sender’s effective outstanding-data limit is constrained by both mechanisms.
Conceptually:
Allowed outstanding data ≲ min(receive window, congestion window)
The TCP congestion-control specification, RFC 5681, describes this relationship.
What Is TCP Slow Start?
When a new connection begins, the sender generally does not know how much capacity is available across the network path.
Slow start allows TCP to probe the available capacity by increasing the amount of data in flight as acknowledgments confirm delivery.
Despite its name, slow start can grow the congestion window rapidly.
Under traditional acknowledgment-driven behavior, the window can approximately double over successive round-trip times during this phase.
Slow start is not designed to remain active indefinitely.
The sender eventually changes its behavior according to thresholds, congestion indications, and the selected control algorithm.
What Happens During Congestion Avoidance?
During congestion avoidance, TCP generally increases its sending allowance more cautiously.
If the network indicates congestion, the sender can reduce its congestion window.
Traditional algorithms commonly interpret packet loss as a congestion signal.
Other algorithms may use additional measurements, and Explicit Congestion Notification (ECN) can allow compatible networks to signal congestion without necessarily discarding packets.
The detailed response depends on the chosen congestion-control algorithm.
What Are TCP Reno and CUBIC?
TCP congestion control is not one immutable algorithm.
Reno is associated with classic loss-based congestion-control behavior.
CUBIC uses a cubic function to control the growth of its congestion window and is designed for efficient operation across a range of network conditions, including high-capacity paths.
CUBIC is specified in RFC 9438.
Different operating systems and configurations can use different algorithms.
Therefore, explaining slow start and congestion avoidance describes important TCP behavior, but it does not mean every implementation adjusts its congestion window in exactly the same way.
What Is the TCP Sliding Window?
The sliding-window concept describes how TCP allows multiple bytes to be transmitted before their acknowledgments arrive.
Without pipelining, a sender would transmit a small piece of data, wait for an acknowledgment, and only then transmit the next piece.
That would waste substantial capacity on paths with long round-trip delays.
TCP instead allows a suitable amount of data to remain in flight.
As acknowledgments arrive, the sender’s permitted transmission range advances.
This is why it is called a sliding window.
For example:
- The sender transmits several TCP segments within the permitted window.
- The receiver acknowledges successfully received byte ranges.
- The sender recognizes that some outstanding bytes have been acknowledged.
- The available sending range advances, allowing more data to be transmitted.
The size and movement of this window are influenced by receive-window information, congestion control, and other protocol state.
Sliding-window operation is central to TCP’s ability to maintain throughput without waiting for a separate acknowledgment after every segment.
What Is Inside a TCP Segment?
A TCP segment contains a TCP header and, when present, application data.
The header includes fields used to identify the connection and manage transmission.
| TCP Header Field | Function |
|---|---|
| Source Port | Identifies the sending transport endpoint |
| Destination Port | Identifies the receiving transport endpoint |
| Sequence Number | Identifies a position in the transmitted byte stream |
| Acknowledgment Number | Identifies the next sequence number expected, when ACK is set |
| Data Offset | Indicates the TCP header length |
| Flags | Communicate connection and control information |
| Window | Advertises receive-window information |
| Checksum | Detects certain transmission errors |
| Urgent Pointer | Supports TCP’s urgent-data mechanism |
| Options | Carry additional capabilities and parameters |
The full TCP header format is defined in RFC 9293.
What Do TCP Flags Mean?
Several TCP control flags are particularly useful for understanding connection behavior.
| Flag | Main Meaning |
|---|---|
| SYN | Synchronizes sequence numbers during connection establishment |
| ACK | Indicates that the acknowledgment field is valid |
| FIN | Indicates the sender has finished sending data |
| RST | Resets a connection |
| PSH | Requests prompt delivery of data toward the receiving application |
| URG | Indicates that the urgent pointer is significant |
TCP also has control bits related to Explicit Congestion Notification.
Flags are not separate application messages by themselves.
They are fields within TCP segments that help endpoints coordinate the connection.
What Does the TCP Checksum Protect?
The TCP checksum helps detect accidental corruption affecting the segment.
It covers the TCP header, data, and specified pseudo-header information derived from IP.
The receiving endpoint verifies the checksum.
However, a checksum is not a cryptographic authentication mechanism.
It cannot provide the confidentiality, integrity guarantees against deliberate tampering, or authentication properties of TLS.
A valid TCP checksum does not prove that the sender is trustworthy.
How Does TCP Decide the Size of a Segment?
TCP does not necessarily place all application data into one segment.
It must consider limits imposed by the network and connection.
One important parameter is the Maximum Segment Size (MSS).
MSS describes the maximum amount of TCP payload data a peer is willing to receive in a segment under the applicable conditions.
The MSS option can be exchanged during the connection handshake.
Another related concept is the Maximum Transmission Unit (MTU), which describes a maximum network-layer packet size supported by a link or path context.
For example, a conventional Ethernet link often uses an MTU of 1,500 bytes.
For an IPv4 packet without additional IP or TCP options:
- IPv4 header: 20 bytes.
- TCP header: 20 bytes.
- Available TCP payload: 1,460 bytes.
This is a simplified example, not a universal MSS value.
IPv6, additional headers, tunneling, and other network features can change the calculation.
The sender’s packetization also depends on implementation behavior.
The important relationship is that MSS concerns TCP payload size, while MTU concerns the packet size supported at a lower networking layer.
How Does TCP Close a Connection?
A TCP connection supports communication in both directions.
Therefore, closing one direction does not automatically mean that the other direction must stop immediately.
A normal connection shutdown uses FIN and ACK exchanges.
For example:
- The client sends FIN to indicate that it has no more data to transmit.
- The server acknowledges the FIN.
- The server finishes sending its remaining data and sends its own FIN.
- The client acknowledges the server’s FIN.
This is a common four-segment illustration.
The actual exchanges may differ because FIN and ACK information can sometimes be combined.
One endpoint may also temporarily continue receiving after it has stopped sending.
This is called a half-closed connection.
TCP maintains connection states that coordinate shutdown and protect against problems involving delayed packets.
For example, an endpoint may remain in TIME-WAIT after a normal close.
A reset using RST is different from an orderly FIN-based shutdown. It terminates connection state abruptly under the applicable protocol rules.
What Is the Difference Between TCP and UDP?
TCP and UDP are transport-layer protocols, but they provide different services.
TCP establishes connections and offers ordered, reliable byte-stream delivery.
UDP provides a connectionless datagram service without TCP’s built-in acknowledgment, retransmission, or ordered-delivery mechanisms.
| Feature | TCP | UDP |
|---|---|---|
| Connection model | Connection-oriented | Connectionless |
| Data model | Ordered byte stream | Individual datagrams |
| Reliability mechanisms | Acknowledgments and retransmission | Not provided by UDP itself |
| Delivery ordering | Provided for the byte stream | Not guaranteed |
| Flow control | Built into TCP | Not provided by UDP itself |
| Congestion control | Required for TCP | Not supplied by UDP itself |
| Header size | At least 20 bytes | 8 bytes |
| Typical applications | Many web connections, file transfer, email protocols | DNS exchanges, real-time applications, QUIC transport |
UDP is not simply an inferior version of TCP.
Some applications benefit from controlling timing, retransmission, and message boundaries themselves.
For example, a real-time application may prefer to process recent information rather than wait for recovery of every missing piece of older information.
Other protocols use UDP as a foundation and add their own reliability and security mechanisms.
The detailed differences are explained in How Does UDP Work?.
How Do HTTP and HTTPS Use TCP?
TCP is a transport protocol.
HTTP is an application-layer protocol.
They solve different problems.
HTTP defines requests, responses, methods, headers, and status codes.
TCP provides a reliable, ordered byte stream over which certain versions of HTTP can communicate.
For example, HTTP/1.1 commonly operates over TCP.
HTTP/2 also commonly uses TCP, with TLS protection for standard browser HTTPS deployments.
HTTPS uses TLS to provide encryption, integrity protection, and authentication.
In a conventional HTTPS connection over TCP, the relationship is:
HTTP → TLS → TCP → IP
However, not every modern HTTPS connection uses TCP.
HTTP/3 uses QUIC over UDP.
QUIC provides its own reliable-stream and congestion-control capabilities.
This means HTTP/3 can deliver reliable HTTP communication without using TCP as its transport protocol.
The distinction is specified in RFC 9114: HTTP/3.
Why Does HTTP/3 Use QUIC Instead of TCP?
HTTP/2 can multiplex multiple streams within one connection, but when those streams share TCP, a lost TCP packet can delay delivery of data on other HTTP/2 streams.
This is a form of transport-level head-of-line blocking.
QUIC provides separate reliable streams whose delivery progress can be less tightly coupled when a packet is lost.
HTTP/3 uses those capabilities while retaining familiar HTTP request-and-response semantics.
This does not mean QUIC eliminates packet loss or that HTTP/3 always performs better.
It uses a different transport architecture to manage the consequences of network conditions.
For a deeper explanation, see How Does QUIC Work?.
Does TCP Encrypt Your Data?
No.
TCP provides transport features such as reliable delivery, ordering, flow control, and congestion control.
It does not inherently encrypt the application data transmitted through the connection.
A TCP connection can carry plaintext application data or encrypted data supplied by another protocol.
For example:
Unencrypted HTTP over TCP: HTTP content is not protected by TLS.
HTTPS over TCP: TLS encrypts and authenticates HTTP communication before TCP transports it.
The distinction is important because reliability and security are separate properties.
A correctly functioning TCP connection may deliver every byte in the proper order without protecting the content from an observer along the network path.
TLS addresses important confidentiality, authentication, and integrity requirements that TCP does not provide.
Why Can TCP Affect Internet Speed?
TCP performance depends on how quickly data can be transmitted, acknowledged, and recovered.
Several factors matter.
Round-Trip Time
Round-trip time (RTT) is the time it takes for information to travel to the remote endpoint and for feedback to return.
Higher RTT can increase the time required for connection setup and affect how quickly congestion-control mechanisms increase the sending window.
Packet Loss
Lost data may need to be retransmitted.
Packet loss can also cause some congestion-control algorithms to reduce the amount of outstanding data.
This can lower throughput even when the physical link has substantial capacity.
Receive-Window Size
If the receive window is too small for the connection’s bandwidth and RTT, the sender may be unable to keep enough data in flight to use the available capacity.
Window scaling helps support larger receive windows.
Congestion Window
The congestion-control algorithm limits how aggressively TCP can send data.
This protects the network but can also constrain throughput when the sender is recovering from congestion or probing for additional capacity.
Bandwidth-Delay Product
A useful way to understand high-speed TCP connections is the bandwidth-delay product.
It represents how much data would need to be in flight to fully utilize a path at a given rate and round-trip time.
For example, consider an illustrative connection with:
- Available bandwidth: 100 Mbps.
- Round-trip time: 100 milliseconds.
The bandwidth-delay product is:
100,000,000 bits/second × 0.1 second = 10,000,000 bits
That equals approximately 1.25 MB of data in flight.
This does not mean TCP must always maintain exactly that amount, nor does it guarantee that the connection can achieve 100 Mbps.
It illustrates why large receive and congestion windows can matter on high-bandwidth, high-latency paths.
A fast physical connection alone is not enough. TCP must also be able to maintain suitable amounts of outstanding data under the prevailing network conditions.
Does TCP Guarantee That an Application Receives Every Message?
Not unconditionally.
TCP provides reliable byte-stream transfer while its connection remains operational.
But several limitations remain.
A connection can fail before all data is delivered.
An application may stop running.
The destination can close the connection unexpectedly.
And TCP acknowledgments indicate acceptance of data by the receiving TCP implementation, not necessarily that an application permanently saved or processed the information.
For example, a server might acknowledge data and then crash before writing it to a database.
The TCP acknowledgment does not guarantee that the database operation succeeded.
Applications that require stronger assurances need their own mechanisms, such as transaction confirmation, durable storage, and appropriate retry behavior.
This distinction is essential when discussing reliable networking.
TCP reliability concerns transport delivery. Application-level success is a separate requirement.
TCP Makes Unreliable Networks Useful for Reliable Communication
TCP works by establishing a connection, organizing data as a sequence of bytes, and tracking the progress of transmission between two endpoints.
Sequence numbers preserve order. Acknowledgments report reception. Retransmission recovers missing data when possible. Flow control protects the receiver, while congestion control manages the amount of traffic sent into the network.
These mechanisms allow applications to communicate over IP networks where individual packets may be delayed, reordered, corrupted, or lost.
TCP does not choose the complete network route, encrypt application data by itself, or guarantee that every application operation succeeds.
Its essential contribution is more specific and powerful: it turns an imperfect packet-delivery service into a reliable, ordered byte stream that applications can use.