TCP与UDP协议

最新推荐文章于 2024-06-15 10:58:32 发布

邋遢的流浪剑客

最新推荐文章于 2024-06-15 10:58:32 发布

阅读量413

点赞数 1

分类专栏： # 计算机网络文章标签： TCP协议 UDP协议 TCP三次握手与四次挥手 TCP滑动窗口 TCP拥塞控制

本文链接：https://blog.csdn.net/qq_40378034/article/details/100893573

版权

计算机网络专栏收录该内容

14 篇文章 6 订阅

订阅专栏

一、TCP协议

1、TCP 的特性

TCP提供一种面向连接的、可靠的字节流服务
在一个TCP连接中，仅有两方进行彼此通信。广播和多播不能用于TCP
TCP使用校验和，确认和重传机制来保证可靠传输
TCP给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
TCP使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

注意：TCP并不能保证数据一定会被对方接收到，因为这是不可能的。TCP能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说TCP也不是100%可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知

2、三次握手与四次挥手

1）、三次握手

在这里插入图片描述

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器

1）TCP服务器进程先创建传输控制块TCB，时刻准备接收客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态

2）TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，报文首部中的同部位SYN=1，同时选择一个初始序列号seq=x ，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号

3）TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文的ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号

4）TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号

5）当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了
在这里插入图片描述
为什么TCP客户端最后还要发送一次确认呢？

主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误

如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接收到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接

2）、四次挥手

在这里插入图片描述

数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接收。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接收服务器发送的最后的数据）

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些
在这里插入图片描述
为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文

为什么建立连接是三次握手，关闭连接却是四次挥手呢？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端

而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次

参考：https://blog.csdn.net/qzcsu/article/details/72861891#commentBox

3、利用窗口控制提高速度

TCP以1个段为单位，每发一个段进行一次确认应答的处理，这样的传输方式有一个缺点就是包的往返时间越长通信性能就越低
在这里插入图片描述
为解决这个问题，TCP引入了窗口这个概念。即使在往返时间较长的情况下，它也能控制网络性能的下降。此时，确认应答不再是以每个分段，而是以更大的单位进行确认，转发时间将会被大幅度的缩短。也就是说，发送端主机在发送了一个段以后不必要一直等待确认应答，而是继续发送
在这里插入图片描述
窗口大小就是指无需等待确认应答而可以及继续发送数据的最大值。上图中窗口大小为4个段

这个机制使用大量的缓存区实现对多个段同时进行确认应答的功能
在这里插入图片描述
上图中，发送数据中圈起来的部分是窗口。在这个窗口内的数据即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机得设置缓存保留这些待被重传的数据，直到收到它们的确认应答

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

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

4、窗口控制与重发控制

在使用窗口控制中，如果出现丢失该怎么办？

首先，我们先考虑应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的。然后，在没有使用窗口控制的时候，没有收到确认应答的数据都会被重发。而使用了窗口控制，即使有少部分的确认应答丢失也不会进行数据重发，可以通过下一个确认应答进行确认
在这里插入图片描述
其次，我们来考虑一下某个报文段丢失的情况。如下图所示，接收主机如果收到一个自己应该接收的序号以外的数据时，会针对当前为止收到数据返回确认应答

当某一报文段丢失后，发送端会一直收到序号为1001的确认应答。在窗口比较大，又出现报文段丢失的情况下，同一个序号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答，就会将其所对应的数据进行重发。这种机制也被称作高速重发控制
在这里插入图片描述

5、流量控制

如果发送者发送数据过快，接收者来不及接收，如果接收端将本应该接收的数据丢弃的话，就又会触发重发机制，从而导致网络流量的无端浪费

为了防止这种现象的发生，TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流量控制。它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。该大小限制就被称作窗口大小，窗口大小的值是由接收端主机决定的

TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大，说明网络的吞吐量越高

接收端的这个缓冲区一旦面临数据溢出时，窗口大小的值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。也就形成了一个完整的TCP流量控制
在这里插入图片描述
如上图所示，当接收端从3001号开始的数据段后缓冲区即满，不得不暂时停止接收数据。之后，在收到发送窗口更新通知后通信才得以继续进行。如果这个窗口的更新通知在传送途中丢失，可能会导致无法继续通信。为避免此类问题的发生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口大小信息

6、拥塞控制

网络中的链路容量和交换结点中的缓存和处理机都有着工作的极限，当网络的需求超过它们的工作极限时，就出现了拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。常用的方法就是：

慢开始、拥塞控制
快重传、快恢复

一切的基础还是慢开始，这种方法的思路是这样的：

1）、发送方维持一个叫做“拥塞窗口”的变量，该变量和接收端口共同决定了发送者的发送窗口；
2）、当主机开始发送数据时，避免一下子将大量字节注入到网络，造成或者增加拥塞，选择发送一个1字节的试探报文

3）、当收到第一个字节的数据的确认后，就发送2个字节的报文

4）、若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级

5）、最后会达到一个提前预设的“慢开始门限”，比如24，即一次发送了24个分组，此时遵循下面的条件判定：

cwnd < ssthresh，继续使用慢开始算法
cwnd > ssthresh，停止使用慢开始算法，改用拥塞避免算法
cwnd = ssthresh，既可以使用慢开始算法，也可以使用拥塞避免算法

6）、所谓拥塞避免算法就是：每经过一个往返时间RTT就把发送方的拥塞窗口+1，即让拥塞窗口缓慢地增大，按照线性规律增长

7）、当出现网络拥塞，比如丢包时，将慢开始门限设为原先的一半，然后将cwnd设为1，执行慢开始算法（较低的起点，指数级增长）
在这里插入图片描述
上述方法的目的是在拥塞发生时循序减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。慢开始和拥塞控制算法常常作为一个整体使用，而快重传和快恢复则是为了减少因为拥塞导致的数据包丢失带来的重传时间，从而避免传递无用的数据到网络