HTTP协议之Transfer-Encoding

HTTP协议中的Transfer-Encoding

浏览器和服务器端支持持久连接

持久连接（Persist Connection）
HTTP1.0默认不是持久连接的
HTTP1.1默认是持久连接的
在HTTP请求和响应中加入Connection:KEEP-alive这个告诉对方当前tcp连接时持久连接的，
进行持久连接，可以减少客户端的等待时间，因为不使用持久连接，要尽心TCP的三次握手过程。
如果不想使用TCP的持久连接可以在HTTP头部加入connection：close，来告诉对方当前连接在客户端获取响应后，关闭TCP连接。

transfer-encoding：则是用来改变报文格式。
content-encoding:是HTTP实体内容进行编码，目的是优化传输，例如服务器端用gzip对响应实体尽心压缩，
并不是服务器端所有的信息都需要压缩处理，例如图片，已经是高度压缩过得了，就不用压缩了。压缩会浪费消耗CPU资源。

HTTP持久连接和非持久连接的区别：
①如果是HTTP是持久连接，如果服务器端返回数据没有实体内容的长度即（Content-length）则浏览器一直处于pending状态，
即一直等待状态。如果是非持久连接的话，不会出现这种情况。

这是因为，对于非持久连接，浏览器可以通知连接是否关闭来界定请求或者响应实体的边界；而对于持久连接，
这种方法显然不奏效。需要在响应中加入Content-length告诉浏览器当前响应结束。

由于Content-Length字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没有那么好获得，例如实体
来自于网络文件，或者有动态语言生成。这时候要想获取长度，只能开一个足够打的buffer，等内容全部生成好再
计算。但这样做一方面需要更大的内容开销，另一方面也会让客户端等待更久。

我们在做web性能优化时，有一个重要的指标叫TTFB(TIME TO FIRST Byte)，它代表的是从客户端发出请求到收到响应
的第一个字节所花费的时间。大部分；浏览器自带的network面板都可以看到这个指标，越短的TTFB意味着用户可以
越早看到页面内容，用户体验好。

可想而知，服务器端为了计算响应实体长度而缓存所有内容，跟更短的TTFB理念不一样。
但在HTTP报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，
也能知道实体的边界。

Transfer-Encoding：chunked，利用分块传输

分跨传输相当简单，只需要在HTTP响应头中加入Transfer-Encoding：chunked，就代表这个报文采用了分块编码。

Keep-Alive: timeout=5, max=100（代表当前TCP连接可以保持5秒，这个TCP连接最多接受100个HTTP请求，超过100个就断开）