网络编程之快速理解TCP和UDP的差异

Posted 2022-02-05 大忽悠爱忽悠

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了网络编程之快速理解TCP和UDP的差异相关的知识，希望对你有一定的参考价值。

建立连接方式的差异

TCP

说到 TCP 建立连接，相信大多数人脑海里肯定可以浮现出一个词，没错就是–“三次握手”。TCP 通过“三次握手”来建立连接，再通过“四次挥手”断开一个连接。在每次挥手中 TCP 做了哪些操作呢？

流程如下图所示（TCP的三次握手和四次挥手）：

上图就从客户端和服务端的角度，清楚的展示了 TCP 的三次握手和四次挥手。可以看到，当 TCP 试图建立连接时，三次握手指的是客户端主动触发了两次，服务端触发了一次。

我们可以先明确一下 TCP 建立连接并且初始化的目标是什么呢？

1）初始化资源；
2）告诉对方我的序列号。

所以三次握手的次序是这样子的：

1）client端首先发送一个SYN包告诉Server端我的初始序列号是X；
2）Server端收到SYN包后回复给client一个ACK确认包，告诉client说我收到了；
3）接着Server端也需要告诉client端自己的初始序列号，于是Server也发送一个SYN包告诉client我的初始序列号是Y；
4）Client收到后，回复Server一个ACK确认包说我知道了。

其中的 2 、3 步骤可以简化为一步，也就是说将 ACK 确认包和 SYN 序列化包一同发送给 Client 端。到此我们就比较简单的解释了 TCP 建立连接的“三次握手”。

UDP

我们都知道 TCP 是面向连接的、可靠的、有序的传输层协议，而 UDP 是面向数据报的、不可靠的、无序的传输协议，所以 UDP 压根不会建立什么连接。

就好比发短信一样，UDP 只需要知道对方的 ip 地址，将数据报一份一份的发送过去就可以了，其他的作为发送方，都不需要关心。

数据发送方式的差异

关于 TCP、UDP 之间数据发送的差异，可以体现二者最大的不同之处：

TCP：

由于 TCP 是建立在两端连接之上的协议，所以理论上发送的数据流不存在大小的限制。但是由于缓冲区有大小限制，所以你如果用 TCP 发送一段很大的数据，可能会截断成好几段，接收方依次的接收。

UDP：

由于 UDP 本身发送的就是一份一份的数据报，所以自然而然的就有一个上限的大小。

那么每次 UDP 发送的数据报大小由哪些因素共同决定呢？

UDP协议本身，UDP协议中有16位的UDP报文长度，那么UDP报文长度不能超过2^16=65536；
以太网(Ethernet)数据帧的长度，数据链路层的MTU(最大传输单元)；
socket的UDP发送缓存区大小。

先来看第一个因素，UDP 本身协议的报文长度为 2^16 - 1，UDP 包头占 8 个字节，IP 协议本身封装后包头占 20 个字节，所以最终长度为： 2^16 - 1 - 20 - 8 = 65507 字节。

只看第一个因素有点理想化了，因为 UDP 属于不可靠协议，我们应该尽量避免在传输过程中，数据包被分割。所以这里有一个非常重要的概念 MTU -- 也就是最大传输单元。

在 Internet 下 MTU 的值为 576 字节，所以在 internet 下使用 UDP 协议，每个数据报最大的字节数为： 576 - 20 - 8 = 548

数据有序性的差异

我们再来谈谈数据的有序性。

TCP

对于 TCP 来说，本身 TCP 有着超时重传、错误重传、还有等等一系列复杂的算法保证了 TCP 的数据是有序的，假设你发送了数据 1、2、3，则只要发送端和接收端保持连接时，接收端收到的数据始终都是 1、2、3。

UDP

而 UDP 协议则要奔放的多，无论 server 端无论缓冲池的大小有多大，接收 client 端发来的消息总是一个一个的接收。并且由于 UDP 本身的不可靠性以及无序性，如果 client 发送了 1、2、3 这三个数据报过来，server 端接收到的可能是任意顺序、任意个数三个数据报的排列组合。

可靠性的差异

其实大家都知道 TCP 本身是可靠的协议，而 UDP 是不可靠的协议。

TCP

TCP 内部的很多算法机制让他保持连接的过程中是很可靠的。比如：TCP 的超时重传、错误重传、TCP 的流量控制、阻塞控制、慢热启动算法、拥塞避免算法、快速恢复算法等等。所以 TCP 是一个内部原理复杂，但是使用起来比较简单的这么一个协议。

UDP

UDP 是一个面向非连接的协议，UDP 发送的每个数据报带有自己的 IP 地址和接收方的 IP 地址，它本身对这个数据报是否出错，是否到达不关心，只要发出去了就好了。

所以来研究下，什么情况会导致 UDP 丢包：

数据报分片重组丢失：在文章之前我们就说过，UDP 的每个数据报大小多少最合适，事实上 UDP 协议本身规定的大小是 64kb，但是在数据链路层有 MTU 的限制，大小大概在 5kb，所以当你发送一个很大的 UDP 包的时候，这个包会在 IP 层进行分片，然后重组。这个过程就有可能导致分片的包丢失。UDP 本身有 CRC 检测机制，会抛弃掉丢失的 UDP 包；
UDP 缓冲区填满：当 UDP 的缓冲区已经被填满的时候，接收方还没有处理这部分的 UDP 数据报，这个时候再过来的数据报就没有地方可以存了，自然就都被丢弃了。

