OSI参考模型以及TCP/IP模型

Posted 2021-12-10 冬天的毛毛雨

OSI(Open System Interconnection)开放式系统互联，是计算机网络通信的基本框架；它将网络通信的工作分为7层，具体如下图左边蓝色部分所示；它更像是一个理论上的网络分层划分，对于我们编写代码来说并没有太多实际意义；它主要是提供了一系列“协议”，让网络通信更加标准；通过这些协议可以促进不同设备间的兼容性；促进标准化工作；结构上也更容易分割，这样做的好处就是利于实现和维护；就像平时我们使用的电源插板一样，这个行业里有一个标准，只要你的电视机等电器设备在做连接电源的插口时符合这些标准，那么你就不用担心买回来的电器无法适配家中的插座；

TCP/IP模型则是将OSI参考模型以TCP/IP协议的方式重新划分，因为目前市场上几乎所有的网络通信都是基于TCP/IP协议；这个模型是对OSI模型的一个简化；主要分为5层（网络上也有针对TCP/IP模型分为4层的），其对应的简化方式如下图所示；

OSI 7层模型功能描述：
应用层：它是整个层级划分中最高，也是直接面向用户的一层，具体的体现比如：浏览器，各种客户端程序等；
表示层：主要负责数据处理，比如压缩/解压缩，加密/解密等；
会话层：建立，管理，验证目标与目标之间的通信会话；
传输层：建立目标机器与目标机器之间端口的连接并实现两个目标之间的数据传递方式；
网络层：负责网络中目标机器之间的报文传输，这一层传输时依靠的是IP地址；比如路由器；解决跨网络的主机通信问题。
数据链路层：负责网络之间相邻节点的可靠传输，传输依靠的是通过Mac地址；比如交换机；解决相邻主机通信问题。
物理层：原始信号传输，数据传递介质，比如网线之类的；物理层的任务就是透明地传输比特流。

举个通俗易懂的“栗子”来说明一下这7层的含义：

我想写一封情书给一个漂亮姑娘；我最终的目的是想要通过书信里的文字让她能理解我的心意，但我们距离很远，又没有手机，所以我决定以写信的方式进行；再讲例子之前，要先注意一点，不要把应用层，表示层等这些划分的层级与具体的事物关联起来去做具体化想象，而应该“协议化”，“标准化”，后面有表述；

1： 我现在想写信，内容就是“我爱你，漂亮的姑娘”，可是这么肉麻的话，我希望就我和她能看到具体的内容；在这里，可以把“我”看成某个应用，我要传递数据给另外一台机器上的某个应用，但是我传递给她的数据一定是根据某些“协议”来的（HTTP协议等），比如，她是一个文化程度不高的人，看不懂英文，如果我把信的具体内容写成英文，她看不懂，那么这封信即使传递出去了也没有价值；所以相当于我们很默契的约定好了，这封信应该用中文写；“我”这个应用，以及使用了中文写的文字，就属于应用层应该遵守的协议以及该干的事情；所以不能简单的将“我”这个应用来代表会话层，而应该将“我”这个应用，以及约定好的中文形式内容合起来并为会话层；

2：我买了一个信封，将我写的内容放到信封里封起来；这个过程就是表示层，内容被我套进了信封进行了加密，并且在信封上写上了姑娘的地址，贴了邮票；而信封也是因为我遵守了写信这件事的一些俗成约定与协议，所以我不会随意用一个盒子或者纸盒将信放进去（我遵守的信封“协议”，以及使用信封加密这个过程都应该称为表示层，而不是单纯将信封理解为表示层），接下来就是交给下一层（会话层）处理；

3：会话层，相当于邮局的部分管理系统，邮局拿到我的信之后，需要在邮票上盖章，只有盖完章之后才说明了这封信的“合法性”，这封信不管是在邮局的哪个网点，不管这个网点是100平的规模，还是只有一个10平米的小网点，看到这封信上有邮票，并且盖了章，就知道这封信是“合法”能通行的；所以会话层相当于一个管家，它负责对数据进行相关的验证管理，如果你贴了邮票，我盖了章你才能在整个邮局系统通行，不然就无法通行。

4：传输层，会话层已经对我的信进行了“合法”校验等操作，传输层拿到这个“合法”数据后，开始进行装车，但是我不能随意用摩托车或者其他货车去装载这个信；而应该使用邮局内部系统规定的方式；比如，邮局内部的“协议”是，所有的信都必须使用带有邮政标识的绿色的货车进行运输，也只有这种货车才能不管在邮局的哪个网点都拥有通行的权力，不然其他网点按照规矩办事可能会拒绝你的信，因为你没按照我规定的货车运货；这里就相当于我已经把要发送的内容按照规定的方式都已经装载好了，这规定的方式遵守的协议就是TCP或者UDP；这一层说的端口与端口之间的连接;

5：网络层，车已经装载完毕，邮局开始运送我的信，而邮局送信使用的是货运车，货运车根据我信封的地址，送到漂亮姑娘住的小区；而漂亮姑娘住的小区地址就相当于是IP地址；而这一层就是我们平常说的IP协议层；而这个地址按照协议就是必须先写省份，再写市之类的格式；

6：数据链路层，当信被送到小区门口后，发现进不去，因为门卫（交换机）说，本小区的信都放在我这里，我再帮你送上去；数据链路层就是将比特流组合成字节，再将字节组合成帧，通过mac地址（姑娘的门牌号）进行差错检测；

7：这封信在整个的传输过程中，走的是高速，还有其他道路，这些路和运送信的车都属于物理层，它们就是真正保证我的信能够安全快速送达的最底层保证；信号的最终传输都是通过物理层实现的；常用的一些设备比如网线；

