
TCP:提供了可靠、面向连接的传输,适用于需要数据完整性和顺序的场景
UDP:提供了更轻量、面向报文的传输,适用于实时性要求高的场景
区别总结:
对比项 | TCP | UDP |
|---|---|---|
连接方式 | 面向连接(三次握手、四次挥手) | 无连接(直接发) |
是否可靠 | ✔ 保证可靠、有序、不丢包 | ❌ 不保证 |
性能 | 慢(需要确认、重传) | 快(无握手、无重传) |
是否有头部 | 20~60 字节 | 8 字节 |
适合数据大小 | 大 | 小 |
传输方式 | 字节流 | 报文(Datagram) |
是否有流量控制 | ✔ 有(滑动窗口) | ❌ 无 |
是否有拥塞控制 | ✔ 有 | ❌ 无 |
是否可广播 | ❌ 不支持 | ✔ 可广播、多播 |
常用场景 | HTTP、FTP、数据库通信 | 视频、直播、游戏、物联网 |
三次握手主要是为了确定双方都有接收和发送的能力
简要步骤:
TCP 三次握手图示:
客户端首先发送一个同步序列号(SYN)消息给服务器,服务端回复一个SYN-ACK消息,最后客户端再发送一个ACK确认消息给服务端,确认已经收到服务端发来的SYN-ACK消息

步骤解释:
主要有两个原因:
因为网络请求比较复杂,发送方第一次发送请求后,可能由于网络原因被阻塞住了,此时发送方可能又会再次发送请求。
1)如果只有两次握手,那么接收方对于发送方的请求只能接受或者拒绝,同时接收方无法识别发送方发送的这个请求是旧的还是新的请求,如下图所示:

2)如果网络阻塞时间较长,发送方可能多次发送请求,且接收方还可能全部接受这些连接(它不清楚,以为都是有效的),这就造成了不必要的资源浪费。

因此三次握手,多了一次发送方确认接收方接受的连接是否争取的验证过程,所以避免了历史重复连接的错误情况。
因为网络本身不稳定,可能会导致:
然而,因为TCP是一个可靠的传输协议,可以保证数据在传输过程不丢失且有序,所以对于上述问题在TCP中引入序列号,使得:
序列号是有序的,因此在通信过程中,需要同步序列号,那么如何同步?

中间一步合并的优点在于:接收方告知发送方收到序列号的同时还可以把自己的序列号告知发送方
四次挥手主要目的为了确保数据全部传输完成
简要步骤:
TCP 四次挥手图解:

Client 进入**TIME_WAIT**是为保证所有数据安全接受,防止延迟的FIN包影响新连接的完整性,避免出现混淆问题。
主要是为了确保数据完整性
TCP 是一个全双工协议,也就是说双方都要关闭,每一方都向对方发送 FIN 和回应 ACK。
客户端发起连接断开,代表客户端没数据要发送的,但是服务器可能还有数据没有返回给客户端。
就像我对你说数据发完了,你收到之后回复说好的收到,然后你再对我说你数据发完了,我收到之后也回复你说好的收到。这样才能保证数据不会丢失
如果我说数据发完了,你收到之后说确认收到,但不说数据是否发完了,那我收到确认之后就会离开,而你的还没发完的数据就发不了了,那就会造成数据不完整性
一个FIN+ACK 代表一方的数据发送完了,我们有两个端就需要两个 FIN+ACK,也就是四次通信
可以,不一定都是四次,也可以是三次。
主要发生在:
如果 Client 发送 FIN 给 Server 的时候 Server 已经没有数据发送给 Client,那么Server 就可以将 FIN 和 ACK 一起发送给 Client 了,那么四次挥手就可以变成三次挥手。

The end......
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。