HTTP协议

缓存您的 CORS,以提高性能和利润

CORS 是许多 API 所必需的,但基本配置会产生大量额外请求,从而减慢每个浏览器 API 客户端的速度,并向您的后端发送不必要的流量。

这可能是传统 API 的问题,但在无服务器平台上会成为一个更大的问题,在无服务器平台上,您的账单通常直接与收到的请求数量挂钩,因此这很容易使您的 API 成本翻倍。

所有这些都是不必要的:它正在发生,因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。

        

http CORS options请求(预检请求)详解

一、跨域资源共享 CORS简介

整个CORS通信过程,都是浏览器自动完成,不需要用户参与。

实现CORS通信的关键是服务器。只要服务器实现了CORS接口,就可以跨源通信。

OPTIONS请求即预检请求,可用于检测服务器允许的http方法。当发起跨域请求时,由于安全原因,触发一定条件时浏览器会在正式请求之前自动先发起OPTIONS请求,即CORS预检请求,服务器若接受该跨域请求,浏览器才继续发起正式请求。

preflight,一个cors预检请求,属于options请求。该请求会在浏览器认为即将要执行的请求可能会对服务器造成不可预知的影响时,由浏览器自动发出

利用预检请求,浏览器能够知道当前的服务器是否允许执行即将要进行的请求,只有获得了允许,浏览器才会真正执行接下来的请求。…

HTTP/2 与 HTTP/3:比较

HTTP(超文本传输​​协议)是万维网所基于的应用层传输协议。最初在 80 年代后期构思为基于单行文本的协议,最初记录为HTTP/0.9,其第一个全功能迭代(v. 1.0)于 1996 年在RFC 1945中记录。

随着互联网的使用和期望的增长,改进 HTTP 本身的需求也在增长。1.1 版在 1997 年的RFC 2068和 1999 年的RFC 2616中记录,随后在 2014 年的 RFC (7230-7235) 中记录了 — 整整十年半之后!— 记录消息语法/路由;语义/内容;条件和范围请求;缓存;和认证。…

            

HTTP2 下的 Transfer-Encoding: chunked

在 HTTP 中传输数据有一个 chunked 的方式, 又称“分块传输”。在响应报文里用头字段Transfer-Encoding: chunked 来表示。意思是报文里的 body 部分不是一次性发过来的,而是分成了许多的块(chunk)逐个发送。而 HTTP2.0 协议作为 HTTP协议的升级,自然是对chunked模式做支持?不然!

HTTP2 是没有 chunked 的!

分块传输也可以用于“流式数据”,例如由数据库动态生成的表单页面,这种情况下 body 数据的长度是未知的,无法在头字段“Content-Length”里给出确切的长度,所以也只能用 chunked 方式分块发送。

chunked 的编码规则

  • 每个分块包含两个部分,长度头和数据块;
  • 长度头是以 CRLF(回车换行,即rn)结尾的一行明文,用 16 进制数字表示长度;
  • 数据块紧跟在长度头后,最后也用 CRLF 结尾,但数据不包含 CRLF;
  • 最后用一个长度为 0 的块表示结束,即“0rnrn”

HTTP2 下的分块传输

先说结论,HTTP2 是不支持 

构建 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