前言
又一个访问网页失败的案例，该案例来自于 Wireshark sharkfest 2018 - Point And ShootPacket，其中的 Case 2 Cannot see homepage，描述的是来自 OSAKA 的用户抱怨访问一些网站页面不能显示，但是另外一些网站页面可以，譬如 Google OK，但是 Apple 不行，而其他像是 TOKYO 的用户反馈从来没有遇到过类似问题。
首先结论先行，该问题是广域网环境 MTU 问题导致，在以前的案例分析中也经常碰到 MTU 相关问题，总体上来说这类案例比较好分析，为什么会又再写篇文章？主要是因为该案例基于对比分析的思路，多点捕获了相关数据包，由于数据包跟踪文件齐全，可以很清晰的看到问题本质。
问题信息
为了故障排查，用户首先分别在 OSAKA 和 TOKYO 局域网下各捕获了一个 pcap 文件，2_OSAKA_FAIL_LAN.pcap 和 2_TOKYO_SUCCESS_LAN.pcap。
数据包跟踪文件基本信息如下：
λ capinfos 2_*.pcap
File name: 2_OSAKA_FAIL_LAN.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 5
File size: 705 bytes
Data size: 601 bytes
Capture duration: 0.103908 seconds
First packet time: 2013-01-30 13:32:30.562003
Last packet time: 2013-01-30 13:32:30.665911
Data byte rate: 5783 bytes/s
Data bit rate: 46 kbps
Average packet size: 120.20 bytes
Average packet rate: 48 packets/s
SHA256: bc72d90c881b05f9c4f0423d54506eb9dcd919add11a0d40f0365b1906b5ec18
RIPEMD160: cab2cf3a865fb2b58305d03cb1fbdae18275de6c
SHA1: 693698c13dfe8049b6a5ffcc7b1c226d5e35e61c
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 5
File name: 2_TOKYO_SUCCESS_LAN.pcap
File type: Wireshark/tcpdump/... - pcap
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: 65535 bytes
Number of packets: 233
File size: 216 kB
Data size: 213 kB
Capture duration: 1.349497 seconds
First packet time: 2013-01-30 13:35:40.939895
Last packet time: 2013-01-30 13:35:42.289392
Data byte rate: 157 kBps
Data bit rate: 1263 kbps
Average packet size: 914.41 bytes
Average packet rate: 172 packets/s
SHA256: b6ccfd9aea3cd032d905bdcc71c3fefe61b3d4444878c3a28863ab317f573dd2
RIPEMD160: d7735defdc1b10326b1a49ac7efc082e8fbc0dc6
SHA1: cca8863abe3ca3b41f40db97425b1b554eba6978
Strict time order: True
Number of interfaces in file: 1
Interface #0 info:
Encapsulation = Ethernet (1 - ether)
Capture length = 65535
Time precision = microseconds (6)
Time ticks per second = 1000000
Number of stat entries = 0
Number of packets = 233
2_OSAKA_FAIL_LAN.pcap，文件通过 Tcpdump 捕获，无截断，数据包捕获数量仅为 5 个，捕获持续时间仅为 0.1 秒，平均速率 46 kbps。考虑到数据包数量少以及捕获时长极短，推断用户根据问题所在，精确过滤仅保留了必要的问题数据包。
2_TOKYO_SUCCESS_LAN.pcap，文件同样通过 Tcpdump 捕获，无截断，数据包捕获数量 233 个，捕获持续时间为 1.3 秒，平均速率 1263 kbps。
专家信息如下，两个数据包跟踪文件总体来说并没有明显的问题所在，需要进入实际数据包分析。
问题分析
直接展开 OSAKA 和 TOKYO 两个局域网的数据包信息，对比如下：
该数据包跟踪文件在客户端侧捕获，可以看到在 TCP 三次握手之后，客户端的 GET 请求，服务器仅回复了 ACK 确认收到，仅就这 5 个数据包结束，并没有收到服务器实质数据响应包。考虑到数据包数量极少，且无其他现象，单就此数据包无法判断问题，需要对比成功的数据包跟踪文件。
该数据包跟踪文件在客户端侧捕获，同样的在 TCP 三次握手之后，客户端的 GET 请求，服务器不仅回复了 ACK，也回复了带有数据的分段 No.6-7（TCP Len 1414），HTTP 交互结果 200 OK。
客户端和服务器在 TCP 三次握手过程中，分别通告了 MSS、WS 因子、SACK 等选项支持情况。对比可知，做为客户端侧，OSAKA 和 TOKYO 发出的 SYN 中 MSS 均为 1460，但是收到服务器侧发来的 SYN/ACK 中，OSAKA MSS 为 1460，而 TOKYO MSS 为 1414，而此处的差异就造成之后的部分数据分段发送失败。
OSAKA ：客户端和服务器双向通告的 MSS 为 1460，这也就造成双方认为在之后 TCP 交互中可以传输的最大 TCP 分段长度为 1460。对比 TOKYO 可知，服务器在收到客户端的 GET 请求之后，会发送数据响应，也就是客户端预期能收到的 No.6-7，Frame Length 为 1514（14 Ethernet 首部 + 20 IPv4 首部 + 20 TCP 首部 + 1460 TCP Len），但由于广域网中间路径的最小 MTU 限制，造成 No.6-7 在中间被丢弃，所以客户端则并没有收到后续数据包，仅收到服务器 No.5 ACK 后陷入沉寂。
TOKYO：客户端 SYN 通告的 MSS 为 1460，服务器 SYN/ACK 通告的 MSS 为 1414，造成双方认为在之后 TCP 交互中可以传输的最大 TCP 分段长度为 1414。因此服务器在收到客户端的 GET 请求之后，会发送数据响应，也就是 No.6-7，Frame Length 为 1468（14 Ethernet 首部 + 20 IPv4 首部 + 20 TCP 首部 + 1414 TCP Len），满足广域网中间路径的最小 MTU 限制，因此 No.6-7 传输成功，客户端正常收到完成交互。
至此，通过 OSAKA 局域网失败和 TOKYO 局域网成功 的数据包跟踪文件对比，已经明确可知是由于 MTU 问题 所引起的访问网页失败。但问题的根因是什么呢？ 譬如同样是访问 Google 服务端，OSAKA 用户失败，而 TOKYO 用户成功，难道是 Google 服务端看菜下饭，回复给 OSAKA 用户的 MSS 是 1460，而回复给 TOKYO 用户的 MSS 是 1414，问题会出现在服务端嘛，区别对待？！不能说百分百不可能，但是确实大多数这样的案例问题会出现在中间的网络环境。
而为了解决广域网上的传输问题，用户又分别在 OSAKA 广域网 和 TOKYO 广域网上捕获了相关数据包，分别为 2_OSAKA_FAIL_WAN.pcap 和 2_TOKYO_SUCCESS_WAN.pcap ，捕获点大概如下：
客户端（局域网捕获点）--- 本地路由器（广域网捕获点）--- 广域网 --- 服务器端
可以看到客户端和服务器双向实际通告的 MSS 均为 1460，经过路由器时也并没有对其做任何修改，最后双方所选择使用的 MSS 自然也都是 1460。
再一次通过对比分析，可以很清晰的找到问题所在，以下描述完整过程：
a. 客户端本地通告的 MSS 为 1460（LAN SYN），在经过本地路由器时，被路由器修改变成了 MSS 1414（WAN SYN），自然服务器收到的客户端 SYN MSS 也为 1414；
b. 服务器通告的 MSS 为 1460（WAN SYN/ACK），在经过本地路由器时，被路由器修改变成了 MSS 1414（LAN SYN/ACK），最后客户端收到的服务器 SYN/ACK MSS 为 1414。
此处重点，需理解 TCP 三次握手中的 TCP OPTIONS 是通告，而非协商。
因为如果是协商，服务器在收到客户端 SYN MSS 1414 后，经比较本地的 MSS 1460，越小优选，服务器所发出的 SYN/ACK MSS 理论上应该是 1414，但是实际情况是 1460，说明是通告，各自通告自身的选项。
c. 最后的结果，客户端和服务器双方 MSS 均为 1414，客户端根据 SYN/ACK MSS 1414 选择，服务器根据 SYN MSS 1414 选择，遵循越小优选。
问题总结
问题的原因在于 MTU，而根因是 OSAKA 的路由器没有调整 MSS 大小，造成传输时 MTU 超出限制而引起丢包，最终反映的应用现象就是访问网页失败，所以像是经过类似 PPPOE、IPSEC VPN 等等需要添加报头的网络环境，需要根据实际情况调整 MSS 或者 MTU 的值来保证正常传输。
