分布式架构 网络传输优化
本文主要讲解，浏览器请求过程及网络传输等优化手段
优化之前首先了解其调用过程，如下图：
流程分析
-
通过URL请求到服务器，浏览器就要知道这个url对应的ip是什么？只有知道了ip地址，浏览器才能准备把请求发送到指定服务器的具体ip和端口上去。浏览器的DNS解析器负责把url解析为正确的ip地址，这个解析很花时间，而且这个解析时间段，浏览器不能从服务器那里下载任何东西。浏览器和操作系统提供了DNS解析缓存支持
-
获取IP之后，浏览器会请求与服务器连接，TCP经过3次握手后建立连接通道
-
浏览器真实发送http请求，发送请求报文（请求行：包含请求方法、URI、HTTP版本信息，请求首部字段，请求内容实体，空行）
-
通用首部字段（请求报文与响应报文都会使用的首部字段）
Date：创建报文时间
Connection：连接的管理
Cache-Control：缓存的控制
Transfer-Encoding：报文主体的传输编码方式 -
请求首部字段（请求报文会使用的首部字段）
Host：请求资源所在服务器
Accept：可处理的媒体类型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的内容编码
Accept-Language：可接受的自然语言 -
网络开始传输请求到服务器，这个会包含很多时间，如网络阻塞时间、网络延迟时间、真正传输内容时间等
-
web服务器接收到请求，会根据url上下文转交给相应web应用进行处理
-
web应用会经过很多处理，如 filter、aop前置处理、IOC处理、处理寻找对象和创建，进行业务处理后生成Response对象，熟悉spring对此过程更清晰
-
返回HTTP响应报文（状态行：包含HTTP版本、状态码、状态码的原因短语,响应首部字段,响应内容实体,空行）
-
响应首部字段（响应报文会使用的首部字段）
Accept-Ranges：可接受的字节范围
Location：令客户端重新定向到的URI
Server：HTTP服务器的安装信息 -
实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
Allow：资源可支持的HTTP方法
Content-Type：实体主类的类型
Content-Encoding：实体主体适用的编码方式
Content-Language：实体主体的自然语言
Content-Length：实体主体的的字节数
Content-Range：实体主体的位置范围，一般用于发出部分请求时使用 -
通过网络传输应答内容回到前端浏览器，先返回html代码，不包含图片、外部脚本、css等
-
浏览器解析页面，进行渲染和绘制过程
1.装载和解析html文档，构建DOM，如果在解析过程中发现需要其它资源，如图片，浏览器会发出请求获取资源
2.装载和解析css，构建cssom
3.根据DOM和cssom构建渲染树
4.然后对渲染树节点进行布局处理，确认其屏幕位置
5.渲染好的节点绘制到界面上，渲染引擎不会等到所有html都解析完后才创建布局渲染树，并行处理解析渲染树同时向后端请求资源
重绘：页面渲染到后面发现需要修改前面已经绘制元素的外观，如背景色、文字颜色。需要重绘这个元素
回流：页面渲染到后面发现需要修改前面已经绘制好的元素某些行为，引起页面上某些元素占位面积、定位方式、边距的变化，会引起周围或者整个页面重新渲染
针对以上第三点之后，可以进行特定的网络优化
优化思路：
- 尽量利用浏览器缓存，优化到极致能不传输最好不传
- 尽量减少需要传输的内容数据量
- 尽量最短距离访问，比如使用客户端最近CDN
- 尽量优化网络链路
详细描述
- 使用浏览器本身缓存，尽量减少来回传输数据量
- 精简代码，移除不必要的字符以减少其大小
- 静态文件，如JS/CSS，进行混淆压缩，如jsmin、YUIcompressor、CSScompressor
- 优先考虑使用CSS来代替，其次才是图片裁剪，如果条件允许，选择有损压缩格式，如jpg
针对大图片，尽量进行精简，在图片效果和大小之间仔细斟酌 - 压缩请求传输内容，前后端交互文章中有详细实例说明，使用压缩 如Gzip 后再传输给客户端，客户端接收后由浏览器进行解压，稍微会占取客户端和服务器的CPU，但是会显著提高宽带利用率，特别是纯文本，相当明显
- 减少cookie传递，http规范中描述，每个客户端最多保持300个，每个域名下最多20个，其大小基本保持4K左右，如需传输控制其传输大小
总结
web调用过程分为很多阶段、不同阶段处理方式不同，其过程链路复杂甚长，了解过程后可对其中特定点进行优化，本文主要特定阐述网络传输的优化方式，周期甚短，优化过后效果显著。
作者简介：张程 技术研究
更多文章请关注微信公众号：zachary分解狮 (frankly0423)
