前言

在现代网络通信中，TCP 和 UDP 已经成为事实上的标准协议。绝大多数情况下，TCP 被认为是默认的传输协议，尤其是对可靠性要求较高的应用，比如文件下载和网页加载。然而，随着互联网应用的快速发展，TCP 协议在某些场景下逐渐暴露出性能问题，特别是在对低延迟和高实时性要求极高的场景（如视频聊天和在线游戏）中，TCP甚至出现整体不可用的情况。

尽管 TCP 的设计初衷是为了保证可靠传输，但其顺序传输、拥塞控制和丢包重传机制在这些场景下可能成为瓶颈。因此，越来越多的解决方案选择基于 UDP 实现应用层协议，以满足这些特定场景的需求。

为什么 TCP 会有性能问题？

传输延迟累积

TCP 以可靠性为核心，其可靠传输特性依赖以下机制：

1. 顺序传输：TCP 确保数据包按照发送顺序到达接收端。如果某一个数据包丢失，TCP 会暂停后续数据包的交付，直到丢失的数据包重传成功。
2. 丢包重传：一旦检测到数据丢失，TCP 会重发丢失的数据包，但这需要额外的时间。
3. 拥塞控制：TCP 会根据网络状况调整传输速度，以避免网络过载，但在网络波动较大的情况下，这种机制会显著降低传输速度。

现在我们以视频聊天这个场景为例，在视频聊天中，用户往往更关心当前的、最新的传输数据，而视频数据的特点是丢失了部分数据包并不影响整体数据的可读性。

使用TCP

如果使用TCP进行通讯，当出现数据包丢失，TCP 的阻塞特性会阻塞后续的数据传输，无法满足尽可能快的传输最新的数据流需求，且失去时效性的数据已经没有传输价值了，但是TCP仍然会将这些数据进行顺序的传输。

如上图所示，数据流的传输会滞后，且这个滞后延时会不断出现累计、消除，无法带来稳定的体验。

使用UDP

相比之下，基于 UDP 的协议通过放弃内置的重传和顺序控制机制，将这些逻辑交给应用层处理：

• 不阻塞后续数据传输：即使某些数据包丢失，后续的数据包仍然可以继续传输，保持实时性。
• 自定义丢包处理：应用可以根据需求决定是否重传关键数据，或者通过插值算法平滑丢失数据的影响。
• 避免拥塞控制限制：UDP 没有内置的拥塞控制，传输速度不会因为网络波动而受限。

在自定义的UDP传输协议下，数据包之间的传输是独立的，我们可以尽可能的以时效性为主去完成这个传输，忽略部分数据包的丢失。

NAT穿透

在之前的文章中，我们说过NAT（网络地址转换）是为了解决IPv4地址枯竭而引入的机制，它通过将局域网设备的私有地址映射为公网地址，实现多设备共享一个公网 IP。

然而，NAT 的存在限制了外部设备直接与局域网设备的通信，因为NAT默认只允许内部设备发起的连接通过。换言之，一台在NAT子网下的设备，通常是不能被外部主动通过TCP协议访问的。

相比之下，UDP 的无连接特性使其更容易穿透NAT：

• UDP 无需建立连接：它可以直接发送数据包，而无需像 TCP 那样进行三次握手。
• NAT 映射规则：当局域网设备通过 UDP 向外发送数据包时，NAT 会为该设备临时打开端口映射，允许外部设备的返回数据通过。
• UDP 打洞（Hole Punching）：通过中继服务器（如 STUN），局域网设备可以获知对方的公网地址，并直接发送数据实现 P2P 通信。

总结

随着互联网应用的不断演进，传统的 TCP 协议虽然在可靠性方面表现卓越，但其延迟累积、NAT 穿透难度高等问题使其在某些场景下显得力不从心。相比之下，基于 UDP 的自定义协议在低延迟、高实时性需求下展现出了巨大优势。

无论是视频聊天还是实时对战游戏，UDP 的高效性和灵活性已经成为这些场景的首选解决方案。未来，随着网络技术的发展，我们或许会看到更多基于 UDP 的创新协议，为实时通信提供更强大的支持。

开篇 - 写在2024年2月

2024新年已经过完了，现在正在回北京的飞机上闲来无事，想着利用这点时间写一个总结，对过去这两年做一个简单的回顾。

对职业发展的理解

如何理解职业？

现在各种社交媒体上，总是充斥着这样的焦虑: xxx干到35岁即失业；

我刚毕业的前2年里，潜意识里都默许了上面这些话，也跟随着这些言论一起吐槽过、焦虑过。我来自一个江西的乡村小镇，包括我父母也一直在给我贩卖这些焦虑，认为”编制”才是最终归宿，而我年纪大了之后就会失业。我也曾被这些话影响到过，有时会思考如果有一天我真的干不动的怎么办？

但现在，我对这些逐渐看明白了，那些对此深以为然的人，往往会希望事情一成不变，这样也就没有了所谓的风险。 举几个典型的例子：

1. 大部分人追捧公务员、国企岗位，就是为了”稳定”；
2. 老一辈人洗衣服、洗碗坚持手洗，每天乐此不疲并认为就应该这样，不接受洗衣机、洗碗机、拖地机；
3. 一样东西只要不坏就会一直用，比如家里年纪比我还大的”古董”；

但我的价值观却不是如此：

1. 我不喜欢重复、机械性的工作，我会想办法让他能自己运转，而我能解脱出来去做更有意义的事情；
2. 我希望能创就事业，实现具体的价值，不想躺平；

所以这个问题应该变成: “如何拒绝平庸”。而对想实现价值的人来说，这是一个一生的目标，只会恨一生太短。

对技术的理解的转变

什么是技术?

刚毕业那段时间，总是热衷于”讨论”技术，也经常会被代入到网络上关于”xx语言现在最厉害”、”xx大火”，也曾漫无目的的去看过一些东西。

技术是什么？技术只是为了解决问题罢了，曾经我们组招了一个小哥来做Golang开发，结果这小哥是抱着”我就是来写Go的”的信念，结果来的时候策划正好需要一个工具来测试游戏，就让他先支持下做个简单的页面，结果这小哥下午就离职了。 如果一个人只是把自己定位成”我就只写xxx”，那得有多狭隘呀？

而在去年，我在公司内部主导了很多技术升级的工作，其中一个重点就是: 将之前总是复制代码重复实现的业务，抽离成基础组件。以及一些开发调试工具，我希望能将大家从无意义的重复工作中解放出来，这才是技术的价值。

角色和心态的转变

角色的变化

从去年开始，我逐渐开始从一个人做事变成带领一个小团队一起做事。我愈发明白一个道理：一个人哪怕再厉害、全能也是渺小的，真正能做成大事的是一个强大的团队。

带领团队后，我意识到我的思维需要有转变，需要更多的去帮助团队里的人去成长，让有志气的人能够独当一面，把不适合团队的人剔除。

心态的变化

在当前的环境里，技术总在一个”外包”的位置上，不管是真的纯外包公司、还是公司内部的研发团队，只是把业务方的诉求实现出来。

也就是说，提出需求的人往往不具备技术背景，他思考的策略空间是不够的，这个情况在国外往往是反过来的，技术团队需要直接对产品负责，其他人员只作为辅助。如果Google的广告团队是由非技术人员负责，那就永远不会出现现在这个强大的AI广告引擎。

这是我目前会努力寻求的一个改变，我希望能带领一个技术团队直接对产品负责，所做的一切工作都是为了更好的打造产品，而不是造空中楼阁。

前言

前面我们介绍过，网络底层的通信是通过一个个小的数据包进行的。当需要传输大量数据时，数据通常会被分割成多个小包，每个小包通过网络传输。这种数据包的传输方式虽然高效，但也带来了一些挑战。网络环境本身是不稳定的，数据包的到达顺序不可预期，甚至数据包可能在传输过程中丢失或者失真，导致传输的数据出错或不完整。

为了应对这些问题，传输层协议应运而生。传输层的主要任务是在不可靠的网络环境中确保数据能够正确地从一个点传输到另一个点。TCP和UDP是传输层协议的代表，它们各自解决了不同的网络传输问题。

TCP协议

TCP的来历与发展

TCP（Transmission Control Protocol, 传输控制协议）最初由 Vint Cerf 和 Bob Kahn 于1974年提出，作为Internet协议族的一部分。TCP的设计目的是提供一种可靠的、面向连接的数据传输服务，尤其适用于需要高可靠性的应用，如电子邮件和文件传输。

