文章目录
参考书籍：《图解HTTP》
参考博客：http://www.ruanyifeng.com/blog/2016/08/http.html
本文内容主要基于 HTTP/1.1 版本。
一、TCP/IP 协议族
为了使世界上的计算机可以通过网络互相通信，就需要在不同的硬件、软件、操作系统之间制定一种通信规则，这种规则就称为协议（protocol）。
为了实现全球互联网通信，IETF（The Internet Engineering Task Force，国际互联网工程任务组） 对相关的所有硬件和软件制定了一系列标准协议，集合起来总称为「TCP/IP 协议族」，简称「TCP/IP」。
1、分层模型
TCP/IP 四层模型和 OSI 七层模型对比：
2、数据处理流程
数据在层与层之间传输，发送端每到一层都会对附加一个首部信息，接收端每到一层就会删除一个对应首部，最终拆包出原始数据。
TCP/IP 四层协议处理数据流程：
OSI 七层协议处理数据流程：
3、HTTP 和 IP、TCP、DNS
在 TCP/IP 协议族中，与 HTTP 关系最密切的三个协议就是 IP、TCP、DNS。
IP 协议：
Internet Protocol网际协议，位于网络层。- 作用是把各种数据包传送给对方。
- 为保证把数据传送到对方，要满足两个重要的条件：IP地址和 MAC地址。
- IP地址指明节点被分配到的地址，MAC地址是网卡所属的固定地址，二者配对。
- IP地址可变换，但MAC地址基本不变。
TCP 协议：
- 位于传输层，提供可靠的字节流服务，确保可靠性
- 三次握手确保数据能到达目标
DNS 服务：
Domain Name System，负责域名解析，位于应用层，把域名解析成IP地址
二、HTTP 协议结构
- 客户端： 请求访问文本或图像等资源的一方
- 服务器端：提供资源响应的一方
HTTP：（Hyper Text Transfer Protocol）client 和 server 之间传输数据的超文本传输协议。
每个 HTTP 请求和响应都遵循相同的格式，一个 HTTP 包含 Header 和 Body 两部分，其中 Body 是可选的。
1、HTTP 请求报文
HTTP GET 请求格式：
GET /path HTTP/1.1
Header1: Value1
Header2: Value2
Header3: Value3
HTTP POST 请求格式：
POST /path HTTP/1.1
Header1: Value1
Header2: Value2
Header3: Value3
body data goes here...
- 每个 Header 占用一行。
- 当遇到空行，即连续两个换行符
\r\n时，Header 部分结束，后面的数据全部是 Body。 - 当请求网站首页时，URI 为
/
URI 和 URL
- URI：统一资源标识符，用字符串标识某一互联网资源
- URL：统一资源定位符，表示资源的地点（互联网上所处的位置），是URI的子集
URI 的格式：
- 登录信息：可选
- 服务器端口号：当使用默认端口 80 时，可选
- 查询字符串：查询指定文件路径时的参数，可选
- 片段标识符：标记出已获取资源中的子资源（文档内的某个位置），可选
2、HTTP 响应格式
HTTP/1.1 200 OK
Header1: Value1
Header2: Value2
Header3: Value3
body data goes here...
HTTP 响应如果包含 body，也是通过 \r\n\r\n 来分隔的。
2.1 响应码
| 响应码 | 说明信息 | 常用响应码 | 响应码说明 |
|---|---|---|---|
| 1xx | 指示信息， 表示请求已接收，继续处理 |
100 101 |
继续 切换协议 |
| 2xx | 成功， 表示请求已被成功接收、理解 |
200 OK201 |
客户端请求成功 已创建 |
| 3xx | 重定向， 要完成请求必须有更进一步的操作 |
301 |
资源（网页等）被永久转移到其它URL |
| 4xx | 客户端错误， 请求有语法错误或请求无法实现 |
400 Bad Request401 Unauthorized403 Forbidden404 Not Found |
请求有语法错误，不能被服务器所理解 请求未经授权 服务器收到请求，但是拒绝提供服务 请求资源不存在 |
| 5xx | 服务器端错误， 服务器未能实现合法的请求 |
500 Internal Server Error503 Server Unavailable |
服务器发生不可预期的错误 服务器当前不能处理请求，过后可恢复正常 |
2.2 Content-Type 和 Content-Encoding
- Body 的数据类型由
Content-Type头来确定，而不是 URL-
即使 URL 是
http://www.baidu.com/meimei.jpg，也不一定就是图片。 -
Content-Type:text/html;charset=utf-8：响应内容是网页，编码是UTF-8 -
Content-Type:image/png：响应内容是图片
-
Content-Encoding: gzip：说明 Body 数据是被压缩的，压缩方式是 gzip- 要先将数据解压缩，才能得到真正的数据
- 压缩的目的在于减少Body的大小，加快网络传输
3、查看 HTTP 报文
我们可以通过很多工具来查看 client 和 server 之间的报文传输情况，也就是常说的 「抓包」。
这里以 Chrome 浏览器为例进行简单的抓包说明：
-
在 Chrome 地址栏输入
www.sina.com，浏览器将显示新浪首页 -
通过
Chrome - F12 - Network查看 client 和 server 之间的通信过程 -
点击
Name为www.sina.com的记录，查看右侧的Request和Response的view source内容。
Chrome F12 说明：
Elements： 网页结构Console：控制台输出信息Source：资源文件Network：浏览器和服务器的所有通信记录Headers：显示请求头、请求体和响应头信息view source：显示浏览器和服务器之间的原始/实际通信内容
Response：显示响应体内容
4、HTTP 请求流程
还是以访问新浪首页为例，总结一下 HTTP 请求的流程：
- 1、 client 向 server 发送 HTTP 请求
- 请求包括：方法，URI，域名，其它 headers，使用
POST方法时还包括 Body
- 请求包括：方法，URI，域名，其它 headers，使用
- 2、 server 向 client 返回 HTTP 响应
- 响应包括：响应码，响应类型，其它 headers，响应 Body
- 3、 若 client 还要向 server 请求其它资源（如图片），则再次发送 HTTP 请求，重复步骤 1、2。
浏览器解析过程：
- 当浏览器读取到新浪首页的 HTML 源码后，它会解析 HTML 并显示页面，
- 然后，根据 HTML 里面的各种链接，再发送 HTTP 请求给新浪服务器，拿到相应的图片、视频、Flash、JavaScript脚本、CSS等各种资源，
- 最终显示出一个完整的页面，所以我们在 Network 下面能看到很多额外的 HTTP 请求。
HTTP 协议具备极强的扩展性，虽然浏览器请求的是新浪首页 http://www.sina.com，但是新浪可以在响应的 HTML 中链入其他服务器的资源，比如<img src="https://n.sinaimg.cn/index/mid_article/images/ask.png">，从而将请求压力分散到各个服务器上。
并且一个站点可以链接到其他站点，无数个站点互相链接起来，就形成了 WWW（World Wide Web） 。
三、HTTP 版本发展
| 公布年份 | HTTP版本 | 说明 | 特点 |
|---|---|---|---|
| 1990年 | HTTP/0.9 | 非正式标准 | 只有简单的 GET 方法，响应只能是 HTML |
| 1996年 | HTTP/1.0 | 开始作为正式标准，记载于 RFC1945，被广泛应用 | 支持 GET、POST、HEAD方法 响应更丰富，增加头信息等 短连接 |
| 1997年 | HTTP/1.1 | 目前主流的版本，RFC2616 是当前最新修订版 | 默认是长连接，引入管道机制 使用 chunked 分块传输 |
| 2015年 | HTTP/2 | 谷歌自行研发的 SPDY 协议合并而来 |
低延时传输，优化了二进制协议，多路复用，头信息压缩等等 |
| 2018年 | HTTP/3 | 谷歌开发 QUIC 协议合并而来 |
基于 UDP，响应更快 |
1、HTTP 1.0
主要缺点：
- 短连接，一个连接只能有一个请求，即每次请求都会重新建立一个 TCP 连接
- TCP 建立连接需要三次握手，加上慢启动的特性，这将是很耗资源和性能的一步
解决办法：
- 部分
HTTP 1.0的实现版本，在请求头中添加了一个Connection:keep-alive标记- 该标记要求服务器不要关闭 TCP 连接，以便其他请求复用。服务器同样回应这个字段。
- 直到客户端或服务器主动关闭连接。
但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法，并没有被广泛支持。
2、HTTP 1.1
HTTP 1.1 版本中引入了很多优化技术，这是到目前为止使用最广泛的版本，但是大部分服务器也支持1.0版本。
2.1 持久连接
最大的变化就是引入了持久连接（HTTP persistent connection或HTTP connection reuse）。
特点：
- TCP 连接默认不关闭，可以被多个请求复用
- 只要任意一端没有明确提出断开连接，则保持连接状态。
- 建立一次 TCP 连接后，可以进行多次请求和响应交互
- 减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻服务器负载，使 web 页面显示速度更快。
目前，对于同一个域名，大多数浏览器允许同时建立 6 个持久连接。
2.2 管道机制
在持久连接的基础上还引入了管道机制（pipelining）。
特点：
- 在同一个 TCP 连接里面，客户端可以同时并行发送多个请求，而不用等待前面请求的响应，进一步提升效率。
- 之前版本中，发送一个请求后要等待并收到响应，才能发送下一个。
2.3 Content-Length 字段
在管道机制中，一个 TCP 连接同时发送多个请求，服务器依次处理并返回响应。
- 为了准确区分响应数据包是属于哪一个请求的，在响应头中加入
Content-length字段，声明本次响应的数据长度。- 在 1.0 版中，浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。
如 Content-Length: 3495 表示本次回应的长度是 3495 个字节，后面的字节就属于下一个回应了。
2.4 分块传输编码
使用 Content-Length 字段的前提是，服务器发送回应之前，必须知道回应的数据长度。
对于一些很耗时的动态操作、或者传输大量数据时，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。
更好的处理方法是，产生一块数据，就发送一块，采用"流模式"（stream）取代"缓存模式"（buffer），使浏览器逐步显示页面。
因此，1.1 版本又引入了 “分块传输编码”（chunked transfer encoding）。只要请求或响应的头信息有 Transfer-Encoding 字段，就表明回应将由数量未定的数据块组成。
Transfer-Encoding: chunked
每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了，例如：
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0
2.5 队头堵塞
虽然 1.1 版本允许复用 TCP 连接，但是同一个 TCP 连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。
要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞"（Head-of-line blocking）。
为了避免这个问题，只有两种方法：
- 一是减少请求数
- 二是同时多开持久连接。
对应的，需要做很多网页优化工作，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。
2.6 Cookie 机制
Cookie 技术最早是在 1994 年由 Netscape 公司的一名员工提出的，最终在 2011 年才被 IETF 正式纳入规范中。
HTTP 无状态特点：
-
无状态：
stateless- HTTP 协议自身不对请求和响应之间的通信状态进行保存
- 简单，方便，不保存客户端状态，减少服务器 CPU 及内存消耗
-
缺点：
- 对于要求登录认证的网站，为了使服务器识别登录信息，需要在每次请求报文中附加一些信息，在连接较多时会增加带宽压力。
-
为了在特定场景中实现保持状态的功能，引入了 Cookie 技术来实现状态的管理。
Cookie 机制：
- client 发出请求后，server 返回响应，并在响应报文中加入
Set-Cookie字段，用于通知 client 保存 Cookie。 - client 收到响应后，把
Set-Cookie字段以文本保存在本地 - client 再次向 server 发送请求，并在请求报文中加入
Cookie字段。 - server 收到带 cookie 的请求，比对服务器记录，得到之前的状态信息。
为了进一步优化 HTTP 协议，近几年陆续推出了 HTTP/2 和 HTTP/3，但是目前为止大部分浏览器使用的还是 HTTP/1.1 版本。