从 输入网址(URL)到页面展示的过程
从输入网址到页面呈现这个过程大致可分为以下这几个部分：
- 网络通信
- 页面渲染
1.网络通信
1.1输入网址
当我们在浏览器的地址栏输入网址例如(https://www.zhihu.com/)，https://代表使用的传输协议，www.zhihu.com代表服务器地址，zhihu.com代表域名。一个完整的URL包括协议、服务器地址(主机)、端口、路径
https://www.zhihu.com/
1.2 域名解析
域名解析的过程实际上是通过域名找到与之对应的服务器ip 的过程。
-
1.先从浏览器缓存里找IP,因为浏览器会缓存DNS记录一段时间
-
2.如没找到,再从本地Hosts文件查找是否有该域名和对应IP
-
3.如没找到,再从路由器缓存找
-
4.如没好到,再从本地DNS缓存查找
-
5.如果都没找到,浏览器域名服务器向根域名服务器(zhihu.com)查找域名对应IP,还没找到就把请求转发到下一级,直到找到IP
DNS域名解析过程
域名解析过程注意
- 主机向本地域名服务器查询采用递归查询
- 本地域名服务器向根域名服务器的查询采用的是迭代查询。
DNS域名解析过程
1.2 数据传输
1.2.1应用层 客户端发送HTTP请求报文
应用层 客户端发送HTTP请求报文
HTTP报文包括：
报文首部 （请求行+各种首部字段+其他）
空行
报文主体 （应被发送的数据）通常并不一定要有报文主体
下面对百度首页请求报文首部进行分析：
请求行
请求方法GET 请求URI / HTTP协议版本 1.1
GET / HTTP/1.1
首部字段
请求资源所在服务器
Host: www.baidu.com
连接方式：持久连接 HTTP/1.1之前版本默认非持久连接Connection: keep-alive
报文指令：要求所有中间服务器不返回缓存资源
Pragma: no-cache
控制缓存的行为：缓存前必须先确认其有效性，防止从缓存中返回过期的资源
Cache-Control: no-cache
用户代理可处理的媒体类型
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 q表示权重从而区分优先级
http客户端浏览器信息
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
可接受的内容编码类型
Accept-Encoding: gzip, deflate, sdch
可接受的语言
Accept-Language: zh-CN,zh;q=0.8
相关信息或标记
Cookie: BAIDUID=3C67AA3EF6B3347D3AA986CE489268C4:FG=1; BIDUPSID=3C67AA3EF6B3347D3AA986CE489268C4;
传输层 确保传输报文可靠性的TCP协议
位于传输层的TCP协议为传输报文提供可靠的字节流服务。为了方便传输，将大块的数据分割成以报文段为单位的数据包进行管理，并为它们编号，方便服务器接收时能准确地还原报文信息。TCP协议通过“三次握手”等方法保证传输的安全可靠。“三次握手”的过程是，发送端先发送一个带有SYN（synchronize）标志的数据包给接收端，在一定的延迟时间内等待接收的回复。接收端收到数据包后，传回一个带有SYN/ACK标志的数据包以示传达确认信息。接收方收到后再发送一个带有ACK标志的数据包给接收端以示握手成功。在这个过程中，如果发送端在规定延迟时间内没有收到回复则默认接收方没有收到请求，而再次发送，直到收到回复为止。详细过程如下图!
三次握手
网络层 负责传输的IP协议
IP协议的作用是把TCP分割好的各种数据包传送给接收方。而要保证确实能传到接收方还需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一对应的关系，一个网络设备的IP地址可以更换，但是MAC地址一般是固定不变的。ARP协议可以将IP地址解析成对应的MAC地址。当通信的双方不在同一个局域网时，需要多次中转才能到达最终的目标，在中转的过程中需要通过下一个中转站的MAC地址来搜索下一个中转目标。具体过程如下图：
IP协议
链路层 传输数据的硬件部分
在网络层找到对方的MAC地址后，就将数据发送到数据链路层传输。至此请求报文已发出，客户端发送请求的阶段结束
服务器接收报文
接收端服务器在链路层接收到数据后，删除该层的首部信息并向网络层传递，网络层将接收的数据向传输层传递，在传输层会将传输的数据按序号从组请求报文并传送给应用层。当数据传输到应用层才能算真正接收到由客户端发送过来的HTTP请求
应用层 服务器发送HTTP响应报文
下面对百度首页响应报文首部进行分析：
状态行
协议版本 状态码 状态码原因短语
HTTP/1.1 200 OK
首部字段
当前服务器上安装的HTTP服务器程序信息
bfe:Baidu Front End。百度人自己写的反向代理及防攻击接入层
Server: bfe/1.0.8.18
响应日期时间
Date: Thu, 08 Dec 2016 14:48:19 GMT
说明报文实体的媒体类型
Content-Type: text/html; charset=utf-8
传输编码方式：分块编码
Transfer-Encoding: chunked
链接方式：持久链接 http/1.1之后这个已经没必要了
Connection: keep-alive
只接受对持相同自然语言的请求返回缓存
Vary: Accept-Encoding
缓存控制：仅向特定用户返回响应
Cache-Control: private
Cxy_all: baidu+43a6e396a3ed26dc7d1de13c6af79e49
缓存过期时间
Expires: Thu, 08 Dec 2016 14:47:38 GMT
X-Powered-By: HPHP
X-UA-Compatible: IE=Edge,chrome=1
Strict-Transport-Security: max-age=172800
BDPAGETYPE: 1
BDQID: 0xc9d964a600018bb8
BDUSERID: 0
设置cookie
Set-Cookie: H_PS_PSSID=1451_21116_17001_21408_21417_21554_20929; path=/;
响应报文的传输方式与请求报文相同，简单点说就是原路返回在响应报文中我们通过Chrome DevTool的Network面板可以看到输入的www.baidu.com会被重定向到https://www.baidu.com/,点击重定向后的www.baidu.com,在右边的Response面板中可以看到客户端接收到的报文实体即返回的HTML页面代码
网络通信流程图
网络通信流程图
在网络通信阶段对前端优化建议：
减少HTTP请求数合并资源，如合并 JavaScript 文件、CSS 文件，利用 CSS Sprite 合并图片等
内联图片,data url节省了HTTP请求,但是如果这个图像在网页多个地方显示会加大网页的内容，延长下载时间。
域名提前解析，在页面中不同域名的链接需指定预取域名：<link rel="dns-prefetch" href="http://this-is-a.com">
，IE9+支持
避免重定向（重定向会增加http请求的次数）
cookie优化，cookie越多会导致请求头越大
启用GZIP压缩（Accept-Encoding：g-zip）
使用 CDN加速，减小服务器压力
合理利用HTTP缓存，通过设置Expires
名词术语：
DNS（Domain Name System，域名系统）:因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。
CDN的全称是Content Delivery Network，即[内容分发网络]其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。
