もしインターネットの１秒が１年だったら 第1回（vol.47掲載）
written by hakatashi・Mine02C4
編注：本記事は「SunPro 2016 技術書典」で発表された記事に説明・イラストを追加し、シェルマガvol.47に掲載したものです。
以下リンク先で、オリジナル版の全文が公開されています。
https://sunpro.io/techbookfest/
インターネットが日本中のあらゆる人間に行き渡るようになってから、すでに10年単位の時間が経過しています。今日においてインターネットを支えるネットワーク技術が重要であることは言うまでもありませんが、実際にネットワークでどのタイミングで何が起こり、どれくらいの時間が費やされるのかということを身を持って体感している人は、たとえネットワークに精通している人でも少ないのではないでしょうか？ この記事では、1 秒というわずかな時間を1年にまで拡大し、ネットワーク上で何が起こっているかを人間スケールでざっくりと解説していきます。
はじめに
こんにちは。先号まで石川啄木を蘇らせようとしていた博多市(@hakatashi) です。今回から、2016年の技術書典にSunProとして発表した「インターネットの1秒がもし1年だったら」というだいぶ抽象的で怪しい記事を、シェルスクリプトマガジン向けに再構成してお届けします。
インターネットというのは光の速さを身をもって感じることができるメディアです。先日、Hiraku Nakanoさんの「composerの遅さをまじめに考える」というスライド*1を拝見したのですが、そこではPHPのパッケージマネージャーであるcomposerが遅い原因として、「光の速さが遅すぎる」という理由が挙げられていました。
ユニークな考え方ですが言われてればたしかに道理で、日本からアメリカのサーバーまでハンドシェイクで何度も往復していると、確かに光といえど100ミリ秒単位で時間を浪費しています。
サーバーが近ければ通信は早いというのは誰もが知っていることですが、光の速度のせいだと言われるとなにやら圧倒されるものがあります。
この記事では、そんなネットワークの微視的な時間スケールについて徹底的に解剖します。一回の通信を解析し、それぞれ時系列順に細かく分解し、それぞれの操作でどれくらいの時間が費やされ、どんなイベントがいつ発生するのかを逐一追っていきたいと思います。
とはいえ、ネットワーク通信における時間経過はミリ秒単位で数えられます。今回は、そんな微細な時間の移り変わりをなるべくわかりやすくするため、通信上の1秒という時間を1年にまで引き伸ばし、約3000万倍の時間スケールでネットワークのイベントを追跡してみます。
*1 http://www.slideshare.net/hinakano/composer-phpstudy
共著者について
本記事の筆頭筆者はhakatashiですが、今回の記事を書くにあたり、同じSunProメンバーでありネットワークスペシャリスト取得者のMine02C4*2から、企画段階からの多大な協力と大幅な加筆を得ることができました。
ネットワーク知識不足のhakatashiにパケット解析を指南し、本記事では特にTLS 関連の項目の執筆、および全体のレビューを担当しています。共著者として名を連ねていますが、彼の協力なしでは本記事は恐ろしくクオリティの低いものになったであろうことは疑いようがなく、その貢献度に関しては計り知れません。どうぞお見知り置きください。
*2 HP: http://mine02c4.nagoya/, Twitter: @mine_studio
シチュエーション
今回解剖する対象の通信として、HTTPSによる通信をメインに解析しました。ふだん我々がブラウザから毎日使っているプロトコルなのは言うまでもなく、SSL/TLSの処理を挟むので、それなりに面白い結果になるのではないでしょうか。
また、HTTPS通信を行う際に必要となるARPやDNS通信についても述べていきます。さらに、通信を行うサーバーとクライアントの場所ですが、今回は、技術書典の会場でもある東京のインターネット環境から、さくらインターネットが誇る、北海道の石狩データセンターまでの通信を行います。
Googleマップによると、東京から、石狩データセンターがある石狩市新港中央までは1177.3km。光ファイバーに用いられる石英ガラスの屈折率は1.50程度*3なので、光は約20万km/sでこの距離を移動します。つまり、東京から石狩までの物理的な片道時間は約5.9ミリ秒となります。瞬く間もないほどの時間ですが、時間スケールを1年に引き伸ばすと2日と3時間半もかかります。往復で4日と7時間。石狩までぶらり旅といった感じですね。
1秒 → 1年
1秒が1年になった世界の様子をもう少し見てみましょう。
真空中の光は時速34kmで移動します。先ほど出てきた光ファイバー中の光速は時速23km程度になるので、自転車か、休憩しながらのドライブ旅程度の速さになります。ちなみに男子マラソンの世界記録は時速20.6kmです。*4*5
3GHzのCPUは、こんな世界でも1秒間に95回という高橋名人の6倍のクロックを刻みます。PC3-12800のメモリーの転送速度は、もはやダイアルアップ接続よりも遥かにナローバンドですが、最大で1秒間に3200ビットの情報を読み出すことができます。
*4 2014年ベルリンマラソンのデニス・キメット選手の記録、2時間2分57秒より。
*5 ただし、この速度で走行するとこの世界では体重が26% 増えるのでオススメしない。
制約など
今回パケットを解析する上で、話を簡便化するためにいくつかの制約を加えています。
● DNSのシステムを明確に示すため、ローカルホストにDNSサーバーを置き、そこからリクエストのたびにルートDNSサーバーからアドレスを引いています。
● 複雑かつ時間がかかりすぎるため、ネームサーバーでのDNSSECの検証処理は無効化しています。
● SSL/TLSの証明書検証処理は無効化しています。
測定環境
測定には、ラップトップマシン上のUbuntuの仮想環境を使用しました。一回の測定ごとにDNSキャッシュとARPキャッシュをクリアし、なるべくクリーンな状態で測定を行いました。
また、先程も述べたとおりDNSサーバーはローカルホストに設置し、そこから外部に向けてアドレスを引くようにしました。
サーバーは先ほど述べたさくらの石狩データセンターへのアクセスを確実に測定するため、今回の記事のためにさくらVPSの石狩リージョンのサーバーを調達しました。OSはさくらVPSの初期OSであるCentOS 6.8で、デフォルトのApache 2.2.15をほとんどそのまま使用しました。SSL は自己署名証明書で通信し、証明書の検証は無効化してあります。
クライアントは、Windows上の仮想マシンのUbuntu 14.04.4を用いました。クライアントアプリケーションはcURLを用いています。ネームサーバーはローカルホストにBIND 9.9.5を立て、キャッシュを無効化した上でルートサーバーからアドレスを引くよう設定してあります。
通信内容は、100KB(102400 バイト)のバイナリファイルをGETリクエストで取得するもので、HTTPパラメータはほぼcURLのデフォルトを使用しています。
パケットキャプチャはクライアント側とサーバー側で同時に行い、tcpdumpで同じ通信を2度キャプチャして解析しています。時刻に関しては毎度NTPで時刻補正しましたが精度が得られなかったのでサーバー側とクライアント側の測定値を見て適当に補正を行いました。
今回記事中で使用した数字は、以上の条件のもとに行った10回の測定結果の平均値をもとにしています。
サーバーちゃんとクライアントちゃん
サーバーちゃん 
クライアントちゃん
今回、せっかく時間軸を人間スケールで語るので、通信処理の登場人物も人間という体で解説していきます。
この話の主人公は「クライアントちゃん」と「サーバーちゃん」です。クライアントちゃんは東京で悠々とした生活を送っている普通の女の子であり、趣味は暗号と文通です。一方サーバーちゃんは石狩のデータセンターで、ひしめき合うたくさんのサーバーとともに、Webサーバーとして多忙な毎日を送っています。
こんな対称的な2人が、今回は年明けと同時に通信を開始します。さらに、通信は手紙のやり取り、IPアドレスは住所、ルーターは郵便ポスト……というように、適宜シチュエーションに合わせた読み替えを行っていきます。あくまで例えですので、あまり正確ではないかもしれませんが、今回の目的はあくまで通信処理の全貌をふわっと理解することなので、あまり厳密に考えず、空っぽの頭で読んでください。
また、今回解説する通信処理の概略を、簡単なシーケンスダイアグラムで示します。通信処理の主役は情報をやり取りするサーバーちゃんとクライアントちゃんなのですが、第1回は2人の通信が開始するまでの準備作業が主となり、サーバーちゃんはまだ登場しません。インターネット通信において目的のサーバーのアドレスを見つけるためにどのような処理が行われているのかを一段階ずつ検証していきます。
それでは、クライアントちゃんとサーバーちゃんの通信の始まりです。
ルーターのアドレス解決
1月1日 午前0時0分 ARPリクエスト送信
あけましておめでとうございます。NHKの「ゆく年くる年」を見ながらインターネットの年が明けます。
この瞬間、東京でまったりと紅白歌合戦を見ていたクライアントちゃんは、石狩にいるサーバーちゃんに聞きたいことがあるのを思い出しました。長い長い通信の始まりです。
さっそくクライアントちゃんはサーバーちゃんに手紙を書くことにしました。
クライアントちゃんは何もわかりません。郵便ポスト(ルーター) の場所も、サーバーちゃんの住所(IPアドレス) も、いつも使っていた住所録(DNSサーバー) の場所も覚えていません。
キャッシュを削除したクライアントちゃんは記憶を失ってしまったのです。
覚えているのは、ただ石狩にいるはずのサーバーちゃんのことだけ……。
困ったクライアントちゃんは、まずは郵便ポスト(ルーター) を探すことにしました。家の中や向こう三軒両隣のことならともかく、遠く石狩に住むサーバーちゃんに手紙を届けるには、何よりポストがなければ話が始まりません。
クライアントちゃんはもうネットワークに接続しているので、ルーターのIPアドレスはすでに分かっています。しかし実際にルーターと通信するには、ルーターのMACアドレスが必要です。これを引くために、ARP（Address Resolution Protocol）と呼ばれるプロトコルを用います。
ARPリクエストはIPアドレスに対応するMACアドレスを検索するリクエストです。MACアドレスのプロードキャストアドレス(FF:FF:FF:FF:FF:FF) に向けて発信することで、同一ネットワーク内のすべての機器にこのリクエストを送信することができます。クライアントちゃんは街中に響く声でポストの場所を尋ねました。
「郵便ポストはどこですかぁぁぁぁ？？！！」
1月1日 午前3時26分 ARPレスポンス受信
いったい今何時だと思っているんでしょうか。クライアントちゃんの声は街中に響き渡り、近隣住民からたいへん大目玉を食らいましたが、努力の甲斐あって、3時間半後に親切な人がポストの場所を教えてくれました。
ARPは、ブロードキャストでネットワーク全体に配信されたイーサネットフレームに対して、尋ねられているIPアドレスが自分のものであればMACアドレスを応答するというシンプルな仕組みで動作します。
今回は事前にARPキャッシュを削除してから通信を行ったので、通信前に必ずARPの問い合わせが走るようにして計測したのですが、そもそもARPは頻繁にキャッシュを消去します。*6クライアントちゃんはとても忘れっぽいのです。
*6 Ubuntu の場合、キャッシュの有効時間は15 分程度。
DNS解決
1月1日 午前5時7分 DNSクエリ送信 1回目
親切なおじさんのおかげで、クライアントちゃんは郵便ポストの場所を知ることができました。
またすぐ忘れてしまうのですが、この世界では約900年後のことなので、特に気にすることはありません。
となると次にクライアントちゃんが知るべきはサーバーちゃんの住所(=IPアドレス) です。郵便ポストを見つけても相手の住所がわからないと手紙は送れません。サーバーちゃんの住所を知るために、クライアントちゃんはルートサーバーに住所を問い合わせることにしました。
電話番号に電話番号問い合わせサービスがあるように、ネットワークの世界にも、ドメイン名から相手のアドレスを問い合わせるためのDNS（Domain Name Service）があります。
電話番号の場合は104番という番号を知っていれば他の番号を問い合わせることができます。
インターネットにおける“104”は、世界に13個存在するルートサーバーのアドレスです。今回は、13個の中で唯一日本の団体が管理している、Mルートサーバーに問い合わせるようにルートサーバーの設定を変更しています。*7
サーバーちゃんの住所を一秒でも早く正確に知りたいクライアントちゃんは、世界中に数あるDNSサーバーの中でも最も権威あるルートサーバーに一筆したためることにしました。あらゆるキャッシュを削除したクライアントちゃんも、一番大事なルートサーバーの住所は覚えています。
あれこれ悩んで手紙を書き、ようやく完成したのはそれから1時間半後のことでした。早朝の冷たい冬風が骨身に染みます。クライアントちゃんはコートを厚めに羽織ってポストに手紙を投函しに行きました。
一刻も早く返事が帰ってくることを願って……。
「うぅっ、さぶっ。早くお返事来るといいなぁ」
*7 もっとも、ルートサーバーはクラスタ構成になっており国単位で分散しているため、必ずしも問い合わせたマシンが日本に存在するかどうかは保証されないのですが…。
1月14日 午前3時57分 DNSレスポンス受信 1回目
最初に手紙を送ってから2週間が経過しました。冬休みも終わって正月気分もようやく抜けてくる頃です。もうこの時点で直接会いに行ったほうが手っ取り早いんじゃないかという気がしますが、石狩は遠いのです。そんな気軽に会いに行けないのです。たぶん。
ともあれ、ルートサーバーからようやく返事が帰ってきました。郵便局が怠慢なのかルートサーバーがお役所仕事をしてるのか知りませんが、とにかくこれでサーバーちゃんの住所を知ることができた……というわけではありません。
ルートサーバーは世界中のすべてのマシンのIPアドレスを記録しているわけではありません。
ドメイン名を問い合わせられたDNSサーバーは、自らが委任するDNSゾーンのネームサーバーの情報を返します。今回問い合わせたドメイン名はさくらのVPSサーバーにデフォルトで割り当てられたドメイン*8なので、ルートサーバーはjpサブドメイン*9のネームサーバー*10を返してきました。つまりjpドメインのことはjpドメインの担当者に聞けということです。
「えー……」
*8 .vs.sakura.ne.jp で終わるドメイン名
*9 .jp はTLD(Top Level Domain) なのでサブドメインと呼んでいいか微妙ですが……
*10 a.dns.jp, b.dns.jp, c.dns.jp, d.dns.jp, e.dns.jp, f.dns.jp, g.dns.jp の7 つ
1月14日 午前9時52分 DNSクエリ送信 2回目
jp ドメインの担当者というのは要はJPRS（日本レジストリサービス）のことです。サーバーちゃんの住所を聞き出す手がかりを得たクライアントちゃんは、夜が明けるのを待ってから今度はJPRSのDNSサーバーに対して手紙を書きました。
実を言うと、jpドメインのネームサーバーを管理しているのはJPRSその人ですが、実際の運用は、JPRSを含めた5つの独立した組織によって行われています。これはルートサーバーが世界に13個あるのと同じく、ネームサーバーがダウンした際のリスクを可能な限り最小限に抑えるためです。
2 回目のDNSレイヤーの内容は、トランザクションIDを除いて前回ルートサーバーに対して送ったのと全く同じ内容です。DNSはなるべく高速に動作するように簡明に設計されているため、このようにパケットの内容を容易に再利用できるようになっています。決してクライアントちゃんがサボっているわけではありません。
1月27日 午後2時30分 DNSレスポンス受信 2回目
ふたたび待つこと2週間。すでに1月が終わりに近づいてきました。
クライアントちゃんの元にJPRSからの返信が届きました。サーバーちゃんの住所はまだわかりません。今度はsakura.ne.jpの権威サーバーである、さくらインターネットのネームサーバー*11の情報が返ってきました。
「……またかよ」
ここに来てようやくさくらインターネットの影に辿り着きました。サーバーちゃんの住所ゲットまであと一息です。
*11 ns1.dns.ne.jp, ns2.dns.ne.jp
1月27日 午後6時56分 DNSクエリ送信3回目
同じやり取りも3回繰り返すと飽きてしまいますね。けれどクライアントちゃんはサーバーちゃんに手紙を届けるために、めげずにDNSのパケットを送り続けます。今度は先ほど入手したさくらインターネットのネームサーバーの住所に対して、みたびサーバーちゃんの住所を尋ねる手紙を出します。
ところで、先ほどからクライアントちゃんは気軽にあちこちにDNSパケットを送ったり受け取ったりしていますが、これはDNSがUDPプロトコルの上で動作しているからです*12。UDPは、後ほど解説するTCPと異なり、相手のマシンとの接続を確立する必要がないため、気軽に任意のアドレスにいきなりデータを送りつけることができます。
逆に言うと、TCPのような再送要求やエラー訂正などの機能を持たないため、伝送経路のどこかでパケットが損失した場合、クライアントちゃんは返事を待ちぼうけということになってしまいます。
もっとも、それもタイムアウトするまでですが。
*12 DNS自体はTCP上でも動作することが義務付けられています。
2月10日 午前9時35分 DNSレスポンス受信 3回目
2月に突入しました。幸い3度目のクエリも待って待って待ちぼうけという事にはならず、ポストに投函してから2週間経って再び返事が帰ってきました。そこには待ち望んでいたサーバーちゃんの住所がくっきりと書かれています。
これにて名前解決完了。ようやくサーバーちゃんに対してパケットを送りつけることができるようになります。もうあちこちのネームサーバーとパケットをやりとりする必要はありません。年が明けてから41日間、実時間にして110ミリ秒が経過しました。この調子で年内にサーバーちゃんとの通信を終えることができるのでしょうか。クライアントちゃんの通信はまだまだこれからです。
「この続きはシェルマガvol.48、またはオリジナル版掲載サイトを見てねっ！」
本記事掲載のシェルスクリプトマガジンvol.47は以下リンク先でご購入できます。
