传输层协议TCP、UDP

川长思鸟来 2021-12-03 23:47 453阅读 0赞

# [UDP用户数据报协议 ][UDP_] #

用户数据报协议（User Datagram Protocol，简称UDP）是一种允许在基于IP的网络中无连接地发送数据报的协议。通过使用用户数据报协议，应用程序可以非常快速地发送信息，因为既不必建立与收件人的连接，也不必等待答案。但是，不能保证数据包将到达完成，并在同一顺序它们被发送。此外，该协议不提供自己的保护，以防止第三方操纵或访问。但是，可以通过可选的可用校验和检测故障数据包（强制性地与IPv6结合使用）。

报文结构：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

*  源端口：源端口号。在需要对方回信时选用。不需要时可用全0。
 *  目的端口：目的端口号。这在终点交付报文时必须要使用到。
 *  长度： UDP用户数据报的长度，其最小值是8（仅有首部），不会出现TCP粘包半包问题。
 *  校验和：检测UDP用户数据报在传输中是否有错。有错就丢弃。

### **UDP的功能** ###

1.  UDP 是无连接的：通过UDP进行的数据传输的特点是它在没有在发件人和收件人之间现有连接的情况下发生。然后将相应的数据包发送到首选IP地址，指定目标端口，而不必在其后面的计算机进行响应。但是，如果还要将数据包返回给收件人，则UDP标头也可以选择包含源端口。
2.  UDP 使用端口：与TCP一样，UDP使用端口，以便将数据包传输到正确的后续协议或目标系统上的所需应用程序。端口由根据经过验证的模式的数字定义，0到1023之间的数字分配给固定服务。
3.  UDP 支持快速，无延迟的通信：由于缺少连接设置，传输协议适用于快速数据传输。这也是由于单个数据包的丢失仅影响传输质量的事实。另一方面，使用TCP连接时，会自动重新请求丢失的数据包，从而导致整个传输过程停止。
4.  UDP 不保证数据的安全性和完整性：发件人和收件人之间缺乏相互身份验证可确保UDP的出色传输速度 – 但是，协议既不能保证数据包的完整性，也不能保证数据包的安全性。
5.  UDP支持一对一，一对多，多对一，多对对的交互通信。
6.  UDP的头部占用较小，只占用8个字节。

### UDP(User Datagram Protocol) ###

UDP不提供复杂的控制机制，利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立刻按照原样发送到网络上的一种机制。

即使是出现网络拥堵的情况下，UDP也无法进行流量控制等避免网络拥塞的行为。此外，传输途中如果出现了丢包，UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。如果需要这些细节控制，那么不得不交给由采用UDP的应用程序去处理。换句话说，UDP将部分控制转移到应用程序去处理，自己却只提供作为传输层协议的最基本功能。UDP有点类似于用户说什么听什么的机制，但是需要用户充分考虑好上层协议类型并制作相应的应用程序。

### TCP(Transmission Control Protocol) ###

TCP充分实现了数据传输时各种控制功能，可以进行丢包的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费。

TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。此处不一一叙述。  
TCP与UDP如何加以区分使用？

TCP用于在传输层有必要实现可靠性传输的情况。由于它是面向有连接并具备顺序控制、重发控制等机制的。所以它可以为应用提供可靠传输。

另一方面，UDP主要用于那些对高速传输和实时性有较高要求的通信或广播通信。举一个IP电话进行通话的例子。如果使用TCP，数据在传送途中如果丢失会被重发，但是这样无法流畅地传输通话人的声音，会导致无法进行正常交流。而采用UDP，它不会进行重发处理。从而也就不会有声音大幅度延迟到达的问题。即使有部分数据丢失，也只是影响某一小部分的通话。此外，在多播与广播通信中也使用UDP而不是UDP。RIP、DHCP等基于广播的协议也要依赖于UDP。

### UDP如何实现可靠传输 ###

由于在传输层UDP已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制

简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的

*  超时重传（定时器）
 *  有序接受 （添加包序号）
 *  应答确认 （Seq/Ack应答机制）
 *  滑动窗口流量控制等机制 （滑动窗口协议）
 *  等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制，比如使用UDP数据包+序列号，UDP数据包+时间戳等方法。

目前已经有一些实现UDP可靠传输的机制，比如