TCP的初步定义在RFC 675: Specification of Internet TCP中，随着互联网的发展，TCP的规范不断被改进和完善，直到成为今天我们所熟知的协议。

其他相关文档包括：

• RFC 793: Transmission Control Protocol: 定义了TCP的核心机制，包括三次握手和四次挥手
• RFC 1122: Requirements for Internet Hosts – Communication Layers: 对TCP的实现进行了补充说明
• RFC 1323: TCP Extensions for High Performance: 为提高性能添加了窗口扩大选项和时间戳选项
• RFC 2581: TCP Congestion Control: 介绍了TCP的快速重传与快速恢复算法，提高了数据传输的性能

TCP的特性

TCP协议的核心特性包括：

1. 面向连接：在数据传输之前，必须先通过三次握手建立连接，保证双方都准备好进行数据交换。
2. 可靠传输：通过序列号、确认号、校验和等机制，确保数据包的顺序、完整性和无误。
3. 流量控制：通过滑动窗口机制控制数据的传输速率，防止接收端溢出。
4. 拥塞控制：在网络拥塞时，动态调整数据的发送速率，避免网络的过载。

什么是连接?

连接的定义在RFC文档中有过明确说明:

RFC675

   A pair of sockets form a CONNECTION which can be used to carry data
   in either direction [i.e. full duplex]. The connection is uniquely
   identified by the <local socket, foreign socket> address pair, and
   the same local socket can participate in multiple connections to
   different foreign sockets

RFC793

Connections:

    The reliability and flow control mechanisms described above require
    that TCPs initialize and maintain certain status information for
    each data stream.  The combination of this information, including
    sockets, sequence numbers, and window sizes, is called a connection.
    Each connection is uniquely specified by a pair of sockets
    identifying its two sides.

在TCP协议中，连接是由一对套接字（Socket）确立的。套接字是操作系统提供的网络接口，它允许程序在网络中进行数据的收发。本质是为一对通信的进程（客户端和服务端）提供一个稳定的通道，所有通过TCP协议传输的数据都需要通过这个连接。每个连接由五元组唯一标识：

• 本地IP地址
• 本地端口号
• 远程IP地址
• 远程端口号
• 协议类型（TCP）

通过这五个元素的组合，操作系统能够唯一识别每个连接，确保数据能够正确发送和接收。

三次握手

为什么要有三次握手?

三次握手的目的是为了初始化连接的传输参数设置，确保双方都准备好进行数据传输：

1. 通过交换序列号来确认双方都准备好接收数据。
2. 交换必要的连接参数，如窗口大小、序列号等，以保证连接的正常建立。

三次握手的过程由以下几个步骤组成：

1. 客户端发送SYN请求：客户端首先发送一个SYN包，表示请求连接，并选择一个初始序列号。
2. 服务端回应SYN-ACK：服务端收到SYN包后，回应一个SYN-ACK包，表示同意连接，并告知其初始序列号。这实际上是两个数据，只是合并在一个数据包里发送出去。
3. 客户端确认ACK：客户端收到SYN-ACK包后，发送一个ACK包，确认连接建立。

为什么需要三次而不是两次？

首先，三次握手和两次的区别就是，对SYNC需不需要进行ACK？

答案是需要：

• 避免重复连接请求：客户端和服务端可以通过序列号确认连接请求的唯一性。

  如果SYNC数据包传输延迟较高，客户端进行了重试，那服务端可能会收到2个重复的建立TCP请求(其中一个是已经过期的)，通过ACK的机制，客户端可以通过比对Seq明白哪个ACK是当前连接的。

• 双方同步连接信息：三次握手确保了客户端和服务端都确认了彼此的接收能力和状态。

四次挥手

为什么要有四次挥手?

四次挥手的目的是为了可靠地断开TCP连接，确保双方都能够完成数据的传输，且连接能够彻底关闭。四次挥手的过程如下：

1. 主动关闭方发送FIN包：当客户端或者服务端完成数据传输后，主动关闭方发送一个FIN包，表示自己不再发送数据。
2. 接收方确认FIN：接收方收到FIN包后，发送ACK包确认收到FIN包，并进入关闭等待状态。
3. 接收方发送FIN包：接收方也完成数据传输后，向主动关闭方发送一个FIN包，表示自己也不再发送数据。
4. 主动关闭方确认FIN：主动关闭方收到接收方的FIN包后，发送ACK包确认，连接正式关闭。

四次挥手确保了双方都可以在合适的时机断开连接，且数据不会丢失或被误处理。

为什么需要四次而不是三次？

因为被关闭方的ACK和FIN不能合在一起发送

1. 当收到FIN后，需要立即回复一个ACK。
2. 此后将缓冲区未发送的数据发送完毕后，再发送一个FIN包，表示剩余数据传输完毕。

UDP协议

UDP的发展过程

UDP（用户数据报协议）是TCP协议的对立面，最早由 David P. Reed 于1980年提出，并在 RFC 768 中进行定义。与TCP不同，UDP是一个无连接的协议，不提供可靠性保障。它的设计目标是低延迟和简单性，适合对速度要求高、对丢包不敏感的应用场景。

相关文档：RFC 768: User Datagram Protocol

有了TCP为什么还需要UDP?

尽管TCP提供了可靠的传输，但它也带来了较大的开销，尤其是在需要快速响应和低延迟的场景中，TCP可能显得过于笨重。UDP没有像TCP那样的连接建立过程、数据确认、流量控制等机制，提供了更为简洁的传输方式。

UDP允许应用层自行处理丢包、顺序、流量控制等问题，因此它更适合需要低延迟且对数据丢失容忍的应用。例如：

• 实时视频和音频通信（如视频会议）
• 在线游戏（如多人在线对战游戏）
• DNS查询

TCP协议在操作系统内核中得到了统一实现，而UDP则更为灵活，允许用户根据自己的需求实现具体的协议细节。这样，UDP能够提供更大的自由度和效率，但也需要开发者更多的工作来确保协议的可靠性和顺序性。

ISP对TCP、UDP的处理

数据包的特征与识别

TCP和UDP数据包在协议头部有明确的标识，运营商可以通过这些特征进行识别。例如，TCP数据包包含了源端口、目的端口、序列号等信息，而UDP则通过源端口和目的端口来标识数据包的来源和目标。

ISP(Internet Service Provider, 网络供应商)对UDP的处理

在网络负载较高时，一些ISP会选择性地丢弃UDP数据包，特别是当这些数据包的传输带宽占用较高时。因为UDP没有像TCP那样的流量控制机制，它的传输更容易受到网络拥塞的影响，因此ISP有时会采取策略来丢弃UDP数据包，以保证网络稳定性。

当前TCP和UDP的应用

TCP的应用

由于TCP的可靠性，它已经成为互联网应用的事实标准。大多数需要保证数据可靠传输的应用程序，如HTTP（Web浏览）、FTP（文件传输）、SMTP（电子邮件）等，都使用了TCP。由于TCP实现复杂且在操作系统内核中统一管理，普通用户和应用程序通常无需关心其细节。

UDP的应用

与TCP不同，UDP的灵活性使其能够在特定场景下提供优异的性能，特别是在实时应用中。UDP常常和应用层协议结合使用，例如：

• QUIC协议：由Google提出，结合了TCP和UDP的优点，用于提升HTTP/2协议的性能，减少延迟。
• 实时流媒体：如视频会议、VoIP等实时传输协议，通常使用UDP以减少延迟。

总结

本文介绍了TCP和UDP协议的基本原理、发展过程及其应用场景。

1. 我们讲解了TCP的本质是由一对相互通讯的Socket组成的连接，也讲解了建立、断开连接的交互流程和设计本质。
2. 我们讲解了UDP协议是对TCP的重要补充，基于UDP协议实现的应用层协议在很多场景下解决了TCP的性能问题。

前言

在前面的文章里，我们讲解了现代网络分层模型的发展过程，以及从宏观层面上体现的系统工程思维。 那这篇文章就让我们来看看网络数据的传输过程。我们就以常见的家庭网络环境，说明网络是如何工作的，涉及到网络中的常见设备、设备如何接入网络以及数据包的传输方式。

网络中常见设备

在家庭网络中，最常见的设备包括交换机和路由器。

