深入理解 Linux 的 TCP 三次握手

约定不等于承诺〃 2024-04-08 10:36 49阅读 0赞

在后端相关岗位的入职面试中，三次握手的出场频率非常的高，甚至说它是必考题也不为过。一般的答案都是说客户端如何发起 SYN 握手进入 SYN\_SENT 状态，服务器响应 SYN 并回复 SYNACK，然后进入 SYN\_RECV 等诸如此类。但今天我想给出一份不一样的答案。

其实三次握手在内核的实现中，并不只是简单的状态的流转，还包括端口选择，半连接队列、syncookie、全连接队列、重传计时器等关键操作。如果能深刻理解这些，你对线上把握和理解将更进一步。如果有面试官问起你三次握手，相信这份答案一定能帮你在面试官面前赢得非常多的加分。

在基于 TCP 的服务开发中，三次握手的主要流程图如下：

![ca22c4b8e6e60ef170e1408142630e0d.jpeg][]

服务器中的核心代码是创建 socket，绑定端口，listen 监听，最后 accept 接收客户端的请求。

<table> 
 <tbody> 
  <tr> 
   <td>//服务端核心代码<br> int main ( int argc, char const *argv[])<br> { <br> int fd = socket(AF_INET, SOCK_STREAM, 0 );<br> bind(fd, ...);<br> listen(fd, 128 );<br> accept(fd, ...);<br> ...<br> }</td> 
  </tr> 
 </tbody> 
</table>

客户端的相关代码是创建 socket，然后调用 connect 连接 server。

<table> 
 <tbody> 
  <tr> 
   <td>//客户端核心代码<br> int main () { <br> fd = socket(AF_INET,SOCK_STREAM, 0 );<br> connect(fd, ...);<br> ...<br> }</td> 
  </tr> 
 </tbody> 
</table>

看起来简单的几个系统调用，实际上却包含了非常复杂的内核底层操作。根据内核工作原理，我深度展开一下三次握手过程中的内部操作。

友情提示 ：本文中内核源码会比较多。如果你能理解的了更好，如果觉得理解起来有困难，那直接重点看本文中的描述性的文字，尤其是加粗部分的即可。另外文章最后有一张总结图归纳和整理了全文内容。

一、服务器的 listen

我们都知道，服务器在开始提供服务之前都需要先 listen 一下。但 listen 内部究竟干了啥，我们平时很少去琢磨。

今天就让我们详细来看看，直接上一段 listen 时执行到的内核代码。

<table> 
 <tbody> 
  <tr> 
   <td>//file: net/core/request_sock.c<br> int reqsk_queue_alloc (struct request_sock_queue * queue ,<br> unsigned int nr_table_entries)<br> { <br> size_t lopt_size = sizeof (struct listen_sock);<br> struct listen_sock * lopt ;<br><br> //计算半连接队列的长度<br> nr_table_entries = min_t (u32, nr_table_entries, sysctl_max_syn_backlog);<br> nr_table_entries = ......<br><br> //为半连接队列申请内存<br> lopt_size += nr_table_entries * sizeof (struct request_sock *);<br> if (lopt_size &gt; PAGE_SIZE)<br> lopt = vzalloc(lopt_size);<br> else<br> lopt = kzalloc(lopt_size, GFP_KERNEL);<br><br> //全连接队列头初始化<br> queue -&gt;rskq_accept_head = NULL ;<br><br> //半连接队列设置<br> lopt-&gt;nr_table_entries = nr_table_entries;<br> queue -&gt;listen_opt = lopt;<br> ......<br> }</td> 
  </tr> 
 </tbody> 
</table>

在这段代码里，内核计算了半连接队列的长度。然后据此算出半连接队列所需要的实际内存大小，开始申请用于管理半连接队列对象的内存（半连接队列需要快速查找，所以内核是用哈希表来管理半连接队列的，具体在 listen\_sock 下的 syn\_table 下）。最后将半连接队列挂到了接收队列 queue 上。

另外 queue->rskq\_accept\_head 代表的是全连接队列，它是一个链表的形式。在 listen 这里因为还没有连接，所以将全连接队列头 queue->rskq\_accept\_head 设置成 NULL。

当全连接队列和半连接队列中有元素的时候，他们在内核中的结构图大致如下。

![857d7e3bf79f2557335931a20cb1aa44.png][]

在服务器 listen 的时候，主要是进行了全/半连接队列的长度限制计算，以及相关的内存申请和初始化 。全/连接队列初始化了以后才可以相应来自客户端的握手请求。

二、客户端 connect

客户端通过调用 connect 来发起连接。在 connect 系统调用中会进入到内核源码的 tcp\_v4\_connect。

<table> 
 <tbody> 
  <tr> 
   <td>//file: net/ipv4/tcp_ipv4.c<br> int tcp_v4_connect (struct sock *sk, struct sockaddr *uaddr, int addr_len)<br> { <br> //设置 socket 状态为 TCP_SYN_SENT<br> tcp_set_state(sk, TCP_SYN_SENT);<br><br> //动态选择一个端口<br> err = inet_hash_connect(&amp;tcp_death_row, sk);<br><br> //函数用来根据 sk 中的信息，构建一个完成的 syn 报文，并将它发送出去。<br> err = tcp_connect(sk);<br> }</td> 
  </tr> 
 </tbody> 
</table>

在这里将完成把 socket 状态设置为 TCP\_SYN\_SENT。再通过 inet\_hash\_connect 来动态地选择一个可用的端口后（端口选择详细过程参考前文

[ca22c4b8e6e60ef170e1408142630e0d.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a73b197b806b4d099a429e51f0d7f528.jpeg
[857d7e3bf79f2557335931a20cb1aa44.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/c1f780d6e9f44926a253eb96e1213bb6.png