用Wireshark分析re-transmission和package loss

使用Wireshark分析丢包, 需要先了解TCP的工作方式，下面我自己画的图总结了TCP建立/传输/关闭.

TCP工作原理

基本原理映射到Wireshark中如下:

TCP 建立连接
E.g. 50391申请建立连接刀8080，发送[SYN]. 8080收到后返还[SYN, ACK]说明收到连接建立请求.
之后50391发送ACK给8080确认建立链接

TCP 关闭连接
E.g. 52803 发送[FIN, ACK]给8080说明我要关闭了, 8080 收到后发送了ACK证明请求收到，
之后8080也发送[FIN, ACK]给52803说明关闭连接, 然后52803返回ACK说明收到，至此完成4次挥手

包传输
如截图所示, 8080向49369发送数据包.
其中Wireshark标记的[TCP segment of a reassembled PDU] 表示TCP缓存数据过大. 本端能够接收的最大报文长度由TCP在发起连接的第一个报文TCP头里面通过MSS(Maximum Segment Size)来决定. (见上上图, MSS=1460)

8080给49369发送数据包的同时, 49369需要对包进行ACK确认，如下图8080发送Seq为1419的包(长度为1418)后，
49369返回了ACK确认，并说明我已收到你发的数据包, 你下次要发seq为ack号的给我

包重传  Re-transmission
当接收端没有及时回复时，发送端会重传 (TCP Retransmission)

Retransmission并不表示有问题，如果经过全部Retransmission后接收端得到了所有package, 则说明网络TCP连接还是成功的。如上图所示, 接收端49409最后的ACK说明其已经收到package到15854了，而发送端的最后一个包是15599+255=15854。
因为接收端和发送端数据一致，所以这次connection是成功的。

丢包 package loss
我们可以看到下图8800 发送到Seq为5673的数据包时, 49245只返回了ACK=1419的确认。
经过多次重传Re-transmission后还是没有收到49245的确认，直到49245超时给了RST的信号，中断了连接。

发送端发的数据和接收端确认接收到的数据相差较大，相差的数据可以看作是丢掉了。