[ネットワーク] RFCとエイプリルフール

RFC(Request For Comments)というものがあります。これはコンピュータネットワークの通信仕様やファイルフォーマットなどの技術仕様の集まりであり、情報をリクエストとして公開することで推敲＆改版を重ね、より良いものにしていくという目的の下に始められたものです。

全てのRFCはインターネット上で全文を読むことができます(素晴らしい！)。

さて、このRFCで面白いのが、毎年エイプリルフールにちなんで数件のジョークRFCが公開されていることにあります。過去において有名なのが例えば「伝書鳩プロトコル(RFC 1149など)」「コーヒーポット制御プロトコル(RFC 2324)」として、他の真面目なRFCと同列に公開されています。

伝書鳩によって情報を伝える方法はどういう特性があり、注意点は何であるかなどが大真面目に書かれているからなかなか面白いです。

そして今年は、次の２つが公開されました。

• "IANA Considerations for Three Letter Acronyms" (RFC 5513)
• "IPv6 over Social Network" (RFC 5514)

前者はIANAで扱う３文字熟語が増えてきて困るので、それを登録管理性にしようという自虐ネタ。そして後者は一向に広がりを見せないIPv6に対して、MixiやMySpace, FacebookなどのソーシャルネットワーキングサービスでIPv6を採用することによって事例を一気に増やしてしまおうという、これまた自虐ネタ。

後者はIPv6関連の業務に携わった経験がある身としては、なんとも苦い味のするジョークでした。

[Network] LeopardのTCP再送アルゴリズム

今日はTCPについて色々と調べたり、データをキャプチャしていた１日でした。
その中で、Mac OSX10.5(Leopard)のTCPでちょっと気になったので記します。

TCPの「高速再転送アルゴリズム(Fast retransmission algorithm)」といえば、重複ACKを3回連続して受け取った時に直ちにパケットを再送する仕組みです。
ところが、Leopardのパケットをキャプチャしていたら、重複ACKを3回受信する前にパケットを再送しているところがありました。

おかしい。
RTOもまだ余裕があるので、通常のスロースタートに遷移する再送では決してありません。

まだ調べている最中なのですが、どうもLeopardのTCPはACKの返ってくる時間によるFast Retransmissionアルゴリズムが実装されているようです。
その仕組み、出典がどんなものかゼンゼン見当もついていないのですが、まずはメモとして残しておきます。

この記事、何か分かったら後で追記します。
ネットワーク屋でなければ意味分からない記事ですみません。

(2008/5/20追記)

両者のカーネルソースを読み比べています。カーネルのソースはAppleのサイト：http://www.opensource.apple.com/darwinsourceから手に入るもので（要ADCアカウント）、とりあえず差の大きい10.3.9と10.5.2のソースを比較してます。

ものすごい数の違いがあって苦戦しているものの、収穫は上がっています。TCPパケットの受信部(tcp_input.c)で目立つところでは、

• 高速再転送アルゴリズムが有効になる重複ACKの受信数が10.3.9の3から10.5.2の2に変更されている
• MSS DoS攻撃に対する防御策が張られている(MSSを極端に小さくしてコネクションを開設させ、その上で大量のデータを遅らせることによるDoS攻撃)
• T/TCPが廃止されている
• RFC3465の導入
• 未使用で開いたままのTCPコネクションを積極的に閉じる処理が追加されている（メモリ消費の改善？）

こんなところ。でも、時間による高速再転送処理は見つかりませんでした。重複ACKの受信数が減っていることが両者の違いなだけなんだろうか？

[Network] 久しぶりぶりの学会誌読み

会社の一人が電子情報通信学会に入っていて学会誌も購読していることを知り、頼み込んで学会誌を見させてもらいました。数年ぶりのScholar気分です。気分だけですが。

って、電子情報通信学会って学会誌と論文誌とは分冊なのね。論文を期待していた身としてはがっかり。
でも学会誌にも論文誌の方の目次だけは載っていたので、ざっと目を通したところ、ネットワークでは未だMANET(Mobile Ad-hoc NETwork)が盛んに議論されていることに気づきました。

確か数年前もMANETが盛り上がっていたと思うんだけど、まだまだ現役なんだね。

・・・うーん、でもなあ。MANETかぁ。

ユビキタスとかRFIDとか、IPv6とかの延長で論じられている可能性が高いんだけれど、本当にそんな時代が来るんだろうか。
決定打はIPv6だとは思うけれど、いかんせんIPv6は全然セキュアじゃない。いや、語弊が無いように言うとIPv6はIPsecによってP2P通信のセキュリティを高めることを意図しているんだけれど、IPsecは実際に動かすには重すぎるんですよ。セキュアであることを突き詰めすぎて、誰も届かない高みに上っていってしまった感じ。電池で動かすデバイスで動作させるにはちょっと厳しい。
そうなるとIPv6の「自分の身は自分で守る」的姿勢がむしろ仇になってしまい、全然セキュアに通信できなくなってしまう。MANETはバケツリレーのようにノード間で助け合って情報を運ぶので、中継ノードには情報が漏れまくり。