以上两张图片摘自网络

从上面两张图我们也能看出，各层与各层之间都有一定“具体的物体”，这些物体在运行时又分别遵守了在该层应该遵守的协议；但这些模型终究是要对两个目标机器之间的数据传输；再来一张终极解释的图片，看看两个机器之间如何进行通信；

Socket（套接字）底层通信原理

Socket通信一直给人一种非常神秘的感觉，如果要了解Socket就必须先从“宏观”的角度来理清楚它的原理；

首先，Socket最开始是在Unix/Linux上使用的，之后由于其方便，高效，目前绝大部分市场上的应用都采用的是Socket；如果不熟悉Unix/Linux也没关系，但需要知道的是，在Unix/Linux中，可以认为“一切皆文件”，这里的文件的怎么解释？一个文件如果要进行修改必须先open操作，然后read/write操作，之后再close。那也就意味着Socket本质的通信方式也是打开某个“文件”，然后读取，然后关闭；

另外，再说一下进程间通信，系统的每个进程都是在自己的“范围”内运行，如果两个进程要进行通信就必须通过“系统”提供的其他方式；比如android中的进程间通信就是靠binder机制；而网络机器之间的应用数据传递也是“进程间通信”，只是之前不夸机器，这次夸了机器而已；如果对binder机制不是特别熟悉，那么我们可以先把整个Binder机制的底层操作逻辑看成一个文件。（在windows电脑上，我们可以通过局域网看到其他电脑分享的文件，同时也具备对该文件一定的操作权限）

如上图所示，某“文件”就代表了整个Binder机制的底层逻辑；A机器的A应用通过Binder机制，将自己的数据写入到A机器系统提供的“某文件”，然后A机器的“某文件”通过Socket的方式与B机器的“某文件”进行数据的传输，当B应用需要获取从A应用来的数据时，只需要实时监听B系统提供的“某文件”是否发生了改变，改变了什么即可；

但这种“文件操作”对于上层应用来说是非常不友好的，所以系统使用了Scoket（套接字）的方式来帮助我们建立起他们之间的链接，开发者只需要关注Socket的API即可；

上图来源于网络，Socket就是封装了TCP/IP那一层；

再来看一下Scoket的通信原理；

此图来源于网络：（原文链接：https://www.cnblogs.com/JavaHxm/p/10968210.html）

再根据之前我们说到的“宏观”方式来理解这幅图，TCP服务器有一个“文件”需要共享出去，并且时刻知道它发生了哪些改变，当发生了某些改变时，服务器对这个文件做相应的业务修改；为了能够实现共享，于是使用了Socket，Socket通过调用socket(),bind()，listen()，accept()方法来创建了一个“文件”，并且时刻监听着；TCP客户端则按照服务器的方式创建Socket并通过connect()方法去连接服务器的“文件”，不停的往“文件”中写入数据，服务器则根据“文件”里数据的变化来实行自己的业务逻辑；直到满足两者的交流后再通过close()方法进行关闭；想更加自信的了解不同的方法具体做了什么事情，可以访问上图底部提供的参考连接；

TCP的3次握手和四次挥手

3次握手解读

第一次：客户端发送请求给服务器，请求包括syn=1，以及随机产生的seq数值；

第二次：服务器收到客户端发来的信息后，先确认请求，然后向客户端发送ack number（ack等于seq+1），syn=1，ack=1；

第三次：客户端检查ack是否正确，即第一次发过去的seq是不是已经加1了，以及ack是否为1，如果正确；客户端会再发送ack number（seq+1），ack=1，服务器确认seq值以及ack=1后则连接成功；

4次挥手解读

第一次：客户端发起中断连接请求，发送FIN报文；

第二次：服务器接收到客户端的FIN后，回馈一个ACK给客户端，告诉客户端，你的请求我已经收到，但请等待一下，我可能还有数据要发给你；客户端进入FIN_WAIT状态（此时还没有关闭，只是客户端想断开连接）；

第三次：服务器发送FIN给客户端，告诉客户端我已经发送完数据了，现在你可以关闭连接；

第四次：客户端接收到服务器的FIN，再发送ACK给服务器，服务器收到ACK后，则断开连接；

为什么三次握手，确有4次挥手？

因为服务器接到客户端发送的请求后，只需要校验请求是否合法，如果ok则可以直接连接；但挥手时有一个特殊情况需要处理，当客户端需要断开连接时，服务器还有可能有一些数据是没有发送给客户端的，当服务器接到客户端发送的断开请求时，必须要先确认自己的数据都已经发送完毕了，所以接收到客户端的请求时，服务器端回应两次；

Http协议

Http请求

GET方式请求

请求往往由请求行，请求头，请求体组成；

请求行：请求方式Method，协议版本号组成；GET / HTTP/1.1

请求头：访问的域名，用户代理等信息；Host:www.baidu.com

消息体：由于是Get方式，看不到请求体；

POST方式请求

请求行：请求方式Method，协议版本号组成；POST / HTTP/1.1

请求头：访问的域名，用户代理等；Content-Length，Content-Type等；参数很多，请自行查证HTTP协议相关知识；

消息体：跟请求头用一个空行隔开；主要是post类型时，记录传给服务器的参数；

Http响应

Http协议响应图

响应一般分为响应行，响应头信息，响应体

响应行：HTTP/1.1 200 ok（协议名称，版本，状态码，对应状态码的解释）

响应头信息：类似请求头里的信息，有很多的参数约定；

响应体：跟响应头以空行隔开；服务器根据要求返回的“文本”内容；