TCP和UDP协议的区别和原理最近重新认识了TCP和UDP的原理和区别，简单总结一下。一、功能首先，tcp和udp都工作在传输层，用于程序间传输数据。数据一般包括：文件类型、视频类型、jpg图片等。第二，区别在于TCP是基于连接的，而UDP是非连接的。tcp传输数据稳定可靠，适用于对网络通信质量要求高的场景。需要准确传输给对方，比如传输文件、发送邮件、浏览网页等，udp的优点是速度快，但是可能会出现丢包的情况，因此适用于对实时性要求高但又不需要少量丢包的场景。例如：域名查询、语音通话、视频直播等。udp还有一个很重要的应用场景就是隧道网络。例如：VXLAN以人与人之间的通信为例：UDP协议相当于给对方写了一封信。信寄出后，无法知道对方是否收到了信。内容是否完整，你是无法得到及时反馈的，而TCP协议就像电话沟通一样，在这一系列过程中你都能得到及时反馈，并能保证对方及时收到。如下图所示：3.TCP通信的过程：tcp是如何保证以上过程的？分为三步：三路握手、传输确认、四路挥手。三向握手是建立连接的过程。四、三次握手：客户端向服务器发起连接时，会先发送一包连接请求数据，问过去，能不能和你建立连接？这个数据包称为SYN数据包。如果对端同意连接，它会回复一个SYN+ACK包。客户端收到后，会发一包ACK包，连接就建立了，因为这个过程中要互相发送三包数据。所以称为三次握手。为什么是三次握手而不是两次握手？这是为了防止由于无效的请求消息而突然将错误发送到服务器。这是什么意思？假设使用双向握手建立连接，客户端向服务器发送syn包请求建立连接。由于一些不明原因，没有到达服务器，中间某个网络节点卡住了。客户端为了建立连接，会重新发送syn包，此时数据包正常投递，服务端发送syn+ack后连接建立。但是被第一个数据包阻塞的网络突然恢复，第一个syn包被发送到服务器。这时服务器会认为客户端发起了新的连接，所以在两次握手后进入等待数据状态，服务端认为是两次连接，而客户端认为是一次连接，导致不一致的状态。如果服务器在三次握手过程中收不到最终的ack包，自然不会认为连接建立成功。所以三次握手本质上是为了解决网络通道不可靠的问题。为了在不可靠的通道上建立可靠的连接，经过三次握手后，客户端和服务器都进入数据传输状态。5.数据传输数据传输：一个数据包可能被拆分成多个数据包进行传输，如何处理丢包问题，这些数据包到达的顺序不同，乱序问题如何处理？针对这些问题，tcp协议为每个连接建立了一个发送缓冲区。连接建立后第一个字节的序号为0，以后每个字节的序号都会加1。发送数据时，从数据缓冲区中取出一部分数据，组成发送报文。序列号和长度会附在tcp协议头中。接收端收到数据后，需要回复确认信息。确认报文中的ack等于接收到的序号加上长度，也是下一个包数据传输的起始序号。这种一问一答的发送方式可以让发送方确认发送的数据已经被对方收到。发送方也可以一次发送连续的多包数据。接收方只需要回复一个ack即可。如图：六次或四次挥手：处于连接状态的客户端和服务端都可以发起连接关闭请求，需要四次挥手才能关闭连接。假设client发起关闭连接的请求，向server发送一个FIN包，表示要关闭连接，进入terminationwaiting1filling。服务端收到FIN包后发送ACK包，表示进入关机等待状态，客户端进入终止等待2状态，这是第二次挥手，此时服务端还可以发送未发送的数据，并且客户端还可以接受数据，服务器发送数据后，发送一包FIN包，最后进入确认状态。这是第三波。客户端收到ACK包后，恢复ACK包，进入超时等待状态。超时后关闭连接，服务器收到ACK包后立即关闭连接。这是第一次挥手四次。为什么客户端等待超时？这是为了保证对方已经收到ACK包，因为假设客户端在发送完最后一个ACK包后就释放了连接。一旦ACK包在网络中丢失，服务器将停留在最终确认状态。如果等待一段时间，此时服务器会因为没有收到ack包而重新发送FIN包，客户端会响应FIN包重新发送ack包并刷新超时时间。这个机制和第三次握手是一样的。也是为了在不可靠的网络链路中保证可靠的连接断开确认。7、UDP协议udp：首先，udp协议是非连接的。发送数据就是封装一个简单的数据包，然后从网卡中发送出去。数据包之间没有状态连接，由于udp的处理方式简单导致性能损失非常小。对于cpu来说，内存资源占用比tcp小很多。但是udp不能保证网络传输过程中不丢包，所以udp在传输稳定性上弱于udp。TCP。因此，tcp和udp的主要区别：tcp传输数据稳定可靠，适用于对网络通信质量要求高的场景，需要准确传输给对方。比如传输文件，发送邮件，浏览网页等。UDP的优点是速度快，但是可能会丢包，所以适合对实时性要求高，但丢包要求不高的场景。比如：域名查询、语音通话、视频直播等。udp还有一个很重要的应用场景就是隧道网络，比如：VXLAN。来源：https://blog.csdn.net/weixin_...
