TCP入門：押さえておきたい特徴とUDPとの違い【ネットワーク基礎】

By /

はい、承知いたしました。「TCP入門：押さえておきたい特徴とUDPとの違い【ネットワーク基礎】」というテーマで、約5000語の詳細な記事を作成します。

TCP入門：ネットワーク通信の要「TCP」を徹底解説！押さえておきたい特徴とUDPとの違い【ネットワーク基礎】

はじめに：インターネットを支える「見えない努力」とは？

現代社会において、インターネットは私たちの生活になくてはならない基盤となっています。Webサイトの閲覧、メールの送受信、動画視聴、オンラインゲーム、クラウドサービスの利用など、あらゆるデジタル活動はネットワーク通信によって成り立っています。しかし、これらの通信がなぜこれほどまでにスムーズかつ正確に行われるのか、その裏側には様々な技術的な仕組みが存在します。

ネットワーク通信において、データがどのように送られ、どのように受け取られるかを規定するのが「プロトコル」です。プロトコルは、通信を行う機器同士が共通の言語で会話するための「約束事」のようなものです。インターネットプロトコルスイート（TCP/IPモデル）は、これらのプロトコルを階層的にまとめたもので、その中でも特に重要な役割を担っているのが「トランスポート層」に位置するプロトコルです。

トランスポート層の主要なプロトコルとして、「TCP（Transmission Control Protocol）」と「UDP（User Datagram Protocol）」があります。この二つのプロトコルは、どちらもアプリケーション層からのデータを受け取り、ネットワーク層へと引き渡す役割を担いますが、その性質と機能は大きく異なります。

この記事では、特にインターネット通信において圧倒的に利用頻度が高いTCPに焦点を当て、その仕組み、主要な特徴、そしてなぜそれらの特徴が必要なのかを徹底的に解説します。さらに、もう一つの主要なプロトコルであるUDPと比較することで、それぞれの特性と使い分けの重要性を明らかにします。ネットワークの基礎をしっかりと理解したい方、特にTCP/IPについて学び始めたばかりの方にとって、この記事が深い理解への一歩となることを目指します。

さあ、インターネットの信頼性を支える「見えない努力」であるTCPの世界を一緒に探求しましょう。

1. トランスポート層とは何か？ネットワークモデルにおける役割

TCPとUDPは、インターネットプロトコルスイート（TCP/IPモデル）における「トランスポート層」に位置します。TCP/IPモデルは、通信機能を役割ごとにいくつかの階層に分けて考えます。一般的には以下の4階層（または5階層）で説明されます。

  1. アプリケーション層 (Application Layer)：ユーザーが直接利用するアプリケーション（Webブラウザ、メールクライアントなど）が使用するプロトコル（HTTP, FTP, SMTP, DNSなど）。
  2. トランスポート層 (Transport Layer)：アプリケーション層からのデータを、ネットワーク上の特定のプロセスへ確実に（または効率的に）届ける役割を担う。TCPやUDPがここに位置する。
  3. インターネット層 (Internet Layer)：ネットワーク上の特定のコンピュータ（ホスト）へデータを届ける役割を担う。IP (Internet Protocol) が代表的。データパケットのルーティング（経路選択）を行う。
  4. ネットワークインターフェース層 (Network Interface Layer)：物理的なネットワーク媒体（Ethernetケーブル、Wi-Fiなど）を通じて、隣接する機器との間でデータをやり取りする役割を担う。ドライバやネットワークカードがこれに該当する。OSI参照モデルではデータリンク層と物理層に分割されることが多い。

