确认应答机制与超时重发机制【TCP原理(笔记一)】

简介: 确认应答机制与超时重发机制【TCP原理(笔记一)】

通过序列号与确认应答提高可靠性

在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK(ACK(Positive Acknowled-gement)意指已经接收。) )。

确认应答机制的基本原理

1.发送方将数据分割成称为TCP段(TCP segment)的较小单元,并为每个段分配一个唯一的序列号。

2.发送方将这些TCP段发送给接收方,并启动一个定时器来跟踪每个已发送段的确认。

3.接收方收到TCP段后,将按序将它们重新组装成完整的数据流,并发送一个确认(ACK)给发送方。确认中包含接收到的最高序列号,表示该序列号之前的所有数据都已正确接收。

4.发送方在接收到确认后,会停止相应定时器,并继续发送下一个序列号的TCP段。如果发送方5.在定时器超时之前未收到确认,它将重新发送未确认的TCP段。

通常,两个人对话时,在谈话的停顿处可以点头或询问以确认谈话内容。如果对方迟迟没有任何反馈,说话的一方还可以再重复一遍以保证对方确实听到。因此,对方是否理解了此次对话内容,对方是否完全听到了对话的内容,都要靠对方的反应来判断。网络中的“确认应答”就是类似这样的一个概念。当对方听懂对话内容时会说:“嗯”,这就相当于返回了一个确认应答(ACK)。而当对方没有理解对话内容或没有听清时会问一句“咦?”这好比一个否定确认应答(NACK(NACK(Negative Acknowledgement)) )。

正常的数据传输

TCP通过肯定的确认应答(ACK)实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答,说明数据已经成功到达对端。反之,则数据丢失的可能性很大。


如图所示,在一定时间内没有等到确认应答,发送端就可以认为数据已经丢失,并进行重发。由此,即使产生了丢包,仍然能够保证数据能够到达对端,实现可靠传输。

数据包丢失的情况

未收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到,只是返回的确认应答在途中丢失。这种情况也会导致发送端因没有收到确认应答,而认为数据没有到达目的地,从而进行重新发送。如图所示。

确认应答丢失的情况

此外,也有可能因为一些其他原因导致确认应答延迟到达,在源主机重发数据以后才到达的情况也履见不鲜。此时,源发送主机只要按照机制重发数据即可。但是对于目标主机来说,这简直是一种“灾难”。它会反复收到相同的数据。而为了对上层应用提供可靠的传输,必须得放弃重复的数据包。为此,就必须引入一种机制,它能够识别是否已经接收数据,又能够判断是否需要接收。


上述这些确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现。序列号是按顺序给发送数据的每一个字节(8位字节)都标上号码的编号(序列号的初始值并非为0。而是在建立连接以后由随机数生成。而后面的计算则是对每一字节加一。) 。接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的序号作为确认应答返送回去。就这样,通过序列号和确认应答号,TCP可以实现可靠传输。

发送的数据

  • 序列号(或确认应答号)也指字节与字节之间的分隔。
  • TCP的数据长度并未写入TCP首部。实际通信中求得TCP包的长度的计算公式是:IP首部中的数据包长度-IP首部长度TCP首部长度。

重发超时如何确定

重发超时是指在重发数据之前,等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答,发送端将进行数据重发。那么这个重发超时的具体时间长度又是如何确定的呢?


最理想的是,找到一个最小时间,它能保证“确认应答一定能在这个时间内返回”。然而这个时间长短随着数据包途径的网络环境的不同而有所变化。例如在高速的LAN中时间相对较短,而在长距离的通信当中应该比LAN要长一些。即使是在同一个网络中,根据不同时段的网络拥堵程度时间的长短也会发生变化。


TCP要求不论处在何种网络环境下都要提供高性能通信,并且无论网络拥堵情况发生何种变化,都必须保持这一特性。为此,它在每次发包时都会计算往返时间(Round Trip Time也叫RTT。是指报文段的往返时间。) 及其偏差(RTT时间波动的值、方差。有时也叫抖动。) 。将这个往返时间和偏差相加重发超时的时间,就是比这个总和要稍大一点的值。


