【计算机网络】运输层
2017-02-27 23:45
309 查看
运输层
运输层协议为运行在不同主机上的进程提供了逻辑通信功能，使得主机之间好像直接相连一般。运输层协议最重要的便是TCP和UDP协议，这是当今最主流的运输层协议。
运输层提供了不同主机上的进程之间的逻辑通信，网络层提供了主机之间的逻辑通信。他们之间的区别可以用一个例子来说明。假设有A家族和B家族的人，他们会互相通信。A家族由A1来负责收取A家族所有成员的信件，并将这些信件交到邮政服务的邮车上。B家族的B1也做着同样的事情。信封送到之后，由A1分发从B家族发来的信封。这里的A1便是运输层协议，邮车则是网络层协议，A家族是一个主机，A家族的所有成员是主机上的进程。A家族的成员实际上只与A1进行逻辑通信，而A1收齐信封之后则与邮车进行逻辑通信。
网络层协议中有一种协议叫IP协议，即网际协议，它的服务模型为尽力而为交付服务。它会尽最大的努力交付报文段，但不保证报文段中数据的完整性，以及交付的顺序。因此它是不可靠服务。然而，我们知道，建立在不可靠服务之上的TCP协议却是一种可靠的，按序交付的运输层协议，之后我们会讲到。
运输层协议提供的最低限度的服务是：进程到进程的数据交付，差错检查。这也是UDP提供的全部服务。
套接字：
套接字是应用层与运输层之间的一个接口,它有唯一标识符——端口。一个套接字对应一个进程，一个进程可以有多个套接字。运输层实际上并没有将数据直接交给进程，而是将数据交给了一个中间的套接字。而应用层再从套接字中获得数据。
多路分解：
将运输层报文段中的数据交付到正确的套接字的工作成为多路分解。
多路复用：
在源主机从不同套接字中收集数据块，并为每个数据块分装上首部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。
在报文段中，我们指定源端口号和目的端口号，当运输到目的主机时，运输层协议检查报文段中的目的端口号，将其送往对应的套接字。
UDP套接字由一个二元组（目的IP地址，目的端口号）标识
TCP套接字由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）标识
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
标识
对于两个不同源IP或者源端口号，却具有相同目的IP和端口号的UDP，两个报文段将通过相同的套接字被定位到相同进程。
对于两个不同源IP或者源端口号，却具有相同目的IP和端口号的TCP，两个报文段将通过不同的套接字，因为服务器会创建新的套接字来对应不同的TCP连接。
UDP无法提供可靠服务，那么是否意味着它没有用处呢？答案是否定的，有许多应用更适合UDP。原因如下：
① 关于何时、发送什么数据的应用层控制更为精细。
② 无需建立连接。TCP在数据传输前需要3次握手，而UDP不需要，意味着不会产生建立连接的时延。
③ 无连接状态。TCP需要在端系统维护连接状态，而UDP不需要。
④ 分组首部开销小。TCP有20字节的首部开销，UDP只有8字节。
使用UDP的应用也是可以实现可靠传输的，可以通过在应用程序自身中建立可靠性机制来完成，但这并不是无足轻重的任务。这样的好处是应用进程可以进行可靠通信，而无需受制于TCP拥塞控制机制和传输速率限制。
UDP检验和：
对发送方的UDP报文段中所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。（回卷即如果最高位产生进位，则把这个进位与最低位相加），例如0110011001100000、0101010101010101，1000111100001100，相加得到0100101011000010，该和的反码运算结果是1011010100111101，这个数就是我们的检验和。如果该分组中没有差错，那么接收方接收到的数据的和再加上检验和，得到的应该是1111111111111111。如果出现了0，则说明出现了差错。
可靠数据传输原理
TCP是在不可靠的网络层之上实现的可靠数据传输协议。
① 考虑运输层的底层信道是完全可靠的。这种情况下，发送方的状态只是等待上层调用，发送数据。而接收方的状态则是等待下层调用，接受数据并传给应用层。
② 考虑运输层的底层信道并不可靠，有可能发生比特差错。在通常情况下，如果我们接收到一个完整的报文，我们会回以一个肯定确认，如果没接收完整，我们会回以一个否定确认。如果内容接收有误，发送方则会再次传送数据。基于这样重传机制的可靠数据传输协议称为自动重传请求协议（ARQ协议）。ARQ协议需要三种功能：差错检验，接收方反馈和发送方重传。这种情况下，发送方的状态是等待上层调用，被调用后发送数据，进入等待ACK（肯定确认）或者NAK（否定确认）的状态。如果收到NAK，则重传数据并停留在该状态，如果收到ACK则回到等待调用的状态。接收方则是等待下层调用，接收到数据后则利用差错检验，发生差错则发送一个NAK给发送方。没有差错则发送ACK给发送方并且将数据上传到应用层。当发送方等待ACK或者NAK时，他不能继续传输数据，这样的协议被称为停等协议。
③ 然而，上面的方法并没有考虑到ACK分组或者NAK分组也有可能发生丢失的情况（接收方发回的ACK或者NAK都没有差错检验），发送方无法知道接收方是否正确接受了上一块发送的数据。解决这一问题的简单方法是在数据分组中添加一新字段，让发送方对数据分组编号，接收方只需要检查序号就可以确定接收到的分组是否为重传。发送方的新字段为0则说明目前传的是老数据块，为1则说明之前的数据块已经传输完毕，现在传输的是新的数据块。同时我们对接收方发回的ACK/NAK分组也添加差错检验功能，如果发送方收到的ACK或者NAK分组有错，则发送方再次发送数据。
④ 如果收到受损的分组，接收方将发送否定确认NAK，如果不发送NAK，而是对上次正确接收的分组发送一个ACK，发送方收到对同一个分组的两个ACK（即收到冗余ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。发送方发送数据后等待ACK0，如果收到ACK1，则说明当前数据块出现差错，重传，收到ACK0后进入下一个状态，等待再次发送数据，这次发送数据的时候会进入等待ACK1的状态，如果收到ACK0，则说明当前数据块出现差错，重传，收到ACK1后进入初始状态。
⑤ 考虑运输层的底层信道并不可靠，有可能发生比特差错，还有可能发生丢包现象（即整个分组不见了）。发送方发送分组，如果该分组或者接收方对该分组的ACK发生了丢失，如果发送方愿意等待足够长的时间以便确认分组已丢失，则它只需要重传该数据分组即可。不管是数据分组丢失，还是ACK丢失，还是分组或者ACK过度时延，发送方都使用万能的重传来处理。我们使用一个倒计数定时器，每发送一个分组，启动一个定时器，到期后响应定时器中断，或者接收到ACK报文后终止定时器
流水线：
不使用停等协议，允许发送方发送多个分组而无需等待（之前发送分组后需要等待ACK报文），许多从发送方向解说房输送的分组可以被看成是填充到一条流水线中，所以这种技术被称为流水线。这种技术大大提升了吞吐量。协议的发送方必须能够缓存那些已发送但是还没有确认的分组，接收方需要缓存那些已正确接收的分组。解决流水线的差错恢复有两种基本方法：回退N步（GBN），选择重传（SR）
GBN协议
GBN协议中，发送方维持一个长度为N的窗口，窗口之前是已经发送并且被确认的分组，窗口内是已经发送但未被确认的分组和可用但还没被发送的分组，窗口后是不能使用的分组。GBN协议发送方当应用层要求发送报文时，需要检查当前窗口是否已满，未满则产生一个分组将其发送。GBN协议中对序号为n的分组的确认采取累积确认，表明接收方已经正确收到序号为<=n的所有分组。如果发生超时，则采取回退N步的方式，重传所有已经发送但是还没有被确认的分组。它的定时器是针对最早的已发送未确认分组，如果收到一个ACK，但仍有已发送未确认分组，则定时器重新启动，如果没有，则定时器终止。
GBN协议接收方如果序号为n的分组被正确接收并且按序，则接收方为分组n发送一个ACK，其他所有情况下接收方丢弃该分组，并且为最近按序接收的分组重新发送ACK。如果分组k已经接收并且交付，则所有序号<=k的分组也已经交付。
SR协议：
选择重传协议仅仅重传那些它怀疑在接收方出错的分组而避免不必要的重传。它同样使用窗口的模式，从上层接收到数据的处理方式跟GBN协议一样，但是发送方已经收到了对窗口中某些分组的ACK，则将那些标记为已接收，如果收到窗口第一个分组的ACK，则将窗口向前移动到最小序号已发送未确认分组处，如果此时窗口内有未发送分组，则发送之。另一个与GBN协议不同的是，每个分组都拥有自己的逻辑定时器。因为超时发生后只能发送一个分组。而接收方将确认一个正确接收的分组不管是否按序，失序的分组将缓存到所有序号更小的分组接收到为止才交付给上层。对于SR协议而言，发送方和接收方的窗口并不总是一致。
TCP报文段结构：
32比特的序号字段、32比特的确认号字段、16比特的接收窗口字段、4比特的首部长度字段、选项字段、6比特的标志字段：ACK，RST、SYN、FIN、PSH、URG
序号：
TCP三次握手期间设置发送缓存，TCP将数据引导至该连接的发送缓存中，每次可取出并放入报文段中的数据数量受限于MSS（最大报文段长度）。TCP中的数据流根据MSS被分成很多块并且分配序号，当我们发送报文段时，那些序号会被填入32比特的序号字段里。
确认号：
主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。假设主机A收到主机B包含0到535的报文段和900到1000的报文段，仍在等待536，因此A到B的下一个报文段将在确认号中包含536。
可靠数据传输：
TCP的超时定时器可以理解为与最早的未被确认的报文段相关联。
超时发生时，TCP通过重传引起超时的报文段来响应超时。
TCP也使用流水线，使得发送方在 任意时刻都可以有多个已发出但还未被确认的报文段存在。
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
来自接收方的ACK到来时，TCP将ACK的值y与TCP状态变量SendBase，即最早已发送未确认字节比较。TCP采用累积确认，所以y确认了在y之前的所有字节都已经接收。如果y>SendBase,则ACK是在确认一个或多个先前未被确认的报文段，因此发送方更新SendBase变量，如果有未被确认的报文段，TCP重启定时器。
超时间隔加倍：
当超时时间发生时，TCP重传具有最小序号的还未被确认的报文段。只是每次TCP重传时都会将下次超时间隔设置为2倍。
TCP差错恢复机制：
TCP的确认是累计式的（只确认流中至第一个丢失字节为止的字节），但它跟GBN协议还有SR协议并不完全相同，比如，TCP会将正确接收但失序的报文段缓存起来。又比如1到n的报文段中第k个报文段的确认报文丢失，但是其余n-1个报文段在其超时之前顺利到达，如果是GBN协议，会重传k到n的所有报文段，而TCP至多重传一个报文段k，如果k+1的确认报文在k超时之前到达，TCP甚至不会重传k。
流量控制服务：
TCP提供的流量控制服务消除了缓存溢出的可能性。它通过维护一个接收窗口的变量来提供流量控制。TCP不允许已分配的缓存溢出，则必须满足等式接收缓存中的数据流的最后一个字节的编号-接收方的应用程序从缓存读出的数据流的最后一个字节的编号<=接收缓存大小。而发送方在连接的整个生命周期则必须保证发送到连接中但未被确认的数据量<=接受缓存窗口的可用大小。这便是TCP的流量控制服务。而UDP不提供这种服务，对于UDP，如果进程从缓存中读取报文段的速度过慢则会到时缓存溢出从而丢失数据。
TCP连接管理：
三次握手①:发送的报文中，特殊报文段SYN比特设置为1，并随机选择一个初始序号client放置于序号字段中。
三次握手②:服务器提取出SYN报文段，为该连接分配缓存和变量，并发送允许连接的报文段，其中SYN比特设置为1，确认字号为client+1，并且服务器选择自己的初始序号server放到序号字段中。
三次握手③：客户端给连接分配缓存和变量，将server+1放置到确认字段中,此时连接已经建立，SYN比特置0，并且此时可以携带数据。
TCP的关闭：
任何一方都可以引起TCP连接的关闭。首先客户端发送FIN比特为1的报文段。服务器收到之后也回复一个FIN比特为1的报文段，最后，客户对服务器的终止报文段进行确认，释放用于该连接的所有资源。
网络拥塞的代价：
当分组的到达速率接近链路容量时，分组经历巨大的排队时间延迟。
发送方必须执行重传以补偿因为缓存溢出而丢失的分组。
发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。
TCP如何检测到网络拥塞呢？要么出现超时，要么是接收到三个冗余ACK，发送方就认为发送方到接收方的路径上出现了拥塞。一个丢失的报文段意味着阻塞，当丢失报文段时应当降低TCP发送方的速率。此时应当减小发送速率以应对这种情况。而一个ACK的到达是一切顺利的隐含提示，则能够增加发送方的速率。
TCP调节传输速率的策略是增加其速率以响应到达的ACK，除非出现丢包事件才减小传输速率。
TCP拥塞控制算法：①慢启动 ②拥塞避免 ③快速恢复
慢启动：
当一条TCP连接开始时，拥塞窗口被设置为1个MSS大小，即可以容纳一个报文，TCP发送方希望尽快找到可用带宽的数量，因此，第一个ACK到达时，拥塞窗口将翻倍，变为2个MSS大小，此时最大可以发送两个报文段，这两个报文段的ACK到达后，拥塞窗口又翻倍变为4个MSS大小，直到4个ACK报文到达，再次翻倍..直到出现一个由超时指示的丢包事件时，这种指数增长才消失。此时将慢启动阈值设为拥塞窗口长度/2，并且拥塞窗口长度再次从1开始慢启动，当增长到慢启动阈值时，TCP转到拥塞避免模式。
拥塞避免模式：
一次RTT（往返时延）只将拥塞窗口的值增加一个MSS。当这种模式再次遇到超时情况时，处理方式跟之前一样。对于3个冗余ACK引发的丢包事件，TCP将拥塞窗口的值减半并且将慢启动阈值，接下来进入快速恢复状态。
快速恢复：
对于引起TCP进入快速恢复的缺失报文段，对收到的每个冗余ACK，拥塞窗口的值增加一个MSS，最终当丢失报文段的ACK到达时，TCP在降低拥塞窗口值后进入拥塞避免状态。如果出现超时，则处理方式跟之前一样，进入慢启动状态。
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
运输层协议为运行在不同主机上的进程提供了逻辑通信功能，使得主机之间好像直接相连一般。运输层协议最重要的便是TCP和UDP协议，这是当今最主流的运输层协议。
运输层提供了不同主机上的进程之间的逻辑通信，网络层提供了主机之间的逻辑通信。他们之间的区别可以用一个例子来说明。假设有A家族和B家族的人，他们会互相通信。A家族由A1来负责收取A家族所有成员的信件，并将这些信件交到邮政服务的邮车上。B家族的B1也做着同样的事情。信封送到之后，由A1分发从B家族发来的信封。这里的A1便是运输层协议，邮车则是网络层协议，A家族是一个主机，A家族的所有成员是主机上的进程。A家族的成员实际上只与A1进行逻辑通信，而A1收齐信封之后则与邮车进行逻辑通信。
网络层协议中有一种协议叫IP协议，即网际协议，它的服务模型为尽力而为交付服务。它会尽最大的努力交付报文段，但不保证报文段中数据的完整性，以及交付的顺序。因此它是不可靠服务。然而，我们知道，建立在不可靠服务之上的TCP协议却是一种可靠的，按序交付的运输层协议，之后我们会讲到。
运输层协议提供的最低限度的服务是：进程到进程的数据交付，差错检查。这也是UDP提供的全部服务。
套接字：
套接字是应用层与运输层之间的一个接口,它有唯一标识符——端口。一个套接字对应一个进程，一个进程可以有多个套接字。运输层实际上并没有将数据直接交给进程，而是将数据交给了一个中间的套接字。而应用层再从套接字中获得数据。
多路分解：
将运输层报文段中的数据交付到正确的套接字的工作成为多路分解。
多路复用：
在源主机从不同套接字中收集数据块，并为每个数据块分装上首部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。
在报文段中，我们指定源端口号和目的端口号，当运输到目的主机时，运输层协议检查报文段中的目的端口号，将其送往对应的套接字。
UDP套接字由一个二元组（目的IP地址，目的端口号）标识
TCP套接字由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）标识
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
标识
对于两个不同源IP或者源端口号，却具有相同目的IP和端口号的UDP，两个报文段将通过相同的套接字被定位到相同进程。
对于两个不同源IP或者源端口号，却具有相同目的IP和端口号的TCP，两个报文段将通过不同的套接字，因为服务器会创建新的套接字来对应不同的TCP连接。
UDP无法提供可靠服务，那么是否意味着它没有用处呢？答案是否定的，有许多应用更适合UDP。原因如下：
① 关于何时、发送什么数据的应用层控制更为精细。
② 无需建立连接。TCP在数据传输前需要3次握手，而UDP不需要，意味着不会产生建立连接的时延。
③ 无连接状态。TCP需要在端系统维护连接状态，而UDP不需要。
④ 分组首部开销小。TCP有20字节的首部开销，UDP只有8字节。
使用UDP的应用也是可以实现可靠传输的，可以通过在应用程序自身中建立可靠性机制来完成，但这并不是无足轻重的任务。这样的好处是应用进程可以进行可靠通信，而无需受制于TCP拥塞控制机制和传输速率限制。
UDP检验和：
对发送方的UDP报文段中所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。（回卷即如果最高位产生进位，则把这个进位与最低位相加），例如0110011001100000、0101010101010101，1000111100001100，相加得到0100101011000010，该和的反码运算结果是1011010100111101，这个数就是我们的检验和。如果该分组中没有差错，那么接收方接收到的数据的和再加上检验和，得到的应该是1111111111111111。如果出现了0，则说明出现了差错。
可靠数据传输原理
TCP是在不可靠的网络层之上实现的可靠数据传输协议。
① 考虑运输层的底层信道是完全可靠的。这种情况下，发送方的状态只是等待上层调用，发送数据。而接收方的状态则是等待下层调用，接受数据并传给应用层。
② 考虑运输层的底层信道并不可靠，有可能发生比特差错。在通常情况下，如果我们接收到一个完整的报文，我们会回以一个肯定确认，如果没接收完整，我们会回以一个否定确认。如果内容接收有误，发送方则会再次传送数据。基于这样重传机制的可靠数据传输协议称为自动重传请求协议（ARQ协议）。ARQ协议需要三种功能：差错检验，接收方反馈和发送方重传。这种情况下，发送方的状态是等待上层调用，被调用后发送数据，进入等待ACK（肯定确认）或者NAK（否定确认）的状态。如果收到NAK，则重传数据并停留在该状态，如果收到ACK则回到等待调用的状态。接收方则是等待下层调用，接收到数据后则利用差错检验，发生差错则发送一个NAK给发送方。没有差错则发送ACK给发送方并且将数据上传到应用层。当发送方等待ACK或者NAK时，他不能继续传输数据，这样的协议被称为停等协议。
③ 然而，上面的方法并没有考虑到ACK分组或者NAK分组也有可能发生丢失的情况（接收方发回的ACK或者NAK都没有差错检验），发送方无法知道接收方是否正确接受了上一块发送的数据。解决这一问题的简单方法是在数据分组中添加一新字段，让发送方对数据分组编号，接收方只需要检查序号就可以确定接收到的分组是否为重传。发送方的新字段为0则说明目前传的是老数据块，为1则说明之前的数据块已经传输完毕，现在传输的是新的数据块。同时我们对接收方发回的ACK/NAK分组也添加差错检验功能，如果发送方收到的ACK或者NAK分组有错，则发送方再次发送数据。
④ 如果收到受损的分组，接收方将发送否定确认NAK，如果不发送NAK，而是对上次正确接收的分组发送一个ACK，发送方收到对同一个分组的两个ACK（即收到冗余ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。发送方发送数据后等待ACK0，如果收到ACK1，则说明当前数据块出现差错，重传，收到ACK0后进入下一个状态，等待再次发送数据，这次发送数据的时候会进入等待ACK1的状态，如果收到ACK0，则说明当前数据块出现差错，重传，收到ACK1后进入初始状态。
⑤ 考虑运输层的底层信道并不可靠，有可能发生比特差错，还有可能发生丢包现象（即整个分组不见了）。发送方发送分组，如果该分组或者接收方对该分组的ACK发生了丢失，如果发送方愿意等待足够长的时间以便确认分组已丢失，则它只需要重传该数据分组即可。不管是数据分组丢失，还是ACK丢失，还是分组或者ACK过度时延，发送方都使用万能的重传来处理。我们使用一个倒计数定时器，每发送一个分组，启动一个定时器，到期后响应定时器中断，或者接收到ACK报文后终止定时器
流水线：
不使用停等协议，允许发送方发送多个分组而无需等待（之前发送分组后需要等待ACK报文），许多从发送方向解说房输送的分组可以被看成是填充到一条流水线中，所以这种技术被称为流水线。这种技术大大提升了吞吐量。协议的发送方必须能够缓存那些已发送但是还没有确认的分组，接收方需要缓存那些已正确接收的分组。解决流水线的差错恢复有两种基本方法：回退N步（GBN），选择重传（SR）
GBN协议
GBN协议中，发送方维持一个长度为N的窗口，窗口之前是已经发送并且被确认的分组，窗口内是已经发送但未被确认的分组和可用但还没被发送的分组，窗口后是不能使用的分组。GBN协议发送方当应用层要求发送报文时，需要检查当前窗口是否已满，未满则产生一个分组将其发送。GBN协议中对序号为n的分组的确认采取累积确认，表明接收方已经正确收到序号为<=n的所有分组。如果发生超时，则采取回退N步的方式，重传所有已经发送但是还没有被确认的分组。它的定时器是针对最早的已发送未确认分组，如果收到一个ACK，但仍有已发送未确认分组，则定时器重新启动，如果没有，则定时器终止。
GBN协议接收方如果序号为n的分组被正确接收并且按序，则接收方为分组n发送一个ACK，其他所有情况下接收方丢弃该分组，并且为最近按序接收的分组重新发送ACK。如果分组k已经接收并且交付，则所有序号<=k的分组也已经交付。
SR协议：
选择重传协议仅仅重传那些它怀疑在接收方出错的分组而避免不必要的重传。它同样使用窗口的模式，从上层接收到数据的处理方式跟GBN协议一样，但是发送方已经收到了对窗口中某些分组的ACK，则将那些标记为已接收，如果收到窗口第一个分组的ACK，则将窗口向前移动到最小序号已发送未确认分组处，如果此时窗口内有未发送分组，则发送之。另一个与GBN协议不同的是，每个分组都拥有自己的逻辑定时器。因为超时发生后只能发送一个分组。而接收方将确认一个正确接收的分组不管是否按序，失序的分组将缓存到所有序号更小的分组接收到为止才交付给上层。对于SR协议而言，发送方和接收方的窗口并不总是一致。
TCP报文段结构：
32比特的序号字段、32比特的确认号字段、16比特的接收窗口字段、4比特的首部长度字段、选项字段、6比特的标志字段：ACK，RST、SYN、FIN、PSH、URG
序号：
TCP三次握手期间设置发送缓存，TCP将数据引导至该连接的发送缓存中，每次可取出并放入报文段中的数据数量受限于MSS（最大报文段长度）。TCP中的数据流根据MSS被分成很多块并且分配序号，当我们发送报文段时，那些序号会被填入32比特的序号字段里。
确认号：
主机A填充进报文段的确认号是主机A期望从主机B收到的下一字节的序号。假设主机A收到主机B包含0到535的报文段和900到1000的报文段，仍在等待536，因此A到B的下一个报文段将在确认号中包含536。
可靠数据传输：
TCP的超时定时器可以理解为与最早的未被确认的报文段相关联。
超时发生时，TCP通过重传引起超时的报文段来响应超时。
TCP也使用流水线，使得发送方在 任意时刻都可以有多个已发出但还未被确认的报文段存在。
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
来自接收方的ACK到来时，TCP将ACK的值y与TCP状态变量SendBase，即最早已发送未确认字节比较。TCP采用累积确认，所以y确认了在y之前的所有字节都已经接收。如果y>SendBase,则ACK是在确认一个或多个先前未被确认的报文段，因此发送方更新SendBase变量，如果有未被确认的报文段，TCP重启定时器。
超时间隔加倍：
当超时时间发生时，TCP重传具有最小序号的还未被确认的报文段。只是每次TCP重传时都会将下次超时间隔设置为2倍。
TCP差错恢复机制：
TCP的确认是累计式的（只确认流中至第一个丢失字节为止的字节），但它跟GBN协议还有SR协议并不完全相同，比如，TCP会将正确接收但失序的报文段缓存起来。又比如1到n的报文段中第k个报文段的确认报文丢失，但是其余n-1个报文段在其超时之前顺利到达，如果是GBN协议，会重传k到n的所有报文段，而TCP至多重传一个报文段k，如果k+1的确认报文在k超时之前到达，TCP甚至不会重传k。
流量控制服务：
TCP提供的流量控制服务消除了缓存溢出的可能性。它通过维护一个接收窗口的变量来提供流量控制。TCP不允许已分配的缓存溢出，则必须满足等式接收缓存中的数据流的最后一个字节的编号-接收方的应用程序从缓存读出的数据流的最后一个字节的编号<=接收缓存大小。而发送方在连接的整个生命周期则必须保证发送到连接中但未被确认的数据量<=接受缓存窗口的可用大小。这便是TCP的流量控制服务。而UDP不提供这种服务，对于UDP，如果进程从缓存中读取报文段的速度过慢则会到时缓存溢出从而丢失数据。
TCP连接管理：
三次握手①:发送的报文中，特殊报文段SYN比特设置为1，并随机选择一个初始序号client放置于序号字段中。
三次握手②:服务器提取出SYN报文段，为该连接分配缓存和变量，并发送允许连接的报文段，其中SYN比特设置为1，确认字号为client+1，并且服务器选择自己的初始序号server放到序号字段中。
三次握手③：客户端给连接分配缓存和变量，将server+1放置到确认字段中,此时连接已经建立，SYN比特置0，并且此时可以携带数据。
TCP的关闭：
任何一方都可以引起TCP连接的关闭。首先客户端发送FIN比特为1的报文段。服务器收到之后也回复一个FIN比特为1的报文段，最后，客户对服务器的终止报文段进行确认，释放用于该连接的所有资源。
网络拥塞的代价：
当分组的到达速率接近链路容量时，分组经历巨大的排队时间延迟。
发送方必须执行重传以补偿因为缓存溢出而丢失的分组。
发送方在遇到大时延时所进行的不必要重传会引起路由器利用其链路带宽来转发不必要的分组副本。
当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组而使用的传输容量最终被浪费掉了。
TCP如何检测到网络拥塞呢？要么出现超时，要么是接收到三个冗余ACK，发送方就认为发送方到接收方的路径上出现了拥塞。一个丢失的报文段意味着阻塞，当丢失报文段时应当降低TCP发送方的速率。此时应当减小发送速率以应对这种情况。而一个ACK的到达是一切顺利的隐含提示，则能够增加发送方的速率。
TCP调节传输速率的策略是增加其速率以响应到达的ACK，除非出现丢包事件才减小传输速率。
TCP拥塞控制算法：①慢启动 ②拥塞避免 ③快速恢复
慢启动：
当一条TCP连接开始时，拥塞窗口被设置为1个MSS大小，即可以容纳一个报文，TCP发送方希望尽快找到可用带宽的数量，因此，第一个ACK到达时，拥塞窗口将翻倍，变为2个MSS大小，此时最大可以发送两个报文段，这两个报文段的ACK到达后，拥塞窗口又翻倍变为4个MSS大小，直到4个ACK报文到达，再次翻倍..直到出现一个由超时指示的丢包事件时，这种指数增长才消失。此时将慢启动阈值设为拥塞窗口长度/2，并且拥塞窗口长度再次从1开始慢启动，当增长到慢启动阈值时，TCP转到拥塞避免模式。
拥塞避免模式：
一次RTT（往返时延）只将拥塞窗口的值增加一个MSS。当这种模式再次遇到超时情况时，处理方式跟之前一样。对于3个冗余ACK引发的丢包事件，TCP将拥塞窗口的值减半并且将慢启动阈值，接下来进入快速恢复状态。
快速恢复：
对于引起TCP进入快速恢复的缺失报文段，对收到的每个冗余ACK，拥塞窗口的值增加一个MSS，最终当丢失报文段的ACK到达时，TCP在降低拥塞窗口值后进入拥塞避免状态。如果出现超时，则处理方式跟之前一样，进入慢启动状态。
由于TCP不使用否定确认，所以当TCP接收方收到一个序号大于下一个所期望的、按序的报文段时，接收方通过对已经接收到的最后一个按序字节数据进行重复确认（产生冗余ACK）来告诉发送方有报文段丢失。一旦收到3个冗余ACK，TCP就执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 