TCP UDP详解

TCP UDP协议

1. 概述

TCP、UDP协议是TCP/IP体系结构传输层中的两个重要协议。

如图所示为计算机网络四层模型：

**IP协议**是网际层中的核心协议，它可以互联不同的网络接口，并向其上层提供无连接、不可靠的数据传输服务。

TCP/IP体系结构的应用层中包含许大量的应用层协议，其中有些应用层协议需要使用可靠传输服务，例如浏览网页、传输文件等，这些数据一旦传输失败会造成无法挽回的危害。而有些则需要使用不可靠传输服务，例如音视频通话等，少量的数据传输错误并不会对播放造成大影响。

由于应用层需要使用可靠和不可靠两种传输服务，但IP协议只能提供不可靠传输服务，于是就需要传输层来提供可靠/不可靠的传输服务。

其中TCP提供可靠性传输服务，UDP提供不可靠传输服务。

TCP ：Transmission Control Protocol，传输控制协议，为上层提供的是面向连接的可靠的数据传输服务。使用TCP通信的双方，在传送数据之前必须首先建立TCP连接（逻辑连接，而非物理连接）。数据传输结束后必须要释放TCP连接。TCP为了实现可靠传输，就必须使用很多措施，例如TCP连接管理、确认机制、超时重传、流量控制、拥塞控制等。TCP的实现复杂，报文首部较大，占用处理机资源比较多。

UDP ：User Datagram Protocol，用户数据报协议，为其上层提供的是无连接的不可靠的数据传输服务，因此不需要实现可靠传输的各种机制。使用UDP通信的双方，在传送数据之前不需要建立连接。UDP的实现简单，用户数据报首部比较小。

2. 端口号 复用 分用

端口号 ：运行在计算机上的进程使用进程标识符PID来区分，但是因特网上的计算机使用操作系统复杂，不同的操作系统又有不同格式的进程标识符，为了使运行在不同操作系统的计算机的应用进程之间能够进行通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识，而这个标识方法就是**端口号**，运输层使用端口号来区分应用层的不同应用进程。端口号只具有本地意义，即端口号只是为了标识本计算机应用进程，在因特网中，不同的计算机中的相同端口没有联系，你电脑上的8080端口跟我电脑上的8080端口一点关系没有。

发送方的复用 ：应用层报文经过传输层TCP协议进行封装，称为TCP复用。应用层报文经过传输层UDP协议封装，称为UDP复用。传输层的报文经过网络层IP协议的封装，称为IP复用

接收方的分用：网络层使用IP协议解析接受的IP数据报，称为IP分用。传输层使用TCP协议解析接受的TCP数据报，称为TCP分用。传输层使用UDP协议解析接受的UDP数据报，称为UDP分用。

‍

3. TCP

3.1 TCP首部格式

TCP协议处于传输层，它向上层（应用层）提供面向连接的可靠传输服务，为了实现可靠传输，采用了**面向字节流**的方式。

TCP在发送数据时从发送缓存中取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后在发送给下层。一个TCP报文段由首部和数据载荷两部分组成，TCP实现连接管理、确认机制、超时重传、流量控制、拥塞控制这些功能都体现在它首部中各字段的作用。

TCP首部由两部分构成 ：20字节的固定首部和最大40字节的扩展首部。也就是说，一个TCP首部的字节数在20~60字节之间。

源端口 ：16比特，即两字节，写入源端口号，用于标识发送该TCP报文段的应用进程。

目的端口 ：16比特，即两字节，写入目的端口号，用于标识接受该TCP报文段的应用进程。

假如我们使用web服务127.0.0.1:8080远程访问MySQL服务器48.104.60.218:3306；源端口就是我们自己的IP地址中的端口8080，目的端口就是MySQL服务器的IP地址中的端口3306。

接下来看看与TCP实现可靠性传输有关的三个字段 ：序号、确认号、ACK。

序号 ：占32比特，取值范围[0, 2^32 - 1]，序号增加到最后一个后，下一个序号就又回到0。序号的值用来指出本TCP报文段**数据载荷**第一个字节的序号。如图所示，首部的序号即为数据载荷第一个字节的序号122。

确认号 ：占32比特，取值范围[0, 2^32 - 1]，确认好增加到最后一个后，下一个确认好又回到0。确认号的值用于指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。可以这样理解：若确认号为n，则代表之前已经成功接收到序号为n-1的报文段，下一次期望收到序号为n的报文段。只有ACK标识的值为1时，确认号字段才有效。