**UDT（UDP-based Data Transfer Protocol）**  
        基于UDP的数据传输协议（UDP-based Data Transfer Protocol，简称UDT）是一种互联网数据传输协议。UDT的主要目的是支持高速广域网上的海量数据传输，而互联网上的标准数据传输协议TCP在高带宽长距离网络上性能很差。 顾名思义，UDT建于UDP之上，并引入新的拥塞控制和数据可靠性控制机制。UDT是面向连接的双向的应用层协议。它同时支持可靠的数据流传输和部分可靠的数据报传输。 由于UDT完全在UDP上实现，它也可以应用在除了高速数据传输之外的其它应用领域，例如点到点技术（P2P），防火墙穿透，多媒体数据传输等等。

# **TCP传输控制协议** #

TCP报文结构：TCP报文是TCP层传输的数据单元，也叫报文段。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1][]

**1、端口号**：用来标识同一台计算机的不同的应用进程。

*  **1）源端口**：源端口和IP地址的作用是标识报文的返回地址。
 *  **2）目的端口**：端口指明接收方计算机上的应用程序接口。

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

**2、序号和确认号**：是TCP可靠传输的关键部分。**序号**是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。e.g.一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。**所以序号确保了TCP传输的有序性**。确认号，即ACK，指明下一个期待收到的字节序号，表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。

**3、数据偏移／首部长度**：4bits。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15\*32/8 = 60，故报头最大长度为60字节。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值。

**4、保留**：为将来定义新的用途保留，现在一般置0。

**5、控制位**：URG  ACK  PSH  RST  SYN  FIN，共6个，每一个标志位表示一个控制功能。

*  **1）URG**：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。
 *  **2）ACK**：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。
 *  **3）PSH**：push标志，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。
 *  **4）RST**：重置连接标志，用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。
 *  **5）SYN**：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
 *  **6）FIN**：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。

**6、窗口**：滑动窗口大小，用来告知发送端接受端的缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。窗口大小时一个16bit字段，因而窗口大小最大为65535。

**7、校验和**：奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据，以 16 位字进行计算所得。由发送端计算和存储，并由接收端进行验证。

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

**9、选项和填充**：最常见的可选字段是最长报文大小，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。

**10、数据部分**： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

### **1、TCP主要特点** ###

1.  TCP是面向连接的运输层协议。使用之前必须建立连接，使用之后必须释放连接。
2.  每一条TCP连接只能有两个端点，每一条连接只能是点对点的。
3.  TCP提供可靠交付的服务。 通过TCP连接传送的数据，无差错，无丢失，不重复，按序到达。
4.  TCP提供全双工通信。允许通信双方的应用程序在任何时候都能发送数据。TCP连接的两端设有发送缓存和接收缓存，用来存储双向通信的数据。发送时，应用程序把数据发送给TCP缓存就可以干自己的事情了，TCP会在合适的时候发送出去。接收时，TCP会把接收的数据放入缓存，应用程序在合适的时候读取缓存中的数据。
5.  面向字节流

**了解****TCP协议端口****的连接状态，对排除和定位网络或系统故障会有很大帮助，因此了解一下是有必要的：**

*  1、**LISTENING** ：提供某种服务，侦听远方TCP端口的连接请求，当提供的服务没有被连接时，处于LISTENING状态，端口是开放的，等待被连接。
 *  2、**SYN\_SENT (客户端状态)**：客户端调用connect，发送一个SYN请求建立一个连接，在发送连接请求后等待匹配的连接请求，此时状态为SYN\_SENT.
 *  3、**SYN\_RECEIVED (服务端状态)**：在收到和发送一个连接请求后，等待对方对连接请求的确认，当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN\_RCVD状态，如果连接成功了就变为ESTABLISHED，正常情况下SYN\_RCVD状态非常短暂。
 *  4、**ESTABLISHED**：ESTABLISHED状态是表示两台机器正在传输数据。
 *  5、**FIN-WAIT-1**：等待远程TCP连接中断请求，或先前的连接中断请求的确认，主动关闭端应用程序调用close，TCP发出FIN请求主动关闭连接，之后进入FIN\_WAIT1状态。
 *  6、**FIN-WAIT-2**：从远程TCP等待连接中断请求，主动关闭端接到ACK后，就进入了FIN-WAIT-2 .这是在关闭连接时，客户端和服务器两次握手之后的状态，是著名的半关闭的状态了，在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN\_WAIT\_2状态，而服务器则一直处于WAIT\_CLOSE状态，而直到应用层来决定关闭这个状态。
 *  7、**CLOSE-WAIT**：等待从本地用户发来的连接中断请求 ，被动关闭端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也作为文件结束符传递给上层应用程序),并进入CLOSE\_WAIT. 
 *  8、**CLOSING**：等待远程TCP对连接中断的确认,处于此种状态比较少见。
 *  9、**LAST-ACK**：等待原来的发向远程TCP的连接中断请求的确认,被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭连接,TCP也发送一个 FIN,等待对方的ACK.进入LAST-ACK。
 *  10、**TIME-WAIT**：在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态,等待足够的时间以确保远程TCP接收到连接中断请求的确认,很大程度上保证了双方都可以正常结束,但是也存在问题，须等待2MSL时间的过去才能进行下一次连接。
 *  11、**CLOSED**：被动关闭端在接受到ACK包后，就进入了closed的状态，连接结束，没有任何连接状态。

