【网络工程】网络延迟优化：Nagle、TCP_NODELAY 与中断亲和

// Nagle 算法伪代码
if (有未确认的数据 && 新数据 < MSS) {
    // 等待，直到：
    // 1. 收到之前数据的 ACK，或
    // 2. 缓冲区累积到 MSS 大小
    buffer_data();
} else {
    send_immediately();
}

// 演示 Nagle + Delayed ACK 延迟的 C 代码
#include <sys/socket.h>
#include <netinet/tcp.h>
#include <time.h>

// 不设置 TCP_NODELAY（Nagle 默认开启）
// 分两次 write 发送数据
void send_with_nagle(int fd) {
    struct timespec start, end;
    char header[100] = "GET / HTTP/1.1\r\nHost: example.com\r\n";
    char body[200] = "...(body data)...";
    
    clock_gettime(CLOCK_MONOTONIC, &start);
    
    write(fd, header, strlen(header));  // 第一个小包
    write(fd, body, strlen(body));       // 第二个小包——被 Nagle 阻塞
    
    char response[4096];
    read(fd, response, sizeof(response));
    
    clock_gettime(CLOCK_MONOTONIC, &end);
    
    long latency_us = (end.tv_sec - start.tv_sec) * 1000000 +
                      (end.tv_nsec - start.tv_nsec) / 1000;
    printf("With Nagle: %ld μs\n", latency_us);
    // 可能输出：With Nagle: 40500 μs（多了 ~40ms）
}

// 禁用 Nagle 算法——每次 write 立即发送
int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

# Delayed ACK 的超时时间由内核常量控制
# TCP_DELACK_MIN = 40ms（Linux 默认）
# 无法通过 sysctl 修改，需要修改内核或使用 TCP_QUICKACK

# 使用 TCP_QUICKACK 临时禁用 Delayed ACK
# int flag = 1;
# setsockopt(fd, IPPROTO_TCP, TCP_QUICKACK, &flag, sizeof(flag));
# 注意：TCP_QUICKACK 只对下一个 ACK 生效，需要每次读取后重新设置

# 在 Go 中使用 TCP_QUICKACK
# conn.(*net.TCPConn).SetNoDelay(true) // TCP_NODELAY
# // TCP_QUICKACK 需要通过 syscall
# rawConn, _ := conn.(*net.TCPConn).SyscallConn()
# rawConn.Control(func(fd uintptr) {
#     syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP,
#         syscall.TCP_QUICKACK, 1)
# })

// TCP_CORK 的用法——用于批量组装数据后一次性发送
int cork = 1;
setsockopt(fd, IPPROTO_TCP, TCP_CORK, &cork, sizeof(cork));

// 分多次写入数据——不会发送
write(fd, header, header_len);
write(fd, body_part1, len1);
write(fd, body_part2, len2);

// 拔掉软木塞——立即发送所有缓冲数据
cork = 0;
setsockopt(fd, IPPROTO_TCP, TCP_CORK, &cork, sizeof(cork));

# 在 Nginx 中设置 TCP_NODELAY
# 默认已开启：tcp_nodelay on;

# 同时使用 TCP_NOPUSH（相当于 TCP_CORK）
# 在发送响应头+体时先 cork，全部写入后再 uncork
# tcp_nopush on;
# tcp_nodelay on;
# 两者可以同时开启——Nginx 会在发送最后一个数据块时自动 uncork

// 差：多次 write — 每次系统调用都有开销
write(fd, header, header_len);
write(fd, body, body_len);
write(fd, footer, footer_len);

// 好：使用 writev — 一次系统调用发送多个缓冲区
struct iovec iov[3] = {
    { .iov_base = header, .iov_len = header_len },
    { .iov_base = body,   .iov_len = body_len },
    { .iov_base = footer, .iov_len = footer_len },
};
writev(fd, iov, 3);

// 好：使用 sendmsg — 最灵活的发送接口
struct msghdr msg = {
    .msg_iov = iov,
    .msg_iovlen = 3,
};
sendmsg(fd, &msg, 0);

# 每次请求建立新连接的延迟开销：
# TCP 握手：1 RTT（SYN → SYN-ACK → ACK）
# TLS 握手：1-2 RTT
# 总计：2-3 RTT（跨大洲 ≈ 200-300ms）

