若手のエンジニアによってはいきなりクラウドから入ったために、実はどういう仕組みで通信できているのかよく分かっていなかったりすることがあるようです。クラウドやら SDK がよしなにやってくれるので意識しなくてもなんとかなっちゃう部分について、頭の中でイメージを形づくりながら楽しく学ぶ方法はないかなぁ、と思いを巡らしたところ、ジョークから学べないかと狂気じみた発想に至りまして、その可能性についてテストがてらメモっときます。
ジョークはググるとあちこちで見つかるので、気になる方は検索してみてください。
ハンドシェイク
In high society, TCP is more welcome than UDP. At least it knows a proper handshake.
コネクション型の TCP はデータの送受信を始める前にコネクションを確立するために 3-way ハンドシェイクをします。一方、コネクションレス型の UDP はハンドシェイクなしでデータの送信を始めます。上記のジョークはこの違いをネタにしたものです。
ではここで質問です。TCP はなぜ初めにハンドシェイクをするのでしょうか？それはコネクションの両端でシーケンス番号を同期させるためです。送信ポートと受信ポートの仲がいいからノリでやっている訳ではありません。無駄なことはしないところが通信プロトコルの洗練さであり "proper" の所以です。
バー
A TCP packet walks in to a bar and says “I want a beer”, barman says “you want a beer?” and TCP packet says “yes, a beer”.
TCP が ACK でパケットの到着を確認する様を皮肉ったジョークです。なかなかビールが飲めません。
これを踏まえて、バーには色々な通信プロトコルのパケットがやってきます。
A UDP packet walks into a bar without a checksum. Nobody cares.
気にしない、気にしない。
A DHCP packet walks into a bar and asks for a beer. Bartender says: “here, but I’ll need that back in an hour!"
これまた飲めません。まぁ、リースですからね。それにしても 1 時間とはなかなか厳しい運用です。
A LSA Type 6 packet walks into a bar and asks the bartender for a drink. The bartender ignores him.
Standards Track の RFC であるにも関わらず、Cisco が OSPF の LSA Type 6 をサポートしていないので、世間から無視される悲しい運命にあるようです。
A LSA Type 2 packet walks into a bar and asks for a beer. Bartender say’s “here, but don’t leave the area with it.”
OSPF の LSA Type 2 はエリア内でのみフラッディングされるので、持ち出しできません。
IP packet with TTL=1 arrives at bar. Bartender: “Sorry, can’t let you leave…and you don’t get any beer either…”
ああ、やっぱり飲めないのね。。TTL (Time To Live) はルーター・スイッチをホップする度に 1 減ります。0 になるとパケットが消滅します。TTL の初期値を見ればどういう OS のホストか分かったり、減り具合を見て中継路がどうなっているか推測できたりと、トラブルシューティングでも使えるフィールドです。
とまあこんな具合で、各プロトコルで同型のジョークが量産できそう・されてそうです。
混雑
A bunch of TCP packets go into a bar, until it’s overcrowded. The next day, half as many go in.
A bunch of TCP packets walk into a bar. The bartender says, “Hang on just a second, I need to close the window.”
これらは TCP のウィンドウ制御に関するものです。TCP は輻輳ウィンドウとフロー制御ウィンドウのいずれか小さい方を一度に送信できるパケットの数 (送信ウィンドウ) として用います。
一文目は輻輳ウィンドウの制御をネタにしたものです。タイムアウトにより輻輳を検知すると輻輳ウィンドウをその時の輻輳ウィンドウの半分のサイズに設定します (という記述から TCP Reno のことだと分かります。TCP Tahoe だと、次の日のお客さんパケットは 1 人になっちゃいます)。なお、より厳密には半分のサイズ + 3 パケット分になるのですが、お酒の場でそういう細かいことをチクチク言うのは野暮ってもんです。
二文目はフロー制御ウィンドウをネタにしたものです。フロー制御ウィンドウは受信側のバッファの空き容量を表します。受信側のバッファの空きがなくなると、ACK で通知されるフロー制御ウィンドウのサイズが 0 になります。それを "close the window" と言ってる訳ですね。このお客さん達はドアからではなく窓から入ってくるのです。実際のバーで想像してみるとなかなかシュール。
それにしても、店の要請はもちろんのこと、自分で判断してお店通いを控えるあたりがお行儀がよくさすがハイソサイエティ。
さいごに
通信プロトコルに関するジョークをいくつか見てきましたが、バーに客が訪れる感じとか、親近感の沸きやすい日常的な物事になぞらえて表現できることがお分かりかと思います。もちろん実際にはもの凄い速さでお店を出入りしている訳ですが。。。
ここまで読んでいただいた皆さん、RFC やテキストで仕様をもうちょっとちゃんと調べたいな〜、パケットをダンプして実際の挙動を観察してみたいな〜、という気持ちが少しでも湧いてきたでしょうか？もしそうであればこのアイデアは芽があるな、ということで。
なお、この投稿は UDP でお届けしております。