北邮《计算机网络》蒋老师思考题及答案-传输层

蒋yj老师yyds！
答案自制，仅供参考，欢迎质疑讨论

传输层思考题

P2P和E2E的区别

• 相邻 or 有子网

使用socket的c/s模式通信，流控如何反映到编程模型

• 编程时cs双方自己定义了buffer

三次握手解决什么问题

• 子网丢/重/乱的问题

举一个两次握手失败的例子

• 链路上突然出现A对B握手的一个Seg（之前遗留的），B回复A，此时B已经建立连接，而A对此事毫不知情，这就产生了一个half-open的连接

为什么链路层是两次握手而非三次？

• 因为链路层是p2p的，不会重复和乱序

两军问题在TCP实践中怎么解决

• 对于先断开的一方，收到对方的FIN后发送ACK并等待一个TIME WAIT，在这个时间之内，如果对方继续发来FIN，那么继续回ACK。超时则关闭。对于后断开的一方，如果没收到ACK，就一直发送。
• 如果产生了半开，那么经过一个固定时长自动关闭。

传输层怎么处理流控

• AIMD

传输层拥塞控制算法的四个基本目标的含义

• 预防
• 高效
• 公平
• 收敛

AIMD解决什么问题

• 快速找到公平点

TCP中如何调节某个TCP连接的发送速率并体现AIMD思想

• 慢启动算法

了解TCP拥塞控制算法的区别

• ACK Clock 确认时钟：通过使用一个确认时钟， TCP平滑输出流量和避免不必要的路由器队列。
• Slow Start 慢启动：每个RTT内发送的数据包数目指数增长，使用确认时钟将发送端的传输速率与网络路径相匹配
• Add Increase：当slow start后超过了slow start threshold， TCP 就从慢速启动切换到线性增加，每个RTT内，收一ACK发出一包，最后一个ACK连发两包。
• Muilt Decrease: 当收到三个重复ACK后，cwin减半（快恢复）
• Fast retransmission：当收到三个重复ACK后，门限减半，慢启动
• Fast recovery：门限减半，cwin减半（具体做法：确认时钟）

TCP Tahoe和TCP Reno的区别

• Tahoe用的fast retransmission

• Reno用的fast recovery

TCP选项NACK和SACK是如何提高效率的

• SACK (Selective ACKnowledgement) 选择确认：该确认列出了3个己接收的字节范围。有了这个信息，发送端在实现拥塞窗口时可以更直接地确定哪些数据包需要重传，并跟踪那些还在途中的数据包。
• NACK ``：

链路层丢包率10%会对TCP有什么影响

• TCP会认为子网拥塞，从而把发送速度降到很慢

现代互联网TCP可以做到效率接近90%吗

• 能，《计算机网络(第5版)》 Tanenbaum & Wetherall 著 严伟 潘爱民 译 Page 456
  

两台主机间所有连接线路的链路层误码率均为0%，TCP就不会出现重传了吗

• 路由器可能发生拥塞，也有可能选择不合适的路由，导致超时

理解TCP报头各个字段的用途

• 实验二中做了分析，此处略

TCP报头Window最大取值65535，是不是意味着接收窗口最大只能说65535字节

• 不是，选项（ Options ）字段提供了一些可选项。P431
  

Nagle解决了什么问题？优缺点

• 用粘包的方式避免T层每次只传很少的字节导致各层开销占比很大
• 优点：
• 减小开销占比
• 实现了self-clocking: ACK返回的越快，数据传输地也就越快
• 使得单位时间内发送的报文段的数目更少
• 缺点：某些消息不及时传送，对于应用层来说，响应变慢

Clark解决了什么问题

• 愚蠢窗口（Silly Window Syndrome）

TCP超时定时器是如何动态确定的

• 注意是超时定时器

• 几个公式，由Jacobson贡献，第三个式子的系数4是 J 大佬认定的，没有为什么

• $$SRTT=\alpha SRT{T}_{旧}+(1-\alpha )RT{T}_{本次}$$

• $$RTTVAR=\beta RTTVA{R}_{旧}+(1-\beta )|SRTT-RT{T}_{本次}|$$

• $$RTO=SRTT+4\times RTTVAR$$

当接收方缓冲区满，TCP通过什么机制通知发方别发了

• 捎带window size

如果随后收方缓冲区空闲，收方如何通知

• 窗口更新段
• 窗口更新报文段是一个不包含数据的纯ACK(只有ACK标志位被置位), 用于通告发送端可以继续发送数据，纯ACK不会被重传, TCP必须采取相应措施来处理这些丢包

如果这个通知丢失，会导致发方长久等待吗

• TCP对此主要有两个设计来避免死锁：

• 发送端可以发送1字节的段，以便强制接收端重新宣告下一个期望的字节和窗口大小。这种

  数据包称为窗口探测（window probe ）。

• 持续计时器（persistence timer ）的设计。当持续计时器超时后，发送端给接收端发送一个探询消息。接收端对探询消息的响应是将窗口大小告诉发送端。如果它仍然为0 ，则重置持续计时器，并开始下一轮循环。如果它非0 ，则现在可以发送数据了。