蒋yj老师yyds！
答案自制，仅供参考，欢迎质疑讨论
问题一览
-
-
- 传输层思考题
-
-
- P2P和E2E的区别
- 使用socket的c/s模式通信，流控如何反映到编程模型
- 三次握手解决什么问题
- 举一个两次握手失败的例子
- 为什么链路层是两次握手而非三次？
- 两军问题在TCP实践中怎么解决
- 传输层怎么处理流控
- 传输层拥塞控制算法的四个基本目标的含义
- AIMD解决什么问题
- TCP中如何调节某个TCP连接的发送速率并体现AIMD思想
- 了解TCP拥塞控制算法的区别
- TCP Tahoe和TCP Reno的区别
- TCP选项NACK和SACK是如何提高效率的
- 链路层丢包率10%会对TCP有什么影响
- 现代互联网TCP可以做到效率接近90%吗
- 两台主机间所有连接线路的链路层误码率均为0%，TCP就不会出现重传了吗
- 理解TCP报头各个字段的用途
- TCP报头Window最大取值65535，是不是意味着接收窗口最大只能说65535字节
- Nagle解决了什么问题？优缺点
- Clark解决了什么问题
- TCP超时定时器是如何动态确定的
- 当接收方缓冲区满，TCP通过什么机制通知发方别发了
-
-
传输层思考题
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 大佬认定的，没有为什么
S R T T = α S R T T 旧 + ( 1 − α ) R T T 本次 SRTT = \alpha SRTT_旧 + (1-\alpha) RTT_{本次} SRTT=αSRTT旧+(1−α)RTT本次
R T T V A R = β R T T V A R 旧 + ( 1 − β ) ∣ S R T T − R T T 本次 ∣ RTTVAR = \beta RTTVAR_旧 + (1-\beta)|SRTT-RTT_{本次}| RTTVAR=βRTTVAR旧+(1−β)∣SRTT−RTT本次∣
R T O = S R T T + 4 × R T T V A R RTO = SRTT + 4 × RTTVAR RTO=SRTT+4×RTTVAR
当接收方缓冲区满，TCP通过什么机制通知发方别发了
- 捎带window size
如果随后收方缓冲区空闲，收方如何通知
- 窗口更新段
- 窗口更新报文段是一个不包含数据的纯ACK(只有ACK标志位被置位), 用于通告发送端可以继续发送数据，纯ACK不会被重传, TCP必须采取相应措施来处理这些丢包
如果这个通知丢失，会导致发方长久等待吗
TCP对此主要有两个设计来避免死锁：
发送端可以发送1字节的段，以便强制接收端重新宣告下一个期望的字节和窗口大小。这种
数据包称为窗口探测（window probe ）。
持续计时器（persistence timer ）的设计。当持续计时器超时后，发送端给接收端发送一个探询消息。接收端对探询消息的响应是将窗口大小告诉发送端。如果它仍然为0 ，则重置持续计时器，并开始下一轮循环。如果它非0 ，则现在可以发送数据了。