概述：
在平时的运维过程中，我们经常会遇到一些数据传输的问题，在我们平时遇到的数据传输问题中定位难度从难到易基本为：数据传输慢不符合预期、数据传输过程有丢包、数据传输被终止或网络断开连接。
如果要对数据流分析抓包是最直接的办法，它可以帮助你更快的定位问题。最常用的抓包工具：wireshark（windows系统）、tcpdump（linux系统） （工具使用略）
接下来分享下我总结的几个常见数传异常报文：
*TCP Dup Ack（TCP Dup Ack 22#1此报文为22号报文的重发报文）
TCP报文中的Ack字段是对预期达到的下一个报文的序列号，而看到Dup Ack则说明由于某些原因Dup Ack发起方没有收到预期序列号的报文，从而发送Dup Ack再次请求预期数据报文，直到收到预期报文，才会停止发送Dup Ack报文。
遇到此类报文很可能是因为两台终端之间设备有丢包，可能是防火墙或者安全设备将数据包丢弃造成，建议在两台终端之间的其他网络设备进行抓包对比，以确定异常位置。
*TCP Retransmission
TCP retransmission报文代表重传，重传是指具有相同TCP序列号的报文至少两次或多次经过，重传报文是一种很常见的影响数据传输速率的异常报文。
原因分析：
1、两台终端之间的其他网络节点发生功能紊乱，存在丢包，造成对端未收到相应序列号的报文或本端未收到对端的回复报文。（建议检查防火墙，网流分析、信安系统、Ddos等安全设备）
2、对端未正常发送确认报文，对端功能紊乱（多为安全软件或网卡校验功能造成）
3、本端收到确认报文，但没有正常处理（建议检查安全软件，网卡设置等）
*TCP Out-Of-Order
TCP Out-Of-Order是一种TCP报文乱序，报文乱序是指，该报文没有携带续期的序列号，即在同一个TCP连接上，相同源地址发出的后一个TCP报文序列号不等于前一个报文的序列号加上前一个报文的报文长度（）Out-Of-Order的乱序主要指实际收到的报文序列号小于预期报文序列号。此报文会与Dup Ack报文匹配出现，因为接收端没有收到预期的序列号，就会再次发送ack报文请求预期序列号报文。
可能原因：中间网络节点之间发生功能紊乱，转发或者发送了异常报文；对端发送了乱序报文。
*TCP Previous Segment Lost
TCP Previous Segment Lost也是一种TCP报文乱序。此乱序报文主要指实际收到的报文序列号大于预期序列号，或者说实际上在收到这个报文之前还应该收到一个或多个报文，但没有收到。
可能原因：基本同上
*TCP Winodws Update
TCP Windows Update 表明更改滑动窗口大小，可能变大也可能变小，跟TCP连接上层应用对接收到的报文数据处理速度有关，此报文并不代表一定有异常。
*TCP Zero Windows
TCP Zero Windows 表明滑动窗口变成0。
发生场景
1、TCP连接复位或者断开时，发送ACK消息，知名TCP窗口为0，此种情况无需多关注
2、输出传输过程中出现Zero Windows，TCP连接创建时接收端会通知发送端可用的TCP接收窗口，随着发送端不断往接收端发送数据报文，如果接收端不能及时从TCP接收缓冲中提取报文进行处理，name接收缓冲的积累报文就会越来越多，TCP可用的滑动窗口大小也会越来越小，直到滑动接收窗口变为0。
Zero Winodws消息通常会在接收端TCP接收缓冲满时发出，告诉发送端“数据已满等等”，发送端收到此类通知后，会暂时停止向该接收端发送数据。对于经常出现Zero Windows的TCP连接，部分防火墙的规则会发送RST消息断开这些慢连接。
原因：通常是接收端应用处理不及时。请检查应用程序
*TCP Windows Full
TCP Windows Full于Zero Windows有一定的联系。数传过程中者两个报文常常会一起出现。区别在于TCP Windows Full出现在发送端-》接收端的报文里，TCP Zero Windows出现在接收端->发送端的报文上。
原因：同上
