情報科学苦手の会で発表しました
はじめに
2009/12/06 に開催された情報科学苦手の会で発表をしてきました．各自の苦手な分野を互いに補う趣旨の勉強会です．
苦手といいつつみんなプロフェッショナルな詐欺紛いの勉強会でした．
僕は苦手なネットワーク分野で調子に乗って３本も発表してしまいました．みなさんの貴重な時間を奪って申し訳ないです．
まとめサイトに資料が無いのは，急場で資料を作ったので権利関係の問題がクリアできていないからです．ごめんなさい．
以下に発表のタイトルと内容の要約，補足を書いておきたいと思います．
他の参加者の感想等（随時追加）
kmizu さん： 第一回情報科学苦手の会感想・意見等トラックバック用エントリ - kmizuの日記
shinh さん： 2009-12-08
syuu1228さん： 情報科学苦手の会に参加してきました - syuu1228's blog
NetPenguinさん： 2009-12-06
takesakoさん： 情報科学苦手の会に参加してきました | TAKESAKO @ Yet another Cybozu Labs
cubicdaiyaさん： 情報科学苦手の会 - 考える人、コードを書く人
firewoodさん： 情報科学苦手の会 - firewood's diary
risoufさん： 情報科学苦手の会 - risou style
mowamowaさん： http://d.hatena.ne.jp/mowamowa/20091206/1260108510
Road to the White House -Explore Recent Internet-
自宅のラップトップから www.whitehouse.gov にアクセスするまでにどのような経路をたどっているのかを追いかける発表です．
TCP/IP など個々のネットワーク技術についてはなんとなくわかっているけど，実際に自分の家からインターネットまでどのように繋がっているのかがわからない人向けの発表です．
802.11, Ethernet, VDSL, FTTH, FLET'S, traceroute, AS, CDN あたりがキーワードです．時間が無いので個々のプロトコルの詳細や，DNS, HTTP, routng については省略しましたが，主配線盤まで VDSL だとか，フレッツ網で L2TP だとか，NTT の GIN だとか，中途半端に細かいことを書いたりしました．
フレッツ網は L3 なので LT2P でトンネリングする，といったあたりが，知らない人には何のことかわからなかったかもしれません．もうすこしレイヤーについて詳しくはじめに述べても良かったと思いました．
その筋の人はピンと来るんですが，ホワイトハウスを選んだのは Akamai の CDN について触れたかったからです．世界各地のネットワークの中のサーバ（エッジサーバ）にコンテンツをコピーした上で，元のドメインに CNAME をつけることで Akamai の特殊なネームサーバに誘導した上で，ネームサーバはアクセス元のアドレスから一番近いエッジサーバを計算して，そのアドレスを返し，これによって高速なアクセスが可能になるという仕組みです．詳しくは「geek なページ」さんなどで解説されています．
ちょっと発散した発表になってしまったかなと反省しています．
Google Public DNS and IP anycast
id:hayamiz からの要望があって，ちょうど旬の Google Public DNS の話題について発表しました．Google Public DNS は IP anycast 技術を用いて世界中から高速な名前解決ができるという売りですが，どういう仕組なのかを解説しました．また，IP anycast を用いて DNS を運用する技術は Google 特有のものではなく，RFC に仕様が定義され，一般の DNS でも運用されているという内容を，日本で運用されている M ルートサーバと，a.dns.jp を具体事例に挙げて解説しました．
この発表はASと経路の広告とBGPについて事前知識が無いと意味不明だったかもしれません．スライドも急だったので（当日の朝１時間ぐらいで作った）理解し難い内容になってました．反省です．
Google Public DNS を使うと前述の Akamai が正常に動作しなくなるのでは，具体的には www.whitehouse.gov という名前がアメリカから解決されたらキャッシュされて日本からアクセスしてもアメリカのエッジサーバに飛ばされたりするのでは，という質問がありました．テンパってうまく答えられなかったので，改めてまとめたいと思います．
id:shinichiro_h さんに指摘していただいたように Google の DNS が良く分散配置されていれば，それなりにうまくネットワーク的に近いエッジサーバに飛ばされると思います．ブラックボックスである Akamai のエッジサーバ選択アルゴリズムと Google のネットワークトポロジと Google DNS の実装に依存するのですが，anycast での分散は大雑把なので，Akamai ほどの最適化が得られることはないと考えられます．また，クライアントとDNSサーバが近く，DNSサーバとWebサーバが近くても，クライアントとWebサーバが近くなるとは限りません．単純なアルゴリズムだと Akamai からすると DNS のクエリは Google の AS から飛んできていることしか分かりません．AS レベルでの経路判定を行っていて，Google の AS がアメリカのものだと判定された場合 Akamai はアメリカのエッジサーバを返す可能性もあります．述べた通り Akamai さんのアルゴリズム次第で，やっぱりわからないので，とりあえず試してみました．
DNSサーバ(8.8.8.8)の場所
/Users/yuyarin% traceroute -P ICMP 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 60 byte packets 9 ve-5.alala1.otemachi.wide.ad.jp (203.178.140.215) 3.465 ms 3.408 ms 3.324 ms 10 as15169.dix-ie.jp (202.249.2.189) 3.547 ms 3.274 ms 3.998 ms 11 209.85.241.68 (209.85.241.68) 3.693 ms 10.306 ms 3.550 ms 12 209.85.250.90 (209.85.250.90) 33.724 ms 33.788 ms 33.666 ms 13 209.85.250.101 (209.85.250.101) 35.025 ms 209.85.250.103 (209.85.250.103) 35.000 ms 209.85.250.101 (209.85.250.101) 34.800 ms 14 209.85.241.154 (209.85.241.154) 34.934 ms 209.85.241.158 (209.85.241.158) 37.593 ms 209.85.241.154 (209.85.241.154) 35.025 ms 15 google-public-dns-a.google.com (8.8.8.8) 35.465 ms 36.361 ms 35.435 ms
WIDE[9] から dix-ie 経由[10]で Google[11-15](AS15169) に入っています．RTT も 35ms と，サーバの物理位置も国内だろうとわかります．
東大から www.whitehouse.gov
/Users/yuyarin% dig www.whitehouse.gov ;; ANSWER SECTION: www.whitehouse.gov. 7200 IN CNAME www.whitehouse.gov.edgekey.net. www.whitehouse.gov.edgekey.net. 21600 IN CNAME e2561.g.akamaiedge.net. e2561.g.akamaiedge.net. 20 IN A 96.16.74.135
/Users/yuyarin% traceroute -P ICMP 96.16.74.135 traceroute to 96.16.74.135 (96.16.74.135), 64 hops max, 60 byte packets 10 as2516.nspixp2.wide.ad.jp (202.249.2.110) 1.441 ms 1.383 ms 1.663 ms 11 otejbb204.kddnet.ad.jp (59.128.7.194) 2.936 ms 2.092 ms 1.979 ms 12 kotcbb202.kddnet.ad.jp (59.128.4.26) 5.887 ms 4.575 ms 9.690 ms 13 cm-kot201.kddnet.ad.jp (125.29.22.146) 3.697 ms 3.871 ms 5.658 ms 14 125.29.31.54 (125.29.31.54) 5.104 ms 3.659 ms 4.413 ms 15 a96-16-74-135.deploy.akamaitechnologies.com (96.16.74.135) 4.786 ms 3.378 ms 3.404 ms
発表の時と同じく KDDI[11-14] の中にエッジサーバがあります．RTT は 5ms 以下と，物理的にも非常に近いとわかります．
東大から Google の DNS に問い合わせて www.whitehouse.gov
/Users/yuyarin% dig @8.8.8.8 www.whitehouse.gov ;; ANSWER SECTION: www.whitehouse.gov. 7200 IN CNAME www.whitehouse.gov.edgekey.net. www.whitehouse.gov.edgekey.net. 21600 IN CNAME e2561.g.akamaiedge.net. e2561.g.akamaiedge.net. 20 IN A 118.214.90.135
/Users/yuyarin% traceroute -P ICMP 118.214.90.135 traceroute to 118.214.90.135 (118.214.90.135), 64 hops max, 60 byte packets 8 tokyo2-dc-RM-AE-0-11.sinet.ad.jp (150.99.203.14) 4.635 ms 8.083 ms 4.138 ms 9 lax-gate1-RM-P-7-0-0-11.sinet.ad.jp (150.99.203.62) 105.155 ms 104.958 ms 104.744 ms 10 xe-11-3-0.edge5.LosAngeles1.Level3.net (4.59.48.1) 105.931 ms 104.476 ms 104.576 ms 11 ae-3-80.edge1.LosAngeles1.Level3.net (4.69.144.135) 105.893 ms 105.054 ms 105.423 ms 12 192.205.33.225 (192.205.33.225) 109.359 ms level3-gw.la2ca.ip.att.net (192.205.33.229) 105.311 ms 192.205.33.225 (192.205.33.225) 154.217 ms 13 cr1.la2ca.ip.att.net (12.122.128.10) 119.457 ms 117.247 ms 116.581 ms 14 cr82.sj2ca.ip.att.net (12.122.1.146) 116.015 ms 117.146 ms 116.091 ms 15 gar9.la2ca.ip.att.net (12.122.104.41) 115.963 ms 118.044 ms 115.624 ms 16 12.118.124.94 (12.118.124.94) 184.192 ms 184.611 ms 183.641 ms 17 58.27.104.177 (58.27.104.177) 183.968 ms 184.256 ms 193.955 ms 18 58.27.106.102 (58.27.106.102) 188.201 ms 188.439 ms 58.27.106.106 (58.27.106.106) 185.317 ms 19 118.214.90.135 (118.214.90.135) 185.723 ms 185.324 ms 187.070 ms
SINET[9] の東京 DC2 からロサンゼルスに太平洋を超えて渡って，Level3[10-11] を通って ATT[12-16] を通って，TMNET[17-18] に入ってますね．．．太平洋超えちゃった．．．
TCP/IP/Ethernet Overview
L4 以下をやってほしいと要望があったので，これもやってみました．特に L2 から物理層にかけてが良く知らないとのことなのでそこに重点を置きました．
先頭に立っている TCP にはほとんど触れませんでした．ネットワーク屋さんから見ると IP/Ethernet は自分たちの仕事の範囲だけど，TCP はユーザ側のものなので．．．
Ethernet の主要な規格を紹介した後，Ethernet フレームのフォーマット詳細（Preamble, IFG 含む）を解説し，PCS, PMA, PMD などの物理層側のことを簡単に紹介し，1000BASE-T のエンコード(8B/1Q4) に触れました．Half/Full Duplex，CSMA/CD，MTU，も紹介しました．
IP では ARP と，ルーティングとフォワーディングの違いについて簡単に紹介しました．
時間の問題も合ったので，かなりはしょって，もしかしたら期待に添えなかったと思います．．．
MTU を調整するとスループットが上がるのかという質問については未検証です．RWIN と同時に調整して上がったという報告はよく見られます．
おわりに
アウトプットすると自分の理解の足りていない部分がはっきりと分かって良いですね．たくさんの時間を使って発表したので恐縮していたのですが，何人かの方から好評を頂いたので嬉しかったです．
