Linux的TCP连接数量确实受到65535个端口号的限制，因为每个TCP连接都需要绑定一个本地IP地址和端口号。但是，在实际的服务器应用中，可以通过多种方式实现并发处理，例如：

1. 多线程/进程：使用多线程或多进程来并发处理请求，可以大大提高服务器的并发能力。

2. 异步编程模型：采用异步编程模型，如Reactor、Proactor等，可以在单线程中同时处理多个并发请求，并且避免了多线程带来的资源消耗和上下文切换的开销。

3. 负载均衡：采用负载均衡技术，将请求分散到多个处理节点上，以增加整体系统的吞吐量和并发处理能力。

4. 缓存技术：采用缓存技术，可以减少服务器的I/O操作，从而提高请求处理速度和并发性能。

5. 优化系统参数：针对具体的应用场景和硬件环境，适当调整系统参数，如TCP/IP协议栈参数、内核参数等，也可以提高服务器的并发处理能力。

总之，在实际的服务器应用中，可以通过多种方式来实现并发处理，避免单一TCP连接数的限制，从而满足不同规模和复杂度的应用需求。

这明显是进入了思维的误区，65535是指可用的端口总数，并不代表服务器同时只能接受65535个并发连接。

举个例子：

我们做了一个网站，绑定的是TCP的80端口，结果是所有访问这个网站的用户都是通过服务器的80端口访问，而不是其他端口。可见端口是可以复用的。即使Linux服务器只在80端口侦听服务， 也允许有10万、100万个用户连接服务器。Linux系统不会限制连接数至于服务器能不能承受住这么多的连接，取决于服务器的硬件配置、软件架构及优化。

01

我们知道两个进程如果需要进行通讯最基本的一个前提是：能够唯一的标示一个进程。在本地进程通讯中我们可以使用PID来唯一标示一个进程，但PID只在本地唯一，网络中的两个进程PID冲突几率很大。

这时候就需要另辟它径了，IP地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样可以利用IP地址＋协议＋端口号唯一标示网络中的一个进程。

能够唯一标示网络中的进程后，它们就可以利用socket进行通信了。socket（套接字）是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。socket源自Unix，是一种"打开—读/写—关闭"模式的实现，服务器和客户端各自维护一个"文件"，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

02

唯一能够确定一个连接有4个东西：

1. 服务器的IP

2. 服务器的Port

3. 客户端的IP

4. 客户端的Port

服务器的IP和Port可以保持不变，只要客户端的IP和Port彼此不同就可以确定一个连接数。一个socket是可以建立多个连接的，一个TCP连接的标记为一个四元组(source_ip, source_port, destination_ip, destination_port)，即(源IP，源端口，目的IP，目的端口)四个元素的组合。只要四个元素的组合中有一个元素不一样，那就可以区别不同的连接。

举个例子：

->你的主机IP地址是1.1.1.1， 在8080端口监听

->当一个来自 2.2.2.2 发来一条连接请求，端口为5555。这条连接的四元组为(1.1.1.1, 8080, 2.2.2.2, 5555)

->这时2.2.2.2又发来第二条连接请求，端口为6666。新连接的四元组为(1.1.1.1, 8080, 2.2.2.2, 6666)

那么，你主机的8080端口建立了两条连接；

->（2.2.2.2）发来的第三条连接请求,端口为5555(或6666)。第三条连接的请求就无法建立，因为没有办法区分于上面两条连接。

同理，可以在同一个端口号和IP地址上绑定一个TCP socket和一个UDP socket

因为端口号虽然一样，但由于协议不一样，所以端口是完全独立的。

TCP/UDP一般采用五元组来定位一个连接:

source_ip, source_port, destination_ip, destination_port， protocol_type

即（源IP，源端口，目的IP，目的端口，协议号）

综上所述，服务器的并发数并不是由TCP的65535个端口决定的。服务器同时能够承受的并发数是由带宽、硬件、程序设计等多方面因素决定的。

所以也就能理解淘宝、腾讯、头条、百度、新浪、哔哔哔哔等为什么能够承受住每秒种几亿次的并发访问，是因为他们采用的是服务器集群。服务器集群分布在全国各地的大型机房，当访问量小的时候会关闭一些服务器，当访问量大的时候回不断的开启新的服务器。

以上个人浅见，欢迎批评指正。

认同我的看法，请点个赞再走，感谢！

喜欢我的，请关注我，再次感谢！

Hi，你好。很高兴看到并回答此问题。如果我的回答对你有帮助，记得点个赞哦~~

