可靠的UDP和ACK方法问题

Question

我正在阅读有关可靠UDP的实现（即再次发送ACK数据包和重新连接数据包的实现）。

在这两个主要模式中，我似乎发现网络上的网络：

1. 客户端为每个收到的数据包发送一个包含该数据包的序列的ACK。 Server假设数据包已无法传递，除非它收到ACK。

2. 客户端发送带有其认为缺少数据包的序列的ACK数据包。 Server假设数据包已交付，除非它从客户端接收ACK，说它缺少一个序列，然后再重新安排请求的（丢失）数据包。

简而言之，在1中。客户发送接收到的数据包的顺序，而在2中。客户端发送丢失数据包的顺序。

只是想知道每种方法的利弊是什么，哪一种是主流的（我假设1，但是2似乎是一种非常聪明的方法，因为据说大多数数据包确实到达，并且通常只丢失了少数数据包）。

编辑：这两种方法的一个简短示例：

Method 1: Server sends: 1,2,3,4,5 
Client received: 1,3,5,4 
Client sends back: ACK 1, ACK 3, ACK 5, ACK 4  
Server resends: 2.. maybe more if ACK packets were lost


Method 2:
Server sends 1,2,3,4,5,6,7,8
Client receives: 1,3,2,5,7
Client Sends :ACK (lowest continuous 3,highest received 7,  seem to be missing 4,6)
Server resends: 4,6,8

Answer 1

#2 也称为负ACK，又名Nak，它是运输的乐观观点。当运输正常运行时，这意味着更好的比例。

#1 是一个悲观的观点，假设运输经常失败。

TCP使用ACK，因为对拥塞控制有基本的依赖性来删除数据包以执行流量成型以创建一个公平的网络。可靠的UDP通道通常使用NAKS，因为您使用的是可靠的高速中型或低速率流，并且需要在基本ACK实现的典型锁定步骤上使用低延迟。

请注意，如果您提高了一步，并在可靠的UDP频道上方看订阅管理，那么ACK或NAK使用情况就没有明确的赢家。市场数据界已证明这两种技术都在高容量网络上高速使用。 Acks具有订阅的好处，即在网络故障后您不需要复杂的重新同步，但是当每个主机都会发出重新提交时，您会看到网络和CPU使用的一致峰值。