运输层知识要点——谢希仁《计算机网络》

Posted 2023-04-16

参考技术A 为了在计算机网络中有条不紊地交换数据，就必须遵守一些事先约定好的规则。这些规则明确规定了所 交换数据的格式 以及有关的 同步 问题。

同步的含义：在一定条件下应当发生什么事件，因而含有时序的意思。

网络协议：为进行网络中的数据交换而建立的规则、标准或约定。

网络协议由以下三个要素组成：

   1）语法：即数据与控制信息的结构或格式

   2）语义：即需要发出何种控制信息，完成何种动作以及做出何种反应

   3）同步：即事件实现顺序的详细说明

一、运输层协议的概述

   1.1 进程之间的通信

   1.2 运输层的两个主要协议

   1.3 运输层的端口

二、用户数据报协议UDP

   2.1 UDP概述

   2.2 UDP的首部格式

三、传输控制协议TCP概述

   3.1 TCP的最主要的特点

   3.2 TCP的连接

四、可靠传输的工作原理

   4.1 停止等待协议

   4.2 连续ARQ协议

五、TCP报文段的首部格式

六、TCP可靠传输的实现

   6.1 以字节为单位的滑动窗口

   6.2 超时重传时间的选择

   6.3 选择确认SACK

七、TCP的流量控制

   7.1 利用滑动窗口实现流量控制

   7.2 必须考虑传输效率

八、TCP的拥塞控制

   8.1 拥塞控制的一般原理

   8.2 几种拥塞控制方法

   8.3 随机早期检测RED

九、TCP的运输连接管理

   9.1 TCP的连接建立

   9.2 TCP的连接释放

   9.3 TCP的有限状态机

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

1.1 进程之间的通信

1.只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到了下三层的功能

2.两个主机进行通信就是两个主机中的应用进程互相通信。从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。（IP协议能把分组送到目的主机）

网络层时为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

3.运输层一个重要功能——复用、分用。 （应用进程复用、分用运输层）

1.2 运输层的两个主要协议

1.UDP—User Datagram Protocol 用户数据报协议（无连接）：DNS/RIP/DHCP/SNMP/NFS

TCP—Transmission Control Protocol 传输控制协议（面向连接）：SMTP/TELNET/HTTP/ FTP

1.3 运输层的端口

问题：为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须使用统一的方法（而这种方法必须与特定操作系统无关）对TCP/IP体系的应用进程进行标识。

为什么不用进程号来区分？（第一，不同操作系统的进程标识符不同；第二，用功能来识别，而不是进程，例如邮件服务功能，而不管具体是哪个进程）

解决方案：在运输层使用协议端口号，即端口。软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。（端口号只具有本地意义，只是为了标识本计算机应用层中各个进程在和运输层交互时的层间接口。）

端口分为两大类：

1）服务器使用的端口号：熟知端口号或系统端口号（0~1023）；登记端口号（1024~49151）

2）客户端使用的端口号：49152~65535

2.1 UDP概述

1.UDP只在IP的数据报服务至上增加了很少一点功能，就是复用、分用以及差错检测功能

2.特点

   1）无连接

   2）尽最大努力交付

   3）面向报文 （不合并、不拆分、保留这些报文的边界）

   4）UDP没有拥塞控制

   5）UDP支持一对一、一对多、多对一和多对多的交互通信

   6）UDP的首部开销小，只有8字节

应用进程本身可以在不影响应用的实时性的前提下，增加一些提高可靠性的措施，如采用前向纠错或重传已丢失的报文。

2.2 UDP的首部格式

1.traceroute 让发送的UDP用户数据报故意使用一个非法的UDP端口号，接收方丢弃报文，并由ICMP（网络控制报文协议）发送“端口不可达”差错报文给发送方。

2.计算检验和。IP数据报的校验和只检验IP数据报的首部，但UDP的校验和是把首部和数据部分一起都检验。（12字节的首部+真正的首部+数据来进行校验和的计算）

   Q1.为什么计算校验和要加12字节的伪首部

   Q2.计算校验和的原理是什么？

3.1 TCP的最主要的特点

1.面向连接的运输层协议（建立连接、传输数据、释放连接）

2.点对点，每一条TCP连接只能有两个端点

3.可靠交付（无差错、不丢失、不重复、并且按序到达）

4.全双工通信。TCP连接的两端都设有发送缓存和接收缓存。

5.面向字节流。（流指的是流入到进程或从进程流出的字节序列；面向字节流：TCP把应用程序交下来的数据看成是一连串的无结构字节流。 接收方的应用程序必须有能力识别接收到的字节流，把它还原成有意义的应用层数据。 因此TCP可以根据窗口值和当前网络状况调整发送的报文长度。划分短一点，或者积累到足够多再发送出去。）

3.2 TCP的连接

1.TCP把连接作为最基本的抽象。

2.每一条TCP连接有两个端点。TCP连接的端点叫作套接字。

   套接字soket = （IP地址：端口号）

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。

   TCP连接 ::= socket1, socket2

理想的传输条件有以下两个特点：

   1）传输信道不产生差错

   2）不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据

实际的网络并不具备，因此：

   1）出现差错时，让发送方重传

   2）接收方来不及处理时，及时告诉发送方适当降低发送数据的速度

4.1 停止等待协议

1.“停止等待”就是没发送完一个分组就停止发送，等待对方的确认，在收到确认后再发送下一个分组。

2.超时重传。在每发完一个分组就设置一个超时计时器，如果在超时计时器之前收到对方的确认，就撤销已设置的超时计时器。如果未收到，就认为刚才的分组丢失，并重传。

3.三种情况：A发送的分组出错、丢失；B发送的确认丢失；B发送的确认迟到

确认丢失：B丢弃重复的分组，向A重传确认

确认迟到：A丢弃重复的确认，B丢弃重复分组，并向A重传确认

4.常称为自动重传请求ARQ，重传时自动进行的（超时即重传）

