一次HTTP请求发生了什么

这里以访问Google.com举例子。

https://xiaolincoding.com/network/1_base/what_happen_url.html

HTTP

首先是对URL进行解析，从而生成发送给web服务器的信息。

HTTP分为了三个部分，

请求报文中分为：请求行，请求头，请求体。

响应报文中：状态行，消息头，消息体。

其中，请求行定义了HTTP的版本。

浏览器输入了URL之后，并不一定立即发网络请求，浏览器自身会判断输入的是URL还是搜索词。URL规范化，补全协议。

HSTS：可能直接把http升级为https

HSTS（HTTP Strict Transport Security）可以理解为：网站告诉浏览器：“以后访问我，只准用 HTTPS，别再尝试 HTTP。”

当浏览器缓存命中时，可能根本不访问浏览器。

DNS

在发送HTTP请求之前，需要根据服务器域名查询对应的IP地址。如果本地有DNS的缓存，则可以省去这一次请求。

DNS不一定只用UDP，响应过大，截断的情况下，可能回退到TCP。

DNS中的域名是通过句点来划分的，越右边代表层级越高。（因为这是外国人发明的，外国人写地址的时候喜欢从小地址说到大地址，而中国人相反）

Happy Eyeballs 是一种网络连接优化机制，主要用来解决设备同时支持 IPv6 和 IPv4 时，因为某一条网络路径异常而导致“连接卡很久”的问题。简单来说，IPv6和V4谁先连上就用谁。

DNS是一个树形结构。

根DNS服务器，顶级DNS服务器，权威DNS服务器。根域的DNS服务器信息保存在互联网中所有的DNS服务器中。这样以来任何DNS服务器就都可以找到并访问根域的DSN服务器了。

客户端首先会发送一个DNS请求（客户端TCP/IP）设置中填写的DNS服务器地址。本地DNS服务器如果找不到到，会继续向上查找。比如google.com这个域名是归com这个顶级域名服务器管理的。该请求被交给google.com在干活子区域服务器。

最后本地服务器根据区域服务器地址得到了www.google.com的地址。DNS中存在缓存，浏览器会先去看自身有没有这个域名的缓存。如果有就返回，如果没有就去问操作系统。操作系统， 本地DNS服务器也会有自己的缓存。

DNS协议是跑在UDP上的，UDP是跑在IP上的。这个请求可能出现丢失，这种情况下，客户端要重新发起一次DNS查询。

假设拿到了IP 69.171.235.22。

协议栈

通过DNS获取到IP之后，就可以把HTTP的传输工作交给操作系统的协议栈。

这里对应了TCP/IP协议中的五层，

操作系统的协议栈负责把应用程序的数据，按照网络协议，一层层封装后发出去。再一层层解析，最终交给应用层操作系统内核里的TCP、UDP、IP，统称为协议栈。

TCP/IP的层是逻辑上的协议分层；操作系统协议栈是这些协议层的一种具体实现，天然可以跨越多层。

浏览器的service worker：浏览器里独立于网页运行的后台脚本，在网页和网络之间，可以拦截请求，决定读缓存还是走网络。还能做离线访问，推送通知，后台同步等事情。多个TAB的请求经过浏览器统一网络栈后，可能命中同一个连接池，从而复用一条TCP连接。

TCP

HTTP是基于TCP协议的。

TCP无论是三次握手，四次回收，数据包，ACK。都是采用这种模式。

HTTP虽然是无状态的，但是它的建立是在有状态的TCP上的。

TLS是SSL的后继版本，都用与在网络中实现加密身份认证和数据完整性保护。

此外，因为访问的是google.com，我们还需要额外的进行TLS的握手。

客户端                          服务器
  | ---- SYN ----------------> |
  | <--- SYN + ACK ----------- |
  | ---- ACK ----------------> |   TCP 三次握手完成
  |
  | ---- ClientHello --------> |
  | <--- ServerHello/... ----- |
  | ---- Key Exchange/... ---> |
  | <--- Finished ------------ |   TLS 握手完成
  |
  | ---- HTTP 请求 -----------> |
  | <--- HTTP 响应 ----------- |

TLS1.2 通常需要2RTT。TLS1.3通常只需要1RTT，比TLS1.2快很多。

