Linux下TCPIP连接及其内核参数
2017-09-03 22:09:47 阿炯
本站赞助商链接，请多关照。 TCP连接的状态

首先介绍一下TCP连接建立与关闭过程中的状态。TCP连接过程是状态的转换，促使状态发生转换的因素包括用户调用、特定数据包以及超时等，具体状态如下所示：

CLOSED：初始状态，表示没有任何连接。

LISTEN：Server端的某个Socket正在监听来自远方的TCP端口的连接请求。

SYN_SENT：发送连接请求后等待确认信息。当客户端Socket进行Connect连接时，会首先发送SYN包，随即进入SYN_SENT状态，然后等待Server端发送三次握手中的第2个包。

SYN_RECEIVED：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态，表示Server端的Socket接收到来自Client的SYN包，并作出回应。

ESTABLISHED：表示连接已经建立，可以进行数据传输。

FIN_WAIT_1：主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包(表示己方不再有数据需要发送)，则进入FIN_WAIT_1状态，等待对方返回ACK包，此后还能读取数据，但不能发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回ACK包，所以FIN_WAIT_1状态一般很难见到。

FIN_WAIT_2：主动关闭连接的一方收到对方返回的ACK包后，等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后，便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包，所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时，则直接进入TIME_WAIT状态，无须经过FIN_WAIT_2状态。

TIME_WAIT：主动关闭连接的一方收到对方发送的FIN包后返回ACK包(表示对方也不再有数据需要发送，此后不能再读取或发送数据)，然后等待足够长的时间(2MSL)以确保对方接收到ACK包(考虑到丢失ACK包的可能和迷路重复数据包的影响)，最后回到CLOSED状态，释放网络资源。

CLOSE_WAIT：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后(表示对方不再有数据需要发送)，相应的返回ACK包，然后进入CLOSE_WAIT状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发送，但不能再读取数据，直到数据发送完毕。

LAST_ACK：被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包(表示己方不再有数据需要发送)，然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态，释放网络资源。

CLOSING：比较罕见的例外状态。正常情况下，发送FIN包后应该先收到(或同时收到)对方的ACK包，再收到对方的FIN包，而CLOSING状态表示发送FIN包后并没有收到对方的ACK包，却已收到了对方的FIN包。有两种情况可能导致这种状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；其二，如果ACK包丢失而对方的FIN包很快发出，也会出现FIN先于ACK到达。


在本站的参考手册中亦有《TCP连接状态详解》，可以前往查看，在正式开始介绍前，可以了解一下ISO与TCP大分层上的关系，如下图：



TCP连接的状态转换如下图所示



TCP连接的关闭方式

建立TCP连接需要三次握手，而关闭连接则需要四次握手，并且分为主动关闭和被动关闭。这是由于TCP连接是全双工的，我关了你的连接，并不等于你关了我的连接，因此双方都必须单独进行关闭。当一方完成它的数据发送任务后可以发送FIN包来终止这个方向的连接，表明自己不再有数据需要发送；收到FIN包的那一方虽然不能再读取数据，但仍能发送数据。以Client主动关闭连接为例：

Client向Server发送FIN包，表示Client主动关闭连接，然后进入FIN_WAIT_1状态，等待Server返回ACK包。此后Client不能再向Server发送数据，但能读取数据。

Server收到FIN包后向Client发送ACK包，然后进入CLOSE_WAIT状态，此后Server不能再读取数据，但可以继续向Client发送数据。Client收到Server返回的ACK包后进入FIN_WAIT_2状态，等待Server发送FIN包。

Server完成数据的发送后，将FIN包发送给Client，然后进入LAST_ACK状态，等待Client返回ACK包，此后Server既不能读取数据，也不能发送数据。

Client收到FIN包后向Server发送ACK包，然后进入TIME_WAIT状态，接着等待足够长的时间(2MSL)以确保Server接收到ACK包，最后回到CLOSED状态，释放网络资源。Server收到Client返回的ACK包后便回到CLOSED状态，释放网络资源。

TCP连接的建立到关闭，需要经历以下状态迁移(假定Client发起连接，并主动关闭连接)：

