丁寧なTCPと潔いUDP

あなたがインターネットで何かを送るとき、そのデータってこう、一方的に送りつけられてるだけだと思います？ と言いますと？それとも実は送る前に、今送っても大丈夫ですか？みたいな、すごく丁寧な挨拶が交わされてると思いますか？ ああ、面白い問いかけですね。まるで人間関係の始まり方みたいだ。そうなんです。 いきなり本題から入るか、まずは自己紹介から始めるか。実はインターネットの世界でもこの始め方がものすごく重要なんですよ。 まさに。今回はですね、ご提供いただいた資料をもとにインターネット通信におけるその礼儀作法とも言える2つのやり方、TCPとUDPについて深く掘り下げていこうと思います。 はい。きっとこの話を聞き終える頃には、あなたのオンライン体験がある時は確実性を、またある時はスピードを優先するのか、その裏側の仕組みがはっきりと見えてくるはずです。 いいですね。データたちがどんな会話をしているのか、その舞台裏を覗いていきましょう。では早速なんですが、資料を読み解いていきましょうか。ええ。 資料だと片方の通信方式を「既読スルーされると不安になるタイプ」って表現してるんですよ。これ面白いですよね。ふふふ、分かりやすいですね。 まずはこの確実に届けたい派、TCPから見ていきましょう。はい。TCP、正式にはTransmission Control Protocol。このプロトコルの最大の使命は、もう資料にある通りデータを確実に、 そして順番通りに相手に届けること。確実に順番通りに。 ええ。そのために使われるのがスリーウェイ・ハンドシェイクといういわば通信前の儀式なんです。スリーウェイ・ハンドシェイク、3回の握手ですね。 なんだかすごく丁寧な印象ですけど、でもなんで3回も必要なんですかね？1回とかじゃダメなんですか？ この「両方」を確認するためなんですよ。両方。なるほど。資料にある電話をかける時のやり取りっていう例えが一番しっくりくるかなと。 ああ、これはもう実際にやってみたほうが分かりやすそうです。ええ。私がデータを送る側、あなたが受け取る側で、この握手、再現してみませんか？ ええ、ぜひ。では始めましょうか。はい。じゃあ行きますね。もしもし、聞こえますか？接続を開始したいのですが。 はい、今のが最初の握手です。ほう。専門的にはSYN（シン）と呼ばれる信号を送っている状態です。SYN。 はい。シンクロナイズ、つまり同期を取りましょう、始めましょうっていうそういう意思表示ですね。では返しますよ。はい聞こえますよ。ありがとうございます。 そちらも私のこの声は聞こえているでしょうか？お、返事が来ました。しかも質問で返してきた。これが2回目の握手、SYN-ACK（シンアック）です。 SYN-ACK。はい。あなたのSYNを受け取ったっていう確認のACK。これはアクノレッジメント、承認の略ですね。はいはい。 それに加えてこちらからもあなたと同期を取りたいですっていうSYNを返している。つまりあなたの声が聞こえたっていう返事と、こちらの声が聞こえるかの確認を一度にやってるわけです。 なるほど。返事と質問を同時に。確かに合理的ですね。ええ。では最後の握手ですね。はい、そちらの方へバッチリ聞こえています。 これで双方の準備が整いました。では本題のデータを送ります。カチャッ。そして最後の握手、これがACK（アック）です。アック。 ええ。相手からのSYN-ACKを受け取ったことで「よし、相手も準備万端だ」と確信して、接続が正式に確立されました。これでようやく安心してデータを送ることが。 なるほど。この3段階の丁寧な確認があるからこそ、信頼性が担保されるわけです。いやあ、面白いですね。SYN、SYN-ACK、ACK。 この、なんていうか機械的で丁寧なカチャカチャッていうやり取りが、メールを送ったりウェブサイトを読み込んだりする裏側で、もう一瞬のうちに行われてると。そういうことです。 以前大事なファイルをダウンロードしてて99%で失敗したことがあって、あれは本当にガッカリしましたけど。ああ、ありますね。 でも今思うと、あれはTCPが最後の1ビットまで届かなかったことを正直に教えてくれた誠実なエラーだったんですね。まさにその通りです。 TCPは嘘をつきません。全部届いたか、どこかで失敗したか、必ず白黒はっきりさせる。だからこそ私たちは壊れたファイルを受け取ったりすることがないわけです。 でもその丁寧さって逆を言うと、例えばコンマ1秒を争うような場面だと致命的な遅延になりそうですよね。ええ。 オンラインゲームでボタンを押すために「もしもし、はい聞こえます、了解です」なんてやってたら、もうとてもプレイにならない気がします。素晴らしい指摘です。 そのTCPの丁寧さが逆に足かせになる場面。はい。そのもどかしさを解消するために存在するのが、もう1つのプロトコル、UDPなんです。UDP。 はい。User Datagram Protocol。資料の言葉を借りるなら、ハンドシェイクなしです。挨拶なしですか？一切なしです。 いきなり「これ投げとくからね、これも、これも」と一方的にデータを送りつける。ええ。 もうイメージとしてはシュパッ、シュパッ、シュパッっていう感じです。TCPが電話だとしたら、UDPはポストにハガキを投げ込み続けるような。はあ。 でも確認なしで送りつけるなんて、ちょっと乱暴な技術に聞こえちゃいますけど、本当にそれで問題ないんですかね？届かなかったらどうなるんですか？ 資料には「届かなかったらその時だという潔さ」ってありますよね。はい、あります。これ決して乱暴なのはでなくて、思想が全く違うんです。 UDPが重視するのは確実性よりもリアルタイム性とスピード。リアルタイム性とスピード。ええ。 目的のためには多少のデータの欠損は許容しようという考え方です。多少の欠損は許容する。ええ。 先ほどのオンラインゲームの例で考えてみましょう。あなたのキャラクターの位置情報って1秒間に何十回もサーバーに送られてるわけです。はいはい。 もし0.1秒前の位置情報データが途中で消えちゃっても、TCPみたいに「すみません、さっきのデータが届いてないのでもう一度送ってください」って通信を止めて再送を待つ意味ってありますか？ いや全くないですね。0.1秒前の位置なんてもう過去の情報で、それより今の最新の位置の方がずっと重要ですから。その通りです。 UDPの世界では古いデータは無価値なんです。だから届かなかったデータはもういさぎよく諦めて、とにかく最新のデータを送り続ける。なるほど。 ビデオ会議も同じですよね。私が今話している映像のフレームが数枚欠けたとしても、会話を止めてまで過去の映像を再送してもらうより、 ちょっとカクついても話がリアルタイムに進む方がいいじゃないですか。ああ、腑に落ちました。 ビデオ会議でよく見る「ネットワーク帯域が不安定です」っていう表示は、もしかして裏側でUDPのデータが大量に失われてて、もう追いつけないよっていう悲鳴だったりするわけですか。 まさにそういうことです。少ないデータの欠損よりも遅延がないことの方が圧倒的に重要。動画の生配信、オンラインゲーム、IP電話。 これら全てがUDPの哲学の恩恵を受けてるんです。はあ、なるほどなあ。TCPは慎重で礼儀正しい優等生。 UDPはちょっと荒っぽいけど仕事が早いスピードスターみたいな、そういうキャラクターが見えてきました。ええ、ええ。良い例えですね。 ということは僕たちがウェブサイトを見る時には、まずTCPで接続を確立してからページを読み込むと。基本的にはそうなんですが、実はそれよりももっと前の段階があるんですよ。 えっ、そうなんですか？ウェブサイトの閲覧はTCPだって今。ええ。例えばあなたが example.com とブラウザに入力したとき、 コンピューターはまず「example.comっていうサーバーはインターネット上のどこにいるの？」って住所問い合わせをするんです。住所問い合わせ。 はい。これをDNSルックアップと言いますが、このほんの短い問い合わせには多くの場合UDPが使われます。へえ。 住所を聞くだけのごく短いやり取りですからね。「この住所どこ？」「ここだよ」っていう一往復で済む。こんな小さなことにTCPの丁寧な3回の握手はちょっと大げさなんです。 確かに。だからまずはUDPで素早く住所を聞き出して、その住所が分かってから本丸であるウェブサイトのデータをごっそりダウンロードするために満を持してTCPが登場する。 なるほど。このように1つの目的を達成するために両者が連携プレーをすることもあるんです。適材適所ということですね。 さて、ではこの話全体が何を意味するのか、確実性のTCPかスピードのUDPかという使い分けが重要だってのはよく分かりました。ええ。 そしてここで最も重要なのは、これどちらが優れているか、っていう話ではないということなんです。はい。資料が示す核心は、まさに目的に応じた使い分けにある。 1文字でも欠けると意味が変わってしまうメール、1ビットでも壊れたら開けないファイルはTCP。ええ。 多少の欠損は許容できるけど、とにかく遅延を避けたいライブ配信やゲームはUDP。私たちは意識することなく、目的に応じてインターネットの話し方を使い分けてるわけですね。 でも話はそれで終わりじゃないと。その通りです。さすがですね。エンジニアたちはこのTCPの信頼性とUDPのスピードを見てこう考えたわけです。 この両方の良いところを合わせた最強のプロトコルは作れないだろうかと。最強のプロトコル。はい。 そこで生まれたのが比較的新しいQUIC（クイック）という技術です。QUIC。ええ。これはGoogleなどが中心になって開発したもので、 まさにUDPのスピードっていう土台の上にTCPのような信頼性を再構築しようという野心的な試みなんです。UDPの上にTCPを載せるみたいな感じですか？ おお、非常にいい例えです。UDPの挨拶なしでいきなりデータを送れるっていう身軽さを活かしつつ、 もしデータが届かなかったら再送を要求するとか、そういうTCP的な賢い機能を後付けしている。はあ。しかもTCPが抱えていたいくつかの弱点を克服するように設計されてるんです。 と言うと、僕たちの身近なところでももう使われてるんですか？もちろんです。あなたがYouTubeの動画をクリックしたとき、ほとんど待たずに再生が始まりますよね。 はい、そうです。あるいは不安定なWi-Fi環境でもGoogle検索が比較的スムーズにできたり、その裏側ではこのQUICが活躍していることが多いんです。 へえ。いわばUDPっていうスピードスターにTCPっていう優等生の頭脳を移植したような存在。この話は単なる二者択一で終わるんじゃなくて、常に進化し続けてるんです。 いやあ、それは驚きました。単にTCPとUDPの2種類を使い分けてるだけだと思ってたら、その先にハイブリッドみたいな次世代の技術がもう生まれていて、 しかも日常的にその恩恵を受けていたとは。ええ。そしてどちらの個性もその進化の過程も、全ては私たちの快適なデジタルライフを支えるためにある。 そう考えると少し見え方が変わってきませんか？変わりますね。今回の話でインターネット通信には、 丁寧な挨拶から始めるTCPと要件だけを素早く投げるUDPっていう2つの個性があって、さらにその進化系のQUICが存在することを見てきました。ええ。 普段何気なく使っている通信の裏側で、こんなにも目的意識のはっきりした使い分けと絶え間ない技術革新が行われていたとは本当に驚きでしたね。 そこで1つ面白い問いが浮かび上がるんです。はい。今回の話はあくまでコンピューター同士の通信プロトコルの世界でした。 ですが、もし私たちの日常生活や仕事のコミュニケーションにこのTCPとUDPの考え方を応用するとしたらどうでしょう？ 人間関係に、ですか？そうです。常に丁寧な背景説明と相互確認、つまりTCP的なやり方が必要な場面もあれば、 スピード優先で結論とか要点のみを端的に伝えるUDP的な緊急の連絡もはずです。ああ、なるほど。 相手や状況を考えずに常にTCP的なコミュニケーションばかりしていると、前置きが長くて要領を得ないなって思われたり、 逆にUDP的なコミュニケーションばかりだと、説明不足で不親切だって思われるかもしれない。確かに。 あなたが明日行うコミュニケーションは、TCP的であるべきか、それともUDP的であるべきか、少し考えてみるのも面白いかもしれませんね。