ACK ：确标志位，取值为1时确认号才有效；取值为0时确认号无效。TCP规定，连接建立后所有的TCP报文段都必须把ACK置为1。

如图，客户端向服务端发送一个TCP数据报，序号为200代表此数据报的数据载荷部分的第一个字节的序号为200。确认号为800代表客户端已经收到服务端发送的序号为799号以及之前的数据报，现在想要序号为800的数据报。ACK的值为1保证确认号有效。数据载荷长度代表此次传输的字节数。也就是说，此次传输的数据载荷部分的序号为 200 - 300。

数据偏移 ：占4比特，并以4字节为单位。用于指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远。这个字段实际上是指出了TCP报文段的首部有多少个字节。同时，它的值是首部字节数除以4的。首部的字节数范围为：20 ~ 60，所以数据偏移字段的值范围为 5~15，即 0101到1111。

保留 ：占6比特，保留以后使用。目前值为0。

窗口 ：占16比特，以字节为单位。指出发送本报文段的一方的接收窗口。窗口值作为接收方让发送方设置其发送窗口的依据。这是以接收方的接受能力来控制发送方的发送能力，称为流量控制。需要注意的是，发送窗口的大小还取决于拥塞窗口的大小，也就是从接收窗口和拥塞窗口中取最小值。

校验和 ：占16比特，用于检查整个TCP报文段在传输过程中是否出现了误码。

紧急指针 ：占16比特，以字节为单位，用来指明紧急数据的长度。当发送方有紧急数据时，可将紧急数据插队到发送缓存的最前面，并立刻封装到一个TCP报文中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。

SYN ：同步标志位，在TCP连接建立时用来同步序号。TCP规定，SYN值为1时代表正在建立连接，此报文段不能携带数据。

FIN ：终止标志位，用于释放TCP连接。TCP规定，FIN值为1时代表正在释放连接，此报文段不能携带数据。

RST ​：复位标志位，用于复位TCP连接。当RST为1时，表示TCP连接出现了异常，此时必须先断开连接，再重新建立连接。RST还用来拒绝非法报文段或拒绝TCP连接。

PSH ​：推送标志位，用来实现推送操作。当接受方收到该标志位为1的报文段会尽快上交应用进程，而不必等到接收缓存都填满后再向上交付。

URG ：紧急标志位，与紧急指针字段共同实现紧急操作。紧急标志位URG为1时，紧急指针有效，为0时紧急指针无效。

选项 ：选项中的字段都是可选值，扩展功能。选项的字节数可变

填充 ​：由于选项的字节数可变，那就使用填充字段确保报文段首部能被4整除。假如选项有3字节，那么填充就只有1个字节。

为什么一定要确保首部字节数要能被4整除？因为数据偏移字段的值是首部字节数除以4。

3.2 建立连接-三次握手

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。TCP运输连接的建立和释放是每一次面向娘连接的通信中必不可少的过程。

TCP运输连接分为以下三个阶段：

1. 通过三次握手建立TCP连接
2. 进行数据传输
3. 通过四次挥手断开TCP连接

先来介绍一下TCP连接的建立 ：三报文握手

最初，TCP客户端与TCP服务端的TCP进程都处于关闭状态，即CLOSED。

一开始，TCP服务端先创建TCP传输控制块，用于存储TCP连接中的以下重要信息，例如TCP连接表、指向发送和接受缓存的指针、指向重传队列的指针…TCP服务端创建传输控制块后就进入监听状态（LISTEN）等待接受TCP客户端的连接请求。

TCP客户端在发起连接请求之前也要创建传输控制块，之后发起连接请求。

第一次握手 ：

TCP客户端进程向TCP服务端进程发送TCP连接请求报文段，并进入同步已发送状态（SYN-SEND）。

此连接请求报文段首部中的值：

• SYN ：1，表明这是一个TCP连接请求报文段。同时规定此时的报文段不能携带数据。

• 序号(seq) ：初始值x

第二次握手 ：

TCP服务端接收到请求连接报文后，如果同意连接，会向TCP客户端发送 连接请求确认报文段，并进入同步已接受状态（SYN-RCVD）。

该报文段首部中的值：

• SYN ：1，表明现在正在进行TCP连接。同时规定此时的报文段不能携带数据。

• ACK ：使确认号生效。

• 确认号(ack) ：由于客户端发送的序号为x，那么确认号就是x+1，代表“我已经收到序号为x以及之前的数据了，你下次给我发x+1吧”。

