http服务端的监听开销？

Question

问题如下：
背景：一个维护性系统要给一个高实时性系统进行维护。
1）维护性系统这边系统通过http进行配置下发，软件升级，实时性系统作为http服务端。
2）实时性系统认为开启一个http（tcp）的监听服务占用线程轮询开销，拒绝作为http的服务端。希望维护系统发送一个udp报文给实时性系统，然后实时性系统作为http客户端访问维护性系统获取配置数据。
3）方式1和方式2的区别就在于实时性系统作为udp服务端和tcp服务端的性能开销对比？这个不太清楚

Answer 1

你所谓的实时系统要么等待tcp包，要么等待udp包，对于服务来说是一样的，但udp包是允许丢包的，如果你的系统不允许丢包的化，就需要自己来管理udp丢包的处理。所以除非是音视频这种丢一两帧无所谓的通讯，否则都应该优先考虑tcp的通讯，从服务端的角度上说，没有性能上的差异，从通讯速度本身来说udp是会比tcp要快一些的。但这个快是有代价的。

Answer 2

TCP开销：

1. 长连接需要保持心跳是有开销的
2. 短连接每次握手挥手是有开销的
3. TCP报头比UDP报头大，传输也有开销
4. TCP还有额外的校验也是有开销的

UDP开销小是有代价的：

1. 无法确定传输过程中是否丢包
2. 无法确定数据包是否传输完整
3. 无法确定是谁发起的数据包

Answer 3

我觉得这个其实不能简单的从你给出的3个问题方向来讨论，还需要到具体场景中看。

1. 因为高实时系统可能有自身限制，不能很好的实现http服务监听，但udp监听可能可以做到；
2. 此外对于通信丢包之类问题，如果连接链路本身比较简单，可能不成为问题；

3. 还要看配置使用和高实时性的均衡问题，既到底是保障高实时的可靠性，还是更多保障配置要及时更新，如果

   1. 保障高实时性，则配置短时没有及时更新影响不大，则udp的问题影响就更小，反正只需要udp接受一个触发信号，需要本地在保障高实时且有资源剩余情况下，才会主动触发http请求去获取新配置（可能这个过程比较占资源），并在完整获取后合适的时间进行配置更新。
   2. 要求及时更新配置，则不能很好保障实时性，这时首先要保证配置能及时送达，这时高实时系统必须维持一个高可用的接收配置的通道，也就是http服务通道，这样在高实时性系统中必须要增加比较大的资源来保障这个过程的稳定可行。

总之这个问题需要结合具体场景，认真的分析需要来进行决策，而不仅仅是简单的看两种协议特性来处理的问题。