缓存您的 CORS,以提高性能和利润
CORS 是许多 API 所必需的,但基本配置会产生大量额外请求,从而减慢每个浏览器 API 客户端的速度,并向您的后端发送不必要的流量。
这可能是传统 API 的问题,但在无服务器平台上会成为一个更大的问题,在无服务器平台上,您的账单通常直接与收到的请求数量挂钩,因此这很容易使您的 API 成本翻倍。
所有这些都是不必要的:它正在发生,因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。…
记录-交流-Web开发知识分享
CORS 是许多 API 所必需的,但基本配置会产生大量额外请求,从而减慢每个浏览器 API 客户端的速度,并向您的后端发送不必要的流量。
这可能是传统 API 的问题,但在无服务器平台上会成为一个更大的问题,在无服务器平台上,您的账单通常直接与收到的请求数量挂钩,因此这很容易使您的 API 成本翻倍。
所有这些都是不必要的:它正在发生,因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。…
本文是我最近在字节内部做的分享《重新理解 Web,才能迈向███》的第一章节
到底什么是 Web?要回答这个问题,需要先理解 Web 的三要素:
第一个核心要素是「Web Runtime」,基于 Web 的内容或应用,本质上都是一种用高度抽象的方式来实现、分发和运行的客户端软件,需要建立在一个非常 high level 的软件抽象层(abstraction layer)上,这个抽象层就是「Web Runtime」。
提供「Web Runtime」的客户端技术,可以分为这么四类:
Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,简称“K8s”或者“Kube”。Kubernetes 最初由 Google 的工程师开发和设计,Google 是最早研发 Linux 容器技术的企业之一,曾公开分享介绍 Google 云服务背后的技术- 如何将一切都运行于容器之中。Google 每周会启用超过 20 亿个容器全都由内部平台 Borg 支撑。Borg 是 Kubernetes 的前身,多年来开发 Borg 的经验教训成了影响 Kubernetes 中许多技术的主要因素。
HTTP(超文本传输协议)是万维网所基于的应用层传输协议。最初在 80 年代后期构思为基于单行文本的协议,最初记录为HTTP/0.9,其第一个全功能迭代(v. 1.0)于 1996 年在RFC 1945中记录。
随着互联网的使用和期望的增长,改进 HTTP 本身的需求也在增长。1.1 版在 1997 年的RFC 2068和 1999 年的RFC 2616中记录,随后在 2014 年的 RFC (7230-7235) 中记录了 — 整整十年半之后!— 记录消息语法/路由;语义/内容;条件和范围请求;缓存;和认证。…
偶然进入谷歌实验室的Browser-FS-Access项目,这个项目使用 File System Access API 实现文件上传现在,对于不支持文件系统访问API的浏览器使用 <input type="file">
和 <a download>
进行优雅降级。
这不是重点,重点是我在如此官方的项目中又一次见到了这个名字——ponyfill!
…
WebSocket:是一种计算机通信协议,通过单个TCP连接提供全双工通信通道。IETF于 2011 年将 WebSocket 协议标准化为RFC 6455。当前允许 Web 应用程序使用该协议的 API 规范称为WebSockets。[1]它是由WHATWG维护的活跃标准,也是W3C的 WebSocket API的继承者。[2]
WebSocket 与HTTP不同。这两种协议都位于OSI 模型的第 7 层,并依赖于第 4 层的 TCP。尽管它们不同,但RFC 6455声明 WebSocket“旨在通过 HTTP 端口 443 和 80 工作以及支持 HTTP 代理和中介” ,从而使其与 HTTP 兼容。为了实现兼容性,WebSocket握手使用HTTP Upgrade 标头将 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
端口 | 说明 |
---|---|
0 | 无效端口,通常用于分析操作系统 |
1 | 传输控制协议端口服务多路开关选择器 |
2 | 管理实用程序 |
3 | 压缩进程 |
5 | 远程作业登录 |
7 | 回显 |
9 | 丢弃 |
11 | 在线用户 |
13 | 时间 |
17 | 每日引用 |
18 | 消息发送协议 |
19 | 字符发生器 |
20 | FTP文件传输协议(默认数据口) |
21 | FTP文件传输协议(控制) |
22 | SSH远程登录协议 |
23 | telnet(终端仿真协议),木马Tiny Telnet Server开放此端口 |
24 | 预留给个人用邮件系统 |
25 | SMTP服务器所开放的端口,用于发送邮件 |
今天来讲一讲TCP 的 TIME_WAIT
的问题。这个问题尽人皆知,不过,这次遇到的是不太一样的场景,前两天也解决了,正好写篇文章,顺便把 TIME_WAIT
的那些事都说一说。对了,这个场景,跟我开源的探活小工具 EaseProbe 有关,我先说说这个场景里的问题,然后,顺着这个场景跟大家好好说一下这个事。…
近期评论