HTTP协议

构建 HTTP 请求行的时候是怎么确定用什么版本的 HTTP 协议的?

目前主流的 HTTP 协议版本有 HTTP/1.1、HTTP/2、HTTP/3(实验性)。请求发生时具体使用的版本是由客户端主导、客户端和服务器共同协商决定的。

比如支持 HTTP/2 的客户端,会在 TLS 握手发起时,在 ALPN(Application-Layer Protocol Negotiation) 扩展中标明自己支持 h2 和 http/1.1,打开 curl 命令的调试模式就能看到:

如果服务器也支持 h2,就会告诉客户端:

不支持也同样会告诉:

浏览器使用 HTTP/2 也是这个原理。但是 HTTP/3 使用了 UDP,UDP 不需要握手,所以没法用和 HTTP/2 相同的方式来进行协商。而是反过来了,是起初先按照普通的 HTTP 1.1/2 进行请求,服务器从这些请求的响应头(alt-svc)中告诉客户端,自己是支持 h3 的。这样如果客户端也支持 h3。就可以在往后的请求中直接使用 h3,ma 是 max-age,表示超过这个时间就得忘掉这个域名是支持 h3

HTTP/3 正式发布,有哪些站点提速了?

💡 HTTP/3 是超文本传输协议 (HTTP) 的第三个版本,以前称为 HTTP-over-QUIC。
QUIC 最初由 Google 开发,是 HTTP/2 的继承者。Google 和 Facebook 等已经使用 QUIC 来加速网络。
HTTP 简史

对于游戏开发者来说,重要的协议是UDP(用户数据报协议)。UDP是快速、即发即弃的标准:你在网络上扔了一个数据包,它就被抓住或者有时被丢掉了。

像Web这样要求稳定的系统,正确使用的底层协议是TCP(传输控制协议)。这是一个更正式的系统,它保证了数据包的交付与正确顺序。TCP 创建了可靠连接,后来又创建了可靠的信息流。

随后,它们被正式命名为“TCP/IP 堆栈”。

后来,基于 TCP/IP 编写的WWW和 HTTP 成为互联网的主要用途。另一个缺失的首字母缩略词是TLS(传输层安全),它提供了加密相关元素,并成为事实上的安全标准。

而在那个年代里, PC 之间的连接通常是有线的,任何损失都是由于旧铜线上的噪音造成的。

TCP 协议非常适合收集偶尔出错的数据包,而随着Web的发展使用 UDP 协议逐渐减少。

进入QUIC

今天的互联网已经进入一个发展非常不同的场景了。

比如现在家中的 PC

HTTP/3 重磅来袭

一.现状:

HTTP/3 的基础即谷歌多年探索的基于 UDP 的 QUIC 协议。与 TCP 相比,使用 UDP 可以提供更大的灵活性,并且可以使 QUIC 完全于用户空间中实现——对协议实现的更新不像 TCP 那样需要绑定到操作系统更新。使用 QUIC,可以简单地将 HTTP 级别的流映射到 QUIC 流的顶部,从而继承 HTTP/2 的所有优点,而不会产生队头阻塞。HTTP/3 虽仍处于草案状态,但很多用户已经跃跃欲试。

二.优势

HTTP/3 利用 QUIC 加速 HTTP 请求,QUIC 提供比 TCP 和 TLS 更高的加密和性能
QUIC 是一种默认加密的新传输协议,旨在加快 HTTP

HTTP/3 发布!

6 月 6 日,IETF QUIC(Internet Engineering Task Force,互联网工程任务组,简称 IETF)、比利时的 HTTP 工作组成员 Robin Mark 在 Twitter 上宣布“历时 5 年,HTTP/3 终于被标准化为 RFC 9114。将与 RFC 9204(QPACK header 压缩)和 RFC 9218 (可扩展的优先级)一起开启 Web 的新篇章!”,这意味着该协议已经进入了稳定的状态,而 HTTP/3 是 HTTP 超文本传输协议的第三个主要版本。…

关于队头阻塞(Head-of-Line blocking),看这一篇就足够了

(译)Robin Marx: QUIC 和 HTTP/3 队头阻塞的细节

作者:Robin Marx,原文:Head-of-Line Blocking in QUIC and HTTP/3: The DetailsGitHubrmarx/holblocking-blogpost

您可能已经听说,经过4年的工作,新的 HTTP/3 和 QUIC 协议终于接近正式标准化。预览版现在可以在服务器和浏览器中进行测试

与 HTTP/2 相比,HTTP/3 有很大的性能改进,这主要是因为它将底层传输协议从 TCP 改为基于 UDP 的 QUIC。在这篇文章中,我们将深入了解其中的一项改进,即消除…

            

四个决策树让你彻底掌握 HTTP 状态码

你好,我是看山。

众所周知,每一个 HTTP 响应都会带有一个 HTTP 状态码(HTTP Status Code),是用来表示 HTTP 服务器响应状态的代码。它由 RFC 2616 规范定义的,并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范扩展。作为 web 开发者,平时经常 200、301、302、404、500、503 等。最近正在开发一些对外的接口(公司内部各系统间互相调用的接口,也算是内部 Open API 吧),接口调用失败时需要返回一些状态码,考虑借用 HTTP 状态码的含义,可以让调用方通过状态码就能够大体知道出了什么问题,不用彼此重新约定不熟悉的编码规则,方便沟通及错误定位。自认为想法不错,但是在实际编写中遇到了问题,这个多的状态码该怎么用?就用这个机会好好学习下什么场景用什么状态码,也通过本文记录一下 HTTP 状态码的内容。在本文中借 Michael Kropat 的 《Choosing an HTTP Status Code —