下面我结合之前的项目来回答一下。

楼主所理解的65535（端口数量）与连接数是一个东西，这个是错的。具体原因前面已经有不少同行小伙伴描述的非常清楚了，我就不再阐述了。

下面我具体来回答一下楼主的后半部分：服务器是如何支撑百万并发的。

下面阐述的观点是：通过优化系统架构提升系统负载能力，即提高系统并发量。

一、什么是高并发

高并发是互联网系统所面临的普通问题，也是系统架构时考虑的重要因素之一。

【并发与负载】是相对的两个词。

想实现高并发，就要提高系统负载能力。系统负载能力强了，自然可以处理高并发请求。

所以，实现高并发，本质就是提高系统的负载能力。

一般对于系统负载能力的评估参数有：响应时间 、吞吐量、每秒请求数QPS、并发用户数。

• 响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。
• 吞吐量：单位时间内处理的请求数量。
• QPS：每秒响应请求数，与吞吐量概念类似。
• 并发用户数：同时使用系统功能的用户数量。

二、如何提高并发处理能力（并发数）

需要说明的是：以下内容不考虑【带宽】和【硬件配置】这两个因素。

很显然，带宽高、硬件配置高，系统负载能力就强，能处理的并发用户数就多。

那么如何提高并发处理能力呢？

答案就是：通过优化系统架构来提高并发处理能力。

并且系统架构设计是一个复杂的过程，不仅涉及到技术层面，还包括业务层面。

三、通过业务拆分提高并发处理能力（微服务架构）

将一个系统拆分为多个子系统，每个子系统负责一个单独的服务，这就是常说的【服务治理】

拆分为多个子系统后，每个子系统（服务）独立运行，每个服务之间通过REST/RPC方式调用，用户也可以直接调用这些服务接口。

这种设计将大化小，这种架构也称为【微服务架构】。

举例：商城系统中，可拆分为【订单服务】【用户服务】【产品服务】等多个服务接口。

四、通过水平扩展提高并发处理能力

这一块要分开来讲。

1. 前端部分

使用nginx反向代理软件提高并发处理量

nginx进行水平扩展：DNS轮询等

2. 应用服务器部分

java中常见的应用服务器tomcat为例，它可以实现集群和负载均衡。集群配置成功后，相当于提供了一个“服务器池”，如果想要再提高处理能力，只需要向“池”中继续添加应用服务器即可。另外，集群也实现了系统高可用。

3. 数据库层面

常见的分库分表，读写分离都是解决数据库压力大的方法之一。

数据库瓶颈是系统在运行中最先碰到、最常碰到的问题之一。

经常见到的问题就是磁盘IO高，导致处理缓慢。

刚才所说方法都可以解决这一问题。

常见的分表原则有：按范围分，按哈希值分。

4. 缓存层面

在系统中添加缓存是当前必选的方案。

添加缓存的主要目标是减少磁盘IO。

可以缓存的内容很多，例如缓存页面内容(HTML,CSS,图片)，缓存应用服务器中数据对象等。

通过设计多级缓存，实现数据的快速获取、请求的快速响应。

在分布式架构中，还要注意分布式缓存的更新一致性问题。（不再详述）

五、最后

其实很多系统的并发数都不到百万级，只有少量头部网站才会有，例如淘宝。

但我们之所以研究如何解决百万级并发架构，是从中学会和掌握【系统架构演变过程】。

系统架构设计的原则是：适合的就是最好的。不能刚开始架构就要满足百万级，因为这样设计会提高成本，造成资源浪费。

所以，我们要明白：系统架构是演进的。

只有当我们经历了从【单一架构】至【分布式架构】这一过程，才能真正理解架构的能力。在这过程中，你的架构能力也会飞快增长。

我是一名Java全栈开发工程师、系统架构师，从业15年。曾带领小团队完成多个数百万级项目。我正在写一些关于互联网行业及开发技术方面的文章。关注我，你一定会有所收获。

如果有项目开发、行业及求职方面的问题，都可以在评论区留言或私信我。（关注后私信我，向你免费分享行业级学习资料）

你好，IT行业的码农前来答题。

题主有一个概念上的误解，错误的把TCP端口号的上限65535理解成了TCP连接数的上限，进而认为Linux无法实现超过65,535个的并发任务，实际上端口号数量和TCP连接数确实有关联，但并非一一对应的关系。

65,535从哪来的，干啥的？

