计算机网络 tcp和udp

一、TCP

建立连接-TCP 三次握手

1）什么是半连接队列和全连接队列？

2）为什么要三次握手?

3）三次握手过程中可以携带数据吗？

断开连接-TCP 四次挥手

1）为什么要四次挥手？

2）为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？

3）如果第二次挥手时服务端的 ACK 没有送达客户端，会怎样？

4）为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？

TCP 如何保证传输的可靠性？

TCP 如何实现流量控制？

TCP 的拥塞控制是怎么实现的？

ARQ 协议了解吗?

1. 停止等待 ARQ 协议

2. 连续 ARQ 协议

超时重传如何实现？超时重传时间怎么确定？

二、UDP

UDP的特点

UDP的缓冲区

三、TCP 与 UDP的区别

1）连接性

2）可靠性

3）速度和效率

4）数据包大小

5）适用场景

在计算机网络中，UDP（用户数据报协议）和TCP（传输控制协议）是传输层最为核心的两种协议。它们各自具有独特的特点和优势，适用于不同的应用场景。本文将详细探讨UDP与TCP之间的区别，帮助读者更好地理解这两种协议，并在实际应用中做出合适的选择。

一、TCP

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。它是因特网协议族（TCP/IP协议族）中最为核心的传输协议之一，为许多应用程序提供可靠的数据传输服务。

TCP协议的主要特点包括面向连接、可靠传输、顺序控制、流量控制和拥塞控制等。这些特点确保了TCP在数据传输过程中的高可靠性和稳定性。

建立连接-TCP 三次握手

建立一个 TCP 连接需要“三次握手”，缺一不可：

一次握手：客户端发送带有 SYN（SEQ=x）标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务端的确认；
二次握手：服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态；
三次握手：客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务端都进入ESTABLISHED 状态，完成 TCP 三次握手。

当建立了 3 次握手之后，客户端和服务端就可以传输数据啦！

1）什么是半连接队列和全连接队列？

在 TCP 三次握手过程中，Linux 内核会维护两个队列来管理连接请求：

半连接队列（也称 SYN Queue）：当服务端收到客户端的 SYN 请求时，此时双方还没有完全建立连接，它会把半连接状态的连接放在半连接队列。
全连接队列（也称 Accept Queue）：当服务端收到客户端对 ACK 响应时，意味着三次握手成功完成，服务端会将该连接从半连接队列移动到全连接队列。如果未收到客户端的 ACK 响应，会进行重传，重传的等待时间通常是指数增长的。如果重传次数超过系统规定的最大重传次数，系统将从半连接队列中删除该连接信息。

这两个队列的存在是为了处理并发连接请求，确保服务端能够有效地管理新的连接请求。另外，新的连接请求被拒绝或忽略除了和每个队列的大小限制有关系之外，还和很多其他因素有关系，这里就不详细介绍了，整体逻辑比较复杂。

2）为什么要三次握手?

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常。
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常。
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常。

三次握手就能确认双方收发功能都正常，缺一不可。

3）三次握手过程中可以携带数据吗？

在 TCP 三次握手过程中，第三次握手是可以携带数据的（客户端发送完 ACK 确认包之后就进入 ESTABLISHED 状态了），也就是说，一旦完成了前两次握手，TCP 协议允许数据在第三次握手时开始传输。

如果第三次握手的 ACK 确认包丢失，但是客户端已经开始发送携带数据的包，那么服务端在收到这个携带数据的包时，如果该包中包含了 ACK 标记，服务端会将其视为有效的第三次握手确认。这样，连接就被认为是建立的，服务端会处理该数据包，并继续正常的数据传输流程。

断开连接-TCP 四次挥手

断开一个 TCP 连接则需要“四次挥手”，缺一不可：

第一次挥手：客户端发送一个 FIN（SEQ=x）标志的数据包->服务端，用来关闭客户端到服务端的数据传送。然后客户端进入 FIN-WAIT-1 状态。
第二次挥手：服务端收到这个 FIN（SEQ=X）标志的数据包，它发送一个 ACK （ACK=x+1）标志的数据包->客户端。然后服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
第三次挥手：服务端发送一个 FIN (SEQ=y)标志的数据包->客户端，请求关闭连接，然后服务端进入 LAST-ACK 状态。
第四次挥手：客户端发送 ACK (ACK=y+1)标志的数据包->服务端，然后客户端进入TIME-WAIT状态，服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后客户端也可以关闭连接了。

只要四次挥手没有结束，客户端和服务端就可以继续传输数据！

1）为什么要四次挥手？

TCP 是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

第一次挥手：A 说“我没啥要说的了”
第二次挥手：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
第三次挥手：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
第四次挥手：A 回答“知道了”，这样通话才算结束。

2）为什么不能把服务端发送的 ACK 和 FIN 合并起来，变成三次挥手？

因为服务端收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务端到客户端的数据传送。

3）如果第二次挥手时服务端的 ACK 没有送达客户端，会怎样？

客户端没有收到 ACK 确认，会重新发送 FIN 请求。

**4）为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？**

第四次挥手时，客户端发送给服务端的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。

MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。

