前言
流媒体播放中，常常需要借助Wireshark从TCP层面对交互过程进行分析，本文记录一些常见的TCP异常报文及其分析。目前的场景是主机安装了流媒体服务，主机同时创建了一个docker容器运行Nginx，抓包发现Nginx跟流媒体通信存在大量异常报文，说明主机跟docker容器之间网络没有配置正确。报文截图如下：
乱序与丢包
[TCP Previous segment not captured]
[TCP Previous segment not captured]报文指的是在TCP发送端传输过程中，该Seq前的报文缺失了。一般在网络拥塞的情况下，造成TCP报文乱序、丢包时，会出现该标志。
需要注意的是，[TCP Previous segment not captured]解析文字是wireshark添加的标记，并非TCP报文内容。
例子：
流媒体服务器39.135.135.81，端口80，发送序号Seq=147154的包，长度Len=1360，那么下一个数据包序号应该为Seq=147154+1360=148514，可以看到客户端请求的也是Ack=148514。而服务器下一个包序号为Seq=149874，中间的包丢失了。
[TCP Out-Of-Order]
[TCP Out-Of-Order]指的是TCP发送端传输过程中报文乱序了。
例子：
继续上面的包分析，因为208142包序号为Seq=148514，而前一个序号为Seq=149874，故有此错误标志。
Seq=148514实际是208139包的响应，因为网络拥塞的情况下，TCP包不能按顺序到达，所以出现[TCP Previous segment not captured] 和 [TCP Out-Of-Order]标志。
[TCP dup ack XXX#X]
[TCP dup ack XXX#X]表示第几次重新请求某一个包，#前XXX表示第几个包（不是Seq），#后的X表示第几次请求。丢包或者乱序的情况下，会出现该标志。
[TCP segment of a reassembled PDU]
当wireshark抓包的时候，会出现如下的内容[TCP segment of a reassembled PDU],说明发送端发送的TCP缓存数据过大，需要进行分片发包，分片发包过程中，发送端发送的数据报文中的Ack(Acknowledgment number)编号保持一致
TCP在发起连接的第一个报文TCP头里面通过MSS(Maximum Segment Size),告知对方本端能够接收的最大报文（TCP净荷的大小），TCP层收到上层大块报文后，会分解成小块报文发送
重传
1、[TCP Fast Retransmission]
快速重传，一般快速重传算法在收到三次冗余的Ack，即三次[TCP dup ack XXX#X]后，发送端进行快速重传。
为什么是三次呢？因为两次 duplicated ACK 肯定是乱序造成的，丢包肯定会造成三次 duplicated ACK。
2、[TCP Retransmission]
超时重传，如果一个包的丢了，又没有后续包可以在接收方触发[Dup Ack]，或者[Dup Ack]也丢失的情况下，TCP会触发超时重传机制。检测是否是服务器的防火墙开启，导致收不到任何的数据，客户端连接失败
TCP Window
1、[TCP ZeroWindow]
作为接收方发出现的标志，表示接收缓冲区已经满了，此时发送方不能再发送数据，一般会做流控调整。接收窗口，也就是接收缓冲区win=xxx ，告诉对方接收窗口大小。
例子：
传输过程中，接收方TCP窗口满了，win=0，wireshark会打上[TCP ZeroWindow]标签。
2、[TCP window update]
当接收端接收窗口大小发生变化，可以接收数据了，则有该标志。
例子：
接收方消耗缓冲数据后，更新TCP窗口，，可以看到从win=0逐渐变大，这时wireshark会打上[TCP window update]标签。
3、[TCP window Full]
作为发送方的标识，当前发送包的大小已经超过了接收端窗口大小，wireshark会打上此标识，标识不能在发送。
多个RST重复报文
24086 2023-10-10 08:26:33.653662 50.146.251.184 50.146.253.40 TCP 74 53628 → 27001 [RST] Seq=157 Win=33553408 Len=0 WS=1024 MSS=265 TSval=1061109567 TSecr=0
24087 2023-10-10 08:26:33.653687 50.146.251.184 50.146.253.40 TCP 74 53628 → 27001 [RST] Seq=157 Win=33553408 Len=0 WS=1024 MSS=265 TSval=1061109567 TSecr=0出现这种异常情况，就是现场主机安装了安全软件导致的，跟操作系统层面没有任何关系，联系网管放行即可
[SYN, ECN, CWR]
CWR拥堵标志位不影响连接，完成TCP三次握手，正常交互
[SYN, ECE, CWR]
CWR拥堵标志位不影响连接，完成TCP三次握手，正常交互
192.168.10.178 192.168.10.173 TCP 66 30020 → 30006 [SYN, ECE, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM
192.168.10.173 192.168.10.178 TCP 54 30006 → 30020 [RST, ACK] Seq=349364778 Ack=1 Win=0 Len=0
192.168.10.178 192.168.10.173 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 30020 → 30006 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM
192.168.10.173 192.168.10.178 TCP 66 [TCP Port numbers reused] 30006 → 30020 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM
192.168.10.173 192.168.10.178 TCP 54 [TCP Dup ACK 711#1] 30006 → 30020 [ACK] Seq=1 Ack=1 Win=2097152 Len=0[Malformed Packet]
在对接海康1400视图库的时候，抓包发现返回的报文提示畸形报文的提示，实际上通过通过追踪流是可以查看到完整的报文内容：
POST /VIID/Subscribes HTTP/1.1
Host: 32.140.51.24:8023
Accept: /
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
User-Identify: 32100100005035000139
Content-Length: 523
{“SubscribeListObject”:{“SubscribeObject”:[{“ApplicantName”:“admin”,“ApplicantOrg”:“bdbb04990cdd40949e742380e713981d”,“BeginTime”:“20220120105119”,“DataType”:0,“EndTime”:“21220120105119”,“OperateType”:0,“Reason”:“SYRJ3210000000503000000920220120105119”,“ReceiveAddr”:“ http://32.140.50.33:5689/VIID/SubscribeNotifications",“ReportInterval”:5,“ResourceURI”:“32100000005030000009”,“SubscribeDetail”:“3”,“SubscribeID”:“000000000000032022012010511900000”,“Title”:“SYRJ3210000000503000000920220120105119”,"maxTransNum”:10000}]}}
HTTP/1.1 200
P3P: CP=CAO PSA OUR
Content-Type: application/viid+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 20 Jan 2022 02:46:34 GMT
ce
{“ResponseStatusListObject”:{“ResponseStatusObject”:[{“RequestURL”:“/VIID/Subscribes”,“StatusCode”:“0”,“StatusString”:“…”,“Id”:“000000000000032022012010511900000”,“LocalTime”:“20220120104634”}]}}
0
