计算机网络Day7

TCP如何实现可靠传输

• 停止等待协议

超时重传的时间要大于数据包一个往返时间RTT

 

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。

这种可靠传输的协议常称为自动重传请求ARQ(Automatic Repeat reQuest)。

ARQ表明重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

停止等待协议的优点是简单，但缺点是信道利用率太低。

U是信道利用率，Td是发数据包的时间，RTT是传输往返时间，Ta是收数据包的时间。

解决信道利用率低的问题：流水线传输。

发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。

由于信道上一直有数据不间断的传送，这种传输方式可获得很高的信道利用率。

流水线传输如何进行确认：连续ARQ协议。

发送方维持一个发送窗口，发送窗口中的数据包可以连续发送不用等待确认。当有数据包确认之后，数据包从发送缓存中扔掉，相当于窗口移动。这就是流水线传输，使用滑动窗口技术来实现可靠传输。

接收方一般采用累积确认的方式，即接收方应答当前连续收到的最后一个数据包。优点是容易实现，信道利用率高。缺点是不能向发送方反映接收方已经收到的所有分组信息。

以字节为单位的滑动窗口

TCP的流量控制

根据图片来理解

B接收有一个缓存大小，当B接收了部分数据之后会根据自己缓存剩余大小来调整接收滑动窗口的大小，A发送端会根据B接收滑动窗口大小来调整发送滑动窗口大小。当B缓存满时，B接收滑动窗口变为0，A发送滑动窗口也变为0，等待B读取数据。当B清除缓存时，B窗口又可以相应变大，继续接收数据。

这就解决了通信两端处理时间不一样的问题，实现了流量控制。

如果接收端发送的划窗调整报文丢失怎么办？----发送端会定时向接收端发送了解接收端划窗信息的报文，解决一直等待的问题。

TCP拥塞控制

• 慢开始和拥塞避免

拥塞窗口执行慢开始算法由1指数增长到慢开始门限-->只要网络未出现拥塞，执行拥塞避免算法，加法增大拥塞窗口-->一旦网络出现拥塞，慢开始门限ssthresh立即变为出现拥塞时窗口的一半，拥塞窗口cwnd变为1，执行慢开始算法。

拥塞避免并非完全能够避免拥塞，利用以上的措施要完全避免网络拥塞还是不可能的。
拥塞避免是说在拥塞避免阶段吧拥塞避免窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

• 快重传和快恢复

快重传算法：如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。重新设置慢开始门限 ssthresh为当前拥塞窗口的一半，与慢开始不同之处是拥塞窗口 cwnd 不是设置为 1，而是比ssthresh稍大一点，执行拥塞控制算法。

FRR的优势：

在TCP/IP中，快速重传和恢复(fast retransmit and recovery，FRR)是一种拥塞控制算法，它能快速恢复丢失的数据包。没有FRR，如果数据包丢失了，TCP将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了FRR，就不会因为重传时要求的暂停被耽误。 当有单独的数据包丢失时，快速重传和恢复(FRR)能最有效地工作。

A发送窗口的上限：

拥塞窗口和B计算机的接收窗口较小的一个

TCP传输连接：

连接建立，数据传送，连接释放。发起主动请求的是Client，被动打开的是Server。

• TCP连接建立(三次握手Three_)

(1)第一次握手:Client将标志位SYN置为1，随机产生一个序号seq=x, 并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

(2)第二次握手:Server端收到数据包后由标志位SYN=1得知Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1,随机产生一个序号seq=y，并将数据包发送给Client以确认连接请求，此时Server进入SYN_RCVD状态。

(3)第三次握手:Client收到确认后，检查ack是否为x+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，如果正确则建立连接成功，Client和Server都进入ESTABLISHED状态

为什么要三次握手，两次不行吗？

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

在两次握手的情况下：Client发送了第一个请求连接并且没有丢失，只是在网络中滞留时间太长。这时，由于Client迟迟没能收到Server的确认，以为Server没有收到，于是又发了一个建立连接的请求并完成了两次握手，传输数据，然后关闭连接。然而这时第一个请求到达了Server端，由于两次握手的机制，Server端立即建立起连接，这将导致不必要的错误和资源浪费。

三次握手的情况下：就算第一次的请求到达Server，Server发送SYN和ACK并不能使Client回复确认，由于Server收不到确认，就知道Client并没有请求连接。

Server端易受SYN攻击？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN攻击。

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

• TCP连接释放(四次挥手 Four-Way Wavehand)

(1)第一次挥手:Client发送一个FIN，seq=u，用来关闭Client到Server的数据传输，Client进入FIN_WAIT_1状态。

(2)第二次挥手:Server收到FIN后，发送一个ACK给Client，ack=u+1，seq=v，Server进入CLOSE_WAIT状态。此时TCP出于半关闭状态。

(3)Client收到确认后，进入FIN_WAIT_2状态，等待Server释放连接。

(4)第三次挥手:当Server不再有数据需要发送时，发送一个FIN和ACK，seq=w，ack=u+1，用来关闭Server到Client的数据传输，Server进入LAST_ACK状态。

(5)第四次挥手:Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK，seq=u+1，ack=w+1，然后等待2MSL后进入CLOSED状态。

(6)Server收到确认后，进入CLOSED状态。

为什么要延时等待2MSL？

保证Client最后一个发送的ACK报文能够到达Server端，如果中途丢失，Server会超时重传FIN和ACK报文。而Client能在2MSL时间内收到这个重传的报文，接着Client重传一次确认报文ACK，并重启计时器再计时2MSL。如果不等待而直接进入CLOSED状态，那么Server端很有可能就无法正常关闭。

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

因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。ACK报文是用来应答的，SYN报文是用来同步的。

而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但还是可以接收数据的，服务端未必在这个时候都把数据发完了，等待数据都发完时再发送FIN报文给对方来表示同意关闭连接。因此，服务端一般会把ACK和FIN分开发送。