TCP协议报文,核心特性可靠的原因,超时重传详细介绍

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: TCP协议报文,核心特性可靠的原因,超时重传详细介绍

一、TCP协议

每一行是四个字节,前面的20个字节是固定的(TCP最短长度,20字节,选项部分:有/无都行,当然了你有多个也行)

4bit表示的范围0——15 此处的单位是4字节🌸 ,所以要把这里的数值*4,才是真正的报头长度TCP,最大的长度60字节。

保留六位的六个标识位:resvered设计TCP大佬比设计UDP的大佬,留个心眼,虽然现在不用,但是先占有个位置,后面可能需要用(目前TCP这么多年大概不用了 🌸 )

二、TCP核心特性的保障

TCP核心特性:有连接,可靠传输,面向字节流,全双工

可靠传输:内核实现的可靠传输,写代码的时候,感知不到(人本身就是这么设计,让感知成本,使用成本降低)🌻

网络传输中:常常会遇到那种后发先至(当连续发送多条信息的时候)🌻

网络上从A到B中间路径有很多(初心,冗余,让他不怕核弹这种,一个弹过来影响通讯)

比如:舔狗狗哥舔女神

问女神吃不吃麻辣烫呀?愿不愿意做我女朋友啊?

女神先回我:好的好的。😃 滚一边去,下头男啊🌚🌚🌚

结果后发先至,😍虽说没有吃麻辣烫,但是做我女朋友也挺好。(🤠小丑)。

另外每个节点/路由器/交换机/繁忙程度不一样,此时,这样的转发过程,也会存在差异。

那么我们该怎么办呢?

针对数据进行编号

TCP是面向字节流,不是按照条为单位进行传输的。

确认应答的意思,假如说应答下一个数据1001,就说明(1-1000)之前的数据全收到了,下面该从1001开始发。

1.针对字节进行编号的,而不是针对条

2.应答报文也是要和收到的数据序号相关联而不是相等。

只要知道这一串字节的开始编号,以及数据的长度,每个字节的编号也就知道了,TCP报头中,把这一串字节的编号表示出来,再结合报文长度,此时每个字节编号就都确定了。

编号也就是那个32位序号

32位确认序号——这个字段是给应答报文使用的,假如超越了32位,就开始从头计算,4个字节->42亿9千万,4个G,一般也不会一口气传4G

三、保留的六位标志位对于应答报文的作用

保留的六位具体是

那么对于应答报文是怎么样呢🐳🐳

ACK为0,表示这是一个普通报文,此时只有32位序号,是有效的

ACK为1,表示这是一个应答报文,这个报文的序号和确认序号都是有效的->确认报文的序号和正常报文,之间没有关联关系,各自论各自的,序号是你自己的主机发送的数据进行编号。

数据1-1000,序号1,长度1000,确认序号无意义,ACK为0

下一个返回确认报文1001,序号未知,假设是100(这个序号根发送序号没啥关系),长度不知道,确认序号是1001,ACK是1->应答报文可能携带载荷,也可能没有。

下一个传输应答的时候,应答是应答的序号,与发送的序号无关,上个应答序号是100,这个应答报文就应该是101,序号未知。

确认应答,是TCP保证->IP协议的报头中,可以知道载荷多长的,IP载荷长度——TCP报头长度->TCP载荷长度

如果设备过于繁忙,后来新来的等待的太久,就可能会被丢弃,越忙越容易丢包

面对丢包,我们的应对机制是什么呢?,难道丢包就不可靠了吗?

四、如何处理丢包——超时重传的原理

这个问题最大的就是:无法区分是哪种情况,既然无法区分,那就都重新传输呗。但是也不能随意去重啊。你想想一个问题,你转50块钱,就算你没收到,我发出去了啊,我再发一个50,那不就亏了50嘛(任何问题一用钱💰🤬🤬考虑都好过分)接收方收到数据之后,需要对数据进行呢去重,把重复的数据丢弃掉,保证应用程序,调用inputStream的时候,读到的不会出现重复,如何进行去重?如何高效判定当前数据是否重复,直接使用TCP的序号,来作为判定依据

->TCP在内核中,给每个socket对象都安排一个内存空间,相当于一个队列,也称为“接收缓冲区”,收到的数据,都会被放到缓冲区里,并且按照序号排列,已经排好序了。