### **2、三次握手** ###

首先需要认识几个TCP的状态名称与含义,在TCP层，有个FLAGS字段，这个字段有以下几个标识：**SYN, FIN, ACK, PSH, RST**

1.  **SYN** 标志位用来建立连接，如果SYN=1而ACK=0,表明它是一个连接请求；如果SYN=1且ACK=1，则表示同意建立一个连接。
2.  **FIN** 表示关闭连接，置1时表示发端完成发送任务。用来释放连接，表明发送方已经没有数据发送了。
3.  **ACK** 表示响应，置1时表示确认号（为合法，为0的时候表示数据段不包含确认信息，确认号被忽略。)
4.  **PSH** 表示有 DATA数据传输，置1时请求的数据段在接收方得到后就可直接送到应用程序，而不必等到缓冲区满时才传送。
5.  **RST** 标志位用来复位一条连接。当RST=1时，表示出现严重错误，必须释放连接，然后再重新建立。
6.  **URG** 为紧急数据标志，如果URG为1，表示本数据包中包含紧急数据。此时紧急数据指针表示的值有效，它表示在紧急数据之后的第一个字节的偏移值（即紧急数据的总长度）。

一般地，当出现FIN包或RST包时，我们便认为客户端与[服务器][Link 1]端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2][]

1.  **第一次握手:**客户机A发送标识位SYN = 1,随机产生序列号seq = x的数据包到服务器B,服务器B由SYN = 1知道客户机A要建立连接，并进入SYN\_SEND状态，等待服务器确认；
2.  **第二次握手:**服务器B收到请求并确认联机信息后,向客户机A发送标识位SYN = 1,ACK = 1和随机产生的序列号seq = y, 确认码ack number = x+1（客户机A发送的seq+1）的数据包，此时服务器进入SYN\_RECV状态；
3.  **第三次握手:**客户机A收到后检查确认码ack number是否正确,即和第一次握手发送的序列号加1结果是否相等，以及ACK标识位是否为1；若正确，客户机A发送标识位ACK = 1、seq = x + 1和确认码ack number = y + 1（服务器B发送的seq+1）到服务器B，服务器B收到后确认ACK=1和seq是否正确，若正确则完成建立连接，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手，客户端与服务器开始传送数据。

**       为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。**

TCP建立连接为什么是三次握手？这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"**在不可靠信道上可靠地传输信息**"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.

为什么不能用两次握手进行连接？3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

### **3、四次挥手** ###

对于4次挥手，其实你仔细看是2次，因为TCP是**全双工**的，所以，发送方和接收方都需要Fin和Ack。只不过，有一方是被动的，所以看上去就成了所谓的4次挥手。由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。

如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME\_WAIT状态。上图是双方同时断连接的示意图。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 3][]

1.  **第一次挥手：**客户端A发送一个FIN = 1、初始化序列号seq = u，到服务器B，用来主动关闭客户A到服务器B的数据传送，客户机A进入FIN-WAIT-1状态，等待服务器B发送FIN；
2.  **第二次挥手：**服务器B收到这个FIN，它发回ACK = 1、确认序号ack number为收到的序号加1（ack number=u+1）；和SYN一样，一个FIN将占用一个序号seq = v，客户机A进入FIN-WAIT-2，稍后关闭连接，服务器B进入CLOSE\_WAIT，等待关闭连接;
3.  **第三次挥手：**服务器B关闭与客户端A的连接，发回标识位FIN = 1，ACK = 1,seq = w和确认码ack number=u+1给客户端A，服务器B进入LAST\_ACK，等待最后一次ACK确认;
4.  **第四次挥手：**客户端A发送ACK = 1报文确认，并将确认序号设置为收到序号加1（ack number=w+1）到服务器B，客户机A进入TIME-WAIT等待2MAL后进入CLOSE可用状态，服务器B进入CLOSE可用状态。

