HTTP和HTTPS - 技术栈

1. HTTP

参考HTTP详解(一)：HTTP各版本差异_android app激活和登录-CSDN博客

1.0 HTTP 0.9

只支持GET请求方式：由于不支持其他请求方式，因此客户端没办法向服务端传输太多的信息
没有请求头 概念：所以不能在请求中指定版本号，服务端也只具有返回HTML字符串的能力
服务端相响应之后，立即关闭TCP连接

1.1 HTTP 1.0

请求方式新增了POST，DELETE，PUT，HEADER等方式
默认为短连接 ，即客户端单次请求后就关闭TCP连接；需要Connection：Keep-Alive才可以启用长连接
增添了请求头和响应头的概念，在通信中指定了 HTTP 协议版本号，以及其他的一些元信息 (比如: 状态码、权限、缓存、内容编码)
扩充了传输内容格式，图片、音视频资源、二进制等都可以进行传输
在这个版本主要就是对请求和响应的元信息进行了扩展，客户端和服务端有更多的获取当前请求的所有信息，进而更好更快的处理请求相关内容。

特性

无状态：服务器不跟踪不记录请求过的状态
无连接：浏览器每次请求都需要建立tcp连接

无状态：对于无状态的特性可以借助cookie/session 机制来做身份认证和状态记录

无连接导致的性能缺陷有两种：

无法复用连接：每次发送请求，都需要进行一次tcp连接（即3次握手4次挥手），使得网络的利用率非常低
队头阻塞：HTTP 1.0 规定在前一个请求响应到达之后下一个请求才能发送，如果前一个阻塞，后面的请求也会被阻塞

1.2 HTTP 1.1

默认长连接，一个TCP连接长时间持续有效，可以传送多个HTTP请求和响应
管道化：基于上面长连接的基础，管道化可以不等第一个请求响应继续发送后面的请求，但响应的顺序还是按照请求的顺序返回。虽然管道化，可以一次发送多个请求，但是响应仍是顺序返回，仍然无法解决队头阻塞的问题。
缓存处理：当浏览器请求资源时，先看是否有缓存的资源，如果有缓存，直接取，不会再发请求 ，如果没有缓存，则发送请求，通过设置字段cache-control来控制缓存。
断点续传：在上传/下载资源时，如果资源过大，将其分割为多个部分，分别上传/下载，如果遇到网络故障，可以从已经上传/下载好的地方继续请求，不用从头开始，提高效率。

1.3 HTTP 2.0

二进制传输：HTTP 1.x 的解析是基于文本 ，HTTP 2 之后将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，提高传输效率
多路复用：做到同一个连接并发处理多个请求
头部压缩
服务器推送：服务器可以额外的向客户端推送资源，而无需客户端明确的请求

头部压缩

在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。

HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

存在的缺点

建立连接时间长
队头阻塞问题相较于 HTTP 1.1 更严重：HTTP 2.0中，多个请求是跑在一个TCP管道中的，一旦丢包，TCP就要等待重传（丢失的包等待重新传输确认），从而阻塞该TCP连接中的所有请求

1.4 HTTP 3.0

HTTP/3 采用了谷歌多年探索的基于 UDP 的QUIC协议，原名叫 HTTP-over-QUIC，在 2018 年被 IETF 批准更名为 HTTP/3。目前，Cloudflare、Google Chrome、Firefox Nightly 均表示支持 HTTP/3。

QUIC 是一种通用传输协议，与 TCP 非常相似，除了 HTTP 和网页加载之外，它还可以并且将用于更多场景，例如 DNS、SSH、SMB、RTP 等都可以在 QUIC 上运行。

实现了类似TCP 的流量控制，传输可靠性的功能。
实现了快速握手功能（QUIC基于UDP，UDP是面向无连接的，不需要握手和挥手，比TCP快）
集成了TLS加密功能
多路复用，解决队头阻塞问题（单个"流"是有序的，可能会因为丢包而阻塞，但是其他流不会受到影响）

1.5 QUIC

2. HTTPS：加密；数字证书；消息认证码；443端口；性能略慢

参考细说Http 和 Https的区别（图文详解）-CSDN博客

HTTP（Hypertext Transfer Protocol），是一种发送和接收HTML页面的方法，主要用于Web浏览器和网站服务器之间传递信息。它的主要特点如下：

