UDP与TCP

最新推荐文章于 2024-08-06 08:11:08 发布

Yiiz_go

最新推荐文章于 2024-08-06 08:11:08 发布

阅读量151

点赞数 1

分类专栏：前端面试准备文章标签：前端网络

本文链接：https://blog.csdn.net/qq_23864635/article/details/96862587

版权

前端面试准备专栏收录该内容

5 篇文章 0 订阅

订阅专栏

UDP与TCP

1.UDP 与 TCP 的区别是什么？

UDP 协议 是面向无连接的，不需要在正式传递数据之前先连接起双方。 UDP 协议只是数据报文的搬运工，不保证有序且不丢失的传递到对端，并且UDP 协议也没有任何控制流量的算法，总的来说 UDP 相较于 TCP 更加的轻便。一般可以用于直播、即时通讯、即时游戏等。

TCP 无论是建立连接还是断开连接都需要先需要进行握手。在传输数据的过程中，通过各种算法保证数据的可靠性，当然带来的问题就是相比 UDP 来说不那么的高效。

2.TCP建立连接–三次握手

起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCB。服务器创建完 TCB 后便进入 LISTEN 状态，此时开始等待客户端发送数据。
第一次握手
客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。
第二次握手
服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。
第三次握手
当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

3.为什么 TCP 建立连接需要三次握手，明明两次就可以建立起连接

防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误。
客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求B。此时请求顺利到达服务端，服务端应答完就建立了请求，然后接收数据后释放了连接。
假设这时候连接请求 A 在两端关闭后终于抵达了服务端，那么此时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。但是客户端其实是 CLOSED 的状态，那么就会导致服务端一直等待，造成资源的浪费。

4.TCP断开连接–四次握手

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK。
第一次握手
若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。
第二次握手
B收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。
第三次握手
B如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。
第四次握手
A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃）时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

PS：通过延迟确认的技术（通常有时间限制，否则对方会误认为需要重传），可以将第二次和第三次握手合并，延迟 ACK 包的发送。

4.为什么客户端 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态？

为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。

5.TCP如何解决数据丢包或报文顺序不对的问题？

TCP有ARQ超时重传机制。

一种是停止等待ARQ。
比如说A向B发送一个报文，同时启动定时器，如果超时就重新发送。B如果收到相同序号的报文就会丢弃重新应答。A接受相同序号应答也丢弃。
这种是单个单个传的，效率就比较低，但也不会有那种多个丢包的情况。
另一种，高效一点，连续ARQ。
它用的窗口，A持续发这个窗口内的数据，B累积确认，收到多个后统一应答A，ack标志告诉A，这个序号之前的数据已经收到了。但是如果A收到3个重复的ack，那就说明有失序或丢包的情况，就会启用快速重传/快速恢复。
快速重传TCP taho ，阈值设为当前窗口一半，窗口设为1开始慢开始，重新传送。
快速恢复TCP Remo，机制是窗口减半，阈值为当前窗口，启用拥堵避免。不过，它是重发接收端要的包，接受收到一个Ack就退出，如果丢了很多个包就尬住再3ack触发一遍。
因此快恢复进行了优化——TCP New Reno。它是区别在于它记下了这个发送段的最大序号，并且每次都比对。
比如说1-10，丢包丢了4，7。最大序号就是10。接受方发的ack包是4，发送方发4，接受方收到4，发7。那么发送方就会对比7和10，知道是丢了多个包，发7。接受方收到，发11，发送方收到11后，对比10，比10大就退出快恢复阶段了。