5.缺点：信道利用率太低

   U=Td/(Td+RTT+Ta)

为了提高传输效率，发送方不使用停止等待协议，而是采用流水线传输。流水线传输就是发送发可连续发送多个分组，不必等每发完一个分组就停顿下来等待对方的确认。（连续ARQ协议和滑动窗口协议）

4.2 连续ARQ协议

1.位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。

2.累积确认：接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。

3.缺点：Go-back-N （发送前5个分组，第3个分组丢失，后面三个要重传）

1.源端口和目的端口

2.序号。 每个字节都按顺序编号。

3.确认号。 期望收到对方下一个报文段的第一个数据字节的序号。

若确认号=N，则表明：到序号N-1为止的所有数据都已正确收到。

4.数据偏移。 指出TCP报文段的数据起始处距离TCP报文段的起始处有多远（也即TCP报文段首部长度）。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。

5.窗口。窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。

6.1 以字节为单位的滑动窗口

1.发送缓存用来暂存：

   1）发送应用程序传送给发送方TCP准备发送的数据；

   2）TCP已发送但未收到确认德尔数据

2.接收缓存用来存放：

   1）按序到达的、但尚未被接收应收程序读取的数据；

   2）未按序到达的数据

3.注意三点：

   1）A的发送窗口是根据B的接收窗口设置的，但是在同一时刻，由于网络传输的滞后，A的发送窗口并不总是B的接收窗口一样大

   2）TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程

   3）TCP接收方有累计确认功能（不能过分推迟发送确认，否则会导致发送方不必要的重传）

6.2 超时重传时间的选择

1.超时重传时间设置太短，会引起很多不必要的重传；如果设置太长，使网络的空闲时间增大，降低传输效率。

2.新的RTTs = (1-a)x(旧的RTTs) + ax（新的RTT样本），其中RTT样本的时间为：记录一个报文段发出的时间，以及收到相应的确认时间，时间差就是报文段的往返时间RTT。

3.RTO = RTTs + 4 x RTTd，其中RTO为超时重传时间，RTTd是RTT的偏差的加权平均值。

新的RTTd = (1-b) x （旧的RTTd）+ b x |RTTs - 新的RTT样本|

4.一个问题：发送一个报文段，设定的重传时间到了，还没有收到确认。于是重传报文段。经过一段时间，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

1）解决方法1，在计算加权平均值RTTs时，只要报文段重传了，就不采用其往返时间样本。

引入的问题：报文段的时延突然增大的情况

2）解决方法2，报文段每重传一次，就把超时重传时间RTO增大一些（一般是2倍）。当不在发生报文段的重传时，再根据加权平均计算。

6.3 选择确认SACK

SACK文档并没有指明发送发应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

7.1 利用滑动窗口实现流量控制

1.流量控制：就是让发送方的发送速率不要太快，要让接收方来得及接收。

2.利用滑动窗口机制可很方便地在TCP连接上实现对发送方的流量控制。发送方的发送窗口不能超过接收方给出的接收窗口的数值。

3.死锁情况：B向A发送了零窗口的报文段后不久，B又有了一些缓存空间，因此B向A发送rwnd = 400.然而该报文段在传送过程中丢失。A一直等待B发送的非零窗口的通知，B也一直等待A发送的数据。（ 窗口通知不超时重传？为什么？ ）

解决方法：TCP为每个连接设有一个持续计时器。只要一方收到对方的零窗口通知，就启动计时器。计时器到期后，发送一个零窗口探测报文段，而对方就在确认这个探测报文段时给出了现在的窗口值。若仍为零，收到报文段的一方重新设置持续计时器。

7.2 必须考虑传输效率

1.应用程序把数据传送到TCP的发送缓存后，剩下的发送任务就由TCP来控制了。

2.三种不同的机制来控制TCP报文段的发送时机：

   1）TCP维持一个变量，它等于最大报文段长度MSS，只要缓存中的存放的数据达到MSS，就组装成一个TCP报文段发送出去

   2）由发送方的应用进程指明要求发送报文段，即TCP支持推送操作

   3）发送方设置一个定时器

3.问题一、若用户只发送一个字节，则非常浪费带宽。

解决方法：若发送应用程序把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去。（采用收到确认就发送+并开始缓存的方式；同时当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。）

4.问题二、糊涂窗口综合症。接收缓存已满，应用程序一次只读取一个字节，然后向发送方发送确认。

解决方法：让接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。则接收方就发出确认报文。

8.1 拥塞控制的一般原理

1.拥塞的定义：对资源的需求 > 可用资源。 在计算机网络中的链路带宽、交换结点中的缓存和处理机等，都是网络中的资源。

2.拥塞解决不能靠解决某一个部分的问题。因为这会将瓶颈转移到其他地方。问题的实质往往是整个系统的各个部分不匹配。只有所有部分都平衡了，问题才会得到解决。

3.拥塞控制与流量控制的比较。

   1）拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

   拥塞控制有个前提：网络能够承受现有的网络负荷

   拥塞控制是一个全局性过程。（发送拥塞时，不知道在某处、什么原因造成的）

   2）流量控制：点对点通信量的控制，是个端到端的问题

   流量控制：抑制发送端发送数据的速率，以便使接收端来得及接收。

4.寻找拥塞控制的方案无非就是使不等式 “对资源的需求 > 可用资源 ”不再成立的条件。但是必须考虑该措施带来的其他影响。

5.计算机网络是个复杂的系统。从控制理论的角度来看拥塞控制，可以分为开环控制和闭环控制两种方法。

   1）开环控制：设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦系统运行起来，就不再中途改正。

   2）闭环控制：基于反馈环路。

   步骤一、监测网络系统以便检测到拥塞在何时、何处发生；

   步骤二、把拥塞发生的信息传送到可采取行动的地方

   步骤三、调整网络系统的运行以解决出现的问题

8.2 几种拥塞控制方法（只考虑网络拥塞程度，即假设接收方总是有足够大的缓存空间）