当客户端进入TIME-WAIT状态的时候(也就是第四次挥手的时候)，必须经过时间计数器设置的时间**2MSL(最长报文段寿命)**后，才能进入关闭状态，这时为什么呢？

这最主要是因为两个理由：

*  1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
 *  2、他还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。

注意：在服务器发送了FIN-ACK之后，会立即启动超时重传计时器。客户端在发送最后一个ACK之后会立即启动时间等待计时器。

为什么是2MSL

我们知道服务端收到ACK，关闭连接。但是客户端无法知道ACK是否已经到达服务端，于是开始等待？等待什么呢？假如ACK没有到达服务端，服务端会为FIN这个消息超时重传 timeout retransmit ，那如果客户端等待时间足够，又收到FIN消息，说明ACK没有到达服务端，于是再发送ACK，直到在足够的时间内没有收到FIN，说明ACK成功到达。这个等待时间至少是：服务端的timeout + FIN的传输时间，为了保证可靠，采用更加保守的等待时间2MSL。

MSL，Maximum Segment Life，这是TCP 对TCP Segment 生存时间的限制。

客户端发出ACK，等待ACK到达对方的超时时间 MSL，等待FIN的超时重传，也是MSL，所以如果2MSL时间内没有收到FIN，说明对方安全收到FIN。

### **4、TCP通信原理** ###

首先，对于TCP通信来说，每个TCP Socket的内核中都有一个发送缓冲区和一个接收缓冲区，TCP的全双工的工作模式及TCP的滑动窗口就是依赖于这两个独立的Buffer和该Buffer的填充状态。

接收缓冲区把数据缓存到内核，若应用进程一直没有调用Socket的read方法进行读取，那么该数据会一直被缓存在接收缓冲区内。不管进程是否读取Socket，对端发来的数据都会经过内核接收并缓存到Socket的内核接收缓冲区。read索要做的工作，就是把内核接收缓冲区中的数据复制到应用层用户的Buffer里。进程调用Socket的send发送数据的时候，一般情况下是讲数据从应用层用户的Buffer里复制到Socket的内核发送缓冲区，然后send就会在上层返回。换句话说，send返回时，数据不一定会被发送到对端。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 4][]

### **5、可靠传输的工作原理** ###

TCP 连接的每一端都必须设有两个窗口——一个发送窗口和一个接收窗口。TCP 的可靠传输机制用字节的序号进行控制。TCP 所有的确认都是基于序号而不是基于报文段。发送过的数据未收到确认之前必须保留，以便超时重传时使用。发送窗口不动(没收到确认)和前移(收到新的确认)。

*  发送缓存用来暂时存放：发送应用程序传送给发送方 TCP 准备发送的数据；TCP 已发送出但尚未收到确认的数据。
 *  接收缓存用来暂时存放：按序到达的、但尚未被接收应用程序读取的数据； 不按序到达的数据。

TCP/IP可靠传输的基础是滑动窗口协议和连续ARQ协议，配合着流量控制和拥塞控制，使得整个传输过程保证：

*  传输信道不产生差错。
 *  不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据（通过累计确认、超时重传、拥塞控制三大模块保证）。

### **自动重传请求(ARQ)：** ###

**左图：**图a情况是传输中没有出现差错情况下的，A发送完M1后收到确认再发送下一组。图b是传输过程中出现差错，这里就采用了超时重传。实现超时重传就要在每发送完一个分组时设置一个超时计时器，如果在计时器到期之前收到对方的确认，就撤销已设置的超时计时器。

![2019071910563720.png][]![2019071910564363.png][]

**右图：**图a如所示，B接收到，但是回应确认消息的时候丢失，这时候A的超时计时器到期了，就又发送了M1，这时候B会丢弃重复的M1，再次重传确认消息。图b是B在收到A发送的M1后，B回应确认消息返回给A时迟到了，这时候A又发送一次M1，同样的，B会丢弃M1，再次重传确认。A收到迟到后的确认消息会什么也不做。

使用上述的确认和重传机制，TCP就能在不可靠的传输网络上实现可靠的通信！！！像上述的这种可靠传输协议常称为自动重传请求ARQ。 意思是重传的请求是自动进行的。停止等待协议一个显著的特点是**效率太低，信道利用率太低**。

### **滑动窗口协议和连续ARQ协议****：** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 5][]

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。下图表示发送方收到对第1个分组的确认，于是把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。

接收方一般都是**采用累积确认**的方式，也就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组分组为止的所有分组都已正确收到了。

累计确认优点：容易实现，即使确认丢失也不必重传。缺点：不能向发送方反映出接收方已经正确收到所有的分组的信息。

