TCP协议报头格式和滑动窗口

简介: TCP协议报头格式和滑动窗口

[TOC]

TCP报头格式

image-20230811215559584

端口号

两个端口号比较好理解,通过端口号来找到指定的进程

序号和确认序号

先要认清这两个序号首先得了解TCP的确认应答(ACK)机制

确认应答(ACK)机制

根据生活例子来说,当我们再和别人聊天时需要得到对方的回复才能够确定对方能够听到我们的话。对于TCP通信也是如此,当一端向另一端发送数据后,对端收到数据后需要告诉发送端已经收到了,这样发送端才能够知道,因此作为接收端就会应答确保已经接收到数据了

这种机制就是确认应答机制

在真实的使用场景中,TCP发送端如果是一条数据发送后等收到接收端的应答再发送另一条数据,这样效率就非常的低。所以真实的场景中,发送端会一下子发送多条数据。那么为了确保每一条数据都被接收端接收到了,那么接收端就需要对应每一条数据都进行应答,那么如何保证接收端应答的是对应的数据。或者说如果发生了丢包,接收端不会应答该条数据那么作为发送端如何知道是哪一条数据没有收到接收端的应答呢

这就引进了序号和确认序号的概念:

序号可以用来标识数据之间的不同,接收端收到数据后应答该条数据就会返回确认序号,而这个确认序号就是数据序号+1 。这样的目的是告诉发送端下次发送数据的序号从这个确认序号开始。

有了序号和确认序号的配合后,应答机制就能保证应答的是指定的数据

需要注意:接收方应答了一个确认序号后,就代表着这个确认序号之前的所有序号的数据都已经接收到。

也就是说假如接收端接收到了序号1000和3000的数据,但是没有收到2000的数据,那么接收端应答的确认序号只会是1001。那么这里又得引出一个概念:

超时重传机制

根据上述的例子,如果接收端没有收到2000的数据,那它就只会发送1001的应答。那么作为发送端迟迟都等不来2000的数据的应答,那发送端就会意识到数据丢包了。这时候作为发送端就会再次向接收端发送数据。

关于数据丢包就会出现另一种情况,上述的情况是发送端发送的数据丢包了。那么如果接收端接收到了数据,但是它发送的应答丢包了呢。这种情况同样会导致发送端迟迟收不到应答而重新发送数据,那假如应答老是丢包那么发送端就会发送很多份相同的数据,这时候作为接收端就会收到很多重复的数据。所以接收端需要对数据去重,而去重就可以利用序号实现,因为每个相同的数据都会有相同的序号

image-20230811222432166

首部长度

  1. TCP协议的报头是有标准长度的也就是最少长度,长度为20字节。因此读取时首先会读取20字节
  2. 首部长度为4个比特位,也就是说范围在[0000 - 1111]也就是[0 - 15]
  3. TCP报头的总长度 = 首部长度 * 4字节
  4. 因为TCP协议的标准长度为20字节,因此首部长度初始为5(0101)

窗口大小

首先的了解TCP协议发送数据和读取数据是在哪里得到的。

事实上,接收端调用read函数将数据读取并不是从TCP的报文中读取的,而是从一个缓冲区中也就是接收缓冲区中读取的。而发送端调用write函数写数据发送也不是直接写到TCP的报文中,而是写到发送缓冲区中

那么对于缓冲区而言就必定有大小,窗口大小就是指接收缓冲区的大小。TCP的报头中要含有自己缓冲区剩余的大小,为了告诉发送端自己的缓冲区大小还剩多少,让发送端做出发送策略调整,防止出现发送的太快导致来不及读使得缓冲区满了,也不能发的太慢

报文类型

事实上,TCP的报文也是有类型的,接收端要根据不同类型的报文做出不同的动作

image-20230811223736461

这几个就对应着TCP不同的报文类型,而这几个都是一位来着,置1或置0

URG

数据对于接收方而言,乱序就是不可靠的现象。所以要对收到的数据进行排序,因为报文是有序号的所以可以保证数据的按序到达。那么如果需要排队那就难免会有需要插队的情况。

URG:代表着有需要尽快读取的数据

