經典的」服務器最多65536個鏈接」誤解

無心間在一個牛人的技術博客上看到了這篇博客，也解了本身心中多年的謎(呵呵，雖說得有點誇張，可是我以爲這是好多java程序員須要瞭解透徹的知識)。

「由於TCP端口號是16位無符號整數, 最大65535, 因此一臺服務器最多支持65536個TCP socket鏈接.」 � 一個很是經典的誤解! 即便是有多年網絡編程經驗的人, 也會持有這個錯誤結論.

要戳破這個錯誤結論, 能夠從理論和實踐兩方面來.

理論

系統經過一個四元組來惟一標識一條TCP鏈接. 這個四元組的結構是{local ip, local port, remote ip, remote port}, 對於IPv4, 系統理論上最多能夠管理2^(32+16+32+16), 2的96次方個鏈接. 若是不單單考慮TCP, 則是一個五元組, 加上協議號(TCP, UDP或者其它).

實踐

服務器綁定一個ip:port, 而後accept鏈接, 全部accept的鏈接使用的本地地址也是一樣的ip:port.

擴展內容

若是某個客戶端向同一個TCP端點(ip:port)發起主動鏈接, 那麼每一條鏈接都必須使用不一樣的本地TCP端點, 若是客戶端只有一個IP則是使用不一樣的本地端口, 該端口的範圍在*nix系統上的一個例子是32768到61000, 能夠經過以下命令查看:

[root@benegg.com ~]# cat /proc/sys/net/ipv4/ip_local_port_range
32768   61000

也就是說, 一個客戶端鏈接同一個服務器的同一個ip:port(好比進行壓力測試), 最多能夠發起30000個左右的鏈接.

TCP客戶端(TCP的主動發起者)能夠在同一ip:port上向不一樣的服務器發起主動鏈接, 只需在bind以前對socket設置SO_REUSEADDR選項.

系統支持的最大打開文件描述符數(包括socket鏈接):

[root@benegg.com ~]# cat /proc/sys/fs/file-max
580382

單個進程所能打開的最大文件描述符數:

[root@benegg.com ~]# ulimit -n
1024

結論

不管是對於服務器仍是客戶端, 認爲」一臺機器最多創建65536個TCP鏈接」是沒有根據的, 理論上遠遠超過這個值.