计算机网络06--从零开始学

接着上一篇博客计算机网络05--从零开始学

1.TCP的流量控制：利用滑动窗口实现流量控制。

 流量控制就是让发送方不要发送太快，要让接收方来得及接收。

 

如图所示，说明了利用可变窗口大小进行流量控制。设主机A向主机B发送数据。双方确定的窗口值是400.再设每一个报文段为100字节长，序号的初始值为seq=1,图中的箭头上面大写ACK，表示首部中的却认为为ACK，小写ack表示确认字段的值。

     接收方的主机B进行了三次流量控制。第一次把窗口设置为rwind=300，第二次减小到rwind=100最后减到rwind=0，即不允许发送方再发送过数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。

     假如，B向A发送了零窗口的报文段后不久，B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段，然而这个报文段在传送中丢失了。A一直等待收到B发送的非零窗口的通知，而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态，TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器，若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

2.TCP的拥塞控制

1.拥塞控制的原理

     在某段时间，若对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变化，这种情况叫做拥塞。一句话：请求的资源大于了可用资源。

     网络拥塞往往是由许多因素引起的，简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。例如，当节点的缓存容量太小，到达该节点的分组因无法存储而不得不丢弃。当某个结点缓存容量扩展到非常大，于是凡到达该结点的分组均可在结点的缓存队列中排队，不受任何限制。由于输出链路的容量和处理机的速度并未提高，因此在这队列中的绝大多数的分组在排队等待时间会大大增加，结果上层软件只好把他们进行重传。因此，问题的是指往往是整个系统的各个部分不匹配，只有各个部分平衡了，问题才会得到解决。由拥塞引起的重传，不会环节网络的拥塞，反而会加剧网络的拥塞。

2.拥塞控制和流量控制的差别

     所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。这个整个网络的输入负载是否超过网络所能承受的。

     流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

3.拥塞控制设计

    实际的情况是随着负载的增大，网络吞吐量增长的速率逐渐减小，当提供的负载达到某一数值时，网络的吞吐量反而随提供负载的增大而下降，这时网络就进入了拥塞状态。当吞吐量下降到零，网络无法工作，这就是所谓的死锁。

     拥塞控制是很难设计的，因为它是一个动态的问题，许多情况下，甚至正式拥塞控制机制本身成为引起网络性能恶化甚至死锁的原因。从控制理论的角度来看拥塞控制这个问题，可以分为开环控制和闭环控制两种方法。开环控制就是在设计网络时事先将有关拥塞发生的所有因素考虑周到，一旦系统运行起来就不能在中途改正。

     闭环控制是基于反馈环路的概念，包括如下措施：

     1）监测网路系统以便检测拥塞在何时何地发生

     2）把拥塞发生的信息传送到可采取行动的地方

     3）调整网络系统的行动以解决出现的问题。

4.拥塞控制方法

因特网建议标准RFC2581定义了进行拥塞控制的四种算法，即慢开始（Slow-start)，拥塞避免（Congestion Avoidance)快重传（Fast Restrangsmit)和快回复（Fast Recovery）。我们假定

     1）数据是单方向传送，而另外一个方向只传送确认

     2）接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定。

--慢开始和拥塞避免

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

     慢启动原理：发送方自己的发送窗口等于拥塞窗口，

     1）当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引其网络拥塞

     2）比较好的方法是试探一下，即从小到达逐渐增大发送端的拥塞控制窗口数值

     3）通常在刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段的MSS的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS的数值，当rwind足够大的时候，为了防止拥塞窗口cwind的增长引起网络拥塞，还需要另外一个变量---慢开始门限ssthresh

     拥塞控制具体过程为：

     1）TCP连接初始化，将拥塞窗口设置为1

     2）执行慢开始算法，cwind按指数规律增长，知道cwind == ssthress（慢开始门限）开始执行拥塞避免算法，cwnd按线性规律增长

     3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行。

--快重传和快恢复

     一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。

     快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。慢开始算法只是在TCP建立时才使用

     快恢复算法有以下两个要点：

     1）当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限减半，这是为了预防网络发生拥塞。

     2）由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd值设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，是拥塞窗口的线性增大。

3.TCP运输连接管理

TCP是面向连接的协议，有三个阶段：连接建立、数据传送 和 连接释放。运输连接的管理就是使运输连接的简历和释放都能正常地进行。

在TCP连接建立过程中要解决一下三个问题：

1、  要使每一方都能够确知对方的存在： 所以需要三次握手。

2、  要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。

3、  能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配：建立TCP。

  三次握手：

面试八股 | 计算机网络 | TCP三次握手 - 力扣（LeetCode）

