由于TCP连接本质上可以理解为是client-server端的一对socket内核对象，那么从理论上将应该是【2^32 (ip数) * 2^16 (端口数)】条连接（约等于两百多万亿）
struct socket {
....
//INET域专用的一个socket表示, 提供了INET域专有的一些属性，比如 IP地址，端口等
struct sock *sk;
//TCP连接的状态：SYN_SENT、SYN_RECV、ESTABLISHED.....
short type;
....
};
struct inet_sock {
...
__u32 daddr; //IPv4的目标地址。
__u16 dport; //目标端口。
__u32 saddr; //源地址。
__u16 sport; //源端口。
...
};
这个 socket 对象也就是一个数据结构，里面包含了 TCP 四元组的信息：源IP、源端口、目标IP、目标端口。
如果只以ESTABLISH状态的连接来算（这些连接只是建立，但是不收发数据也不处理相关的业务逻辑）那么一台服务器最大能建立多少连接呢？
这种情况下，那么能建立的连接数量主要取决于【内存的大小】（因为如果是）ESTABLISH状态的空闲连接，不会消耗CPU（虽然有TCP保活包传输，但这个影响非常小，可以忽略不计）
我们知道一条ESTABLISH状态的连接大约消耗【3.3KB内存】，那么通过计算得知一台4GB内存的服务器，【可以建立100w+的TCP连接】（当然这里只是计算所有的连接都只建立连接但不发送和处理数据的情况，如果真实场景中有数据往来和处理（数据接收和发送都需要申请内存，数据处理便需要CPU），那便会消耗更高的内存以及占用更多的CPU，并发不可能达到100w+）
上面讨论的都是进建立连接的理想情况，在现实中如果有频繁的数据收发和处理（比如：压缩、加密等），那么一台服务器能支撑1000连接都算好的了，所以一台服务器能支撑多少连接还要结合具体的场景去分析，不能光靠理论值去算。抛开业务逻辑单纯的谈并发没有太大的实际意义。
服务器的开销大头往往并不是连接本身，而是每条连接上的数据收发，以及请求业务逻辑处理！！！
三次握手里socket的全连接队列长度由参数net.core.somaxconn来控制，默认大小是128，当两台机器离的非常近，但是建立连接的并发又非常高时，可能会导致半连接队列或全连接队列溢出，进而导致server端丢弃握手包。然后造成client超时重传握手包（至少1s以后才会重传），导致三次握手连接建立耗时过长。可以调整参数net.core.somaxconn来增加去按连接队列的长度，进而减小丢包的影响在Linux一切皆文件，当然也包括之前TCP连接中说的socket。进程打开一个socket的时候需要创建好几个内核对象，换一句直白的话说就是打开文件对象吃内存，所以Linux系统基于安全角度考虑（比如：有用户进程恶意的打开无数的文件描述符，那不得把系统搞奔溃了），在多个位置都限制了可打开的文件描述符的数量。
内核是通过【hash表】的方式来管理所有已经建立好连接的socket，以便于有请求到达时快速的通过【TCP四元组】查找到内核中对应的socket对象
在epoll模型中，通过红黑树来管理epoll对象所管理的所有socket，用红黑树结构来平衡快速删除、插入、查找socket的效率