微软做网站wordpress_域名输入后index of_然后点进取

下班路上发了一则朋友圈：

周四听了斯坦福老教授 John Ousterhout 关于 Homa 的分享，基本重复了此前那篇 It’s Time To Rep… 的格调，花了一多半时间喷 TCP…

Ousterhout 关于 Homa 和 TCP 之间的论争和论证，诸多反复回执，非常精彩：Is It Time to Replace TCP in Data Centers? && Response to Ivan Pepelnjak’s Blog Post && …

但本文我要说点和 Homa 有关又无关的东西，关于 HTTP 的。我觉得 HTTP 非常适合用 Message-Based protocol 传输。从 RFC2068 1.4 说起：

HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used;

紧接着下面一段多余了：

In HTTP/1.0, most implementations used a new connection for each request/response exchange. In HTTP/1.1, a connection may be used for one or more request/response exchanges, although connections may be closed for a variety of reasons.

上面这段话的 connection 关键词深入人心，让人觉得理所当然。

HTTP 是个无状态协议，天然应被 Message-Based transport 承载，非常自然且合理，why not？所以根本不需要 QUIC，甚至不再需要 TCP。

Homa 号称 RPC-Oriented，但也可以 HTTP-Oriented，每一对 Request/Response 类似一次 RPC。不限于 Homa，任何一个 Message-Based transport 承载 HTTP 都是高尚的。

采用 Message 承载 HTTP，其生命周期和 HTTP 的无状态对应，限制在一次 Request/Response，也就再也无需 TCP 连接管理了。

传输层为每次 Request/Response 生成单机唯一的 Message ID，将 Request/Response 映射到 Message，将 Message 映射到 packet 完成 packetization，以 Message ID 区分，即可并行多个 Request/Response。走这条路线，可直接消除 TCP 的问题，也就没了 QUIC 存在的必要。

HTTP/1.0 多条 TCP 连接并行处理多个 Request/Response，考虑 TCP 连接开销不可扩展，HTTP/1.1 允许多个 Request/Response 复用同一条 TCP 连接，但连接复用引入了 HTTP HoL blocking，比如短 Response 跟在长 Response 后面，为解决 HTTP HoL blocking，HTTP/2 引入二进制分帧多路复用，但引入了 TCP HoL blocking，为了解决 TCP HoL blocking，搞出了 QUIC。

若一开始使用 Message 模式并行处理 Request/Response，问题消失，就没有创建多条 TCP 的必要，自然就不会遭遇连接开销过大问题，接下来的一连串问题都不存在。遗憾的是，HTTP/1.0 一开始采用了 TCP。

这一切的根源在于一开始用一个有状态的 byte stream 协议去承载一个无状态的 Message 交互，结果最终 QUIC 虽然 UDP-Based，却也成了 TCP-Like，造化弄人。

Message 承载 HTTP 可能让人觉得奇怪，可将 HTTP 换成 RPC 就变得很自然，明明一回事，这就是先入为主的力量。
随便就是两个问题，若 Response 有 2GB，Message 如何装得下，若 Response 只 1KB，丢了就没有足够的 packet 触发 fast retransmit。说到底还是在用 TCP 思维解决 Message 问题。

必须要明确，TCP fast retransmit 是大量报文一起发送时顺带的恩惠，不是必须的，如果 TCP 只发生 1 个报文，便不会触发 fast retransmit。至于 2GB 的 Response，虽然怎么看它都像一条流，但它其实还是 Message：

采用 Message 承载 HTTP 并不仅仅因为它解决了连接管理问题，更不是因为它看起来更合理，还有一个很重要的优势，Ousterhout 在分享 Homa 时也提到了，Message-Based 可以利用多核优势并行处理，提高计算资源利用率。

至于说 Message-Based 拥塞控制，今晚没时间写了，明天详细聊下 L4S。

好归好，但历史和现实的力量往往更强大。

HTTP 标准化前，只有 TCP 满足 “reliable” 需求，著名的 Web Server 全假设 HTTP 被 TCP 承载，浏览器根本没有动力和动机偏向 UDP，到 HTTP 标准化时，就有了 “most implementations used a new connection…” ，注意修饰词，most implementations，但实际上是 all implementations。

之前说过，若不是 Google 同时掌控 App Server 和 Chrome Browser，QUIC 同样很难演进，可即便是 QUIC，依然还是 TCP-Like，还是没能突破老路子。

TCP 的影响力渗透到了每一根汗毛，即使 Amazon SRD 也在 “纠正 TCP 的问题”，各个新的旧的 transport 都在被 TCP 牵绕，却几乎从来没能另辟蹊径解决根本核心的问题，也许这个问题和 TCP 根本就没关系，就像本文说的 HTTP。

任何一个新协议都要试图解决 TCP 的某个或某些问题而不是解决 TCP 上层逻辑真正的问题，这才是真正的问题。

以前就了解过 Homa，但只有听 Ousterhout 亲自讲的时候才会有仪式感，他不止一次提到 Message 如何如何比 byte stream 好，比如边界清晰，并行处理，负载均衡…但他也说了，Homa 是专治 DataCenter 的各种不服的，而不打算去卷公网… 可我 don’t think so. 我觉得 Message-Based protocol 可以更好承载 HTTP 在公网上传输(运营商友好性是问题，但这是后话)，我觉得 HTTP 和 RPC 是一回事，无状态乒乓协议真不适合用 byte stream 承载，无论 TCP 还是 QUIC。我还是觉得现在几乎所有 transport 都被 TCP 影响了，任何一个新协议都要试图解决 TCP 的某个问题而不是解决 TCP 上层逻辑真正的问题。回头看，很多使用 TCP 的应用并不是非要用 TCP，而是没有别的选择借用 TCP，时间久了就成事实上的 TCP-Based。重新审视这些 “借用” 是高尚的。

浙江温州皮鞋湿，下雨进水不会胖。