下载掌阅APP，畅读海量书库
立即打开
在讲课的过程中，我往往极不情愿介绍OSI参考模型，因为我很怕学生向我提问一些我答不出来的问题。答不出来还好，诚实地说一句“不知道”，倒也一了百了。就怕学生问一些貌似简单，我也能回答上来的问题，但我的答案明显是一些人云亦云的说法，无法就其中的细节给予更加深入的解释。为什么会出现这类尴尬情况呢？因为OSI参考模型是一个 理论参考模型 ，而且真的是“仅供参考”，人们对于它的解读基本来自 定义 ，而不是对于经验的总结。此外，它诞生的背景据说很不靠谱。
不靠谱到什么程度？
想象这样一个场景：一个新入行的同学拿着一份需求来咨询我某个企业网络应该划分成几个子网。我跷着二郎腿，吃着麻辣味的太阳锅巴，眼睛直勾勾地盯着电视上正在播映的《葫芦娃》，看也不看他的需求，不假思索地告诉他：“分7个”。这个同学一边思考着为什么是“7”，一边愣愣地注视着电视上正在和蛇精斗智斗勇的葫芦兄弟们，瞬间恍然大悟，扭头就走。一边走一边说：“得亏这家伙看的不是《水浒》。”
就是不靠谱到这种程度。
OSI模型设计之初，参与设计的人倒是没看《葫芦娃》。但 据说 人家当年讨论应该把网络分成几层时，碰巧聊到了白雪公主与 七个 小矮人的故事，于是就有了我们现在的OSI七层模型。从这个角度看，我们可以得出一个结论：生于18世纪的格林兄弟深刻改变了网络发展的历史。在这个OSI七层模型中，最为人们所诟病的是上三层在功能上进行分类的必要性。读者在网络技术领域接触的信息越来越多，就会发现OSI模型的第五层和第六层在工作中甚少有人提及。
当然，不管OSI模型有多不靠谱，它依然顽强地活在大学教材及工程师们似是而非的称谓中，甚至有愈演愈烈之势。就冲这一点，OSI模型仍然是一个需要大书特书的话题。具体而言， 这个为了对异构网络进行标准化而自20世纪70年代开始起草，并最终于1984年发布的参考模型明确区分了服务、接口和协议这三个概念。在这个逻辑的分层结构中，每一层会接受下一层所提供的服务，并且向上一层提供服务。接受和提供服务是通过服务访问点（SAP）来实现的，而具体的服务是通过协议来实现的。
在前文中，我们已经通过信用卡中心的例子说明过分层模型的工作方式了，下面我们再次通过经典的邮局示例来深入解释一下这个理念。这个例子才是各大高校和培训机构常用的例子。
如图1-4所示，甲地的写信人A通过邮局给乙地的收信人B寄出一封信。根据下层为上层提供服务的理念：邮局是A的下层，运输部门是邮局的下层。假设A与B这两个人都用中文写信，各地邮局使用相同的规则来收发信件，这说明了同一层之间使用的协议（语言和收发信件的规则）是相同的。A并不关心邮局是如何把信件从甲地发送到乙地的。也许邮局本来通过陆运方式发送信件，而现在改用空运方式发送信件，但只要A把信件扔进邮筒中，信件就会被送达B。而甲地邮局也无须知道信件里的具体内容，它所关心的是如何把信件发送到乙地邮局。这个案例很好地说明了各层之间的独立性。
图1-4 邮局示例
OSI参考模型把网络通信所需的所有功能，从上到下定义了七个层级， 并且分别定义了这些层级可以提供哪些服务，能够实现哪些功能等（见图1-5）。我们刚刚说过，OSI模型只是一个概念模型，它并没有提供实现这些功能的方法。因此就某个具体的协议而言，它也不一定能够提供OSI为该层定义的所有服务；同样，一个协议是否只能按照OSI对该层的定义来提供服务，答案也是未必。如果一个协议既具有第七层的一部分功能，又具有第六层的一部分功能，那它到底属于第几层协议呢？更诡异的情形是，如果一个协议从封装数据包的角度来看属于第七层协议，但从功能的定义上却属于第三层或第四层的协议，它又该属于第几层的协议呢？这也是在讨论一些协议时，工程师们经常会争论的地方。在后文涉及这种情况时，我们会提供一些模棱两可的解释。但我们的建议是，读者大可不必过于纠结这种分类。分层模型固然重要，具体协议仅供参考。
图1-5 OSI参考模型
不管作者本人如何看待OSI模型，一旦涉及写作出版网络技术类教材，还是不得不把各层的功能分别解释一番，各类网络技术读物概莫能外。本书当然不能免俗。在介绍OSI模型各层的功能划分时，一般有两种思路：一种是从应用层介绍到物理层，这种方式称为自顶向下；另一种是从物理层介绍到应用层，这种方式称为自底向上。鉴于后者比较适合刚刚踏入网络技术世界的读者，因此 我们将采取自底向上的方式对这七层的功能进行介绍 。