陈硕 (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 协议，理解三路握手的同学明白，TCP 连接是虚拟的连接，不是电路连接，维持 TCP 连接理论上不占用网络资源（会占用两头程序的系统资源）。只要连接的双方认为 TCP 连接存在，并且可以互相发送 IP packet，那么 TCP 连接就一直存在。

对于问题 1，向一个 TCP 服务程序发起一个连接，客户端（为明白起见，以下称为 faketcp 客户端）只需要做三件事情（三路握手）：

1a. 向 TCP 服务程序发一个 IP packet，包含 SYN 的 TCP segment

1b. 等待对方返回一个包含 SYN 和 ACK 的 TCP segment

1c. 向对方发送一个包含 ACK 的 segment

在做完这三件事情之后，TCP 服务器程序会认为连接已建立。而做这三件事情并不占用客户端的资源（？），如果faketcp 客户端程序可以绕开操作系统的 TCP/IP 协议栈，自己直接发送并接收 IP packet 或 Ethernet frame 的话。换句话说，faketcp 客户端可以一直重复做这三件事件，每次用一个不同的 IP:PORT，在服务端创建不计其数的 TCP 连接，而 faketcp 客户端自己毫发无损。很快我们将看到如何用程序来实现这一点。

对于问题 2，为了让一个 TCP 客户端程序认为连接已建立，faketcp 服务端只需要做两件事情：

2a. 等待客户端发来的 SYN TCP segment

2b. 发送一个包含 SYN 和 ACK 的 TCP segment

2c. 忽视对方发来的包含 ACK 的 segment

在做完这两件事情（收一个 SYN、发一个 SYN+ACK）之后，TCP 客户端程序会认为连接已建立。而做这三件事情并不占用 faketcp 服务端的资源（？）换句话说，faketcp 服务端可以一直重复做这两件事件，接受不计其数的 TCP 连接，而 faketcp 服务端自己毫发无损。很快我们将看到如何用程序来实现这一点。

基于对以上两个问题的分析，说明单独谈论“TCP 并发连接数”是没有意义的，因为连接数基本上是要多少有多少。更有意义的性能指标或许是：“每秒钟收发多少条消息”、“每秒钟收发多少字节的数据”、“支持多少个活动的并发客户”等等。

faketcp 的程序实现

代码见： https://github.com/chenshuo/recipes/tree/master/faketcp 可以直接用 make 编译

为了验证我上面的说法，我写了几个小程序来实现 faketcp，这几个程序可以发起或接受不计其数的 TCP 并发连接，并且不消耗操作系统资源，连动态内存分配都不会用到。

我家里有一台运行 Ubuntu Linux 10.04 的 PC 机，hostname 是 atom，所有的试验都在这上面进行。

家里试验环境的网络配置是：

陈硕在《谈一谈网络编程学习经验》中曾提到“可以用 TUN/TAP 设备在用户态实现一个能与本机点对点通信的 TCP/IP 协议栈”，这次的试验正好可以用上这个办法。

试验的网络配置是：

具体做法是：在 atom 上通过打开 /dev/net/tun 设备来创建一个 tun0 虚拟网卡，然后把这个网卡的地址设为 192.168.0.1/24，这样 faketcp 程序就扮演了 192.168.0.0/24 这个网段上的所有机器。atom 发给 192.168.0.2~192.168.0.254 的 IP packet 都会发给 faketcp 程序，faketcp 程序可以模拟其中任何一个 IP 给 atom 发 IP packet。

程序分成几步来实现。

第一步：实现 icmp echo 协议，这样就能 ping 通 faketcp 了。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/icmpecho.cc

其中响应 icmp echo request 的函数在 https://github.com/chenshuo/recipes/blob/master/faketcp/faketcp.cc#L57 这个函数在后面的程序中也会用到。

运行方法，打开 3 个命令行窗口：

1. 在第 1 个窗口运行 sudo ./icmpecho ，程序显示

allocted tunnel interface tun0

2. 在第 2 个窗口运行

$ sudo ifconfig tun0 192.168.0.1/24

$ sudo tcpdump -i tun0

3. 在第 3 个窗口运行

$ ping 192.168.0.2

$ ping 192.168.0.3

$ ping 192.168.0.234

发现每个 192.168.0.X 的 IP 都能 ping 通。

第二步：实现拒绝 TCP 连接的功能，即在收到 SYN TCP segment 的时候发送 RST segment。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/rejectall.cc

运行方法，打开 3 个命令行窗口，头两个窗口的操作与前面相同，运行的 faketcp 程序是 ./rejectall

3. 在第 3 个窗口运行

$ nc 192.168.0.2 2000

$ nc 192.168.0.2 3333

$ nc 192.168.0.7 5555

发现向其中任意一个 IP 发起的 TCP 连接都被拒接了。

第三步：实现接受 TCP 连接的功能，即在收到SYN TCP segment 的时候发回 SYN+ACK。这个程序同时处理了连接断开的情况，即在收到 FIN segment 的时候发回 FIN+ACK。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/acceptall.cc

运行方法，打开 3 个命令行窗口，步骤与前面相同，运行的 faketcp 程序是 ./acceptall。这次会发现 nc 能和 192.168.0.X 中的每一个 IP 每一个 PORT 都能连通。还可以在第 4 个窗口中运行 netstat –tpn ，以确认连接确实建立起来了。如果在 nc 中输入数据，数据会堆积在操作系统中，表现为 netstat 显示的发送队列（Send-Q）的长度增加。

第四步：在第三步接受 TCP 连接的基础上，实现接收数据，即在收到包含 payload 数据 的 TCP segment 时发回 ACK。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/discardall.cc

运行方法，打开 3 个命令行窗口，步骤与前面相同，运行的 faketcp 程序是 ./acceptall。这次会发现 nc 能和 192.168.0.X 中的每一个 IP 每一个 PORT 都能连通，数据也能发出去。还可以在第 4 个窗口中运行 netstat –tpn ，以确认连接确实建立起来了，并且发送队列的长度为 0。

这一步已经解决了前面的问题 2，扮演任意 TCP 服务端。

第五步：解决前面的问题 1，扮演客户端向 atom 发起任意多的连接。

代码见 https://github.com/chenshuo/recipes/blob/master/faketcp/connectmany.cc

这一步的运行方法与前面不同，打开 4 个命令行窗口。

1. 在第 1 个窗口运行 sudo ./connectmany 192.168.0.1 2007 1000 ，表示将向 192.168.0.1:2007 发起 1000 个并发连接。

程序显示

allocted tunnel interface tun0
press enter key to start connecting 192.168.0.1:2007

2. 在第 2 个窗口运行

$ sudo ifconfig tun0 192.168.0.1/24

$ sudo tcpdump -i tun0

3. 在第 3 个窗口运行一个能接收并发 TCP 连接的服务程序，可以是 httpd，也可以是 muduo 的 echo 或 discard 示例，程序应 listen 2007 端口。

4. 回到第 1 个窗口中敲回车，然后在第 4 个窗口中用 netstat -tpn 来观察并发连接。

有兴趣的话，还可以继续扩展，做更多的有关 TCP 的试验，以进一步加深理解，验证操作系统 TCP/IP 协议栈面对不同输入的行为。甚至可以按我在《谈一谈网络编程学习经验》中提议的那样，实现完整的 TCP 状态机，做出一个简单的 mini tcp stack。

第一道题的答案：

在只考虑 IPv4 的情况下，并发数的理论上限是 2**48。考虑某些 IP 段被保留了，这个上界可适当缩小，但数量级不变。实际的限制是操作系统全局文件描述符的数量，以及内存大小。

一个 TCP 连接有两个 end points，每个 end point 是 {ip, port}，题目说其中一个 end point 已经固定，那么留下一个 end point 的自由度，即 2 ** 48。客户端 IP 的上限是 2**32 个，每个客户端IP发起连接的上限是 2**16，乘到一起得理论上限。

即便客户端使用 NAT，也不影响这个理论上限。（为什么？）

在真实的 Linux 系统中，可以通过调整内核参数来支持上百万并发连接，具体做法见：

http://urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/

http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3