TCP网络编程的本质

基于事件的非阻塞网络编程是编写高性能并发网络服务程序的主流模式，它把原来”主动调用recv来接收数据，主动调用accept来接收新连接，主动调用send来发送数据“的思路换成”注册一个收数据的回调，网络库收到数据会调用我，直接把数据提供给我，供我消费。注册一个接收连接的回调，网络库接收了新连接会回调我，直接把新的连接对象传给我，供我使用。需要发送数据的时候，只管往连接中写，网络库会负责无阻塞地发送。“

TCP 网络编程本质论

TCP 网络编程最本质的是处理三个半事件：

1. 连接的建立，包括服务端接受 (accept) 新连接和客户端成功发起 (connect) 连接。
2. 连接的断开，包括主动断开 (close 或 shutdown) 和被动断开 (read 返回 0)。
3. 消息到达，文件描述符可读。这是最为重要的一个事件，对它的处理方式决定了网络编程的风格（阻塞还是非阻塞，如何处理分包，应用层的缓冲如何设计等等）。
4. 消息发送完毕，这算半个。对于低流量的服务，可以不必关心这个事件；另外，这里“发送完毕”是指将数据写入操作系统的缓冲区，将由 TCP 协议栈负责数据的发送与重传，不代表对方已经收到数据。

这其中有很多难点，也有很多细节需要注意，比方说：

1. 如果要主动关闭连接，如何保证对方已经收到全部数据？如果应用层有缓冲（这在非阻塞网络编程中是必须的，见下文），那么如何保证先发送完缓冲区中的数据，然后再断开连接。直接调用 close(2) 恐怕是不行的。
2. 如果主动发起连接，但是对方主动拒绝，如何定期 (带 back-off) 重试？
3. 非阻塞网络编程该用边沿触发(edge trigger)还是电平触发(level trigger)？（这两个中文术语有其他译法，我选择了一个电子工程师熟悉的说法。）如果是电平触发，那么什么时候关注 EPOLLOUT 事件？会不会造成 busy-loop？如果是边沿触发，如何防止漏读造成的饥饿？epoll 一定比 poll 快吗？
4. 在非阻塞网络编程中，为什么要使用应用层缓冲区？假如一次读到的数据不够一个完整的数据包，那么这些已经读到的数据是不是应该先暂存在某个地方，等剩余的数据收到之后再一并处理？。假如数据是一个字节一个字节地到达，间隔 10ms，每个字节触发一次文件描述符可读 (readable) 事件，程序是否还能正常工作?
5. 在非阻塞网络编程中，为什么要使用应用层发送缓冲区？假设应用程序需要发送40kB数据，但是操作系统的TCP发送缓冲区只有25KB剩余空间，那么剩下的15KB数据怎么办？如果等待OS缓冲区可用，会阻塞当前线程，因为不知道对方什么时候收到并读取数据。因此网络库应该把这15KB数据缓存起来，放到这个TCP连接的应用层发送缓冲区中，等socket变得可写的时候立刻发送数据，这样”发送“操作不会阻塞。如果应用程序随后又要发送50KB的数据，而此时发送缓冲区中尚有未发送的数据，那么网路库应该把这50KB的数据追加到发送缓冲区的末尾，而不能立刻尝试write,因为这样会打乱数据的顺序。
6. 在非阻塞网络编程中，如何设计并使用缓冲区？一方面我们希望减少系统调用，一次读的数据越多越划算，那么似乎应该准备一个大的缓冲区。另一方面，我们系统减少内存占用。如果有 10k 个连接，每个连接一建立就分配 64k 的读缓冲的话，将占用 640M 内存，而大多数时候这些缓冲区的使用率很低。muduo 用 readv 结合栈上空间巧妙地解决了这个问题。
7. 如果使用发送缓冲区，万一接收方处理缓慢，数据会不会一直堆积在发送方，造成内存暴涨？如何做应用层的流量控制？
8. 如何设计并实现定时器？并使之与网络 IO 共用一个线程，以避免锁。