生きる時間

存続時間( TTL ) またはホップ制限は、コンピュータまたはネットワーク内のデータの存続期間または寿命を制限するメカニズムです。TTL は、データに添付または埋め込まれたカウンターまたはタイムスタンプとして実装できます。規定のイベントカウントまたは期間が経過すると、データは破棄されるか再検証されます。コンピュータネットワークでは、TTL によってデータパケットが無期限に循環することが防止されます。コンピューティングアプリケーションでは、TTLは一般にパフォーマンスの向上とデータのキャッシュ管理に使用されます。

説明

オリジナルのDARPAインターネットプロトコルのRFCでは^[1]^:§1.4TTLを次のように説明しています:

存続時間は、インターネットデータグラムの存続期間の上限を示します。これはデータグラムの送信者によって設定され、処理される経路上の各ポイントで削減されます。インターネットデータグラムが宛先に到達する前に存続時間がゼロになると、インターネットデータグラムは破棄されます。存続時間は、自己破壊の時間制限と考えることができます。

IPパケット

インターネットプロトコルでは、TTLは8ビットのフィールドです。IPv4ヘッダーでは、TTLは20オクテットの9番目のオクテットです。IPv6ヘッダーでは、40オクテットの8番目のオクテットです。TTLの最大値は255で、これは1オクテットの最大値です。推奨される初期値は64です。^[2]^[3]

存続時間値は、IPデータグラムがインターネットシステム内に存在できる時間の上限と考えることができます。TTL フィールドはデータグラムの送信者によって設定され、宛先までのルート上のすべてのルーターによって減らされます。データグラムが宛先に到着する前に TTL フィールドがゼロになると、データグラムは破棄され、インターネット制御メッセージプロトコル(ICMP) エラーデータグラム ( 11 - 時間超過) が送信者に返送されます。TTL フィールドの目的は、配信できないデータグラムがインターネットシステム上で循環し続け、最終的にそのような「不滅」なデータグラムによってシステムが圧倒される状況を回避することです。

理論上、IPv4では存続時間は秒単位で測定されますが、データグラムを渡すすべてのホストは TTL を少なくとも 1 単位減らす必要があります。実際には、 TTL フィールドはホップごとに 1 ずつ減らされます。この実践を反映するために、このフィールドはIPv6ではホップ制限に名前が変更されています。

DNSレコード

TTL はドメインネームシステム(DNS)でも発生し、権威ネームサーバーによって特定のリソースレコードに対して設定されます。キャッシュ (再帰)ネームサーバーが権威ネームサーバーにリソースレコードを照会すると、そのレコードは TTL で指定された時間 (秒単位) キャッシュされます。スタブリゾルバーがTTL の期限が切れる前にキャッシュネームサーバーに同じレコードを照会すると、キャッシュサーバーは権威ネームサーバーから再度リソースレコードを取得するのではなく、すでにキャッシュされているリソースレコードで応答します。NXDOMAIN (存在しないドメイン) 応答の TTL は、SOAレコードの MINIMUM フィールドと SOA 自体の TTL の小さい方から設定され、リゾルバーが否定応答をキャッシュできる期間を示します。^[4]^{[専門用語]}

TTL が短いと権威ネームサーバーの負荷が大きくなる可能性がありますが、 Web サーバーやMX レコードなどの重要なサービスのアドレスを変更するときに役立つため、サービスが移動される前に DNS 管理者が中断の可能性を減らすために TTL を短くすることがよくあります。

使用される単位は秒です。DNS の以前の一般的な TTL 値は 86400 秒、つまり 24 時間でした。TTL 値が 86400 の場合、権威ネームサーバーで DNS レコードが変更されると、クライアントによる最後の更新から最大 24 時間、世界中の DNS サーバーがキャッシュから古い値を表示し続ける可能性があります。

災害復旧(DR) システムの一部である新しい DNS 方式では、一部のレコードの TTL が意図的に非常に低く設定されている場合があります。たとえば、TTL を 300 秒にすると、重要なレコードが 5 分で期限切れになり、これらのレコードが世界中で迅速にフラッシュされるようになります。これにより、管理者はレコードをタイムリーに編集および更新できるようになります。TTL 値は「レコードごと」であり、特定のレコードにこの値を設定すると、世界中のすべての標準 DNS システムで自動的に適用される場合があります。ただし、一部のキャッシュ DNS ネームサーバーは、権限のあるレコードに関係なく独自の TTL を設定するため、TTL の期限が切れた後にすべてのダウンストリーム DNS サーバーに新しいレコードがあることが保証されないという問題が残っています。

ウェブ

有効期限は、レコードの有効期限が切れる日時として表現されることもあります。HTTPExpires:応答のヘッダー、Cache-Control: max-ageリクエストと応答の両方のヘッダーフィールド、およびexpiresHTTP クッキーのフィールドは、このように有効期限を表現します。

参照

参考文献

^ J. Postel編 (1981 年 9 月)。インターネットプロトコル - DARPA インターネットプログラムプロトコル仕様。IETF。doi : 10.17487 / RFC0791。STD 5。RFC 791。IEN 128、123、111、80、54、44、41、28、26。 インターネット標準 5。RFC 760 は廃止されました。RFC 1349、2474、および 6864 によって更新されました。
^ 「TCP/IP のデフォルトの TTL 値」。2013 年 2 月 12 日にオリジナルからアーカイブ。2013 年 2 月 19 日に取得。
^ 「IP オプション番号」。2012 年 11 月 30 日。2013年 2 月 19 日閲覧。現在推奨されているインターネットプロトコル (IP) のデフォルトの存続時間 (TTL) は 64 です [RFC791]、[RFC1122]。
^ M. Andrews (1998 年 3 月). DNS クエリのネガティブキャッシュ (DNS NCACHE). ネットワークワーキンググループ. doi : 10.17487/RFC2308 . RFC 2308. 提案された標準。RFC 1034 およびRFC 1035 を更新します。RFC 4035、RFC 4033、RFC 4034、RFC 6604 、RFC 8020、RFC 8499、RFC 9499、およびRFC 9520 によって更新されます。

外部リンク

デフォルトの IP パケットの存続時間 (TTL) 値
ループを防止し、ネットワークトポロジを監視するために使用される Gnutella TTL および Hops ヘッダー値

[rfc791-1] J. Postel編 (1981 年 9 月)。インターネットプロトコル - DARPA インターネットプログラムプロトコル仕様。IETF。doi : 10.17487 / RFC0791。STD 5。RFC 791。IEN 128、123、111、80、54、44、41、28、26。 インターネット標準 5。RFC 760 は廃止されました。RFC 1349、2474、および 6864 によって更新されました。

[2] 「TCP/IP のデフォルトの TTL 値」。2013 年 2 月 12 日にオリジナルからアーカイブ。2013 年 2 月 19 日に取得。

[3] 「IP オプション番号」。2012 年 11 月 30 日。2013年 2 月 19 日閲覧。現在推奨されているインターネットプロトコル (IP) のデフォルトの存続時間 (TTL) は 64 です [RFC791]、[RFC1122]。

[rfc2308-4] M. Andrews (1998 年 3 月). DNS クエリのネガティブキャッシュ (DNS NCACHE). ネットワークワーキンググループ. doi : 10.17487/RFC2308 . RFC 2308. 提案された標準。RFC 1034 およびRFC 1035 を更新します。RFC 4035、RFC 4033、RFC 4034、RFC 6604 、RFC 8020、RFC 8499、RFC 9499、およびRFC 9520 によって更新されます。