版本: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,然后通知应用程序可以进行数据的交互。
此时状态图和上图一样,只是状态有变更,此处就省略了。