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

TCP数据传输过程

TCP乱序重组原理

HTTP解析渲染 

 

TCP乱序重组

TCP具备乱序重组的功能。
（1）TCP具备缓冲区
（2）TCP报文具备序列号
因此，对于你说的问题，一种常见的处理方式是：TCP会先将报文段3缓存下来，当报文段2到达时，再根据序列号进行拼接。
2 固然缓冲区也有满的时候，这时接收端会直接丢弃报文，不作任何其余处理；
发送方的定时器发现迟迟收不到接收方丢弃报文的确认号（ack number），就会重传该报文。这就是TCP的超时重传功能

Sequence Number是包的序号，用来解决网络包乱序（reordering）问题。
Acknowledgement Number就是ACK——用于确认收到，用来解决不丢包的问题。
MTU: Maxitum Transmission Unit 最大传输单元
MSS: Maxitum Segment Size 最大分段大小

对于建连接的3次握手，主要是要初始化Sequence Number 的初始值。通讯的双方要互相通知对方本身的初始化的Sequence Number（缩写为ISN：Inital Sequence Number）——因此叫SYN
全称Synchronize Sequence Numbers。也就上图中的 x 和 y。
这个号要做为之后的数据通讯的序号，以保证应用层接收到的数据不会由于网络上的传输的问题而乱序
（TCP会用这个序号来拼接数据）。

网络文件时流量巨大，出现不少
TCP segment of a reassembled PDU
其实主机响应一个查询或者命令时若是要回应不少数据（信息）而这些数据超出了TCP的最大MSS时，
主机会经过发送多个数据包来传送 这些数据（注意：这些包并未被分片）
。对wireshark来讲这些对相应同一个查询命令的数据包被标记了“TCP segment of a reassembled PDU”

问题，wireshark如何识别多个数据包是对同一个查询数据包的响应?
wireshark是根据sequence number来识别，这些数据包ACK number是相同的，
固然number的数值与查询数据包中的next sequence number也是同样的。
对于TCP协议而言就不同了，这个协议是面向链接的协议，
对于TCP协议而言它很是在乎数据包的到达顺序以及是否传输中有错误发生。因此有些TCP应用对分片有要求---不能分片（DF）。

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

基于本身理解

Statistics ->Flow Graph

重点讲数据传输过程：

TCP数据传输过程

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的增长是和传输的字节数相关的, 数据分段中的序列号Seq能够保证全部传输的数据按照正常的次序进行重组，并且经过确认保证数据传输的完整性。

　　上图中，三次握手后，来了两个Len:1381的包，而第二个包的SeqNum就成了1381。而后第一个ACK回的是1381，表示第一个1381收到了,第二个Ack回的是 2761，表示第二个1381收到了

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

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

　　　3.ack递增，seq链接（开始的位置），只须要Seq便可重组。

　

TCP乱序重组原理

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

　Tcp引入快速重传机制，不以时间驱动而是以数据驱动重传。若是包没有连续到达，就ack可能被丢了的包，若是发送方连续收到3次相同的ACK，就重传，这样就不等timeout就重传了。并且对于乱序报文不丢弃，而是缓存下来（减小重传）当即发送但愿接受的报文确认。

　　例子：

　　发送端A发送了如下几个包：第一个：1001－1100，第二个1101－1200，第三个FIN包(序列号是1201，一个虚字节)。
　　1）第二个包在传输的过程当中丢失了，接收端收到第三个包后并不丢弃，而是缓存下来，而后，当即发送一个ACK，确认号是1101（这样作的目的是没必要等到发送端A的第二个包超时后重传，发送端A收到3个一样的ACK后当即重传，这是快速重传的概念）。
　　2）当发送端A收到3个确认号都是1101或者第二个包的超时计时器到时间后，当即从新发送第二个包（之因此能够重传，是由于TCP协议在接收端和发送端都各自创建了两个发送、接收缓存）。
　　3）这样，当接收端B收到来自A的第二个包后，缓存中的数据都是按序的了。
　　4）对于按序包，接收端B对序列号的最后一个字节+1，也就是发送确认号是1202的ACK包。

　　5）发送端A收到确认号是1202后，便不能再发送任何数据了。

快速重传：

　　若是发送方发出了1，2，3，4，5份数据，第一份先到送了，因而就ack回2，结果2由于某些缘由没收到，3到达了，因而仍是ack回2，后面的4和5都到了，可是仍是ack回2，由于2仍是没有收到，因而发送端收到了三个ack=2的确认，知道了2尚未到，因而就立刻重转2。而后，接收端收到了2，此时由于3，4，5都收到了，因而ack回6。

