我之前在旧版CUPS环境下也碰到过几乎一模一样的AirPrint延迟问题，结合你给出的环境信息和日志细节，分享几个具体的排查和解决方向：

1. 先定位CUPS的属性查询响应效率 #

问题的核心是iOS设备在10秒内多次发送Get-Printer-Attributes请求，这说明它没收到及时的响应才会重试。你可以先手动模拟这个请求，看看单次查询的耗时：

ipptool -t -v ipp://localhost/printers/[你的打印机名称] get-printer-attributes.test

如果单次查询就超过5秒，那问题肯定出在CUPS处理请求的环节。接下来可以：

• 把CUPS的LogLevel临时改成debug2（在cupsd.conf里修改），然后查看/var/log/cups/access_log和error_log，看看每次处理Get-Printer-Attributes时，CUPS在执行什么操作——比如是不是在查询打印机的实时状态（墨量、纸张）时卡住了？
• 尝试在printers.conf里给打印机添加状态查询超时限制，比如在DeviceURI后面加上?wait-timeout=3，或者直接关闭实时状态查询：StateTimeouts=0（这个参数在CUPS 1.5.4里是支持的）。
• 检查cupsd.conf里的MaxClients和Timeout参数，是不是并发连接限制过低，或者超时设置不合理导致请求排队。

2. 排查Avahi的mDNS响应速度 #

AirPrint依赖Avahi做服务发现，虽然你能找到打印机，但mDNS的响应延迟也可能触发iOS的重试机制：

• 用avahi-browse -r _ipp._tcp _universal._sub._ipp._tcp查看打印机的服务发布情况，看看服务记录是不是正常，有没有重复发布的情况。
• 检查avahi-daemon.conf里的cache-entries-max和ratelimit-interval-usec参数，是不是缓存或速率限制导致响应变慢。另外确保CUPS和Avahi联动正常——cupsd.conf里要有BrowseRemoteProtocols ipp配置，Avahi能正确订阅CUPS的服务。

3. 分析网络交互的时序 #

用tcpdump抓包分析iOS设备和Linux主机之间的通信，明确延迟出在哪个阶段：

tcpdump -i [你的网卡名称] port 631 or port 5353

重点看：

• iOS的Get-Printer-Attributes请求是不是及时到达Linux主机？
• CUPS的响应是不是立刻返回，还是有明显延迟？
  如果请求到响应的间隔超过5秒，那就是服务端的问题；如果响应很快但iOS还是重试，可能是网络丢包或者iOS端的兼容性问题（不过你两个iOS版本都有问题，后者概率低）。

4. 考虑CUPS版本的优化空间 #

你的CUPS 1.5.4是2012年的旧版本，AirPrint的支持在后续版本里有不少性能优化。如果环境允许，可以尝试：

• 编译升级到CUPS 2.2.x系列（长期支持版），这个版本对AirPrint的属性查询效率有明显提升。
• 查找针对CUPS 1.5.4的AirPrint延迟补丁，有些社区补丁会修复旧版本中属性查询缓慢的问题。

5. 手动预设打印机属性 #

如果CUPS每次都要从打印机获取某些属性（比如media-size、printer-driver-name）导致延迟，可以在printers.conf里手动预设这些属性，避免实时查询：

MediaSize=A4
PrinterDriverName=你的打印机驱动名称

这样CUPS收到Get-Printer-Attributes请求时，直接返回预设值，能大幅加快响应速度。

我当时是通过关闭CUPS的实时状态查询+手动预设常用属性，解决了同样的10秒延迟问题，你可以先从ipptool测试和CUPS日志调试入手，定位具体的慢环节，再针对性优化。

内容的提问来源于stack exchange，提问作者Sunny L