パケットが道を見つけるしくみ
ルーターはパケットのTTLを一つずつ減らします。0になるとパケットは捨てられるので、ループにはまったパケットが永久に回り続けることはありません。
ほかの何かを読む前に、シミュレーターを試しましょう。TTLを2にして「送信」を押し、次に64にしてもう一度送ります。1回目にパケットがどこで止まるか見てみましょう。
ドラッグで回転、スクロールまたはピンチで拡大・縮小。
いま見たもの:どのパケットにもあるカウントダウン
TTLが2のとき、どのパケットも2番目に出会うルーターで消え、赤いメッセージが戻ってきました。64のときは、四つのルーターを通り、残り60でサーバーに届きました。IPv4のヘッダーには、生存時間(TTL)と呼ばれる8ビットの欄があるので、その最大値は255です。RFC 791は、どのルーターもこれを少なくとも一つ減らさなければならないとしていて、多くのコンピューターは64から始めます。0になると、ルーターはパケットを捨て、ICMPの「Time Exceeded(時間超過)」メッセージ(RFC 792)を送信元に送り返します。それがあの赤いメッセージでした。
そもそもなぜカウントダウンがあるのでしょう? 経路表のまちがいで、パケットが輪を描いて回り続けることがあります。上限がなければ、そのパケットは永久にリンクを使い続けます。名前には「時間」とあり、RFC 791の文面では秒で測ることになっています。けれども、どのルーターも少なくとも一つは減らすので、実際にはホップの数として働きます。IPv6はこの欄に、もっとわかりやすい「ホップリミット(Hop Limit)」という名前をつけました。
tracerouteボタンは、この決まりを使って地図をかきます。TTL 1の調査用パケットを送ると、最初のルーターがそれを捨てて返事をするので、そのルーターのアドレスがわかります。TTL 2なら2番目のルーターがわかり、行き先が答えるまでこれを続けます。押してみて、作られる一覧を読みましょう。次にR1とR3の間を切ってもう一度送り、パケットが別の道を通るのを見ましょう。
ルーターは表の1行を調べるだけ
あなたのノートパソコンから別の大陸のサーバーまでの道筋全体を知っているルーターはありません。どのルーターも一つのことを決めるだけです。この行き先アドレスなら、次はどの隣にパケットを渡すか。パケットは1ホップ進み、次のルーターがまた決めます。道筋は、こうした一つずつの選択のつながりです。
この判断は転送表から出てきます。転送表はプレフィックスの一覧で、それぞれに使う隣のルーターが書かれています。ルーターは行き先と一致するもののうち、プレフィックスがいちばん長いものを選びます。長いプレフィックスほど、より正確に一致しているからです。たとえば表で、203.0.0.0/16は隣のB、203.0.113.0/24は隣のAへ送るとします。203.0.113.9行きのパケットは両方に一致しますが、/24が勝ってAへ行きます。203.0.7.1行きのパケットは/16にしか一致しないので、Bへ行きます。たいていの表には、それ以外すべてのための既定の項目もあります。家のルーターでは、それはISPを指しています。
| パケットの行き先 | 一致する項目 | 送り先 |
|---|---|---|
| 203.0.113.9 | 203.0.113.0/24(A)、203.0.0.0/16(B)、既定(ISP) | A、いちばん長い(24ビット) |
| 203.0.7.1 | 203.0.0.0/16(B)、既定(ISP) | B、いちばん長い(16ビット) |
| 8.8.8.8 | 既定 0.0.0.0/0(ISP) | ISP |
表を書くのはだれか
一つの会社の中では、ルーターはルーティングプロトコルを使って届けられる先を教え合い、リンクがこわれると新しい道を計算します。インターネットを形づくる何万もの別々のネットワークの間では、ボーダーゲートウェイプロトコル(BGP、RFC 4271)が「198.51.100.0/24に届けられます」といった知らせを運びます。ケーブルが切れると、そこを通る経路は取り下げられ、通信は残っている道に移ります。シミュレーターでR1とR3の間を切ったときに起きたのは、このことです。
なくなるパケットの多くは、いっぱいの待ち行列からこぼれる
ルーターはパケットを待たせることもあります。混み合うときは、出ていくリンクが運べるより速くパケットが着くので、ルーターはそれぞれメモリーに待ち行列を持っています。待ち行列がいっぱいになると、次に着いたパケットはそのまま捨てられます。だれにも知らされず、送信元はあとで気づくしかありません。これがインターネットでパケットがなくなるいちばんよくある原因で、ケーブルが切れるよりずっと多いのです。Wi-Fiの電波が弱くてもフレームがこわれ、捨てなければならなくなることがあります。IP自体は何も約束しません。RFC 791は、IPは信頼性のある通信の機能を提供せず、受信確認も再送もないと述べています。なくなったデータを取り戻すのは両端のコンピューターの仕事で、それが次の単元です。
3,000,000バイトの写真は2055個のパケット
一つのパケットの大きさにはリンクによる上限があります。イーサネットでは、一つのフレームが運べるデータは最大1500バイトです(RFC 894)。IPv4ヘッダーの20バイトとTCPヘッダーの20バイトを引くと、一つのパケットにはあなたのデータが約1460バイト入ります。だから3,000,000バイトの写真には3,000,000 ÷ 1460 ≈ 2054.8、切り上げて2055個のパケットが必要で、その一つずつが別々に経路を選ばれます。
- TTL 64で出発したパケットが4台のルーターを通りました。着いたときのTTLはいくつですか?
- TTLは8ビットの欄です。入る最大の値はいくつですか?
- パケットのTTLが0になると、ルーターはどうしますか?
- パケットを捨て、送信元にICMPのTime Exceededを送る
- TTL 64にして送り出す
- 送信元に送り返す
- ネットワークが空くまで持っておく
- TTLはなぜあるのですか?
- 経路のループにはまったパケットが永久に回り続けないように
- 光の速さを測るため
- Webページをどれだけの間キャッシュしてよいかを示すため
- ファイルのパケットを数えるため
- tracerouteがTTL 1の調査用パケットを送ります。答えるのはだれですか?
- 道筋の最初のルーター
- 行き先のサーバー
- DNSリゾルバー
- だれも答えない
- 表に203.0.113.0/24 → Aと203.0.0.0/16 → Bがあります。203.0.113.9行きのパケットはどこへ行きますか?
- A
- B
- 両方
- どちらでもない
- 同じ表です。203.0.7.1行きのパケットはどこへ行きますか?
- B
- A
- 両方
- 捨てられる
- 一つのパケットに約1460バイトのデータが入ります。3,000,000バイトのファイルには何個のパケットが必要ですか?
- インターネットの別々のネットワークの間で経路の知らせを運ぶプロトコルはどれですか?
- BGP
- DNS
- HTTP
- UDP
- シミュレーターでR5とサーバーの間を切りました。どうなりますか?
- 何も届かない。サーバーにはリンクが一つしかない
- パケットはR4を回って進む
- パケットが速く着く
- UDPのパケットだけが届く
- 「どのルーターも、サーバーまでの道筋全体を知っている。」 それぞれのルーターは、転送表から次のホップを選ぶだけです。道筋はそうした一つずつの選択がつながってできるもので、同じメッセージのパケットでも別々の道筋を通ることがあります。
- 「TTLは、パケットに残っている秒数だ。」 RFC 791はたしかに秒で説明していますが、どのルーターも少なくとも一つは減らさなければならないので、実際にはホップを数えています。IPv6はホップリミットと名前を変えました。DNSレコードのTTLは同じ名前の別の値で、こちらは本当に秒です。
- 「なくなるパケットのほとんどは、こわれたケーブルが原因だ。」 ほとんどは、待ち行列がいっぱいになった混み合うルーターで捨てられます。Wi-Fiの電波が弱くてもフレームがこわれます。ケーブルが切れるのはもっとまれで、ルーターはたいてい通信をそこから迂回させられます。
- 「IPは、すべてのパケットが届くように面倒をみる。」 RFC 791は、IPは信頼性のある通信の機能を提供しない、受信確認も再送もないと述べています。回復させるのは両端の2台のコンピューターで、ふつうはTCPを使います。
- ルーターは転送表を使って1ホップずつ決める。いちばん長く一致するプレフィックスが勝つ。
- BGPはネットワークの間に経路の知らせを広め、リンクがこわれると経路を取り下げる。
- TTL(IPv6ではホップリミット)はルーターごとに1減る。0になるとパケットは捨てられ、ICMPが知らせる。
- tracerouteはTTL 1、2、3…と送って道筋の地図を作る。
このコースの出典 (28)
- (checked 2026-10-17; reordered 2026-10-19: standards first, then official documentation, then operators and papers, history sources last)
- IETF RFCs (rfc-editor.org): RFC 768 UDP (1980, 8-byte header)
- RFC 791 IPv4 (1981, 32-bit addresses, "does not provide a reliable communication facility", TTL field "measured in units of seconds" but every module must decrease it by at least one, so it is only an upper bound)
- RFC 792 ICMP (Time Exceeded)
- RFC 801 NCP/TCP transition plan (1 January 1983)
- RFC 894 Ethernet (1500-byte payload)
- RFC 1034 and RFC 1035 DNS (1987, HOSTS.TXT kept by SRI-NIC, labels up to 63 octets and names up to 255, TTL in seconds)
- RFC 1122 (127.0.0.0/8 loopback)
- RFC 1918 private addresses (10/8, 172.16/12, 192.168/16)
- RFC 2131 DHCP, RFC 3022 NAT, RFC 3596 AAAA records, RFC 3849 and RFC 5737 documentation addresses, RFC 4271 BGP-4, RFC 4291 IPv6 text form, RFC 6298 TCP retransmission timer (initial RTO 1 second)
- RFC 6335 port ranges (0-1023, 1024-49151, 49152-65535)
- RFC 7766 DNS over TCP, RFC 8200 IPv6 (128-bit addresses, Hop Limit)
- RFC 8446 TLS 1.3 (one round-trip handshake)
- RFC 9000 QUIC and RFC 9114 HTTP/3, RFC 9110 HTTP semantics (status code classes)
- RFC 9293 TCP (three-way handshake, sequence numbers)
- IANA: ip-parameters registry (recommended default TTL 64)
- IPv4 free pool depleted 3 February 2011 (NRO and ARIN announcements)
- Official documentation: MDN Web Docs "How does the Internet work?" (45 cables for 10 computers, switches, routers, MAC and IP addresses, internet and web)
- "What is a URL?", "HTTP response status codes" (developer.mozilla.org)
- Cloudflare Learning Center: "What is DNS?" (four kinds of DNS server, 8 steps of an uncached lookup, browser and OS caches, TTL)
- "What is HTTP/3?" (cloudflare.com/learning)
- Google Chrome Help, "Browse in Incognito mode" (support.google.com/chrome/answer/95464, checked 2026-10-19: Incognito limits what is saved to the device; websites and organisations that manage your network, like your school, employer or internet service provider, may be able to observe your activity)
- Operators and papers: root-servers.org (13 root name servers run by 12 organisations, 2047 instances on 2026-10-17)
- Jacobson and Karels 1988, Congestion Avoidance and Control (loss mostly congestion)
- History blocks only: UCLA Samueli School of Engineering, Internet50 (first ARPANET message "LO", UCLA to SRI, 29 October 1969, 22:30)
- historyofinformation.com and Wikipedia ARPANET (Kline)
- Spiceworks/SRI history (HOSTS.TXT kept by SRI-NIC)
- Numbers (2^32, 2^96, 45 and 6 cables, packet counts, round-trip times)
確認日: 2026-10-17