(问题5-15：能否利用TCP发送端和接收端交换报文段的图来说明慢开始的特点？
答：慢开始的特点可以用下图来说明。
拥塞窗口cwnd的初始值是1（为方便起见，这里将拥塞窗口的单位设为报文段）。
以后每收到一个对新的报文段的确认，就将发送端的拥塞窗口cwnd加1。
可以看出，拥塞窗口cwnd按照指数规律增长。所谓“新的报文段”就是指“未被确认过的报文段”。由于报文段在因特网中传输时，有可能在某个路由器处滞留一段时间，但以后又被交付到接收端（重复交付）。接收端对每一个收到的无差错的报文段都可能给出确认。因此，对同一个报文段，发送端有可能收到几个重复的确认。但除了第一个确认可以使发送端拥塞窗口cwnd加1以外，对其余重复的报文段的确认都不能再使发送端拥塞窗口加1。
(问题5-16：对于拥塞避免是否也能够用发送端和接收端交换的报文段来说明其工作原理？
答：可以，但这只能是示意图。
因为在拥塞避免的开始，发送端的拥塞窗口swnd=ssthresh，这时可以发送好几个报文段。按照RFC2581文档，每经过一个往返时间RTT，拥塞窗口就增加一个MSS的大小（以字节为单位）。
在我们讨论原理时，以报文段个数作为窗口单位较为方便，因此在图中每经过一个RTT，发送端拥塞窗口swnd就在ssthresh的基础上加1。
在图中将发送端发送报文段用一个粗箭头表示（因为这里面包含有许多个报文段，很难一个个画出），确认报文段也用一个粗箭头表示（这也可能有许多个确认报文段），因此RTT也是概念性的往返时间。
正因为RTT无法很严格地画出，因此在图中左边增加一个注释，即“收到对所有报文段的确认”。这里假定收到对所有报文段的确认所需的时间就是RTT。
(问题5-17：TCP连接很像一条连接发送端和接收端的双向管道。当TCP在连续发送报文段时，若要管道得到充分的利用，则发送窗口的大小应怎样选择？
答：我们可以用下面的图来说明这一问题。
图中在发送端和接收端之间的两个白色长条表示TCP全双工通信的发送管道和接收管道。管道是对信道的一种抽象，便于讨论问题（可以不涉及下层互连网络的细节）。
假定在t=0时发送端使用慢开始算法来发送报文段，因此在t=0时只能发送一个报文段（图中标有1的绿色长方条就代表报文段1）。图中的时间都是按离散的时间单位表示。
为简化分析，我们还假定，发送窗口仅由发送端的拥塞窗口来确定，接收端不对发送窗口加以限制。
假定在t=1时，报文段1的第一个比特正好走完四分之一的管道，同时该报文段的最后一个比特正好发送完毕。
t=4，报文段1的前沿到达接收端。
t=5时，接收端将报文段1接收完毕。
假定接收端立即发送确认报文段。我们所用的标记是：对报文段n的确认报文段我们用具有标记n的红色小长方条表示。
t=9，对报文段1的确认的前沿到达发送端。
t=10，发送端将发送窗口加1变为2（可以发送报文段2和3），并开始发送报文段2（这一步图中省略了，没有画出）。
t=11，报文段2走完发送管道的四分之一，发送端开始发送报文段3。
t=12，报文段2和3填满发送管道的一半。
t=14，报文段2的前沿到达接收端。
t=15，接收端收完报文段2，并发送对报文段2的确认。
t=16，接收端收完报文段3，并发送对报文段3的确认。
t=19，对报文段2的确认前沿传播到发送端。
t=20，发送端收到对报文段2的确认，将发送窗口加1变为3（可以发送报文段4,5和6），并开始发送报文段4（这一步图中省略了，没有画出）。对报文段3的确认的前沿也在这个时间传播到发送端。
再以后的过程我们用下面的另一张图来说明。
t=21，发送端收到对报文段3的确认，将发送窗口再加1变为4（可以发送报文段4,5,6和7），并开始发送报文段5。此时，报文段4已完全进入发送管道，前沿到了管道的四分之一处。
以后的过程读者自己都可以看懂。这里只再提几点。
发送端每收到一个对没有确认过的报文段的确认，就将发送窗口加1。因此在陆续收到确认4~7后，将发送窗口加4，即增大到8，可以连续发送报文段8~15。
管道空间是有限的。从图中表示的例子可以看出，这样的管道至多可容纳4个报文段。当发送窗口很小时，管道在大部分时间内是比较空的（见前面的第一张图）。这说明在TCP连接中传输数据的效率比较低。
当发送窗口增大时，管道逐渐被填满。可以看出，在t=34~38时，发送管道一直是被填满的，这说明发送管道被利用得很充分。因为报文段的传输需要时间，因此对报文段的确认总是会滞后一段时间。上面的例子表明，在单方向发送报文段（另一个方向发送确认）的情况下，发送管道和接收管道往往不能同时被充分利用（除非发送窗口的数值较大）。但如果双向都能发送数据报文段，那么发送管道和接收管道就都能够被利用得较充分。
我们还可看出，接收管道（即接收端发送确认报文段的管道）在任何情况下都没有填满。这是因为确认报文段很短，只需很短的时间就可发送出去。但接收一个数据报文段需要较多的时间，这就造成确认报文段不可能连续地从接收端发送出去。
(问题5-18：假定在一个互联网中，所有的链路的传输都不出现差错，所有的结点也都不会发生故障。试问在这种情况下，TCP的“可靠交付”的功能是否就是多余的？
答：不是多余的。TCP的“可靠交付”功能在互联网中起着至关重要的作用。
至少在以下所列举的情况下，TCP的“可靠交付”功能是必不可少的。
每个IP数据报独立地选择路由，因此在到达目的主机时有可能出现失序。
由于路由选择的计算出现错误，导致IP数据报在互联网中兜圈子。最后数据报首部中的生存时间TTL的数值下降到零。这个数据报在中途就被丢弃了。
在某个路由器突然出现很大的通信量，以致路由器来不及处理到达的数据报。因此有的数据报被丢弃。
以上列举的问题表明了：必须依靠TCP的“可靠交付”功能才能保证在目的主机的目的进程接收到正确的报文。
(问题5-19：TCP是通信协议还是软件？
答：协议与实现协议的软件之间的区别，类似于编程语言的定义与编译器之间的区别。与编程语言的情况类似，编程语言的定义与编程语言的实现之间的区别有时也会比较模糊。大家与TCP软件打交道的机会远远比与TCP协议规范打交道的机会要多，因而会很自然地把某个协议的具体实现当作是协议的标准。尽管如此，我们必须明确地区分两者。
总之，TCP是通信协议，而不是一个软件。
(问题5-20：在计算TCP的往返时间RTT的公式中，本教材过去的版本是取(=7/8。但现在的新版本是取(=1/8。为什么会有这样大的改变？
答：过去的版本是参考有的国外教材，这个教材上把RTT的计算公式写为：
平均往返时延RTT((((旧的RTT)((1(()((新的往返时延样本)
而取(=7/8。
现在的新版本是考虑到最好和RFC文档的写法一致，这样可能会更加便于读者查阅RFC文档。现在的RTT计算公式是：
新的RTTS((1(()((旧的RTTS)((((新的RTT样本)
而取(=1/8。但这两种不同的写法在实质上并无不同，得出的计算结果是一样的。
另外有些改动的地方是：
(1)RTT以前译为“往返时延”，现在改为“往返时间”。这样更加准确一些，因为RTT的后面一个T是Time，应当译为“时间”。以前用的“往返时延”来自“Round-TripDelay”。
(2)以前没有用RTTS这个符号，是为了使符号不要太多。现在看来，多用一个符号可能会更清楚一些（RFC文档也有这个符号，但他们使用的文本文件，不便于用下标，因此他们用的符号是SRTT，表示SmoothedRTT（平滑的RTT）。
11122233331t=1t=2t=3t=41t=6t=7t=8t=9111发送端接收端22222发送端接收端t=11t=12t=13t=14t=15t=17t=18t=193331t=52t=163158889991010101111111212121213131314148910114444555666777567t=21t=22t=23t=244t=25t=27t=28t=29444发送端接收端发送端接收端t=30t=31t=32t=33t=34t=36t=37t=3888855566756767799104567t=268910t=3511发送端接收端cwnd=1，发送M0确认M0收到“对M0的确认”cwnd=2,发送M1~M2确认M1~M2收到“对M1~M2的确认”cwnd=4,发送M3~M6确认M3~M6M0M1~M2M3~M6tM7~M14收到“对M3~M6的确认”cwnd=8,发送M7~M14发送端接收端当cwnd=ssthresh时开始“拥塞避免”发送确认收到对所有报文段的确认cwnd=ssthresh+1发送确认t收到对所有报文段的确认cwnd=ssthresh+2收到对所有报文段的确认cwnd=ssthresh+3收到对所有报文段的确认cwnd=ssthresh+4发送确认发送确认可发送N个报文段可发送N+1个报文段可发送N+2个报文段可发送N+3个报文段可发送N+4个报文段发送确认RTTRTTRTTRTTRTT |
|