基于请求响应模式： HTTP协议采用客户端-服务器架构模式，客户端向服务器发送请求，服务器返回相应的响应。这种模式能有效分离应用逻辑，提高系统的可维护性和扩展性。
基于文本传输： HTTP协议使用ASCII码作为通信协议，每个请求和响应都是一条文本消息，这使得通信协议更加简单、直观、易于处理。
支持多媒体传输：HTTP协议可以传输多种类型的数据，如HTML、XML、JSON、图片、音频、视频等，这使得HTTP协议成为一种通用的网络传输协议，适用于各种不同类型的应用场景。
无连接：HTTP协议是一个无连接协议，每个请求都是独立的，服务器处理请求后立即关闭连接。这有助于节省资源，但也带来了一些缺点，如需要重新建立连接、重复发送相同的头部信息等。
无状态： HTTP协议没有客户端的状态存储，也没有事务处理的"内存"能力。这意味着每次访问网站时可能需要重复的登录操作。

然而，HTTP协议也存在一些不足之处。由于它以明文方式发送内容，不提供任何方式的数据加密，因此安全性较差 。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。因此，HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等支付信息。

与HTTP相比，HTTPS（Hypertext Transfer Protocol Secure）则是以安全为目标的HTTP通道。它在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS的内容加密、身份验证以及数据完整性保护的原理主要依赖于SSL/TLS协议。下面我们详细来看看这几方面的实现原理。

2.1 内容加密：对称加密+非对称加密

对称加密：在密钥交换完成后，客户端和服务器会生成一个共享的会话密钥。这个会话密钥用于后续的加密和解密操作。双方使用这个会话密钥，通过对称加密算法（如AES）对传输的数据进行加密和解密，确保数据在传输过程中的安全性。

如上图，对称加密虽然保证了消息的保密性，但是因Client和Service共享一个密匙，这样就导致密匙特别容易泄露。

非对称加密：非对称加密的性能会慢上至少几倍，增加系统消耗 。因此，Https将两种加密结合起来使用。在HTTPS的握手阶段，服务器会将其公钥发送给客户端 。这个公钥用于后续的加密通信。客户端使用服务器的公钥加密一个对称密钥，然后将加密后的随机数发送给服务器。服务器使用其私钥解密这个对称密钥，从而确保双方都能安全地交换密钥，这个过程称为密钥交换。密钥交换后就可以用对称加密的方法加密数据，实现数据快速安全的传输。

2.2 身份验证：HTTPS使用数字证书来验证服务器的身份

数字证书：数字证书是由权威的证书颁发机构（CA）颁发的，包含了服务器的公钥、服务器的身份信息以及CA的签名等信息。当客户端与服务器建立HTTPS连接时，服务器会将其数字证书发送给客户端。
验证过程：客户端收到服务器的数字证书后，会验证证书的合法性。首先，客户端会检查证书是否由受信任的CA颁发。然后，客户端会检查证书是否过期以及证书中的服务器身份信息是否与正在连接的服务器一致。最后，客户端会使用CA的公钥验证证书上的签名，确保证书在传输过程中没有被篡改。如果证书验证通过，客户端就可以确认服务器的身份是可信的。

2.3 数据完整性：HTTPS通过消息认证码（MAC）来确保数据的完整性

消息认证码：在HTTPS通信过程中，每个传输的数据包都会附带一个MAC值。这个MAC值是通过将数据包的内容和会话密钥一起输入到一个哈希函数中计算得出的。因此，只有持有相同会话密钥的接收方才能计算出正确的MAC值。
完整性校验：当接收方收到数据包时，它会使用相同的会话密钥和哈希函数计算MAC值，并与数据包中附带的MAC值进行比较。如果两个MAC值相同，那么接收方就可以确认数据包在传输过程中没有被篡改，从而保证了数据的完整性和安全性。

2.4 端口：HTTP 默认使用 80 端口，而 HTTPS 默认使用 443 端口

2.5 性能

因为HTTPS 需要进行加密和解密操作，因此它的性能可能略低于 HTTP。但随着技术的发展，这种性能差距已经接近可以忽略。

总结：加密；数字证书；消息认证码；443端口；性能略慢

HTTP和HTTPS在差异方面，最显著的是安全性。HTTP是明文传输协议，而HTTPS是加密传输协议。这种加密特性使得HTTPS在传输敏感信息时更具优势。此外，浏览器地址展示方式也有所不同，HTTPS有绿色安全锁标志，而HTTP则有网站不安全标志提醒。在协议层面，HTTPS在HTTP的基础上加入了SSL安全认证证书，从而提供了更高级别的安全防护。在涉及敏感信息传输的场景中，如在线购物、银行业务等，基本都是用HTTPS协议进行数据传输。

GET和POSE有什么区别