计算机网络（谢希仁版）——第五章回顾

Posted 2020-10-04

　　为什么有了IP层，还需要运输层？

　　从IP层的角度来看，网络通信的双方是两台主机，然而实际上，网络通信的双方应为两个应用或者说进程，因此数据仅仅指出源主机和目标主机是不够的。而指明数据“源进程”和“目标进程”的工作就是运输层负责的。此外，IP层并不负责数据内容的差错检测（为了减轻网络路由器的压力），只对IP分组的首部进行检测，而运输层则会对数据内容进行差错检测（这一工作在主机处完成，不会对路由器造成压力）

 

　　运输层是如何指明“源进程”和“目标进程”的？

　　运输层实际上并没有指明“源进程”和“目标进程”，因为通信双方无法确认对方主机上的进程，而且有时候发送方需要目标方对数据进行处理，但不需要知道目标方是哪个进程处理的数据（比如我们向某个服务器上传文件，但我们不需要知道该服务器处理此任务的进程是什么）。所以运输层采用的是“协议端口号”，简称端口号，来指明“源”和“目标”。运输层只要将数据传递给目标主机的目标端口即可，至于目标端口是目标主机的哪个进程负责，并不重要。

 

　　并且由此可见，网络中的进程通信，不仅要知道对方的IP地址，还需要知道对方的端口号。

 

　　

 

　　运输层有哪些协议？

　　主要有用户数据报协议UDP（User Datagram Protocol）和传输控制协议TCP（Transmission Control Protocol）。

 

　　UDP和TCP的主要差异是什么？

　　UDP的特点就是“尽最大努力但不一定可靠”，TCP的特点则是“面向连接、可靠”

 

　　UDP是怎样工作的？

　　简单地说：将应用层报文装入UDP用户数据报，再将UDP用户数据报装入IP数据报。在UDP处不进行划分，若数据过长，则在IP层进行分片。

　　

 

 

　　此外，若接收方发现UDP数据报的目标端口没有对应进程，则通过ICMP发送“端口不可达”报文给发送方，也就是第四章中traceroute应用的原理。

 

 

　　TCP的特点是什么？

　　1.面向连接：TCP通信的双方在开始通信前必须建立TCP连接，通信结束后必须释放TCP连接

　　2.面向字节流：TCP通信双方均有发送缓存和接收缓存，从应用层传下来的报文存放在发送缓存内，然后根据当前状况决定从发送缓存中提取多少字节组成报文段发送出去；从另一方接收到的TCP报文存放在接收缓存内，然后进程在合适时间读取接收缓存内的数据。

 

　　什么是TCP连接？

　　TCP连接是一个抽象的概念，一条TCP连接有且只有两个端点（套接字，socket），一个套接字即一个IP地址与一个端口号

　　

 

 

　　TCP提供可靠服务的原理是什么？

　　根本原理就是“停止等待协议”，该协议简单的说就是：发送方发一份数据，接收方若收到就回一个“确认”，发送方收到确认就发下一份数据，若发送方超过一定时间依然没收到“确认”则自动重传原数据，简称超时重传。

　　

　　此外该协议规定，如果接收方发回的确认丢失，发送方依然重传原数据，接收方再次收到相同数据则丢弃并再次发送确认。如果接收方发回的确认迟到，则发送方收下该确认不作处理。

　　

　　使用这样的停止与等待协议，就可以在不一定可靠的网络上实现可靠的通信或者说数据传送。而这样的协议通常称为自动重传请求ARQ（Automatic Repeat reQuest），因为不需要接收方来请求发送方重传，重传是自动进行的。

　　但是，简单的停止等待协议的信道利用率太低，因为每次都必须等待确认才能进行下一次发送

　　

　　解决的办法是利用流水线思想，实现连续ARQ协议，这也是TCP实现可靠传输的根本。

　　

　　

　　

　　连续ARQ协议是怎样的？

　　

 

　　

 

　　TCP报文段的首部格式是怎样的？

　　

　　

 　　

　　

　　

　　

 　　

 

 

　　TCP的可靠传输是怎样的？

　　其原理就是连续ARQ，但在TCP中叫做滑动窗口协议，简要如下

　　

　　而当发送方A收到接收方B的确认后，就可以将发送窗口前移。

　　

 

 

　　

　　TCP是如何确定重传时间的？

　　发送方记录从报文段发出到收到确认所耗费的时间，即报文段往返时间RTT，根据RTT计算出超时重传时间RTO

 

