人生の全てはTCP/IPに学んだ

2008/1/29

1. ゆずり合うこと

TCPはネットワーク帯域を他のTCPセッションと譲り合います。 TCPには、ネットワークが混雑(輻輳:ふくそう)してくると、送信されるパケット量を減らす仕組みがあります。この譲り合いがあるからこそ、現在のインターネットは多数の人間が同時に使えています。

同様に、現実世界においても無理な競い合いを行うよりも譲り合いを行った方がスケーラビリティが上昇します。

2. 信頼はきめ細やかな確認応答で実現されること

TCPでは、信頼性を確保するためにAck(Acknowledgement、確認応答)を送信してデータの到着を伝えます。 TCPのセッションが確立している間は、Ackが細かく送受信され続けます。このきめ細かな確認応答が信頼の根幹であると言っても過言ではありません。

現実世界においても、きめ細かく応答を行う事が重要です。メールなどを受け取っても、全く返事をしない相手との信頼関係構築は難しいかも知れません。

3. 音信不通が長いと関係が切れてしまう場合があること

TCPセッションにおいて、全くパケットのやり取りが行われない期間があると、セッションが切れてしまう場合があります。 TCPセッションの両端に位置する各エンドポイントにおけるTCPのステートがClosedになってしまう事によって切れる場合もありますが、途中にNAT(NAPT,IPマスカレード含む)ルータなどがある場合、30秒ほどで変換テーブルが破棄されてしまうこともあります。

現実世界においても、音信不通が長くなってしまうと、ステータスが「他人」へと転落します。

4. 細かい振動状態が実は安定状態であること

TCPにおける安定的なデータ転送は、データ送信量を増やしたり減らしたりすることの繰り返しである事が多いです。このデータ送信量の細かな振動は、マクロな眼で見ると「安定状態」になっていることが多いです。

現実世界においても、全くぴったりと動かないような安定というのは少なく、ミクロな眼で見ると細かい変化や振動を繰り返す状態こそが安定と言えるのではないでしょうか。

5. 細かい事に一々答えているよりも、まとめて答えた方が効率が良いこと

TCPでは、全てのパケットに対するAckを送信するのではなく、ある程度まとめた範囲を指定したAckを返します。全てのパケットに対して一々Ackを返していたのでは非常に非効率になってしまいます。

現実世界においても、細かすぎる返答は嫌われます。空気を読んだ範囲でまとめて応答をすることが推奨されます。

6. 自分の許容範囲をあらかじめ相手に伝えておくと効率が良いこと

TCPでは、自分が受け取れるデータ許容量を受信者が伝えます。この許容量はWindow(ウィンドウ、窓)と呼ばれています。データ送信側は、その伝えられた値の範囲内でデータを送信します。

現実世界においても、自分の許容範囲を正しく伝えた方が効率が良い場合が多いです。自分が実際にこなせる以上の仕事を引き受けてしまうと、自分だけではなく相手にも多大な迷惑がかかる場合があります。

7. 窓は徐々に開いていくこと

一般的なTCPアルゴリズムでは、ウィンドウサイズは小さいところから開始されます。ウィンドウサイズは、輻輳が発生しなければ徐々に拡大していきます。

現実世界においても、心の窓が最初から全開であることは少なく、相手に対する許容の気持ちは徐々に大きくなっていくものではないでしょうか。

8. 不都合があると窓は小さくなる

一般的なTCPアルゴリズムでは、輻輳(パケットの喪失など)が発生するとウィンドウサイズが小さくなります。ウィンドウサイズが小さくなると、転送されるデータ量が少なくなり、輻輳が回避されるという仕組みです。

現実世界においても、相手に対する開きすぎた窓が小さくなるのは何か不都合が発生したときであると思われます。

9. 信頼よりも速度や簡易さを求める人もいるということ

インターネットが設計された当初は信頼性のある通信だけで十分であり、信頼性の無いトランスポートプロトコルは必要ないと思われていたようです。 TCPのIPプロトコル番号が6番で、UDPが17番であることからも、この事が垣間見えます。

しかし、音声通信など「信頼性よりも即時性の方が重要になる」タイプの通信では、パケットが欠落したとしても気にせず通信を続けた方が良い場合があります。

現実世界においても、時間をかけてしっかりとして信頼を築いてから何かをするよりも、スピードを求める事があります。

10. 信頼の無いところで何かを作り上げるのは難しいこと

信頼性の無い通信手段は必要ですが、信頼性が無いトランスポート層を利用したプログラムを書くのは大変です。例えば、UDPを利用した音声や映像の通信では、FEC(Forward Error Correction)やその他手法を利用して途中で欠落したパケットを補完する仕組みを実装したり、パケットが欠落したかどうかを知る仕組みを実装したり、データの到着順序が入れ替わった時の対応をしなければなりません。

TCPを使っていれば、このような事を心配する必要はありません。やはり、信頼が無いところでは何かを作るのは、信頼があるところで作るよりも難しくなるようです。

11. 譲り合いを拒否する一人が全員に迷惑をかけてしまうこと

TCPは、各自が譲り合いの精神を持つことでスケーラビリティを確保しています。地球上の多くの人が同時にインターネットを利用しても、インターネットが壊れてしまわないのは、TCPに入っている譲り合いの精神のおかげかも知れません。

しかし、この譲り合いの世界に、全く人に譲る事をしようとしないようなDoS攻撃のようなUDPストリームなどが入り込むと、TCPはUDPに対して帯域を譲ってしまいます。全く譲る事をしない単一のUDPストリームが多数のTCPストリームに対して「そこのけそこのけ」をしてしまうのです。

現実世界においても、特定の個人が多くの人に迷惑をかけるということが発生します。

12. 距離はキクということ

サリーフロイド氏によると、TCPの取り得る性能は以下の数式で表せるそうです(参考：Promoting the Use of End-to-End Congestion Control in the Internet, Sally Floyd and Kevin Fall, IEEE/ACM Transactions on Networking, 1999)。

この数式を見ると、RTTである「R」が大きくなればなるほどTCPのデータ転送性能は低下する事がわかります。光の早さには限界があるため、一般的には距離が離れれば離れるほどTCPによるデータ転送性能は低下します。 (もちろん、距離よりも物理層の形態や、ルータのホップ数がキク場合も多いです。)

TCPでさえ、距離に大きく左右されてしまうのであれば、現実世界の恋愛の性能が距離に左右されないということはあり得るのでしょうか？

13. 距離が離れているときには複数チャネル用意するのが効果的ということ

距離が離れるとTCPによるデータ転送性能は低下します。この問題を回避する最も一般的な手法は、TCPのセッション数を増加させる事ではないでしょうか。例えば、HTTPでは同時に複数のTCPセッションを確立してデータ転送性能を向上させようとするのが一般的です。

遠距離恋愛においても、電話だけなどの単一チャネルではなく、複数のチャネルでセッションを確立することによって性能を改善することが可能であると思われます。

14. (不特定 || 特定)多数に対する信頼は難しいこと

TCPは1対1で行う通信です。一方、マルチキャストは多数に対して行う通信です。

1対1で行われるTCPでは信頼性を確保することが可能ですが、マルチキャストでの信頼性確保は非常に困難です。不可能ではないかも知れませんが、非常に複雑な手法を要求される場合が多くなってしまいます。

現実世界でも、特定の個人に対する信頼は可能でも、多数に対する信頼は難しいと思われます。

15. 自分が知らなければ知ってそうな隣人に聞くのが良いということ

ルータによるインターネットでのパケット転送は、自分の知っている経路と照らし合わせてパケットを次の人に渡す事の繰り返しです。各ルータは、パケットの宛先を直接知ってるわけではなく、知っている人を知っているだけです。このように、各ルータが知ってそうな隣人に依頼を行う事によって、スケーラビリティが確保されています。

現実世界においても、何かを知っている人を知っているということは非常に強みになります。

16. defaultとなる存在がいるかどうかが大きいこと

インターネットに接続されている全てのルータが、全ての宛先ネットワークに関する情報を知っているわけではありません。自分が知らなければ、自分よりももっと良く知っているdefaultの経路に対してパケットを転送します。

現実世界においても、本当に困ったときに相談ができるdefaultな存在があると非常に心強いのではないでしょうか。

17. 物は言いようで何でも人生につなげられるということ

ええ、この記事がそうです。

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！