TCP流量控制

在主机B接收到来自主机A的报文段后，它将数据放入它的接收缓存中。但接收缓存是有限的，如果接收缓存满了之后仍有报文段到达，则会发生报文段丢失。为了解决这个问题，我们需要TCP流量控制机制来协调主机A发送数据的速率和主机B应用层进程读取数据的速率。（注意，流量控制和拥塞控制相似但完全不同，流量控制解决的是到达之后主机中的事情，而拥塞控制解决的是到达之前网络核心中的事情）
与拥塞控制机制类似，流量控制机制也维护一个称作接收窗口的变量。：请添加图片描述
其中RcvBuffer是接收缓存的字节量，rwnd是还空闲的接收缓存，即接收窗口的字节量。为了计算rwnd，我们维护两个红线所代表的字节的编号，命名为LastByteRead和LastByteRcvd：

LastByteRead（右边红线）：主机B应用层进程从缓存读出的最后一个字节的编号。
LastByteRcvd（左边红线）：放入主机B接收缓存的最后一个字节的编号。

因此，计算rwnd的公式为：
在这里插入图片描述
有了rwnd之后，主机B在报文中将这个信息告知主机A。对于主机A来说，它维护两个变量LastByteSent和LastByteAcked，这两个变量的差就是主机A发送到连接中但还没确认的数据量，也就是在主机A视角中，这些数据是在网络中进行传输，还没有放入缓存的。因此，主机A需要保证：
在这里插入图片描述
最后，考虑当rwnd=0的情况。此时主机A不会向主机B发送报文，但如果主机B也不向主机A发送报文，那么即使rwnd已经被开辟出来，主机A也不会知道。因此，在rwnd=0时，主机A继续向主机B发送只有一个字节的报文段以得到来自主机B的确认报文，这些确认报文中含有关于rwnd的更新，最后，当主机A发现确认报文中的rwnd值非0时，停止发送一字节报文段，继续发送在它发送缓存中的数据。
不同于TCP，UDP不提供流量控制服务。这意味着如果一个进程的套接字的接收缓存已满，有新数据再到达时这个数据将会丢失。

TCP连接管理

本节中考虑如何建立和拆除一个TCP连接。

建立TCP连接

在这里插入图片描述
TCP连接建立的过程称为“三次握手”。

客户TCP向服务器TCP发送一个特殊报文段，这个报文段中没有应用层数据，它的SYN标志字段设为1，因此也被称为SYN报文段。在序号字段，它选择一个随机序号client_isn并发送给服务器作为初始序号。综合这些信息，客户在第一次握手中告诉服务器：我要建立一个TCP连接，client_isn是我的初始序号。
服务器TCP收到来自客户TCP的SYN报文后，也向客户发送一个SYN报文，其中确认号字段设为client_isn+1，表示已经成功确认收到带有初始序号的报文；在序号字段，它也选择一个随机序号server_isn作为初始序号。在这份作为第二次握手的报文中，服务器告诉客户：我收到了你的第一次握手报文，server_isn是我的初始序号。 这份报文也被称作SYNACK报文段。
在前两次握手中，实际上已经建立TCP连接。第三次握手实际上也可以算作正式传输数据的第一个报文，但由于它的确认号字段设为server_isn+1，因此这个报文也可以作为对第二次握手报文的确认，我们将它也纳入握手过程，构成“三次握手”。

拆除TCP连接

在这里插入图片描述
TCP连接拆除的过程被称为“四次挥手”。注意，TCP连接是全双工连接，因此也要拆除两次。

客户TCP向服务器TCP发送一个特殊的报文段，其中FIN标志字段设为1。在这个报文段中，客户告诉服务器：我要进行客户->服务器方向TCP连接的拆除。
服务器TCP向客户TCP发送确认报文。
服务器TCP重复客户TCP的过程，发送特殊报文段并接收响应报文，拆除服务器->客户方向连接的拆除。

TCP状态的转换

在连接和拆除过程中，客户和服务器双方的TCP状态都会改变。

客户TCP

在这里要解释的就是TIME_WAIT状态。在这个状态下，客户TCP等待一段时间（一般是30秒），如果最后的确认报文发生丢包或其他问题，客户TCP进行重传。
服务器TCP

这个有限状态机很简单，不多赘述。

TCP拥塞控制

我们将从理想情况开始，逐渐构造出TCP协议中进行拥塞控制的机制。

情况1：两个发送方，一个无限缓存的路由器

为了简化问题，在这种情况下，假定我们的协议只进行发送数据，不进行任何其他功能，且每一个报文段都不会丢包；两台主机发送数据的速率也假定相等：
在这里插入图片描述
注意数据进入路由器缓存和被推出路由器缓存的速率小于主机发送数据的速率。设链路的传输速率为R，且两台主机共享一条链路，我们可以画出如下两个图：

第一个图是主机吞吐量和主机发送速率之间的关系。小于R/2时，吞吐量和发送速率相等，大于R/2时，吞吐量受限于链路速率；第二张图是时延与主机发送速率之间的关系。由于数据在路由器缓存中会排队造成时延，因此时延量随主机发送速率的增加而快速增长，在大于R/2时，由于路由器缓存中的数据只会不断增加，因此时延可以无限大。因此，当分组的到达速率接近链路容量时，分组经历巨大的排队时延。

情况2：两台主机，一台具有有限缓存的路由器

在这里插入图片描述
在路由器缓存有限的情况下，分组有可能会被路由器丢弃，因此协议会重传数据。那么发送方发送的数据中包括两部分：初始数据和重传数据。设λ_in^’是运输层发送数据的速率（包括初始数据和重传数据），有时它也被称作网络载荷。
不难看出，在这种情况下，网络性能完全取决于重传数据的数量。下面是发送速率与主机吞吐量（即主机接收之前未接收过的数据）之间的关系：

在这里插入图片描述

当无需重传时，性能与情况1相同，用a）表示。
发送方确定一个分组丢失时才重传（比如将超时时间设置为1年）。在实践中确定吞吐量与发送速率的关系约如图b），即初始数据：重传数据=2:1
发送方在超时机制下重传。此时有可能发生分组未丢失但超时的情况，此时如果我们假定每一个分组都被发送两次，则画出的图如c）。

情况3：四个发送方，有限缓存的多台路由器

请添加图片描述
在图中，我们建立了从A到C的双工连接（分别表示为A-C，C-A）和从B到D的双工连接。

当发送速率很小时，数据都正常发送。
当发送速率很大时，我们选择一条链路来看。注意A-C连接和B-D连接共享的R2路由器所在线路，如果A-C连接和B-D连接发送速率都很大，会导致它们在同一条链路上竞争流量，导致大量分组被丢弃，分组的重传又会恶化这种情况。

在实践中，我们可以分析出下图来表示吞吐量与发送速率的关系：
请添加图片描述
注意，当发送速率接近R/2时，可以参考情况2的c），吞吐量不能到达R/2。
另外，如果A-C连接发送的分组在R2路由器被丢弃了，那么它所使用的R1路由器所在链路的资源也会被浪费，由此我们可以看到，当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组所用的传输容量都被浪费掉了。
请添加图片描述
我是霜_哀，在算法之路上努力前行的一位萌新，感谢你的阅读！如果觉得好的话，可以关注一下，我会在将来带来更多更全面的知识讲解！