CC BY 4.0 (除特别声明或转载文章外)
如果这篇博客帮助到你,可以请我喝一杯咖啡~
随手标注:虚拟内存的意义:目前内存大小已经足够大,而虚拟内存的仍然有其存在的意义,它可以缩短程序的创建时间和加载时间,加快程序的响应速度
运输层的滑动窗口协议和数据链路层滑动窗口协议的区别
TCP滑动窗口采用字节流方式,每个数据段使用其第一个字节的编号作为序号。确认号为期待接收的下一个字节(下一个数据段)的序号。每个数据段一个编号。
数据链路层的序号和确认号是其在滑动窗口协议中的顺序号。每个帧一个编号。
超时定时器:TCP只有一个超时定时器,数据链路层每个帧都有一个。TCP只要有没收到的数据段,就一定会启动。如果超时没有收到,会选择序号最小的哪一个,重传那个数据段。如果还有未确认的,就会重启。这样保证每一个都可以轮到超时定时器。
用ack值和win值改发动窗口大小的方法
ack等于自身,win等于发送窗口大小sws。
快速重传
如果发送方收到一个数据段的3次重复的ACK(算上第一次,共四次),它就认为其后的数 据段(由确认号指出)已经丢失,在超时之前会重传该数据段, 这种方法称为快速重传(fast retransmit)。
延迟确认
采用延迟确认(delayed ACK)时,接收方并不在收到数据段立即进行确 认,而是延迟一段时间再确认。如果这个期间收到多个数据段,则只 需要发送一个确认。如果在这个期间接收方有数据帧要发往发送方, 还可以使用捎带确认(piggybacking) 。
大部分的系统 (Windows, Unix)的延迟确认时间为200毫秒。
选择性确认
选择性确认允许接收方把收到的数据块通过数据段的选项告知发送方,使发送 方不会重传这些数据块
TCP超时计算—Jacobson算法
流控制和拥塞控制
流控制:一个发送方,一个接收方(滑动窗口协议,调整发送窗口的大小) 拥塞控制:网络中的数据过多,网络层受不了,需要每个连接都减慢速度。
拥塞的表现
拥塞(a top-10 problem!):
- 简单来说: 「太多的主机发送太快太多的数据给网络处理」。 这不 同于流控制!
- 表现:
- 丢包 (路由器上缓冲区溢出)
- 长延迟 (在路由器缓冲区中排队)
拥塞控制方法
拥塞控制(Congestion Control)的两大类方法:
端到端的拥塞控制: 没有来自网络的明确的反馈 终端系统通过丢包和延迟推 导的拥塞 TCP协议的方法 网络辅助的拥塞控制: 路由器反馈给终端系统 用一个比特指出拥塞发生 (SNA, DECbit, TCP/IP ECN, ATM) 向发送方给一个明确的发 送速率。
TCP拥塞控制
超时或收到3个重复ack就认为丢包了,看作拥塞发生了。 TCP协议通过减少发送速率来控制拥塞。发送速率与发送 窗口大小有关: 发送速率 rate = SWS(Sending Window Size)/RTT 引入拥塞窗口变量CongWin来限制SWS。 SWS = Min(CongWin, AdvWin) TCP协议改变CongWin的三种机制: 加性增乘性减(AIMD) 慢启动(slow start) 在超时时间之后的保守方 加性增 (additive increase): 每个RTTCongWin增加1MSS,直到丢包 乘性减 (multiplicative decrease): 在丢包后CongWin减半