随便谈谈网络通讯延迟和应用
首先丢出2个简单定理。
定理1
任何所谓的软件编程本质上都是面向硬件编程
定理2
任何软件操作的根本延迟受制于硬件循环所需要的时间
计算机作为一个输入输出设备，本质上就是3个步骤，输入、处理、输出。计算机之间的通讯媒介，无非有线无线，其实主要是取决于介质和通讯方式。
如果是有无线的场合，包括WiFi或者是无线电RF还是所谓的5G，都在这个范畴。WiFi存在Jitter，这个延迟必须考虑在内，一般会考虑多个WiFi的NIC提高带宽减小延迟。民用无线电技术如今可以做到40Gbps的带宽不是问题，延迟也较低，但是这个容易有干扰，还需要无线电执照许可，比如无人机都用WiFi的公共频段，所以机器在某个场合聚集就都废了，而且干扰技术也压根不存在问题。
有线，只要是基于电的，那都逃不过物理定律，非超导的常温状态下，联系到基本电磁干扰和信号衰减，距离做到百米级别，带宽做到10Gbps已经是极限。需要比如10Gbps以上的带宽往往都是光纤接口。这个好处是简单粗暴，买硬件设备和电缆就行。
但是，有些场合是不需要考虑延迟的，而是需要可靠性的，比如HTTPS的响应。TCP加上TLS这一层，这个其实是怎么都不会快的，对于一个看网页的用户来说，100ms和200ms的响应，是没几个人会抱怨的，通过CDN等等可以优化吞吐到很理想的状态，也就是小于100ms，接近于本地的的速度。这个WiFi的好处就是随处可得，问题是搞延迟低吞吐。
如今的Web应用，从TCP/IP模型看，主要是第4层应用层的折腾，IP层都不会考虑，靠买设备解决。我称之为延迟在100ms以下的应用。这个往往都是通过CDN来，但是也不会小于15ms。本质上还是堆设备以及在现有的TCP/IP的第3层上捣鼓，优化路由优化连接，以城市为单位部署更多的节点诸如此类。
但是要记得，15ms是一个很高的延迟。为什么这么说，因为15ms几乎是现有互联网跨地域应用的一个极限，也就是无论是你玩游戏也好，所谓的低延迟视频的也好，所谓的低延迟实时数据分析也罢，这个延迟对于现有GPCPU（看清楚，不是GPCPU）来说，都逃不过定理2——就是说，你怎么折腾，从NIC触发中断，然后Kernel再来折腾，然后再来通知Userspace的程序去处理，如果是转发的话这个再来一遍，这个过程已经消耗了许多CPU循环，而且许多操作跟数据处理本身并无关联。当然可以打一下Realtime Linux内核补丁，但是从根本上来说，这些步骤都需要进行，都是基于现有的硬件之上，所以本质上也没什么意义。看到搞什么Apache Spark+Kafka的就觉得搞笑，就这些Java堆起来的大路货，最多做做Web应用，在核心关键场合，这些都统统得废。
当你在本地跑个NodeJS，本地发个HTTP请求，那个已经最少1ms，这个就是单个PC工作站能做到的极限——跑了一圈应用程序的Runtime，到OS API，外加TCP/IP Stack，然后返回结果再重新跑一轮。在异步编程还没流行的时代，服务器的表现其实也并没有太差劲，而且同步网络编程好写逻辑。但是归根结底，无论同步和异步，都是仰仗硬件架构加上OS的核心API提供给上层。应用程序得益于多线程使得逻辑和网络发包线程可以分开，但是其实只是充分利用了系统的间歇性存在的资源，和本质上的提高并无相关。也就是说给定输入输出设备，服务器跑个Linux，无论是用libuv（C）、libevent（C）、netty.io（Java）、asio（C++）、Erlang、Scala等等随便什么框架写的应用，处理效率只可能在某个极限戛然而止。当然这里存在许多迷信成分，就是比如优化内存分配，优化连接，最后都会落实成部署更多的节点。当今C和C++语言连带框架构造的网络服务系统，是当今现有计算机体系网络性能的极限，比如Netflix。你堆什么框架，都是一样，不可能解决根本延迟问题，改进的只是开发的时间、风格、成本问题等等其他方面。
顺便提个GPU。这NVIDIA本来就是靠卖硬件吃饭的公司，出货量就是一切。对于应用程序来说，如何驱动GPU工作，那得再加一层驱动核心，上层怎么CUDA或OpenCL，最后都绕不过Driver那个地方。而且Driver还不是问题，Driver本身的职责是个复杂的调用，包括DMA和设备管理了。前者会连到坑爹的IO部分，后者各自厂商有各自的应用解释层，本质上也是用一套API操作GPU。所以对于低延迟和高IO访问、随机访问的程序，GPU是很少干的过CPU。唯一的可能就是当单个步骤的线性计算量很大，CPU不划算的时候，GPU才有用武之地。看，如果GPU性能真的有纸上那么强，现有的游戏帧速度应该早就突破成千上万，GPU计算延迟应该极地，但是其实最后并没有，因为指标和执行是两个概念，参考定理2。可能有人会说AI\ML加速，看，如果真的GPU是终极解决方案，那Google就没有必要发展TPU了，因为无论如何，GPGPU的架构和执行模型不可能干的过独立的芯片。
还可以提一下FPGA+PC。这个架构目前云端已经有，号称提供低延迟，但是其实并没有解决本质问题。设想，一台装在机房里的云端节点，插上了FPGA加速卡，然后就号称能做什么了，这个就和GPU一样，不好意思还得走PCI-E总线和MMU内存控制器，一般来说还是得有驱动那一层干这个，不然无法驱动FPGA卡进行工作。这个FPGA表现对比GPU是折中，就是说它的硬件循环延迟要低于CPU（看具体型号），远低于GPU，但是吞吐量是不如CPU和GPU的。FPGA的性能很好计算，看FPGA的频率，看吞吐计算量，当然还有处理逻辑。有些计算FPGA非常有优势，比如FFT，当然也有限制，比如一旦牵涉到了浮点计算这个效能会降低。
许多文章已经考虑过FPGA和GPU，比如这一篇《GPU vs FPGA Performance Comparison》，列出了FPGA和GPU的优劣势对比图。
那么对于如今的AI来说，GPU是足够用的，比如训练视频流数据，无非就是解码后丢给训练框架，这个地方吞吐不会巨大，一般民用的所谓视频AI分析并没有低延迟的需求。譬如1920x1080@30fps，首先摄像头和编码理论上需要最少2*33=66ms，然后是网络传输的时间，假设为15ms，再加上进入主机程序丢给GPU解码，解码器最少需要1-2帧的延迟，然后是训练然后输出，那么假设我们开始训练一个摄像头的数据，从摄像头接收可见光辐射，到人类坐在办公室里看到镜头，已经需要了最少100ms，再考虑一下实际运行环境以及客户端软件编写水平的差异，最好的结果往往是小于200ms。当然这个延迟对于如今的应用来说可用，但是延迟依然是实在是太高了。这种乐高级别的系统做做某些CV应用还是可以的，毕竟人类没见过几个在街头蒙上面具以奥运会百米冲刺的速度飞奔。
那么对于特种应用来说，假设给定网络硬件部分、CPU和操作系统，对于简单计算来说，FPGA是会比GPU效能更高的。因为首先哪怕是50Gbps的NIC，对于单个网络应用来说，单个会话数据流也是吃不满的。那么就是变成了，每一个业务循环输入输出真正完成的时间，才是系统的总延迟。上面的关于视频的问题，显然纯粹FPGA编解码是可以达到所谓的实时性能，也就是整个系统最少有2-3帧时间的延迟。我说的是直接摄像头捕获到输出端的显示，不是什么预录制的视频编解码，这种例子一点意义都没有。
许多特种应用，需要极低的延迟。这个时候根据考量，如果是距离在允许范围内，一般只考虑电磁传输，比如微波通信在金融系统中的应用。做金融通讯的可以不计成本的怼高技术和硬件，提高几个ms在交易上是可以有巨大优势的。如今华尔街都是应该目标瞄准纳秒级别的通讯延迟了，豪秒已经没什么搞头了——毫秒是A股水平，上海的租用的机房能够提供大概<50ms的延迟，当然套利组合那边不要创造收益率负83%然后跳楼就行。纳秒级别的通讯配上全球原子钟阵列，这个可以一战。
现在问题了，立足于ISA和逻辑门电路的这种体系，本质上是面向GPCPU的，也就是譬如x86这种，你的每一个LEA，每一个CALL，对于CPU来说都是高层API，底层流水线那边都得跑一串。解决方案当然是买卡，买FPGA卡来做，把一部分逻辑丢在网卡上做完，进入PC的都是面向高层的应用，比如数据库IO、可视化监控等等，这些都是属于非延迟关键的场合。当然最后的关键是往往买卡也是搞不定的，因为卡的延迟也会出现，最后应用套利组合的现场会受制于当前的硬件架构，这个是最高的极限，不过一般可以接受。
末了，我理想中最佳的低延迟方案是，1）传输部分全部是微波或者光纤，2）高度优化的网络连接接口，3）计算部分直接在硬件层次上完成，理想是ASIC，最多用一下FPGA，4）如果需要外部数据，实现一套硬件Cache，而且编码上百分之百的针对硬件的行为进行优化。这么一套组合拳下来，这个特殊系统的低延迟还是很容易办到的。
本文谢绝转载。欢迎行业公司和个人联系探讨。
