- 1还在用手画太阳花，太out了，python教你如何轻松画一朵！_idle如何画一朵花
- 2“Git：不容错过的现代化版本控制系统” 基础入门篇_初探git,理解和使用版本控制的魔法
- 3c++ STL less 的视角
- 4Java正则表达式汇总_java正则表达式,不能输入引号(单引号和双引号)以及特殊字符<、>、#和&
- 5C语言的printf的介绍_printf("%g%+gi\n", a.rp, a.ip);
- 6【蓝桥杯选拔赛真题50】python充电器 青少年组蓝桥杯python 选拔赛STEMA比赛真题解析_蓝桥杯青少组stema
- 7框架技术 ---- SPA和Vue的组件化开发_vue和spa
- 8git命令（使用git review）
- 9【Django】Django实现对IP地址访问过滤_django 限制 国内 ip 访问
- 10图像处理： 马赛克艺术_马赛克是什么纹理
计算机网络（谢希仁-第八版）第五章习题全解_计算机网络第八版谢希仁课后答案第五章
赞
踩
5-01 试说明运输层在协议栈中的地位和作用。运输层的通信和网络层的通信有什么重要的区别？为什么运输层是必不可少的？
地位和作用：
从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能的最低层，当网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时，都要使用协议栈中的运输层。
网络层和运输层通信的重要区别：
从IP层来说，通信的两端是两台主机，IP数据报的首部明确标志了这两台主机的IP地址。但实际上，真正进行通信的实体是在主机中的应用进程——是一台主机中的应用进程和另一台主机中的应用进程在交换数据（即通信）。
因此，IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。
而运输层正是实现主机间进程通信的协议层，实现不同主机之间进程的“逻辑通信”（逻辑通信的意思是：从应用层来看，只要应用层报文交给下面的运输层，运输层就可以将这报文传送到对方的运输层。。好像这种通信就是沿水平方向直接传送数据，但事实上这两个运输层之间并没有一条水平方向的物理连接，数据的传送是经过多个层次传送的）
为什么运输层必不可少：
正如前面所说的，真正通信的实体是主机之间的不同进程，因此，需要运输层将网络分组交付给进程，完成进程间的通信。除此之外，由于网络层的不可靠性，运输层还要对收到的报文进行差错检测，运输层的TCP协议还可以保证可靠传输。
5-02 网络层提供数据报或虚电路服务对上面的运输层有何影响？
网络层提供的数据报或虚电路服务不影响上面的运输层的运行机制，但提供不同的服务质量。
网络层所提供的服务越多，传输层协议就可以做得越简单。
虚电路服务的思路是：可靠通信应当由网络来保证 。它规定属于同一条虚电路的分组按照同一路由进行转发，而且转发的方式总是按发送的顺序以此到达终点。这样做虽然使中间的网络节点造价比通信端点造价高，但这样能基本保证报文无差错、不丢失、不重复且按序地进行交付，因此运输层的协议就可以做得很简单。
数据报服务的思路是：可靠通信由用户主机来保证，它对运输层只提供简单灵活，无连接的，尽最大努力交付的数据报服务，是不可靠的通信。因此，若要保证通信的质量，要求主机有一个复杂的传输协议，这个协议就交给运输层。
5-03 当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接还是无连接的？
这个问题得从不同层次来看：
若是运输层，TCP是面向连接的，为应用程序提供端到端的可靠传输服务。
若是IP层，IP是无连接的，是不可靠的传输，可能丢包、乱序等。
5-04 试画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接又复用到IP数据报上。
在一台主机中经常有多个应用进程分别和另一台主机中的多个应用进程通信。
在上图中，主机A的进程AP1和主机B的进程AP3通信，而此时，AP2也和对方的AP4通信。他们都可以用同一个运输层协议进行数据交换（当然要加上适当的首部），这表明运输层有个很重要的功能——复用。
复用——发送方不同的应用进程都可以使用同一个运输层协议传输数据
分用——接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程
IP层的复用和分用：发送方使用不同协议的数据都可以封装成IP数据报发送出去，而在接收方的IP层根据IP首部的协议字段进行分用，把剥去首部的数据交付应当接受这些数据的协议。
5-05 试举例说明有些应用程序愿意采用不可靠的UDP，而不愿意采用可靠的TCP。
实时数据：
比如QQ聊天、视频播放平台哔哩哔哩等。在互联网上传输实时数据的分组时，有可能会出现差错甚至丢失。如果利用TCP协议对这些出错或丢失的分组进行重传，那么时延就会大大增加。因此，实时数据的传输在运输层就应采用用户数据报UDP协议。这就是意味着，对于实时数据的传输，我们宁可丢失少量分组，也不要等待太晚到达的分组。在连续的音频和视频数据流中，很少量的分组丢失对播放效果的影响不大，因而是可以容忍的。
另外，当网络出现拥塞时，TCP的拥塞控制就会让TCP的发送方放慢报文段的发送。可能有的应用程序就不愿意放慢其报文段的发送速度。
其次，可能有的应用程序不需要TCP的可靠传输，在上面这些情况下，就宁可使用UDP来传送。
5-06 接收方收到有差错的UDP用户数据报时应如何处理？
因为UDP首部的检验和字段，会检验首部和数据部分。
如果有差错，接收方会丢弃这个用户数据报；
但是也可以上交给应用层，但要附上出现了差错的警告。
5-07 如果应用愿意使用UDP完成可靠传输，这可能吗？请说明理由。
这是可能的，但这要由应用层自己来完成可靠传输。例如，应用层自己使用可靠传输协议。
底层不保证可靠传输，又想实现可靠传输，这就只能将可靠传输交付上层来实现了。
计网｜计算机网络传输层(运输层)一些必须要懂的重难点课后习题整理（一） - 知乎 (zhihu.com)
https://zhuanlan.zhihu.com/p/402864699
5-08 为什么说UDP是面向报文的，而TCP是面向字节流的？
UDP是面向报文的：发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对用用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这意味着，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一整个报文。所以说UDP是面向报文传输的。
TCP是面向字节流：TCP中的“流”指的是流入到进程或从进程流出的字节序列。虽然应用程序和TCP的交互是一次一个数据块（大小不等），但是TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
5-09 端口的作用是什么？为什么端口号要划分为三种？
我们知道，通信的实体是主机之间的进程。在单个计算机中的进程是用进程标识符来标志的，但是在互联网中，计算机的操作系统种类很多，不同的操作系统又使用不同格式的进程标识符。为了使运行在不同操作系统上的计算机中的进程能够相互通信，就必须用统一的方法对应用进程进行标志。
但是，将一个特点机器上运行的特定进程，指明为互联网上通信的最后终点时不可行的。这是因为进程是动态的程序，进程的创建和撤消都是动态的，通信的一方几乎无法知道和识别对方机器上的进程。另外，我们往往需要利用目的主机提供的功能来识别终点，但是不一定要知道这个服务器的功能是由目的主机的哪一个进程实现的。
因此，端口就应运而生了。在应用层和运输层之间的界面上，设置一个特殊抽象的“门”，应用层中的应用要通过运输层发送到互联网，就必须通过这个“门”，这个“门”就是端口。
简而言之，端口的作用就是对TCP/IP体系的应用进程进行统一的标志，使运行在不同操作系统的计算机的应用进程能够互相通信。
将端口号分为3类是因为：避免端口号重复，无法区分应用进程。二是因特网上的计算机通信都是采用C/S方式，在客户发起通信请求时，必须知道服务器的端口，对于一些主要
的应用程序，必须让所有用户知道。
5-10 试说明运输层中伪首部的作用。
伪首部并不是UDP用户数据报真正的首部，只是在计算检验和时，临时添加在UDP用户数据包前面，得到一个UDP用户数据报。
检验和就是按照这个临时的UDP用户数据报来计算的。这个伪首部既不向下传送也不向下递交，仅仅是为了计算检验和。
5-11 某个应用进程使用运输层的用户数据报UDP，然后继续向下交给IP层后，又封装成IP数据报。既然都是数据报，是否可以跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没有提供？
不可以。
IP数据报承担了主机寻址功能，可以找到目的主机，却无法找到目的进程，分组还是停留在网络节点中，而无法到达通信实体。
UDP提供了对进程的分用和复用功能，以及对数据报的差错检测。
5-12 一个应用程序用UDP，到了IP层把数据报再划分为4个数据报片发送出去。结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。
重传时，IP数据报的标识字段会有另一个标识符，只有标识符相同的IP数据报片才能组装成一个IP数据报。
5-13 一个UDP用户数据报的数据字段为8192字节。在链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每个IP数据报的数据字段长度和片偏移字段的值。
已知UDP数据报的数据字段为8192字节，再加上UDP的首部，一共8200字节。每个MAC帧数据部分的最大长度为1500,除去IP数据报的固定首部20字节，可知IP数据报的数据部分为1480字节。
应当划分为：
8200/1480 = 5...800
因此应当划分为6个IP数据报片，每个数据报片的数据字段长度和片偏移如下：
① 1500字节（加首部20字节） 片偏移为:0
② 1500字节 片偏移为1480/8 = 185
③ 1500字节 片偏移为2960/8 = 370
④ 1500字节 片偏移为4440/8 = 555
⑤ 1500字节 片偏移为5920/8 = 740
⑥ 820 字节 片偏移为7400/8 = 925
5-14 一个UDP用户数据报的首部的十六进制表示是：06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发给服务器还是从服务器发送给客户？使用UDP这个服务器程序是什么？
根据UDP的首部组成：
可知，
源端口: 0*16^3+6*16^2+3*16+2*16^0 = 1586（十进制）
目的端口: 0*16^3+0*16^2+4*16+5*16^0 = 69（十进制）
用户数据报总长度：0*16^3+0*16^2+1*16+12*16^0 = 28(十进制）
数据部分长度 = 总长度 - 首部长度 = 20（字节）
目的端口为69<1023(0~1023为熟知端口），所以数据报是从客户端发送给服务器的，经查询，这个服务器程序TFTP。
5-15 使用TCP对实时话音数据的传输会有什么问题？使用UDP在传送数据文件时会有什么问题？
因为TCP是面向连接的，建立逻辑连接就会有一定的时延，如果再发生网络拥塞，TCP的拥塞控制会让实时话音数据放慢发送速度，这对于实时数据传输是无法忍受的，再加上TCP是可靠传输协议，如果数据出现了丢失，会重传，这时重传的数据已经失去了其意义。
UDP是不可靠的传输协议，如果在使用UDP在传输数据文件出现了错误，会直接丢弃，导致数据的丢失。
5-16 在停止等待协议中如果不使用编号是否可行？为什么？
不可以。
“停止等待”就是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。
分组和确认分组都必须进行编号，这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
5-17 在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也不做）是否可行？试举出具体例子说明理由。
不行，如果接收方在收到重复字段时，不给发送方发送确认分组，发送方会认为接收方没有正确收到这个字段，会一直重传，达到一定的重传次数之后，会认为是网络出现了故障。
5-18 假定在运输层使用停止等待协议。发送方发送报文段M0后在设定的时间内未收到确认，于是重传M0,但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送的过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0,并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。
试画出类似于图5-9所示的双方交换报文段的过程。
5-19 试证明：当用n比特进行分组的编号时，若接受窗口等于1（即只能按序接收分组），则仅在发送窗口不超过2^n - 1时，连续ARQ协议才能正确运行。窗口单位是分组。
坦白说，这个题只有下面链接的博主的解释勉强能看懂
5-20 在连续的ARQ协议中，若发送窗口等于7，则发送端在开始可连续发送7个分组。因此，在每一分组发出后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这7个分组发出的时间分别为t0,t1,...,t6，且tout都一样大。试问如何实现这7个超时计时器（这叫软时钟法）？
可以用相对发送时间实现一个链表：
百度教育 (baidu.com)
用数组也可以：
数组的下标是分组的序号，数组的内容是相对时间(Ti-T(i-1))；
5-21 假定使用连续ARQ协议，发送窗口大小是3，而序号范围是[0,15]，而传输媒体保证在接受方能够按序收到分组。在某一时刻，在接收方，下一个期望收到的序号是5.
试问：
（1）在发送方的发送窗口中可能出现的序号组合有哪些？
（2）接收方已经发送出的、但在网络中（即还未到达发送方）的确认分组可能有哪些？说明这些确认分组是用来确认哪些序号的分组。
（1）根据题目，接受方下一个期望收到的序号是5，而传输媒体又保证分组是按序到达的。
因此，发送窗口只能是下面的情况：
序号组合有：234、345、456、567.
(如果这里没有理解为什么发送窗口的最左最右位置是上图的情形，可以看5-19题链接中博主的解释）
（2）首先我们得搞清楚：发送窗口内的分组可能有哪些情况？
窗口内的分组只能有两种情况：①已经发送，但未经确认的分组；②可以发送，但是还未发送的分组。
若序号组合是234：接收方期望收到的分组是5，说明234是已经发送的分组，但是还未经确认的分组。那么这种情况下，234均未收到确认。
若序号组合是345：那么34均未收到确认。
若序号组合是456：那么4未收到确认。
若序号组合是567：那么无未收到确认的分组。
总的来说，2、3、4分组均有可能未被确认。
5-22 主机A向主机B发送了一个很长的文件，其长度为L字节。假定TCP使用的MSS为1460字节。
（1）在TCP的序号不重复使用的条件下，L的最大值是多少？
（2）假定使用上面计算出的文件长度，而运输层、网络层和数据链路层所用的首部开销共66字节，链路的数据率为10Mbit/s，试求这个文件所需的最短发送时间.
（1）序号所占字节数为4字节，每个字节对应一个序号，序号不重复使用的条件下，L的最大值是2^32 = 4GB = 4294967296 字节。
（2）数据链路层数据部分的最大字节数为1480，
4294967296/1460 = 2941759(约等）
因此，首部总共所占字节:2941759*66 = 194156094 字节，
T = （ 首部+数据部分）/数据率 =（4294967296 + 194156094 ）*8/10^7 = 3591.2986592 s ,大约一个小时
5-23 主机A向主机B连续发送了两个TCP报文段，其序号分别是70和100.试问：
（1）第一个报文段携带了多少字节的数据？
（2）主机B收到第一个报文段后发回的确认中的确认号应当是多少？
（3）如果B收到第二个报文段后发回的确认中的确认号是180，试问A发送的第二个报文段中的数据有多少字节？
（4）如果A发送的第一个报文段丢失了 ，但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少？
（1）在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号：
因此第一个报文段的长度 = 第二个报文段序号 - 第一个报文段序号 = 30 字节
（2）主机B收到的第一个报文段之后，期待收到的序号应当为100
（3）该题跟（1）问相同，因此第二个报文段中的数据有80字节
（4）主机B虽然收到了第二个报文段，但是第一个报文段丢失了，因此，主机B期待收到的报文段的序号依然是第一个报文段的第一个字节的序号：70
5-24 一个TCP连接下面使用256kbit/s的链路，其端到端时延为128ms。经测试，发现吞吐量只有120 kbit/s。试问发送窗口W是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）
第一种情况：接收端在接收完一批数据之后才发送确认：
在一个传输周期内，从发送第一个报文段到收到确认时间为:
T = 发送窗口W/链路速率R+往返时间（2倍的端到端时延）
吞吐量 = 发送窗口W/传输时间T
经计算，
120 kbit/s = W(W/256 kbit/s + 2*128ms)
W = 57826b = 7228 字节（约等）
计算题.一个TCP连接下面使用256kb/s的链路，其端到端时延为128mS。经测试，发 现吞吐量只有120kb/s。_百度知道 (baidu.com)
吞吐量 = 最大发送窗口W/往返时延
120 kbit/s = W/256ms
W = 30720 bit = 3840字节
计网｜计算机网络传输层(运输层)一些必须要懂的重难点课后习题整理（三） - 知乎 (zhihu.com)
5-25 为什么在TCP首部中要把TCP的端口号放入最开始的4个字节？
在ICMP的差错报文中要包含紧随IP头部后面的8个字节的内容，让在TCP头部最开始的4个字节是TCP的端口号，就可以在ICMP的差错报文的上述8个字节中包含TCP的源端口和目的端口。
当发送IP分组的源收到ICMP差错报文时需要用这两个端口来确定是哪个应用进程的网络通信出了差错。
5-26 为什么在TCP首部中有一个首部长度字段，而UDP的首部中就没有这个字段？
UDP提供的无连接的通信服务，首部也是固定的8个字节；而TCP报文段除了固定首部20字节，还有一个可选项，为了使接收方知道哪些字节是数据部分，哪些字节是首部，于是设了这样一个字段标识首部长度。
5-27 一个TCP报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，问还能否用TCP来传送？
因为IP数据报的总长度只有16位，因此IP数据报的最大长度为2^16 - 1 = 65535 字节。
TCP报文段的最大数据部分 = IP数据报最大长度 - IP数据报固定首部 - TCP固定首部
= 65535 - 20 - 20 = 65495 字节
如果要传送的数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，依然可以使用TCP传输，编号用完再重复使用即可，但是应该设法保证不出现编号的混乱。
5-28 主机A向主机B发送TCP报文段，首部中的源端口是m而目的端口是n。当B向A发送回信时，其TCP报文段的首部中的源端口和目的端口分别是什么？
源端口是n,目的端口是m
5-29 在使用TCP传送数据时，如果有一个确认报文段丢失了，也不一定会引起与该确认报文段对应的数据的重传。试说明理由。
由于TCP确认机制采用了累积确认方法，即一个TCP确认报文段中的确认号标识了接收方将要接收方将要接收的下一个字节，这表示接收方已经收到该确认号之前的所有字节。现在假设发送方一次发送了多个报文段，而接收方成功接收到这些报文段并发出相应的确认。如果某个报文段的确认丢失，而在它之后的其他报文段的确认到达，这时，只要该报文段的重传计时器没有超时，发送方就该知道该报文段被正确接收而不需要重传。
5-30 设TCP使用的最大窗口为65535字节，而传输信道不产生差错，带宽也不受限制。若报文段的平均往返时间为20ms，问所能得到的最大吞吐量是多少？
最大吞吐量 = 最大窗口/平均往返时间 = 65535*8 bit / 20*10^-3 s = 26.214 Mbit/s
5-31 通信信道带宽为 1 Gbit/s，端到端传播时延为 10 ms。TCP的发送窗口为65535字节。试问：可能达到的最大吞吐量是多少？信道的利用率是多少？
最大吞吐量 = 发送窗口W / 往返时延
= 65535*8 bit /(20*10^-3) s
= 26.214 Mbit/s
信道的利用率 = 最大吞吐量/信道带宽
= 26.214 Mbit/s /1Gbit/s
= 2.62%(约等)
5-32 什么是Karn算法？在TCP的重传机制中，若不采用Karn算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度？
Karn算法是要解决如下问题：
TCP为了保证可靠传输，在发送完报文段之后，一段时间内没有收到确认报文，就会超时重传该报文段；那么问题来了，这个一段时间究竟是多长的时间？
如果这个超时重传的时间设置过短，正巧该报文段经过的是一个低速率的网络，确认报文段在网络中滞留，会造成很多不必要的重传，使网络负荷增大；若这个超时重传的时间设置过长，正巧该报文段经过的是一个高速率的网络，网络空闲时间增大，降低了传输效率。
TCP如此便采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间差就是报文段的往返时间RTT。为了使得出的结果更平滑，TCP就保留了一个加权平均往返时间RTTs ：
新的RTTs = (1- a) x (旧的RTTs) + a x (新的RTT样本)
可以看出，当a很接近于0的时候，表示新的RTTs和旧的RTTs值相比变化不大，这样就导致RTT值更新较慢；当a接近于1的时候，则表示RTTs值受新的RTT样本的影响较大，这样就导致RTT值更新较快。
问题到这还没完，设想这样一种状况： 发送出一个报文段，设定的重传时间到了，还没有收到确认，于是重传报文段。经过一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？
如果这个确认报文段是对先发送的报文段的确认，但却被判定为对重传报文段的确认，那么会造成RTT越来越短，导致不必要的重传。反之，会造成RTT越来越长，造成网络空闲。
为了解决上述问题，Karn提出了一个算法：在计算加权平均RTTs时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均RTTs和RTO就较准确。
在统计意义上，最后的RTO会减少到使用Karn算法的一半，看下图：
5-33 假定TCP在开始建立连接时，发送方设定超时重传时间RTO = 6秒。
（1）当发送方收到对方的连接确认报文段时，测量出RTT样本值为1.5秒。试计算现在的RTO值
（2）当发送方发送数据报文段收到确认时，测量出RTT样本值为2.5秒。试计算现在的RTO值。
计算RTO的公式为：
根据规定，每当第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本的值，但以后每测量到一个新的RTT样本，就按下式重新计算一个RTTs:
其中，已成为建议标准的RFC 6298推荐的α值为1/8.
而RTTd是RTT的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。RFC 6298建议这样计算RTTd。当第一次测量时，RTTd值取为测量到的RTT样本值的一半，在以后的测量中，则使用下式计算加权平均的RTTd：
这里β是个小于1的系数，它的推荐值是1/4，即0.25.
（1）RTO = 1.5 + 1/2*1.5*4 =4.5 s
（2）新的RTTs = (1-1/8)*1.5 + 1/8*2.5 = 1.625 s
新的RTTd = 3/4*0.75 + 1/4*|1.625 - 2.5| = 0.78125 s
RTO = 1.625+0.78125*4 = 4.75 s
5-34 已知第一次测得TCP的往返时间RTT是30ms。接着收到了三个报文段，用它们测量出的往返时间样本RTT分别是：26ms、32ms和24ms。设α = 0.1.试计算每一个新的加权平均返回时间值RTTs。讨论所得出的结果。
依据以上公式：
RTT1 = 0.9*30+0.1*26 = 29.6 ms
RTT2 = 29.6*0.9 + 0.1*32 = 29.84 ms
RTT3 = 29.84*0.9 + 0.1*24 = 29.256 ms
可以看出，当α的值接近于0的时候，新样本对RTT的影响是很小的。
5-35 用TCP通过速率为1G bit/s的链路传送一个10MB的文件。假定链路的往返时延RTT = 50 ms。TCP选用了窗口扩大选项，使窗口达到可选用的最大值。在接收端，TCP的接收窗口为1MB(保持不变），而发送端采用拥塞控制算法，从慢开始传送。假定拥塞窗口以分组为单位计算，在一开始发送1个分组，而每个分组长度都是1KB。假定网络不会发生拥塞和分组丢失，并且发送端发送数据的速率足够快，因此发送时延可以忽略不计，而接收端每一个收完一批分组后就立即发送确认ACK分组。
（1）经过多少个RTT后，发送窗口大小达到1MB？
（2）发送端把整个10MB文件传送成功共需要经过多少个RTT？传送成功是指发送完整个文件，并收到所有的确认。TCP扩大的窗口够用吗？
（3）根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？
（1）根据慢开始算法，发送方每收到一个对新报文段的确认（对重传的确认不算在内），就把发送方的拥塞窗口加1.因此，发送方每发送一次报文，实际上拥塞窗口是增大了一倍的。因此，1MB = 2^10 KB，所以需要10次发送，发送窗口就能达到1MB大小。
（2）当第10个RTT结束时，已传送成功的分组是2 10 − 1 2^{10}-12
10
−1个分组，正好比1MB少一个分组。一个分组只有1KB，可先不考虑。可以这样分析:在第10个RTT结束时，发送窗口为1MB，已传送成功的数据量约为1MB（准确的是1MB-1 KB)，因此在此基础上，我们还需要再传送9MB（实际上还需要再传送9MB+ 1 KB)。由于发送窗口必须小于等于接收窗口大小，因此，后面的发送窗口大小固定为1MB,因此还需要10个RTT（9MB+1KB）,因此总共需要20个RTT。
5-36 假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。在一开始时发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一组分组后，就立即发回确认ACK。假定分组的编号为i，在一开始发送的是i = 1的分组。以后当 i = 9,25,30,38和50时，发生了分组的丢失。再假定分组的超时重传时间正好是下一个RTT开始的时间。试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。
线性增大：在没有分组丢失的情况下，每收到一个确认拥塞窗口就+1
乘法减小：一但出现超时或3个重复的确认，就要把门限值设置为当前拥塞窗口值的一半
（具体介绍可以看下面37题）
5-37 在TCP的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法？这里每一种算法各起什么作用？“乘法减小”和“加法增大”各用在什么情况下？
慢开始：
这个“慢”并非是指拥塞窗口增长的速度慢，而是指拥塞窗口是由小到大逐渐增大（翻倍增长）的，而不是一开始拥塞窗口就很大。
慢开始算法的初始拥塞窗口是这样规定的：
若SMSS（发送方的最大报文段）>2190字节，则设置初始拥塞窗口为cwnd = 2xSMSS字节，且不能超过2个报文段
若SMSS>1095字节且SMSS<=2190字节，则设置初始拥塞窗口为cwnd = 3xSMSS字节，且不得超过3个报文段
若SMSS<=1095，则设置初始拥塞窗口cwnd = 4xSMSS字节，且不得超过4个报文段
慢开始的拥塞窗口增长规则是:
在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值，就是
拥塞窗口cwnd每次的增长量 = min(N,SMSS)
其中N是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
慢开始算法起的作用:试探性地控制拥塞窗口，避免网络出现拥塞。
拥塞避免（加法增大）:
当慢开始算法使拥塞窗口增长到一定大小的时候，为了避免这种增长可能带来的拥塞，因此，当慢开始算法使得拥塞窗口增长到某个阈值的时候，就要切换到拥塞避免算法来减缓这种增长。
拥塞避免算法的规则是这样的：每经过一个往返时间RTT，发送方的拥塞窗口cwnd的大小就+1，而不是向慢开始那样加倍增长，因此在拥塞避免节点就称为“加法增大”AI，表明在拥塞避免阶段，拥塞窗口cwnd按线性规律缓慢增长，比慢开始的拥塞窗口增长速率缓慢得多。
拥塞避免的作用：显然就是减缓慢开始的拥塞窗口增长速率，以避免过快增长带来的拥塞。
快重传：
有时，个别的报文段在网络中意外丢失，但是此时网络并没有发生拥塞，如果发送方迟迟收不到确认，就会产生超时，并误以为网络发生拥塞，这就导致发送方错误地启动慢开始算法，把拥塞窗口又置为1，因而不必要地降低的传输效率。
采用快重传算法可以让发送方尽早知道发生了个别报文段的丢失，具体做法就是接收方在收到数据时立马发送确认，如M2出现了丢失，在发送方发送M3时，接收方向发送方发送一个对M2的重复确认，当发送方发送M4时，接收方依然向发送方发送一个对M2的重复确认，M5亦如此。这样发送方就收到了三次对M2的重复确认，发送方就知道M2只是意外丢失了，而并未出现拥塞，这样发送方就不会启动慢开始算法了，而是立即重传M2.
快重传的作用：避免发送方对网络拥塞误判引起的误启动慢开始算法，减少不必要的传输效率的降低。
快恢复（乘法减小）：
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始的门限减半，这是为了预防网络发生拥塞，但是并不执行慢开始算法。
快恢复的作用：使拥塞窗口不会被过分地减小，提高传输效率。
“加法增大”和“乘法减小”各用在什么情况下？
加法增大用在当慢开始算法使拥塞窗口的大小>=门限值的时候
乘法减小用在当发送方连续收到三个重复确认的时候
5-38 设TCP的ssthresh的初始值为8（单位为报文段）。当拥塞窗口上升到12时网络发生了超时，TCP使用慢开始和拥塞避免。试分别求出RTT = 1到RTT = 15的各拥塞窗口大小。你能说明拥塞窗口每一次变化的原因吗?
假设此时拥塞窗口初始值为1
当RTT = 1 时，cwnd = 1
当RTT = 2 时，cwnd = 2，因为此时发送方收到1个确认报文
当RTT = 3 时，cwnd = 4，因为此时发送方收到两个确认报文
当RTT = 4 时，cwnd = 8，因为此时发送方收到四个确认报文
当RTT = 5 时，cwnd = 9，因为此时拥塞窗口达到了阈值，使用了拥塞避免算
当RTT = 6 时，cwnd = 10，因为启用了拥塞避免算法
当RTT = 7 时，cwnd = 11，因为启用了拥塞避免算法
当RTT = 8 时，cwnd = 12，因为启用了拥塞避免算法
当RTT = 9 时，cwnd = 1，因为发生了超时，启用慢开始算法，ssthresh减半
当RTT = 10 时，cwnd = 2，因为此时发送方收到一个确认报文
当RTT = 11 时，cwnd = 4，因为此时发送方收到两个确认报文
当RTT = 12 时，cwnd = 6，此时拥塞窗口达到了阈值，下面要使用拥塞避免算法
当RTT = 13 时，cwnd = 7，因为启用了拥塞避免算法
当RTT = 14 时，cwnd = 8，因为启用了拥塞避免算法
当RTT = 15 时，cwnd = 9，因为启用了拥塞避免算法
5-39 TCP的拥塞窗口cwnd大小与RTT的关系如下所示:
(1)试画出如图5-25所示的拥塞窗口与RTT的关系曲线。
(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有多大?
（1）
（2）慢开始:[1，6]，[23，26]
（3）拥塞避免:[6,16]，[7，22]
（4）RTT = 16时，发送方是通过收到三个重复的确认，RTT = 22后发送方是检测到超时
（5）RTT = 1时，门限为32 ; RTT = 18 时，门限为21；RTT = 24时，门限为13
（6）在RTT等于