Client
CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

Server
CLOSED -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

对Server与Client的影响

在详细了解TCP连接的状态和关闭方式后，我们会发现TIME_WAIT状态是一个奇葩的存在！主动关闭连接的一方在发送最后一个ACK包后，无论对方是否收到都会进入TIME_WAIT状态，等待2MSL的时间，然后才能释放网络资源。MSL就是Maximum Segment Lifetime(数据包的最大生命周期)，是一个数据包能在互联网上生存的最长时间，若超过这个时间则该数据包将会消失在网络中。操作系统通常会将2MSL设为4分钟，最低不少于30秒，因而TIME_WAIT状态一般维持在30秒至4分钟。这个是TCP/IP协议必不可少的，是TCP/IP设计者设计的，也就是无法解决的。TIME_WAIT状态的存在主要有两个原因：
1)、可靠地实现TCP全双工连接的终止。在关TCP闭连接时，最后的ACK包是由主动关闭方发出的，如果这个ACK包丢失，则被动关闭方将重发FIN包，因此主动方必须维护状态信息，以允许它重发这个ACK包。如果不维持这个状态信息，那么主动方将回到CLOSED状态，并对被动方重发的FIN包响应RST包，而被动关闭方将此包解释成一个错误(在Java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须能够处理四次握手协议中任意一个包丢失的情况，主动关闭方必须维持状态信息进入TIME_WAIT状态。
2)、确保迷路重复数据包在网络中消失，防止上一次连接中的包迷路后重新出现，影响新连接。TCP数据包可能由于路由器异常而迷路，在迷路期间，数据包发送方可能因超时而重发这个包，迷路的数据包在路由器恢复后也会被送到目的地，这个迷路的数据包就称为Lost Duplicate。在关闭一个TCP连接后，如果马上使用相同的IP地址和端口建立新的TCP连接，那么有可能出现前一个连接的迷路重复数据包在前一个连接关闭后再次出现，影响新建立的连接。为了避免这一情况，TCP协议不允许使用处于TIME_WAIT状态的连接的IP和端口启动一个新连接，只有经过2MSL的时间，确保上一次连接中所有的迷路重复数据包都已消失在网络中，才能安全地建立新连接。

对于Client而言，每个连接都需要占用一个端口，而系统允许的可用端口数不足65000个(这也是在TCP参数优化后才能达到)。因此如果Client发起过多的连接并主动关闭(假设没有重用端口或者连接多个Server)，就会有大量的连接在关闭后处于TIME_WAIT状态，等待2MSL的时间后才能释放网络资源(包括端口)，于是Client会由于缺少可用端口而无法新建连接。

对Server而言(特别是处理高并发短连接的Server)，Server端与Client建立的连接是使用同一个端口的，即监听的端口，每个连接通过一个五元组区分，包括源IP地址、源端口、传输层协议号(协议类型)、目的IP地址、目的端口，因而在理论上，Server不受系统端口数的限制。但是Server对每个端口上的连接数是有限制的，它要使用哈希表记录端口上的每个连接，并受到文件描述符的最大打开数的限制。所以，如果Server主动关闭连接，同样会有大量的连接在关闭后处于TIME_WAIT状态，等待2MSL的时间后才能释放网络资源(包括哈希表上的连接记录和文件描述符)，于是Server会由于达到哈希表和文件描述符的限制而无法接受新连接，造成性能的急剧下滑，性能曲线会持续产生严重的波动。对于这种情况，有三种应对方式：
试图让Client主动关闭连接，由于每个Client的并发量都比较低，因而不会产生性能瓶颈。
优化Server的系统TCP参数，使其网络资源的最大值、消耗速度和恢复速度达到平衡。
改写TCP协议，重新实现底层代码，不过该方式难度很大，而且系统的稳定性和安全性可能受到影响。

理解/proc/sys/net目录下参数

所有的TCP/IP参数都位于/proc/sys/net目录下(请注意，对/proc/sys/net目录下内容的修改都是临时的，任何修改在系统重启后都会丢失)，例如下面这些重要的参数：

