wireshark抓包tcp为何没有四次挥手而是三次挥手

最新推荐文章于 2024-06-25 04:50:10 发布

yiichan

最新推荐文章于 2024-06-25 04:50:10 发布

阅读量5.2k

点赞数 4

分类专栏： Linux 网络文章标签： vscode ubuntu linux

本文链接：https://blog.csdn.net/Yichuan_Sun/article/details/121524432

版权

Linux 同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

网络

1 篇文章 0 订阅

订阅专栏

在wireshark上抓包，使用telnet直接连接baidu的ip，端口使用www，

p4@u1804:~$ ping www.baidu.com
PING www.a.shifen.com (183.232.231.174) 56(84) bytes of data.
64 bytes from 183.232.231.174 (183.232.231.174): icmp_seq=1 ttl=128 time=37.8 ms
64 bytes from 183.232.231.174 (183.232.231.174): icmp_seq=2 ttl=128 time=82.9 ms
^C
--- www.a.shifen.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 37.866/60.400/82.935/22.535 ms

ip是183.232.231.174，telnet连接一下，输入了个字符串“what???”

p4@u1804:~$ telnet 183.232.231.172 www
Trying 183.232.231.172...
Connected to 183.232.231.172.
Escape character is '^]'.
what???
HTTP/1.1 400 Bad Request

Connection closed by foreign host.

wireshark抓包记录如下

可以看到三次握手（3,4,5）很正常，但是四次挥手却少了一次ack，成了三次挥手（13,14,15）。

上网查资料，发现有一种说法是，像《wireshark网络分析的艺术》P12-P21里说，由于延迟确认（也就是确认报文由下一个发送报文携带，一起传送过来），第二次挥手ack与第三次挥手fin合并成了一次，也就是包14。

** Seq是当前发送报文的第一个字节的序列号。Ack是确认号，期望收到对方下一个报文的第一个字节的序列号（可以理解为请求对方发送的第一个字节的序列号）。 ** Win是发送窗口的大小，单位字节。大写ACK和小写Ack不是同一个概念。

SYN和ACK、FIN、PSH都是标志位，SYN表示连接建立和连接接受请求，ACK只有为1时确认号Ack才有效，而且规定在连接建立以后所有传送的报文段ACK都要置为1。FIN指释放连接标志位，表示要释放一个连接。PSH是推送标志位，当两个进程通信时，有时一端想键入命令后立即收到对方的响应，就会把这一位置为1，接收方收到PSH=1的报文，会尽快地交付接收进程，而不再等整个缓存都填满了后再向上交付。

下面详细说一下三次握手和四次挥手的过程。用点分十进制的最后一个数字代表其IP地址。数字表示包的序列号，在抓包截图的第一列。Seq和Ack的功能是简述，不全述。

第一次握手，3。213 -> 172，发送SYN=1的tcp报文，Seq=0。请求建立连接，发送213的0号字节。

第二次握手，4。172 -> 213，发送SYN=1，ACK=1的tcp报文，Seq=0，Ack=1。对连接请求进行回复，同意建立连接，发送172的0号字节，请求213的1号字节。

第三次握手，5。213 -> 172，发送ACK=1的tcp报文，Seq=1，Ack=1。请求发送端通知接收端连接建立成功，发送213的1号字节，请求172的1号字节。

9,10,11,12，我输入what???的发送过程，以及172对我的应答，包11显示这是个bad request。http报文的解析如下。显示当前Sequence number是1，Acknowledgement number是10，意为当前发送包首字节序列号是10，请求213发送首字节序列号是10的包。在包12中213做了回复。