【计算机网络】【自顶向下课后习题-3】

 R1.  a）就叫这个协议未简单传输协议STP。在发送方，STP从发送进程接收不超过1196字节的数据块、目标主机地址和目标端口号。STP向每个块添加一个4字节的头，并将目标进程的端口号放在头中。STP然后将目标主机地址和结果段提供给网络层，网络层将段交付给目的主机的STP，目的主机基于STP检查段中的端口号，从段中提取数据，并将数据传递给由端口号标识的进程。

b）段现在有两个头字段：源端口字段和目标端口字段。在发送方，STP接受不超过1192字节的数据块、目标主机地址、源端口号和目标端口号。STP创建一个段，其中包含应用程序数据、源端口号和目标端口号。然后，它将段和目标主机地址提供给网络层。在接收到段后，接收主机上的STP给出应用程序的应用程序数据和源端口号。

c）不，传输层不需要在核心中做任何事。传输层“存活”在最终系统中。

R2.  a）略（答案就是信从发送方到接收方的过程）

b）不需要，邮件服务器不必打开信封，它只需要检查信封上的地址。

R3.源端口号y和目标端口号x

R4.应用程序开发人员可能不希望其应用程序使用TCP的拥塞控制，这会在拥塞时限制应用程序的发送速率。通常，IP电话和IP视频会议应用程序的设计者选择在UDP上运行他们的应用程序，因为他们希望避免TCP的拥塞控制。另外，有些应用程序不需要TCP提供的可靠数据传输。

R5.由于大多数防火墙都被配置为阻止UDP通信，因此使用TCP进行视频和语音通信可以让通信通过防火墙。

R6.是的。应用程序开发人员可以将可靠的数据传输放到应用层中协议。然而，这需要大量的工作和调试。

R7.是的，两个段将指向同一个套接字。由于UDP报文结构中没有IP地址（UDP中只有源端口号和目标端口号），对于每个接收到的段，在套接字接口上，操作系统将为进程提供IP地址，以确定各个段的来源 。

R8.对于每个持久连接，Web服务器创建一个单独的“连接套接字”。每个连接套接字被标识为具有四个元组：源IP地址、源端口号、目标IP地址、目标端口号。当主机C接收和IP数据报，它检查数据报/段中的这四个字段确定哪个套接字应该通过TCP段的有效负载。因此，来自A和B的请求通过不同的套接字。这两个参数的标识符用于目标端口的套接字具有80，但是，这些套接字的标识符源IP地址的不同值。与UDP不同，传输层通过时TCP段对应用程序进程的有效负载，它不指定源IP地址，因为这是由套接字标识符隐式指定的。

R9.  RDT（可靠数据传输协议）

接收机需要序列号来确定到达的数据包是包含新数据还是是重传。

R10.处理通道中的损失。如果在该分组的计时器持续时间内未接收到发送分组的ACK，则假定该分组（其ACK或NACK）已经丢失。因此，分组被重传。

R11.在RDT 3.0协议中仍然需要计时器。如果知道往返时间，那么唯一优势是，发送方肯定知道数据包或数据包的ACK(或NACK）已经丢失，而实际情况是，在计时器过后，ACK（或NACK)可能仍然在发送方的途中。然而，要检测丢失，对于每个包，一个持续时间不变的定时器仍然需要。

R12.a)第一个分组毁掉后，后面的分组都不被接收方接收。发送方隔一段时间后重发这五个分组。

b)ACK丢失不会触发任何重传，因为回退N步使用累积确认。

当一个包丢失时，回退N步重新传输之后的所有包，而选择重传只重新传输丢失的包。在确认ACK丢失的情况下，选择重传收到重复的包后发送一个反复的ACK，而回退N步使用累积确认，因此重复的ACK是不必要的。

c）发送者无法发送第六个数据包，因为发送窗口大小固定为5。

R13.当一个包丢失时，回退N步重新传输之后的所有包，而选择重传只重新传输丢失的包。在确认ACK丢失的情况下，选择重传收到重复发包后发送一个重复的ACK，而回退N步使用累积确认，因此重复的ACK是不必要的。