そんな中でMANETに期待するのはちょっと無理があるかなと、将来に悲観的になってしまうのでした。
性善説にしたがった、昔の清く正しいインターネット世界だったらとても面白い、未来のある技術だと思うけれどね。

最近体重が70kgを切ったところで停滞しているボクの、駄文でした。

(2008/5/16追記)
GoogleがIPv6によるアクセスをサポートした、と宣言しました。検索業界の最大手がとうとうIPv6をサポートしたのか、という驚きのニュースです。

そうなると次は各種プロバイダがどこまで追従するか、というのが問題。いくらWebサイトがサービスを提供しても、そこへIPv6でアクセスするための道が無ければ意味がないですからね。

でも、日本では当分先なのかなあ、と思います。プロバイダとしては最大手の1つであるNTT BフレッツのIPv6サービスでは、信じられないことに「本アドレスはNTT東日本が提供するサービスでの利用を目的に割り当てるものであり、インターネット接続等で利用することはできません」という、意味ないじゃん的のひどい有り様。Yahoo!BBも2005年の試験サービス以降のニュースはないし、今後しばらくは何も変わらない世界なんでしょう。

[Network] SNMPパケットの構造

SNMPパケットの構造を勉強したので、メモ。

■SNMPパケットはBERによって成り立っている
SNMP(ここではoverIP)パケットは、フィールドのすべてがBER(Basic Encoding Rule)というルールのもとで記述されています。これは

• タグ　(Tag)
• データ部の長さ　(Length)
• データ部/値　(Value)

というTLV形式とも呼ばれる構造の組み合わせで成り立っている、と言い換えられます。タグ部(T)にはコマンドや値の型も引っ括めて定義されていて、SNMPv1では以下の情報が存在します。

• INTEGER(0x02)　整数型
• OCTET STRING(0x04)　可変長のバイト列、文字型、MACアドレス等
• NULL(0x05)　値なし
• OBJECT ID(0x06)　オブジェクトID
• SEQUENCE(0x30)　TLVが入れ子になっている
• Ip Address(0x40)　IPアドレス
• Counter(0x41)　カウンタ値
• Gauge(0x42)　ゲージ値
• Time Ticks(0x43)　TimeTick値
• Get-Request(0xA0)　SNMP Get-PDU
• Get-Next(0xA1)　SNMP Get-NextPDU
• Get-Response(0xA2)　SNMP Get-ResponsePDU
• SET-Request(0xA3)　SNMP Set-RequestPDU
• TRAP(0xA4)　SNMP Trap-PDU

データ部の長さ(L部)とオブジェクトIDは最上位ビットがデータの連続性を表す7bitエンコーディングで定義され、それ以外のデータ部(V)は原則8bitエンコーディングで表されます。

例えば「20という数値(Integer)」は、TはIntegerなので0x02、Lは255以下で1バイトで表現できるので0x01、Vは20の16進表記で0x14、ということで

　【0x02 0x01 0x14】

というように表現します。「'20'という文字」であればOCTET STRINGでASCII表現をするだけなので、

　【0x04 0x02 0x42 0x40】

です。ちなみにOCTET STRINGはLがしっかり定義されているので、途中でヌル文字(0x00)が混じっていてもよく、またヌル終端である必要もありません。そのためMIBではビット列の表現によく使われています。

SEQUENCEの例も挙げておきます。「上の2つをまとめた集合」とした場合に、

　【0x30 0x07 0x02 0x01 0x14 0x04 0x02 0x42 0x40】

となるだけです。「T:0x30/L:0x07(3+4)/V:データの羅列」となっているのが見て取れるでしょうか。

■SNMPパケットフォーマット
SNMPパケットは、徹頭徹尾このTLVの組み合わせで構成されています。GetRequestの場合の構造を例示します。

SEQUENCE
｜　INTEGER (バージョン(SNMPv1は0固定))
｜　OCTET STRING (コミュニティ("public"))
｜　Get-Request (コマンドの種類)
｜　｜　INTEGER (ユニークなID)
｜　｜　INTEGER (error status。エラーコード)
｜　｜　INTEGER (error index。何番目のOIDがエラーか)
｜　｜　SEQUENCE
｜　｜　｜　SEQUENCE
｜　｜　｜　｜Object-ID
｜　｜　｜　｜Null (0x05 0x00)

