传输层协议（UDP和TCP）

最新推荐文章于 2023-09-16 16:37:09 发布

阿瑶带我飞

最新推荐文章于 2023-09-16 16:37:09 发布

阅读量270

点赞数

分类专栏： JavaEE初阶传输层的协议文章标签： udp 网络网络协议

本文链接：https://blog.csdn.net/C_TQH/article/details/130134557

版权

JavaEE初阶同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

传输层的协议

1 篇文章 0 订阅

订阅专栏

一、UDP

1、UDP的报文格式

🍔注意：一个UDP报文的最大长度就是64KB

校验和存在的意义，就是用来判定一下，当前传输的数据是否出错。校验和出错，传输的数据一定发生了改变；校验和正确，传输的数据也有可能发生改变

2、UDP的特点

无连接
不可靠
面向数据报
全双工

相对来说内容比较少，软柿子捏完了，接下来看看TCP

二、TCP

1、TCP的特点

报文格式：

有连接
可靠传输（TCP的初心，最核心的机制）
面向字节流
全双工

2、如何实现可靠传输

1、确认应答

对于网络传输过程中可能会出现后发先至的情况，针对这一问题，TCP进行了处理，每一个socket都有一块缓冲区，可以在这里进行 "整队" ，处理了这个问题

2、超时重传

网络传输会出现"丢包"现象，如果包丢了，接收方就收不到发送方发来的数据，自然就不会返回ACK应答报文了。如果发送方迟迟没有收到接收方发来的ACK报文，就会视为 "丢包" ，就会再发一遍

对于丢包，有两种情况：

1、数据直接丢了，接收方没有接收到数据，自然不会发送ACK应答报文，超时重传

2、返回的ACK丢了，此时接收方会收到两份相同的数据（会存在问题），TCP会到接收缓冲区当中查找是否有相同序号的数据，自动去重

TCP针对多个包丢失，处理思路：

继续超时重传，每丢包一次，超时等待时间变长（重传的频率降低），连续多次重传，都无法得到ACK，此时TCP就会重置连接，如果重置连接也失败了，就会关闭连接，放弃网络通信了

3、连接管理机制（非常重要）

网络原理最核心的问题

TCP建立连接：三次握手

TCP断开连接：四次挥手

三次握手

四次挥手

TCP报头

三次握手过程，一定是客户端先向服务器发送SYN同步报文，服务器随即发送应答报文ACK和SYN（同时发送的，是由操作系统内核来控制的），客户端收到服务器发来的ACK和SYN，向服务器发送应答报文ACK，三次挥手结束，连接建立。

四次挥手过程，客户端和服务器谁都可以先进行发送，假如客户端先向服务器发送FIN结束报文，服务器接收到之后，回应ACK报文（操作系统内核完成），然后也会发送FIN结束报文给客户端，客户端收到后也回应一个ACK报文，四次挥手结束，连接断开。

🍔三次握手，ACK和SYN是同一个时机触发的（都是内核来完成的）

🍔四次挥手，ACK和FIN则是不同时机触发的（ACK是内核完成的，会在收到FIN的时候第一时间返回，FIN则是应用程序代码控制的，在调用到socket的close方法的时候才会触发FIN）

4、滑动窗口（批量传输）

批量传输

滑动窗口

如果在此过程中出现丢包的情况下，该怎么处理呢？

分为两种情况：

这种情况，不要紧，可以通过确认序号来解决。确认序号的含义：该序号之前的数据都已经收到了，后一个ACK能够涵盖前一个ACK。

上述重传过程，没有任何冗余操作，丢了数据才会重传，不丢数据的不会重传，整体速度是比较快的，这个重传过程也被称为快速重传

5、流量控制

接收端处理数据的速度是有限的，如果发送端发的过快，导致接收端的缓冲区被打满，这个时候如果发送方继续发送，就会造成丢包，继而引起丢包重传等一系列连锁反应。TCP支持根据接收端的处理能力，来决定发送方的发送速度，这个机制就叫流量控制