# 使用连接池复用连接：
# 第一次请求：2-3 RTT（握手）+ 请求延迟
# 后续请求：直接请求延迟（0 RTT 握手开销）

# Go HTTP 客户端连接池配置
# transport := &http.Transport{
#     MaxIdleConns:        100,
#     MaxIdleConnsPerHost: 10,
#     IdleConnTimeout:     90 * time.Second,
# }

# DNS 解析可能增加 50-200ms 延迟
# 措施：

# 1. 本地 DNS 缓存（systemd-resolved）
systemd-resolve --statistics | grep "Cache"

# 2. 应用层 DNS 缓存
# Go：默认缓存 DNS 结果
# Java：-Dsun.net.inetaddr.ttl=60（缓存 60 秒）

# 3. 浏览器 DNS 预取
# <link rel="dns-prefetch" href="//api.example.com">

# 4. DNS 预热——程序启动时提前解析
# 在服务启动时异步解析所有依赖服务的域名

# 中断合并将多个包的中断合并为一次——减少 CPU 开销但增加延迟

# 查看当前设置
ethtool -c eth0
# rx-usecs: 50        # 接收中断延迟 50μs
# rx-frames: 64       # 或累积 64 帧后中断

# 延迟敏感场景——降低中断合并
ethtool -C eth0 rx-usecs 0 rx-frames 1
# 每个包都产生中断——延迟最低但 CPU 消耗最高

# 吞吐量优先场景——增加中断合并
ethtool -C eth0 rx-usecs 100 rx-frames 128

# 自适应中断合并（网卡根据负载自动调整）
ethtool -C eth0 adaptive-rx on

# Busy Polling 让应用线程主动轮询网卡
# 避免了中断 → 软中断 → 唤醒进程的延迟

# 全局配置
sysctl -w net.core.busy_poll=50       # epoll_wait 时轮询 50μs
sysctl -w net.core.busy_read=50       # 阻塞 read 时轮询 50μs

# Socket 级别配置（更精细）
# int poll_usecs = 50;
# setsockopt(fd, SOL_SOCKET, SO_BUSY_POLL, &poll_usecs, sizeof(poll_usecs));

# 效果测量
# 正常模式：RTT ~15μs（含中断+软中断延迟）
# Busy Poll：RTT ~5μs（但 CPU 100% 轮询）

# NAPI（New API）是 Linux 网络收包的核心机制
# 高负载时从中断切换到轮询，减少中断开销

# NAPI 的工作流程：
# 1. 网卡收到第一个包 → 触发硬中断
# 2. 硬中断处理程序 → 禁用网卡中断，调度 NAPI poll
# 3. 软中断中 NAPI poll → 批量从网卡取包
# 4. 处理完所有积压包 → 重新启用中断

# NAPI budget 参数
sysctl net.core.netdev_budget
# 默认 300 — 每次软中断最多处理 300 个包
# 增大可以提高吞吐量但可能增加单包延迟

sysctl net.core.netdev_budget_usecs
# 默认 2000（2ms）— 每次软中断最长处理时间

# curl 的 -w 选项可以输出各阶段的时间

curl -o /dev/null -s -w "\
DNS:        %{time_namelookup}s\n\
TCP:        %{time_connect}s\n\
TLS:        %{time_appconnect}s\n\
TTFB:       %{time_starttransfer}s\n\
Total:      %{time_total}s\n\
" https://example.com

# 典型输出：
# DNS:        0.012s
# TCP:        0.028s      ← TCP 握手完成
# TLS:        0.065s      ← TLS 握手完成
# TTFB:       0.120s      ← 首字节到达（含服务端处理）
# Total:      0.135s      ← 全部完成

# 各阶段计算：
# DNS 解析：12ms
# TCP 握手：28 - 12 = 16ms（1 RTT）
# TLS 握手：65 - 28 = 37ms（2 RTT）
# 服务端处理：120 - 65 = 55ms
# 数据传输：135 - 120 = 15ms

# 批量测试取平均
for i in $(seq 1 20); do
    curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com
done | awk '{sum+=$1; n++} END{printf "Avg TTFB: %.3fs\n", sum/n}'

# 在 Wireshark 中分析延迟