上記のとおりです。縦棒「｜」は上のタグで示すLengthの範囲を表します。レスポンスや設定時のときもほとんど同じフォーマットです。フォーマットの例外はありません。

したがってBERさえ分かってしまえば、ダンプデータからSNMP情報を読み取ることも可能になります。
思っていたよりも簡単なルールで成り立っているんですね。

あ、ちなみにSNMP over IPはUDPパケットなので

　｜IPヘッダ｜UDPヘッダ｜SNMPパケット｜

という構造になっています。ポート番号は161です。

−−−

え？なぜこんなことを調べているかって？それは、前回pySNMPのexe化で挫折したことが悔しいので、自分でSNMPライブラリを作ろうとしているからです。

Getは出来るようになったので、あとはSetさえ実装すれば動くようになってくれるはずです。ただ、後悔する場合にはwalkやGetNextも実装しておかないと。

また進捗報告をさせてください。

[Network] なぜWiresharkではchecksum errorが頻発するのか

仕事柄、Wireshark(Ethereal)でネットワークトラフィックをキャプチャすることがよくあります。

ところが自分を含めたキャプチャ結果をいざ見ると、結構な頻度(というよりもほぼ100%)で、送信されているTCPパケットのチェックサムが正しくない(checksum error)と出てしまい、解析の妨げになっていました。しかもerrorなのに通信は普通に続いているので、意味が分かりません。

気になってしょうがなかったのでインターネットで調べてみたところ、原因が分かったので記録しておきます。

どうもNICには「checksum offloading」という機能があるようで、この機能がONになっていると、TCPパケット等のチェックサム計算をOSではなくNICドライバ内で行ってくれます。昨今のGigabit Ethernetなどでは色々をCPUに行わせると負荷が半端無く大きくなってしまいますので、なるほど便利な機能です。

しかしこれが有効になっていると、OSでパケットキャプチャするWiresharkでは、この後NICでチェックサム計算する前の内容をキャプチャしてしまうため、checksumが不正(＝計算前)な値で記録されてしまいます。

これがchecksum errorが発生する原因でした。

余談ですが、同様に昨今のPHYチップはEthernetフレームが届くたびに割り込みをCPUにかけるのではなく、データが届いているというフラグだけ立てておいて、そのままバッファリングしておくようになっています（CPUはそれをポーリング）。そうすることで割り込み増加によるCPU負荷の増大を抑えているわけです。

また、CPU以外に処理を行わせることで負荷を下げるというアイデアはGPU-CPU間でも用いられていて、WindowsVistaであればAero、MacOSXであればCore ImageやCore Graphics Extremeがこのアイデアを活用しています。OpenGLやDirectXもそう。

そこで対策はというと、どうやらWiresharkを使う場合に「checksum offloadingを無効」にしたり、「Wiresharkでchecksum errrorを無視」するくらいしかないようです。速度や他PCの解析の妨げになるので、トレードオフです。

困ったものです。

L2スイッチのミラーポートにつないだ別のPCでキャプチャすればいいじゃない、なんていうマリーアントワネットさんは帰ってください。

[Network] TCPコネクションのスケーラビリティ

LinuxのTCP実装では受信ウィンドウサイズ（SO_RCVBUF）を設定すると、内部ではその2倍の領域が当該コネクション用に確保されます。

例えばデフォルト(ディストリビューションによる)では64KBが受信ウィンドウサイズとして用いるので、内部では128KBが1コネクションにつき消費されているわけです。意外と消費するものなんです。

このことは組込み分野などのメモリ制約が厳しい領域では要注意部分として周知されているものの、PCなどのアプリケーション、Webアプリケーションではあまり意識されていません（多分）。メモリは潤沢にありますし、またOSで同時に開けるTCPコネクションの数も制限（WinXPだと4個）に制限されているので、あまり問題になることもないわけですから。

ところが、同じPCでもサーバー側になると様子が変わります。

サーバーは不特定多数に対してTCPコネクションを開き、それを維持しなければなりません。各コネクションに対して受信バッファを用意しなければならないので、コネクション開設要求に耐えられるだけのメモリが必要になります。そのため、

• メモリは多めに用意しておく
• 1つ1つのコネクションを短時間で終わらせる
• あとはロードバランシング

といった方法が取られます。そしてそれでも溢れるような場合は、HTTPサーバであれば503（Service Temporarily Unavailable）をクライアント側に返し、今来ているリクエストを何とか順番にこなしていきます。

しかし、今流行のAjaxやCometは、この対策がほとんど功を奏しません。なぜかというと、両技術とも実装方法によっては(←2008/1/31 ioさんの指摘を受けて追記)コネクションを開設（維持）したままで通信を行わせることになりうるため、本来コネクションレスであるはずのクライアント-サーバ間のTCPコネクションがずっと開きっぱなしになります。つまり、メモリをどんどん消費してしまう。
知り合いのサーバ屋さんも、「Cometはメモリをバカ食いするから使いたくない」と言ってました。

