TCP vs. UDP
目次
UDPはGigE Vision規格で採用されているプロトコルであり、すべてのGigE VisionベースのEthernetカメラで使用されています。UDPは優れたストリーミング性能、低レイテンシ、マルチキャストに対応し、TCPよりも全体的にシンプルな設計です。UDPはコネクションレス型のプロトコルであり、データ伝送を開始する前に送信側と受信側のデバイス間でハンドシェイクを行う必要がありません。フロー制御やパケット信頼性が組み込まれていないため、データ送信に対してより「介入の少ない」アプローチを提供します。一方、TCPはコネクション型のプロトコルであり、クライアントとホスト間の接続を確立する必要があります。また、フロー制御、パケット再送信、パケット結合などの信頼性機能も組み込まれています。一般的に、UDPはTCPにある追加機能を省き、速度とシンプルさを重視して設計されているのに対し、TCPは伝送の信頼性をより重視しています。
TCPとUDPの概要
| TCP | UDP | |
|---|---|---|
| Connection Design | Connection-oriented | Connectionless |
| Connection Handshake | Yes (SYN, SYN-ACK, ACK) | None. PC sends discovery packets to cameras on same subnet |
| Guaranteed Frame delivery | Yes | No |
| Transmission Method | Stream-oriented | Datagram |
| Data Retransmission | Yes (hardware layer) | Optional (requires filter driver) |
| Flow Control | Yes (hardware layer) | Optional - Inter-packet delay |
| Jumbo Frames | Yes | Yes |
| Receive Side Coalescing / Large Packet Coalescing | Yes | No |
| Multi-cast | No | Yes |
GigE Vision規格でUDPを使用する理由
GigE Visionが制定された2006年当時、カメラメーカーはUDPを選択しました。その理由は、効率的なストリーミング性能だけでなく、シンプルであることにもあります。UDPは規格へ迅速に実装でき、不足している信頼性機能はUDPの上に追加することができました。これらの機能はアプリケーションレベルで動作します（ソフトウェアで実行され、ホストPCのCPUリソースとカメラのファームウェアを使用します）。また、これらの信頼性機能はカメラメーカーにとって任意であるため、メーカーがそれらの機能を省略する場合は、さらにシンプルな実装が可能になります。GigE Vision規格では、デバイス制御、ストリーム、検出、機能リストのメカニズムを定義することで、EthernetデバイスがUDPを使用して通信できるようにしています：
- GigE Vision Control Protocol（GVCP）は、GigE Visionアプリケーションがデバイスを設定し、制御を確立する方法を定義します。
- GigE Vision Stream Protocol（GVSP）は、カメラからPCへ画像を転送するために使用される各種データタイプと伝送方法を規定し、任意のパケット再送信機能も含みます。
- GigEのデバイス検出メカニズムは、ネットワーク上でデバイスを検出する方法を定義します。
- XMLファイルには、すべてのカメラ機能を定義するGenAPIの記述が含まれています。この記述はGenICam規格に基づいています。
これに対してTCPは、カメラ上で実装するにはより複雑なプロトコルです。パケット再送信などの必須機能をハードウェアレベルで実装する必要があるため、カメラ側により多くのハードウェアリソース（より大きなFPGA領域、より多くのオンボードメモリ）が求められます。GigE VisionでUDPを選択したことにより、カメラメーカーはEthernetカメラの開発において柔軟性を得ることができました。
UDPが採用されたとはいえ、カメラメーカーとユーザーは、データ転送の信頼性を完全に無視することはできないと理解していました。GigE Vision規格には、TCPに類似した信頼性機能に関する項目が含まれており、これらの任意機能は各データパケットのヘッダーに追加されます。GigE Vision規格には、シーケンス情報を含むGVSPヘッダーがあり、1つのフレームのパケットを順不同で送信し、受信後に再整列できるようになっています。また、パケットがドロップした場合、GVSPヘッダーによってパケット再送信も可能になります。
10GigEカメラにおけるUDPの課題
GigE Visionにおける現在のUDP実装は、1GigE帯域幅を前提として使用されてきました。前述のとおり、UDPに不足している信頼性機能はGigE Vision規格のアプリケーション層に組み込まれています。つまり、使用される信頼性機能は、ホスト側で利用可能なCPUリソース、カメラのソフトウェアとフィルタードライバーの品質、追加機能を処理するカメラファームウェアの堅牢性に制限されます。例えば、多くのカメラメーカーでは、GigE Visionのパケット再送信には、ホストPC上で欠落パケットを監視するためのフィルタードライバーと呼ばれる専用ソフトウェアドライバーが必要です。PCが欠落パケットを検出すると、カメラに再送信要求を送信します。その後、カメラはそのパケットを解析する必要があります。通常これはカメラのファームウェアで行われ、続いてカメラの画像バッファからそのパケットを取得します。カメラは通常の伝送を一時停止し、要求されたパケットを再送信する必要があります。フレーム全体に複数の欠落パケットが散在している場合、PCとカメラの両方に負荷がかかります。ただし、1Gigabitの速度では、ドロップしたパケットを監視して再送信するために必要なCPUおよびカメラリソースは十分に利用できます。
ホストPCが順不同パケットやドロップしたパケットを処理する例です。UDPには信頼性機能が組み込まれていないため、データ配送はカメラメーカーが提供するフィルタードライバーによって監視されます。このドライバーは各パケットのGVSPヘッダーを読み取ります。
LUCIDは、GigE VisionにおけるUDPデータ転送の最適化に継続的に取り組んできました。当社のフィルタードライバーは、高速かつ低レイテンシで、CPU性能を最適化するとともに、ユーザーが利用できるすべての任意の信頼性機能を提供します。最も効率的な性能を得るには、LUCIDのフィルタードライバー（LUCIDLwf.sys）をインストールすることで、DMAパケット転送による高速なパケット監視が可能になります。例えば、4台のAtlas10 10GigEカメラをフル帯域幅で同時にストリーミングしても、CPUリソースの平均使用率はわずか8%です。
LUCIDのUDPフィルタードライバーにより、CPUリソースを最適化しながら複数台の10GigE Atlas10カメラを運用できます。PC仕様はこちらをご覧ください。
しかし、一部の10GigEアプリケーション、特にフルフレーム配送のためのトリガーが非常に重要なアプリケーションでは、GigE VisionのUDP技術が限界に達する場合があります。10GigEでストリーミングされるデータ量の大幅な増加は、信頼性の問題を引き起こす可能性があります。特に、ホストPCの仕様が十分でない複数台10GigEカメラのアプリケーションではその傾向が強くなります（当社KB記事「複数台のAtlas10カメラをストリーミングするためのサンプルPC構成」をご覧ください）。カメラ1台あたり監視すべきデータ量が10倍になるため、最初の問題によってパケット再送信が発生すると、ホストPCとカメラの処理が追いつかなくなる可能性があります。その結果、CPUがデータストリームの処理で過負荷となり、パケットがドロップします。これにより、破損した画像や不完全な画像が発生します。画像伝送の帯域幅が増えるにつれて、さらに多くのパケットがドロップする可能性が高まり、CPU使用率が上昇し続け、カメラへのパケット再送信要求が増え続けるという悪循環が生まれます。GigE Vision規格はUDPの上に信頼性機能を追加していますが、現在のUDPとパケット再送信の使用方法では、CPUリソースが限界に達することで、破損画像が連鎖的に発生する可能性があります。
UDP伝送中に発生した破損画像の例です。黒いバーは通常、ストリーム開始時に画像バッファがまだ使用されていないために発生します（a）。動きのあるシーンでパケットがドロップすると、画像バッファに最後に保持されていたパケットにより、前の画像が表示されます（b）。
TCPの信頼性：ハンドシェイクから開始
UDPと比較して、TCPには信頼性機能が組み込まれており、10GigEカメラを含むEthernetカメラでフルフレーム配送を保証できます。ただし、これはすべてのフレームが配送されることを保証するものではなく、1つのフレーム（画像）を構成するすべてのパケットが配送されることを意味します。言い換えれば、アプリケーションで破損画像や不完全な画像（上記の例）が発生することはありませんが、接続やホストPCで重大な障害が発生した場合には、フレームドロップが発生する可能性があります。
検査のためにカメラトリガーを必要とするアプリケーションでは、フルフレーム配送が重要です。このような状況では、パケットがドロップして破損画像が発生し、OCRの誤読や物体検出の精度低下などの問題につながらないようにすることが不可欠です。UDPとは異なり、TCPではホストPCにフィルタードライバーをインストールする必要がなく、ネットワークインターフェースカード（NIC）とカメラのFPGAを利用して、パケット再送信と追加の信頼性機能をハードウェアレベルで管理します。信頼性の高いデータ伝送の基盤は、TCPの3ウェイハンドシェイクから始まります。このハンドシェイクによりTCPソケット接続が作成され、システムリソースが予約され、データ伝送用のTCPウィンドウサイズ（バッファ）が設定されます。システムリソースを予約するため、それらのリソースを他のタスクで使用する前に接続を終了する必要があります。
UDPを使用するGVSPでは、1フレーム内のすべてのデータパケットにGVSPヘッダーが挿入されます。一方、TCPを使用するGVSPでは、GVSPヘッダーは1フレームにつき1回だけ挿入されます。これによりオーバーヘッドが削減されます。
Atlas10 10GigEカメラとのTCPハンドシェイク（SYN、SYN-ACK、ACK）により、TCPソケット接続が確立され、システムリソースが予約され、データ伝送用のTCPウィンドウサイズ（バッファ）が設定されます。
カメラとホストPC間でTCP接続が確立されると、アプリケーションは、より信頼性の高いパケット配送、より高いフレームレート、一貫して低いCPU使用率というメリットを活用できます。これら3つの利点は、以下のTCP機能によって実現されます：
- TCPフロー制御とウィンドウ制御（ハードウェアレベル）
- パケット再送信（ハードウェアレベル）
- Large Receive Offload（Linux）およびReceive Side Coalescing（Windows）（いずれもハードウェアレベル）
TCPフロー制御とウィンドウ制御
TCPフロー制御
TCPを使用する場合、NICは特定量のデータ（バイト単位）を正常に受信したことを確認するため、確認応答パケット（ACK）をカメラに返送する必要があります。ACKパケットは、受信済みのデータ量、回線上にあるデータ量（転送中）、および「スライディングウィンドウ」に残っている空き容量をカメラに通知します。ACKは、正しいACKが受信されるまでカメラを一時停止させ、フレームレートを低下させることで、カメラのフレームレート設定に役立ちます。これをフロー制御と呼び、NICの準備が整うまで、蓄積されるパケットをTCPスライディングウィンドウとカメラの画像バッファに保存することで、パケット配送の信頼性を高めます。これにより、カメラとホストPCはハードウェアレベルで接続品質を継続的に監視できます。NICは受信した各パケットに対して可能な限りACKを送信するよう設定されていますが、ホストPCの負荷状況によっては、ACK送信を遅延させ、複数のパケットに対して1つのACKを送信する場合があります。また、10GigEは全二重であるため、ACKの送信によってカメラ側のオーバーヘッドが増えたり、帯域幅を消費したりすることはありません。
カメラのフロー制御
カメラ側では、各フレーム（画像）がTCPスライディングウィンドウへの次フレームのオフロードを開始する前に、ホストPCからのACKを要求します。ホストPCが長時間ビジー状態になると、Atlas10の880MBオンカメラフレームバッファがフレームでいっぱいになり、最終的にカメラはフレームをドロップします。その結果、PCの準備が整うまでフレームレートが低下し、データフローが抑えられます。ただし、データが欠落した不完全な画像がホストPCに送信されることはありません。これは、カメラのフレームバッファ内の最後のフレームが、カメラがそのフレームのすべてのパケットを送信し、ホストPCが適切な数のACKをカメラに返送するまで保持されるためです。TCP ACKはカメラのFPGAとホストPCのNICで処理されるため、カメラのファームウェアからは認識されません。なお、LUCIDではTCP ACK頻度を1に設定しています。これにより最も低いレイテンシが得られます（この設定はWindowsのみで利用可能です）。
TCPパケット再送信
TCPパケット再送信は、ACKを利用してパケットが受信されていることを確認するため、TCPフロー制御と連携して動作します。ホストPC側でパケットが欠落した場合、ホストは同じ確認応答番号を持つACKを3回送信し、パケット再送信を開始します。また、「再送信タイマー」が満了した時点でACKを受信していない場合、カメラは最後のパケットを自動的に再送信します。ホストはTCPウィンドウ内にある任意のデータを要求できます。パケット再送信はTCPハードウェアによって管理されるため、GigE Visionのパケット再送信用に帯域幅予約（DeviceLinkThroughputReserve）を設定する必要がなくなります。これにより、約10%の帯域幅（UDP使用時のLUCIDデフォルト設定）が解放され、カメラはより高いフレームレート*に到達できます（*センサーの最大フレームレートに依存します）。TCPでもパケット再送信には帯域幅を使用する必要がありますが、その帯域幅はTCPハードウェアによって動的に調整されるため、ユーザーが固定値を設定する必要はありません。
Large Receive Offload（LRO）／Receive Side Coalescing（RSC）
Large Receive Offload（LRO、Linux）およびReceive Side Coalescing（RSC、Windows）により、NICは小さなパケットをより大きなセグメントに結合でき、CPUが処理する必要のある小さなパケット数を削減できます。NICがパケットを受信すると、まず結合可能かどうかが確認されます（正しいシーケンス、有効なCRC、適切なTCPフラグ）。結合可能な場合、最初のパケットのヘッダーは保持されますが、後続パケットのヘッダーは削除されます。これは、割り込み（割り込み調整）までのすべての受信パケットに対して継続されます。パケット結合は、NICが割り込み調整時間内にパケットを結合するため、追加のレイテンシを発生させません。より少数で大きなセグメントにより、より効率的なストリームが生成されます。この概念は、ジャンボフレームと割り込み調整を有効にすることに似ており、いずれもCPU使用率の低減に役立ちます（最大フレームレートに到達するためのヒントをご覧ください）。UDPでは各パケットの開始と終了が定義されているため、パケット結合はできません。一方、TCPはストリームベースであるため、データに明確な境界がありません。
LROとRSCにより、特に10GigE複数台カメラのアプリケーションでCPU使用率を低減できます。これによりCPUリソースが解放され、物体検出や分類など、他のビジョンタスクにCPUを集中させることができます。
上図：Atlas10カメラとNICは16kジャンボフレームに設定されていますが、LinuxのLarge Receive Offloadにより、NICで30k（29928）フレームに結合されています。これにより、システムが処理する必要のあるパケットセグメント数が削減されます。パケット結合は、TCPがストリームベースであるためTCPでのみ可能です。
上図：Ubuntu 18.04で4台のAtlas10カメラが10GigEでストリーミング。LROなしで画像取得中のCPU使用率は約2.2%。
上図：Ubuntu 18.04で4台のAtlas10カメラが10GigEでストリーミング。LRO有効時の画像取得中のCPU使用率は約1.9%。
上図：Windows 10で4台のAtlas10カメラが10GigEでストリーミング。RSCなしで画像取得中のCPU使用率は約13%。
上図：Windows 10で4台のAtlas10カメラが10GigEでストリーミング。RSC有効時の画像取得中のCPU使用率は約11%。（PC仕様はこちらをご覧ください。）
まとめ
LUCIDは現在、Atlas10 10GigEカメラ向けにUDP（GigE Vision）とTCPの両方のプロトコルをサポートしています。ユーザーは当社のArena Software Development Kitを使用して、プロトコルを簡単に切り替えることができます。LUCIDのフィルタードライバーはUDPを大幅に最適化し、高速で低レイテンシなデータ伝送を実現しますが、ユーザーによっては、何よりもフルフレーム配送の保証を優先し、TCPを選択する場合があります。UDP接続でアプリケーションがパケットドロップや高いCPU使用率に悩まされている場合、TCPは10GigEカメラとホストPC間でより信頼性の高いデータ伝送を提供できます。TCPのフロー制御、パケット再送信、LRO/RSC技術により、ハードウェアレベルで動作しながら、フルフレーム配送を保証する高帯域幅の画像転送を実現します。Atlas10カメラに搭載されたLUCID独自の10GigE IPコアにより、LUCIDは従来のUDPに加えてTCP接続もサポートし、ユーザーが信頼性の高い10GigEビジョンアプリケーションを構築する際の選択肢を広げます。
ArenaViewでは、UDPからTCPへの切り替えは簡単です。画像取得を停止し、プロトコルを変更して、再度開始するだけです。