如果是HTTP3，使用QUIC协议，不适用TCP，而是吧传输层和TLS握手结合起来，通常还能进一步减少握手延迟。HTTP3需要跑在HTTPS上，因此默认也是443端口。

TCP三次握手的第三次，客户端直接发ACK时，可以同时携带应用层数据。因此理论上只需要一个额外的RTT就可以发送数据。

如果HTTP请求的消息比较长，超过了MSS的长度，这时候TCP需要把HTTP数据拆成一块块的数据发送，而不是一次性发送所有数据。

• MTU一个网络包的最大长度，以太网中一般为1500字节
• MSS：去除IP和TCP头部之后，一个网络包能容纳的TCP数据最大程度。

数据会被以MSS的程度为单位进行拆分，拆分出来的每一块数据都会被放进单独的网络保重。也就是在每个被拆分的数据加上TCP头部信息，然后交给IP层发送数据。

HTTP中涉及到了TCP的俩个端口，一个是浏览器用来发送数据的端口，这个端口是随机的，另一个是web服务器监听的端口号，http默认是80，https默认是443.浏览器会根据http还是https来决定访问80端口还是443端口。

TCP报文交给网络层，也就是IP协议来进行处理。

IP

TCP模块在进行连接，收发，断开等操作时，都需要委托IP模块将数据封装成网络包发送给通信对象。（DNS底层的UDP也是一样的）

IPv4 每个数据包基本都要带上这些首部字段，但它们不完全算“没用的冗余”，而是为了让网络中的每一台路由器都能独立处理这个包。

但如果一次传输的是一个 1500 字节左右的以太网包，IPv4 的 20 字节只占约 1.3%，开销就不明显了。IP是一种无连接数据包协议，每个IP包都涉及成可以被独立转发。中间路由器一般不需要记住“前一个包是谁的。

IPv6 的基础首部反而固定成了 40 字节，比 IPv4 最小的 20 字节更大，但把分片、首部校验和等东西简化或移走了，让路由器处理起来更简单、更快。

因为HTTP是通过TCP传输的，所以在IP包头的协议号，要填写为06（16进制），表示协议为TCP。

当存在多个网卡时，填写源IP地址时，就需要判断到底应该填写哪个地址。应该使用哪一个网卡来发送包。如果发现网卡和目标地址在一个子网，优先使用那个网卡发送数据。

比如一台机器有：

eth0: 192.168.1.10
eth1: 10.0.0.10

路由表类似：

default via 192.168.1.1 dev eth0 metric 100
default via 10.0.0.1 dev eth1 metric 200
10.0.0.0/24 dev eth1
192.168.1.0/24 dev eth0

当你请求：

https://www.example.com

大致过程是：

域名解析
   ↓
得到目标公网 IP，例如 93.184.216.34
   ↓
内核查路由表
   ↓
匹配 93.184.216.34 的路由
   ↓
没有更具体路由 → 匹配 default
   ↓
比较 metric / priority
   ↓
选择 default via 192.168.1.1 dev eth0
   ↓
HTTP/TCP 流量从 eth0 发出去

也就是说，在上面的例子里，通常会走 eth0，因为它的默认路由优先级更高（Linux 中一般是 metric 越小优先级越高）。

可以把判断规则粗略理解成：

1. 最长前缀匹配优先：例如目标 10.0.0.50 会直接匹配 10.0.0.0/24，走 eth1，不会走默认路由。
2. 如果有多条同样具体的路由，再比较 metric、priority 等属性。
3. 如果配置了策略路由，还可能根据源 IP、fwmark、用户、接口等选择不同路由表。
4. 最后选中的路由中 dev eth0 / dev eth1 才真正决定出口网卡。

IP 协议本身并不要求底层一定是以太网、Wi-Fi、光纤之类的东西。它只要求底层能把一串数据从一个节点送到另一个节点。所以只要你能规定：

“把 IP 数据报写进存储介质 → 绑在信鸽腿上 → 信鸽飞到目的地 → 读取数据 → 继续转发”

那信鸽就可以充当 IP 的“链路层”。这件事还有一个著名的恶搞标准：RFC 1149《A Standard for the Transmission of IP Datagrams on Avian Carriers》，即“通过鸟类载体传输 IP 数据报的标准”。后来还真有人用信鸽携带数据做过实验。