• 序号(seq) ：初始值y。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4nZdkdLy-1678504984186)(assets/image-20230308181233-f7ep57n.png)]​

第三次握手 ：

TCP客户端收到连接请求确认报文段后，还需要向TCP服务端进程发送一个**普通的TCP确认报文段，并进入连接已建立状态（ESTABLISHED）。由于是一个普通**的连接建立报文段，所以它的SYN字段值并不为1，所以这个报文段可以携带数据，但是它不携带数据。

（TCP规定，SYN为1的报文段不能携带数据，报文段发送时消耗一个序号。SYN不为1的报文段可以携带数据，如果不携带数据，不消耗序号）

该报文段的首部值：

• ACK ：1，保证确认位可用。
• 序号(seq) ：x+1，因为TCP服务端上次发的报文中的确认号为x+1。由于SYN值不为1，并且没有携带数据，故x+1这个序号下次还能用，也就是建立连接后还可以再使用一次x+1这个序号。
• 确认号(ack) ：y+1，因为TCP服务端上次发送的报文段的序号为y，所以我们这次发送y+1，表示我们已经接收到了序号y以及之前的数据，下次我们想要序号为y+1的数据。

当TCP服务端接收到TCP客户端第二次报文时，服务端也进入连接已建立状态（ESTABLISHED）。

现在，双方都已进入连接建立状态，可以根据已经建立好的TCP连接进行可靠的数据传输。

那么为什么建立TCP连接一定需要三次呢？为什么不能是两次？为什么不能使用两次报文握手建立连接呢？

接下来看看两报文握手会出现的问题 ：

TCP客户端发出请求连接报文，但是因为网络问题长时间停滞在网络中，于是触发超时重传机制，TCP客户端重新发起TCP连接请求报文段，这次成功建立连接。之后便是数据的传输，最后数据传输完成，服务端与客户端断开连接。

断开连接后突然，上次因为网络问题滞后的TCP连接请求发送到了TCP服务端，服务端以为客户端想要再次建立TCP连接，于是服务端进入监听（LISTEN）状态并向客户端发送连接请求确认报文，但是客户端此时为关闭状态，对连接请求确认报文不予理睬，于是服务端一直处于监听状态并发送连接请求确认报文。这就造成了TCP服务端资源的浪费。

综上所述，采用三报文握手而不是两报文握手是为了防止已失效的连接请求报文段突然传送到了TCP服务端因而导致的错误。

3.3 释放连接-四次挥手

TCP通过四次挥手来结束TCP的连接。

在断开连接之前，客户端与服务端都处于连接已建立状态（ESTABLISHED）。

第一次挥手 ：

TCP客户端会发送TCP连接释放报文段，进入终止等待1状态（FIN-WAIT-1）。TCP连接释放报文段的字段值为：

• FIN ：1，代表此时正在释放TCP连接，此报文段不能携带数据。
• ACK ：使确认号生效。
• seq(序号) ：u，代表此报文段的数据载荷的第一个字节的序号为u。
• ack(确认号) ：v，代表已经收到序号为v-1的数据，下次想要序号为v的数据。

​

第二次挥手 ：

服务端接收到客户端发送的TCP连接释放报文段后，会向客户端发送一个普通的TCP确认报文段，并进入关闭等待状态（CLOSE-WAIT）。

（此时的TCP连接进入了半关闭状态，因为客户端到服务端的TCP连接进入关闭状态，因为客户端已经没有数据要发送了；但是服务端到客户端的TCP连接通道还没关闭，因为服务端要继续发送那些还未发送完毕的数据。）

此报文段的字段值 ：

• ACK ：1，保证确认号有效
• 序号(seq) ：v，代表此报文段的数据载荷的第一个字节的序号为v。
• 确认号(ack) ：u+1，代表已经收到客户端发送的第u条数据，下次想要u+1。

TCP客户端收到TCP服务端发送的TCP确认报文段后就会进入终止等待2状态（FIN-WAIT2）。

​​

第三次挥手 ：

当TCP服务端所有剩余数据发送完毕后，TCP服务端会发送TCP连接释放报文段，并进入最后确认状态（LAST-ACK）。

该报文段的字段：

• FIN ：1，表示正在释放连接。
• ACK ：1，保证确认号有效。
• 序号(seq) ：w，为什么不是v+1？因为第二次挥手之后可能传输了其他剩余数据报。
• 确认号(ack) ：u+1。为什么是u+1？不是又发送了剩余数据吗？因为剩余数据报只是服务端向客户端发送，客户端向服务端的TCP连接通道已经断开。

