停止-等待协议:发送方发送一个报文段后立即停止,
接收方正确收到后发送一ACK(Acknowledgement,即确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误)
每发送一个报文段就要停下等待确认。
现在考虑各种突发情况:当接收方发现报文段出错后,它要返回一个否定确认(NAK),
发送方收到NAK->重传。;当发送超时时,接收方收不到自然也就不会发送NAK,
此时有:发送方每发送完一个报文段,就开始计时,超时后仍没有收到ACK就重传;
当发送的成功到达,但是ACK在途中丢失:发送方察觉超时:又重传。。。(以上:简单表述)
下面再讨论细节问题:
1)接收方为了发现报文段出错,必须采用某种检错技术
2)因为发送方启用了计时技术,所以NAK也就没必要了。
3)确定合理的超时时间:至少要大于RTT,但是还要综合网速情况。
4)不能让接收方收到重复的报文,所以要定序:发送方给报文段添加序号。
停止-等待协议的效率太低。改进措施是在收到ACK之前不等待,连续发送,所以让ACK带上 相应的 与发送报文序号 对应的序号,
以此来区分哪个ACK时哪个报文段的。ACK的这个序号就叫确认号。
在TCP中,确认号是指这个确认号之前的数据都已经成功收到。
比如:接收方发送了确认号500表示500之前(1~499号)都已经成功收到啦~希望收到500号及其以后的报文段~
但是“500”这个数,不能太大,也不能太小,已发送且未确认的数据量达到一个限制值的时候,
要等待ACK的到来,不到不能再发送了。这个限制值叫做窗口。
比如说窗口是 :100字节,发出100字节后等待->收到ACK表示接受了70字节,
此时已发送未确认的数据量就是30 , 30<100,发送方还可以接着继续发送70字节的数据,这样又达到了窗口值100字节。如此反复。
直到所有数据都发送完毕。
------------------------------------------------------——-——————————————————————整理自《计算机网络》