我有两个应用程序在同一台计算机上运行并通过 使用 Loopback 接口的 UDP 数据包。应用程序生成包， 而其他应用程序则消耗它们。一切都运转良好，但做 使用“tcpdump”进行数据包捕获我注意到 TTL 始终为 64，这就是 问题出现了。
“tcpdump”命令的输出
02:27:34.541512 IP (tos 0x0, ttl 64, id 26465, offset 0, flags [DF], proto UDP (17), length 1344)
localhost.43557 > localhost.21001: [bad udp cksum 0x0340 -> 0x73f0!] UDP, length 1316
02:27:34.551505 IP (tos 0x0, ttl 64, id 26488, offset 0, flags [DF], proto UDP (17), length 1344)
localhost.43557 > localhost.21001: [bad udp cksum 0x0340 -> 0xc06c!] UDP, length 1316
02:27:34.557514 IP (tos 0x0, ttl 64, id 26511, offset 0, flags [DF], proto UDP (17), length 1344)
localhost.43557 > localhost.21001: [bad udp cksum 0x0340 -> 0xd039!] UDP, length 1316
确实，Linux 中 Loopbak 接口上的 TTL 始终为 64，因为 Linux 不支持 执行其值的减少，因为它仅在重新发送时执行 通过路由跳跃（IP路由）？
如果不减少TTL， 到。如果没有进程捕获通过 Loopback 接口发送的 UDP 数据包，会发生什么情况？ b.包裹是否闲置？ C. 内核会在第一次捕获数据包时丢弃它吗？
如果在相同场景下数据包是作为TCP发送的， 到。数据包是否会发生与 UDP 相同的情况？ b.还是处理方式不同？
注意。我为英语道歉，因为我只会说西班牙语。为了翻译我使用了谷歌。
我不确定，但我认为这些数据包被处理一次，然后被丢弃。我担心计算机上会产生不必要的流量并降低其性能。
第一个答案：是的，Linux 中通过 Loopback 接口发送的数据包的 IP 标头中的 TTL 字段通常为 64。这是因为 Loopback 接口不会演进物理网络跳数，并且通常在数据包穿越物理网络时执行 TTL 递减接口。
第二个答案：如果通过 Loopback 接口发送 UDP 数据包，而没有相应的进程来捕获它，则内核会丢弃该数据包，以防止不必要的流量或性能下降，因为 Loopback 接口是虚拟的，并且该数据包在该数据包内没有预期的接收者同一设备。
第三个答案：对于通过 Loopback 接口发送的 TCP 数据包，行为类似。如果目标端口没有进程监听，TCP握手将无法完成，连接也不会建立。