R14. a）错   

b）rwnd（接收窗口，即缓存中的那块空闲空间）cwnd（拥塞窗口）

空间是随着时间变化的，所以rwnd是动态的。

c)对   d)错    e)对    f)错    g)错    （f,g有点不理解）

R15.   a）20 bytes     b）ACK number=90

R17.R/2

R18. ssthresh（慢启动阈值），被用来确定是用慢启动还是用拥塞避免算法来控制数据传送。

错的，不是设置为原来慢开始的一半，而是设置为拥塞窗口的当前值的一半。

P1. e）可能相同

f）不能相同（可能你想到并行连接，并行连接的源端口号是不同的）

P3.

 结果取反：11010001

接收方将带有该反码的4个8比特字节求和，如果结果为全1，就说明没出问题。

1比特的差值可以检测出来，但2比特差可能检测不出来：比如第一个8比特字节的最后一个字节由1变为0，第二个8比特字节的最后一个字节由0变为1，这样求和取反就会得到和正常情况相同的结果。

P4.c)第一个字节=01010100，第二个字节=01101101 （同时翻转第5个比特位）（？）

01010100和01101101相加等于11000001你看和原来的01011100，01100101相加后一样。

P5.不，接收方不能完全确定没有发生任何位错误。比如上面两道题就是例子。这是因为计算数据包的校验和的方式。如果包中两个16位字的对应位（相加在一起）是0和1，那么即使这些位分别翻转到1和0，和仍然是保持不变。因此，接收方计算的1s补码也将是相同的。这就意味着，即使存在传输错误，校验和也将进行验证。

P6.

假设发送方处于“从上面等待呼叫1”状态，而接收方处于“从下面等待1”状态。

发送方发送一个序列号为1的数据包，并转换为“等待ACK或NAK 1”，等待ACK或NAK。

现在假设接收方正确地接收序列号为1的数据包，发送一个ACK，然后转换为状态“从下面等待0”，等待序列号为0的数据包。

但是，ACK已经损坏。当rdt2.1发送方获得顺坏的ACK时，它用序列号1重新发送数据包。然而，接收方正在等待序列号为0的数据包，并且总是在没有得到序列号为0的数据包时发送NAK。

因此，发送方将始终发送一个序列号为1的数据包，而接收方将始终锁定该数据包。也不会从那个状态继续。

P7.要想最好回答这个问题，首先考虑一下为什么我们需要序列号。我们看到发送方需要序列号，是为了使接收方能够判断数据包是否是已经接收到了数据包的副本。

而在ACK 的情况下，发送方接收的ACK不需要带有序列号，因为发送方不需要ACK上的序列号判断是否检测到重复的ACK。

对于rdt3.0接收器来说，一个重复的ACK是显而易见的，因为当它接收到原始ACK时，它会转换到下一个状态。重复的ACK不是发送方需要的ACK，因此会被rdt3.0发送方忽略。

P8.协议rdt3.0的发送方与协议2.2的发送方不同，因为已经添加了超时。我们已经看到，超时的引入增加了在发送方到接收方数据流中重复数据包的可能性。然而，协议rdt2.2中的接收方已经可以出来重复的数据包。（弱国接收方发送丢失的ACK，然后发送方重新传输旧数据，则rdt2.2中的接收方重复出现）。因此，协议rdt2.2中的接收器也将作为协议rdt3.0中的接收器工作。

P9.下图显示了损坏的数据和损坏的ACK的场景。

一开始老是看不明白为什么数据M0错了，返回的是A1，哎呀一下子反应不过来，难不成还返回A0吗，返回A0那不就说明M0没错嘛，这里不都是只用0101的嘛，所以0的上一个也是1呀，所以返回的是M0的上一个呀，返回上一个的ACK不就说明这个M0数据包有问题嘛。

 P10.添加一个计时器，它的值大于已知的往返传播延迟。我们将超时事件添加到“等待ACK或NAK 0”和“等待ACK或NAK 1”状态。如果发生超时事件，则重新发送最近发送的数据包。让我们看看为什么这个协议仍将与rdt2.2接收器一起工作。

