1、HTTP基础
超文本传输协议。
-
协议：HTTP是用在计算机世界里的协议，它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范。
-
传输：HTTP是一个在计算机世界里专门用来在俩点之间传输数据的约定和规范。HTTP 协议是一个双向协议
-
超文本：它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本。
总结：HTTP是一个在计算机世界俩点之间传输超文本数据的约定和规范
2、HTTP常见字段
HOST：服务器域名
Content-Length：本次回应的数据长度
Connection：Keep-Alive 是否使用长链接
Accept：客户端请求时告诉服务器自己接受哪些格式
Accept-Encoding：告诉服务器接受哪些压缩方法
Content-Type：服务器告诉客户端本次数据格式
Content-Encoding：服务器返回的数据用了什么压缩格式
HTTP是基于TCP进行通信的，HTTP协议通过设置回车符、换行符作为HTTP header的边界，通过Context-Length字段作为HTTP body的边界。来解决粘包问题。
3、HTTP缓存技术
强制缓存和协商缓存
3.1 强制缓存
只要浏览器缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
强缓存利用HTTP响应头部字段实现
-
Cache-Control：相对时间（优先级高）
-
Expires：绝对时间
-
3.2 协商缓存
当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。
-
基于时间实现
-
基于唯一标识实现
协商缓存需要配合强制缓存中Cacha-Control字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。
4、HTTP/1.1
优点：
-
简单：HTTP基本的报文格式就是header+body，头部信息也是key-value简单文本形式。
-
灵活易于扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和补充。
-
应用广泛和跨平台
缺点：
-
无状态
-
明文传输
-
不安全
4.1 HTTP性能：
HTTP协议是基于TCP/IP，采用请求-应答通信 模式
长连接：早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。因此HTTP采用了长连接
管道网络传输（默认不开启）： 即可在一个TCP链接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来就可以发出第二个请求出去。服务器必须按照接收请求的顺序发送对这些管道化请求的响应。HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。（如果服务器在处理A请求耗时较长，后续的请求都会被阻塞住）
5、HTTP/1.1、HTTP/2、HTTP/3演变
HTTP/1.1 相比 HTTP/1.0 性能上的改进：
-
使用长连接改善HTTP/1.0短链接造成的性能开销
-
使用管道网络传输
HTTP1.1性能瓶颈
-
请求/相应头部未经压缩就发送，首部信息越多延迟越大，只能压缩Body部分
-
发送冗长的首部。每次互相发送相同的首部造成。
-
服务器是按请求的顺序相应的。队头阻塞
-
没有请求优先级控制
-
请求只能从客户端开始，服务器只能被动响应
5.1 HTTP/2做了什么优化
那 HTTP/2 相比 HTTP/1.1 性能上的改进：
-
头部压缩
-
二进制格式
-
并发传输
-
服务器主动推送资源
-
头部压缩
如果同时发出多个请求且它们的头一样或者相似，那么协议会帮你消除重复的部分
利用HPACK算法：在客户端和服务器同时维护一张头信息表。所有字段都会存入这个表，生成一个索引号，相同的头部只发送索引号。
-
二进制格式
头信息和数据体都是二进制，统称为帧：头信息帧和数据帧
-
并发传输
HTTP/1.1的实现是基于请求-相应模式。同一个连接中，HTTP完成一个事务，才能处理下一个事务。
HTTP/2引入Stream。多个Stream复用在一条TCP连接。一个TCP连接包好多个Stream，Stream里包含一个或多个Message，对应HTTP/1中的请求和响应。Message里包含一个或多个Frame，Frame是HTTP/2最小单位。以二进制存放HTTP/1中的内容（头部和包体）
针对不同的HTTP请求用独一无二的Stream ID来区分，接收端可以通过Stream ID有序组成HTTP消息，不同的额Stream可以乱序发送的。因此可以并发不同的Stream。
-
服务器推送
HTTP/2中客户端和服务器双方都可以建立Stream。客户端Stream ID为奇数、服务器Stream ID为偶数
例如客户端通过 HTTP/1.1 请求从服务器那获取到了 HTML 文件，而 HTML 可能还需要依赖 CSS 来渲染页面，这时客户端还要再发起获取 CSS 文件的请求，需要两次消息往返，HTTP/2中服务器可以主动推送CSS文件。
【学习地址】：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击1079654574加群领取哦~
缺陷：
HTTP/2还是存在对头阻塞问题。但不是在HTTP层，而是在TCP这一层。
HTTP/2是基于TCP协议来传输数据，TCP是字节流协议，TCP层必须保证收到的字节数据是完成且连续的，然后内核才会讲缓冲区里的数据返回给HTTP应用，那么当前一个字节数据没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到上一个请求最后一个字节数据到达时，HTTP/2应用层才能从内核中拿到数据。
因此一旦发生丢包现象，就会触发TCP的重传机制，这个TCP连接中的所有HTTP请求都必须等待这个丢了的包被重传回来。
5.2 HTTP/3 做了哪些优化？
因为HTTP/2在TCP层出现了队头阻塞，因此HTTP/3把HTTP下层的TCP协议改成了UDP
UDP 发送是不管顺序，并且HTTP/3基于UDP的QUIC协议可以实现类似TCP的可靠性传输
QUIC特点：
-
无队头阻塞
-
更快的连接建立
-
连接迁移
-
无队头阻塞
QUIC协议也有类似HTTP/2 Stream多路复用概念，在一个连接上建立并发传输多个Stream，Stream可以认为就是一条HTTP请求
QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。 所以QUIC连接上的多个Stream之间并没有依赖，都是独立的。
-
更快的连接
对于HTTP/1和HTTP/2协议，TCP和TLS时分层的，需要分批次来握手，先TCP握手，在TLS握手。
但是HTTP/3的QUIC协议并不是与TLS分层，而是QUIC包含了TLS。它在自己的帧会携带TLS里的记录，同时QUIC使用的是TLS/1.3，只需要1个RTT就可以同时完成建立连接与密钥协商。
、
甚至第二次连接时，应用数据包可以和QUIC握手信息一起发送，达到0-RTT。
-
连接迁移
基于TCP传输协议的HTTP协议，通过四元组（源IP、源端口、目的IP、目的端口）确定一条TCP连接。那么例如设备从4G切换到WIFI时，意味着IP地址变了，那么就必须重新建立连接
而QUIC协议没有用四元组来绑定连接，而是通过连接ID来标记通信的俩个端点，客户端和服务端各选择一组ID来标记自己。因此即使网络变化，但是只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以无缝第复用原连接。
所以，QUIC是一个在UDP之上的伪TCP+TLS+HTTP/2的多路复用协议
6、HTTP和HTTPS
区别：
-
HTTP是超文本传输协议，信息是明文传输，存在安全风险，HPPTS在TCP和HTTP网络层增加了SSL/TLS安全协议，使得报文能够加密传输
-
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
-
HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
-
HTTPS协议需要像CA（证书权威机构）申请数字证书
HTTP由于是明文传输，存在三个风险：窃听风险，篡改风险，冒充风险
HTTPS加入了SSL/TLS协议，解决了上述问题。包括信息加密，校验机制，身份证书
-
混合加密
HTTP采用的是对称加密和非对称加密结合的混合加密方式
-
在通信建立前采用非对称加密的方式交换会话密钥
-
通信过程中全部使用对称加密的会话密钥加密明文数据
-
摘要算法+数字签名
为了保证传输的内容不被篡改，对内容计算出一个【指纹】，然后同内容一同传输对方，对方接收后，先是对内容也算出一个指纹，然后跟发送方指纹做比较，如果指纹相同。证明内容没有被篡改。
用摘要算法（哈希函数）来计算出内容的哈希值，这个哈希值是唯一的。且无法通过哈希值推算出内容
通过数字签名来保证传输的内容不被替换掉。利用非对称加密， 私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。
-
数字证书
在计算机里，将服务器公钥房子数字证书里（由数字认证机构颁发简称CA），只要证书是可信的，公钥就是可信的。通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。
6.1 HTTPS是如果建立连接
SSL/TLS协议基本流程：
-
客户端像服务器索要并验证服务器的公钥。
-
双方协商生产会话密钥
-
双方采用会话密钥进行加密通信
前俩步也就是SSL/TLS的建立过程，也就是握手过程。
TLS的握手阶段涉及四次通信，使用不同的密钥交换算法，TLS握手流程也不一样，常用算法RSA和ECDHE。
TLS协议建立过程
-
ClientHello
首先客户端向服务器发起加密通信请求，包括客户端支持的TLS协议版本，客户端产生的随机数，客户端支持的密码套件列表
-
ServerHello
服务器收到客户端请求后，像客户端做出响应。内容包括确认TLS协议版本、服务器产生的随机数、确认的密码套件列表、服务器的数字证书
-
客户端回应
客户端收到服务器的回应后，首先确认服务器证书的正确性，如果没有问题取出弓腰，然后使用它加密向服务器发送一个随机数随机数、加密通信算法改变通知、告知随后的信息采用会话密钥加密通信。表示客户端的握手阶段已经结束。客户端握手结束通知，并把之前所有内容的数据做个摘要，供服务器校验。
服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
-
服务器最后回应
服务器收到客户端的第三个随机数之后，计算出本次会话密钥。然后向客户端发送最后消息，加密通信算法改变通知，表示随后信息都将用会话密钥通信。服务器握手结束通知，把之前所有内容的数据做个摘要，供客户端校验。
至此整个TLS握手阶段结束，客户端和服务端进入加密通信，使用最普通的HTTP协议。但是会用会话密钥加密通信的内容
6.2 HTTPS如何保证完整性的
TLS在实现上分为握手协议和记录协议俩层
-
TLS握手协议就是TLS四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用数据。
-
TLS记录协议负责保护应用程序数据并验证其完整性和来源，所以对HTTP数据加密是使用记录协议。TLS记录协议主要负责消息的压缩、加密及数据的认证。
-
-
首先消息会被分割成多个较短的片段，对每个片段进行压缩。
-
经过压缩的片段会被加上消息验证码（MAC值，是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。通过附加消息认证码的MAC值，可以识别出篡改，为了防止重放攻击，在计算消息认证码时，还加上了片段的编码。
-
经过压缩的片段在加上消息认证码会一起通过对称密钥进行加密。
-
上述加密的数据在加上由数据类型、版本号、压缩后的长度组成的报文头就是最终的报文数据
-