HTTP协议，全称超文本传输协议(HyperText Transfer Protocol)，是目前互联网上应用最为广泛的一种网络协议，位于应用层。

一、HTTP基础

1.HTTP协议用于客户端和服务端之间的通信

两台计算机之间使用HTTP协议通信时，必有一端是客户端，另外一端是服务器端。其中请求访问资源的一端为客户端，提供资源响应的一端称为服务器端。有时候两台计算机的角色可能会互换，但是仅从一条通信路线来说，客户端和服务器端的角色是确定的。

2.通过请求和响应的交换达成通信

HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。

3.HTTP是不保存状态的协议

HTTP是一种无状态协议。协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。可是随着 Web 的不断发展，我们的很多业务都需要对通信状态进行保存。于是我们引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

4.请求URI定位资源

HTTP协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。

5.告知服务器意图的 HTTP 方法

6.持久链接节省通信量

HTTP协议的初始版本中，每进行一个 HTTP 通信都要断开一次 TCP 连接。比如使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。

6.1 持久链接

为了解决上述 TCP 连接的问题，HTTP/1.1 和部分 HTTP/1.0 想出了持久连接的方法。其特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。旨在建立一次 TCP 连接后进行多次请求和响应的交互。在 HTTP/1.1 中，所有的连接默认都是持久连接。它的好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

6.2管线化(pipelining)

持久连接使得多数请求以管线化方式发送成为可能。以前发送请求后需等待并接收到响应，才能发送下一个请求。管线化技术出现后，不用等待亦可发送下一个请求。这样就能做到同时并行发送多个请求，而不需要一个接一个地等待响应了。比如，当请求一个包含多张图片的 HTML 页面时，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术要比持久连接速度更快。请求数越多，时间差就越明显。

7.使用Cookie的状态管理

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

二、HTTP工作流程

2.1 TCP/IP通信传输流

HTTP协议是站在在TCP/IP协议肩膀上的，从HTTP往下看，是TCP协议保证了运输的可靠性，是IP协议保证了数据可以达到目标地址，是以太网协议在局域网内传递信息。所以说HTTP工作流程，先谈TCP/IP通信传输流。

TCP:IP通信传输流.png

利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则从链路层往上走。

• 首先作为发送端的客户端在应用层（HTTP 协议）发出一个想看某个 Web 页面的 HTTP 请求。
• 为了传输方便，在传输层（TCP 协议）把从应用层处收到的数据（HTTP 请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。
• 在网络层（IP 协议），增加作为通信目的地的 MAC 地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全了。
• 接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP请求。

2.2 HTTP请求流程

HTTP请求流程.png

• 发送端在层与层之间传输数据时，每经过一层时必会被打上该层所属的头部信息。
• 接收端在层与层之间传输数据时，每经过一层时会把对应的头部消去。

具体介绍如下：

1. 地址解析
   比如我们用百度搜索swift

http://www.baidu.com/baidu?wd=swift

协议名：http。这里指要发出的是什么协议。
主机名：www.baidu.com。通过DNS解析，我们可以把主机名解析成服务器的IP地址。
请求文件名：baidu。当我们访问到服务器后，就可以通过文件名请求指定的文件。
请求参数：wd=swift。即使同一个网页，可能针对不同的用户，服务器要返回给客户端的信息也是不一样的 。而服务器就是通过URL中“?”后面携带的参数不同来响应不同的用户或者同一个用户的不同请求的。

2. 封装HTTP 请求
   这一步把上面写的 URL 以及本机的一些信息封装成一个 HTTP 请求数据包
3. 封装 TCP 包
   第三步就是封装 TCP 包 , 建立 TCP 连接 , 也就是常说的"三次握手"。
4. 客户端发送请求命令
   在连接建立之后 , 客户端发送 HTTP 请求到服务端与请求相关的信息都会包含在请求头和请求体中发送给服务器端 。
5. 服务器端响应
   服务器端在收到请求之后 , 根据客户端的请求发送给客户端相应的信息 , 相关的响应信息都会放在响应头和响应体中。
6. 关闭连接
   服务器端在发送完响应之后 , 就会关闭连接 , 如果过客户端的请求的头部信息中有 Connection-alive , 那么客户端在响应完这个请求之后不会关闭连接 , 知道客户端的所有请求都响应完毕 , 才会关闭连接 , 这样大大节省了带宽和 IO 资源。

三、HTTP协议报文结构

1.报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文；响应端（服务器端）的叫做响应报文。HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

2.报文结构

HTTP 报文大致可分为报文首部和报文主体两部分。两者由最初出现的空行（CR+LF）来划分。通常，并不一定有报文主体。
报文结构如下：