·假设超时是由于丢失的数据包引起的，即发送方到接收方通道上的数据包。在这种情况下，接收机从未接收到先前的传输，并且从接收机的角度来看，如果接收到超时重传，它看起来与接收到的原始传输完全相同。

·假设现在一个ACK丢失了。接收器最终会在超时时重新发送数据包。但是，重传与ACK被混淆时的动作完全相同。因此，发送者的反应与损失是一样的，就像混乱的ACK一样。rdt2.1接收器已经可以处理混淆的ACK的情况。

P11. 注意读题，这些分组是在比如等待0结果没等到才会发生分组（ACK,1,checksum）

 所以如果删除这些分组，那么就会造成死锁。

发送方：发送了包0后，进入等待ACK状态。

接收方：等待0状态，收到了一个损坏的包。如果什么都不做，那么就会一直在这个状态等待。

P12.（这个有点不理解）

该协议仍在工作，因为如果重新传输将是如果接收到错误的分组实际上已经丢失（并且从接收机的观点来看，它从不知道这些事件中的哪一个发生，如果有的话）。

为了解决这个问题背后的更微秒的问题，必须允许过早的发生超时。在这种情况下，如果分组的每个额外副本被确认并且每个副本接收的额外ACK导致要发送的当前分组的另一个额外拷贝，发送分组N的次数将随着N接近无穷大而不受限制地增加。

P13. rdt3.0就被叫做比特交替协议

（看不懂这道题）

P14.不会更好。如果在偶尔发送数据的情况下只使用NAK，那么接收方检测到包x丢失的途径只能是：接收了x-1号包后，再接收到了x+1号包，这时，接收方才知道x号包丢失了。（刚开始一直想不明白，x错了不是当场给出NAK了吗，为啥说要x+1才能知道，哎呀人说的是丢失我想的是包出错，丢失了你接收方都没见过即都没接收过x你给啥NAK，所以呀是x+1接着来才能知道x丢失了）又由于发送方发送间隔比较长，那么x号包得经过好久才能收到重传。所以在重传速度方面体现不了优势，况且还存在NAK丢失的情况，接收方就永远收不到目标包的重传了。

如果要发送大量数据，而且很少丢包，那么只使用NAK要比ACK好些，只有当接收方收到损坏的分组时才发送NAK。

P15.发送一个分组耗时12ms，如果要满足利用率为90%，那么*12ms/30us=90%，即使得n为2451个最大报文段长度。

P16.（没看懂）

可以提升信道利用率，发送方会发送更多管道数据到链路中。

有安全隐患，如果数据包丢失了，发送方不知道如何重发。

P17-21完头晕

P22.（这道题我不怎么理解）

a）可能是[k-3，k]到[k，k+3]

b）[k-4，k-1]

P23.下图是图3-27的问题

 1/2的序列长度

P24.  a）对，假设发送方的窗口为3，发送了1，2，3.接收方收到后，给出了3个ACK，可能中途出现了拥塞，ACK迟到了，于是发送方重发了1，2，3。这时之前的3个ACK到了发送方，发送方将窗口移到4，5，6，之后重发的3个包对应的ACK也收到了，这就落到了窗口之外。

b）对，和a）一样

c）对     d）对

在发送窗口和接收窗口都为1时，GBN和SR与比特交替协议是等价的。

P25.  a）TCP段里要放一些不必要的东西（序号、确认号），UDP段里能放更多的有效载荷。

b）对于TCP，由于流量控制和拥塞控制，从应用程序将数据写入其发送缓冲区到将数据提供给网络层之间可能存在显著的延迟。UDP由于流控制而没有延迟

 P26.（不理解）

P27.  a）是这样子的，序列号是127，则说明前面发送过1-127了，所以127是还没包括第一段的，而第一段是80字节，所以第一段发送后即第二段发送时序列号是127+80=207，源端口号还是302，目的端口号还是80。

b）确认号207，源端口号80，目标端口号80。