TCP 如何保证传输的可靠性？

基于数据块传输：应用数据被分割成 TCP 认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
重传机制 : 在数据包丢失或延迟的情况下，重新发送数据包，直到收到对方的确认应答（ACK）。TCP 重传机制主要有：基于计时器的重传（也就是超时重传）、快速重传（基于接收端的反馈信息来引发重传）、SACK（在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了）、D-SACK（重复 SACK，在 SACK 的基础上，额外携带信息，告知发送方有哪些数据包自己重复接收了）。
流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（TCP 利用滑动窗口实现流量控制）。
拥塞控制 : 当网络拥塞时，减少数据的发送。TCP 在发送数据的时候，需要考虑两个因素：一是接收方的接收能力，二是网络的拥塞程度。接收方的接收能力由滑动窗口表示，表示接收方还有多少缓冲区可以用来接收数据。网络的拥塞程度由拥塞窗口表示，它是发送方根据网络状况自己维护的一个值，表示发送方认为可以在网络中传输的数据量。发送方发送数据的大小是滑动窗口和拥塞窗口的最小值，这样可以保证发送方既不会超过接收方的接收能力，也不会造成网络的过度拥塞。

TCP 如何实现流量控制？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

为什么需要流量控制? 这是因为双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来。如果接收方处理不过来的话，就只能把处理不过来的数据存在 接收缓冲区(Receiving Buffers) 里（失序的数据包也会被存放在缓存区里）。如果缓存区满了发送方还在狂发数据的话，接收方只能把收到的数据包丢掉。出现丢包问题的同时又疯狂浪费着珍贵的网络资源。因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。

这里需要注意的是（常见误区）：

发送端不等同于客户端
接收端不等同于服务端

TCP 为全双工(Full-Duplex, FDX)通信，双方可以进行双向通信，客户端和服务端既可能是发送端又可能是服务端。因此，两端各有一个发送缓冲区与接收缓冲区，两端都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制（TCP 传输速率不能大于应用的数据处理速率）。通信双方的发送窗口和接收窗口的要求相同。

TCP 的拥塞控制是怎么实现的？

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即 慢开始、 拥塞避免、快重传、快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免： 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1.
快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

ARQ 协议了解吗?

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认信息（Acknowledgements，就是我们常说的 ACK），它通常会重新发送，直到收到确认或者重试超过一定的次数。

ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

1. 停止等待 ARQ 协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

1) 无差错情况:

发送方发送分组，接收方在规定时间内收到，并且回复确认。发送方再次发送。

2) 出现差错情况（超时重传）:

只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。

3) 确认丢失和确认迟到

确认丢失：确认消息在传输过程丢失。

当 A 发送 M1 消息，B 收到后向 A 发送了一个 M1 确认消息，但却在传输过程中丢失。而 A 并不知道，在超时计时过后，A 重传 M1 消息，B 再次收到该消息后。
处理措施：
- 丢弃这个重复的 M1 消息，不向上层交付。
- 向 A 发送确认消息（不会认为已经发送过了，就不再发送。A 能重传，就证明 B 的确认消息丢失）。

确认迟到：确认消息在传输过程中迟到。

A 发送 M1 消息，B 收到并发送确认。在超时时间内没有收到确认消息，A 重传 M1 消息，B 仍然收到并继续发送确认消息（B 收到了 2 份 M1）。此时 A 收到了 B 第二次发送的确认消息。接着发送其他数据。过了一会，A 收到了 B 第一次发送的对 M1 的确认消息（A 也收到了 2 份确认消息）。
处理措施：A 收到重复的确认后直接丢弃。B 收到重复的 M1 后也直接丢弃。

2. 连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

优点：信道利用率高，容易实现，即使确认丢失，也不必重传。

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5 条消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

超时重传如何实现？超时重传时间怎么确定？

当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。

RTT（Round Trip Time）：往返时间，也就是数据包从发出去到收到对应 ACK 的时间。
RTO（Retransmission Time Out）：重传超时时间，即从数据发送时刻算起，超过这个时间便执行重传。

RTO 的确定是一个关键问题，因为它直接影响到 TCP 的性能和效率。如果 RTO 设置得太小，会导致不必要的重传，增加网络负担；如果 RTO 设置得太大，会导致数据传输的延迟，降低吞吐量。因此，RTO 应该根据网络的实际状况，动态地进行调整。

RTT 的值会随着网络的波动而变化，所以 TCP 不能直接使用 RTT 作为 RTO。为了动态地调整 RTO，TCP 协议采用了一些算法，如加权移动平均（EWMA）算法，Karn 算法，Jacobson 算法等，这些算法都是根据往返时延（RTT）的测量和变化来估计 RTO 的值。

二、UDP

UDP（User Datagram Protocol，用户数据报协议）是一种无连接的、不可靠的、面向数据报的传输协议。它工作在OSI模型的传输层，使用IP作为底层协议，提供了一种简单的数据包交换服务。

UDP协议属于内核协议栈，而内核是用C语言写的，在底层UDP的报头是一个位段类型的结构体。

UDP的特点

