网络协议系列之八:TCP差错控制

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介:

TCP的差错控制主要使用校验和确认超时重传这三个工具进行差错控制。

校验和主要用来检验数据报文是否受到损伤。如果校验和无效,报文就会在终点被丢弃。

确认是接收端用来证实确实收到了报文,在TCP中,使用的是累计确认,接收端会告诉发送端其下一个希望接收的字节编号。

超时重传是差错控制的核心。实际上当发送端发送一段字节的数据后,会把这个报文段保存在一个队列中,并启动一个计时器,这个计时器也叫RTO(重传计时器),若计时器超时发送端还没有收到接收端的ACK确认,那么发送端会把队列中的首部报文重新发送。

当然RTO的值是动态的,与RTT有关,RTT是一个报文自发送到接收端返回确认的时间。如果RTO的值不是很大。使用简单的超时重传也就够了,但是如果RTO的值足够大,再使用超时重传就不太切实际了。

TCP是这样处理的:如果发送端连续收到三个重复的超时重传ACK,那么发送端可以不必等待计时器到达而选择马上重传报文段,这种机制也称为快重传

还有一点要注意的是:接收端接收的数据可能不是按序到达的,当接收到不是按序到达的数据的时候,接收端不会丢弃该数据,而是先保存起来,并立即发送一个ACK,当其他失序的报文都到达后才把数据交付给接收进程。由于当RTO的值比较大的时候,TCP会采用快重传机制重传丢失的报文段,所以当发送完一个报文段后,如果发送端连续接收到3个重复的ACK确认的时候就会马上重传报文段,即使RTO计时器还没有超时。下图是快重传的一个流程图:

快重传

针对这个流程图说明快重传的机制:

  1. 当发送端收到接收端ackNo=301的报文的时候,继续传输起始编号为301长度为100字节的数据,但是这个报文段丢失了,而发送端继续传输了字节编号从401到500的字节,接收端于是收到了失序但无差错的报文段,接收端把这段报文保存起来,并在接收窗口隔一个空隙,表示还有失序的报文没有到达,并给发送端发送ackNo=301的报文,表示起始编号为301的字节数据我这边还没有收到,你那边注意一下,准备重传吧
  2. 发送端收到这个报文后,仍然继续传输起始编号为501到600的字节,接收端接收到后保存起来,并重新发送ackNo=301的报文
  3. 发送端继续发送起始编号为601到700的字节,接收端收到后保存起来,并再次发送ackNo=301得的报文,由于这已经是第四次收到重复的ACK确认了,虽然这时RTO计时器还没有到达,但是发送端立即发送起始编号为301的字节数据。
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
6天前
|
Web App开发 缓存 网络协议
不为人知的网络编程(十八):UDP比TCP高效?还真不一定!
熟悉网络编程的(尤其搞实时音视频聊天技术的)同学们都有个约定俗成的主观论调,一提起UDP和TCP,马上想到的是UDP没有TCP可靠,但UDP肯定比TCP高效。说到UDP比TCP高效,理由是什么呢?事实真是这样吗?跟着本文咱们一探究竟!
30 10
|
26天前
|
域名解析 缓存 网络协议
TCP传输层详解(计算机网络复习)
本文详细解释了TCP/IP协议族的分层模型、各层的功能、TCP报文的格式以及TCP连接建立的三次握手和断开的四次挥手过程。
67 2
TCP传输层详解(计算机网络复习)
|
24天前
|
网络协议 Java API
【网络】TCP回显服务器和客户端的构造,以及相关bug解决方法
【网络】TCP回显服务器和客户端的构造,以及相关bug解决方法
51 2
|
24天前
|
存储 网络协议 Java
【网络】UDP和TCP之间的差别和回显服务器
【网络】UDP和TCP之间的差别和回显服务器
55 1
|
1月前
|
域名解析 存储 网络协议
TCP套接字【网络】
TCP套接字【网络】
29 10
|
25天前
|
XML 网络协议 算法
【TCP】网络原理
【TCP】网络原理
26 0
|
2月前
|
网络协议 C语言
C语言 网络编程(十三)并发的TCP服务端-以进程完成功能
这段代码实现了一个基于TCP协议的多进程并发服务端和客户端程序。服务端通过创建子进程来处理多个客户端连接,解决了粘包问题,并支持不定长数据传输。客户端则循环发送数据并接收服务端回传的信息,同样处理了粘包问题。程序通过自定义的数据长度前缀确保了数据的完整性和准确性。
|
2月前
|
网络协议 C语言
C语言 网络编程(十一)TCP通信创建流程---服务端
在服务器流程中,新增了绑定IP地址与端口号、建立监听队列及接受连接并创建新文件描述符等步骤。`bind`函数用于绑定IP地址与端口,`listen`函数建立监听队列并设置监听状态,`accept`函数则接受连接请求并创建新的文件描述符用于数据传输。套接字状态包括关闭(CLOSED)、同步发送(SYN-SENT)、同步接收(SYN-RECEIVE)和已建立连接(ESTABLISHED)。示例代码展示了TCP服务端程序如何初始化socket、绑定地址、监听连接请求以及接收和发送数据。
|
2月前
|
网络协议 C语言
C语言 网络编程(十四)并发的TCP服务端-以线程完成功能
这段代码实现了一个基于TCP协议的多线程服务器和客户端程序,服务器端通过为每个客户端创建独立的线程来处理并发请求,解决了粘包问题并支持不定长数据传输。服务器监听在IP地址`172.17.140.183`的`8080`端口上,接收客户端发来的数据,并将接收到的消息添加“-回传”后返回给客户端。客户端则可以循环输入并发送数据,同时接收服务器回传的信息。当输入“exit”时,客户端会结束与服务器的通信并关闭连接。
|
2月前
|
网络协议 C语言
C语言 网络编程(十二)TCP通信创建-粘包
TCP通信中的“粘包”现象指的是由于协议特性,发送方的数据包被拆分并在接收方按序组装,导致多个数据包粘连或单个数据包分割。为避免粘包,可采用定长数据包或先传送数据长度再传送数据的方式。示例代码展示了通过在发送前添加数据长度信息,并在接收时先读取长度后读取数据的具体实现方法。此方案适用于长度不固定的数据传输场景。