Wireshark理解TCP乱序重组和HTTP解析渲染

TCP乱序重组

这个还是取决于对TCP协议的理解，参照TCP序列号和确认号详解，讲解很清晰

基于自己理解

Statistics ->Flow Graph

重点讲数据传输过程：

1)  发送数据：服务器向客户端发送一个带有数据的数据包，该数据包中的序列号Seq和确认号Ack与建立连接第三步的数据包中的序列号和确认号相同；

如上图Seq=1 ACK=1

2)  确认收到：客户端收到该数据包，向服务器发送一个确认数据包，该数据包中，序列号是为上一个数据包中的确认号值，而确认号为服务器发送的上一个数据包中的序列号+所该数据包中所带数据的大小。

如上图Seq=1 Ack=999　　　　Seq(x)=Ack(y)  1 　　Ack(x)=Seq(x)+998 (data len) 　999　 　　　　 c——》s

　　Seq=999 Ack=1381　　　Seq(y)=Ack(x)  999   Ack(y)=Seq(y)+1381(data len) 　1381  　　　　 s——》c

　　Seq=1381　Ack=999 　　Seq(x)=Ack(y) 1381  Ack(x)=Seq(x)+998 (data len)　 999　　　        c——》s　

　　Seq=999　 Ack=2761     Seq(y)=Ack(x)  999  Ack(y)=Seq(y)+1381(data len)     2761　  　　　  s——》c
数据分段中的序列号可以保证所有传输的数据按照正常的次序进行重组，而且通过确认保证数据传输的完整性。

　　SeqNum的增加是和传输的字节数相关的。上图中，三次握手后，来了两个Len:1381的包，而第二个包的SeqNum就成了1381。然后第一个ACK回的是1381，表示第一个1381收到了,第二个Ack回的是 2761，表示第二个1381收到了

注意：1.Wireshark使用了Relative SeqNum——相对序号，以便更容易观察，在protocol preference 中取消掉就可以看到“Absolute SeqNum”。

　　   2.服务器端处理一次客户端请求，发送的多个数据包的ACK是相同的，如上，均为999

对于乱序和拥塞，TCP的处理：

　Tcp引入快速重传机制，不以时间驱动而是以数据驱动重传。如果包没有连续到达，就ack可能被丢了的包，如果发送方连续收到3次相同的ACK，就重传，这样就不等timeout就重传了。

HTTP解析渲染

刚开始认为http在发出请求后，会并发建立TCP连接，连接数基本不变，但实际情况并非如此，这就涉及到HTTP的加载、解析、渲染的过程。