网络原理 | UDP协议与TCP协议的对比、相关面试常见问题总结
目录
UDP协议
UDP协议端格式
UDP的特点
TCP协议与UDP协议的对比
相关面试题总结
如何基于UDP协议实现可靠传输？
TCP连接为什么是三次握手而不是两次或四次？
三次握手过程中可以携带数据吗？
为什么要四次挥手而不是三次？
什么是CLOSE_WAIT？
为什么服务端会出现大量的CLOSE_WAIT？
TIME_WAIT状态需要等待多久？为什么？
UDP协议
UDP协议端格式
16位的UDP长度表示整个数据报（UDP首部+UDP数据）的最大长度
如果校验和出错，就直接丢弃
UDP的特点
UDP传输数据的过程类似于寄信，UDP不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。
无连接
知道对端的IP和端口号就可以直接进行传输，无需建立连接
不可靠
UDP协议没有任何的安全机制，发送端发送数据报以后，如果因为网络故障无法到达对方，UDP协议层也不会给应用层返回任何错误信息
面向数据报
应用层交给UDP多长的报文，UDP原样转发，既不会拆分也不会合并.
例如用UDP协议传输100个字节的数据，如果发送端一次性发送100个字节，那接收端也必须一次性接收100个字节的数据，不能每次分十次接收，每次接收10个字节数据
缓冲区
UDP只有接收缓冲区，而没有发送缓冲区
大小受限
UDP协议首部中有一个16位的最大长度，一个UDP能传输的最大数据为64k(包含UDP的首部)
TCP协议与UDP协议的对比
· TCP协议有连接（通过三次握手建立连接，四次挥手释放连接）、是可靠的传输协议(传输数据没有丢失，不会重复) 、面向字节流传输(发送数据时以字节为单位，一个数据报可以拆分成若干组进行发送)、有发送缓冲区和接收缓冲区、传输数据大小不限、TCP协议适用于可靠性比较高的场景，TCP只适用于点对点的传输
· UDP协议无连接、不可靠，面向数据报(一个报文只能一次发送完成)、只有接收缓冲区无发送缓冲区，UDP传输数据大小受限，一次只能传输64k的数据，UDP支持一对一、一对多、多对一、多对多的传输，UDP协议适用于高速传输和实时性要求比较高的通信领域，例如视频通信、直播等等.
相关面试题总结
关于tcp的安全机制、效率机制、三次握手四次挥手在上篇博客中有概述：TCP安全机制、效率机制、三次握手四次挥手
如何基于UDP协议实现可靠传输？
在应用层来实现类似TCP的可靠机制：
①对其引入序列号，以确保数据的顺序
②引入确认应答机制，确保对端接收到数据
③引入超时重传，如果隔一段时间没有应答就重发数据
④对其引入拥塞控制，以确保合理利用带宽，拥塞控制基于慢启动、拥塞避免、快重传、快恢复算法实现.
TCP连接为什么是三次握手而不是两次或四次？
tcp连接的三次握手：
①第一次握手是客户端发送syn，申请建立客户端到服务端的连接
②第二次握手是服务端返回syn和ack，ack是对于第一次握手的确认，syn是服务端申请到客户端的连接
③客户端返回ack，是对于服务端申请连接的确认，至此双方成功建立连接.
①为什么不是两次握手？
原因1：为了防止已失效的连接请求报文段传送到服务端从而产生错误
例如客户端第一次对服务端发送的连接请求因为网络阻塞的原因没有按时到达服务端，此时客户端由于未收到服务端发来的确认报文，就会重新向服务端发送连接请求，此时收到了确认，客户端和服务端经过两次握手完成了连接，传输数据，然后关闭了连接，此时第一次发送的连接请求又到达了服务端，服务端收到这个失效的请求报文段以为是客户端要建立新的连接，就发送了确认报文段，此时新的连接就建立了.但是此时客户端并没有发送建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发出数据，但服务端却以为连接已经建立一直在等待客户端发送数据，服务端的资源就这样浪费了.
如果采取了三次握手，就可以防止上述现象的发生，客户端不会向服务端的确认发出确认，服务端因为没有收到客户端的确认，就知道客户端并没有要求建立连接.
原因2：TCP是双向协议，两次握手只能保证单向连接畅通，只有通过第三次握手，才能保证双向都可以接收到对方发送的数据
第一次握手是客户端向服务端发送连接请求，第二次握手是服务端向客户端发送确认和连接请求，如果只有两次握手，只能建立单向的连接，只有三次握手才能建立双向连接.
②为什么不是四次握手？
第二次握手时可以拆分来发送，先发送ACK确认报文段确认，再发送同步报文段SYN请求连接，这样就成了四次握手.
三次握手过程中可以携带数据吗？
第一次握手和第二次握手不能，第三次握手可以.
如果第一次握手可以携带数据的话，如果有人要恶搞服务器，每次都在第一次握手的SYN报文中存放大量的数据，然后一直发送SYN报文，这会让服务器花费很多时间、内存空间来接收这些报文.
但第三次握手时，此时客户端已经完成了客户端到服务端的连接，它已经知道了服务端的接收、发送能力是正常的，所以能正常发送/携带数据.
为什么要四次挥手而不是三次？
由于TCP的半关闭特性，TCP连接提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力.
任何一方都可以在数据传输结束后发出释放连接的通知，待对方确认后进入半关闭状态.当另一方也没有数据再发送时，就会发送连接释放的通知，对方确认后就完全关闭了连接.
例如：A向B发送FIN，A再收到B的确认ACK就是两次网络传输了，B发送FIN，再收到A的确认ACK也是两次网络传输.
其实三次挥手并不是不能断开连接，因为TCP的半关闭特性，所以需要四次.例如A向B发送FIN请求关闭连接，B收到后发送确认，这个时候A不会再发送数据，但是如果B发数据给A，A还是要接受的，等到B发送数据结束后，再给A发送连接释放报文，A再发送确认，所以是四次挥手而不是三次，B对A发送确认和B对A发起释放不能合在一起发送.
什么是CLOSE_WAIT？
CLOSE_WAIT是被动关闭连接形成的，服务端在收到客户端发送的FIN，对客户端发出确认后就进入了CLOSE_WAIT状态
为什么服务端会出现大量的CLOSE_WAIT？
服务端没有执行close方法，因为执行close方法才会发送第三个数据报，因此导致了四次握手不能完成.
TIME_WAIT状态需要等待多久？为什么？
客户端在接收到第三个数据报之后就会进入TIME_WAIT状态，需要等待2msl.1个msl是单个TCP报文传输的最大时间.
等待2msl是为了保证两个在传输方向上尚未被接收或迟到的报文段都已经消失，也可以保证最后一个报文段可靠到达(也就是说需要等待的是第四次握手返回的数据报以及可能重传的数据).