到底一台服务器上最多能创建多少个 TCP 连接 | plantegg

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [plantegg.github.io](https://plantegg.github.io/2020/11/30/%E4%B8%80%E5%8F%B0%E6%9C%BA%E5%99%A8%E4%B8%8A%E6%9C%80%E5%A4%9A%E8%83%BD%E5%88%9B%E5%BB%BA%E5%A4%9A%E5%B0%91%E4%B8%AATCP%E8%BF%9E%E6%8E%A5/)

经常听到有同学说一台机器最多能创建 65535 个 TCP 连接，这其实是错误的理解，为什么会有这个错误的理解呢？

[](#port-range "port range")port range
--------------------------------------

我们都知道 linux 下本地随机端口范围由参数控制，也就是 listen、connect 时候如果没有指定本地端口，那么就从下面的 port range 中随机取一个可用的

```
# cat /proc/sys/net/ipv4/ip_local_port_range

2000	65535
```

port range 的上限是 65535，所以也经常看到这个**误解**：一台机器上最多能创建 65535 个 TCP 连接

[](#到底一台机器上最多能创建多少个TCP连接 "到底一台机器上最多能创建多少个TCP连接")到底一台机器上最多能创建多少个 TCP 连接
----------------------------------------------------------------------

先说**结论**：在内存、文件句柄足够的话可以创建的连接是**没有限制**的（每个 TCP 连接至少要消耗一个文件句柄）。

那么 / proc/sys/net/ipv4/ip_local_port_range 指定的端口范围到底是什么意思呢？

核心规则：**一个 TCP 连接只要保证四元组 (src-ip src-port dest-ip dest-port) 唯一就可以了，而不是要求 src port 唯一**

后面所讲都遵循这个规则，所以在心里反复默念：**四元组唯一** 五个大字，就能分析出来到底能创建多少 TCP 连接了。

比如如下这个机器上的 TCP 连接实际状态：

```
# netstat -ant |grep 18089

tcp        0      0 192.168.1.79:18089      192.168.1.79:22         ESTABLISHED

tcp        0      0 192.168.1.79:18089      192.168.1.79:18080      ESTABLISHED

tcp        0      0 192.168.0.79:18089      192.168.0.79:22         TIME_WAIT

tcp        0      0 192.168.1.79:22         192.168.1.79:18089      ESTABLISHED

tcp        0      0 192.168.1.79:18080      192.168.1.79:18089      ESTABLISHED
```

从前三行可以清楚地看到 18089 被用了三次，第一第二行 src-ip、dest-ip 也是重复的，但是 dest port 不一样，第三行的 src-port 还是 18089，但是 src-ip 变了。他们的四元组均不相同。

所以一台机器能创建的 TCP 连接是没有限制的，而 ip_local_port_range 是指没有 bind 的时候 OS 随机分配端口的范围，但是分配到的端口要同时满足五元组唯一，这样 ip_local_port_range 限制的是连同一个目标（dest-ip 和 dest-port 一样）的 port 的数量（请忽略本地多网卡的情况，因为 dest-ip 为以后 route 只会选用一个本地 ip）。

**那么为什么大家有这样的误解呢？**我总结了下，大概是以下两个原因让大家误解了：

*   如果是 listen 服务，那么肯定端口不能重复使用，这样就跟我们的误解对应上了，一个服务器上最多能监听 65535 个端口。比如 nginx 监听了 80 端口，那么 tomcat 就没法再监听 80 端口了，这里的 80 端口只能监听一次（如果有个连接用了 80 连别人，这里 80 还是不能被 listen…… 想想）。
*   另外如果我们要连的 server 只有一个，比如：1.1.1.1:80 ，同时本机只有一个 ip 的话，那么这个时候即使直接调 connect 也只能创建出 65535 个连接，因为四元组中的三个是固定的了。

我们在创建连接前，经常会先调 bind，bind 后可以调 listen 当做服务端监听，也可以直接调 connect 当做 client 来连服务端。

bind(ip,port=0) 的时候是让系统绑定到某个网卡和自动分配的端口，此时系统没有办法确定接下来这个 socket 是要去 connect 还是 listen. 如果是 listen 的话，那么肯定是不能出现端口冲突的，如果是 connect 的话，只要满足 4 元组唯一即可。在这种情况下，系统只能尽可能满足更强的要求，就是先要求端口不能冲突，即使之后去 connect 的时候四元组是唯一的。

但如果我只是个 client 端，只需要连接 server 建立连接，也就不需要 bind，直接调 connect 就可以了，这个时候只要保证四元组唯一就行。

bind() 的时候内核是还不知道四元组的，只知道 src_ip、src_port，所以这个时候单网卡下 src_port 是没法重复的，但是 connect() 的时候已经知道了四元组的全部信息，所以只要保证四元组唯一就可以了，那么这里的 src_port 完全是可以重复使用的。

![](https://plantegg.github.io/images/951413iMgBlog/640-20220224103024676.png)

**是不是加上了 SO_REUSEADDR、SO_REUSEPORT 就能重用端口了呢？**

[](#TCP-SO-REUSEADDR "TCP SO_REUSEADDR")TCP SO_REUSEADDR
--------------------------------------------------------

文档描述：

SO_REUSEADDR Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address. When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address. Argument is an integer boolean flag.

从这段文档中我们可以知道三个事：

1.  使用这个参数后，bind 操作是可以重复使用 local address 的，注意，这里说的是 local address，即 ip 加端口组成的本地地址，也就是两个本地地址，如果有任意 ip 或端口部分不一样，它们本身就是可以共存的，不需要使用这个参数。
2.  当 local address 被一个处于 listen 状态的 socket 使用时，加上该参数也不能重用这个地址。
3.  当处于 listen 状态的 socket 监听的本地地址的 ip 部分是 INADDR_ANY，即表示监听本地的所有 ip，即使使用这个参数，也不能再 bind 包含这个端口的任意本地地址，这个和 2 中描述的其实是一样的。

==SO_REUSEADDR 可以用本地相同的 (sip, sport) 去连 connect 远程的不同的（dip、dport）// 而 SO_REUSEPORT 主要是解决 Server 端的 port 重用 ==

[SO_REUSEADDR 还可以重用 TIME_WAIT 状态的 port](https://mp.weixin.qq.com/s/YWzuKBK3TMclejeN2ziAvQ), 在程序崩溃后之前的 TCP 连接会进入到 TIME_WAIT 状态，需要一段时间才能释放，如果立即重启就会抛出 Address Already in use 的错误导致启动失败。这时候可以通过在调用 bind 函数之前设置 SO_REUSEADDR 来解决。

What exactly does SO_REUSEADDR do?

This socket option tells the kernel that even if this port is busy (in the TIME_WAIT state), go ahead and reuse it anyway. If it is busy, but with another state, you will still get an address already in use error. It is useful if your server has been shut down, and then restarted right away while sockets are still active on its port. You should be aware that if any unexpected data comes in, it may confuse your server, but while this is possible, it is not likely.

It has been pointed out that “A socket is a 5 tuple (proto, local addr, local port, remote addr, remote port). SO_REUSEADDR just says that you can reuse local addresses. The 5 tuple still must be unique!” This is true, and this is why it is very unlikely that unexpected data will ever be seen by your server. The danger is that such a 5 tuple is still floating around on the net, and while it is bouncing around, a new connection from the same client, on the same system, happens to get the same remote port.

By setting `SO_REUSEADDR` user informs the kernel of an intention to share the bound port with anyone else, but only if it doesn’t cause a conflict on the protocol layer. There are at least three situations when this flag is useful:

1.  Normally after binding to a port and stopping a server it’s neccesary to wait for a socket to time out before another server can bind to the same port. With `SO_REUSEADDR` set it’s possible to rebind immediately, even if the socket is in a `TIME_WAIT` state.
2.  When one server binds to `INADDR_ANY`, say `0.0.0.0:1234`, it’s impossible to have another server binding to a specific address like `192.168.1.21:1234`. With `SO_REUSEADDR` flag this behaviour is allowed.
3.  When using the bind before connect trick only a single connection can use a single outgoing source port. With this flag, it’s possible for many connections to reuse the same source port, given that they connect to different destination addresses.

[](#TCP-SO-REUSEPORT "TCP SO_REUSEPORT")TCP SO_REUSEPORT
--------------------------------------------------------

SO_REUSEPORT 主要用来解决惊群、性能等问题。通过多个进程、线程来监听同一端口，进来的连接通过内核来 hash 分发做到负载均衡，避免惊群。

SO_REUSEPORT is also useful for eliminating the try-10-times-to-bind hack in ftpd’s data connection setup routine. Without SO_REUSEPORT, only one ftpd thread can bind to TCP (lhost, lport, INADDR_ANY, 0) in preparation for connecting back to the client. Under conditions of heavy load, there are more threads colliding here than the try-10-times hack can accomodate. With SO_REUSEPORT, things work nicely and the hack becomes unnecessary.

SO_REUSEPORT 使用场景：linux kernel 3.9 引入了最新的 SO_REUSEPORT 选项，使得多进程或者多线程创建多个绑定同一个 ip:port 的监听 socket，提高服务器的接收链接的并发能力, 程序的扩展性更好；此时需要设置 SO_REUSEPORT（**注意所有进程都要设置才生效**）。

setsockopt(listenfd, SOL_SOCKET, SO_REUSEPORT,(const void *)&reuse , sizeof(int));

目的：每一个进程有一个独立的监听 socket，并且 bind 相同的 ip:port，独立的 listen() 和 accept()；提高接收连接的能力。（例如 nginx 多进程同时监听同一个 ip:port）

(a) on Linux SO_REUSEPORT is meant to be used _purely_ for load balancing multiple incoming UDP packets or incoming TCP connection requests across multiple sockets belonging to the same app. ie. it’s a work around for machines with a lot of cpus, handling heavy load, where a single listening socket becomes a bottleneck because of cross-thread contention on the in-kernel socket lock (and state).

(b) set IP_BIND_ADDRESS_NO_PORT socket option for tcp sockets before binding to a specific source ip  
with port 0 if you’re going to use the socket for connect() rather then listen() this allows the kernel  
to delay allocating the source port until connect() time at which point it is much cheaper

[](#The-Ephemeral-Port-Range "The Ephemeral Port Range")[The Ephemeral Port Range](http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html)
---------------------------------------------------------------------------------------------------------------------------------------------

Ephemeral Port Range 就是我们前面所说的 Port Range（/proc/sys/net/ipv4/ip_local_port_range）

A TCP/IPv4 connection consists of two endpoints, and each endpoint consists of an IP address and a port number. Therefore, when a client user connects to a server computer, an established connection can be thought of as the 4-tuple of (server IP, server port, client IP, client port).

Usually three of the four are readily known – client machine uses its own IP address and when connecting to a remote service, the server machine’s IP address and service port number are required.

What is not immediately evident is that when a connection is established that the client side of the connection uses a port number. Unless a client program explicitly requests a specific port number, the port number used is an ephemeral port number.

Ephemeral ports are temporary ports assigned by a machine’s IP stack, and are assigned from a designated range of ports for this purpose. When the connection terminates, the ephemeral port is available for reuse, although most IP stacks won’t reuse that port number until the entire pool of ephemeral ports have been used.

So, if the client program reconnects, it will be assigned a different ephemeral port number for its side of the new connection.

[](#linux-如何选择Ephemeral-Port "linux 如何选择Ephemeral Port")linux 如何选择 Ephemeral Port
---------------------------------------------------------------------------------

有资料说是随机从 Port Range 选择 port，有的说是顺序选择，那么实际验证一下。

如下测试代码：

```
#include <stdio.h>      // printf

#include <stdlib.h>     // atoi

#include <unistd.h>     // close

#include <arpa/inet.h>  // ntohs

#include <sys/socket.h> // connect, socket

void sample() {

// Create socket

int sockfd;

if (sockfd = socket(AF_INET, SOCK_STREAM, 0), -1 == sockfd) {

perror("socket");

}

// Connect to remote. This does NOT actually send a packet.

const struct sockaddr_in raddr = {

.sin_family = AF_INET,

.sin_port   = htons(8080),     // arbitrary remote port

.sin_addr   = htonl(INADDR_ANY)  // arbitrary remote host

};

if (-1 == connect(sockfd, (const struct sockaddr *)&raddr, sizeof(raddr))) {

perror("connect");

}

// Display selected ephemeral port

const struct sockaddr_in laddr;

socklen_t laddr_len = sizeof(laddr);

if (-1 == getsockname(sockfd, (struct sockaddr *)&laddr, &laddr_len)) {

perror("getsockname");

}

printf("local port: %i\n", ntohs(laddr.sin_port));

// Close socket

close(sockfd);

}

int main() {

for (int i = 0; i < 5; i++) {

sample();

}

return 0;

}
```

bind 逻辑测试代码

```
#include <netinet/in.h>

#include <arpa/inet.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <errno.h>

#include <string.h>

#include <sys/types.h>

#include <time.h>

void test_bind(){

int listenfd = 0, connfd = 0;

struct sockaddr_in serv_addr;

char sendBuff[1025];

time_t ticks;

socklen_t len;

listenfd = socket(AF_INET, SOCK_STREAM, 0);

memset(&serv_addr, '0', sizeof(serv_addr));

memset(sendBuff, '0', sizeof(sendBuff));

serv_addr.sin_family = AF_INET;

serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);

serv_addr.sin_port = htons(0);

bind(listenfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr));

len = sizeof(serv_addr);

if (getsockname(listenfd, (struct sockaddr *)&serv_addr, &len) == -1) {

perror("getsockname");

return;

}

printf("port number %d\n", ntohs(serv_addr.sin_port)); //只是挑选到了port，在系统层面保留，tcp连接还没有，netstat是看不到的

}

int main(int argc, char *argv[]) {

for (int i = 0; i < 5; i++) {

test_bind();

}

return 0;

}
```

### [](#3-10-0-327-ali2017-alios7-x86-64 "3.10.0-327.ali2017.alios7.x86_64")3.10.0-327.ali2017.alios7.x86_64

编译后，执行 (3.10.0-327.ali2017.alios7.x86_64)：

```
#date; ./client && echo "+++++++" ; ./client && sleep 0.1 ; echo "-------" && ./client && sleep 10; date; ./client && echo "+++++++" ; ./client && sleep 0.1 && echo "******"; ./client;

Fri Nov 27 10:52:52 CST 2020

local port: 17448

local port: 17449

local port: 17451

local port: 17452

local port: 17453

+++++++

local port: 17455

local port: 17456

local port: 17457

local port: 17458

local port: 17460

-------

local port: 17475

local port: 17476

local port: 17477

local port: 17478

local port: 17479

Fri Nov 27 10:53:02 CST 2020

local port: 17997

local port: 17998

local port: 17999

local port: 18000

local port: 18001

+++++++

local port: 18002

local port: 18003

local port: 18004

local port: 18005

local port: 18006

******

local port: 18010

local port: 18011

local port: 18012

local port: 18013

local port: 18014
```

从测试看起来 linux 下端口选择跟时间有关系，起始端口肯定是顺序增加，起始端口应该是在 Ephemeral Port 范围内并且和时间戳绑定的某个值（也是递增的），即使没有使用任何端口，起始端口也会随时间增加而增加。

### [](#4-19-91-19-1-al7-x86-64 "4.19.91-19.1.al7.x86_64")4.19.91-19.1.al7.x86_64

换个内核版本编译后，执行 (4.19.91-19.1.al7.x86_64)：

```
$date; ./client && echo "+++++++" ; ./client && sleep 0.1 ; echo "-------" && ./client && sleep 10; date; ./client && echo "+++++++" ; ./client && sleep 0.1 && echo "******"; ./client;

Fri Nov 27 14:10:47 CST 2020

local port: 7890

local port: 7892

local port: 7894

local port: 7896

local port: 7898

+++++++

local port: 7900

local port: 7902

local port: 7904

local port: 7906

local port: 7908

-------

local port: 7910

local port: 7912

local port: 7914

local port: 7916

local port: 7918

Fri Nov 27 14:10:57 CST 2020

local port: 7966

local port: 7968

local port: 7970

local port: 7972

local port: 7974

+++++++

local port: 7976

local port: 7978

local port: 7980

local port: 7982

local port: 7984

******

local port: 7988

local port: 7990

local port: 7992

local port: 7994

local port: 7996
```

以上测试时的参数

```
$cat /proc/sys/net/ipv4/ip_local_port_range

1024    65535
```

将 1024 改成 1025 后，分配出来的都是奇数端口了：

```
$cat /proc/sys/net/ipv4/ip_local_port_range

1025    1034

$./client

local port: 1033

local port: 1025

local port: 1027

local port: 1029

local port: 1031

local port: 1033

local port: 1025

local port: 1027

local port: 1029

local port: 1031

local port: 1033

local port: 1025

local port: 1027

local port: 1029

local port: 1031
```

之所以都是偶数端口，是因为 port_range 从偶数开始, 每次从 ++ 变到 + 2 的[原因](https://github.com/plantegg/linux/commit/1580ab63fc9a03593072cc5656167a75c4f1d173)，connect 挑选随机端口时都是在起始端口的基础上 + 2，而 bind 挑选随机端口的起始端口是系统 port_range 起始端口 + 1（这样和 connect 错开），然后每次仍然尝试 + 2，这样 connect 和 bind 基本一个用偶数另外一个就用奇数，一旦不够了再尝试使用另外一组

```
$cat /proc/sys/net/ipv4/ip_local_port_range

1024    1047

$./bind &  ---bind程序随机挑选5个端口

port number 1039

port number 1043

port number 1045

port number 1041

port number 1047  --用完所有奇数端口

$./bind &    --继续挑选偶数端口

[8] 4170

port number 1044

port number 1042

port number 1046

port number 0    --实在没有了

port number 0
```

可见 4.19 内核下每次 port 是 + 2，在 3.10 内核版本中是 + 1. 并且都是递增的，同时即使 port 不使用，也会随着时间的变化这个起始 port 增大。

Port Range 有点像雷达转盘数字，时间就像是雷达上的扫描指针，这个指针不停地旋转，如果这个时候刚好有应用要申请 Port，那么就从指针正好指向的 Port 开始向后搜索可用 port

[](#tcp-max-tw-buckets "tcp_max_tw_buckets")tcp_max_tw_buckets
--------------------------------------------------------------

tcp_max_tw_buckets: 在 TIME_WAIT 数量等于 tcp_max_tw_buckets 时，新的连接断开不再进入 TIME_WAIT 阶段，而是直接断开，并打印 warnning.

实际测试发现 在 TIME_WAIT 数量等于 tcp_max_tw_buckets 时 新的连接仍然可以不断地创建和断开，这个参数大小不会影响性能，只是影响 TIME_WAIT 数量的展示（当然 TIME_WAIT 太多导致 local port 不够除外）, 这个值设置小一点会避免出现端口不够的情况

tcp_max_tw_buckets - INTEGER  
Maximal number of timewait sockets held by system simultaneously.If this number is exceeded time-wait socket is immediately destroyed and warning is printed. This limit exists only to prevent simple DoS attacks, you _must_ not lower the limit artificially, but rather increase it (probably, after increasing installed memory), if network conditions require more than default value.

[](#SO-LINGER "SO_LINGER")[SO_LINGER](https://notes.shichao.io/unp/ch7/)
------------------------------------------------------------------------

SO_LINGER 选项**用来设置延迟关闭的时间，等待套接字发送缓冲区中的数据发送完成**。 没有设置该选项时，在调用 close() 后，在发送完 FIN 后会立即进行一些清理工作并返回。 如果设置了 SO_LINGER 选项，并且等待时间为正值，则在清理之前会等待一段时间。

如果把延时设置为 0 时，Socket 就丢弃数据，并向对方发送一个 `RST` 来终止连接，因为走的是 RST 包，所以就不会有 `TIME_WAIT` 了。

This option specifies how the `close` function operates for a connection-oriented protocol (for TCP, but not for UDP). By default, `close` returns immediately, but ==if there is any data still remaining in the socket send buffer, the system will try to deliver the data to the peer==.

SO_LINGER 有三种情况

1.  l_onoff 为 false（0）， 那么 l_linger 的值没有意义，socket 主动调用 close 时会立即返回，操作系统会将残留在缓冲区中的数据发送到对端，并按照正常流程关闭 (交换 FIN-ACK），最后连接进入`TIME_WAIT`状态。**这是默认情况**
2.  l_onoff 为 true（非 0）， l_linger 为 0，主动调用 close 的一方也是立刻返回，但是这时 TCP 会丢弃发送缓冲中的数据，而且不是按照正常流程关闭连接（不发送 FIN 包），直接发送`RST`，连接不会进入 time_wait 状态，对端会收到 `java.net.SocketException: Connection reset`异常
3.  l_onoff 为 true（非 0）， l_linger 也为非 0，这表示 `SO_LINGER`选项生效，并且超时时间大于零，这时调用 close 的线程被阻塞，TCP 会发送缓冲区中的残留数据，这时有两种可能的情况：
    *   数据发送完毕，收到对方的 ACK，然后进行连接的正常关闭（交换 FIN-ACK）
    *   超时，未发送完成的数据被丢弃，连接发送`RST`进行非正常关闭

```
struct linger {

int   l_onoff;        /* 0=off, nonzero=on */

int   l_linger;       /* linger time, POSIX specifies units as seconds */

};
```

### [](#NIO下设置-SO-LINGER-的错误案例 "NIO下设置 SO_LINGER 的错误案例")NIO 下设置 SO_LINGER 的错误案例

在使用 NIO 时，最好不设置`SO_LINGER`。比如 Tomcat 服务端接收到请求创建新连接时，做了这样的设置：

```
SocketChannel.setOption(SocketOption.SO_LINGER, 1000)
```

`SO_LINGER`的单位为`秒`！在网络环境比较好的时候，例如客户端、服务器都部署在同一个机房，close 虽然会被阻塞，但时间极短可以忽略。但当网络环境不那么好时，例如存在丢包、较长的网络延迟，buffer 中的数据一直无法发送成功，那么问题就出现了：`close会被阻塞较长的时间，从而直接或间接引起NIO的IO线程被阻塞`，服务器会不响应，不能处理 accept、read、write 等任何 IO 事件。也就是应用频繁出现挂起现象。解决方法就是删掉这个设置，close 时立即返回，由操作系统接手后面的工作。

这时会看到如下连接状态

![](https://plantegg.github.io/images/951413iMgBlog/image-20220721100246598.png)

以及对应的堆栈

![](https://plantegg.github.io/images/951413iMgBlog/image-20220721100421130.png)

查看其中一个 IO 线程等待的锁，发现锁是被 HTTP 线程持有。这个线程正在执行`preClose0`，就是在这里等待连接的关闭

![](https://plantegg.github.io/images/951413iMgBlog/image-20220721100446521.png)

每次 HTTP 线程在关闭连接被阻塞时，同时持有了`SocketChannelImpl`的对象锁，而 IO 线程在把这个连接移除出它的 selector 管理队列时，也要获得同一个`SocketChannelImpl`的对象锁。IO 线程就这么一次次的被阻塞，悲剧的无以复加。有些 NIO 框架会让 IO 线程去做 close，这时候就更加悲剧了。

**总之这里的错误原因有两点：1）网络状态不好；2）错误理解了 l_linger 的单位，是秒，不是毫秒。 在这两个原因的共同作用下导致了数据迟迟不能发送完毕，l_linger 超时又需要很久，所以服务会出现一直阻塞的状态。**

[](#为什么要有-time-wait-状态 "为什么要有 time_wait 状态")为什么要有 time_wait 状态
--------------------------------------------------------------

TIME-WAIT - represents waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.

![](https://plantegg.github.io/images/951413iMgBlog/image-20220721093116395.png)

[](#短连接的开销 "短连接的开销")短连接的开销
--------------------------

用 ab 通过短连接走 lo 网卡压本机 nginx，CPU0 是 ab 进程，CPU3/4 是 Nginx 服务，可以看到 si 非常高，QPS 2.2 万

![](https://plantegg.github.io/images/951413iMgBlog/image-20220627154822263.png)

再将 ab 改用长连接来压，可以看到 si、sy 都有下降，并且 si 下降到短连接的 20%，QPS 还能提升到 5.2 万

![](https://plantegg.github.io/images/951413iMgBlog/image-20220627154931495.png)

[](#一条连接的开销 "一条连接的开销")[一条连接的开销](https://mp.weixin.qq.com/s/BwddYkVLSYlkKFNeA-NUVg)
----------------------------------------------------------------------------------

主要是内存开销 (如图，来源见水印)，另外就是每个连接都会占用一个文件句柄，可以通过参数来设置：fs.nr_open、nofile（其实 nofile 还分 soft 和 hard） 和 fs.file-max

![](https://plantegg.github.io/images/951413iMgBlog/640-20220413134252639)

从上图可以看到：

*   没有收发数据的时候收发 buffer 不用提前分配，3K 多点的内存是指一个连接的元信息数据空间，不包含传输数据的内存 buffer
    
*   客户端发送数据后，会根据数据大小分配 send buffer（一般不超过 wmem，默认 kernel 会根据系统内存压力来调整 send buffer 大小)
    
*   server 端 kernel 收到数据后存放在 rmem 中，应用读走后就会释放对应的 rmem
    
*   rmem 和 wmem 都不会重用，用时分配用完释放

可见，内核在 socket 内存开销优化上采取了不少方法:

*   内核会尽量及时回收发送缓存区、接收缓存区，但高版本做的更好
*   发送接收缓存区最小并一定不是 rmem 内核参数里的最小值，实际大部分时间都是 0
*   其它状态下，例如对于 TIME_WAIT 还会回收非必要的 socket_alloc 等对象

[](#可用-local-port-不够导致对端time-wait-连接重用进而卡顿案例 "可用 local port 不够导致对端time_wait 连接重用进而卡顿案例")[可用 local port 不够导致对端 time_wait 连接重用进而卡顿案例](https://ata.alibaba-inc.com/articles/251853)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A 进程选择某个端口，并设置了 reuseaddr opt（表示其它进程还能继续用这个端口），这时 B 进程选了这个端口，并且 bind 了，如果 A 进程一直不释放这个端口对应的连接，那么这个端口会一直在内核中记录被 bind 用掉了（能 bind 的端口 是 65535 个，四元组不重复的连接你理解可以无限多），这样的端口越来越多后，剩下可供 A 进程发起连接的本地随机端口就越来越少了，这时会造成新建连接的时候这个四元组高概率重复，一般这个时候对端大概率还在 time_wait 状态，会忽略掉握手 syn 包并回复 ack ，进而造成建连接卡顿的现象

[](#结论 "结论")结论
--------------

*   在内存、文件句柄足够的话一台服务器上可以创建的 TCP 连接数量是没有限制的
*   SO_REUSEADDR 主要用于快速重用 TIME_WAIT 状态的 TCP 端口，避免服务重启就会抛出 Address Already in use 的错误
*   SO_REUSEPORT 主要用来解决惊群、性能等问题
*   全局范围可以用 net.ipv4.tcp_max_tw_buckets = 50000 来限制总 time_wait 数量，但是会掩盖问题
*   local port 的选择是递增搜索的，搜索起始 port 随时间增加也变大

[](#参考资料 "参考资料")参考资料
--------------------

[https://segmentfault.com/a/1190000002396411](https://segmentfault.com/a/1190000002396411)

[linux 中 TCP 的 socket、bind、listen、connect 和 accept 的实现](https://blog.csdn.net/a364572/article/details/40628171)

[How Linux allows TCP introspection The inner workings of bind and listen on Linux.](https://ops.tips/blog/how-linux-tcp-introspection/)

[https://idea.popcount.org/2014-04-03-bind-before-connect/](https://idea.popcount.org/2014-04-03-bind-before-connect/)

[TCP 连接中客户端的端口号是如何确定的？](https://mp.weixin.qq.com/s/C-Eeoeh9GHxugF4J30fz1A)

[对应 4.19 内核代码解析](https://github.com/plantegg/linux/commit/9b3312bf18f6873e67f1f51dab3364c95c9dc54c)

[How to stop running out of ephemeral ports and start to love long-lived connections](https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/)