版本：linux 4.18.1
作为学习笔记，本篇只讨论常规的交互过程，旨在理清 linux 内核对 TCP 相关的信息管理。
服务端调用 listen 函数后一直处于 TCP_LISTEN 状态，等待客户端的连接请求；
上一节我们分析了第一握手，客户端发送了 SYN 包，现在我们来看下服务端接收 SYN 包后的处理过程。
内核收到任何 TCP 消息，都会进入该函数。首先在全局的 tcp_hashinfo 中查找 sock，然后进行相应的处理。
看下查找过程：
服务端在某个 inet_listen_hashbucket 中找到与请求包目的端口对应的 sock，它处于 TCP_LISTEN 状态。
此后，服务端创建一个 request_sock 对象来表示这个半连接，并添加到ehash 中管理；
最后构建 SYN+ACK 响应包，向客户端发送 第二次握手。
这里有个地方需要注意， 代表这个半连接的 sock 的状态是 TCP_NEW_SYN_RECV，不是 TCP_SYN_RECV，这和以前学到的三次握手状态转换图有点出入。
查阅资料发现这个状态是 Linux 4.4+ 以后新增的，本文主要以理清握手过程为主，暂不深究为什么新增这个状态，以后再探讨。
服务端发送第二次握手后，内核中保存的 tcp 相关信息如下所示：
未完待续...