参数(路径+文件)

描述

默认值

优化值

/proc/sys/net/core/rmem_default

默认的TCP数据接收窗口大小(字节)。

229376

256960

/proc/sys/net/core/rmem_max

最大的TCP数据接收窗口(字节)。

131071

513920

/proc/sys/net/core/wmem_default

默认的TCP数据发送窗口大小(字节)。

229376

256960

/proc/sys/net/core/wmem_max

最大的TCP数据发送窗口(字节)。

131071

513920

/proc/sys/net/core/netdev_max_backlog

在每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。

1000

2000

/proc/sys/net/core/somaxconn

定义了系统中每一个端口最大的监听队列的长度，这是个全局的参数。

128

2048

/proc/sys/net/core/optmem_max

表示每个套接字所允许的最大缓冲区的大小。

20480

81920

/proc/sys/net/ipv4/tcp_mem

确定TCP栈应该如何反映内存使用，每个值的单位都是内存页(通常是4KB)。第一个值是内存使用的下限；第二个值是内存压力模式开始对缓冲区使用应用压力的上限；第三个值是内存使用的上限。在这个层次上可以将报文丢弃，从而减少对内存的使用。对于较大的BDP可以增大这些值(注意，其单位是内存页而不是字节)。

94011  125351  188022

131072  262144  524288

/proc/sys/net/ipv4/tcp_rmem

为自动调优定义socket使用的内存。第一个值是为socket接收缓冲区分配的最少字节数；第二个值是默认值(该值会被rmem_default覆盖)，缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是接收缓冲区空间的最大字节数(该值会被rmem_max覆盖)。

4096  87380  4011232

8760  256960  4088000

/proc/sys/net/ipv4/tcp_wmem

为自动调优定义socket使用的内存。第一个值是为socket发送缓冲区分配的最少字节数；第二个值是默认值(该值会被wmem_default覆盖)，缓冲区在系统负载不重的情况下可以增长到这个值；第三个值是发送缓冲区空间的最大字节数(该值会被wmem_max覆盖)。

4096  16384  4011232

8760  256960  4088000

/proc/sys/net/ipv4/tcp_keepalive_time

TCP发送keepalive探测消息的间隔时间(秒)，用于确认TCP连接是否有效。

7200

1800

/proc/sys/net/ipv4/tcp_keepalive_intvl

探测消息未获得响应时，重发该消息的间隔时间(秒)。

75

30

/proc/sys/net/ipv4/tcp_keepalive_probes

在认定TCP连接失效之前，最多发送多少个keepalive探测消息。

9

3

/proc/sys/net/ipv4/tcp_sack

启用有选择的应答(1表示启用)，通过有选择地应答乱序接收到的报文来提高性能，让发送者只发送丢失的报文段，(对于广域网通信来说)这个选项应该启用，但是会增加对CPU的占用。

1

1

/proc/sys/net/ipv4/tcp_fack

启用转发应答，可以进行有选择应答(SACK)从而减少拥塞情况的发生，这个选项也应该启用。

1

1

/proc/sys/net/ipv4/tcp_timestamps

TCP时间戳(会在TCP包头增加12个字节)，以一种比重发超时更精确的方法(参考RFC 1323)来启用对RTT 的计算，为实现更好的性能应该启用这个选项。

1

1

/proc/sys/net/ipv4/tcp_window_scaling

启用RFC 1323定义的window scaling，要支持超过64KB的TCP窗口，必须启用该值(1表示启用)，TCP窗口最大至1GB，TCP连接双方都启用时才生效。

1

1

/proc/sys/net/ipv4/tcp_syncookies

表示是否打开TCP同步标签(syncookie)，内核必须打开了CONFIG_SYN_COOKIES项进行编译，同步标签可以防止一个套接字在有过多试图连接到达时引起过载。

1

1

/proc/sys/net/ipv4/tcp_tw_reuse

表示是否允许将处于TIME-WAIT状态的socket(TIME-WAIT的端口)用于新的TCP连接 。

0

1

/proc/sys/net/ipv4/tcp_tw_recycle

