TCP与UDP图文详解

TCP和UDP

一、UDP

1. 什么是UDP

UDP是不可靠的、无连接的、数据报协议。细微的处理它会交给上层的应用去完成。在 UDP 的情况下，虽然可以确保发送消息的大小，却不能保证消息一定会到达。因此，应用有时会根据自己的需要进行重发处理。

UDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况，UDP 也无法进行流量控制等避免网络拥塞行为。此外，传输途中出现丢包，UDP 也不负责重发。甚至当包的到达顺序出现乱序时也没有纠正的功能。如果需要以上的细节控制，不得不交由采用 UDP 的应用程序去处理。

2.UDP数据报首部

头部结构中各部分的作用：

（1）16位源端口号：记录源端口号，在需要对方回信时选用。不需要时可用全0。

（2）16位目的端口号：记录目标端口号。这在终点交付报文时必须要使用到。

（3）长度：UDP数据报的长度（包括数据和首部），其最小值为8B（即仅有首部没有数据的情况）。

（4）校验和：检测UDP数据报在传输中是否有错，有错就丢弃。该字段时可选的，当源主机不想计算校验和，则直接令该字段为全0。当传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给进程。如果接收方UDP发现收到的报文中目的端口号不正确（即不存在对应端口号的应用进程），就丢弃该报文，并由ICMP发送“端口不可达”差错报文交给发送方。

3. UDP的使用场景

UDP 常用于一下几个方面：

1. 包总量较少的通信（DNS、SNMP等）
2. 视频、音频等多媒体通信（即时通信）
3. 限定于 LAN 等特定网络中的应用通信
4. 广播通信（广播、多播）

二、TCP

1.什么是TCP

TCP是可靠的、面向连接的、数据流式协议。流就是指不间断的数据结构，当应用程序采用 TCP 发送消息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP 为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备“流控制（流量控制）”、“阻塞控制”、提高网络利用率等众多功能。

TCP充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在 UDP 中都没有。

此外，TCP 作为一种面向连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。

根据 TCP 的这些机制，在 IP 这种无连接的网络上也能够实现高可靠性的通信（ 主要通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现）。

2. TCP数据报首部

下图表示的是TCP首部的数据格式，默认大小为20 bit：

1).16位的源端口号和目的端口号，我们知道端口号就是标识特定主机上的唯一的进程，而IP地址是来表示标识网络中的不同主机的，这两个源（source）和目的（dst）端口号和IP首部中的源和目的IP地址，则标识互联网上的唯一进程，所以套接字的定义说白了就是IP地址和端口号共同组成。

2).32位的确认序号，上一个字段的序号是对数据的编号，所以确认序号是下一个期望接收的TCP分段号，相当于是对对方所发送的并且已经被本方所正确接受的分段的确认。仅当ACK标志为1时有效。确认号表示期望收到的下一个字节的序号。

3).32位的序号，表示在这个报文段中的第一个数据字节序号。如果将字节流看作在两个应用程序间的单向流动，则TCP用序列号对每个字节进行计数。用来保证到达数据顺序的编号，所以这个字段需要比较大的存储。

4).4位的报头长度，以32位（4字节）字长为单位，需要这个值是因为任选字段的长度是可变的。跟IP头部一样，以4字节为单位。最大是60个字节。不存在任选字段正常的报头长度是20字节。其实相当于给出数据在数据段中的开始位置。

5).保留位，6位，必须为0

6).标志位，占有6个比特位，他们中可以有多个为置为1，依次为：URG，ACK，PSH，RST，SYN，FIN。

下面具体分析：

URG：该位为1说明表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并督促上层应用敢快处理这些数据。

ACK：确认号有效

PSH：接收方应尽快将这个报文交给应用层，叫做push。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队。

RST：连接复位，复位因主机奔溃或其他原因而出现的错误连接，也可以用于拒绝非法的分段或拒绝连接请求，这个用处还是比较多的

SYN：是一个同步序号，通常与ACK合用用来建立连接。也就是常说的三次握手

FIN：既然有建立连接那么必然有拆除连接，这个字段表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

7).紧急指针，只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。

8).窗口大小，TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。这是一个16 bit字段，因而窗口大小最大为65535字节。

9).校验和，用于对分段首部和数据进行校验。正常情况下为一定为0

ACK理解：ack表示期望下次接收到的序号。那么ack是如何算出来的呢，就是通过收到的序号，和数据长度相加得来。假设A收到B过来的数据（seq = 5，len = 15）。len表示数据长度。那么A就会回复B，“刚才的数据我已经收到了，你接下来就发序号为20的包给我吧”。这样就保证了数据不会乱序。综上，确认号就是下一次将要收到包的序号。同时也等于发送方的序号+数据长度（确认号在ACK标志位有效时才有用。)

