浏览器工作原理之HTTP协议

浏览器要做的事情, 就是把一个URL变成一个屏幕上可以显示的网页

大体流程是这样的:

1. 浏览器首先使用HTTP协议或者HTTPS协议, 向服务端请求页面.
2. 把请求回来的HTML代码经过解析, 构建成DOM树
3. 计算DOM树上的CSS属性
4. 最后根据CSS属性对元素进行渲染, 得到内存中的位图
5. 对位图进行合成, 这会极大地增加后续的绘制速度
6. 合成之后, 在绘制到界面上

我们从HTTP请求回来开始, 这个过程并不是想象中的做完上一步, 在做下一步, 而是一条流水线. 从HTTP请求回来, 就产生了流式的数据, 后续的构建DOM树, 计算CSS, 渲染(得到内存中的位图), 合成, 绘制, 都是尽可能的流式的处理上一步的产出, 也就是说, 不用等上一个步骤完全结束, 就开始处理上一步的输出, 这样我们浏览网页时, 才会看到逐步出现的页面.

先介绍下网络通讯的部分:

HTTP协议

浏览器首先要做的就是, 根据URL把数据取回来, 取回数据使用的是HTTP协议, 这个过程要经过DNS查询.

HTTP协议是基于TCP协议出现的, 对HTTP协议来说, TCP协议是一条双向的通讯通道, HTTP协议在TCP协议的基础上, 规定了Request-Response的模式. 这个模式决定了通讯一定是由浏览器首先发起的.

大部分情况下, 浏览器的实现者只需要用一个TCP库, 甚至一个现成的HTTP库就可以完成浏览器的网络通讯部分. HTTP(超文本传输协议)是纯粹的文本协议, 它是规定了使用TCP协议来传输文本格式的一个应用层协议. 在TCP通道中传输的, 完全是文本.

HTTP协议格式

请求:

GET / HTTP/1.1
Host: www.baidu.com

account=521365120&password=123456

响应:

HTTP/1.1 404 Not Found
Data: Fri, 25 jan 2019 12:23:12 GMT
Content-Type: text/html
Content-Length: 170
Connection: keep-alive
Location: https://www.baidu.com


  ...
  ...

请求部分

在请求部分, 第一行为请求行, 它分为三个部分, 请求方法, 请求的路径和请求的协议和版本.

在请求行之后, 紧跟着的若干行是请求头, 请求头中的每行由key/value键值对组成

在请求头之后, 以一个空行为分隔, 是请求体. 请求体可能包含文件或者表单数据.

简单看下, 请求的路径完全由服务端来定义, 没有什么特别内容

请求方法:

介绍一下请求行中的method(请求方法), 它表示我们此次HTTP请求希望执行的操作类型. 方法有以下几种定义:

• GET
• POST
• HEAD
• PUT
• DELETE
• CONNECT
• OPTIONS
• TRACE

浏览器通过地址栏访问页面都是GET方法. 表单提交产生POST方法.

HEAD则是和GET方法类似, 只返回请求头, 多数由javascript发起

PUT和DELETE方法分别表示添加资源和删除资源, 但是实际上这只是语义上的一种约定, 并没有强制约束.

CONNECT现在多用于HTTPS和WebScket.

OPTIONS和TRACE一般多用于调试, 多数线上服务都不支持

请求头

Accept: 浏览器接收的格式
Accept-Encoding: 浏览器接收的编码方式
Accept-Language: 浏览器接受的语言, 用于服务端判断多语言
Cache-Control: 控制缓存的时效性
Connection: 连接方式, 如果是keep-alive, 且服务端支持, 则会复用连接
Host: HTTP访问的域名
if-Modified-Since: 上次访问时的更改时间, 如果服务器认为此时间后自己没有更新, 则会给出304响应.

if-None-Match: 次访问时使用的E-Tag, 通常是页面的信息摘要, 这个比更改时间更准确些

User-Agent: 客户端标识, 因为一些历史原因, 这是一个糟糕的东西, 多数浏览器这个字段都很复杂, 区别十分微妙

