旅游网站前端建设论文,wordpress学校主题,wordpress主题摄影,最专业的网站建设公司哪家好下班路上发了一则朋友圈#xff1a;
周四听了斯坦福老教授 John Ousterhout 关于 Homa 的分享#xff0c;基本重复了此前那篇 It’s Time To Rep… 的格调#xff0c;花了一多半时间喷 TCP…
Ousterhout 关于 Homa 和 TCP 之间的论争和论证#xff0c;诸多反复回执…下班路上发了一则朋友圈
周四听了斯坦福老教授 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 blockingHTTP/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 有 2GBMessage 如何装得下若 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 BrowserQUIC 同样很难演进可即便是 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。重新审视这些 “借用” 是高尚的。 浙江温州皮鞋湿下雨进水不会胖。