要解释好这个问题，就要先说清楚65,535的含义。在Linux系统中，如果两个机器要通信，那么相互之间需要建立TCP连接，为了让双方互相认识，Linux系统用一个四元组来唯一标识一个TCP连接： {local ip, local port, remote ip, remote port}，即本机IP、本机端口、远程IP、远程端口，IP和端口就相当于小区地址和门牌号，只有拿到这些信息，通信的双方才能互相认知。在Linux系统中，表示端口号（port）的变量占16位，这就决定了端口号最多有2的16次方个，即65,536个，另外端口0有特殊含义不给使用，这样每个服务器最多就有65,535个端口可用。因此，65,535代表Linux系统支持的TCP端口号数量，在TCP建立连接时会使用。

TCP怎么建立连接，与端口号是什么关系？

Linux服务器在交互时，一般有两种身份：客户端或者服务器端。典型的交互场景是：

（1）服务器端主动创建监听的socket，并绑定对外服务端口port，然后开始监听

（2）客户端想跟服务器端通信时，就开始连接服务器的端口port

（3）服务端接受客户端的请求，然后再生成新的socket

（4）服务器和客户端在新的socket里进行通信

可以看到，端口port主要用在服务器和客户端的“握手认识”过程，一旦互相认识了，就会生成的的socket进行通信，这时候port就不再需要了，可以给别的socket通信去使用，所以很明显TCP连接的数量可以大于TCP端口号的数量65,535。

考虑一下两个极端场景，即某台Linux服务器只作为客户端或者服务器端

（1）Linux服务器只作为客户端

这时候每发起一个TCP请求，系统就会指定一个空间的本地端口给你用，而且是独占式的，不会被别的TCP连接抢走，这样最多可以建立65535个连接，每个连接都与不同的服务器进行交互。这种场景，就是题主所描述的样子，但是由于条件过于苛刻，属于小概率事件，所以更多的还是理论上的可能，现实的环境中几乎不会出现。

（2）Linux服务器只作为服务端

这种场景下，服务端就会固定的监听本地端口port，等着客户端来向它发起请求。为了计算简单，我们假设服务器端的IP跟端口是多对一的，这样TCP四元组里面就有remote ip和remote port是可变的，因此最大支持创建TCP个数为2的32次方（IP地址是32位的）乘以2的16次方（port是16位的）等于2的48次方。

现实中单台Linux服务器支持的TCP连接数量

通过前面的分析我们知道，在现实场景中，由于存在端口port复用的情况，服务器可同时支持的TCP连接数跟65,535没有一一对应关系，事实上，真正影响TCP连接数量的，是服务器的内存以及允许单一进程同时打开文件的数量，因为每创建一个TCP连接都要创建一个socket句柄，每个socket句柄都占用一部分系统内存，当系统内存被占用殆尽，允许的TCP并发连接数也就到了上限。一般来讲，通过增加服务器内存、修改最大文件描述符个数等，可以做到单台服务器支持10万+的TCP并发。

当然，在真实的商用场景下，单台服务器都会编入分布式集群，通过负载均衡算法动态的调度不同用户的请求给最空闲的服务器，如果服务器平均内存使用超过80%的警戒线，那么就会及时采用限流或者扩展集群的方式来保证服务，绝对不会出现服务器的内存被耗尽的情况，那样就算事故了。

总之，65,535只是Linux系统中可使用端口port数量的上限，端口port数量与TCP连接数量并非完全一一对应的关系，服务器支持的TCP并发连接数量主要跟服务器的内存以及允许单个进程同时打开的文件数量有关系，通过端口复用及调整服务器参数等手段，单台服务器支持的TCP并发连接数是可以高于65,535的。

TCP/IP 协议规定了端口数占两个字节，所以 65535 是端口数的上限，但是和连接数不是一个意思。

一个 TCP 连接（会话）用四元组来标识:

客户端IP : 源端口 -＞ 服务器 IP : 目的端口

TCP 连接大概有这么几种场景:

1，服务端需要监听特定的端口（socket listen），比如 WEB 需要监听 80 和 8080 端口，监听的端口是独占的，也就是说同一 IP 的端口绑定数量上限是 65535;

2，客户端连接服务器，系统会自动分配本地空闲端口，本地端口也是独占的，所以传出连接数（Outgoing）上限是 65535;

3，当服务端收到传入的连接请求（socket accept）并建立连接，对于服务端而言，传入连接并不会产生新的端口占用，连接数量不受端口限制，而是操作系统和系统资源限制。