6、拥塞控制

滑动窗口的大小取决于流量控制和拥塞控制这两个因素共同决定

🍔流量控制衡量了接收方的数据处理能力
🍔拥塞控制衡量了传输路径的数据处理能力

通过实验的方式，找到一个合适的发送速率，开始的时候，按照一个小的速率发送，如果不丢包，就可以提高速率（扩大窗口大小），如果出现丢包，则立即把速率调小，重复上述过程。要知道，网络的拥堵情况不是一成不变的，每时每刻都在变化，此时拥塞控制这样的策略就能很好的适应变化的网络环境，处于一种动态平衡的状态

7、延时应答

延时应答的效果，就是通过这个延时，让接收方应用程序，趁机多消费点数据，此时反馈的窗口大小，就会更大一丢丢，此时发送方的发送速率就会更快一点

8、捎带应答

基于延时应答

四次挥手，有时候就挥手三次，原因在于捎带应答，不过概率极低

9、面向字节流

对于粘包问题，要如何避免，归根到底就一句话，明确两个包之间的边界

对于定长的包，保证每次都按固定的大小读取即可
对于变长的包，可以在包头位置，约定一个包总长度字段，从而就知道包的结束位置了
对于变长的包，还可以在包与包之间使用明确的分隔符（应用层协议，是程序猿自己来定义的），之前写的回显程序就是这样来处理的

10、异常情况

1.进程关闭 / 进程崩溃

进程没了，socket是文件，随之被关闭，但是连接还在（操作系统内核来控制的），仍然可以四次挥手断开连接

2.主机关机（正常流程关机）

先杀死所有的用户进程，也会触发四次挥手，如果挥完，直接就可以了；如果没有挥完，必比如，对方的FIN过来了，咱们没来得及ACK就关机了，此时对端就会重传FIN，重传几次之后，发现都没有ACK，尝试重新连接，如果还不行，就直接断开连接

3.主机掉电

瞬间机器就关了，来不及进行任何挥手操作

🍔对端是发送方，对端就会收不到ACK->超时重传->重置连接->释放连接

🍔对端是接收方，对端是无法立即知道发送方这边是没来得及发新的数据还是直接就挂了，这时候，TCP内置的心跳包，保活机制就起到了作用，心跳包具有周期性，对端的接收方，会定期给发送方发一个心跳包（ping），发送端返回一个（pong），如果每个ping都有及时的pong，这时候就说明当前对端的状态良好，如果ping过去之后，没有pong与之回应，说明心跳没了，发送方可能挂了

4.网线断开

和主机掉电类似，也会设置一个心跳包

三、TCP/UDP对比

TCP用于可靠传输的情况，应用于文件传输，重要状态更新等场景
UDP用于对高速传输和实时性要求较高的通信领域，另外可以用于广播

UDP特点：

无连接
不可靠
面向数据报
全双工

TCP特点：

有连接
可靠传输
面向字节流
全双工

四、小结

为什么TCP这么复杂？因为既要保证可靠性，同是又要尽可能提高性能

可靠性

校验和
序列号（按序到达）
确认应答
超时重发
连接管理
流量控制
拥塞控制

提高性能

滑动窗口
快速重传
延迟应答
捎带应答

其他

定时器（超时重传定时器，保活定时器，TIME_WAIT定时器）

五、扩展问题（经典面试题）

1、UDP本身是无连接的，不可靠的，面向数据报的协议，如果要基于传输层UDP协议，来实现一个可靠传输，应该如何设计？

2、UDP大小是受限的，如果要基于传输层UDP协议，传输超过64KB的数据，应该如何设计？

以上两个问题很类似，都可以参考TCP的可靠性机制在应用层实现类似的逻辑：

引入序列号，保证数据顺序
引入确认应答，保证对端收到了数据
引入超时重传，每隔一段时间没有应答，就重发数据