记一次HTTP/TCP数据报的探究

记一次HTTP/TCP数据报的探究

探究背景：我们经常说TCP是传输层协议，IP是网络层协议，HTTP协议是应用层协议等等，那么究竟他们三者是如何融洽的工作在一起的呢？我们今天主要来实验探究一下TCP和HTTP到底是怎么结合的。

实验环境：

server：192.168.254.136，使用  6B

ipv4类型：2B

------------------------------------------------------------------------------------------------------------------------------

头部长度：0.5B

服务类型：1B

总长度：  2B

标识：    2B

TTL：     1B

协议：    1B

校验和：  2B

源IP：    4B

目的IP：  4B

-------------------------------------------------------------------------------------------------------------------------------

目的端口：2B

序列号：  4B

确认号：  4B

保留字段：6bits

URG/ACK/PSH/RST/SYN/FIN各1bit

窗口大小：2B

校验和：  2B

紧急指针：2B

--------------------------------------------------------------------------------------------------------------------------------

padding：6B   填充字段，放置在数据链路层中。

IP报文分析：

4位版本号：IP协议（IPv4）版本号位4

4位头部长度：标识头部有多少个4字节，即最大共15*4个字节

8位服务类型：包含一个4位优先权字段：最小延时，最大吞吐量，最高可靠性和最小费用。

16位总长度：表示整个IP数据报的长度，最大表示65535，但由于MTU限制，一般无法到达这个值。

16位标识：唯一的标识数据报。系统采用加1的方式边发送边赋值。

3位标识（保留，DF禁止分片，MF更多分片）：所以这个标志是为分片存在，DF设置时禁止分片所以如果数据报太大则发送失败。MF设置时，如果产生分片，除了最后一个分片，其他此片置1。

13位分片偏移：分片相对原始IP数据报开始处的偏移。

8位生存时间（TTL）：数据报到达目的地之前允许经过的路由跳跳数。跳一下减1，得0丢弃。

8位协议：用来区分上层协议（ICMP为1，TCP为6，UDP为17）。

16位头部校验和：仅以CRC算法检验数据报头部在传输过程中是否损坏。

32位源IP和目的IP。

TCP报文分析：

16位源端口号和16位目的端口号。

32位序号：一次TCP通信过程中某一个传输方向上的字节流的每个字节的编号，通过这个来确认发送的数据有序，比如现在序列号为1000，发送了1000，下一个序列号就是2000。

32位确认号：用来响应TCP报文段，给收到的TCP报文段的序号加1，三握时还要携带自己的序号。

4位头部长度：标识该TCP头部有多少个4字节，共表示最长15*4=60字节。同IP头部。

6位保留。6位标志。URG（紧急指针是否有效）ACK（表示确认号是否有效）PSH（提示接收端应用程序应该立即从TCP接收缓冲区读走数据）RST（表示要求对方重新建立连接）SYN（表示请求建立一个连接）FIN（表示通知对方本端要关闭连接）

16位窗口大小：TCP流量控制的一个手段，用来告诉对端TCP缓冲区还能容纳多少字节。

16位校验和：由发送端填充，接收端对报文段执行CRC算法以检验TCP报文段在传输中是否损坏。

16位紧急指针：一个正的偏移量，它和序号段的值相加表示最后一个紧急数据的下一字节的序号。

分析完这60个字节的TCP报文之后再接着看6号报文，这个同样是服务器端发送给客户端的TCP报文，与上一个报文看看有何不同。我们来逐个对比一下上述字段。

首先就是整个IP数据报的长度不一样了，一个是40一个是1500，然后标识不一样了，由17800变成了17801，验证了刚刚说的自增的方式排序。当然校验和肯定也就不一样了，所以IP数据报文只有这两处不同，不算校验和。

TCP报文中前面部分除了校验和均相同，只是在最后附加了一个1460字节的数据字段，那么多个数据包之间有什么联系呢？

我们单独看5-8这几个包，当客户端发出请求后，服务器端先发送一个空的TCP包，所以Seq=1，Len=0，下一个包的Seq仍然是1，但是长度变成了1460，那么第三个TCP包的Seq则为1+1460，即Seq2=Seq1+Len。而ACK不变，那么客户端接受之后发送反馈包，Seq为服务器端的Ack数字，Ack为上一个数据包的Seq+Len，即1461+1460=2921。

然后服务器端继续向客户端发送数据，9号报文的序列号为2921，是客户端响应报文中的Ack，Ack仍然是370，长度为1460。10号报文的Seq也是9号报文的Seq+Len=2921+1460=4381，11号为客户端响应报文，Seq保持370不变，Ack为4381+1460=5841。

同样的道理，下面三个数据包也符合这个规律。最后传输完毕，第15个报文组成一段完整的HTTP报文。

但是需要注意的是，尽管第15个包在wireshark里是写的HTTP，但实际上这个包也是TCP的数据包，包含TCP的数据！

我们来看，前四行都是和普通的TCP报文是一样的，并且长度为1431，不足1460，说明传输完成了。

最后两行是HTTP报文，也就是说收到了全部的TCP传输报文，并合并为一个完整的HTTP应答报文。

然后TCP四次断开，不再详解。提示一点就是，16号包Seq是15号包中的Seq+Len 即：10192=8761+1431，17号包的Ack是16号包的Seq+1

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。