1.慢开始和拥塞避免

1）发送方维持一个拥塞窗口。

   拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。

   控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口增大；如果网络出现拥塞，则减小。

2）慢开始的思路：由小到大逐渐增大拥塞窗口数值。每收到一个对新的报文段的确认，把拥塞窗口增加至多一个MSS的数值。（没经过一个传输轮次，拥塞窗口cwnd就加倍）

轮次：把拥塞窗口所允许发送的报文段都连续发送出去，并收到了对已发送的最后一字节的确认。

慢开始的“慢”并不是指cwnd的增长速率慢，而是指TCP开始发送报文段时先设置cwnd=1（一个MSS数值）。

3）慢开始门限ssthresh

   为防止拥塞窗口增长过大，引入一个慢开始门限ssthresh。

   当cwnd < ssthresh时，使用上述的慢开始算法

   当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法

4）拥塞避免算法

思路：让拥塞窗口cwnd缓慢增大，即没经过一个往返时间RTT就把发送方的拥塞窗口cwnd增加1，而不是加倍。

5）慢开始门限的设置

只要发送方判断网络出现拥塞（没有按时收到确认），就把慢开始门限ssthresh设置为出现拥塞时发送方窗口值的一半，然后把拥塞窗口cwnd重置为1，执行慢开始算法。

6）乘法减小和加法增大

乘法减小：网络出现拥塞时，把慢开始门限ssthresh减半（当前的ssthresh的一半），并执行慢开始算法。

加法增大：执行拥塞避免方法

2.快重传和快恢复

1）快重传（尽快重传未被确认的报文段）

首先，要求接收方每收到一个失序的报文段后就立即发出重复确认。（如接收方收到了M1和M2后都分别发出了确认，但接收方没有收到M3但接着收到了M4。此时接收方立即发送对M2的重复确认。）

其次，发送方只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段M3.

2）快恢复

要点一、当发送方连续收到三个重复确认，就执行“乘法减小”算法，把慢开始门限ssthresh减半。

要点二、由于发送方认为网络很可能没有发生拥塞（因为收到了连续的重复确认），把cwnd设置为慢开始门限ssthresh减半后的值，然后开始执行拥塞避免算法

慢开始算法只在TCP连接建立时和网络出现超时才使用。

3.发送方的窗口

发送方窗口的上限值 = Min [rwnd, cwnd]

8.3 随机早期检测RED（IP层影响TCP层的拥塞控制）

1.网络层的分组丢弃策略

网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略。

如果路由器队列已满，则后续到达的分组将都被丢弃。这就叫做尾部丢弃策略。

2.全局同步

由于TCP复用IP，若发生路由器中的尾部丢弃，就可能会同时影响到很多条TCP连接，结果就使许多TCP连接在同一时间突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多，网络恢复正常后，其通信量又突然增大很多。

3.随机早期检测RED

使路由器的队列维持两个参数，即队列长度最小门限THmin和最大门限THmax。当每一个分组到达时，RED就先计算平均队列长度Lav。RED算法是：

1）若平均队列长度小于最小门限THmin，则把新到达的分组放入队列进行排队

2）若平均队列长度超过最大门限THmax，则把新到达的分组丢弃

3）若平均队列长度在最小门限THmin和最大门限THmax之间，则按照某一概率p将新到达的分组丢弃。

随机体现在3），在检测到网络拥塞的早期征兆时（即路由器的平均队列长度超过一定的门限值时），就先以概率p随机丢弃个别的分组，让拥塞控制只在个别的TCP连接上进行，因而避免发生全局性的拥塞控制。

4.平均队列长度Lav和分组丢弃概率p

Lav = (1-d) x (旧的Lav) +d x (当前的队列长度样本)

p = ptemp / (1- count x ptemp)

ptemp = pmax x (Lav - THmin) / (THmax - THmin)

TCP时面向连接的协议。

运输连接就有三个阶段：连接建立、数据传送和连接释放

运输连接的管理：使运输连接的建立和释放都能正常地进行。

在TCP连接建立过程中要解决以下三个问题：

   1）要使每一方能够确知对方的存在

   2）要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳等等）

   3）能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

9.1 TCP的连接建立

1.TCP规定，SYN=1报文段不能携带数据，但消耗一个序号

2.TCP规定，ACK=1报文段可以携带数据，如果不携带数据则不消耗序号

3.为什么A还要发送一次确认？为了防止已失效的连接请求报文突然又传送到B，因而产生错误。

“已失效的连接请求报文段”

A发出第一个连接请求报文段，在网络中滞留超时，又发出了第二个连接请求。但B收到第一个延迟的失效的连接请求报文段后，就误认为是A又发出了一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立。此时A不会理睬B的确认，也不会发数据，但B一直等A发送数据，B的许多资源就浪费了。

采用三次握手，A不会向B发送确认，因此B就知道A并没有要求建立确认。

9.2 TCP的连接释放

1.TCP规定，FIN报文段基石不携带数据，也消耗一个序号

2.第二次握手后，TCP通知高层应用程序，因而从A到B这个方向的连接就释放，TCP连接处于半关闭状态

3.为什么A在TIME-WAIT状态必须等待2MSL的时间

  1）为了保证A发送的最后一个ACK报文段能够到达B。因为ACK可能丢失，此时B可能会超时重传，然后A重传确认，并重新启动2MSL计时器

  2）防止“已失效的连接请求报文段”出现在本连接中。可以使本连接持续时间内所产生的所有报文段都从网络中消失。

9.3 TCP的有限状态机

计算机网络原理（谢希仁第八版）第五章课后习题答案

第五章

