清楚搞懂HTTP及HTTPS
提纲
HTTP基本概念
HTTP是什么？描述一下
HTTP（HyperText Transfer Protocol）是超文本传输协议
详细解释“超文本传输协议”？
超文本传输协议可以拆成三个部分：超文本、传输、协议。
协议
HTTP是一个用在计算机世界里的协议。
它使用计算机能够理解的语言，确立了一种计算机之间交流通信的规范（两个以上的参与者——协），以及相关的各种控制和错误处理方式（行为约定和规范——议）。
传输
HTTP协议是一个双向协议，是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。数据虽然在两点之间传输，但允许中间有中转或接力。中间人需要遵从HTTP协议，只要不打扰基本的数据传输，就可以添加任意额外的东西。
超文本
超文本就是超越了普通文本（字符文字、图片、视频、压缩包等）的文本，它是文字、图片、视频等的混合体，最关键是有超链接，能从一个超文本跳转到另一个超文本。
HTML就是最常见的超文本，它本身只是纯文字文件，但内部用很多标签定义了图片、视频等链接。经过浏览器的解释，呈现出一个有文字、有画面的网页。
HTTP传输的内容是超文本。
结论
HTTP是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。
“HTTP 是用于从互联网服务器传输超文本到本地浏览器的协议HTTP” ，这种说法正确吗？
不正确，因为也可以是服务器到服务器，所以采用两点之间的描述更准确。
“HTTP常见的状态码”有哪些？
1xx
1xx类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2xx
2xx类状态码表示服务器成功处理了客户端的请求。
200 OK是最常见的成功状态码，表示一切正常。如果是非HEAD请求，服务器返回的响应头都会有body数据。
202 Accepted表示服务器已经收到请求消息，但尚未进行处理，用于将请求由另一个进程或服务器进行处理，或是对请求进行批处理的情形。
204 No Content也是最常见的状态码，与200 OK基本相同，但响应头没有body数据。
206 Partial Content是应用于HTTP分块下载或断电续传，表示响应返回的body数据并不是资源的全部，而是其中一部分，也是服务器的处理成功状态。
3xx
3xx类代码表示客户端请求的资源发送了变动，需要客户端用新的URL重新发送请求获取资源，也就是重定向。
301 Moved Permanently表示永久重定向，说明请求的资源已经不存在了，需要改用新的URL再次访问。
302 Found表示临时重定向，说明请求的资源还在，但暂时需要用另一个URL来访问。
301和302都会在响应头里使用字段Location，指明后续要跳转的URL，浏览器会自动重定向新的URL。
304 Not Modified不具有跳转含义，表示资源未修改，重定向已存在的缓冲缓冲，也称缓存重定向，用于缓存控制。
4xx
4xx状态码表示客户端发送的报文有误，服务器无法处理，是错误码。
400 Bad Request表示客户端请求的报文有错误，但只是个笼统的错误。
403 Forbidden表示服务器禁止访问资源，并不是客户端的请求出错。
404 Not Found表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
5xx
5xx类状态码表示客户端请求报文正确，但服务器处理时内部发生了错误，属于服务器端的错误码。
500 Internal Server Error与400类似，时格笼统通用的错误码，服务器发生了什么错误，我们并不知道。
501 Not Implemented表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
502 Bad Gateway通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
503 Service Unavailable表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。
HTTP常见字段有哪些？
Host 字段
客户端发送请求时，用来指定服务器的域名。
有了Host字段，就可以将请求发往同一台服务器上的不同网站。
Host: www.A.com
Content-Length 字段
服务器在返回数据时，会有Content-Length字段，表明本次响应的数据长度。
Content-Length: 1000
上图是告诉浏览器，本次服务器响应的数据长度是1000个字节，后面的字节就是下一个响应了。
Connection 字段
Connection字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。
HTTP/1.1版本的默认连接都是持久连接，但为了兼容老版本的HTTP，需要指定Connection首部字段的值为Keep-Alive。
Connection: keep-alive
这样，一个可复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但这不是标准字段。
Content-Type 字段
Content-Type字段用于服务器响应时，告诉客户端，本次数据是什么什么格式。
Content-Type: text/html; charset=utf-8
上面的类型表明，发送的是网页，编码是UTF-8。
客户端请求时，可以使用Accept字段声明自己可以接受哪种数据格式。
Accept: */*
上面的类型声明中，客户端声明自己可以接受任何格式的数据。
Content-Encoding 字段
Content-Encoding字段说明数据的压缩方法，表示服务器返回的数据使用了什么压缩格式。
Content-Encoding: gzip
上面的类型声明表示，服务器返回的数据采用了gzip方式压缩，告知客户端需要用此方法解压。
客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩格式。
Accept-Encoding: gzip, deflate
GET 与 POST
说一下GET和POST的区别？
GET方法
Get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
比如，你打开我的文章，浏览器就会发送 GET请求给服务器，服务器就会返回文章的所有文字及资源。
POST方法
POST方法是反向操作，向URI指定的资源提交数据，数据就放在报文的body里。
URI，统一资源标志符（Uniform Resource Identifier），表示的是web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都由一个URI进行标识的。
URL，统一资源定位符（Uniform Resource Locator）是URI的一个子集。
比如，你在我文章底部，敲入了留言后点击“提交”，浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。
GET与POST对比
- POST更安全（不会作为url的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录和书签中）
- POST发送的数据更大（GET有url长度限制）
- POST能发送更多的数据类型和编码方式（GET只能发送ASCII字符进行url编码）
- GET参数通过URL传递，POST放在Request body中
- GET在浏览器回退时是无害的，而POST会再次提交请求
- POST用于修改和写入数据，GET一般用于搜索排序和筛选之类的操作
- POST比GET慢
GET和POST方法都是安全和幂等的吗？
“安全”“幂等”的概念：
在HTTP协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源。
所谓的“幂等”，意思是多次执行相同的操作，结果都是“相同”的。
很明显，GET方法就是安全且幂等的，因为它是只读操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的的
POST因为是新增或提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以是不幂等的。
HTTP特性
HTTP/1.1的优点有哪些，如何体现？
HTTP最突出的优点是简单、灵活和易于扩展、应用广泛和跨平台。
1. 简单
HTTP基本的报文格式是header + body，头部信息是key-value简单文本形式，易于理解，降低了学习和使用门槛。
2. 灵活和易于扩展
HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
同时HTTP由于是工作在应用层（OSI第七层），则它的下层可以随意变化。
HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层，HTTP/3甚至把TCPP（就是TCP/IP）层换成了UDP的QUIC。
3. 应用广泛和跨平台
HTTP的应用范围非常广泛，从台式机的浏览器到手机上的各种app，同时天然具有跨平台的优越性
HTTP的缺点？
HTTP协议里有优缺点一体的双刃剑，分别是无状态、明文传输，同时还有一大缺点不安全。
1. 无状态
好处
因为服务器不会记忆HTTP的状态，所以不需要额外的资源来记录状态信息。因此减轻了服务器的负担，能够把更多的CPU和内容用来对外提供服务。
坏处
既然服务器没有记忆能力，它在完成有关联性的操作的时候会非常麻烦。
例如，登录 ➡️ 添加购物车 ➡️ 下单 ➡️ 结算 ➡️ 支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，所以每次都要问一遍身份信息。
对于上述的无状态问题，解决方案有很多种，其中比较简单的方式是使用Cookie技术。（还有通过Session保存状态信息 ）
Cookie通过在请求和响应报文中，写入Cookie信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的小贴纸，后续客户端请求服务器时，带上小贴纸，服务器就能认得了。
2. 明文传输
好处
明文意味着，在传输过程中的信息是可方便阅读的。通过浏览器的F12控制台或Wireshark抓包都可以直接肉眼查看，为调试工作带来了极大的便利。
坏处
明文也意味着，HTTP的所有信息都暴露在光天化日之下，在漫长的传输过程中，信息的内容毫无隐私可言，很容易被窃取。
3. 不安全
- 通信使用明文（不加密），内容有可能被窃听*（账号信息泄露）*
- 不验证通信方的身份，有可能遭遇伪装*（访问假的淘宝）*
- 无法证明报文的完整性，内容有可能被篡改*（植入垃圾广告）*
HTTP的安全，可以用HTTPS的方式解决，也就是通过引入SSL/TLS层，使得在安全上达到了极致。
HTTP/1.1的性能如何？
HTTP协议是基于TCP/IP连接的，并且使用请求-应答的通信方式，所以性能的关键体现在这两点：
1. 长连接 / 持久连接 👍
早期HTTP/1.0的性能有一个很大的问题：每发起一个请求，都要新建一次TCP连接（三次握手），而且是串行请求，做了无谓的TCP连接建立和断开，增加了通信开销。
为了解决上述TCP连接问题，HTTP/1.1提出了长连接通信方式，也叫持久连接。这种方式的好处在于减少了TCP连接的重复建立和断开造成的额外开销，减轻了服务器端的负载。
持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
2. 管道网络传输 👍
HTTP/1.1采用了长连接的方式，这使得管道(pipeline)网络传输成为了可能。即，可在同一个TCP连中，客户端可以发起多个请求，只要第一个请求发出去了，不必再等其回来，就可以发第二个请求出去。这样可以减少整体的响应时间。
例如，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里，先发送A请求，然后等待服务器做出响应，收到后，再发送B请求。管道机制则是允许浏览器同时发出A请求和B请求。
然而，服务器还是按照顺序，先响应A请求，完成后再响应B请求。要是前面的响应特别慢，后面就会有许多请求排队等着，这就是队头阻塞。
3. 队头阻塞 👎
“请求 - 应答”的模式加剧了HTTP的性能问题。
因为，当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了。这样会招致客户端一直请求不到数据，也就是队头阻塞。
总结
总之，HTTP/1.1的性能一般般，后续的HTTP/2和HTTP/3就是在优化HTTP的性能。
HTTP 与 HTTPS
HTTP 与 HTTPS 有哪些区别？
- HTTP时超文本传输协议，信息是明文传输，存在安全风险。HTTPS解决了HTTP不安全的问题，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
- HTTP连接建立相对简单，TCP三次握手之后便可以进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才可以进入加密报文传输。
- HTTP的端口号是80；HTTPS的端口号是443。
- HTTPS协议需要向CA(证书权威机构)申请数字证书，来保证服务器的身份是可信的。
HTTP解决了HTTPS的哪些问题？
HTTP由于是明文传输，所以在安全上存在以下三个风险：
窃听风险，比如在通信链路上可以获取通信内容篡改风险，比如强制植入垃圾广告冒充风险，比如冒充淘宝网站
HTTPS在HTTP与TCP层加入了SSL/TLS协议。
可以很好的解决上述的风险：
信息加密：交互信息无法被窃取校验机制：无法篡改通信内容，篡改了就不能正常显示身份证书：证明淘宝是真的淘宝网
可见，只要自身不作“恶”，SSL/TLS协议是能保证通信安全的。
HTTPS是如何解决上面三种风险的？
混合加密的方式实现信息的机密性，解决了被窃听的风险摘要算法的方式实现完整性，它能够为数据生成独一无二的“指纹”，指纹用于校验数据的完整性，解决了被篡改的风险- 将服务器公钥放入
数字证书中，解决了被冒充的风险
混合加密
HTTPS采用非对称加密 + 对称加密的混合加密方式：
- 在通信建立前采用
非对称加密的方式交换会话密钥，后续就不再使用非对称加密 - 在通信过程中，全部使用
对称加密的会话密钥的方式加密明文数据
采用混合加密方式的原因：
对称加密只用一个密钥，运行速度快，密钥必须保密，无法做到安全的密钥交换。常用方法DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES。非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发，私钥保密，解决了密钥交换问题，但速度慢**（接受报文的一方生成公钥和私钥，私钥自己保留，公钥对外公布）**常用方法：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）。
摘要算法（Hash算法）
客户端在发送明文之前，会通过摘要算法算出明文的“指纹”，发送的时候把指纹 + 明文一同加密成密文，发送给客户端。客户端解密后，用相同的摘要算法算出发送过来的明文。通过比较客户端携带的“指纹”和算出来的“指纹”作比较，若“指纹”相同，说明数据是完整的。
常用方法：MD2、MD4、MD5、HAVAL、SHA。
数字证书
背景：客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解决。那么问题来了，如何保证公钥不被冒充，具有信任度呢？
借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由CA颁发）中，只要证书是可信的，公钥就是可信的。
对于数字签名，这里有一篇通俗易懂的好文章！
HTTPS是如何建立的，其间交互了什么？
SSL/TLS协议基本流程：
- 客户端向服务器索要并验证服务器的公钥
- 双方协商生产
会话密钥 - 双方采用会话密钥进行加密通信
前两步叫握手阶段。
SSL/TLS的握手阶段涉及四次通信，如下图：
SSL/TLS协议建立的详细流程：
1. ClientHello
首先，由客户端向服务器发起加密通信请求，也就是ClientHello请求。
在这一步，客户端主要向服务器发送以下信息：
- 客户端支持的
SSL/TLS协议版本，如TLS1.2版本 - 客户端生产的随机数
Client Random，后面用于生产会话密钥 - 客户端支持的
密码套件列表，如RSA加密算法
2. ServerHello
服务器收到客户端请求后，向客户端发出响应，也就是ServerHello。
服务器响应的内容如下：
确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信- 服务器产生的随机数
Server Random，后面用于生产会话密钥 - 确认的
密码套件列表，如RSA加密算法 - 服务器的
数字证书
3. 客户端响应
客户端收到服务器的响应之后，首先通过浏览器或操作系统中的CA公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
- 一个随机数
pre-master key，该随机数会被服务器公钥加密（是握手阶段的第三个随机数） - 加密通信算法改变通知，表示最后的信息都将用
会话密钥加密通信 - 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项的同时，把之前所有内容发生的数据做个摘要，用来供服务端校验
接着就用双方协商的加密算法，各自生成本次通信的会话密钥。
4. 服务器的最后响应
服务器收到客户端的第三个随机数pre-master key之后，通过协商的加密算法，计算出本次通信的会话密钥。然后向客户端发送最后的信息：
- 加密通信算法改变通知，表示随后的信息都将用
会话密钥加密通信 - 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项的同时把之前所有内容发生的数据做个摘要，用来供客户端校验
至此，整个SSL/TLS的握手阶段全部结束
接下来，客户端与服务器进入加密通信，就完全使用普通的HTTP协议，只不过用会话密钥加密内容。
HTTP/1.1、Http/2、HTTP/3演变
与HTTP/1.0相比，HTTP/1.1提升了什么性能？
与HTTP/1.0相比，HTTP/1.1性能上的改进：
- 使用TCP长连接的方式，改善了HTTP/1.0短连接造成的性能开销
- 支持管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发送第二个请求，减少了整体的响应时间
但HTTP/1.1还是有性能瓶颈：
请求/响应头部(Header)未经压缩就发送，首部信息越多，延迟越大。只能压缩Body的部分发送冗长的首部，每次互相发送相同的首部造成的浪费较多- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是
队头阻塞 没有请求优先级控制- 请求只能从客户端开始，
服务器只能被动响应
根据HTTP/1.1的性能瓶颈，HTTP/2做了哪些优化？
HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性是有保障的。
与HTTP/1.1相比，HTTP/2性能上的改进：
1. 头部压缩
HTTP/2会压缩头，如果同时发出多个请求，它们的头是一样的或是相似的，那么协议会帮你消除重复的部分。
这就是所谓的HPack算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，这样就提高了速度。
2. 二级制格式
HTTP/2不再用像HTTP/1.1里的纯文本形式的报文，而是全面采用了二进制格式。
头信息和数据体都是二进制，并且统称为帧(frame)：头信息帧和数据帧。
这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。
3. 数据流
HTTP/2的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的响应。因此，必须要对数据包做标记，指明它属于哪个响应。
每个请求或响应的所有数据包，称为一个数据流(Stream)。
每个数据流标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。
客户端还可以指定数据流的优先级。优先级高的请求，服务器就会先响应。
4. 多路复用
HTTP/2可以在一个连接中，并发多个请求或响应，而不用按顺序意义对应。
移除了HTTP/1.1中的串行请求，不需要排队等待，也就不会出现队头阻塞的问题，降低了延迟，大幅度提高了连接的利用率。
举例来说，在TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就响应A请求已经处理好的部分，接着响应B请求，完成后，再响应A请求剩下的部分。
5. 服务器推送
HTTP/2还在一定程度上改善了传统的 请求 - 应答 工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
举例来说，在浏览器刚请求HTML的时候，就提前把可能会用到的JS、CSS文件等静态资源主动发给客户端，降低延时的等待，也就是服务器推送(Server Push/Cache Push)。
HTTP/2有哪些缺陷，HTTP/3做了哪些优化？
HTTP2主要的问题在于：多个HTTP请求复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中的所有HTTP请求，都必须等待这个丢了的包被重传回来。
也就是说：
- HTTP/1.1中的管道传输中，如果有一个请求阻塞了，那么队列后的请求也统统被阻塞
- HTTP/2多请求服复用一个TCP连接，一旦发生丢包，就会阻塞住所有的HTTP请求
这都是基于TCP传输层的问题，所以HTTP/3把HTTP下层的TCP协议改成了UDP！
UDP发生时不管顺序的，也不管丢包的，所以不会出现上述问题。
但UDP时不可靠传输，而基于UDP的QUIC协议，可以实现类似TCP的可靠性传输。
QUIC有一套自己的机制可以保证传输的可靠性。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响- TLS升级成了最新的
1.3版本 - 头部压缩算法升级为
QPack - HTTPS要建立一个连接，要花费6次交互。先是建立3次握手，然后是TLS/1.3的3次握手。而QUIC直接把以往的TCP和TLS/1.3的6次交互，
合并成了3次，减少了交互次数- 是的，TLS/1.3由TLS/1.2的4次握手变成了3次，详解
因此，QUIC是一个基于UDP的伪TCP + TLS + HTTP/2的多路复用协议。
QUIC是新协议，对于很多网络设备，根本不知道什么是QUIC，只会当作UDP，这样就出现了新的问题。所以HTTP/3现在的普及进度非常缓慢，不知道未来UDP能否逆袭TCP。