缓存您的 CORS，以提高性能和利润
CORS 是许多 API 所必需的，但基本配置会产生大量额外请求，从而减慢每个浏览器 API 客户端的速度，并向您的后端发送不必要的流量。
这可能是传统 API 的问题，但在无服务器平台上会成为一个更大的问题，在无服务器平台上，您的账单通常直接与收到的请求数量挂钩，因此这很容易使您的 API 成本翻倍。
所有这些都是不必要的：它正在发生，因为您不知道缓存如何为 CORS 请求工作。让我们解决这个问题。…
重新理解 Web
本文是我最近在字节内部做的分享《重新理解 Web，才能迈向███》的第一章节
到底什么是 Web？要回答这个问题，需要先理解 Web 的三要素：
- Web Runtime
- 前端技术
- URL
1.1 Web Runtime
第一个核心要素是「Web Runtime」，基于 Web 的内容或应用，本质上都是一种用高度抽象的方式来实现、分发和运行的客户端软件，需要建立在一个非常 high level 的软件抽象层（abstraction layer）上，这个抽象层就是「Web Runtime」。
提供「Web Runtime」的客户端技术，可以分为这么四类：
- 传统浏览器：一种应用层的 Web 平台，在桌面平台上是主流，比如 Chrome、Safari、Edge
- PWA（Progressive Web App）：基于 OS 层的
Kubernetes（K8s）基本概念
Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，简称“K8s”或者“Kube”。Kubernetes 最初由 Google 的工程师开发和设计，Google 是最早研发 Linux 容器技术的企业之一，曾公开分享介绍 Google 云服务背后的技术- 如何将一切都运行于容器之中。Google 每周会启用超过 20 亿个容器全都由内部平台 Borg 支撑。Borg 是 Kubernetes 的前身，多年来开发 Borg 的经验教训成了影响 Kubernetes 中许多技术的主要因素。
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) 中记录了 — 整整十年半之后！— 记录消息语法/路由；语义/内容；条件和范围请求；缓存；和认证。…
polyfill、ponyfill、prollyfill傻傻分不清楚
一、ponyfill是什么？
偶然进入谷歌实验室的Browser-FS-Access项目，这个项目使用 File System Access API 实现文件上传现在，对于不支持文件系统访问API的浏览器使用 <input type="file"> 和 <a download> 进行优雅降级。
这不是重点，重点是我在如此官方的项目中又一次见到了这个名字——ponyfill！
…
http 103 Early Hints (早期提示)：它是什么以及如何实现它
WebSocket介绍
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 协议的?
目前主流的 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、https、RTSP、RTMP等常见默认端口大全
| 端口 | 说明 |
|---|---|
| 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服务器所开放的端口，用于发送邮件 |
从一次经历谈 TIME_WAIT 的那些事
今天来讲一讲TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe 有关，我先说说这个场景里的问题，然后，顺着这个场景跟大家好好说一下这个事。…
近期评论