电子科大计网期末复习之传输层

博客原文：https://uestcwxy.love/2023/06/21/计网/3/

1、传输层：两个进程之间的逻辑通信，网络层: 两个主机之间的逻辑通信

• 传输层协议运行在端系统
  • 发送方: 将应用程序报文分成报文段传递给网络层,
  • 接受方: 将报文段重新组装成报文传递到应用层
• 传输层可以为应用提供多种协议(因特网: TCP 和 UDP)
  • 可靠按序递交 (TCP)：拥塞控制/流量控制/连接建立
  • 不可靠的无序传递: UDP“尽力传递” IP的直接扩展
  • 两种服务均不保证: 延迟/带宽

2、多路复用/多路分解工作原理

在发送主机多路复用:从多个套接字收集数据, 用首部封装数据，然后将报文段传递到网络层(多路复用）

在接收主机多路分解:将接收到的数据段传递到正确的套接字（多路分解）

多路复用/分解如何工作?（报文段头部字段实现）

• 主机收到IP数据报

  • 每个数据报有源IP地址，目的IP地址
  • 每个数据报搬运一个报文段
  • 每个报文段有源和目的端口号 （回忆: 对于特定应用程序具有周知端口号)

• 主机用IP地址和端口号指明报文段属于哪个合适的套接字

3、无连接多路分解（ UDP 套接字：目的IP地址, 目的端口号）

• 当主机收到UDP报文段：检查报文段中的目的端口号、用端口号指示UDP报文段属于哪个套接字
• 来自不同的源IP地址且/或源端口号的IP报文报，导向同一个的套接字
• SP 提供“返回地址”

4、面向连接的多路分解（TCP套接字：源IP地址、源端口号、目的IP地址、目的端口号）

• 服务器主机支持很多同时的TCP 套接字:每个套接字用4部分来表示
• Web服务器对每个连接的客户都有不同的套接字：非持久 HTTP 将对每个请求有一个不同的套接字

5、 UDP用户数据报协议

UDP 是面向报文的

基于Internet IP协议

• 复用/分用
• 简单的错误校验

“尽最大努力”服务，报文段可能:

• 丢失
• 会传递失序的报文到应用程序无连接
• 在UDP接收者发送者之间没有握手
• 每个UDP 报文段的处理独立于其他报文段

为什么有 UDP?

• 不需要建立连接 (减少延迟)
• 简单: 在发送者接受者之间不需要连接状态
• 很小的报文段首部
• 没有拥塞控制: UDP 能够用尽可能快的速度传递

常用于流式多媒体应用：丢包容忍/速率敏感

其他UDP应用：DNS/SNMP/RTP

经UDP的可靠传输 : 在应用层增加可靠性/应用程序特定的差错恢复！

6、UDP报文格式（8字节）每个字段含义

7、UDP是面向报文的传输方式

面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。因此，应用程序必须选择合适大小的报文。若报文太长，则IP层需要分片，降低效率。若太短，会是IP太小。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。即应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文。

思考大的视频文件如何利用UDP传输：

• 将大数据分成多个小包，每个小包的大小不能超过UDP协议数据包的最大长度（一般为64KB）。

• 在每个小包中增加一个序列号，用于确保数据包的顺序和完整性。

• 在每个小包中增加一个校验和，用于检测数据包在传输过程中的错误。

• 接收方将收到的小包按照序列号和校验和的方式进行重组和验证，确保数据的完整性和正确性。

• 对于丢失的数据包，发送方需要在一定时间内进行重传，以保证数据的可靠性。

9、UDP首部的校验和计算

（1）将UDP伪头部、UDP头部和数据部分全部用16进制数表示。

（2）将第一个16进制数与第二个16进制数相加。求和时产生的进位必须回卷加到结果上。

（3）将上一步得到的16位数与第三个16进制的数相加，重复第二步，直到累加完所有的16进制数，并且得到的结果为16进制数。

（4）将累加最后得到的16进制数取反，得到校验和。

发送方对校验和进行了反码操作，并放入了校验和字段 发送给了接受方 等接收方对其他字段进行了二进制的加法，其中就有校验和字段，就会变成原码和反码的加法，就都变成1了，如果不是都是1的话 那就说明其中的字段和发送方的字段不一样，肯定就是错误的，就把包丢了。

10、可靠数据传输原理rdt1.0-rdt3.0的工作场景（no loss、lost packet、lost ack、timeout）

Rdt1.0: 完全可靠信道上的可靠数据传输

Rdt2.0: 具有bit错误的信道

• 下层信道可能让传输分组中的bit受损：利用校验和检测bit位错误
• 问题: 如何从错误中恢复
  • 确认(ACKs): 接收方明确告诉发送方分组接收正确
  • 否认 (NAKs):接收方明确告诉发送方分组接收出错
  • 发送方收到NAK后重发这个分组
• 在 rdt2.0中的新机制 (在 rdt1.0中没有的)：
  • 差错检测
  • 接收方反馈: 控制信息 (ACK,NAK) rcvr->sender
  • 重传

停等协议:发送方发送一个报文，然后等待接受方的响应

rdt2.0: 缺陷

如果ACK/NAK发生错误/被破坏(corrupted)会怎么样？

• 为ACK/NAK增加校验和，检错并纠错
• 发送方收到被破坏ACK/NAK时不知道接收方发生了什么，添加额外的控制消息
• 如果ACK/NAK坏掉，发送方重传
• 不能简单的重传：产生重复分组

如何解决重复分组问题？

• 序列号(Sequence number): 发送方给每个分组增加序列号
• 接收方丢弃重复分组

rdt2.2: 无NAK的消息协议

我们真的需要两种确认消息(ACK + NAK)吗？

• 同 rdt2.1一样的功能, 但只用 ACKs
• 如何实现？
  • 接收方通过ACK告知最后一个被正确接收的分组
  • 在ACK消息中显式地加入被确认分组的序列号
• 发送方收到重复ACK之后，采取与收到NAK消息相同的动作
  • 重传当前分组

rdt3.0: 具有出错和丢失的信道

新假设: 下层信道还要丢失报文 (数据或者 ACKs)

校验和, 序号, 确认, 重发将会有帮助，但是不够

