透视http协议

虎妞先生

发布于 2023-10-16 18:08:39

1750

发布于 2023-10-16 18:08:39

文章被收录于专栏：前端开疆扩土之路前端开疆扩土之路

http协议是什么？

超文本传输协议

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

TCP/IP 四层模型

链接层

网络层

传输层

应用层

OSI 七层模型

物理层

数据链路层

网络层

传输层

会话层

表示层

应用层

输入网址再按下回车，后面发生了什么

浏览器从地址栏的输入，进行域名解析，因此通过浏览器缓存，系统缓存，host文件中获得服务器的 IP 地址和端口号；
浏览器用 TCP 的三次握手与服务器建立连接；
浏览器向服务器发送拼好的报文；
服务器收到报文后处理请求，同样拼好报文再发给浏览器；
浏览器解析报文，渲染输出页面。

http报文

请求行有三部分：请求方法，请求目标和版本号；
状态行也有三部分：版本号，状态码和原因字符串；

GET / HTTP/1.1	HTTP/1.1 200 OK

请求方法

“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。

只有 GET 和 HEAD 方法是“安全”的，因为它们是“只读”操作

“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。

POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；而 PUT 是“替换或更新数据”，多次更新一个资源

客户端和服务器看到的 URI 是不一样的。客户端看到的必须是完整的 URI，使用特定的协议去连接特定的主机，而服务器看到的只是报文请求行里被删除了协议名和主机名的 URI。

在 URI 里对“@&/”等特殊字符和汉字必须要做编码，否则服务器收到 HTTP 报文后会无法正确处理。

http的特点

HTTP 是灵活可扩展的，可以任意添加头字段实现任意功能；
HTTP 是可靠传输协议，基于 TCP/IP 协议“尽量”保证数据的送达；
HTTP 是应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据；
HTTP 使用了请求 - 应答模式，客户端主动发起请求，服务器被动回复请求；
HTTP 本质上是无状态的，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。

http有哪些优点？又有哪些缺点？

HTTP 最大的优点是简单、灵活和易于扩展；
HTTP 拥有成熟的软硬件环境，应用的非常广泛，是互联网的基础设施；
HTTP 是无状态的，可以轻松实现集群化，扩展性能，但有时也需要用 Cookie 技术来实现“有状态”；
HTTP 是明文传输，数据完全肉眼可见，能够方便地研究分析，但也容易被窃听；
HTTP 是不安全的，无法验证通信双方的身份，也不能判断报文是否被窜改；
HTTP 的性能不算差，但不完全适应现在的互联网，还有很大的提升空间。

http传输大文件的方法

数据压缩
- gzip 只处理文本效果较好
- 所以各大网站的服务器都会使用这个手段作为“保底”。例如，在 Nginx 里就会使用“gzip on”指令，启用对“text/html”的压缩。
分块传输可以流式收发数据，
- 节约内存和带宽，使用响应头字段“Transfer-Encoding: chunked”来表示，分块的格式是 16 进制长度头 + 数据块；
范围请求可以只获取部分数据，即“分块请求”，实现视频拖拽或者断点续传，使用请求头字段“Range”和响应头字段“Content-Range”，响应状态码必须是 206；
- 也可以一次请求多个范围，这时候响应报文的数据类型是“multipart/byteranges”，body 里的多个部分会用 boundary 字符串分隔。

https

本质

在客户端和服务器之间协商出一个对称密钥，每次发送之前加密，收到之后解密，达到内容的加密传输。
先用非对称加密传输对称加密的密钥，然后用对称加密传输通信的内容。

具体过程

客户端告诉服务端，我要建立链接
- 附加一串信息
- - TLS版本
  - hash加密算法套件
  - 对称加密算法
  - 非对称加密算法
服务端选择算法之后，生成一个随机数发送给客户端

服务器继续发送服务器证书，证书里有它的公钥，服务器地址证书签名证书机构证书机构的签发方

客户端解析证书，拿到公钥
- 权威机构在颁布证书的时候，会对它的证书做摘要，生成指纹，再使用它的私钥对这段指纹进行加密，生成一个数字签名。当接收方收到证书后，先用证书指定的算法对证书做摘要，然后再用公钥对数字签名解密，如果和摘要的结果一致就证明是可信的。
- 用公钥加密一个随机数Pre-master Secret ，发送服务端
服务端利用自己的私钥揭秘，得到随机数，三个随机生成Master Secret, 只在握手阶段使用
客户端和服务端再根据master secret 将直接生产他们的会话密钥、
MAC Secret MAC Secret是用来验证身份的。你是客户端你发消息了，我是服务端，我接收到这个消息以后，我也对这个消息进行有个HMAC，然后我得到这个HMAC，我可以去验证一下客户端连同这个消息一起发过来的HMAC，他们两个是不是一致。如果一致，我就可以确定消息确实是客户端发给我的。

TLS1.3

优化HMAC算法

减少握手阶段

加密套件的简化

简化密钥协商算法

http/2

头部压缩

对header进行压缩，开发了专门的“HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，

利用哈夫曼树对响应和请求头进行编码。计算出先频率，编码。

二进制帧

不再是“Header+Body”的形式，而是分散为多个二进制“帧”

虚拟流

它是二进制帧的双向传输序列，HTTP/2 就可以在一个 TCP 连接上用“流”同时发送多个“碎片化”的消息，这就是常说的“多路复用”（ Multiplexing）——多个往返通信都复用一个连接来处理。而在“连接”的层面上看，消息却是乱序收发的“帧”。多个请求 / 响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。

服务器推送

浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟

也增强了安全性，要求至少是 TLS1.2，而且禁用了很多不安全的密码套件。

队头阻塞

通常我们说队头阻塞，都是说tcp，但是HTTP1.1中也有一个类似TCP队头阻塞的问题

TCP队头阻塞

TCP是一种可靠传输，这个可靠就是体现在它能够“按序到达”，然后再被上层接收，这里的按序到达指的是最终顺序是按序排列的，也就是说每当有一个或几个Packet丢失的时候，会等待它到达后合并，然后再向上交付。

当一个流的第一个数据包丢失了，那么即使后面的数据包都到达了，后面的这些数据包也不能被处理，而是要等第一个数据包到了之后才能被上层接收处理

HTTP队头阻塞

HTTP管道化要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟，直到队头的响应送达。

如何解决队头阻塞

对于HTTP1.1中管道化导致的请求/响应级别的队头阻塞，可以使用HTTP2解决。HTTP2不使用管道化的方式，而是引入了帧、消息和数据流等概念，每个请求/响应被称为消息，每个消息都被拆分成若干个帧进行传输，每个帧都分配一个序号。每个帧在传输是属于一个数据流，而一个连接上可以存在多个流，各个帧在流和连接上独立传输，到达之后在组装成消息，这样就避免了请求/响应阻塞。

当然，即使使用HTTP2，如果HTTP2底层使用的是TCP协议，仍可能出现TCP队头阻塞。