35题，36题已经做了更正，特别感谢粉丝奈七七的答案。
1.试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？为什么运输层是必不可少的？
答：运输层处于面向通信部分的最高层，同时也是用户功能中的最低层，向它上面的应用层提供服务 运输层为应用进程之间提供端到端的逻辑通信，但网络层是为主机之间提供逻辑通信（面向主机，承担路由功能，即主机寻址及有效的分组交换）。 各种应用进程之间通信需要“可靠或尽力而为”的两类服务质量，必须由运输层以复用和分用的形式加载到网络层。
2.网络层提供数据报或虚电路服务对上面的运输层有何影响？
答：网络层提供数据报或虚电路服务不影响上面的运输层的运行机制。 但提供不同的服务质量。
3.当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接的还是面向无连接的？
答：都是。这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。
4.试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接有复用到IP数据报上。
答：

在图中，主机H3同时和主机H1和主机H2进行通信。H1和H3两个应用进程（HTTP和SMTP）进行通信，这需要使用两个TCP连接。这两个TCP连接所传送的报文段，使用下面的网络层IP数据报进行传送。H2和H3的应用进程（HTTP）进行通信，这需要使用一个TCP进行连接。这个TCP连接所传送的报文段，也要使用下面的网络层IP数据报进行传送。在网络层所传送的IP数据报已看不到运输层以上的复用情况。
5.试举例说明有些应用程序愿意采用不可靠的UDP，而不用采用可靠TCP。
答：VOIP：由于语音信息具有一定的冗余度，人耳对VOIP数据报损失由一定的承受度，但对传输时延的变化较敏感。有差错的UDP数据报在接收端被直接抛弃，TCP数据报出错则会引起重传，可能带来较大的时延扰动。因此VOIP宁可采用不可靠的UDP，而不愿意采用可靠的TCP。
6.接收方收到有差错的UDP用户数据报时应如何处理？
答：丢弃。
7.如果应用程序愿意使用UDP来完成可靠的传输，这可能吗？请说明理由。
答：可能，但应用程序中必须额外提供与TCP相同的功能。
8.为什么说UDP是面向报文的，而TCP是面向字节流的？
答：发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。发送方TCP对应用程序交下来的报文数据块，视为无结构的字节流（无边界约束，课分拆/合并），但维持各字节。
9.端口的作用是什么？为什么端口要划分为三种？
答：端口的作用是对TCP/IP体系的应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。熟知端口，数值一般为0——1023.标记常规的服务进程；登记端口号，数值为1024——49151，标记没有熟知端口号的非常规的服务进程。
10.试说明运输层中伪首部的作用。
答：用于计算运输层数据报校验和。
11.某个应用进程使用运输层的用户数据报UDP，然而继续向下交给IP层后，又封装成IP数据报。既然都是数据报，可否跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没提提供？
答：不可跳过UDP而直接交给IP层IP数据报IP报承担主机寻址，提供报头检错；只能找到目的主机而无法找到目的进程。UDP提供对应用进程的复用和分用功能，以及提供对数据差分的差错检验。
12.一个应用程序用UDP，到IP层把数据报在划分为4个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
答：不行。重传时，IP数据报的标识字段会有另一个标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同，因此不能组装成一个IP数据报。
13.一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每一个IP数据报字段长度和片偏移字段的值。
答：UDP数据报 = 首部8字节 + 数据部分组成。
因为数据字段为8192字节，所以数据报总长度 = 8192 + 8 = 8200 字节。
以太网的最大传输单元MTU = 1500。
因为要划分为几个IP数据报，而每个IP数据报的首部占20字节，所以字段部分最大占1480字节。
划分的时候，可以划分为 8200 / 1480 = 5，余 800 字节。
所以应当划分为 6 个IP数据报片，前 5 个都是 1480 字节，第 6 个是 800 字节。一个字段即为8个字节。
第一个IP数据报字段长度：1480，第一片偏移字段：1480 * 0 / 8 = 0
第二个IP数据报字段长度：1480，第二片偏移字段：1480 * 1 / 8 = 185
第三个IP数据报字段长度：1480，第三片偏移字段：1480 * 2 / 8 = 370
第四个IP数据报字段长度：1480，第四片偏移字段：1480 * 3 / 8 = 555
第五个IP数据报字段长度：1480，第五片偏移字段：1480 * 4 / 8 = 740
第六个IP数据报字段长度：800， 第六片偏移字段：1480 * 5 / 8 = 925
UDP数据报的首部存在于第一个IP数据报片中，所以第一个IP数据报字段为：首部8字节 + 1472数据部分。
14.一UDP用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是服务器发送给客户？使用UDP的这个服务器程序是什么？
解：源端口：1586（前4个字节0632）
目的端口：69（00 45）
用户数据报总长度：28 字节（00 1C，其中首部占8字节）
数据部分长度：20 字节
这个用户数据报是：从客户发送给服务器
服务器程序：TFTP。
UDP数据报由首部字段和数据字段组成，其中首部占8个字节（TCP数据报首部占20字节），格式如下:

以上求出的长度为UDP数据报的总长度28字节，由于UDP数据报的首部占8字节，所以数据字段长度占20字节
因为目的端口号 69 < 1023，是常用的服务端口，所以这个数据报是发往服务器端的
0~1023：常用的服务端口
1024~49151是被注册的端口，也成为“用户端口”
其中 1024~5000为临时端口
因为端口号为69，所以使用 UDP 的这个服务器程序是TFTP
TFTP：是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。端口号为69。
15.使用TCP对实时话音数据的传输有没有什么问题？使用UDP在传送数据文件时会有什么问题？
答：如果语音数据不是实时播放（边接受边播放）就可以使用TCP，因为TCP传输可靠。接收端用TCP讲话音数据接受完毕后，可以在以后的任何时间进行播放。但假定是实时传输，则必须使用UDP。 UDP不保证可靠付，但UCP比TCP的开销要小很多。因此只要应用程序接受这样的服务质量就可以使用UDP。
16.在停止等待协议中如果不使用编号是否可行？为什么？
答:不可行，分组和确认分组都必须进行编号，才能明确哪个分则得到了确认。
17.在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也没做）是否可行？试举出具体的例子说明理由。
答:可行，比如收到重复的报文段不确认相当于确认丢失。
18.假定在运输层使用停止等待协议。发送发在发送报文段M0后再设定的时间内未收到确认，于是重传M0，但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1，不久就收到了对M1的确认。接着发送方发送新的报文段M0，但这个新的M0在传送过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0，并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。
答：
我们可以看出，旧的M0被当成是新的M0！可见运输层不能使用停止等待协议（编号只有 0 和1 两种）。
19.试证明：当用 n 比特进行分组的编号时，若接收到窗口等于 1（即只能按序接收分组），当仅在发送窗口不超过$2^n-1$时，连接 ARQ 协议才能正确运行。窗口单位是分组。
答：

