Internet

How does the Internet work？

• 互联网是一个由相互连接的计算机组成的全球网络，它使用一套标准的通信协议来交换数据。
• 互联网使用 IP 和 TCP 等标准化协议将设备和计算机系统连接在一起。
• 互联网的核心是由相互连接的路由器组成的全球网络，这些路由器引导不同设备和系统之间的通信。
• 您需要熟悉的基本概念和术语包括数据包、路由器、IP 地址、域名、DNS、HTTP、HTTPS 和 SSL/TLS。
• 协议在实现互联网通信和数据交换方面起着至关重要的作用，它允许不同制造商和供应商的设备和系统进行无缝通信。

What is HTTP？

HTTP 是一种基于 TCP/IP 的应用层通信协议，它规范了客户端和服务器之间的通信方式。它定义了如何在互联网上请求和传输内容。我所说的应用层协议，是指它只是一个抽象层，规范了主机（客户端和服务器）的通信方式。HTTP 本身依赖于 TCP/IP 来获取客户端和服务器之间的请求和响应。默认情况下，使用 TCP 80 端口，但也可以使用其他端口。而 HTTPS 使用的是 443 端口。

TCP

三次握手在其最简单的形式中是指，在开始共享应用数据之前，客户端和服务器在TCP连接中共享一系列数据包。

• SYN - Client picks up a random number, let’s say x, and sends it to the server.
• SYN ACK - Server acknowledges the request by sending an ACK packet back to the client which is made up of a random number, let’s say y picked up by server and the number x+1 where x is the number that was sent by the client
• ACK - Client increments the number y received from the server and sends an ACK packet back with the number y+1

三方握手完成后，客户端和服务器之间的数据共享就可以开始了。需要注意的是，客户端可以在发出最后一个 ACK 数据包后立即开始发送应用数据，但服务器仍需等待收到 ACK 数据包才能满足请求。

HTTP/2

1. Binary Protocol

每个 HTTP/2 请求和响应都有一个唯一的流 ID，并被划分为若干帧。帧只是二进制数据块。帧的集合称为流。每个帧都有一个流 ID，用来标识所属的流，每个帧都有一个共同的头。此外，除了流 ID 唯一之外，值得一提的是，客户端发起的任何请求都使用奇数流 ID，而服务器的响应则使用偶数流 ID。

除了 HEADERS 和 DATA 之外，我认为值得一提的另一种帧类型是 RST_STREAM，它是一种特殊的帧类型，用于中止某些流，即客户端可以发送此帧，让服务器知道我不再需要此流了。在 HTTP/1.1 中，让服务器停止向客户端发送响应的唯一方法是关闭连接，这会导致延迟增加，因为任何连续请求都必须打开新的连接。而在 HTTP/2 中，客户端可以使用 RST_STREAM，停止接收特定流，同时连接仍将打开，其他流仍将发挥作用。

2. Multiplexing（多路复用）

由于 HTTP/2 现在是二进制协议，而且正如我在上文所说，它使用帧和流来处理请求和响应，因此一旦打开 TCP 连接，所有流都会通过同一连接异步发送，而无需打开任何其他连接。反过来，服务器也以同样的异步方式做出响应，即响应没有顺序，客户端使用指定的流 id 来识别特定数据包所属的流。这也解决了 HTTP/1.x 中存在的head-of-line 阻塞问题，即客户端无需等待耗时的请求，而其他请求仍在处理中。

3.报头压缩

这是一个单独的 RFC 的一部分，专门用于优化发送的报头。其本质是，当我们不断地从同一个客户端访问服务器时，就会在报头中重复发送大量冗余数据，有时可能会有 cookie 增加报头的大小，从而导致带宽占用和延迟增加。为了克服这一问题，HTTP/2 引入了报头压缩技术。

