HTTP的复盘与整理

最新推荐文章于 2025-05-28 18:52:45 发布

原创最新推荐文章于 2025-05-28 18:52:45 发布 · 4.1k 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#http

计算机网络专栏收录该内容

3 篇文章

订阅专栏

参考笔记

概述

HTTP即超文本传输协议（ HyperText Transfer Protocol），用以浏览器和服务器之间传递数据，HTTP1.0版本是无状态（stateless）的，即同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时相同，服务器不维护任何有关客户端过去所发请求的信息。

HTTP的操作过程

用户点击链接后浏览器分析URL，与对应的服务器建立TCP链接（耗费1RTT）；
服务器持续监听80端口，监听到请求后同意建立连接，与浏览器建立起TCP连接；
浏览器发起HTTP请求文档数据，服务器响应后通过HTTP响应报文返回给浏览器；
浏览器接收到HTTP报文，解析后将数据渲染到页面，显示给用户并释放TCP连接。

非持久性连接

每个TCP连接最多允许传输一个对象
HTTP 1.0版本使用非持久性连接
响应时间：建立TCP连接（1RTT）+ 发送HTTP请求消息到HTTP响应消息的前几个字节到达（1个RTT） = 2RTT

持久性连接

HTTP消息格式

请求消息：

ASCII：人直接可读，carriage return为回车；line feed为换行

HTTP请求消息的通用格式，下图中“SP”代表“空格”；而“cr”表示“回车”；“lf”为“换行”

响应消息：

下图中第一行中的“200”表示网页被正常获取，常用的响应码包括：301 Moved Permanently（资源已被移动），400 Bad Request，404 Not Found，505 HTTP Version Not Supported等

HTTP2

二进制分帧：

帧：HTTP/2 数据通信的最小单位

消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。

流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID。

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

多路复用：

代替原来的序列和阻塞机制，所有就是请求的都是通过一个 TCP连接并发完成（HTTP1.1虽然支持长连接，但不支持高并发，当请求数量过多时，仍会使用多个TCP链接）

同域名下所有通信都在单个连接上完成。
单个连接可以承载任意数量的双向数据流。
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。
同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
单个连接上可以并行交错的请求和响应，之间互不干扰。
在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级，数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。

服务器推送：

服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。了解更多 Server Push 特性

头部压缩：

HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

HTTP3 & QUIC

HTTP VS HTTP2：

多路复用：多路复用时，多文件传输有时只需维护一个 TCP 连接。如果是 HTTP1 协议下，每份资源的传输对应一个 TCP 连接，一般最多只能开启 6 个 TCP 连接来传输多路数据，后续每增加一个新链接就会因为拥堵问题卡死，进而导致整个进程无法运行。因此HTTP/2解决了 HTTP 的队头阻塞问题。
头部压缩和 Server Push：HTTP2 会通过 HPACK 做头部压缩。同时 HTTP2 是二进制协议，在解析上相比基于文本的 HTTP解析效率上有所提升，并且 HTTP2 还增加了 Server Push。
在 TCP 下，依然无法解决延迟问题，比如为防止初始阻塞而引入的慢启动；TCP 队头阻塞，比如由于发生丢包，整个连接涉及的传输数据都需要重传而引起的阻塞。

HTTP3 VS HTTP2：

HTTP3 本质不是对 HTTP 协议本身的改进，它主要是集中在如何提高传输效率。上图是相比 HTTP2 而言 HTTP3 提升的点：

HTTP3 使用 stream 进一步扩展了 HTTP2 的多路复用。在 HTTP3 模式下，一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时，你只需要重传丢包文件的对应 stream 即可。
HTTP3 不再是基于 TCP 建立的，而是通过 UDP 建立，在用户空间保证传输的可靠性，相比 TCP，UDP 之上的 QUIC 协议提高了连接建立的速度，降低了延迟。
通过引入 Connection ID，使得 HTTP3 支持连接迁移以及 NAT 的重绑定。
HTTP3 含有一个包括验证、加密、数据及负载的 built-in 的TLS安全机制。
拥塞控制。TCP 是在内核区实现的，而 HTTP3 将拥塞控制移出了内核，通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。
头部压缩。HTTP2 使用的 HPACK，HTTP3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持，也优化了压缩率。

QUIC：

QUIC使用UDP而不再是TCP，

避免 ossification（僵化）：QUIC 协议加密负载，也是避免协议僵化一种方式，比如当中间层处理 UDP 数据时，只需要按照数据包的方式去处理即可，不需要去关注内部层的具体信息。
放弃改进 TCP 本身
创新方向：QUIC 是由谷歌提出的，所以 UDP 是以浏览器为出发点，从协议、从浏览器方向来进行创新。
这些年性能的优化提升都针对 TCP ，使得 UDP 性能没有任何改进。当然随着 QUIC3 的发布，相信后续应该会有相对的投入。
安全问题，也就是反射攻击，即伪造原地址。这个指发送数据包时的原地址是伪造的，不是真正的地址，会引起放大攻击。原因是 QUIC 握手过程是不对称的，特别是第一次请求时，客户端只需要发送几个字节的信息到服务器，而服务器则需要把证书等很多东西返还给客户端，这个不对称的机会造成了放大。草案 27 定义了两个规则和机制来限制反射攻击：客户端发送Initial包，即第一个数据包时，其长度必须在 1200 bytes以上，不足部分用 Padding 帧填充，同时，当服务端不确定客户端可靠性时，可以发送 Retry 包要求客户端再次提供验证信息。