我一直在阅读iptables的man-page（睡前阅读），我遇到了“TTL”的目标，但它警告说：
设置或增加TTL字段可能是非常危险的
和
不要设置或增加离开本地networking的数据包的值！
我可以看到如何减less或设置TTL可能会导致数据包在到达目的地之前被丢弃，但是增加会有什么影响？
通过路由器时TTL减less。 这可以确保，如果数据包在圈子中移动，它最终会死亡。
IP v4数据包的TTL字段是一个8位字段（十进制数255）。 因此，在启动时将其设置为高，这不是什么大问题，因为它在一个格式良好的数据包中实际上不会那么大（尽pipe有些东西可能接受畸形IP数据包）。
但是，如果增加了一些内容，并且递增步骤是循环的一部分 ，那么数据包可以保持循环而不会达到零。 随着时间的推移（可能非常短，或逐渐泄漏），数据包可能会在包含该循环的系统中build立，导致数据包过载。
数据包的TTL保持路由健全，基本上。 如果一个数据包的TTL非常大，并由于某种原因被捕获到一个循环路由中，可能会导致大量的stream量（称为“数据包风暴”）并干扰正常的操作。 太低的TTL会导致连接丢失，因为在数据包到达目的地之前丢失数据包。
有一点答案似乎已经错过了，但这纯粹是学术的（因为在互联网上似乎需要多less跳）：如果一个数据包由于到期的TTL通常无法到达目的地，那么增加它将允许数据包到达目的地，但不会影响返回的数据包，并在到达您的networking之前到期。
更新：根据维基百科上的这个页面 ：
理论上，在IPv4下，生存时间以秒为单位，尽pipe每个通过数据报的主机必须至less减less一个单位的TTL。 实际上，TTL字段在每一跳都减less一个。 为了体现这种做法，该字段在IPv6中被重命名为跳数限制。
更新2：有人更新我的文章和引用的维基百科，我认为这可能是最好的参考RFC本身 – http://www.ietf.org/rfc/rfc791.txt – 只要在那里searchTTL，它确实相当一个很好的解释：
这个字段表示允许数据报保留在因特网系统中的最大时间…每个处理数据报的模块必须至less减less一个TTL，即使它在不到一秒的时间内处理了数据报
我知道只有一个程序，可以使用更高的TTL值，这是traceroute 。 正如名称所示，它通过修改TTL值来跟踪到达目标主机的路由。 标准的最大跳数是20，但可以增加。
处理分组的每个路由器递减TTL值，直到分组到达其目的地，或者TTL达到零，并且死亡。
正如其他人所说，如果有一个负循环，增加TTL可能会导致永不死亡的数据包。 通常，如果TTL值不够大，尝试更大TTL的逻辑应该可能由端对端客户端处理。
如果你确定一个路由器不在一个循环中（树型拓扑），理论上可以安全地增加TTL值。 话虽如此，允许更多的标准跳可能会使外部networking更容易拥堵。 如果内部networking与外部networking之间有长链路，只要没有周期，较大的TTL值可能会有所帮助。 话虽如此，有人可能很容易为networking添加一个边缘并创build一个循环，因此从较大的TTL值开始，数据包首先发起更安全。