与请求和响应不同的是，头并不是以 gzip 或 compress 等格式压缩的，而是采用了一种不同的头压缩机制，即使用哈夫曼编码对字面值进行编码，并由客户端和服务器维护一个头表，客户端和服务器在后续请求中省略任何重复的头（如用户代理等），并使用双方维护的头表来引用它们。

说到标头，我想补充一点，除了增加了一些伪标头（即 : :method, :scheme, :host and :path）外，标头仍然与 HTTP/1.1 相同。

4.服务器推送

服务器推送是 HTTP/2 的另一个强大功能，服务器在知道客户端将请求某个资源后，可以在客户端不提出请求的情况下将其推送给客户端。例如，假设浏览器加载了一个网页，它会解析整个页面，找出需要从服务器加载的远程内容，然后向服务器发送相应请求以获取该内容。

服务器推送可让服务器通过推送它知道客户将需要的数据来减少往返次数。具体做法是，服务器发送一个名为 PUSH_PROMISE 的特殊帧，通知客户端："嘿，我正要把这个资源发送给你！请不要向我索取"。PUSH_PROMISE 帧与导致推送发生的流相关联，它包含承诺的流 ID，即服务器将发送待推送资源的流。

5.请求优先级

客户端可通过在打开数据流的 HEADERS 帧中加入优先级信息，为数据流指定优先级。在其他任何时候，客户端都可以发送 PRIORITY 帧来更改数据流的优先级。

在没有任何优先级信息的情况下，服务器会异步处理请求，即不分先后顺序。如果为某个数据流分配了优先级，服务器就会根据优先级信息来决定处理哪个请求需要多少资源。

6.安全性

关于 HTTP/2 是否应强制规定安全性（通过 TLS），与会者进行了广泛的讨论。最终，会议决定不做强制要求。不过，大多数供应商表示，只有在通过 TLS 使用 HTTP/2 时，他们才会支持 HTTP/2。因此，虽然 HTTP/2 在规格上并不要求加密，但无论如何，它已成为默认的强制要求。既然如此，HTTP/2 通过 TLS 实现时确实会有一些要求，例如必须使用 1.2 或更高版本的 TLS，必须有一定级别的最小密钥大小，需要短时密钥等。

目前已经更新到使用TLS1.3了

HTTP/3

QUIC1

个人理解

没有介绍的那么离谱增速，即便是减少握手次数，仍然会因为安全性产生问题，并且只比TCP+TLS1.3快一个握手。

然后对于包丢失的改进，对于round-robin可能有比较好的效果，但是round-robin的加载缓慢会极大提升用户的不满，即现在大多使用顺序传输，所以可能大部分情况下和TPC是没有太大区别。

连接迁移的情境性过强，也没有什么增速。

虽然可能对于一般用户这没有什么更快的效果，但是对于高速网络和慢速网络的用户可能确实能产生巨大提升。

个人感觉最大优势就是它（开源）且可以在客户端，而不是在服务端去更改，可以去不断的改进；而TPC相对来说还是比较难以发生变化的，它一般在OS的内核中实现。

更快的演进和更高的灵活性是 QUIC（以及 HTTP/3）的核心内容。

QUIC2

2023年5月刚出，挖个坑以后填。

What is a domain name？

域名即人能理解的这种英文名，例如google.com ，DNS解析域名给出IP地址，再通过IP地址访问到网页。总不能有人想要记IP地址吧哈哈哈。

下面给出MDN的图，清晰易懂。

What is hosting？

网络托管，或是虚拟主机。

• 第一种共享托管，就是一堆人用一台机子，如果黑客攻击别人的网站，你的也会崩（便宜，适合新手，但是性能最差）
• VPS 这个就比上面的高级一些，虽然都是用同一台，但是你的空间是分出来了，类似一个虚拟的电脑，大家都是独立的，同台机子的别人崩了，你不会。价格比上面的贵
• 托管VPS 这个托管不托管就是类似有没有给你搭好那种（可以适合萌新一键搭建这种，不需要从零自己配置。）价格更贵嘛就是。
• 整个专属的服务器，不需要多讲。

