为什么HTTP是基于文本的而不是一些压缩方法？为什么不压缩JS？

Question

我从谷歌Chrome浏览器上嗅了一些数据包 - 我发现：

1. HTTP请求以文本形式发送 - 实际上是发送'GET BLABLABLA'
2. JS以文字形式收到
3. HTML \ images等以一些压缩方法传输。

我的问题是 - 为什么在没有任何压缩的情况下传输HTTP和JS？ 我认为完全格式的HTTP请求可以压缩到大约3~5个字节，不包括cookie，并且还可以压缩页面选择（例如site.com/thisisanicefile.html＆gt; site.com/ABC)
另外 - 为什么JS被转换为纯文本而不是令牌数组（编程语言在执行前转换为令牌数组 - 脚本语言也是如此）？ 谢谢 - 马克

Answer 1

对于HTTP：嗯，这就是协议的定义方式。该协议是基于文本的。实现简单，无需担心字节序等问题。

内容（html，javascript，images，...）可以压缩发送，这是在浏览器和服务器之间编码“协商”的问题（两者都需要支持它）。请参阅维基百科上的HTTP Compression页面，了解其工作原理。

以预处理的形式（某种字节码）传输JavaScript需要在所有浏览器中标准化并实现字节码形式，并且几乎不会带来任何好处。与压缩的，缩小的JavaScript相比，大小差异可能不会很明显（毕竟，您将发送相同数量的信息，因此一个好的压缩算法应该使两者的大小几乎完全相同）。

您还需要先编译JS代码，然后再将其提供给您的Web服务器（一个更多的构建/部署任务），或者即时编译它（CPU浪费），这样就不需要了浏览器上的完整源代码解释器，不限制语言（如果前端不能处理JS源，则不会在前端生成eval /代码）。

Answer 2

HTTP标头永远不会被压缩 - 只有HTTP标头压缩的协议。我认为没有必要，它不像标题是你的100kB +网站的很大一部分。

对于单个HTTP请求，行为取决于服务器配置和客户端。如果客户端没有说它很乐意接受gzip / deflated内容，则服务器将不会压缩。如果客户端确实如此，那么服务器可能选择压缩，具体取决于其配置。 （例如，对于Apache，您需要设置mod_deflate）。

例如，服务器不能压缩JPEG和PNG是完全合理的，因为它们已经被压缩了。服务器也可能不会选择压缩PHP处理程序处理的任何内容，而是希望将其留给处理程序来压缩或不压缩。 （例如，如果处理程序提供PDF，它可以压缩，但如果它提供MP3，则不会。）

简短回答：一切都取决于。

Answer 3

  

......过早优化是万恶之源

（c）you know who

标题应始终作为文本 - 只有正文可以gzip压缩。 Js主体也可以被gzip压缩 - 请参阅网络服务器设置。