方法: 发送者等待“合理的”确认时间

• 如果在这个时间内没有收到确认就重发
• 如果报文（或者确认）只是延迟 (没有丢失):
  • 重发将导致重复，但是使用序号已经处理了这个问题
  • 接受方必须指定被确认的报文序号
• 要求倒计时定时器：只有在定时器超时时才触发重发

rdt3.0的性能分析

流水线: 发送方允许发送多个 “在路上的”, 还没有确认的报文

• 序号数目的范围必须增加
• 在发送方/接收方必须有缓冲区

流水线技术的两个通用形式: go-Back-N,*** 选择重传***

11、GBN协议

Go-Back-N(GBN)协议: 发送方

• 分组头部包含k-bit序列号
• 窗口尺寸为N，最多允许N个分组未确认

• ACK(n): 确认到序列号n(包含n)的分组均已被正确接收
  • 可能收到重复ACK
• 对第一个发送未被确认的报文定时(timer)
• timeout(n):若超时，重传窗口中的分组n及所有更高序号的分组

Go-Back-N(GBN)协议: 接收方

只有ACK: 对接收的分组总是发送具有最高按序序号的ACK

• 可能产生冗余的ACKs
• 仅仅需要记住期望的序号值（expectedseqnum）

对失序的分组:

• 丢弃 (不缓存) -> 没有接收缓冲区!
• 重新确认具有按序的分组

12、SR协议

• 接收方分别确认已经收到的分组:必要时，缓冲报文, 最后按序提交给上层
• 发送者只重发没有收到确认的分组:对每个没有确认的报文发送者都要启动一个定时器(每个未被确认的报文都有一个定时器)
• 发送窗口:N 个连续序号/限制被发送的未确认的分组数量

发送方

• 从上层收到数据 ：如果下一个可用的序号在发送方窗口内，则将数据打包并发送,启动定时器
• 超时(n)：重发分组n, 重启定时器
• 收到ACK(n)在[sendbase,sendbase+N-1]内:
  • 标记分组n被接收
  • 如果n是最小的未确认分组，则增加窗口基序号到下一个未被确认的序号

接收方

• 分组n的序号在[rcvbase, rcvbase+N-1]内

  • 发送ACK(n)

  • 失序分组: 缓冲

  • 有序分组: 交付上层 (包括已经缓冲的有序分组), 提高窗口到下一个没有接收的分组

• 分组n在[rcvbase-N,rcvbase-1]内

  • 发送ACK(n)

• 其他：忽略

选择性重传: 两难选择

例子:

序号: 0, 1, 2, 3

window size=3

在两种情况下接收方没有感觉到差别!

Q: 窗口大小和序号大小有什么关系?

A: 窗口小于或等于序号空间大小的一半

可靠数据传输机制及用途总结

机制	用途和说明
检验和	用于检测在一个传输分组中的比特错误。
定时器	用于检测超时/重传一个分组，可能因为该分组（或其ACK）在信道中丢失了。由于当一个分组被时延但未丢失（过早超时），或当一个分组已被接收方收到但从接收方到发送方的ACK丢失时，可能产生超时事件，所以接收方可能会收到一个分组的多个冗余拷贝。
序号	用于为从发送方流向接收方的数据分组按顺序编号。所接收分组的序号间的空隙可使该接收方检测出丢失的分组。具有相同序号的分组可使接收方检测出一个分组的冗余拷贝。
确认	接收方用于告诉发送方一个分组或一组分组已被正确地接收到了。确认报文通常携带着被确认的分组或多个分组的序号。确认可以是逐个的或累积的，这取决于协议。
否定确认	接收方用于告诉发送方某个分组未被正确地接收。否定确认报文通常携带着未被正确接收的分组的序号。
窗口、流水线	发送方也许被限制仅发送那些序号落在一个指定范围内的分组。通过允许一次发送多个分组但未被确认，发送方的利用率可在停等操作模式的基础上得到增加。我们很快将会看到，窗口长度可根据接收方接收和缓存报文的能力或网络中的拥塞程度，或两者情况来进行设置。

13、TCP是面向面向连接传输

• 点到点:

  • 一个发送者,一个接收者

• 可靠按序的字节流:

  • 没有“信息边界”

• 流水线:

  • TCP 拥塞和流量控制设置窗口大小

• 收发缓冲区
  

• 全双工数据:

  • 同一个连接上的双向数据流
  • MSS: 最大报文段长

• 面向连接:

  • 在数据交换前握手(交换控制信息)
  • 连接状态只在连接的两端中维护，在沿途节点中并不维护状态。
  • TCP连接包括：两台主机上的缓存、连接状态变量、socket等

• 流量控制:

  • 发送方不会淹没接收方

TCP是面向字节流，虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

有可能将多条数据当成一条数据进行处理，因此需要在应用层进行数据的边界管理

编程影响：上层可能会将多条数据当做一条数据处理。

特殊字符间隔： 使用此方法则必须对数据中的特殊字符进行转义，否则会造成二义

数据定长：规定固定长度的数据，实际数据少的则需要进行补位

在应用层头部定义数据长度（例如http协议，先取头部，再根据头部中的数据长度取出数据）

14、TCP报文格式（字段含义/用途）

15、 TCP 往返时延的估计和超时

设置超时

• EstimtedRTT 加上 “安全余量”

• EstimatedRTT变化大 -> 更大的安全余量

SampleRTT 偏离 EstimatedRTT多少的估计

• DevRTT = (1-β)*DevRTT +β*| SampleRTT-EstimatedRTT | (典型地, β = 0.25)

然后设置超时时间间隔:

TimeoutInterval = EstimatedRTT + 4*DevRTT

设置超时

初始时TimeoutInterval设置为1秒

第一个样本RTT获得后， EstimatedRTT=SampleRTT，DevRTT=SampleRTT/2， TimeoutInterval =EstimatedRTT + max (G, K*DevRTT) （K=4，G是用户设置的时间粒度）

16、TCP可靠数据传输

TCP 发送方事件

• 从应用程序接收数据:

  • 用序号创造一个报文
  • 序号是报文中第一个数据字节在字节流中的位置编号
  • 如果没有启动定时器，则启动定时器 （定时器是最早没有被确认的报文发送时启动的）
  • 设置超时间隔: TimeOutInterval

