HTTP：压缩传输、分块传输

1. 本文重点

什么是压缩传输？

（如何开启Tomcat、Weblogic的压缩传输功能）

什么是分块传输？

（迅雷的断点续传？）

2. 压缩传输

目的很单纯

就是要通过压缩手段

减小响应尺寸、节省带宽、提高速度

2.1 HTTP协议如何发挥作用？

客户端与服务端之间通过

Accept-Encoding与Content-Encoding

合作完成

Accept-Encoding:请求头部；

用于告知服务器，浏览器支持的压缩方式，供服务器选择；

例：Accept-Encoding:gzip, deflate, br

Content-Encoding:响应头部；

用于告知浏览器，传输数据的压缩方式，以便浏览器解压；

例：Content-Encoding:gzip

2.2 如何开启Tomcat压缩功能？

例：配置Server.xml，开启Tomcat压缩

例：开启压缩后，验证运行情况

2.3 如何开启Weblogic压缩功能？

例：配置域的“Web应用程序”，开启GZIP；

注：Weblogic从12c开始，才增加了对GZIP压缩的支持....

3. 分块传输

跟“迅雷断点续传”没啥关系

它只是一种数据传输机制

用于界定报文从哪开始、到哪结束用的

3.1通常如何判定[报文边界]？

浏览器通常用响应头中Content-Length字段描述的长度信息，从报文中截取数据；

例：浏览器请求jquery-3.3.1.js(271,751字节)

注：Content-Length必须与报文实体主体长度匹配；

若Content-Length < 报文实体主体，报文会被截断；

若Content-Length > 报文实体主体，浏览器会认为响应未接受完，连接会处于挂起状态；

例：Content-Length > 报文实体主体长度，浏览器表现；

这个策略没什么不妥，只是需要服务端提前计算好响应报文长度（Content-Length）。但某些场景（比如GZIP压缩），提前计算最终报文尺寸，费时费力，于是就有了分块传输编码。

3.2 新方法：分块传输编码

Transfer-Encoding: chunked

分块传输编码（Chunked transfer encoding）是一种数据传输机制，允许服务端在不预先给出报文长度的情况下，分块将输出发送给客户端。

注1：服务端开启压缩后，通常会采用分块传输方式。

注2：Content-Length与Transfer-Encoding不能同时出现在响应中。

例：Content-Length与Transfer-Encoding同时出现，客户端报错；

参考：

《图解HTTP》

《HTTP权威指南》

http://tomcat.apache.org/tomcat-8.0-doc/config/http.html

https://docs.oracle.com/cd/E72987_01/wls/WLACH/taskhelp/web_applications/ConfigureGZIPCompression.html

走过路过不要错过

赶紧关注一下

QQ用户：

微信用户：

长按下方二维码