c）如果第二个报文段在第一个报文段之前到达，在第一个到达报文段的确认当中，确认号为127，表示它仍然在等待字节127和以后。

d）注意哈最后接收到重发后的127,80byts，返回的ACK是ACK247而不是207哟，因为在此之前已经接收到ACK247了，就说明247之前的都接收到了，所以是返回ACK247而不是207。

P28.（看不懂答案）

答案：由于链路容量只有100Mbps，所以主机A的发送速率最多可达100Mbps。不过，之际A向接收缓冲区发送数据的速度比主机B从缓冲区中删除数据的速度要快。接收缓冲区的填充速率约为40Mbps。当缓存器已满时，主机B通过设置RcvWindow=0向主机A发送停止发送数据的信号。然后主机A停止发送，知道接收到RcvWindow>0的TCP段为止。主机A将作为RcvWindow的值的函数反复停止并开始发送从主机B接收。平均而言，主机A向主机发送数据的长期速率b作为此连接的一部分，不超过60Mbps。

P29.

这里补充一些SYN洪泛和TCP连接的知识。

SYN洪泛，利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。

问题就出在TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或者掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的（第三次握手无法完成），这种情况下服务器端一般会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级（大约是30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟不是什么很大的问题，但是如果一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源-数以万计的半连接，即使是简单的保持并遍历也会消耗很多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。导致服务器端忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求（毕竟客户端的正常请求比率非常小），此时从正常客户的角度看来，服务器失去响应，这种情况我们称作：服务器端受到了SYN Flood攻击（SYN洪水攻击）。

接下来我们从TCP连接建立的过程说起：

第一步，请求端（客户端）发送一个包含SYN标志的TCP报文，SYN即同步，同步报文会指明客户端使用的端口以及TCP连接的初始序号；

第二步，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK的报文，表示客户端的请求被接受，同时TCP序号被加1。

第三步，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。

那它是这样防止这个SYN洪泛的呢？

现在有一种有效的防御系统，称为SYN cookie它们被部署在大多数主流操作系统中

·当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法的用户还是一个SYN洪泛攻击的一部分。因此服务器不会为该报文段生成一个半开连接。相反，服务器生成一个初始TCP序列号，该序列号是SYN报文段的源和目的IP导致与端口号以及仅有该服务器知道的秘密数的复杂函数（散列函数）。这种精心制作的初始序列号被称为“cookie”。服务器则发送具有这种特殊初始序列号的SYNACK分组。重要的是，服务器并不记忆该cookie或任何对应于SYN的其它状态信息

·如果客户是合法的，则它将返回一个ACK报文段。当服务器收到该ACK，需要验证该ACK是与前面发送到某些SYN相对应的。前面讲过对于一个合法的ACK，在确认字段中的值等于SYNACK字段（此时为cookie值）中的值加1.服务器则将使用该报文段中的源和目的IP导致与端口号以及秘密数运行相同的散列函数，如果该函数的结果加1与客户的SYNACK中的确认（cookie）值相同的话，服务器认为该ACK对应于较早的SYN报文段，因此它是合法的，服务器则生成一个具有套接字的全开连接

·在另一方面，如果客户没有返回一个ACK报文段，则初始的SYN并没有对服务器产生危害，因为服务器没有为它分配任何资源。

回到这道题：

a）服务器使用特定的初始序列号（从源和目的地IP和端口的散列中获取）来低于SYN洪水攻击

b）不。半开连接是不可能的，因为在建立完整连接之前，使用SYN cookie的服务器不会维护任何连接的连接变量和缓冲区。为了建立完全开放的连接，估计则应该从攻击者那里知道与（伪造的）源IP地址对应的特定初始序列号。这个序列号需要每个服务器使用的“秘密”编号，而攻击者不知道这个秘密号码，它无法猜测初始序列号。

c）不，服务器可以简单地计算这些初始序列号时加上时间戳，并为这些序列号选择一个存活值，即使攻击者重播，也可以丢弃过期的初始序列号。

后面的知识学的不好，看题目都很懵，待再重看书籍这部分时再做剩下的这些题