看到上面，有些人就会有些疑问，URG和PSH都是紧急时使用，那么这两个有什么关系和区别呢？
答：在一般的数据中都会存在PSH，而URG只有在紧急情况下才会触发TCP报文中的紧急指针字段，那么到底什么样的情况才是紧急情况呢？紧急方式是向对方发送紧急数据的一种方式，表示数据需要优先处理。它是一个正的偏移，与TCP首部中序号字段的值相加表示紧急数据后面的字节，紧急指针是数据最后一个字节，TCP首部中只有紧急指针指出紧急数据的位置，它所指的字节为紧急数据，但没有办法指定紧急数据的长度。

3. 三次握手

TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好两端之间的准备工作。

所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发。

下面来看看三次握手的流程图：

seq：占 4 字节，序号范围[0，2^32-1]，序号增加到 2^32-1 后，下个序号又回到 0。TCP 是面向字节流的，通过 TCP 传送的字节流中的每个字节都按顺序编号，而报头中的序号字段值则指的是本报文段数据的第一个字节的序号。

ack：占 4 字节，期望收到对方下个报文段的第一个数据字节的序号。

三次握手:

• 第一次握手：客户端将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器端确认。
• 第二次握手：服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。
• 第三次握手：客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

为什么需要三次握手而不是两次？

握手的两端都有可能发送数据包，发送数据包都有一个序号，通信双方都需要随机产生一个初始的序列号， 并且把这个起始值告诉对方。

4. 四次挥手

四次挥手即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。

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

下面来看看四次挥手的流程图：

中断连接端可以是客户端，也可以是服务器端。

• 第一次挥手：客户端发送一个FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入FIN_WAIT_1状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。
• 第二次挥手：服务器端收到FIN后，先发送ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入FIN_WAIT_2 状态，继续等待服务器端的FIN报文。
• 第三次挥手：当服务器端确定数据已发送完成，则向客户端发送FIN=N报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入LAST_ACK状态。
• 第四次挥手：客户端收到FIN=N报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=N+1后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。服务器端收到ACK后，就知道可以断开连接了。客户端等待了2MSL后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，

具体流程如下图：

5. TCP实现可靠传输的几个方面

5.1 通过序列号与确认应答提高可靠性

在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答（ACK）。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。 反之，则数据丢失的可能性很大 。

在一定时间内没有等待到确认应答，发送端就可以认为数据已经丢失，并进行重发。由此，即使产生了丢包，仍然能够保证数据能够到达对端，实现可靠传输。

未收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到，只是返回的确认应答在途中丢失。这种情况也会导致发送端误以为数据没有到达目的地而重发数据。

此外，也有可能因为一些其他原因导致确认应答延迟到达，在源主机重发数据以后才到达的情况也屡见不鲜。此时，源主机只要按照机制重发数据即可。

对于目标主机来说，反复收到相同的数据是不可取的。为了对上层应用提供可靠的传输，目标主机必须放弃重复的数据包。为此我们引入了序列号。

序列号是按照顺序给发送数据的每一个字节（8位字节）都标上号码的编号。接收端查询接收数据 TCP 首部中的序列号和数据的长度，将自己下一步应该接收的序列号作为确认应答返送回去。通过序列号和确认应答号，TCP 能够识别是否已经接收数据，又能够判断是否需要接收，从而实现可靠传输。

5.2 重发超时的确定

重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。 如果超过这个时间仍未收到确认应答，发送端将进行数据重发。最理想的是，找到一个最小时间，它能保证“确认应答一定能在这个时间内返回”。

TCP 要求不论处在何种网络环境下都要提供高性能通信，并且无论网络拥堵情况发生何种变化，都必须保持这一特性。为此，它在每次发包时都会计算往返时间及其偏差。将这个往返时间和偏差时间相加，重发超时的时间就是比这个总和要稍大一点的值。

在 BSD 的 Unix 以及 Windows 系统中，超时都以0.5秒为单位进行控制，因此重发超时都是0.5秒的整数倍。不过，最初其重发超时的默认值一般设置为6秒左右。

数据被重发之后若还是收不到确认应答，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。

此外， 数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。

5.3 以段为单位发送数据

在建立 TCP 连接的同时，也可以确定发送数据包的单位，我们也可以称其为“最大消息长度”（MSS）。最理想的情况是，最大消息长度正好是 IP 中不会被分片处理的最大数据长度。

TCP 在传送大量数据时，是以 MSS 的大小将数据进行分割发送。进行重发时也是以 MSS 为单位。