(这里又是一个生产者消费者模型,收到数据,接收的网卡,把数据放到对应socket的接收缓冲区内核中)

应用程序,调用read,就是从这个接收缓冲区中,消费数据,当数据被read走后,就可以从队列中删除掉了(read有两种模式,读到就删除,也可以读到不删除)-》接收缓冲区,数据按照序号有序排列~队列队首序号已经超过了新收到的这个数据的序号,新收到的序号在之前被读过了

以下是去重的思想:假如给B发一条序号为100,B成功收到消息后,并返回101作为确认,然后确认的消息发生了丢包,你不知道消息是否到达,所以你进行了重新发送,序号仍为100,确保B能正常接收,但是由于B之前已经读完了那个主机A的内容,所以他会帮你进行一个去重(注意不是根据内容去重的哈🌝🌝)

后发先至的这个问题,是根据序号重新排列的过程,因此应用程序不必考虑数据传输先后的顺序问题。

五、超时重传的时间

为啥我们重新传输的时候就能够传过去呢?(这就如同电脑重启,丢包的本质是概率问题)重传的次数增加,总体传输的成功概率也就越大,高中算数,一个丢包0.1概率,连着丢10的概率很低的。

超时时间当然也不是一个固定的值,(这段时间一直传不过去,就不传了这种),是会随着超时轮次的增加,进一步增加

随着转轮次数的增加,等待时间也会越来越长,当前认为,正常情况下,第二次重新传输有极大情况,重传成功,如果很多次都不成功,那就有可能当前的网络有故障。

超时重传的轮次也不是无限的,重新传输到一定次数,会重置TCP连接。使用复位报文

TCP复位报文

RST,那个六位里面的

RST为1,表示一个复位报文-》除非严重的故障,复位操作也无法成功,最后只好放弃连接。

确认应答是TCP可靠最核心的机制

超时连接是TCP可靠性的有效补充

下一篇更屌,面试最常考的就是我的下一章,等我


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
网络协议 算法 网络性能优化
【计算机网络】TCP 如何实现可靠传输
【计算机网络】TCP 如何实现可靠传输
78 6
|
6月前
|
网络协议 前端开发 Java
为何要3次握手?TCP协议的稳定性保障机制
为何要3次握手?TCP协议的稳定性保障机制
为何要3次握手?TCP协议的稳定性保障机制
|
1月前
|
存储 XML JSON
【TCP】核心机制:延时应答、捎带应答和面向字节流
【TCP】核心机制:延时应答、捎带应答和面向字节流
47 2
|
1月前
|
网络协议 算法 网络性能优化
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
30 2
|
4月前
|
网络协议 算法 程序员
提高网络稳定性的关键:TCP滑动窗口与拥塞控制解析
**TCP可靠传输与拥塞控制概要:** 小米讲解TCP如何确保数据可靠性。TCP通过分割数据、编号段、校验和、流量控制(滑动窗口)和拥塞控制(慢开始、拥塞避免、快重传、快恢复)保证数据安全传输。拥塞控制动态调整窗口大小,防止网络过载,提升效率。当连续收到3个相同ACK时执行快重传,快恢复避免剧烈波动。关注“软件求生”获取更多技术内容。
126 4
提高网络稳定性的关键:TCP滑动窗口与拥塞控制解析
|
网络协议 算法 网络性能优化
TCP为什么是可靠的(怎么保证有效传输的)?
TCP为什么是可靠的(怎么保证有效传输的)?
548 0
|
网络协议 Linux 网络性能优化
TCP 协议如何保证传输的可靠性
TCP 协议如何保证传输的可靠性
211 0
|
存储 缓存 弹性计算
【计算机网络】TCP的可靠性传输机制和常见配置讲解
【计算机网络】TCP的可靠性传输机制和常见配置讲解
【计算机网络】TCP的可靠性传输机制和常见配置讲解
|
网络协议 Java
java实现TCP数据传输反馈
java实现TCP数据传输反馈
|
存储 网络协议 程序员
【TCP 协议】报文格式,数据可靠传输的机制(一)
【TCP 协议】报文格式,数据可靠传输的机制(一)
271 0