トランスポート層の主な役割:

  • プロセス間通信 (End-to-End Communication): インターネット層が「どのコンピュータにデータを届けるか」を決めるのに対し、トランスポート層はさらに進んで「そのコンピュータ上のどのアプリケーション（プロセス）にデータを届けるか」を特定します。これは、ポート番号という識別子を使うことで実現されます。例えば、Webサーバーは通常80番ポート（HTTP）や443番ポート（HTTPS）で待ち受け、メールサーバーは25番ポート（SMTP）などで待ち受けます。トランスポート層ヘッダーには、送信元ポート番号と宛先ポート番号が含まれており、これによりデータが適切なアプリケーションに届けられます。
  • データのセグメント化と組み立て: アプリケーション層から受け取った大きなデータを、ネットワーク層で扱うことができるサイズ（IPパケットの最大長に合わせて調整されることが多い）に分割します。分割されたデータ片は「セグメント」（TCPの場合）または「データグラム」（UDPの場合）と呼ばれます。受信側では、これらのセグメント/データグラムを元のデータに組み立て直します。
  • 信頼性の提供 (オプション): トランスポート層は、データの送受信における信頼性を高めるための機能を提供することがあります。具体的には、データが正しく相手に届いたかを確認したり、届かなかった場合に再送したり、順番がばらばらに届いたデータを正しい順序に並べ替えたりといった機能です。ただし、この信頼性確保の機能は、TCPが提供するものであり、UDPは提供しません。
  • 流量制御 (Flow Control, TCPのみ): 受信側の処理能力を超えた速度でデータが送られてこないように調整する機能です。
  • 輻輳制御 (Congestion Control, TCPのみ): ネットワーク全体が混雑している状況を検知し、データの送信速度を落とすことで、ネットワークの崩壊を防ぐ機能です。

TCPとUDPは、これらのトランスポート層の役割のうち、「プロセス間通信」と「データのセグメント化/組み立て」は共通して担いますが、「信頼性の提供」「流量制御」「輻輳制御」といった機能はTCPのみが提供します。この違いが、両プロトコルの性質と用途の大きな違いを生み出しています。

2. TCP (Transmission Control Protocol) とは？その本質

TCPは、その名の通り「伝送制御プロトコル」であり、インターネット上で信頼性の高いデータ転送を実現することを目的としたトランスポート層プロトコルです。信頼性が高いとは、データが送信された順番通りに、重複なく、欠落なく、そして破損していない状態で受信側に届けられることを意味します。

TCPは、インターネットの初期から存在し、World Wide Web (HTTP), 電子メール (SMTP, POP3, IMAP), ファイル転送 (FTP), リモートログイン (SSH) など、多くの基幹サービスで利用されています。これらのサービスでは、データの欠落や順序の入れ替わりが許容されないため、TCPの信頼性機能が不可欠となります。

TCPの本質は、「コネクション指向」であることです。データを送受信する前に、送信側と受信側の間で仮想的な通信路（コネクション）を確立します。このコネクションを通じてデータが送受信され、通信終了時にはコネクションを解放します。電話をかけるイメージに似ています。相手と繋がってから話し始め、話し終わったら電話を切る、という流れです。このコネクションがあるからこそ、TCPは様々な制御機能（信頼性、流量制御、輻輳制御）を実現できるのです。

3. TCPの主要な特徴：信頼性と制御のメカニズムを深掘り

TCPが「信頼性の高い」通信を実現するために、どのような仕組みを持っているのでしょうか？ ここでは、TCPの主要な特徴とその詳細なメカニズムを解説します。

3.1. コネクション指向 (Connection-Oriented)

TCPの最も基本的な特徴は、通信を行う前にコネクションを確立する必要があることです。このプロセスは「3ウェイハンドシェイク (Three-Way Handshake)」と呼ばれます。

3ウェイハンドシェイクの詳細:

  1. SYN (Synchronize): コネクションを確立したいクライアント側が、サーバーに対して「コネクションを開始したい」という意思表示として、SYNフラグを立てたTCPセグメントを送信します。このセグメントには、クライアント側の初期シーケンス番号 (ISN_C) が含まれます。
    • クライアントの状態遷移: CLOSED -> SYN_SENT
  2. SYN + ACK (Synchronize + Acknowledgement): SYNを受け取ったサーバーは、コネクション要求を受け入れる意思表示として、SYNフラグとACKフラグを立てたTCPセグメントをクライアントに返信します。このセグメントには、サーバー側の初期シーケンス番号 (ISN_S) と、クライアントから受け取ったISN_Cに対する確認応答番号 (ACK番号 = ISN_C + 1) が含まれます。
    • サーバーの状態遷移: LISTEN -> SYN_RECEIVED
  3. ACK (Acknowledgement): SYN+ACKを受け取ったクライアントは、サーバーからの応答を確認し、コネクション確立の最終確認として、ACKフラグを立てたTCPセグメントをサーバーに送信します。このセグメントには、サーバーから受け取ったISN_Sに対する確認応答番号 (ACK番号 = ISN_S + 1) が含まれます。この時点で、クライアント側はコネクションが確立されたとみなし、データ送信を開始できます。
    • クライアントの状態遷移: SYN_SENT -> ESTABLISHED
  4. ACKを受け取ったサーバーも、コネクションが確立されたとみなし、データ送受信可能な状態になります。
    • サーバーの状態遷移: SYN_RECEIVED -> ESTABLISHED

