Update 计算机网络 - 应用层.md
补充 DNS 记录类型与省略协议重定向附录,精简并调整主机接入网络请求 URL 的流程说明,新增帧结构图并重新绘制相关协议配图。
|
Before Width: | Height: | Size: 156 KiB After Width: | Height: | Size: 174 KiB |
|
Before Width: | Height: | Size: 226 KiB After Width: | Height: | Size: 232 KiB |
|
Before Width: | Height: | Size: 140 KiB After Width: | Height: | Size: 143 KiB |
|
After Width: | Height: | Size: 262 KiB |
|
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 136 KiB |
@@ -18,6 +18,7 @@
|
||||
* [附录:实测](#附录实测)
|
||||
* [A1 访问网页各阶段的耗时](#a1-访问网页各阶段的耗时)
|
||||
* [A2 DNS 的 TTL 与 CNAME](#a2-dns-的-ttl-与-cname)
|
||||
* [A3 省略协议时的重定向](#a3-省略协议时的重定向)
|
||||
* [参考资料](#参考资料)
|
||||
<!-- GFM-TOC -->
|
||||
|
||||
@@ -26,7 +27,7 @@
|
||||
|
||||
DNS 是一个分布式数据库,提供了主机名和 IP 地址之间相互转换的服务。这里的分布式数据库是指,每个站点只保留它自己的那部分数据。
|
||||
|
||||
域名具有层次结构,从上到下依次为:根域名、顶级域名、二级域名。
|
||||
域名具有层次结构,从上到下依次为:根域名、顶级域名、二级域名。例如 com 是顶级域名,example.com 是二级域名,www.example.com 是三级域名;完整的写法是 www.example.com.,最右边的点代表根。
|
||||
|
||||
以解析 www.example.com 为例:主机先查浏览器缓存、操作系统缓存和 hosts 文件,没有命中就向本地 DNS 服务器查询。本地 DNS 服务器依次询问根服务器、com 顶级域服务器和 example.com 的权威服务器,前两者只返回下一级服务器的地址,权威服务器返回最终的 IP 地址。
|
||||
|
||||
@@ -43,14 +44,16 @@ www.jd.com.s.galileo.jcloud-cdn.com. 20 IN CNAME wwwv6.jcloudimg.com.
|
||||
wwwv6.jcloudimg.com. 15 IN A 119.147.159.135
|
||||
```
|
||||
|
||||
每行是一条资源记录:名字、剩余的 TTL、类别 IN(互联网)、类型和值。常见的类型有 A(IPv4 地址)、AAAA(IPv6 地址)、CNAME(别名,指向另一个域名)、NS(该区域的权威服务器)和 MX(邮件服务器)。
|
||||
|
||||
第二列是剩余的 TTL,5 秒后再查询,四个值都减少了 5;直接问京东的权威服务器,第一条记录的 TTL 是 120。修改记录后,各级缓存中的旧记录要等 TTL 到期才会失效,所以更换服务器的 IP 地址之前,通常先把 TTL 调小。
|
||||
|
||||
这个结果也说明了 CDN 的调度方式:www.jd.com 通过 CNAME(别名记录)把解析交给 CDN 的调度系统,调度系统根据查询来源的位置返回较近的节点地址,TTL 只有几十秒,便于随时切换节点。DNS 负载均衡见 [DNS 域名解析](集群.md#2-dns-域名解析),CDN 见 [CDN](缓存.md#三cdn)。
|
||||
|
||||
DNS 可以使用 UDP 或者 TCP 进行传输,使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输,这就要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输:
|
||||
DNS 可以使用 UDP 或者 TCP 进行传输,使用的端口号都为 53。大多数情况下 DNS 使用 UDP 进行传输:一次查询只是一问一答,报文通常只有几十到几百字节,用 UDP 一个往返就能得到结果,TCP 还要先三次握手,服务器也要为每个连接保存状态。代价是域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。在两种情况下会使用 TCP 进行传输:
|
||||
|
||||
- 如果返回的响应超过 512 字节(DNS 规定通过 UDP 传输的报文不超过 512 字节,使用 EDNS 扩展后可以更大);
|
||||
- 区域传送(主域名服务器把整个区域的数据传送给辅助域名服务器,称为 AXFR;只传送变化部分的增量传送称为 IXFR)。
|
||||
- 响应超过 UDP 报文的长度上限:DNS 规定通过 UDP 传输的报文不超过 512 字节(使用 EDNS 扩展后可以更大),超出时服务器返回截断的响应并置 TC 标志,客户端改用 TCP 重新查询;
|
||||
- 区域传送:主域名服务器把整个区域的数据传送给辅助域名服务器,称为 AXFR,使用 TCP;只传送变化部分的增量传送称为 IXFR,可以用 UDP,放不进一个 UDP 报文时同样改用 TCP。
|
||||
|
||||
DNS 报文默认不加密,也不验证来源,常见的攻击有两种:DNS 劫持指的是攻击者控制了用户使用的 DNS 服务器或路由器,把域名解析到自己的地址;DNS 污染指的是在查询途中抢先返回伪造的响应,解析器会接受先到达的那个。防范的方法:
|
||||
|
||||
@@ -78,7 +81,9 @@ FTP 使用 TCP 进行连接,它需要两个连接来传送一个文件:
|
||||
|
||||
动态主机配置协议(Dynamic Host Configuration Protocol, DHCP)提供了即插即用的连网方式,用户不再需要手动配置 IP 地址等信息。
|
||||
|
||||
DHCP 配置的内容不仅是 IP 地址,还包括子网掩码、网关 IP 地址。
|
||||
DHCP 配置的内容不仅是 IP 地址,还包括子网掩码、网关 IP 地址和 DNS 服务器的地址。
|
||||
|
||||
分配的地址有租期,客户端在租期过半时向原服务器续租,到期没有续上就要停止使用这个地址。
|
||||
|
||||
DHCP 工作过程如下:
|
||||
|
||||
@@ -121,7 +126,7 @@ IMAP 协议中客户端和服务器上的邮件保持同步,如果不手动删
|
||||
|
||||
|应用| 应用层协议 | 端口号 | 传输层协议 | 备注 |
|
||||
| :---: | :--: | :--: | :--: | :--: |
|
||||
| 域名解析 | DNS | 53 | UDP/TCP | 长度超过 512 字节时使用 TCP |
|
||||
| 域名解析 | DNS | 53 | UDP/TCP | 响应被截断或 AXFR 时使用 TCP |
|
||||
| 动态主机配置协议 | DHCP | 67/68 | UDP | |
|
||||
| 简单网络管理协议 | SNMP | 161/162 | UDP | |
|
||||
| 文件传送协议 | FTP | 20/21 | TCP | 控制连接 21,数据连接 20 |
|
||||
@@ -137,55 +142,47 @@ IMAP 协议中客户端和服务器上的邮件保持同步,如果不手动删
|
||||
|
||||
在浏览器中输入 https://www.example.com/ 并回车后,主要经过以下步骤:
|
||||
|
||||
1. 浏览器解析 URL,得到协议 https、主机名 www.example.com、端口(省略时 https 为 443)和路径 /,各部分的含义见 [URL](HTTP.md#url),然后检查缓存,有未过期的缓存时直接使用;
|
||||
2. DNS 解析域名,得到 IP 地址;
|
||||
1. 浏览器解析 URL,得到协议 https、主机名 www.example.com、端口(省略时 https 为 443)和路径 /,各部分的含义见 [URL](HTTP.md#url),然后检查缓存,有未过期的缓存时直接使用,见 [缓存](HTTP.md#缓存);
|
||||
2. DNS 解析主机名 www.example.com,得到 IP 地址,路径和参数不参与解析;
|
||||
3. 与服务器进行 TCP 三次握手,HTTPS 还要进行 TLS 握手;
|
||||
4. 发送 HTTP 请求,服务器处理后返回响应;
|
||||
5. 浏览器解析 HTML,再请求其中引用的 CSS、JavaScript、图片等资源,最后渲染出页面;
|
||||
6. 连接保持一段时间供后续请求复用,空闲后关闭。
|
||||
4. 发送 HTTP 请求。请求通常先到达负载均衡或[反向代理](集群.md#3-反向代理服务器)(例如 Nginx),再转发给某台应用服务器,应用服务器查询缓存或数据库后生成响应。如果响应是重定向,例如只输入 baidu.com 时浏览器补上协议后访问,得到 301 和 Location: https://www.baidu.com/(见[附录 A3](#a3-省略协议时的重定向)),浏览器对新地址重新走一遍前面的步骤;
|
||||
5. 浏览器解析 HTML 构建 DOM 树,解析 CSS 构建 CSSOM,两者合成渲染树,再计算每个元素的位置和大小(布局),最后绘制到屏幕上。解析中遇到 CSS、JavaScript、图片等外部资源时另发请求,不带 async 或 defer 的普通脚本(type 不是 module)会暂停 HTML 的解析,直到脚本下载并执行完;
|
||||
6. 连接保持一段时间供后续请求复用,空闲后关闭,见 [短连接与长连接](HTTP.md#1-短连接与长连接)。
|
||||
|
||||
以下是访问该网址时各阶段的耗时(curl 实测,见[附录 A1](#a1-访问网页各阶段的耗时)):
|
||||
|
||||
<div align="center"> <img src="pics/url-timeline.png" width="760px"/> </div><br>
|
||||
|
||||
下面从网络各层的角度,看一台刚接入网络的主机发出这个请求的完整过程。
|
||||
从网络各层看,一台刚接入局域网的主机要发出这个请求,先后要用到 DHCP、ARP、DNS、TCP 和 TLS。下图是它依次发出的前几个帧,下面逐步说明:
|
||||
|
||||
<div align="center"> <img src="pics/url-frames.png" width="760px"/> </div><br>
|
||||
|
||||
### 1. DHCP 配置主机信息
|
||||
|
||||
- 假设主机最开始没有 IP 地址以及其它信息,那么就需要先使用 DHCP 来获取;
|
||||
- 主机生成一个 DHCP 请求报文,并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中;
|
||||
- 该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255)和源 IP 地址(0.0.0.0)的 IP 数据报中;
|
||||
- 该数据报则被放置在 MAC 帧中,该帧具有目的地址 FF:FF:FF:FF:FF:FF,将广播到与交换机连接的所有设备;
|
||||
- 连接在交换机的 DHCP 服务器收到广播帧之后,不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文,之后生成 DHCP ACK 报文,该报文包含以下信息:IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中,UDP 报文段又被放入 IP 数据报中,最后放入 MAC 帧中;
|
||||
- 该帧的目的地址是请求主机的 MAC 地址,因为交换机具有自学习能力,之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项,因此现在交换机就可以直接知道应该向哪个接口发送该帧;
|
||||
- 主机收到该帧后,不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址,并在其 IP 转发表中安装默认网关。
|
||||
- 主机最开始没有 IP 地址,要先用 DHCP 获取:它把 Discover 报文放入源端口 68、目的端口 67 的 UDP 报文段,再放入源地址 0.0.0.0、目的地址 255.255.255.255 的 IP 数据报,最后放入目的 MAC 为 FF:FF:FF:FF:FF:FF 的广播帧,交换机把它转发给所有设备;
|
||||
- DHCP 服务器经过 Offer、Request、Ack 的交互(见[动态主机配置协议](#动态主机配置协议)),在 Ack 中给出 IP 地址、子网掩码、默认网关和 DNS 服务器的地址;
|
||||
- 交换机在转发主机的广播帧时已经记下了主机的 MAC 地址在哪个接口(自学习),所以服务器单播给主机的帧只从这一个接口转发出去(客户端要求广播回复时,Offer 和 Ack 仍会发给所有设备);
|
||||
- 主机按 Ack 配置自己的 IP 地址、子网掩码和 DNS 服务器,并把网关设为默认路由。
|
||||
|
||||
### 2. ARP 解析 MAC 地址
|
||||
|
||||
- 主机通过浏览器生成一个 TCP 套接字,套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字,主机需要知道网站的域名对应的 IP 地址;
|
||||
- 主机生成一个 DNS 查询报文,该报文具有 53 号端口,因为 DNS 服务器的端口号是 53;
|
||||
- 该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中;
|
||||
- 该 IP 数据报被放入一个以太网帧中,该帧将发送到网关路由器;
|
||||
- DHCP 过程只知道网关路由器的 IP 地址,为了获取网关路由器的 MAC 地址,需要使用 ARP 协议;
|
||||
- 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文,将该 ARP 查询报文放入一个具有广播目的地址(FF:FF:FF:FF:FF:FF)的以太网帧中,并向交换机发送该以太网帧,交换机将该帧转发给所有的连接设备,包括网关路由器;
|
||||
- 网关路由器接收到该帧后,不断向上分解得到 ARP 报文,发现其中的 IP 地址与其接口的 IP 地址匹配,因此就发送一个 ARP 回答报文,包含了它的 MAC 地址,发回给主机。
|
||||
- 浏览器要和 www.example.com 建立连接,先要知道它的 IP 地址,因此主机生成 DNS 查询报文,放入目的端口 53 的 UDP 报文段,再放入目的地址为 DNS 服务器的 IP 数据报;
|
||||
- DNS 服务器不在本网络,数据报要先交给网关路由器。DHCP 只给出了网关的 IP 地址,而以太网帧需要的是它的 MAC 地址,所以主机先用 ARP 查询;
|
||||
- ARP 请求放在广播帧中,网关路由器发现查询的 IP 地址是自己接口的地址,回复包含自己 MAC 地址的 ARP 响应;
|
||||
- 主机把这个映射记入 ARP 缓存,之后发往其它网络的帧,目的 MAC 都是网关的地址,见 [地址解析协议 ARP](计算机网络%20-%20网络层.md#地址解析协议-arp)。
|
||||
|
||||
### 3. DNS 解析域名
|
||||
|
||||
- 知道了网关路由器的 MAC 地址之后,就可以继续 DNS 的解析过程了;
|
||||
- 网关路由器接收到包含 DNS 查询报文的以太网帧后,抽取出 IP 数据报,并根据转发表决定该 IP 数据报应该转发的路由器;
|
||||
- 因为路由器具有内部网关协议(RIP、OSPF)和外部网关协议(BGP)这两种路由选择协议,因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项;
|
||||
- 到达 DNS 服务器之后,DNS 服务器抽取出 DNS 查询报文,并在 DNS 数据库中查找待解析的域名;
|
||||
- 找到 DNS 记录之后,发送 DNS 回答报文,将该回答报文放入 UDP 报文段中,然后放入 IP 数据报中,通过路由器反向转发回网关路由器,并经过以太网交换机到达主机。
|
||||
- 主机把装有 DNS 查询的帧发给网关路由器,路由器按转发表把 IP 数据报逐跳转发到 DNS 服务器。转发表由 RIP、OSPF、BGP 等路由选择协议事先建立,见[路由选择协议](计算机网络%20-%20网络层.md#路由选择协议);
|
||||
- DNS 服务器的缓存中有这条记录时直接回答,否则按[域名系统](#域名系统)中的过程依次询问根服务器、顶级域服务器和权威服务器;
|
||||
- DNS 回答报文沿相反的方向回到主机,主机得到 www.example.com 的 IP 地址。
|
||||
|
||||
### 4. HTTP 请求页面
|
||||
|
||||
- 有了 HTTP 服务器的 IP 地址之后,主机就能够生成 TCP 套接字,该套接字将用于向 Web 服务器发送 HTTP GET 报文;
|
||||
- 在生成 TCP 套接字之前,必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 443 的 TCP SYN 报文段(HTTP 为 80),并向服务器发送该报文段;
|
||||
- HTTP 服务器收到该报文段之后,生成 TCP SYN ACK 报文段,发回给主机;
|
||||
- 连接建立之后,HTTPS 还要先完成 TLS 握手,见 [TLS 握手](HTTP.md#tls-握手),之后浏览器生成 HTTP GET 报文,并交付给 HTTP 服务器;
|
||||
- HTTP 服务器从 TCP 套接字读取 HTTP GET 报文,生成一个 HTTP 响应报文,将 Web 页面内容放入报文主体中,发回给主机;
|
||||
- 浏览器收到 HTTP 响应报文后,抽取出 Web 页面内容,之后进行渲染,显示 Web 页面。
|
||||
- 主机向服务器 IP 地址的 443 端口(HTTP 为 80)发送 TCP SYN 报文段,经过[三次握手](计算机网络%20-%20传输层.md#tcp-的三次握手)建立连接,这些帧同样先交给网关;
|
||||
- HTTPS 接着进行 TLS 握手,协商出会话密钥并验证服务器的证书,见 [TLS 握手](HTTP.md#tls-握手);
|
||||
- 浏览器发送 HTTP GET 报文,服务器读取请求,把页面内容放入响应报文的主体发回;
|
||||
- 浏览器解析 HTML,再请求其中引用的资源,最后渲染出页面。
|
||||
|
||||
## 附录:实测
|
||||
|
||||
@@ -222,6 +219,20 @@ www.jd.com. 120 IN CNAME www.jd.com.gslb.qianxun.com.
|
||||
www.jd.com.gslb.qianxun.com. 60 IN CNAME www.jd.com.s.galileo.jcloud-cdn.com.
|
||||
```
|
||||
|
||||
### A3 省略协议时的重定向
|
||||
|
||||
macOS 自带的 curl 8.7.1,2026-10-30 分别以 http 和 https 访问 baidu.com,只显示状态行和 Location 首部:
|
||||
|
||||
```text
|
||||
$ curl -s -D - -o /dev/null http://baidu.com | grep -iE '^HTTP|^location'
|
||||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://www.baidu.com/
|
||||
|
||||
$ curl -s -D - -o /dev/null https://baidu.com | grep -iE '^HTTP|^location'
|
||||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://www.baidu.com/
|
||||
```
|
||||
|
||||
## 参考资料
|
||||
|
||||
- [RFC 1035: Domain Names - Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035)
|
||||
|
||||