博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
网络协议系列之八:TCP差错控制
阅读量:7014 次
发布时间:2019-06-28

本文共 1022 字,大约阅读时间需要 3 分钟。

TCP的差错控制主要使用校验和确认超时重传这三个工具进行差错控制。

校验和主要用来检验数据报文是否受到损伤。如果校验和无效,报文就会在终点被丢弃。

确认是接收端用来证实确实收到了报文,在TCP中,使用的是累计确认,接收端会告诉发送端其下一个希望接收的字节编号。

超时重传是差错控制的核心。实际上当发送端发送一段字节的数据后,会把这个报文段保存在一个队列中,并启动一个计时器,这个计时器也叫RTO(重传计时器),若计时器超时发送端还没有收到接收端的ACK确认,那么发送端会把队列中的首部报文重新发送。

当然RTO的值是动态的,与RTT有关,RTT是一个报文自发送到接收端返回确认的时间。如果RTO的值不是很大。使用简单的超时重传也就够了,但是如果RTO的值足够大,再使用超时重传就不太切实际了。

TCP是这样处理的:如果发送端连续收到三个重复的超时重传ACK,那么发送端可以不必等待计时器到达而选择马上重传报文段,这种机制也称为快重传

还有一点要注意的是:接收端接收的数据可能不是按序到达的,当接收到不是按序到达的数据的时候,接收端不会丢弃该数据,而是先保存起来,并立即发送一个ACK,当其他失序的报文都到达后才把数据交付给接收进程。由于当RTO的值比较大的时候,TCP会采用快重传机制重传丢失的报文段,所以当发送完一个报文段后,如果发送端连续接收到3个重复的ACK确认的时候就会马上重传报文段,即使RTO计时器还没有超时。下图是快重传的一个流程图:

快重传

针对这个流程图说明快重传的机制:

  1. 当发送端收到接收端ackNo=301的报文的时候,继续传输起始编号为301长度为100字节的数据,但是这个报文段丢失了,而发送端继续传输了字节编号从401到500的字节,接收端于是收到了失序但无差错的报文段,接收端把这段报文保存起来,并在接收窗口隔一个空隙,表示还有失序的报文没有到达,并给发送端发送ackNo=301的报文,表示起始编号为301的字节数据我这边还没有收到,你那边注意一下,准备重传吧
  2. 发送端收到这个报文后,仍然继续传输起始编号为501到600的字节,接收端接收到后保存起来,并重新发送ackNo=301的报文
  3. 发送端继续发送起始编号为601到700的字节,接收端收到后保存起来,并再次发送ackNo=301得的报文,由于这已经是第四次收到重复的ACK确认了,虽然这时RTO计时器还没有到达,但是发送端立即发送起始编号为301的字节数据。

转载地址:http://lmhtl.baihongyu.com/

你可能感兴趣的文章
撬动智能家居市场 智慧家庭“最强大脑”被激活
查看>>
走向5G:爱立信携手新加坡电信为物联网部署4G LTE网络
查看>>
DBA必备技能:通过truss跟踪解决监听无法启动案例
查看>>
GNOME 基金会签署用户数据宣言 2.0
查看>>
《产品设计与开发(原书第5版)》——3.4 步骤1:确立章程
查看>>
《Adobe Illustrator CS6中文版经典教程(彩色版)》—第1课1.5节探索“控制面板”...
查看>>
MySQL 问题分析:ERROR 1071 : Specified key was too long;max
查看>>
我的友情链接
查看>>
nginx tcp代理
查看>>
Linux日志分析常用命令-备忘
查看>>
sybase笔记 3712错误
查看>>
Zabbix 监控windows服务器监控闪断zabbix_get [12577]: Timeout while executing operatio
查看>>
MicrosoftRemoteDesktop Mac版
查看>>
EXCEL拼sql语句
查看>>
分析称明年第二季度平板出货量超PC
查看>>
Device eth0 has different MAC address than expected, ign
查看>>
DXP,AD不用新建PCB完美解决 Unknown Pin 和Failed to add class member 问题
查看>>
web.xml <context-param>只能放一对<param-name>和<param-value>
查看>>
html测验 --(w3cshool)
查看>>
XP对Win7说:哥们,你的U盘我打不开啊
查看>>