7

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

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

  1. 客户端为每个接收到的数据包发送一个 ACK​​，其中包含该数据包的序列。服务器假定数据包未送达，除非它收到 ACK。

  2. 客户端发送一个带有它认为丢失的数据包序列的 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
4

1 回答 1

8

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

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

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

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

于 2011-05-15T16:39:40.560 回答