重发超时的计算既要考虑往返时间又要考虑偏差是有其原因。如图所示,根据网络环境的不同往返时间可能会产生大幅度的摇摆,之所以发生这种情况是因为数据包的分段是经过不同线路到达的。TCP/IP的目的是即使在这种环境下也要进行控制,尽量不要浪费网络流量。


17345d5fef9e4b50a49555f33bfbcb17.jpg

在BSD的Unix以及Windows系统中,超时都以0.5秒为单位进行控制,因此重发超时都是0.5秒的整数倍(偏差的最小值也是0.5秒。因此最小的重发时间至少是1秒。) 。不过,由于最初的数据包还不知道往返时间,所以其重发超时一般设置为6秒左右。


数据被重发之后若还是收不到确认应答,则进行再次发送。此时,等待确认应答的时间将会以2倍、4倍的指数函数延长。


此外,数据也不会被无限、反复地重发。达到一定重发次数之后,如果仍没有任何确认应答返回,就会判断为网络或对端主机发生了异常,强制关闭连接。并且通知应用通信异常强行终止。

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
Web App开发 弹性计算 编解码
最佳实践:如何扩展你的SRS并发能力?
当我们用SRS快速搭建了视频服务,业务也开始上线运行了,很快就会遇到一个问题:如何支持更多的人观看?如何支持更多的人推流?这本质上就是系统的水平扩展能力,SRS当然是支持的,而且有多种扩展的方法,这篇文章就就详细分析各种扩展的方案,以及各种方案的应用场景和优缺点。
3277 0
最佳实践:如何扩展你的SRS并发能力?
|
人工智能 网络协议 算法
5 分钟搞懂 ECN
5 分钟搞懂 ECN
3559 0
|
C# 前端开发
WPF中Style文件的引用——使用xaml代码或者C#代码动态加载
原文:WPF中Style文件的引用——使用xaml代码或者C#代码动态加载   WPF中控件拥有很多依赖属性(Dependency Property),我们可以通过编写自定义Style文件来控制控件的外观和行为,如同CSS代码一般。
5137 0
|
8月前
|
存储 API 内存技术
GD32通过SPI和QSPI模式读取GD的NOR Flash
GD32通过SPI和QSPI模式读取GD的NOR Flash
1222 2
|
缓存 网络协议
TCP累计确认和延迟确认傻傻分不清?
TCP累计确认和延迟确认傻傻分不清?
1181 1
|
数据格式 Python
【Python】已解决:Excel无法打开文件test.xIsx“,因为文件格式或文件扩展名无效。请确定文件未损坏,并且文件扩展名与文件的格式匹配。
【Python】已解决:Excel无法打开文件test.xIsx“,因为文件格式或文件扩展名无效。请确定文件未损坏,并且文件扩展名与文件的格式匹配。
1447 0
|
网络协议 Shell 网络安全
ssh: connect to host github.com port 22: Connection refused
本文讨论了在使用Git命令操作GitHub时遇到的"ssh: connect to host github.com port 22: Connection refused"错误,分析了可能的原因,并提供了使用443端口或https协议作为解决方案,最终确定问题是由于DNS解析错误导致,通过修改hosts文件解决。
ssh: connect to host github.com port 22: Connection refused
|
监控 网络协议 安全
在Linux中,如何进行系统性能的峰值测试?
在Linux中,如何进行系统性能的峰值测试?
|
机器学习/深度学习 人工智能 运维
智能化运维:AI技术在IT管理中的创新应用
本文将探讨如何运用人工智能技术优化IT运维流程,提升效率并减少人为错误。我们将从智能监控、自动化响应到预测性维护等方面,分析AI在现代IT运维中的角色和价值。文章旨在为读者提供一种全新的视角,理解AI技术如何成为IT部门的强大盟友,并指出实施这些技术时可能遇到的挑战及应对策略。
|
存储 算法 安全
微信团队分享:来看看微信十年前的IM消息收发架构,你做到了吗
好的架构是迭代出来的,却也少不了良好的设计,本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构,愿各位读者能从中获得启发。
695 1