​

第四次挥手：

收到服务端发送的TCP连接释放报文段后，客户端发送普通的确认报文段，之后进入时间等待状态（TIME-WAIT）。

收到该报文段后，服务端关闭。处于时间等待状态2MSL(2mins)后，客户端TCP连接关闭。

该报文字段值 ：

• ACK ：1，保证确认号有效
• 序号(seq) ：u+1
• 确认号(ack) ：w+1

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u0RBO0Rt-1678504984188)(assets/image-20230309151435-5c57p7p.png)]​

为什么客户端还要等待两分钟再关闭TCP连接呢？

假如不进行等待而直接关闭，也就是客户端发送第四次挥手之后立即关闭TCP连接。那么如果最后一个确认报文丢失，此时客户端已经关闭，但服务端还在等待最后的确认保报文，一直没等到就会触发超时重传机制发送第三次挥手报文，但是客户端已经关闭，那么服务端就会一直发送第三次挥手报文，非常浪费资源。而等待两分钟就可以解决这个问题，客户端有足够时间等待服务端发送的超时重传报文。

​

至此，四报文挥手过程完毕。

接下来看看保活计时器 ：

在客户端与服务端建立连接后，如果客户端出现故障，应当有措施让服务端主动断开连接而不是一直等待下去。这时就要使用到保活计时器。

• TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器(定时2小时)。
• 若2小时内没接收到TCP客户端发送的数据，则当保活计时器到时后，TCP服务器向TCP客户端发送一个探测报文段，以后则每75秒发送一次，若连续10个报文段都无响应，TCP服务端主动断开TCP连接。

3.4 TCP流量控制

为什么需要流量控制？一般来说，我们更加希望传输速度越快越好，但是如果发送方发送数据的速度过快，会导致接受方来不及接收，这就会造成数据的丢失。

所以流量控制就是为了让发送方发送的速率不要太快，要让接受方来得及接收。

TCP的流量控制是通过滑动窗口来实现的。如果此时A向B传输数据，在传输数据前B告诉A：我的接收窗口rwnd=400(receiver window)。这表示 ：发送方A的发送窗口不能超过接受方B的接收窗口的值，也就是400字节。

假如B最初的接收窗口大小为400，那么A可以发送400字节的数据。B接收400字节数据并发送确认后，这400字节的数据会先从A的发送缓存中删除。现在A成功向B发送了400字节的数据，但是B的接收缓存没多少空间了，于是B对A说：我的接收窗口为rwnd=300。这表示发送方A的发送窗口不能超过300字节。就这样，如果发送后B的发送缓存还没腾出空间，会继续减小接收窗口直到B的发送缓存没有空间，这时B向A发送的rwnd=0，即零窗口通知，代表不要再发送数据了，等我腾出空间再说吧。

如果A发送的数据丢失怎么办呢？

A给B发送消息，如果数据丢失，并不会影响A后续数据的发送，B发送的ack消息会告诉A哪些数据还没有发送，到时A重新发送即可。

如果B发送的rwnd丢失怎么办呢？

如果B发送给A的rwnd丢失，A一直在等待B发送的窗口通知(rwnd)以便设置自己的发送窗口，而主机B以为A已经接收到窗口通知，他就一直等待A发送的数据，这就会造成死锁的局面。为了解决这个问题，TCP为每一个连接设置一个持续定时器。

如果B给A发送零窗口通知，持续计时器会重新计时，当持续计时器超时时，证明已经很久没有收到零窗口通知了，A就给B发送一个探测报文，B接收该报文后，将自己的接收窗口值发送给A，如果此值为0，则持续计时器重新计时；如果此值为其他值，A将其发送窗口大小设置为此值。于是死锁问题得以解决。

3.5 TCP拥塞控制

拥塞 ：对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏。这种情况叫做拥塞（congestion）。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

TCP对拥塞控制提供了四种算法 ：

1. 慢开始（slow-start）
2. 拥塞避免（congestion avoidance）
3. 快重传（fast retransmit）
4. 快恢复（fast recovery）

为了简单起见，我们假设发送方A，接收方B，A只发送数据报，B只发送确认报。并且接收方的接收窗口足够大，此时发送方的发送窗口就只受拥塞控制的影响。

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。

• 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些。网络出现拥塞，拥塞窗口就减小一些。
• 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文段（即发生超时）

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。

具体的拥塞控制可以参考 ：https://juejin.cn/post/6844903664566403085

实在是讲不出来