运输层章节重要概念
-
运输层提供应用进程之间的逻辑通信，也就是说，运输层之间的通信并不是在两个运输层之间直接传递数据。运输层向应用层屏蔽了下面网络的细节（如网络拓扑、所采用的的路由选择协议等），它使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。
-
网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
-
运输层有两个主要的协议：TCP 和 UDP。它们都有复用和分用，以及检错的功能。当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工通信的可靠信道。当运输层采用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。
-
运输层用一个 16 位端口号来标志一个端口。端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网的不同计算机中，相同的端口号是没有关联的。
-
两台计算机中的进程要互相通信，不仅要知道对方的 IP 地址（为了找到对方的计算机），而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。
-
运输层的端口号分为服务器端使用的端口号（0 ～ 1023 指派给熟知端口，1024~49151是登记端口号）和客户端暂时使用的端口号（49152～65535）。
-
UDP 的主要特点是：(1)无连接；(2) 尽最大努力交付；(3) 面向报文；(4)无拥塞控制；(5) 支持一对一、一对多、多对一和多对多的交互通信；(6) 首部开销小（只有四个字段：源端口、目的端口、长度、检验和）。
-
TCP 的主要特点是：(1)面向连接；(2) 每一条 TCP 连接只能是点对点的（一对一）；(3)
) 提供可靠交付的服务；(4) 提供全双工通信；(5) 面向字节流。 -
TCP用主机的IP地址加上主机上的端口号作为TCP 连接的端点。这样的端点就叫做套接字（socket）或插口。套接字用（IP 地址：端口号）来表示。
-
停止等待协议能够在不可靠的传输网络上实现可靠的通信。每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。分组需要进行编号。
-
超时重传是指只要超过了一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。
-
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。
-
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已正确收到了。
-
TCP 报文段首部的前 20 个字节是固定的，后面有 4N 字节是根据需要而增加的选项（N 是整数）。在一个 TCP 连接中传送的字节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。
-
TCP 首部中的确认号是期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则表明：到序号 N－1为止的所有数据都已正确收到。
-
TCP 首部中的窗口字段指出了现在允许对方发送的数是经常在动态变化着的。
-
TCP 使用滑动窗口机制。发送窗口里面的序号表示允许发送的序号。发送窗口后沿的后面部分表示已发送且已收到了确认，而发送窗口前沿的前面部分表示不允许发送。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。发送窗口前沿通常是不断向前移动的。
-
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
-
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
-
流量控制是一个端到端的问题，是接收端抑制发送端发送数据的速率，以便使接收端来得及接收。拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
-
为了进行拥塞控制，TCP 的发送方要维持一个拥塞窗口 cwnd 的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接收窗口中较小的一个。
-
TCP 的拥塞控制采用了四种算法，即慢开始、拥塞避免、快重传和快恢复。在网络层，也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM）,以减少网络拥塞的发生。
-
运输连接有有三个阶段，即：连接建立、数据传送和连接释放。
-
主动发起 TCP 连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP 的连接建立采用三报文握手机制。服务器要确认客户的连接请求，然后客户要对服务器的确认进行确认。
-
TCP 的连接释放采用四报文握手机制。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后就进入半关闭状态。当另一方也没有数据再发送时，则发送连接释放通知，对方确认后就完全关闭了 TCP 连接。
习题
- 试说明运输层在协议栈中的地位和作用。运输层的通信和网络层的通信有什么重要的区别？为什么运输层是必不可少的？
从通信和信息处理的角度来看，运输层像上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络的边缘部分中的两个主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
从网络层来说，通信的两端是两个主机。IP数据报的首部明确地标志了这两个主机的IP地址。但“两个主机之间的通信”这种说法还不够清楚。这是因为，真正进行通信的实体是在主机中的进程，是这个主机中的一个进程和另一个主机中的一个进程在交换数据（即通信）。因此严格地讲，两个主机进行通信就是两个主机中的应用进程互相通信。IP 协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信（见图 T-5-01）。因此，运输层是不可缺少的。
所以运输层的通信和网络层的通信有很大的区别。网络层提供主机之间的逻辑通信，而运输层则提供应用进程之间的逻辑通信。
运输层还有复用、分用的功能，还要对收到的报文进行差错检测。
- 网络层提供数据报或虚电路服务对上面的运输层有何影响？
网络层提供的两种服务的最大不同就是：数据报不提供可靠的交付，而虚电路服务则提供可靠的交付。初看起来，似乎是如果网络层提供了可靠的交付，那么运输层就可以简化一些，就不需要可靠交付了，因而可以简化一些。其实不然。事实证明，即使网络层提供了可靠的交付，那也只是主机到主机的通信是可靠的，而我们需要的进程到进程的通信仍然可能出错。因此，当必须保证可靠通信时，不管网络层提供多么可靠的服务，运输层仍然必须有可靠交付的协议。因此，互联网在网络层只提供比较简单的数据报服务（这样就使得网络层大大简化，使得网络的造价降低），而用连接在网络上的主机中的运输层来实现可靠交付。可见对于互联网的设计，网络层的服务并没有对运输层的设计产生多大的影响。
- 当应用程序使用面向连接的 TCP 和无连接的IP 时，这种传输是面向连接的还是无连接的？
这要在不同层次来看。在运输层是面向连接的，而在网络层则是无连接的。
- 试画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接又复用到IP数据报上。
如图T-5-04：
在图T-5-04中，主机H3同时与主机H1和H2进行通信。H1和H3的两个应用进程（HTTP和SMTP）进行通信，这需要使用两个TCP连接。这两个TCP连接所传送的报文段，使用下面的网络层的IP数据报传送。H2和 H3的应用进程（HTTP）进行通信，这需要使用一个TCP 连接。这个 TCP 连接所传送的报文段，也要使用下面的网络层的IP数据报来传送。在网络层所传送的 IP 数据报已看不到运输层以上的复用情况。
- 试举例说明有些应用程序愿意采用不靠的UDP，而不愿意采用可靠的TCP。
这可能有以下情况：
首先，在互联网上传输实时数据的分组时，有可能会出现差错甚至丢失。如果利用 TCP协议对这些出错或丢失的分组进行重传，那么时延就会大大增加。因此，实时数据的传输在运输层就应采用用户数据报协议UDP，而不使用TCP协议。这就是说，对于传送实时数据，我们宁可丢失少量分组（当然不能丢失太多，否则重放的质量就太差了），也不要等待太晚到达的分组。在连续的音频或视频数据流中，很少量分组的丢失对播放效果的影响并不大（因为这是由人来进行主观评价的），因而是可以容忍的。在这种情况下，我们愿意采用不可靠的UDP，而不愿意采用可靠的TCP。
其次，当网络出现拥塞时，TCP的拥塞控制就会让TCP的发送方放慢报文段的发送。可能有的应用程序就不愿意放慢其报文段的发送速度。另外，可能有的应用程序不需要 TCP 的可靠传输。在这些情况下，就宁可使用UDP来传送。
- 接收方收到有差错的 UDP 用户数据报时应如何处理？
简单的丢弃。
- 如果应用程序愿意使用UDP完成可靠传输，这可能吗？请说明理由。
这是可能的，但这要由应用层自己来完成可靠传输。例如，应用层自己使用可靠
传输协议。当然，这还是需要相当大的工作量的。
- 为什么说UDP是面向报文的，而TCP是面向字节流的？
发送方的 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文，如教材的图 5-4 所示。在接收方的UDP，对IP层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程。也就是说，UDP一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。
- 端口的作用是什么？为什么端口划分为3种？
端口是用来标志进程的。端口也就是协议端口号。但这种在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念。硬件端口是不同硬件设备进行交互的接口，而软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。不同的系统，具体实现端口的方法可以是不同的（取决于系统使用的操作系统）。TCP/IP的运输层用一个16位端口号来标志一个端口。但端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网中不同的计算机中，相同的端口号是没有关联的。
两个计算机中的进程要互相通信,不仅必须知道对方的IP地址(为了找到对方的计算机）,而且还要知道对方的端口号（为了找到对方计算机中的应用进程）。
端口号有三种。不同的端口类别有其特殊的用途。例如，客户端是通信的发起方，而服务器是服务的提供方。它们对端口的使用要求是不同的。这三种端口号是：
熟知端口号或系统端口号，数值为 0~1023。这些数值可在网址 www.iana.org查到。
IANA把这些端口号指派给了TCP/IP最重要的一些应用程序，让所有的用户都知道。登记端口号，数值为 1024~49151。这类端口号是为没有熟知端口号的应用程序使用
的。使用这类端口号必须按照IANA规定的手续登记，以防止重复。
上面两种端口号是服务器端使用的端口号。下面的一种是客户端使用的端口号。短暂端口号，数值为49152~65535。这类端口号仅在客户进程运行时才动态选择，是
留给客户进程选择暂时使用。
- 试说明运输层中伪首部的作用
所谓的“伪首部”是因为这种伪首部并不是UDP用户数据报或者TCP报文段真正的首部。只是在计算校验和的时候，临时添加在UDFP用户数据报或者TCP报文段的前面，得到一个临时的UDP用户数据报或者TCP报文段。检验和就是按照这个临时的UDP用户数据报或者TCP数据报文段来计算的。伪首部既不向下传送也不向上递交，而仅仅是为了计算运输层的校验和。
- 某个应用进程使用运输层的用户数据报UDP，然后继续向下交给IP层后，又封装成IP数据报。既然都是数据报，是否可以跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没有提供？
IP数据报只能找到目的主机而无法找到目的进程。如果应用进程直接把数据交给下面的 IP 层，那么在传送到对方IP层后，就只能交付目的主机，但不知道应当交付哪一个应用进程。UDP提供对应用进程的复用和分用功能，以及提供对数据部分的差错检验。这些功能IP 层没有提供。
- 一个应用程序用UDP，到了IP层把数据报再划分为4个数据报片发送出去。结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成为完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。重传时，IP 数据报的标识字段会有另一个标识符。仅当标识符相同的 IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同，因此不能组装成一个IP数据报。
- 一个UDP用户数据报的数据字段为8192字节。在链路层要使用以太网来传送。试问应当划分几个IP数据报片？说明每一个IP数据报片的数据字段长度和为片偏移字段的值。
UDP用户数据报的长度为8192+8=8200B
以太网数据字段最大长度是1500B。若IP首部为20B，则IP数据报的数据部分只能为1480B。1480x5+800=8200B,因此划分的数据报片共6个。
第1个数据报片的片偏移字节为1480x0=0B
第2个数据报片的片偏移字节为1480x1=1480B
第3个数据报片的片偏移字节为1480x2=2960B
第4个数据报片的片偏移字节为1480x3=4440B
第5个数据报片的片偏移字节为1480x4=5920B
第6个数据报片的片偏移字节为1480x5=7400B
将以上的片偏移字节数除以8，就可以得出片偏移字段值，因此片偏移字段值分别为：0、185、370、555、740、925.
- 个UDP用户数据报的首部的十六进制表示是：06 32 00 45 00 1C E2 17。试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是从服务器发送给客户？使用UDP的这个服务器程
序是什么？
将十六进制转为二进制为：
源端口号06 32(00000110 00110010)1586;
目的端口号：00 45(00000000 01000101)69;
UDP用户数据报总长度00 1C(00000000 00011100)28字节;
校验值:E2 17(11100010 00010111)(...)
此UDP用户数据报是客户端发送给服务器(目的端口<1023，是熟知端口)。服务器程序是TFTP，TFTP服务器端口为69
- 使用TCP对实时话音数据的传输有没有什么问题？使用UDP在传送数据文件时会产生什么问题？
对实时话音数据的传输是不能使用TCP的。这是因为用TCP传输话音数据时，只要一出现差错或丢失，TCP 就要重传。这就产生了额外的时延，有时这种时延会达到很高的数值，使接收方无法容忍。在实时话音通信中，我们宁可丢掉几个分组（尽管话音质量会差一些，但仍然可以听懂），也不愿意收到太迟来到的分组，因为这样会使重放的话音质量严重恶化。虽然 UDP 不保证可靠交付，但 UDP 比 TCP 的开销要小很多。因此
只要应用程序接受这样的服务质量就可以使用UDP。
使用UDP传送数据文件时，如果出现了差错，UDP仅仅是少收了这个出错的报文段，并不通知发送方重传。这样就不能保证正确地传送数据。因此在传送数据文件时，我们都是采用TCP来传送的。
- 在停止等待协议中，如果不使用编号是否可行？为什么？
在停止等待协议中，如果不使用编号是不可行的，例如考虑下面的例子：
A发送报文段M1，B收到后发送确认(无编号)。但这个确认很晚才传送给A。A在没有等到确认时，超时重传了M1。
B 收到A发送的重传的M1。但B并不知道是重传的，因为报文段没有编号。B无法判断是重传的老报文段，还是新的报文段。B只能把A发送的重传的M1收下,并发送确认。但这个确认使A认为是对其发送的M2的确认，于是以为发送的两个报文段B都收到了。
这样简单的例子可以看出，不使用编号，A以为发送的两个报文段都正确的传送到B，而实际上B收到了两个重复的报文段。可见在停止等待协议中。如果不使用编号是不可行的。
- 在停止等待协议中，如果收到重复的报文段时不予理睬是否可行？
不可以，如果不予理睬，则另一方会不断的重传重复的报文。
- 假定在运输层使用停止等待协议。发送方在发送报文段 M0后在设定的时间内未收到确认，于是重传M0但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1，不久就收到了对M1的确认。接着发送方发送新的报文段M0，但这个新的M0在传送过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨出M0是旧的。于是收下Mo，并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。试画出双方交换报文段的过程。
如图T-5-18：
我们可以看出，旧的M0被当作是新的M0!可见运输层不能使用停止等待协议。
- 试证明：当用n比特进行分组的编号时，若接收窗口等于1（即只能按序接收分组），则仅在发送窗口不超过2”-1时，连续ARQ协议才能正确运行。窗口单位是分组。
如上图5-19所示，设发送窗口记为\(W_T\),接收窗口记为\(W_R\),假定用3个Bit > 进行编号，设接口窗口刚好在7号窗口处。发送窗口 W-的位置不可能比②的位 > 置更靠前。因为接收窗口的位置表明接收方 正等待接收7号分组，而这时的发 > 送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括7号分组， > 也就是不可能比②的位置更靠前（前方就是图的右方）。发送窗口 W-的位置也 > 不可能比③的位置更靠后。因为接收窗口的位置表明接收方已经对6 号分组>>> >（以及以前的分组）发送了确认。但如果发送窗口 W-的位置再靠后一个分组， > 即在6号分组的左边，那就表明还没有发送6号分组。但接收窗口的位置表明接 > 收方已经发送了对6号分组的确认。这显然是不可能的。
发送窗口 W7的位置可能是在某个中间的位置，如①。
对于①和②的情况，在 W7的范围内必须无重复序号，即 Wr ≤ 2"。
对于③的情况，在 Wr+ WR的范围内无重复序号，即 Wr+ WR ≤ 2"。
现在 WR=1，故发送窗口的最大值Wr<=2”-1。
- 在连续ARQ协议中，若发送窗口等于7，则发送端在开始时可连续发送7个分组。因此，在每一分组发出后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 to, t1,..., t6，且 \(t_{out}\) 都一样大。试问如何实现这 7 个超时计时器（这叫软时钟法）？
使用相对发送时间实现一个链表(如图T-5-20)
- 假定使用连续ARQ协议，发送窗口大小是3，而序号范围是[0,15]，而传输媒体保证在接收方能够按序收到分组。在某一时刻，在接收方，下一个期望收到的序号是5。试问：
(1) 在发送方的发送窗口中可能出现的序号组合有哪些？
(2) 接收方已经发送出的、但仍滞留在网络中（即还未到达发送方）的确认分组，可能有哪些？说明这些确认分组是用来确认哪些序号的分组。
(1). 在接收方，下一个期望收到的序号是5，这表明到4为止的分组都已经收到，若这些确认都已到达发送方，则发送窗口最靠前，其范围是[5,7]。
假定所有的确认都丢失了，发送方都没有收到这些确认，。这时，发送窗口最靠后，应该为[2,4]，因此，发送窗口可以是[2,4],[3,5],[4,6],[5,7]当中的任何一个。S
(2). 接收方期望收到序号是5的分组，说明序号为2，3，4的分组都已经收到，并且发送了确认。对序号为1的分组的确认肯定被发送方收到了，否则发送方不可能发送4号分组。可见，对序号为2，3，4的分子组的确认仍然有可能滞留在网络中。这些确认是用来确认序号为2，3，4的分组的。
- 主机A向主机B发送一个很长的文件,其长度为L字节。假定TCP使用的MSS为1460字节。
(1) 在TCP的序号不重复使用的条件下，L的最大值为多少
(2) 假定使用上面计算出的文件长度，而运输层、网络层和数据链路层所用的首部开销共66字节，链路的数据率为10Mbit/s，试求这个文件所需的最短传输时间。
(1)可能的序号共\(2^{32}\)个。TCP的序号是数据字段的每一个字节的编号，而不是每一个报文段的编号，因此，这一小题与报文段的长度无关。这个文件长度L字节的最大值就是可能的序号数。
(2) \(2^{32}/1460=2941758.422\)，需要发送2941759个帧。帧首部的开销是66×2941759=194156094字节。
发送的总字节数是=232+194156094=4489123390字节。数据率10Mbit/s=1.25 MB/s=1250000字节/秒。发送4489123390字节需时间为：4489123390/1250000=3591.3秒。即59.85分，约1小时。
- 主机A向主机B连续发送两个TCP报文段，其序号分别是70和100。试问：
(1)第一个报文段携带了多少字节的数据
(2)主机B收到第一个报文段后，发回的确认中的确认号是多少?
(3)如果主机B收到第二个报文段后，发回的确认中的确认号是180，试问A发送的第二个报文段中数据有多少字节？
(4)如果A发送的第一个报文段丢失了，但第二个报文段到达了 B。B在第二个报文段到达后向 A 发送确认。试问这个确认号应为多少？
(1)第一个报文段的数据序号是 70 到 99，共 30 字节的数据
(2)B期望收到下一个报文段的第一个数据字节的序号是 100，因此确认号应为100。
(3))A发送的第二个报文段中的数据中的字节数是 180-100=80字节。
(4)B在第二个报文段到达后向A发送确认，其确认号应为70
- 一个TCP连接下面使用256 kbit/s的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kbit/s。试问发送窗 W是多少？（提示：可以有两种答
案，取决于接收端发出确认的时机。）
设发送窗口=W(bit),发送端连续发送完窗口内的数> 据为T，有两种情况：
接收端在收完一批数据后的最后才发出确认，因此发送端经过(256ms+T)后才能发送下一个窗口的数据。
接收端每收到一个很小的报文段后就发回确认，因此发送端经过256ms略多一些的时间即可再发送数据。因此每经过256ms就能发送一个窗口的数据。
如图T-5-24给出了两种不同情况的图解：
- 为什么在TCP首部中要把TCP端口号放入最开始的4个字节中？
在ICMP差错报文中要包含IP首部后面的8个字节的内容，而这里有TCP首部中源端口和目的端口。当TCP收到ICMP差错报文时，需要用这两个端口来确定是哪条连接出现了差错。
- 为什么TCP首部中有一个首部长度字段，而UDP没有？
TCP除了固定的首部长度外，还有一些选项，因此TCP首部长度是可变的。UDP首部长度是固定的，因此并不需要该字段。
- 一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度，超过 TCP 报文段中的序号字段可能编出的最大序号，问还能否用TCP来传送？
一个TCP最大报文的数据部分最多为65495字节。数据部分再加上TCP首部的20字节，再加上IP首部20字节，刚好是IP数据报的最大长度65535字节。当然，若IP首部包含了选项，则IP首部长度就超过了20字节，这时候TCP数据部分的最大长度就小于65495字节。
如果用户要传送的数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，仍可用TCP来传送。编号用完后再重复使用。但应设法保证不出现编号的混乱。
- 主机A向主机B发送TCP报文段，首部中的源端口是m而目的端口是n。当B向A发送回信时,其TCP报文段的首部中的源端口和目的端口分别是什么？
解答：当B向A发送回信时，其TCP 报文段首部中的源端口就是A发送的TCP报文段首部中的目的端口 n，而B发送的TCP报文段首部中的目的端口就是A发送TCP报文段首部中的源端口 m。
- 在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
还未重就接收到了对更高序号的确认。
- 设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时间为20 ms，问所能得到的最大吞吐量是多少？
在发送时延忽略的条件下，每20ms就可以发送65535x8=524280bit
最大数据率=(524280bit)/(20ms)=26.2Mbit/s
- 通信带宽为1Gbit/s，端到端传播时延为10ms，TCP的发送窗口为65535字节，试问：可能达到的最大吞吐量是多少？信道的利用率是多少？
发送一个窗口的比特数为：65535x8=524280bit
所需时间为：(524280bit)/(1000000000bit/s)=0.524ms
往返时间为：20ms
最大吞吐量为：(0.524280Mbit)/(20ms+0.524ms)=25.5Mbit/s
信道利用率为（25.5Mbit/s）/(1000Mbit/s)=2.55%
- 什么是Karn算法？在TCP的重传机制中，若不采用Karn算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度？
Karn算法允许TCP能够区分有效和无效往返时间样本，从而改进了往返时间的估算。
若不采用Karn算法，而是在收到确认时都认为对重传报文的确认，那么由此得出的往返时间样本和超时重传时间都会偏小，如图T-5-32所示，TCP发送了报文段后，没有收到确认，于是超时重传报文段。但刚重传报文后，马上收到了确认，显然，这个确认是对原来报文段的确认。但是根据题意，我们认为这个确认就是对重传报文的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到0.因此上述做法是不可取的。
- 假定TCP在建立连接的时候，发送放确认的超时重传时间RTO=6s，（1）当发送方收到对方的连接确认报文段时，测量出RTT样本值为1.5s，试计算现在的RTO值；（2）当发送方发送数据报文段并收到确认时，测量出RTT样本值为2.5s，试计算现在的RTO值。
RTO计算如下：
（1）第一次测量到RTT样本时，\(RTT_s\)值就取这个测量到的\(RTT\)样本值。因此\(RTT_s\)=1.5s。\(RTT_D\)值取测量到的\(RTT\)样本值的一半，即\(RTT_D\)=1.5sx0.5=0.75s。
因此\(RTO=RTT_S + 4 * RTT_D\)=1.5s+0.75*4=4.5s。
（2）新的\(RTT\)样本值为2.5s。
新的\(RTT_S=(1-\alpha)*(旧的RTT_s)+ \alpha * (新的RTT样本)\)
=（1-1/8）* 1.5s+1/8*2.5s=1.625s。
\(新的RTT_D=(1- \beta)*(旧的RTT_D)+ \beta *(RTT_S - 新的RTT样本值)\)
=(1-1/4) * 0.75+1/4*|1.625-2.5|=0.78s
\(RTO=RTT_S + 4*RTT_D\)=1.625+0.78*4=4.75s。
- 已知第一次测得TCP的往返时间RTT是30ms。接着收到了三个确认报文段，用它们测量出的往返时间样本RTT分别是：26ms,32ms和24ms。设α=0.1。试计算每一次的新的加权平均往返时间值 RTTs。讨论所得出的结果。
刚开始\(RTT_S=RTT=30ms\)
由：\(新的RTT_S=(1-\alpha)*(就旧的RTT_s)+\alpha*(新的RTT_s)样本\)
第一次计算出：\(RTT_S=(1-0.1)*20+0.1*26=29.6ms\)
第二次计算出：\(RTT_S=(1-0.1)*29.6+0.1*32=29.84ms\)
第三次计算出：\(RTT_S=(1-0.1)*29.84+0.1*24=29.256ms\)
三次算出加权平均往返时间分别为29.6,29.84和29.256ms。
可以看出，\(RTT\)的样本值变化多达20%时((30－24)/30 = 6/30 = 1/5 = 20%)，加权平均往返时间 \(RTT_S\)的变化却很小。
- 试计算一个包括五段链路的运输连接的单程端到端时延。五段链路中有两段是卫星链路，有三段是广域网链路。每条卫星链路又由上行链路和下行链路两部分组成。可以取这两部分的传播时延之和为 250 ms。每一个广域网的范围为1500km，其传播时延可按150000km/s来计算。各数据链路速率为48kbit/s，帧长为960位。
广域网额传播时延：\((1500km)/(150000km/s)=0.01s=10ms\)
每一个节点的传播时延：\((960bit)/(4800bit/s)=0.02s=20ms\)
如下表格所示：
WAN WAN WAN 卫星网 卫星网 合计 传播时延 10ms 10ms 10ms 250ms 250ms 530ms 发送时延 20ms 20,s 20ms 20ms 20ms 100ms 总共需要630ms。
- 重复35题，但假定其中的一个陆地上的广域网的传输时延为150ms。
WAN WAN WAN 卫星网 卫星网 合计 传播时延 10ms 10ms 10ms 250ms 250ms 530ms 发送时延 150ms 20ms 20ms 20ms 20ms 230ms 总共需要760ms。
- 在 TCP 的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法？这里每一种算法各起什么作用？乘法减小”和“加法增大”各用在什么情况下？
慢开始算法的思路是这样的：当主机开始发送数据时，如果立即把大量数据字节
注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。经验证明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段 MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd就加倍。为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样，拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
快重传算法首先要求接收方每收到一个失序的报文段后，就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等待自己发送数据时才进行捎带确认。
快恢复算法，其过程有一下两个要点：
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限
ssthresh 减半。这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd 值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。
由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd 值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。以防止网络出现过早瘫痪。
- 设TCP的sshresh初始值为8（单位为报文段），当拥塞窗口上升到12时网络发生了超时，TCP开始使用慢来是和拥塞避免。试分别求出第1轮次和第15论次传输的各拥塞窗口的大小。你能说明拥塞窗口每一次变化的原因吗？
如下表所示：
轮次 拥塞窗口 拥塞窗口变化的原因 1 1 网络发生了超时，TCP使用慢开始算法 2 2 拥塞窗口加倍 3 4 拥塞窗口加倍 4 8 拥塞窗口加倍 5 9 TCP使用拥塞避免算法，拥塞窗口值加1 6 10 TCP使用拥塞避免算法，拥塞窗口值加1 7 11 TCP使用拥塞避免算法，拥塞窗口值加1 8 12 TCP使用拥塞避免算法，拥塞窗口加1 9 1 网络发生了超时，TCP使用慢开始算法 10 2 拥塞窗口值加倍 11 4 拥塞窗口值加倍 12 6 拥塞窗口值加倍，但到达12的一半时，改为拥塞避免算法。 13 7 TCP使用拥塞避免算法，拥塞窗口值加1 14 8 TCP使用拥塞避免算法，拥塞窗口值加1 15 9 TCP使用拥塞避免算法，拥塞窗口值加1
- TCP的拥塞窗口cwnd大小与传输轮次n的关系如下表T-5-39所示，试画出拥塞窗口与轮次之间的关系曲线；指明TCP工作在慢开始阶段的时间间隔；在第16轮次和第22轮次之后发送方是通过收到3个重复的确认，还是通过超时检测到丢失了报文段；在第1轮次、第18轮次、第24轮次发送时，门限ssthresh分别被设置为多大；在第几轮发送出第70个报文段；假定在第26轮次之后收到了三个重复的确认，因此而检测出了报文段的丢失，那么拥塞窗口cwnd和门限ssthresh应该设置为多大？
n 1 2 3 4 5 6 7 cwnd 1 2 4 8 16 32 33 n 8 9 10 11 12 13 14 cwnd 34 35 36 37 38 39 40 n 15 16 17 18 19 20 21 cwnd 41 42 21 22 23 24 25 n 22 23 24 25 26 cwnd 26 1 2 4 8 （1）：拥塞窗口同样传输轮次图如图T-5-39所示：
（2）：慢开始时间间隔：[1,6]，[23,26]
（3）：拥塞避免时间间隔：[6,16]，[17,22]
（4）：在第16轮次之后发送方通过收到3个重复的确认，检测到丢失了报文段，因为题目给出，下一轮次的拥塞窗口减半了；在第22轮次之后发送方式通过超时检测到丢失了报文段，因为题目给出，下一轮次的拥塞窗口下降到1了。
（5）：在第1轮次发送时，门限sshresh被设置为32，因为从第6轮次起就进入了拥塞避免状态。拥塞窗口每个轮次加1；在第18轮次发送时，门限sstresh被设置为发生拥塞窗口42的减半，即21；在第24轮次发送时，门限sstresh被设置为发生拥塞时拥塞窗口26的一半。即13。
（6）：第1轮次发送报文段1（cwnd=1）
第2轮次发送报文段2、3（cwnd=2）
第2次发送报文段4、5、6、7（cwnd=4）
第4次发送报文段8~15（cwnd=8）
第5次发送报文段16~31（cwnd=16）
第6次发送报文段32~63（cwnd=32）
第7次发送报文段64~96（cwnd=33）
因此第70报文段在第7轮出现
（7）：检测出报文段的丢失时拥塞窗口cwnd=8，因此拥塞窗口cwnd的数值减小到一半，等于4，而门限sstresh应该设置为4。
- TCP进行流量控制时，是以分组的丢失作为产生拥塞的控制，有没有不是因为拥塞而引起分组丢失的情况？如果有，请举出三种情况。
不是因拥塞而引起分组丢失的情况是有的，举例如下：
当IP数据报传输过程中需要分片，但其中的一个数据报片未能及时到达终点，而终点组装IP数据报已经超时，因而丢弃该数据报。
IP数据报已经到达终点，但接收缓存已满，只能丢弃数据报。
数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的存储空间而只好丢弃。
- 用TCP传送512字节的数据，设窗口为100字节，而TCP报文段每次也是传送100字节的数据，再设发送方和接收方的起始序号分别为100和200。试画出从连接过程到连接释放的状态图
解答：要传送的512B的数据必须划分为6个报文段传送，前5个报文段各100B，最后一个报文段传送 12 B。图 T-5-41 是双方交互的示意图。下面进行简单的解释。
报文段#1：A 发起主动打开，发送 SYN 报文段，处于 SYN-SENT 状态，并选择初始序号seq =100。B处于LISTEN状态。
报文段#2：B确认A的SYN报文段，因此ack=101（是A的初始序号加1）。B选择初始序号seq = 200。B 进入到 SYN-RCVD 状态。
报文段#3：A发送ACK报文段来确认报文段#2，ack=201（是B的初始序号加1）。A没有在这个报文段中放入数据。因为SYN 报文段#1消耗了一个序号，因此报文段#3的序号是seq = 101。这样，A 和B都进入了ESTABLISHED状态。
报文段#4：A发送 100 字节的数据。报文段#3 是确认报文段，没有数据发送，报文段#3并不消耗序号，因此报文段#4的序号仍然是seq=101。A在发送数据的同时，还确认B的报文段#2，因此ack=201。
报文段#5：B 确认 A 的报文段#4。由于收到了从序号 101 到 200 共 100 字节的数据，因此在报文段#5中，ack=201（所期望收到的下一个数据字节的序号）。B发送的SYN报文段#2消耗了一个序号，因此报文段#5的序号是seq=201，比报文段#2的序号多了一个序号。在这个报文段中，B给出了接收窗口rwnd=100。
从报文段#6 到报文段#13 都不需要更多的解释。到此为止，A 已经传送了 500 字节的数据。值得注意的是，B 发送的所有确认报文段都不消耗序号，其序号都是 seq = 201。
报文段#14：A发送最后12字节的数据，报文段#14的序号是seq=601。
报文段#15：B 发送对报文段#14 的确认。B 收到从序号 601 到 612 共 12 字节的数据。
因此报文段#15 的确认号是 ack = 613（所期望收到的下一个数据字节的序号）。需要注意的是，从报文段#5 一直到报文段#15，B 一共发送了 6 个确认，都不消耗序号，因此B发送的报文段#15的序号仍然和报文段#5的序号一样，即
seq = 201。报文#17：B发送确认报文段，确认号 ackx=614，进入CLOSE-WAIT状态。由于确认报文段不消耗序号，因此#17的序号仍然和报文段#15一样，即seq=201。
报文段#18：B 没有数据要发送，就发送 FIN 报文段#18，其序号仍然是
seq = 201。这个FIN 报文段会消耗一个序号。报文段#19：A 发送最后的确认报文段。报文段#16 的序号是 613已经消耗掉了。因此现在的序号是 seq = 614。但这个确认报文段并不消耗序号。
其他的地方不再需要更多的解释了。
- 在教材的图 5-29 中所示的连接释放过程中，在 ESTABLISHED 状态下，B 能否
先不发送 ack = u + 1 的确认？ （因为B在后面要发送的连接释放报文段中，仍
有 ack = u + 1 这一信息。）
如果B不再发送数据了，可以把两个报文段合并成为一个，即只发送 FIN＋ACK
报文段。但如果 B 还有数据要发送，那就不行，因为A迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。
- 在什么情况下会发生从状态SYN-SENT到状态SYN-RCVD的变迁？
当A和B都作为客户，即同时主动打开TCP连接，这时的每一方的状态变迁都是：CLOSED->SYN-SENT->SYN-RCVD->ESTABLISHED
- 试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相
通信的用户分别连接在网络的两结点上。
设A是客户，B是服务器。A和B建立了TCP连接后，A向B传送一个文件，当A收到来自B的确认后，文件的传送任务就完成了。A 就释放 TCP 连接，B 也随之释放TCP 连接。这就是最简单的一种连接释放方法。
但也可以有另一种情况。A 发送一个文件，里面含有一些数据，需要 B 进行修改。B 收到文件后就发送了确认。A 收到确认报文段后，就可以释放 TCP 连接，因为 A 已经没有数据要向B 发送了，可以向 B 发送 FIN 报文段，然后 B 给出确认。这时的 TCP 连接就处于半关闭状态。A不能再发送数据了，但B可以发送数据。等B向A发送完修改后的数据，B再向A发送 FIN 报文段，A 确认后，TCP 连接就释放了。这就是另一种连接释放的方法。
- 解释为什么突然释放运输层连接就可能会丢失用户数据，而是用TCP的连接释放方法就可保证不丢失数据？
现在 A 应当发送的数据都已经发送完毕了。如果 A 现在突然把 TCP 连接释放掉，那么有可能出现这种情况：A 发送给 B 的某些报文段正在网络中传送，但因某种原因，报文段丢失了。A以为B应当收到A所发送的全部报文段，但事实上，有些报文段B没有收到。这就是题目所说的“可能会丢失用户数据”。
我们再假定：A 已经收到了来自B的确认,B向A确认已经收到了A所发送的全部数据。如果A现在突然把 TCP 连接释放掉，那么A发送给B的数据是不可能丢失了，因为B已经确认收到了A所发送的全部数据。现在可能会丢失的，是 B 无法向 A 发送一些数据了（如果B还有这样的数据），因为TCP 连接已经突然释放了。
因此，必须使用TCP的连接释放，这样就可保证不丢失数据。