前几天我在新浪微博上出了两道有关 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 并发连接数”是没有意义的，因为连接数基 本上是要多少有多少。更有意义的性能指标或许是：“每秒钟收发多少条消息”、“每秒钟收发多少字 节的数据”、“支持多少个活动的并发客户”等等。