在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。
随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，根据 HTTP Archive 的统计，当前平均每个页面都会产生上百个请求。越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。
Hapck原理:
具体规则可以描述为：
通信双方共同维护了一份静态表，包含了常见的头部名称与值的组合
根据先入先出的原则，维护一份可动态添加内容的动态表
用基于该静态哈夫曼码表的哈夫曼编码数据
当要发送一个请求时，会先将其头部和静态表对照，对于完全匹配的键值对，可以直接使用一个数字表示，如method: GET，对于头部名称匹配的键值对，可以将名称使用一个数字传输，同时告诉服务端将它添加到动态表中，以后的相同键值对就用一个数字表示了。这样，像cookie这些不经常变动的值，只用发送一次就好了。
即服务器发送/user.html时，就可以主动把/user.js和style.csspush给浏览器，使资源提前达到浏览器；除了静态文件，还可以推送比较耗时的API，只是需要提前将参数和cookie等信息通过某个方式告知服务端（如和路由关联）。Apache、GO的net/http、node-spdy都实现了server push（但ngnix没有=_=）
Server push是HTTP/2协议里面唯一一个需要开发者自己配置的功能。其他功能都是服务器和浏览器自动实现，无需开发者介入。
在HTTP1.1时代，也有提前获取资源的方法，如preload和prefetch，前者是在页面解析初期就告诉浏览器，这个资源是浏览器马上要用到的，可以立刻发送对资源的请求，当需要用到该资源时就可以直接用而不用等待请求和响应的返回了；后者是当前页面用不到但下一页面可能会用到的资源，优先级较低，只有当浏览器空闲时才会请求prefetch标记的资源。从应用层面上看，preload和server push并没有什么区别，但是server push减少浏览器请求的时间，略优于preload，在一些场景中，可以将两者结合使用。