• 交换机: 负责局域网中将不同设备之间的数据转发。交换机依赖MAC地址来进行数据转发，通常它会维护一张 MAC 地址表，通过比对MAC地址来决定将数据包传给哪个接口。
• 路由器: 一般作为局域网的互联网接入口，主要用于将局域网与外部网络的数据包转发。

另外，通常来说，现代家用路由器是多功能的，它们统一集成了路由器、交换器、无线AP接入点、DHCP服务器的功能。

网络的常见参数

在家庭局域网中，通常会涉及到以下几个关键的网络组件：

• 网关（Gateway）：通常是家用路由器的 IP 地址，它负责在局域网和外部网络之间转发数据包，充当出口。当数据包需要发送给一个局域网外的IP，则都需要先发送给网关，由网关决定下一跳。
• DNS 服务器（DNS Server）：负责将域名解析为 IP 地址，访问网站时使用。
• 子网掩码（Netmask）：用于确定一个设备的 IP 地址所在的子网范围，帮助设备判断其他设备是否位于同一子网内。

这些组件共同作用，使得局域网内的设备能够正常通信并与外部互联网进行交互。

设备接入网络

当一个新设备连接到家庭网络时，则首先需要获取上面提到的参数：IP 地址、网关和DNS服务器等信息。这个过程是由DHCP请求来完成的。 具体过程如下:

1. 设备发送一个DHCP Discover广播请求，用于寻找网络中可用的 DHCP 服务器。
2. 路由器（局域网中的 DHCP 服务器）收到该请求后，回复一个DHCP Offer，提供为其分配的 IP 地址和其他网络参数。
3. 设备收到 DHCP Offer 后，发送DHCP Request，表示它接受分配的 IP 地址。
4. 最后，DHCP服务器通过DHCP Acknowledgment确认该 IP 地址的分配，并提供网关和 DNS 等相关信息。

这样，设备便成功接入了网络，并拥有了唯一的 IP 地址，能够正常进行数据通信。

数据是如何传输

数据的分包

在网络中传输的数据通常需要进行分包，尤其是当数据量较大时，分包能够有效提高传输效率。这里的分包过程由传输层协议（如 TCP 或 UDP）来完成。通过分包，数据可以更加灵活地在网络中传输，适应不同的网络条件。

这里，我们先不去详细的讲TCP、UDP对数据的拆分和整合，只是先明确数据最终会被拆分成一个个小的数据包进行传输，而这里我们先关注这些数据包是如何在网络间传输的。

设置IP和MAC地址

在发送数据包时，首先要明确数据包发送参数：

1. 目标IP地址。这是数据包的最终去向，它标识数据需要到达的目标设备。
2. 直接转发的MAC地址。用于确定如何在当前子网内进行传输。 IP 地址用于标识网络层的目标，而MAC地址用于标识链路层在局域网内的传输路径。在同一局域网内，MAC地址用于确保数据包能够通过交换机正确转发到目标设备。

当设备A要向设备B发送数据时，数据包的发送过程会有所不同，具体取决于B设备是否在同一个子网内(通过子网掩码判断)：

• 同一局域网内：如果A和B在同一个子网内，那么数据包的目标MAC地址就是B的MAC地址。数据包通过交换机进行定向传输，交换机会将数据包直接转发给B。
• 不同子网：如果B在外部网络中，A会将数据包的目标IP地址设置为B的IP，但MAC地址设置为网关（通常是路由器）的MAC地址，数据包会先发给路由器，由路由器负责将数据转发到外部网络。

ARP 协议

ARP协议在局域网中起到至关重要的作用，它将IP地址解析为MAC地址，从而实现数据链路层的传输。

通常每个设备都会维护一个IP-MAC地址表（即ARP表），当设备第一次要向局域网内的某个IP发送数据包，此时会通过ARP协议来局域网内广播，请求目标IP设备的MAC地址。 得到响应回复后，则将MAC地址添加到地址表中保存起来，下次即可直接使用。

有线和无线网络

• 有线网络：在有线网络中，交换机负责将数据包定向传输到目标设备，数据只会被传输到匹配的目标端口，其他设备无法接收到该数据包。
• 无线网络：在无线网络中，数据包通过无线信道广播，所有设备都可以接收到广播的数据包，但只有目标设备会继续处理它。无线信道的竞争和冲突避免机制（如 CSMA/CA）确保了无线传输的可靠性。

NAT过程

NAT(Network Address Translation)是为了解决IPv4地址短缺问题，允许多个局域网设备共享一个公网IP地址。其工作流程可以分为以下几个步骤：

1. 请求外部访问：局域网内的设备（如设备A）向互联网中的服务器发送请求时，设备A使用私有IP地址作为源地址。该请求首先被路由器接收到。
2. 地址转换：路由器将设备A的私有IP地址转换为路由器的公网IP地址。为了跟踪多个设备的请求，路由器还会为每个转换记录一个唯一的端口号。路由器维护一个转换表，将局域网内设备的私有IP和端口号映射到公网IP和端口号。
3. 数据返回：互联网中的服务器响应设备A的请求，并将响应数据包发送回路由器的公网IP地址。路由器根据转换表中的信息，找到对应的私有IP地址和端口号。
4. 数据包转发：路由器将返回的数据包中的公网IP地址和端口号转换回设备A的私有IP地址和端口号。数据包被正确转发到设备A，完成整个通信过程。

比如在上图中，设备A则是在NAT机制下，和目标服务器完成了通讯。而在目标服务器眼里，和他交互的是74.125.68.102这个IP，他并不知道A实际上是一个局域网内的机器。

接收端

1. 目标IP地址检查: 路由器首先会查看数据包中的目标IP地址是否和自己匹配。如果数据包的目标IP地址匹配，路由器会继续处理；如果不匹配，数据包会被丢弃。
2. NAT映射表查找: 路由器检查其NAT映射表。通过匹配数据包中的目标IP地址和目标端口，查找是否有相应的映射条目。
3. 映射转换: 如果NAT映射表中存在匹配项，路由器会根据映射规则，将数据包的目标地址转换为内网设备的私有IP地址和端口。这个过程确保了数据包能够被正确转发到内网中相应的设备。
4. 转发到内网设备: 路由器将数据包转发到局域网中指定的设备。通常，路由器会根据私有IP地址和端口号，在局域网内确定目标设备，并将数据包通过交换机或其他网络设备送到目标设备的网络接口。

总结

在本文中提到的各种设备和过程都可以在五层网络模型中找到它们的位置：

• 物理层：包括网络接口、网线、无线信号等，所有物理的通信介质和硬件传输。
• 数据链路层：交换机和MAC地址的传输工作，包括ARP协议，它用于在局域网内将IP地址解析为MAC地址，以便进行链路层的数据传输。
• 网络层：路由器的功能，以及IP地址的寻址和路由的过程，NAT的IP地址转换也属于网络层的内容。

所以，总结来看：物理层+数据链路层+网络层这三层实现了将数据包从源地址传输到目标地址的功能。

前言

说起网络分层模型，大家总是会机械地去背那几个名字，物理层、数据链路层、网络层……我们的大脑不善于去记忆一些没有含义的符号，所以只是去记这几个词语没有任何意义。

所以这篇文章的目标是什么呢？是从问题的源头，来探讨网络分层模型的本质是什么，分层是为了解决什么问题的，为什么要提出这种方式来处理网络通信。

这里我们不去讨论那些复杂的协议细节，而是从网络分层的演化历史和现状，来说明现代计算机网络的系统结构。

网络的发展

TCP/IP模型的基础协议定义过程可以从以下RFC文件中找到：

• RFC 768 - User Datagram Protocol (UDP)：定义了另一种传输层协议UDP，提供无连接、不可靠的数据传输服务。
• RFC 791 - Internet Protocol (IP)：网络层的核心文档，定义了IP协议的格式、寻址和路由功能。
• RFC 793 - Transmission Control Protocol (TCP)：描述了传输层的TCP协议，包括连接管理、数据可靠传输等。
• RFC 1122 - Requirements for Internet Hosts – Communication Layers：详细描述了每一层在TCP/IP模型中的职责，成为实现TCP/IP协议栈的关键参考。

四层模型

也就是所谓的TCP/IP模型，基于实际应用的TCP/IP协议栈提出。它是互联网发展的基石，随着ARPANET项目的进行，TCP/IP协议被开发并被用于连接不同的网络设备。

四层模型包含了网络接口层、网络层、传输层和应用层，覆盖了从硬件到用户应用的全过程，是实际网络通信的骨架。