能够更快地回收TIME-WAIT套接字。

0

1

/proc/sys/net/ipv4/tcp_fin_timeout

对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间(秒)。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。

60

30

/proc/sys/net/ipv4/ip_local_port_range

表示TCP/UDP协议允许使用的本地端口号

32768  61000

1024  65000

/proc/sys/net/ipv4/tcp_max_syn_backlog

对于还未获得对方确认的连接请求，可保存在队列中的最大数目。如果服务器经常出现过载，可以尝试增加这个数字。

2048

2048

/proc/sys/net/ipv4/tcp_low_latency

允许TCP/IP栈适应在高吞吐量情况下低延时的情况，这个选项应该禁用。

0

 

/proc/sys/net/ipv4/tcp_westwood

启用发送者端的拥塞控制算法，它可以维护对吞吐量的评估，并试图对带宽的整体利用情况进行优化，对于WAN 通信来说应该启用这个选项。

0

 

/proc/sys/net/ipv4/tcp_bic

为快速长距离网络启用Binary Increase Congestion，这样可以更好地利用以GB速度进行操作的链接，对于WAN通信应该启用这个选项。

1

 


上节源自：最初的幸福ever

从开发角度看TCP网络协议栈的工作原理

一、TCP 网络开发 API

TCP，全称传输控制协议（Transmission Control Protocol），是一种面向连接的、可靠的、基于字节流的传输层通信协议。

1.1、TCP 服务器调用的 API
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>

// 1
int socket(int domain, int type, int protocol);

// 2
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

// 3
int listen(int sockfd, int backlog);

// 4
ssize_t recv(int sockfd, void *buf, size_t len, int flags);

// 5
int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

// 6
ssize_t send(int sockfd, const void *buf, size_t len, int flags);

// 7
int close(int fd);

// 8
int shutdown(int sockfd, int how);

1.2、TCP 客户端调用的 API
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>

// 1
int socket(int domain, int type, int protocol);

// 2
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

// 3
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

// 4
ssize_t send(int sockfd, const void *buf, size_t len, int flags);

// 5
ssize_t recv(int sockfd, void *buf, size_t len, int flags);

// 6
int close(int fd);

// 7
int shutdown(int sockfd, int how);

1.3、API 函数的作用
（1）int socket(int domain, int type, int protocol)
在文件系统中分配一个 fd，并创建 TCB 数据结构。

（2）int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
为 TCP 的 socket 绑定本地 IP 地址和端口。

（3）int listen(int sockfd, int backlog)
将 TCP 置于 LISTEN 状态。

（4）int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen)
从全连接队列中取出一个节点，并分配一个 fd。

（5）ssize_t recv(int sockfd, void *buf, size_t len, int flags)
在对应 fd 中，从读缓冲区中拷贝出数据。

（6）ssize_t send(int sockfd, const void *buf, size_t len, int flags)
把 fd 对应的 TCB 数据拷贝到写缓冲区中。

（7）int close(int fd)
准备一个 FIN 包，放到写缓冲区，是否 fd。

（8）int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
准备一个 SYN 包，交给协议栈发送出去，等待三次握手完成后才返回。

二、TCP 的三个阶段

2.1 TCP 建立连接
TCP 连接的建立主要依靠 socket ()、bind ()、listen ()、connect ()、accept () 这几个函数。

2.1.1、TCP 的三次握手
示意图：


三次握手在 kernel 协议栈中进行，那么三次握手是在哪几个函数中发送的呢？

第一次，由 connect () 函数触发 发起握手，也就是发送 syn 包到服务端；

第二次，在 listen () 之后 accept () 之前，服务器接收到 syn 包后发送 syn&&ack 包到客户端；

第三次，客户端发送 ack 包到服务端完成连接的建立。