この3つのステップを踏むことで、双方の初期シーケンス番号が交換され、通信に必要な情報（相手のポート番号、シーケンス番号、ウィンドウサイズなど）が共有されます。コネクションが確立された状態は「ESTABLISHED」と呼ばれます。

コネクションの維持: コネクションが確立された後、TCPはデータの送受信を行います。コネクション自体は、データが送受信されている間、アクティブな状態を保ちます。特にデータが送受信されなくても、定期的に小さなパケット（キープアライブパケットなど）を交換することでコネクションが生きているか確認することもあります。

コネクションの解放: 通信が終了したら、TCPはコネクションを解放します。このプロセスは通常「4ウェイハンドシェイク (Four-Way Handshake)」と呼ばれます。どちらか一方（例えばクライアント）が通信終了を要求することから始まります。

  1. FIN (Finish): 通信を終了したいクライアントが、FINフラグを立てたTCPセグメントをサーバーに送信します。「こちらからのデータ送信はもうありません」という意思表示です。クライアントは「FIN_WAIT_1」状態へ遷移します。
    • クライアントの状態遷移: ESTABLISHED -> FIN_WAIT_1
  2. ACK (Acknowledgement): FINを受け取ったサーバーは、FINに対する確認応答としてACKフラグを立てたTCPセグメントをクライアントに返信します。この時点で、サーバー側からクライアントへのデータ送信はまだ可能な「ハーフクローズ (Half-close)」状態になります。サーバーは「CLOSE_WAIT」状態へ遷移します。
    • サーバーの状態遷移: ESTABLISHED -> CLOSE_WAIT
    • クライアントの状態遷移: FIN_WAIT_1 -> FIN_WAIT_2 (ACKを受信後)
  3. FIN (Finish): サーバー側も送信すべきデータがなくなったら、通信終了を要求するため、FINフラグを立てたTCPセグメントをクライアントに送信します。「こちらもデータ送信を終了します」という意思表示です。サーバーは「LAST_ACK」状態へ遷移します。
    • サーバーの状態遷移: CLOSE_WAIT -> LAST_ACK
  4. ACK (Acknowledgement): サーバーからのFINを受け取ったクライアントは、そのFINに対する確認応答としてACKフラグを立てたTCPセグメントをサーバーに返信します。このACKがサーバーに届けば、サーバー側は完全にコネクションを閉じることができます（CLOSED状態へ遷移）。
    • クライアントの状態遷移: FIN_WAIT_2 -> TIME_WAIT (FINを受信後)
    • サーバーの状態遷移: LAST_ACK -> CLOSED (ACKを受信後)

クライアント側は、最後のACKを送信した後、すぐにCLOSED状態にはならず、しばらくの間「TIME_WAIT」状態にとどまります。これは、最後のACKがネットワーク上で失われた場合に、サーバーからの再送されたFINセグメントを正しく処理し、サーバーがCLOSED状態へ遷移できることを保証するためです。TIME_WAIT状態の長さは、通常「Maximum Segment Lifetime (MSL)」の2倍に設定されます（MSLはネットワーク上でセグメントが生存できる最大時間）。この状態が終了すると、クライアントもCLOSED状態へ遷移します。

このように、TCPはコネクションの確立から解放まで、丁寧な手順を踏むことで、信頼性の高い通信路を確保します。これは、通信相手が「存在し、通信可能であること」「互いの初期状態を把握すること」を保証するために不可欠なプロセスです。

3.2. 信頼性の確保：確認応答、再送制御、順序制御、チェックサム

TCPが「信頼性」を謳う上で、最も重要な機能群です。

3.2.1. 確認応答 (Acknowledgement, ACK)

