HTTP与HTTPS的区别

• HTTP是明文传输；HTTPS是由 HTTP+SSL 协议构建的可进行身份验证、信息加密和完整性校验的网络协议，比HTTP协议安全
• HTTP的端口号是80，HTTPS是443
• HTTPS需要到 CA 申请证书，一般需要交费

HTTP

一个HTTP请求流程：

1. 地址解析：从URL中分解出协议名、域名、端口、对象路径。
2. DNS解析域名，得到主机的IP地址
3. 封装HTTP请求数据包
4. 封装成TCP包，通过三次握手建立TCP连接
5. 客户端发送HTTP请求
6. 服务器处理HTTP请求并响应
7. 四次握手断开TCP连接

HTTP不同版本的区别

HTTP/1.0

引入请求头和响应头，引入状态码，提供了Cache机制来缓存下载过的资源

HTTP/1.1

• 引入持久连接。在HTTP/1.0中每一对请求响应都需要单独的TCP连接；HTTP/1.1可以在一个TCP连接上可以进行多次请求和响应

• 支持虚拟主机。在HTTP/1.0中一个IP地址只能绑定一个域名，因此服务器只能支持一个域名。HTTP/1.1实现了一台物理主机可以绑定多个拥有独立域名的虚拟主机，并且在请求头添加Host字段，用来表示当前域名，供服务器区分。

• 客户端Cookie。用户登录时，服务器验证用户登录信息正确后，会在响应头用Set-Cookie字段，把Cookie返回给客户端；当用户再次访问服务器时，浏览器会读取之前保存的Cookie数据并写入请求头的Cookie字段中。

• Cookie相关安全机制。响应头返回 Set-Cookie: HttpOnly，禁止JavaScript脚本通过document.cookie访问Cookie，以阻止XSS攻击。设置响应头 Set-Cookie: Samesite=Strict，浏览器只能在访问相同站点时发送cookie；Lax只允许第三方站点通过连接打开或get请求时携带cookie；Node允许浏览器在同站请求、跨站请求下继续发送cookie。利用Samesite字段可以防止CSRF攻击。

问题：队头堵塞。TCP通道中，需要等待前面的请求返回后才能进行下一次请求。如果某个请求因为某些原因没有及时返回，就会阻塞后面的所有请求。这就是(应用层面的)队头阻塞问题。

HTTP/2

• **二进制传输。**在 HTTP1.x 时代，无论是传输内容还是头信息，都是文本/ASCII编码的。但由于存在空格或其他字符，很难判断消息的起始和结束，使得想要实现并发传输异常困难。使用二进制传输可以避免这个问题，因为传输内容只有1和0。

• 多路复用。在一个TCP连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，解决了队头阻塞的问题。这依赖于在应用层（HTTP/2）和传输层之间添加的二进制分帧层：发送者发送的请求或响应都会被转换为一个个带有Stream ID的帧 (并且它们采用二进制编码) ，多个帧之间可以乱序发送；接收者从乱序的二进制帧中选择ID相同的帧，按顺序重新组装成请求/响应报文。（在 HTTP 1.x中，如果想并发多个请求，必须使用多个TCP链接，但浏览器对单个域名有6个的TCP链接请求限制；在HTTP/2中，同域名下所有通信都在单个连接上完成，单个连接可以承载任意数量的双向数据流）

• 请求优先级。可以设置数据帧的优先级，让服务端先处理优先级高的请求。

• 头部压缩。HTTP/2对请求头和响应头进行了压缩。HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新；每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。（例如：第一个请求 发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销）

• 服务器推送。服务端可以在发送页面HTML时主动推送JS和CSS文件等其它资源，而不用等到浏览器解析HTML到相应位置，发起请求后再响应。（如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端）

参考：

• zhuanlan.zhihu.com/p/26559480

• juejin.cn/post/684490…

• segmentfault.com/a/119000002…

HTTP/3

HTTP由于使用TCP协议，还是有一些问题：在TCP传输数据包的过程中，一旦丢包，之后的数据就得等待丢包重传，造成(TCP的队头)阻塞。而且建立TCP连接很费时。