Ⅰ、设发送窗口记为 W_T，接收窗口记为 W_R。假定用 3 比特进行编号。设接收窗口正好在 7 号分组处（有阴影的分组）。
Ⅱ、发送窗口 W_T的位置不可能比 ② 的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组，而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组，也就是不可能比 ② 的位置更靠前（前方就是图的右方）。
Ⅲ、发送窗口 W_T的位置不可能比 ③ 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组（以及以前的分组）发送了确认。但如果发送窗口 W_T的位置再靠后一个分组，即在 6 号分组的左边，那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。
Ⅳ、发送窗口 W_T的位置可能在某个位置的中间，如 ①。
对于 ① 和 ② 的情况，在 W_T的范围内必须无重复序号，即 W_T ⩽ $2^n$。
对于 ③ 的情况，在 W_T+ W_R的范围内无重复序号，即 W_T + W_R ⩽ $2^n$。
现在 W_R = 1,故发送窗口的最大值：W_T ⩽ $2^n-1$。
20.在连续 ARQ 协议中，若发送窗口等于 7，则发送端在开始时可连续发送 7 个分组。因此，在每一分组发送后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t₀,t₁,…t₆,且t_out都一样大。试问如何实现这 7 个超时计时器（这叫软件时钟法）？
答：
方法1：可采用链表记录，其信息域为分组的相对发送时间和分组编号来实现。当编号为 0 的分组定时时钟到期后，修改链表指针并重发此分组，同时将头指针指向编号为 1 的分组，以此类推。此类方法相当于数据结构算法里的链表建立的过程。我有一篇C++的链表文章，可以参考。

方法2：可以定义一个含有7个数据的数组，数组中的数据表示时间，当该组数据发送出去时，在对应序号的数组中填入时间值，该时间值是该组发送出去的时间+超时时间得到，如何不停的对该数组的值进行扫描，当接收到接收端的确认分组时，即将对应数组序号的时间值设置为空，准备记录下一个数据发发送时间，当系统时间大于数组中某一个时间值时，说明该分组以及超时了，需要进行重传。
21.使用连续 ARQ 协议中，发送窗口大小是 3，而序列范围 [0, 15]，而传输媒体保证在接收方能够按序收到分组。在某时刻，接收方，下一个期望收到序号是 5。试问：
（1）在发送方的发送窗口中可能有出现的序号组合有哪几种？
（2）接收方已经发送出去的、但在网络中（即还未到达发送方）的确认分组可能有哪些？说明这些确认分组是用来确认哪些序号的分组。
答:
（1）在接收方，下一个期望收到的序号是 5。这表明序号到 4 为止的分组都已收到。若这些确认都已到达发送方，则发送窗口最靠前，其范围是 [5, 7]。
假定所有的分组都丢失了，发送方都没有收到这些确认。这时，发送窗口最靠后，应为 [2, 4]。因此，发送窗口可以是 [2, 4]，[3, 5]，[4, 6]，[5, 7] 中的任何一个。
（2）接收方期望收到的序号 5 的分组，说明序号为 2，3，4 的分组都已收到，并且发送了确认。对序号为 1 的分组的确认肯定被发送方收到了，否则发送方不可能发送 4 号分组。可见，对序号为 2，3，4 的分组的确认有可能仍滞留在网络中。这些确认是用来确认序号为 2，3，4 的分组的。
22.主机 A 向主机 B 发送一个很长的文件，其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。
（1）在 TCP 的序号不重复使用的条件下，L 的最大值是多少？
（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部开销共 66 字节，链路的数据率为 10 Mb/s，试求这个文件所需的最短发送时间
答：（1）可能的序号共 $2^{32}$=4294967296 个。TCP 的序号是数据字段中每一个字节的编号，而不是每一个报文段的编号。因此，这一小题与报文段的长度无关，即用不到题目给出的 MSS 值。这个文件 L 的最大值就是可能的序号数，即 4294967296 字节。若1GB= $2^{30}$B，则 L 的最大值为 4 GB。
（2）发送帧数等于数据字节/每帧的数据字节=$2^{32}$/1460=2941758.422，需要发送 2941759 个帧。
帧首部的开销是 66×2941759 = 194156094 字节。
发送的总字节数 = $2^{32}$ + 194156094 = 4489123390字节。
数据率 10 Mbilt/s = 1.25 MB/s = 1250000 字节/秒。
发送 4489123390 字节需时间为：4489123390/1250000 =3591.3 秒。
即 59.85 分，约 1 小时。
23.主机 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 字节（实际上，就是序号 100 到序号 179 的字节，即 179 - 100 + 1 = 80 字节）
（4）B 在第二个报文段到达后向 A 发送确认，其确认号应为 70。（报文段丢失，就会重复发送确认上一个未收到的报文段第一个序号，即 70）
24.一个 TCP 连接下面使用 256 kb/s 的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）。
答：设发送窗口 = W（bit），再设发送端连续发送完窗口内的数据所需要的时间 = T。有两种情况：
（a）接收端在收完一批数据的最后才发出确认，因此发送端经过 (256 ms + T) 后才能发送下一个窗口的数据。
（b）接收端每收到一个很小的报文段就发回确认，因此发送端经过比 256 ms 略多一些的时间即可在发送数据。因此每经过 256 ms 就能发送一个窗口的数据。

