你大体上有这么两种选择：

应用程序包办一切。程序把应用层的数据，按某种编码转化为二进制数据，然后程序去操控网卡，

把二进制数据发送到网络上。

这期间，通信的连接方式、传输的可靠性、速度和效率的保证等等，都需要这个程序去实现。

然后下次开发另外一个应用的时候，就把上面这些活，再干一遍。  

应用程序、操作系统、网络设备等环节各自分工。

应用程序只负责实现应用层的业务逻辑，操作系统负责连接的建立、处理网络拥塞和丢包乱序、优化网络读写速度等等，

然后把数据交给网卡，后者和交换机等设备做好联动，负责二进制数据在物理线路上的传送和接收。  

那么显然，第一种大包大揽的方式，实现难度太大、耦合度太高，怎么看都是一个“反面典型”。

所以，我们应该选择第二种，也就是分层的方式去实现。  

你有没有发现，其实这个思路，跟编程的思想是类似的。

在编程中，我们需要把一些逻辑抽象为函数或者对象，以实现更好的解耦和复用。

在网络世界里也是如此，每一层干好自己的分内事，那么所有的层次配合起来工作的时候，就显得有条不紊了。

说到具体的分层模型，你应该会想到两种比较有名的方案。

对，它们就是 OSI 的七层模型，和 TCP/IP 的四层 / 五层模型。

这两种模型的最大区别，就是前者在传输层和应用层之间，还有会话层和表示层，而后者没有。

我们来看一下示意图：  

那在这里，你可能还会想：这两种模型哪种用得最多，或者说，哪种更合理呢？ 

其实我觉得倒不用过于纠结在“谁比谁更好”这个点上，如果我们理解了每一层的作用， 那么就不会被表象上的层级所束缚了。

事实上，两种分法都有可取之处。

一般来说，七层模型在我们工作当中谈论得更多些。比如，我的同事会找过来说“你帮我 建一个七层规则吧”。

这里的七层，就是指应用层，他说的“七层规则”呢，可能是 HTTP 路由规则，比如把符合某种条件的 HTTP 请求，

分流到某个特定的后端集群。

还有一些场景，也是比较适合用七层模型来解释的。比如，TLS 虽然在 TCP 之上，按 TCP/IP 模型就要被归入应用层。

但事实上，在 HTTPS 的场景下，HTTP 协议就是运行在 TLS 协议之上的，那么是不是把 HTTP 和 TLS 分到不同的层次更合适呢？正好在七层模型 里，第五层和第六层，可以分别代表 TLS 的会话保持功能和数据加解密这种表示层的功 能。

不过，会话层和表示层的协议确实比较少。

从控制模型复杂度的角度来看，如果把这两层 都合并到应用层，那么模型倒是比较简单，也适合入门学习的。

所以从这一点上看， TCP/IP 模型也有可取之处。 这里你可能稍有疑问，为什么 TCP/IP 还有四层和五层模型这两种说法呢？

其实五层模型就 是 OSI 的前四层，加上一个应用层。

这样的话，这个五层模型跟 OSI 七层模型，差异就比四层模型又缩小了一点。

所以，你现在应该明白了，两种分层模型的最大差异，其实还是在会话层和表示层上面。 

第一到第四层，已经基本统一了。

而它们的最高层，虽然一个叫第七层，一个叫第四层或 者第五层，表面上虽然并不一致，但实际上都可以用“应用层”来代替。

这样既避免了可 能的误解，也更加准确地表示了这一层的具体用途。