wireshark抓包分析TCP三次握手_Hulk%的博客-CSDN博客_tcp三次握手抓包分析

  TCP连接的建立采用跟客户-服务器模式。主动发起连接建立的应用进程叫做客户端，而被动等待连接建立的应用进程叫做服务器。TCP连接建立的过程叫做握手，握手要在客户端和服务器端交换3个TCP报文。

最初TCP两端的程序都处于CLOSED（关闭）状态，一开始B的TCP服务进程优先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务器进程就处于LISTEN状态，等待客户端的连接请求，A的TCP客户端进程也是首先创建传输控制块TCB，然后打算建立TCP连接时，向B发出连接请求报文段，这时首部中的同步位SYN=1（在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1，因此SYN置为1就表示这是一个连接请求或连接接受报文。）,同时选择一个初始序号seq=x,TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号，这时TCP客户进程进入同步已发送状态（SYN-SENT）状态。

B收到连接请求报文段以后，如同意建立连接，则向A发送确认，在确认报文段中应该把SYN位和ACK位都置为1,确认号ack=x+1,同时也为自己选择一个初始序号seq=y.这个报文段也不能携带数据，但同样要消耗掉一个序号，这时TCP服务器进程进入SYN-RCVD（同步收到）状态。

TCP客户端进程收到确认后还要向B给出确认，确认报文段的ACK为1，确认号ack=y+1,而自己的序号seq=x+1,ACK报文可以携带数据，但是如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1,这时TCP连接已建立，A进入已建立连接（ESTABLISHED）状态，当B收到A的确认后，也进入ESTABLISHED状态。

三次握手可以改为四次握手，效果是一样的，B给A发送的报文段也可以拆成两个，先发送一个确认报文段（ACK=1,ack=x+1）,然后再发送一个同步报文段（SYN=1，sey=y）

为什么A要最后一次发送确认呢？考虑这样一种情况，A发出第一个链接报文，在某些网络节点长时间滞留了，结果A再次发来连接请求，然后B发确认，然后A向B发确认连接建立，数据传输，连接释放后，B收到滞留的第一个请求，于是B向A发确认，如果A最后一次确认不要了，那么这个连接就建立起来了。

确认ACK（ACKnowledgment）      仅当ACK = 1时确认号字段才有效，当ACK = 0时确认号无效。TCP规定，在连接建立后所有的传送的报文段都必须把ACK置为1。

wireshark抓包分析TCP三次握手

首先把包抓出来：

第一次握手 客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接：

数据包的关键属性如下：

SYN ：标志位，表示请求建立连接

Seq = 0 ：初始建立连接值为0，数据包的相对序列号从0开始，表示当前还没有发送数据

Ack =0：初始建立连接值为0，已经收到包的数量，表示当前没有接收到数据

 [SYN + ACK]: 标志位，同意建立连接，并回送SYN+ACK

Seq = 0 ：初始建立值为0，表示当前还没有发送数据

Ack = 1：表示当前端成功接收的数据位数，虽然客户端没有发送任何有效数据，确认号还是被加1，因为包含SYN或FIN标志位。（并不会对有效数据的计数产生影响，因为含有SYN或FIN标志位的包并不携带有效数据）

第三次握手的数据包

客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1,

数据包的关键属性如下：

ACK ：标志位，表示已经收到记录

Seq = 1 ：表示当前已经发送1个数据

Ack = 1 : 表示当前端成功接收的数据位数，虽然服务端没有发送任何有效数据，确认号还是被加1，因为包含SYN或FIN标志位（并不会对有效数据的计数产生影响，因为含有SYN或FIN标志位的包并不携带有效数据)。

就这样通过了TCP三次握手，建立了连接。开始进行数据交互

为什么需要三次握手？

三次握手：严格来说即使N次握手也不能保证双方百分百成功建立连接，因为只要最后一次确认丢失，双方就处于一种信息不对称的状态（这种不对称是当前时间点的不对称，对这个时间点以前的信息对称的）。成功建立连接的标志应该是：互相都知道对方都准备好传输数据，这种情况至少需要三次握手。以A为客户端，B为服务器端为例， 假如只使用一次握手：A向B发送了一个报文，然后双方都认为连接建立，这种情况其实已经相当于UDP无连接了，没有任何意义；假如使用二次握手：A向B发送syn报文，B向A发送一个ACK报文（可能也报文syn字段），这时B已经知道了A要向他建立连接，双方的信息基本对称了，然而此时B到A的报文段有可能丢失，那么A就无法判断B是否收到了自己的连接请求，A状态未知，B也知道A的这种情况，所以需要第三次握手，即A想B发出ACK报文，这时双方都知道对方都已经准备好传输数据（之前的的时间点准备好，当前的状态仍然是不对称）。