它的特点会非常极端：延迟巨大、抖动巨大、丢包方式很有生物学特色，但带宽未必低。 比如一只鸽子带一张 1 TB 的存储卡，飞 1 小时，平均“吞吐量”约等于 2.2 Gbit/s。只不过你发一个 ping，可能一两个小时后才回来。

MAC

生成了IP头部之后，接下来网络包还需要在IP头部上面加MAC头部。MAC头部是以太网使用的头部，它包含了接收方和发送方的地址信息。

一般在TCP/IP通信里，MAC包头的协议类型只使用

• 0800：IP协议
• 0806：ARP协议

发送方的MAC地址是在网卡生产时写到ROM里的，只要将这个值读取出来写到MAC头部就可以了。

接受方地址则通过ARP协议，广播获取。

ARP协议也是操作系统网络协议栈的一部分。作用是把Ipv4地址转化为mac地址。

这里客户端会根据自己的IP，子网掩码判断（拿目标IP和自己IP对子网掩码做安位与运算，判断是不是和自己一个网段的）。

比如子网掩码是255.255.255.0的情况下，只有最后的三个数字才是内网设备。

本机判断69.171.235.22。不在本地网段之后。发现默认网关是192.168.31.1。

然后ARP会去解析192.168.31.1对应的MAC地址。如果发现没有缓存过这个IP对应的MAC地址，ARP会通过局域网广播。FF:FF:FF:FF:FF:FF 表示以太网广播，所以同一广播域里的设备都会收到。所有设备检查目标IP，如果找的是自己就单播回复。

ARP工作在网络层（IP）和数据链路层（MAC）之间。

在链路层是没有IP地址的概念的，二层交换机在转发以太网帧时，不需要依赖IP地址。只需要根据自己的MAC地址表（CAM表）决定从哪个端口转发。

网卡

网络只是存放在内存中的二进制数字信号，没办法直接发送给对方。因此，我们要将数字信号转换为电信号，才能在物理上传输。负责执行这一操作的是网卡，要控制网卡还需要靠网卡驱动程序。网卡驱动程序获取网络包之后，会将其复制到网卡内的缓冲区中，接着在开头加上报头和起始帧分界符，在末尾加上用于检测错误的帧校验序列。

• 起始分界符是一个用来表示包起始位置的标记
• 末尾的FCS（帧校验序列）用来检查包传输过程中是否有损坏

最后网卡将包转换为电信号，通过网卡发送出去。

交换机

如果交换机A下面有B，C俩个交换机，B下设备要和C下设备通信。那么B下面很多MAC地址都对应同一个端口。这是正常现象。

交换机的设计是将网络包原样转发到目的地。普通交换机，核心工作是对以太网数据做二层转发，全程不会修改帧的源MAC地址和目的MAC地址；他工作在数据链路层，因此也被叫做2层网络设备。

首先，从终端发来的以太网电信号，会通过网线到达交换机的对应端口。交换机的端口物理芯片会先接受信号，把连续的电信号转换成能处理的数字信号。

随后，交换机会通过帧末尾的FCS（帧校验序列）检查数据有没有在传输的过程中出错，如果校验失败会直接丢弃这个帧，校验无误的话，就把完整的以太网帧存入这个端口的接收区和缓冲区。交换机不会核对数据帧的目的MAC地址，只要是通过合法校验的帧全部手下放入缓冲区。把帧存入缓冲区之后，交换机会立即检查自己的MAC地址表，看看这个帧的目的MAC地址有没有对应的记录。

交换机的MAC地址表主要包含俩个信息。

• 局域网内设备的MAC地址
• 这个终端设备在交换机的哪个端口上

交换机根据MAC地址表找到MAC地址，然后将信号发送到相应的端口。

如果MAC地址表中找不到指定的MAC地址，可能是因为具有该地址的设备还没有向交换机发送过包，或者这个设备有一段时间没工作导致地址被从地址表中删除了。这种情况下，交换机无法判断把包发送到哪个端口，只能把包转发到除了源端口之外的所有端口上，无论该设备在哪个端口上都能收到该包。这样做不会产生什么问题，因为以太网的设计本来就是将包发送到整个网络的，只有相应的接受者才接收包，其他设备会忽略这个包。

发送了包之后目标设备会做出想要，支援哦返回了响应包，交换机就可以将它的地址写入MAC地址表，下次就不需要把包发到所有端口了。

