叮叮叮，收到同事在群里发的故障问题，是一个网络连通性问题。工作中这种问题出现的频率最多了，觉得还是比较有意思，所以总结了一下整体过程分享给大家。
问题描述
业务环境是 K8s 容器平台，容器平台可以管理docker容器又可以管理qemu虚拟机。 发生故障的设备是一台Windows虚拟机，这台设备最终的目的是要出网访问互联网。
看到下图中使用 ping 223.5.5.5 主机 和 ping www.baidu.com 域名，检测后都是可以访问互联网的。唯独使用浏览器访问 www.baidu.com 域名时一直处于无法连接状态，环境中也不存在防火墙拦截、上网行为管理等其他网络限制问题。
继续尝试了下访问其他网站，又发现新的现象，结果 Bing 搜索可以打开，这也可以证明浏览器层面没有做限制。
现在只有浏览器访问百度、腾讯网等网站的时候一直处于连接超时， 随即通过 ping 针对这些网站测试连通性时现象也是正常的，也可排除不是dns解析等问题。
排查思路
通过表面排查固然不能有新的进展了，这里和大家分享下心得，遇到暂时瓶颈问题时不要着急，一定要保持清醒的思维，不要放弃，重新把问题思考！
刚刚说明网络中不存在限制，也使用ping检测都是正常，下面让我们回归网络的本质， 这里需要清楚的是浏览器访问网站它是一种应用层的网络访问，而ping只能检测到网络层面，按照OSI参考模型来讲，下面应该继续排查第四层传输层，也就是TCP协议，TCP连接特性大家都知道，三次握手机制。另外需要注意的是，以百度为例浏览器访问www.baidu.com 默认就会重定向至 https://www.baidu.com，这里面涉及HTTPS认证过程。
HTTPS建立认证过程，参考如下图
（图片来源于全栈安全）
下面进行抓包分析
这段报文源IP 10.30.1.11是windows主机出网口， 目的IP 39.156.70.239是百度服务器地址。
首先编号 6、7、8 报文完成TCP的三次握手包；
编号12、14是windows客户端发送的TLS Client Hello握手包，这里Wireshark 提示 [TCP segment of a reassembled PDU] 表示是TCP分段机制，当上层协议数据(如HTTP响应)超过 TCP MSS(Maximum Segment Size)时，TCP会自动将其分成多个段传输；
这里需要注意：TCP自动分片，最大的分片是1414字节，而在TCP握手包时MSS协商的最大TCP传输却是1460字节。
那这里1414字节的计算公式是 1414字节 =（以太帧(14字节) + IP头(20字节) + TCP头(20字节) + TCP payload(1360字节) ）
推测出 windows客户端本身MTU是 1500字节， 在网络经过的中间设备上，比如交换机或路由器，肯定MTU低于了1500字节，目前现象看中间设备是MTU是1400字节，导致没有按照协商的MSS进行分片。
编号 16 ，提示 [TCP Previous segment not captured]， Continuation Data 表示TCP 数据流中存在不完整或乱序的数据段。
编号 18，也提示TCP重传，可以明确此时已经开始丢包。
经过上面分析，接下来需要关注的地方是
- 大量重传：表明网络丢包严重
- 乱序分段：可能导致重组失败
- 重组失败：提示 "TCP Previous segment not captured"
目前重点怀疑的地方是MSS握手协商值与TCP分片存在差异问题。
查看windows客户端网卡MTU是1500字节， 这与抓包看到TCP握手协商值符合预期。
下面找到出网口设备，发现MTU值1400字节，那大概率就是这里进行分片处理后，发送网络包进行重组包导致失败的原因。
解决问题
最后将windows客户端MTU修改为1400 与 出网口设备MTU保持一致。
再次通过windows访问互联网成功。
技术文章持续更新，请大家多多关注呀~~
搜索微信公众号，关注我【 帽儿山的枪手 】
