TCP源码浅读（6）三次握手-被动方接收ACK

版本：linux 4.18.1

作为学习笔记，本篇只讨论常规的交互过程，旨在理清 linux 内核对 TCP 相关的信息管理。

在 第四节 我们讨论了被动方接受 SYN 后的逻辑，简单回顾一下：

收到 SYN 请求包后，服务端创建一个 request_sock 对象来表示这个 半连接，并添加到 ehash 中管理，此时该 sock 的状态为 TCP_NEW_SYN_RECV。然后就向客户端发送了第二次握手包。

现在我们看下服务端接收到第三次握手后的处理。

入口函数 tcp_v4_rcv 老相识了：

1、首先查找 sock，会在 ehash 中找到代表半连接的 request_sock，它处于 TCP_NEW_SYN_RECV 状态；

2、根据 request_sock 关联到 inet_listen_hashbucket 监听该端口的 tcp_sock （TCP_LISTEN）；

3、调用子流程 tcp_check_req 对 ACK 包做合法性检查，检查通过后，创建一个新的 tcp_sock ，用来表示和客户端的全连接；

4、对新的 tcp_sock 进一步处理。

流程相比之前稍微复杂一些，我们分步骤阅读，首先，进入 tcp_check_req 看下：

1、对客户端发来的第二次握手包做合法性检查，比如序列号是否正确，控制位检查等...；

2、检查通过后，创建一个全新的 tcp_sock 表示这个连接，状态为 TCP_SYN_RECV；

3、把这个新的 sock 添加到 inet_bind_bucket 的 owners 链表 和 ehash 中管理，将代表半连接的 request_sock 从 ehash 中删除；

4、最后将新建的 sock 添加到全连接队列，同时更新半连接数和全连接队列值。

看下执行到这时内核管理信息：

看着眼花缭乱，对着源码看其实很清晰的。

 最后我们进入 tcp_child_process 看下： 

这里会将表示这个全连接的 sock 状态进一步修改为 TCP_ESTABLISHED，然后通知应用程序可以进行数据的交互。

此时状态图和上图一样，只是状态有变更，此处就省略了。