全新OSI网络栈：容器与半层

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

早在1983年，当时我还在学习如何通过PEEK和POKE操作Apple ][e的硬件，计算机和电信行业的一群志同道合者聚在一起，制定了一套详细的规范，并将其称为开放系统互连（OSI）。这项工作最初旨在共同商定实际接口，后来逐渐演变为一种通用参考模型，供互联网工程任务组（IETF）等其他组织用于开发接口。这些接口最终可以成为标准，而且事实上也确实如此，例如IP、TCP和HTTP等。

我们大多数人都曾在大学计算机科学课程中费力学过这一参考模型。我们学习了“OSI七层模型”，但进入现实世界后才发现，实际实现很少能与OSI网络模型完全对应。

尽管如此，它与实际情况的对应程度已经足够高，因此我们仍将其作为最初设计的参考模型使用。大多数人都知道，第4层通常指TCP，第7层通常指HTTP，而第2/3层通常指IP和以太网。这些说法几乎可以互换使用。

几年前，我们甚至还争论过，与SDN和虚拟网络相关的覆盖协议究竟属于哪一层。它们算不上真正的第2层协议，但也不完全属于第3层，而是介于两者之间。

大多数时候，我们可以忽略这个问题，只需笼统地指向这两个层级，将其称为“覆盖网络”。大家都明白我们的意思，而且还有其他问题值得争论，比如云的定义，以及DevOps是否适合企业。

容器应运而生，更准确地说，是容器网络应运而生。容器编排环境（COE）高度动态且自动化，因此网络堆栈中需要增加更多层。

与覆盖网络一样，我们不太愿意在OSI模型中创建新层。毕竟，它如今已成为标准参考模型，而更改标准可能需要很长时间。非。常。漫。长。但与覆盖网络一样，这些层仍作为网络堆栈中不可或缺的接口而存在。也正因如此，我倾向于将它们称为“半”层，因为它们对COE网络的未来至关重要。

第4.5层：服务网格

第一个“半层”位于第4层和第5层之间，服务网格的执行和自动化正是在这一层发挥作用。简而言之，服务网格由以边车模式部署的代理构成，这些代理会拦截每个请求，从而能够在整个容器环境中针对服务执行特定于域的路由。服务网格以底层协议的存在为前提，并对其进行有效扩展。这是必要的，因为其下方的所有网络层都假定连接和路由仅基于IP地址。尽管归根结底，这确实是数据包在容器环境中如何传输的方式，但决定将特定请求发送到哪个IP地址和端口时，依据的并不是这些信息，而是与服务和应用的状态及位置相关的各种变量。实质上，我们会查看请求的元信息，并据此确定其路由方式。这些元信息对于构建“网格”至关重要，而该网格又能保障每项服务的可用性和扩展能力。

第 7.5 层：服务标签

第二个“半层”位于靠近顶部的位置，在第7层之上。暂且不谈“人类层（第8层）”这个玩笑，COE确实会在应用之上添加一层元数据，充当“黏合剂”，使容器化环境能够实现扩展。这些应用或服务“标签”用于标识COE可自动扩展的各项独立服务。没有这些标签，几乎无法区分不同的应用。这是因为OSI模型的每一层都可以通过IP地址和端口等特定构造来识别。长期以来，我们已经熟悉依赖共享这些构造的架构实现，而这种共享发生在环境外部（虚拟服务器和基于主机的网络）；容器则在环境内部造成了同样的问题。共享端口和IP地址后，很难以所需速度区分不同服务。

在容器化环境的第7.5层添加“标签”，可让负载均衡和路由等网络服务唯一标识资源，同时确保可扩展性和可用性。

新的“容器层”使环境能够与网络构造解耦，从而比以往仍与网络堆栈中其他层紧密绑定的技术具有更强的可移植性。容器化环境在“半层”运行，并以传统层的存在为前提，因此不依赖任何特定的网络方案或架构，可以同样轻松地在开发与测试、测试与生产、本地部署与云环境之间迁移。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章