低延迟网络技术和银子弹

Gel*_*tor 4 c++ java networking low-latency

在对低延迟网络进行一些基本的谷歌搜索后,我提出了以下程序员和系统设计人员在开始低延迟网络时应该考虑的事项:

  1. 必须一起考虑硬件,系统和协议的设计

  2. 使用UDP而不是TCP开发协议并实现简单的ack-nak,在应用程序级别重新发送逻辑

  3. 减少从线路上消耗和打包数据的进程或线程的上下文切换次数(最好为零)

  4. 使用OS的最佳选择器(选择,kqueue,epoll等)

  5. 使用具有大量板载缓冲区(fifo)的高质量NIC和交换机

  6. 使用多个NIC,专门用于下游和上游数据流

  7. 减少其他设备或软件生成的IRQ数量(如果不需要,可以简单地删除它们)

  8. 减少互斥锁和条件的使用.而是尽可能使用无锁编程技术.利用架构的CAS功能.(无锁容器)

  9. 考虑单线程多线程设计 - 上下文切换非常昂贵.

  10. 理解并正确使用架构的缓存系统(L1/L2,RAM等)

  11. 希望完全控制内存管理,而不是委托给垃圾收集器

  12. 使用优质电缆,保持电缆尽可能短,减少扭曲和卷曲的数量

我的问题:我想知道在开始使用低延迟网络时,SOers认为其他什么是重要的.

请随意批评以上任何一点

Jer*_*fin 8

电缆质量通常是一种红鲱鱼.我想更多关于连接网络分析仪,看看你是否得到足够的重新传输来关心.如果你变得非常多,请尝试隔离它们发生的位置,并更换导致问题的电缆.如果您没有收到导致重新传输的错误,那么电缆(实际上)对延迟没有影响.

NIC和(特别是)交换机上的大缓冲区本身不会减少延迟.事实上,为了真正减少延迟,您通常希望使用最小的缓冲区,而不是更大的缓冲区.坐在缓冲区中而不是立即处理的数据会增加延迟.说实话,它很少值得担心,但仍然如此.如果你真的想最大限度地减少延迟(并且非常关心带宽)你最好使用集线器而不是交换机(那种难以找到的东西,但只要网络拥塞足够低,肯定是低延迟).

多个NIC可以帮助很多带宽,但它们对延迟的影响通常非常小.

编辑:然而,我的主要建议是获得规模感.通过一英尺减少网络电缆可以节省大约一纳秒的时间 - 与通过几种汇编语言指令加速数据包处理相同的一般顺序.

结论:与任何其他优化一样,为了获得更远的距离,您需要先测量延迟时间,然后才能减少延迟.在大多数情况下,减少电线长度(使用一个示例)不会产生足够的差异,只是因为它开始很快.如果事情开始需要10微秒,那么你所能做的就是加速它超过10微秒,所以除非你的事情如此之快以至于10美元占你的时间的很大一部分,否则不值得攻击.

  • 电缆和网络管理员的一个常见问题是切断电缆所需的时间,然后最终将它们拧入机舱侧面以保持物品清洁.双绞线信令的问题在于这种动作会导致巨大的信号衰减,这在考虑微秒分辨率的延迟时会引起问题. (3认同)
  • 不,他有一点意见.在我们现在推动网络的速度下,您必须将传输视为混合模拟 - 数字设计,并且弯曲双绞线电缆中的信号劣化实际上是天线效应.毫无疑问,天线效应在模拟方面. (3认同)

Jas*_*onN 6

其他:

1:使用userland网络堆栈

2:与处理代码(共享缓存)在同一套接字上的服务中断

3:更喜欢固定长度的协议,即使它们的字节大一点(解析速度更快)

4:忽略网络字节顺序约定,只使用本机排序

5:从不在例程和对象池中分配(尤其是垃圾收集语言)

6:尝试尽可能地防止字节复制(TCP发送困难)

7:使用直通切换模式

8:黑客网络堆栈删除TCP慢启动

9:广告一个巨大的TCP窗口(但不要使用它),所以另一方可以一次拥有大量的机上数据包

10:关闭网卡合并,尤其是发送(如果需要,可以在应用堆栈中打包)

11:比光学更喜欢铜

我可以坚持下去,但这应该让人们思考

一个我不同意:

1:网络电缆很少出现问题,除非出现问题(电缆类型有例外)