我做过一个方案，在完全没有物理网卡的硬件平台上，让上层应用照常使用标准的网络编程接口。socket 照写，TCP/IP 照跑，CORBA、DDS 这类中间件照常工作，应用代码一行不改。
这篇不讲实现细节，方案本身不方便摊开。但我想聊聊这个问题的难处在哪，以及为什么大多数团队在这个坑里一蹲就是几个月。
01
这个坑，比看上去深得多
场景很典型。硬件平台换了，或者出于成本、功耗、供应链的考虑，新平台干脆没配网卡。能用的通信外设只剩串口这一类低速点对点接口。
但软件栈不会等你。上面的应用全都建立在以太网的前提上，跑 socket 的、跑 TCP/IP 协议的，重的还有 CORBA、DDS 这种分布式中间件，整套体系假定底下就是标准网络。
问题的全貌，上层软件栈和底层硬件之间隔着一道断层
把这两头接上，常规思路有三条，我一条条说为什么都疼。
改应用。把网络编程接口全换成串口读写。几十个应用挨个动刀，工作量先放一边，改完的代码跟原平台分叉了，以后两边都要养。
改中间件。往 CORBA 或 DDS 的内部动手，把它的传输层换掉。这类中间件是几十万行级别的成熟系统，协议、发现机制、QoS 层层咬合，动一处带一片。更要命的是从此背上私有分叉，上游每升级一次，手术重做一遍。
写个协议转换层。在中间加一层自定义的封装转发。听着轻量，做起来是另一回事，分包重组、流控、异常恢复、多系统适配，每一项都是实打实的工作量，联调时一个丢包你很难说清死在哪一层。
三条路的共同点是，都在往系统里加新的复杂度。工作量不可控，风险不可控，后期维护是个无底洞。
我见过不少团队就在这仨选项里来回纠结，最后挑了一条硬着头皮走完，项目延期半年起步。
02
我的解法，一句话版本
我当时没走这三条路。
方案公开能说的只有一句，一套硬件无关的虚拟网卡方案，让操作系统和上层软件以为自己底下有一块正常的网卡。
无网卡平台上，标准以太网通信全链路跑通。上层应用零修改移植，原样编译、原样运行。
整个方案对系统的侵入极小，应用层和中间件代码不用修改。
判断一个方案好不好，
就看上面的人需不需要知道它存在。
这套方案做到了，上面的人完全不知道。
03
为什么这个问题值得去解决
总会遇到一些变态的需求，硬件平台没有物理网卡，但软件已经有以前现成的，软件栈跑在标准网络编程接口上。更要命的是系统里有 CORBA、DDS 这类中间件，动不得又绕不开。换主控、裁剪 BOM、国产化替代、老平台续命，被通信适配卡住。评估过改中间件或写协议转换层，觉得工作量和风险吃不下。