MSS 在三次握手的时候，在两端主机之间被计算得出。两端的主机在发出建立连接的请求时，会在 TCP 首部中写入 MSS 选项，告诉对方自己的接口能够适应的 MSS 的大小。然后会在两者之间选择一个较小的值投入使用。

6. 滑动窗口控制

利用窗口控制提高速度

6.1 什么是窗口控制？

TCP 以1个段为单位，每发送一个段进行一次确认应答的处理。这样的传输方式有一个缺点，就是包的往返时间越长通信性能就越低。

窗口控制：

窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。上图中窗口大小为4个段。这个机制实现了使用大量的缓冲区，通过对多个段同时进行确认应答的功能。

为解决这个问题，TCP 引入了窗口这个概念。确认应答不再是以每个分段，而是以更大的单位进行确认，转发时间将会被大幅地缩短。也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送。如下图所示：

6.2 什么是滑动窗口控制？

滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。

只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动，因此这种协议称为滑动窗口协议。当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。

上图中的窗口内的数据即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机需要设置缓存保留这些待被重传的数据，直到收到他们的确认应答。

在滑动窗口以外的部分包括未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓存区清除。

收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也别称为滑动窗口控制。

6.3 滑动窗口的理解

TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。假定发送方设备以每一次三个数据包的方式发送数据，也就是说，窗口大小为3。发送方发送序列号为1、2、3的三个数据包，接收方设备成功接收数据包，用序列号4确认。发送方设备收到确认，继续以窗口大小3发送数据。当接收方设备要求降低或者增大网络流量时，可以对窗口大小进行减小或者增加，本例降低窗口大小为2，每一次发送两个数据包。当接收方设备要求窗口大小为0，表明接收方已经接收了全部数据，或者接收方应用程序没有时间读取数据，要求暂停发送。发送方接收到携带窗口号为0的确认，停止这一方向的数据传输。

我们可以看下面一张图来分析一下固定窗口大小有什么问题。

这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。

我们看看滑动窗口是如何工作的。我们看下面几张图。

首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3(这是发送方发送序列2的回答确认，下一次接收方期望接收到的是3序列信号)。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3个数据开始发。这个时候窗口大小就变成了2。

这个时候发送方发送2个数据。

看到接收方发送的ACK是5就表示他下一次希望收到的数据是5，发送方就知道我刚才发送的2个数据对方收了这个时候开始发送第5个数据。

这就是滑动窗口的工作机制，当链路变好了或者变差了这个窗口还会发生变话，并不是第一次协商好了以后就永远不变了。

6.4窗口控制中的重发控制

在使用窗口控制中， 出现丢包一般分为两种情况：

① 确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的，如下图：

② 某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序列号以外的数据时，会针对当前为止收到数据返回确认应答。如下图所示，当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，因此，**在窗口比较大，又出现报文段丢失的情况下，同一个序列号的确认应答将会被重复不断地返回。**而发送端主机如果连续3次收到同一个确认应答，就会将其对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称为高速重发控制。

7.TCP的可靠性总结

TCP的可靠性体现在：

• 滑动窗口机制
• 3次握手建立连接
• 拥塞避免算法
• 流量控制
• 超时重传机制

参考链接：拥塞避免算法和流量控制

具体实现：

a ) 首先，应用数据被分割成TCP认为最合适发送的数据块。称为段（Segment）传递给IP层。这个第一个步骤。

b）当TCP发出一个段后，它会启动一个定时器，等待目的端确认收到这个报文段。若没有及时收到确认，将重发送这个报文段。

c）当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送的，通常将推迟几分之一秒。

d）TCP将保持它首部和数据的校验和，这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到段的校验和有差错，TCP 将丢弃这个报文也不进行确认（对方就会重复发送了）。

e）TCP承载与IP数据报来传输，而IP数据报可能会失序，因为中间的路由过程可能路线不一致，到达的时间也会有长短，所以TCP的报文段到达时也可能会失序。但是TCP收到数据后会重新排序到正确的顺序（通过序号）。

f）IP数据报会重复报，TCP的接收端会丢弃这些重复包。

g）TCP还能提供流量控制，TCP连接的双方都是有一定大小的存储空间

三、TCP和UDP的使用场景

TCP 和 UDP 的优缺点无法简单地、绝对地去做比较：TCP 用于在传输层有必要实现可靠传输的情况；而在一方面，UDP 主要用于那些对高速传输和实时性有较高要求的通信或广播通信。TCP 和 UDP 应该根据应用的目的按需使用。

本文参考 TCP/IP 卷一