Fangliding：反对为 (x)mux 引入上千行状态的 ACK 机制，认为是在重新引入 TCP 已抽象掉的问题
在 Xray-core issue #7115 关于 (x)mux 连接稳定性的讨论中，Fangliding 对「引入 ACK 机制」的提议提出反对：为部分网络一分钟断一条连接的情况引入上千行、涉及各种状态的 ACK 状态管理并不值得；TCP 已费大力气把这些问题抽象掉，再引入进来不划算；HTTP/2 也没有做这类机制，仅处理队头阻塞的 window update 就已带来很大麻烦。
作者原文@Fangliding19. I'm saying this as a reminder & a history record: As long as there is no ACK mechanism & no decoupling between proxy & apps session, using mux & xmux will only worsen the connection performance eventualy (regardless of their benefits, only in terms of stability) ; mobile networks , ADSL Setups & etc... right now cannot even tolerate the normal connection failures at proxy level , let alone using (x)mux that leads this to a more worse connection quality; Quic was introduced to address this, but because it's normally blocked for foreign IPs in Russia & Iran ( I don't know about China ), This ACK mechanism will replace Connection Migration & benefits of QUIC which can be added to (x)mux. This Decouplization should be an Standard , not a demand so that it's simply responded : "due to complexity , this FR is Closed as not Planned " .
In the future , we'll be heading towards this , closing FRs won't help it. This should be as i said, an Standard , not an even irrevelant matter!几个人的网络和你一样一分钟断一条连接 就为了你引入一个上千行涉及各种状态的ack状态管理？tcp费大力气抽象掉的东西又引入进来 http2都没做这种东西 光是一个为了处理队头阻塞的window update就已经带来多大的麻烦了