四层模型中的每一层各自承担不同的职责：

1. 网络接口层：负责物理介质和数据链路的传输，包括通过以太网、Wi-Fi等方式将数据包从设备发送出去或接收进来。典型的网络设备有网卡、集线器（Hub）、交换机等，负责信号的物理传输。
2. 网络层：负责不同网络之间的数据传输，主要涉及IP地址的寻址和路由选择，确保数据包能够到达目标设备。典型设备包括路由器，它们通过查看数据包中的目标IP地址决定如何转发。网络层主要考虑的是将单个数据包从一个IP地址传输到另一个IP地址。
3. 传输层：负责端到端的数据传输和连接管理，或UDP协议来确保数据的完整性和可靠性。传输层的主要功能是控制数据包的传输顺序、确认和错误重传。通常由操作系统中由协议栈来实现。传输层和网络层的区别在于，网络层只考虑数据包的传递，而传输层则是为了在不可靠的网络环境下构建一个完整、可靠的传输过程。
4. 应用层：直接面向用户，提供各种网络服务，例如HTTP、FTP等协议。应用层由运行在设备上的程序实现，例如Web浏览器、电子邮件客户端等。

OSI七层模型

国际标准化组织（ISO）在20世纪80年代提出，旨在创建一个通用的参考模型，使不同厂商的网络设备可以互相通信。其目标是通过对网络通信过程的精细化分层，提供标准化的协议和接口，确保各层的功能独立、模块化，以便于开发和互操作性。OSI模型希望实现全球范围内网络系统的互联，因此在理论上设计了七个层次，涵盖了从物理传输到应用程序的所有方面。

尽管OSI模型在理论上非常完善，但TCP/IP协议已经在互联网中广泛应用，成为事实上的标准，因此OSI模型未能成功推行。相比之下，TCP/IP协议栈的实现更为简单实用，符合当时互联网快速发展的需求。这种标准化滞后导致了OSI模型的推行失败。

虽然OSI七层模型在理论上非常系统和全面，但它在实践中的推行却遇到了很多问题，导致它未能成为主流标准，原因包括：

1. 复杂性过高：七层模型在实际实现中显得过于复杂，尤其是会话层和表示层的功能往往在应用层被一并实现，导致理论与实际应用脱节。
2. 标准化滞后：在OSI模型被提出时，TCP/IP协议已经在互联网上得到了广泛的应用，成为事实上的标准。因此，OSI模型即使有理论上的优势，但在时间上却未能抢占先机。
3. 实用性不强：OSI模型中的某些功能（如会话层的会话管理和表示层的数据格式化）在实际中很难独立实现，更多情况下这些功能被直接集成到应用层中，这使得模型的层次划分显得不够实用。

五层模型

是介于这两者之间的存在，通常被用于教育和基础概念的讲解。它简化了OSI模型，但比四层模型多了一些细节划分。五层模型中的层次是物理层、数据链路层、网络层、传输层和应用层，去掉了OSI模型中较为抽象的会话层和表示层，更符合人们理解网络通信的需求。

分层的本质：职责分离

分层的核心目的是职责上的拆分。分层让每一部分都只专注于解决自己的问题，提供清晰的接口和功能，从而简化了开发和维护工作。每一层只专注于和邻近层进行交互，而不需要关心其他层的具体实现。

当一个应用程序（例如浏览器）发送请求时，数据包的传输过程可以分为以下几个步骤：

1. 应用层生成数据：应用层生成数据并附加目标IP地址和目标端口信息。
2. 传输层分段并封装：传输层（如TCP）将数据分割成多个段并加上传输头部。
3. 网络层选择路径并封装：根据目标IP地址选择合适的路径，并将数据封装成数据包。
4. 网络接口层封装成帧并传输：数据包被传递给网络接口层，在该层中被封装成帧，添加MAC地址，最终通过物理层的介质（如以太网、电缆或Wi-Fi）传输出去。
5. 路由器转发数据包：在传输过程中，数据包可能会经过多个路由器，每个路由器负责查看数据包的目标IP地址，并决定将其转发到哪个下一跳。
6. 目标设备逐层解封装：目标设备接收到数据包后，逐层进行解封装，最终在应用层呈现给目标应用程序，例如Web服务器收到请求并做出响应。

职责分离体现在哪？

对于应用程序来说，它只需要生成数据包并附加目标IP地址和目标端口信息，然后交给传输层和网络层来处理。应用程序并不需要知道数据包如何被拆分、重组，也不关心中间经过多少路由设备。它只负责把数据交给传输层，传输层通过TCP/UDP进行封装，接着由网络层找到合适的路径，最终将数据传输到目标设备的对应端口上。因此，应用层只需要关注它的业务数据，传输的过程由下层协议来保证。

本质上，网络分层模型就是对网络系统的梳理和流程化，是经典的工程思维的体现。通过标准化的流程和接口，将一个极其复杂且不可控的工程问题拆分为若干个小问题，使每一部分都可以独立解决。这种分层的设计使得每一层只需要专注于自己的职责，通过标准化接口与其他层交互，减少了系统的复杂性并提高了开发的可维护性。

总结

只有真正了解网络发展的历史和分层模型想解决的问题，才能真正理解网络分层模型的意义。计算机网络是人类设计出来的一个非常精妙的系统，也是一个异常庞大的工程，里面很多结构的设计、处理是非常值得我们借鉴到日常工作里的。

前言

在上一篇文章中，我们创建了新的namespace，并在cgroup hierachy上创建对应的节点。同时利用exec将指定进程放置到了新建的namespace，替换成为了pid为1的上帝进程，由此形成了一个容器。

之前我们介绍了docker是如何使用aufs和overlay来组织镜像: Docker是如何生成/保存镜像的?。但此时我们并未在文件系统上做额外处理，所以容器中的进程仍然可以访问到完整的宿主机文件视图，这显然不是我们期望的。

所以本文就来解答这个问题: 我该如何修改容器的文件视图，让容器内的进程看起来就像独占了一整个操作系统？

核心点

容器的文件视图组织

在项目的/config/global_config.go文件中，我们可以看到miniDocker对容器文件系统路径的相关定义:

const (
    PathMnt       = "/var/lib/mdocker/overlay2/mnt"
    PathReadWrite = "/var/lib/mdocker/overlay2/rw"
    PathImage     = "/var/lib/mdocker/overlay2/image"
    PathWorkDir   = "/var/lib/mdocker/overlay2/workdir"
)

我们以创建一个busybox容器为例:

• 利用以下命令生成mnt挂载点:

  mount -t overlay overlay \ 
  > lowerdir=<PathImage>/busybox,\
  > upperdir=<PathRW>/containerName,\
  > workdir=<PathWorkDir>/containerName <PathMnt>/containerName
  

pivot-root

现在我们得到了一个”看起来像”是操作系统的目录:

/ # ls
bin dev etc home proc root sys tmp usr var

那如何让容器的根目录挂载到overlay2生成的文件视图上呢？答案就是pivot_root这个黑魔法。

我们先来看看pivot_root的man page介绍，pivot_root的command使用方法为:

pivot_root new_root put_old

当执行上面的命令后，会发生这么两件事:

1. 当前进程的new_root会被设置成/根目录。
2. 原根目录会被移动到put_old目录下。

当然，这是有限制条件的:

1. new_root和put_old必须是目录，且new_root必须是mount挂载点并且不能是当前根目录。
2. put_old必须是new_root或者其子目录。

是不是感觉有点晕？那我们换个说法，pivot这个单词表示枢轴、转动，按照上面的描述，name各个路径的关系如下:

这个时候，我们把old_root和new_root之间的路径视为一个pivot:

让pivot旋转以下，是不是就像描述的那样，new_root被旋转到了根目录的位置上。这样容器的overlay2挂载点就成为了容器namespace里的root dir。

但是pivot_root并不会改动当前调用进程的workdir，所以我们需要进行手动修改: chdir /

构建新的文件系统

在利用pivot_root修改了根目录的挂载点后，剩余的事情就简单很多了:

• 卸载old_root这个挂载点，使用detach的方式移除原文件系统的挂载。由于当前系统必然依赖原文件系统，所以使用detach懒卸载的方式移除调原文件系统。
• 重新挂载/proc和/dev等系统级目录。其中/dev使用tmpfs，这是一个基于内存的文件系统。

代码实现讲解

总体流程

图3: mdocker文件系统创建流程

创建overlay2文件系统