DNS and how it works？

Domain Name System (DNS)

步骤

0. 用户在网络浏览器中键入 "example.com"，该查询会进入互联网，并被 DNS 递归解析器接收。

1. 解析器然后查询 DNS 根名称服务器（.）。

2. 然后，根服务器向解析器回复顶级域 (TLD) DNS 服务器（如 .com 或 .net）的地址，该顶级域存储其域的信息。在搜索 example.com 时，我们的请求指向 .com TLD。

3. 解析器会向 .com TLD 发出请求。

4. 然后，TLD 服务器响应域名服务器 example.com 的 IP 地址。

5. 最后，递归解析器向域名服务器发送查询。

6. 然后，域名服务器会向解析器返回 example.com 的 IP 地址。

7. 然后，DNS 解析器向网络浏览器回复最初请求的域名 IP 地址。

   DNS 查询的 8 个步骤返回 example.com 的 IP 地址后，浏览器就可以发出网页请求：

8. 浏览器向 IP 地址发出 HTTP 请求。

9. 该 IP 的服务器返回网页，并在浏览器中呈现（第 10 步）。

图片来自What is DNS? | How DNS works | Cloudflare

DNS 查询有哪些类型？

在典型的 DNS 查询中，会出现三种类型的查询。通过组合使用这些查询，DNS 解析的优化过程可以缩短查询距离。在理想情况下，缓存记录数据可用，允许 DNS 名称服务器返回非递归查询。

3 种 DNS 查询：

0. 递归查询 - 在递归查询中，DNS 客户端要求 DNS 服务器（通常是 DNS 递归解析器）向客户端提供所请求的资源记录，或者在解析器找不到记录时提供错误信息。
1. 迭代查询 - 在这种情况下，DNS 客户端将允许 DNS 服务器返回其所能提供的最佳答案。如果被查询的 DNS 服务器没有与查询名称匹配的记录，它将把查询结果转发给域名空间较低层次的权威 DNS 服务器。然后，DNS 客户端将向转介地址进行查询。这一过程在查询链下的其他 DNS 服务器上继续进行，直到出现错误或超时为止。
2. 非递归查询 - 通常发生在 DNS 解析器客户端查询 DNS 服务器的记录时，因为该服务器对该记录具有权威性，或者该记录存在于其缓存中。通常情况下，DNS 服务器会缓存 DNS 记录，以防止额外的带宽消耗和上游服务器的负载。

What is DNS caching? Where does DNS caching occur?

缓存的目的是将数据临时存储在某个位置，从而提高数据请求的性能和可靠性。DNS 缓存涉及将数据存储在离请求客户端更近的位置，这样就能更早地解决 DNS 查询，避免在 DNS 查找链的更深处进行额外查询，从而缩短加载时间并减少带宽/CPU 消耗。DNS 数据可以缓存在不同的位置，每个位置都会在一定时间内存储 DNS 记录，具体时间由存活时间（TTL）决定。

Browser DNS caching

现代网络浏览器的默认设置是在一定时间内缓存 DNS 记录。这样做的目的显而易见：DNS 缓存离网络浏览器越近，检查缓存和向 IP 地址发出正确请求所需的处理步骤就越少。当请求 DNS 记录时，浏览器缓存会首先检查所请求记录的位置。

在 Chrome 浏览器中，您可以访问 chrome://net-internals/#dns 查看 DNS 缓存的状态。

Operating system (OS) level DNS caching

操作系统级 DNS 解析器是 DNS 查询离开机器前的第二站，也是最后一站。操作系统中用于处理该查询的进程通常称为 "存根解析器 "或 DNS 客户端。当存根解析器收到应用程序的请求时，它会首先检查自己的缓存，看是否有记录。如果没有，它就会在本地网络之外向互联网服务提供商（ISP）内部的 DNS 递归解析器发送 DNS 查询（设置递归标志）。

