共计 12854 个字符，预计需要花费 33 分钟才能阅读完成。
网络的导航，是从输出 url 到最终获取到文件的过程。其中牵扯到浏览器架构、操作系统、网络等一系列常识。本文将从各个角度具体阐述这一过程，波及广度与深度。如果您是曾经有肯定根底的同学，那么本文能够疾速带你系统化整顿碎片化常识。
导航篇
本大节，咱们将以一般申请作为抓手，追随申请数据包漫游整个 OSI 模型，本节目录：
-
导航篇
- 解析 URI
- 构建申请
- 查找强缓存
-
DNS 解析
- DNS 层级
- Hosts
- DNS 解析流程
-
协定栈
- 传输层
- TCP / IP 协定簇上层
- ARP
- ICMP
- 网卡与驱动
-
电信号护航者
- 中继器
- 集线器
- 网桥
- 交换机
- 网关
- 递归至对端
解析 URI
当咱们在地址栏输出须要申请的网站地址，如：晨风 并按下回车，
Chrome 首先会解析内容，判断这是 URL 还是搜寻内容，若是搜寻内容则主动 URL 编码并拼接为默认搜索引擎的 params。
如果是 URI，如:test.com，则解决 URI，增加 http 并默认拜访 80 端口号。
在 Chrome 层面，如果你的地址栏本来就有展现页面，那么进行上述操作后，会触发以后页面的 beforeunload 与 unload 事件。同时浏览器标签进入 loading 图标状态，新页面有两个重要的工夫节点，在渲染篇会具体介绍:
interactive：它示意浏览器曾经实现了HTML parser、Recalculate Style、Layout Tree、Render Tree、draw list等工作。complete: 它示意浏览器曾经实现页面渲染，这会替换掉本窗口本来的位图，显示最新的界面。在interactive与complete之间，就是渲染过程中的合成线程的工作地位，Chrome渲染过程基于 skia 进行2D界面元素的绘制。
早些时候一些网站会在 URI 中间接制订门路和具体的后缀的文件，如：https://www.test.com/home/index.html。然而这所带来的诸如非法拜访等平安问题与互联网业务需要的爆发式增长，人们对 Web 的安全性与效率有了更高的要求，因而引入代理服务器满足 保障平安 、 负载平衡 、 缓存代理 等需要。古代 Web 简直都采纳代理服务器以暗藏实在的资源地位。
构建申请
通过 URI Check 后，Chrome 须要为它创立 get 申请，在此之前先介绍一下 Chrome 的架构组成。
Chrome 目前采纳的是 SOA 架构，次要特点是将应用程序的不同的 Service 进行拆分，并通过这些服务之间定义良好的接口和协定分割起来。罕用的过程如下：
- 浏览器主过程：负责页面展现，用户交互，子过程治理等性能
- 渲染过程：每个选项卡都有本人的渲染过程，无关乎是否为 same-site 站点，
SandBox运行环境，解决HTML、CSS、JavaScript。同时V8和Blink也都运行在该过程中。 - 插件过程：负责插件运行，依据插件的性能决定是否运行在
Sandbox环境 - GPU 过程：解决一些非凡的 CSS 成果
- NetWork Service：解决网络资源加载，申请响应，校验 CORS。
- Storage Service：解决对
localStorage、sessionStorage、cookie、Indexed DB存储的管制。 - Audio Service：解决音视频
Buffer的音量播放等操作 - V8 PAC tool：利用 V8 解析 PAC 文件，干一些你懂得的事 😁。
从上文得悉 Chrome 主过程须要通过 IPC 把构建申请的工作委托给 NetWork Service 负责此工作。
NetWork Service 接受任务后，创立了 get 申请，其中申请行由 申请办法 + 申请门路 + HTTP 版本号 组成；申请头信息由 Chrome 内置提供。
在 HTTP 2.x 规范中引入了
Hpack和Stream，其中Hpack次要的目标是压缩申请报文头信息以缩小每次链接发送的冗余数据。它会将报文头信息整合成一张Hash Table，并应用Huffman编码压缩文本内容。并且申请行也被勾销，其内容置入Hash Table首部并以:结尾，以此辨别申请行与申请头信息。Stream的作用咱们稍后介绍
查找强缓存
NetWork Service 会委托 Storage Service 顺次在 service work cache、memory cache、disk cache、push cache（HTTP2 Stream）中寻找对应的 URI 是否有可用的强缓存，如果存在强缓存，则间接应用缓存进入浏览器解析环节，否则进入 DNS 解析。
为了不便同学们学习和验证，我把非 memory cache 的 cache 资源在 MacOS 的地位统计如下：
- Service Work Cache：
/Users/YOUR_NAME/Library/Application Support/Google/Chrome/Default/Service Worker/[CacheStorage || ScriptCache] - Disk Cache：
/Users/YOUR_NAME/Library/Application Support/Google/Chrome/Default/Application Cache/Cache
因为 Chrome 勾销了通过 chrome://cache 进行拜访，因而查看这类问题时须要自行装置反编译工具查看。
个别状况下大文件会默认寄存在
disk cache中，小文件存入memory cache。但当内存使用率较高时，须要缓解应用压力会优先放入disk cache。HTTP 2 提供了多路复用，头部压缩、Service Push。其中 Service Push 是惟一须要手动实现的性能，Service Push 可在某次 Stream 中返回用户端还没被动申请，然而相干的数据，以节约报文上不必要的开销。
DNS 解析
若强缓存不存在或过期时，NetWork Service 持续将报文发送至接收端。这须要 OS 的配合，首先须要将报文委托给 OS 至协定栈，但 OS 无奈辨认报文对应的 domain，因而无奈提供相应帮忙。咱们必须提供 IP 地址。将制订域名转换成 IP 的工作是由 DNS 服务器提供。
域名的诞生也是为了合乎人们的习惯性记忆，没有人喜爱记忆无意义的 IP 地址。于是便有了 DNS 服务赋能 IP 对应的 Domain 以不便记忆。
DNS 层级
因为域名零碎是外国人创造的，因而 DNS 的层级划分是 从右往左依据 **.** 进行切分 ，它就像英文人名一样， 根域 / 姓氏 取域名最开端的局部，不合乎国人记忆习惯。
依据层级 DNS 服务器分为：
- 根域 DNS 服务器：不保留具体的域名信息，但它是通向所有顶级域 DNS 服务器的总入口
- 顶级域 DNS 服务器：代表不同的域名后缀服务器，如
cn、com、tech等。同样不保留具体的域名信息，是通往对应后缀权威 DNS 服务器的总入口 - 权威 DNS 服务器：正如其名，代表着对应 Domain 映射 IP 的权威。它是存储映射关系的实在服务器。
从上图可知，DNS 服务器之间有着相似 trie 树的构造，树的每一层的信息都是残缺域名的一部分且 非叶子节点的信息均是没有帮忙的。而叶子节点被称为权威服务器，是 IP 与 Domain 映射关系存储的理论地位。根域 DNS 服务器的信息保留在互联网中所有的 DNS 服务器中，正因如此，客户端只须要拜访到任意 DNS 服务器就能够顺着它找到根域服务器，从而获取指标 IP。
Chrome 从 83 版本开始正式开始了 DOH 即 DNS-over-HTTPS，次要目标是避免本来的 DNS 申请因为是 HTTP 明文传输导致容易被中间人篡改，因而 DOH 就是批着 TLS 的 DNS 申请。
Hosts
正如 JavaScript 的 Promise 反对 thenable，instanceof 反对 Symbol.hasInstance，JSON.stringify 反对 toJSON 等等都会开设一个定制化行为的入口。
域名解析也存在本地定制化入口 Hosts。它是一个本地的关联“数据库”，将 Domain 与 IP 地址绝对应。解析优先级大于 DNS 服务。
DNS 解析流程
笔者以拜访 http://www.test.com 为例，DNS 的解析流程如下：
- 查看
hosts是否存储指标domain和IP地址的映射关系，若找到则间接返回给客户端。 - 若
hosts不存在对应domain，客户端建设DNS申请，问询本地DNS服务器Domain对应的IP地址。 - 本地
DNS服务器收到申请后，首先查看DNS缓存是否找到domain对应的IP地址，若找到则间接返回给客户端。若DNS缓存中不存在，则找到本身记录的根域DNS地址并发动申请问询根域服务器Domain对应的IP地址。 - 根域服务器不保留具体的数据，然而指明了咱们接下来询问的指标：对应
com的顶级域名服务器地址。 - 本地
DNS服务器收到根域的回应后，持续问询com的顶级域名服务。 - 顶级域名服务器同理睬返回绝对应
test.com的权威服务器地址。 - 本地服务器持续问询权威服务器，它是域名解析后果的原出处，也是最初一次问询。
- 权威
DNS服务器返回域名对应的IP地址给客户端。 - 本地
DNS服务器缓存后果。将IP发给OS。 OS返回IP至Chrome NetWork Service。
这下 NetWork Service 领有了绿卡，曾经万事俱备。终于可通过 socket library 将数据委托给 OS 以进入协定栈啦。同时也标记着行将来到 OSI 应用层。
协定栈
申请数据包在 OS 的帮忙下进入协定栈。工作在应用层与传输层两头的协定栈会解决对应 H2 的 Hpack 和 Stream，如果 domain 应用了 TLS / SSL 协定，那么 OS 会从本地加密套件列表中选取加密套件，并将信息增加至数据包。
传输层
至此数据包来到协定簇下层，它示意工作在传输层和网络层相干的协定总称。协定簇分为高低两个局部，别离承当不同的工作且上上层关系有肯定的规定，下层实现局部工作后会委托上层继续执行。在下层协定簇中最先映入眼帘的便是负责数据包收发的 TCP / UDP
TCP
TCP 是面向一对一链接，牢靠有状态且基于字节流的协定。在 HTTP 传输数据之前，首先须要 TCP 建设连贯，TCP 连贯的建设，通常称为三次握手。
在深刻介绍 TCP 前，咱们得先理解 MTU，它是一个网络包的最大长度，在以太网中个别为 1500 字节。而咱们的 HTTP 数据表都昌都很有可能会大于 1500，所以要对超出的内容进行切片发送，TCP 会对报文进行切分并增加一些信息以确保每个数据包能顺利达到接收端。TCP 数据的最大长度为 MSS，它通过 MTU – TCP head – IP head 计算而来。至此咱们介绍下 TCP Head 具体增加的信息。
源端口、指标端口
首先是一组端口号，如果没有它们，数据包到端后不晓得本人是属于哪个端口利用的数据。
同时，咱们也通过源 IP、源端口、指标 IP 和指标端口组成惟一的标识。
这时候可能有同学提出疑难，那么浏览器关上多个页签时，如果拜访的域名和端口也一样，数据如何对应正确的标签？笔者推断 Chrome 可能通过 TCP 的 timestamp 或 ISN 进行辨认，若有同学能提供精确的答案欢送指出。
Sequence Number
简称 seq，它代表本报文段第一个字节的序列号，序列号是一个长为 4 个字节，也就是可能示意 32 位的无符号整数。如果达到最大值了后就循环到 0。它次要有以下几个作用
- 确保端具备发送性能的标记。
- 首次发送 SYN 报文时替换 ISN。
-
确保被切分的数据包以正确的程序组装。
ISN 即 Initial Sequence Number，通过三次握手中的前两次握手进行替换，其目标是避免不法分子得悉 ISN 后伪造 IP 和 Port 通过 TCP 标记位对链接进行非法攻打。因为当初的 ISN 并不是一个固定的值，而是每 4 ms 加一，溢出则回到 0。从而大大提高了攻击者猜想 ISN 的难度。
Acknowledgment Number
简称 ack，和 seq 一样，占有 4 个字节，具体示意小于此字节的内容均已收到。它次要有以下几个作用
- 确保端具备接管能力
- 告知发送端冀望下一次发送的数据起始地位
标记位
依据 TCP 报文解决信息的类别不同，须要给予肯定的标识，这就是标记位。
常见的标记位有 SYN，ACK，FIN，RST，PSH。这方面比拟根底，不分明的同学能够联合三次握手去具体理解。
窗口大小
它赋能 TCP 做流量管制，通信单方各申明一个窗口（缓存大小），标识本人以后可能的解决能力。这也被称为初始化窗口。
除了用滑动窗口做流量管制以外，TCP 还会通过拥塞窗口做拥塞管制，通过初始化的拥塞窗口采取慢启动、疾速重传和疾速复原、拥塞防止等能力。
校验和
占用两个字节，避免传输过程中数据包有损坏，如果遇到校验和有过错的报文，TCP 则间接抛弃，通过使返回的 ack 值放弃不变以揭示发送端须要重传。
紧急指针
这是为了应答一些应用程序在某些紧急情况下（如在某些连贯中进行强制中断）
要求在接管方在没有解决完数据之前就可能发送一些紧急数据。
选项
这是 TCP 中的可选项，其中比拟重要的是
- TimeStamp:
TCP工夫戳，解决RTT错乱与序列号回绕 - MSS：前文提过，通过
MTU–TCP head–IP head计算而来。
回到三次握手，所谓的建设 连贯，只是单方计算机里保护一个状态机，在连贯建设的过程中，单方的状态从 close → established。通过三次握手的 SYN，ACK 传递确保单方的发送接管能力。
在 Linux 中咱们能够通过 netstat -napt 来查看 TCP 链接状态：
tcp 0 0 0.0.0.0:5440 0.0.0.0:* LISTEN 9138/java
tcp 1070 0 199.161.10.251:9020 199.161.10.251:34512 CLOSE_WAIT 4122/java
tcp 1 0 199.161.10.251:60254 199.161.100.195:38399 CLOSE_WAIT 7377/java
tcp 1076 0 199.161.10.251:9020 199.161.10.251:34540 CLOSE_WAIT 4122/java
tcp 416 0 199.161.10.251:9020 199.161.10.251:39166 CLOSE_WAIT 4122/java
tcp 0 0 199.161.10.251:36956 199.161.10.116:22 ESTABLISHED 7377/java在理论的网络环境中，此时数据包传输被阻塞，先和对端实现三次握手，之后才持续发送数据。这也是人们在 HTTP3.0 前，称 HTTP 是基于 TCP 的次要起因，同时从此处能够看出 TCP 的队头阻塞 是个不可避免的问题。
TCP 还提供了 keep-alive 性能，然而十分鸡肋。
UDP
UCP 是面向无连贯，一对多发送且无状态的协定。
因为 TCP 的先入为主且其可靠性禁受住了历史的考验，让咱们很容易置信它会始终放弃 Web 端传输层的主导地位，然而 Google 团队的创始能力，也再一次让笔者大开眼界。HTTP 3.0 规范将摈弃 TCP。UDP 胜利取得主导地位。
次要的起因想必大家早已略有耳闻，TCP 链接必须经验三次握手，即使你应用了 TFO (TCP Fast Open) 也一样。如果须要进步数据交互的安全性，既减少传输层平安协定（TLS），在确保安全的 Session Ticket 优化计划下也须要减少 1 RTT。咱们不思考 PSK，因为它不平安。总之，TCP 协定连贯建设的老本绝对较高，因为 TCP 是在操作系统内核和中间件固件（上文所提的协定栈）中实现的，因而对 TCP 进行重大更改简直是不可能的。
而 UDP 协定是无连贯协定。客户端收回 UDP 数据包后，只能“假如”这个数据包曾经被服务端接管。益处是在传输层无需对数据包进行校验，个别用于网络游戏、流媒体数据的一些传输。与之绝对的，如果须要确保数据传输的可靠性，应用层协定须要本人对包传输状况进行确认。此协定就是 QUIC
QUIC 协定是基于 UDP 的低时延的互联网传输层协定。HTTP 2.0 解决了由 HTTP 引起的队头阻塞问题，但更深层次的 TCP 队头阻塞问题无奈防止，QUIC 基于 UDP 协定，因而彻底解决了所有队头阻塞问题。
QUIC 协定依据连贯的服务器是新的还是已知的，可在 1-2 个 RTT 内实现连贯的创立（包含反对 TLS），这具备很高的诱惑力。
QUIC 尽管有诸多劣势，但目前仍未达到大量遍及的阶段，并且目前局部路由会封杀 QUIC 所在的 443 端口，UDP 包过多让服务商误以为是攻打、防火墙对 QUIC 的反对等均未到位。让咱们一起期待 QUIC 协定标准可能成为终稿并实现推广的那天。
本文次要还是以目前支流的 TCP 为主，通过 TCP 包头后，以后数据包如下：
TCP / IP 协定簇上层
在传输层执行连贯、收发、断开等各阶段操作都须要委托 IP 协定将数据包封装成网络包发送给通信对象。上面咱们来看看 IP 报文头部的格局
其中最重要的是源 IP 与指标 IP。
- 源 IP 即以后客户端的 IP 地址
- 指标 IP 为 DNS 域名解析失去的接收端服务器 IP
其次是 IP Header 中的协定号，示意传输层应用的协定。以十六进制示意。例如 06 示意的是 TCP。通过 IP Header 包装后，如下：
路由表
通过 IP Head，咱们通晓了接收数据的指标 IP，但咱们不能确定这个 IP 间隔咱们地址地位有多远，很多时候或者咱们无奈间接发送到对端，而是要在网关中进行数次直达，管制此过程就是依据路由表的规定。
在 Linux 零碎能够依据 route -n 查看以后零碎的路由表。
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 199.161.100.1 0.0.0.0 UG 100 0 0 eth0
199.254.169.254 199.161.100.153 255.255.255.255 UGH 100 0 0 eth0
199.161.100.0 0.0.0.0 255.255.252.0 U 100 0 0 eth0此步也是网关是否染指链接过程的要害分歧点。来看看路由表是如何工作的。
- 首先依据路由表 list 顺次取出每一条信息
- 依据每条信息中的子网掩码（Genmask）与接管方的指标 IP 进行与运算，如果后果和 Destination 匹配，阐明与咱们通信的对端处在同一以太网中，接下去的发送不须要走网关。并确定以以后的 IP 作为 IP 包头地址。
- 若以上匹配都失败了，那么会匹配到默认网关，个别这就是路由器的 IP，最初网络包会转发给路由器，让路由器帮忙发送。
ARP
生成 IP 包头后，网络包还须要加上 MAC 包头，IP 的诞生是为了更加不便的治理计算机在各类以太网中的身份。而连入所有网络的每一个计算机都会有网卡接口，每一个网卡都会有一个惟一的地址，这个地址就叫做 MAC 地址。计算机之间的数据传送，就是通过 MAC 地址来惟一寻找、传送的。MAC 包头的构造如下：
其中发送方的 MAC 非常容易确认，因为 MAC 在网卡生产过程中曾经写入 ROM 中，间接读取此值写入 MAC 头部即可。
接收端的 MAC 地址绝对简单一些，以后咱们曾经通晓了接管方的 IP，通过子网掩码，咱们能把接收端分为两类
- 处于同一子网的街坊
- 处于内部子网的通信对象，咱们交给居委会大妈（网关）去通信
能够看得出来，不管通信对象是否是街坊，咱们首次发送的对象都是同一子网的，兴许是街坊服务器兴许是网关。因而咱们应用播送进行问询指标的 MAC 地址。
播送
ARP 协定会在以太网中以播送的模式，对以太网所有的设施问话路由表匹配的指标 IP 地址对应的 MAC 地址。
就像操场的喊话，所有人都能够听见，但如果喊话对象不是本人，不再回应就是。被喊话的对象听见后，以 MAC 地址作为回应。
ARP 缓存
正如大部分服务一样，ARP 也有本人的缓存零碎，以空间换工夫提高效率。获取到 MAC 地址后，OS 会把本次查问后果放到一块叫做 ARP 缓存的内存空间留着当前用，不过缓存的工夫就几分钟。
也就是说，在构建 MAC 包头时：
- 先查问 ARP 缓存，如果其中曾经保留了对方的 MAC 地址，就不须要发送 ARP 播送查问，间接应用 ARP 缓存中的地址。
- 而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 播送查问。
linux 中能够应用 arp -a 查看 ARP 缓存的内容
gateway (199.161.100.1) at 79:2c:29:11:0a:32 [ether] on eth0
? (199.161.100.251) at ff:91:13:17:a0:00 [ether] on eth0
? (199.161.101.189) at ff:63:8a:1f:83:00 [ether] on eth0
? (199.161.100.153) at b3:ab:ef:43:1d:40 [ether] on eth0失去接管方 MAC 地址后，读取本身网卡 ROM 的 MAC 地址，塞入 MAC 头，目前的数据包出现为：
ICMP
ICMP 协定是 IP 的一个组成部分，必须由每个 IP 模块实现。
次要用于在 IP 主机、路由器之间传递管制音讯。管制音讯是指网络通不通、主机是否可达、路由是否可用等网络自身的音讯。
网卡与驱动
通过协定栈生成的网络包只是内存中的一串二进制信息，还是无奈间接进行发送。须要将数字信息转换成电信号，计算机底层实际上也是各种逻辑电路的组合，通过晶体管等硬件扭转高下电压。转换成数字信号后，就能够在网线上进行传输。这就是数据真正的发送过程。同时网卡负责的局部也被称为 Ethernet Frame
网卡负责执行这一操作，然而要管制网卡，必须依附网卡驱动程序，它内置了网卡行为的一些办法。具体步骤如下：
- 网卡驱动从 IP 模块获取到网络包后，会复制其二进制信息至网卡内的缓存区。为了辨别这一段段的数据，咱们须要一套规定来传输二进制，比方多少电信号为一组，如何辨认结尾和结尾等等。
- 因而咱们在二进制信息的起始地位增加报头和二进制帧的起始合成符，用来示意包的起始地位
- 在数据包结尾加上 FCS，也被称为帧校验序列，查看包在传输过程中是否损坏。
- 最初网卡将包转换为电信号，通过网线和光纤等物理介质进行传输。
最初整个数据帧出现如下图：
电信号护航者
中继器
因为电信号在传输过程中会一直衰减，为了不让信号衰减对通信品质产生影响，产生了中继器。它仅做放大信号作用，能把信号传导偏僻的中央。
集线器
咱们假如参加网络链接的单方都只有一个网络接口，那么只可能建设一对一的通信，从前文也能够发现，咱们须要有播送这样一对多的场景，播送也就是将信号进行复制，这就是集线器的作用，并且能够将电信号整形再放大。它工作于物理层。
顺便提一下它和交换机的区别，它没有交换机的智能记忆和学习能力，也不具备交换机所具备的 MAC 地址表。它发送数据时都是没有针对性的，能够说它就是播送发送的代名词。
网桥
自从有集线器以来它解决了一对多的效率问题，同时也带来了问题，在实在的网络环境中，很有可能有多个集线器连贯在一起，但因为是用来做播送通信，会互相冲突，因而咱们须要可能无效隔离各个子网，这就是网桥。名称也十分形象。它位于数据链路层，而集线器是在物理层。因而它能够无效的管制让播送通信仅仅在于一个部分，部分和部分两头用网桥连贯。
网桥原理
当初咱们来介绍下网桥是如何解决播送抵触的。网桥只有两个端口，连贯两个端口的网络被切分成 A、B 两个子网，网桥外部会为每个子网保护一张表，一开始表是空的，网桥会别离依据 A、B 子网发送的数据包，并解开 MAC 头部获取源 MAC 地址，并记录在对应的表中，并转发给另一子网。工作一段时候后简直能够记录下 A、B 子网中所有的机器的 MAC 地址。此时假如网桥接管 A 子网的数据包，它还是会拆解 MAC 头部查看接收端 MAC 地址。如果发现 A 表曾经记录了此 MAC 地址，阐明这不须要播送给 B 子网，A 子网内就能够解决，网关会抛弃此数据包，如果 A 表不存在接口端 MAC 地址，则转发给 B 子网，再查看源 MAC 地址，如果不存在则持续补充在 A 表上。到此就彻底解决了因集线器整形扩充数据包后子网间播送抵触的问题。
在理论环境中，网桥外部不肯定有两个子表，也可能是收集在一起的，具体要看外部实现决定。
交换机
网桥是切分一个局域网一分为二，也解决了播送抵触问题，但历史的车轮总在向前，因为网桥是数据链路层的播送通信，A 和 B 通信的时候，C 和 D 就没法通信。就像一座小桥负载无限，无奈让多人一起通过。为了可能实现多对多的通信，于是多端口的网桥诞生了，这就是交换机。
电信号与交换机
咱们回到正规，网卡依据以太网协定给二进制数据增加起始符和 FCS，并转换为电信号进行发送。
之后电信号通过网线达到交换机网线接口，交换机内模块接管后会将电信号转换为数字信号，数字信号示意让信息参数在给定范畴内体现的更加间断，而不是离散。与之绝对的是模拟信号。
交换机的一个重要的作用就是确保数据包可能原样的转发到目的地。他会拆解以太网头部获取 FCS 校验谬误，如果数据没问题则进入交换机缓冲区，之后局部根本和之前网卡的概念雷同，然而工作形式和网卡不一样，因为网卡的 ROM 中有 MAC 地址，而交换机没有。取而代之的是替换机会保护一张 MAC 地址表。地址表次要蕴含两个信息：
- 记录下接管方 MAC 地址的信息
- 记录下此接管方的设施链接在交换机的哪个端口上。
仔细的同学应该发现了，这部分和网桥十分类似，只是网桥只有两个端口，通过拆表记录，能够不记录端口地位信息。如果目前的数据包和 MAC 表上记录的 MAC 地址匹配上了，就会间接转发到对应的端口。如果找不到指定的 MAC 地址，很可能此地址背地的设施还没有和交换机发送过包，或者因为继续没有工作，导致交换机把它从地址表中删除了。此时只能和播送一样，发送给所有的端口，前文也提过，在同一以太网中，设计之初就是以播送的模式发送给整个网络的所有设施，只有接收者才会接管包，其余设施会疏忽。接管方返回响应后，替换机会对其 MAC 地址进行记录。
除了没有记录的 MAC 地址会转发到除了源端口外的所有端口外，如果接管地址满足播送地址，也会触发同样的行为，常见的播送地址有：
- MAC 地址的 FF:FF:FF:FF:FF:FF
- IP 地址的 255.255.255.255
网关
前文讲述路由表时提过，如果没有比配到默认网关的状况下，是可能不须要网关的，因而咱们假如之前的接管方 IP 地址匹配到了默认网关。
默认网关个别就是路由器的别称，达到路由器时也能够比作高速路的关卡，数据包筹备来到子网了。下文咱们以路由器代指网关。
路由器，也被称为三层网络设备，路由器每个端口都有 MAC 地址和 IP 地址。所以它能够作为以太网的发送和接收端，从此角度来看，它和网卡是一样的。咱们来看看路由器的工作流程：
- 路由器会拆解以太网首部，验证 FCS 校验，如果没有问题进入下一步
- 接下来拆解 MAC 首部，查看接管方的 MAC 地址是否是本人，不是本人就抛弃数据包
- 如果是发送给本人的包，此 MAC 首部的工作彻底实现，便齐全删掉 MAC 头部。持续拆解 IP 首部，读取到 IP 地址。
- 接着查问本身的路由表，这和 IP 层查问路由表的操作统一，先验证子网掩码，再看具体的子网 IP
- 如果网关为空，则示意对应的 IP 地址就是指标地址，曾经到达起点。
- 如果没有匹配上路由表的子网，阐明还未到达起点，持续把数据包转发给路由器的默认网关
递归至对端
路由器会依据查问到的默认网关 IP，通过 ARP 获取 MAC 地址，并且也具备 ARP 缓存，查问到 MAC 地址后，给数据包新增 MAC 头，之后数据包加上以太网首部，通过端口转发给其余网关。尽管路由器读取了 IP 包的指标 IP，然而发送方和接管方的 IP 地址是永远不会被扭转的。
转发到其余网关后还会递归这些步骤，进行网关到网关的直达，直到到达对端 IP。
达到接收端后会顺次去除以太网首部、MAC 首部、IP 首部、TCP 首部，最初读取 HTTP 信息。到此 test.com 胜利接管到了 get 申请，向咱们发送资源文件。
服务器的 HTTP 过程看到，原来这个申请是要拜访一个页面，于是就把这个网页文件封装在 HTTP 响应报文里。
HTTP 响应报文也须要穿上 TCP、IP、MAC 头部，不过这次是源地址是服务器 IP 地址，目标地址是客户端 IP 地址。
套上各种首部后，再次从网卡发送进来，只交换机转发到网关路由，路由器就把响应数据包发到了下一个路由器，接着递归过程，直到跳到了客户端的路由器，路由器扒开 IP 头部发现的确是给本子网的信息，于是把包发给了子网交换机，再由交换机转发到咱们一开始的发送端。
发送端 OS 收到了服务器的响应数据包后，去除各种头部，拿到最初 HTTP 的响应报文，通过 IPC 将包发给 Network Service。
Network Service 收到报文后判断响应状态码，还记得咱们一开始的拜访地址吗？test.com 因而返回了 301 状态码，咱们能够通过 curl -I test.com 查看：
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0
Date: Tue, 07 Sep 2021 03:21:49 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
X-DIS-Request-ID: 241ea10b621b0644e9844c0f52ef76e1
Location: http://www.test.com/此时 Network Service 会主动构建新的申请，申请的指标为响应报文的 location，那么回到本文构建申请的环节，从新走一遍整个流程，值得注意的是古代浏览器会默认开启 connection: keep-alive 这会复用之前建设的 TCP 链接，放慢申请速度。直到 Network Service 再次收到响应。
本次收到响应后，状态码失常，接着查看响应头部 content-type。它是 MIME 的子集。若内容无奈解析，浏览器会启动主动下载，如果为 text/html，就正式进入编译篇。能够通过 curl -i [https://www.test.com/](https://www.test.com/) 查看：
HTTP/1.1 200
Server: nginx/1.18.0
Date: Tue, 07 Sep 2021 03:39:19 GMT
Content-Type: text/html
Content-Length: 8859
Connection: keep-alive
Keep-Alive: timeout=20
ETag: "5e53086c-229b"
X-DIS-Request-ID: c821b8e4044843e8855e76558a610532
Set-Cookie: dis-request-id=c821b8e4044843e8855e76558a610532; secure
Set-Cookie: dis-timestamp=2021-09-06T20:39:19-07:00; secure
Set-Cookie: dis-remote-addr=61.175.192.50; secure
X-Frame-Options: sameorigin
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
...最初，如果客户端要来到了，向服务器发动了 TCP 四次挥手，至此单方的连贯就断开了。
笔者在到端后省略了 TCP 首次到端后进行的二次握手，QUIC 以及 TLS 的校验等工作。它们在 HTTP 首次响应前就被实现。
网络的导航，是从输出 url 到最终获取到文件的过程。其中牵扯到浏览器架构、操作系统、网络等一系列常识。本文将从各个角度具体阐述这一过程，波及广度与深度。如果您是曾经有肯定根底的同学，那么本文能够疾速带你系统化整顿碎片化常识。
