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的加载、解析、渲染的过程。

时间: 2024-10-09 12:36:08

Wireshark理解TCP乱序重组和HTTP解析渲染的相关文章

Wireshark抓包实例分析TCP重复ACK与乱序

转载请在文首保留原文出处: EMC 中文支持论坛https://community.emc.com/go/chinese 介绍 TCP 的一大常见问题在于重复 ACK 与快速重传.这一现象的发生也是由于性能问题,本章讨论如何发现这一问题以及他们意味着什么. 另一个常见问题是前一片段丢失以及乱序片段.某些情况下,这一现象喻示着故障发生,可能是由于网络问题或是抓包中断. 更多信息 重复 ACK 与快速重传 : 当网速变慢时,重复 ACK 是可能的原因之一.大多数情况下,重复 ACK 的发生是由于高延

转_结合Wireshark捕获分组深入理解TCP/IP协议栈

转自: http://blog.chinaunix.net/uid-9112803-id-3212207.html 摘要: 本文剖析了浏览器输入URL到整个页面显示的整个过程,以百度首页为例,结合Wireshark俘获分组进行详细分析整个过程,从而更好地了解TCP/IP协议栈. 一.俘获分组 1.1 准备工作 (1) 清空浏览器缓存 首先清空Web浏览器的高速缓存,确保Web网页是从网络中获取,而不是从高速缓冲取得[1].谷歌浏览器,Options --> Under the Hood -->

TCP对SACK的处理以及乱序的处理细节

不容易啊,天气热得厉害,终于到了周末却哪里也去不了,昨晚就特意向老婆申请了一段不长不短的周末时间用来总结近期的工作,也实属不易,如果申请没有获得批准,我也只好利用夜晚了,因为我几乎是一个不用怎么睡觉,可吃可不吃的人,只要有水,烧酒,就好了...大早上的,热醒了,看来也用不到我申请的时间了....此时是早上4点半... RFC2018描述了TCP SACK的规范,主要是规范了SACK的定义以及在使用该特性的时候,发送端和接收端的行为建议.RFC文档本身非常容易读懂,建议通读一遍,花不了半小时,我之

转_结合Wireshark捕获分组深入理解TCP/IP协议栈之TCP协议(TCP报文格式+三次握手实例)

转自: http://blog.chinaunix.net/uid-9112803-id-3212041.html 摘要: 本文简单介绍了TCP面向连接理论知识,详细讲述了TCP报文各个字段含义,并从Wireshark俘获分组中选取TCP连接建立相关报文段进行分析. 一.概述 TCP是面向连接的可靠传输协议,两个进程互发数据之前需要建立连接,这里的连接只不过是端系统中分配的一些缓存和状态变量,中间的分组交换机不维护任何连接状态信息.连接建立整个过程如下(即三次握手协议): 首先,客户机发送一个特

wireshark的使用教程--用实践的方式帮助我们理解TCP/IP中的各个协议是如何工作的

 wireshark的使用教程 --用实践的方式帮助我们理解TCP/IP中的各个协议是如何工作的 wireshark是一款抓包软件,比较易用,在平常可以利用它抓包,分析协议或者监控网络,是一个比较好的工具,因为最近在研究这个,所以就写一下教程,方便大家学习. 这里先说Wireshark的启动界面和抓包界面 启动界面: 抓包界面的启动是 按file下的按钮 之后会出现 这个是网卡的显示,因为我有虚拟机所以会显示虚拟网卡,我们现在抓的是真实网卡上的包所以在以太网卡右边点击start 开始抓包 这个就

通过packetdrill构造的包序列理解TCP快速重传机制

TCP的逻辑是极其复杂的,其学习曲线虽然很平缓但其每一步都是异常艰难,好在这些都是体力活,只要肯花时间也就不在话下了.想彻底理解一个TCP的机制,有个四部曲:1.读与其相关的RFC:2.看Linux协议栈的TCP实现:3.通过抓包以及其它工具来确认事实就是如此:4.解决一个与之相关的网络问题.经历了以上四步骤,相信任何人都可以在相关领域内稍微装逼一把了...        本文的内容是TCP快速重传机制,但是与其它文章不同的是,本文并不剖析源码实现,也不翻译RFC,更不是原理性介绍,而是通过一个

深入理解TCP协议及其源代码-拥塞控制算法分析

这是我的第五篇博客,鉴于前面已经有很多人对前四个题目如三次握手等做了很透彻的分析,本博客将对拥塞控制算法做一个介绍. 首先我会简要介绍下TCP协议,其次给出拥塞控制介绍和源代码分析,最后结合源代码具体分析拥塞控制算法. 一.TCP协议 关于TCP协议,其实在我的第二篇博客中:https://www.cnblogs.com/xiaofengustc/p/12012638.html 已有简要的介绍,并且在该博客中我还拿TCP协议与HTTP协议.UDP协议做了相关对比.有兴趣的同学可以参见我的第二篇博

理解TCP和UDP协议

目录 TCP 协议 UDP协议 TCP和UDP的区别 TCP和UDP的使用场景 一 TCP协议 1.TCP的头部格式 理解TCP协议,首要的就是TCP协议的头部格式 ·        Source Port和Destination Port:分别占用16位,表示源端口号和目的端口号:用于区别主机中的不同进程,而IP地址是用来区分不同的主机的,源端口号和目的端口号配合上IP首部中的源IP地址和目的IP地址就能唯一的确定一个TCP连接: ·        Sequence Number:用来标识从T

如何利用wireshark对TCP消息进行分析

(1) 几个概念介绍 1 seq:数据段的序号,计算方法或者增长方式:seq2=seq1+len1(len仅仅是数据段的长度,不包括TCP头)(同一个发送方的tcp报文序号的计算方法) 2 ACK:确认号的计算方法,接收方的ACK号与发送方的SEQ和LEN之间的关系: 甲:发送"seq:x,len:y"给乙: 乙:回复的确认号,x+y,表示它收到了x+y之前的所有字节: 小结: 综合上面SEQ和ACK的计算,可以发现: (1)理论上,接收方回复的Ack恰好就等于发送方的下一个seq号: