TCP擬人化の元ネタ見つかった

嬉しい。

TCPフロー制御アルゴリズムは人のマネージメントへ応用できるか Matzにて、同名のタイトルが元ネタであることがわかった。

TCPフロー制御アルゴリズムは人のマネージメントへ応用できるか ありえるえりあ

TCPは現実的なプロトコルなので、過度な期待はせず、以下のような冷酷な仮定と性質を持っています(カッコ内は技術的な用語)。
– 完全に終わったという報告しか信用しない(選択的あるいは否定的な確認応答を返せない)
– 余力があるかどうかを、部下にしょっちゅう自己申告させる(スライディング・ウィンドウ)
– 余力があると言った奴でも、実績の無い奴は信用しない。しかし、可能な限り速く、能力一杯までタスクアサインする(スロースタート)
– 部下の仕事の速さを測定して、状況再確認のタイミングに生かす(RTTの測定とタイムアウトの計算)
– 納期に遅れた(タスクを落とした)奴の信用度は一気に落とす。しかし、タスクを落とさない、ぎりぎりの能力を速やかに見つける(輻輳回避アルゴリズム)

これはまるで、人間を信頼することをやめて、「信用できるのは数字だけ」を信条とするマネージャのためにあるかのようです。

このクールさがたまらない。

他にも色々派生がある。
人生の全てはTCP/IPに学んだ
連載:アニメーションで見るパケット君が住む町(10)TCP課長は几帳面でしっかりもの!

ドラッカーの名著で「もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら」が可能なら、実用的なTCPで「もし高校野球の女子マネージャーがRFC 793の『Transmission Control Protocol』を読んだら」を書いてくれないものかな。誰か。高校野球の女子マネージャーとTCPだと無理筋だけど別のマネージャーなら…。

TCP先生! ~TCP教師としての擬人化~

インターネットの情報を確実に伝えることに役立っている技術の1つとして、TCPがある。TCPとはTransmission Control Protocolの略で、伝送制御プロトコル、次々に伝えて送るために送り方・受け方をどのように調節するかを決めた約束事である。

TCPのおかげで正確に、なるべく速く送ることができる。インターネットが混雑している時にもなんとかやり取りができるのも、TCPのおかげだ。

このTCPの仕組みを擬人化するネタがわりと面白いので、いくつか考えてみようと思う。思いついたのが教育的なものだったので、TCP教師で。

正確に漏れなく教える

TCP教師は1対1で教育するときに絶大な信頼を得ている。

TCP教師は正確に教育する。彼は教育する内容に関して、全てに番号をつける。(シーケンス番号)

TCP教師が生徒に対して教えた内容について、生徒はTCP教師へ一定時間内に分かったということを伝えなければならない。そのとき、生徒は分かった内容が何か、番号で伝えることになる。(ACK)

生徒は教えられた内容が理解できるかどうか、確認をする(チェックサム)。往々にして生徒は、分からなかった内容についてTCP教師に伝えることはしないものだ。生徒は分からなかった内容はそのままにして黙っている。

TCP教師は抜け目がない。自身が教えた内容を番号で把握している。自身が教えた内容について、一定時間の反応がなければ、再度、教育を行う。また理解しなければ延々と再教育を行う。しぶとい。(ARQ, タイムアウト再送)

しかしTCP教師にも温情はある。一度、理解できなかった内容についての再教育までの猶予は2倍に伸ばされる。(TCPタイムアウト時間)

だが彼にも限界はある。彼の定める時間以上は待ってはくれないのだ。その時間になると再教育が始まる。(最大TCPタイムアウト時間)

TCP教師以外の再教育

再教育の方法にはいくつかの方法がある。

1つの教育内容について、ある方面、別の角度からの情報を付け加えることで、勘違いが発生しても、正しい方向に導けるような布石を打つ方法がある。必要最低限の教育では、1つの勘違いから理解できないということが多い。はじめから効率を犠牲にして、情報多めにした方が、1回の教育で理解できる確率が高いはずだ。(FEC)

TCP教師のやり方は、個人授業や数人とのやり取りではうまくいく方法かもしれない。しかし、教室や講堂で50人~100人単位で伝えなければならなくなったらどうだろうか。一人ひとりから、理解したかどうかの確認をもらっても処理しきれない。理解できない生徒がぽろぽろ出てくると、何度も同じ話をすることになる。さすがのTCP教師もお手上げだ。(マルチキャスト, ACK爆発問題, マルチキャスト再送問題)

この場合は、理解できない人間が数人が出てきても仕方がないという割り切りが必要なのだ。

また別の組み合わせるべき方法として、分からなかった人は挙手をする、という手法がある。(NAK)

分かった人が分かったということを伝えるケースと、分からなかった人だけが挙手をするケースを比べれば、後者のほうが多人数の場合には効率がよさそうだ。再教育の回数を制限すれば、何とか時間内に教育することが可能になりそうだ。(再送回数の制限)

しかし考えてみると、なぜ、TCP教師は「分からなかった人は挙手をする」という方法をとらなかったのか。それは、TCP教師が1対1で教育をしていても、分からなかった生徒がTCP教師に分からなかったという事実を伝えない(伝えられない)ことがあるからだ。生徒には生徒なりの事情があるものだ。シャイな生徒もいるのだろう。

だから、TCP教師は、生徒からの「分かった報告」が来るまでは再教育を続ける。「余分な情報を付け加える」方法も「分からなかった人は挙手をする」方法も採用しないのは、それらの方法が完璧に教育内容を伝えられることが保証されていないからなのだ。潔癖なTCP先生は完璧に教育することを誇りに思っている。

この世界の生徒は、分からなかった内容に関して「分かりました」と嘘をつくことはない。TCP教師が聞き間違いをしなければ、だが、その確率は著しく低い。

TCP教師以外の教師の中には、「分かった生徒が分かったことを伝える」方法と、「余分な情報を付け加える」方法を組み合わせた方がよいのではないかと考えている人もいる。彼らはTCP教師よりも、低年齢の生徒を扱っているようだ。低年齢の生徒の中には、頻繁に勘違いするものもいる。そういった配慮が必要なのだろう。そういった生徒に対してTCP教師が直接教えようとしても効率が悪いのだが、組み合わせの方法を使う彼らの教育方針の賜物で、TCP教師の教育が効率よく行えることもある。(無線伝送の問題, H-ARQ)

1対1の教育でもTCP教師にはお手上げの生徒がいるのだ。しかしTCP教師は日夜、教育方法について研究している。いつの日か、彼も、そういった生徒を克服できる日が来るのかもしれない。

後書き
この話を読んだ人には、TCP教師はどのような風貌、人格に見えるのだろうか。

『分からなかった内容に関して「分かりました」と嘘をつくことはない』、とのくだりは、チェックサムを行っているので、逐一理解をしているのかテストを行っている、という表現でもよかったのかもしれない。

元ネタとなったTCPな仕事論が書かれたページが見つからん…

次に書く気力があったら、「3ウェイハンドシェーク」「フロー制御」「輻輳制御」についてのテーマで。

光回線とちょっとした伝送実験

ADSLによって一般に普及した俺らのブロードバンドが、光回線によって技術の夜明けを見るようで胸が熱くなる。ような時期があったが光回線に変えてインターネット(Web)体験はそれほど変わったのだろうか。

電話、テレビ、動画サイトの待ち時間、オンラインゲームの安定性、確かに変わるだろう。しかし、それが今までの体験と大きく違うとは思えない。FTTHの利点は、帯域幅、低遅延、安定性などが考えられるが、その中でもADSLとは決定的に違うと感じる点は上りの帯域幅である。帯域幅の測定サイトにおいても、80Mbps以上を記録できる点が特に素晴らしい。

この上り帯域を使って何か面白い実験ができないかどうか考えた。

そういえば、ADSLが開通したときに実験の1つとして音楽や動画をリアルタイム伝送していたことを思い出した。これと同様のことを光回線で行えないか考えたところ、地上デジタル放送のMPEG-2 TSをリアルタイム伝送するというアイディアが出てきた。

しかしADSLの頃のように低帯域で伝送するのではなく、10Mbps以上の帯域を必要とするので出口にも光回線レベルのものが必要となる。そこで光回線を有する友人に協力してもらい、VLCを用いて伝送を行うこととした。地上波の録画したTSを伝送することとした。VLCをサーバ・クライアントの両方に利用するHTTPによるTCP伝送である。そのほかの設定はデフォルトのままである。

結果は、安定して伝送することができた。出てくる映像にも特に問題はない、という意見をもらった。統計情報を出してもらったところ、10分間で映像に関してはロストフレームが100フレーム程度だった。実際に出力される映像については見ていないが、統計情報の結果からも、うまくいっていたことだろう思う。

この結果を踏まえ、前回のfriioからPS3にリアルタイムで出力できたことを考えれば、ロケーションフリーテレビのデジタル放送版を自作することも可能であろう。この実現には光回線は必須であるであるように思える。

また、友人同士で興味のあるビデオを見て議論したり、親族に録画した映像を流しながらテレビ電話で説明したりなど、コミュニケーションと重なる映像視聴の体験も広がることだろう。

そういったことを今回の実験で感じることができたので、良かった。

フレッツ光ネクストが開通したり!

ケーブル50m買ってきたりハブ買ってきたり、ケーブルを管に通そうとしたら通らなかったので先に針金通したり、管を土中に埋めたり、壁に穴開けたり、ケーブルの先っちょに圧着端子つけたら10Mbpsしか出なくて涙目になったり、よくみたら配線が間違っていて直したら1Gbps出て安心したり、クロスケーブル混ざっていて萎えたり、速度測定したら速度出なくて萎えたり、TCP1セッションじゃスピードが出ないことに気がついたりしたけれど、私は元気です。

===== Radish Network Speed Testing Ver.4.0.4β - Test Report =====
測定条件
 精度:高 データタイプ:圧縮効率低
下り回線
 速度:187.4Mbps (23.43MByte/sec) 測定品質:95.8 接続数:4
上り回線
 速度:94.06Mbps (11.76MByte/sec) 測定品質:98.5 接続数:2
測定者ホスト:***************.s**.a***.ap.plala.or.jp
測定時刻:2010/4/1(Thu) 18:54
==================================================================

PSPのxdsファイルを用いたダウンロードの際の挙動の一観察

PSPにはWebブラウザが存在している。このブラウザはNetFrontベースで意外としっかりしているが、やはり、PCブラウザには敵わない。

そんなWebブラウザであるが、一応、インターネットから大きなファイルをダウンロードすることができる。そのダウンロードの形式の1つとして非公式ではあるが、xdsファイルを用いるものがある。このxdsファイルを用いることで、複数ファイルのダウンロードに対応することができる。複数ファイルといっても、動画or音楽ファイル+サムネイルを一緒のフォルダに入れるということ程度しかできない。

xdsではmp3などのメディアのファイルとjpgを指定することができる。このxdsファイルによるダウンロードが行うことができたかどうか、Webサーバプログラムであるapacheのログを確認してみたところ、xdsファイルアクセス後にmp3ファイルに3,4回のアクセスを行っていることが確認できた。間は1秒程度だ。

このmp3ファイルへの複数のアクセスは、複数コネクションを張っているのではないか?と仮説を立ててみた。PSPは無線LAN接続のみしかインターネットにアクセスすることができない。そのためTCPコネクションを複数張ることで無線LANの帯域変化を吸収しているのではないかと考えたからだ。

仮説を検証するべく、自宅内でネットワークを構築し、Webサーバ上でキャプチャを行い、観察を行った。tcpdump(正確にはtshark)によるキャプチャを行い、キャプチャ結果から簡易な解析を行った。結果として、複数コネクションを張っているという仮定は正しくはなかった。

キャプチャの結果、xdsファイルへのアクセスが1回、mp3ファイルへのアクセスが4回、が確認された。

xdsファイルにアクセス後の初回のmp3へのHTTPアクセスはサーバからの応答HTTPヘッダを参照後、直ちにTCPによるRSTフラグを送信していることが分かった。つまりmp3の実体をダウンロードすることなくPSPから切断を行っている。このアクセスは実際にダウンロードを行っていないことから、実際に指定したmp3ファイルが存在しているかどうかを確認していると考えられる。

後の2回のmp3へのアクセスは同様にTCPのRSTフラグを送信することによってコネクションを切断しており、実体は4回目のアクセス時にダウンロードを行っていることが分かった。複数回の確認を行う理由を知るため、セグメントを確認してみたところ、HTTPヘッダに違いがあることが分かった。

1回目のアクセスの要求時のHTTPヘッダ

Connection: Keep-Alive

2回目のアクセスの要求時のHTTPヘッダ

Pragma: no-cache
Cache-Control: no-cache
Connection: close

3回目のアクセスの要求時のHTTPヘッダ

Connection: Keep-Alive

この挙動について調べてみたところ、確信はないが、2回目のHTTPヘッダはProxyサーバに対する制御を行っていると考えられる。

Cache-Controlにおけるno-cacheはHTTP 1.1においてブラウザやProxyがキャッシュを行ってはならないことを示す。PragmaはHTTP 1.0への互換性のために指定している。この設定を行うことによって、(実際にそのような挙動を行うのかどうか確認はおこなっていないが)Proxyのキャッシュを削除しているのではないかと思う。またConnectionのcloseはKeep-Aliveを終了する旨であり、Proxyがサーバに対する永続的接続を一旦終了するように促している。

その後、キャッシュクリアされたProxyにおいて、オリジナルのサーバのファイルにアクセスしようとしているのではないか、と考えられる。

以上の結果をもって、当初の仮定であるTCP複数コネクションによるダウンロード説は棄却とする。

ネットワークに関して読んだ本

タネンバウム教授のコンピュータネットワークの本を久しぶりに見なおす。この本はネットワーク全体のことを広く浅く説明してくれる。実装よりもなぜ、そうしたのか、理由を書いてくれている。さらにADSLから光ケーブル、衛星、最新のWiMAXの技術など、版のたびに丁寧に改定してくれている。自分が読んだ本は第2版だったが、第4版の新たな追加には驚かされた。

記憶のある最も古くに読んだ本は、ゼロからはじめるスイッチ&ルータのような気がする。今、手元にないのでわからないが、この本でTCPの簡単な仕組みを知った気がする。

その後、シスアド初級の本でスター型などのトポロジについて勉強した(資格は取るよりも資格勉強の本自体が面白いことを知った)。

次に詳解TCP/IP Vol.1とタネンバウムのコンピュータネットワーク本を読んだ。詳解TCP/IPはゼミで読んだのだが、あれは自分1人で読める本ではなかった。教えてくれる人がいるからこそ、読める本だったと思う。

それに対してタネンバウムのコンピュータネットワーク本は、自分的にはヒットな本で自分で読み進んだ覚えがある。電車の中で重たい本をずっと読んでいた。この本を読むときには、すでに詳説TCP/IPを読んでいたはずなので読めたのはそのためかもしれない。

4年前頃に日経コンピュータの年間購読が無償だったので申し込んだ。講義室に誰かの忘れた日経の紹介冊子がおいてあり、その冊子にて無償取り扱いをしてあったような気がする。日経コンピュータは、それこそ銀行のシステムやNの交換機システムがどのように設計されているのか、その開発者たちの言葉を得られる本だった。この本からは、コンピュータにおける様式美が何なのか学んだ。

その後、日経ネットワークをよく買うようになった。日経ネットワークはその頃、P2PやVPNなど当時のトレンドを抑えており、また、トレンドを簡単に説明することに長けていたので、その世界に非常に入りやすかった。その本でネットワーク製品の概要について学んだ。

さらに時々、日経NEを買って、最新のプロダクト情報について調べた。

日経ネットワークがつまらなくなったので、購読するなら日経コミュニケーションだということで、その後、日経コミュニケーションを年間購読した。この本でアクセス系、コア系、無線系の概要と、ソリューションにおけるモバイルのあり方について学んだ。日経コミュニケーションの購読を1年前にやめてしまったために、NGNの知識はその頃のまま。たとえば、日経コミュニケーションの記事でNGNにかけるNEC不退転の決意はかなり大きな扱いで、感動した。

その日経コミュニケーションがAmazon.co.jp: NTTの自縛 知られざるNGN構想の裏側: 本: 宗像 誠之,日経コミュニケーションというNGN否定本っぽいのを出しているので、いつか読みたいと思っている。

今、思い出せるのは、これくらい。