（a）：吞吐量=数据量/时间
数据量=W；时间=发送时延+往返时延=W/256kbit/s+256ms；
吞吐量=W/[(W/256kbit/s)+256ms]=120kbit/s;
求得W=57825.88bit，约等于7228字节。
（b）：吞吐量=数据量/时间
数据量=W；时间=发送时延+往返时延=256ms（这里b是发送一点就确认接收一点，所以发送时延可以忽略不计。）
吞吐量=W/256ms=120kbit/s；
求得W=30720bit=3840字节。
25.为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节？
答：在 ICMP 的差错报文中要包含 IP 首部后面的8个字节的内容，而这里面有 TCP 首部中的源端口和目的端口。当 TCP 收到 ICMP 差错报文时需要用这两个端口来确定是哪条连接出了差错。
26.为什么在 TCP 首部中有一个首部长度字段，而 UDP 的首部中就没有这个这个字段？
TCP 首部除固定长度部分外，还有选项，因此 TCP 首部长度是可变的。UDP 首部长度是固定的。
27.一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号，问还能否用 TCP 来传送？
答：（1） 一个 TCP 那段的数据部分最多为 65495 字节，此数据部分加上 TCP 首部的 20 字节，再加上 IP 首部的 20 字节，正好是 IP 数据报的最大长度 65535。（当然，若 IP 首部包含了选择，则 IP 首部长度超过20字节，这时 TCP 报文段的数据部分的长度将小于 65495 字节。）
（2）如果数据的字节长度超过 TCP 报文段中的序号字段可能编出的最大序号，仍可用 TCP 传送。编号用完后可重复使用。但应设法保证不出现编号的混乱。
IP 数据报的最大长度 = $2^{1}6$ − 1 = 65535 字节
TCP 报文段的数据部分 = IP 数据报的最大长度 - IP 数据报的首部 - TCP 报文段的首部 = 65535 - 20 - 20 = 65495 字节
一个 TCP 报文段的最大载荷是 65515 字节.
IP数据报的最大长度为 $2^{1}6$ − 1= 65535 字节，减去 IP 数据报首部 20 字节和 TCP 首部 20 字节后的 TCP 报文段的数据部分为 65495 字节。
28.主机 A 向主机 B 发送 TCP 报文段，首部中的源端口是 m 而目的端口是n。当 B 向 A 发送回信时，其 TCP 报文段的首部中源端口和目的端口分别是什么？
答：当 B 向 A 发送回信时，其 TCP 报文段的首部中得到源端口就是 A 发送的 TCP 报文段首部的目的端口 n，而 B 发送的 TCP 报文段首部中的目的端口就是 A 发送的 TCP 报文段首都的源端口 m。
29.在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
答：还未重传就收到了对更高序号的确认。因为 TCP 接收方只会对按序到达的最后一个分组发送确认。当对更高的序号确认了，意味着已经到达了，即不用重传了。
30.设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时延为 20 ms，问所能得到的最大吞吐量是多少?
解： 最大吞吐量那就是单位时间内的最大发送数据量。
即每20ms可以发送65535×8=524280bit。
吞吐量=524280bit/20ms=26.2Mb/s。
31.通信信道带宽为 1 Gb/s，端到端时延为 10 ms。TCP 的发送窗口为 65535 字节。试问:可能达到的最大吞吐量是多少?信道的利用率是多少?
解：吞吐量=发送数据/时间
发送数据最大=65535×8=524280bit。
时间=发送时延+往返时延=524280bit/(1Gbit/s)+20ms=20.524ms。
最大吞吐量=524280bit/20.524ms=25.5Mbit/s。
信道利用率=吞吐量/带宽=(25.5Mbit/s)/(1Gbit/s)×100%=2.55%。
32.什么是 Karn 算法?在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度?
答：Karn 算法允许 TCP 能够区分开有效的和无效的往返时间样本，从而改进往返时间的估算。
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如下图所示，TCP 发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。
但是，根据题意，我们就认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零、
因此，上述的这种做法是不可取的。
33.假定 TCP 在开始建立连接时，发送方设定超时重传时间是RTO = 6秒。
（1）当发送方接到对方的连接确认报文段时，测量出 RTT 样本值为1.5秒。试计算现在的RTO值。
（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为2.5秒。试计算现在的RTO值。
解：（1）当第一次测量RTT样本时，RTT_S就取值RTT样本值为1.5s。RTT_S=1.5s
根据RFC2988的建议，RTT_D取值为RTT样本值的一半。
RTT_D=0.75s
根据公式可得：RTO=RTT_S+4RTT_D=1.5s+3s=4.5s
（2）新的RTT样本为2.5s。（根据RFC6298推荐，α取1/8，β取1/4。）
即新的RTT_S=（1-α）×（旧的RTT_S)+α×（新的RTT样本）=1.625s
新的RTT_D=（1-β）×（旧的RTT_D)+β×|RTT_S-新的RTT样本|=0.78s
根据公式：RTO=RTT_S+4RTT_D=1.625s+4×0.78s=4.75s
34.已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值RTT_S。讨论所得出的结果。
解：公式：即新的RTT_S=（1-α）×（旧的RTT_S)+α×（新的RTT样本）
第一次：RTT_s=（1-0.1）×30ms+0.1×26ms=29.6ms
第二次：RTT_S=（1-0.1）×29.6ms+0.1×32ms=29.86ms
第三次：RTT_S=（1-0.1）×29.86ms+0.1×24ms=29.256ms
三次的加权平均时间相差不大，当RTT样本值变化不大时，RTT_s的变化也是很小的。
35.用TCP通过速率为1Gbit/s的链路传送一个10MB的文件。假定链路的往返时延RTT=50ms。TCP选用了窗口扩大选项，使窗口达到可选用的最大值。在接收端，TCP的接收窗口为1MB，而发送端采用拥塞控制算法，从慢开始传送。假定拥塞窗口以分组为单位计算，在一开始发送1个分组，而每个分组长度都是1KB.假定网络不会发生拥塞和分组丢失，并且发送端发送数据的速率足够快，因此发送时延可以忽略不计，而接收端每一次收完一批分组后就立即发送确认ACK分组。
(1)经过多少个RTT后，发送窗口大小达到1MB？
(2)发送端把整个10MB文件传送成功共需要多少个RTT？传送成功是指发送完整个文件，并收到所有的确认。TCP扩大的窗口够用么？
(3)根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？
解：(1)根据拥塞算法，就是每一次接收端发出确认时，发送端口就会增加为原来的2倍。则1MB=1024KB。那么就是$2^{10}$KB=1MB，也就是来回十次就可以了，经过10个RTT，发送窗口大小达到1MB。

