在使用 TCP/IP 協議時，會遇到一個經典的問題：TCP 連接數量最大不能超過 65535。這是因為 TCP 協議頭中的端口號是 16 位的，因此最大只能表示 65535 個端口號。那么，服務器又是如何應對百萬千萬的并發連接的呢？
linux TCP 連接數量最大不能超過 65535
在理解如何處理大量并發連接之前，我們需要了解為什么 TCP 連接數量最大不能超過 65535。在 TCP 協議中，每個連接都需要一個唯一的端口號和 IP 地址來標識。由于 TCP 協議頭中的端口號只有 16 位，因此本地端口個數最大只有65536，端口0有特殊含義，不能使用，因此最多只能表示 65535 個端口號。因此，TCP 連接數量也被限制在 65535 個。
需要注意的是，這個限制是針對每個 IP 地址的。也就是說，每個 IP 地址最多只能有 65535 個 TCP 連接。如果有多個 IP 地址，則可以建立更多的連接。這也是為什么現代服務器通常都會有多個網卡和 IP 地址的原因之一。
服務器如何應對大量并發連接
現代服務器需要應對大量的并發連接，而這個限制看似會成為服務器的瓶頸。那么，服務器又是如何應對大量并發連接的呢？以下是一些常用的技術：
多線程/多進程模型
多線程/多進程模型是最基本的處理并發連接的方法之一。在這種模型中，每個連接都由一個單獨的線程/進程處理。當有新連接時，服務器會創建一個新的線程/進程來處理它。這種方法的好處是簡單易懂，容易實現，但是會占用大量的系統資源，特別是當并發連接數非常高時，會導致系統崩潰。
事件驅動模型
事件驅動模型是一種更高效的處理并發連接的方法。在這種模型中，服務器將所有連接都加入到一個事件循環中。當有新的事件發生時，比如有新連接到來或有數據可讀可寫時，事件循環會通知相應的處理函數來處理這些事件。這種方法的好處是能夠處理大量的并發連接，而且占用系統資源較少。目前，最常見的事件驅動模型是 epoll。
協程/異步IO
協程協程/異步IO 是最新的處理并發連接的方法之一。在這種方法中，服務器使用協程或異步IO來處理連接。協程是一種輕量級的線程，它可以在不同的連接之間切換執行。在協程中，當有連接需要處理時，協程會切換到相應的處理函數中，處理完成后再切換回來繼續執行。異步IO 則是一種非阻塞的IO 模型，它能夠在不等待 IO 操作完成的情況下繼續執行其他任務。這種方法的好處是能夠處理大量的并發連接，同時占用的系統資源較少。
負載均衡
另一種處理并發連接的方法是負載均衡。在負載均衡中，服務器使用多臺物理或虛擬服務器來處理大量的并發連接。當有新連接到來時，負載均衡服務器會根據一定的策略將連接轉發給后端的物理或虛擬服務器處理。這種方法的好處是能夠平衡服務器的負載，避免單臺服務器過載導致系統崩潰。