　　若超时重传后收到了确认，但这个确认其实是迟到的确认，会对RTO的计算造成怎样的影响？该如何解决？

　　

　　解决的办法有两种：

　　1.只要是重传的报文段，不对其往返时间采样

　　方法1容易引起新的问题，假设原RTO为x，突然间RTT增加了并导致了重传，使得理论上RTO应改为1.5x，但由于没有对重传的RTT采样，RTO依然为x，这样一来后面的报文段将不断的“重传-不采样”，因为RTO并没有更新。

　　解决方法是改进1，即方法2.每当报文段重传，就增加RTO，典型做法为使RTO变为2倍，直至没有重传发生，再按RTT采样计算方式重新确认RTO。

 

　　

　　如果出现接收到的报文段没有出错，如下图，只是缺失一部分或者未按序到达，该怎么办？

　　

　　典型做法是当首次出现缺失或失序时即发送最小确认号，如上图的情形，接收方依然发送1001的确认号给发送方。但是这种做法比较浪费资源，所以TCP支持选择性确认SACK。要想使用SACK，双方必须在建立TCP连接时即确定允许SACK，使用时利用TCP报文段首部的“选项”字段（可变长）指明字节块的边界，受限于首部长度上限，一个TCP报文段最多指明4个字节块的边界。

 

　　

　　什么是TCP的流量控制？

　　简单地说就是控制发送方的发送速度，以保证接收方来得及处理数据。在TCP中的做法就是令接收方发送的确认报文段中包含自身的接受窗口大小，发送方则根据接收方接收窗口的大小来调整自己的发送窗口。

　　

 

　　什么是TCP的拥塞控制？

　　流量控制是“针对接收方”的，而拥塞控制则是“针对网络状况”的。当网络的负载很大时，发送方发出去的分组很容易被路由器丢弃，而丢弃又会导致发送方重传，最终网络可能不堪重负而瘫痪，所以发送方必须考虑到网络的拥塞情况来决定是否发送数据以及发送数据的速率该是多少。

 

 

　　TCP是如何实现拥塞控制的？

　　TCP的拥塞控制是四种算法的综合：慢开始、拥塞避免、快重传和快恢复

　　1.慢开始

　　即发送方维护一个拥塞窗口cwnd，发送方的发送窗口必须小于cwnd和接收方接收窗口中更小的那个。初始时cwnd设为一个最大报文段长度MSS，如果发送方发送一次报文段并且按时收到了确认则令cwnd加倍，否则令cwnd重置为1（确认超时或丢失时可以认为网络发生了拥塞，因为现在的通信线路质量较好，不容易出现传输出错导致的分组丢失）。由于cwnd一开始较小，所以叫做慢开始，基本原理就是“先传少一点，没有问题就传多一点，以此类推”

　　2.拥塞避免

　　如果只是按照慢开始算法的“没有拥塞则加倍cwnd”，那么cwnd的增加就会过快，将会很容易“触发”网络拥塞，所以TCP设置了一个慢开始的上限ssthresh，当cwnd超过ssthresh之后，cwnd不再是加倍增加，而是每经过一个轮次（没有拥塞的情况下）就+1MSS，同时ssthresh也+1MSS，cwnd的增长改为线性增长。此外，如果遇到了拥塞，则cwnd重置为1，ssthresh变为当前ssthresh的一半

　　

　　3.快重传

　　快重传即接收方每当收到失序的报文段就立刻向发送方发送重复确认（对失序前的报文段），而发送方连续收到三个重复确认的话就立刻重传缺失的报文段，这样做的目的在于令发送方尽早重传丢失的报文段。

　　

　　4.快恢复

　　即当发生快重传时，很可能网络没有拥塞（如果网络拥塞，不会一连三个报文段送至接收方，发送方也不会一连收到三个确认），因此此时可以考虑不使用慢开始，而是令ssthresh减半，cwnd等于新的ssthresh

　　

 

 

　　TCP的连接建立与释放是怎样的？

　　TCP的连接建立如下图，其中ack为确认号字段，seq为序号字段，注意TCP连接是全双工的，所以B向A发送的报文段也有seq

　　

 

　　TCP连接的释放如下图，注意B在CLOSE-WAIT的阶段依然可以向A发送数据且A此时依然会接收（因为是A提出的结束连接，但B不一定传输完了数据）。A之所以有TIME-WAIT阶段，是因为若B在LAST-ACK阶段超时未收到A发送的最后一个报文段，则B会向A重传FIN=1，ACK=1的报文段，A若重收到该报文段则重发最后一个报文段给B。