(2)从图中可看出，当第10个RTT结束时，已传送成功的分组是$2^{10}-1$个分组，正好比1MB少一个分组。一个分组只有1KB，可先不考虑。可以这样分析:在第10个RTT结束时，发送窗口为1MB，已传送成功的数据量约为1MB（准确的是1MB-1 KB)，因此在此基础上，我们还需要再传送9MB（实际上还需要再传送9MB+ 1 KB)。由于每经过一个RTT，发送窗口就加倍，因此在第11个RTT结束时，又成功发送了1MB。第12个RTT结束时，又成功发送了2MB。第13个RTT结束时，又成功发送了4MB。至此，一共又成功传送了I+2+4=7MB。与9MB 相比还差2MB。因此还要经过一个RTT。在第14个RTT开始时把所有剩下的数据2MB(实际上是2MB+1KB）都发送完毕。这样，全部10MB的数据成功发送完毕需要14个 RTT。
(3)吞吐率=数据量/时间
数据量=10MB=10×$2^{20}$B=10×$2^{20}$×8bit
时间=14×50ms=0.7s
有效吞吐率=10×$2^{20}$×8bit/0.7s=119.8Mbit/s
带宽利用率=吞吐量/带宽
带宽利用率=119.8Mbit/s/1Gbit/s×100%=11.98%
36.假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。在一开始发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一分组后，就立即发回确认ACK。假定分组的编号为i，在一开始发送的是i=1的分组。以后当i=9，25，30，38，50时，发生了分组的丢失。再假定分组的超时重传时间正好是下一个RTT开始的时间。试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。
答：开始时拥塞窗口（发送窗口)为1 pkt，发送编号为1的分组。
当RTT=1时(即第1个RTT结束时),收到确认，拥塞窗口增大到2 pkt,发送2个分组，其编号为2和3。
当RTT=2时(即第2个RTT结束时),收到确认,拥塞窗口增大到3 pkt,发送3个分组，其编号为4~～6。
当RTT=3时(即第3个RTT结束时),收到确认,拥塞窗口增大到4 pkt,发送4个分组，其编号为7~10。
但在RTT=4时(即第4个RTT结束时),发送端发现编号为9的分组丢失了,没有收到相应的确认。于是这时把拥塞窗口减半，从前面的4减到2。请注意，拥塞窗口的值仅在RTT为整数值时才有意义。因为只有在这些时刻，确定了发送端能够发送几个分组。分组一旦发送出去，发送窗口就不再起作用。只有到了下一个RTT 结束时，发送窗口才再次起作用。
后面的分组发送，在图中表示，就不再作过多的解释了。但最后，在RTT=18时，由于编号为50的分组丢失，拥塞窗口应减半，从5 pkt减小到2.5 pkt。但分组组不能只发送半个，因此实际上拥塞窗口就是2。如果在图中把拥塞窗口设定为2.5 pkt，那么在发送时也只能发送2个分组。因此在RTT -18时，发送的分组编号是50和51。

37.在 TCP 的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法?这里每一种算法各起什么作用? “乘法减小”和“加法增大”各用在什么情况下?
答：
① 慢开始：
在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以分组注入到网络的速率更加合理。
② 拥塞避免：
当拥塞窗口值大于慢开始门限时，停止使用慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延 RTT 就增加一个 MSS 的大小。
③ 快重传算法规定：
发送端只要一连收到三个重复的 ACK 即可断定有分组丢失了，就应该立即重传丢手的报文段而不必继续等待为该报文段设置的重传计时器的超时。
④ 快恢复算法：
当发送端收到连续三个重复的 ACK 时，就重新设置慢开始门限 ssthresh 与慢开始不同之处是拥塞窗口 cwnd 不是设置为 1，而是设置为 ssthresh 若收到的重复的 ACK 为 n 个（n>3），则将 cwnd 设置为 ssthresh 若发送窗口值还容许发送报文段，就按拥塞避免算法继续发送报文段。若收到了确认新的报文段的 ACK，就将 cwnd 缩小到 ssthresh。
⑤ 乘法减小：
是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时（即出现一次网络拥塞），就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。
⑥ 加法增大：
是指执行拥塞避免算法后，在收到对所有报文段的确认后（即经过一个往返时间），就把拥塞窗口 cwnd 增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。
38.设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？
答：拥塞窗口大小及变化原因见下表：

轮次	拥塞窗口	拥塞窗口变化的原因
1	1	网络发生了超时，TCP 使用慢开始算法
2	2	拥塞窗口值加倍
3	4	拥塞窗口值加倍
4	8	拥塞窗口值加倍，这是 ssthresh 的初始值
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 值置为 1；其次执行慢开始算法，cwnd 按指数规律增长，因此随后窗口大小分别为 2，4，8。当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 9，10，11，12，直到上升到 12 为止发生拥塞；然后把门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5，门限值 ssthresh 变为6,；然后进入慢开始，cwnd 值置为1，cwnd 按指数规律增长，随后窗口大小分别为 1，2，4，6。当拥塞窗口 cwnd = ssthresh 时，进入拥塞避免阶段，其窗口大小依次是 7，8，9。
39.TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示：

