HTTP请求：Hyper Text Transfer Protocol的缩写，即超文本传输协议。
一、HTTP协议的结构
HTTP报文由客户机到服务器的请求和从服务器到客户机的相应构成。
1、请求报文的组成：
| 请求行 | 信息头 | 请求头 | 实体头 | 报文主体 |
请求行的格式如下：
Method [分隔符] Request - URL [分隔符] HTTP-Version CRLF
解释说明：
（1）Method 表示完成Request - URL的方法，该字段是大小写敏感的，据RFC2616标准（现行的HTTP/1.1）得知，通常有以下8种方法：
| OPTIONS | 请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项 |
| HEAD | HEAD方法跟GET方法相同，只不过服务器响应时不会返回消息体 |
| PUT | 把消息本体中的消息发送到一个URL,跟POST类似 |
| TRACE | 是用来调用一个远程的请求信息应用程序层的循环后退 |
| CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
| DELETE | 请求服务器删除Request-URI所标识的资源 |
| GET | 由客户端请求服务端获取Request-URI所标识的资源的方法 |
| POST | 由客户端向服务端提交Request-URI所标识的资源后附加新的数据 |
（2）[分隔符]为空格
（3）Request - URL： 遵循URL格式，此字段为星号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务本身。
（4）HTTP-Version：表示支持的HTTP版本，如HTTP/1.1
（5）CRLF：表示换行回车符
HTTP的头包括通用的信息头、请求头、响应头、实体头4部分，每个头域由一个域名、冒号和值域3部分组成。域名是大小写无关的；域值前可以添加任何数量的空格，每个HTTP请求可以包含多个HTTP头域。
HTTP报文主体则包含了HTTP请求的内容，对于get方法，报文主体为空，对于post方法，报文主体则包含需要发送给服务器的数据。
2、响应报文的组成：
| 状态行 | 信息头 | 响应头 | 实体头 | 报文主体 |
解释说明：
（1）状态行由状态码和原因分析两部分组成，其中，状态码由3位数字组成，表示请求是否被理解或被满足，用来支持自动操作；原因分析是对原文的状态码作简单的描述，用于供用户使用。
3、无论是请求报文还是响应报文，虽然分别由以上五个部分组成，但是在一定情况下有些并不是必须要的，但是对于：General-header(通用头部)、请求头（客户端->服务器[Request Header])、响应头(服务端->客户端[Response Header]) 这三部分是必须要有的。于是我那一个实例来对这三部分的内容进行说明记录：
（1）General-header(通用头部)
1 Request URL: http://115.148.141.110:8980/v1/purchase/list # 请求的URL地址（包含请求类型、请求域名、请求端口、请求地址）
2 Request Method: POST # 请求方式
3 Status Code: 200 OK # 响应的状态码、结果
4 Remote Address: 127.0.0.1:8899 # 请求的远程地址
5 Referrer Policy: no-referrer-when-downgrade # referrer策略（五种方法）
（2）请求头（客户端->服务器[Request Header]) --以下数据是通过fidder抓取所得（关于Fidder基本说明的去这里：https://www.cnblogs.com/Zhan-W/p/9813218.html）。
1 POST /v1/purchase/list HTTP/1.1 # 请求方式、请求地址、请求所使用的协议和版本 2 Host: 115.157.151.673:8180 # 目标主机地址和端口号 3 Connection: keep-alive # 维护客户端和服务端的连接关系 4 Content-Length: 68 # 描述HTTP消息实体的传输长度 5 Accept: application/json, text/javascript, */*; q=0.01 #发送端（客户端）希望接受的数据类型、q 是权重系数，范围 0 =< q <= 1，q 值越大，请求越倾向于获得其“;”之前的类型表示的内容 6 Origin: http://apptest.zhidianlife.com:8007 # 浏览器在referrer字段中只显示源网站的源地址（即协议、域名、端口），而不包括完整的路径 7 Authorization: c81e7286507f4aa4b6179f4c381b4c64 # 请求所需的认证信息 8 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36 # 客户端版本号的名字 9 Content-Type: application/json # 请求实体，文档类型 10 Referer: http://apptest.zhidianlife.com:8007/procurement/order?_t=756512&_winid=w9290 # 从来于哪里 11 Accept-Encoding: gzip, deflate # 客户端接收编码类型，一些网络压缩格式： gzip, deflate 12 Accept-Language: zh-CN,zh;q=0.9 # 客户端接收的语言类型 、中文
（3）响应头(服务端->客户端[Response Header])
1 HTTP/1.1 200 OK # 请求协议以及本版、请求状态码
2 Date: Tue, 02 Jul 2019 14:07:31 GMT # 服务端响应客户端的内容过期时间
3 Content-Type: application/json; charset=utf-8 # 服务端发送的类型及采用的编码方式
4 Server: Kestrel # WEB 服务器 服务端的Web服务端名
5 Vary: Origin # WEB服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应所返回的对象响应后续的请求
6 Access-Control-Allow-Credentials: true # 允许运行客户端携带证书式访问
7 Access-Control-Allow-Origin: http://apptest.zhidianlife.com:8007
8 Content-Length: 33310 # 允许指定的域名、地址访问
其中涉及到前端页面性能问题的字段主要有以下：Accept-Encoding、Connection、Date
3、GET与POST请求过程
POST请求的过程：
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送post请求头（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回100 Continue响应
- 浏览器发送数据
- 服务器返回200 OK响应
GET请求的过程：
- 浏览器请求tcp连接（第一次握手）
- 服务器答应进行tcp连接（第二次握手）
- 浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，所以http会在此时进行第一次数据发送）
- 服务器返回200OK响应
4、HTTP状态码的分类
| 分类 | 分类描述 |
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
-----时间不够了，明天还要上班，还在公司加班，写的粗糙，有什么不对的以及可以完善的希望各位大神留言---