如果接收方MAC地址是一个广播地址，那么交换机会将包发送到除源端口之外的所有端口。广播地址有

• MAC地址中的：FF:FF:FF:FF:FF:FF
• IP地址中的255.255.255.255

路由器

NAT

电脑：
192.168.1.10:50000

家用路由器公网 IP：
203.0.113.5

访问网站：
142.250.72.14:443

这个包到达路由器后，路由器发现192.168.1.10是私网地址，不能直接在公网internet上路由。于是NAT模块会改写这个包。

最常见的家庭网络使用的是NAPT、PAT，所以他通常会同时修改IP和端口。因此几十台，甚至几百台的内网设备，可以共享一个公网IPv4地址。

NAT的本质是IP层地址改写，因此通常被认为是网络层的功能。为什么要改端口呢？因为假设俩个设备访问同一个网站，那么返回的数据包，路由器就不知道交换给哪个设备了。

家庭NAT是有状态的，因为他必须记住内网连接到公网连接的映射。Protocol | Source IP | Source Port | Destination IP | Destination Port

数据包在经过交换机完整终端之间的转发之后就会到达路由器。由它把数据包转发给外网的下一个路由器。路由器和交换机都是通过查表来决定数据包该发送到哪。最核心的区别是在网络层级和能力边界。

• 路由器是工作中网络层的三层设备，核心是基于IP地址做网络段转发的，俗称网络的出口大门。它的每个负责路由转发的端口，都有专属的MAC地址和IP地址，既能识别二层以太网真，也能处理三层的IP包。
• 普通二层交换机是工作在数据链路层的二层设备，核心是基于MAC地址做局域网的终端转发，俗称局域网的内部枢纽。每个物理端口都有自己的MAC地址，但是本身没有IP地址，只识别和处理以太网帧，不处理IP层的内容。交换机不会修改MAC地址。

路由器的端口具有MAC地址，因此他就能成为以太网的发送方和接收方；同时还具有IP地址，从这个意义上来说，它和计算机网卡是一样的。

当转发包时，路由器端口会接收发给自己的以太网包，然后路由表查询转发目标，再由相应端口作为发送方，将以太网包发送出去。

每次经过一次三层路由器IPv4的TTL-1，IPV6的Hop Limit -1，到0就丢弃（linux是64，Window是128））。

首先电信号到达网线接口部分，路由器中的模块会将电信号转换成数字信号，然后通过包末尾的FCS进行错误校验。

如果没问题，则检查MAC头部中的接收方MAC地址，看看是不是发给自己的包，如果是就留下，否则就丢弃。

完成接受操作后，路由器就会去掉包开的MAC头部。MAC头部的作用就是将包送达给路由器，其中的接收方MAC地址就是路由器的端口的MAC地址。因此，当包到达路由器之后，MAC头部的任务就完成了。于是MAC头部就会被丢弃。

接下来，路由器会根据MAC头部后方的IP头部中的内容进行包转发的操作。

转发操作先查询路由表判断转发目标

假设地址为10.10.1.101要向192.168.1.100的服务器发送一个包。路由器匹配和前面将的一亿元，每个条目的子网掩码和192.168.1.100 IP做与运算，得到结果与对应条目的目的地在进行匹配，如果匹配就会作为候选转发目标，如果不匹配就继续与下个条目进行路由匹配。实在找不到匹配路由时，就会选择默认路由，路由表中子网掩码为0.0.0.0 的记录表示默认路由。

路由器负责在不同子网之间转发数据包。在一般常见的家庭公司局域网中，默认网关就是路由器的某个接口地址。它负责把不是本子网的流量转发出去。

接下来就会进入包的发送操作，我们要根据路由表的关系列判断对方的IP地址。

• 如果路由表中的网关这一栏，填写了具体的下一跳的IP。那么这个IP只能是下一个路由器，所以这个包还没到最终目的地，要继续转发。
• 如果网关为空：说明这个目标网络和当前路由器是直连的，不需要再交给另一个路由器。此时就可以直接根据目标IP去查找设备。

假设路由器的IP路由表是

10.0.0.0/24 192.168.1.1
192.168.2.0/24 空

