可靠的UDP和ACK方法问题答案

【问题标题】：Reliable UDP and ACK method question可靠的UDP和ACK方法问题
【发布时间】：2011-01-07 09:59:34
【问题描述】：

我正在阅读可靠 UDP 的实现（即发送 ACK 数据包并再次重新发送非 ACK 数据包）。

我似乎在网上发现了两种主要模式：

客户端为每个接收到的数据包发送一个 ACK，其中包含该数据包的序列。除非收到 ACK，否则服务器假定数据包未送达。
客户端发送一个 ACK 数据包，其中包含它认为丢失的数据包序列。服务器假定数据包已交付，除非它从客户端收到一个确认丢失序列的 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

【问题讨论】：

那么，如果在方法二中，客户端确认说它丢失了某些东西的数据包永远不会传递呢？
据我了解，在方法 2 中有一个 ACK 说“这里没有丢失数据包（并且接收到的最高 seq 是 532）”......所以如果服务器发送 1 个数据包并且没有收到 ACK该数据包被重新发送。此外，方法 2 中的 ACK 数据包通常是定期发送的。我猜这很像 ping
那么您能否进一步澄清一下这些差异？因此，方法 1 显式地确认数据包，只要达到新的 seq no（因此可能是多个数据包的 ack），而方法 2 定期确认数据包而不是显式地确认数据包？
否，方法 1 为每个收到的数据包发送一个 ACK。没有嵌入其他逻辑。方法 2 定期发送一个 ACK 并嵌入一个逻辑以提供某种传输窗口：我有所有数据包直到序列 40，我似乎丢失了数据包 41,45 和 47。（或者：我有所有数据包到序列 56，没有丢失的数据包）

标签： udp network-protocols unreliable-connection

【解决方案1】：

#2 也称为 Negative ACK，又名 NAK，是一种乐观的传输观点。这意味着当传输正常运行时可以更好地扩展。

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

TCP 使用 ACK 是因为基本依赖拥塞控制来丢弃数据包以执行流量整形以创建公平的网络。可靠的 UDP 通道通常使用 NAK，因为您使用的是可靠的高速中速或低速流，并且要求在基本 ACK 实现典型的锁定步骤上具有低延迟。

请注意，如果您更上一层楼并查看可靠的 UDP 通道之上的订阅管理，则 ACK 或 NAK 的使用没有明确的赢家。市场数据世界已经证明在高容量网络上高速使用这两种技术。 ACK 具有订阅的好处，即您不需要在网络故障后进行复杂的重新同步，但是当每个主机发出重新订阅时，您会看到网络和 CPU 使用率的一致峰值。

【讨论】：