最新技術は華やかで便利そうですが、元の設計や(←2008/1/31追記)足回りがしっかりしていないと足元をすくわれることになりますね、という話でした。

ちなみに今やってる業務とは全然関係ありません。間違っているところとかがあれば遠慮なく指摘してください。特にioさん、ピロキシノフさん。

[Network] メールアドレスhack

皆さんが使っているメールアドレス、実はちょっとした秘密があります。
それは、

　「メールアドレスの大文字小文字はたいてい区別されない」

ということ。厳密にはアカウント部分（=@より前の部分）が対象で、なおかつメールサーバの実装に依存しているものですが、ほとんどのケースで問題はありません。

つまり「hoge@piyo.com」だろうが「HOGE@piyo.com」、さらには「hOgE@piyo.com」だろうがメールサーバ側は問題なく配信してくれるのです。ご存知でしたか？

※ RFCではcase sensitiveかどうかは規定していません。また、プロバイダによっては通用しないところもあります。

ちなみに10年近くもネットワークに関連する仕事をしていて、数ヶ月前に初めて知ったというのは内緒の方向で。
（ioさん、ピロキシノフさん、知ってました？）

実はこれがなかなか便利なのです。たとえば

　「ネットショッピングをしたいけれど、メールアドレスを入力したら
　　以後迷惑メールが届くようになるかもしれない」
　「別のメールを使えばいいけれど、複数アカウントの管理が面倒くさい」

なんていうときでも、買い物をするときは「hOGe@piyo.com」など普段と異なるcaseの組み合わせで入力しておけば、いざメールアドレスが流出して迷惑メールが来るようになっても大丈夫。メールソフトで「hOGe@piyo.com宛のメールはゴミ箱へ」という仕訳ルールを作ることで、とても簡単にフィルタリングできます。
ショッピングサイトのデータベースは大文字をわざわざ小文字に変えるようなことはしていないからできるテクニックです。

これならごく私的な理由により怪しいサイトで買い物をしなければならない・ごく私的な理由により会員制のサイトに（以下略）というときも安心ですね。

−−−

ちなみにGMailではアカウント名に続けて「+任意の文字列」を記述できるようになっていて、同じようにメールの分類に役立てられます。が、このルールだと弾かれるショッピングサイトが多いです（+を使うのはRFCにも準拠していて問題ないのに・・・何でKDDIみたいな非準拠メールアドレスがOKでこちらはダメなんだ）。
それに対して上記のアドレスの使い分けはほとんどの場合で有効なので、なかなか便利です。

なお実使用前には必ず動作チェックしておくことをお忘れなく。自分宛にメールを出してみれば対応状況が分かります。

以上、メールのTipsでした。

必死な理由

なんでお父さんは必死にならなければならないかというと、それは統計多重効果を見込んで組み込んだ業務がオーバーフローしてしまったためです。(泣)

【統計多重効果】
通信の世界でよく用いられる技術用語で、通信を行う端末群の発生トラフィックの時間的変化は端末数の増加に伴い平滑化されるため、キャパシティ以上の端末を収容しても大丈夫、という理屈。
もうちょっと分かりやすく言うと、通信するPCの数が増えれば増えるほど、同時に全端末が最大通信量で通信(ムービーをダウンロードしながらオンラインゲームとか)する確率は低くなるという考え方です。

大数の法則に似ているけど、ちょっと違うので注意。じゃんけんで全員が同じ手になり続ける確率・・・というのも違うな。誰か良いたとえを教えてください。

担当している5プロジェクトのうち2つが面倒くさいことになり、また別の1つでも一人分の作業100%のアウトプットを求められているので、さあ大変。
これまでは１つ１つの忙しさの波がずれていたのでこなせていたのですが、一気に押し寄せれば決壊しますがな。

どう考えても自分のせいではない物もあるのですが、ここしばらくは200-240%の作業量でこなさないといけません・・・。

がんばります。

SNMPの最新実装を追う・・・つもりが

注：技術的な話です。つまんないですからね。

仕事でIPv6まわりのSNMP実装状況を見ていました。以下はそのときのメモです。

続きを読む "SNMPの最新実装を追う・・・つもりが"

Vistaが使用するIPv6ユニキャストアドレス

先に言っておきます。この記事は、ネットワークの技術的な話で終始していて、興味のない人にはつまらない話です。すみませんです。

IPv6を調査していて気づいた点をメモします。EUI-64の危険性と、それに対するVistaやLinuxの方針についてです。

続きを読む "Vistaが使用するIPv6ユニキャストアドレス"