调整TCP窗口大小提升吞吐量
日常上网时，你有没有遇到过视频加载卡顿、大文件上传慢得像蜗牛？这些问题往往和传输层协议的配置有关。TCP作为主流的传输协议，默认的接收窗口可能只有64KB，面对高带宽延迟积（BDP）的网络链路，这个值明显不够用。适当增大TCP窗口，能让发送方在等待确认期间持续发送更多数据，提高链路利用率。
比如在跨城市的数据中心之间传备份文件，把窗口从默认值调到256KB甚至更大，实际测速能提升3倍以上。Linux系统中可以通过修改/etc/sysctl.conf来调整：
net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.ipv4.tcp_rmem = 4096 87380 262144
net.ipv4.tcp_wmem = 4096 65536 262144改完执行sysctl -p生效。别小看这几行配置，关键时刻能让内网同步效率翻个跟头。
启用选择性确认（SACK）减少重传浪费
传统TCP一旦丢包，即使后续数据已正确到达，也会要求从丢失位置开始全部重发。这就像快递掉了一件，结果整单重寄，明显不划算。SACK机制允许接收方告诉发送方“我收到了第3、4、5包，就差第2包”，发送方只补发第2包即可。
大多数现代操作系统默认开启SACK，但某些老旧设备或特殊网络环境下可能被关闭。检查Linux是否启用：
cat /proc/sys/net/ipv4/tcp_sack返回1表示已开。如果为0，可以用echo 1 > /proc/sys/net/ipv4/tcp_sack临时打开。这个功能在无线网络或跨国链路这种容易丢包的场景下特别实用。
合理设置拥塞控制算法
不同网络环境适合不同的拥塞控制策略。传统Reno在高延迟链路上反应迟钝，而Cubic更适合长肥管道（Long Fat Pipe）。如果你跑的是数据中心内部高速网络，试试BBR——Google推出的算法，主打主动探测带宽，避免过度依赖丢包信号。
查看当前使用的算法：
sysctl net.ipv4.tcp_congestion_control切换成BBR：
sysctl -w net.ipv4.tcp_congestion_control=bbr配合CDN推流或者云服务器对外服务时，换上BBR经常能看到更稳定的吞吐表现，直播推流卡顿率明显下降。
利用UDP优化实时业务传输
TCP追求可靠，但对语音通话、在线游戏这类应用来说，低延迟比完整数据更重要。这时候该考虑基于UDP自定义协议。WebRTC就是个好例子，它用UDP承载音视频流，即使偶尔丢帧也不影响整体流畅性。
自己开发时可以结合QUIC的思想，在应用层做轻量级可靠性保障，只对关键数据做重传，非关键部分直接跳过。比如游戏里玩家移动位置，新坐标到了，旧的自然失效，没必要死磕每条消息都送达。
连接复用减少握手开销
频繁建立短连接会带来大量SYN和ACK交互，HTTP/1.1的Keep-Alive、HTTP/2的多路复用都在解决这个问题。对于内部微服务通信，尽量复用已有TCP连接，避免每次请求都三次握手+四次挥手。
Nginx反向代理后端服务时，启用keepalive upstream能显著降低连接建立频率。配置示例：
upstream backend {
server 10.0.0.1:8080;
keepalive 32;
}
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}线上接口平均响应时间能压下来不少，尤其在高并发查询场景下效果突出。