TCP/IP Reference Model

The TCP/IP model consists of four layers that handle different aspects of network communication:

• Link Layer: Handles IP packet encapsulation and de-encapsulation, manages ARP/RARP message transmission and reception
• Network Layer: Responsible for routing packets and directing them toward their destination network or host
• Transport Layer: Handles packet fragmentation and reassembly, wrapping data into TCP or UDP protocol format
• Application Layer: Provides services to end users through protocols like HTTP, FTP, Telnet, DNS, and SMTP

OSI Seven-Layer Model

Data Flow Through the OSI Layers

The OSI model describes both the encapsulation process (data traveling downward from Application to Physical layer) and the de-encapsulation process (data traveling upward from Physical to Application layer).

Downward Encapsulation: When data moves from sender to receiver, it passes through each layer starting at the Application layer. Each layer appends its own header information containing layer-specific controls and metadata. The Transport layer adds port numbers, the Network layer adds IP addresses, and so forth.

Upward De-encapsulation: Upon reaching the receiver, data flows upward starting from the Physical layer. Each layer strips away its corresponding header, processes the information, and passes the payload to the layer above. The Transport layer uses port numbers to deliver data to the correct application, while the Network layer validates destination addresses.

Data Link Layer

Switches

Switches enable VLAN (Virtual Local Area Network) segmentation. Devices within the same VLAN can communicate directly, while inter-VLAN communication requires routing. By default, all ports belong to VLAN 1.

Network Layer

SNAT and DNAT

Network Address Translation (NAT) operates primarily at the Network layer, typically implemented on routers and NAT gateways.

Source NAT (SNAT): When a client using a private IP address (such as 192.168.x.x) needs to communicate on the public internet, the NAT gateway translates the private source address to a public IP. For instance, a request originating from 192.168.1.2 gets translated to a public IP like 203.0.113.1 before reaching the internet.

Destination NAT (DNAT): When requests arrive at a server's edge device (load balancer, firewall), the public destination IP gets translated to an internal private server address for load balancing or security purposes. A request targeting 123.456.78.90 might be translated to an internal address like 10.0.0.1.

NAT Benefits: The finite public IPv4 address space necessitates address sharing. NAT allows multiple devices to share a single public IP, alleviating address scarcity. Additionally, private IP addresses are unreachable from the public internet, providing inherent firewall protection for local networks.

Routers

Routers segment broadcast domains, preventing broadcast storms from propagating across the entire network. They divide networks into distinct subnets, whereas switches within an LAN share the same IP subnet.

UDP Protocol

UDP (User Datagram Protocol) handles packet transmission alongside TCP but operates without connection establishment. Positioned at the Transport layer (Layer 4), above IP, UDP lacks built-in packet grouping, assembly, and sequencing capabilities. Once sent, UDP provides no confirmation of delivery or integrity.

UDP packets consist of an 8-byte header and a data section (maximum 65,535 bytes total). The header contains source and destination ports.

Characteristics

1. Connectionless UDP bypasses the connection setup phase required by TCP. Data can be transmitted immediately without handshaking. UDP acts as a simple datagram搬运工, performing no segmentation or concatenation.

At the sender, the Application layer passes data to UDP, which adds only its header before delivering to the Network layer. At the receiver, UDP strips the IP header and passes data directly to the Application layer without modification.

2. Multicast Capabilities UDP supports unicast, multicast, and broadcast transmission modes, enabling one-to-one, one-to-many, many-to-many, and many-to-one communication patterns.

3. Message-Oriented UDP preserves application-layer message boundaries. It neither merges nor splits messages, simply adding its header and passing data to IP. Applications must select appropriately sized messages.

4. Unreliable Delivery The connectionless nature guarantees no reliability guarantees. UDP transmits data without confirmation, provides no backup, and shows no concern for successful delivery. Without congestion control, UDP maintains constant transmission rates regardless of network conditions. While this causes packet loss during poor connectivity, it suits real-time applications like video conferencing where speed matters more than perfect accuracy.

5. Minimal Header Overhead UDP headers contain:

• Source and destination port numbers (16 bits each, source port optional)
• Total datagram length
• Checksum (optional in IPv4) for error detection