overlay2文件系统的创建在mdocker run进程中执行:

• 根据imageName和用户volume参数，生成overlay2文件系统mnt point。
• 创建mdocker init进行，并将其工作目录设置为刚才创建的overlay2文件系统mnt point。

调整容器(namespace)的mount结构

本节的主体逻辑在/container/container_init/mount_init.go中，这个逻辑在mdocker init命令的进程中完成。

逻辑调用链如下:

// /cmd/init_cmd.go
func initCmdAction(ctx *cli.Context) error {
	return container_init.ContainerProcessInit()
}

// /container/container_init/container_process.go
func ContainerProcessInit() error {
	// ...

	// 初始化容器mount
	if err := mountInit(); err != nil {
		return fmt.Errorf("mount init failed: %v", err)
	}

	// ...

	return nil
}

// /container/container_init/mount_init.go
func mountInit() error {
	// 改变当前Namespace的Mount传播模式
	err := syscall.Mount("", "/", "", uintptr(config.MountFlagsPrivate), "")
	if err != nil {
		return err
	}

	// ...

	// 调用pivot切换rootfs
	err = pivotRoot(pwd)
	if err != nil {
		return err
	}

	// ...

	return nil
}

值得注意的是，在调整容器的mount结构前，需要先将namespace下的mount传播模式改为private，否则这些操作会被传播到外部。

结束语

本讲我们降到如何为容器生成overlay2文件系统，并且其作为容器的文件根目录。这样一来，容器就脱离了宿主机的文件系统，在自己看来就是独占了一个完整的存储设备。

前言

最近组装了一个Linux服务器放在家里，因为家里没有公网ip所以还调研了一些内网穿透方案。这篇文章给大家分享一下我搭建家用服务器的过程。

为什么我要搭一个home-server?

主要原因有这么几个:

1. 云服务器性价比低，就阿里云来说一个16G4核的机器一个月动辄几百，而我个人用的云服务器大部分情况下都是空负载。
2. 最近PC换成了M1的mbp，折腾很多东西都需要x86机构的机器。
3. 想自己搭建nas服务，存储一些个人数据。

硬件采购

在选配件的时候得想清楚到底想要一台怎样的机器。对我来说，主要考虑的点有:

1. 机箱体积要小，因为我希望摆到衣柜顶上然后我家猫就霍霍不到了。
2. All-In-One，所以性能要稍微好一些。
3. 运行时安静一些，所以选择了水冷来压这颗i5 12600K。
4. 我家目前带宽只有千兆，所以我没有单独买网卡，直接用了主板上的千兆网卡。

操作系统安装

系统选择

由于采用了12代的cpu，所以需要选择Linux内核版本较高的发行版。 我选择的是Ubuntu 22.04 LTS，内核版本为5.15.0。镜像从官网下载即可ubuntu下载

这个版本我目前使用上没有遇到什么问题，12代u能在这个版本上正常工作。

mac下启动盘制作

mac系统下引导u盘制作可参考以下过程:

# 调整格式为img
hdiutil convert -format UDRW ubuntu-22.04-desktop-amd64.iso -o ubuntu.iso
# 找到u盘dev
diskutil list # 找到external的挂载硬件
# 取消挂载
sudo diskutil umountDisk /dev/disk4
# 格式化u盘
sudo diskutil eraseDisk ExFAT ud /dev/disk4
# 将系统镜像写入u盘
sudo dd if=./ubuntu.iso of=/dev/disk4 bs=1m

服务管理方案

服务搭建

所有服务都是用Docker运行的，目前我用到的有:

1. gitlab -> 个人代码仓库
2. codimd -> 笔记服务，codimd的markdown编辑器十分强大，用过的都说好
3. nextcloud -> 私有Drive服务
4. 博客nginx服务

硬盘管理

服务器上安装的硬盘有:

• 固态512G+2T
• 机械硬盘4T x2

使用划分

1. 512G为系统盘，挂载到”/”目录下。
2. 机械硬盘划分为lvm物理设备，所有的硬盘都由一个vg(volume group)管理。通过划分lv(logic volume)来划分硬盘。已划分的lv可以扩容。

内网穿透

由于没有公网ip，所以外部是无法直接访问的。我的方案是用一台云服务器运行frp转发流量，在外面可以通过云服务器的公网ip访问家用服务器。

具体搭建可参照文档gofrp

重要数据备份

对于一些比较重要的数据，比如codimd中我记录的笔记，如果某一天家里进贼了把我的硬盘都顺走了那我可要哭死了。 所以服务器上创建cron job每天定时将数据同步到云服务器上，以及不定期的备份到移动硬盘里备份。说白了，就是不要把鸡蛋放在一个篮子里。

结束语

以上就是我的home-server方案，其实这个方案比较适合的还是家里有公网ip的人。廉价的云服务器带宽并不能满足一些大文件的传输，仅仅只能满足基本的web访问以及git代码同步。

对于那些长期需要有一台服务器工作，但并不是长时间高负载的人来说，在家里搭建一个服务器可以说一个不错的选择。如果不是用于AI模型训练等，电费几乎可以忽略不计，长时间下来成本上肯定会比租云服务器要划算。

前言

之前的几篇文章对docker依赖的Linux底层技术进行了剖析讲解, 我们现在简单回顾一下:

• 容器实际上是通过Linux的Namespace机制隔离起来的一个”沙箱”， 沙箱中运行着一组进程。
• 容器通过cgroup对容器进行分组和使用资源限制。
• 容器通过aufs组织文件系统，将不变的镜像作为只读层，在其之上是容器的读写层。
• 容器利用虚拟网络设备和iptables进行网络通讯，典型的网络模型为bridge网络。

那从这篇开始，我们就根据这些特性实现一个mini版的docker。

代码已经开源在github: miniDocker

准备工作

创建容器涉及的代码文件

.
├── boot
│   └── init.go                   // 环境初始化
├── cmd
│   ├── init_cmd.go               // mdocker init 逻辑入口
│   └── run_cmd.go                // mdocker run 逻辑入口
├── config
│   └── global_config.go          // 全局配置
├── container
│   ├── cgroups
│   │   ├── cgroup_manager.go     // cgroup管理
│   │   └── subsystems            // subsystem具体设置处理逻辑
│   └── container_init
│      └── container_process.go   // 创建容器的init进程
├── entry.go                      // 程序入口文件
└── utils
    └── logger_utils.go           // print log方法

创建容器

如何创建一个容器?

我们先来看一个命令:

mdocker run -ti busybox sh

当你敲下这行命令，一个以busybox为镜像的容器就启动了，在容器中运行着一个sh进程。

现在让我们来思考一个问题，之前我们在讲解namespace时分别用了unshare和go程序调用shell命令来启动新进程同时创建namespace，那我们在mdocker中如何来做这件事的呢？

如上图所示，mdocker run启动容器的流程为:

1. 创建一个新的进程mdocker init，这个命令只用于创建容器时使用且为非用户指令。创建进程时，会新建一个pipe并将一端设置到init进程上，这个pipe用于传递用户命令。
2. mdocker run进程在创建init进程后，还需要在外部执行一些环境设置逻辑，处理完成后将user command通过pipe发送给init进程。
3. init进程读取到用户命令后，先执行容器环境设置，如文件系统等。之后调用exec执行用户命令。

// run命令主逻辑
func run(ctx *cli.Context) error {
	// 创建 mdocker init进程
	initCmd, initPipe, err := container_init.NewContainerProcess()
	if err != nil {
		return err
	}
	if err = initCmd.Start(); err != nil {
		return err
	}

	// 将用户命令指定命令通过pipe传递给init进程
	err = sendInitCommandParams(cmdArr, initPipe)
	if err != nil {
		return err
	}

	// 当设置了ti参数时, 等待init进程退出
	if ctx.Bool(runCmdFlagTty) {
		_ = initCmd.Wait()
	}

	return nil
}

容器启动涉及到2个进程，run进程和init进程。run进程是用户直接创建的进程，由于是用户直接创建的，所以run进程是运行在container外的。 而container是在创建init进程时，指定clone_flag创建namespace后形成的。 这样设置的目的是:

• run进程和init进程处于容器内外，可以分别负责为容器设置环境。如run进程负责记录一些容器信息、设置cgroup、初始化网络等。
• 实现起来比较简单。

exec替换init进程