TCPでは、送信されたデータが受信側に正しく届いたことを確認するために、受信側から送信側へ「確認応答 (ACK)」を返信します。ACKには、次に受信側が期待するデータのシーケンス番号（ACK番号）が含まれます。送信側は、送ったデータに対するACKが返ってくるのを待ちます。

  • シーケンス番号 (Sequence Number, Seq): TCPが送信する各バイトは、ストリーム内の位置を示す一意のシーケンス番号を持ちます。TCPセグメントのヘッダーにあるシーケンス番号フィールドには、そのセグメントに含まれるデータの最初のバイトのシーケンス番号が入ります。
  • 確認応答番号 (Acknowledgement Number, Ack): 受信側が次に受け取りたいと考えているデータのシーケンス番号を示します。例えば、送信側がシーケンス番号1000から始まる100バイトのデータを送った場合、受信側がこれを受け取ると、次に期待するのはシーケンス番号1100から始まるデータなので、ACK番号として1100を返信します。これは「累積確認応答」と呼ばれ、その番号までの全てのデータが正しく受信されたことを意味します。

3.2.2. 再送制御 (Retransmission)

送信側は、送ったデータに対応するACKが一定時間内に届かない場合、そのデータが失われたか、ACKが失われたと判断し、同じデータを再送します。ACKが届くまでの待ち時間は「再送タイムアウト (Retransmission Timeout, RTO)」と呼ばれ、ネットワークの状況（往復時間 RTT: Round Trip Time）に応じて動的に計算されます。単に時間が過ぎるのを待つだけでなく、「高速再送 (Fast Retransmit)」という仕組みもあります。これは、同じデータに対する重複したACK（通常3回以上）を受信した場合、タイムアウトを待たずにデータが失われたと判断して再送するものです。これにより、パケットロス発生時の復旧を高速化できます。

3.2.3. 順序制御 (Sequencing)

IP層はデータを独立したパケットとして扱うため、ネットワークの経路によっては、送信された順序とは異なる順序で受信側に届くことがあります。TCPでは、各セグメントにシーケンス番号が付与されているため、受信側は到着したセグメントをシーケンス番号順に並べ替えることができます。順番が乱れて届いたデータは、受信バッファに一時的に保持しておき、前のデータが届いてからアプリケーション層に正しい順序で渡されます。これにより、アプリケーションは常に送信された通りの順序でデータを受け取ることができます。

3.2.4. チェックサム (Checksum)

TCPセグメント全体（TCPヘッダー、データ、さらにIPヘッダーの一部情報を含む疑似ヘッダー）に対してチェックサムが計算されます。送信側はこのチェックサムを計算してヘッダーに格納し、受信側も同様の計算を行って、ヘッダー内のチェックサムと比較します。両者が一致しない場合、データがネットワーク上で破損したと判断し、そのセグメントは破棄されます。受信側は破棄したセグメントに対するACKを返さないため、送信側はタイムアウト後にそのセグメントを再送します。チェックサムはデータの破損を検出する機能であり、修正する機能ではありません。

これらの確認応答、再送制御、順序制御、チェックサムといった機能が連携することで、TCPはデータ転送の信頼性を極めて高く保っています。多少のネットワークの不安定さがあっても、アプリケーション層には正確なデータストリームとして渡すことができます。

3.3. 流量制御 (Flow Control)

流量制御は、送信側が受信側の処理能力を超えた速度でデータを送りつけないように調整する機能です。受信側のバッファがあふれてデータが破棄されるのを防ぐために行われます。TCPでは、「スライディングウィンドウ (Sliding Window)」という仕組みを使って流量制御を実現します。

  • 受信ウィンドウ (Receiver’s Window, RWND): 受信側は、自身が現在データを受信するために利用できるバッファのサイズ（バイト数）を、送信側に対して定期的に通知します。このサイズを受信ウィンドウサイズと呼びます。TCPヘッダーには「ウィンドウサイズ (Window Size)」フィールドがあり、ここに現在のRWNDの値が格納されます。
  • 送信ウィンドウ (Sender’s Window): 送信側は、受信側から通知されたRWNDのサイズを見て、まだ確認応答を受け取っていない（ACKが来ていない）データのうち、送信可能なデータの最大量を制限します。この制限量が送信ウィンドウサイズとなります。送信側は、送信ウィンドウの範囲内でしかデータを送信しません。ACKが届くと、送信ウィンドウは「スライド」し、より新しいデータを送信できるようになります。

例えば、受信ウィンドウサイズが5000バイトと通知された場合、送信側は最大で5000バイト分のデータを、ACKが返ってこないうちに続けて送信できます。最初の1000バイトのACKが返ってきたら、送信ウィンドウは1000バイト分スライドし、さらに1000バイト新しいデータを送信できるようになります。

