TCP连接传输断开分析

最新推荐文章于 2024-03-25 09:00:00 发布

weixin_34247032

最新推荐文章于 2024-03-25 09:00:00 发布

阅读量686

点赞数

文章标签：网络 python java

原文链接：https://my.oschina.net/googlewell/blog/854477

版权

2019独角兽企业重金招聘Python工程师标准>>>

三次握手wireshark数据分析,抓的是245地址的客户端访问217的tomcat服务器的流量包。

下面单独分析每一个TCP数据包，wireshark默认开启了TCP协议的相对顺序号，也就是为什么seq的值是0了，实际上不是，这里我们去掉这个选项，使用真实的seq。

第一个数据包ip245--->217

这里我们只需注意三个地方

TCP Segment Len，也就是该tcp段的长度0，不携带数据，只是发送一次握手。

Sequence number，顺序号2078038420，许多都简写为seq（wireshark默认把TCP第一次握手的值作为基数写为0，以后其他该握手的有效TCP段里都是相对这该值。），我们记做a0。

Acknowledgment number，应答序号，所希望的下一个序号，第一次为0，也就是没有需要应答的内容，对方回应的顺序号可以随意。

Flags，标志位，这里代表SYN，也就是第一次握手连接。

第二个数据包217--->245

TCP Segment Len：0，不携带数据。

Sequence number：2852887843，随机生成的，我们记做b0。

Acknowledgment number：2078038421，我们记做a1，也就是上次对方seq：a0+1，意思就是确认收到a0了，我需要你发下一个序号a1的数据。+1表达了两层意思。

Flags：SYN|ACK,握手和回应，回应上次握手。

第三个数据包245--->217

TCP Segment Len：0，不携带数据。

Sequence number：2078038421，也就是a1，上次期望应答的就是这个序号，这次回复了。

Acknowledgment number：2852887844，我们记做b1，上次对方顺序号b0+1，期望下次回应b1。

Flags：ACK，至此连接基本已经建立，上次获取了对方发送的顺序号了，所以这次只需发送应答信息就好，无需带上SYN标志位了。

下面给出一个三次握手图示

seq为发送序号，ack为回应序号，flag为标志，data为数据长度

seq=a0 ack=0 flag=syn data=0
A-------------------------------------------------->B

seq=b0 ack=a1 flag=syn|ack data=0
A<--------------------------------------------------B

seq=a1 ack=b1 flag= ack data=0
A-------------------------------------------------->B

三次握手已经完成，其他资料介绍到这里就算了，大家有没有想过为什么要进行三次握手，三次握手的作用是什么呢？三次握手实际上就是顺序号的互换。

A：我的顺序号

B：我收到了，这是我的顺序号

A：我收到了

现在双方都有了对方的顺序号了，相当于做个登记，然后如果中间数据传输出现丢失就可以判断了。上面都看到了，TCP里都是不携带数据的，有了顺序号，就可以发送数据了，谁向谁发送数据都可以了。

下面就开始数据传输了。

正常情况下网络数据传输是全双工的，也就是互相发送。现在双方都有自己和对方的顺序号了，可以互相同时发送，这里说简单的，有一方先发送的情况，比如说http请求，握手之后，应当是客户端先发送数据，我请求那个网页，然后服务器返回；对于有的模式，socket连接成功后，客户端只需接受信息，发送的是服务器，也就是推送信息，服务器先发送。这里分析的是http协议，所以首先发送的数据的是客户端。

下面分析第四个数据包了245--->217

TCP Segment Len：367，携带了367字节数据。

Sequence number：2078038421，与上次一致，也就是a1。

Acknowledgment number：2852887844，与上次一致，也就是b1。

Flags：PSH|ACK，PSH就是应用层flush清空缓存的意思，也就是强制发送数据，TCP用PSH给对方一个提示，在telnet等输入一个字符都要实时交互的情况用的非常普遍。

这里看一下Next sequence number：2078038788，也就是Sequence number + TCP Segment Len

有人会疑惑，为什么seq和ack的值与三次握手最后一次的一样。这是因为，B只回应过一次，也就是三次握手的第二次，那次B要求A应答的就是a1，同理，B也只发送了一个b0，我们让B下次应答的也是b1。(额外推测一下，如果不是A先发送数据，是B先发送数据呢，seq肯定是b1，ack就是a2了；如果同时发送数据的话，A收到如愿的b1，但是B收到的确是a1，它想要的是a2，这下乱了，脑仁有点炸。所以感觉可以同时发送，但是必须先有请求的，这地方有点懵逼，查查资料，如果查到再解答。)

下面分析第五个数据包了217--->245

TCP Segment Len：188，携带了188字节数据。

Sequence number：2852887844，上次期望应答的就是这个序号，这次回复了。

Acknowledgment number：2078038788，这个上面用红色特殊说明过，是上次Sequence number + TCP Segment Len，它就表明上次你发的序号和367字节数据都收到了。

下面分析第六个数据包了217--->245

TCP Segment Len：1460，携带了1460字节数据。

Sequence number：2852888032，上次的seq 2852887844+188。

Acknowledgment number：2078038788，和上次一样，还是确认上上次的数据，只是数据太大，分多段回应。

下面分析第七个数据包了245--->217

TCP Segment Len：0，没有携带数据。

Sequence number：2078038788，回应对方上次的请求。

Acknowledgment number：2852888032，是上次Sequence number + TCP Segment Len，它就表明上次你发的序号和1460字节数据都收到了。

下面分析第八个数据包了217--->245

下面分析第九个数据包了217--->245

八九个都是回应的一个包，只是返回分块了。第九个包还发送了结束连接的请求。

至此，一个http请求和服务器返回数据就完成了。具体看一下几个包都是干什么的。

第四个包是发送http的get请求的，一次发完。然后第五、六个数据包是服务器返回的，服务器一个分了4个包返回数据，五、六是前两个，客户端回应了一个数据包七，八、九是后两个，应为九还带了断开连接的请求，这里放在四次挥手里讲。

在这里我们也发现了Sequence number和Acknowledgment number并不是像三次握手那样简单的+1了，而是和TCP段里携带数据大小有关系了。五六八九的ack大家注意一下都是一样的，五六的ack是七的seq，七还没出生，五六就知道了它的seq了。这里提一下，最后一起说，顺便解开自己上面说的懵逼的地方。

列出最后的四次挥手，图中第一个编号542也就是上面说的第九个包