结构#

第一章可以看作是整本书的缩影，其结构是由内向外的，其主要讲述了下面的这部分内容：

• 定义基础: 从「具体构成」(软件和硬件) 和 「提供的服务」(基础设施) 两个角度定义了什么是互联网,并且引出 [[协议]] 的概念
• 网络边缘: 介绍了我们日常生活中的设备，以及他们是如何通过 「接入网」 接入互联网的
• 网络核心: 深入网络内部，探讨负责转发数据的路由器和交换机网络。重点对比了「分组交换」与「电路交换」，并解释了互联网是由众多 ISP（网络服务提供商）组成的 网络的网络
• 性能指标： 这一段内容讲解了数据在网络之间传输的时候为什么会产生延迟，为什么会丢包？以及什么因素决定了网络的吞吐量
• 协议分层与封装: 这一节内容讲述为了应对网络的复杂性，网络被划分为 5 个层次:应用层、传输层、网络层、链路层、物理层 (这也是本书的结构),并且介绍了数据在不同的层之间如何进行封装
• 网络安全威胁: 简单的讲述了一些互联网面临的常见的攻击手段

知识点与名词#

第一章中我们需要理解的知识点将被列在下面:

• 协议: 原书1.1.3
  • 协议(protocol)定义了在两个或多个通信实体之间交换的报文的格式和顺序，以及报文的发送/接收或其他事件所采取的操作
• 端系统/主机：原书1.2
  • 位于网络边缘的设备：客户端 通常是发起通信的设备，服务端 是等待联系的设备
• 分组交换：原书1.3.1
  • 互联网传输数据的核心方式: 发送方将长报文分割成小的数据块「即分组或数据包」，这些分组在网络中独立传输并且贡献链路宽带
• 存储转发: 原书1.3.1
  • 多数分组交换机（路由器）采用的机制。路由器必须接收到完整的数据包后，才能开始向输出链路转发它的第一个比特
• 四种网络延迟: 原书1.4.1
  • 处理延迟
    • 检查包头，决定将数据包导向何处所需要的时间
  • 排队延迟
    • 数据包在路由器输出队列中等待传输的时间
  • 传输延迟
    • 将数据包的所有比特推向链路所需的时间
  • 传播延迟
    • 比特在物理媒介中从一个路由器传播到下一个路由器所需的时间（取决于物理距离和光速）
• 丢包： 原书1.4.2
  • 由于路由器的队列容量是有限的，当到达的流量过大导致队列满了时，新到达的包或队列中的包就会被丢弃
• 吞吐量与瓶颈链路： 原书1.4.4
  • 吞吐量是目标端接收数据的速率。在一条端到端的路径中，吞吐量往往受限于那条传输速率最慢的链路（即瓶颈链路）
• 协议栈与封装 原书1.5.2
  • 数据从应用层向下传递时，每一层都会给它加上自己的「头部信息（Header）」，这就是封装。就像把信件装进快递信封，再装入集装箱一样

结构#

1. 应用层原理基础: (2.1)
   • 首先定义了网络应用是如何构建的，以及它们是如何通过“套接字（Socket）”这个门与底层的传输层（TCP/UDP）交互的
2. 四大核心应用协议：(2.2 - 2.5)
   • Web与HTTP(2.2):现代互联网的基石
   • 电子邮件(2.3): SMTP、IMAP等
   • DNS 目录服务(2.4): 将人类可读的域名转换为机器可读的IP
   • P2P 文件分发(2.5): 探讨去中心化的架构(如bt种子)
3. 内容分发网络 CDN: (2.6)
   • 为了解决海量视频/内容带来的带宽和延迟瓶颈，引出了 CDN
4. Socket 编程Lab: (2.7)
   • 最后，回归代码，展示如何用 TCP 和 UDP 的 Socket API 写出真实的客户端与服务端

知识点#

1. 网络应用架构和Socket接口
   • 客户端-服务端架构 (Client-Server) ：服务器拥有固定的IP地址且始终在线，由客户端主动向服务器发起请求
   • 套接字 (Socket) ： 进程通过网络发送和接受消息的软件接口
   • TCP 与 UDP 的选择 : TCP提供面向链接，可靠的数据传输和拥塞控制；UDP 提供无连接，不可靠但无延迟的传输
2. Web 与 HTTP
   • 无状态 (Stateless) 与 Cookies：HTTP 服务器本身不保存客户端的状态。为了识别用户身份（如登录状态），引入了 Cookie 机制，在 HTTP 请求和响应的 Header 中传递状态
   • 持久连接 (Persistent Connections)：HTTP/1.1 默认使用持久连接，允许在同一个 TCP 连接上发送多个 HTTP 请求和响应，避免了每次请求都消耗一次 TCP 握手的 RTT（往返时间）
   • Web 缓存 (代理服务器/Proxy) : Web 缓存代表原始服务器满足 HTTP 请求，极大降低了客户端的响应延迟和机构接入链路的带宽压力
   • HTTP/2 与 队头阻塞 (HOL Blocking) ： 在 HTTP/1.1 中，如果一个大对象（如大视频）排在队列前面，会阻塞后面小对象的传输（队头阻塞）。HTTP/2 通过将消息分割成小帧 (Frames) 并在单个 TCP 连接上交错传输，解决了这个问题
3. DNS
   • 核心功能: 将人类易读的主机名转换为32位的IP地址
   • 分布式层次数据库: DNS 不是一台集中式服务器，而是由 根 DNS 服务器 (Root)、顶级域 DNS 服务器 (TLD) 和 权威 DNS 服务器 (Authoritative) 组成的层级结构
   • DNS 缓存：为了减少延迟，DNS 广泛使用缓存技术。本地 DNS 服务器可以缓存它收到的任何解析结果，极大地减少了查询流量
4. 视频流与CDN内容分发网络
   • DASH ： 客户端根据当前网络带宽动态选择请求不同清晰度（比特率）的视频块
   • CDN ： 为了避免单点故障和跨大洲传输的高延迟，CDN 在全球部署服务器集群
   • DNS 重定向 ： CDN 利用 DNS 机制来拦截用户的请求，并将请求智能地重定向到距离用户最近或负载最低的 CDN 缓存节点

一个简单实例#

我们来设想一个场景:当我们在浏览器中输入 www.bilibili.com 来访问B站并且播放视频，这些组件会这样进行工作:

1. DNS介入: 浏览器首先需要知道 bilibili 网页服务器的 IP。它调用 DNS 发起查询
2. CDN和DNS进行联动: Bilibili 不会返回单一的IP，其DNS服务器会利用 DNS 重定向技术，根据当前发起请求的主机地理位置，返回距离我们最近的CDN节点的IP地址
3. TCP 握手与 HTTP 请求：浏览器拿到 IP 后，通过 Socket API 发起 TCP 三次握手，然后发送 HTTP GET 请求
4. Cookie 维持状态：HTTP 请求头中带有 Cookie，让 Bilibili 知道你已经登录，并且推荐你喜欢的视频
5. DASH 动态流媒体：当你开始播放时，视频播放器使用 DASH 协议，基于你当前的网络状况，不断通过 HTTP 请求不同画质的视频分片

结构#

1. 传输层服务与多路复用 (3.1 - 3.2)
   • 网络层只负责把数据送到”主机”,而传输层负责将数据分发给主机上具体的”应用进程”(通过端口号实现多路复用/分解)
2. 无连接传输 UDP (3.3)
   • 一种”裸奔”的协议,仅提供多路复用和简单的错误检测,不保证可靠性,但延迟极低
3. 可靠数据传输原理 RDT (3.4)
   • 这是一个纯理论推导章节.探讨在一个会丢包,会出错的底层网络上,如何通过确认(ACK),定时器,序列号和重传机制,一步步构建出绝对可靠的传输通道
4. 面向链接的传输 TCP (3.5)
   • 理论落地.详细讲解 TCP 的报文结构,三次握手/四次挥手,RTT (往返时间) 估算,以及如何通过接收窗口(rwnd)实现流量控制
5. 拥塞控制原理与 TCP 拥塞控制 (3.6-3.7)
   • 探讨网络拥堵的代价.重点解析 TCP 如何通过拥塞窗口(cwnd)慢启动,拥塞避免(AIMD),快速恢复等算法
