网络七层模型与TCP/UDP的原理是什么
这篇文章主要讲解了“网络七层模型与TCP/UDP的原理是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“网络七层模型与TCP/UDP的原理是什么”吧！
10年积累的成都做网站、成都网站设计、成都外贸网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有白水免费网站建设让你可以放心的选择与我们合作。
为了使全球范围内不同的计算机厂家能够相互之间能够比较协调的进行通信，这个时候就有必要建立一种全球范围内的通用协议，以规范各个厂家之间的通信接口，这就是网络七层模型的由来。本文首先会对网络七层模型的功能进行介绍，然后会讲解传输层的两个重要协议：TCP和UDP协议，并且会着重讲解TCP协议中的三次握手和四次挥手的过程。
1. 网络七层模型
关于网络七层模型，我们首先以一个图例来展示其功能：
应用层：主要指的是应用程序部分，比如我们的Java程序，应用层所产生的数据成为应用层数据，典型的应用层协议，比如有HTTP协议，dubbo的rpc协议，这些都是由我们的应用层程序自己定义的；
表示层：这一层主要是对应用层的数据进行一些格式转换，加解密或者进行压缩和解压缩的功能；
会话层：会话层的主要作用是负责进程与进程之间会话的建立、管理以及终止的服务；
传输层：传输层提供了两台机器之间端口到端口的一个数据传输服务，因为应用层、表示层和会话层所针对的都是某个应用进程，而进程是和端口绑定的，但是同一台服务器上是可以有多个进程的，因而传输层提供的就是这种不同的端口到端口的访问，以实现区分不同进程之间的通信服务。在传输层最典型的协议有TCP和UDP协议，TCP提供的是面向连接的、可靠的数据传输服务，而UDP则是无连接的、不可靠的数据传输服务。在上面的图中我们也可以看出，经过传输层之后，数据会被加上TCP或者UDP头部，用以实现不同传输层协议的功能；
网络层：传输层提供的是同一台主机上的端口到端口的传输服务，而网络层则提供的是不同主机之间的连接服务，最典型的网络层协议就是IP协议，网络层会将当前的数据包加上一个IP头部，从而实现目标机器的寻址；
数据链路层：这一层是承接软件和硬件的一层，由于其会将当前的数据报发送到不稳定的物理层硬件上进行传输，因而为了保障数据的完整性和可靠性，数据链路层就提供了校验、确认和反馈等机制，用以提供可靠的数据报传输服务；
物理层：物理层的主要作用就是将
0101这种二进制的比特流数据转换为光信号，用以在物理介质上进行传输。
网络七层模型主要是提供的一种规范，而在这每一层上为了实现不同的功能，各个计算机厂商都会实现自己的协议，这些协议的标识就是通过一些协议头和进行的，比如上面图中，数据在经过每一层的封装之后都会为其加上自己的协议头部，当数据经过屋里介质传输到目标机器上后，其就会反过来，将数据进行一层一层的解析，解析的过程其实就是根据其每一层头部信息来实现该层的相关功能。
另外，网络七层模型是一种比较理想化的模型，现在应用比较广泛的是网络五层模型，五层模型与七层模型的主要区别在于将应用层、表示层和会话层统一划分到应用层中了，由应用程序实现其相关的功能。
2. TCP与UDP
在我们的应用开发过程中，我们其实不需要太过于关注底层相关的功能，这些只需要相关的服务提供商提供相应的功能即可。不过在传输层之中，我们需要特别关注一下现在广泛使用的两个协议：TCP和UDP协议。这两个协议之间的主要区别如下：
| TCP | UDP |
|---|---|
| 面向连接 | 无连接 |
| 提供数据可靠保证 | 不提供数据可靠性保证 |
| 速度相对较慢 | 速度较快 |
| 占用资源较多 | 占用资源较少 |
关于TCP和UDP，可以看到，这两个协议各自分别有非常鲜明的特点：TCP虽然占用资源较多，速度相对较慢，但是提供了可靠的数据传输服务，这在大多数的互联网业务中是非常必要的；而UDP虽然不提供可靠性的数据保证，但是其速度非常快，而且占用资源较小，这在一些对数据可靠性较低的场景中是非常有用的，比如音视频服务，物联网数据上报服务等等，这些情况下，数据丢失一两帧都是可以接受的。
TCP和UDP在资源占用上的区别，不仅体现在数据传输方式上，还体现在了数据的传输格式上。对于数据传输方式，TCP每次发送数据的方式都是按照时间窗口的方式一个数据报一个数据报的发送，并且需要等待每个数据报都给数据发送方响应ACK，这个时候才会发送下一个数据窗口的数据，如果当前窗口内有任意一个数据报没有发送成功，那么整个窗口内的数据都会重新发送；而UDP则没有窗口的概念和对应的ACK机制，其获取到每一个数据报之后，都只是简单的为其封装UDP协议头，然后将其发送出去，其不会管这个数据是否发送成功，因而UDP传输比TCP是要快很多的。对于数据传输格式，这里我们以TCP和UDP的数据报的格式进行讲解，如下是TCP的数据报格式：
可以看到，TCP数据报的头部中不仅包含了源端口号和目的端口号，还包含了序号、确认序号、首部长度、标志位等等信息，总的来看，除去真正的数据部分，头部信息占用的位数就达到了192位，当然，这么多字段主要的作用是为了实现TCP面向连接的可靠性传输的功能。如下则是UDP数据报的格式：
可以看到，这里UDP的数据包格式相对于TCP就非常的精简了，其头部主要就只有源端口号、目的端口号、长度和校验和字段，这些总共占用的字节数是8个字节。这也就是UDP协议传输速率非常快的另一个原因。
2.1 三次握手和四次挥手
TCP是一个提供可靠传输服务、面向连接的的传输层协议，其可靠性保证主要是通过每次数据报发送时的ACK机制实现的，而其连接的建立和释放则主要是通过三次握手和四次挥手的方式实现的。如下是其三次握手和四次挥手的过程：
对于三次握手，其整体过程如下：
首先客户端会发送一个建立连接的请求，其标志位中会带上
SYN=1, seq=x，这里的SYN=1根据前面TCP头部信息的讲解中我们知道，其表示建立连接的请求，而seq=x则只是当前请求的一个序号，不同的请求是有不同的序号的，加这个序号的原因也是为了将其与服务端的响应请求关联起来；在服务端接收到客户端建立连接的请求之后，其就会返回
SYN=1, ACK=1, seq=y, ack_seq=x+1，这里的SYN=1, ACK=1表示的是对客户端建立连接的请求的同意响应，seq=y则标识了这是服务端的一次数据发送，而ack_seq=x+1则表示其是对客户端的seq=x的请求的一个响应；在客户端接收到服务端的响应的时候，客户端就能够确认服务端是能够正常接收和发送数据的，而服务端在接收到客户端的第一次请求的时候也能够确认客户端能够正常的发送请求。这个时候，客户端就会发送一个
ACK=1, seq=x+1, ack_seq=y+1给服务器，服务器接收到后就会完成连接的建立。
可以看到，前两次请求都是建立连接所必要的，而客户端要发送第三次请求的原因主要有两点：
可以让服务器确保客户端是能够正常发送和接收请求的；
由于连接的建立是在不稳定的网络上进行的，因而这里有可能第一次请求是由于客户端在某个时间点发送的，但是由于网络延迟，导致很久之后服务器才接收到该请求，但此时服务器并不知道这个连接建立的请求是否是正常请求，其还是会正常发送一个同意建立连接的响应给客户端，如果第一请求是由于网络延迟造成的，那么客户端是不会再发送第三次握手给服务器的，这个时候服务器等待超时后也就不会建立这一次的连接了。
对于四次挥手，其是在客户端与服务器交互完成之后，由客户端发起的。四次挥手的主要流程如下：
客户端首先会发送一个
FIN=1, seq=u给服务器，根据前面TCP头部信息的讲解，我们知道FIN=1表示这是一个断开连接的请求，而seq=u则标识了这次请求的一个序号；服务器接收到客户端的断开连接的请求后，其就会向客户端发送一个
ACK=1, seq=v, ack_seq=u+1的响应，这里的seq=v还是表示当前请求的序号，而ack_seq=u+1则表示这是对客户端发送的seq=u的断开连接的请求的响应，但是需要注意的是，这个请求并不表示服务器同意断开连接，此时还只是一个半关闭的状态，因为此时服务器可能还有数据在进行处理没有发送给客户端，此时服务器就会完成这些断开连接的工作；待服务器完成了断开连接的准备工作之后，其就会给客户端发送一个
FIN=1, ACK=1, seq=w, ack_seq=u+1的响应，注意，这个过程中客户端一直都处于等待状态的。这里相对于前一次响应，多了一个FIN=1，就是表示当前是确认断开连接的请求；客户端在接收到服务器的响应之后，其就会给服务器发送一个
ACK=1, seq=u+1, ack_seq=w+1的响应，表示同意断开连接，服务器接收到后就会断开连接，而客户端则会等待一小段时间后自行断开连接。
3. 小结
本文首先讲解了OSI网络七层模型，详细讲解了模型中每一层的作用，然后讲解了传输层中TCP和UDP的主要区别，从传输方式和传输数据格式上对两种协议进行了对比，最后讲解了TCP协议中三次握手和四次挥手的主要过程，并且详细讲解了每一步的作用。
感谢各位的阅读，以上就是“网络七层模型与TCP/UDP的原理是什么”的内容了，经过本文的学习后，相信大家对网络七层模型与TCP/UDP的原理是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！
网站栏目：网络七层模型与TCP/UDP的原理是什么
标题链接：http://scjbc.cn/article/gchjgo.html