これにより、受信側が忙しくてデータを処理できない場合（バッファが埋まってRWNDが小さくなる）、送信側は自動的に送信速度を落とします。受信側がデータ処理を終えてバッファに空きができれば（RWNDが大きくなる）、送信側は再び速度を上げることができます。

  • ゼロウィンドウ問題: 受信バッファが満杯になり、RWNDが0と通知された場合、送信側はそれ以上のデータを送信できません。しかし、受信側がバッファのデータを処理して空きができても、RWンドが0のままでは送信側はそれを知る術がありません。この問題を解決するため、送信側は「Persistent Timer」というタイマーを使用し、定期的に小さなパケット（ウィンドウプローブ）を送信して、受信側に現在のRWNDを通知してもらうように促します。

流量制御は、エンド・ツー・エンド（送信元から送信先まで）での速度調整を行う機能です。ネットワーク上の複数の通信が引き起こす混雑とは区別されます。

3.4. 輻輳制御 (Congestion Control)

輻輳制御は、ネットワーク全体の混雑（輻輳）を防ぐための機能です。ネットワーク機器（ルーターなど）のバッファがあふれてパケットが破棄されると、再送が増加し、さらにネットワークが混雑するという悪循環（輻輳崩壊）に陥る可能性があります。TCPの輻輳制御は、このような事態を避けるために、ネットワークの状況を推測し、送信速度を調整します。

輻輳制御は、主に「輻輳ウィンドウ (Congestion Window, cwnd)」という概念を使って実現されます。送信側は、受信ウィンドウ(rwnd)と輻輳ウィンドウ(cwnd)のうち、小さい方のサイズに基づいて送信できるデータ量を制限します（Effective Window = min(rwnd, cwnd)）。

TCPの輻輳制御アルゴリズムは進化しており、様々なバージョンがありますが、基本的な考え方は以下の4つのフェーズから構成されます。

  1. スロースタート (Slow Start): コネクション確立直後や、ネットワークでパケットロスが発生して輻輳が疑われる状態からの回復時に使用されます。最初は小さなcwnd（通常、最初のMSSまたは数MSS）から始め、ACKを受信するごとにcwndを指数関数的に増加させます。これにより、利用可能な帯域幅を急速に探し出します。増加は、事前に設定されたしきい値（ssthresh: Slow Start Threshold）に達するか、パケットロス（タイムアウトまたは重複ACK）が発生するまで続きます。
  2. 輻輳回避 (Congestion Avoidance): cwndがssthreshを超えた後、またはパケットロスからの回復後、cwndの増加ペースを緩めます。ACKを受信するごとにcwndを線形的に増加させます。具体的には、RTT（往復時間）あたり約1 MSSずつ増加させます。これは「Additive Increase Multiplicative Decrease (AIMD)」の一部で、線形増加部分にあたります。パケットロスが発生するまで、このフェーズが続きます。
  3. 高速再送 (Fast Retransmit): 前述の信頼性確保の項目でも触れましたが、これは輻輳を検知するメカニズムとしても機能します。送信側が同じACKを3回以上受信した場合（重複ACK）、ネットワークでパケットが失われた（つまり輻輳が始まった可能性がある）と判断し、タイムアウトを待たずに該当パケットを再送します。
  4. 高速回復 (Fast Recovery): 高速再送が発生した場合に続くフェーズです。タイムアウトが発生した場合に比べて、ネットワークはまだ完全に崩壊しているわけではないと判断し、スロースタートに戻るのではなく、輻輳回避に近い形でcwndを回復させます。アルゴリズムによって詳細は異なりますが、一般的にはssthreshをパケットロス発生時のcwndの半分程度に設定し、cwndを線形的に回復させようとします。

パケットロスが発生した場合、輻輳が発生したとみなされ、cwndは大幅に減少させられます（AIMDのMultiplicative Decrease部分）。具体的には、タイムアウトが発生した場合はcwndを初期値に戻し、高速再送が発生した場合はcwndを半分程度に減らすことが多いです（アルゴリズムによる）。

代表的なTCP輻輳制御アルゴリズムには、TCP Tahoe, TCP Reno, TCP NewReno, TCP SACK, TCP Cubic (Linuxのデフォルト), TCP BBRなどがあり、それぞれcwndの増加や減少の仕方、パケットロス検知後の挙動に違いがあります。これらのアルゴリズムは、様々なネットワーク環境（高速・高遅延、低速・低遅延など）でより効率的に帯域幅を利用し、かつネットワークの公平性や安定性を保つために研究・開発されてきました。

輻輳制御は、個々の通信の送信速度を調整することで、ネットワーク全体のスループットを最大化し、輻輳崩壊を防ぐ協力的なメカニズムです。もしTCPがこの機能を持っていなければ、皆が最大速度でデータを送り続けようとし、ネットワークはすぐに麻痺してしまうでしょう。

3.5. 全二重通信 (Full-Duplex)

TCPコネクションが確立されると、送信側と受信側は同時に互いにデータを送受信できます。これは電話のように、双方向で同時に会話できる状態に例えられます。TCPヘッダーには送信用のシーケンス番号と受信用の確認応答番号が両方含まれており、これによりデータの送受信が同時に行われます。HTTP/1.1以降の永続的コネクションや、FTPのデータ転送コネクションなど、双方向通信が必要なプロトコルでこの全二重性が活かされます。

3.6. セグメント化 (Segmentation) とTCPヘッダー

アプリケーション層から渡されるデータは、ネットワーク層で扱うには大きすぎる場合があります。TCPは、このデータを適切なサイズ（通常、ネットワーク層のMTUに基づいて決定されるMSS: Maximum Segment Size以下）に分割します。この分割された単位を「TCPセグメント」と呼びます。

各TCPセグメントには、制御情報を含む「TCPヘッダー」が付加されます。TCPヘッダーは、これらの制御機能（コネクション、信頼性、流量制御、輻輳制御など）を実現するために様々なフィールドを含んでおり、通常は20バイト（オプションがない場合）以上のサイズになります。

TCPヘッダーの主要なフィールド (20バイト):

  • 送信元ポート番号 (Source Port): 16ビット。データを送信するアプリケーションのポート番号。
  • 宛先ポート番号 (Destination Port): 16ビット。データを受信するアプリケーションのポート番号。
  • シーケンス番号 (Sequence Number): 32ビット。このセグメントに含まれるデータの最初のバイトのシーケンス番号（接続開始時はISN）。
  • 確認応答番号 (Acknowledgement Number): 32ビット。次に期待するデータのシーケンス番号（ACKフラグが設定されている場合のみ有効）。
  • データオフセット (Data Offset / Header Length): 4ビット。TCPヘッダーの長さを示す（32ビットワード単位）。オプションフィールドの有無によって可変。
  • 予約済み (Reserved): 6ビット。将来の使用のために予約されており、通常は0。
  • フラグ (Flags / Control Bits): 6ビット。TCPコネクションの状態や制御を示すフラグ。
    • URG (Urgent Pointer): 緊急ポインタが有効であることを示す。
    • ACK (Acknowledgement): 確認応答番号フィールドが有効であることを示す。
    • PSH (Push): 受信側でデータをバッファリングせず、すぐにアプリケーションに渡すように促す。
    • RST (Reset): コネクションを強制的に終了させる。
    • SYN (Synchronize): コネクション確立要求。
    • FIN (Finish): コネクション終了要求。
  • ウィンドウサイズ (Window Size): 16ビット。受信側が現在受信できるデータのバイト数（受信ウィンドウサイズRWND）。流量制御に使用される。
  • チェックサム (Checksum): 16ビット。ヘッダー、データ、および一部のIPヘッダー情報（疑似ヘッダー）に対するチェックサム。データ破損の検出に使用される。
  • 緊急ポインタ (Urgent Pointer): 16ビット。URGフラグが設定されている場合に有効。セグメント内で緊急データがどこまで含まれているかを示す。ほとんど使われない。
  • オプション (Options): 可変長。MSS（最大セグメントサイズ）通知、ウィンドウズケール（RWNDを大きくするため）、SACK（選択的ACK）など、追加のTCP機能に関する情報。

これらのヘッダーフィールドを見るだけでも、TCPがいかに多くの制御情報を含み、複雑な処理を行っているかが分かります。このヘッダー情報を使って、TCPは上記で説明した様々な機能を実現しています。

4. UDP (User Datagram Protocol) とは？その本質

UDPは「ユーザーデータグラムプロトコル」と呼ばれ、TCPと同じトランスポート層に位置しますが、その性質は大きく異なります。UDPはコネクションレス型のプロトコルであり、信頼性よりも速度や効率性を重視します。

