HTTP网络协议（六）
19~20课
19.HTTPS
安全这种东西是相对的，尽可能提高安全性
HTTP（HyperText Transfer Protocol Secure）,译为：超文本传输安全协议
常称为HTTP over TLS、HTTP over SSL、HTTP Secure
由网景公司于1994年首次提出
HTTPS的默认端口号是443（HTTP是80）
现在在在浏览器输入http://www.baidu.com
会自动重定向到https://www.baidu.com
SSL/TLS
-HTTPS是在HTTP的基础上使用SSL/TLS来加密保文，对窃听和中间人攻击提供合理的防护
-SSL/TLS也可以用在其他协议上，比如
FTP —> FTPS
SMTP —-> SMTPS
TLS（Transport Layer Secure）,译为：传输层安全协议
-前身是SSL（Secure Sockets Layer）,译为：安全套接层
历史版本信息
SSL1.0:因为存在严重的安全漏洞，从未公开过
SSL2.0:1995年，已于2011年弃用（RFC_6176）
SSL3.0:1996年，已于2015年弃用（RFC_7568）
TLS1.0:1999年（RFC_2246）
TLS1.1:2006年（RFC_4346）
TLS1.2:2008年（RFC_5246）
TLS1.3:2018年（RFC_8446）
SSL/TLS — 工作在哪一层
应用层和传输层之间
OpenSSL
OpenSSL是SSL/TLS协议的来源实现，始于1998年，支持Windows、Mac、Linux等平台
Linux、Mac一般自带OpenSSL
WIndows下安装OpenSSL :https://
常用的命令
生成私钥：openssl genrsa -out mj.key
生成公钥：openssl rsa -in my.key -public -out mj.pem
可以使用OpenSSL构建一套属于自己的CA，自己给自己颁发证书，称为“自签名证书”
HTTPS的成本
证书的成本
加解密计算（消耗更多CPU资源，降低访问速度。比HTTP访问稍微慢一点）
降低访问速度
有些企业的做法是，包含敏感数据的请求才使用HTTPS，其他保留使用HTTP
HTTPS的通信过程
总的可以分为三大阶段
1.TCP的三次握手
2.TLS的连接
3.HTTP的请求和响应
TLS1.2的连接
大概有10大步骤(省略了ACK步骤）
1.Client Hello
-TLS的版本
-支持加密的组件（Cipher Suite）等
加密组件是指所使用的加密算法及密钥长度等
-一个随机数（Client Random）
2.Server Hello
-TLS的版本号
-选择的加密组件
是从接收到的客户端加密组件列表中挑选出来的
3.Certificate
-服务器的公钥证书（被CA签名过的）
4.Server Key Exchange
-用以实现ECDHE算法的其中一种参数（Server Params）
ECDHE是一种密钥交换算法
为了防止伪造，Server Params经过了服务器私钥签名
5.Sever Hello Done
-告知服务端：协商部分结束了
-到目前为止：客户端和服务器之间通过明文共享了
Client Random、Server Random、 Server Params
-而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实性
6.Client Key Exchange
-用以实现ECDHE算法的另一个参数（Client Params）
-目前为止，客户端和服务器都拥有了ECDHE算法需要两个参数：Server Param、Client Params
-客户端，服务器都可以
使用ECDHE算法根据Server Params、Client Params 计算出一个新的随机密钥串：Pre-master secret
然后结合Client Random、Server Random、Pre-master secret 生成主密钥
最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥，服务端阿松的会话密钥等
7.Change Cipher Spec
告知服务器：之后的通信会采用计算出来的会话密钥进行加密
8.Finished
-包含连接至今全部保文的整体校验值（摘要），加密之后发给服务器
-这次握手协商是否成功，要以服务器是否能够正确解密该保文
9.10Change Cipher Spec、Finished
-到此为止，客户服务器都验证加密解密没问题，握手正式结束
-后面开始传输加密的HTTP请求和加密了
20.SPDY_QUIC_HTTP2+HTTP3
TLS1.2连接
ECDHE密钥加密算法
HTTP协议的不足（HTTP/1.1）
-同一时间，一个连接智能对应一个请求
针对同一个域名，大多数浏览器允许最多6个并发连接
-允许客户端主动发起请求
一个请求只能对应一个响应
-同一个回话的多次请求中，头消息会被重复传输
通常会给每个传输增加500-800字节的开销
如果使用Cookie, 增加的开销有时会达到上千字节
SPDY
SPDY（speedy的缩写），是基于TCP的应用层协议，它强制要求使用SSL/TLS
2009年11月，Google宣布将SPDY作为提高网络速度的内部项目
SPDY与HTTP的关系
SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
SPDY与HTTP的关系
SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
只需要增加一个SPDY层，现有的所有服务端应用均不用做任何修改
SPDY是HTTP/2的前身
2015年9月，Google宣布移除对SPDY的支持，用到HTTP/2
HTTP/2
HTTP/2，于2015年5月以RFC_7540正式发表
根据W3Techs的数据，截至2019年6月，全球有36.5%的网站支持了HTTP/2
不强求使用SSL/TLS，但商业使用中基本都是用了SSL/TLS安全层
HTTP1.1和HTTP/2速度对比
http://www.http2demo.io/
https://http2.akamai.com/demo
HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容
比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变
因此，想要升级到HTTP/2（只是应用层面的东西）
-开发者不需要修改任何代码
-只需要升级服务器配置、升级浏览器
底层操作系统内核就不好改，需要微软修改windows内核代码，太难了（TCP IP）
HTTP/2的特性- 二进制格式
-HTTP/2采用二进制格式传输数据，而非HTTP1.1的文本格式
-二进制格式在协议的解析和优化扩展上带来很多优势和可能
数据流：已建立的连接内的双向字节流，可以承载一条或多条消息
-所有通信都在一个TCP连接上完成，此连接可以承载任意数字的双向数据流
消息：于逻辑HTTP请求或响应消息对应，由一些列帧组成
帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）
来自不同数据流的帧可以交错发送，然后在根据每个帧头的数据流标识符重新组装
HTTP/2的特性 - 多路复用（Multipxing）
-客户端和服务器可以将HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来
-并行交错地发送多个请求，请求之间互不影响
-并行交错地发送多个响应，响应之前互不干扰
-使用一个连接并行发送多个请求和响应
-不必在为绕过HTTP/1.1限制而做很多工作
比如把image sprites、合
并CSS\CS、内嵌CSS\JS\Base64图片、域名分片等
精灵图片
image sprites(也叫做CSS Sprites), 将多张小图合并成一张大图
最后通过CSS结合小图的位置，尺寸进行精准定位
HTTP/2的特性 - 优先级
HTTP/2标准允许每个数据流都有一个关联的权重和依赖关系
-可以向每个数据流分配一个介于1～256之间的整数
-每个数据流与其他数据流之间可以存在显示依赖关系
每个客户端可以构建和传递“优先级树”，表明他倾向于如何接受响应
服务器可以使用此消息通过CPU、内存、和其他资源的分配设定数据流处理的优先级
-再资源数据可用之后，确保高优先级响应以最快方式传输至客户端
尽可能先给父数据流分配资源
同级数据流（共享相同父项）应按其权重比例分配资源
HTTP/2的特性 - 头部压缩
HTTP/2的使用HPACK压缩请求头和响应头
-可以极大减少头部，进而提高性能
早期版本的HTTP/2和SPDY使用zlib压缩
-早期将所传输头数据的大小减少85%～88%
-但在2021年夏天，被攻击导致会话劫持
-后被更安全的HPACK取代
HTTP/2的特性 - 服务器推送（Server Push）
服务器可以对一个客户端请求发送多个响应
-除了最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确的请求
HTTP/2的问题 - 对头阻塞（Head of line blocking）
QUIC
HTTP/2的问题 - 握手延迟
QUIC 0ms 可以办到0RTT建立连接
RTT（Round trip time）: 往返时延，可以简单理解为通信一来一回的时间
HTTP/3
Google 觉得HTTP/2仍不够快，于是有了HTTP/3
-HTTP/3由Google开发，弃用了TCP协议，改为使用基于UDP协议的QUIC协议实现
-QUIC（Quic UDP Internet Connections）,译为快速UDP网络连接，由Google开发，在2013年实现
-于2018年从HTTP-over-QUIC改为HTTP/3
![Bull pptx] - PowerPoint.JPG](https://upload-images.jianshu.io/upload_images/1623463-93a14572e15c71ff.JPG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
HTTP/3 - 疑问
HTTP/3基于UDP，如何保证可靠传输？
-由QUIC来保证，它来编写可靠传输代码。只要有一层保证可靠传输就可以了。
假设UDP层丢了数据，QUIC层会告诉服务端，丢失了哪一部分请重发
-为何Google不开发一个新的不同于TCP、UDP的传输层协议？
1.目前世界上的网络设备基本只认识TCP、UDP（UDP没有传输阻塞的问题，QUIC可靠部分就由Google处理好啦）
2.如果要修改传输层，意味着操作系统的内核也要修改
3.另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用
4.因此，想要开发并应用一个新的传输层协议，是极其困难的一件事情
HTTP/3的特性 - 连接迁移
TCP基于4要素（源IP、源接口、源IP、目标端口）
-切换网络时，至少会有一个要素发生变化，导致连接发生变化
-当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
-所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
-如果实现得很好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百浩渺的时间。
QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持
-QUIC连接不以4要素的影响，当4要素发生变化时，原连接依然维持
-即使IP或者端口发生变化，只要connection ID没有变化，那么连接依然可以维持
-比如
当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
当Wi-Fi连接不再可用时吗，将连接转移到蜂窝网络连接
HTTP/3的问题 - 操作系统内核、CPU负载
据Google和FaceBook称，于基于TLS的HTTP/2相比，它们大规模部署QUIC需要近2倍的CPU使用量
-Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的的信息传输
-TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
随着时间的推移，相信这个问题会逐步得到改善