Http 即超文本传输协议，一种建立在 TCP 上的无状态连接，属于应用层协议，http传输的内容都是明文的，不安全的。Http 协议用于客户端与服务器端之间的通信，它规定了客户端与服务端之间的通信格式，包括请求和响应的格式。
Http的基本的工作流程是这样的：客户端发送一个 Http 请求，服务端收到请求之后开始处理，处理结果返回给客户端，客户端对结果进行处理。目前流行的 Http 版本是 HTTP/1.1。这里也主要结合Http1.1总结下Http协议。
报文是在 Http 应用程序之间发送的数据块，它可以分为请求报文和响应报文，不过它们都是由三部分组成：报文首部、空行、报文主体。
//起始行
POST /tools/mockapi/448/weBankstep HTTP/1.1
// 请求首部
Host: www.wanandroid.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://www.wanandroid.com/tools/mockapi
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: xxx
// 请求体
name=sunnyday&age=18
//起始行
HTTP/1.1 200 OK
//响应首部
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Thu, 01 Jan 1970 08:00:00 CST
Content-Type: application/json;charset=utf-8
Transfer-Encoding: chunked
Date: Fri, 15 Mar 2019 13:30:00 GMT
//响应体
test: {
"good1": "http://a/b/1.png",
"good12": "http://a/b/2.png"
}
在开发中我们平时使用的GET、POST请求方法就是被设置在请求报文的起始行中
如上请求报文模拟用户登录的post请求，上传的键值对被设置到http的请求报文请求体中
其实响应内容可以为很多类型，如图片、视频、html、json 注意上面响应报文Content-Type: application/json;charset=utf-8 说明响应类型为json，json数据编码为utf-8。
| 方法 | 说明 | 支持的http协议版本 |
|---|---|---|
| GET | 获取资源 | 1.0、1.1 |
| POST | 传输请求主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获得报文首部 | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问支持的方法 | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK | 建立和资源之间的联系 | 1.0 |
| UNLINK | 断开连接关系 | 1.0 |
作用：get方法用来请求访问被URI识别的资源。指定的资源经服务端解析后返回响应内容。
例如：get请求的资源为纯文本，服务端就原样返回，如果是向CGI（通用网管接口）那样的程序，则返回经过执行后输出的结果。
注意：get 方法时，请求报文的请求体一般为空。get一般不会发送请求体。
作用：用来传输请求主体，请求的主体可为text、file、media等。
注意：虽然get也可以传输请求主体，但一般不用get进行传输，而是使用post方法，post与get功能很相似，get侧重获取内容，post侧重传输请求主体。
作用：用来传输文件
注意：put要求请求主体中需包含文件内容。但是http1.1的put方法不具备验证机制任何人都可以上传文件，存在安全性问题，一般web网站不使用这个方法。若配合web应用的验证机制或者采用REST标准设计的web网站就可能会开放使用put方法。
作用：用户获取报文首部部分，用户获取URI的有效性、资源更新的日期时间等。
注意：head与get的区别，head不返回报文主体。
作用：客户端通过该方法可以查询发出去的请求是怎样被加工/篡改的。因为当请求目标服务器时可能会通过代理服务器中转，trace方法就是用来确认连接过程中的一系列操作的。
流程：发送请求时请求首部的Max-Forwards字段会填入一个数值，每经过一个服务器该数字就会减一，当数字刚好为0时，就停止继续传输，最后接受到请求的服务器则返回状态码200 OK的响应。
栗子：
//请求
TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2
// 响应
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024
TRACE / HTTP/1.1 //返回响应包含请求内容
Host: hackr.jp //返回响应包含请求内容
Max-Forwards: 2 //返回响应包含请求内容
作用：CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协
议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接
层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容
加 密后经网络隧道传输。
方法使用格式：
CONNECT 代理服务器名:端口号 HTTP版本
// 请求
CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host: proxy.hackr.jp
// 响应
HTTP/1.1 200 OK（之后进入网络隧道）
| 状态码 | 描述 | 解释 |
|---|---|---|
| 200 | 全部资源请求成功 | 从客户端发来的请求在服务器端被正常处理 |
| 204 | 无响应体请求成功 | 服务器接收的请求已成功处理，但在返回的响应报文中无响应体，对应客户端的HEAD请求 |
| 206 | 范围资源请求成功 | 客户端进行了范围请求，服务器成功执行了请求。响应报文中包含由 Content-Range 指定范围的响应体内容。 |
| 301 | 永久重定向 | 请求的资源已经被分为了新的URI，需要使用新的URI进行请求（浏览器重新请求时会把POST改为GET然后进行请求，但301标准是禁止将 POST 方法改变成 GET 方法的，一般大家都不遵守301标准） |
| 302 | 临时重定向 | 请求的资源已被分配了新的 URI，希望用户能使用新的 URI 访问。（浏览器重新请求时会把POST改为GET然后进行请求，但302标准是禁止将 POST 方法改变成 GET 方法的，一般大家也不遵守302标准） |
| 303 | 临时重定向 | 请求的资源已被分配了新的 URI，希望用户能使用新的 URI 访问（303 状态码明确表示客户端应当采用 GET 方法获取资源，浏览器会把POST 改成 GET，并删除请求报文内的主体，之后请求会自动再次发送。） |
| 304 | 临时重定向 | 客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系。附带条件的请求是指采用 GET方法的请求报文中包含 If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since 中任一首部。 |
| 307 | 临时重定向 | 请求的资源已被分配了新的 URI，希望用户能使用新的 URI 访问（浏览器收到响应后，重新自动请求，请求时不会POST变为GET，大家都必须遵守307标准。） |
| 400 | 错误请求 | 请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。 |
| 401 | 需要认证 | 发送的请求需要有可通过的 HTTP认证信息 |
| 403 | 拒绝资源访问 | 该状态码表明对请求资源的访问被服务器拒绝了。 |
| 404 | 资源找不到 | 该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。 |
| 500 | 内部服务错误 | 服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。 |
| 404 | 服务器不可用 | 服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入RetryAfter 首部字段再返回给客户端。 |
在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富，HTTP 协议的请求和响应报文中必定包含 HTTP 首部，首部字段同时存在于请求和响应报文内，首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。
首部字段可以分为五类，首部字段可存在报文首部，可存在报文主体中。具体分类如下：
通用首部字段是指，请求报文和响应报文双方都会使用的首部
HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition等在其他 RFC 中定义的首部字段，它们的使用频率也很高。
（1）为 Cookie 服务的首部字段
管理服务器与客户端之间状态的 Cookie，虽然没有被编入标准化HTTP/1.1 的 RFC2616 中，但在 Web 网站方面得到了广泛的应用。
| 首部字段名 | 首部类型 | 说明 |
|---|---|---|
| Set-Cookie | 响应首部字段 | 服务器设置该字段的一些值，开始状态管理所使用的Cookie信息 |
| Cookie | 请求首部字段 | 客户端设置该字段的一些值，之后服务器接收到Cookie信息。 |
| 属性 | 说明 |
|---|---|
| NAME=VALUE | 赋予 Cookie 的名称和其值（必需项） |
| expires=DATE | Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。 |
| path=PATH | 将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录） |
| domain=域名 | 作为 Cookie 适用对象的域名 （若不指定则默认为创建 Cookie的服务器的域名） |
| Secure | Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。当省略 secure 属性时，不论 HTTP 还是 HTTPS，都会对 Cookie 进行回收。 |
| HttpOnly | Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对Cookie 的信息窃取。 |
Set-Cookie: name=value; secure
首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个Cookie 时，同样可以以多个 Cookie 形式发送。
Cookie: status=enable
（2）X-Frame-Options
首部字段 X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其他 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。
首部字段 X-Frame-Options 有以下两个可指定的字段值：
（3）X-XSS-Protection
首部字段 X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下：
（4）DNT
首部字段 DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被收集，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下：