（1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
（2）指明 TCP 工作在慢开始阶段的时间间隔。
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。
（4）在第 16 轮次和第 22 轮次之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？
（5）在第 1 轮次，第 18 轮次和第 24 轮次发送时，门限 ssthresh 分别被设置为多大？
（6）在第几轮次发送出第 70 个报文段？
（7）假定在第 26 轮次之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？
答：(1)
（2）慢开始时间间隔：[1, 6] 和 [23, 26]
（3）拥塞避免时间间隔：[6, 16] 和 [17, 22]
（4）在第 16 轮次之后发送方通过收到三个重复的确认，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口减半了。在第 22 轮次之后发送方通过超时，检测到丢失了报文段，因为题目给出，下一个轮次的拥塞窗口下降到 1了。
（5）在第 1 轮次发送时，门限 ssthresh 被设置为 32，因为从第 6 轮次起就进入了拥塞避免状态，拥塞窗口每个轮次加 1。
在第 18 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 42 的一半，即 21。
在第 24 轮次发送时，门限 ssthresh 被设置为发生拥塞时拥塞窗口 26 的一半，即 13。
（6）第 1 轮次发送报文段 1。（cwnd = 1）
第 2 轮次发送报文段 2， 3。（cwnd = 2）
第 3 轮次发送报文段 4 ~ 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，而门限 ssthresh 应设置为检测出报文段丢失时的拥塞窗口 8 的一半，即 4。
40.TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出三种情况。
答：不是因为拥塞而引起分组丢失的情况是有的，举例如下：
① 当 IP 数据报在传输过程中需要分片，但其中一个数据报片未能及时到达终点，而终点组装 IP 数据报已超时，因而只能丢弃该数据报。
② IP 数据报已经到达终点，但终点的缓存没有足够的空间存放此数据报。
③ 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的储存空间而只好丢弃。
41.用 TCP 传送 512 字节的数据。设窗口为 100 字节，而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200，试画出类似于教材中图 5-31 的工作示意图。从连接建立阶段到连接释放都要画上。
要传送的 512 B 的数据必须划分为 6 个报文段传送，前 5 个报文段各 100 B，最后一个报文段传送 12 B。下图是双方交互的示意图。下面进行简单的解释。
【----- 进行三报文握手 -----】
报文段 #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 到 602 共 12 字节的数据。因此，报文段 #15 的确认号是 ack = 613（所期望收到的下一个数据字节的序号）。
需要注意的是，从报文段 #5 一直到 报文段 #15，B 一共发送了 6 个确认，都不消耗序号，因此 B 发送的报文段 #15 的序号仍然和报文段 #5 的序号一样，即 seq = 201。
【-----数据传送完毕-----】
【-----进行四报文挥手------】
报文段 #16：A 发送 FIN 报文段。前面所发送的数据报文段 #14 已经用掉了序号 601 到 612，因此报文段 #16 序号是 seq = 613。A 进入 FIN-WAIT-1 状态。报文段 #16 的确认号 ack = 202。
报文段 #17：B发送确认报文段，确认号为 614，进入 CLOSE-WAIT 状态。由于确认报文段不消耗序号，因此报文段 #17 的序号仍然和报文段 #15 的一样，即 seq = 201
报文段 #18：B 没有数据要发送，就发送 FIN 报文段 #18，其序号仍然是 seq = 201。这个 FIN 报文会消耗一个报文。
报文段 #19：A 发送最后的确认报文段。报文段 #16 的序号是 613，已经消耗掉了。因此，现在的序号是 seq = 614。但这个确认报文段并不消耗序号。
【-----四报文挥手结束-----】
42.在图 5-29 中所示的连接释放过程中，主机 B 能否先不发送 ACK = x + 1 的确认?（因为后面要发送的连接释放报文段中仍有 ACK = x + 1 这一信息）
答：
如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。
43.在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？
答：

当 A 和 B 都作为客户，即同时主动打开 TCP 连接。这时的每一方的状态变迁都是：
CLOSED -> SYN-SENT -> SYN-RCVD -> ESTABLISHED
44.试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
答：设 A，B建立了运输连接。
协议应考虑一下实际可能性： A 或 B 故障，应设计超时机制，使对方退出，不至于死锁；
A主动退出，B被动退出
B主动退出，A被动退出
45.解释为什么突然释放运输连接就可能会丢失用户数据，而使用 TCP 的连接释放方法就可保证不丢失数据。
答：当主机 1 和主机 2 之间连接建立后，主机 1 发送了一个 TCP 数据段并正确抵达主机 2，接着主机 1 发送另一个TCP数据段，这次很不幸，主机 2 在收到第二个 TCP 数据段之前发出了释放连接请求，如果就这样突然释放连接，显然主机 1 发送的第二个 TCP 报文段会丢失。
而使用 TCP 的连接释放方法，主机 2 发出了释放连接的请求，那么即使收到主机 1 的确认后，只会释放主机 2 到主机 1 方向的连接，即主机 2 不再向主机 1 发送数据，而仍然可接收主机 1 发来的数据，所以可保证不丢失数据。
46.试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。
答：3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
假定 B 给 A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功地建立了，可以开始发送数据分组。可是，B 在 A 的应答分组在传输中被丢失的情况下，将不知道 A 是否已准备好，不知道 A 建议什么样的序列号，B 甚至怀疑 A 是否收到自己的连接请求分组，在这种情况下，B 认为连接还未建立成功，将忽略 A 发来的任何数据分组，只等待连接确认应答分组。而 A 发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
47.一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据，请求服务器发送一个长度为 L

以上是关于运输层知识要点——谢希仁《计算机网络》的主要内容，如果未能解决你的问题，请参考以下文章

耗时一个月！期末熬夜复习整理 | 计算机网络（谢希仁第七版）大合集知识点+大量习题讲解

计算机网络原理（谢希仁第八版）第五章课后习题答案

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

计算机网络 华南理工大学期末重点 第五章 传输层 谢希仁

《计算机网络（第7版）谢希仁 著》第三章 数据链路层 要点及习题总结

谢希仁计算机网络学习系列内容汇总