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

本文探讨了网络IO模型的发展,从早期的C10K问题解决方案(如iocp/epoll)到现代服务器的高速网卡需求,指出网络IO库的延迟已不适应硬件发展。着重分析了内核协议栈延迟的重要性,并提到C10M时代的来临对网络技术的新挑战。
摘要由CSDN通过智能技术生成

在目前网络上能搜索到的,关于网络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时代已经到来。

  • 8
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值