1. 传输层协议基础TCP与UDP的江湖恩怨搞网络开发的兄弟们肯定都听说过TCP和UDP这对欢喜冤家。简单来说TCP就像个严谨的快递小哥必须亲手把包裹交到你手里还要你签字确认而UDP则像放飞自我的信鸽把信扔出去就不管了。我在实际项目中最深的体会是选错协议类型性能直接掉坑里。先看TCP的头部结构这玩意儿有20字节的固定首部关键字段我都整理在这张表里字段名位数作用说明源端口16发送方的应用进程端口号目的端口16接收方的应用进程端口号序列号32保证数据有序传输的唯一标识确认号32期望收到的下一个字节的序列号数据偏移4指出TCP报文段的数据起始处距离起始处有多远标志位6包含URG/ACK/PSH/RST/SYN/FIN六个控制位窗口大小16接收方当前允许发送的数据量校验和16校验首部和数据部分的完整性而UDP就简单粗暴多了首部只有8个字节源端口2字节目的端口2字节长度2字节校验和2字节实际抓包时有个坑要注意Wireshark默认会启用Relative sequence numbers相对序列号这会导致看到的序列号都是从0开始的简化值。建议在Preferences - Protocols - TCP里取消勾选这个选项才能看到真实的序列号。2. TCP三次握手从Wireshark看连接建立去年排查一个线上问题时我发现某服务接口的响应时间偶尔会突然飙高。用Wireshark抓包分析后发现有大量SYN包重传这就是典型的握手失败问题。下面带大家用Wireshark还原三次握手过程第一次握手客户端发送SYN1, seqx的报文No. Time Source Destination Protocol Length Info 1 0.000000 192.168.1.100 203.119.245.12 TCP 66 59374 → 80 [SYN] Seq0 Win64240 Len0第二次握手服务端回复SYN1, ACK1, seqy, ackx12 0.028145 203.119.245.12 192.168.1.100 TCP 66 80 → 59374 [SYN, ACK] Seq0 Ack1 Win29200 Len0第三次握手客户端发送ACK1, seqx1, acky13 0.028245 192.168.1.100 203.119.245.12 TCP 54 59374 → 80 [ACK] Seq1 Ack1 Win64240 Len0关键技巧在Wireshark过滤器中输入tcp.flags.syn1 and tcp.flags.ack0可以快速定位到SYN包。如果发现大量SYN包没有对应的SYNACK回复基本可以确定是服务端拒绝连接或网络不通。3. TCP流量控制滑动窗口的魔法遇到过文件上传特别慢的情况吗很可能就是窗口大小设置不合理。我做过一个实验在局域网内传输大文件时通过Wireshark的TCP Stream Graph - Window Scaling可以看到窗口大小的动态变化实际调优经验如果看到窗口经常降为0说明接收方处理不过来通过sysctl -w net.ipv4.tcp_window_scaling1启用窗口缩放适当增加接收缓冲区大小sysctl -w net.core.rmem_max16777216 sysctl -w net.ipv4.tcp_rmem4096 87380 167772164. TCP拥塞控制网络拥堵时的交警去年双十一大促期间我们的订单服务出现了间歇性超时。通过分析抓包数据发现大量超时重传和快速重传。TCP的拥塞控制算法主要有四种状态慢启动窗口指数增长拥塞避免窗口线性增长快速重传收到3个重复ACK时触发快速恢复重传丢失报文后直接进入拥塞避免调优建议# 启用BBR拥塞控制算法 echo net.ipv4.tcp_congestion_controlbbr /etc/sysctl.conf # 调整重传参数 sysctl -w net.ipv4.tcp_retries28 sysctl -w net.ipv4.tcp_syn_retries35. UDP协议分析快但不可靠的独行侠直播和视频会议这类应用最爱的就是UDP。我做过一个对比测试在同一网络环境下UDP的延迟比TCP低30%以上。但要注意几个问题MTU限制UDP包最好不要超过1472字节以太网MTU1500减去IP头20和UDP头8校验和虽然可选但强烈建议开启应用层重传对于重要数据需要自己实现确认机制用Wireshark分析DNS查询典型的UDP应用No. Time Source Destination Protocol Length Info 1 0.000000 192.168.1.100 8.8.8.8 DNS 74 Standard query 0x58ba A www.example.com6. 性能调优实战从抓包发现问题分享一个真实案例某次上线后API响应时间从50ms暴涨到2s。通过Wireshark分析发现大量TCP零窗口报文频繁出现报文重传握手阶段RTT时间异常最终定位是Nagle算法和延迟确认的冲突解决方案# 关闭Nagle算法根据实际情况谨慎使用 setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)flag, sizeof(int)); # 调整延迟确认参数 echo 1 /proc/sys/net/ipv4/tcp_delack_min7. 协议选型指南根据我的经验可以按照这个决策树来选择协议是否需要可靠传输 ├─ 是 → TCP └─ 否 → 是否对延迟敏感 ├─ 是 → UDP 应用层可靠性 └─ 否 → 考虑QUIC等其他协议最后提醒大家所有调优参数都要先做测试不同业务场景的最佳配置可能完全不同。建议用ab、wrk等工具做基准测试配合Wireshark观察实际效果。
EduCoder 计算机网络实验 传输层协议实战：从抓包到性能调优
发布时间：2026/7/16 1:51:15
1. 传输层协议基础TCP与UDP的江湖恩怨搞网络开发的兄弟们肯定都听说过TCP和UDP这对欢喜冤家。简单来说TCP就像个严谨的快递小哥必须亲手把包裹交到你手里还要你签字确认而UDP则像放飞自我的信鸽把信扔出去就不管了。我在实际项目中最深的体会是选错协议类型性能直接掉坑里。先看TCP的头部结构这玩意儿有20字节的固定首部关键字段我都整理在这张表里字段名位数作用说明源端口16发送方的应用进程端口号目的端口16接收方的应用进程端口号序列号32保证数据有序传输的唯一标识确认号32期望收到的下一个字节的序列号数据偏移4指出TCP报文段的数据起始处距离起始处有多远标志位6包含URG/ACK/PSH/RST/SYN/FIN六个控制位窗口大小16接收方当前允许发送的数据量校验和16校验首部和数据部分的完整性而UDP就简单粗暴多了首部只有8个字节源端口2字节目的端口2字节长度2字节校验和2字节实际抓包时有个坑要注意Wireshark默认会启用Relative sequence numbers相对序列号这会导致看到的序列号都是从0开始的简化值。建议在Preferences - Protocols - TCP里取消勾选这个选项才能看到真实的序列号。2. TCP三次握手从Wireshark看连接建立去年排查一个线上问题时我发现某服务接口的响应时间偶尔会突然飙高。用Wireshark抓包分析后发现有大量SYN包重传这就是典型的握手失败问题。下面带大家用Wireshark还原三次握手过程第一次握手客户端发送SYN1, seqx的报文No. Time Source Destination Protocol Length Info 1 0.000000 192.168.1.100 203.119.245.12 TCP 66 59374 → 80 [SYN] Seq0 Win64240 Len0第二次握手服务端回复SYN1, ACK1, seqy, ackx12 0.028145 203.119.245.12 192.168.1.100 TCP 66 80 → 59374 [SYN, ACK] Seq0 Ack1 Win29200 Len0第三次握手客户端发送ACK1, seqx1, acky13 0.028245 192.168.1.100 203.119.245.12 TCP 54 59374 → 80 [ACK] Seq1 Ack1 Win64240 Len0关键技巧在Wireshark过滤器中输入tcp.flags.syn1 and tcp.flags.ack0可以快速定位到SYN包。如果发现大量SYN包没有对应的SYNACK回复基本可以确定是服务端拒绝连接或网络不通。3. TCP流量控制滑动窗口的魔法遇到过文件上传特别慢的情况吗很可能就是窗口大小设置不合理。我做过一个实验在局域网内传输大文件时通过Wireshark的TCP Stream Graph - Window Scaling可以看到窗口大小的动态变化实际调优经验如果看到窗口经常降为0说明接收方处理不过来通过sysctl -w net.ipv4.tcp_window_scaling1启用窗口缩放适当增加接收缓冲区大小sysctl -w net.core.rmem_max16777216 sysctl -w net.ipv4.tcp_rmem4096 87380 167772164. TCP拥塞控制网络拥堵时的交警去年双十一大促期间我们的订单服务出现了间歇性超时。通过分析抓包数据发现大量超时重传和快速重传。TCP的拥塞控制算法主要有四种状态慢启动窗口指数增长拥塞避免窗口线性增长快速重传收到3个重复ACK时触发快速恢复重传丢失报文后直接进入拥塞避免调优建议# 启用BBR拥塞控制算法 echo net.ipv4.tcp_congestion_controlbbr /etc/sysctl.conf # 调整重传参数 sysctl -w net.ipv4.tcp_retries28 sysctl -w net.ipv4.tcp_syn_retries35. UDP协议分析快但不可靠的独行侠直播和视频会议这类应用最爱的就是UDP。我做过一个对比测试在同一网络环境下UDP的延迟比TCP低30%以上。但要注意几个问题MTU限制UDP包最好不要超过1472字节以太网MTU1500减去IP头20和UDP头8校验和虽然可选但强烈建议开启应用层重传对于重要数据需要自己实现确认机制用Wireshark分析DNS查询典型的UDP应用No. Time Source Destination Protocol Length Info 1 0.000000 192.168.1.100 8.8.8.8 DNS 74 Standard query 0x58ba A www.example.com6. 性能调优实战从抓包发现问题分享一个真实案例某次上线后API响应时间从50ms暴涨到2s。通过Wireshark分析发现大量TCP零窗口报文频繁出现报文重传握手阶段RTT时间异常最终定位是Nagle算法和延迟确认的冲突解决方案# 关闭Nagle算法根据实际情况谨慎使用 setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)flag, sizeof(int)); # 调整延迟确认参数 echo 1 /proc/sys/net/ipv4/tcp_delack_min7. 协议选型指南根据我的经验可以按照这个决策树来选择协议是否需要可靠传输 ├─ 是 → TCP └─ 否 → 是否对延迟敏感 ├─ 是 → UDP 应用层可靠性 └─ 否 → 考虑QUIC等其他协议最后提醒大家所有调优参数都要先做测试不同业务场景的最佳配置可能完全不同。建议用ab、wrk等工具做基准测试配合Wireshark观察实际效果。
