UDP和TCP的区别上一篇文章TCP建立连接的三次握手和四次握手进行了释放连接的握手方式。详细来说，本节教程将讲解TCP的其他内容。首先是UDP协议，它也是传输层协议。两者有什么区别和联系？相同的是：UDP和TCP是TCP/IP体系结构中传输层的两个重要协议，下图是TCP/IP的体系结构图：补充一点就是IP协议在下层在TCP和UDP协议中，IP协议可以为各种网络应用提供服务，IP层协议用于互连不同的网络接口。下面是结构图：image-20210718234432031TCP和UDP的使用频率在互联网层仅次于IP协议。UDP也称为用户数据报协议，而TCP称为传输控制协议。更重要的区别是UDP是无连接的，而TCP是面向连接的。下面是两种通信方式通信示意图：如上图所示，对于UDP，它可以在不建立连接的情况下传输数据，而对于TCP，则需要进行“三消息握手”才能建立连接数据传输前，然后数据传输完成后，需要“四次报文挥手”释放连接。这也是因为UDP的无连接特性。对于UDP，它支持单播、组播和广播。对于TCP来说，由于是通过三次握手建立的连接，所以具有可靠的通道。它只支持单播。下面是两种通信方式的示意图：接下来分析UDP和TCP数据传输的详细过程，可以看到对于UDP来说，它是面向应用报文的，发送端的应用进程会向应用消息在传输层传送到UDP。UDP直接在应用层报文中加上UDP报头，使其成为UDP用户数据报，然后发送。接收方UDP收到UDP用户数据报后，去掉UDP报头，将应用层数据包递交给应用进程，换句话说，UDP既不合并也不拆分应用进程递交的数据包，而是保留了这些数据包的边界，也就是说，UDP是面向应用的Wen的。接下来上图右侧是TCP数据发送流程。发送方的TCP将应用进程传递的数据块视为一系列非结构化的字节流。TCP不知道这些要传输的字节流的细节。意思是，只需给它们编号并将它们存储在它们自己的发送缓冲区中。TCP根据发送策略从发送缓冲区中提取一定数量的字节，构造一个TCP报文段并发送。一方面，接收方的TCP从接收到的TCP报文中取出数据负载部分，存入接收缓冲区。一方面，将接收缓冲区中的一些字节传递给应用程序进程。TCP不保证接收到的数据块与发送应用进程发送的数据块相同。有对应大小的关系，但是接收应用进程接收到的字节流必须和发送应用进程发送的字节流完全一样。同时，接收应用进程必须能够识别接收到的字节流，并将其还原为有意义的应用层数据。也就是说，TCP是面向字节的，这是TCP实现可靠传输、流量控制、拥塞控制的基础。接下来，我们再看一个对比。示意图如下：也就是说，对于TCP/IP架构，Internet层向上提供无连接、不可靠的传输服务，而对于UDP，传输层向上提供无连接、不可靠的传输服务，这样的机制也造成数据丢包和误码，但对于UDP传输，只是丢弃，什么都不做；但对于TCP传输协议来说，互联网层向上提供无连接、不可靠的传输服务，TCP所在的传输层向上提供面向连接的可靠传输服务，同样实现了基于TCP连接的可靠通道，无传输错误和错误代码。、丢失、乱序和重复问题。让我们比较一下UDP和TCP消息的标头。UDP用户数据报由标头和数据负载组成。TCP段也由标头和数据有效负载组成。UDP用户数据报头只有8个字节。仅包含源端口、目标端口、长度和校验和。对于TCP，它的头部包含了更多的信息，它的头部大小最少为20字节，最多为60字节。总结综上所述，TCP和UDP的特点和区别总结如下：应用层传递的消息尽可能直接打包传递，即不可靠；没有使用流量控制和拥塞控制。头部开销很小，只有8个字节。传输控制层协议TCP是面向连接的。可以一对一通信面向字节流的可靠传输，使用流量控制和拥塞控制头部最小20字节，最大60字节TCP流量控制滑动窗口的介绍在上一篇TCP中有介绍在三次握手和四次挥手过程中，我们知道对于TCP通信来说，每发送一条数据，都需要一个确认响应。当上一个数据包收到响应时，发送下一个数据包。这样一个通信的流程是这样的：从上面的示意图也可以看出，如果每发送一个数据包进行响应，那么就发送下一个数据包。一个数据包，这样效率太低了，这个时候引入滑动窗口的概念。有了窗口，你可以指定窗口的大小。窗口大小是指在不等待响应的情况下可以继续发送数据的最大值。比如当前窗口为3，那么发送端可以连续发送3次。TCP段，并且如上图所示，如果其中一个ACK丢失，可以通过下一个确认响应来确认。例如，如果ACK600丢失，则ACK700的确认响应可以替代ACK600的确认响应。流量控制根据上面提到的滑动窗口机制，我们知道因为这个机制，我们可以让传输速率更快，但是如果发送方的发送速率太快，接收方可能无法及时处理时间，这会造成数据的丢失，而要描述的流控就是让发送端的发送速率不要太快，让接收端及时接收，使用滑动窗口机制可以轻松实现流发送方对TCP连接的控制。在介绍流量控制是如何实现之前，我们先来看看发送方和接收方的滑动窗口。首先介绍一下发送者窗口。发件人的窗口有多大？这取决于接收器。一方能处理多少数据，也就是说，在发送数据之前，接收方会向发送方报告一个窗口大小。此窗口大小是Advertised窗口。这是什么意思？看下面示意图：LastByteAcked：第一部分和第一部分第二部分的分界线LastByteSent：第二部分和第三部分的分界线从示意图也可以看出。对于Advertisedwindow，这个窗口的大小应该等于第二部分+第三部分。对于接收端来说，其缓存中记录的内容比较简单，如下示意图所示：其中，MaxRcvBuffer正如其字面意思一样，是最大缓冲区大小，接收端的窗口大小也是就像一个蓝色方框所示，说到这里，引入一个问题，那就是：接收窗口和发送窗口的大小是否相等？答案是它们并不完全相等。接收窗口的大小约等于发送窗口的大小。原因是滑动窗口不是静态的。例如，当接收方的应用进程读取数据速度较快时，接收窗口很快就会空出，但要告诉发送方这个消息，就需要通过网络进行传输，那么这种依赖关系就会存在不一致，所以近似相等。发送方和接收方的窗口基本有这些内容，然后是关于流量控制的内容：首先假设窗口保持不变，即9，当4的确认到来时，窗口会向右移动一个，并且全程，13这个序号的包也可以发。如果此时发送端发送速度过快，就会将第三部分的10、11、12、13全部发送出去，然后停止发送。当确认到来时，客户端相当于多滑动了一个窗口。此时可以发送第14个数据包。如果接收方的处理速度太慢，则可以通过确认信息调整窗口的大小。现在假设一个极端的情况，即接收端还没有处理数据，那么当6号包的确认到达时，窗口大小不能为9，需要缩小为8。下面是窗口的变化发送方收到6的确认包后，可以看到此时窗口的变化不是向右移动一个空格，而是窗口左侧缩进一个空格，整体大小为窗口没有改变。如果接收端还没有处理数据，那么随着确认的数据包越来越多，窗口会越来越小，直到为0。下面是接收端窗口的变化：上面接收端对应的发送窗口图情况如下，当14的确认到达发送端时，发送端的窗口也调整为0，停止发送。如果发生这种情况，发送方将定期发送窗口检测数据包，看看是否有机会调整窗口的大小。当接收端比较慢的时候，为了防止低能窗口综合症，不要留下一个字节快点告诉发送端，然后马上又重新填满。当窗口太小时，窗口不会更新，直到达到一定大小，或者缓冲区有一半为空，才更新窗口。以上就是TCP中的流量控制。TCP拥塞控制在一定时间内，如果网络中对某种资源的需求超过了该资源所能提供的可用部分，网络性能就会恶化。这种情况称为拥塞。计算机网络中的链路容量（即带宽）、交换节点中的缓存和处理器等都是网络资源。如果在没有控制的情况下发生拥塞，整个网络的吞吐量将随着输入负载的增加而增加。在坠落的同时。下图是理想拥塞控制、实际拥塞控制、无拥塞控制的图。曲线如下：TCP的拥塞控制算法主要涉及四种，即：慢启动算法拥塞避免算法快速重传算法在解释这四种拥塞控制算法之前，快速恢复算法假设如下条件：数据单向传输，同时另一个方向只是发送确认接收方总是有足够大的缓冲空间，所以发送方发送的窗口的大小是由网络的拥塞程度决定的。最大报文段数MSS作为讨论的单位，不以字节为单位。也就是说现在发送方和接收方之间的通信是这样的，具体过程如下图所示：发送方发送一个TCP数据段给接收方，接收方返回一个TCP确认段给发送方收到整个段后。窗口cwnd的状态变量，其值取决于网络拥塞程度，动态变化。拥塞窗口cwnd的维护原则：只要网络不发生拥塞，拥塞窗口的值就会增加；但只要网络中存在拥塞，拥塞窗口就会减小。判断网络拥塞发生的依据：应该收到的确认报文没有按时收到（即发生超时重传）。发送方以拥塞窗口为发送窗口，即swnd=cwdn维护一个慢启动阈值ssthresh状态变量：当cwnd
