Wireshark TS | 访问网页失败

前言

访问网页失败也是日常比较常见的问题之一，导致问题的原因可能有很多种，像是客户端、浏览器、服务器或者网络等等，自然具体问题得具体分析。本篇以一个实际案例来说明下 TCP 连接相关的问题，该数据包仍然来自于 Wireshark sharkfest 2017，一些简短但有趣的 TCP 跟踪文件中的又一个。

问题信息

数据包跟踪文件基本信息如下：

λ capinfos Sample04.pcapng
File name:           Sample04.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   33
File size:           6228 bytes
Data size:           5005 bytes
Capture duration:    38.709141 seconds
First packet time:   2011-01-14 01:14:52.475277
Last packet time:    2011-01-14 01:15:31.184418
Data byte rate:      129 bytes/s
Data bit rate:       1034 bits/s
Average packet size: 151.67 bytes
Average packet rate: 0 packets/s
SHA256:              48ca202b8b7c2cf0fd20fe0909cae6cd2a30fbdbdad17492a5cab7f2749bb745
RIPEMD160:           151de4053735268f9943f00403f72aef66debf42
SHA1:                a3fb91edd6db023edb2648f6d69dfafb2b7c6a27
Strict time order:   True
Capture comment:     Sanitized by TraceWrangler v0.6.4 build 808
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
                     Time resolution = 0x06
                     Number of stat entries = 0
                     Number of packets = 33

λ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

数据包推测通过 Wireshark 所捕获，数据包数量 33 个，文件大小 6228 字节，捕获时长约 38.7 秒，平均速率 1034 bits/s，并经过 TraceWrangler 匿名化软件所处理。

关于 TraceWrangler 匿名化软件简介，可以查看之前的文章《Wireshark 提示和技巧 | 如何匿名化数据包》

专家信息如下，其中有需要注意的地方是 Previous segment not caputred 的警告信息，以及 RST、（疑似）重传、DUP ACK 等，考虑到总包数 33 本身较少，少量疑似有问题的信息仍然需要关注。

问题分析

TCP Previous segment not caputred

首先什么是 TCP Previous segment not caputred? 实际上在以前的文章，包括大家自己手头上的实际案例，应该是一种比较常见的专家提示信息。

Set when the current sequence number is greater than the next expected sequence number.
1

如字面意思所述，TCP 之前的段未被捕获到，实际上数据包跟踪文件里这个未被捕获到的提示一般有两种可能：

1. 所捕获的原始 TCP 会话发生了丢包。如果是这种情况，镜像流量是原样复制了一份，原本就少了部分数据包，自然所捕获到的数据包也相应就少一部分。
2. 所捕获的原始 TCP 会话数据包交互正常，但在镜像流量的过程中发生了丢包，也就是说镜像捕获丢包，如果是这样的情况，也同样会告警提示某些段未被捕获到。

当然这两种情况，有时也会比较好区别，简要说明如下：

1. 所捕获的原始 TCP 会话发生了丢包。如果是这种情况，因为丢包，原始会话自然会进行重传之类的动作，在之后所捕获到的数据包自然也可以看到相关现象。（需要区分重传和乱序）
2. 所捕获的原始 TCP 会话数据包交互正常，但镜像捕获丢包，如果是这样的情况，自然原始会话会正常 ACK 该分段，而捕获的数据包看到这个 ACK，会相应提示 ACKed segment that wasn’t caputred 信息，因为捕获的跟踪文件中实际没有这个分段。

举例：

类似文章和案例很多，有兴趣的同学可以查看《丢包？不要轻易下结论》、《丢包？不要轻易下结论续》、《TCP Previous Segment Lost》等。

基本分析

回到本案例，展开完整的数据包文件信息，如下：

主要分析如下：

1. No.1 和 No.2，首先是一对 DNS 请求和响应，查询 www.boerse-stuttgart.de，以及响应的 A 记录 IP 217.110.67.201;

2. 从 No.3 开始，客户端发起了到服务器 HTTP 80 的访问，也就是 TCP Stream 0，在 TCP 正常三次握手后，客户端发起的 HTTP 请求，服务器响应 301 重定向，http -> https 跳转 。

当然可能是 TraceWrangler 匿名化应用的问题，服务器端 IP 0.115.64.211（被修改过），和 DNS 响应中的 IP（217.110.67.201）并不一致，小问题可忽略。

3. 因此从 No.8 开始，客户端发起了到服务器 HTTPS 443 的访问，也就是 TCP Stream 1 ，在 TCP 正常三次握手后，在进行 TLS 握手时发生了问题。

在客户端 No.11 发送 Client Hello 后，服务器并无任何响应，在 3 秒后，客户端 No.13 超时重传了数据包，服务器此时所发送来的 No.14 提示即有 TCP Previous segment not caputred，说明服务器传输方向在之前有分段丢失的情况发生，因此客户端产生了 No.15 的 DUP ACK 现象。之后因为 TLS 握手失败问题，客户端主动 FIN 了连接，之后会话匆匆结束。而体现在应用上的异常现象，就是网页访问失败，打不开~

进一步分析

转向 TCP 详细分析，打开上帝视图，看看究竟发生了什么问题

1. TCP 三次握手中，注意双方通告后的结果，MSS 为 1380 字节；
2. 客户端 No.11 Client Hello 发送出去后，理论上应该是收到服务器端的 Server Hello，但是却发生了丢包，无任何数据包收到后，因此 No.13 客户端发生超时重传；
3. 服务器端 No.14 Seq 4141 以及 TCP Previous segment not caputred, 说明了丢失了 4140 字节的分段，也就是 4140/1380 = 3，刚好 3 个 MSS 的数据包。说明服务器按 MSS 1380 所发送出来的数据包，在中间传输时被丢弃了，这种情况判断是中间路径 MTU 小于 1420 （1380+40）导致；（传输路径 MTU 问题）
4. 之后服务器方面也并没有啥补救措施，在客户端 No.15 DUP ACK 仍然请求数据分段 Seq 1 的情况下，服务器陷于沉寂，当然这是站在客户端的抓包角度上来说，从服务器方面来说肯定是在重传，不断重传；
5. 最后客户端在 30 秒后忍无可忍，FIN 断开连接，Over 。

问题总结

本案例中的访问网页失败算是一类比较简单的故障场景，问题现象明确且容易复现，三下五除二也就解决了，当然相对也会有很复杂的场景，就比较烧脑了 ~ 😔