• 超时:

  • 重发导致超时的报文
  • 重新开始定时器

• 收到确认:

  • 如果ACK落在窗口之内，则确认对应的报文，并且滑动窗口
  • 若还有未确认的报文，重新开始定时器

TCP 接收方事件

接收方的事件	TCP 接收方行为
期望序号的报文段按序到达. 所有在期望序号以前的报文段都被确认	延迟ACK. 等到 500ms看是否有下一个报文段，如果没有，发送ACK
期望序号的报文段按序到达.另一个按序报文段等待发送ACK	立即发送单个累积ACK, 确认两个有序的报文段
收到一个失序的报文段，高于期望的序号，检测到缝隙	立即发送重复 ACK, 指出期望的序号
到达的报文段部分地或者完全地填充接收数据间隔	立即发送 ACK, 证实缝隙低端的报文段已经收到

超时间隔加倍

• TCP每次重传，都会把下一次的超时间隔设置为先前值的两倍。

• 但是当收到上层应用的数据和收到ACK两个事件中的任何一个发生时，定时器的TimeoutInterval值恢复为由近期的EstimatedRTT和DevRTT计算得到。

• TimeoutInterval =EstimatedRTT + max (G, K*DevRTT) （K=4，G是用户设置的时间粒度）

快速重传

• 发送方可以在超时之前通过重复的ACK检测丢失报文段
• 发送方常常一个接一个地发送很多报文段
• 如果报文段丢失,则发送方将可能接收到很多重复的 ACKs
• 如果发送方收到4个对同样报文段的确认，则发送方认为该报文段之后的数据已经丢失。
• 启动快速重传: 在定时器超时之前重发丢失的报文段

17、 TCP 流量控制机制

(假设 TCP 接收方丢弃失序的报文段)

• 缓冲区的剩余空间= RcvWindow= RcvBuffer-[LastByteRcvd - LastByteRead]

• 接收方在报文段接收窗口字段中通告其接收缓冲区的剩余空间

• Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow尺寸

• Receiver告知Sender，RcvWindow=0,会出现什么情况？

18、 TCP连接管理（序号、确认序号）

建立连接

回忆: TCP在交换数据报文段之前在发送方和接收方之间建立连接

初始化TCP 变量:

-序号

-缓冲区流控信息 (例，接收窗口)

客户: 连接发起者 Socket clientSocket = new Socket(“hostname”,“port number”);

服务器: 被客户联系 Socket connectionSocket = welcomeSocket.accept();

三次握手：

Step 1: 客户发送TCP SYN报文段到服务器

-指定初始的序号

-没有数据

Step 2: 服务器接收SYN, 回复 SYN/ACK 报文段

-服务器分配缓冲区

-指定服务器的初始序号

Step 3: 客户接收 SYN/ACK, 回复 ACK 报文段, 可能包含数据

关闭连接

客户关闭套接字: clientSocket.close

Step 1: 客户发送 TCP FIN 控制报文段到服务器

Step 2: 服务器接收 FIN, 回复 ACK. 进入半关闭连接状态；

Step 3: 服务器发送FIN到客户，客户接收 FIN, 回复 ACK，进入 “time wait”状态等待结束时释放连接资源

Step 4: 服务器接收 ACK. 连接关闭.

19、拥塞控制的方法

根据网路层是否为运输层拥塞控制提供了显示帮助，来区分拥塞控制方法。分为两类方法:

端到端拥塞控制:

• 没有从网络中得到明确的反馈
• 从端系统观察到的丢失和延迟推断出拥塞
• TCP采用的方法

网络辅助的拥塞控制:

路由器给端系统提供反馈

单bit指示拥塞 (SNA, DECnet, TCP/IP ECN, ATM)

指明发送者应该发送的速率

19、TCP拥塞控制（慢启动、拥塞避免、快速恢复；总结: TCP 拥塞控制）

• 端到端控制 (没有网络辅助)

• 发送方限制发送: LastByteSent-LastByteAcked <min( CongWin , RcvWindow )

• 大体上,

  rate=CongWin /RTT(Bytes/sec)，CongWin 是动态的, 感知的网络拥塞的函数

• 发送方如何感知拥塞 ?

  • 丢失事件 = 超时或者 3 个重复的ACKs
  • TCP 发送方在丢失事件发生后降低发送速率 (CongWin)

• 如何合理控制发送速率？

  • AIMD（拥塞避免）
  • 慢启动

TCP AIMD(Additive-increase,multiplicative-decrease)

原理：发送方增加传输速率（窗口大小），谨慎地探测可用带宽，直到发生丢包事件

方法：AIMD

• 加性递增: 每个RTT内如果没有丢失事件发生，拥塞窗口增加1个MSS（拥塞避免）
• 乘性递减: 发生丢包事件后将拥塞窗口减半

TCP 慢启动（slow start）

• 连接开始的时候, CongWin = 1 MSS

  • Example: MSS = 500 bytes & RTT = 200 msec

  • 初始速率 = 20 kbps

• 有效带宽将 >> MSS/RTT

  • 希望尽快达到期待的速率，故将以2的指数方式增加速率。

• 故以指数方式增加速率，直到产生丢失事件，或者达到某个阈值ssthresh

ssthresh（阈值）变量

（发送丢失事件后，ssthresh设置为丢失事件事件前的 CongWin 的1/2）

什么时候从指数增加变为线性增加（拥塞避免）?

• 当CongWin达到ssthresh时。
• 每收到1个ACK, CongWin =CongWin + (MSS/ CongWin)*MSS

对拥塞事件的反应

• 当超时事件发生时:
  • CongWin 立即设置为 1个 MSS；
  • 窗口开始指数增长（进入慢启动）
  • 到达一个阈值后再线性增长
• 收到三个重复的确认时：
  • CongWin 减半+3 (Reno版)
  • 然后，窗口线性增长（快速恢复）

注：上述为TCP Reno版本的内容，在TCP Tahoe版本里，无论超时还是三个重复，都直接将CongWin 置为 1个 MSS

怎么理解不同的丢包事件？