TCP 报头：
0 |1 |2 |3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Source Port | Destination Port |
+---------------------------------------------------------------+
| Sequence Number |
+---------------------------------------------------------------+
| Acknowledgment Number |
+-------+-----------+-+-+-+-+-+-+-------------------------------+
| Header| Reserve |U|A|P|R|S|F| Window |
| Length| |R|C|S|S|Y|I| |
| | |G|K|H|T|N|N| |
+-------------------------------+-------------------------------+
| Checksum | Urgent Pointer |
+---------------------------------------------------------------+
| Option |
+---------------------------------------------------------------+
| Data |
| ... |
+---------------------------------------------------------------+

SYN：即 synchronous，同步。
ACK：即 acknowledgement，确认。
PSH：即 push，推送。
FIN ：即 finish，结束。
RST：即 reset，重置。
URG：即 urgent，紧急。
Sequence Number：是数据包本身第一个字节的序列号。
Acknowledge Number：是期望对方继续发送的那个确认数据包的序列号其值一般为接收到的 Sequence Number 加 1。

从报文中可以看出，SYN 包最重要的是将 SYN 位设为 1，设置 Sequence Number；ACK 包最重要的是将 ACK 位设为 1，设置 Acknowledgment Number。

半连接队列和全连接队列：

在三次握手中，Linux kener 协议栈会维护两个队列：半连接队列和全连接队列。

半连接队列（也叫 SYN 队列）：半连接队列在第一握手中，当客户端发送 SYN 包到服务端时，服务端的半连接队列会加入一个节点，表示此连接处于半连接状态。

全连接队列（也叫 ACCEPT 队列）：全连接队列在第三握手中，当客户端发送 ACK 包到服务端时，服务端会检查半连接队列中是否存在此连接节点（通过五元组进行查找），如果存在就将此连接节点加入全连接队列中；否则将抛弃此连接。

accpt () 函数在三次握手完成后，从全连接队列中取出连接节点，为节点分配 socket fd，返回到用户态。

那么，accept () 函数如何知道全连接队列中有节点呢？

当三次握手完成后，全连接队列创建节点的同时会释放一个有连接接入的信号（single 或信号量），这个信号决定了 accept () 函数是否可以从全连接队列中取节点；也决定 epoll 等 IO 多路复用器能不能检查这个连接 fd 是否可读。

在阻塞模式下，accept () 函数一直等待信号，直到全连接队列中有节点才返回。

在非阻塞模式下，全连接队列为空 accept () 函数就返回 - 1，否则返回 socket fd。

在 listen () 函数有，有一个 backlog 参数，这个参数表示的是全连接队列的大小还是半连接队列的大小呢？

随着 TCP 协议的不断迭代，backlog 参数在不同的版本中代表的含义也不相同；它可以是半连接队列大小，也可以是全连接队列大小，也可以是半连接队列 + 全连接队列的大小总和。不过，效果不会有太大差异。目前版本中主要表示全连接队列的大小。

DDOS 攻击：

根据三次握手原理，产生一种对服务器的攻击方式：DDOS 攻击。所谓 DDOS 攻击，就是客户端伪造一些不存在的 IP，一直发送 SYN 包，使服务器的半连接队列不断增大，当半连接队列的大小达到极限时，造成网络阻塞就会导致服务器无法再接受连接，从而使服务器奔溃。

2.1.2、TCP 状态转换
TCP 状态转换图：


（1）从状态转换图看出，LISTEN 状态可以通过发送 SYN 和数据转换到 SYN_SEND 状态；也就是 LISTEN 状态可以发送数据。

（2）SYN_SEND 状态可以收到 SYN，并发送 SYN 和 ACK 转换到 SYN_RECV 状态；也就是两个设备可以互发 SYN 包，建立连接。

2.2 TCP 传输数据
TCP 传输数据主要依靠 send() 和 recv() 两个函数。使用 send() 函数发送数据时，返回正数不一定代表发送成功。因为 send() 函数仅仅只是将数据拷贝到协议栈的写缓冲区，由协议栈发送；发送过程中会经过 N 个网关，可能存在丢包或链路断开导致未能发送到目的地。如果要知道数据是否发送成功，需要加上确认机制（ACK）。