例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已经发送过的N个分组。可见，当通信线路质量不好时，连续ARQ协议会带来负面影响。

### **6、TCP的流量控制** ###

**        流量控制的目的：**让发送方的发送速率不要太快，要让接收方来得及接收。利用**滑动窗口机制**就可以实现对发送方的流量控制。

流量控制往往是指点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送速率，以便使接收端来得及接受。利用滑动窗口机制就可以实现流量的控制。原理就是运用TCP报文中的窗口大小字段来控制，发送的发送窗口不可以大于接收方的接收窗口大小。如果接收方没有足够的缓存来接收数据，发送方就会收到一个零窗口的通知。此时发送方停止发送。并且定时发送一个窗口探测报文来探测接收方的接收能力。

考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致**死锁**。

解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 6][]

### 7、**TCP的****拥塞控制** ###

流量控制是端到端的交互，如果只是局域网内的两台设备交互，我想通过滑动窗口大概能控制得不差，但是实际网络的情况非常复杂，发送方和接收方之间还有路由器和交换机，网络传输线路又复杂，这个时候就需要拥塞控制。**      **

**        拥塞控制：**TCP模块为了防止过多的数据注入网络，使网络中的路由器或链路不致于过载。以此提高网络利用率，降低丢包率，并保证网络资源对每条数据流的公平性而采取的控制手段。拥塞控制包含四部分内容：**慢启动、拥塞避免、快速重传、快速恢复**。

拥塞窗口的概念：发送报文段速率的确定，既要根据接收端的能力，又要从全局考虑不要使网路发生拥塞，这由接收窗口和拥塞窗口两个状态量来决定。接收窗口又称通知窗口，是接收端根据目前接收缓存大小所许诺的最新窗口值，是来自接收端的流量控制。拥塞窗口cwnd是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制。

*  **慢启动：**网络传输刚开始时，并不知道网络的实际情况，所以采取一种试探的方式控制数据的发送速率。慢启动阶段，数据的发送速率以指数方式增长，即就是拥塞窗口的增长，每次都是收到确认报文段数量的2倍。可以看出慢启动并不慢，拥塞窗口增长的速度很快。所以，为其设置了一个慢启动门限，当达到门限时，就进入到拥塞避免阶段。
 *  **拥塞避免：**当拥塞窗口的大小采用慢启动方式增长到慢启动门限时，就进入拥塞避免阶段，拥塞避免阶段不再以指数形式增长拥塞窗口，而是每经过一个往返时间RTT就将发送方的拥塞窗口+1， 使其增长速度减缓。按照线性方式增长。如果发生网络拥塞，比如丢包时，就将慢启动门限设为原来的一半，然后将拥塞窗口设置为1，开始执行慢启动算法。（较低的起点，指数级增长）。
 *  **快速重传：**假设发送方发送的报文段分别为：M1,M2,M3,M4,M5,M6 , 当接收方收到M1和M2后，M3报文段丢失，接着收到的M4，M5，M6都不做处理，而是没接收到一个报文段就对M2重复确认，发送方接收到重复的三次确认报文段，就对其后的报文段进行重新发送，而不需要等待超时时间到达。当快速重传后，立即进入到快速恢复阶段。
 *  **快速恢复：**将慢启动门限设置为原来的一半，然后将拥塞窗口设置为现在的慢启动门限值，不再执行慢启动算法，而是直接进入拥塞避免阶段。使发送窗口成线性方式增大。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 7][]

什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP：当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……

[UDP_]: https://www.simcf.cc/4609.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20211203/01dd2a8dec4e42d3896bf7989052863e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1]: /images/20211203/d8d9d0b2eda64163bc9798aca521e4a0.png
[Link 1]: https://www.baidu.com/s?wd=%E6%9C%8D%E5%8A%A1%E5%99%A8&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2]: /images/20211203/c4aee9409a6c4032b4a44a658a0f7002.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 3]: /images/20211203/1a68a6c13c754224ac37b178173d0a7a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 4]: /images/20211203/2ca3a8ba51fe4f5687ef4b2ddc19f29f.png
[2019071910563720.png]: https://img-blog.csdnimg.cn/2019071910563720.png
[2019071910564363.png]: /images/20211203/c530999289744924b6edaacf7ae48f3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 5]: /images/20211203/f52f4e41d7984470bae978b9b09a4163.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 6]: /images/20211203/b609eec7d3bb41f1b18ec219bb3b2472.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 7]: /images/20211203/c1f7b0999b4f4772ba27b79a448ee337.png