• 3 个重复的 ACKs 表明网络具有传输一些数据段的能力
• 在三个重复的确认之前超时是“更加严重的警告”

在快速恢复阶段：

• 对于引起TCP进入快速恢复状态的缺失报文段，每收到一个冗余的ACK，CongWin的值增加一个MSS。
• 最终，当对丢失的报文段的一个ACK到达时，TCP在降低 CongWin（cwnd = ssthresh）后，进入拥塞避免状态。

---

UDP 报文实现差错检测时，不需要在网络上传输的部分是（A ）

A. 伪首部 B. 首部 C. 数据 D. 校验和

运输层协议在端系统和路由器中都可以实现。( × )

数据0x9876A543的十六比特因特网校验和为（ C ）

A、0x3DB9 B、0x3DBA C、0xC245 D、0xC246

十六比特因特网校验和是通过将数据分成16位的字，然后将这些字相加，如果有溢出则将溢出部分加到结果上，最后对结果取反得到的。对于数据0x9876A543，我们可以将其分成两个16位的字：0x9876和0xA543。将这两个字相加得到0x13DB9，由于有溢出，所以我们需要将溢出部分加到结果上，得到0x3DBA。最后对结果取反得到校验和为0xC245。

UDP服务器端将为每个客户的请求建立一个新的套接字。 （ × ）

TCP 中，套接字是一对一的关系。如要向 10 个客户端提供服务，那么除了负责监听的套接字外，还需要创建 10 套接字。但在 UDP 中，不管是服务器端还是客户端都只需要 1 个套接字。

一条线路带宽为1Mbps，往返时延为45ms，假设数据帧的大小为1000字节。若采用停等协议方式，实际的数据率大约是（ C ）。

A、15Kbps B、1.5Kbps C、151Kbps D、1510Kbps

由于带宽为1Mbps，所以发送一个1000字节的数据帧需要8ms。加上往返时延45ms，总共需要53ms才能发送一个数据帧。因此，实际的数据率为1000字节/53ms = 151.51Kbps。

在选择重传协议中，假设发送窗口和接收窗口的大小相等，如果用来表示分组序号的字段长度为8个比特，则发送方窗口长度最大为（ C ）。

A、32 B、64 C、128 D、256

在选择重传协议中，发送窗口和接收窗口的大小相等，用来表示分组序号的字段长度为8个比特，那么序号的范围为0-255。由于选择重传协议要求发送窗口的大小不能超过序号空间的一半，所以发送方窗口长度最大为256/2=128。

流水线可靠传输技术中序号的数量应该大于等于发送窗口和接收窗口之和。（√）

因为序号的数量决定了可以同时发送的数据帧的数量，而发送窗口和接收窗口之和决定了可以同时发送和接收的数据帧的数量。如果序号的数量小于发送窗口和接收窗口之和，那么就会出现序号重复的情况，导致数据传输出错。因此，为了保证流水线可靠传输技术的正确性，序号的数量应该大于等于发送窗口和接收窗口之和。

GBN回退N帧可靠传输中某一分组超时时，要重传该分组及其以后的所有分组。（√）

因为在GBN协议中，接收方只能按序接收数据帧，如果某一分组丢失，那么其后面的所有分组都无法被接收方正确接收。因此，当某一分组超时时，发送方需要重传该分组及其以后的所有分组，以保证数据的正确传输。

在选择重传（SR）协议中，发送方可能会收到落在其当前窗口之外的分组的ACK包。（√）

比如，如果序号为sendbase的分组发送后，接收方正确的收到了该分组，但是对其应答的ack超时，没有到，于是发送方又重发了序号为sendbase的分组。而接收方，也会再次发送ack。后到的ack就可能在窗口外。

能为计算机网络通信提供加密防护服务的协议是( B )。

A、ARP B、SSL C、SMTP D、PPP

SSL协议在传输层和应用层之间，为网络通信提供安全保障。

ARP（Address Resolution Protocol）是一种用于将IP地址解析为物理地址的协议；SMTP（Simple Mail Transfer Protocol）是一种用于发送电子邮件的协议；PPP（Point-to-Point Protocol）是一种用于在点对点链路上进行数据传输的协议。

TCP是一个点对点的协议，协议双方连接的端点是应用进程端口号（ √ ）

TCP报头中的确认号是指（ B ）

A、传输数据的第一个字节在缓冲区中的位置编号

B、期待接收的下一个字节的位置编号

C、已连续接收的最后一个字节在缓冲区中的位置编号

D、当前接收数据的序号

确认号用于告诉发送方，接收方已经成功接收到了哪些数据，期待接收的下一个字节的序号是多少。这样，发送方就可以根据确认号来判断哪些数据已经被成功接收，哪些数据需要重传。

假设主机 A 通过一条 TCP 连接向主机 B 发送两个紧接着的 TCP 报文段。第一个 报文段的序号为 90，第二个报文段序号为 110。
a. 第一个报文段中有多少数据？20 bytes
b. 假设第一个报文段丢失而第二个报文段到达主机 B。那么在主机 B 发往主机 A 的确认报文中，确认号应该是多少？确认号 = 90

假定主机A通过TCP连接向主机B发送一个序号为20的20字节报文段后，那么主机A收到的确认号不可能是（ B ）

A、10 B、39 C、40 D、无法确定

主机甲和主机乙间已建立一个TCP连接，主机甲向主机乙发送了两个连续的TCP段，分别包含300字节和500字节的有效载荷，第一个段的序列号为200，主机乙正确接收到两个段后，发送给主机甲的确认序列号是 （ D ）

A．500 B.700 C.800 D.1000

TCP协议中的确认号表示接收方期待接收的下一个字节的序号。由于主机甲发送了两个连续的TCP段，分别包含300字节和500字节的有效载荷，所以主机乙期待接收的下一个字节的序号应该是200+300+500=1000。

主机甲与主机乙之间已建立一个TCP连接，主机甲向主机乙发送了3个连续的TCP段，分别包含300字节、400字节和500字节的有效载荷，第3个段的序号为900。若主机乙仅正确接收到第1和第3个段，则主机乙发送给主机甲的确认序号是（B ）

A．300 B．500 C．1200 D．1400

TCP什么时候对报文段采用快速重传？ ©

A、报文段的定时器过期

B、估计往返时延过长

C、收到之前发出的一个报文段的三个重复ACK

D、以上都不是

快速重传是TCP协议中的一种重传机制，它用于在收到三个或以上的冗余ACK（duplicate ACK）时快速重传丢失的数据包。当发送方收到三个重复的ACK时，它可以推断出接收方已经成功接收了之前的报文段，但是当前的报文段丢失了。因此，发送方会立即重传该报文段，而不是等待定时器过期。

网络上所抓到的TCP数据报文段中，有一个字段RcvWindow，其含义和作用为（ A ）

A、接收可用空间大小，用于流量控制

B、发送可用空间大小，用于流量控制

C、发送可用空间大小，用于拥塞控制

D、接收可用空间大小，用于拥塞控制

是接收方向发送方指示接收缓存可用空间的大小，主要用于发送方控制其发送窗口的大小。

主机甲和主机乙之间已建立一个TCP连接，TCP最大段长度为1000字节，若主机甲的当前拥塞窗口为4000字节，在主机甲向主机乙连接发送2个最大段后，成功收到主机乙发送的第一段的确认段，确认段中通告的接收窗口大小为2000字节，则此时主机甲还可以向主机乙发送的最大字节数是（A）

A：1000 B：2000 C：3000 D：4000

TCP采用序列号、确认、滑动窗口协议等机制来实现端到端节点之间可靠的数据传输。其中，滑动窗口协议规定未被确认的分组数最多为窗口的大小，且只需要重传未被确认的分组。通告的接收窗口大小为2000B，则说明此时主机乙具有一个2000B的空闲缓冲区，即此时主机乙最大还可以接收2000B的数据。由于主机乙还未对主机甲发出第2个报文段进行确认，因此这2000B的空闲缓冲区还需预留出1000B用于接收第2个报文段，即此时主机甲还可以向主机乙发送的最大字节数只有1000B。

主机甲向主机乙发送一个(SYN＝1，seq＝3210)的TCP段，期望与主机乙建立TCP连接，若主机乙接受该连接请求，则主机乙向主机甲发送的正确的TCP段可能是（C ）

A．(SYN＝0，ACK＝0，seq＝3211，ack＝3211)

B．(SYN＝1，ACK＝1，seq＝3210，ack＝3210)

C．(SYN＝1，ACK＝1，seq＝3211，ack＝3211)

D．(SYN＝0，ACK＝0，seq＝3210，ack＝3210)

TCP是面向连接的,所谓面向连接,就是当计算机双方 通信时必需先建立连接,然后数据传送,最后拆除三个过程,也就是 客户主动打开TCP传输,服务器被动打开。第一次握手:客户发送SYN =1, seq = x给服务器,即客户的TCP向服务器发出连接请求报文段, 其首部中的同步位SYN=1,并选择序号seq = x,表明传送数据时的第一个数据字节的序号是 x。第二次握手:服务器发送 SYN= 1, ACK =l , seq = y, ack = x+1给客户,即服务器的TCP收到连接请求报文段后,如同意则发回确认。服务器在确认报文段中应使 SYN=1,使ACK= 1,其确认号ack = x+1,自己选择的序号seq = y。第三次握手: 客户发送ACK= 1, seq = x+1, ack = y+1给服务器,即客户收到此报 文段后向服务器给出确认, 其ACK= 1,确认号ack = y+1。客户的TCP 通知上层应用进程,连接已经建立。服务器的 TCP收到主机客户的确认后,也通知其上层应用进程: TCP连接已经建立。 如果ACK为0，那么数据报不包含确认信息，确认字段被省略。 SYN：用于建立连接。 目前连接还在建立阶段，乙向甲发送的TCP段是包含确认信息ack的， 则SYN=1，ACK=1； 至于seq，ack，乙向甲发送的seq可以随意，但是 乙向甲发送的 ack却要求是之前甲向乙发送的请求seq加1。

一个TCP连接总是以1KB的最大段长发送TCP段，发送方有足够多的数据要发送。当拥塞窗口为16KB时发生了超时，如果接下来的4个RTT（往返时间）时 间内的TCP段的传输都是成功的，那么当第4个RTT时间内发送的所有TCP段 都得到肯定应答时，拥塞窗口大小是多少？

根据慢开始算法的原则,在第4个RTT时间后,拥塞窗口为16,此时发生拥塞,拥塞窗口大小变为1KB,慢开始门限值变为8 KB。接下来3个RTT后,拥塞窗口大小变为8 KB,此时进入拥塞避免算法,当第4个RTT后,拥塞窗口加1,拥塞窗口大小变为9 KB。

16KB超时，阈值变为8KB，客户端从1KB开始穿（执行快开始算法）

1RTT 结束，1KB->2KB
2RTT 结束，2KB->4KB
3RTT 结束，4KB->8KB（到达阈值，执行拥塞避免算法）
4RTT 结束，8KB->9KB

（1）将“慢开始门限值”设置为出现超时时刻的“拥塞窗口值”的一半，也就是16KB ÷ 2 = 8KB；

（2）将“拥塞窗口值”设置为1KB，重新开始“慢开始”算法。题目还给定超时后的4个RTT（往返时间）时间内的TCP段的传输都是成功，也就是说超时后又进行了以下四个轮次的传输：

超时后的第一个传输轮次：拥塞窗口值为1KB，进行超时后的第一个传输轮次，成功后拥塞窗口值增加到2KB；

超时后的第二个传输轮次：拥塞窗口值为2 KB，进行超时后的第二个传输轮次，成功后拥塞窗口值增加到4 KB；

超时后的第三个传输轮次：拥塞窗口值为4 KB，进行超时后的第三个传输轮次，成功后拥塞窗口值增加到8 KB；

超时后的第四个传输轮次：拥塞窗口值为8 KB，进行超时后的第四个传输轮次，成功后需要增加拥塞窗口的值，由于已经达到“慢开始门限值”，因此拥塞窗口的值线性加1 KB变为9 KB，之后改用“拥塞避免”算法。

拥塞避免和慢启动
当拥塞发生时（超时或收到重复确认），慢启动门限ssthresh被设置为当前拥塞窗口cwnd大小（题目为16）的一半，即8。同时cwnd重置为1（最大报文段长度）。新的数据被接收，则cwnd增加，规则为ssthresh之前， 慢启动，即cwnd指数增长；到达ssthresh之后， 拥塞避免，即cwnd加1。

TCP 可靠数据传输过程中的定时器设置，初始时定时器 T 设置为 1 秒，第 1 个样本 SampleRTT=2 秒，获得该样本后估算 EstimatedRTT=2 秒，偏差 DevRTT=1 秒，第 2 个样本 SampleRTT=1 秒，第 3 个样本 SampleRTT=3 秒，计算收到第三个样本后 TCP 为第四个待发送分 组设定的定时器 T 的值？（要求：给出 EstimatedRTT 和 DevRTT 的均值公式和定时器 T 的计算 公式，EstimatedRTT 公式中系数是 0.125，DevRTT 公式中系数是 0.25，给出每次收到样本时均 值的变化，计算时小数保留 3 位）

ERTT=（1-a）ERTT+a*SRTT
DRTT=（1-b）DRTT+b*|SRTT-ERTT|
T=ERTT+4*DRTT
收到第二个样本后：DRTT=（1-0.25）*1+0.25*|1-2|=1 秒 ，ERTT=（1-0.125）*2+0.125*1=1.875 秒
收到第三个样本后：DRTT=（1-0.25）*1+0.25*|3-1.875|=1.031 秒 ，ERTT=（1-0.125）*1.875+0.125*3=2.016 秒
定时器 T：（1 分） T=2.016+4*1.031=6.14 秒

（注：在计算DRTT时，ERTT用上一轮的）

在SR中，发送窗口大小不能超过序号空间的(1/2)。

小于(1024)的TCP/UDP端口号已保留与现有服务一一对应，此数字以上的端口号可自由分配。

设TCP拥塞窗口的当前阈值为8（单位为报文段），当拥塞窗口上升到12时收到3个重复ACK，那么下一轮传输时拥塞窗口大小为( )

A.8 B.9 C.6 D.4

在 TCP 拥塞控制中，当收到 3 个重复的 ACK 时，会触发快速重传和快速恢复算法。在快速重传和快速恢复算法中，当收到 3 个重复的 ACK 时，阈值会被设置为当前拥塞窗口大小的一半，拥塞窗口大小会被设置为阈值加上 3 个 MSS（最大报文段长度）的大小。根据题目中给出的信息，当前阈值为 8，当拥塞窗口上升到 12 时收到 3 个重复 ACK。此时，阈值会被设置为当前拥塞窗口大小的一半，即 12/2=6。拥塞窗口大小会被设置为阈值加上 3 个 MSS 的大小，即 6+3=9。

TCP通信时，若某一方发送带有FIN标志的数据段，其含义为（C）

A.将断开通信双方的TCP连接

B.连接被重新建立

C.单方面释放连接，表示本方已经无数据发送，但可以接收对方数据

D.终止数据发送，双方都不能发送数据

假设使用8位校验和字段对数据0x5879B432计算Internet校验和，结果是（C）

A.0xB8

B.0x48

C.0x47

D.0xB7

以下哪个TCP熟知端口号是错误的（ D ）

A.HTTP:80

B.TELENT:23

C.SMTP:25

D.FTP:24

一般情况下,FTP使用的端口号为21和20。

主机甲和主机乙已建立TCP连接，甲始终以MSS=1KB大小的段发送数据，并一直有数据发送；乙每收到一个数据段都会发出一个接收窗口为10KB的确认段。若甲在t时刻发生超时，其拥塞窗口为8KB。则从t时刻开始，不再发生超时情况下，经过10个RTT后，甲的发送窗口是多少？

当t时刻发生超时时，把sthresh设为8的一半，即为4，且拥塞窗口设为1KB。然后经历10个RTT后，拥塞窗口的大小依次为2、4、5、6、7、8、9、10、11、12，而发送窗口取当时的拥塞窗口和接收窗口的最小值，而接收窗口始终为10KB，所以此时的发送窗口为10KB。

简述 TCP 拥塞控制中进入慢启动、快速恢复、拥塞避免三种状态对应的触发事件？

慢启动状态的事件：开始传输；超时；低于阈值；

快速恢复的事件：三次及以上重复确认；

拥塞避免：高于阈值，正常收到分组确认

假设主机A通过一条TCP连接向主机B发送一个大文件。主机A发送但未被确认的字节数不会 超过接收缓存的大小。 （ √ ）

流量控制

假设主机A通过TCP连接向主机B发送一个大文件。如果某个段(segment)的Seq号为 m,那下一个正常发送的段的Seq号必然为m+1（×）

下一个正常发送的段的序列号并不一定是m+1，而是m加上前一个段中数据的字节数。例如，如果前一个段中包含512个字节的数据，那么下一个正常发送的段的序列号将是m+512。

TCP报文段在它的首部中有一个rwnd字段。(√)

rwnd即接收窗口（receive window），用来告知发送方，自己在该TCP连接的缓存中还有多少可用空间

假定在一条TCP连接中最后的SampleRTT等于1秒，那么对于该连接的TimeoutInterval的当前值 必定大于等于1秒。 （ × ）

Timeout Interval=EstimatedRTT+4×DevRTT，所以TimeoutInterval数据和SampleRTT无关

假设主机A通过一条TCP连接向主机B发送一个序号为38的4个字节的报文段。在这个相同的 报文段中，确认号必定是42。 （ × ）

某些情况下（比如该报文段发送超时）接收方会发送一个重复的ACK，即确认号仍然是 38。

考虑TCP的拥塞控制。当发送方定时器超时时，其ssthresh的值将被设置为原来值的 一半。（ x ）

看准了，应该是ssthresh被设置为当前拥塞窗口的一半。

考虑一个GBN协议，其发送方窗口为4,序号范围为1024。假设在时刻接收方期待的下一个有序分组的序号是k，且媒体不会对报文重新排序。回答以下问题：

a. 在t时刻，发送方窗口内的报文序号可能是多少？论证你的回答。

b. 在t时刻，在当前传播回发送方的所有可能报文中，ACK字段的所有可能值是多少？论证你的 回答。

GBN协议特点：GBN协议几个特点：

• 发送方拥有一个窗口，长度为N；
• 接收方无窗口，只接收希望接受序号的报文，对于失序到达的报文段采取的方式是直接丢弃；
• 在重传的时候，将会重传当前发送方窗口中所有未被确认的报文段。

a）在t时刻，接收方起到收到的下一个分组序号为k，说明接收方已经正确接受了k之前的所有分组，对于发送方而言，我们考虑两种最极端的情况：

第一种情况：假设之前所有的报文都正确传输，没有任何丢失的问题，那么在这种情况下，发送方正确接收了接收方对于小于k的所有报文的ACK确认，因此窗口将会不断向后移动，序号如下图所示：

k	k+1	k+2	k+3

第二种情况：由已知条件我们可以得知序号为k-1的报文是发送方发送的最后一个报文，假设该报文虽然到达了接收方，但是接收方返回的ACK确认由于一些原因没有到达发送方，则窗口不会移动，在这种情况下我们再假设序号k-1位于窗口的最后一列，即如下图所示的所有序号报文都没有在发送方被确认，则得到了我们最坏的一种情况：

K-4	K-3	K-2	K-1

两种极端情况中间的任意一种情况都可能发生，因此发送方窗口序号可能为k-4、k-3、k-2、k-1、k、k+1、k+2、k+3。如果发送方窗口为N，则发送方窗口序号可能为[k，k+N-1]或[k-N，k-1]。

b）如果接收机正在等待分组k，则它已经接收（并确认）了分组k-1和在此之前的3个分组。如果发送方尚未接收到这4个ACK中的任何一个，则值为[k-4，k-1]的ACK消息可能仍在传播。ACK字段的所有可能值为k-1、k-2、k-3、k-4。如果发送方窗口为N，那么ACK字段的所有可能值为[k-N，k-1]。

考虑从主机A向主机B传输L字节的大文件，假设MSS为536字节。

a. 为了使得TCP序号不至于用完，L的最大值是多少？前面讲过TCP的序号字段为4字节。

b. 对于你在(a)中得到的L，求出传输此文件要用多长时间？假定运输层、网络层和数据链路层首部总共为66字节，并加在每个报文段上，然后经155Mbps链路发送得到的分组。忽略流量控制和拥塞控制，使主机A能够一个接一个连续不断地发送这些报文段。

a. 序号占用 4 字节，即 32 位。它的范围是 [0,2^32−1]，也就是说一共有 4 294 967 296 个序号。 L = 2^32 = 4294967296 byte

b. 报文段的数量为L/MSS取上整。4294967296/536 ≈ 8012999组 所有分组的总头部信息 = 66 * 8012999 = 528857934 byte 总数据量 4294967296 + 528857934 = 4823825230 byte 所需时间 = 4823825230 byte/155Mbps ≈ 249秒 = 4.15分钟

UDP和TCP使用反码来计算它们的检验和。假设你有下面3个8比特字节:01010011，01100110，01110100。这些8比特字节和的反码是多少?(注意到尽管UDP 和 TCP 使用 16 比特的字来计算检验和，但对于这个问题，你应该考虑8比特和。)写出所有工作过程。UDP 为什么要用该和的反码，即为什么不直接使用该和呢?使用该反码方案，接收方如何检测出差错?1比特的差错将可能检测不出来吗?2比特的差错呢?

0101 0011 + 0110 0110 = 1011 1001 1011 1001 + 0111 0100 = 1 0010 1101（多了一位，第一位1回卷） 0010 1101 + 1 = 0010 1110 取其反码，得到1101 0001。

运用反码相加，全1的检测对于计算机来说更加方便，速度会更快。

将反码1101 0001 放在检验和处，在接受方将全部的传输数据和检验和相加为1111 1111时，无差错，只要有任意一位为0，传输中就出现了差错。

1比特的差错一定能够检查出来，2比特的差错如果出现在同一位上，则会被忽略。

主机A和B经一条TCP连接通信，并且主机B已经收到了来自A的最长为126字节的所有字节。 假定主机A随后向主机B发送两个紧接着的报文段。第一个和第二个报文段分别包含了 80字节和 40字节的数据。在第一个报文段中，序号是127,源端口号是302,目的地端口号是80。无论何时 主机B接收到来自主机A的报文段，它都会发送确认。

a)在从主机A发往B的第二个报文段中，序号、源端口号和目的端口号各是什么？

b)如果第一个报文段在第二个报文段之前到达，在第一个到达报文段的确认中，确认号、源端口号和目的端口号各是什么？

c)如果第二个报文段在第一个报文段之前到达，在第一个到达报文段的确认中，确认号是什么？

d)假定由A发送的两个报文段按序到达B。第一个确认丢失了而第二个确认在第一个超时间隔之后 到达。画出时序图，显示这些报文段和发送的所有其他报文段和确认。（假设没有其他分组丢 失。）对于图上每个报文段，标出序号和数据的字节数量；对于你增加的每个应答，标出确认号。

a） 在从主机A到B的第二段中，序列号为207，源端口号码是302，目的地端口号是80。

b） 如果第一段在第二段之前到达，则在对第一段的确认中到达段，确认号为207，源端口号为80并且目的地端口号是302。

c） 如果第二段在第一段之前到达，则在对第一个到达的段，确认号码是127，表明它仍然是等待字节127及以后。

d）

假设TCP Reno是一个经历如上所示行为的协议，回答下列问题。在各种情况中，简要地论证你的回答。

（1）指出TCP慢启动运行时的时间间隔。

（2）指出TCP拥塞避免运行时的时间间隔。

（3）在第16个传输轮回之后，报文段的丢失是根据3个冗余ACK还是根据超时检测岀来的？

（4）在第22个传输轮回之后，报文段的丢失是根据3个冗余ACK还是根据超时检测出来的？

（5）在第1个传输轮回里，ssthresh的初始值设置为多少？

（6）在第18个传输轮回里，ssthresh的值设置为多少？

（7）在第24个传输轮回里，ssthresh的值设置为多少？

（8）在哪个传输轮回内发送第70个报文段？

（9）假定在第26个传输轮回后，通过收到3个冗余ACK检测出有分组丢失，拥塞的窗口长度和 ssthresh的值应当是多少？

（10）假定使用TCP Tahoe （而不是TCP Reno）,并假定在第16个传输轮回收到3个冗余ACK。在第19 个传输轮回，ssthresh和拥塞窗口长度是什么？

（11）再次假设使用TCP Tahoe,在第22个传输轮回有一个超时事件。从第17个传输轮回到第22个传 输轮回（包括这两个传输轮回），一共发送了多少分组？

(1) [1,6] and [23,26]

(2) [6,16] and [17,22]

(3) 3个冗余ACK

(4) 超时

(5) 32

(6) 21（在16轮回， CongWin = 42, ssthresh设置为当前拥塞窗口的一半）

(7) 14（在22轮回， CongWin = 29,向下取整）

(8) 7（64-96）

(9) 4，7

(10) 21，4（拥塞窗口长度变为1，慢启动，17为1，18为2，19为4）

(11) 52=1+2+4+8+16+21(第17个发了1个，第18个发了2个，第19个发了4个，第20个发了8个，第21个发了16个，第22个翻倍超过ssthresh，因此只发了21个,慢启动不能超阈值)

主机A通过一条TCP连接向主机B发送一个很大的文件。在这条连接上，不会出现任何分组丢失和定时器超时。主机A与因特网连接链路的传输速率表示为R bps，主机A上的进程能够以S bps 的速率向TCP套接字发送数据，其中S = 10 x R。假设TCP的接收缓存足够大，能够容纳整个文件，并且发送缓存只能容纳这个文件的百分之一。如何防止主机A上的进程连续地向TCP套接字以速率S bps传送数据呢？还是用TCP流量控制呢？还是用TCP拥塞控制？或者用其他措施？阐述其理由。

首先，由于接收方的接收缓存能容纳整个大文件，因此不会出现流量控制；并且因为在这条连接上不会出现任何分组丢失和定时器超时，因此拥塞控制机制不会遏制发送方的速率。最后，由于发送方的发送缓存会很快被填充满，因此一旦发送缓存被填充满，进程将无法继续以 S 速率向套接字发送数据，而是以 R 向套接字发送数据。

比较GBN、SR和TCP（无延时的ACK）。假设对所有3个协议的超时值足够长，使得5个连续的数据报文段及其对应的ACK能够分别由接收主机（主机B）和发送主机（主机A）收到（如果在信道中无丢失）。假设主机A向主机B发送5个数据报文段，并且第二个报文段（从A出发）丢失。最后所有5个数据报文段已经被主机B正确接收。

请问主机A总共发送了多少个报文段和主机B总共发送了多少ACK？它们的序号是多少？对于三种协议回答这个问题。

假设发送的五个数据报文段的序号分别为1、2、3、4、5.

GBN：A总共发送了5+4=9个报文段，分别为1、2、3、4、5、2、3、4、5，B总共发送了4+4=8个ACK，序号分别为1、1、1、1、2、3、4、5；

SR：A总共发送了5+1=6个报文段，分别为1、2、3、4、5、2，B总共发送了4+1=5个ACK，序号分别为1、3、4、5、2；

TCP：A总共发送了5+1=6个报文段，分别为1、2、3、4、5、2，B总共发送了4+1=5个ACK，序号分别为2、2、2、2、6.

对于TCP，GBN，SR之间关系的总结：

GBN：

发送方拥有一个窗口，长度为N；

接收方无窗口，只接收希望接受序号的报文，对于失序到达的报文段采取的方式是直接丢弃；

在重传的时候，将会重传当前发送方窗口中所有未被确认的报文段；

采用累计应答的方式。例如接收端返回ACK=3，则证明报文段3以及之前的报文段都被正确接收。

接收端不对失序到达的分组进行缓存。

SR：

发送方拥有一个窗口，长度为N；

接收方拥有一个窗口，长度为N，对于失序到达的报文段将会缓存下来；

在重传的时候，将会重传窗口中超时的单个报文，而不会重传窗口中所有的报文；

接收端返回ACK是当前接收成功报文段的序号，SR不采用累计应答的方式，如接收到序号为0的报文段，则ACK确认ACK=0。

TCP：

TCP使用累计应答的方式。这一点与GBN类似。

TCP在接收端会设置缓存，来缓存正确接收但是失序的分组，这点与SR类似。（实际上TCP RFC并没有对接收端要怎样处理失序到达的分组提出要求，但是在接收端设置缓存是实践中大家都采用的方法）

TCP使用快速重传机制：如果收到对于一个特定报文段的3个冗余ACK，则在超时事件发生前就会对该报文段进行重传，这大大节约了时间。

在重传的时候，将会重传窗口中超时的单个报文，而不会重传窗口中所有的报文；

接收方回复的ACK确认序号是希望接收到的下一个报文段的序号，如接收到序号为0的报文段，则ACK确认ACK=1。

补充关于选择重传的过程：

窗口下界：最左边第一个窗口对应的序号

假设发送窗口和接收窗口都为4，发送方发送0帧，接收方收到0帧，并回复0帧确认，由于0帧是接收窗口下界，于是移动窗口使得窗口下界为第一个未被接收的帧（1号帧），同时把新加入帧（4号帧）的状态置为可接收状态：

发送方发送1帧，接收方收到1帧，并回复1帧确认，由于1帧是接收窗口下界，于是移动窗口使得窗口下界为第一个未被接收的帧（2号帧），同时把新加入帧（5号帧）的状态置为可接收状态：

发送方发送2帧，但是2帧丢失，接收方未收到2帧：

发送方发送3帧，接收方收到3帧，缓存三帧，发送ACK3：

发送方收到ACK0，由于窗口下限被确认，所以窗口右移一个，发送4帧，接收方收到4帧，缓存，发送ACK4：

发送方收到ACK1，由于窗口下界被确认，所以窗口右移1个，发送5帧，接收方接收5帧，缓存，发送ACK5：

发送方2帧超时未收到2帧确认，重新传2帧，这次接收方收到了，2-5帧交付（发送给上层网络层），发送ACK2：

发送方收到ACK3，但是无帧可发，等待，一直到ACK2到达，窗口下界被确认，窗口右移1个。