Cookie: 客户端存储的cookie字符串

请求体

请求体主要用于提交表单的场景. 实际上, 请求体是比较自由的, 只要浏览器端发送的body是服务端认可的就可以了. 一些常见的body格式如下:

• application/json
• application/x-www-form-urlencoded
• multipart/form-data
• text/xml

我们使用html的form标签提交产生的http请求, 默认会产生application/x-www-form-urlencoded的数据格式, 当有文件上传时, 则会使用multipart/form-data.

响应部分

第一部分是响应行, 由协议和版本, 状态码和状态文本
第二部分是响应头, 由key/value组成
第三部分是空行
第四部分则是响应体, 为html代码

响应状态码和状态文本

• 1xx: 临时回应, 表示客户端请继续

• 2xx: 请求成功

• 3xx: 表示请求的目标有变化, 希望客户端进一步处理.

  • 301/302: 永久性/临时性跳转
  • 304: 客户端缓存没有更新

• 4xx: 客户端请求错误

  • 403: 无权限
  • 404: 请求的页面不存在
  • 418: it's a teapot, 来自一个愚人节玩笑

• 5xx:服务端错误

  • 500: 服务端错误
  • 503: 服务端暂时性错误, 可以一会再试

对前端来说, 1xx系列的状态码是非常陌生的, 原因是1xx的状态直接被浏览器的http库直接处理掉了, 不会让上层应用知晓.

2xx系列的状态最熟悉的就是200, 这通常是网页请求成功的标志, 也是我最喜欢的状态码

3xx系列比较复杂, 301实际上更接近于一种报错, 提示客户端下次你可别来了, 304又是一个很重要的状态码, 产生这个状态的前提是: 客户端本地已经有缓存的版本, 并且在请求头中告诉了服务端, 当服务端通过时间或者tag, 发现没有更新的时候, 就会返回一个不含body的304状态码.

响应头

Catch-Control: 缓存控制, 用于通知各级缓存的保存时间, 例如max-age=0, 表示不要缓存

Connection: 连接类型, Keep-Alive表示复用连接
Content-length: 内容的长度, 有利于浏览器判断是否已结束
Content-Encoding: 内容编码方式, 通常是gzip
Content-type: 内容类型, 请求的网页则为text/html
Data 当前的服务器日期
ETag 页面的信息摘要, 用于判断是否需要重新到服务器取回页面
Expires: 过期时间, 用于判断下次请求是否需要到服务端取回页面
Keep-Alive: 保持连接不断时需要的一些信息, 如timeout=5, max=100

Last-Modified: 页面上次修改的时间
Server: 服务端软件的类型
Set-Cookie: 设置cookie, 可以存在多个
Via: 服务端的请求链路, 对一些调试场景是很重要的一个响应头

HTTPS

HTTPS基本保持了HTTP的设计思想, 它主要有两个作用, 一是确定请求的目标服务器的身份, 从而保证传输的数据不被网络中间节点窃听或者篡改.

HTTPS是使用加密通道来传输HTTP的内容, 但是HTTPS首先与服务端建立一条TLS加密通道. TLS构建于TCP协议之上, 它实际上是对传输内容做了加密, 所以从传输内容上来看, HTTPS和HTTP没有任何区别.

HTTP2

HTTP2是HTTP1.1的升级版本, 它最大的改进有两点, 一是支持服务端推送, 二是支持TCP连接复用.

服务端推送能够在客户端发送第一个请求到服务端时, 提前把一部分内容推送给客户端, 放入缓存当中, 这可以避免由客户端请求顺序带来的并行度不高, 从而导致的性能问题.

TCP连接复用, 则使用同一个TCP连接来传输多个HTTP请求, 避免了TCP连接建立时的三次握手开销, 和初建立TCP连接时传输窗口小的问题.

其实很多优化涉及更下层的协议, IP层的分包情况等, 和物理层的建连时间等都是需要被考虑的.

未完待续...