# 1. TCP 握手延迟
# 过滤：tcp.flags.syn == 1
# 测量 SYN 和 SYN-ACK 之间的时间差

# 2. 服务端处理延迟
# Statistics → TCP Stream Graphs → Time-Sequence (tcptrace)
# 或者看 HTTP 请求发完到响应第一个字节的间隔

# 3. 使用 tshark 批量分析
tshark -r capture.pcap -qz io,stat,1,"COUNT(tcp.analysis.ack_rtt)tcp.analysis.ack_rtt"

# 提取每个连接的 RTT
tshark -r capture.pcap -T fields -e tcp.analysis.ack_rtt \
    -Y "tcp.analysis.ack_rtt" | \
    awk '{sum+=$1; n++} END{printf "Avg RTT: %.3fms\n", sum/n*1000}'

# 服务端启用 TFO
sysctl -w net.ipv4.tcp_fastopen=3
# 1 = 客户端启用
# 2 = 服务端启用
# 3 = 两端都启用

# C 代码——服务端
# int qlen = 5;
# setsockopt(listen_fd, IPPROTO_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen));

# C 代码——客户端
# sendto(fd, data, len, MSG_FASTOPEN,
#        (struct sockaddr*)&server_addr, sizeof(server_addr));

# 验证 TFO 是否生效
cat /proc/net/tcp_fastopen_key
# 如果有密钥说明已启用

# 统计 TFO 使用情况
cat /proc/net/netstat | grep TFO
# TcpExt: ... TCPFastOpenActive TCPFastOpenPassive

# 发送缓冲区过大会导致 Bufferbloat——数据在缓冲区排队等待
# 结果：延迟增加、抖动增大

# 查看默认发送缓冲区
sysctl net.ipv4.tcp_wmem
# 4096  16384  4194304

# 对于延迟敏感应用，限制发送缓冲区
# int bufsize = 65536;
# setsockopt(fd, SOL_SOCKET, SO_SNDBUF, &bufsize, sizeof(bufsize));

# 注意：实际分配是设置值的 2 倍（内核开销）
# 设置 65536 → 实际 131072

# 检测 Bufferbloat

# 1. 在无负载时测量 RTT
ping -c 20 target | tail -1
# rtt avg = 10ms

# 2. 施加负载（iperf3 灌满带宽）
iperf3 -c target -t 60 &

# 3. 同时测量 RTT
ping -c 20 target | tail -1
# rtt avg = 300ms  ← 如果暴增，说明有 Bufferbloat

# 解决方案：使用 AQM（Active Queue Management）
# fq_codel 或 cake 队列规则
tc qdisc replace dev eth0 root fq_codel
# 或
tc qdisc replace dev eth0 root cake bandwidth 900mbit

# TLS 1.2 → 1.3 升级
# TLS 1.2：2 RTT 握手
# TLS 1.3：1 RTT 握手（0-RTT 恢复）

# Nginx TLS 优化配置
# ssl_protocols TLSv1.2 TLSv1.3;
# ssl_prefer_server_ciphers off;
# 
# # Session Ticket（避免完整握手）
# ssl_session_tickets on;
# ssl_session_timeout 1d;
# ssl_session_cache shared:SSL:50m;
# 
# # OCSP Stapling（避免客户端查询 OCSP）
# ssl_stapling on;
# ssl_stapling_verify on;
# resolver 8.8.8.8 1.1.1.1 valid=300s;

# 测量 TLS 握手延迟
curl -o /dev/null -s -w "TLS: %{time_appconnect}s, TCP: %{time_connect}s\n" \
    https://example.com
# TLS 握手时间 = time_appconnect - time_connect

# HTTP/1.1 的队头阻塞 → HTTP/2 多路复用

# HTTP/2 帧级多路复用
# 多个请求在同一连接上并行传输
# 消除了 HTTP 层的队头阻塞

# 但 HTTP/2 仍然有 TCP 层的队头阻塞：
# 如果一个包丢失，所有流都被阻塞

# HTTP/3 (QUIC) 解决了 TCP 队头阻塞：
# 每个流独立，丢包只影响单个流

# 延迟对比（丢包 1% 环境下）
# HTTP/1.1：基线延迟
# HTTP/2：P50 更低，但 P99 可能更高（TCP HoL）
# HTTP/3：P50 和 P99 都最低

