江山如画2022-02-07问题1: 从可用性角度分析，通过 iptables 修改 mss 只对 tcp 报文生效，对 udp 报文不生效。由于udp 报文传输时没有协商 mss 的过程，如果发现 udp 负载长度比 mtu 大，会交给网络层分片处理，分片传输途中只要有一个分片丢了，由于 udp 没有反馈给发送端具体是哪个分片丢了的能力，只能重新传整个包，传输效率会变低。 从运维角度分析，由于修改中间环节某个服务器的 iptables ，对于其它侧是透明的，可能会对定位问题带来困扰。 问题2: 遇到过 mtu 引发的问题。之前手动创建了虚拟网卡，和物理网卡之间做了流量的桥接，发现有些报文在二者之间转发时会被丢掉，分析发现虚拟网卡的 mtu 设置过大，并且报文 DF 位设置为了 1，通过 ifconfig 命令把虚拟网卡的 mtu 改小，报文就可以正常转发了。作者回复: 回答的很详细，很明显经过了仔细的思考，不是随便写的，不光为你的答案，我更要为你的学习态度点赞！ udp这部分，协议要求是udp载荷不要超过512字节，比常见MTU小很多，所以可能这个超出MTU的问题没有tcp那样严重。但是就像你说的，udp丢包的话，相应的容错和重传，协议栈本身是不做的，这就给应用程序提出了要求。 从运维角度分析的答案也很好，我也是很看重这一点：如果把配置“藏”在各个地方而其他人不知道，就等于是给其他运维和开发人员“埋雷”，我们应该尽量避免。
共 4 条评论18- Geek_9555062022-06-05Flow Graph 展示页的左下角有一个复选框 "limt to display filter"，勾上之后就只展示过滤的内容了，不需要再单独保存展示
作者回复: 多谢补充，工具的使用方面有很多小的细节：）
7 
张靳2022-02-12开始对[为什么有重复确认（DupAck）]这个小节标志位Dup ACK的两个报文是载荷为688和57的两个报文的确认报文不是很理解，在杨老师指导下豁然开朗，做一下我的理解记录： 最开始我对wirshark的符号有误解，我选中Dup ACK报文发现是7号报文（三次握手的ack报文）的重复确认（有两个对勾），我就以为是7号报文的确认报文，这个理解本身有问题，因为ack本身没有ack了，不然就没完没了了。查阅了Dup ACK的定义，当发现丢包或者乱序的时候接收方会收到一些Seq序列号比期望值大的包，每收到这种包就会ack一次期望的Seq值。 所以我们知道可能有丢包才会有重复确认，且确认得是对端发过来得报文。那么结合整个tcp流来看，发生重传得报文是没收到的，然后确认了688和57载荷得报文。作者回复: 很好，自己想明白了这知识就真的是你的了：）
3
Geek33402022-02-08老师，有一点不是很理解： 由于 Tunnel 1 比 Tunnel 2 的封装更大一些，所以服务端选择了不同的传输尺寸，一个是 1388，一个是 1348。 为啥会有这种选择呢，按照理解，MSS会自动从MTU-40来计算，不太理解为啥中间的IPIP隧道会影响到MSS的分段 经过LB的，1388 + 40(TCPIP) + IP(20) + IP(20) = 1468 不经过LB的，1348 + 40(TCPIP) + IP(20) = 1408 在本次案例中，以下命令能解决问题，应该如何理解呢？我理解1400应该是调整小了MSS到1400，但是之前的1388也没有超限呀，不理解： iptables -A FORWARD -p tcp --tcp-flags SYN SYN -j TCPMSS --set-mss 1400作者回复: 您好，图中tunnel1也是用在gz和bj服务器之间的，并不是仅仅在gz和bj lb之间。 第二个问题，mss改为1400是一个示例，并不是说当时这个案例就是用了这个数值。 有任何其他疑问也都可以提哈
共 5 条评论2
潘政宇2022-02-07杨老师，中间设备不是只是转发作用吗，协商mss也参与吗作者回复: 中间设备负责转发，但因为IP和TCP报文是不加密的，所以可以在中间环节修改这些转发报文的MSS字段，这就起到了让通信两端都按照修改后的MSS进行传输的效果。 理论上说，不光MSS，几乎其他任何IP头部和TCP头部字段都可以被中间设备修改。
共 2 条评论2
piboye2022-08-03 来自上海包的收发路径不一致的时候, MSS 协商是不是就失效了? 运营商网络, 如果出现链路调整, 之前协商的MSS 是不是也会可能失效了? 特别是长链接场景, 这种情况, 是不是要预先设置一个比较保守的值?作者回复: Linux对MSS会随时间发生变化这一点也是有机制来保护的，比如依赖PMTU报文进行调整。PMTU是网络设备会遵循的协议，当设备收到一个超过其MTU的报文时，一方面会丢弃，一方面会返回一个Destination Unreachable的ICMP消息，具体可以参考RFC 1191： https://www.rfc-editor.org/rfc/rfc1191 由于网络的复杂性，这种ICMP消息经常会被拦截，导致发送端压根不知道自己的报文因为MTU超限而被丢弃了，就会导致各种问题。 在已经知道有隧道的情况下，尽量设置合理的相对低的MTU值，是保障网络通信的一个经验。
1
Pantheon2022-02-22每一个字都值得分析,老师的课写的很棒,实战派作者回复: 谢谢支持，也希望大家坚持学习和反馈，通过这门课程，提升对网络的理解，和网络排查的水平~
1
志强2022-02-08老师有几个疑问请教： 问题1."我们选中 575 号报文"下边的图中Dup ACK报文是31号，"为什么是两个重复确认报文呢？我们把视线从 2 个 DupAck 报文往上挪"下边的图中dup ack 就变成了3号，是人为修改的还是怎么回事？ 问题2.有两次31号报文的dup ack，是因为收到了额外两次17号报文吧，有人肯能会问那为啥看不到17号报文的重传呢，这个我也不太清楚，可能是处理重传的位置在捕获抓包之后吧，要是在客户端抓包就能看到17号报文的重传，请老师指正 问题3.无论是握手的ack 还是数据的ack，这个ack是谁给回的，知道是内核给回复，具体哪一层的什么函数处理过后给回复的ack；kcp老师了解吗，是应用层在再给回复还是也是内核给的恢复 谢谢老师，期待您的详细解答作者回复: 关于这3个问题： 1. 你看到DupAck to从#31变成了#3，是因为截图的问题，#3那个是另外单独保存的抓包文件，所以编号不一样，但是TCP流确实是同一个。这个截图我们刚替换成统一#31的，也感谢你的细心！ 2. 这两次对#31报文的DupAck，只是因为握手之后的第一个数据报文（也就是1388字节那个）没有到客户端，但后面两个报文到了，所以客户端回复的两次ack号只能停留在握手结束的时候。这不是说客户端收到了两次SYN+ACK。DupAck的意思是：“我需要你那边跟这个ack号等值的seq号的报文”，而不是“我需要你再发一次我刚刚ack过的报文”，这里正好差了一个“身位”，你再想想？ 3. ack是内核协议栈回复的，你可以从github上git clone一下linux内核代码，然后在IDE里，搜一下TCPHDR_ACK在代码中的位置。大体上说，ACK标志位的设置是一类函数，比如SYN、FIN、RST（不含被动RST）、传输阶段等报文都是在各自不同的函数里面设置了ACK标志位，而它们的发送都会走到tcp_transmit_skb()来完成。 kcp没了解，也没用过:(
共 3 条评论1
janey2023-02-07 来自江苏MTU我看有的文章说是二层的，不知道到底算那层的？作者回复: MTU当然是三层的，属于IP报文的长度，一般是1500字节。
斯蒂芬.赵2023-01-11 来自山东不明白，如果传入的tcp载荷超过了mtu值，不应该根据mss值自动的分段么作者回复: 是的，不过这里的麻烦是由于很多网络限制，通信两端其实经常无法收到PMTU ICMP消息，也就导致无法及时调整MSS来适配网络状况，也是文中案例的诱因之一。