The compact 8-byte header (versus TCP's minimum 20 bytes) makes UDP highly efficient for data transmission.

Achieving Reliability Over UDP

Since UDP lacks reliability mechanisms, applications must implement their own:

• Acknowledgment and Retransmission: Receivers send ACK packets confirming receipt. Senders retransmit after timeout if acknowledgments don't arrive, with configurable retry limits
• Flow and Congestion Control: Dynamic rate adjustment based on network conditions
• Checksum and Correction: Error detection via checksums, optionally with Forward Error Correction (FEC) to recover corrupted packets
• Sequence Management: Numbering packets at the sender and reassembling them in order at the receiver, handling duplicates and out-of-order delivery

TCP Protocol

TCP (Transmission Control Protocol) establishes reliable, connection-oriented, byte-stream communication between devices. When computers need to exchange data reliably—such as loading web pages or retrieving emails—TCP ensures complete, ordered delivery. File downloads require the entire content, not fragments, making reliability essential.

Characteristics

Connection-Oriented TCP establishes connections via a three-way handshake before transmitting data, ensuring reliable communication.

Unicast Only Each TCP connection connects exactly two endpoints, supporting only point-to-point communication.

Byte-Stream Delivery TCP transmits data as a continuous byte stream without preserving application message boundaries, unlike UDP's message-oriented approach.

Reliable Transmission TCP assigns sequence numbers to each byte transmitted. Receivers acknowledge successful receipt with ACK packets indicating the next expected byte. Unacknowledged data within the round-trip time gets retransmitted automatically.

TCP tracks exactly what was sent, what was received, and what remains outstanding, guaranteeing ordered delivery without errors.

Congestion and Flow Control TCP reduces transmission rates when network congestion is detected, preventing network overload.

Full-Duplex Communication Both endpoints can transmit simultaneously. Each side maintains buffers for temporary data storage. TCP can send segments immediately or buffer data for batch transmission, with maximum segment size determined by MSS.

Limitations

Head-of-Line Blocking TCP's head-of-line blocking occurs at the packet level—the next segment cannot be delivered to the application until the preceding segment arrives. HTTP's head-of-line blocking operates differently, occurring at the request-response level where subsequent requests wait for preceding ones to complete.

Comparison Summary

TCP delivers connection-oriented, reliable service; UDP provides connectionless, unreliable service. UDP sacrifices accuracy for speed, making it suitable for real-time applications. TCP suits scenarios requiring data integrity over transmission speed.

TCP Connection Establishment and Termination

Key TCP Header Flags and Fields

• Sequence Number: 32-bit field numbering each byte in the TCP byte stream
• Acknowledgment Number: Indicates the next expected byte from the peer
• ACK Flag: Confirms acknowledgment field validity (1=valid, 0=invalid)
• SYN Flag: Initiates connection establishment (SYN=1 indicates connection request)
• FIN Flag: Signals complete data transmission and requests connection release
• RST Flag: Forces immediate connection termination
• PSH Flag: Directs receiver to deliver data immediately to the application without buffering

Three-Way Handshake

Per TCP specification, ACK segments may carry data but don't consume sequence numbers when they don't.

1. Client initiates: Client sends a SYN segment containing its initial sequence number (ISN), transitioning to SYN_SENT state. SYN segments consume a sequence number even without data.

2. Server responds: Server sends SYN-ACK containing its ISN and acknowledgment number (client ISN + 1). Server enters SYN_RCVD state. The acknowledgment number confirms receipt of the client's SYN. If the server doesn't receive client acknowledgment, it retransmits SYN-ACK with exponential backoff (1s, 2s, 4s, 8s...), eventually removing the half-open connection from its queue.

3. Client confirms: Client sends ACK with acknowledgment number (server ISN + 1), transitioning to ESTABLISHED. Server enters ESTABLISHED upon receiving the ACK, completing the handshake.

Why Three Handshakes?

Two handshakes insufficient: A delayed connection request arriving late could cause servers to establish invalid connections upon receiving spurious SYN-ACK packets, wasting resources. Three handshakes prevent invalid connection establishment when the delayed client request never receives acknowledgment.

Verifying bidirectional capability: First handshake confirms client transmission and server reception. Second confirms server transmission and client reception, though server cannot yet verify client's receiving capability. Third completes verification.

Mitigating SYN Flood: Attackers spoofing numerous nonexistent IPs attempting SYN flooding would find two handshakes sufficient to exhaust server resources. The third handshake reduces attack effectiveness since attackers won't complete acknowledgment.

Four handshakes unnecessary: Three exchanges suffice to verify send/receive capabilities; additional handshakes provide diminishing returns.

Data Carrying During Handshake: Only the third handshake can carry data. The first two cannot—if they carried data, attackers could flood servers with large SYN packets consuming excessive memory and processing. The third handshake occurs in ESTABLISHED state with confirmed server capabilities.

Dynamic ISN: The ISN exchanges during handshakes prevent sequence number prediction attacks. Fixed ISNs would allow attackers to guess subsequent acknowledgment numbers. Each connection generates a new ISN.

Connection Identification: Servers identify connection attempts via source IP, source port, sequence number, and acknowledgment number carried in TCP headers.

Four-Way Connection Termination

FIN segments consume sequence numbers even without data.

1. Initiator sends FIN: Client sends FIN=1 segment, transitioning to FIN_WAIT_1 (half-close state—cannot send, only receive)

2. Peer acknowledges: Server sends ACK, entering CLOSE_WAIT. Client receives ACK and transitions to FIN_WAIT_2

3. Peer sends remaining data and FIN: Server transmits any outstanding data, then sends FIN=1, entering LAST_ACK

4. Initiator confirms: Client sends ACK, transitioning to TIME_WAIT. After waiting 2 MSL (Maximum Segment Lifetime), the connection closes completely.

Why 2 MSL Wait? First MSL ensures the final ACK reaches the peer. Second MSL ensures the peer's retransmitted FIN reaches the initiator if the original ACK was lost. This prevents delayed packets from a closed connection being misinterpreted as new connection data.

Why Four Terminations, Not Three? Merging ACK and FIN into one segment would risk premature closure if one endpoint still has data to transmit.

Troubleshooting TIME_WAIT Accumulation: High volumes of short-lived connections generate TIME_WAIT states. NAT devices and load balancers may extend connection retention. Frequent port reuse between the same source-destination pair increases TIME_WAIT occurrence. Diagnose using netstat or ss commands. Solutions include connection pooling, persistent connections, and adjusting TIME_WAIT duration.

Connection Queues and SYN Flood Defense

Half-Open Queue: When server receives SYN and responds with SYN-ACK, the connection enters SYN_RCVD state in the half-open (SYN) queue awaiting final acknowledgment.

Accept Queue: After completing three-way handshake, completed connections wait in the accept queue before applications consume them.

SYN Flood Attack: Attackers flood servers with SYN packets from spoofed IPs, filling the half-open queue and exhausting resources. Servers repeatedly retransmit SYN-ACK without receiving final handshakes. Mitigation strategies include increasing queue capacity, reducing SYN-ACK retransmission attempts, and SYN Cookie technology—generating cryptographic cookies during SYN handling instead of allocating resources, verified upon final handshake.

Full Server Capacity Responses:

• Silent timeout: Server ignores SYN, client retransmits until timeout
• Connection rejection: Server sends RST, client immediately receives rejection error

TCP Fast Open (TFO)

TFO reduces latency by enabling data transmission during the handshake:

1. Initial handshake: Client sends SYN with potential TFO cookie request
2. Server responds: Instead of immediate SYN-ACK, server computes and returns a SYN Cookie in the Fast Open option
3. Client caches: Client stores the cookie for future connections
4. Subsequent handshakes: Client sends SYN + cached cookie + HTTP request together
5. Server verification: Server validates cookie; if valid, immediately processes and responds with data

This permits HTTP response generation before completing the three-way handshake, saving one RTT.

TCP Timestamps

Timestamp option format: kind (1 byte) + length (1 byte) + info (8 bytes), where kind=8, length=10, info contains timestamp and timestamp echo (4 bytes each).

RTT Calculation: When A sends to B, timestamp records A's sending time. B's response includes both B's timestamp and the echoed A timestamp. Upon receiving the response, A calculates RTT as current time minus echoed timestamp.

Sequence Number Wraparound Prevention: Sequence numbers wrap from 2^32-1 back to 0. Without timestamps, delayed packets with identical sequence numbers could be mistaken for new transmissions. Timestamps distinguish packets since different sending times produce different values.

Retransmission Timeout (RTO)

TCP retransmits unacknowledged segments after timeout. RTO dynamically adjusts based on round-trip time estimates.

Classic Method: Maintains smoothed RTT (SRTT) updated with each measurement:

srtt = α × previous_srtt + (1 - α) × current_rtt

With α typically 0.8-0.9. RTO calculation:

rto = min(upper_bound, max(lower_bound, β × srtt))

Where β = 1.3-2.0. This method performs poorly when RTT varies significantly.

Standard Method (Jacobson/Karels):

srtt = (1 - α) × srtt + α × rtt    // α = 1/8
rttvar = (1 - β) × rttvar + β × |rtt - srtt|    // β = 1/4
rto = μ × srtt + ∂ × rttvar    // μ = 1, ∂ = 4

This algorithm incorporates RTT deviation, providing better sensitivity to network fluctuations.

TCP Reliability Mechanisms

• Sequence/Acknowledgment Numbers: Bytes are numbered sequentially; ACKs indicate next expected byte, detecting and recovering lost packets
• Retransmission: Unacknowledged data triggers retransmission using exponential backoff for timeout adjustment
• Out-of-Order Detection: Reassembles reordered packets and discards duplicates
• Error Detection/Correction: Checksums detect corruption; FEC can correct errors
• Flow Control: Sliding window limits unacknowledged data based on receiver buffer capacity
• Congestion Control: Strategies including slow start, congestion avoidance, fast retransmit, and fast recovery prevent network overload

Flow Control

TCP buffers transmitted and received data. Flow control regulates transmission based on receiver buffer capacity.

Sliding Window

TCP implements two windows: send window and receive window.

Send Window limits unacknowledged data. The window slides forward upon acknowledgment, removing acknowledged data and adding new data. Window size equals min(rwnd, cwnd). Cumulative ACKs confirm all prior bytes.

The send window comprises four regions:

• Sent and acknowledged
• Sent but unacknowledged
• Not sent but transmissible
• Not sent and cannot transmit

Receive Window determines maximum data before acknowledgment. Receivers advertise available buffer space via rwnd, adjusting dynamically.

Flow Control Process

Assume both endpoints initialize windows to 200 bytes:

1. Sender transmits 100 bytes, reducing usable window by 100
2. Receiver processes only 40 bytes due to load, leaving 60 in buffer
3. Receiver shrinks window by 60 (200 → 140), advertising new size
4. Sender adjusts send window accordingly
5. Acknowledged section increases by 40 bytes

Congestion Control

Flow control addresses receiver capacity but ignores network conditions. Congestion control responds to network issues.

On Congestion Detection:

• Multiplicative decrease: Set ssthresh to half current cwnd
• Slow start restart: Reset cwnd to initial value (typically 1 MSS)

State Variables:

• Congestion Window (cwnd): Sender's transmission capacity
• Slow Start Threshold (ssthresh): Transition point between algorithms

Congestion Window vs Receive Window

Receive window restricts the sender based on receiver capacity; congestion window restricts based on network capacity. Actual send window equals min(rwnd, cwnd).

Slow Start

Beginning transmission without knowing network conditions requires conservative behavior to prevent congestion collapse.

1. After handshake, initialize cwnd to 1-2 MSS
2. Each ACK received increases cwnd by 1 MSS (doubling each RTT)
3. Upon reaching ssthresh, transition to congestion avoidance

Congestion Avoidance

Once approaching capacity:

• Previously cwnd increased by 1 per ACK; now increases by 1/cwnd per ACK
• Each RTT adds only 1 MSS instead of exponential growth

Fast Retransmit

Out-of-order packets trigger duplicate ACKs for the last in-order byte. Receiving three duplicate ACKs strongly indicates packet loss:

Example: Segment 5 lost
- Segments 6, 7 arrive but generate ACK 4
- Three duplicate ACKs trigger immediate retransmission of segment 5
- No waiting for RTO timeout

Selective Acknowledgment (SACK)

SACK allows receivers to specify wich segments arrived, enabling selective retransmission of only missing segments. The SACK option in ACK headers uses left/right edges to report received ranges.

Fast Recovery

After fast retransmit:

• ssthresh = cwnd / 2
• cwnd = ssthresh
• cwnd grows linearly

Nagle's Algorithm and Delayed ACK

Sending many small packets (1 byte at a time) creates excessive overhead. Nagle's algorithm optimizes this:

• First packet transmits immediately
• Subsequent data waits until:
  • Packet reaches MSS size, or
  • All prior ACKs arrive

Delayed ACK: Multiple arriving packets can share acknowledgment. Instead of ACK-ing each packet immediately, receivers delay up to 500ms (typically under 200ms) to combine acknowledgments.

Delayed ACKs cannot be used when:

• Receiving large packets requiring window updates
• TCP in quickack mode
• Detecting out-of-order packets

TCP Keep-Alive

Connection failures from network issues or crashes remain undetected without application-level awareness. Keep-alive probes idle connections:

sudo sysctl -a | grep keepalive

# Check interval: 7200 seconds
net.ipv4.tcp_keepalive_time = 7200
# Maximum probes: 9
net.ipv4.tcp_keepalive_probes = 9
# Probe interval: 75 seconds
net.ipv4.tcp_keepalive_intvl = 75

The 2-hour probe interval suits detecting long-dormant connections but cannot promptly detect recent failures.

TCP Checksum Reliability

TCP uses checksum validation—summing transmitted bytes and comparing with received sum. This provides only basic integrity checking, making it unsuitable for security-sensitive applications. TLS supplements TCP's transport reliability with data confidentiality and stronger integrity guarantees.

TCP Timers

Retransmission Timer: Triggered upon segment transmission. If ACK doesn't arrive within timeout, segment retransmits. Timeout dynamically adjusts to network conditions.

Persistence Timer: Prevents deadlock when receiver advertises zero window. Upon expiration, sender probes for updated window size.

TIME_WAIT Timer: Ensures final ACK delivery and clears delayed packets after connection termination.

Keep-Alive Timer: Monitors idle connection health. Probes sent after idle period; connection closes after configured probe failures.

Forward Error Correction (FEC)

FEC enables error correction without retransmission by adding redundant information:

Encoding: Sender generates error-correcting codes (Hamming codes, Reed-Solomon) adding parity/check bits before transmission.

Decoding: Receiver uses redundancy to detect and correct errors within the code's capability.

FEC works effectively under moderate noise but fails when errors exceed correction capacity, necessitating retransmission fallback.

Noise Sources:

• Thermal noise from electronic components
• Electromagnetic interference (EMI/RFI)
• Channel effects (attenuation, multipath propagation)
• Quantization noise during analog-digital conversion
• Inter-symbol interference

Bypassing the 6-Connection Limit

Browsers limit concurrent connections per hostname. Solutions include:

• Domain Sharding: Distribute resources across multiple subdomains, each permitting 6 connections
• HTTP/2: Multiplexing enables multiple requests over single connections
• Resource Optimization:
  • Merge multiple CSS/JS files
  • Use sprite sheets for images
  • Inline small stylesheets and scripts in HTML

TCP Segmentation and Reassembly

Sticky and Split Packets

Issues arise at the transport layer but require application-layer solutions.

Sticky Packets: Multiple application messages combine into single TCP segments, obscuring message boundaries.

Split Packets: Single application message divides acros multiple TCP segments, requiring reassembly.

Root Cause: TCP operates as a byte stream without inherent message boundaries. Network conditions, buffer management, and protocol optimizations cause merging or splitting.

Solutions:

• Length Prefix: Include message length in header
• Fixed-Length Messages: Pad shorter messages to uniform size
• Delimiter: Use unambiguous boundary markers
• Switch to UDP: Maintains message boundaries naturally