Backend Performance Optimization - TCP Protocol Optimization

Problem Description
The TCP protocol is the cornerstone of Internet communication, but its default configuration may lead to performance bottlenecks in high-concurrency, high-latency, or poor network environments. Optimizing the TCP protocol can significantly improve network transmission efficiency, reduce latency, and lower resource consumption. This topic will delve into the key mechanisms of TCP (such as the three-way handshake, flow control, and congestion control) and explain how to improve the network performance of backend services through parameter tuning and architectural design.

Core Knowledge Points Breakdown

1. Performance Overhead and Optimization of the TCP Three-Way Handshake

   • Root Cause:
     Each TCP connection requires a "SYN → SYN-ACK → ACK" three-way handshake, consuming at least 1 RTT (Round-Trip Time). In short-lived connection scenarios (e.g., HTTP/1.0), frequent handshakes waste significant time.
   • Optimization Strategies:
     • Persistent Connection Reuse: Use HTTP/Keep-Alive or connection pools to avoid repeated handshakes.
     • TCP Fast Open (TFO): Allows carrying data in the initial SYN packet, reducing 1 RTT (requires client and server support).
     • Adjust Kernel Parameters (Linux example):

       # Increase the half-open connection queue (SYN queue) capacity to prevent connection failures due to SYN Flood attacks  
       echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog  
       # Enable SYN Cookies to mitigate flood attacks  
       echo 1 > /proc/sys/net/ipv4/tcp_syncookies  
       

2. Flow Control and Window Optimization

   • Principle:
     The sliding window mechanism coordinates the sending and receiving rates to prevent overwhelming the receiver. The window size is constrained by the receiver's rwnd (receive window) and the Bandwidth-Delay Product (BDP).
   • Bottleneck Analysis:
     • If rwnd is too small, the sender frequently waits for acknowledgments in high-latency links, reducing utilization (e.g., with 100ms latency and 1Gbps bandwidth, BDP ≈ 12.5MB, requiring a window ≥ 12.5MB to saturate the bandwidth).
     • The default window size may be only 64KB, insufficient for high-speed networks.
   • Optimization Methods:
     • Adjust Receive Window:

       # Set maximum receive window to 16MB  
       echo "net.ipv4.tcp_rmem = 4096 87380 16777216" >> /etc/sysctl.conf  
       sysctl -p  
       

     • Enable Window Scaling Option: Use the TCP Window Scale option to expand the window up to 1GB (requires mutual support).

3. Congestion Control Algorithm Selection

   • Default Algorithm Issues:
     CUBIC (Linux default) converges slowly in high-bandwidth, high-latency networks, leading to bandwidth waste.
   • Scenario-Based Selection:
     • BBR: Proposed by Google, dynamically adjusts sending rates based on bandwidth and latency estimates, suitable for high-bandwidth, high-packet-loss networks (e.g., video streaming, cross-border transmission).
     • CUBIC: Stable and reliable, suitable for general internet services.
   • Switching Algorithms:

     # Check current algorithm  
     sysctl net.ipv4.tcp_congestion_control  
     # Switch to BBR  
     echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf  
     sysctl -p  
     

4. TIME_WAIT Accumulation and Port Exhaustion

   • Cause:
     The active closing party enters the TIME_WAIT state (lasting 2MSL, e.g., 60 seconds). In high-concurrency, short-lived connection scenarios, this may exhaust all available ports.
   • Solutions:
     • Reuse TIME_WAIT Connections:

       # Allow reusing connections in TIME_WAIT state  
       echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse  
       # Fast recycling of TIME_WAIT connections (use with caution, may affect NAT networks)  
       echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle  
       

     • Expand Port Range:

       echo "60000 65535" > /proc/sys/net/ipv4/ip_local_port_range  
       

5. Buffer and Queue Tuning

   • Background:
     The kernel allocates send/receive buffers for each TCP connection. Default values may not suit high-load scenarios.
   • Adjustment Strategies:

     # Dynamically adjust buffer range (min/default/max)  
     echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_rmem  # Receive buffer  
     echo "4096 87380 16777216" > /proc/sys/net/ipv4/tcp_wmem  # Send buffer  
     # Auto-adjust buffer size  
     echo 1 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf  
     

Practical Case: Intra-Network Microservices Communication Optimization

• Scenario:
  A financial system's microservices cluster requires frequent cross-data-center calls (2ms latency). The original QPS was 5000, with a target of 20000.
• Optimization Steps:
  1. Replace HTTP short connections with gRPC persistent connections to reduce handshake overhead.
  2. Enable BBR congestion control to improve bandwidth utilization.
  3. Adjust the receive window to 8MB to match the Bandwidth-Delay Product (2ms × 10Gbps ≈ 2.5MB).
  4. Set tcp_tw_reuse=1 to prevent port exhaustion.
• Result:
  QPS increased to 21000, and average latency dropped from 15ms to 4ms.

Summary
TCP optimization requires targeted adjustments based on business scenarios (e.g., latency-sensitive or bandwidth-sensitive), while being cautious of side effects from parameter tuning (e.g., increased memory usage). It is recommended to validate results with stress testing tools (e.g., iperf) and deploy changes gradually in production environments.