而这个要配合这紧急指针使用,通过紧急指针知道一个偏移量在报文的有效数据中通过偏移量找到该数据

ACK

ACK用于建立连接时应答确认

SYN

用于请求连接

PSH

催促接收端尽快读取数据,避免缓冲区满

FIN

用于断开连接请求

RST

由于连接并不一定会成功,RST就用于重置连接

滑动窗口

因为发送端发出数据后接收端不一定会接收到数据,也就是出现丢包。因此发送端在发送出去数据后并不能直接将数据抹除,需要等待接收端应答后才可以抹除。那么这份数据保存在哪里呢?

这种数据就保存在滑动窗口中

image-20230811225908424

图中为缓冲区的分布,其中中间部分就是滑动窗口

滑动窗口的大小怎么设定怎么变化

对于缓冲区本质上就是一个数组,所以滑动窗口就有这个数组中的两个下标控制大小

image-20230811230408810

而决定缓冲区的大小和接收端的接受能力有关,也就是不管未来滑动窗口怎么变化都一定要保证在接收端的接受范围内。

因为数据都是有数据序号的,因此滑动窗口的变化:win_start = 应答收到的数据确认序号,win_end = win_start + 对端的窗口大小

滑动窗口变化问题

窗口会往左移动吗?

答案肯定是不会的

窗口一定会向右移动吗?

肯定窗口的变化可以得出,只有收到应答时窗口才会滑动,所以也有可能是不动的,但是如果动了一定是向右动

滑动窗口移动的本质就是数组下标的更新,所以窗口有可能会不动的

同样窗口也有可能变成0,例如对方的缓冲区满了

如果一直移动,空间不够了怎么办

针对这个问题,操作系统内核将发送缓冲区组织为环形结构了

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
人工智能 物联网 测试技术
以小博大,微软开源27亿参数模型Phi-2,魔搭最佳实践来啦!
近日,微软公布了在 Microsoft Ignite 2023大会上宣布开源的 Phi-2 模型的更多细节,“打破传统语言模型缩放定律,可PK比自己大25倍的模型”、“以小博大”等评价,让Phi-2一时间在开源社区中引发关注。
|
SQL API 数据库
优雅地进行入参数据校验:场景和处理方式
在日常的开发工作中,入参数据校验是确保程序健壮性的关键步骤之一,我们需要确保请求中的数据类型、格式和取值范围符合要求,以保证接口的安全性和稳定性,还有就是传递给方法或函数的数据需要满足一定的规则和要求,以保证程序的正常运行和数据的有效处理。那么本文就来分享一下在哪些场景下进行入参数据校验,并分享一些优雅的处理方式,以提高代码的可读性、扩展性和复用性。
269 3
优雅地进行入参数据校验:场景和处理方式
|
消息中间件 监控 开发者
构建高效微服务架构:后端开发的新趋势
在现代软件开发中,随着业务需求的不断复杂化和系统功能的日益增多,传统的单体应用逐渐暴露出扩展性差、维护困难等问题。为了应对这些挑战,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、技术栈选择以及在实际开发过程中可能遇到的挑战,为后端开发者提供一份构建和维护微服务的实用指南。
|
调度 数据库 数据库管理
数据库事务中调度串行化、冲突可串行化、前趋图(优先图)
数据库事务中调度串行化、冲突可串行化、前趋图(优先图)
986 0
|
Kubernetes Cloud Native 虚拟化
云原生|kubernetes|minikube的部署安装完全手册(修订版)
云原生|kubernetes|minikube的部署安装完全手册(修订版)
1941 1
ApplicationEventPublisher的简单使用
ApplicationEventPublisher的简单使用
598 0
|
小程序 Java 数据库
从根儿上学习微服务01:微服务的“前世今生”
从根儿上学习微服务01:微服务的“前世今生”
135 0
|
存储 C语言 C++
C语言面向对象
C语言面向对象
170 0
|
Android开发
【错误记录】前台进程报错 ( Bad notification for startForeground invalid channel for service notification )
【错误记录】前台进程报错 ( Bad notification for startForeground invalid channel for service notification )
1546 0
【错误记录】前台进程报错 ( Bad notification for startForeground invalid channel for service notification )