容器的最终目的是要运行用户目标程序，所以init进程还有一个任务就是要负责启动目标程序。最直接的办法当然是直接创建一个新进程。 但init进程在container的namespace中是pid为1的进程，当init进程退出时namespace会被操作系统自动销毁，并且在namespace下的所有进程都会收到signal退出运行。

这里就要使用到linux的一个系统调用-exec。exec会用目标程序替换init进程，这个过程中保持pid不变，只是原init进程的上下文和数据栈等被替换为目标程序。

所以我们在init进程处理完容器初始化后，用exec来启动目标进程，这样就能让目标程序在容器中的进程id为1。

// ContainerProcessInit 容器init进程初始化
func ContainerProcessInit() error {
	// call exec to replace current process, cmdArray: exec file path(only used for display), params...
	if err = syscall.Exec(cmdPath, cmdArray[0:], os.Environ()); err != nil {
		utils.LoggerUtil.Fatalf("mount fail: %s", err.Error())
	}

	return nil
}

在linux环境下，也可以用exec命令来使用这个系统调用:

$ echo $$
24871
$ exec /bin/bash
$ echo $$ # 进程id没有变化
24871

cgroup hierarchy节点创建

我们需要为container创建一个cgroup节点，然后将init进程分配到对应的节点中。 在介绍cgroup hierarchy时，我们提到linux默认在/sys/fs/cgroup下创建了默认的cgroup hierarchy tree并将subsystem与之绑定。

对于一个cgroup，我们按照以下结构去创建container节点:

.
├── ...
├── mdocker
    ├── <container_id 1>
    └── <container_id 2>

在cgroup根目录下创建mdocker节点，作为所有容器节点的根节点。在mdocker下，则是对应每个container对应的cgroup node。

cgroup的处理逻辑通过cgroupManager实现，具体操作则通过路径创建/删除、文件写入实现。

结束语

本文讲解了mdocker创建容器的流程，解析了关键的逻辑点。但是具体的代码实现还是要大家自己去结合注释去阅读、调试。本系列文章也不会一行行代码地去解释，而是讲解实现上的关键点，欢迎大家去阅读github仓库中的代码。

前言

在之前的文章中，我们介绍了Docker容器隔离机制namespace，资源管理工具CGroup以及Docker使用的文件系统unionFS。我们知道了Container其实就是被Linux内核用”沙箱”隔离起来的一组进程。

但是光靠这些还不够，linux新创建的network namespace初始状态下是不带任何网络功能的，这篇文章就会为大家解析容器是如何实现与外界的网络交互的。

虚拟网络设备

Linux 网络数据流向

计算机与外界网络通讯往往要依赖网卡，网卡和物理网络线路相连，将电信号/光信号转化为数字信号。然后内存对信号进行解析，交由上层的协议栈，最终交付给用户层。

而Linux内核在将网络包交付给协议栈之前，有一个网络设备层层。其中的网络设备可以是真实的(比如默认网卡eth0)或者虚拟的，对内核来说，他们之间没有区别。

这里我们不去讨论具体虚拟网络设备是如何实现的，大家只需要建立一个概念，就是我们可以在内核中添加虚拟网络设备来创建一个内核中的”虚拟网络”。就像局域网一样大家都可以有自己不同的ip地址、mac地址。

而发送数据包的流程和接受类似，希望能更深入了解的可以阅读附录中的文章。

network namespace的协议栈

对于一个network netspace来说，他拥有自己独立的协议栈，以及独立的网络设备挂载表。 接下来，我们会介绍如何使用veth和bridge设备让子network namespace可以和其他子空间或外部的网络进行交互。

veth

使用veth连接netns

veth(virtual ethernet)设备具有以下特点:

• 成对出现
• 一端连接协议栈，另一端peer之间对接

一对veth可以连接不同的协议栈，即当veth挂载到不同的network namespace或者container时，就变成了这样:

如何使用veth

首先利用ip命令创建两个netns:

$ ip netns add ns1
$ ip netns add ns2

创建一对veth:

$ ip link add veth1 type veth peer name veth2

启动这两个veth，分配ip并分别设置到新创建的两个netns中:

$ ip link set dev veth1 up
$ ip link set veth1 netns ns1
$ ip netns exec ns1 ifconfig veth1 192.168.1.1/24 up

$ ip link set dev veth2 up
$ ip link set veth2 netns ns2
$ ip netns exec ns2 ifconfig veth2 192.168.1.2/24 up

设置完成后，我们就可以在netns中测试网络可达:

$ ip netns exec ns2 ping -c 1 192.168.1.1 -I veth2
PING 192.168.1.1 (192.168.1.1) from 192.168.1.2 veth2: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.057 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms

我们在ns2中的veth2上进行抓包:

$ ip netns exec ns2 tcpdump -nn -i veth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth2, link-type EN10MB (Ethernet), capture size 262144 bytes

11:09:11.150688 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 12550, seq 1, length 64
11:09:11.150771 IP 192.168.1.2 > 192.168.1.1: ICMP echo reply, id 12550, seq 1, length 64
11:09:12.679528 IP6 fe80::80de:ccff:fe40:dfe4 > ff02::2: ICMP6, router solicitation, length 16

ns1发出的ICMP包转发到了veth2上，至此ns1和ns2之间建立了网络通道。

bridge

在上面的例子中，虽然ns1和ns2通过一对veth连接了起来，但是这时只做到了2个namespace之间的访问。如果我们有多个namespace，那所有需要访问的namespace之间都需要一对veth，很明显这不是一种聪明的做法。

bridge介绍

bridge作为一个虚拟网络设备，也有自己的ip地址、mac地址。而和普通的网络设备不同，bridge的数据出口有多端，会根据mac地址进行转发，原理和交换机类似。

我们可以对上面的veth进行些许改造，在netns之外创建一个bridge，而netns则通过veth对接入到bridge之上:

使用bridge连接veth-pair

使用brctl创建一个bridge设备并分配ip:

$ brctl addbr br0
$ ip link set dev br0 up
$ ifconfig br0 192.168.1.11/24 up

创建veth-pair，将ns1通过veth-pair连接到br0上:

$ ip link add veth1 type veth peer name br-veth1 # 创建veth-pair
$ brctl addif br0 br-veth1 # 将br-veth1端连接到br0上
$ ip link set dev br-veth1 up  # 启动br-veth1
$ ip link set veth1 netns ns1  # 将veth1设置到ns1中
$ ip netns exec ns1 ip link set dev veth1 up  # 启动veth1
$ ip netns exec ns1 ifconfig veth1 192.168.1.1/24 up  # 给veth1分配ip
$ ip netns exec ns1 ip route add default via 192.168.1.11  # 设置ns1默认路由

对ns2做相同的处理。

设置完成后，我们就可以测试ns1和ns2之间网络可达:

$ ip netns exec ns1 ping 192.168.1.2 -c 1
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.134 ms

--- 192.168.1.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.134/0.134/0.134/0.000 ms

在br0进行抓包:

$ tcpdump -nn -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes

12:38:50.845461 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 13124, seq 1, length 64
12:38:50.845549 IP 192.168.1.2 > 192.168.1.1: ICMP echo reply, id 13124, seq 1, length 64

在ns2中抓包:

$ ip netns exec ns2 tcpdump -nn -i veth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth2, link-type EN10MB (Ethernet), capture size 262144 bytes

12:39:41.973639 IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 13128, seq 1, length 64
12:39:41.973680 IP 192.168.1.2 > 192.168.1.1: ICMP echo reply, id 13128, seq 1, length 64

可以看到实际上包是由br0转到ns中的veth2的。

再尝试ping一个外网的ip，不过在这之前我们需要先修改下iptables的规则，否则收到的私有地址包默认会被丢弃:

$ iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
$ iptables -t nat -D POSTROUTING -s 192.168.1.0/24 -j MASQUERADE # 还原

然后我们尝试ping一下baidu的ip:

$ ip netns exec ns1 ping 220.181.38.251 -c 1
PING 220.181.38.251 (220.181.38.251) 56(84) bytes of data.
64 bytes from 220.181.38.251: icmp_seq=1 ttl=52 time=5.23 ms

--- 220.181.38.251 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

成功ping通，现在nets内、外网的通讯都建立了。

清理实验环境

$ ip netns delete ns1 ns2 # 删除ns1和ns2后，创建的veth-pair会自动删除
$ ifconfig br0 down # 停止br0
$ brctl delbr br0 # 删除br0

结束语

