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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 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,例如对方的缓冲区满了

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

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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
网络协议 算法
简述TCP报文首部字段及其作用
TCP报文首部字段及其作用
1604 0
|
1月前
|
网络协议 算法 数据格式
【TCP/IP】UDP协议数据格式和报文格式
【TCP/IP】UDP协议数据格式和报文格式
119 3
|
6月前
|
网络协议 网络性能优化
TCP和UDP协议的特点和用途
TCP是面向连接、可靠的传输协议,提供按序交付和流量控制,适合网页浏览、邮件及文件传输等需要高可靠性的场景,例如在线购物交易数据的准确传输。而UDP是无连接、不可靠但速度更快的协议,具有较小的头部开销,常用于实时应用如在线游戏和语音通话,其低延迟特性适合对即时性要求高于准确性的场合,如多人在线游戏中的即时互动。
|
缓存 网络协议 安全
TCP首部格式【TCP原理(笔记五)】
TCP首部格式【TCP原理(笔记五)】
294 0
TCP首部格式【TCP原理(笔记五)】
|
网络协议
TCP UDP报文段的详细解释
TCP UDP报文段的详细解释
220 0
|
6月前
|
网络协议 算法 安全
UDP报文格式详解
UDP报文格式详解
358 0
|
网络协议
UDP的报文结构
UDP的报文结构
92 0
|
网络协议
传输层——TCP协议)(一)
传输层——TCP协议
89 0
|
存储 消息中间件 缓存
计网 - TCP 的封包格式:TCP 为什么要粘包和拆包?
计网 - TCP 的封包格式:TCP 为什么要粘包和拆包?
129 0
|
缓存 网络协议 网络架构
四十、TCP协议的特点、TCP报文段格式和TCP的连接管理
四十、TCP协议的特点、TCP报文段格式和TCP的连接管理
四十、TCP协议的特点、TCP报文段格式和TCP的连接管理