如果一个包要去10.0.0.8，网关有IP 192.168.1.1。那么路由器先发给192.168.1.1，让后续的路由器继续处理。如果一个包要去192.168.2.8，发现网关为空，就知道192.168.2.8直接连接在自己的网络上。

知道对方IP地址之后，需要通过ARP协议根据IP地址查询MAC地址，并将查询结果作为接收方的MAC地址。路由器也有ARP缓存，因此会受限在ARP缓存中查询路由器，如果找不到则发送ARP查询请求。

接下来是发送方的MAC地址，这里填输出端口的MAC地址。还有一个以太类型字段，填写0800（16进制）来表示IP协议。

网络包完成后，接下来会将其转换成电信号并通过端口发送出去。这一步的工作过程和计算机也是相同的。

发送出去的网络包会通过交换机到达下一个路由器。由于接收方的MAC地址就是下一个路由器的地址，所有交换机会根据这一地址将包传输到下一个路由器。

接下来，下一个路由器会将包再转发给下一个路由器，经过层层转发之后，网络包就到达了最终目的地。

在网络包的传输过程中，源IP和目标IP是不会变的，一直变化的是MAC地址，因为MAC地址在以太网俩个设备之间进行传输。

服务器和客户端

RX ring：网卡收到数据包后，放到这里，等待CPU驱动来处理

TX ring：内核准备好要发送到数据后，放到这里等待网卡取出并发出去

这个ring一般是放在主机内存中，由网卡和驱动共同使用。

数据包抵达服务器后，服务器会先扒开数据包的MAC头部，查看是否和自己的MAC地址符合，符合就将包收起来。接着继续扒开IP头，发现IP地址符合，根据IP头中协议项，知道自己上层是TCP协议。扒开TCP头，里面有序列号，如果是自己要的，就放入缓存中然后返回一个ACK，如果不是就丢弃。TCP头部里面还有端口号，HTTP服务器正在监听这个端口号。于是服务器自然就知道是HTTP进程想要这个包，将包发送给HTTP进程。

服务器里的HTTP进程看到，原来这个请求是要访问一个页面，于是就把这个页面封装在HTTP响应报文里。HTTP响应报文也要穿上TCP，IP，MAC头部，不过这次源地址是服务器的IP地址，目的地址是客户端IP地址。然后从网卡发送，交由交换机发送到出城的路由器，路由器把相应数据包发送到下一个路由器。最后调到了客户端所在的的路由器，路由器发给交换机，换机将数据转发到客户端。然后客户端开始扒开数据包，将收到的数据包只剩HTTP响应报文之后，交给浏览器去渲染页面。

VPN

默认

以Clash为例，其主要工作在应用层，但是在开启TUN模式后，会下沉到网络层来接管流量。

默认的系统代理模式下，只会在应用层工作。Clash会在本地启动一个代理服务器。同时告诉系统，把支持代理的应用流量

比如Chrome想访问https://google.com，Windows告诉chrome。HTTP/HTTPS 请求不要直接连 google.com，先连接本机代理 127.0.0.1:7890

然后chrome先通过7890端口和Clash简历连接。Clash收到之后，会解析目标地址，然后查询规则，假设规则命中代理，clash会自己创建一个新的socket。Clash通常不是把原来的TCP/IP数据包修改目的地址后继续抓饭出去。而是终止原来的连接，再创建一条新的连接。因此从TCP的角度来看，有俩条连接。

连接 1：

Chrome  ───── TCP ─────> Clash
        127.0.0.1:7890


连接 2：

Clash   ───── TCP ─────> Proxy Server
                         1.2.3.4:443

这俩个连接是在本机上完成的。远程的代理服务还要再简历连接

连接 3：

Proxy Server ───── TCP ─────> google.com:443

TUN模式

但是如果Clash开启TUN模式情况就会完全不一样了。此时Clash会拆跟腱一类虚拟网卡的接口比如

clash TUN Adapter

windows路由表被设置为

0.0.0.0/0
    ↓
Clash TUN

应用层完全不知道Clash的存在。0.0.0.0/0 代表没有更具体的路由匹配IPv4的流量。所以路由变成

应用 → Windows 网络栈 → Clash TUN → Clash 规则判断 → 代理 / 直连 → 互联网

他接管几乎所有程序的网络流量，不要求应用本身支持sockets或者http代理。能代理一些不走系统代理的程序，比如游戏，命令行，客户端程序。该模式覆盖范围更广。