本文解析了如何利用虚拟网络设备让容器具有网络交互的能力，结合之前的文档，我们的docker实现原理基础就告一段落了。接下来会从0开始一步一步的实现容器，逐步为它加上隔离、挂载、网络通讯等功能。

敬请期待吧~

reference

1. Monitoring and Tuning the Linux Networking Stack: Receiving Data
2. Linux网络虚拟化
3. Linux Switching – Interconnecting Namespaces

前言

我们知道，Docker容器中的进程实际上就是跑在Linux Namespace中，与外部全局Namespace隔离开来（Docker容器是如何隔离的?)。但是我们在Docker容器中看见的文件视图是如何来的呢? 容器镜像是如何供容器使用的？本文将围绕Docker镜像的底层存储原理来剖析容器和镜像是如何运作的。

Union File System

UnionFS(Union File System), 是一种把其他文件系统联合到一个挂载点，提供统一视图的文件系统服务。它使用read-only或read-write的branch把不同文件系统的文件整合，根据层级透明的覆盖低层文件来提供一个统一的文件视图。

UnionFS遵循了写时复制(copy-on-write)原则，即若文件内容没有任何修改，使用对他的使用都可以指向一个唯一的文件实体。当修改操作发生时，先复制一个新文件，之后的修改和读取操作都将基于新文件之上进行。 COW避免了无意义的文件复制，因为绝大多数文件在使用中都不会发生变化，那我们只需要对那少部分发生修改的文件进行复制就行了。

Docker使用的存储驱动

早期Docker是基于Centos开发的，所以Docker最初使用了Centos上默认集成的aufs作为存储引擎。

aufs(Advanced Multi-Layered Union Filesystem)，是Docker选用的第一种存储驱动，具有快启动，内存、存储友好的优点。但是aufs一直没有合并到Linux内核主线中(据说由于aufs代码的维护性较差)，所以有可能有些Linux发行版内核中默认并不支持该文件系统。

目前为止, Docker支持的存储驱动如下:

• aufs
• overlay/overlay2
• btrfs
• device mapper
• zfs
• vfs

本文着重解析aufs和overlay2在Docker存储中的使用。

aufs

aufs挂载和结构说明

aufs可用以下命令进行挂载:

mount -t aufs -o br={branch-0-path}={rw/ro}:...:{branch-1-path}={rw/ro} none {mount-path}

• aufs的branch分为read-only和read-write，可以在挂载时在options中指定，若都不指定，则默认第一个branch为read-write，其他的branch为read-only。
• branch的顺序按照参数顺序从左到右排列，第一个branch在最上层，最后一个在最下层。
• aufs不需要dev设备，所以设备填none即可。

如图所示，对于重名文件，上层文件在统一挂载点上会覆盖下层，但是并不会影响到下层branch真实的文件内容。

修改aufs挂载点上的文件

对于只读挂载

若在挂载时制定所有分支都为read-only，那么将不被允许在挂载点上修改文件。

对于读写挂载

若branch中存在read-write，那所有修改文件的操作都会被写入可写的branch路径。若存在多个可写branch，写入的操作会遵循相应的策略，具体可查看aufs文档。这里我们按照Docker的使用方式，只考虑单个可写branch。

创建我们的工作目录:

root@master:aufs $ tree -L 2
.
├── container-layer
│   ├── container-layer.txt
├── img-layer1
│   └── img-layer1.txt
├── img-layer2
│   ├── img-layer1-fake.txt
│   └── img-layer2.txt
├── img-layer3
│   └── img-layer3.txt
├── img-layer4
│   └── img-layer4.txt
└── mnt-aufs

每个txt文件内容从上至下如下:

container-layer.txt -> I'm container-layer
img-layer1.txt -> I am layer1
img-layer1-fake.txt -> i'm fake img-layer1
img-layer2.txt -> I am layer2
img-layer3.txt -> I am layer3
img-layer4.txt -> I am layer4

ok，现在我们将container-layer作为读写层，其他作为只读层挂载到mnt-aufs路径:

root@master:aufs $ mount -t aufs -o br=./container-layer:./img-layer1:./img-layer2:./img-layer3:img-layer4 none ./mnt-aufs
root@master:aufs $ ls mnt-aufs/
container-layer.txt  img-layer1-fake.txt  img-layer1.txt  img-layer2.txt  img-layer3.txt  img-layer4.txt

挂载完成后，所有branch的文件都出现在了mnt-aufs路径下。

在mnt-aufs下修改文件

我们可以在mnt-aufs进行文件修改操作，不同的操作会对应不同的变化:

• 对于container-layer下文件，所有变动都会直接在对应branch的原始路径下进行。即修改、删除container-layer.txt都在直接反应在container-layer路径下。
• 对于只读层的文件，修改时会在可写层复制一个文件，之后所有基于该文件的修改都会发生在新复制的文件上，这就是COW；删除文件会在可写上创建一个.wh文件表示该文件已删除。
• 若绕过挂载点直接去修改原始路径下的文件，不会遵循上述aufs的规则，但是修改的内容仍然会同步到挂载点下。

Docker是如何使用aufs的?

本文相关的Docker测试建议新创建Linux虚拟裸机来进行接下来的实验

修改Docker存储引擎为aufs

目前Docker默认的存储引擎是overlay2，具体信息可以通过Docker info命令查看:

root@master:aufs $ docker info | grep "Storage Driver"
 Storage Driver: aufs

可以重启docker daemon进程重新制定存储引擎:

root@master:~ $ systemctl stop docker
root@master:~ $ dockerd --storage-driver=overlay2 &

Docker Image的aufs存储

Docker的aufs存储内容默认都在/var/lib/docker/aufs路径下，结构如下:

├── diff
├── layers
└── mnt

• diff，存储着Image Layer的内容
• layers，存储着layer堆叠信息metadata
• mnt， 镜像或者容器的挂载点，也就是容器最终看到的文件系统的样子

拉取一个镜像

我们在裸机上新安装的Docker没有任何镜像，所以初始状态下的aufs是空的。现在我们拉去一个ubuntu:15.04镜像.

root@master:aufs $ tree -L 2
.
├── diff
│   ├── 0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
│   ├── 2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
│   ├── a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306
│   └── b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164
├── layers
│   ├── 0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
│   ├── 2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
│   ├── a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306
│   └── b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164
└── mnt
    ├── 0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
    ├── 2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
    ├── aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da
    └── b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164

## 镜像的堆叠顺序
root@master:aufs $ cat layers/b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164
0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306

root@master:aufs $ cat layers/0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306

root@master:aufs $ cat layers/2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306

root@master:aufs $ cat layers/a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306

可以看到，我们拉取的镜像一共有4个layer，layers中记录的堆叠信息表明了layer的顺序。

在镜像上作修改

我们创建一个Dockerfile，对镜像进行一些修改

root@master:docker $ cat Dockerfile
FROM ubuntu:15.04
RUN echo "Hello world" > /tmp/newfile
root@master:aufs $ docker build -t changed-ubuntu .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM ubuntu:15.04
 ---> d1b55fd07600
Step 2/2 : RUN echo "Hello world" > /tmp/newfile
 ---> Running in f88047e60424
Removing intermediate container f88047e60424
 ---> a8c4a7335b4b
Successfully built a8c4a7335b4b
Successfully tagged changed-ubuntu:latest

查看镜像使用了哪些image layer:

root@master:aufs $ docker history changed-ubuntu
IMAGE          CREATED         CREATED BY                                      SIZE      COMMENT
a8c4a7335b4b   2 minutes ago   /bin/sh -c echo "Hello world" > /tmp/newfile    12B
d1b55fd07600   6 years ago     /bin/sh -c #(nop) CMD ["/bin/bash"]             0B
<missing>      6 years ago     /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$…   1.88kB
<missing>      6 years ago     /bin/sh -c echo '#!/bin/sh' > /usr/sbin/poli…   701B
<missing>      6 years ago     /bin/sh -c #(nop) ADD file:3f4708cf445dc1b53…   131MB

可以清楚看到每一层是由什么命令添加的，我们在镜像的最上层新加了一层，大小只有12B。

root@master:aufs $ tree -L 2
.
├── diff
    ...
│   └── aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da
├── layers
    ...
│   └── aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da
└── mnt
    ...
    └── aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da

root@master:aufs $ cat layers/aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da
b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164
0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c
2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57
a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306

查看aufs下，发现多了一个layer，并且这个layer恰好加载了之前4个layer之上。查看该层diff的内容，就只有一个文件，就是我们通过Dockerfile添加的那个文件。

