TCP延迟确认机制和SACK

 

一 TCP的ACK原理和延迟确认机制

(1)ACK的定义:

TCP协议中,接收方成功接收到数据后会回复一个ACK数据包,表示已经确认接收到ACK确认号前面的所有数据。字段长度是32位。

(2)ACK的作用

发送方在一定时间内没有收到服务端的ACK确认包后,就会重新发送数据包。发送方收到了ACK,表明接收方已经接收到数据,保证了数据可靠传输。

(3)ACK机制

接收方在收到数据后,不是立即会给发送方发送ACK的。可能有以下原因:

A 收到数据包的序号前面还有需要接收的数据包。因为发送方发送数据时,并不是需要等上次发送数据被ACK就可以继续发送TCP包,而这些TCP数据包到达的顺序是不保证的,这样接收方可能先收到后发送的TCP包(注意提交给应用层时是保证顺序的)。

B 为了降低网络流量,ACK有延迟确认机制。

C ACK的值到达最大值后,又会从0开始。

(4)ACK延迟确认机制

接收方在收到数据后,并不会立即回复ACK,而是延迟一定时间。一般ACK延迟发送时间为200ms,但是这个200ms并非收到数据后需要延迟的时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。这样做有2个目的:

  1. 这样做的目的是ACK是可以合并的,也就是指如果连续收到两个TCP包,并不一定需要ACK两次,只要回复最终的ACK就可以了,可以降低网络流量。
  2. 如果接收方有数据要发送,那么就会在发送数据的TCP数据包里,带上ACK信息。这样做,可以避免大量的ACK以一个单独的TCP包发送,减少了网络流量。

比如:正常TCP断开是4次挥手,但是抓包抓到大部分都是3次挥手。就是延迟确认的结果吧。

 

二:浅议SACK

(1)SACK:

Selective Acknowledgement,选择性确认。

(2)功能

TCP收到乱序数据后会将其放到乱序序列中,然后发送重复ACK给对端。对端如果收到多个重复的ACK,认为发生丢包,TCP会重传最后确认的包开始的后续包。这样原先已经正确传输的包,可能会重复发送,降低了TCP性能。为改善这种情况,发展出SACK技术,使用SACK选项可以告知发包方收到了哪些数据,发包方收到这些信息后就会知道哪些数据丢失,然后立即重传丢失的部分。

    需要注意的是只有收到失序的分组时才会可能会发送SACK,TCP的ACK还是建立在累积确认的基础上的。也就是说如果收到的报文段与期望收到的报文段的序号相同就会发送累积的ACK,SACK只是针对失序到达的报文段的。

(3)格式

SACK包括了两个TCP选项,一个选项用于标识是否支持SACKSACK_permitted),是在TCP连接建立时时发送;另一种选项则包含了具体的SACK信息。

1SACK_permitted选项

该选项只允许在TCP连接建立时,有SYN标志的包中设置,也即TCP握手的前两个包中,分别表示通信的两方各自是否支持SACK

2SACK信息选项

SACK信息选项用于通告对端接收数据的信息。

该选项参数告诉对方已经接收到并缓存的不连续的数据块,注意都是已经接收的,发送方可
根据此信息检查究竟是哪个块丢失,从而发送相应的数据块。
   *    Left Edge of Block
       
不连续块的第一个数据的序列号
   *    Right Edge of Block
       
不连续块的最后一个数据的序列号之后的序列号

### Kafka 的 ACK 机制原理与实现方式 Kafka 的 ACK(Acknowledgment)机制是一种用于确保消息成功传递处理的关键技术。它通过配置不同的 `acks` 参数值,允许生产者指定在认为一条消息已被成功写入之前需要收到多少个副本的确认[^1]。 #### 配置参数及其含义 - **acks=0**: 生产者不会等待任何来自服务器的响应。这种模式下,数据丢失的可能性较高,但由于无需等待确认,因此具有最高的吞吐量。 - **acks=1**: 只要分区的 Leader 已经成功接收到并存储了该条消息,则会向生产者返回确认信息。然而,如果此时 Follower 尚未同步此消息而 Leader 发生崩溃,则可能导致数据丢失。 - **acks=all 或 -1**: 这是最安全的选择之一,表示只有当所有 In-Sync Replicas (ISR) 成员均完成对该记录的复制之后才会给客户端反馈已接受的通知;这种方式能够提供最强的数据保障能力,但同时也可能带来一定的延迟增加效果[^4]。 #### 技术细节与源码层面解析 从源码角度来看,ProducerRecord 被创建后会被封装成 RecordBatch 并放入 Transmitter 中准备传输至 Broker 。一旦批次内的每条日志项都得到了满足条件数量节点的认可回应即视为整个操作结束。具体来说,在发送请求时设置了 timeout retry 等属性控制重试逻辑以便应对网络波动等问题造成的临时失败情况发生[^2]。 另外值得注意的是,为了进一步增强系统的健壮性,Kafka 提供了幂等性事务支持功能。其中前者主要依赖于 ProducerId(PID)+Sequence Number 组合唯一标识每次调用尝试避免重复提交相同内容的现象出现;后者则借助 Two-phase Commit Protocol 来协调多个 topic-partition 上的操作达成全局一致状态变化的目的。 ```python from kafka import KafkaProducer producer = KafkaProducer(bootstrap_servers='localhost:9092', acks='all') future = producer.send('my-topic', b'raw_bytes') try: record_metadata = future.get(timeout=10) except Exception as e: print(f"Error occurred: {e}") finally: producer.close() ``` 上述代码片段展示了如何利用 Python 客户端库设置 `acks='all'` 参数以启用最严格的确认策略实例演示过程[^3]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值