高性能服务系列【八】C10M时代，网络IO库需要重建

在目前网络上能搜索到的，关于网络IO模型的文章，基本都是关于多路复用的iocp/epoll的，这些技术是为了解决C10K问题而提出的解决方案。现代网卡已经普遍支持10Gb，100Gb也不少见，这些解决方案已经无法提升性能的需求。

我们忽略应用层技术和应用背景，重点讨论网络IO这个底层技术。我们首先需要知道这些底层技术的产生背景，就是著名的C10K问题，简单的说，就是要解决服务端如何支持一万个客户端同时连接。C10K问题的本质就是操作系统问题，考察之前的技术：

1、同步阻塞IO模型，需要为每个客户端连接指定一个进程/线程。多进程/多线程导致上下文切换频繁。

2、异步IO模型，加上SELECT/POLL，解决了上下文切换频繁问题。但客户端连接是否数据，仍然需要逐个检查，效率不高。

iocp/epoll两个模型，只有在客户端连接是可用的情况，才会通知应用层继续IO操作，处于空闲状态的客户端连接则无需理会。，C10K问题就这么解决了。

linux2.5内核引入的epoll，但2.6版本公认是最好。经过近20年的发展到现在，已经很成熟。比如ACE、asio、libevent，libev，libuv。还有基于iocp/epoll的知名网关组件，ngnix，haproxy，和qpid、zeroMQ消息总线等。

现在服务器安装10Gb/100Gb带宽网卡已经十分普遍，按照最小以太帧84字节来算，10Gb的网卡最小延迟能达到50ns。而当前网络IO库的延迟单次调用都要超过1us，这说明着网络库已经落后于硬件的发展。

网络IO延迟包括线上传输的延迟加上内核协议栈的延迟。早前硬件制约了网络传输延迟，内核协议栈的延迟在硬件延迟面前，显得微不足道。但硬件提升，内核协议栈延迟的占比就凸显出来。

如何解决内核协议栈延迟，目前已经有很多方案可以参考的做法。但并没有像C10K解决方案那么普及。

C10M时代已经到来。