Skip to main content

1. Introduction

1.1. Motivation​

Traditional TCP connection establishment requires a three-way handshake, which introduces at least one full round-trip time (RTT) latency before data transmission can begin. For many modern applications, particularly web services and mobile applications, this latency represents a significant performance bottleneck.

Latency Problem in Typical Scenarios​

In traditional TCP, a client must:

  1. Send a SYN packet
  2. Wait for the server's SYN-ACK response
  3. Send an ACK acknowledgment
  4. Finally send application data

This means application data transmission requires at least 1.5 RTT (assuming the server responds immediately after receiving the ACK).

Challenges of HTTP Short Connections​

For HTTP request-response patterns:

  • Each new connection requires a complete three-way handshake
  • For short connections (e.g., single API calls), handshake latency is a large proportion of total time
  • This problem is more severe in high-latency networks (such as mobile networks)

Example Latency Calculation:

  • 50ms RTT network: handshake latency = 50ms
  • 200ms RTT network (transcontinental): handshake latency = 200ms

For API calls returning small amounts of data, handshake latency may exceed actual data transmission time.

1.2. Key Concepts​

TCP Fast Open (TFO) solves this problem by allowing data exchange during the TCP handshake.

A TFO Cookie is an encrypted token used to validate client identity:

  1. Cookie Request Phase:

    • Client requests a TFO Cookie during initial connection
    • Server generates and returns a cookie (encrypted based on client IP address)
    • Client caches the cookie for subsequent use

  2. Fast Open Phase:

    • Client includes cookie and application data in the SYN packet
    • Server validates the cookie's validity
    • If validation passes, server accepts SYN data and can respond immediately

Performance Improvement​

Data transmission timeline with TFO:

  1. Initial Connection: Client sends SYN (requesting cookie)
  2. Subsequent Connections: Client sends SYN + Cookie + Data → Server processes immediately

Latency Reduction: Saves 1 full RTT

Security Design​

The TFO Cookie mechanism provides the following security protection:

  • Anti-Amplification: Limits SYN data packet size
  • Anti-Resource Exhaustion: Cookie validation ensures client identity
  • Backward Compatibility: Servers that don't support TFO will ignore the option

Terminology​

According to RFC 2119, keywords in this document have the following meanings:

  • MUST: Absolute requirement
  • SHOULD: Strongly recommended but may be ignored in specific circumstances
  • MAY: Completely optional feature

Use Cases​

TFO is particularly suited for:

  • Web Browsing: HTTP/HTTPS requests
  • API Calls: RESTful API, RPC
  • Mobile Applications: Frequent short connection requests
  • IoT Devices: Periodic data reporting

Limitations and Considerations​

When using TFO, note:

  • SYN data may be retransmitted (idempotency requirement)
  • Some network devices may interfere with TCP options
  • Cookies have expiration times and need periodic renewal

Next Section: 2. Protocol Overview will detail the TFO workflow and message exchange patterns.

Last updated on