知识不是智慧，解决问题的方法才是智慧。
前言
问题信息
λ capinfos Sample04.pcapngFile name: Sample04.pcapngFile type: Wireshark/... - pcapngFile encapsulation: EthernetFile timestamp precision: microseconds (6)Packet size limit: file hdr: (not set)Number of packets: 33File size: 6228 bytesData size: 5005 bytesCapture duration: 38.709141 secondsFirst packet time: 2011-01-14 01:14:52.475277Last packet time: 2011-01-14 01:15:31.184418Data byte rate: 129 bytes/sData bit rate: 1034 bits/sAverage packet size: 151.67 bytesAverage packet rate: 0 packets/sSHA256: 48ca202b8b7c2cf0fd20fe0909cae6cd2a30fbdbdad17492a5cab7f2749bb745RIPEMD160: 151de4053735268f9943f00403f72aef66debf42SHA1: a3fb91edd6db023edb2648f6d69dfafb2b7c6a27Strict time order: TrueCapture comment: Sanitized by TraceWrangler v0.6.4 build 808Number of interfaces in file: 1Interface #0 info:Encapsulation = Ethernet (1 - ether)Capture length = 65535Time precision = microseconds (6)Time ticks per second = 1000000Time resolution = 0x06Number of stat entries = 0Number of packets = 33λ
关于 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.
如字面意思所述，TCP 之前的段未被捕获到，实际上数据包跟踪文件里这个未被捕获到的提示一般有两种可能：
-
所捕获的原始 TCP 会话发生了丢包。如果是这种情况，镜像流量是原样复制了一份，原本就少了部分数据包，自然所捕获到的数据包也相应就少一部分。 -
所捕获的原始 TCP 会话数据包交互正常，但在镜像流量的过程中发生了丢包，也就是说镜像捕获丢包，如果是这样的情况，也同样会告警提示某些段未被捕获到。
-
所捕获的原始 TCP 会话发生了丢包。如果是这种情况，因为丢包，原始会话自然会进行重传之类的动作，在之后所捕获到的数据包自然也可以看到相关现象。（需要区分重传和乱序） -
所捕获的原始 TCP 会话数据包交互正常，但镜像捕获丢包，如果是这样的情况，自然原始会话会正常 ACK 该分段，而捕获的数据包看到这个 ACK，会相应提示 ACKed segment that wasn't caputred 信息，因为捕获的跟踪文件中实际没有这个分段。
类似文章和案例很多，有兴趣的同学可以查看《丢包？不要轻易下结论》、《丢包？不要轻易下结论续》、《TCP Previous Segment Lost》等。
基本分析
-
No.1 和 No.2，首先是一对 DNS 请求和响应，查询 www.boerse-stuttgart.de，以及响应的 A 记录 IP 217.110.67.201;
-
从 No.3 开始，客户端发起了到服务器 HTTP 80 的访问，也就是 TCP Stream 0，在 TCP 正常三次握手后，客户端发起的 HTTP 请求，服务器响应 301 重定向，http -> https 跳转 。
当然可能是 TraceWrangler 匿名化应用的问题，服务器端 IP 0.115.64.211（被修改过），和 DNS 响应中的 IP（217.110.67.201）并不一致，小问题可忽略。
-
因此从 No.8 开始，客户端发起了到服务器 HTTPS 443 的访问，也就是 TCP Stream 1 ，在 TCP 正常三次握手后，在进行 TLS 握手时发生了问题。
TCP Previous segment not caputred，说明服务器传输方向在之前有分段丢失的情况发生，因此客户端产生了 No.15 的 DUP ACK 现象。之后因为 TLS 握手失败问题，客户端主动 FIN 了连接，之后会话匆匆结束。而体现在应用上的异常现象，就是网页访问失败，打不开~进一步分析
-
TCP 三次握手中，注意双方通告后的结果，MSS 为 1380 字节； -
客户端 No.11 Client Hello 发送出去后，理论上应该是收到服务器端的 Server Hello，但是却发生了丢包，无任何数据包收到后，因此 No.13 客户端发生超时重传； -
服务器端 No.14 Seq 4141 以及 TCP Previous segment not caputred, 说明了丢失了 4140 字节的分段，也就是 4140/1380 = 3，刚好 3 个 MSS 的数据包。说明服务器按 MSS 1380 所发送出来的数据包，在中间传输时被丢弃了，这种情况判断是中间路径 MTU 小于 1420 （1380+40）导致；（传输路径 MTU 问题） -
之后服务器方面也并没有啥补救措施，在客户端 No.15 DUP ACK 仍然请求数据分段 Seq 1 的情况下，服务器陷于沉寂，当然这是站在客户端的抓包角度上来说，从服务器方面来说肯定是在重传，不断重传； -
最后客户端在 30 秒后忍无可忍，FIN 断开连接，Over 。
问题总结
往期推荐
原文始发于微信公众号（Echo Reply）：Wireshark TS | 访问网页失败
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论