IP カメラをビデオ監視プラットフォームに接続する際、よくある設定の質問の 1 つは、ビデオを TCP と UDP のどちらで伝送するかというものです。多くのネットワークカメラと監視プラットフォームは両方のオプションをサポートしていますが、パケット損失、遅延、輻輳、または不安定なネットワーク条件が発生した場合、これら 2 つのプロトコルの動作は大きく異なります。

すべての監視プロジェクトに自動的に適した単一のプロトコルは存在しません。TCP は信頼性の高い順序付き配信をより重視する一方、UDP は伝送オーバーヘッドを削減し、一般的に低遅延が優先される状況により適しています。適切な選択は、ネットワークパス、リアルタイム表示の重要性、利用可能な帯域幅の安定性、およびアプリケーションが許容できるパケット損失量に依存します。

この区別は、監視システムが単一のローカルネットワークを超えて拡張されるにつれて、ますます重要になります。監視センターと同じ建物に設置されたカメラは安定した予測可能な条件下で動作するかもしれませんが、広域ネットワークやインターネットリンクを介して接続された別のカメラは、帯域幅の変動、パケット損失、一時的な輻輳を経験する可能性があります。両方の環境で同じトランスポート設定を使用しても、常に同じ結果が得られるとは限りません。

トランスポート方式が重要な理由

監視カメラは継続的にビデオデータを生成し、それがフィールドデバイスから監視プラットフォーム、録画システム、またはリモート視聴ポイントへと伝送される必要があります。このデータの伝送方法は、ビデオの到着速度や、ネットワークが不安定になったときのシステムの動作に影響を与える可能性があります。

十分な帯域幅と比較的安定した接続性を備えた制御されたローカルネットワークでは、短期的な小幅な変動にもかかわらず、伝送はスムーズに維持されるかもしれません。しかし、同じビデオがより広範なネットワークやインターネットリンクを経由する必要がある場合、パケット損失、輻輳、およびネットワーク状態の変化がより重要になります。

ビデオ監視は、データの価値が時間と密接に関連しているという点で、通常のファイル転送とは異なります。ライブ監視中、オペレーターは通常、数秒後ではなく、今何が起こっているかを確認する必要があります。欠落データの回復に余分な時間を費やすプロトコルは完全性を向上させるかもしれませんが、イベントとその監視画面への表示との間の遅延も増加させる可能性があります。

TCP と UDP はこれらの条件に異なる対応をします。TCP は信頼性の高い配信を維持しようと試みる一方、UDP はすべてのパケットの確認応答を待たずに直接伝送を優先します。この違いは、ビデオ監視におけるほとんどの実用的なプロトコル選択の決定の基礎となります。

このため、プロトコルの選択は、孤立したカメラ設定としてではなく、監視ネットワーク設計全体の一部として考慮されるべきです。カメラの台数、伝送距離、ネットワーク品質、同時視聴要件、およびリアルタイム応答の重要性はすべて最終結果に影響します。

TCP がビデオ伝送を処理する方法

TCP（Transmission Control Protocol）はコネクション指向です。通常のデータ伝送が始まる前に、通信エンドポイント間にコネクションが確立されます。その後、TCP はデータの配信を管理し、情報が確実に正しい順序で宛先に届くようにします。

伝送中にパケットが損失または破損した場合、TCP は欠落情報を再送信できます。確認応答メカニズムにより、送信側はデータが正常に受信されたかどうかを判断できます。これにより、データの完全性と信頼性の高い配信が重要な場合に TCP が役立ちます。

順序付き配信も重要な特性です。データパケットが予期しない順序で到着した場合、TCP はそれらを再編成してから受信アプリケーションにデータを提示できます。信頼性の観点から、この動作は、個々のパケットが損失または遅延したときに受信側が不完全なシーケンスのまま放置されないため、価値があります。

トレードオフは、追加の伝送オーバーヘッドです。コネクションの確立と維持、受信データの確認、および損失パケットの再送信は遅延を引き起こす可能性があります。ネットワーク状態が悪化すると、再送信情報を待つことで、ライブイベントと監視側に表示されるビデオとの間の時間がさらに増加する可能性があります。

この影響は、ネットワークがパケットを繰り返し損失する場合により顕著になります。少量の再送信では目に見える影響はほとんどありませんが、損失が続くと、プロトコルが欠落情報を回復しようとする間にデータが待機する可能性があります。ライブ監視アプリケーションでは、これが再生遅延、一時的な停止、または実際のイベントと表示ビデオとの間の乖離の拡大として現れることがあります。

TCP はまた、輻輳制御メカニズムを使用して、ネットワーク状態に応じて伝送動作を調整します。これにより、混雑したネットワーク上でトラフィックが共存しやすくなりますが、利用可能な帯域幅の変動は伝送遅延の変化につながる可能性があります。

したがって、監視アプリケーションでは、ネットワークパスが予測しにくく、可能な限り低いレイテンシを達成することよりも信頼性の高い配信が重要である場合に、TCP を検討できます。プロジェクトがパケット損失に対するより制御された応答と引き換えに、ある程度の追加遅延を許容できる場合に特に役立ちます。

UDP が有利な点

UDP（User Datagram Protocol）は異なる動作をします。コネクションレスであるため、永続的なトランスポートコネクションを最初に確立して維持することなく、データを宛先に直接送信できます。

UDP は、TCP のような確認応答、再送信、および順序付けの保証を提供しません。パケットが損失する可能性があり、パケットが異なる順序で到着する可能性もあります。これらの条件に対する必要な処理はすべて、通信プロセスまたはアプリケーションの他の場所で実行する必要があります。

コネクション管理と再送信のオーバーヘッドの多くを排除することにより、UDP は重要な利点、すなわち伝送遅延の低減を得ています。リアルタイムアプリケーションでは、欠落パケットの再送信を待つよりも、最新情報を迅速に受信する方が有用な場合があります。

実際のライブ監視では、これは個々のパケットが損失してもストリームが進み続けることができることを意味します。回復を待って後続の情報を遅延させる代わりに、システムは新しいビデオデータを受信し続けることができます。偶発的な損失が許容される場合、この動作はフィールドカメラとオペレーターの画面との間のより即時的な関係を維持するのに役立ちます。

この特性により、UDP は、リアルタイムオーディオおよびビデオ伝送、オンライン対話型サービス、および一部のパケット損失がより即時の配信と引き換えに許容されるライブ監視などのアプリケーションに適しています。

UDP はトランスポート層で TCP スタイルの輻輳制御を提供しません。ネットワークが輻輳すると、パケットは設定されたレートで送信され続ける可能性があり、これによりパケット損失が増加し、同じネットワークを共有する他のトラフィックにも影響を与える可能性があります。したがって、ネットワーク容量は UDP ベースの監視計画の重要な部分であり続けます。

UDP はネットワーク品質が悪い場合の解決策として解釈されるべきではありません。その低いオーバーヘッドは遅延の低減に役立ちますが、利用可能な帯域幅がカメラストリームに必要な量を一貫して下回る場合、パケット損失が顕著になる可能性があります。適切に設計された監視ネットワークは、予想されるカメラ台数と同時ビデオセッションに対して依然として十分な容量を必要とします。

信頼性、遅延、帯域幅の比較

監視ネットワークの要件を直接比較すると、TCP と UDP の実用的な違いがより明確になります。

これらの違いは、プロトコル選択をカメラ仕様のみに基づいて行うべきではない理由を説明しています。同じカメラでも、安定したローカルネットワーク、共有度の高いネットワーク、または予測しにくいリモート接続のいずれで伝送するかによって、パフォーマンスが異なる場合があります。

また、偶発的なネットワーク変動と継続的な帯域幅不足を区別することも重要です。TCP は個々の損失パケットを回復するかもしれませんが、再送信が繰り返されると遅延が増加する可能性があります。UDP は再送信待ちを回避できるかもしれませんが、継続的な輻輳はより多くのパケット破棄につながる可能性があります。どちらのアプローチも、適切なネットワークリソースを提供する必要性を排除するものではありません。

導入推奨：ネットワークが安定しており低遅延が優先される場合は UDP を使用し、ビデオがより不安定なインターネット接続を経由し、信頼性の高い配信がより重要になる場合は TCP を検討してください。

実際のプロジェクトのためのプロトコル選択

プロトコル選択は、すべてのカメラが TCP を使用しなければならない、またはすべてのライブストリームが UDP を使用しなければならないという固定ルールではなく、実際のネットワーク環境から始めるべきです。

ネットワーク状態が良好な適切に管理された監視 LAN では、UDP が効果的なオプションとなりえます。その低いプロトコルオーバーヘッドは、すべての損失パケットの再送信を待たずにリアルタイムビデオ配信をサポートします。これは、オペレーターがイベントを可能な限り少ない遅延で観察する必要がある場合に特に有用です。

ローカルネットワークは通常、管理者にスイッチ、帯域幅割り当て、接続デバイス数に対するより多くの制御を提供します。伝送経路が短く、ネットワーク状態が予測可能な場合、UDP パケット損失に関連するリスクは管理しやすくなります。

カメラがインターネット経由または一貫して安定していないネットワークパスを介してビデオを伝送する場合、状況は変化する可能性があります。パケット損失または一時的なネットワーク変動は UDP ストリームに影響を与える可能性があります。なぜなら、損失パケットはトランスポートプロトコルによって自動的に再送信されないからです。

リモート監視リンクも、他のアプリケーションが同じ帯域幅を競合するにつれて、日中に変化する可能性があります。低トラフィック時に正常に動作するストリームが、繁忙期には異なる動作を示すことがあります。これが、プロトコルを理想的な条件下での短いテスト後にのみ選択すべきではない理由です。

このような状況では、TCP をテストする価値があるかもしれません。その確認応答と再送信メカニズムは配信の信頼性を向上させることができますが、パケットを再送信する必要がある場合、結果として得られるビデオはより多くの遅延を経験する可能性があります。

したがって、信頼性はリアルタイムパフォーマンスと比較衡量されるべきです。完全で順序付けられた配信が主な要件である場合、TCP には明確な利点があります。低遅延がより重要であり、偶発的なパケット損失が許容される場合、UDP が通常より自然な選択です。

利用可能な帯域幅も考慮する必要があります。プロトコルの変更は、一貫して過負荷状態にあるネットワークを補償することはできません。カメラ台数、同時ストリーム数、および同じ接続を共有する他のトラフィックはすべて最終結果に影響します。

カメラの台数が増えるにつれて、計画者は個々のカメラが生成する帯域幅だけでなく、監視センターに到達する総トラフィックも考慮する必要があります。複数のオペレーターが同時にライブストリームを開くと、ネットワーク負荷がさらに増加する可能性があります。したがって、プロトコル選択は、システムの予想規模と一緒に評価されるべきであり、それとは別に評価されるべきではありません。

実用的な導入アプローチ

新しい監視ネットワークプロジェクトでは、プロトコルを決定する前に伝送経路を評価することが最も有用なアプローチです。

カメラが主に安定したローカルネットワーク内で通信するのか、それともビデオがリモートおよびインターネットベースのリンクを経由する必要があるのかを特定することから始めます。予測可能な帯域幅を持つローカルネットワークは、低遅延 UDP 伝送により適した条件を提供しますが、不安定な外部経路では TCP の信頼性により重点が置かれる場合があります。

次の考慮事項は、ビデオの運用目的です。ライブ監視は、オペレーターが今何が起こっているかを理解する必要があるため、タイムリーな画像配信により大きな価値を置きます。安定した配信を優先するアプリケーションは、欠落パケットの再送信と引き換えに追加の遅延を受け入れる場合があります。

ネットワークテストでは、リンクが理想的でなくなった場合に何が起こるかも調べる必要があります。カメラが正常に接続できるかどうかのみを確認するのではなく、プロジェクトチームは、帯域幅が混雑したとき、複数のストリームが開かれたとき、または一時的なパケット損失が発生したときに、ビデオが引き続き使用可能かどうかを観察する必要があります。

同じ条件下で TCP と UDP を比較すると、どちらのトレードオフがより許容できるかが明らかになります。TCP がより安定したストリームを維持するが顕著な遅延を導入する場合、プロジェクトは信頼性が即時応答よりも重要かどうかを決定する必要があります。UDP が低遅延で十分にスムーズなままである場合、ライブビューイングにより適している可能性があります。

現実的なトラフィック条件下で両方のオプションをテストすることは、カメラと監視プラットフォームが両方のプロトコルをサポートする場合に特に有用です。空のネットワークでうまく機能する構成は、ピークトラフィック時には異なる動作をする可能性があるため、プロトコル選択は実験室条件だけでなく、通常および高負荷の運用条件を反映する必要があります。

大規模な導入では、異なるタイプのリンクを個別に評価することも有益です。同じ施設内のカメラは、外部ネットワークを介して接続されたリモートサイトと同じプロトコル決定に従う必要は必ずしもありません。最終的なアーキテクチャは、すべてのカメラに単一の設定を適用するのではなく、実際の通信条件に基づくことができます。

最後に、トランスポートプロトコルは監視ネットワーク設計の一部として扱われるべきです。ネットワークの安定性、利用可能な帯域幅、および通信経路の品質は依然として基本的なものです。TCP と UDP はネットワーク問題に異なる対応をしますが、どちらのプロトコルも根本的な容量または接続性の問題を取り除くことはできません。

結論

TCP と UDP は、ネットワークビデオ監視において異なる優先順位に役立ちます。TCP は、確認応答および再送信メカニズムを備えたコネクション指向の信頼性が高く順序付けられた伝送を提供し、データ配信の信頼性がより重視される場合に適しています。ただし、その追加の制御メカニズムは、特にパケット損失が再送信を繰り返しトリガーする場合に、遅延を増加させる可能性があります。

UDP は、伝送オーバーヘッドを削減し、低遅延配信をサポートするよりシンプルなコネクションレスアプローチを使用し、これはリアルタイム監視にとって価値があります。妥協点は、パケット配信と順序が保証されないため、ネットワークの安定性と利用可能な帯域幅が特に重要になることです。

実際の監視プロジェクトでは、ネットワークが安定しておりリアルタイムパフォーマンスが主な関心事である場合、UDP が適切な選択となることがよくあります。ビデオがより不安定なインターネット接続を経由し、パケット配信がより重要になる場合、TCP を代替案としてテストできます。最終的な決定は、普遍的なプロトコル設定に依存するのではなく、実際のネットワーク状態、運用要件、カメラ規模、および実世界の伝送テストに基づくべきです。

FAQ

すべてのカメラが同じトランスポートプロトコルを使用する必要がありますか？

いいえ。カメラと監視プラットフォームが両方のオプションを提供している場合、ネットワーク条件に応じて異なる伝送経路を設定できます。ローカルカメラとリモート接続されたカメラは、必ずしも同じ伝送要件を持つわけではありません。

カメラが LAN 上では正常に動作するのに、リモート視聴時に不安定になるのはなぜですか？

ローカルネットワークは通常制御が容易ですが、リモート伝送は帯域幅の変動、輻輳、またはパケット損失が発生する複数のネットワークセグメントを経由する可能性があります。そのため、プロトコル設定は完全な伝送経路と一緒に評価される必要があります。

UDP から TCP への変更で、不安定なビデオの問題はすべて解決できますか？

いいえ。プロトコル選択はデータの伝送方法を変更しますが、追加のネットワーク容量を生み出したり、信頼性の低い接続を修復したりするものではありません。持続的な帯域幅不足、過負荷リンク、またはネットワーク障害は別途対処する必要があります。

大規模なカメラ導入の前にプロトコル選択をテストすべきですか？

はい。現実的なネットワーク負荷下で代表的なカメラをテストすることで、レイテンシ、パケット損失、または再送信が要求アプリケーションにより大きな影響を与えるかどうかを確認できます。これは、検証なしにすべてのサイトに単一のプロトコル設定を適用するよりも信頼性が高いです。

同じ監視プロジェクト内で TCP と UDP を異なる方法で使用できますか？

はい。機器とプラットフォームがプロトコル選択を許可している場合、ローカルとリモートの伝送経路を独立して評価できます。安定した内部ネットワークは低遅延伝送を優先するかもしれませんが、異なるネットワーク条件を持つ別のリンクでは、信頼性と遅延の間の異なるバランスが必要になる場合があります。