UDPは、データを送る前にコネクションを確立する手順を踏みません。データを送りたいときに、宛先IPアドレスと宛先ポート番号を指定して、一方的にデータグラムを送信します。電話というよりは、葉書や手紙を送るイメージに近いでしょう。送った葉書が相手に届いたか、破れていないか、順番通りに届いたか、といった確認は一切行いません。

UDPの主な特徴:

  • コネクションレス (Connectionless): コネクションの確立・維持・解放のオーバーヘッドがないため、通信開始が高速です。
  • 非信頼性 (Unreliable):
    • 確認応答・再送制御なし: データが相手に届いたか確認しない。失われたデータの再送も行わない。
    • 順序制御なし: データグラムは送信された順序と異なる順序で到着する可能性がある。アプリケーション側で順序を保証する必要がある場合がある。
    • チェックサムはオプション: ヘッダーとデータに対するチェックサム計算は可能ですが、必須ではありません（IPv4ではオプション、IPv6では必須）。検出機能はありますが、再送は行いません。
  • 流量制御・輻輳制御なし: ネットワークや受信側の状態に関わらず、データを指定された速度で送信し続けます。
  • シンプルなヘッダー: TCPヘッダーに比べて非常にシンプルです。通常はわずか8バイトです。

UDPヘッダーのフィールド (8バイト):

  • 送信元ポート番号 (Source Port): 16ビット。
  • 宛先ポート番号 (Destination Port): 16ビット。
  • 長さ (Length): 16ビット。UDPヘッダーとデータグラムに含まれるデータの合計長（バイト数）。
  • チェックサム (Checksum): 16ビット。ヘッダー、データ、および疑似ヘッダーに対するチェックサム（IPv4ではオプション）。

UDPは、そのシンプルさゆえに、TCPのような複雑な処理や状態管理が必要ありません。これは、プロトコルとしてのオーバーヘッドが非常に小さく、高速なデータ転送が可能であることを意味します。

どのようなアプリケーションでUDPが使われるか？

信頼性よりもリアルタイム性や速度が重視されるアプリケーションでUDPはよく利用されます。

  • DNS (Domain Name System): ドメイン名とIPアドレスの変換。迅速な応答が求められるためUDPが使われます。クエリと応答の小さなデータなので、失われても再送は容易です。
  • DHCP (Dynamic Host Configuration Protocol): ネットワーク参加時にIPアドレスなどを割り当てるプロトコル。ブロードキャスト通信を利用するためUDPが適しています。
  • VoIP (Voice over IP): インターネット電話。音声データはリアルタイム性が重要で、多少のデータ欠落があっても会話は継続できます。TCPで再送を待つよりも、失われたパケットは無視して次のパケットを処理する方が体験が良い場合があります。
  • オンラインゲーム: 特にリアルタイム性の高いFPSなどのゲーム。位置情報や操作情報など、最新の情報が常に必要なため、古い情報が遅れて届く（TCPの再送）よりも、多少欠落しても新しい情報を受け取る方が重要です。ゲームによっては、UDPの上に独自の信頼性レイヤーを実装することもあります。
  • ストリーミング配信: 動画や音楽のリアルタイム配信。VoIPと同様、多少のデータ欠落は許容しつつ、再生を止めないことが重要です。
  • NTP (Network Time Protocol): 時刻同期プロトコル。

これらのアプリケーションでは、TCPの確立や制御にかかる時間や、再送による遅延がデメリットになる場合があります。UDPは、アプリケーション側で必要に応じて信頼性や順序制御の仕組みを実装することで、用途に特化した柔軟な通信プロトコルを構築するための基盤ともなり得ます。

5. TCPとUDPの比較：どちらを選ぶべきか？

特徴 TCP (Transmission Control Protocol) UDP (User Datagram Protocol)
通信方式 コネクション指向 (Connection-Oriented) コネクションレス (Connectionless)
信頼性 高い (確認応答、再送制御、順序制御、チェックサム) 低い (非信頼性)
通信速度 遅い (制御のためのオーバーヘッドが大きい) 速い (オーバーヘッドが小さい)
制御機能 流量制御、輻輳制御、順序制御、エラー制御 (破損検出と再送) なし (エラー検出のためのチェックサムはオプション)
オーバーヘッド 大きい (複雑なヘッダーと制御処理) 小さい (シンプルなヘッダーと処理)
ヘッダーサイズ 通常20バイト + オプション 8バイト
アプリケーション Web (HTTP/HTTPS), メール (SMTP, POP3, IMAP), ファイル転送 (FTP), リモートログイン (SSH), 多くのアプリケーションプロトコル DNS, DHCP, VoIP, オンラインゲーム, ストリーミング, NTP
複雑さ 高い (多くの状態管理とアルゴリズム) 低い (シンプル)