使用场景总结

在文章最后的一部分，聊聊 TCP、UDP 使用场景。

先来说 UDP 的吧，有很多人都会觉得 UDP 与 TCP 相比，在性能速度上是占优势的。因为 UDP 并不用保持一个持续的连接，也不需要对收发包进行确认。但事实上经过这么多年的发展 TCP 已经拥有足够多的算法和优化，在网络状态不错的情况下，TCP 的整体性能是优于 UDP 的。

那在什么时候我们非用 UDP 不可呢？

对实时性要求高：比如实时会议，实时视频这种情况下，如果使用 TCP，当网络不好发生重传时，画面肯定会有延时，甚至越堆越多。如果使用UDP 的话，即使偶尔丢了几个包，但是也不会影响什么，这种情况下使用 UDP 比较好；
多点通信：TCP需要保持一个长连接，那么在涉及多点通讯的时候，肯定需要和多个通信节点建立其双向连接，然后有时在NAT环境下，两个通信节点建立其直接的TCP 连接不是一个容易的事情，而 UDP 可以无需保持连接，直接发就可以了，所以成本会很低，而且穿透性好。这种情况下使用 UDP也是没错的。

以上我们说了 UDP 的使用场景，在此之外的其他情况，使用 TCP 准没错。

毕竟有一句话嘛：

when in doubt，use TCP。

TCP协议的3次握手与4次挥手过程详解

前言

尽管TCP和UDP都使用相同的网络层（IP），TCP却向应用层提供与UDP完全不同的服务。TCP提供一种面向连接的、可靠的字节流服务。

面向连接意味着两个使用TCP的应用（通常是一个客户和一个服务器）在彼此交换数据之前必须先建立一个TCP连接。这一过程与打电话很相似，先拨号振铃，等待对方摘机说“喂”，然后才说明是谁。

下面将分别讲解经典的TCP协议建立连接（所谓的“3次握手”）和断开连接（所谓的“4次挥手”）的过程。

先来认识TCP报文格式

下面是TCP报文格式图：

上图中有几个字段需要重点介绍下：

1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：

   （A）URG：紧急指针（urgent pointer）有效。
   （B）ACK：确认序号有效。
   （C）PSH：接收方应该尽快将这个报文交给应用层。
   （D）RST：重置连接。
   （E）SYN：发起一个新连接。
   （F）FIN：释放一个连接。

需要注意的是：

A）不要将确认序号Ack与标志位中的ACK搞混了。
B）确认方Ack=发起方Req+1，两端配对。

3次握手过程详解

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

（1）第一次握手：

Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手：

Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

（3）第三次握手：

Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

SYN攻击：

在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

#netstat -nap | grep SYN_RECV

4次挥手过程详解

三次握手耳熟能详，四次挥手估计就少有人知道了。所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。

第一次挥手：

Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

第二次挥手：

Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

第三次挥手：

Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

第四次挥手：

Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：

流程和状态在上图中已经很明了了，在此不再赘述，可以参考前面的四次挥手解析步骤。

小结

关于三次握手与四次挥手通常都会有典型的面试题，在此提出供有需求的XDJM们参考：

1）三次握手是什么或者流程？四次握手呢？答案前面分析就是。
2）为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

UDP中一个包的大小最大能多大

点评

因为UDP数据传输的无连接特性，最简单的UDP数据传输就是一次数据交互一个UDP包搞定，这样就不用管分包问题（因为不像TCP，UDP传输时如果分包则是不能保证顺序的，这会带来很多问题）。所以你一次交互的数据如果太多的话，用UDP实现就很可能并不优雅。

前言

在进行UDP编程的时候,我们最容易想到的问题就是,一次发送多少bytes好？

当然，这个没有唯一答案，相对于不同的系统,不同的要求,其得到的答案是不一样的，我这里仅对像ICQ一类的发送聊天消息的情况作分析，对于其他情况，你或许也能得到一点帮助。

网络原理

首先，我们知道，TCP/IP通常被认为是一个四层协议系统：包括链路层、网络层、运输层、应用层。UDP属于运输层，下面我们由下至上一步一步来看。

结论1：局域网环境下，建议将UDP数据控制在1472字节以下

以太网(Ethernet)数据帧的长度必须在46-1500字节之间,这是由以太网的物理特性决定的，这个1500字节被称为链路层的MTU(最大传输单元)。但这并不是指链路层的长度被限制在1500字节，其实这这个MTU指的是链路层的数据区，并不包括链路层的首部和尾部的18个字节。

所以，事实上这个1500字节就是网络层IP数据报的长度限制。因为IP数据报的首部为20字节，所以IP数据报的数据区长度最大为1480字节。而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的。

又因为UDP数据报的首部8字节，所以UDP数据报的数据区最大长度为1472字节。这个1472字节就是我们可以使用的字节数。

当我们发送的UDP数据大于1472的时候会怎样呢？
这也就是说IP数据报大于1500字节，大于MTU，这个时候发送方IP层就需要分片(fragmentation)。把数据报分成若干片，使每一片都小于MTU，而接收方IP层则需要进行数据报的重组。这样就会多做许多事情，而更严重的是，由于UDP的特性，当某一片数据传送中丢失时，接收方无法重组数据报，将导致丢弃整个UDP数据报。

因此，在普通的局域网环境下，我建议将UDP的数据控制在1472字节以下为好。