共 3 篇相关文章
这篇翻译文章源于作者对抗运营商网络劫持的关注，借此机会详细对比了传统HTTPS、SPDY/3.1以及新兴的HTTP/2协议在性能上的具体差异。 测试以Google英国首页为例，在相同条件下对比三者。一个关键区别在于报头压缩：HTTP/2采用的HPACK算法，在报头大小上显著优于SPDY所使用的DEFLATE压缩，使得HTTP/2的空请求报头体积最小，优势明显。 在响应信息大小方面，情况则更为复杂。对于图片资源，三者表现相近。但对于文本内容，虽然HTTP/2报头更小，但其数据帧的可选填充字节，使得最终响应信息反而大于SPDY。文章解释，这种填充机制主要是为了对抗如BREACH等特定安全攻击。 总体来看，HTTP/2在连接初期的数据传输效率上建立了优势，尤其是在报头处理上更为高效。而SPDY在某些特定内容的传输中依然保持着竞争力。文章通过具体的截图和数据，清晰地展示了下一代网络协议在优化性能与保障安全方面的不同设计权衡。
这篇讲的是Google推出的SPDY协议如何试图解决传统HTTP协议在现代Web下面临的性能瓶颈。文章从对比出发，清晰地指出HTTP的三大痛点：每个请求需要单独TCP连接导致的低效、服务端无法主动推送内容、以及重复的头部信息造成带宽浪费。 SPDY的核心思路是“增强而非取代HTTP”，它通过在一个TCP连接上实现多路复用，允许并行处理多个请求；引入服务器推送，让服务器能预加载资源；并压缩头部信息，从而大幅减少延迟和带宽消耗。同时，SPDY强制使用SSL加密传输，提升了安全性。文中特别指出，这使得现有服务端应用无需大改，只需增加SPDY传输层即可升级。 对于不同角色，SPDY的价值立竿见影：普通用户感受到更快的加载速度和更高的安全性；前端工程师可以利用请求优先级优化页面渲染；运维人员则能减少服务器连接资源消耗。文章最后也点明了SPDY作为HTTP 2.0重要候选者的背景，其目标就是让整个网络“快”起来。
这篇讲的是作者如何从翻墙的“痛点”出发，用 Node.js 与 SPDY 协议打造新方案。作者最初依赖 ssh -D，但常遭遇连接中断，即便配置 keep-alive 也难以根治。这让他思考：能否直接走 HTTP 或 SOCKS 协议？核心障碍在于通信的加密与效率。 于是，他将目光投向了 SPDY 协议。文章详细记录了如何用 Node.js 搭建基于 SPDY 的代理服务——它在 TCP 之上实现了多路复用与头部压缩，同时依托 TLS 加密，恰好解决了传统 HTTP 明文传输的安全隐患。作者从环境搭建到代码实现逐步展开，不仅剖析了 SPDY 协议相比 HTTP/1.1 在延迟与吞吐量上的优势，也坦诚对比了与 SSH 隧道在连接稳定性上的差异。最终，这套自建服务不仅运行稳定，更让客户端免于安装额外软件，实现了浏览器原生支持的便利访问。