2.2.1、传输控制块 TCB
为了保证数据能正确分发，TCP 使用一种 TCB（传输控制块）的数据结构，把发送给不同设备的数据封装起来。这个 TCB 会存在整个 TCP 周期，知道断开连接。一个 TCB 数据块包含数据发送双方对应的 socket 信息以及拥有存放数据的缓冲区。建立连接连接发送数据之前，通信双方必须做一个准备工作：分配内存建立 TCB 数据块。当双方准备好自己的 socket 和 TCB 数据结构后，就可以进入 “三次握手” 建立连接。

2.2.2、TCP 分包
TCP 分包就是要传输的数据很大，超出发送缓存区剩余空间，将会进行分包；待发送的数据大于最大报文长度，TCP 在传输前将进行分包。

分包在应用程序的处理一般是发送循环 send ()，接收方循环 recv ()。

2.2.3、TCP 粘包及解决方案
TCP 粘包就是发送方发送的若干数据包到接收方接收时粘成一个包，从接收缓冲区看就是后数据包的头紧接着前数据包的尾。

常见解决方案：
（1）（推荐）应用层协议头前面添加包长度。分两次接收数据；第一次先接收包的长度，然后根据包的长度一次性读取或循环读取数据。

例如：
// ...
ssize count=0;
ssize size=0;
while(count<tcpHdr->length){
size=recv(fd,buffer,buffersize,0);
count+=size;
}
// ...

（2）为每个包添加分隔符。在数据末尾添加分隔符，这会导致解数据可能需要有合包操作；因为分割数据包后，需要记录后一个数据包，用于与该包后面部分数据进行合并。


2.3 TCP 四次挥手
断开连接是比建立连接和传输数据还复杂的一个过程，断开连接主要分为主动关闭和被动关闭两种。

四次挥手示意图：


需要注意的是，调用 close () 不是立即完成断开，而是关闭了数据传输，进入了四次挥手阶段，TCB 数据结构还没有释放。四次挥手结束才真正把 TCB 释放。

根据四次挥手流程，可以思考一些问题：
（1）传输数据过程中，网线断了之后立刻连接，TCP 如何知道？
网线掉线网卡会停止供电，再次连接后网卡恢复供电，网卡服务重启，网络连接重连。应用程序设计通过心跳包检测。

（2）服务器如何知道客户端是否宕机？
一样需要通过心跳包机制来检测。

（3）服务器如何甄别网络阻塞和宕机？
服务器发送心跳包时，不仅仅发一次，而是要发送多次的；如果是网络阻塞，那么在一定时间内一定有回复信息；如果是宕机，无论多长时间都没有客户端的回复。

（4）如果出现大量的 CLOSING 状态，如何处理？
出现大量 CLOSING 状态，基本上业务上要处理的逻辑过多，导致一直在 CLOSING 状态；可以使用异步，将网络层和业务层分离，单独处理。

（5）四次挥手中，为什么存在 TIME_WAIT 状态？
防止没有 LAST_ACK 或 LAST_ACK 丢失，导致一直重发已经不存在的 socket。

小结

需要掌握 TCP 三次握手和四次挥手的过程，熟悉 TCP 状态转换。清楚什么是 SYN 包和 ACK 包。

（1）三次握手是 由客户端发起 SYN，服务端收到 SYN 后发送 SYN 和 ACK，客户端回复 ACK；完成连接的建立。

（2）断开连接主要有主动断开和被动断开。

（3）四次挥手是 由发起方调用 close ()，同时发送 FIN 包；接收端接收到 FIN 包返回 ACK 包，接收端发送 FIN 包；发起方接收到 FIN 包返回 ACK 包；完成断开。

（4）理解 TCP 的状态转换图。LISTEN 状态到 SYN_RCVD 状态和 SYN_SEND 状态，如何进入 ESTABLISHED 状态；四次挥手 FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT、CLOSING 直接的转换，CLOSE_WAIT 和 LAST_ACK 的处理等。

（5）理解 API 的底层原理，以及全连接队列和半连接队列。

（6）TCP 的分包场景以及 TCP 粘包的处理方式。

TCP 通信完整过程：


本节源自《网络通信的神奇之旅：解密 Linux TCP 网络协议栈的工作原理》，作者：Lion Long。