客户端-服务器计算为何没有设置独立的错误与状态信息传输通道？

首先需要明确：你提到的现象本质是上层应用协议的设计选择，和TCP传输层的标准无关，也不存在不可解决的技术难点，核心是收益和成本的权衡，具体可以拆解为几个点说明：

• 第一，单条TCP连接完全可以实现类UNIX系统stdout/stderr的多流分流效果。TCP本身是无差别的字节流传输协议，上层应用只需要在数据包结构里加1个简单的消息类型标记，就可以把返回内容分为「业务结果包」「进度通知包」「错误告警包」等不同类型，客户端接收后自行分类处理即可：需要看进度的用户就把通知渲染到状态窗口，不需要的直接忽略对应类型的包就行，完全不需要额外开端口、建立新连接。
• 第二，额外建立连接的成本远高于预期，高并发场景下不可行。如果服务端要同时承接几万到几十万的客户端连接，每条连接多开1条TCP链路，就意味着要多维护一倍的socket句柄、连接状态、心跳检测逻辑，会大幅提升服务端的内存、CPU开销，还会额外带来防火墙策略配置、NAT穿透失败等运维问题，投入产出比极低。现在包括HTTP/2、HTTP/3在内的主流应用层协议，反而都在把多条逻辑流合并到同一条传输连接上，就是为了降低连接开销，你提到的额外开端口的思路刚好和业界优化方向相反。
• 第三，现有数据库产品其实已经有类似的进度通知能力，只是默认不开放。比如PostgreSQL的异步通知机制、MySQL的查询进度扩展，都是在原有单连接上实现的执行进度上报功能。之所以默认不开启，一方面是因为高频上报进度会占用服务器资源，反而拖慢查询本身的执行速度，对不需要进度通知的生产场景是负收益；另一方面很多包含存储过程、触发器的复杂查询本身很难精准统计执行进度，硬做容易给用户传递错误的预期，这类个性化需求通常更适合在上层业务侧自行实现，不需要放到通用的数据库通信协议里。

最后可以明确：这个需求完全不需要向TCP标准化组织提建议，现有TCP能力已经可以支撑相关实现，要不要做、怎么做都是上层应用层的选择。

内容的提问来源于stack exchange，提问作者haraldk