我很早之前写过一篇关于 HTTP 和 HTTPS 的文章，但对于 HTTPS 介绍还不够详细，只讲了比较基础的部分，所以这次我们再来深入一下 HTTPS，用实战抓包的方式，带大家再来窥探一次 HTTPS
URI, 全称为(Uniform Resource Identifier), 也就是统一资源标识符，它的作用很简单，就是区分互联网上不同的资源。
但是，它并不是我们常说的网址, 网址指的是URL, 实际上URI包含了URN和URL两个部分，由于 URL 过于普及，就默认将 URI 视为 URL 了。
URI 真正最完整的结构是这样的
可能你会有疑问，好像跟平时见到的不太一样啊！先别急，我们来一一拆解。
scheme 表示协议名，比如http, https, file等等。后面必须和://连在一起。
user:passwd@ 表示登录主机时的用户信息，不过很不安全，不推荐使用，也不常用。
host:port 表示主机名和端口。
path 表示请求路径，标记资源所在位置。
query 表示查询参数，为key=val这种形式，多个键值对之间用&隔开。
fragment 表示 URI 所定位的资源内的一个锚点，浏览器可以根据这个锚点跳转到对应的位置。
https://www.yuque.com/kenguba/upkpls/gisxr2/?word=1&name=kenguba#UrkH4
这个 URI 中
https 即scheme部分www.yuque.com 为host:port部分（注意，http 和 https 的默认端口分别为80、443）kenguba/upkpls/gisxr2 为path部分word=1&name=kenguba 表示query部分#UrkH4 就是锚点
URI 只能使用 ASCII , ASCII 之外的字符是不支持显示的，而且还有一部分符号是界定符，如果不加以处理就会导致解析出错。
因此，URI 引入了编码机制，将所有非 ASCII 码字符和界定符转为十六进制字节值，然后在前面加个%
encodeURI("https://www.yuque.com/kenguba/upkpls/gisxr2?name=一缕清风")
"https://www.yuque.com/kenguba/upkpls/gisxr2?name=%E4%B8%80%E7%BC%95%E6%B8%85%E9%A3%8E"
decodeURI("https://www.yuque.com/kenguba/upkpls/gisxr2?name=%E4%B8%80%E7%BC%95%E6%B8%85%E9%A3%8E")
encodeURIComponent("https://www.yuque.com/kenguba/upkpls/gisxr2?name=一缕清风")
"https://www.yuque.com/kenguba/upkpls/gisxr2?name=%E4%B8%80%E7%BC%95%E6%B8%85%E9%A3%8E"
decodeURIComponent("https://www.yuque.com/kenguba/upkpls/gisxr2?name=%E4%B8%80%E7%BC%95%E6%B8%85%E9%A3%8E")
HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。它可以拆成三个部分：
在生活中，我们也能随处可见「协议」，例如：
生活中的协议，本质上与计算机中的协议是相同的，协议的特点:
协 字，代表的意思是必须有两个以上的参与者。例如三方协议里的参与者有三个：你、公司、学校三个；租房协议里的参与者有两个：你和房东。议 字，代表的意思是对参与者的一种行为约定和规范。例如三方协议里规定试用期期限、毁约金等；租房协议里规定租期期限、每月租金金额、违约如何处理等。针对 HTTP 协议，我们可以这么理解。
HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）
所谓的「传输」，很好理解，就是把一堆东西从 A 点搬到 B 点，或者从 B 点 搬到 A 点。
别轻视了这个简单的动作，它至少包含两项重要的信息。
HTTP 协议是一个双向协议。
我们在上网冲浪时，浏览器是请求方 A ，百度网站就是应答方 B。双方约定用 HTTP 协议来通信，于是浏览器把请求数据发送给网站，网站再把一些数据返回给浏览器，最后由浏览器渲染在屏幕，就可以看到图片、视频了。
数据虽然是在 A 和 B 之间传输，但允许中间有中转或接力。
就好像第一排的同学想穿递纸条给最后一排的同学，那么传递的过程中就需要经过好多个同学（中间人），这样的传输方式就从「A < - > B」，变成了「A <-> N <-> M <-> B」。
而在 HTTP 里，需要中间人遵从 HTTP 协议，只要不打扰基本的数据传输，就可以添加任意额外的东西。
针对传输，我们可以进一步理解了 HTTP。
HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。
HTTP 传输的内容是「超文本」
我们先来理解「文本」，在互联网早期的时候只是简单的字符文字，但现在「文本」的涵义已经可以扩展为图片、视频、压缩包等，在 HTTP 眼里这些都算做「文本」。
再来理解「超文本」，它就是超越了普通文本的文本，它是文字、图片、视频等的混合体最关键有超链接，能从一个超文本跳转到另外一个超文本。
HTML 就是最常见的超文本了，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等的链接，在经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。
OK，经过了对 HTTP 里这三个名词的详细解释，就可以给出比「超文本传输协议」这七个字更准确更有技术含量的答案：
HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」
⚠️注意: HTTP 不是用于从互联网服务器传输超文本到本地浏览器的协议，也可以是服务器到服务器，所以采用两点之间的描述会更准确
灵活可扩展 主要体现在两个方面。
可靠传输 HTTP 基于 TCP/IP，因此把这一特性继承了下来。这属于 TCP 的特性，不具体介绍了。请求-应答 也就是一发一收、有来有回， 当然这个请求方和应答方不单单指客户端和服务器之间，如果某台服务器作为代理来连接后端的服务端，那么这台服务器也会扮演请求方的角色。无状态 所谓的优点和缺点还是要分场景来看的，对于 HTTP 而言，最具争议的地方在于它的无状态。
明文传输 即协议里的报文(主要指的是头部)不使用二进制数据，而是文本形式。这当然对于调试提供了便利，但同时也让 HTTP 的报文信息暴露给了外界，给攻击者也提供了便利。WIFI陷阱就是利用 HTTP 明文传输的缺点，诱导你连上热点，然后疯狂抓你所有的流量，从而拿到你的敏感信息。队头阻塞问题 当 http 开启长连接时，共用一个 TCP 连接，同一时刻只能处理一个请求，那么当前请求耗时过长的情况下，其它的请求只能处于阻塞状态，也就是著名的队头阻塞问题。接下来会有一小节讨论这个问题。对于 TCP 而言，在传输的时候分为两个部分: **TCP头 **和 数据部分。
而 HTTP 类似，也是 header + body 的结构，具体而言:
起始行 + 头部 + 空行 + 实体
由于 http 请求报文和响应报文是有一定区别，因此我们分开介绍
对于请求报文来说，起始行类似下面这样:
GET /home HTTP/1.1
也就是方法 + 路径 + http版本。
对于响应报文来说，起始行一般张这个样:
HTTP/1.1 200 OK
响应报文的起始行也叫做状态行。由 http版本、状态码和原因 三部分组成。
⚠️注意：在起始行中，每两个部分之间用空格隔开，最后一个部分后面应该接一个换行，严格遵循 ABNF 语法规范
展示一下请求头和响应头在报文中的位置:
不管是请求头还是响应头，其中的字段是相当多的，而且牵扯到http非常多的特性，这里就不一一列举的，重点看看这些头部字段的格式：
_
:
很重要，用来区分开头部和实体。
问: 如果说在头部中间故意加一个空行会怎么样？
那么空行后的内容全部被视为实体。
就是具体的数据了，也就是 body 部分。请求报文对应请求体, 响应报文对应响应体。
http/1.1 规定了以下请求方法(注意，都是大写):
首先最直观的是语义上的区别。
而后又有这样一些具体的差别:
Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等
比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源
而POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。
⚠️注意: http协议并未get和post是没有字节限制的，但是服务端和浏览器是可以限制字节大小的
先说明下安全和幂等的概念：
那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。
POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。
查看更加详细请点击 了解常见HTTP状态码
1xx
类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少
200 OK
是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
204 No Content
也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据
206 Partial Content
是应用于 HTTP 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
301 Moved Permanently
表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
302 Found
表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问
301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
304 Not Modified
不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。
400 Bad Request
表示客户端请求的报文有错误，但只是个笼统的错误。
403 Forbidden
表示服务器禁止访问资源，并不是客户端的请求出错。
404 Not Found
表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
500 Internal Server Error
与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道
501 Not Implemented
表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思
502 Bad Gateway
通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
503 Service Unavailable
表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。
客户端发送请求时，用来指定服务器的域名
Host: www.A.com
有了 Host 字段，就可以将请求发往同一台服务器上的不同网站
服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。
Content-Length: 1000
如上面则是告诉浏览器，本次服务器回应的数据长度是 1000 个字节，后面的字节就属于下一个回应了。
Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为
Keep-Alive
Connection: keep-alive
一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。
Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
Content-Encoding: gzip
上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压
客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法
Accept-Encoding: gzip, deflate
Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式
Content-Type: text/html; charset=utf-8
上面的类型表明，发送的是网页，而且编码是UTF-8。
客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Accept: */*
上面代码中，客户端声明自己可以接受任何格式的数据
对于 Accept 系列字段的介绍分为四个部分:数据格式、压缩方式、支持语言和字符集
HTTP 支持非常多的数据格式，那么这么多格式的数据一起到达客户端，客户端怎么知道它的格式呢？
当然，最低效的方式是直接猜，有没有更好的方式呢？直接指定可以吗？
答案是肯定的
不过首先需要介绍一个标准 —— MIME(Multipurpose Internet Mail Extensions, 多用途互联网邮件扩展)
它首先用在电子邮件系统中，让邮件可以发任意类型的数据，这对于 HTTP 来说也是通用的。
因此，HTTP 从 **MIME type **取了一部分来标记报文 body 部分的数据类型，这些类型体现在Content-Type这个字段，当然这是针对于发送端而言，接收端想要收到特定类型的数据，也可以用Accept字段。
具体而言，这两个字段的取值可以分为下面几类: