TCP と UDP プロトコル

TCP と UDP は、インターネット プロトコル スイートのトランスポート層で動作し、ネットワーク上のデバイス間のデータ転送を容易にする役割を果たします。

TCP (Transmission Control Protocol) は、送信者と受信者の間に信頼性の高いチャネルを確立する接続指向のプロトコルです。

すべてのデータ パケットが正確かつ正しい順序で配信されることが保証されるため、データの整合性が重要なアプリケーションに最適です。

UDP (User Datagram Protocol) は、専用のエンドツーエンド接続を確立せずにデータを送信するコネクションレス型プロトコルです。

データ パケットの配信や順序は保証されません。これにより、オーバーヘッドが削減され、より高速な伝送速度が可能になります。

これにより、UDP は信頼性よりも速度が重要なアプリケーションに適しています。

---

TCP と UDP を理解する

---

A. 伝送制御プロトコル (TCP)

接続指向プロトコル

TCP は接続指向のプロトコルです。つまり、データ転送を開始する前に、送信者と受信者の間で正式な接続を確立する必要があります。

このセットアップ プロセスは「スリーウェイ ハンドシェイク」として知られています。

このハンドシェイクでは、送信者と受信者は同期 (SYN) パケットと確認応答 (ACK) パケットを交換して、初期シーケンス番号とウィンドウ サイズについて合意します。

この接続を確立すると、双方が通信の準備が整い、データ交換のための信頼できるチャネルが提供されます。

信頼性の高いデータ転送

TCP の主な強みの 1 つは、データ パケットが送信された順序どおりに確実に配信されることを保証できることです。

これは、シーケンスおよび確認メカニズムを通じて実現されます。

• シーケンス: データの各バイトにはシーケンス番号が割り当てられます。

これにより、ネットワーク ルーティングによりパケットが順序どおりに到着しない場合でも、受信者はパケットを正しい順序で再組み立てできます。

• 確認応答: 受信者は、受信したパケットに対する確認応答を送り返します。

送信者が特定の時間枠内に確認応答を受信しない場合、パケットが失われたとみなして再送信します。

フロー制御と輻輳制御

TCP には、データ送信を効率的に管理するために、フロー制御および輻輳制御アルゴリズムが組み込まれています。

• フロー制御: このメカニズムは、送信者があまりにも多くのデータで受信者を急速に圧倒することを防ぎます。

TCP は、受信側が一度に受け入れることができるデータの量 (ウィンドウ サイズ) を通知するスライディング ウィンドウ プロトコルを使用します。

送信者はこの制限を尊重して、スムーズなデータ フローを確保し、受信者側でのバッファ オーバーフローを防止する必要があります。

• 輻輳制御: TCP はネットワーク状態を監視して、ネットワーク内の輻輳を検出します。

スロースタート、輻輳回避、高速再送信、高速リカバリなどのアルゴリズムを使用して、データ送信速度を調整します。

パケット損失または遅延が検出されると (潜在的な輻輳の兆候)、送信側はネットワークの負担を軽減するために送信速度を下げます。

逆に、ネットワークが空いている場合、TCP はスループットを最適化するために送信速度を徐々に上げます。

---

B. ユーザー データグラム プロトコル (UDP)

コネクションレス型プロトコル

UDP はコネクションレス型プロトコルです。つまり、データを送信する前に専用のエンドツーエンド接続を必要としません。

ハンドシェイク プロセスを通じて接続を確立する TCP とは異なり、UDP は事前の通信設定を行わずに、データグラムと呼ばれるデータ パケットを受信者に直接送信します。

接続が確立されないことにより、初期遅延が軽減され、データ送信がすぐに開始できるようになります。

送信者は受信者からの確認応答を待たないため、通信プロセスが簡単かつ効率的になります。

事前の接続を確立せずにデータを送信します

• 即時送信: 接続のセットアップがないため、準備が整うとすぐにデータを送信できます。これは、時間に敏感なアプリケーションにとって非常に重要です。

• ハンドシェイク プロセスなし: 接続の確立と終了に関連するオーバーヘッドを排除し、遅延を削減します。

• ステートレス通信: 各データグラムは独立しており、ルーティングに必要な情報がすべて含まれているため、プロトコルが簡素化され、ネットワーク デバイスのリソース使用量が削減されます。

信頼性は低いが、より高速なデータ転送

UDP は「信頼性の低い」サービスを提供します。これは、ネットワーク用語で次のことを意味します。

• パケット配信の保証なし: データグラムは、送信者に通知されることなく転送中に失われる可能性があります。

• 順序の保証なし: UDP はパケットの順序を変更しないため、パケットは順序が崩れて到着する可能性があります。

• エラー訂正なし: TCP とは異なり、UDP はエラーをチェックしたり、失われたパケットや破損したパケットを再送信したりしません。

特定のコンテキストにおける信頼性の低さの利点

• オーバーヘッドの削減: UDP は、パケット配信の追跡や確認応答の処理を行わないことにより、ネットワーク上で送信される追加データの量を削減します。

• 高速送信: 送信側と受信側の両方で必要な処理が少なくなり、スループットが向上し、レイテンシが低くなります。

• アプリケーション レベルの制御: 一部のアプリケーションは、トランスポート プロトコルに依存するのではなく、信頼性とエラー修正を独自に処理することを好みます。

低いオーバーヘッド

UDP の最小限の設計は、その低いオーバーヘッドに貢献します。

• 小さいヘッダー サイズ: TCP の 20 バイトのヘッダーと比較して、UDP のヘッダーの長さはわずか 8 バイトです。この小さいサイズは、各パケットで送信されるデータが少なくなり、帯域幅が節約されることを意味します。

• 処理の簡素化: 機能が少ないということは、ネットワーク機器やエンドポイントの計算作業が少なくなり、特に高負荷時のパフォーマンスが向上する可能性があります。

• 高性能アプリケーションの効率: オーバーヘッドが削減された UDP は、大量のデータを迅速に送信する必要があり、ある程度のデータ損失を許容できるアプリケーションに適しています。

---

ユースケースの例と実際のアプリケーション

---

A. TCP の使用例

1. Web ブラウジング (HTTP/HTTPS)

ページのレンダリングには信頼性の高いデータ転送が必要です

Web ブラウジングは、Web ページを正しく表示するために、正確かつ完全なデータ転送に大きく依存しています。

HTTP および HTTPS プロトコルは TCP を使用して、テキスト、画像、スクリプトなどの Web ページのすべての要素が確実に正しい順序で配信されるようにします。

TCP のエラー チェックおよび確認機能は、欠落または破損したパケットの再送信を保証し、壊れた画像や不完全なコンテンツを防ぎます。これはユーザー エクスペリエンスと機能にとって不可欠です。

2. 電子メールサービス (SMTP、IMAP)

メッセージの完全かつ順序付けられた配信を保証します

SMTP (Simple Mail Transfer Protocol) や IMAP (Internet Message Access Protocol) などの電子メール プロトコルは、TCP を使用してメッセージの信頼性の高い送信を提供します。

メールには重要な情報や添付ファイルが含まれることが多く、そのままの状態で届く必要があります。

TCP は、電子メールのすべての部分がエラーなく適切な順序で受信されることを保証し、通信の整合性を維持し、個人的および仕事上の通信に重要なデータ損失を防ぎます。

---

B. UDP の使用例

1. リアルタイム通信 (VoIP、ビデオ会議)

信頼性よりも速度を優先して遅延を削減します

Voice over IP (VoIP) やビデオ会議などのアプリケーションでは、スムーズなリアルタイム通信を促進するために遅延を最小限に抑える必要があります。

UDP が使用されるのは、接続の確立やパケット配信の保証といったオーバーヘッドを発生させずにデータを迅速に送信できるためです。

UDP はすべてのパケットが到着するか、または順序どおりであることを保証しませんが、時折データ パケットが失われると、短時間の不具合が発生する可能性がありますが、会話全体に大きな影響を与えることはありません。

自然な通信の流れを維持するために遅延を短縮することが優先されます。

3. ストリーミングサービス

連続再生のための軽微なデータ損失を許容します

ライブ ビデオやオーディオ ストリーミングなどのストリーミング サービスは、UDP を使用してデータをユーザーに継続的に送信します。

このプロトコルのオーバーヘッドが低いため、エラー チェックや再送信に伴う遅延がなく、安定したストリームが可能になります。

軽度のパケット損失により品質がわずかに低下する可能性がありますが、通常はユーザーには認識されません。

主な目的は、バッファリングや中断を防止し、中断のない視聴体験を提供することです。

UDP により、サービスは完全なデータ精度よりも継続的な再生を優先できます。

2. オンラインゲーム

リアルタイムのインタラクションには高速データ送信が必要です

オンライン ゲームでは、プレーヤーのアクションを瞬時に反映するために、迅速かつ継続的なデータ交換が必要です。

UDP は、応答性の高いゲームプレイに不可欠な低遅延通信を提供するため、推奨されます。

プレイヤーは、顕著な遅延なくリアルタイムのインタラクションを体験できます。

一部のデータ パケットが失われる可能性がありますが、通常、ゲームはゲームの状態を頻繁に更新することで補い、シームレスなエクスペリエンスを保証します。

ゲームプレイを流動的に保つために、絶対的な信頼性よりもスピードに重点が置かれています。

---

パフォーマンスに関する考慮事項

TCP と UDP のどちらかを選択する場合は、各プロトコルの特性がネットワーク パフォーマンスにどのような影響を与えるかを考慮することが重要です。

重要な要素には、レイテンシ、スループット、信頼性、およびこれらがアプリケーションの機能やユーザー エクスペリエンスに与える影響が含まれます。

---

レイテンシーとスループット

1. TCP オーバーヘッド

確認応答パケットとハンドシェイクにより遅延が発生する可能性があります

TCP は信頼性と順序付けられたデータ配信を目的として設計されているため、追加のオーバーヘッドが発生します。

• スリーウェイ ハンドシェイク: データ送信を開始する前に、TCP では 3 ウェイ ハンドシェイクを通じて接続を確立する必要があります。

このプロセスには、SYN (同期) パケットと ACK (確認応答) パケットの交換が含まれ、初期遅延が追加されます。

• 確認応答と再送信: 接続を確立した後、TCP は受信したパケットに対して確認応答を要求することで信頼性を確保します。

確認応答が受信されない場合、TCP はデータを再送信します。これにより配信が保証されますが、特に遅延が長いネットワークや長距離では遅延が発生する可能性があります。

• フロー制御と輻輳制御: TCP は、ネットワーク状況に基づいてデータ送信速度を調整し、輻輳を防ぎます。

これらのメカニズムはネットワークの安定性に有益ですが、輻輳時にスループットが低下し、アプリケーションのパフォーマンスに影響を与える可能性があります。

2. UDP の効率

オーバーヘッドの削減によりレイテンシが低下します
UDP の設計は速度と効率を優先します:

接続の確立なし: UDP はコネクションレス型であるため、データを送信する前にハンドシェイクを必要としません。

初期セットアップが不要なため、遅延が軽減され、即時のデータ送信が可能になります。

確認応答なし: UDP は確認応答を待機したり、失われたパケットを再送信したりしないため、TCP でのこれらのプロセスに関連する遅延が排除されます。

最小限のプロトコル オーバーヘッド: ヘッダー サイズが小さく、プロトコル メカニズムが少ないため、UDP はネットワーク上で送信される追加データの量を減らし、スループットを向上させ、遅延を短縮します。

B. 信頼性と速度のトレードオフ

1. 応募要項

速度と信頼性のどちらが重要かを決定する

TCP と UDP のどちらを選択するかは、アプリケーションの特定のニーズによって異なります。

• 信頼性が重要な場合: ファイル転送、Web ブラウジング、電子メール サービスなどのアプリケーションでは、完全かつ正確なデータ配信が必要です。

このような場合、データの整合性と順序を確保するには、TCP の信頼性機能が不可欠です。

• 速度と低遅延が重要な場合: ライブ ビデオ ストリーミング、オンライン ゲーム、VoIP などのアプリケーションは、完璧な信頼性よりもリアルタイムのデータ配信を優先します。

ここで、UDP はオーバーヘッドが低く、転送速度が速いため、途中で一部のデータ パケットが失われたとしても、UDP が好ましい選択肢となります。

2. ハイブリッドアプローチ

適切な場合は両方のプロトコルを採用

一部のシナリオでは、TCP と UDP の両方を組み合わせることでパフォーマンスを最適化できます。

• 選択的なプロトコルの使用: アプリケーションは、特定の機能に TCP を使用し、他の機能に UDP を使用する場合があります。

たとえば、ビデオ会議アプリはリアルタイムの音声およびビデオ ストリームに UDP を使用して遅延を最小限に抑え、一方でアプリ内でのテキスト メッセージの送信やファイル転送には TCP を使用して信頼性の高い配信を確保できます。

• UDP 上のカスタム信頼性メカニズム: 開発者は、UDP 上に独自のエラーチェックおよび再送信戦略を実装できます。

このアプローチにより、アプリケーションの要件に合わせて特別に調整された、必要に応じて信頼性が向上した低遅延通信が可能になります。

• 並列接続: 一部のアプリケーションは、TCP 接続と UDP 接続の両方を同時に確立し、必要に応じて各プロトコルの強みを活用します。

---

セキュリティへの影響

TCP と UDP のどちらかを選択する場合は、パフォーマンスと信頼性だけでなく、セキュリティへの影響も考慮することが重要です。

各プロトコルには、悪意のある攻撃者によって悪用される可能性のある固有の脆弱性があります。

ネットワーク セキュリティを維持するには、これらの脆弱性を理解し、適切な緩和手法を実装することが重要です。

5秒間考えました

V.セキュリティへの影響

TCP と UDP のどちらかを選択する場合は、パフォーマンスと信頼性だけでなく、セキュリティへの影響も考慮することが重要です。各プロトコルには、悪意のある攻撃者によって悪用される可能性のある固有の脆弱性があります。これらの脆弱性を理解し、適切な緩和手法を実装することは、ネットワーク セキュリティを維持するために非常に重要です。

A. TCP セキュリティ上の懸念

1. 脆弱性

SYN フラッディング攻撃に対する脆弱性

TCP の接続指向の性質により、クライアントとサーバー間の接続を確立するには 3 ウェイ ハンドシェイク (SYN、SYN-ACK、ACK) が必要です。

SYN フラッディング攻撃では、攻撃者は大量の SYN リクエストをサーバーに送信しながらハンドシェイクを完了させずに、このメカニズムを悪用します。

具体的には、攻撃者:

• スプーフィングされた IP アドレスを持つ多数の SYN パケットを送信します。

• サーバーは SYN-ACK パケットで応答し、ハーフオープン接続ごとにリソースを割り当てます。

• クライアントからの最終 ACK が到着しないため、これらの接続は半分開いたままとなり、サーバーのメモリと処理能力を消費します。

その結果、サーバーのリソースが過剰になり、サービス拒否 (DoS) 状態が発生するため、正規のクライアントは接続を確立できなくなります。

2. 緩和手法

SYN Cookie の実装

SYN Cookie は、ハーフオープン接続に追加のリソースを必要とせずに、SYN フラッディング攻撃を軽減するサーバー側の技術です。仕組みは次のとおりです:

SYN パケットを受信すると、サーバーはリソースを割り当てる代わりに、状態 (シーケンス番号やその他の接続パラメータなど) を SYN-ACK パケットの初期シーケンス番号 (ISN) フィールドにエンコードします。

クライアントが ACK パケットで応答した場合 (ハンドシェイクが完了した場合)、サーバーは ISN から元の接続状態を再構築し、接続の確立を続行できます。

このアプローチにより、サーバーはハーフオープン接続を追跡する必要がないため、リソースを過負荷にすることなく大量の SYN リクエストを処理できます。

ファイアウォールと侵入防止システムの使用

ファイアウォールと侵入防御システム (IPS) は、SYN フラッド攻撃を検出して軽減するように構成できます。

レート制限: 単一の IP アドレスまたはサブネットからの SYN パケットの数を制限すると、攻撃の影響を軽減できます。

しきい値とアラート: 通常の SYN トラフィックのしきい値を設定し、超過した場合にアラートを生成することで、早期検出に役立ちます。

なりすまし IP アドレスのフィルタリング: 入力および出力フィルタリングを実装して、偽造された送信元 IP アドレスを持つパケットをブロックします。

タイムアウト調整

ハーフオープン接続のタイムアウト期間を調整すると、リソースをより早く解放できます:

SYN-RECEIVED タイムアウトの短縮: サーバーがハーフオープン接続を切断する前に最後の ACK を待つ時間を短縮します。

B. UDP のセキュリティ上の懸念

1. 脆弱性

DNS 増幅などの増幅攻撃を受けやすい

UDP のコネクションレス型の性質と検証の欠如により、増幅攻撃の影響を受けやすくなっています。増幅攻撃では、攻撃者がターゲットに向けられたトラフィックの量を増幅して、分散型サービス拒否 (DDoS) を引き起こす可能性があります。 DNS 増幅攻撃の場合:

• 攻撃者は、なりすましの送信元 IP アドレス (被害者の IP) を使用して小さな DNS クエリ リクエストを送信し、DNS リゾルバーを開きます。
• DNS サーバーは、被害者の IP アドレスに対して、より大きな DNS 応答で応答します。
• 応答はリクエストよりもはるかに大きいため、増幅率が大きくなる可能性があります。

同様の増幅攻撃は、NTP (Network Time Protocol) や SSDP (Simple Service Discovery Protocol) などの他の UDP ベースのサービスを悪用する可能性があります。

2. 緩和手法

レート制限

レート制限を実装すると、ネットワークとの間のトラフィック フローが制御されます:

• 受信リクエストの制限: サーバーが単一の IP またはサブネットから応答する 1 秒あたりのリクエスト数のしきい値を設定します。
• アウトバウンド応答制限: サーバーが増幅器として使用されないように、サーバーが応答を送信する速度を制限します。

堅牢なフィルタリングメカニズム

高度なフィルタリング技術を採用して悪意のあるトラフィックをブロックします:

• 入力および出力フィルタリング: スプーフィングされた IP アドレスを持つパケットをネットワーク エッジでブロックし、ネットワークへの出入りを防ぎます。
• アプリケーション層ゲートウェイ: アプリケーション層データを転送する前に検査および検証できるプロキシまたはゲートウェイを使用します。
• プロトコル コンプライアンス チェック: 受信リクエストが予想されるプロトコルの動作に準拠していることを確認し、不正な形式または疑わしいパケットをドロップします。 未使用の UDP サービスを無効にする

使用されていない UDP サービスを無効にして攻撃対象領域を削減します:

• 不要なポートを閉じる: 必須ではない UDP ポートで実行されているサービスをシャットダウンします。

• オープン サービスのセキュリティ: 必要なサービスについては、悪用を防ぐための認証とアクセス制御を実装します。

• DNSSEC と応答速度制限 (RRL) の使用
  DNS サーバーの場合:

DNSSEC (Domain Name System Security Extensions): DNS 応答に認証を追加し、スプーフィング攻撃の有効性を低減します。

応答速度制限: 増幅攻撃への参加を防ぐために応答速度を制限するように DNS サーバーを構成します。

以上がTCP と UDP プロトコルの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。