TCPを選ぶべきケース:

  • データの信頼性が絶対に必要な場合。例えば、Webサイトのテキストや画像、メールの内容、送受信するファイルなど、1バイトでも欠けたり変わったり、順序が狂ったりすると困るデータ。
  • 送信側が受信側の処理能力を考慮して速度を調整する必要がある場合。
  • ネットワーク全体の混雑を考慮して速度を調整する必要がある場合（インターネット上での公平な帯域幅利用）。
  • アプリケーション側での信頼性や順序制御の実装を避けたい場合。

UDPを選ぶべきケース:

  • データのリアルタイム性が信頼性よりも重要な場合。多少のデータ欠落は許容できるが、遅延は避けたい場合。
  • コネクション確立・維持・解放のオーバーヘッドを避けたい場合。
  • ブロードキャストやマルチキャスト通信を行いたい場合（TCPは基本的にユニキャスト）。
  • アプリケーション側で独自の信頼性や順序制御の仕組みを実装したい場合。
  • 非常にシンプルな通信で、オーバーヘッドを最小限に抑えたい場合。

例えば、Webページを表示する際に、ページのコンテンツ（HTML、画像、CSSなど）が不完全だったり、順序が狂っていたりすると、正しく表示されません。そのため、Web通信（HTTP/HTTPS）には信頼性の高いTCPが必須です。一方、オンラインゲームでキャラクターの動きが遅れて表示されるよりは、多少カクついても最新の情報がすぐに反映される方がゲーム体験として優れていることが多いです。そのため、ゲームの通信にはUDPがよく利用されます。

また、ストリーミング配信のように、ある程度の信頼性は欲しいが、TCPほど厳密な再送や順序制御は不要で、リアルタイム性も重要な場合は、UDPの上に独自の信頼性や順序制御の仕組みを実装したり、TCPとUDPを組み合わせて使用したりすることもあります（例：動画データはUDPで送り、制御信号はTCPで送る）。

まとめ：ネットワーク基礎としてのTCP理解の重要性

この記事では、インターネットのトランスポート層における主要なプロトコルであるTCPに焦点を当て、その詳細な仕組みと主要な特徴を解説しました。TCPは、コネクション指向であること、そして確認応答、再送制御、順序制御、チェックサム、流量制御、輻輳制御といった様々な機能を駆使することで、インターネット上で極めて信頼性の高いデータ転送を実現しています。

一方で、UDPはTCPとは対照的に、コネクションレスで信頼性機能を持たないシンプルなプロトコルであり、その分高速でオーバーヘッドが小さいという特徴を持ちます。信頼性よりもリアルタイム性や効率性が求められる様々なアプリケーションで利用されています。

TCPとUDPは、それぞれ異なる性質を持ち、ネットワークアプリケーションの要件に応じて適切に使い分けられています。HTTP、FTP、SSHといった多くの基幹プロトコルがTCPの上に構築されていることからもわかるように、TCPは現代インターネットの信頼性を支える屋台骨とも言える存在です。

ネットワークの基礎を理解する上で、TCPの「信頼性確保」「流量制御」「輻輳制御」といったメカニズムを深く理解することは非常に重要です。これらの制御がどのように行われているかを知ることで、ネットワークのパフォーマンス問題の原因を探ったり、ネットワーク設計の考え方を理解したりする上で役立ちます。

この記事を通じて、TCPの強力な機能とその裏側にある複雑なメカニズム、そしてUDPとの違いによる使い分けの考え方について、理解を深めていただけたなら幸いです。

TCP/IPプロトコルは、インターネットが今日のように発展する上で不可欠な技術基盤です。今回のTCP入門が、あなたのネットワーク知識をさらに深めるための一助となれば嬉しく思います。

約5000語を目指して記述しましたが、厳密な文字数は環境や計算方法によって多少前後します。内容としては、TCPの主要な特徴（コネクション指向、信頼性、流量制御、輻輳制御、全二重通信、セグメント化/ヘッダー）について、それぞれ詳細な仕組みを含めて解説し、UDPとの違いや使い分けについても比較しました。入門者にも分かりやすく、かつ技術的な詳細にも踏み込むことを意識して記述しました。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール