TCP/IP参考模型-分层架构

系列文章目录

由于因特网的实现是一个分层架构，为了防止篇幅过大，笔者不想一篇文章就写完想表达的所有内容，于是会以系列文章的方式，主要内容包括TCP/IP分层架构、网络层的最短路径算法：Dijkstra算法的实现细节，传输层的TCP传输控制协议的拥塞控制、流量控制以及握手和挥手，和应用层的DNS服务。

《TCP/IP参考模型-分层架构》
《TCP/IP参考模型-应用层的DNS》
《TCP/IP参考模型-传输层TCP》
《TCP/IP参考模型-网络层Dijkstra算法》

前言

TCP/IP参考模型是现今因特网(Internet，大写的I区分于internet表示的互联网)上使用的模型，所有想要连接Internet的网络必须符合这个参考模型的定义。其中特别重要的概念是服务、接口、协议和分层架构。

为什么要分层？

在讨论TCP/IP的分层架构之前，首先需要思考一个问题，为什么要分层？————————————————————————
分层最主要的目的在于，当某个问题特别复杂的时候，你没法直观地去思考怎么做。如果把这个大问题分成几个子问题，然后分别去解决这些子问题，通过解决这些子问题来解决大问题，就相对简单的多。比如在工作的过程中，突然碰到了个难缠的问题，你可能完全没有思绪，不知道怎么动手。这时不妨稍微想一下，要解决这个问题，你首先需要做的是什么，把它写下来，然后是第二件事、第三件事。写下来之后你就对这个问题有了一个感性的认知，基于这个认知再对每一件事情进行拆分、执行就很清晰了。这种思想就叫做分而治之，笔者看过一些开源软件的架构，一开始都是使用这种思想来进行设计的。
当你经常性的这么思考时，就能快速地抓住每一件事情的本质，或者说在问题出现时，往本质的方面思考，而不被表象所束缚。当然，要每次都能抓住问题的本质，很难，这需要刻意练习和学习。
TCP/IP的的分层架构就是这样，它的问题是如何将全世界这么多不同的物理网络相互之间连接起来，因为这个问题很复杂，所以需要拆成一个一个子问题来解决。

TCP/IP参考模型的层次结构

TCP/IP主要分为应用层、传输层、互联网层和数据链路层，他们的顺序如下面表格中的层次列所示。自底向上看，每一层都向上一层提供了一些服务。自顶向下看，每一层都通过接口使用下一层提供的服务。其中接口代表抽象，与之相反的概念就是具体。显然，上层依赖的是下层的抽象，而不是具体实现，这体现了面向对象设计的基本原则之一的依赖倒置原则：模块之间不能相互依赖细节，而应该依赖其抽象。
需要注意的是，在TCP/IP中没有体现物理层，因为因特网本身就是要解决异构物理网络相互连接的问题，所以没有去定义物理网络是怎样的。

层次	相关协议
应用层	HTTP、DNS、MQTT、WebSocket
传输层	TCP、UDP
网络层 （互联网层）	IP、ICMP
链路层	DSL、SONET、802.11、Ethernet

现在我们来自底向上的来谈论每一层提供的服务。

链路层

链路层又称数据链路层(data link layer)，专门用于两个相邻机器之间的数据传输。如果暂时去掉交换机、路由器或者网桥之类的中继器概念，一个简单的例子就是将两台电脑通过双绞线连接起来，这两台电脑便拥有了一个信道，而链路层就是在这个信道上传输数据的软件，它还提供差错控制、流量控制等功能。
对于两台计算机之间的通信，分成点到点链路和广播链路两种，点到点链路就是上面介绍的有线连接。广播链路就是指无线网络，比如WIFI，无线网络本质上就是广播网络，它只有有限个信道，所以难免会出现信道竞争，而解决竞争问题的层就叫介质访问控制(MAC,Medium Access Control)子层。
每一层都有一个数据传输单元的格式和名称，链路层的就叫帧(Frame)，一个帧由帧头、有效载荷、帧尾组成。

网络层

在TCP/IP中，弱化了链路层的概念，因为它跟具体物理信道有关，所以本质上链路层只要能提供给网络层两个相邻计算机或者网关的通信服务就行了，而不在乎其使用的那种技术。
解决了相邻计算机之间传输数据的需求，接下来的问题就是：如何让不在一个物理网络中的设备进行通信。网络层是使用一种叫做路由器的设备，这意味着设备之间不能只跟相邻节点连接，而是要直接或间接地连接到路由器。用这种中心化的设备去管理转发和路由的问题，它首先需要知道这个物理网络下的拓扑结构，然后在拓扑结构中找到一条最短路径。涉及路径的算法大体上分成两种，一种叫域内路由算法，一种叫域间路由算法，分别代表同一个物理网络和不同物理网络如何路由的算法。
关于路由算法我会专门写一篇文章，介绍最短路径算法中的：Dijkstra算法。
网络层的数据传输单元叫做数据报(Datagram)，它是由报头和数据两部分组成。

传输层

网络层提供给传输层一个源计算机到目标计算机的通信服务，但是实际使用通信的都是应用程序，所以传输层需要在网络层的基础上提供给应用程序一个应用程序和应用程序之间的通信能力。网络层提供的是一个尽力而为的数据报服务，所以传输层还要解决通信可靠性的问题，比如如何防止发送方速率远远超过接收方速率而淹没接收方的问题，以及网络状态不好产生丢包的问题，这些问题的解决办法分别叫做流量控制和拥塞控制，还有怎么确保一个数据真的到达了接收方，关于这些内容笔者也会专门写一篇TCP传输控制协议(Transmisson Control Protocol)的文章。
传输层的数据传输单元叫做段(Segment)，同样也是段头和数据两部分。

应用层

有了以上这些层的支持，应用层相对来说就比较简单了，一个老生常谈的协议就是HTTP超文本传输协议（Hyper Text Transport Protocol），它通过调用TCP来实现数据的传输以及可靠性，为什么这么说呢，因为传输层还有一个叫做UDP用户数据报(user datagram protocol)的不可靠协议，它没有TCP的确认机制也没有流量控制机制，所以对于一些对可靠性要求不高的应用来说，它比较有优势，比如DNS域名服务(Domain Name Service)。而有些应用场景嫌弃HTTP包太重，于是就有MQTT消息队列遥测传输(Message Queue Telemetry Transmission)协议，主要用于物联网的低功耗设备通信上。
由于应用层用于解决实际问题，场景特别多，这里我们就以HTTP为例，它的数据传输单元叫做消息(Message)，消息包括消息头和消息内容(Message body)。

总结

通过对各层所提供服务的分析，相信大家已经对这些层有了一个认识，接下来带大家梳理一下，消息从应用层是如何传到另一个机器上的。作为应用程序员，我们接触最多的应该就是应用层的HTTP协议，所以可能大家认为消息就是从客户端HTTP传送给服务端HTTP了，这种认识其实恰好证明了分层的好处，调用者不用了解接口里到底实现了什么。然而，越是这样，我们越要了解底层是什么，它们到底是怎么实现的。
现在我们开始通过自顶向下的方式来了解一个消息是怎么传送到另一台机器上的，还是老规矩，请看图：

在图中，用实线表示消息的实际传输过程，虚线表示对等实体之间通过协议来进行通信的关系，这里解释一下什么叫做对等实体，对等实体就是不同机器相同层次的实体，它们通过使用相同的协议来达成一致。虚线是在编程中大家容易理解的部分，而实际的传输过程是像实线表示的这样进行的：发送方将消息自顶向下的封装，然后接收方自底向上的解封，最终得到原本的消息。上层通过接口来使用下层的服务，这又很符合面向对象思想的封装，对外提供访问接口，隐藏内部实现细节。