网络基础回顾：TCP/IP协议栈、UDP与TCP对比、网络延迟的构成
各位同学好，我是老张。今天咱们聊点基础，但别小看基础——我见过太多性能调优的坑，最后都栽在基础不牢上。网络协议栈这东西，说白了就是数据从你的应用跑到对方机器上的那条路。你想想看，路都不熟，怎么谈优化？
TCP/IP协议栈：数据包的奇幻漂流
先说说TCP/IP协议栈。我个人习惯把它理解成「四层快递系统」：
- 应用层：你写的代码，比如HTTP、WebSocket。这层只管「我要发什么」。
- 传输层：TCP或UDP。这层决定「怎么发、要不要确认」。
- 网络层：IP协议。这层负责「往哪发、走哪条路」。
- 链路层：网卡、网线、Wi-Fi。这层是「物理上怎么传」。
我在项目中遇到过一个问题：某金融系统的交易延迟突然飙升。查了半天，发现是应用层直接操作了原始套接字，绕过了传输层的优化机制。嗯，这里要注意——每一层都有它的职责，别乱跳层。
核心观点：低延迟调优，本质就是让数据在每一层都「快进快出」。哪一层慢了，你就盯着哪一层优化。
UDP与TCP对比：选错协议，延迟翻倍
很多新手问我：「老张，低延迟场景是不是无脑选UDP？」我的回答是：不一定。咱们来掰扯掰扯。
| 特性 | TCP | UDP |
|---|---|---|
| 连接建立 | 三次握手，有延迟 | 无连接，零握手 |
| 可靠性 | 确认重传，保证到达 | 尽最大努力，可能丢包 |
| 流量控制 | 有滑动窗口 | 无，应用自己控制 |
| 头部开销 | 20-60字节 | 8字节 |
| 适用场景 | 网页、文件传输、数据库 | 实时音视频、游戏、监控 |
我曾经在一个实时行情推送项目里，一开始用了TCP。结果发现行情数据稍微一波动，TCP就开始重传、拥塞控制，延迟直接飙到几十毫秒。后来换成UDP，配合应用层的丢包补偿逻辑，延迟稳定在1毫秒以内。说白了，TCP的可靠性是用延迟换来的，你如果不需要100%可靠，就别为它买单。
我的建议：如果你的数据可以容忍偶尔丢一两个包，比如视频帧、游戏状态同步，大胆用UDP。如果是转账、下单这种丢一个包就出大事的场景，老老实实用TCP，或者自己在UDP上实现可靠传输。
网络延迟的构成：四个「堵点」
做低延迟调优，你得先知道延迟从哪来。我把它拆成四个部分：
- 传播延迟：光速在光纤里跑的时间。北京到上海大约1000公里，光速是20万公里/秒，算下来单程5毫秒。这个你改不了，除非你把服务器搬到用户隔壁。
- 处理延迟：路由器、交换机、服务器CPU处理数据包的时间。这个可以优化——比如用DPDK绕过内核协议栈，或者用更快的CPU。
- 排队延迟：数据包在路由器或交换机缓冲区里排队等转发。这是最常见的延迟杀手。我曾经遇到一个案例，某交换机缓冲区满了，一个包排队等了200毫秒才出去。
- 传输延迟：数据从网卡发到线路上的时间。取决于带宽和数据量。比如1Gbps网卡发1500字节的包，大约需要12微秒。
避坑指南：我曾经以为延迟高就是带宽不够，结果花了十几万升级带宽，问题依旧。后来一查，是排队延迟在作祟——交换机缓冲区配置不合理。所以，先定位再优化，别瞎花钱。
为什么会这样？因为很多人只盯着「带宽」和「延迟」这两个词，却不知道延迟内部还有这么多门道。你想想看，如果你连延迟是哪一段造成的都不知道，你怎么优化？
注意：不要一上来就改内核参数。我见过有人把TCP缓冲区改得巨大，结果排队延迟反而更高了。先测量，再动手。用ping测传播延迟，用tcpdump看排队延迟，用perf看处理延迟——数据说话。
好了，这一章的基础就讲到这里。记住一句话：低延迟调优，不是玄学，是科学。搞清楚协议栈怎么工作，搞清楚延迟从哪来，你才能有的放矢。下一章咱们聊聊实际调优工具，到时候我会带几个真实案例来拆解。
公众号:蓝海资料掘金营，微信deep3321