探究背景：我们经常说TCP是传输层协议，IP是网络层协议，HTTP协议是应用层协议等等，那么究竟他们三者是如何融洽的工作在一起的呢？我们今天主要来实验探究一下TCP和HTTP到底是怎么结合的。
实验环境：
server：192.168.254.136，使用httpd作为web服务，复制nginx的首页静态页作为demo
client：192.168.254.1，wireshark抓包
实验步骤：
从客户端访问服务器端，抓取数据包。
报文摘录：
报文分析：
1、第一步，老生成谈的TCP三次握手机制，先进行了三次握手，然后建立连接，此处不再展开。
2、接下来，4号数据包是客户端向服务器端发送HTTP的get请求，内容略。
3、然后是这次我要说的重点部分了。4号报文是客户端向服务器端发送了请求，那么5号报文则开始响应这次请求，第一个TCP包并没有包含任何有效载荷，只有一个60字节的TCP头。我们展开这个报文看看60字节包含什么。
目的mac：6B
源mac： 6B
ipv4类型：2B
------------------------------------------------------------------------------------------------------------------------------
IP版本： 0.5B
头部长度：0.5B
服务类型：1B
总长度： 2B
标识： 2B
标志：3bits片偏移：13bits 共2B
TTL： 1B
协议： 1B
校验和： 2B
源IP： 4B
目的IP： 4B
-------------------------------------------------------------------------------------------------------------------------------
源端口： 2B
目的端口：2B
序列号： 4B
确认号： 4B
头部长度：0.5B
保留字段：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
