TCP と UDP

DNS が IP アドレスを返すと、デバイスは正しい宛先へパケットを送れるようになります。ですが IP は、独立したパケットをネットワーク越しに運ぶだけで、それらが届いたかどうか、正しい順序で届いたかどうか、ネットワークが混雑しているかどうかは追跡しません。

Web ページを多数のパケットに分割すると、その一部は順不同で届き、一部は遅延し、一部は完全に失われることがあります。追加の調整がなければ、受信側のアプリケーションは元のデータを正しく再構成する信頼できる方法を持てません。

トランスポートプロトコルは、4 つの基本的な問題を解決します: ordering（データを正しく再構成すること）、reliability（失われたデータを検出して再送すること）、multiplexing（複数のアプリケーションが 1 つの IP アドレスを共有できるようにすること）、そして congestion control（ネットワークが過負荷にならないようにすること）です。

要するに、IP は「このパケットはどこへ行くべきか？」に答えます。
トランスポートプロトコルは「この会話はどう振る舞うべきか？」に答えます。

データがサーバーのIPアドレスに到達しても、どのプログラムがそれを処理するかは、まだオペレーティングシステムが判断する必要があります。1台のマシンで、Webサーバー、データベースサーバー、SSHサービス、その他多くのアプリケーションを同時に実行できます。

ここでポート番号が重要になります。ポートは、TCPやUDPのようなトランスポートプロトコルで使われる論理的な通信終端です。これにより、システムは受信したトラフィックを振り分けて、正しいアプリケーションプロセスに届けることができます。

たとえば、ポート 80 は通常HTTPに、ポート 443 はHTTPSに、ポート 22 はSSHに使われます。安全なWebサイトにアクセスすると、ブラウザはサーバーのIPアドレスのポート443に接続し、HTTPSで通信したいことを示します。

ポートがなければ、1台のマシンで同時に実行できるネットワークアプリケーションは1つだけになります。ポートによって、1つのIPアドレス上で何千もの同時通信を行えるようになります。

Transmission Control Protocol (TCP) は、完全で正確なデータ配信を必要とするアプリケーション向けに設計されています。生の IP とは異なり、TCP は通信を独立したパケットではなく、連続したバイトストリームとして扱います。

データの各セグメントには sequence number が割り当てられます。受信側はこれらの番号を使って、アプリケーションに渡す前にデータを正しい順序に並べ替えます。セグメントが欠けている場合、TCP はそのギャップを検出し、再送信を要求します。

TCP には flow control も含まれており、送信側が速すぎて受信側を圧倒しないようにします。これは、未確認データとして送信中に存在できる量を制限するスライディングウィンドウ機構によって実現されます。

最後に、TCP は congestion control を実装しています。ネットワークの状態を監視し、ルーターをあふれさせないように送信速度を調整します。これにより、ネットワーク全体の安定性を保ちながら、条件が許すときにはスループットを最大化できます。

TCPはコネクション指向であり、データ転送を始める前に両側が通信に同意する必要があります。このプロセスにより、クライアントとサーバーの両方がデータを交換できる状態であることが保証されます。

まず、クライアントは SYN (synchronize) パケットを送信します。このパケットは初期シーケンス番号を提案し、接続を開きたいという意思を示します。

次に、サーバーは SYN-ACK で応答します。これはクライアントの要求を確認し、サーバー自身の初期シーケンス番号を提供します。

最後に、クライアントはサーバーのシーケンス番号を受信したことを確認するために ACK を送信します。この時点で、両側のシーケンス番号は同期され、接続は正式に確立されます。

このハンドシェイクが完了してから、TCPはアプリケーションデータの転送を開始します。

TCPはデータストリーム内の各バイトに シーケンス番号 を割り当てます。これにより、受信側は欠落したセグメントや順序が前後したセグメントを検出し、元のメッセージを正しく再構築できます。

受信側は、次に受信することを期待しているバイトを示す ACK (acknowledgment) 番号を返します。送信側が一定時間内にACKを受信しない場合、そのセグメントは失われたと判断します。

損失が検出されると、TCPは 再送 を行い、失われたデータをもう一度送信します。この仕組みにより、輻輳やネットワークの不安定さによってパケットが失われても信頼性が確保されます。

TCPはフロー制御のために スライディングウィンドウ も使用します。送信側は、各パケットごとにACKを待つ代わりに、許可されたウィンドウサイズ内で複数のセグメントを送信できます。これにより、厳密な配信保証を維持しながら効率が向上します。

ユーザーデータグラムプロトコル(UDP)はコネクションレスです。TCPとは異なり、データを送信する前にハンドシェイクを行いません。送信側は単にパケットを宛先のIPとポートへ送ります。

UDPは信頼性のためのシーケンス番号を追跡せず、確認応答を待たず、失われたパケットを再送しません。パケットが失われた場合、それは消失したままです。

UDP はこれらの調整機構を取り除くため、オーバーヘッドとレイテンシが大幅に低くなります。そのため、ライブストリーミング、オンラインゲーム、DNS クエリのように、完全な配信よりも速度が重要なユースケースに適しています。

要するに、UDP は信頼性よりもパフォーマンスとシンプルさを優先します。

TCP は、データの欠落や破損があると機能が壊れてしまうアプリケーションに最適です。Web ページ、API、ファイルのダウンロード、メールはいずれも、完全で正しい順序のデータを必要とします。たった 1 バイトでも欠けると、結果が壊れる可能性があります。

UDP は、たまにパケットが失われても問題ないアプリケーションに適しています。リアルタイム動画、音声通話、ゲーム、DNS のような小さなステートレスな問い合わせでは、完全性よりも速度が優先されます。再送を待つと、目立つ遅延が発生します。

重要な判断基準は次のとおりです。
正確性と完全性が必須なら、TCP を使います。
応答性と低遅延が重要なら、UDP のほうが適している場合があります。

宛先ポートが閉じているか、ファイアウォールによってブロックされている場合、サーバーはすぐに connection refused メッセージを返すことがあります。これは、そのマシンには到達できるが、そのポートで待ち受けているアプリケーションがないことを意味します。

クライアントが SYN を送信したのに SYN-ACK を受信できない場合、接続試行は最終的に timeout します。これは、サーバーが停止している、到達不能である、または経路上のファイアウォールによってフィルタされていることを示すことがよくあります。

パケット損失が高い場合、TCP は欠落した確認応答を検出し、retransmissions を行います。信頼性は維持されますが、パフォーマンスは大きく低下します。

深刻な混雑下では、TCP は輻輳制御アルゴリズムによって送信レートを下げます。接続は維持されますが、スループットは低下し、レイテンシは増加します。