正好在前段时间，我在 Twitter 上看到了 AI Agents 这款 ChatGPT 插件。这款插件相当于把 AutoGPT 的功能整合进了网页版的 ChatGPT，可以讲一个复杂的指令拆分成单步操作。配合其他 ChatGPT 插件，即可实现搜自动搜索网页、查找文献，并将查找到的内容汇总在一起。

所以，我也打算尝试使用 AI Agents、Web Requests、WebPilot 三个插件，让 ChatGPT 整理一本关于 L4S 的电子书，帮助我更快速地了解 L4S。

第一次尝试：让 ChatGPT 生成一本关于 L4S 的电子书

初次尝试，我使用了这样一条指令：

Make AI Agent Objective: 整理一本介绍 Low Latency, Low Loss, and Scalable Throughput (L4S) 架构的电子书

可以看到，AI Agents 已经生成了关于整理和制作这么电子书的详细步骤，包括收集资料、整理资料、撰写电子书、校对和修改、发布电子书五部分：

接下来，ChatGPT 开始利用 Web Requests 和 WebPilot 插件上网搜索 L4S 相关信息，包括关于 L4S 的 RFC 文档（RFC 9330）和 IETF 草案，以及 RFC 9330 引用的其他文档。同时，ChatGPT 还能针对查找到的文档，提取关键信息，并提出可以进一步思考的问题：

通过不停地输入 keep going，ChatGPT 最终收集了足够的文档，并生成了电子书的目录：

接下来，我开始让 ChatGPT 撰写电子书的内容。最终生成的电子书如下：

**1. 引言**

低延迟、低丢包、可扩展吞吐量（L4S）架构是一种革命性的网络流量管理方法，旨在提高互联网应用的性能。L4S设计的目的是解决传统互联网架构的限制，这些架构并未针对现代应用的高速、低延迟需求进行优化。

L4S的主要目标是为所有用户提供高质量的互联网体验，无论他们的网络条件如何，或者他们正在使用的应用程序的类型如何。这是通过降低延迟、最小化数据包丢失和确保可扩展吞吐量来实现的。

L4S的一个关键特性是使用显式拥塞通知（ECN），这是一种允许网络节点在数据包丢失之前就信号拥塞的机制。这种对拥塞管理的主动方法使L4S能够在拥塞的网络条件下保持高性能。

在以下各节中，我们将深入探讨L4S的技术细节，探索其实际应用，并讨论其未来前景。

**2. L4S的技术细节**

低延迟、低丢包、可扩展吞吐量（L4S）架构基于一组创新的技术和协议，这些技术和协议共同工作以优化网络性能。L4S的一个关键组成部分是显式拥塞通知（ECN），这是一种允许网络节点在数据包丢失之前就信号拥塞的机制。

在传统的互联网架构中，数据包丢失被用作网络拥塞的信号。然而，这种方法可能导致高延迟和性能差，特别是对于实时应用程序，如视频流和在线游戏。ECN通过提供一种更主动的拥塞管理方法来解决这个问题。

在L4S架构中，ECN与一种新型的主动队列管理（AQM）——双队列耦合AQM一起使用。这种AQM操作两个队列：一个经典队列用于传统流量，一个L4S队列用于低延迟流量。L4S队列设计为保持非常浅的队列深度，这导致L4S流量的低延迟。

L4S的另一个重要特性是其可扩展的拥塞控制算法，它允许在高速网络中保持高吞吐量。这种算法设计为快速对网络条件的变化做出反应，确保网络能够在不引起拥塞的情况下有效地处理大量的流量。

**3. L4S在实践中的应用**

低延迟、低丢包、可扩展吞吐量（L4S）架构不仅仅是一个理论概念；它已经在实际的网络中实施，并且在网络性能方面显示出显著的改进。

L4S的一个关键应用是在数据中心，其中网络拥塞可能对应用程序的性能产生重大影响。通过使用L4S，数据中心可以确保其应用程序即使在重负载网络下也能保持低延迟和高吞吐量。

L4S也被用于互联网服务提供商（ISP）的网络中，以提高他们的客户服务质量。通过在他们的网络中实施L4S，ISP可以为他们的客户提供更好的互联网体验，具有更快的速度和更低的延迟。

L4S的另一个重要应用是在移动网络中，其中网络条件可能变化很大。L4S可以帮助确保移动用户获得一致的高质量体验，无论他们的网络条件如何。

除了这些应用，L4S还在其他领域被探索用于其他领域，如物联网（IoT）网络，其中低延迟和高吞吐量对于IoT设备的性能至关重要。

**4. 比较和对比**

低延迟、低丢包、可扩展吞吐量（L4S）架构代表了对传统互联网架构的重大进步。虽然传统架构依赖于数据包丢失作为网络拥塞的信号，但L4S使用显式拥塞通知（ECN）来主动管理拥塞。这导致了更低的延迟和更少的数据包丢失，从而为用户提供了更好的互联网体验。

L4S和传统架构的另一个关键区别是使用双队列耦合主动队列管理（AQM）。这种创新的方法使L4S能够以不同的方式处理不同类型的流量，确保所有应用的最佳性能。

与其他现代网络架构相比，L4S的可扩展性突出。L4S使用的拥塞控制算法设计为快速对网络条件的变化做出反应，允许它在高速网络中保持高吞吐量。这使得L4S成为数据中心和其他网络速度和容量至关重要的环境的优秀选择。

**5. L4S的未来**

低延迟、低丢包、可扩展吞吐量（L4S）架构不仅是解决今天的互联网挑战的解决方案，也是互联网架构未来的基础。

随着越来越多的设备连接到互联网，以及应用程序在带宽和延迟方面的需求越来越大，像L4S这样高效和可扩展的网络架构的需求只会增长。

L4S的未来发展的一个关键领域是在物联网（IoT）。预计未来几年将有数十亿的IoT设备连接到互联网，L4S处理大量流量的能力，以及其低延迟和高吞吐量将至关重要。

L4S在移动网络中的潜在增长是另一个领域。随着移动数据使用的持续增长，以及新技术如5G的更广泛应用，L4S可能在确保高质量的移动互联网体验中发挥关键作用。

除了这些领域，L4S本身也有进一步的研究和开发的机会。例如，可以开发新的拥塞控制算法以进一步提高L4S的性能，或者可以向L4S架构添加新的功能以支持新类型的应用。

**6. 参考文献和进一步阅读**

以下是本电子书中使用的信息来源列表。这些来源提供了大量关于低延迟、低丢包、可扩展吞吐量（L4S）架构的信息，建议对此主题感兴趣的读者进一步阅读。

