抓包分析 TCP 握手和挥手

前言首先需要明确的是 TCP 是一个可靠传输协议,它的所有特点最终都是为了这个可靠传输服务 。在网上看到过很多文章讲 TCP 连接的三次握手和断开连接的四次挥手,但是都太过于理论,看完感觉总是似懂非懂 。反复思考过后,觉得我自己还是偏工程型的人,要学习这些理论性的知识,最好的方式还是要通过实际案例来理解,这样才会具象深刻 。本文通过 Wireshark 抓包来分析 TCP 三次握手四次挥手,如果你也对这些理论感觉似懂非懂,那么强烈建议你也结合抓包实践来强化理解这些理论性的知识 。
三次握手TCP 建立连接的三次握手是连接的双方协商确认一些信息(Sequence number、Maximum Segment Size、Window Size 等),Sequence number 有两个作用:一个是 SYN 标识位为 1 时作为初始序列号(ISN),则实际第一个数据字节的序列号和相应 ACK 中的确认号就是这个序列号加 1;另一个是 SYN 标识位为 0 时,则是当前会话的 segment(传输层叫 segment,网络层叫 packet,数据链路层叫 frame)的第一个数据字节的累积序列号 。Maximum Segment Size 简称 MSS,表示最大一个 segment 中能传输的信息(不含 TCP、IP 头部) 。Window Size 表示发送方接收窗口的大小 。下面看看我在本地访问博客 mghio 的三次握手过程:

抓包分析 TCP 握手和挥手

文章插图
图中三个小红框表示与服务器建立连接的三次握手 。
  1. 第一步,client 端(这个示例也就是浏览器)发送 SYN 到 server 端;
  2. 第二步,server 端收到 SYN 消息后,回复 SYN + ACK 到client 端,ACK 表示已经收到了 client 的 SYN 消息;
  3. 第三步,client 端收到回复 SYN + ACK 后,也回复一个 ACK 表示收到了 server 端的 SYN + ACK 了,其实
到这一步,client 端的 60469 端口已经是 ESTABLISHED 状态了 。可以看到,其实三次握手的核心目的就是双方互相告知对象自己的 Sequence number,蓝框是 client 端的初始 Sequence number 和 client 端回复的 ACK,绿框是 server 端的初始 Sequence number 和 client 端回复的 ACK 。这样协商好初始 Sequence number 后,发送数据包时发送端就可以判断丢包和进行丢包重传了 。
三次握手还有一个目的是协商一些信息(上图中黄色方框是 Maximum Segment Size,粉色方框是 Window Size) 。
抓包分析 TCP 握手和挥手

文章插图
到这里,就可以知道平常所说的建立TCP连接本质是为了实现 TCP 可靠传输做的前置准备工作,实际上物理层并没有这个连接在那里 。TCP 建立连接之后时拥有和维护一些状态信息,这个状态信息就包含了 Sequence number、MSS、Window Size 等,TCP 握手就是协商出来这些初始值 。而这些状态才是我们平时所说的 TCP 连接的本质 。因为这个太重要了,我还要再次强调一下,TCP 是一个可靠传输协议,它的所有特点最终都是为了这个可靠传输服务 。
四次挥手下面再来看看,当关闭浏览器页面是发生断开连接的四次挥手过程:
抓包分析 TCP 握手和挥手

文章插图
相信你已经发现了,上图抓包抓到的不是四次挥手,而是三次挥手,这是为何呢?
这是由于 TCP 的时延机制(因为系统内核并不知道应用能不能立即关闭),当被挥手端(这里是 server 的 443 端口)第一次收到挥手端(这里是 client 的 63612 端口)的 FIN 请求时,并不会立即发送 ACK,而是会经过一段延迟时间后再发送,但是此时被挥手端也没有数据发送,就会向挥手端发送 FIN 请求,这里就可能造成被挥手端发送的 FIN 与 ACK 一起被挥手端收到,导致出现第二、三次挥手合并为一次的现象,也就最终呈现出“三次挥手”的情况 。

经验总结扩展阅读