【网络协议实战】从Wireshark抓包看TCP/UDP的可靠与高效

1. Wireshark抓包环境搭建与基础操作第一次接触Wireshark时我被这个能看见网络流量的工具震撼到了。记得当时为了排查一个简单的网页打不开的问题打开Wireshark后突然发现原来我的电脑每秒钟都在和数十个服务器窃窃私语下面我就带大家从零开始搭建这个神奇的观测窗口。安装过程非常简单官网下载对应版本后一路Next即可。但有几个实用技巧值得注意在Windows平台建议勾选Install Npcap in WinPcap API-compatible mode选项这对老旧程序兼容性更好安装完成后记得重启系统否则可能无法识别网卡首次启动时如果遇到找不到接口的错误通常是以普通用户权限运行导致用管理员身份启动即可抓包界面的核心区域分为三部分顶部是数据包列表显示捕获到的每个数据包摘要中间是协议解析树像解剖图一样展示数据包各层细节底部是原始字节数据适合进阶分析我常用的几个快捷键CtrlE 开始/停止捕获CtrlK 清空当前捕获CtrlF 搜索数据包内容鼠标中键 快速滚动到指定位置过滤是Wireshark的灵魂功能。有次排查问题我面对上万条数据包手足无措直到同事教我用了这个过滤表达式tcp.port 80 and ip.addr 192.168.1.100瞬间就锁定了目标流量。常用的过滤条件还有http只看HTTP流量tcp.flags.syn1筛选TCP连接请求!arp排除ARP广播包2. TCP三次握手与四次挥手实战解析去年优化公司API响应速度时我通过Wireshark发现了一个典型问题客户端频繁创建短连接导致大量时间消耗在TCP握手阶段。让我们通过抓包看看这个过程。当你在浏览器输入网址时背后发生的第一个关键动作就是TCP三次握手。用Wireshark抓取访问百度时的流量会看到这样的对话客户端发送SYN1, Seq0的报文第一次握手服务端回复SYN1, ACK1, Seq0, Ack1的报文第二次握手客户端发送ACK1, Seq1, Ack1的报文第三次握手这个过程中有几个关键细节初始序列号(Seq)是随机生成的实际抓包看到的不是0ACK号总是对端Seq1窗口大小(Win)字段表示接收缓冲区容量四次挥手的过程则更加有趣。有次我们的服务异常重启导致大量连接没有正常关闭。通过抓包发现主动关闭方发送FIN1的报文第一次挥手被动方立即回复ACK第二次挥手被动方处理完数据后发送FIN第三次挥手主动方回复ACK第四次挥手这里有个常见误区很多人以为ACK和FIN必须分开发送。实际上如果被动方没有待发送数据是可以合并第二次和第三次挥手的称为FIN-ACK包。我在测试环境抓到的这个包就很典型Transmission Control Protocol, Src Port: 443, Dst Port: 53568 Flags: 0x011 (FIN, ACK) Acknowledgment: 13. TCP可靠传输机制深度剖析去年双十一大促期间我们的订单服务出现了少量数据错乱。通过分析生产环境抓包最终定位到是TCP重传机制导致的。让我们看看TCP如何保证可靠性。序列号和确认号是TCP可靠性的基石。在Wireshark中观察文件传输过程你会发现每个包的Seq表示这个包数据部分的起始字节位置Ack表示期望收到的下一个字节位置如果收到乱序包接收方会重复发送之前的Ack滑动窗口控制是另一个精妙设计。有次调优时我注意到这样一个现象Window size value: 1024 [Calculated window size: 262144] [Window size scaling factor: 256]这说明开启了窗口缩放选项TCP Window Scale实际窗口大小是1024*256262144字节。通过这个机制TCP可以动态适应网络状况。重传机制最令人印象深刻。有次网络抖动时我抓到了这样的序列客户端发送Seq1, Len1000超时未收到ACK客户端重传相同Seq和Len的包服务端回复Ack1001Wireshark会智能识别重传在Info列显示[TCP Retransmission]。对于快速重传收到3个重复ACK立即重传则会显示[TCP Fast Retransmission]。4. UDP高效传输特性详解去年开发实时语音系统时我们果断选择了UDP协议。通过Wireshark对比可以清晰看到两者的差异。一个典型的DNS查询UDP协议数据包长这样User Datagram Protocol, Src Port: 55321, Dst Port: 53 Source Port: 55321 Destination Port: 53 Length: 45 Checksum: 0x2ba8 [unverified]与TCP相比UDP头部只有8字节极其精简。没有序列号、确认号、窗口等字段这就是它高效的秘密。但高效也意味着需要自己处理可靠性。有次我们遇到语音卡顿问题抓包发现Frame 1: UDP 58 bytes from 192.168.1.2:5000 → 192.168.1.3:6000 Frame 2: UDP 58 bytes from 192.168.1.2:5000 → 192.168.1.3:6000 Frame 3: UDP 58 bytes from 192.168.1.2:5000 → 192.168.1.3:6000三个完全相同的包这是因为应用层实现了简单的重传机制。Wireshark的Expert Info会提示Duplicate frame。多播是UDP的另一个优势。在抓取视频会议流量时可以看到Ethernet II, Src: 00:1a:2b:33:44:55, Dst: 01:00:5e:7f:ff:fa Internet Protocol Version 4, Src: 192.168.1.100, Dst: 239.255.255.250 User Datagram Protocol, Src Port: 1900, Dst Port: 1900这里的目地MAC地址以01:00:5e开头目地IP是239.x.x.x说明这是个多播包。TCP根本无法实现这种一对多通信。5. TCP与UDP的适用场景对比在物联网网关开发中我们同时用到了TCP和UDP。通过大量实践我总结出它们的适用场景TCP更适合文件传输需要确保每个字节都准确送达网页浏览依赖有序的数据流数据库连接需要长时间保持连接典型案例是HTTPS流量。抓取访问银行的流量会看到Transmission Control Protocol Sequence Number: 1 Acknowledgment Number: 1 Header Length: 32 bytes Flags: 0x018 (PSH, ACK) Window: 2048 [Calculated window size: 262144] [Window size scaling factor: 128]这里有PSH标志表示立即推送数据窗口缩放使得吞吐量更大。UDP更适合视频会议容忍少量丢包DNS查询简单快速物联网传感器数据低功耗需求比如抓取智能家居设备的流量User Datagram Protocol Source Port: 12345 Destination Port: 54321 Length: 23 Checksum: 0x8821 [unverified]只有基础信息没有任何冗余字段这对电池供电的设备至关重要。混合使用案例也很有趣。我们的日志收集系统同时使用TCP传输关键业务日志确保不丢失UDP传输调试信息量大可容忍丢失通过Wireshark可以清晰看到两种流量的区别TCP有复杂的握手和确认UDP则是简单的发了就不管。