# 1. 检查 Redis 是否开启了 TCP_NODELAY
redis-cli CONFIG GET tcp-nodelay
# "tcp-nodelay" "no"  ← 没开！

# 2. 检查网卡中断分布
cat /proc/interrupts | grep eth0
# 所有中断集中在 CPU 0

# 3. 检查是否有 Nagle 延迟
ss -tin dst :6379 | head -5
# 查看是否有未确认的小包

# 1. 开启 TCP_NODELAY
redis-cli CONFIG SET tcp-nodelay yes

# 2. 分散网卡中断
ethtool -L eth0 combined 4
# 设置 IRQ 亲和到不同 CPU
for i in $(seq 0 3); do
    irq=$(grep "eth0-TxRx-$i" /proc/interrupts | awk '{print $1}' | tr -d ':')
    [ -n "$irq" ] && echo $((i+2)) > /proc/irq/$irq/smp_affinity_list
done
# 避开 CPU 0（系统中断较多）和 CPU 1（Redis 进程）

# 3. 绑定 Redis 到固定 CPU
taskset -pc 1 $(pgrep redis-server)

# 结果：P99 从 10ms 降到 0.8ms

# 1. 确认网络 RTT
ping -c 20 remote_host
# rtt avg = 5ms  ← 网络正常

# 2. 用 curl 分解延迟
curl -o /dev/null -s -w "TCP=%{time_connect} TLS=%{time_appconnect}\n" \
    https://remote_host:443
# TCP=0.005 TLS=0.016  ← 握手正常

# 3. 抓包分析
tcpdump -i eth0 host remote_host -w grpc.pcap

# Wireshark 中发现：
# 每个 gRPC 请求后有 ~40ms 间隔
# 原因：客户端库分两次 write（header + body）
# Nagle 生效导致 40ms 延迟

# 在 gRPC 客户端配置 TCP_NODELAY
# Go gRPC 默认已启用 TCP_NODELAY

# 检查是否被覆盖
# grpc.Dial(target,
#     grpc.WithKeepaliveParams(keepalive.ClientParameters{
#         Time:    10 * time.Second,
#         Timeout: 3 * time.Second,
#     }),
# )

# 实际原因：自定义 HTTP/2 transport 覆盖了默认设置
# 修复后：平均延迟从 50ms 降到 8ms（5ms RTT + 3ms 处理）

# 金融交易系统的网络延迟优化栈

# 1. 硬件层
# - 直连光纤（无交换机延迟）
# - 网卡直通 SR-IOV（绕过 hypervisor）

# 2. 内核层
# - 内核旁路（DPDK / kernel bypass）
# - 或者 Busy Polling + 中断禁用
sysctl -w net.core.busy_poll=0      # 改为无限轮询
# CPU 核心隔离——避免调度器干扰
# isolcpus=2,3,4,5 在内核启动参数中

# 3. 应用层
# - 预分配内存，避免 GC
# - 无锁数据结构
# - 忙等待而非阻塞

# 4. 操作系统
# - 关闭透明大页（THP）
echo never > /sys/kernel/mm/transparent_hugepage/enabled
# - 关闭 NUMA 自动均衡
sysctl -w kernel.numa_balancing=0
# - 禁用 CPU 频率调节
cpupower frequency-set -g performance

# 结果：线到线（wire-to-wire）延迟 < 10μs

// 传统网络 I/O 路径：
// 1. epoll_wait()   → 系统调用，用户态→内核态切换
// 2. read()         → 系统调用
// 3. 处理数据
// 4. write()        → 系统调用
// 每个请求至少 3 次系统调用

// io_uring 路径：
// 1. 将 recv/send 操作提交到 SQ（Submission Queue）
// 2. io_uring_enter() 或轮询模式无需系统调用
// 3. 从 CQ（Completion Queue）读取结果
// 可以批量提交，减少系统调用到接近 0

# 检查内核是否支持 io_uring
cat /proc/version
# 需要 Linux 5.1+，推荐 5.19+

# io_uring 的性能优势在高频小包场景最明显
# 基准测试对比：
# epoll + read/write：~200K RPS（单线程）
# io_uring + SQ Polling：~400K RPS（单线程）
# 提升约 2 倍