UDP协议的主要特点包括无连接性、不保证可靠交付、面向报文以及没有拥塞控制等。这些特点使得UDP在实时性要求较高、对数据可靠性要求较低的应用场景中表现出色。

1）无连接：两台主机在使用UDP进行数据传输时，不需要建立连接，只需知道对端的IP和端口号即可把数据发送过去。

2）不可靠：UDP协议没有没有确认重传机制，如果因为网络故障导致报文无法发到对方，或者对方收到了报文，但是传输过程中乱序了，对方校验失败后把乱序的包丢了，UDP协议层也不会给应用层任何错误反馈信息。

PS：在网络中，“不可靠”是个中性词，因为可靠就意味着要付出更多的代价去维护可靠，实现起来会复杂很多；而“不可靠”的话，实现起来会更简单。

3）面向数据报：UDP传输数据时，是以数据报文为单位一个个地发出去，然后一个个地接收的，这导致上面应用层无法灵活控制数据数据的读写次数和数量。

比如用UDP传输100个字节的数据，如果发送端调用一次sendto，发送100个字节，那么接收端也必须调用对应的一次recvfrom去全部接收这100个字节，而不能循环调用10次recvfrom，每次接收10个字节。

UDP的缓冲区

1）UDP没有真正意义上的发送缓冲区。调用sendto会直接把数据交给内核，简单包装后由内核将数据传给网络层协议进行再后续的传输动作。

2）UDP具有接收缓冲区

这个接收缓冲区不能保证收到的UDP报文顺序和发送时UDP报文的顺序一致。比如我们网购多件商品，不是说谁先发货就先收到那个包裹，这些包裹运输途中的路径、运输方式、中转时间等都是不一样和不确定的。

UDP发出去的报文也要经过各种路由转发，每个报文选择的路径并非是一样的，这也导致了UDP报文实际发的顺序和最终收的顺序不一定一致。如果接收端来不及收或收的慢的话，会导致UDP的接收缓冲区存满，之后到达的UDP报文因为无法存下而只能把它丢弃。

三、TCP 与 UDP的区别

1）连接性

UDP是一种无连接的协议。在发送数据之前，UDP不需要建立连接，也不需要在数据发送完毕后释放连接。这种无连接性使得UDP在实时性要求较高的应用场景中能够减少传输延迟和开销。

TCP是一种面向连接的协议。在数据传输之前，TCP需要通过三次握手（SYN+ACK+SYN+ACK）建立连接，确保通信双方之间的链路是可靠的。数据传输完毕后，还需要通过四次挥手（FIN+ACK+FIN+ACK）来释放连接。这种面向连接的特性使得TCP能够提供稳定可靠的数据传输服务。

2）可靠性

UDP不保证可靠交付。它不提供确认和重传机制，也不保证数据包的顺序性。因此，在UDP传输过程中可能会出现数据丢失、重复或乱序等情况。这些特点使得UDP适用于对实时性要求较高、但对数据可靠性要求不高的应用场景。

TCP对数据的可靠性要求非常严格。它使用确认和重传机制来确保数据的完整性和正确性。如果接收方没有收到数据或数据在传输过程中发生错误，TCP会要求发送方重传数据直到接收方确认收到为止。此外，TCP还使用序列号对数据包进行标识以确保数据按照发送顺序进行传输。

3）速度和效率

由于UDP不需要建立连接和维护连接状态且没有拥塞控制机制，因此其传输速度通常比TCP更快。UDP适用于对实时性要求较高且对少量数据丢失不敏感的应用场景如音频、视频流传输等。

TCP在传输过程中需要建立连接、使用确认重传机制和拥塞控制机制等，这些操作都会增加一定的开销并降低传输速度。然而，TCP的可靠性和顺序性使得它适用于对数据完整性要求较高的应用场景如文件传输、电子邮件等。

4）数据包大小

UDP允许发送方一次性将多个数据包打包成一个较大的数据报进行传输。UDP数据报的最大长度受限于底层网络协议（通常是IP协议）的最大传输单元（MTU）。然而，在实际应用中UDP数据报的长度通常会受到网络传输的限制并需要进行分片处理。

TCP将数据划分为较小的数据包进行传输并根据网络状况进行调整。TCP没有固定的数据报大小限制且能够动态地调整数据包的大小以适应网络状况的变化。这种灵活性使得TCP能够适应不同的网络环境并提供稳定可靠的数据传输服务。

5）适用场景

由于UDP具有低延迟、高效率的特点且对数据可靠性要求不高，因此它适用于实时性要求较高且对少量数据丢失不敏感的应用场景如音频视频流传输、在线游戏、DNS解析等。

TCP提供可靠的、有序的数据传输服务且对数据完整性要求较高，因此它适用于对数据可靠性要求较高的应用场景如文件传输、电子邮件传输、网页浏览等。

UDP与TCP作为传输层最为重要的两种协议，各自具有独特的特点和优势并适用于不同的应用场景。了解它们之间的区别并根据实际需求选择合适的协议进行数据传输对于确保数据的安全、稳定和高效传输具有重要意义。在实际应用中应根据具体场景的需求和限制综合考虑各种因素以做出最佳的选择。