root@master:aufs $ cat diff/aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da/tmp/newfile
Hello world
root@master:aufs $ ls
diff  layers  mnt
root@master:aufs $ tree -L 2 diff/aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da/
diff/aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da/
└── tmp
    └── newfile

1 directory, 1 file
root@master:aufs $

Container看见的视图

我们将容器启动:

root@master:aufs $ tree -L 2
.
├── diff
    ...
│   ├── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d
│   └── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d-init
├── layers
    ...
│   ├── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d
│   └── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d-init
└── mnt
    ...
    ├── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d
    └── 3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d-init

对于每一个容器，启动后会发生这么几件事:

• 先创建一个read-only的init layer，用来存储与这个容器环境相关的内容。
• 创建一个和init layer同名的read-write layer，用来存储容器运行时所有的文件修改操作。这个可读写层在容器被删除(docker rm)时候删除，停止容器不会被删除。
• 容器layer堆叠的顺序为: read-write layer => read-only init layer => Image layers

容器启动后，实际上就是在镜像的上方添加了read-only和read-write两个layer，我们可以清楚的查看到aufs的堆叠信息:

root@master:aufs $  cat /proc/mounts| grep aufs
none /var/lib/docker/aufs/mnt/3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d aufs rw,relatime,si=b35884dae88adc30,dio,dirperm1 0 0

root@master:aufs $ cat /sys/fs/aufs/si_b35884dae88adc30/*
/var/lib/docker/aufs/diff/3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d=rw
/var/lib/docker/aufs/diff/3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d-init=ro+wh
/var/lib/docker/aufs/diff/aaad9c0d2a6f3b3fa8485eb608101899c5d759b86899f6f572b2681f97be80da=ro+wh
/var/lib/docker/aufs/diff/b9580e61c5eb81490154112e8e5ad09490972022b7aad0fdf87a613d46758164=ro+wh
/var/lib/docker/aufs/diff/0c234f9c4a5a8d874004763367fd820ef79b355a8c112be916dfa193f5473d2c=ro+wh
/var/lib/docker/aufs/diff/2d382525b7c8a09419c1d8462ca0afad386d2fefd3276761c7d0d9519f461d57=ro+wh
/var/lib/docker/aufs/diff/a2aa1839bab06ca5c7f9cf43434b396d44725d2694bb2cc4fc1f39fe35096306=ro+wh

只有最上层是可读写的，其他全部都是只读层。而容器最终看见的文件系统，就是aufs/mnt目录下跟最上层layer同名的挂载点:

root@master:aufs $ ls mnt/3a019a3b1cc2781f20555822fe4862361ccc270cfe2d022c218821d6a0179f5d/
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

至此，aufs在docker中的使用就讲解完毕了。接下来我们讲一下docker使用的另一种存储引擎overlay2，相信在我们详细解析了aufs的使用后，大家对overlay2的理解和掌握会手到擒来。

overlay2

overlay/overlay2是一种使用上和aufs非常相似的UnionFS，于Linux 3.18中被纳入到内核主线中。和aufs相比，overlay效率更快、使用简单。

overlay只能在两层的结构上工作，所以为了实现多层镜像，Docker在lower层添加了各层的硬链接，并且由于每个layer都会新建一些目录，会比较消耗系统的inode number。overlay2克服了这个问题，原生支持了多层结构(最多128层)，自Docker 17.04后，默认使用overlay2作为存储引擎。

overlay2结构说明

• lowerdir: 底层只读的branch，branch顺序越靠前则层级越高，高层会覆盖底层的同名文件，可以设置多个。
• upperdir: 读写层，在修改时会遵循COW(copy-on-write)原则，对于底层文件复制后修改，修改upperdir则直接修改目标路径文件，层级顺序同上。需要注意的是upperdir只能设置一个目录。
• workdir: 起过渡作用，写入upper的内容会先写入到workdir，然后再移动到upper层。需要注意的是workdir必须制定一个空的路径。
• mergedir: 统一挂载点，对外提供统一的文件视图。

用overlay2进行挂载

我们利用刚才那个文件目录，将container-layer作为upperdir，其他作为lowerdir进行挂载:

mount -t overlay overlay -o lowerdir=./img-layer1:./img-layer2:./img-layer3:./img-layer4,upperdir=container-layer,workdir=./workdir ./mnt

和aufs类似，修改mnt中的文件时有以下几种情况:

• 修改lowerdir中的文件，遵循COW原则，在upperdir中复制一个新文件然后执行修改操作。删除lowerdir中的文件会在upperdir中生成一个特殊的字符设备文件，标记该文件已被删除。
• 修改upperdir中的文件会直接在源路径下修改。

直接修改源路径

在刚才讲解aufs时，我们曾尝试直接去修改aufs源路径中的文件，而虽然绕过了aufs但是修改仍然同步到了联合挂载点上。这一点在overlay2上是不同的，绕过overlay2去直接修改源路径大多数情况下是不会同步到挂载点的。

root@master:overlay2 $ ls -li mnt | grep fake
1311616 -rw-r--r-- 1 root root 35 Apr 19 00:34 img-layer1-fake.txt
root@master:overlay2 $ ls -li img-layer2 | grep fake
1311616 -rw-r--r-- 1 root root 35 Apr 19 00:34 img-layer1-fake.txt
root@master:overlay2 $ echo "modification" >> img-layer2/img-layer1-fake.txt
root@master:overlay2 $ ls -li img-layer2 | grep fake
1311618 -rw-r--r-- 1 root root 32 Apr 19 00:34 img-layer1-fake.txt
root@master:overlay2 $ ls -li mnt
total 24
1311616 -rw-r--r-- 0 root root 35 Apr 19 00:34 img-layer1-fake.txt

原因如上所示，overlay2在挂载时会将当时各文件的inode number记录下来，而这个记录是一次性的。所以当我们直接修改底层文件时，文件的inode number发生了改变，而挂载点上的文件指向的仍然是修改前文件的inode number。

Docker是如何使用overlay2的?

Docker overlay2存储结构

当docker使用overlay2存储引擎时，镜像默认存储在宿主机的/var/lib/docker/overlay2目录下。

• 镜像层(以该layer hashId为路径名)

• l

  这个目录中存放的是指向各层的软连接，名字是一串短哈希。这么做的原因是如果用原始的长哈希将更容易的达到mount命令参数的页大小限制。

Container看见的视图

和aufs一样，每个Docker启动后，都会创建一个只读的init layer和一个读写layer。这是Docker在使用UnionFS一个统一的思路，将镜像层作为只读层，容器运行期间产生的文件修改都统一写入最上层的读写层。当容器被删除时，直接将这个可读写的目录删除即可。

通过docker inspect可以查看容器的挂载路径信息:

root@master:docker $ docker inspect 5860f54f3561 | grep GraphDriver -A 8
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/bcb82447d16aeb674c736f7c1e38bbd20335a1f76000bfded93794d105ee4041-init/diff:/var/lib/docker/overlay2/a0b52b932c79aa0cef156fdd9d2ac601a6bafd0bdf0ac2b44b2c7d87274c83b0/diff:/var/lib/docker/overlay2/d9da8c3a58195f856664a840bfc4459caab2b17f14ea8f99b54949eddc79a870/diff:/var/lib/docker/overlay2/955671fdd85ce04b4a71269f9d6f22114c86b24cdd8ca207e5eb9e03d4a4ed5a/diff:/var/lib/docker/overlay2/786411b49cf906bb3b49904716ace173f7be85671b0cc3eff798cde85691d6cc/diff",
                "MergedDir": "/var/lib/docker/overlay2/bcb82447d16aeb674c736f7c1e38bbd20335a1f76000bfded93794d105ee4041/merged",
                "UpperDir": "/var/lib/docker/overlay2/bcb82447d16aeb674c736f7c1e38bbd20335a1f76000bfded93794d105ee4041/diff",
                "WorkDir": "/var/lib/docker/overlay2/bcb82447d16aeb674c736f7c1e38bbd20335a1f76000bfded93794d105ee4041/work"
            },
            "Name": "overlay2"
        },

可以看到，实际的挂载点是每个layer层的diff路径，UpperDir和MergedDir都是为容器创建的那个可读写的临时layer。

reference

1. aufs 简介以及在 docker 中的使用
2. docker-aufs文档
3. docker-overlay文档
4. Linux文件系统之aufs