HTTPS的默认端口号是443，HTTP是80
HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护
SSL/TLS工作在应用层和传输层之间
HTTPS的通信过程
1.tcp的三次握手
2.tls的连接
3.http的请求和响应
HTTP协议的不足（HTTP1.1)
同一时间，一个连接只能对应一个请求
针对同一个域名，大多数浏览器允许同时最多六个并发连接
只允许客服端主动发起请求
一个请求只能对应一个响应
同一个会话的多次请求中，头信息会被重复传输
通常会给每个传输增加500~800字节的开销
如果使用cookie，增加的开销会更多，可能达到上千字节
SPDY：
SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改
HTTP2的新特性：
二进制格式：
HTTP2采用二进制格式，非HTTP1.1的文本格式
二进制格式再协议的解析和优化扩展上带来更多的优势和可能
HTTP2一些基本概念
数据流：已建立连接内的双向字节流，可以承载一条或者多条信息
所有通信都在一个TCP上连接完成，此连接可以承载任意数量的双向数据流
消息：与逻辑HTTP请求或响应消息对应，由一系列帧组成
帧：HTTP2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）
来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装
HTTP2多路复用
客服端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再另一端把它们组装起来
并行交错地发送多个请求，请求之间互不影响
并行交错地发送多个请求，响应之间互不干扰
使用一个连接并行发送多个请求和响应
不必再为绕过HTTP限制而作很多工作
比如images sprites（将多张小图合并成一张大图，最后通过CSS结合小图的位置、尺寸进行精准定位、合并CSS\JS、内嵌CSS\JS\Base64图片、域名分片等
优先级
HTTP2标准允许每个数据流都有一个关联的权重和依赖关系
可以向每个数据流分配一个介于1至256之间的整数
每个数据流与其他数据流之间可以存在显示依赖关系
客服端可以构建和传递 “优先级树”，表明它倾向于如何接收响应
服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流的优先级
再资源数据可用后，确保将高优先级应以最优方式传输至客服端
头部压缩
HTTP2使用HPACK压缩请求头和响应头
可以极大减少头部开销，进而提高性能
服务器推送
服务器可以对一个客服端请求发送多个响应
除了对最初的响应外，服务器还可以向客服端推送额外资源，而无需客服端额外明确地请求
HTTP2的问题
队头阻塞
握手迟延
RTT：往返时延，可以简单理解为通信一来一回的时间
HTTP3
弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
那么HTTP3基于UDP，如何保证可靠传输？
由QUIC保证
HTTP3的新特性—迁移连接
TCP基于四要素（源IP，源端口，目标IP，目标端口）
切换网络时至少会有一个要素发生变化，导致连接发生变化
当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒时间
QUIC的连接不受四要素的影响，当四要素发生变化时，原连接依然维持
QUIC连接不以4要素作为标识，而是使用一组Connection ID（连接ID）来标识一个连接
即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持
比如：
当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接
HTTP3的问题—操作系统内核、CPU负载
与基于TLS的HTTP2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
若有收获，就点个赞吧
0 人点赞
