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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 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月前
|
网络协议 前端开发 Java
为何要3次握手?TCP协议的稳定性保障机制
为何要3次握手?TCP协议的稳定性保障机制
为何要3次握手?TCP协议的稳定性保障机制
|
1月前
|
存储 XML JSON
【TCP】核心机制:延时应答、捎带应答和面向字节流
【TCP】核心机制:延时应答、捎带应答和面向字节流
50 2
|
1月前
|
网络协议 算法 网络性能优化
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
【TCP】核心机制:滑动窗口、流量控制和拥塞控制
51 2
|
2月前
|
监控 网络协议 UED
TCP协议中的两种保活机制详述
TCP的保活机制通过保活探针和用户配置的保活时间两种方式,为网络通讯提供了重要的保障。它帮助识别并处理那些因为网络不稳定或对端突然下线而变得无响应的连接,对于确保长时间运行的网络应用的稳定性和可靠性非常关键。合理配置和使用TCP保活机制,可以显著提升网络应用的鲁棒性和用户体验。
78 1
|
6月前
|
存储 网络协议 Java
【TCP 连接手段】C++编程视角下的TCP:短连接与长连接深度解析
【TCP 连接手段】C++编程视角下的TCP:短连接与长连接深度解析
180 1
|
网络协议 算法 网络性能优化
TCP为什么是可靠的(怎么保证有效传输的)?
TCP为什么是可靠的(怎么保证有效传输的)?
560 0
|
存储 缓存 弹性计算
【计算机网络】TCP的可靠性传输机制和常见配置讲解
【计算机网络】TCP的可靠性传输机制和常见配置讲解
【计算机网络】TCP的可靠性传输机制和常见配置讲解
|
网络协议 Linux 网络性能优化
TCP 协议如何保证传输的可靠性
TCP 协议如何保证传输的可靠性
214 0
|
网络协议 Java
java实现TCP数据传输反馈
java实现TCP数据传输反馈
|
存储 网络协议 程序员
【TCP 协议】报文格式,数据可靠传输的机制(一)
【TCP 协议】报文格式,数据可靠传输的机制(一)
288 0