计算机网络谢希仁第五章课后题【背诵版本】
5-01 试说明运输层在协议栈中的地位和作用。运输层的通信和网络层的通信有什么重要的区别？为什么运输层是必不可少的？
地位和作用：
运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能的最低层，当网络边缘部分的两台主机进行端到端的通信时，都要使用运输层。
网络层和运输层通信的重要区别：
从网络7层来说，通信的两端是两台主机，IP数据报的首部标志了这两台主机的IP地址。但实际上，真正进行通信的实体是双方主机中的进程——是一台主机中的应用进程和另一台主机中的应用进程在交换数据（即通信）。因此，IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付主机中的应用进程。
而运输层正是实现主机间进程通信的协议层，实现不同主机之间进程的“逻辑通信”（括号不背 逻辑通信的意思是：从应用层来看，只要应用层报文交给下面的运输层，运输层就可以将这报文传送到对方的运输层。。好像这种通信就是沿水平方向直接传送数据，但事实上这两个运输层之间并没有一条水平方向的物理连接，数据的传送是经过多个层次传送的）
为什么运输层必不可少：
真正通信的实体是主机之间的不同进程，因此，需要运输层将网络分组交付给进程，完成进程间的通信。运输层还要对收到的报文进行差错检测，运输层的TCP协议还可以保证可靠传输。
5-02 网络层提供数据报或虚电路服务对上面的运输层有何影响？
数据报提供不可靠的交付，虚电路服务提供可靠交付。但即使网络层提供了可靠交付，那也只是主机到主机的通信是可靠的，而进程到进程的通信仍可能出错。因此当必须保证可靠通信时，即使网络层提供了可靠服务，运输层仍然必须有可靠交付的协议。因此互联网在网络层只提供比较简单的数据报服务，这使得网络层大大简化，使得网络的造价降低，而用运输层来实现可靠交付。因此，网络层的服务并没有对运输层的设计产生多大的影响。
5-03 当应用程序使用面向连接的TCP和无连接的IP时，这种传输是面向连接还是无连接的？
（复习）5-04 试画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上，而这条运输连接又复用到IP数据报上。
如图，多个应用进程(HTTP、SMTP等)使用同一个运输层进行数据传送，而多个 TCP 报文又统一向下交给 IP 层作为.IP 报文的数据部分。
在这张图中，复用主要体现在运输层和网络层之间。首先，主机 A 上的多个应用进程（如 AP1 和 AP2）通过运输层复用，共享同一条传输连接，并通过端口号来区分不同的应用数据。然后，这条传输连接进一步封装到网络层的 IP 数据报中，使得运输层的复用连接也可以在网络层进行复用，使一个 IP 数据报携带多个应用的数据。复用机制提高了网络资源的利用率，允许不同应用共享相同的网络连接，简化了数据传输管理。
5-05 试举例说明有些应用程序愿意采用不可靠的UDP，而不愿意采用可靠的TCP。
传输实时数据的应用进程希望用UDP。在互联网上传输实时数据的分组时，有可能会出现差错甚至丢失。如果利用TCP协议对这些出错或丢失的分组进行重传，那么时延就会大大增加。因此，对于实时数据的传输，我们宁可丢失少量分组，也不要等待太晚到达的分组。在连续的音频和视频数据流中，很少量的分组丢失对播放效果的影响不大，因而是可以容忍的。所以实时数据的传输在运输层就应采用用户数据报UDP协议。
当网络出现拥塞时，TCP的拥塞控制就会让TCP的发送方放慢报文段的发送。可能有的应用程序就不愿意放慢其报文段的发送速度。
其次，可能有的应用程序不需要TCP的可靠传输，在上面这些情况下，就宁可使用UDP来传送。
5-06 接收方收到有差错的UDP用户数据报时应如何处理？
简单丢弃。
因为UDP首部的检验和字段，会检验首部和数据部分。
如果有差错，接收方会丢弃这个用户数据报；
但是也可以上交给应用层，但要附上出现了差错的警告。
5-07 如果应用愿意使用UDP完成可靠传输，这可能吗？请说明理由。
这是可能的，但要由应用层自己来完成可靠传输。例如，应用层自己使用可靠传输协议。
底层不保证可靠传输，又想实现可靠传输，这就只能将可靠传输交付上层来实现了。
（复习）5-08 为什么说UDP是面向报文的，而TCP是面向字节流的？
UDP是面向报文的：发送方的UDP对应用层交下来的报文，在添加首部后就向下交付IP层。对这些报文，既不合并，也不拆分，而是保留这些报文的边界。意味着，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一整个报文。所以说UDP是面向报文传输的。
TCP是面向字节流：TCP把应用层交下来的数据仅仅看成一连串无结构的字节流，并且对每一个字节进行编号，TCP根据当前网络拥塞程度和对方接收缓存大小，决定发送多长报文段。TCP旨在保证数据准确无误的传输给对方，不关心传输了多少个报文段和每个报文段包含多少字节。这表明TCP是面向字节流的。
5-09 端口的作用是什么？为什么端口号要划分为三种？
端口的作用是对 TCP/IP体系应用进程进行统一的标志，使运行不同操作系统的计算机的应用进程能够互相通信。
把端口号分成三种不同的类型是为了方便不同的应用程序使用:
熟知端口号(系统端口号)：其数值标号为0~1023,把它们指派给TCP/IP一些最重要的应用程序使用,让所有的用户都知道。当一种新型的应用程序出现后,IANA必须要为它指派一个熟知端口号,否者因特网上的其它应用程序就无法和它进行通信。
登记端口号：数值为1024~49151（2^14*3-1），给没有熟知端口号的应用程序使用的。
客户端使用的端口号：49152~65535（2^16-1），这类端口号仅在客户进程运行时才动态选择,是留给客户进程暂时使用的。
常见的熟知端口要记住。
FTP:21（文件传输协议 File Transfer Protocol），
Telnet:23，（远程终端协议 Telecommunication Network）
SMTP:25，（电子邮件传输协议 Simple Mail Transfer Protocol）
DNS:53，（域名系统 Domain Name System）
TFTP:69，（简单文件传输协议 Trivial File Transfer Protocol）
HTTP:80，（超文本传输协议 Hypertext Transfer Protocol）
SNMP:161，（简单网络管理协议 Simple Network Management Protocol）
HTTPS:443，（超文本传输安全协议 Hypertext Transfer Protocol Secure）
SNMP(trap):162。(SNMP 陷阱)
DHCP：69，动态主机配置协议 DHCP（Dynamic Host Configuration Protocol）
5-10 试说明运输层中伪首部的作用。
所谓“伪首部”不是 UDP用户数据报或 TCP 报文段真正的首部。只是在计算检验和时，临时添加在报文的前面，得到一个临时的 UDP用户数据报或 TCP 报文段。检验和就是按照这个临时的 UDP用户数据报或 TCP报文段来计算的。伪首部既不向下传送也不向上递交，而仅仅是为了计算运输层的检验和。
5-11 某个应用进程使用运输层的用户数据报UDP，然后继续向下交给IP层后，又封装成IP数据报。既然都是数据报，是否可以跳过UDP而直接交给IP层？哪些功能UDP提供了但IP没有提供？
不可以跳过。IP数据报承担主机寻址功能，网络层转发分组只能找到目的主机，却无法找到目的进程，分组会停留在主机中的网络层中，而没有交付进程。
UDP提供了对进程的分用和复用功能，以及对数据报的差错检测。
5-12 一个应用程序用UDP，到了IP层把数据报再划分为4个数据报片发送出去。结果前两个数据报片丢失，后两个到达目的站。过了一段时间应用程序重传UDP，而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问：在目的站能否将这两次传输的4个数据报片组装成完整的数据报？假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。
不行。仅当标识符相同的IP数据报片才能组装成一个IP数据报。重传的IP数据报片标识字段会有另一个标识符。前两个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协议对这些出错或丢失的分组进行重传，那么时延就会大大增加。因此，对于实时话音数据的传输，我们宁可丢失少量分组，也不要等待太晚到达的分组。在连续的音频和视频数据流中，很少量的分组丢失对播放效果的影响不大，因而是可以容忍的。所以实时话音数据传输在运输层就应采用UDP协议。
- UDP是不可靠的传输协议，如果使用UDP传输数据文件时，出现了错误，会直接丢弃，导致数据的丢失。
- 如果话音数据不是实时播放(边接收边播放)就可以使用TCP。接收端用TCP将话音数据接收完毕后，可以在以后的任何时间进行播放。但本题目假定是实时话音数据传输，因此必须使用 UDP。
5-16 在停止等待协议中如果不使用编号是否可行？为什么？
不可以。分组和确认分组都必须进行编号，这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。（可结合P157上的例子背）
（“停止等待”就是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。）
5-17 在停止等待协议中，如果收到重复的报文段时不予理睬（即悄悄地丢弃它而其他什么也不做）是否可行？试举出具体例子说明理由。
收到重复报文不确认相当于确认丢失。发送方正是因为没有收到该报文的确认才会超时重传这个报文，如果接收方在收到重复报文时，不予理会即不给发送方发送确认分组，发送方会认为接收方没有正确收到这个字段，会一直重传，达到一定的重传次数之后，会认为是网络出现了故障。
5-18 假定在运输层使用停止等待协议。发送方发送报文段M0后在设定的时间内未收到确认，于是重传M0,但M0又迟迟不能到达接收方。不久，发送方收到了迟到的对M0的确认，于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送的过程中丢失了。正巧，一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0,并发送确认。显然，接收方后来收到的M0是重复的，协议失败了。
试画出类似于图5-9所示的双方交换报文段的过程。
5-19（复盘） 试证明：当用n比特进行分组的编号时，若接受窗口等于1（即只能按序接收分组），则仅在发送窗口不超过2ⁿ - 1时，连续ARQ协议才能正确运行。窗口单位是分组。
- 如图，设发送窗口记为WT，接收窗口记为WR。假定用3比特进行编号。设接收窗口正好在7号分组处。
- 发送窗口WT的位置不可能比②的位置更靠前：因为接收窗口的位置表明接收方正等待接收7号分组，发送方不可能已经收到了对7号分组的确认。即不可能比②的位置更靠前(前方就是图的右方)。
- 发送窗口WT的位置也不可能比③的位置更靠后：因为接收窗口的位置表明接收方已经对6号分组(以及以前的分组)发送了确认。若发送窗口在6号分组的左边，那就表明还没有发送6号分组。这显然是不可能的。
- 发送窗口WT的位置可能是在某个中间的位置，如①。
- 对于①和②的情况，在WT的范围内必须无重复序号，即WT≤2ⁿ。
- 对于③的情况，在 WT+WR的范围内无重复序号，即WT+WR≤ 2ⁿ。
- 现在WR=1，故发送窗口的最大值WT≤ 2ⁿ - 1。
5-20 在连续的ARQ协议中，若发送窗口等于7，则发送端在开始可连续发送7个分组。因此，在每一分组发出后，都要置一个超时计时器。现在计算机里只有一个硬时钟。设这7个分组发出的时间分别为t0,t1,...,t6，且tout都一样大。试问如何实现这7个超时计时器（这叫软时钟法）？
5-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的分组的
5-22 （复盘）主机A向主机B发送了一个很长的文件，其长度为L字节。假定TCP使用的MSS为1460字节。
（1）在TCP的序号不重复使用的条件下，L的最大值是多少？
（2）假定使用上面计算出的文件长度，而运输层、网络层和数据链路层所用的首部开销共66字节，链路的数据率为10Mbit/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是多少？（提示：可以有两种答案，取决于接收端发出确认的时机）
5-25 为什么在TCP首部中要把TCP的端口号放入最开始的4个字节？
在ICMP的差错报文中(见教材的图4-28)要包含IP首部后面的8个字节的内容,正是 TCP首部中的源端口和目的端口。当 TCP收到 ICMP 差错报文时，需要用这两个端口来确定是哪条连接出了差错。
5-26 为什么在TCP首部中有一个首部长度字段，而UDP的首部中就没有这个字段？
TCP首部除了20字节固定长度部分外，还有选项，因此TCP首部长度是可变的。UDP首部长度是固定的8字节，不需要这个字段。
5-27 一个TCP报文段的数据部分最多为多少个字节？为什么？如果用户要传送的数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，问还能否用TCP来传送？
（1）（MSS表示 最大报文段长度，但MSS上限是多少呢？可从IP数据报的总长度字段入手，）
IP数据报总长度字段只有16位，因此IP数据报的最大长度为2^16 - 1 = 65535 字节。
TCP报文段的最大数据部分 = IP数据报最大长度 - IP数据报固定首部 - TCP固定首部
= 65535 - 20 - 20 = 65495 字节
（2）如果要传送的数据的字节长度超过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算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。试问：重传时间最后会减小到什么程度？
（结合谢希仁p234图记一下图）Karn 算法。在计算加权平均 RTTs时，只要报文段重传了，就不采用其往返时间样本。这样得出的加权平均 RTTs和 RTO 就较准确。（允许TCP能够区分开有效和无效的往返时间样本，从而改进了往返时间的估算）
若不采用 Karn 算法，而是在收到确认时都认为是对重传报文段的确认，那么由此得出的往返时间样本和重传时间都会偏小。如图 T-5-32所示，TCP发送了报文段后，没有收到确认，于是超时重传报文段。但刚刚重传了报文段后，马上就收到了确认。显然，这个确认是对原来发送的报文段的确认。
但是，根据题意，认为这个确认是对重传的报文段的确认。这样得出的往返时间就会很小。这样的往返时间最后甚至可以减小到很接近于零。因此，上述的这种做法是不可取的。
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
讨论结果：RTTs的波动<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）根据整个文件发送成功所花费的时间（包括收到所有的确认），计算此传输链路的有效吞吐率。链路带宽的利用率是多少？
5-36 （复盘）假定TCP采用一种仅使用线性增大和乘法减小的简单拥塞控制算法，而不使用慢开始。发送窗口不采用字节为计算单位，而是使用分组pkt为计算单位。在一开始时发送窗口为1pkt。假定分组的发送时延非常小，可以忽略不计。所有产生的时延就是传播时延。假定发送窗口总是小于接收窗口。接收端每收到一组分组后，就立即发回确认ACK。假定分组的编号为i，在一开始发送的是i = 1的分组。以后当 i = 9,25,30,38和50时，发生了分组的丢失。再假定分组的超时重传时间正好是下一个RTT开始的时间。试画出拥塞窗口（也就是发送窗口）与RTT的关系曲线，画到发送第51个分组为止。
5-37 在TCP的拥塞控制中，什么是慢开始、拥塞避免、快重传和快恢复算法？这里每一种算法各起什么作用？“乘法减小”和“加法增大”各用在什么情况下？
慢开始：在主机刚刚开始发送报文段时可先将拥塞窗口cwnd 设置为一个最大报文段MSS 的数值。在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。逐步增大发送端的拥塞窗口cwnd，使分组注入到网络的速率更加合理。
拥塞避免：当拥塞窗口大于慢开始门限时，停止慢开始算法而改用拥塞避免算法。拥塞避免算法使发送的拥塞窗口每经过一个往返时延RTT就增加一个 MSS 的大小。
快重传算法：发送端只要一连收到三个重复的ACK，即可断定有分组丢失了就应该立即重传丢的报文段而不必继续等待为该报文段设置的重传计时器的超时。
快恢复算法：当发送端收到连续三个重复的ACK时，执行“乘法减小”算法，把慢开始门限ssthresh 减半，并设置为cwnd 值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
乘法减小：不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时(即出现一次网络拥塞)，就把慢开始门限值ssthresh减半（即设置为当前的拥塞窗口的一半）。当网络频繁出现拥塞时，ssthresh值就下降得很快，以大大减少注入到网络中的分组数。
加法增大：是指执行拥塞避免算法后，使发送的拥塞窗口每经过一个往返时延RTT就增加一个 MSS 的大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。（加法增大=拥塞避免）
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有多大?
【5-40】TCP 在进行流量控制时，是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起分组丢失的情况?如有，请举出三种情况。
- 当IP数据报在传输过程中需要分片，但其中的一个数据报片未能及时到达终点，而终点组装IP数据报已超时，只能丢弃该数据报。
- IP数据报已经到达终点，但接收缓存没有足够空间存放此数据报。
- 数据报在转发过程中经过一个局域网的网桥，但网桥在转发该数据报的帧时没有足够的存储空间而只好丢弃。
5-41复盘背
【5-42】在教材的图5-29中所示的连接释放过程中，在ESTABLISHED状态下，B能否先不发送 ack=u+1的确认?(因为B在后面要发送的连接释放报文段中，仍有ack=u+1这一信息。)
- 如果B不再发送数据了，可以把两个报文段合并成为一个，即只发送FIN+ACK报文段。
- 但如果 B还有数据要发送，那就不行，因为A迟迟收不到确认，就会以为刚才发送的 FIN 报文段丢失了，就超时重传这个FIN报文段，浪费网络资源。
【5-43】在教材的图5-30中,在什么情况下会发生从状态SYN-SENT到状态SYN-RCVD的变迁?
当A和B都作为客户，即同时主动打开TCP连接。这时的每一方的状态变迁都是
CLOSED——SYN-SENT——SYN-RCVD——ESTABLISHED
【5-44】试以具体例子说明为什么一个运输连接可以有多种方式释放。可以设两个互相通信的用户分别连接在网络的两结点上。
假设客户A向客户B发送释放连接请求
第一种情况：四报文挥手释放连接中B发送的ACK和FIN两个报文段是分开发送的，若B向A发送确认后B仍要发送数据，则发送完数据后B再向A发送断开连接请求。
第二种情况：四报文挥手释放连接中B发送的ACK和FIN两个报文段是合在一起发送的，若B向A发送确认后B不再发送数据，则在B向A发送确认时也可以发送断开连接请求。
5-45 解释为什么突然释放运输连接就可能会丢失用户数据，而使用TCP的连接释放方法就可保证不丢失数据。
当主机A和主机B之间连接建立后，主机A发送了一个TCP数据段并正确抵达主机B，接着主机A发送另一个TCP数据段，假设主机B在收到第二个TCP数据段之前发出了释放连接请求，如果这是突然释放连接，则第二个TCP报文段会丢失。
而使用TCP的连接释放方法，主机B发出了释放连接的请求，那么即使收到主机A的确认后，只会释放主机B到主机A方向的连接，B不再向A发送数据，而仍然可接受主机A发来的数据，所以可保证不丢失数据，
5-46 试用具体例子说明为什么在运输连接建立时要使用三报文握手。说明如不这样做可能会出现什么情况。
假设主机A向B发送的连接请求SYN 报文段滞留在网络中的某处。于是A超时重传，与B建立了TCP连接，交换了数据，最后也释放了连接。但滞留在网络中某处的陈旧请求SYN报文段，现在突然传送到B了。如果不使用三报文握手，那么 B就以为A现在要请求建立连接，于是就分配资源，等待A传送数据。但A并没想建立连接，则B就白白等待着A发送数据。
如果使用三报文握手，那么 B在收到陈旧 SYN报文段后，就向A发送 SYN报文段并确认收到。当A收到时，从确认号得知不应理睬这个报文段，则A发送复位报文段，拒绝了TCP 连接的建立，B收到复位报文段后就不会建立连接
（复盘）5-47 一客户向服务器请求建立TCP连接。客户在TCP连接建立的三报文握手中的最后一个报文段中捎带上一些数据，请求服务器发送一个长度为L字节的文件。假定:
（复盘）5-48 5-49UDP首部格式，(5) 5-51 5-56
【5-52】UDP和IP的不可靠程度是否相同?请加以解释。
UDP 和 IP的可靠性略有不同。相同之处是UDP和IP都是无连接，不可靠传输的协议。他们的首部都有检验和字段，当检验出有差错时，就丢弃错误数据报。
不同之处：UDP的检验和是既检验UDP用户数据报的首部又检验数据部分，而IP数据报的检验和只检验 IP 数据报的首部。UDP用户数据报的检验和还增加了伪首部，还检验了下面的IP数据报的源IP地址和目的IP 地址。
【5-57】 某客户有67000 字节的分组。试说明怎样使用UDP 数据报将这个分组进行传送
一个 UDP用户数据报的最大长度是65535 字节。这个分组超过了最大长度，因此必须进行分割(例如，分割成为两个UDP用户数据报)，使其长度不超过最大长度。
【5-58】 TCP在 4:30:20发送了一个报文段。它没有收到确认。在 4:30:25它重传了前面这个报文段。它在 4:30:27收到确认。若以前的RTT值是4秒，根据Karn 算法，新的 RTT 值是多少?
根据Kam 算法，只要是TCP报文段重传了，就不采用其往返时间样本。本题中收到的确认是在重传后收到的。因此RTT值没有变化，仍然是以前的数值(4秒)。
【5-59】（简单，会画就行）TCP连接使用 1000字节的窗口值，而上一次的确认号是 22001。它收到了个报文段，确认了字节22401。试用图来说明在这之前与之后的窗口情况。
在这之前与之后的窗口情况如图T-5-59 所示。这里要注意的是，发送窗门为1000字节，窗口里面的序号也正好是1000个。号码小的在后面，即在图的左方。另外一点要注意的是，发送方收到的确认号表示接收方期望能够收到的序号，也就是发送方要发送的序号。这个序号应当在发送窗1的最前面(最右方)。
【5-61】复盘
【5-62】TCP连接处于ESTABLISHED状态。以下的事件相继发生:
(1)收到一个 FIN 报文段。
(2)应用程序发送“关闭”报文。
在每一个事件之后，连接的状态是什么?在每一个事件之后发生的动作是什么?
解答:
(1)收到FIN 报文段，服务器发送ACK报文段，并进入CLOSE-WAIT状态
(2)应用程序发送“关闭”报文给服务器,表明没有数据要发送了。这时服务器就应当发送 FIN 报文段给客户，然后转换到LAST-ACK 状态，并等待来自客户端的最后的确认。以上的状态转换可参考教材上的图 5-30。
【5-64】TCP 连接处于 FIN-WAIT-1状态。以下的事件相继发生:
(1)收到 ACK 报文段。
(2)收到 FIN 报文段。
(3)发生了超时。
在每一个事件之后，连接的状态是什么?在每一个事件之后发生的动作是什么?
(1)处于FIN-WAIT-1状态的只有TCP的客户。当收到 ACK报文段后，TCP 客户不发送任何报文段，只是从 FIN-WAIT-1状态进入到 FIN-WAIT-2 状态。
(2)在收到 FIN报文段后，TCP 客户发送 ACK 报文段，并进入到TIME-WAIT 状态。
(3)当发生了超时，也就是在经过了2MSL时间后，TCP客户进入到CLOSED状态。
【5-66】（理解）主机 A 通过 TCP 连接向 B发送一个很长的文件，因此这需要分成很多个报文段来发送。假定某一个TCP报文段的序号是x，那么下一个报文段的序号是否就是x+1呢?
解答:设n是报文段数据长度的字节数，那么下一个报文段的序号应当是x+n。如果n=400，那么下一个报文段的序号应当是x+400。若在此报文段中仅有一个字节的数据，则下一个报文段的序号才是x+1。
【5-67】 TCP的吞吐量应当是每秒发送的数据字节数,还是每秒发送的首部和数据之和的字节数?吞吐量应当是每秒发送的字节数，还是每秒发送的比特数?
TCP的吞吐量本来并没有标准的定义，可以计入也可以不计入首部。不过，从拥塞控制来看，拥塞窗口和发送窗口针对的都是TCP 报文段中的数据字段，而重要的参数 MSS 也是指 TCP 报文段中的数据字段的长度，因此，把TCP的吞吐量定义为每秒发送的数据字节数是比较方便的。
计算机内部的数据传送是以每秒多少字节作为单位的，而在通信线路上的数据率则常用每秒多少比特作为单位。这两种表示方法并无实质上的差别。但因为MSS是用字节作为单位，因此，TCP吞吐量用每秒发送多少字节作为单位就比较简单一些。
【5-68】在 TCP的连接建立的三报文握手过程中，为什么第三个报文段不需要对方的确认?这会不会出现问题?
一般情况下只要发送方在三报文握手后紧接着发送数据，那么第三个报文段是不需要对方确认的。假设主机A向B发起SYN报文段，B收到并回复SYN+ACK报文段，此时A向B发送的第三个ACK报文段丢失了，但紧接着A认为连接已建立继续向B发送数据，那么A发送的数据报文段中，确认位ACK=1，并且自己的序号没有改变，确认号也是B选择的初始序号+1，则B仍然可以通过A发送的数据报文段得知A已经确认了B刚才发送的SYN+ACK报文段，B就顺利进入ESTABLISHED状态，可接收A发送的数据。
但是若主机A在三报文握手后不发送数据，那么B没有收到A对SYN+ACK的确认（第三个报文段），则不能接收数据，则B在经过一段时间后还没收到A的确认报文就会终止这个半开连接，这种情况就是第三个报文段的丢失导致了TCP连接无法建立
5-69 复盘 第一次做不会
5-70复盘再看
【5-72】已知 TCP 的接收窗口大小是 600(单位是字节，为简单起见以后就省略了单位)已经确认了的序号是300。试问，在不断地接收报文段和发送确认报文段的过程中，接收窗口也可能会发生变化(增大或缩小)。请用具体例子(指出接收方发送的确认报文段中的重要信息)来说明哪些情况是可能发生的，而哪些情况是不允许发生的。
解答:可以用图 T-5-72 来说明
（1）初始情况，rwnd=600，ack=301
（2）rwnd=600，ack=401，接收窗口前沿前移这是允许的。
（3）rwnd=500，ack=401，接收窗口前沿不动是允许的。
（4）rwnd=500，ack=501，接收窗口前沿前移是允许的。
（5）rwnd=300，ack=501，接收窗口前沿后退是不允许的，（1）中发送方接收到rwnd=600后就把swnd设为600，可发送数据为301~900，假设发送方发送了发送窗口内所有数据，此时接收方缩小了接收窗口rwnd=300，只接收501~800，则导致前前沿的一些数据801~900落在了接收窗口外，接收方只能丢弃这些数据。这种情况是必须避免的。
原文地址：https://blog.csdn.net/zhang_si_hang/article/details/143311870
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！