6. 传输层的演进 QUIC (3.8)
   • 介绍运行在 UDP 之上的现代协议 QUIC,它解决了 TCP 队头阻塞问题,并实现了更快的安全连接建立(HTTP/3 的基础)

知识点#

1. 端口与多路分解
   • UDP 的 2 元组 套接字仅由 (目的 IP,目的端口) 标识
   • TCP 的 4 元组 套接字由 (源 IP,源端口,目的 IP,目的端口) 唯一标识
     • 逻辑链接:为什么你的单台 Nginx Web 服务器在 80 端口上能同时处理成千上万个客户端连接? 因为每个客户端的源 IP 或源端口不同,TCP 依靠这 4 元组将流量精准分解到不同的线程/套接字中.这也解释了为什么客户端压测时会遇到”端口耗尽(Port Exhaustion)“问题
2. TCP 连接管理
   • 三次握手 (3-way Handshake):客户端发送 SYN,服务端回复 SYNACK,客户端回复 ACK
   • 四次挥手 & TIME_WAIT 状态:连接关闭时,主动关闭方会进入 TIME_WAIT 状态(通常持续 1-2 分钟),以确保最后一个 ACK 能到达对方
   • SYN 泛洪攻击与 SYN Cookies:恶意客户端只发 SYN 不发最后一步的 ACK,耗尽服务器资源.通过 SYN Cookies 技术,服务器初始不分配资源,而是用哈希值作为初始序列号,从而防御此类攻击
3. 核心机制:序列号,ACK 与快速重传
   • 累积确认 (Cumulative ACK) 的 ACK 数字表示”我正在等待接收的下一个字节号”,这意味着该数字之前的所有字节都已成功接收
   • 快速重传 (Fast Retransmit):如果网络丢包,发送方通常要等一个漫长的超时时间(Timeout)才能重传.但如果发送方连续收到 3 个冗余 ACK(即同一个 ACK 数字出现 4 次),它会立即判定后续报文已丢失,在超时发生前就执行重传,极大降低了延迟
4. “流量控制” 和 “拥塞控制”
   • 这是最容易混淆的两个概念,它们共同决定了 TCP 实际上能发多快:发送速率受限于 min(rwnd, cwnd)
   • 流量控制 (Flow Control - 保护接收方):接收方在 TCP 头部通过 rwnd (Receive Window) 字段告诉发送方自己接收缓冲区还有多少可用空间,防止发送方发得太快把接收方”淹没”
   • 拥塞控制 (Congestion Control - 保护网络):发送方自己维护一个 cwnd (Congestion Window),根据探测到的网络拥堵情况(丢包)来调整发送速度
   • 慢启动 (Slow Start):连接刚建立时,cwnd 呈指数级增长,以最快速度探明网络可用带宽
   • 拥塞避免 (AIMD):到达阈值后,转为线性增加(每 RTT 增加 1个 MSS);一旦发生丢包(如收到 3 个冗余 ACK),窗口直接减半
   • TCP CUBIC:现代操作系统常用的拥塞控制算法.丢包后,它能根据三次函数曲线,更快地将发送速率恢复到丢包前的水平
5. QUIC
   • 传统 HTTPS 需要先经历 TCP 握手,再经历 TLS(加密)握手,延迟高;且 TCP 保证严格按序到达,会产生”队头阻塞(HOL blocking)”. QUIC 跑在 UDP 上,在应用层实现了独立的可靠性和拥塞控制(类似 TCP NewReno),允许多个数据流多路复用,丢包只影响单个流

Chapter 4 Data Plane#

第四章聚焦单台路由器的局部动作，即当一个数据包达到路由器输入链路的时候，如何将其移动到正确的链路，这些动作通常都在纳秒之间完成且由硬件实现

Chapter 5 Control Plane#

在这一章中，我们主要聚焦于网络范围内的全局逻辑，即如何协调各台路由器，计算出数据包从源主机到目标主机的端到端路径

知识点#

对于两个章节来说，第四章的核心思想是解决单个路由器如何处理和转发数据包的问题，第五章的核心思想是网络范围内的逻辑协调，负责计算转发表并且管理网络设备