实时通信技术选型：从长轮询到WebTransport的二十年演进
2011年，当一个聊天应用需要显示对方"正在输入"的状态时，开发者不得不让客户端每隔几秒向服务器发一次请求——问一句"有新消息吗？"，服务器回答"没有"，然后重复。这种愚蠢的对话在HTTP的世界里持续了整整十五年。 ...
QUIC
HTTP/3的流量控制为何比TCP更精细：从滑动窗口到双层限额机制的技术演进
2016年，Cloudflare在部署HTTP/2时遇到了一个奇怪的问题：某个高优先级的大文件传输会阻塞所有其他请求，尽管HTTP/2已经实现了多路复用。问题的根源在于TCP的流量控制机制——所有流共享同一个滑动窗口，一个流的丢包会让整个连接停摆。 ...
当WebSocket遇上QUIC：WebTransport如何重塑浏览器实时通信的四十年技术演进
2024年，WebTransport API在Chrome 97、Firefox 114、Edge 97中正式发布。这个基于HTTP/3的浏览器API，承诺为实时通信带来「接近原生」的性能体验。W3C WebTransport工作组正在推进规范向Candidate Recommendation阶段演进，目标在2025年完成标准化。但问题的根源要追溯得更远——四十年来，TCP协议的设计选择一直在制约着浏览器端的实时通信能力。 ...
零往返的代价：HTTP/3 0-RTT 为何成为开发者必须正视的安全陷阱
2017年2月，一篇发表在IACR密码学预印本上的论文提出了一个尖锐的问题：当一个协议试图在零次往返中建立安全连接时，它是否还能保持密码学的安全承诺？这篇由德国达姆施塔特工业大学Marc Fischlin和Felix Günther撰写的论文，标题本身就揭示了问题的核心——《Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates》。 ...
TLS 1.3 与 QUIC：互联网传输层十年重构的技术逻辑
1994年，Netscape 发布了 SSL 2.0，首次为 HTTP 加上了加密层。二十年后，IETF 发布了 TLS 1.3（RFC 8446），彻底重构了这个协议。又过了三年，QUIC（RFC 9000）正式成为标准，HTTP/3 随之诞生。这不仅是版本号的更迭，而是互联网传输层设计哲学的根本性转变。 ...
QUIC 协议：当 UDP 重塑互联网传输层
2012年，Google 工程师 Jim Roskind 和他的团队面临一个看似无解的问题：TCP 协议已经统治互联网传输层近 40 年，但它的一些根本性缺陷让 Web 性能优化陷入瓶颈。他们决定做一个在当时看来近乎疯狂的选择——抛弃 TCP，用 UDP 从零重建一个传输协议。 ...