ISP 内部的递归解析器收到 DNS 查询后，也会像之前的所有步骤一样，检查请求的主机到 IP 地址转换是否已存储在本地持久层中。

递归解析器还具有其他功能，具体取决于其缓存中的记录类型：

0. 如果解析器没有 A 记录（DNS A 记录指向给定域名的 IP 地址），但有权威名称服务器的 NS 记录（NS 代表“域名服务器”，域名服务器记录指示哪个 服务器包含实际 DNS 记录），它将直接查询这些名称服务器，从而绕过 DNS 查询中的几个步骤。这一快捷方式可避免从根名称服务器和 .com 名称服务器（在我们搜索 example.com 时）进行查询，有助于更快地解决 DNS 查询。
1. 如果解析器没有 NS 记录，它将跳过根服务器，向 TLD 服务器（本例中为.com）发送查询。
2. 万一解析器没有指向 TLD 服务器的记录，它就会查询根服务器。这种情况通常发生在 DNS 缓存被清除之后。

Browser and how they work？

导航

导航是加载 web 页面的第一步。它发生在以下情形：用户通过在地址栏输入一个 URL、点击一个链接、提交表单或者是其他的行为。

Web 性能优化的目标之一就是缩短导航完成所花费的时间，在理想情况下，它通常不会花费太多的时间，但是等待时间和带宽会导致它的延时。

DNS查询

通过DNS查询到IP地址

TCP握手

通过TCP三次握手与IP地址建立连接

TLS协商

为建立安全连接（HTTPS），通过TLS再来一次握手

响应

浏览器请求数据。首字节时间（TTFB）是用户通过点击链接进行请求与收到第一个 HTML 数据包之间的时间。第一个内容分块通常是 14KB 的数据。

解析

一旦浏览器收到数据的第一块，它就可以开始解析收到的信息。“解析”是浏览器将通过网络接收的数据转换为 DOM 和 CSSOM 的步骤，通过渲染器把 DOM 和 CSSOM 在屏幕上绘制成页面。

DOM 是浏览器标记的内部表示。DOM 也是被暴露的，可以通过 JavaScript 中的各种 API 进行 DOM 操作。

即使请求页面的 HTML 大于初始的 14KB 数据包，浏览器也将开始解析并尝试根据其拥有的数据进行渲染。这就是为什么在前 14KB 中包含浏览器开始渲染页面所需的所有内容，或者至少包含页面模板（第一次渲染所需的 CSS 和 HTML）对于 web 性能优化来说是重要的。但是在渲染到屏幕上面之前，HTML、CSS、JavaScript 必须被解析完成。

渲染

渲染步骤包括样式、布局、绘制，在某些情况下还包括合成。在解析步骤中创建的 CSSOM 树和 DOM 树组合成一个渲染树，然后用于计算每个可见元素的布局，然后将其绘制到屏幕上。在某些情况下，可以将内容提升到它们自己的层并进行合成，通过在 GPU 而不是 CPU 上绘制屏幕的一部分来提高性能，从而释放主线程。

交互

一旦主线程绘制页面完成，你会认为我们已经“准备好了”，但事实并非如此。如果加载包含 JavaScript（并且延迟到 onload 事件触发后执行），则主线程可能很忙，无法用于滚动、触摸和其他交互。

可交互时间（TTI） (en-US)是测量从第一个请求导致 DNS 查询和 SSL 连接到页面可交互时所用的时间——可交互是 First Contentful Paint (en-US) 之后的时间点，页面在 50ms 内响应用户的交互。如果主线程正在解析、编译和执行 JavaScript，则它不可用，因此无法及时（小于 50ms）响应用户交互。

小结

学习基础知识的同时也了解新技术，文章大多为翻译，待以后有更深理解后再自己写，现在写不出东西，大致一些简单的总结可以让自己可以更快回顾。