以上只是考虑了数据包丢失的情况，如果出现数据包延迟达到，就会出现“已失效的连接请求报文段”，比如A向B发送的连接请求报文延迟达到B，B误以为是新的连接请求，然后接受发出ACK报文，如果是二次握手B此时就进入了establishing 状态，但这是种错误的状态，因为A早已放弃这个连接了。

总之多少次握手都无法保证百分百成功建立连接，因为最后一次报文可能出现丢失，延迟达到等各种情况。三次握手成功只是能说明双方现在已经有相当高的概率可以正常通信了。

 四次挥手：

 

数据传输完成后，通信双方都可以释放连接，现在A和B都处于已建立连接（ESTABLISHED），A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，A把链接释放报文段首部的终止控制位FIN（FINis，意思是“完”“终”用来释放一个连接。当FIN=1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。）置为1，其序号seq=u,他等于前面已经传送过的数据的最后一个字节的序号加1，这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认，FIN报文段即使不携带数据他也消耗掉一个报文段。B收到连接释放的报文以后即发出确认，确认号是ack=u+1,而这个报文段自己的序号十v,等于B前面已经传送过的数据的最后一个字节的序号加1.然后B就进入了CLOSE-WAIT（关闭等待状态）。TCP服务器进程这时通知高层应用进程，因而从A到B这个方向的连接就释放了。这时的TCP连接处于半关闭（half-close）,即A已经没有数据要发送了，但B若发送数据A仍要接收，也就是说从A到B这个方向的连接并没有关闭

A收到来自B的确认以后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接，这时B发出连接释放报文段必须是FIN=1，现假定B的序号为w(在半关闭状态B可能又发送了一些数据)，B还必须重复上次已发送过的确认号ack=u+1.这是B就进入了LAST-ACK（最后确认状态），等待A的确认。A在收到B的连接释放报文后，必须对此发出确认，在确认报文段中把ACK置为1，确认号ack=w+1，而自己的序号是seq=u+1,然后A进入TIME-WAIT（时间等待）状态，现在TCP的连接还没有被释放掉，必须经过时间等待计时器设置的时间2MSL后，A才进入到CLOSED状态，时间MSL叫做最长报文段寿命，当A撤销了相应的传输控制块TCB后，就结束了这次tcp连接。

为什么需要四次挥手？

四次挥手：四次挥手实际上就是两个FIN报文和两个ACK报文，这四个报文必不可少。A没有数据要发送了必然会向B发送一个fin报文，B必然要回复个ACK报文。为什么B不能学习三次握手将fin和ack合二为一？，因为B受到fin报文后要通知上层应用程序，上层应用程序可能数据没有发送完毕，这时就不能发送fin，即使是发送完了，B也不应该将两者合二为一（通知上层应用可能需要很多时间，这些都是不确定的），最好的方法就是先发送ACK告诉对方，然后在合适的时机发送自己的fin。

在 TCP C/S 模式下，当 TCP 客户端想断开的时候，不能用 shutdown 和 closesocket 与 TCP 服务器断开，只有让 TCP 服务器端主动断开（TCP 客户端被动断开），TCP 客户端的端口才能立刻被释放。

4.面试题：

1.TCP协议和UDP协议的区别是什么？

TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的

TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。

TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。

TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率

TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。

TCP面向的是字节流的服务，UDP面向的是报文的服务。

TCP介绍和UDP介绍

2.请详细介绍一下TCP协议建立连接和终止连接的过程？

3.三次握手建立连接时，发送方再次发送确认的必要性？

主 要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结 点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次 新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多 资源就这样白白浪费了。

4.四次挥手释放连接时，等待2MSL的意义？

第 一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK 报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。

第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

5. 常见的应用中有哪些是应用TCP协议的，哪些又是应用UDP协议的，为什么它们被如此设计？

以下应用一般或必须用udp实现？

多播的信息一定要用udp实现，因为tcp只支持一对一通信。

如果一个应用场景中大多是简短的信息，适合用udp实现，因为udp是基于报文段的，它直接对上层应用的数据封装成报文段，然后丢在网络中，如果信息量太大，会在链路层中被分片，影响传输效率。

如果一个应用场景重性能甚于重完整性和安全性，那么适合于udp，比如多媒体应用，缺一两帧不影响用户体验，但是需要流媒体到达的速度快，因此比较适合用udp

如果要求快速响应，那么udp听起来比较合适

如果又要利用udp的快速响应优点，又想可靠传输，那么只能考上层应用自己制定规则了。

常见的使用udp的例子：ICQ,QQ的聊天模块。

参考博客：https://www.cnblogs.com/wodemeng/p/4583506.html

         https://www.cnblogs.com/newwy/p/3254029.html
         TCP的运输连接管理 - gaoyanqing - 博客园

         https://www.cnblogs.com/zmlctt/p/3690998.html