5-01 试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？为什么运输层是必不可少的？
地位：属于面向通信部分的最高层，同时也是用户功能中的最底层。
功能：向应用层提供通信服务。
区别：网络层为主机之间提供提供通信，可以使分组到达目的主机的网络层。但主机间的通信实际上是进程之间的通信，网络层无法给进程之间提供通信，但运输层可以，运输层通过其自身的功能，依靠网络层提供的服务，就可以实现两主机间进程与进程的通信。
运输层是要实现应用进程通信的，所以必不可少。
5-02 网络层提供数据报或虚电路服务对上面的运输层有何影响？
虚电路提供可靠服务，保证了数据报在主机之间的无差错传输，但不能保证运输层的无差错传输。数据报服务是不可靠的。总之，网络层提供数据报服务或虚电路服务对运输层是否可靠没有影响。
5-03 当应用程序使用面向连接的TCP和无连接的IP时，这种连接是面向连接的还是面向无连接的？
这要在不同层次来看，在运输层是面向连接的，在网络层则是无连接的。
5-04 试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接又复用到IP数据报上。
H3和H1、H2同时进行通信。H3和H1中的两个进程HTTP和SMTP通信，H3和H2中的HTTP进程通信，共三个TCP连接。三个tcp连接传输的报文段都需要通过下面的网络层利用IP数据报作为载体进行传输。
5-05 试举例说明有些应用程序愿意采用不可靠的UDP，而不用采用可靠TCP。
对实时性要求高的应用程序愿意采用UDP获得低时延的效果，尽管会丢失部分数据报。
5-06 接收方收到有差错的UDP用户数据报时应如何处理？
简单丢弃即可。
5-07 如果应用程序愿意使用UDP来完成可靠的传输，这可能吗？请说明理由。
可能，但应用程序中必须额外提供与TCP相同的功能。
5-08 为什么说UDP是面向报文的，而TCP是面向字节流的？
UDP发送报文时将应用层传下来的报文添加首部后直接交给IP层，接收UDP报文时去掉首部直接交给应用层。
TCP发送报文时先将报文缓存起来，将其看做字节流，对每个字节都要编号，TCP根据网络拥塞情况与对方接收缓存大小决定一次发送多少字节的数据报。
5-09 端口的作用是什么？为什么端口号要划分为三种类型？
端口是应用层中的应用进程与运输层实体进行层间交互的接口，只具有本地意义。
服务器端使用两类端口号，熟知端口号和登记端口号，熟知端口号是给重要的应用程序使用的，登记端口号给没有熟知端口号的应用程序使用。这两类给服务器端使用，为了让所有用户都知道，便于通信。
客户端使用短暂端口号，这种端口号仅在客户端运行时才动态随机选择，留给客户临时使用。
5-10 试说明运输层中伪首部的作用。
用来计算报文的检验和。
5-11 某个应用进程使用运输层的用户数据报UDP，然而继续向下交给IP层后，又封装成IP数据报。既然都是数据报，可否跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没提提供？
不能，UDP数据报中仅指明了通信进程双方的端口号，应用层的数据报直接交付给IP层后，虽然IP层能将数据报运送至目的主机，但不能确定通信进程双方的端口号，无法将数据交付给目的进程，不能完成通信。
没有复用和分用功能，不能实现进程间通信，没有数据部分的差错检验。
5-12 一个应用程序用UDP，到IP层把数据报在划分为4个数据报片发送出去，结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。重传的IP数据报的标识字段会有不同的标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同，因此不能组装成一个IP数据报。
5-13 一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每一个IP数据报片的数据字段长度和片偏移字段的值。
UDP用户数据报的长度：8192+8 = 8200字节
以太网数据字段最大长度1500字节，假设IP数据报首部长度20字节，则数据部分长度为1480字节。
8200 = 1480x5 + 800 所以需划分为6个数据报片。
前五个数据报片数据字段长度1480字节，最后一个800字节。
片偏移字节依次为：0,1480,2960,4440,5920,7400字节。
片偏移字段依次为：0,185,370,555,740,925
5-14 UDP用户数据报的首部十六进制表示是：06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是服务器发送给客户？使用UDP的这个服务器程序是什么？
源端口：0000 0110 0011 0010，十进制为1586。
目的端口：0000 0000 0100 0101，十进制为69。
长度：0000 0000 0001 1100，十进制为28。
数据部分长度：28-8=20。
目的端口小于1023，是服务器端口，程序时TFTP。
5-15 使用TCP对实时话音数据的传输会有什么问题？使用UDP在传送数据文件时会有什么问题？
TCP虽然保证可靠传输，但它的延迟大，因为一旦有分组丢失就要重传，增加时延。
UDP是不可靠的传输协议，UDP传输数据文件如果出现差错，UDP就会丢弃这个数据报，不会重传，所以数据文件有可能是错误的。
5-16 在停止等待协议中如果不使用编号是否可行？为什么？
不行，如果报文段M1的确认报文在网络中延迟了，发送主机重新发送M1后收到延迟的M1确认报文，然后发送M2，收到重传M1的确认报文，就开始发送M3，此时M2有可能在传输过程丢失，而目的主机收到了两个M1。所以不使用编号是不行的。
5-17 在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也没做）是否可行？试举出具体的例子说明理由。
放发送方没有收到确认报文就会重传，接收方就会收到重复报文，停止等待协议对于重复报文要重传确认。让发送方知道自己接收到了报文，让其继续发送下一个。
如果不予理睬，发送发就以为对方没有收到报文，就会继续发送，进而陷入死循环。
5-18 假定在运输层使用停止等待协议。发送发在发送报文段M0后在设定的时间内未收到确认，于是重传M0，但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1，不久就收到了对M1的确认。接着发送方发送新的报文段M0，但这个新的M0在传送过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0，并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。
5-19 试证明：当用 n 比特进行分组的编号时，若接收到窗口等于 1（即只能按序接收分组），当仅在发送窗口不超过2n-1时，连接 ARQ 协议才能正确运行。窗口单位是分组。
- 假定用三比特编号，共有八个序号。假定接收窗口WR，如图阴影部分，发送窗口WT。
- 发送窗口 WT的位置不可能比2的位置更靠前。因为接收窗口的位置表明接收方正在等待接收 7 号分组，而这时的发送方不可能已经收到了对 7 号分组的确认。因此发送窗口必须包括 7 号分组，也就是不可能比2的位置更靠前即右方。
- 发送窗口 WT的位置不可能比 3 的位置更靠后。因为接收窗口的位置表明接收方已经对 6 号分组（以及以前的分组）发送了确认。但如果发送窗口 WT的位置再靠后一个分组，即在 6 号分组的左边，那就表明还没有发送 6 号分组。但接收方的位置表明接收方已经发送了对 6 号分组的确认。这显然是不可能的。
- 发送窗口 WT的位置可能在某个位置的中间，如 1。
- 对于 1 和 2 的情况，在 WT的范围内必须无重复序号（因为如果重复了，比如2的窗口大小为8，发送方把8个报文全部发送出去，这8个里有两个报文序号为7，就有了二义性），即 W T ≤ 2 n W_T\le2^n WT≤2n。
- 对于 3 的情况，在 W T + W R W_T + W_R WT+WR的范围内无重复序号（因为如果重复了，WT就会包含0前面的7，发送这个7接收方并接收到后，发送对序号7的确认，但这两个7只是同一个编号，内容完全不同，这时就会发生回绕），即 W T + W R ≤ 2 n W_T + W_R\le2^n WT+WR≤2n。 WR为1，所以发送窗口不能超过2n-1。
5-20 在连续 ARQ 协议中，若发送窗口等于 7，则发送端在开始时可连续发送 7 个分组。因此，在每一分组发送后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这 7 个分组发出的时间分别为 t0,t1,…t6，且tout都一样大。试问如何实现这 7 个超时计时器（这叫软件时钟法）？
定义一个含有7个数据的数组，数组的值表示时间值。当数据帧发出去的时候，即在数组相应位置中填入时间值，该时间值是由帧发送出去这一时刻的时间加上tout后得到的，然后不停地对该数组的值进行扫描。当收到接收端的确认帧时，即将对应的时间数据设置为空，准备记录下一个数据发送的时间；当系统时间大于数组中的某一序号的帧对应的时间时，说明该帧已经超时，需要重传。
5-21 使用连续 ARQ 协议中，发送窗口大小是 3，而序列范围 [0, 15]，而传输媒体保证在接收方能够按序收到分组。在某时刻，接收方，下一个期望收到序号是 5。试问：
（1）在发送方的发送窗口中可能有出现的序号组合有哪几种？
（2）接收方已经发送出去的、但在网络中（即还未到达发送方）的确认分组可能有哪些？说明这些确认分组是用来确认哪些序号的分组。
（1）接收方期望序号5的分组，说明已经接收到了序号4，已经对发送方发送了确认。
- 如果发送方收到所有确认，则发送窗口序号组合为（5，6，7）。
- 如果所有确认都丢失，则窗口序号组合为（2，3，4）。
所以有可能为（2,3,4）（3,4,5）（4,5,6）（5,6,7）这四种。
（2）对序号为2，3，4的确认分组可能在网络中，用来确认序号为2，3，4的分组的。
5-22 主机 A 向主机 B 发送一个很长的文件，其长度为 L 字节。假定 TCP 使用的 MSS 有 1460 字节。
（1）在 TCP 的序号不重复使用的条件下，L 的最大值是多少？
（2）假定使用上面计算出文件长度，而运输层、网络层和数据链路层所使用的首部开销共 66 字节，链路的数据率为 10 Mb/s，试求这个文件所需的最短发送时间？
（1）TCP有4字节的序号位，共232个序号。每一个字节都有一个序号，所以L最大能有232字节大小，即4GB。
（2）共需要232/1460=2941759个帧。
帧首部共占66x2941759=194156094字节。
帧共占4294967296+194156094=4489123390字节
发送时间：4489123390x8/107=0.997小时
5-23 主机 A 向主机 B 连续发送了两个 TCP 报文段，其序号分别为 70 和 100。试问：
（1）第一个报文段携带了多少个字节的数据？
（2）主机 B 收到第一个报文段后发回的确认中的确认号应当是多少？
（3）如果主机 B 收到第二个报文段后发回的确认中的确认号是 180，试问 A 发送的第二个报文段中的数据有多少字节？
（4）如果 A 发送的第一个报文段丢失了，但第二个报文段到达了 B。B 在第二个报文段到达后向 A 发送确认。试问这个确认号应为多少？
（1）70到99，30个字节的数据。
（2）100
（3）80
（4）对按序到达的最后一个分组确认，显然第一个没收到，收到第二个不会对第二个进行确认，确认的还是第一个之前的，即为70。
5-24 一个 TCP 连接下面使用 256 kb/s 的链路，其端到端时延为 128 ms。经测试，发现吞吐量只有 120 kb/s。试问发送窗口 W 是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）。
（a）收到全部数据后发确认。吞吐量 = W W 256 k b i t / s + 256 m s = 120 k b i t / s 吞吐量=\frac{W}{\frac{W}{256kbit/s}+256ms}=120kbit/s 吞吐量=256kbit/sW+256msW=120kbit/s 解得： W ≈ 7228 B 解得：W\approx7228B 解得：W≈7228B（b）收到一点数据就发送确认，开始发送一个窗口到接收到确认需要256ms
吞吐量 = W 256 = 120 k b i t / s 吞吐量=\frac{W}{256}=120kbit/s 吞吐量=256W=120kbit/s 解得： W = 3840 B 解得：W=3840B 解得：W=3840B
5-25 为什么在 TCP 首部中要把 TCP 端口号放入最开始的 4 个字节？
在ICMP差错报告报文要包括IP首部后8个字节，将TCP端口号放入最开始的4个字节便于用这两个端口确认哪个连接出错了。
5-26 为什么在 TCP 首部中有一个首部长度字段，而 UDP 的首部中就没有这个这个字段？
UDP首部长度字段确定，TCP含有选项需要首部长度字段。
5-27 一个 TCP 报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过 TCP 报文字段中的序号字段可能编出的最大序号，问还能否用 TCP 来传送？
TCP首部与IP首部最短时，数据部分最多。因为IP数据报最长65535字节，去掉20字节的TCP首部与20字节的IP首部，得TCP报文段数据部分最长为65495。
可以，可以重复使用TCP的序号。
5-28 主机 A 向主机 B 发送 TCP 报文段，首部中的源端口是 m 而目的端口是n。当 B 向 A 发送回信时，其 TCP 报文段的首部中源端口和目的端口分别是什么？
源端口为A向B发送报文段的目的端口，目的端口为源端口为A向B发送报文段的源端口。
5-29 在使用 TCP 传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
还没来得及重传就收到了更高序号的确认。
5-30 设 TCP 使用的最大窗口为 65535 字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时延为 20 ms，问所能得到的最大吞吐量是多少?
由于带宽不受限制，发送时延为0。
吞吐量 = 65535 B / 20 m s = 26214 k b i t / s 吞吐量=65535B/20ms=26214kbit/s 吞吐量=65535B/20ms=26214kbit/s
5-31 通信信道带宽为 1 Gbit/s，端到端时延为 10 ms。TCP 的发送窗口为 65535 字节。试问:可能达到的最大吞吐量是多少?信道的利用率是多少?
发送时延：
65535 B / 1 G b i t / s = 0.524 m s 65535B/1Gbit/s=0.524ms 65535B/1Gbit/s=0.524ms最大吞吐量：
65535 B / ( 20 m s + 0.524 m s ) = 25.55 M b i t / s 65535B/(20ms+0.524ms)=25.55Mbit/s 65535B/(20ms+0.524ms)=25.55Mbit/s信道利用率：
25.55 M b i t / s / 1 G b i t / s = 2.55 25.55Mbit/s/1Gbit/s=2.55% 25.55Mbit/s/1Gbit/s=2.55
5-32 什么是 Karn 算法?在 TCP 的重传机制中，若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时延样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度?
Karn算法：在计算加权平均
R T T s RTT_s RTTs时，只要报文段重传了，就不采用其往返时间样本。能够区分开有效的和无效的往返时间样本，改进了往返时间的估算。如果重传后立即收到原始报文段的确认报文，那么重传时间将会降低到很小，具体根据网络情况而定。
5-33 假定 TCP 在开始建立连接时，发送方设定超时重传时间是RTO = 6秒。
（1）当发送方接到对方的连接确认报文段时，测量出 RTT 样本值为1.5秒。试计算现在的RTO值。
（2）当发送方发送数据报文段并接收到确认时，测量出RTT样本值为2.5秒。试计算现在的RTO值。
（1）
R T T S = R T T = 1.5 s RTT_S=RTT=1.5s RTTS=RTT=1.5sR T T D = R T T / 2 = 0.75 s RTT_D=RTT/2=0.75s RTTD=RTT/2=0.75sR T O = R T T S + 4 R T T D = 4.5 s RTO=RTT_S+4RTT_D=4.5s RTO=RTTS+4RTTD=4.5s（2）
R T T S = ( 1 − α ) R T T S + α R T T = 0.875 × 1.5 + 0.125 × 2.5 = 1.625 s RTT_S=(1-\alpha)RTT_S+\alpha RTT=0.875\times1.5+0.125\times 2.5=1.625s RTTS=(1−α)RTTS+αRTT=0.875×1.5+0.125×2.5=1.625sR T T D = ( 1 − β ) R T T D + β × ∣ R T T S − R T T ∣ = 0.75 × 0.75 + 0.25 × 0.875 ≈ 0.78 s RTT_D=(1-\beta)RTT_D+\beta\times|RTT_S-RTT|=0.75\times0.75+0.25\times0.875\approx0.78s RTTD=(1−β)RTTD+β×∣RTTS−RTT∣=0.75×0.75+0.25×0.875≈0.78sR T O D = R T T S + R T T D = 4.75 s RTO_D=RTT_S+RTT_D=4.75s RTOD=RTTS+RTTD=4.75s
5-34 已知第一次测得 TCP 的往返时延的当前值 RTT 是 30 ms。现在收到了三个接连的确认报文段，它们比相应的数据报文段的发送时间分别滞后的时间是：26 ms，32 ms 和24 ms。设 α = 0.1。试计算每一次的新的加权平均往返时间值RTTS。讨论所得出的结果。
第一次：
R T T S = 30 m s RTT_S=30ms RTTS=30ms第二次：
R T T S = 27 m s + 2.6 m s = 29.6 m s RTT_S=27ms+2.6ms=29.6ms RTTS=27ms+2.6ms=29.6ms第三次：
R T T S = 29.84 m s RTT_S=29.84ms RTTS=29.84ms第四次：
R T T S = 29.256 m s RTT_S=29.256ms RTTS=29.256ms新RTT样本值对RTTs有影响但很小。
5-35 用TCP通过速率为1Gbit/s的链路传送一个10MB的文件。假定链路的往返时延RTT=50ms。TCP选用了窗口扩大选项，使窗口达到可选用的最大值。在接收端，TCP的接收窗口为1MB，而发送端采用拥塞控制算法，从慢开始传送。假定拥塞窗口以分组为单位计算，在一开始发送1个分组，而每个分组长度都是1KB.假定网络不会发生拥塞和分组丢失，并且发送端发送数据的速率足够快，因此发送时延可以忽略不计，而接收端每一次收完一批分组后就立即发送确认ACK分组。
(1)经过多少个RTT后，发送窗口大小达到1MB？
(2)发送端把整个10MB文件传送成功共需要多少个RTT？传送成功是指发送完整个文件，并收到所有的确认。TCP扩大的窗口够用么？
(3)根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？
（1）发送窗口每经过一个RTT增大一倍，窗口大小1MB=210KB，经过十个RTT后窗口大小就能达到1MB。
（2）由等比数列求和公式得第n个RTT结束后发送的分组数为：2 n − 1 2^{n}-1 2n−1。10个RTT结束后发送1MB-1KB的数据，还剩9MB+1KB的数据，由于发送端窗口受接收窗口限制，所以10个RTT结束后就一直为1MB，剩下9MB+1KB的数据需要10个RTT。所以共需要20个RTT。
窗口最大为210<230-1（扩大后窗口最大值），够用。
（3）花费时间：14x50ms=0.7s
吞吐率：10 M B / 0.7 s = 119.8 M b i t / s 10MB/0.7s=119.8Mbit/s 10MB/0.7s=119.8Mbit/s利用率：
119.8 M b i t / s / 1 G b i t / s = 11.98 % 119.8Mbit/s/1Gbit/s=11.98\% 119.8Mbit/s/1Gbit/s=11.98%
5-36 假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。在一开始发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一分组后，就立即发回确认ACK。假定分组的编号为i，在一开始发送的是i=1的分组。以后当i=9，25，30，38，50时，发生了分组的丢失。再假定分组的超时重传时间正好是下一个RTT开始的时间。试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。
抓住线性增加与指数减小就很容易画出来。
5-37 在 TCP 的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法?这里每一种算法各起什么作用? “乘法减小”和“加法增大”各用在什么情况下?
慢开始：主机发送数据时，拥塞窗口设置为一个最大报文段MSS的数值。每收到一个报文段的确认，就把拥塞窗口增加一个MSS，所以每经过一个RTT，拥塞窗口cwnd就加倍。
拥塞避免：防止拥塞窗口增长过大，我们需要设置一个慢开始门限ssthresh，当cwnd>ssthread时，使用拥塞避免算法，其定义为，每经过一个RTT，发送方的拥塞控制窗口cwnd大小加一。
快重传：收到失序报文段要立即发出对已收到报文段的重复确认，发送方收到3个重复确认，就知道网络未拥塞，只是分组丢失，所以立即重传已收到报文段的后面一个报文。
快速恢复：发送方知道是丢失报文段，网络未拥塞，所以就将门限值调整为cwnd/2，将拥塞窗口也减半。
乘法减小：慢开始与拥塞避免阶段只要超时就将门限值设为拥塞窗口的一半。
加法增大：拥塞避免阶段，拥塞窗口线性增大。
5-38 设 TCP 的 ssthresh 的初始值为 8 (单位为报文段)。当拥塞窗口上升到 12 时网络发生了超时，TCP 使用慢开始和拥塞避免。试分别求出第 1 次到第 15 次传输的各拥塞窗口大小。你能说明拥塞控制窗口每一次变化的原因吗？
RTT拥塞窗口原因11网络超时，慢开始22拥塞窗口加倍34同上48同上59拥塞避免，窗口加一610同上711同上812同上91慢开始102窗口加倍114同上126同上，但最多到门限值一半137拥塞避免148拥塞避免159拥塞避免
5-39 TCP 的拥塞窗口 cwnd 大小与传输轮次 n 的关系如表所示：
（1）试画出如教材中图 5-25 所示的拥塞窗口与传输轮次的关系曲线。
（2）指明 TCP 工作在慢开始阶段的时间间隔。
（3）指明 TCP 工作在拥塞避免阶段的时间间隔。
（4）在RTT=16和RTT= 22 之后发送方是通过收到三个重复的确认还是通过超时检测到丢失了报文段？
（5）在RTT=1，RTT=18和RTT=24发送时，门限 ssthresh 分别被设置为多大？
（6）在RTT等于多少时发送出第 70 个报文段？
（7）假定在RTT=26之后收到了三个重复的确认，因而检测出了报文段的丢失，那么拥塞窗口 cwnd 和门限 ssthresh 应设置为多大？
（2）1-6,23-26
（3）6-16， 17-22
（4）RTT=16执行快重传，所以收到了3次重复确认，RTT=22时执行慢开始，所以是超时。
（5）RTT=1，因为cwnd到32后执行拥塞避免算法，所以ssthresh 为32。RTT=18，时执行快重传算法，ssthresh 设为cwnd的一半，即为21。RTT=26，执行慢开始算法，ssthresh 设为cwnd的一半，即为13。
（6）
RTT已发送的报文段1123374155316637127
所以RTT=7时发送出第70个报文段。
（7）cwnd设为4，ssthread设为4。
5-40 TCP 在进行流量控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出三种情况。
一、IP数据报需要分片，分片丢失引起分组丢失。
二、终点缓存不够，分组被丢弃。
三、路由器缓存不够，分组丢弃。
5-41 用 TCP 传送 512 字节的数据。设窗口为 100 字节，而 TCP 报文段每次也是传送 100 字节的数据。再设发送端和接收端的起始序号分别选为 100 和 200，试画出类似于教材中图 5-28 的工作示意图。从连接建立阶段到连接释放都要画上。
5-42 在图 5-29 中所示的连接释放过程中，主机 B 能否先不发送 ACK = u + 1 的确认?（因为后面要发送的连接释放报文段中仍有 ACK = u + 1 这一信息）
如果 B 不再发送数据了，是可以把两个报文段合并成为一个，即只发送 FIN+ACK 报文段。但如果 B 还有数据报要发送，而且要发送一段时间，那就不行，因为 A 迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个 FIN 报文段，浪费网络资源。
5-43 在图 5-30 中，在什么情况下会发生从状态 SYN-SENT 到状态 SYN-RCVD 的变迁？
当 A 和 B 都作为客户，即同时主动打开 TCP 连接。
5-44 试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
假设A是客户，B是服务器，AB通信完A发送FIN报文段，B连续发送ACK与FIN报文段，A发送ACK报文段，双方连接释放。
A发送完FIN报文段，B发送ACk报文段，TCP处于半关闭状态，B还能发送数据，数据发送完发送FIN报文段，A发送ACK报文，连接完全释放。
5-45 解释为什么突然释放运输连接就可能会丢失用户数据，而使用 TCP 的连接释放方法就可保证不丢失数据。
主机A与主机B建立了TCP连接。
假设A向B发送数据，且发送完了，A将TCP连接释放，如果某些报文段丢失，那就没法继续传送。
假设A向B发送数据，发送完且收到了B的确认，A将连接释放，但此时B发送的数据可能会丢失。
5-46 试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能会出现什么情况。
3 次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
假定 B 给 A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功地建立了，可以开始发送数据分组。可是，B 在 A 的应答分组在传输中被丢失的情况下，将不知道 A 是否已准备好，不知道 A 建议什么样的序列号，B 甚至怀疑 A 是否收到自己的连接请求分组，在这种情况下，B 认为连接还未建立成功，将忽略 A 发来的任何数据分组，只等待连接确认应答分组。而 A 发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
5-47 一个客户向服务器请求建立 TCP 连接。客户在 TCP 连接建立的三次握手中的最后一个报文段中捎带上一些数据，请求服务器发送一个长度为 L 字节的文件。假定：
（1）客户和服务器之间的数据传输速率是 R 字节/秒，客户与服务器之间的往返时间是 RTT（固定值）。
（2）服务器发送的 TCP 报文段的长度都是 M 字节，而发送窗口大小是 nM 字节。
（3）所有传送的报文段都不会出错（无重传），客户收到服务器发来的报文段后就及时发送确认。
（4）所有的协议首部开销都可忽略，所有确认报文段和连接建立阶段的报文段的长度都可忽略（即忽略这些报文段的发送时间）。
试证明，从客户开始发起连接建立到接收服务器发送的整个文件多需的时间 T 是：T = 2RTT + L/R，当 nM > R(RTT) + M
或 T= 2RTT + L/R + (K - 1)[ M/R + RTT - nM/R]，当 nM < R(RTT) + M
其中，K=『L/nM』，符号『x』表示若 x 不是整数，则把 x 的整数部分加 1。
（提示：求证的第一个等式发生在发送窗口较大的情况，可以连续把文件发送完。求证的第二个等式发生在发送窗口较小的情况，发送几个报文段后就必须停顿下来，等收到确认后再继续发送。建议先画出双方交互的时间图，然后再进行推导。）
第一种情况：n M > R ∗ R T T + M nM>R*RTT + M nM>R∗RTT+M时，服务器发送完窗口数据之前就接收到了确认，窗口向前滑动，能够一直不间断发送。所以T = 2RTT + L/R，当 nM > R(RTT) + M第二种情况：
n M < R ∗ R T T + M nM<R*RTT+M nM<R∗RTT+M时，服务器发送完窗口内容还未收到确认，只能等待 M / R + R T T + n M / R M/R+RTT+nM/R M/R+RTT+nM/R时间后才能再次发送，一次发送nM字节，所以需要发送 K = ⌈ L / ( n M ) ⌉ K=\lceil L/(nM) \rceil K=⌈L/(nM)⌉次。需要K-1个间隔，所以得证。
5-48 网络允许的最大报文段长度为 128 字节，序号用 8 比特表示，报文段在网络中的寿命为 30 s。求发送报文段的一方所能达到的最高数据率。
8比特有255个序号。能一次发送
128 × 255 × 8 = 261120 b i t 128\times255\times8=261120bit 128×255×8=261120bit。最大寿命为30s，最高数据率=261120bit/30s=8704bit/s
5-49 下面是以十六进制格式存储的一个 UDP 首部：
CB84000D001C001C
试问:
(1) 源端口号是什么？
(2) 目的端口号是什么？
(3) 这个用户数据报的总长度是什么？
(4) 数据长度是多少？
(5)这个分组是从客户到服务器还是从服务器到客户？
(6) 客户进程是什么？
（1）
12 × 1 6 3 + 11 × 1 6 2 + 8 × 16 + 4 = 52100 12\times16^3+11\times16^2+8\times16+4=52100 12×163+11×162+8×16+4=52100（2）
13 13 13（3）
16 + 12 = 28 b y t e 16+12=28byte 16+12=28byte（4）
20 b y t e 20byte 20byte（5）客户到服务器，因为目的端口号是熟知端口。
（6）从 RFC 867 可以得知，这个客户进程是 Daytime。当 Daytime 服务器收到客户发送的 UDP 用户数据报后，就把现在的日期和时间以 ASCII 码字符串的形式返回给客户。
5-50 把教材上的图 5-7 计算 UDP 检验和的例子自己具体演算一下，看是否能够得出书上的计算结果。
可以使用两种方法进行二进制反码求和的运算。一种方法是把这 14 行的 16 位数据一起从低位到高位逐位相加。另一种方法是把这 14 行的 16 位数据两行两行地相加（即二进制反码求和）
我们这里使用后一种方法，这里要相加 13 次。
第 1 行和 第 2 行相加，得 10100001 01111011
再和第 3 行相加，得 1 01001100 011111110。请注意，最左边（最高位）的 1 是进位得到的 1，这要和最低位相加。因此和第 3 行相加后，得 01001100 01111111。最低位的 1 就是由最高位的进位得到的。这叫做 “回卷”。
再和第 4 行相加，得 01011010 10001010。
再和第 5 行相加，得 01011010 10011011。
再和第 6 行相加，得 01011010 10101010。
再和第 7 行相加，得 01011110 11101001。
再和第 8 行相加，得 01011110 11110110。
再和第 9 行相加，得 01011111 00000101。
第 10 行是全 0，不用再计算相加。
再和第 11 行相加，得 10110011 01001010。
再和第 12 行相加，得 00000110 10011111。这里的最低位的 1 由最高位的进位回卷得到的。
再和第 13 行相加，得 01001111 11101101。
再和第 14 行相加，得 10010110 11101101。这就是二进制反码求和的结果。把这个结果求反码（1 换成 0 而 0 换成 1），得出：01101001 00010010。这就是应当写在检验和字段的数。和书上给出的结果是一致的。
UDP 用户数据报传送到接收端后，再进行检验和计算。这就是把收到的 UDP 用户数据报连同伪首部（以及可能的填充全零字节）一起，按二进制反码求这些 16 位字的和。当无差错时其结果应当全 1。否则就表明有差错出现，接收方就应丢弃这个 UDP 用户数据报（也可以上交应用层，但附上出现差错的警告）。
5-51 在以下几种情况下，UDP 的检验和在发送时数值分别是多少？
（1）发送方决定不使用检验和。
（2）发送方使用检验和，检验和的数值是全 1。
（3）发送方使用检验和，检验和的数值是全 0。
（1）UDP 规定，UDP 的上层用户可以关闭检验和的计算（即在 UDP 的传送过程中，不使用检验和这个检错功能）。这样做的好处是可以提高 UDP 的传送速度（但要牺牲一些可靠性）。如果发送方决定不使用检验和，那么发送方的检验和的值应当置为全 0。这表示这个数值不是计算出来的，而是发送方关闭了检验和这个功能。
（2）如果发送方使用检验和，但检验和的数值是全 1。
我们可以想一想，怎么会出现这种情况。如果计算检验和最后的结果是全 1，就表明得出这个结果的前一个步骤（即二进制反码求和）的结果是全 0。在什么情况下，伪首部和整个 UDP 按 16 位字进行二进制反码求和的结果是全 0 ？这就是伪首部和整个 UDP 的所有字段都是 0。但很明显，这是不可能的。所有的地址和数据都是 0，还有什么意义？不要以为两个 1 相加就是 0。不对。两个 1 相加按二进制反码求和的结果是 1 0。这里的 1 是进位。因为此按照计算检验和的规矩来计算，对真实的 UDP 用户数据报不可能得出检验和的数值是全 1。
但是，计算检验和时的倒数第二步，即按二进制反码求和的结果却有可能是全 1。在这种情况下，最后一步求反码，就会得出检验和是全 0。但是前面我们已经讲过，检验和置为全 0是表示发送方不使用检验和。这样就产生了疑问：如果检验和是全 0，是发送方不使用检验和？还是使用了检验和但检验和的结果碰巧全是 0？无法确定。于是 UDP 协议就规定：如果计算检验和的结果刚好是全 0，那么就把它人为的置为全 1。因为前面已经讲过，全 1 的检验和是不可能由计算出来的。因此接收方一旦收到检验和为全 1 的 UDP 用户数据报，就知道这是人为的，真正地检验和其实是全 0。
（3）发送方使用检验和，检验和的数值是全 0。
前面已经讲过，这是不可能的。如果发送方计算出来的检验和是全 0，那也要把它变成全 1 再发送出去。
5-52 UDP 和 IP 的不可靠程度是否相同? 请加以解释。
UDP 和 IP 都是无连接的协议和不可靠传输的协议。UDP 用户数据报和 IP 数据报的首部都有检验和字段。当检验出现差错时，就把收到的 UDP 用户数据报或 IP 数据报丢弃。这是它们的相同之处。
但 UDP 和 IP 的可靠性是有些区别的。UDP 用户数据报的检验和是既检验 UDP 用户数据报的首部又检验整个的 UDP 用户数据报的数据部分，而 IP 数据报的检验和仅仅检验 IP 数据报的首部。UDP 用户数据报的检验和还增加了伪首部，即还检验了下面的 IP 数据报的源 IP 地址和目的 IP 地址。
5-53 UDP 用户数据报的最小长度是多少？用最小长度的 UDP 用户数据报构成的最短 IP 数据报的长度是多少？
UDP 用户数据报的最小长度是 8 字节，即仅有首部而没有数据。用最小长度的 UDP 源用户数据报构成的最短 IP 数据报的长度为 28 字节。此 IP 数据报具有 20 字节的固定首部，首部中没有可选字段。
5-54.某客户使用 UDP 将数据发送给一个服务器，数据共 16 字节。试计算在运输层的传输效率（有用字节与总字节之比）。
UDP的数据报总长度=16+8=24字节
传输效率=(16/24)×100%=66.7%
5-55.重做 54，但在 IP 层计算传输效率。假定 IP 首部无选项。
IP数据报总长度=24+20=44字节
传输效率=(16/44)×100%=36.4%
5-56 重做 54，但在数据链路层计算传输效率。假定 IP 首部无选项，在数据链路层使用以太网。
以太网有 14 字节的首部，4 字节的尾部（FCS 字段），发送以太网的帧之前还有 8 字节的前同步码。但其数据字段的最小长度是 46 字节，而我们的 IP 数据报仅有 44 字节，因此还必须加上 2 字节的填充。这样，以太网的总长度 = 14 + 4 + 8 + 2 + 44 = 72 字节。
传输效率=(16/72)×100%=22.2%
5-57 某客户有 67000 字节的分组。试说明怎样使用 UDP 用户数据将这个分组进行传送。
一个 UDP 用户数据报的最大长度为 65535 字节。现在的长度超过了这个限度，因此不能使用一个 UDP 用户数据报来传送。必须进行切割（例如，分割为两个 UDP 用户数据报），使其长度不超过以上的限度。
5-58 TCP 在 4:30:20 发送了一个报文段。它没有收到确认。在 4:30:25 它重传了前面这个报文段。它在 4:30:27 收到确认。若以前的 RTT 值为 4 秒，根据 Karn 算法，新的 RTT 值为多少？
4s（重传不管）
5-59 TCP 连接使用 1000 字节的窗口值，而上一次的确认号是 22001。它收到了一个报文段，确认号是 22401.。试用图来说明在这之前与之后的窗口情况。
5-60 同上题，但在发送方收到的确认号为 22401 的报文段时，其窗口字段变为 1200 字节。试用图来说明在这之前与之后的窗口情况。
5-61 在本题中列出的 8 种情况下，画出发送窗口的变化。并标明可用窗口的位置。已知主机 A 要向主机 B 发送 3 KB 的数据。在 TCP 连接建立后，A 的发送窗口大小是 2 KB。A 的初始序号是 0。
(1) 一开始 A 发送 1 KB的数据。
(2) 接着 A 就一直发送数据，直到把发送窗口用完。
(3) 发送方 A 收到对第 1000 号字节的确认报文段。
(4) 发送方 A 再发送 850 B的数据。
(5) 发送方 A 收到 ack = 900 的确认报文段。
(6) 发送方 A收到对第 2047 号字节的确认报文段。
(7) 发送方 A把剩下的数据全部都发送完。
(8) 发送方 A 收到 ack = 3072 的确认报文段。
（1）我们应当注意到，发送窗口 = 2 KB 就是 2 ×1024 = 2048 字节。因此，发送窗口应当是从 0 到第 2047 字节为止，长度是 2048 字节。A 开始就发送了 1024 字节，因此发送窗口中左边的 1024 个字节已经用掉了（窗口的这部分为灰色），而可用窗口是白色的，从第 1024 字节到第 2047 字节位置。请注意，不是到第 2048 字节位置，因此第一个编号是 0 而不是 1。
（2）发送方 A 一直发送数据，直到把发送窗口用完。这时，整个窗口都已用掉了，可用窗口的大小已经是零了，一个字节也不能发送了。
（3）发送方 A 收到对第 1000 字节的确认报文段，表明 A 收到确认号 ack = 1001 的确认报文段。这时，发送窗口的后沿向前移动，发送窗口从第 1001 字节（不是从第 1000 字节）到第 3048 字节（不是第 3047 字节）为止。可用窗口从第 2048 字节到第 3048 字节。【注意，因为从 1001 起，3048 - 1001 + 1 = 2048】
（4）发送方 A 再发送 850 字节，使得可用窗口的后沿向前移动 850 字节，即移动到 2898 字节。现在的可用窗口从第 2898 字节到 3048 字节。
（5）发送方 A 收到 ack = 900 的确认报文段，不会对其窗口状态有任何影响。这是个迟到的确认。
（6）发送方 A 收到对第 2047 号字节的确认报文段。A 的发送窗口再向前移动。现在的发送窗口从第 2048 字节开始到第 4095 字节。可用窗口增大了，从第 2898 字节第 4095 字节。
（7）发送方 A 把剩下的数据全部发送完。发送方 A 共有 3 KB（即 3072 字节）的数据，其编号从 0 到 3071。因此现在的可用窗口变小了，从第 3072 字节到第 4095 字节。
（8）发送方 A 收到 ack = 3072 的确认报文段，表明序号在 3071 和这以前的报文段都收到了，后面期望收到的报文段的序号熊 3072 开始。因此新的发送窗口的位置又向前移动，从第 3072 号字节到第 5119 号字节。整个发送窗口也就是可用窗口。
5-62 TCP 连接处于 ESTABLISHED 状态。以下的事件相继发生：
（1）收到一个 FIN 报文段。
（2）应用程序发送 “关闭” 报文。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）处于 ESTABLISHED 状态又能够收到一个 FIN 报文段，只有 TCP 的服务器端而不会是客户端。当这个服务器端收到 FIN 时，服务器就向客户端发送 ACK 报文段，并进入到 CLOSE-WAIT 状态。这是被动关闭。请注意，这时客户端不会再发送数据了，但服务器端如还有数据要发送给客户端，那么还是可以继续发送的。
（2）应用程序发送 “关闭” 报文给服务器，表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到 LAST-ACK 状态，并等待来自客户端的最后的确认。
5-63 TCP 连接处于 SYN-RCVD 状态。以下的事件相继发生：
（1）应用程序发送 “关闭” 报文。
（2）收到 FIN 报文段。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）根据教材图5-30，处于 SYN-RCVD 状态而又能够收到应用程序发送的 “关闭” 报文的，只有 TCP 的客户端而不会是服务器端。这时，客户端就应当向服务器端发送 FIN 报文段，然后进入到 FIN-WAIT-1 状态。
（2）客户机收到FIN后发送ACK，进入CLOSING状态。
5-64 TCP 连接处于 FIN-WAIT-1 状态。以下的事件相继发生：
（1）收到 ACK 报文段。
（2）收到 FIN 报文段。
（3）发生了超时。
在每一个事件之后，连接的状态是什么？在每一个事件之后发生的动作是什么？
（1）客户机收到ACK后进入FIN-WAIT-2状态，之后没有别的动作了。
（2）收到FIN发送ACK，进入TIME-WAIT状态。
（3）进入CLOSED状态。
5-65 假定主机 A 向 B 发送一个 TCP 报文段。在这个报文段中，序号是 50，而数据一共有 6 字节长。试问，在这个报文段中的确认字段是否应当写入 56？
这个报文段的确认字段是期待对方下次发送报文段的第一个字节的序号，与它本身的序号与数据无关。
5-66 主机 A 通过 TCP 连接向 B 发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个 TCP 报文段的序号是 x，那么下一个报文段的序号是否就是 x + 1 呢？
不是应该是x+n，n是本报文段数据长度的字节数。
5-67 TCP 的吞吐量应当是每秒发送的数据字节数，还是每秒发送的首部和数据之和的字节数？吞吐量应当是每秒发送的字节数，还是每秒发送的比特数？
TCP 的吞吐量本来并没有标准的定义，可以计入首部，也可以不计入首部，但应当说清楚。不过，从拥塞控制来看，拥塞窗口和发送窗口针对的都是 TCP 报文段中的数据字段，而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度，因此，把 TCP 的吞吐量定义为每秒发送的数据字节数是比较方便的。
计算机内部的数据传送是以每秒多少字节作为单位的，而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。在上面的习题中，因为 MSS 用字节作为单位，因此，用每秒发送多少字节作为 TCP 吞吐量的单位就比较简单一些。
5-68 在 TCP 的连接建立的三报文握手过程中，为什么第三个报文段不需要对方的确认？这会不会出现问题？
① 关于这个问题，还不能简单地用 “是” 或 “否” 来回答。
② 我们假定 A 是客户端，是发起 TCP 连接建立一方。现在假定三报文握手过程中的第三个报文段（也就是 A 发送的第二个报文段 —— 确认报文）丢失了，而 A 并不知道。这是，A 以为对方收到了这个报文段，以为 TCP 连接已经建立，于是就开始发送数据报文段给 B。
③ B 由于没有收到三报文握手中的最后一个报文段（A 发送的确认报文段），因此 B 就不能进入 TCP 的 ESTABLISHED 状态（“连接已建立” 状态）。B 的这种状态可以叫做 “半开连接” ，即仅仅把 TCP 连接打开了一半。在这种状态下，B 虽然已经初始化了连接变量和缓存，但是不能接收数据。通常，B 在经过一段时间后（例如，一分钟后） ，如果还没有收到来自 A 的确认报文段，就终止这个半开连接状态，那么 A 就必须重新建立 TCP 连接。因此，在这种情况下，第三个报文段（A 发送的第二个报文段）的丢失，就导致了 TCP 连接无法建立。
④ 但是，假定 A 在这段时间内，紧接着就发送了数据。我们知道，TCP 具有累计确认的功能。在 A 发送的数据报文段中，自己的序号也没有改变，仍然是和丢失的确认真的序号一样（丢失的那个确认帧不消耗序号），并且确认位 ACK = 1，确认号也是 B 的初始序号加 1。当 B 收到这个报文段后，从 TCP 的首部就可以知道，A 已确认了 B 刚才发送的 SYN + ACK 报文段，于是就进入了 ESTABLISHED 状态（“连接已建立” 状态）。接着，就接收 A 发送的数据。在这种情况下，A 丢失的第二个报文段对 TCP 的连接建立就没有影响。
⑤ 大家知道，A 在发送第二个报文段时，可以有两种选择：
（1）仅仅是确认而不携带数据，数据接着在后面发送。
（2）不仅是确认，而且携带上自己的数据。
⑥ 在第一种选择时，A 在下一个报文段发送自己的数据。但下一个报文的首部中仍然包括了对 B 的 SYN + ACK 报文段的确认，即和第二种选择发送的报文段一样。
⑦ 在第二种选择时，A 省略了单独发送一个确认报文段。
从这里也可以看出，A 发送的第二个仅仅是确认的报文段，是个可以省略的报文段，即使丢失了也无妨，只要下面紧接着就可以发送数据报文段即可。
5-69 现在假定使用类似 TCP 的协议（即使用滑动窗口可靠传送字节流），数据传输速率是 1 Gbit/s，而网络的往返时间 RTT = 140 ms。假定报文段的最大生存时间是 60 秒。如果要尽可能快的传送数据，在我们的通信协议的首部中，发送窗口和序号字段至少各应当设为多大？
这题不会，会的话能私信教教我吗，呜呜呜。
5-70 假定用 TCP 协议在 40 Gbit/s 的线路上传送数据。
（1）如果 TCP 充分利用了线路的带宽，那么需要多长的时间 TCP 会发生序号绕回？
（2）假定现在 TCP 的首部中采用了时间戳选项。时间戳占用了 4 字节，共 32 位。每隔一定的时间（这段时间叫做一个滴答）时间戳的数值加 1。假定设计的时间戳是每隔 859 微秒，时间戳的数值加 1。试问要经过多长时间才发生时间戳数值的绕回。
（1）
2 32 b y t e ( 40 / 8 ) b y t e / s = 859 m s \frac{2^{32}byte}{(40/8)byte/s}=859ms (40/8)byte/s232byte=859ms（2）
859 × 1 0 − 6 × 2 32 = 42.7 天 859\times10^{-6}\times2^{32}=42.7天 859×10−6×232=42.7天
5-71 5.5 节中指出：例如，若用 2.5 Gbit/s 速率发送报文段，则不到 14 秒钟序号就会重复。请计算验证这句话。
2 32 b y t e ( 2.5 / 8 ) b y t e / s = 13.74 s \frac{2^{32}byte}{(2.5/8)byte/s}=13.74s (2.5/8)byte/s232byte=13.74s
5-72 已知 TCP 的接收窗口大小是 600（单位是字节，为简单起见以后就省略了单位），已经确认了的序号是 300。试问，在不断的接收报文段和发送确认报文段的过程中，接收窗口也可能会发生变化（增大或缩小）。请用具体的例子（指出接收方发送的确认报文段中的重要信息）来说明哪些情况是可能发生的，而哪些情况是不允许发的。
（1）这是题目开始的情况。接收方发送的确认报文段中的接收窗口 rwnd = 600。已确认的序号是 300。接收方发送的确认报文段的 ack = 301，表示期望收到开始的序号为 301 的数据。我们看到，序号 301 到 900 都在接收窗口内。
（2）接收窗口增大总是不受限制的。这就是说，只要接收端的 TCP 能够拿出更多的空间来接收发来的数据，就可以这样做。图中给出的例子是：已确认的序号是 400，接收方发送的确认报文段为 ack = 401。假定现在接收窗口从情况（1）的 600 增大到了 700，即 rwnd = 700。现在接收窗口的范围是从 401 到 1100。当接收窗口增大时，接收窗口的前沿总是向前移动的。
（3）这种情况是接收窗口变小了，但接收窗口的前沿没有变化。例如，现在的已确认的序号是 400，接收方发送的确认报文段的 ack = 401。假定现在接收窗口从情况（1）的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。
（4）这种情况是接收窗口变小了，同时接收窗口的前言页向前移动了。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况 (1) 的 600 减少到了 500，即 rwnd = 500。接收窗口的范围是从 501 到 1000。
（5）这种情况是接收窗口变小了，但接收窗口的前沿是后退的。例如，现在已确认的序号是 500，接收方发送的确认报文段的 ack = 501。假定现在接收窗口从情况（1）的 600 减小到了 300，即 rwnd = 300。接收窗口的范围是从 501 到800。但请注意，这种情况是不允许出现的。也就是说，接收窗口的前沿是不允许后退的。在开始时，接收窗口的前沿的编号是 900。不管是接收窗口是变大还是变小，这个窗口的前沿的编号可以不动，也可以前移，但是不允许后退。
为什么不允许出现这种情况呢？可以先观察一下发送方的情况。在一开始，发送方收到接收窗口 = 600 的报文段后（其中 ack = 301），发送方就把发送窗口设置为 600，可以发送的数据的序号从 301 到 900。假定发送方发送了在发送窗口内的全部数据。这本来正好落入到接收窗口之内。但这些数据正在网络中传输时，接收方却缩小了接收窗口，只接收序号从 501 到 800 之间的数据。这就导致最后的一些数据（编号从 801 到 900）落入接收窗口之外，使得接收方只能丢弃这些数据（编号从 801 到 900）。因此，这种情况（在发送时数据是在发送窗口之内，但到达接收端，这些数据却落入到接收窗口之外）必须避免。总之，我们要记住，接收窗口是不允许后退的。
5-73 在上题中，如果接收方突然因某种原因不能够再接收数据了，可以立即向发送方发送把接收窗口置为零的报文段（即 rwnd = 0）。这时会导致接收窗口的前沿后退。试问这种情况是否允许？
这种情况是允许的。当发送方收到这样的信息，并不是把发送窗口缩回到零，而是立即停止发送。什么时候可以再发送数据，就要等接收方重新开放接收窗口，即给出一个非零的接收窗口。
5-74 流量控制和拥塞控制的最主要的区别是什么？发送窗口的大小取决于流量控制还是拥塞控制？
简单地说，流量控制是在一条 TCP 连接中的接收端才用的措施，用来限制对方（发送端）发送报文的速率，以免在接收端来不及接收。流量控制只控制一个发送端。
拥塞控制是用来控制 TCP 连接中发送端发送报文段的速率，以免使互联网中的某处产生过载。拥塞控制可能会同时控制许多个发送端，限制它们的发送速率。不过每一个发送端只知道自己应当怎样调整发送速率，而不知道在互联网中还有哪些主机被限制了发送速率。
我们知道，发送窗口的上限值是 Min [rwnd, cwnd]，即发送窗口的数值不能超过接收窗口和拥塞窗口中娇小的一个。接收窗口的大小体现了接收端对发送端施加的流量控制，而拥塞窗口的大小则是整个互联网的负载情况对发送端施加的拥塞控制。因此，当接收窗口小于拥塞窗口时，发送窗口的大小取决于流量控制，即取决于接收端的接收能力。但当拥塞窗口小于接收窗口时，则发送窗口的大小取决于拥塞控制，即取决于整个网络的拥塞状况。
版权归原作者 进击的博仔 所有， 如有侵权，请联系我们删除。