计算机网络——运输层（可靠传输、超时重传、选择确认、流量控制和拥塞控制、TCP连接和释放）
TCP可靠传输的实现
我们假定数据传输只在一个方向进行，即A发送数据，B给出确认。这样的好处是使讨论限于两个窗口，即发送方A的发送窗口和接收方B的接收窗口。
以字节为单位滑动窗口
发送方构造窗口
窗口前沿和后沿的移动情况
描述发送窗口的状态需要三个指针
传输步骤详解
注意，这里使用的累积确认和超时重传机制：这样在延迟的时间内收到多个连续的包，可以累积一个包，确认通过延迟和累计确认的方式，减少了回复确认包的数量。
窗口和缓存的关系
在TCP的面向字节流的特点得知：把字节流写入TCP的发送缓存，接收方的应用进程从TCP的接收缓存中读取字节流：
首先我们要明确两点：
第一，缓存空间和序号空间都是有限的，并且都是循环使用的。
第二，由于缓存或窗口中实际的字节数可能很大，因此图例仅仅是个示意图，并不代表具体大小数值关系
从此图也可以得知发送缓存和发送窗口不是一个东西
发送缓存
发送缓存用来暂时存放:
(1)发送应用程序传送给发送方TCP准备发送的数据;(2)TCP已发送出但尚未收到确认的数据。
发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除，因此发送缓存和发送窗口的后沿是重合的。
发送应用程序最后写入发送缓存的字节减去最后被确认的字节，就是还保留在发送缓存中的被写入的字节数。
发送应用程序必须控制写入缓存的速率，不能太快，否则发送缓存就会没有存放数据的空间。
接收缓存
接收缓存用来暂时存放:
(1)按序到达的、但尚未被接收应用程序读取的数据;(2)未按序到达的数据。
如果收到的分组被检测出有差错，则要丢弃。
如果接收应用程序来不及读取收到的数据，接收缓存最终就会被填满，使接收窗口减小到零。
反之，如果接收应用程序能够及时从接收缓存中读取收到的数据，接收窗口就可以增大，但最大不能超过接收缓存的大小。
强调三点重要的关系
第一，虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后性
另外，发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。
第二，TCP通常是把不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
第三，TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。需要注意两点：
- 一是接收方不应过分推迟发送确认，否则会导致发送方不必要的重传，这反而浪费了网络的资源。
- TCP标准规定，确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段，则必须每隔一个报文段就发送一个确认。
- 二是捎带确认实际上并不经常发生，因为大多数应用程序很少同时在两个方向上发送数据。
第四、TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此，每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时，一定要弄清楚是哪一方的窗口
超时重传时间
RTTs
TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到的相应的确认时间。这两个时间之差就是报文段往返时间RTT
超时重传时间RTO的计算
往返时间测量相当复杂
通过上述两个例子可以看出:当发送方出现超时重传后，收到确认报文段时是无法判断出该确认到底是对原数据报文段的确认还是对重传数据报文段的确认,也就是无法准确测量出RTT，进而无法正确计算RTO。
练习
选择确认SACK
若收到的报文段无差错只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据?
选择确认(Selective ACK)就是一种可行的处理方法。
说明SACK的工作原理
左边界指出字节块的第一个字节的序号，但右边界减1才是字节块的最后一个序号。
TCP的流量控制
若发送方数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方发送速率不要太快，要让接收方来得及接收。
TCP的流量控制的机制
序号201到300的数据封装成一个TCP报文段发送出去。但该报文段在传输过程中丢失了。这可能由于误码被路由器丢弃或路由器繁忙而丢弃。
注意，上述为第一次流量控制的过程。
超时重传及第二次流量控制
第三次流量控制
TCP持续计时器
设主机B向主机A发送了零窗口的报文段后不久，主机B的接收缓存又有了一些可用空间。于是主机B向主机A发送了接收窗口等于300的报文段。
然而，这个报文段在传输过程中丢失了主机，A会一直等待主机B发送的非零窗口的通知，而主机B会一直等待主机A发送的数据。
TCP持续计时器的原理
当主机A的持续计时器超时时，主机A立刻发送一个仅携带1字节数据的零窗口探测报文段。
假设主机B此时的接收窗口值又为零了，主机B就在确认这个零窗口探测报文段时，给出自己现在的接收窗口值为零。主机A再次收到零窗口通知，就再次启动一个持续计时器。当持续计时器超时时，主机A立刻发送一个零窗口探测报文段。
假设主机B此时的接收缓存又有了一些可用的空间，于是将自己的接收窗口调整为300。主机B就在确认这个零窗口探测报文段时，给出自己现在的接收窗口值为300，这样就打破了死锁的局面。
Q1:A发送的零窗口探测报文段到达B时，如果B此时的接收窗口值仍然为0,那么B根本就无法接受该报文段，又怎么会针对该报文段给A发回确认呢?
A1：实际上TCP规定:即使接收窗口值为0，也必须接受零窗口探测报文段、确认报文段以及携带有紧急数据的报文段。
Q1：如果零窗口探测报文段丢失了，还会打破死锁的局面吗?
A1：回答是肯定的。因为零窗口探测报文段也有重传计时器，当重传计时器超时后，零窗口探测报文段会被重传。
例题
TCP传输效率
应用进程把数据传输到TCP的发送缓存后，剩下的发送任务就由TCP来控制了，且可以用不同的机制来控制TCP报文段的发送时机。
三种机制来控制TCP报文段发送时机
第一种：TCP维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节，就组装一个TCP报文段发送出去。
第二种：发送方的应用进程指明要求发送报文段，即TCP支持的推送操作
第三种：发送方的一个计时器期限到了，将已有的缓存数据装入报文段（但长度不能超过MSS）发送出去。
TCP传输的两大问题——控制发送时机
TCP传输的两大问题——糊涂窗口综合症
要解决此问题，可以让接收方等待一段时间，使得接收缓存已有足够容纳一个最长的报文段，或者等到接收缓存已有一半空间。
TCP的拥塞控制
在计算机网络中的链路容量（带宽）、交换节点的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏，这种情况叫做拥塞。
流量控制与拥塞控制
从控制理论的角度来看拥塞控制这个问题。
流量控制：往往是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便接收端来得及接收。
拥塞控制：防止过多数据注入到网络中，这样可以使网络中的路由器或链路不至于过载。
两者的异同
都是控制源点发送速率，一个点对点地控制，一个全局性控制。
拥塞控制图像
横坐标是提供的负载，也称为输入负载或网络负载 。纵坐标是吞吐量，代表单位时间内从网络输出的分组数目。
在吞吐量饱和之前，网络吞吐量应等于提供的负载，故吞吐量曲线是45°斜线；而到达某一程度吞吐量不再增长而保持为水平线，这就说明提供的负载中有一部分损失掉了。
在实际的网络下，随着提供负载增大，网络吞吐量的增长速率逐渐减小。也就是说吞吐量还未饱和时，就已经有一部分的输入分组被丢弃了。
- 当网络的吞吐量明显小于理想的吞吐量时，网络就进入了轻度拥塞状态、
- 当提供负载达到某一数值时，网络的吞吐量反而随提供的负载的增大而下降，这时网络就进入了拥塞状态。
- 当提供的负载继续增大到某一数值时，网络的吞吐量就下降到零
需要注意：Q1:为什么负载越大，反而容易造成网络拥塞？带宽限制：网络的带宽是有限的，它决定了网络能够同时传输的数据量。当负载增大时，即有更多的数据需要通过网络进行传输，如果这些数据量超过了网络的带宽限制，就会导致网络拥塞
拥塞控制的两种方法
闭环控制
开环控制
衡量拥塞程度的指标：
上述这些指标的上升都标志着拥塞发生的可能性增加。
TCP的拥塞控制算法
为了集中精力讨论拥塞，我们控制以下两个变量：
- 数据是单方面传送的，对方只传送确认报文。
- 接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度来决定。
发送方控制拥塞窗口的原则：只要网络未出现拥塞，拥塞窗口就可以增大，以便将更多分组发送出去；但只要网络出现拥塞，就必须把拥塞窗口减小。
发送方如何判断网络出现拥塞：网络拥塞时，路由器会将来不及处理的分组丢弃；只要发送方未按时收到确认报文，即出现超时，就可以估计出现了拥塞。因此，发送方在超市重传计时器启动时，就判断网络出现了拥塞。
慢开始算法与拥塞窗口
双方建立连接时，拥塞窗口cwnd的初始值被设置为1。这是因为主机刚开始发送数据时，完全不知道网络的拥塞情况。如果立即把大量的数据都注入网络中，就有可能引起网络拥塞。
较好的方法是由小到大逐渐增大发送方的拥塞窗口（慢开始算法）：
发送方给接收方发送名号数据报文段，接收方收到后给发送方发回对零号数据报文段的确认报文段。此时，第一个传输轮次结束，注意，传输轮次是指发送方给接收方。
发送数据报文段后的接收方给发送方发回相应的确认报文段，一个传输轮次所经历的时间其实就是往返时间。
当到达慢算法门值ssthresh=16时，改用拥塞避免算法
又开始使用慢开始算法
之后又是拥塞避免算法：
图像小结：
快重传算法和快开始算法
主机将封装有TCP报文的IP数据报传输到路由器，该数据报首部误码被路由器丢弃，这将导致源主机的重传计时器超时，并误认为出现拥塞，于是将拥塞窗口的值降为1，开启了慢开始算法。
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才捎带确认，而是要立即发送确认，即使收到了失序报文段也要立即发出对已收到报文段的确认回复。
发送方只要一连收到3个重复确认，就可知道现在并未出现网络拥塞，而只是接收方少收到一个报文段，因而立即重传该报文段。
快重传算法步骤如下：
接收方正确接收到M1和M2后都及时发送了确认，现假定未收到M3而接收到了M4。按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及早知道未收到报文段M3。
发送方接着发送了M5、M6，接收方收到后也仍要再次分别发出对M2的重复确认。如此，发送方一个收到4个M2确认，后3个是重复确认，就可知道现在并未出现网络拥塞，而是接收方少收到一个报文段M3，因而立即重传M3。
快恢复算法
发送方现在知道只是丢失个别的报文段。于是不启动慢开始，而是执行快恢复算法
发送方将慢开始门限ssthresh的值和拥塞窗口cwnd的值都调整为当前cwnd值的一半，并开始执行拥塞避免算法。
也有的快恢复实现是把快恢复开始时的cwnd值再增大一些，即cwnd=新ssthresh+3。既然发送方收到了3个重复的确认，就表明有3个数据报文段已经离开了网络。这3个报文段不再消耗网络资源而是停留在接收方的接收缓存中。
可见现在网络中不是堆积了报文段而是减少了3个报文段，因此可以适当把cwnd值增大一些。
练习
发生超时用慢开始算法，三个确认重传采用快重传和快恢复
而且注意题目中询问的是甲的发送窗口。
注意出现超时重传时，慢开始门限要减少一半，且之后开始进行拥塞算法，
在流量控制中，讲过接收窗口会影响发送窗口的大小，在拥塞控制中知道这个关系是取决于拥塞窗口和接收窗口的最小值。
将收到的数据全部存入缓存而不取走，意味着接收窗口会缩小，发送窗口的大小意味多少数据传入，接收数据前的窗口大小减去当前发送窗口大小就是接收数据后的窗口大小。
重新认识到RTT的效果，初次建立连接时不算在RTT中。
一个RRT包括了：从发送上一处的数据——缩小接收窗口——收到确认后修改发送窗口，这个修改是：接收到确认分组时，拥塞窗口翻倍且同时修改接收窗口
快速重传算法
未出现拥塞的前提下的最长时间，即从拥塞窗口从8kb开始使用拥塞避免算法
主动队列管理AQM
假定一个路由器对某些分组的处理时间特别长，那么这就可能使这些分组中的数据部分经过很长时间才能到达终点，结果引起发送方对这些报文段重传，就可能会引起拥塞，于是采取了拥塞控制措施。
TCP拥塞控制与网际层拥塞控制策略有着密切关系。
网络层的策略对TCP拥塞控制影响最大的就是路由器分组丢弃策略，在最简单的情况下，路由器队列通常采用“先进先出”的规则处理到来的分组。而队列长度有限，当队列已满时，以后再到达的所有分组（这些分组都将排在队列尾部）都被丢弃，这叫作尾部丢弃原则。
路由器尾部丢弃往往会导致一连串分组丢失，使发送方出现超时重传，使TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降低到很小的数值。
- 这导致了网络中许多TCP连接（它们源点和终点各不同），这些连接中的报文段通常是复用在网络层中的IP数据报中传送的。
若发生了尾部丢弃，同时使这些TCP进入到慢开始状态，这在TCP术语中称为全局同步
为了避免网络中出现全局同步问题，在1998年提出了主动队列管理。
- 所谓“主动”，就是在路由器的队列长度达到某个阈值但还未满时就主动丢弃IP数据报，而不是要等到路由器的队列已满时才不得不丢弃后面到达的IP数据报，这样就太被动了。
- 应当在路由器队列长度达到某个值得警惕的数值时，也就是网络出现了某些拥塞征兆时，就主动丢弃到达的IP数据报来造成发送方的超时重传，进而降低发送方的发送速率，因而有可能减轻网络的拥塞程度,甚至不出现网络拥塞。
TCP的运输连接管理
TCP是建立连接的协议，运输连接是用来传送TCP报文的。
TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。
因此，运输连接有三个阶段：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接和释放都能正常进行。
TCP建立连接的过程要解决以下三个问题：
- 要使每一方能够确知对方存在
- 要允许双方协商一些参数
- 能够对运输实体资源进行分配
TCP连接的建立采用客户服务器方式，主动发起连接建立的应用进程叫作客户，而被动等待连接建立的应用进程叫作服务器。
TCP的连接建立步骤
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段
一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于收听状态，等待客户的连接请求。此时B处于被动打开链接。
A的TCP客户进程也是首先创建传输控制块TCB。然后，在打算建立TCP连接时，向B发出连接请求报文段。A属于主动打开链接
- 这时首部中同步位SYN=1，同时选择一个初始序号seq=x。TCP规定syn=1的报文段不能携带数据，但要消耗掉一个序号，这时TCP客户进程进入同步已发送状态。
TCP客户进程收到请求后，如同意连接建立，向A发送确认TCP连接请求确认报文段首部中的同步标志位SYN和确认标志位ACK的值都设置为1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y（请注意，这个报文段也不能携带数据，但同样需要消耗一个序号）。
这时TCP服务器进程进入同步收到状态。
TCP客户进程收到B的确认后，还要向B给出确认。
确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1。
TCP标准规定，ACK报文段可以携带数据，如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。
这时，TCP连接已经建立，A进入已建立连接状态。
当B收到A的确认后，也进入已建立连接状态
Q1：“三报文握手”建立TCP连接—使用“三报文握手”，而不是“两报文握手”建立TCP连接的原因。
A1：
当第一次客户端的TCP连接请求报文段传输延迟时，将会超时重传该连接请求报文段，假设经过此次重传后，TCP接收到该报文段后直接进入已建立连接状态（因为是两次握手），并且传输完成后释放连接进入关闭状态。
此时第一次的客户端的TCP连接请求报文传输到服务器，服务器接收后进入连接建立状态，而客户端收到该报文后因为未发送连接请求报文段而不做出反应，所以会导致服务器资源耗费。
练习
- 发送方的初始序列号在第一次握手时创立=第三次握手的seq
- 接受方的初始序列号在第二次握手时创立=第三次握手的ack
TCP的连接释放
数据传输结束后，通信双方都可释放连接。现在A和B都处于连接建立状态。A的应用进程先向其TCP发出连接释放报文段，并停止发送数据，主动关闭TCP连接。
A把连接释放报文段首部的终止控制位FIN置1，其序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入终止等待1状态（FIN-WAIT-1）。需要注意：FIN报文段即使不携带数据，也要消耗一个序号。
B收到连接释放报文段即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面的已传送过的数据最后一个字节的序号加1。然后B就进入关闭等待状态（CLOSE-WAIT）.
TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了。但B若发送数据，A仍要接收。
A收到B的确认后，就进入终止等待2状态，等待B发出的连接释放报文段。若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假定B的序号为w。B还必须重复上次发送过的确认号ack=u+1。这时B就进入了最终确认状态，等待A的确认。
A在收到B的连接释放报文段后，必须对此发出确认。再确认报文段中的ACK置为1，确认号ack=w+1，而自己的序号是seq=u+1（前面发送过的FIN报文段要消耗一个序号），然后进入到时间等待状态。当经过时间等待计时器设置的时间2MSL，A才进入到CLOSED状态。
Q1：TCP客户进入时间等待状态等待2MSL后才进入关闭状态，这是否有必要？
A1：若客户在终止等待2状态收到B发来的报文后，发送了最后确认报文后进入了关闭状态
若客户发送的该报文丢失，服务器的最后确认状态一直向客户发送最后确认报文，但此时客户已经关闭状态，而服务器却无法进入关闭状态。
练习
“消耗序号”的含义：当发送一个SYN段时，尽管它不包含数据，但它仍然会占用一个序号值。这意味着，在后续的数据传输过程中，第一个数据字节的序号将是SYN段序号加1。因此，我们可以说SYN段“消耗掉了一个序号”，因为它为后续的数据传输预留了一个序号空间。
SYN段指的是三次握手时建立同步这个阶段，对于本题，主机甲发送的序号仍是1001，甲给乙发送的第一个应用层数据字节的TCP序号为1001，因为应用层数据作为数据载荷被封装在TCP报文段中。
这里需要注意第三次握手时的1001后续传输时是未携带数据的
实际在应用层到fin段之前如下：
每个序号仅代表一个整数，若每个整数占用相同数量的字节，范围内的整数数量是：
5000 - 1001 + 1 = 4000
TCP计时保活器
TCP建立连接后，如何知道客户端发生故障？
客户端每向服务器发送一次TCP报文，就会激活一次2小时的保活计时器
若TCP出现故障，不能再发送数据，保活计时器到时后，会每隔75秒发送一个TCP探测报文段，一连发送十个后仍无TCP客户进程响应，就判断这个进程所在主机出现故障，便关闭了这个连接。
原文地址：https://blog.csdn.net/2303_80204192/article/details/141203017
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！