1. [RFC 3168：向IP添加显式拥塞通知（ECN）](https://datatracker.ietf.org/doc/html/rfc3168)
2. [RFC 8311：放宽对显式拥塞通知（ECN）实验的限制](https://datatracker.ietf.org/doc/html/rfc8311)
3. [RFC 7560：对增加显式拥塞通知（ECN）反馈的准确性的问题陈述和要求](https://datatracker.ietf.org/doc/html/rfc7560)
4. [RFC 8084：网络传输断路器](https://datatracker.ietf.org/doc/html/rfc8084)
5. [RFC 8085：UDP使用指南](https://datatracker.ietf.org/doc/html/rfc8085)
6. [RFC 3649：大拥塞窗口的高速TCP](https://datatracker.ietf.org/doc/html/rfc3649)
7. [RFC 6679：用于UDP上的RTP的显式拥塞通知（ECN）](https://datatracker.ietf.org/doc/html/rfc6679)

可以看到，ChatGPT 确实生成了内容准确、章节清晰的电子书，能够方便用户更好地了解 L4S。但是，这边电子书仍存在这些不足之处：

• 生成的内容太短，不太像是一本「书」，而更像是一篇科普文章
• 大部分内容来自 RFC 9330 一篇文档，对于搜索到的其他文档，并没有太多地方提到
• 搜索的文档数量还没有那么充足。在搜索资料的过程中，没有找到关于 L4S 的另外两篇重要文档 RFC 9331 和 RFC 9332、关于 L4S 的 WWDC 视频、中文互联网上关于 L4S 的内容等

当然，这是我第一次尝试 ChatGPT + AI Agents，这些不足之处，应该都是能够通过继续向 ChatGPT 提问，进一步收集信息并完善电子书内容来解决的。后续我会进行进一步的尝试。

如果你能访问 ChatGPT，可以通过这个链接看到完整的生成过程：

• https://chat.openai.com/share/63ca36e6-0960-414b-907f-ec0b7bb600d0

第二次尝试：生成一篇关于 L4S 的科普文章

这次，我准备让 ChatGPT 生成一篇关于 L4S 的科普文章。我向 ChatGPT 提问时，补充了更丰富的信息：

Make AI Agent Objective: 博客文章写作
我最近观看了 WWDC 关于 L4S 的视频，了解到了 iOS 17 即将支持 L4S。想要对 L4S 了解更多。视频链接如下：
https://developer.apple.com/videos/play/wwdc2023/10004/
我了解到关于 L4S 有三篇重要的 RFC：
https://www.rfc-editor.org/rfc/rfc9330.html
https://www.rfc-editor.org/rfc/rfc9331.html
https://www.rfc-editor.org/rfc/rfc9332.html
研究了上面的 RFC，我对 L4S 有了详细的了解。

请根据上述信息写作一篇关于 L4S 的科普文章。这篇文章主要面向数码爱好者而非网络专业人士，要求文章详细介绍 L4S，且通俗易懂。

同时，我让 ChatGPT 逐步润色文章内容，并增加配图。最终生成结果如下：

标题：**探索L4S：低延迟和高吞吐量的未来**

你好，数码爱好者们！今天，我们将深入探讨低延迟、低丢包、可扩展吞吐量（L4S）的世界，这是一种新的网络服务，预计将彻底改变我们的数字体验。

在最近的WWDC上，苹果宣布iOS 17将支持L4S，引发了对这项创新技术的关注。但L4S究竟是什么，我们为什么要对它感到兴奋？

## 什么是L4S？

L4S是一种旨在在网络服务中提供低延迟、低丢包和可扩展吞吐量的协议。它在IP层使用显式拥塞通知（ECN）方案，类似于原始的ECN方法，但有一些关键的不同。

L4S的目标是使互联网应用能够实现低排队延迟、低拥塞丢包和可扩展的吞吐量控制。这是因为它认识到排队延迟的根本原因在于发送者的寻找容量的拥塞控制器，而不在于队列本身。

为了更好地理解L4S如何工作，我们可以看一下下面的流程图。这个图解释了如何通过一个独特的标识符将L4S流量与"经典"流量区分开来。

\`\`\`mermaid
graph LR
    A[Internet Traffic] --> B{L4S Identifier}
    B -->|Yes| C[L4S Traffic]
    B -->|No| D[Classic Traffic]
\`\`\`

L4S采用"可扩展"的拥塞控制，它触发来自网络的更频繁的控制信号，并以细粒度的调整对这些信号做出响应，使得L4S流量的排队延迟非常低（通常在毫秒以下）并且始终保持低延迟，而不会损害链路利用率。这意味着即使是寻求容量的（类似TCP的）流量也可以在高流量负载期间同时享受高带宽和非常低的延迟。

## L4S如何工作？

L4S通过一个独特的标识符将自己与"经典"（例如，适应TCP-Reno的）流量区分开来。然后，网络瓶颈可以逐步修改以区分和隔离仍然遵循经典行为的现有流量。这防止了它降低L4S流量的低排队延迟和低丢包率。

L4S架构的三个主要组成部分是：发送主机上的可扩展拥塞控制；网络瓶颈处的主动队列管理（AQM）；以及它们之间的协议。L4S服务不是由网络提供的，而是由L4S发送者使用的可扩展拥塞控制的精心行为产生的。

下面的流程图展示了L4S如何处理网络拥塞。当出现拥塞时，L4S会根据需要增加或减少队列的大小，以保持低延迟和高吞吐量。

\`\`\`mermaid
graph LR
    A[L4S Traffic] --> B[Dual Queue]
    B --> C[Queue for L4S]
    B --> D[Queue for Classic]
    E[Congestion] --> F{Adjustment}
    F -->|Increase| C
    F -->|Decrease| D
\`\`\`

L4S架构主要关注的是增量部署。它定义了允许L4S拥塞控制类别与“经典”拥塞控制类别在共享网络中共存的机制。目标是让L4S的延迟和吞吐量通常要好得多（很少会更糟），同时通常不会影响经典的性能。

## 为什么L4S重要？

L4S对互联网用户和数码爱好者来说是一场游戏规则的改变。它承诺提供始终如一的低延迟和高吞吐量，这意味着更快、更有效和更可靠的互联网体验。无论你是在流媒体视频、玩在线游戏，还是简单地浏览网页，L4S都旨在使你的数字体验更加流畅和愉快。

此外，L4S设计为可扩展，意味着它可以通过添加资源来处理增加的工作量。这种可扩展性使L4S成为一种未来的解决方案，可以随着我们的数字需求的发展而适应和增长。

下面的流程图展示了L4S如何处理网络容量的增加。当需要更多容量时，L4S可以添加更多的资源，以保持其高效率和低延迟。

\`\`\`mermaid
graph TD
    A[L4S Network] --> B{Need More Capacity?}
    B -->|Yes| C[Add Resources]
    B -->|No| D[Operate Normally]
    C --> D
\`\`\`

## 结论

有了像苹果这样的科技巨头的支持，L4S有望成为数字通信未来的重要参与者。随着我们向越来越数字化的世界迈进，像L4S这样优先考虑低延迟、低丢包和可扩展吞吐量的技术将在提供最佳的在线体验方面起着关键的作用。

请继续关注L4S和其他令人兴奋的数字趋势的更多更新！

## 参考文献

1. [An Introduction to L4S](https://domos.ai/blog/an-introduction-to-l4s/)
2. [RFC 9330: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture](https://datatracker.ietf.org/doc/rfc9330/)
3. [RFC 9331: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Dual Queue Coupled AQM](https://datatracker.ietf.org/doc/rfc9331/)
4. [RFC 9332: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Operational Specification](https://datatracker.ietf.org/doc/rfc9332/)
5. [WWDC 2023: iOS 17 Supports L4S](https://developer.apple.com/videos/play/wwdc2023/10004/)

## 延伸阅读

1. [L4S: The Low Latency Low Loss Scalable throughput TCP service](https://www.iab.org/wp-content/IAB-uploads/2016/03/briscoe.pdf)
2. [The L4S Architecture: the next generation of active queue management](https://www.bobbriscoe.net/projects/latency/l4sarch.pdf)

完整的生成过程可以在如下链接中查看：

• https://chat.openai.com/share/190ea312-070b-4844-a941-1d66c877cf98

总结

之前我使用 ChatGPT，主要是进行一些简单的文本处理，或者使用「沉浸式翻译」这样的工具来翻译网页。而这次体验 AI Agents 插件后，我感受到了 ChatGPT 处理复杂任务的能力。

接下来，我将在 ChatGPT 的帮助下进一步学习 L4S，并在后续的文章中分享自己对 L4S 的理解。

备注：

• 题图来源：https://unsplash.com/photos/X5CSjHTjlgw

当家中的联网设备越来越多，你是否会想过，这些设备可能会给家庭网络带来安全风险？

智能家居设备会带来哪些安全性问题？

那么，为什么智能家居设备会给家庭网络带来安全风险？这些设备会带来哪些安全方面的问题？

首先，设备接入家庭网络后，就有能力做到扫描网络中的所有设备，收集家中手机、电脑、路由器等的品牌、型号，以及家庭的地理位置¹，用于数据分析，或者精准推送广告：

• 被曝私自采集用户数据 创维电视与勾正数据相继回应 | 每经网
• 群晖被家里的智能电视尝试登陆SSH和ftp 服务器是什么情况？ – 恩山无线论坛

另外，在软件开发过程中，开发者可能会因为编码疏忽、方便调试等原因，或者引用的第三方 SDK 有问题，有意或者无意地为设备引入后门或漏洞。尤其是软件开发流程不规范的小团队，更有可能给设备带来漏洞。

其中一部分漏洞会使设备绕过 NAT 或防火墙的保护，直接暴露在公网。例如某品牌手机的「快应用」实现，就通过 UPnP，将 55555 端口映射到公网，导致手机能被 Internet 上的所有设备访问：

• （转）Vivo 手机某系统进程开放 55555 端口 初步确定为快应用 – Stage1st

设备上的漏洞还可能会被黑客利用，用来做为跳板，扫描、攻击内网设备，或者用于对外发起 DDoS 攻击：

• 新发现的Mirai Botnet正在操纵各类物联网设备进行DDoS攻击 – cnBeta.COM

还有黑客会利用设备上的漏洞，进行「挖矿」等活动，或者将设备作为 PCDN 节点，占用设备的 CPU、存储、带宽等资源，降低设备寿命：

• 全球首次爆发安卓挖矿蠕虫 智能电视变“矿机”

对于监控摄像头（包括带摄像头的电视机）、智能音箱等设备，如果存在漏洞，理论上黑客能够利用漏洞，「偷看」或者「偷听」家中的画面和声音，严重威胁我们的个人隐私：

• Foscam摄像头设备漏洞分析报告
• 烽火三十六技丨谈摄像头安全隐患及网络摄像头资产数据分析 – FreeBuf网络安全行业门户

对于带有存储功能的智能设备，例如摄像头、NVR、NAS，漏洞还可能导致数据泄漏或丢失：

• SynoLocker: 针对 Synology NAS 的勒索病毒
• Qlocker: 针对 QNAP NAS 的勒索病毒
• 西数：黑客利用远程漏洞抹除My Book用户数据 正研究潜在恢复方案 – 安全 – cnBeta.COM

另外，对于带有云服务的智能硬件，云服务也有可能存在漏洞，或者运维的过程中出现失误，导致隐私泄漏：

• 小米摄像头被谷歌紧急封禁！别人的设备，能看到你家现场 | 量子位
• 小米回应智能摄像头被谷歌停用：解决问题后重新上线|小米|谷歌|智能摄像头_新浪科技_新浪网

如下两篇综述，对智能家居设备、物联网操作系统的安全性问题进行了全面的整理：

• 物联网操作系统安全研究综述
• 智能家居安全综述

如何提高智能家居设备的安全性？

使用重视安全的厂商的智能家居设备

在我们选用智能硬件时，尽量选用大公司、或者重视安全的公司的产品。

大公司的产品，用户量相对较大，更容易受到安全研究人员的关注。这使得安全漏洞更容易被暴露出来，并得到修复。

下图是 Apple Product Security 邮件列表中的一封邮件，可以看出，在软件更新中，Apple 解决了一系列第三方研究机构上报的安全问题：

Apple Product Security 邮件

相对来说，大公司的软件开发流程也会更加规范，会有完整的开发、代码审查、测试等步骤，对于安全问题的响应也会更及时²。

接下来是一些小技巧，通过这些技巧，读者可以粗略判断出一家公司是否重视安全：

首先，可以观察一下厂商官网上，是否有漏洞反馈页面，或者安全奖励计划页面。虽然有这些页面并不完全代表厂商重视安全，但还是能一定程度上看出厂商对安全问题的态度：

• 华为安全奖励计划
• 大华产品安全事件响应中心 
• 小米安全中心
• 漏洞盒子 | 美的IoT安全应急响应中心 （MIoTSRC）
• TCL安全应急响应中心 

此外，还可以查找厂商是否提供安全白皮书，并阅读白皮书中的内容。重视安全的公司，一般会将自己的产品如何保护用户的安全与隐私，详细在白皮书中描述：

• Apple Platform Security – Apple Support
• MIUI12隐私白皮书
• 涂鸦智能安全白皮书

还可以阅读厂商的软件更新日志，观察安全漏洞修复的及时程度。另外，部分厂商还专门提供有安全漏洞更新的邮件列表，或者安全预警邮件，及时通知用户如何解决安全漏洞：

• Security-announce Info Page
• Synology 产品安全顾问 | 群晖科技 Synology Inc.

正确设置路由器，避免设备暴露在公网

家用路由器中一般运行有 NAT，能够避免内网设备被外网访问。这样，攻击者很难从外网直接访问家中的智能家居设备，大大减小了漏洞被利用的可能性。

但是，如果路由器设置有误，例如将智能家居设备设置为 DMZ 主机，或者错误设置了端口转发规则，仍会有可能让设备暴露在公网。

建议定期检查路由器中 DMZ、端口转发等设置，并删除错误配置。

设置防火墙，阻止设备访问 Internet

如果路由器设置正确，不将设备暴露在公网，智能家居设备就难以被外界攻击，安全性大大得到提升。

但是，智能家居设备仍然可以访问 Internet，连接设备厂商的服务器。阻止智能家居设备访问 Internet，能避免厂商通过智能家居设备收集家庭网络中的隐私数据，也能避免厂商服务器被攻击时，家中的智能家居设备被黑客控制。

路由器中的「防火墙」或「家长控制」功能，可用于阻止内网设备访问 Internet：

• 路由器防火墙应用举例—（1）IP地址过滤的使用 – TP-LINK
• 网络控制（家长控制）：暂停网络连接 – AmpliFi

当然，阻止设备访问 Internet，也会带来一些不便之处，例如不能使用厂商的 App 进行远程控制、无法实现高级自动化功能等。针对这些问题，可考虑控制设备的在线时间：例如对于摄像头，可通过脚本，实现有人在家时禁止联网，只有家中无人时，才允许摄像头联网，从而一定程度上取得安全与便利的平衡。

也可以考虑使用 HomeKit、Home Assistant 等工具，实现远程访问家庭设备，具体请参考下文中的介绍。

使用 HomeKit

HomeKit 是来自 Apple 的智能家居平台。与 Google Home、米家等其他厂商的智能家居平台不同，HomeKit 的实现方式比较「另类」，所以在此处单独进行介绍。

• HomeKit 从零完全入门指南（一）：认识 HomeKit – 少数派

大部分智能家居厂商都提供了「云服务」。智能家居设备和手机 App 连接到厂商服务器，实现了出门在外时，也能通过手机 App 控制智能家居设备。

但这样的云服务大多没有实现「端到端加密」。也就是说，手机和智能家居设备之间传输的数据，在服务器上是以明文形式存在的。如果设备厂商的内部管理不严格，运维人员就能看到这些数据。

非端到端加密，数据在服务器上以明文形式存在

而 HomeKit 实现了端到端加密，手机 App 和 HomeKit 家庭中枢之间通信的数据全程保持加密，在服务器上也不会解密 ，安全性更高。

端到端加密，数据在服务器上保持为密文

此外，HomeKit 有如下两个功能，能够提升智能家居的安全性：

其中一个是 HomeKit Secure Video。

当用户购买 iCloud+ 后，HomeKit Secure Video 能将能 10 天内的摄像头录像存储在 iCloud，不额外占用 iCloud 存储空间。摄像头录像在 iCloud 中同样受到端到端加密的保护³。

• HomeKit 摄像头安全性 – Apple 支持
• koush/scrypted：使普通摄像头支持 HomeKit Secure Video

另一个是  受 HomeKit 保护的路由器。

HomeKit 通过一种相对安全的方式，实现了外网访问家中的智能家居设备。所以，使用 HomeKit 之后，就可以按照上文中的介绍，阻止智能家居设备访问 Internet，进一步提升安全性，而不会牺牲太多便利性了。

如果有支持 HomeKit 的无线路由器，这一步的操作会更加便捷。HomeKit 能自动设置路由器，阻止智能家居设备访问 Internet，无需用户手动修改复杂的防火墙规则。同时，HomeKit 路由器还支持 PPSK 认证，避免泄漏主 Wi-Fi 密码。

• 使用 HomeKit 保护路由器 – Apple 支持
• 使用受 HomeKit 保护的路由器 – Apple 支持 (中国)

目前，支持 HomeKit 的智能家居设备数量较少，且价格偏贵。可考虑使用 HomeBridge，让更多第三方设备接入 HomeKit：

• Homebridge
• 如何让米家设备轻松接入 HomeKit？
• HomeBridge 操作指南：从零开始，将你的米家设备接入 Homekit
• 教你把索尼电视接入 HomeKit 平台
• 借助树莓派与 HomeBridge ，将 YeeLight 彩光灯接入 Apple HomeKit | Matrix 精选

当然，HomeKit 并不能保证绝对的安全。不少智能家居设备，除了支持 HomeKit，也提供了自己的 App。通常情况下，设备厂商自己的 App 会提供比 HomeKit 更加丰富的功能，但不一定能提供与 HomeKit 相同等级的安全性。

另外，HomeKit 是闭源软件，HomeKit 基础设施也由 Apple 控制，而不是由用户控制。理论上 Apple 可以私下改变 HomeKit 的实现方式，而不提前通知用户。至于是否应该信任 Apple，就需要读者自行判断了。

• HomeKit 数据安全性 – Apple 支持
• 从 Apple 儿童安全功能的原理出发，聊聊它为什么引发热议 – 少数派
  • Reddit用户发现CSAM检测中使用的苹果NeuralHash算法隐藏在iOS 14.3中 – cnBeta.COM（虽然 Apple 表示在 iOS 15 中启用 CASM检测功能，但是 iOS 14.3 也被发现存在 CASM 检测代码）

自行搭建 Home Assistant

对于不使用 Apple 设备、或者不信任 Apple 的用户，还有另外一种选择：Home Assistant。

• Home Assistant 官网
• Homeassistant：不仅仅是更优秀的智能家居解决方案
• Home Assistant + 树莓派：强大的智能家居系统 · 安装篇

Home Assistant 是一个开源的智能家居平台，可以搭建在 NAS、Raspberry Pi 或者高性能的无线路由器⁴上。通过 HomeBridge，可以实现对智能家居设备的集中控制，以及智能家居设备的跨厂商、跨平台自动化。

将所有智能家居设备接入 Home Assistant 之后，只需要通过安全的方式让 Home Assistant 可被外界访问⁵，就可以阻止智能家居设备访问 Internet，统一使用 Home Assistant 控制智能家居设备了。

选购支持 ONVIF 等开放协议的摄像头，并将监控录像存储在本地

对于监控摄像头，也有不少厂商提供了云服务，可以将监控录像存储在云端，方便视频回放和远程访问。

但是，如果厂商的云服务没有采取正确的加密措施，或者存在安全漏洞，可能就会导致监控录像泄漏。如果担心这样的问题，最好的办法，就是将视频存放在本地。

很多 NAS 都拥有强大的摄像头监控录制软件，例如 Synology 和 QNAP 的 Surveillance Station。可以通过这些工具，将摄像头录像保存在 NAS 上：

• Surveillance Station | 群晖科技 Synology Inc.
• Surveillance Station 安全监控 | NAS 上的 IP 影像监控管理系统 | QNAP

如果想要将视频监控数据和 NAS 上的重要数据分离，还可以考虑使用 NVR 设备：

• 网络硬盘录像机（NVR） | 后端产品 | Hikvision
• Ubiquiti | UniFi | 易于扩展的安防监控系统

对于 NAS 和 NVR，一般使用 ONVIF 协议来连接摄像头。做为一个通用的协议，绝大多数厂商都生产支持 ONVIF 的摄像头，但互联网品牌的家用摄像头（例如小米、Nest 等品牌），也有很多不支持该协议。在选购时需要注意。

如下两个摄像头均支持 ONVIF，且价格不贵，适合搭配 Surveillance Station 或 Home Assistant 使用：

• 169元带云台摄像头实现群晖Surveillance Station高清录像+IPC控制 – KoolShare
• 群晖接入水星（MERCURY）MIPC251C-4网络摄像机-左搜
• 伪开箱 – 水星 mipc251c-4 摄像头 + HomeAssistant 迎宾系统搭建_摄像头_什么值得买

使用单独的 VLAN 和 SSID，将智能家居设备与其他设备隔离

家庭网络中的设备，一般位于同一个局域网，设备之间可以相互访问。设备间的相互访问，可能也会带来安全和隐私问题。

例如前文中提到的，智能家居设备可能会扫描家庭中的所有设备，泄漏设备型号、地理位置等信息。

再例如，即使在路由器上阻止了家中的摄像头访问 Internet，但是，如果电脑感染恶意软件，电脑也有可能访问摄像头，获取摄像头录制的视频，并发送到恶意网站，导致隐私泄露。

那么，什么样的措施，能够阻止家庭网络内设备间的相互影响？划分 VLAN，就是其中的一种方法。不同 VLAN 间的设备能够相互隔离，避免直接访问⁶。关于 VLAN 的基础知识和实际应用，可通过如下两个链接了解：

• 告别杂乱的弱电箱，用网管交换机布置舒适简洁的家庭网络 – 少数派
• 用最野的路子教你布局家庭网络@第二期——通过VLAN实现单网口软路由网口复用 – 哔哩哔哩

VLAN 是以太网的概念，通常只用于有线网络。对于 Wi-Fi，可以创建多个 SSID，让不同的VLAN 绑定不同的 SSID，使链接 Wi-Fi 的设备也能做到相互隔离：

• How do I create multiple SSID’s to operate on multiple VLAN’s | Answer | NETGEAR Support
• Isolating my IOT Devices on a VLAN with the Unifi Dream Machine
• Setup IoT VLANs and Firewall Rules with UniFi. ULTIMATE (Smart) Home Network Part Three
• Ultimate Home Network 2021
• Secure IoT Network Configuration

创建多个 VLAN 和 SSID 看似复杂，但实际上，路由器上的「访客模式」功能，就是通过自动划分 VLAN 和 SSID，实现访客网络的家庭网络的隔离的。希望后续家用无线路由器厂商能够进一步优化，提供一键创建 IoT 网络的功能。

mDNS Proxy

划分 VLAN 和 SSID 虽然提升了安全性，但是智能家居和手机等设备处于不同的网络，无法实现 HomeKit、AirPlay、手机 App 控制等功能⁷。

不过，大部分智能家居设备，使用了 mDNS 和 DNS-SD 协议。这使得我们有办法实现跨 VLAN 控制智能家居设备。

mDNS/DNS-SD 协议用于局域网内的服务发现。该协议最早由 Apple 发扬光大：Apple 通过 Bonjour 软件实现了这两个协议，并在 AirPlay、AirPrint、iTunes 家庭共享、AirPort 路由器等产品和服务中得到了广泛应用。

• RFC 6762 – Multicast DNS
• RFC 6763 – DNS-Based Service Discovery 
• Apple中国 – Mac OS X – Bonjour
• Bonjour – Apple Developer

在智能家居时代，无论是 Apple 的 HomeKit，还是小米米家，都选择使用 mDNS 来查找和发现局域网内的智能家居设备。

mDNS 在大部分情况下，仅限在一个局域网内使用。但一部分路由器支持 mDNS Proxy⁸，能够从一个网络内学习 mDNS 信息，并发布到另一个网络，从而实现跨网络的设备发现。对于不支持 mDNS Proxy 的路由器，也可以使用第三方软件实现：

• UniFi – Best Practices for Managing AirPlay/Chromecast on UniFi Network – Ubiquiti Support and Help Center
• 开源一个自用的 mDNS 反射软件： 解决局域网跨 VLAN 服务发现难题，让你的 IoT 设备可以跨 VLAN 使用 – V2EX
• 配置Bonjour网关示例（AP与AC间二层转发） – WLAN V200R010C00 典型配置案例集 – 华为

使用安全的隧道访问内网设备

如果将内网设备直接暴露在公网，很有可能带来安全问题。

当然，我们可以选择使用 Home Assistant，将 Home Assistant 暴露在公网，并添加 HTTPS 等安全措施。但是，这样做也会有几个缺点：

• 设置麻烦
• 部分设备不支持 Home Assistant
• Home Assistant 拥有 Web 界面，但国内家庭宽带不允许搭建 Web 服务

所以，可以考虑通过建立安全的隧道，让外部设备与家庭设备形成一个虚拟的局域网，实现在外部访问内网设备。这种方式在本文中不再详细介绍，感兴趣的读者可以自行上网搜索。

DIY 智能家居设备

注意：本方法只适合有经验的读者。如果操作不当，可能会带来危险，包括但不限于导致身体受伤、中毒、触电，或引发火灾。

对于具有嵌入式开发能力的读者，还可以选择 DIY 智能家居。自己制作的智能家居设备，软硬件相对可控，而且与成品设备相比，能够自由组合不同的传感器和各种器件，实现成品设备无法实现的功能。

一般来说，DIY 智能家居具有较高的门槛。但是，随着开源软件和开源硬件的流行，Arduino 生态的逐渐完善，以及像 ESP8266/ESP32 这样的廉价易用的 SoC 的出现，用户可以用类似「搭积木」的方式，方便地制作出自己的智能家居设备。在少数派上，也有作者分享过基于 ESP8266 的优秀项目：

• 如何制作一个 WIFI 像素时钟，只要Lametric十分之一的价格

ESPHome 项目可以让用户使用 ESP8266/ESP32，连接各种传感器和电子模块，制作自己的智能家居设备，并接入 Home Assistant。ESPHome 提供的软件框架，可通过配置文件方便地添加功能，无需编程：

• ESPHome — ESPHome

虽然可以使用开源软硬件来制作自己的智能家居设备，但是在制作时，还是要尽量自己对代码进行阅读和审计，确认代码是否安全。

如何发现智能家居设备正在偷偷「做坏事」？

对于已有的智能家居设备，是否有办法看到设备正在做什么？有没有在「做坏事」？在下文中，笔者将介绍几种方法。

检查路由器上的 UPnP 端口映射信息

部分智能家居设备，会通过 UPnP/NAT-PMP，将端口映射到公网。这样做能方便外网访问，但也会带来安全风险。

建议定期检查路由器中的 UPnP 表项，观察是否有设备偷偷开放了不必要的端口。

路由器上的 UPnP 表项

另外，还有一部分路由器，能够统计出通过 UPnP 端口映射转发了多少流量。如果流量过大，则有可能是设备受到了攻击，或者被厂商偷偷用做 PCDN 节点。

端口转发统计信息

使用 Pi-hole、AdGuard Home 等广告过滤工具

想要具体知道设备访问了哪些域名，可以使用 Pi-hole、AdGuard Home 等广告过滤工具。

• Pi-hole – Network-wide protection
• AdGuard Home| 适用于任何操作系统（Windows，macOS，Linux）的网络软件
• AdGuard Home 安装及使用指北
• AdGuard Home：用 DNS 巧去广告，所有设备都能用
• 基于树莓派的全能广告屏蔽助手 —— Pi-hole

这些工具做为 DNS 服务器运行，能够记录和统计家庭网络中所有设备的 DNS 请求，同时屏蔽广告域名和恶意域名。

AdGuard Home 仪表盘界面

不过，一部分设备可能会使用固定的 DNS 服务器地址，或者使用 DNS-over-TLS、DNS-over-HTTPS 等新型的加密 DNS 协议，无法由用户指定 DNS 服务器。对于这样的设备，Pi-hole 等工具就无能为力了。

DPI

DPI 全称为「深度包检测」，能够深入分析经过网络设备的所有数据，以便于对智能家居设备的行为进行分析。

与 Pi-hole 等基于 DNS 的工具相比，DPI 能监控智能家居设备所产生的所有网络流量，实现更全面的分析。

一部分路由器自带了 DPI 功能，例如 Ubiquiti EdgeRouter。对于使用开源操作系统（例如 OpenWrt 或 pfSense）的路由器，可通过安装 ntopng 来实现 DPI 功能：

• ntopng – ntop

IDS/IPS

IDS 全称为「入侵检测系统」，IPS 全称为「入侵防御系统」。这两者在 DPI 的基础上，增加了安全策略，从而可以实现对恶意行为的检测和拦截。常见的 IDS/IPS 包括 SNORT 和 Suricata：

• Snort – Network Intrusion Detection & Prevention System
• Suricata

在这篇文章中，我们可以看出，通过 SNORT 规则，可以检测网络中是否有利用摄像头漏洞进行攻击的活动：

• 漏洞聚焦：Foscam C1 室内高清摄像机存在多个漏洞

IDS/IPS 需要网络设备有较高的性能，在家用路由器里，华硕等品牌的部分型号支持 IPS/IDS。对于拥有高性能软路由的读者，可自行安装 SNORT 或 Suricata，其中，pfSense 和 OPNSense 操作系统对 SNORT/Suricata 的支持比较完善。

蜜罐

蜜罐（英语：honeypot）是一个电脑术语，专指用来侦测或抵御未经授权操作或者是黑客攻击的陷阱，因原理类似诱捕昆虫的蜜罐因而得名。 — Wikipedia

之前某品牌电视自动扫描内网、尝试通过 SSH 登录内网设备，通过蜜罐，就可以方便的「抓出」这些行为

前文中提到的，某些品牌的电视自动扫描内网、尝试通过 SSH 登录内网设备的行为，通过蜜罐，就能非常容易地被发现。

部分路由器自带蜜罐功能，例如笔者正在使用的 UniFi Dream Machine，就带有一个简单的蜜罐。从截图中可以看到，有内网设备访问了蜜罐上的 21、23、80 端口，可以根据这些信息，确认内网设备是否有恶意行为。

UniFi Dream Machine 上的蜜罐

也可以自行在路由器、Raspberry Pi 等设备上安装蜜罐。开源的蜜罐有很多种，可以参考如下链接了解：

• awesome-honeypots/README_CN.md at master · paralax/awesome-honeypots

抓包

除了上文中介绍的方法，还有一种适合专业的用户的方法：抓包。

抓包指的是用工具记录下网络中经过的所有报文，以便于后续进行人工分析。常用的抓包工具是 Wireshark，能够通过图形化的界面来捕获和分析报文：

• Wireshark · Go Deep.

tcpdump 则是一款基于命令行界面的抓包工具。一部分基于 Linux 操作系统的路由器，已经内置了 tcpdump 工具：

• TCPDUMP/LIBPCAP public repository

抓包的结果，需要进行人工分析，才能知道智能家居设备的行为。所以，这种方式只适合专业用户使用。如下链接的博客节目中，有通过抓包方式观察到光猫异常行为的案例，可供大家参考：

• 吟诗的光猫 | 内核恐慌 #61

那么，这样做是不是太麻烦了？

上文中介绍了一系列提高智能家居设备安全性的方法。一部分方法操作较为繁琐，甚至会限制智能家居的部分功能……

使用智能家居本来是为了方便。使用了这些方法，是不是过于复杂，得不偿失了？

在《你的必要隐私手册Android 篇：权限管控与存储空间隔离》一文中，作者 pokon548 说到：

隐私与便利是一门平衡的艺术，世上并不存在绝对的隐私。

其实，对于智能家居设备的安全与隐私问题，也是同样的道理。本文列举了提高智能家居安全性的一系列方式，读者可以根据自身情况，选择出最适合自己的方式，来取得安全与便利的平衡。

当然，也不是说采用了本文中的所有措施，就一定能保护好安全和隐私了。最重要的是，做为用户，我们需要逐步提高安全意识。相反，如果安全意识不足，部分采用本文中的方法，可能还会引入新的安全问题：例如使用 Home Assistant 时，如果没有设置强密码、没有及时更新，且 Home Assistant 暴露在公网，可能就会导致家庭网络被入侵。

另外，对于非常敏感的数据，最好还是尽量保持「离线」。例如摄像头尽量不要放在卧室、智能电视在不用的时候彻底断电、不需要智能功能的设备直接断开网络……

> 题图来自 Unsplash，作者是 Dan LeFebvre。本文部分图片素材来自 Flaticon，作者分别是 xnimrodx、Freepik、DinosoftLabs。
> 想要了解更多关于家庭网络的知识？欢迎在 GitHub 上关注 blanboom/awesome-home-networking-cn。
> 本文首发于少数派，原文链接：https://sspai.com/post/69223

• Nintendo Switch 等游戏主机上的 NAT Type 是 D，导致无法联机游戏
• 使用 eMule 下载文件时，发现获取到了 Low ID，导致下载速度变慢
• 家中的 NAS 只能在内网使用，很难将 NAS 上的文件分享给其他人。出门在外时，想要下载 NAS 上的文件，也发现无法连接。

或许你还会对这些问题感到好奇：

• 每天有那么多人使用微信进行视频通话，腾讯的服务器是否能承受这么大的流量？是否需要支付高额的流量费用？
• 为什么在十多年前，我们就看到过 IP 地址资源不足的新闻。而现在，互联网用户越来越多，IP 地址资源不足却似乎并没有给我们带来什么影响。

其实，这些问题都与 NAT 有关。少数派上已经有两篇文章，也提到了 NAT：

• 入网指南 04 | IP 地址大揭秘 – 少数派
• 局域网游戏串流：让我们都做一回「云」玩家 – 少数派

那么，NAT 到底是什么？NAT 会为我们的「网上冲浪」带来哪些不便之处？如何解决 NAT 为我们带来的不便？…… 本文将尝试详细地解答这些问题。

为什么需要 NAT

在 Internet 上，每台设备都有一个 IP 地址。IP 地址和我们日常生活中的家庭住址类似，一台设备想和另一台设备通信，必须知道另一台设备的 IP 地址，才能将数据发送到对方。

对于 IP 地址的基础知识，少数派已经有一些文章进行了介绍。读者可参考这些文章进行了解：

• 入网指南 04 | IP 地址大揭秘 – 少数派
• 小白也能看懂的网络基础 04 | IP地址是如何工作的 – 少数派
• 小白也能看懂的网络基础 05 | IP 地址深度学习 – 少数派

对于个人、家庭的网络设备，IP 地址一般由运营商分配。在过去，一户家庭一般只有一台电脑，这台电脑通过调制解调器（moden）直接接入 Internet，获取运营商分配的 IP 地址。

而现在，很多家庭会同时拥有手机、电脑、智能家居等多种联网设备，一个 IP 地址完全不够这么多设备使用。

对于常用的 IPv4 地址，其格式是这样的：

可以看出，IPv4 地址一共有 4 294 967 296 个。由于全球互联网用户越来越多，IPv4 地址已经严重不足。

综上，如下两个原因，让我们面临了 IP 地址不够用的问题：

1. 家庭中有多个设备需要联网，但运营商只会分配一个 IP 地址
2. 全球联网设备越来越多，但 IPv4 地址资源有限

所以，我们需要一种技术，让多个设备「共用」同一个 IP 地址，来缓解 IPv4 地址不够用的问题。

什么是 NAT

NAT 的全称是「网络地址转换」（Network Address Translation），指的是路由器等网络设备，在传输数据的过程中，改变数据中的 IP 地址的一种技术。

NAT 可用于内网 IP 地址（以下简称为「内网 IP」）和公网 IP 地址（以下简称为「公网 IP」）之间的转换。例如家庭中的多个联网设备，都拥有各自的内网 IP，无线路由器运行 NAT 功能；家中的设备向外发送数据时，数据中的内网 IP，在无线路由器上会被转换为公网 IP；外部数据发送到家庭设备时，数据中的公网 IP，会被转换为内网 IP。

通过这种方式，家庭设备能够「共享」同一个 IP 地址。即使运营商只为用户分配了一个 IP 地址，用户家中的多台设备，也能同时访问 Internet。

做为对比，如果没有 NAT，家中每一个设备，都需要获取一个独立的公网 IP 地址，对于本来就少的 IPv4 地址资源，就显得有点「奢侈」了。

另外，在 IPv4 地址资源越来越紧张的今天，很多电信运营商，已经不再为用户分配公网 IP；而是直接在运营商自己的路由器上运营 NAT，为用户分配内网 IP。这样，只需要少量的 IP 地址，就可以支撑大量用户的上网需求。这样的 NAT 又叫做 CGN（Carrier-grade NAT，电信级 NAT）。

当然，NAT 还有一些其他的用途，例如做为 IPv4 到 IPv6 的过渡技术。本文暂不讨论这些应用场景。

NAT 是如何工作的

NAT 改变了报文中的 IP 地址。但是，为什么我们平时上网时，并没感觉到 NAT 的存在？

在上文中的例子里，多台内网设备共用同公网 IP。外部数据到达路由器后，路由器应该将数据发送给哪个内网设备？

在介绍 NAT 的工作原理之前，让我们先了解一下另外一个概念：端口号。

• 小白也能看懂的网络基础 07 | TCP和UDP是如何工作的？ – 少数派

简单说，在网络中传输的数据，会被拆分一个个较小的片段。每个片段被称为一个报文。在报文中，除了 IP 地址，一般还包含了端口号。

IP 地址每台电脑唯一，用来找到网络中的电脑。端口号每个应用程序唯一，报文到达电脑后，可根据端口号匹配到应用程序。

在报文中，包含了两个 IP 地址和两个端口号，分别是来源 IP、目的 IP、来源端口、目的端口：

我们使用的大部分软件，例如网页浏览器，都是客户端软件。客户端需要主动向服务器发起连接。

例如，当我们访问少数派网站 sspai.com 后，浏览器能够解析到网站的 IP 地址（下文以 119.23.1.2 为例，不代表网站真实 IP），主动向该地址发起报文，建立连接。由于浏览网页使用的 HTTPS 协议，端口号为 443，所以报文中的目的端口号填充为 443，来源端口号是一个随机分配的值。

当少数派网站收到请求后，则会向用户的浏览器发送网页数据¹。发送的数据中，来源端口号为 443，目的端口号则为用户请求报文中的源端口号。

从下图中也可以看出，回应报文的目的 IP，就是请求报文的源 IP，也就是用户电脑的 IP 地址；回应报文的目的端口号，就是请求报文中的源端口号，也就是用户浏览器的端口号。这样，少数派服务器的回应报文，就能根据 IP 地址发送回用户电脑，并根据端口号最终到达浏览器：

那么，如果用户的电脑是内网设备，经过了 NAT，使用浏览器访问少数派网站时，又会是什么样的过程呢？

首先，浏览器同样会发送请求报文，报文的源 IP 为电脑的内网 IP （此处以 192.168.1.126 为例）。

当报文到达路由器后，路由器将报文源 IP 修改为公网 IP（1.1.1.10），并分配一个新的源端口号。在这个过程中，路由器会记录下源 IP 和源端口号，在转换前后的对应关系，形成 NAT 表项。

路由器将源 IP 和源端口号转换后的报文发送到服务器，服务器回应的报文，目的 IP 和目的端口端口号，就是请求报文中的源 IP 和源端口号。这样，报文就能根据目的 IP，到达用户的路由器上。

路由器收到来自服务器的报文，根据 NAT 表项，将目的 IP 和目的端口号，从外部 IP、外部端口，转换为内部 IP、内部端口。这样，报文就能顺利到达用户电脑的浏览器上。

从上面的例子中可以看出，NAT 通过记录端口号²、IP 地址的对应关系，将出方向报文的源 IP、源端口号从内部地址转换为外部地址，将入方向报文的目的 IP、目的端口号从外部地址转换为内部地址，让内网设备也能正常访问 Internet。但如下两种情况，是 NAT 难以做到的：

1. 内网设备做为服务器，外部设备主动向内网设备发起连接
2. 使用 TCP、UDP 之外的、没有端口号的协议进行通信³

由于我们日常上网，使用的基本上都是 TCP 和 UDP 协议。而且自己的设备一般是做为客户端，主动连接第三方服务器的。所以，在日常上网的情况下，我们一般不会感受到 NAT 的存在。

NAT 为我们带来了哪些不便之处

NAT 缓解了 IP 地址资源不足的问题，同时能使家庭中的多个设备共享同一条宽带，同时上网。另外，启用 NAT 后，外部设备无法主动发起对内网设备的连接，相当于起到了防火墙的作用，保护了内网设备，一定程度上提高了安全性。

NAT 通过「巧妙」的方式，在内部地址和外部地址之间进行转换。大部分情况下，我们感受不到 NAT 的存在。但仍有部分应用，需要内网设备做为服务器，被外部连接，例如：

• 远程访问家中的 NAS、监控摄像头
• eMule、BitTorrent 等 P2P 文件分享应用，使自己的设备可供外部连接，从而能够连接到更多分享者，获取更快的下载、上传速度
• 部分语音通话、视频会议应用，通信双方直接连接，获取更好的通话质量
• 部分联机游戏，不会经过第三方服务器，需要玩家之间直接建立连接

对于这些应用，如果设备位于 NAT 之内，没有公网 IP，就难以实现了。

如何在 NAT 场景下，使内网设备可被连接

那么，在 NAT 环境下，应该如何让内网设备做为服务器，使内网设备被外部连接？下文将介绍几种常见的方式。

多拨

部分运营商，支持在多个设备上，通过 PPPoE 登录同一个宽带账号。每个设备都能获取到一个独立的公网 IP。⁴

如果想让游戏主机等设备获取独立的公网 IP，供外部连接，可以在光猫之后连接交换机。游戏主机连接交换机，直接进行 PPPoE 拨号。无线路由器也连接交换机，家中的其他网络设备经过无线路由器访问 Internet。

但是多拨的局限也很大：

• 仅部分运营商支持多拨
• 一些运营商已不再为用户分配公网 IP，即使通过多拨，也获取不到公网 IP
• 越来越多的设备不再支持 PPPoE。例如 Xbox 360 支持 PPPoE，但 Xbox One 之后的版本已不再支持
• 设备直接获取公网 IP，暴露在公网上，安全性较差。可能需要单独设置防火墙
• 需要额外购买交换机，连接在光猫和路由器之间。会改变家庭网络拓扑，操作比较复杂

所以，这种方式不太常用。

端口转发、DMZ

上文中介绍的 NAT，路由器会根据内网设备发出的报文，自动形成 NAT 表项。实际上，用户还可以在路由器上手动配置端口映射关系，让内网设备可被外部访问。

其中，DMZ 功能，可以指定一台内网设备为 DMZ 主机。到达路由器上的报文，如果没有匹配 NAT 表项，就会转发到 DMZ 主机。从而使 DMZ 主机可被外部访问。

• DMZ的介绍与设定 | 官方支持 | ASUS 中国

DMZ 功能能让一台内网设备上的所有端口，都能被公网访问。但这样做也影响了内网设备的安全性，如果没有特殊需要，不建议打开这一功能。

而 端口转发 功能，可以手动设置端口映射关系，让指定内网设备的指定端口，能够被公网访问：

• 如何在ASUS路由器设置端口转发规则？ | 官方支持 | ASUS 中国

这种方式能够精确控制哪些设备的哪些端口可被公网访问。但需要用户具有一定的网络知识，知道需要被公网访问的应用的端口号，才能正确设置。

另外批评一下任天堂，在官网的帮助文档中，直接让用户打开了所有 UDP 端口的端口转发。这样做降低了安全性，而且可能与用户的其他端口转发规则冲突。不过从另一个方面，也说明了根据实际应用，手动设置端口转发规则，对部分用户来说，确实是一件门槛较高的事情：

• ʝօɦռռʏ Ӽʍǟֆ on Twitter: "Uhhh why is @NintendoAmerica telling every Switch owner to effectively expose their consoles directly to the internet? Real excited for how fat-fingering the IP and forgetting / not being able to set UDP only can also expose anything else on folks’ home networks. https://t.co/R5tSkbatfx" / Twitter

UPnP IGD、NAT-PMP

上文中的端口转发功能，需要手动配置端口转发规则，操作起来比较麻烦。而 UPnP IGD 和 NAT-PMP 协议，则能实现自动配置端口转发规则。

UPnP IGD（互联网网关设备协议）和 NAT-PMP（NAT 端口映射协议）分别由微软和苹果提出，功能类似，都可以让应用程序告诉路由器需要打开的端口，让路由器自动设置端口转发规则。

• 互联网网关设备协议 – 维基百科，自由的百科全书
• NAT端口映射协议 – 维基百科，自由的百科全书

UPnP IGD 和 NAT-PMP 的工作，需要应用程序和路由器的配合。首先需要在路由器上打开 UPnP 或 NAT-PMP 功能：

• 如何设置无线路由器的UPNP功能？ – TP-LINK 服务支持
• Universal Plug’n’Play and NAT-PMP on OpenWrt

还需要使用支持的应用程序。目前 eMule、BitTorrent 等常见的 P2P 文件共享工具，以及 Synology DiskStation 等 NAS 设备，以及 Xbox 等游戏主机，都已经支持相关协议：

• eMule UPnP 设置
• PortForwardingGuide – Transmission
• 路由器配置 | DSM – Synology 知识中心

光猫改为桥接模式，使用路由器拨号

安装宽带时，运营商附送的光猫，一般会默认打开路由功能。这时光猫同时能做为路由器使用。

但光猫的功能和性能有限，一部分型号的光猫不支持 UPnP IGD 等协议，或者不能手动配置端口转发规则。

所以，可以考虑将光猫修改为桥接模式，通过自己的无线路由器拨号，充分利用路由器上端口转发、UPnP IGD、DMZ 等功能。

正常情况下，光猫改桥接，最简单的方式是拨打运营商的客服电话，让运营商远程下发配置。也可以登录光猫的管理页面，自行进行修改，具体需要上网搜索运营商名和光猫型号来查找教程。

向运营商申请获取公网 IP

由于 IPv4 地址资源不足，不少运营商已经不再分配公网 IP。

在部分地区，也可以尝试拨打运营商客服电话，申请分配公网 IP。

另外一部分地区的运营商，在进行 PPPoE 拨号时，用户名中加入 pub，即可获取公网 IP：

• 广东电信真方便，用户名加个 pub. 就能拿到公网 IP 了。 – V2EX

部分地区需要付费购买，例如北京移动宽带，之前提供有公网 IP 叠加包。

但是，由于 IPv4 地址资源本身已经不足，不一定能够成功申请到公网 IP。另外，拥有公网 IP，家中的路由器能直接被公网访问，如果没有配置好，可能会带来更多安全问题。所以，需要根据自己的实际需要，来决定是否申请公网 IP。

PCP

对于运行 NAT 的家庭路由器，通过 UPnP IGD 或 NAT-PMP 协议，可以方便地将端口映射到公网。

但是，由于 IPv4 地址的不足，电信运营商也开始使用 NAT，不再为用户分配公网 IP。那么是否有一种类似 UPnP IGD 或者 NAT-PMP 的协议，运行在运营商的路由器上，能直接在运营商路由器上创建端口转发规则？

PCP 就是这样一种协议：

• Port Control Protocol (PCP) – RFC6887

该协议由 NAT-PMP 发展而来，运行在运营商的路由器上。用户的应用程序可通过 PCP 协议，申请在运营商路由器上打开端口。

PCP 需要运营商的配合，选用支持的网络设备，并打开 PCP 功能，才能正常工作。根据 V2EX 网友的测试，国内已有运营商支持该协议，能通过 PCP 使 eMule 获得 High ID：

• 介绍一个可能有助于 CGN NAT 端口映射的工具 – V2EX

服务器中转

上文中介绍了一系列使内网设备可被外部访问的方式。但这些方式或者需要用户手动配置，或者路由器的支持，或者需要运营商的支持…… 如果上述方式都不可用，就要通过第三方服务器中转的方式，让内网设备供外部访问。

这种方式虽然需要第三方服务器的参与，浪费资源，但成功率最高，所以应用范围也很普遍。例如常见的游戏加速器，就可以通过第三方服务器中转的方式，为游戏主机提供更高的 NAT 类型：

• 网易UU加速盒

也有不少开源的反向代理工具，可以搭建在自己的服务器上，使内网服务可在公网访问：

• fatedier/frp
• ehang-io/nps

服务器中转需要额外的服务器，且需要消耗服务器上的流量。所以这种方式往往需要用户额外付费，例如购买游戏加速器会员，或者自行购买虚拟服务器，并在服务器上搭建反向代理应用。

而对于微信语音、视频通话等应用，默认也会使用其他 NAT 穿透技术，来节省微信服务器的流量费用，降低成本。当其他 NAT 穿透方式不可用时，则采用服务器中转的方式，保证能够正常通话。

NAT 打洞

NAT 打洞的工作过程

如果两台设备都位于 NAT 路由器之后，没有公网 IP。在没有第三方服务器的中转下，是不是就没有办法直接进行通信了？

答案并不是这样的。NAT 打洞，就可以使两台内网设备能够直接通信，不需要第三方服务器的中转、不需要对路由器进行特殊设置、也不需要运营商的配置。微信语音、腾讯会议、Skype 通信等消耗流量较大的应用，都会利用 NAT 打洞实现内网设备间的直接通信。

这项技术听起来很神奇，但是原理并不复杂：

我们以 PC 1、PC 2 两台主机的通信为例。两台主机均位于 NAT 路由器之后，各自的 IP 地址都是内网地址，无法互相通信：

在两台主机能够直接通信之前，需要一台第三方服务器：

PC 1、PC 2 首先需要给服务器发送一个报文。经过 NAT 路由器后，报文的源 IP 和源端口号被转换，同时在路由器上形成 NAT 表项：

报文到达服务器后，服务器记录下 PC 1、PC 2 两侧报文的源 IP 和源端口号，也就是 PC 1、PC 2 两侧的公网 IP 和外部端口号。然后，服务器将两台设备的公网 IP、外部端口号发送给对方。这样，PC 1、PC 2 都能相互知道对方的公网 IP 和外部端口号：

其中一部分路由器的 NAT 检查比较宽松。一旦 NAT 表项建立，只要路由器上收到的报文，目的 IP 和目的端口号能够匹配到 NAT 表项，都会转发到表项对应的内网设备。对于这样的路由器，PC 1、PC 2 互相用对方的公网 IP 与外部端口号，就能直接通信了，不再需要第三方服务器：

另一部分路由器的 NAT 检查比较严格，只有内网设备向指定的目的 IP、目的端口号发送过数据，来自这个 IP 和端口号的报文，才能转发到内网设备：

对于这样的路由器，PC 1、PC 2 两台主机需要同时向对方的公网 IP 和外部端口号发送一个报文。这样，PC 1 侧的路由器认为 PC 1 向 PC 2 发送过数据；PC 2 侧的路由器认为 PC 2 向 PC 1 发送过数据，PC 1 和 PC 2 就能相互通信了。

经历了上述步骤，NAT 打洞成功，两台设备就可以不依赖第三方路由器，直接进行通信。当然，上述过程只是一个简化的描述，不完全描述。如果想要进一步详细了解 NAT 打洞的过程，建议参考文末的 RFC 文档链接。

可以看出，NAT 打洞可以在无需路由器特殊配置、无需运营商配合的情况下，实现两个内网设备的相互通信。另外，对于多层 NAT 的网络环境（例如运营商和家庭路由器各进行一级 NAT），NAT 打洞也能正常处理。

NAT 类型与打洞成功率

在一些路由器的设置页面或文档中，我们会看到，NAT 能设置成不同的类型，例如 Full cone、Restricted cone、Port-Restricted cone、Symmetric：

• [无线路由器] 如何在华硕路由器中更改NAT类型? | 官方支持 | ASUS 中国

在 Xbox、PlayStation、Nintendo Switch 等游戏主机上，我们也能看到不同的 NAT 类型，例如 open、moderate、strict 等：

• 解决 NAT 错误和多人游戏问题 | Xbox Support
• 测试互联网连接 | PlayStation®4 用户指南
• 无法与其他在线玩家连接 – Nintendo Switch 常见问题

那么，这些 NAT 类型到底意味着什么？如何提升 NAT 类型，来获取更好的游戏体验？让我们先来了解一下基础的 NAT 类型：

完全圆锥形 NAT（Full cone NAT）：

对于完全圆锥形 NAT，内网 IP 和内网端口号，被映射为外部 IP 和外部端口号。当路由器收到来自外部的报文时，只要报文的目的 IP 和目的端口号，匹配到 NAT 表项的外部 IP 和外部端口号，都会转换为对应的内网 IP 和内网端口号，转发到内网设备。

对于外部报文，路由器并不关心报文的源 IP 和源端口号（即报文来自谁），只要收到匹配 NAT 表项的报文，都能发送到内网设备。所以，完全圆锥形 NAT 是最宽松的 NAT，打洞最方便。

受限圆锥形 NAT（Restricted cone NAT）：

与完全圆锥形 NAT 相比，受限圆锥形 NAT，在内网设备向外发送报文时，路由器除了生成 NAT 表项，还会根据报文的目的 IP，记录下内网设备正在与哪些外部设备通信。

这样，只有内网设备先发送报文给外部设备，外部设备回应的报文，才会被转发到内网设备。而其他外部设备发送过来的报文，即使匹配 NAT 表项，也无法发送到内网设备。

这样的 NAT 安全性有一定的提高，但是也提高了打洞难度。两台内网设备需要互相给对方发送一个报文，才能打洞成功。

端口受限圆锥形 NAT（Port-Restricted cone NAT）：

端口受限圆锥形 NAT 和受限圆锥形 NAT 类似，但增加了检查的严格程度：受限圆锥形 NAT，只会外部设备的 IP 地址，来检查内网设备与哪些外部设备通信过。而端口受限圆锥形 NAT，会同时根据 IP 地址和端口号来进行检查。

对称 NAT（Symmetric NAT）：

前面的三种圆锥形 NAT，会根据内网设备发出去的报文的源 IP、源端口号两个信息建立 NAT 表项，将内网 IP 和内网端口号映射到外部 IP 和外部端口号。内网设备发出去的报文，无论目的 IP 和目的端口号如何变化，不管发给哪台外部设备，都会被映射为相同的外部 IP 和外部端口号。

而对称 NAT，会同时根据内网设备出方向报文的源 IP、源端口号、目的 IP、目的端口号四个信息来建立 NAT 表项。如果报文的目的 IP、目的端口号发生了变化，映射到的外部端口号也会发生改变。

对于对称 NAT，我们再来回顾一下前文中 NAT 打洞的过程。内网设备首先和第三方服务器通信，内网 IP 和内网端口号会被映射为一个外部 IP 和外部端口号。接下来，内网设备和另一台设备通信，相同的内网 IP 和内网端口号，又会被映射为另外一个外部端口号。这样，NAT 打洞就无法成功。

所以，在对称 NAT 下，很难进行 NAT 打洞。

而 Xbox、PlayStation、Nintendo Switch 上的 NAT 类型，基本上也跟上述四种 NAT 类型对应。例如 Xbox 上的三种 NAT 类型：

• open: 开放。当前主机可被所有外部主机连接。如果主机拥有公网 IP，或通过端口转发等方式，使主机可被外部访问，就能获取到这种类型。
• moderate: 当前主机无法被外部主机直接连接。但是可以通过 NAT 打洞等方式，实现主机间的通信。一般对应上文中的三种圆锥形 NAT。
• strict: 但是 NAT 比较严格，无法打洞成功。一般对应对称 NAT。

PlayStation 的 NAT 类型也与之类似，可参考如下链接：

• 使PS4获得最佳NAT类型 更新华硕路由解决方案 – PS4/PS5综合讨论区 – A9VG电玩部落论坛

所以，对于能设置 NAT 类型的路由器（例如华硕的部分型号），将 NAT 类型设置为 Full cone NAT，能够更容易地实现 NAT 打洞，使游戏主机更容易被外部连接。

使用如下工具，可以检测当前网络的 NAT 类型：

• HMBSbige/NatTypeTester

Q&A

在这一章节，我会解答关于 NAT 的一些常见问题。如果还有其他疑问，欢迎在评论区提出，我会将相关问题与解答，更新到这一章节。

对于「对称 NAT」等更严格的 NAT，是否还可以打洞？

按照上文中的描述，「对称 NAT」是无法打洞成功的。但是，事实真的是这样吗？

实际上，运用一点点概率知识，对称 NAT 也是可以打动成功的。让我们先来了解一下「生日问题」：

生日问题是指，如果在一个房间要多少人，则两个人的生日相同的概率要大于50%? 答案是23人。 这就意味着在一个典型的标准小学班级（30人）中，存在两人生日相同的可能性更高。对于60或者更多的人，这种概率要大于99%。 — Wikipedia

假设内网设备 A 位于「圆锥形 NAT」之后，内网设备 B 位于「对称 NAT」之后。这时候 A 向 B 发送报文，B 并不知道 A 的报文经过 NAT 之后，公网端口号会被转换为什么，所以无法向 A 发送数据。

当然，在 B 不知道 A 的外部端口的情况下，也可以用不同的端口号，依次尝试向 A 发送报文，直到发送成功为止。但端口号一共有 65535 个，扫描所有端口并不现实…..

那么，如果我们运用上「生日问题」，A 随机向 B 以不同的源端口号，发送 256 个报文，形成 256 个 NAT 表项；B 同时也随机以不同的目的端口号，向 A 发送 256 个报文进行探测，打洞成功率就能达到 64%。如果随机探测 1024 个端口，打洞成功率则能达到 98%。

如果想要更详细地了解，可以参考这篇文章中 The benefits of birthdays 部分：

• How NAT traversal works · Tailscale

果壳 DATAMUSE 团队制作了一个有趣的交互页面，来解释生日问题。如果感兴趣，不妨打开如下链接尝试一下：

• 生日悖论 – DATAMUSE

利用 NAT 打洞，能实现哪些有趣的应用

前文中已经提到，语音通话、视频会议应用，以及在线游戏，都用到了 NAT 打洞。那么，利用 NAT 打洞，还能实现哪些有趣的应用？

其实，最常见的应用，就是通过 NAT 打洞，将多个设备组建一个虚拟局域网。例如在家中有 NAS，且没有公网 IP 的情况下，通过这些利用 NAT 打洞的工具，仍然可以在离开家的时候，用手机直接访问 NAS 上的文件。而且由于是直接通信，不会因为第三方服务器中转而降低传输速度。

• ZeroTier
• Tailscale

另外，UniFi Dream Machine 等路由器，也通过 NAT 打洞等技术，使用户安全、方便地远程访问路由器。

TCP 也是一种比较常用的协议，为什么很少见到基于 TCP 的 NAT 打洞？

前面提到的 NAT 打洞，一般都是基于 UDP 协议的。但是，在 Internet 上，TCP 协议也十分常见。例如我们浏览网页、下载文件常用的 HTTP 协议，就是基于 TCP 的。

那么，NAT 打洞时，为什么不常用 TCP 协议？

这主要是因为，TCP 相对 UDP 复杂得多。UDP 协议是基于报文，一个一个报文收发的。而 TCP 需要先建立连接，然后才能传输数据。

所以，应用程序可以方便地发送 UDP 报文，进行打洞。而对于 TCP，操作系统底层处理了连接建立、断开等过程。应用程序无法方便地控制单个报文的发送。

另外，部分路由器的 NAT 实现，也会对 TCP 报文的状态进行额外检查。如果发送报文不属于某个连接，就会丢弃报文。

所以，TCP 打洞理论上能实现，但实现复杂，且成功率不高。如果需要进行 TCP 打洞，建议改用 QUIC 协议。QUIC 协议虽然基于 UDP，但引入了与 TCP 类似的可靠传输、拥塞控制等机制。最新的 HTTP3 协议，就是基于 QUIC 的。

• QUIC, a multiplexed transport over UDP – The Chromium Projects

NAT 打洞必定会成功吗

在网上，我们会常常看到关于「某个工具的 NAT 打洞成功率更高，而另一些工具经常打洞失败」的讨论。那么，如何理解这里说的「成功率」?

NAT 打洞为内网设备之间的直接通信，提供了可能性。但是，不同厂商、不同设备的 NAT 实现，不是完全相同的。另外，两台内网设备之间，可能会经过多个路由器和防火墙，更增加了复杂性。

所以，NAT 打洞无法保证完全成功。例如前文中介绍的对称 NAT，就无法保证 100% 成功。

所以，一个比较好的 NAT 穿透实现，会进行多种尝试：例如先尝试 UPnP IGD 和 NAT- PMP，然后尝试不同的 NAT 打洞方案。在最终无法打洞成功时，选择服务器中转等备用方案。

NAT 打洞是否完美解决了 NAT 引入的问题？是否存在缺点？

NAT 打洞虽然能让内网设备直接通信，那么，是不是大部分设备，都不需要公网 IP，直接位于 NAT 之后就行了。

其实不是这样，比起使用公网 IP 直接通信，NAT 打洞仍存在不少缺点，例如：

• NAT 打洞仍需第三方服务器的参与
• NAT 打洞无法 100% 成功，尤其是对称 NAT，更难打洞成功
• NAT 打洞的过程，需要开发者对应用程序进行适配
• 为了节省资源，路由器上的 NAT 表项会超时删除。所以，NAT 打洞后，需要定期发送报文，维持路由器上的 NAT 表项。否则需要重新打洞
• NAT 打洞的操作本身，也增加了延迟
• NAT 打洞对 TCP 的支持不佳，一般使用 UDP。但不少运营商会对 UDP 进行限速，导致打洞后虽然设备间能直接通信，但无法以较快的速率传输

NAT 的未来

根据前面的介绍，我们看到，NAT 在缓解 IPv4 地址资源不足的问题上，做出了巨大的贡献；同时，NAT 的出现，也避免了个人设备暴露在公网，「意外地」提升了安全性。

但是，NAT 带给我们更多的，是各种各样的限制…… 目前，IPv6 正在逐步普及，等我们彻底用上了 IPv6，NAT 可能就没有了存在的意义⁵。

但是，为了保证安全性，家用路由器、PC、NAS 等设备上，一般都有防火墙功能。防火墙默认会阻止传入连接，除非用户手动配置防火墙，打开特定端口。所以，即使 NAT 被淘汰，类似 NAT 打洞的技术，在 IPv6 时代仍会得到应用。

那么，当 IPv6 普及，NAT 消失，Internet 是否会诞生新的有趣的应用？家中的每个物联网设备都有了公网 IPv6 地址，是否会有一些新的玩法？是否会带来新的安全性问题？随着国内大幅度推进 IPv6 的建设，这些问题应该很快会有答案。

参考链接、延伸阅读

关于 NAT 的具体实现，可参考如下 RFC：

• rfc1631
• rfc2663
• rfc3022
• rfc4787
• rfc5382
• rfc5508

在 NAT 环境中进行 P2P 通信，会遇到哪些问题？应该如何解决？可参考如下 RFC：

• rfc5128

已经有一系列协议，实现了完整的 NAT 打洞过程，可参考如下 RFC：

• rfc3489: STUN 协议。参考部分已有的 NAT 打洞技术，并将其标准化。
• rfc5389: 另一个 STUN 协议（与 RFC 3489 全称不同，但缩写相同）。支持 TCP 打洞。
• rfc5766: TURN 协议。可实现 NAT 打洞失败后，使用服务器中转。
• rfc5245: ICE 协议。更完整的协议，除了如何打洞，还描述了打洞成功后如何通信。

这篇文章介绍了基于 NAT 穿透的虚拟局域网工具 Tailscale 的工作原理，可参考阅读：

• How Tailscale works · Tailscale

在本文的写作过程中，还参考了如下文章。文章中有关于 NAT 的更多知识，如果对 NAT 感兴趣，可结合本文一起阅读：

• How NAT traversal works · Tailscale
• P2P通信原理与实现 – evilpan
• P2P通信标准协议(一)之STUN – evilpan
• P2P通信标准协议(二)之TURN – evilpan
• P2P通信标准协议(三)之ICE – evilpan
• NAT穿透 – 维基百科，自由的百科全书
• P2P通信原理与实现(C++) – 有价值炮灰 – 博客园
• NAT 科普与类型提升 – 晨鹤小站
• 42张图详解 NAT : 换个马甲就能上网

本文配图素材来自 Flaticon，作者包括 Eucalyp、Freepik、Icongeek26、xnimrodx、Good Ware、srip、phatplus。

题图来源：

• rectangular gray corded device on black rack photo – Free Computer Image on Unsplash

对于家庭网络的更多内容，欢迎关注我在 GitHub 上创建的 Awesome List：

• blanboom/awesome-home-networking-cn

本文首发于少数派，原文链接：https://sspai.com/post/68037

这一功能是如何工作的？是否能让网速变快？是否需要打开？本文将尝试解答这些问题。

从「网络如何连接」说起

本章节主要介绍计算机网络的基础知识。如果读者已经熟悉相关知识，可跳过这部分内容。

在介绍「智能队列」之前，先来了解一下基础的网络知识。

两台电脑间进行数据传输，存在两种方式，分别是电路交换和分组交换。

对于电路交换，两台电脑独占一条线路进行数据传输。过去的固定电话，大多使用的就是电路交换。

由于独占一条线路，两台设备之间的通信较为稳定，很难出现数据丢失、数据传输顺序错乱等情况。但一条线路只能供一组电脑使用，另外一组电脑想要通信，就不能复用原来的线路了。

对于分组交换，传输的数据被拆分为小段，每一小段叫做一个数据包（报文）。数据以报文的形式进行转发，从而实现了多组电脑复用一条线路进行通信。

电路交换虽然能保证数据传输的稳定性，但由于独占线路浪费太多资源，所以在 Internet 中，使用的是分组交换。

分组交换将数据拆分成一个一个的小片段来转发，没有独占线路。如果网络条件不好（例如同时有大量报文经过路由器，超出了路由器的处理能力），很有可能遇到数据顺序错乱、甚至数据丢失等情况。那么，这些情况应该如何避免？

• 在微信视频通话、电视直播等应用中，报文的丢失或乱序，只会造成视频图像卡顿，不会造成太严重的影响。所以这些应用会使用简单的 UDP 协议，不考虑丢包、乱序。
• 在网页浏览、文件下载等应用中，一般使用基于 TCP 的 HTTP 协议。TCP 在报文中携带序号，避免乱序；同时提供了报文的丢失重传机制，避免了丢包。所以，也可以认为 TCP 为两台电脑的应用程序建立了一个虚拟的「连接」。（最新版本的 HTTP/3 协议，使用的则是 QUIC。QUIC 虽然基于 UDP，但引入了与 TCP 类似的报文丢失重传机制）

如果想要了解更多网络基础知识，推荐阅读「入网指南」系列文章：

• 入网指南 01 | 一文读懂你身边的「网络」
• 入网指南 02 | 当你发消息的时候，发生了什么
• 入网指南 03 | 交换机在交换什么？
• 入网指南 04 | IP 地址大揭秘
• 入网指南 05 | 除了接线，还有什么影响着我们网上冲浪
• 入网指南 06 | 连上 Wi-Fi 就能上网了吗？

网络延迟：影响上网体验的重要因素

带宽和延迟，是影响上网体验的两大因素。

带宽指的是在单位时间内，网络最多能传输多少数据。

网络的带宽和水管的粗细有着很多相似之处，水管越粗，相同时间流出的水越多；同样地，网络带宽越大，相同时间能够传输的数据越多。

在日常上网过程中，大的带宽能带来这些好处：

• 上传、下载文件的速度更快
• 在线看视频时，缓冲的时间更短
• 如果家中有多个人同时上网，大的带宽能够保证每个人都能流畅上网，相互的影响更小

对于家庭宽带，我们常常听到的 10 兆、50 兆、100 兆、千兆，就是指的带宽的大小。

延迟指的是数据从网络的一端到达另一端，所需要的时间。

过大的延迟也会对上网体验带来不好的影响，例如：

• 在浏览器中输入网址敲回车后，需要等更长的时间，网页才能加载
• 视频聊天、语音通话质量变差，甚至能直接感受到声音、画面的滞后
• 玩在线游戏时，发现游戏变慢

在很多时候，延迟相比带宽更容易被人感知，对网络体验的影响更大。

是什么导致了网络延迟？

上文中介绍过，Internet 使用的是分组交换。如果大家阅读过计算机网络相关的书籍，应该对分组交换的「存储-转发」机制有一定的印象。

简单说，「存储-转发」是指网络设备将收到的报文存储在缓冲区，然后再发送。

这是由于网络设备的性能有限，转发报文有速率限制。如果设备短时间内收到大量报文，一时半会儿处理不过来，就可以先报文存起来，空闲时慢慢发送。通过「存储-转发」，能够提高网络设备的吞吐量，更充分地利用带宽。

其中，存储报文缓冲区，是一个先进先出的队列。那么，队列的长度应该如何确定？是不是队列越长，能够存储的报文越多，网络的性能就越好？大家可以先思考下这个问题。

其实在过去，内存价格比较昂贵，考虑到成本，网络设备的队列不会太大。现在，随着内存价格的下降，网络设备拥有了更大的队列。

但是，网络的带宽是有限的。实际的可用带宽，取决于数据传输路径上的最小带宽。这个最小带宽也被称做带宽上的「瓶颈」（bottleneck）。

由于瓶颈的存在，如果流量长时间以较大速率发送，大的队列并不能显著提升吞吐量。相反，大量报文滞留在队列中，会带来延迟的增大。

这种队列中缓存有大量报文，来不及发送，导致数据传输延迟增大的现象，被称做 bufferbloat（缓冲区膨胀）。

DSLReport 提供的测速服务，能够检测网络的 bufferbloat 程度。不过由于没有中国大陆服务器，测试结果不够准确。国外的读者可以尝试一下：

• DSLReports Speed Test

Flent 是一个本地的网络测试工具，也可以用于测试 bufferbloat：

• Overview — Flent: The FLExible Network Tester

家用无线路由器中的 QoS 功能

在「智能队列」出现之前，很多家用路由器已经提供了 QoS 功能。那么，传统的 QoS 如何解决网络延迟、网络拥堵？存在哪些不足之处？

在了解这个问题之前，先来熟悉一下网络中的报文，是什么样子的：

在网络中传输的报文，一般包括了链路层、网络层、传输层、应用层这四层信息。其中，网络层的源 IP 地址、目的 IP 地址、协议号，和传输层的源端口号、目的端口号，是 QoS 算法中常常会关注的五个信息。这些信息合称「五元组」。

同一个应用在同一时间段内，传输的报文中，这些信息一般是不会发生变化的。例如观看在线视频时，同一个视频的所有报文 ，一般拥有相同的五元组信息。所以，通过五元组，我们能够区分不同应用的流量。

特别地，一些常见的应用，会使用固定的端口号。例如网页浏览一般使用 80、443 端口；英雄联盟游戏，使用的是 5000-5500 端口……

所以，当我们想要提升英雄联盟游戏的体验时，在路由器上设置让 5000-5500 端口的报文优先通过即可：

• How to set up traffic prioritization rules for League of Legends on Nighthawk Pro Gaming router | Answer | NETGEAR Support

家用路由器中常见的 QoS 功能，就是通过手动设置 IP 地址、协议号、端口号等报文特征来实现的。这种方式需要用户了解一定的网络知识，且操作复杂。（虽然部分无线路由器内置了常用应用的 QoS 规则，但仍需要一定的手动设置，且无法及时适配新的、小众的应用）

当然，除了上文中介绍的内容，QoS 还有多种不同的实现方式。例如：

• 对特定应用（例如 BitTorrent）进行限速
• 按照 MAC 地址指定某台设备的优先级（例如提高 Nintendo Switch 的优先级，使游戏更加流畅）
• 通过 WMM、DSCP 等机制来决定报文优先级

这些机制各有各的特色和不足。例如对应用程序限速的方式，虽然效果明显，但无法在网络空闲时，动态利用剩余带宽来提升传输速度，也难以适应带宽频繁变化的无线网络。关于上述 QoS 机制的技术细节，本文不再详细介绍。如果感兴趣，可以搜索相关关键词，进一步了解。

智能队列：通过「全自动」的方式优化网络、降低延迟

什么是「智能队列」

目前，一部分新的无线路由器，开始有了名为「智能队列」的功能。这一功能一般指的是 fq_codel。

fq_codel 包含两种队列管理机制，分别是 Flow Queue 和 CoDel。在下文中，我将简要介绍这两种机制的作用。

Flow Queue

前文中介绍过，网络中的报文一般都有自己的五元组信息；同一应用发送的报文，在一定的时间段内，五元组信息是相同的。这些信息相同的一系列报文，被称做一条流（flow）。

Flow Queue 为每条流单独维护一个队列。例如，如果我们一边在线观看视频，一边进行语音通话，一边玩游戏，Flow Queue 就会为视频播放的流量、语音通话的流量、在线游戏的流量各维护一条队列：

正常情况下，在线观看视频需要占用较大的带宽，但对延迟不敏感，用户可以容忍几秒甚至几十秒的缓冲时间。

而语音通话和在线游戏占用带宽小，但对延迟敏感。例如语音通话时，如果一个人说了一句话，对方在几秒后才能听到，用户就能明显感知到延迟。

如果三种应用共用一个队列，队列中会充满大量视频播放应用的报文，导致语音通话、在线游戏的报文迟迟无法发送，增大了这两种应用的延迟。

Flow Queue 为视频播放、语音通话、在线游戏各维护一条队列，并公平地调度三个队列，避免视频播放的报文占用太多时间，从而让在线游戏、语音通话的报文得到及时处理。由于 Flow Queue 确保了应用程序之间的「公平」（fair），所以又被称做 Fair Queue。

CoDel

我们已经知道，适当长度的队列，能够充分利用带宽、提高吞吐量。但过长的队列，又会导致过大的延迟。也就是说，队列既不能过长、也不能过短。

CoDel 所做的，就是让队列维持在合适长度，最大限度地提升网络性能。

CoDel 通过计算报文在队列中的停留时间，来判断队列是否过长。具体做法如下：

1. 报文进入队列时，在报文上记录当前时间（也就是报文入队时间）
2. 报文出队列时，再次获取当前时间（报文出队时间）
3. 计算报文入队时间与出队时间的差值，即可得到报文在队列中停留的时间
4. 当报文在队列中的停留时间超过阈值，说明队列过长，需要缩小队列长度

当队列过长时，CoDel 会直接丢弃出队列的报文，从而减少队列中报文的数量，达到控制队列长度的效果。（这种对报文的丢弃，并不会对网络带来负面影响，具体请见后续章节）

可以看出，CoDel 根据队列中报文的停留时间，来决定是否丢弃报文。而不是「一刀切」地将队列限制在一个固定的、较小的长度。这样既能降低延迟，又保留了队列最大的优点：吸收短暂的大流量报文、提升吞吐量。

另外，我们的设备，尤其是手机等移动设备，所处的网络环境是复杂多变的。例如手机靠近或远离无线路由器，就有可能导致网络带宽的变化。CoDel 通过计算报文停留时间的方式控制队列，能够更加灵活地适应网络带宽、网络质量的变化。

fq_codel

Flow Queue 确保了不同应用程序的流量能够公平传输。CoDel 控制队列长度，实现了整体延迟的降低。fq_codel 就是将 Flow Queue 和 CoDel 结合在一起使用的机制。

其中，Flow Queue 先将不同的流划分为不同的队列，再为每一个队列使用 CoDel，控制报文的延迟。两者结合使用，共同提升网络体验。

fq_codel 具有免配置、天然适应不同的网络环境、实现简单、消耗资源少等特色，越来越多的无线路由器（以及开源的路由器操作系统），开始内置这一机制。

参考 KoolShare 上的这篇帖子，作者经过测试，发现打开 fq_codel 之后，在 BT 下载占满上行带宽时，在线游戏依旧保持较低的延迟：

• 可能是家庭路由里最好的QoS——在线游戏者的福音 – KoolShare （见 8 楼、10 楼、22 楼、25 楼的测试结果）

是否需要打开「智能队列」？

前面介绍了 fq_codel 的一系列优点。那么，fq_codel 有没有缺点？是否需要我们打开？

我的设备 CPU 性能不强，是否可以打开「智能队列」？

根据这篇帖子，ER-X 路由器在打开 fq_codel 时，最大支持 200M 左右的带宽。

• QoS (fq_codel/cake) Hardware Recommendation : HomeNetworking

ER-X 使用的是 MT7621 CPU。从这个页面可以看到，我们熟悉的小米路由器 Pro、斐讯 K2P 等，都采用了这一系列的 CPU。也就是说，如果宽带带宽小于 200M，使用这些路由器，「智能队列」对网速基本不会有太大影响。

当然，在家用路由器上，不同人有着不同的方案：从百元以下、到千元以上的无线路由器，都有不少人在使用；还有一些人使用有线路由器、软路由，甚至企业级网络设备。

不同的设备，在 CPU 性能上存在很大的差异。还有一些设备，虽然 CPU 性能较弱，但使用了专门的硬件来处理报文。对于 CPU 性能不足的设备，一旦打开了「智能队列」，CPU 就需要参与更多的运算来处理报文，影响报文转发速度。

虽说 fq_codel 是一个简单的算法，占用 CPU 资源相对较少。但考虑到家用网络设备的多样性，还是需要经过实测，才能决定是否要打开该功能。

我家的宽带速度较快（100M 以上），是否还有必要开启「智能队列」？

很多人已经用上了 200M、500M 甚至 1000M 的宽带。而大部分应用跑不满这么大的带宽，即使家里的多个人一起用宽带，也很难把带宽占满。对于这样的宽带，是否有必要开启「智能队列」呢？

大部分家庭宽带，上传和下载带宽是不对等的。例如一个 200M 的宽带，上传带宽可能只有 20M。而很多协议需要客户端和服务端的双向交互（例如 TCP，接收端要向发送端发送确认报文），如果上传速度受到限制，也会影响到下载速度。

所以对于下载带宽大，但上传带宽小的环境，使用「智能队列」也有利于提升上网体验。

但是，流量速率越快，fq_codel 处理报文消耗的 CPU 资源也就越多。如果带宽较大，CPU 可能处理不过来大速率的报文。所以，最终还是要综合考虑宽带带宽，和网络设备的 CPU 性能，来决定是否要打开「智能队列」。

「智能队列」会主动丢弃报文，会不会对网络造成负面影响？

fq_codel 控制队列长度，是通过主动丢弃报文来实现的。或许读者们会有疑问，主动丢包是否会对网络有负面影响？是否会导致传输数据的缺失？

其实，Internet 被设计成分组交换的方式，丢包是很常见的现象。对于视频通话等使用的 UDP 协议的应用，少量丢包不会有太大的影响；对于网页浏览等应用使用的 TCP 协议，其本身的重传机制，也能确保数据全部正确传输。

另外，TCP 协议还拥有拥塞控制机制，能够自动调整数据发送速率。大部分拥塞控制算法在检测到丢包时，能够自动降低发送速率。所以，fq_codel 的丢包，还可以反馈到 TCP，让 TCP 协议主动降低数据发送速率，进一步缓解 bufferbloat。

总之，fq_codel 的丢包并不会对网络带来太多负面影响。

结论

在网络设备的 CPU 性能足够的情况下，打开「智能队列」，能够在一定程度上提升上网体验。推荐有条件的用户打开该功能。

但是，如果家庭网络环境特殊，例如路由器性能差、上下行带宽都非常充足等情况，fq_codel 的作用就没有那么大了。如果不确定是否需要打开，还是建议亲自测试一下，观察该功能对上网体验的影响。

参考资料与延伸阅读

在常用的无线路由器操作系统上设置 fq_codel:

• OpenWrt/LEDE: https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
• Asuswrt-Merlin: https://github.com/RMerl/asuswrt-merlin.ng/wiki/QoS-Queue-Disciplines
• dd-wrt: https://forum.dd-wrt.com/wiki/index.php/QoS
• padavan/rt-n56u: 可参考此脚本设置 https://github.com/StarWhiz/Asus-RT-AC1200-Padavan/blob/master/fq_codel%20script%20for%20Asus%20AC1200.txt
• Ubiquiti EdgeRouter: https://help.ui.com/hc/en-us/articles/220716608-EdgeRouter-Quality-of-Service-QoS-Advanced-Queue
• Linux: https://www.b1c1l1.com/blog/2020/03/26/linux-home-router-traffic-shaping-with-fq_codel/

CAKE 是一种新的队列管理机制。它吸收了 fq_codel 的优点，并在 fq_codel 的基础上增加了更多新特性。如果自己的路由器支持 CAKE，建议直接用 CAKE 代替 fq_codel:

• Cake – Bufferbloat.net
• Piece of CAKE: A Comprehensive Queue Management Solution for Home Gateways
• Cake – Comprehensive Queue Management Made Easy + Slides – BatteMeshV8 – YouTube

如何进一步优化家庭网络、降低网络延迟：

• Introduction – StopLagging.com（一个以降低网络延迟、避免 bufferbloat 为主题的个人博客）
• How I Maximized the Speed of My Non-Gigabit Internet Connection （Speedtest by Ookla 工程师如何优化自己的家庭网络）
• INCREASE BROADBAND SPEED Tips and Guides

fq_codel 基础知识：

• RFC 8289 – Controlled Delay Active Queue Management（CoDel 的 RFC 文档）
• RFC 8290 – The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm （fq_codel 的 RFC 文档）
• Controlling Queue Delay – ACM Queue
• Cgroup – Linux的网络资源隔离 | Zorro’s Linux Book（本文是一篇关于 cgroup 的文章，但文章内也对 fq_codel 做了详细介绍）

关于 Bufferbloat 的更多介绍：

• Introduction – Bufferbloat.net

本文介绍了 Linux 网络协议栈中的「队列」。通过阅读本文，可以更清晰地了解报文在网络设备内部是如何处理的：

• Queueing in the Linux Network Stack – Dan Siemon

传统的 TCP 拥塞控制算法倾向于填满队列，可能会加剧 bufferbloat。所以除了 fq_codel，还可以通过优化 TCP 拥塞控制算法，来缓解 bufferbloat。最近几年流行的 TCP BBR，就是一种新的拥塞控制算法：

• 为什么 TCP 协议有性能问题 – 面向信仰编程
• Socket缓存究竟如何影响TCP的性能？ | Zorro’s Linux Book
• BBR: Congestion-Based Congestion Control | Queue
• Linux Kernel 4.9 中的 BBR 算法与之前的 TCP 拥塞控制相比有什么优势？
• 漫谈TCP-AIMD/BBR的公平性以及buffer bloat

本文中的图片素材来自 www.flaticon.com，作者分别是 Freepik、srip、surang、xnimrodx、Vitaly Gorbachev、photo3idea_studio。题图来自 Unsplash，作者是 Jonathan。

笔者对 fq_codel 的了解还不够深入。如果发现文章中有错误，请在评论区留言指正。

对于家庭网络的更多内容，可关注我在 GitHub 上创建的 Awesome List。欢迎提交 issue 和 pull request：

• blanboom/awesome-home-networking-cn

本文首发于少数派，原文链接：https://sspai.com/post/64870。

• blanboom/awesome-home-networking-cn

在本文中，我将对这份 Awesome List 进行一个简要的介绍，并谈一谈我的网络设备折腾经历。

在本文和接下来的几篇文章中，我将从开箱与设置、特色功能、系统探索、缺点与不足等方面，分享一下我的使用体验。不过暂不涉及性能方面的测试。

家用路由器配置转移 checklist：
- SSID、密码等基本配置
- LAN 网段
- DHCP 服务器为局域网设备分配的固定 IP
- 防火墙规则
- 端口映射规则
- 限制物联网设备、摄像头等访问 Internet
- DDNS、SSL 证书等（如果需要通过 HTTPS 访问路由器管理页面）

这个月的大部分空闲时间，主要用在使用 SwiftUI 写 App，以及阅读《Creative Selection》一书上，所以没有花太多时间用于阅读微博和 RSS 文章。

本期关键词：家庭网络、SwiftUI……