为了解决这些问题，引入HTTP/3。HTTP/3基于UDP协议，又提供了类似于TCP的多路复用数据流、传输可靠性等功能。这套功能称为QUIC协议。

• 流量控制、传输可靠性功能：QUIC在UDP的基础上增加了一层保证数据传输可靠性，提供包括数据包重传、拥塞控制等类似TCP的功能
• 集成TLS加密功能：QUIC使用TLS1.3，减少了握手所花费的RTT数
• 多路复用：同一物理连接上可以又多个独立的逻辑数据流，实现了数据流的单独传输，解决了TCP的队头堵塞问题。
• 快速握手：由于QUIC基于UDP，可以实现使用0～1个RTT来建立连接。

HTTP/3的挑战 ：

目前服务器和浏览器端都没有对HTTP/3提供比较完整的支持。 

部署问题，系统内核对UDP的优化远达不到TCP的优化程度。 

中间设备僵化问题，这些设备对UDP的优化程度远低于TCP，据统计使用QUIC协议时，大约有3% ~ 7%的丢包率。

为什么需要HTTPS

HTTP缺点

• 通信使用明文，容易被窃听
• 无法证明报文的完整性，可能遭遇篡改
• 不验证通信方的身份，容易被伪装

HTTPS解决这些问题，它有以下优势：

数据隐私性：内容经过对称加密，每个连接生成唯一的一个加密密钥。

数据完整性：内容传输经过完整性校验。

身份认证：第三方无法伪造服务端身份。

HTTPS如何解决以上问题？

1. 解决内容可能被窃听问题——加密

对称加密+非对称加密。

在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。

客户端使用对方的公钥进行加密处理“对称的密钥”，然后对方用他自己的私钥解密拿到“对称的密钥”，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。

2. 解决报文可能遭篡改问题——数字签名

发送者将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥将消息摘要加密生成数字签名。把数字签名和原文一起传送给接收者。

接收者用发送者的公钥解密收到的数字签名，得到一份消息摘要；再用同样的Hash算法对收到的原文产生一份消息摘要。对比两份消息摘要，如果相同则收到的信息是完整的，没有被篡改，否则就是被篡改过。

3. 解决通信方身份可能被伪装的问题——数字证书

1. 服务端向第三方机构CA提交公钥、组织信息、个人信息（域名）等信息并申请认证
2. CA验证申请者信息的真实性
3. 如果信息审核通过，CA会向申请者签发认证文件——证书。证书包含：申请者公钥、申请者信息、签发机构CA的信息等信息明文，和一个签名。（散列函数计算明文信息的信息摘要，然后采用CA的私钥对信息摘要进行加密，产生签名）
4. 客户端向服务端发出请求时，服务端返回证书文件
5. 客户端读取证书中的明文信息，采用相同的散列函数计算得到的信息摘要；然后利用对应CA的公钥解密证书中的签名，得出信息摘要。两者对比，如果一致则可以确认证书的合法性，即公钥合法。 
6. 客户端然后验证证书相关的域名信息，有效时间的信息
7. 客户端会内置信任的CA证书信息（包含公钥），如果发来的证书不被信任，也会判定非法。

HTTPS工作流程

HTTPS缺点

• HTTPS协议握手阶段比较费时
• 消耗较多的CPU及内存资源。非对称加密解密，对称加密解密。
• 需要花钱购买证书

HTTPS接入优化

• CDN接入：CDN离用户最近，因此选择使用CDN作为HTTPS接入的入口，减小RTT，减小延时。
• 会话缓存：减少1个RTT的延时；不需要服务器进行非对称私钥解密，可省CPU消耗
• 硬件加速：为接入服务器安装专用的SSL硬件加速卡，作用类似GPU，释放CPU，提供更强的解密能力
• 远程解密：将最消耗CPU资源的非对称RSA解密计算任务转移到其他服务器。
• SPDY/HTTP2：修改协议。