不过 0.0.0.0/0 → Clash TUN 并不等于“所有流量最终都走代理”。它只是表示先交给 Clash；Clash 收到后仍然可以根据规则让某些流量直连。

不过Windows路由遵循最长前缀匹配。同时存在

0.0.0.0/0 → Clash TUN
192.168.1.0/24 → 本地网卡

访问 192.168.1.10 时，/24 比 /0 更具体，所以通常还是走本地局域网路由，而不是 TUN。

但是Clash并不是简单修改IP包。因为如果直接把DST IP从Google改成代理服务器，TCP会直接出问题，从原来的TCP

192.168.1.100:53123
        ↓
142.250.72.14:443

状态是

源 IP
源 Port
目标 IP
目标 Port

因此改了之后就不是同一条TCP了，因此Clash的行为是，

          原始连接
Chrome ─────────────> Clash 虚拟 TCP 栈
                         │
                         │ 解析出目标：
                         │ google.com:443
                         ↓
                    Clash Rule Engine
                         │
               ┌─────────┴─────────┐
               │                   │
            DIRECT               PROXY
               │                   │
               ↓                   ↓
        google.com:443       proxy:443

这个过程通常被叫做TCP interception或者TCP proxying

加密

TLS

笑话

Google 面试官最爱问的问题是：“请说明从在浏览器地址栏输入一个地址到显示网页的整个过程，越详细越好。”直到有一天，他遇到了一个来自中国的应聘者。

三个小时过去了，面试官已经汗流浃背，但应聘者仍在滔滔不绝地讲解 V2Ray 和 Hysteria 在加密和混淆方面的优缺点和区别，甚至连第一个 HTTP 请求都没有发出。

TLS1.2 通常需要2个RTT才能开始发HTTP。

第一轮主要在问，支持的TLS版本和密码套件，服务器回复证书和密钥交换参数。问题在于，客户端收到服务器的密钥交换参数后，才能继续完成密钥交换。

客户端                          服务端
  |                              |
  |---- ClientHello ------------>|  \
  |                              |   } RTT 1
  |<--- ServerHello              |  /
  |     Certificate              |
  |     ServerKeyExchange        |
  |     ServerHelloDone ---------|
  |                              |
  |---- ClientKeyExchange ------>|  \
  |     ChangeCipherSpec          |   } RTT 2
  |     Finished                  |  /
  |<--- ChangeCipherSpec --------|
  |     Finished                  |
  |                              |
  |==== HTTP Request ===========>|

TLS1.3中直接压缩为一个RTT。

在TLS1.3中，客户端不再只是说，我支持这些算法你选一个，而是说，我支持这些算法。顺便这是我的密钥交换参数。

比如客户端直接带一个X25519的临时公钥，服务器收到后，如果接受这个参数就可以。

1. 直接返回自己的 Key Share
2. 双方立刻算出共享密钥
3. 服务器直接发送 Certificate / Finished
4. 客户端收到以后验证完成，就可以发送 HTTP 数据

1.2

第一轮：
客户端：我们用什么方法加密？
服务器：用 X。

第二轮：
客户端：好，那这是我的密钥材料。
服务器：收到，密钥建立好了。

1.3

第一轮：
客户端：我们可以用 X/Y/Z。
       我猜你大概率用 X，
       所以 X 的密钥材料我也一起带来了。

服务器：对，就用 X。
       这是我的密钥材料，搞定。

在HTTP3的QUIC协议中，把传输层连接和TLS握手一起做。所以1个RTT就可以进入正常的应用数据阶段。

V2Ray和Hysteria

V2Ray 和 Hysteria 都属于网络代理/隧道工具。简单说，它们可以把你的网络流量先送到另一台服务器，再由那台服务器访问目标网站或服务。常见用途包括远程访问、隐私保护、跨网络环境连接，以及绕过某些网络路径上的限制或干扰。

V2Ray更像一个代理框架，本身支持多种协议传输数据。

Hysteria偏向针对交叉网络环境优化的告诉隧道协议。主要建立在QUIC和UDP之上。适合高延迟，丢包多，跨国链路不稳定的场景。比如普通TCP代理在网络丢包时速度掉的很厉害，Hysteria往往能保持更高的吞吐量。现在常见的是Hysteria2.