关于 TCP 并发连接的几个思考题与试验

陈硕 (giantchen AT gmail)

blog.csdn.net/Solstice

前几天我在新浪微博上出了两道有关 TCP 的思考题，引发了一场讨论 http://weibo.com/1701018393/eCuxDrta0Nn 。

第一道初级题目是：

有一台机器，它有一个 IP，上面运行了一个 TCP 服务程序，程序只侦听一个端口，问：从理论上讲（只考虑 TCP/IP 这一层面，不考虑IPv6）这个服务程序可以支持多少并发 TCP 连接？答 65536 上下的直接刷掉。

具体来说，这个问题等价于：有一个 TCP 服务程序的地址是 1.2.3.4:8765，问它从理论上能接受多少个并发连接？

第二道进阶题目是：

一台被测机器 A，功能同上，同一交换机上还接有一台机器 B，如果允许 B 的程序直接收发以太网 frame，问：让 A 承担 10 万个并发 TCP 连接需要用多少 B 的资源？100万个呢？

从讨论的结果看，很多人做出了第一道题，而第二道题几乎无人问津。

 

这里先不公布答案（第一题答案见文末），让我们继续思考一个本质的问题：一个 TCP 连接要占用多少系统资源。

在现在的 Linux 操作系统上，如果用 socket()/connect() 或 accept() 来创建 TCP 连接，那么每个连接至少要占用一个文件描述符(file descriptor)。为什么说“至少”？因为文件描述符可以复制，比如 dup()；也可以被继承，比如 fork()；这样可能出现系统里边同一个 TCP 连接有多个文件描述符与之对应。据此，很多人给出的第一题答案是：并发连接数受限于系统能同时打开的文件数目的最大值。这个答案在实践中是正确的，却不符合原题意。

 

如果抛开操作系统层面，只考虑 TCP/IP 层面，建立一个 TCP 连接有哪些开销？理论上最小的开销是多少？考虑两个场景：

1. 假设有一个 TCP 服务程序，向这个程序成功发起连接需要做哪些事情？换句话说，如何才能让这个 TCP 服务程序认为有客户连接到了它（让它的 accept() 调用正常返回）？

2. 假设有一个 TCP 客户端程序，让这个程序成功建立到服务器的连接需要做哪些事情？换句话说，如何才能让这个 TCP 客户端程序认为它自己已经连接到服务器了（让它的 connect() 调用正常返回）？

以上这两个问题问的不是如何编程，如何调用 Sockets API，而是问如何让操作系统的 TCP/IP 协议栈认为任务已经成功完成，连接已经成功建立。

 

学过 TCP/IP