HTTP报文结构.png

3.请求报文及响应报文的结构

请求报文及响应报文的结构.png

上面是请求报文，下面是响应报文。

请求报文和响应报文实例.png

上面是请求报文实例，下面是响应报文实例。
请求报文和响应报文的首部内容由以下数据组成。

• 请求行：包含用户请求的方法，请求URI和HTTP版本。
• 状态行：包含表明响应结果的状态码，原因短语和HTTP版本。
• 首部字段：包含表示请求和响应的各种条件和属性的各类首部。一般有四种首部，分别是：通用首部、请求首部、响应首部和实体首部。
• 其他：可能包含HTTP的RFC里未定义的首部(Cookie等)。

举个例子：
我们用Chrome浏览器打开百度，然后对当前网页进行检查，右键选择检查。然后刷新当前页面，选择Netword选项，就可以看到当前页面网络活动情况。查看www.baidu.com:

例子.png

General：
Request URL: https://www.baidu.com/
Request Method: GET
Status Code: 200 OK
Remote Address: 180.97.33.108:443
Referrer Policy: no-referrer-when-downgrade

Response Headers：

HTTP/1.1 200 OK
Bdpagetype: 1
Bdqid: 0xa9952ef000020d8a
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Cxy_all: baidu+9cadcdf18d354de5e0816c739f51f361
Date: Tue, 30 Oct 2018 08:50:53 GMT
Expires: Tue, 30 Oct 2018 08:50:27 GMT
Server: BWS/1.1
Set-Cookie: delPer=0; path=/; domain=.baidu.com
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=0; path=/
Set-Cookie: H_PS_PSSID=26524_1420_21093_27400_26350; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

Request Headers:

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,zh-TW;q=0.8
Cookie: BAIDUID=0A51A4710C9C0407204028C7D18379A0:FG=1; BIDUPSID=0A51A4710C9C0407204028C7D18379A0; PSTM=1529891328; BD_UPN=123253; MCITY=-315%3A; ispeed_lsm=3; delPer=0; BD_HOME=0; H_PS_PSSID=26524_1420_21093_27400_26350; BD_CK_SAM=1; PSINO=3

四、HTTP 报文首部字段具体分析

HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务端之间以HTTP协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。比如给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

1. HTTP首部字段结构

HTTP首部字段是由首部字段名和字段值构成，中间用冒号“：”分开。比如上面我们看到的：

Host: www.baidu.com
Connection: keep-alive
Pragma: no-cache

2. 4种HTTP首部字段类型

HTTP首部字段根据实际用途可以分为以下4种：

• 通用首部字段：请求报文和响应报文两方都会使用的 首部。
• 请求首部字段：从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
• 响应首部字段：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
• 实体首部字段：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

3.通用首部字段

3.1 Cache-Control

通过指定首部字段Cache-Control的指令，就能操作缓存的工作机制。
指令的参数是可选的，多个指令之间通过“，”分隔。
缓存请求指令

缓存响应指令

4. 请求首部字段

5. 响应首部字段

5. 实体首部字段

6. 其他首部字段

HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上，会出现各种非标准的首部字段。以下是最为常用的首部字段：

6.1 X-Frame-Options

X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。首部字段 X-Frame-Options 有以下两个可指定的字段值：

• DENY：拒绝
• SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context）匹配时许可

6.2 X-XSS-Protection

X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下:

• 0：将 XSS 过滤设置成无效状态
• 1：将 XSS 过滤设置成有效状态

6.3 DNT

DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下：

• 0：同意被追踪
• 1：拒绝被追踪

6.4 P3P

P3P 属于 HTTP 响应首部，通过利用 P3P（The Platform for Privacy Preferences，在线隐私偏好平台）技术，可以让 Web 网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。要进行 P3P 的设定，需按以下操作步骤进行：

1. 创建 P3P 隐私
2. 创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml
3. 从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中

五、HTTP响应状态吗

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求，还是出现了错误。

1. 状态码类别

2. 状态具体描述

在 RFC2616 中定义了 40 种 HTTP 状态码，webDAV ( Web-based Distributed Authoring and Versioning，基于万维网的分布式创作和版本控制)在 RFC4918 和 RFC5842 中，定义了一些特殊的状态码，在 RFC2518、RFC2817、RFC2295、RFC2774、RFC6585 中还额外定义了一些附加的 HTTP 状态码。总共有 60+ 种。具体链接可以见 HTTP状态码 (wikipedia)。虽然状态种类繁多，但实际上经常使用的大概有14种，我们简单介绍一下这14种。