　　接收端收到每一个包，都要发送ACK给服务器端，那么若是是乱序的话，在接收端作判断，发送乱序的包的ACK给服务器，(在wireshark中体现为duplicate ACK )，表示收到一个出问题的分片，TCP当即产生一个应答，这个相同的ACK不会延迟，以告诉服务器端知道一个分片被收到的时候出现问题，而且告诉它但愿获得的序列号，服务器若是收到这样三次相同的ACK包，则当即重传。可是重传成功前，又出现这样的状况，那么丢失的不止一个包，但服务器收到的ACK依然没有增加。

　　对于上面的示例来讲，是重传#2呢仍是重传#2，#3，#4，#5呢？由于发送端并不清楚这连续的3个ack(2)是谁传回来的？也许发送端发了20份数据，是#6，#10，#20传来的呢。这样，发送端颇有可能要重传从2到20的这堆数据（这就是某些TCP的实际的实现）。

　　猜想是在接收端根据序列号进行排序，一接收到重传的数据包便进行重组，而且seq number增长，立刻发ACK给服务器端。

在127 125位置乱序

　　服务器发送过来的seq按照顺序来递增，客户端的seq根据接收到的数据包正确的顺序来递增，ack根据上一次数据包的序列号+此次传输数据包的大小来递增，若是接收到有问题的包，则seq和ack不变，每次都发送相同的seq和ack给服务器端，如71和73.包括以后收到seq不按顺序递增的包，客户端仍是发送相同的ack给服务器端，因此服务器端识别不了具体是哪一个有问题的数据包发送的，只跟初始有问题的数据包有关系。

　　返回服务器端的确认编号其实是客户端但愿收到的序列号。

 

duplicate ACK。接下来几个报文重复此过程，直到接收到缺失的数据包

TCP Previous Segment Lost，看Frame流程，17940--20699的包没有按序到达，然后发的包居然先到了，乱序了，后续127重传的包就是缺乏的包。

71和73的seq和ack是同样的

接收到125的数据包后，ack递增，估计是在客户端进行重组后的结果，发送ack表示已经重组好多少数据，服务器继续发送以起始位置为17941的数据包，即为127。至此，在127以前的数据已经重组完毕。

 另外，若是标记为 “TCP out of order”，则是后到的包，通常不超过“TCP Dup Ack **#3”（？）。

 

HTTP解析渲染 

　　刚开始认为http在发出请求后，会并发创建TCP链接，链接数基本不变，但实际状况并不是如此，这就涉及到浏览器对HTTP的加载、解析、渲染的过程：

1. 用户访问网页，DNS服务器（域名解析系统）会根据用户提供的域名查找对应的IP地址，找到后，系统会向对应IP地址的网络服务器发送一个http请求。
2. 网络服务器解析请求，并发送请求给数据库服务器。
3. 数据库服务器将请求的资源返回给网络服务器，网络服务器解析数据，并生成html文件，放入http response中，返回给浏览器。
4. 浏览器解析 http response。
5. 1~4步骤须要了解HTTP协议。
6. 访问服务器端可能遭遇的问题：若是网络服务器没法获取数据库服务器返回的资源文件（http response 404），或者因为并发缘由暂时没法处理用户的http请求（http response 500）
7. 浏览器解析 http response后，须要下载html文件，以及html文件内包含的外部引用文件，及文件内涉及的图片或者多媒体文件。

加载：当浏览器得到一个html文件时，“自上而下”加载，加载过程当中进行解析渲染。

资源间互相阻塞

　　IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。在渲染到页面的某一部分时，其上面的全部部分都已经下载完成（但并非说全部相关联的元素都已经下载完。）在下载过程当中，若是遇到某一标签是嵌入文件，而且文件是具备语义解释性的（例如：JS脚本，CSS样式），那么此时IE的下载过程会启用单独链接进行下载。而且在下载后进行解析，解析（JS、CSS中若有重定义，后定义函数将覆盖前定义函数）过程当中，中止页面全部往下元素的下载。样式表文件比较特殊，在其下载完成后，将和之前下载的全部样式表一块儿进行解析，解析完成后，将对此前全部元素（含之前已经渲染的）从新进行样式渲染。并以此方式一直渲染下去，直到整个页面渲染完成。

浏览器加载、解析、渲染过程

Nignix一次完整的HTTP事务