Support Center
TCP vs. UDP
목차
UDP는 GigE Vision 표준에서 선택된 프로토콜이며, 모든 GigE Vision 기반 이더넷 카메라에서 사용됩니다. UDP는 뛰어난 스트리밍 성능, 낮은 지연 시간, 멀티캐스트, 그리고 TCP보다 전반적으로 단순한 설계를 제공합니다. UDP는 데이터 전송을 시작하기 전에 송신 장치와 수신 장치 간의 핸드셰이크가 필요 없는 비연결형 프로토콜입니다. 또한 흐름 제어나 패킷 신뢰성이 내장되어 있지 않기 때문에 데이터 전송 방식이 보다 간단합니다. 반면 TCP는 클라이언트와 호스트 간 연결을 설정해야 하는 연결 지향형 프로토콜입니다. 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 표준은 장치 제어, 스트림, 검색, 기능 목록 메커니즘을 정의하여 이더넷 장치가 UDP를 사용해 통신할 수 있도록 합니다:
- GigE Vision Control Protocol (GVCP)은 GigE Vision 애플리케이션이 장치를 구성하고 제어를 설정하는 방법을 정의합니다.
- GigE Vision Stream Protocol (GVSP)은 선택적 패킷 재전송 기능을 포함하여 카메라에서 PC로 이미지를 전송하는 데 사용되는 다양한 데이터 유형과 전송 방법을 지정합니다.
- GigE Device Discovery 메커니즘은 네트워크에서 장치를 찾는 방법을 정의합니다.
- XML 파일에는 모든 카메라 기능을 정의하는 GenAPI 설명이 포함되어 있습니다. 이 설명은 GenICam 표준을 기반으로 합니다.
이에 비해 TCP는 카메라에 구현하기 더 복잡한 프로토콜이며, 패킷 재전송과 같은 필수 기능을 하드웨어 레벨에서 구현해야 하므로 카메라에 더 많은 하드웨어 리소스(더 큰 FPGA 공간, 더 많은 온보드 메모리)가 필요합니다. 궁극적으로 GigE Vision에서 UDP를 선택한 것은 카메라 제조업체가 이더넷 카메라를 개발할 때 더 큰 유연성을 제공했습니다.
UDP가 선택되었지만, 카메라 제조업체와 고객들은 데이터 전송 신뢰성을 완전히 무시할 수 없다는 점을 이해하고 있었습니다. GigE Vision 표준에는 TCP와 유사한 신뢰성 기능에 대한 섹션이 포함되어 있으며, 이러한 선택적 기능은 각 데이터 패킷의 헤더에 추가됩니다. GigE Vision 표준에는 시퀀스 정보를 포함한 GVSP 헤더가 있어 프레임의 패킷을 순서와 관계없이 전송하고, 전송 후 다시 정렬할 수 있습니다. 또한 GVSP 헤더는 패킷이 손실된 경우 패킷 재전송을 지원합니다.
10GigE 카메라에서 UDP의 과제
현재 GigE Vision의 UDP 구현은 1GigE 대역폭을 염두에 두고 사용되었습니다. 앞서 언급했듯이 UDP에 없는 신뢰성 기능은 애플리케이션 계층에서 GigE Vision 표준에 내장되어 있습니다. 즉, 사용되는 모든 신뢰성 기능은 호스트의 사용 가능한 CPU 리소스, 카메라 소프트웨어 및 필터 드라이버의 품질, 추가 기능을 처리하는 카메라 펌웨어의 견고성에 의해 제한됩니다. 예를 들어 많은 카메라 제조업체의 경우, GigE Vision의 패킷 재전송은 누락된 패킷을 모니터링하기 위해 호스트 PC에 필터 드라이버라는 전용 소프트웨어 드라이버가 필요합니다. PC가 누락된 패킷을 감지하면 카메라에 재전송 요청을 보냅니다. 그런 다음 카메라는 패킷을 구문 분석해야 하며, 이는 보통 카메라 펌웨어에서 수행됩니다. 이후 카메라 이미지 버퍼에서 해당 패킷을 가져옵니다. 카메라는 정상 전송을 일시 중지하고 요청된 패킷을 재전송해야 합니다. 프레임 전체에 여러 개의 누락된 패킷이 흩어져 있는 경우, 이는 PC와 카메라 모두에 부담을 줄 수 있습니다. 그러나 1 Gigabit 속도에서는 손실된 패킷을 모니터링하고 재전송하는 데 필요한 CPU 및 카메라 리소스가 충분히 확보됩니다.
호스트 PC가 순서가 맞지 않는 패킷과 손실된 패킷을 처리하는 예시입니다. UDP에는 내장된 신뢰성 기능이 없기 때문에, 카메라 제조업체가 제공하는 필터 드라이버가 데이터 전송을 모니터링합니다. 이 드라이버는 각 패킷의 GVSP 헤더를 읽습니다.
LUCID는 GigE Vision에서 UDP 데이터 전송을 최적화하기 위해 지속적으로 노력해 왔습니다. LUCID의 필터 드라이버는 사용자에게 제공되는 모든 선택적 신뢰성 기능과 함께 빠르고 낮은 지연 시간, 최적화된 CPU 성능을 제공합니다. 가장 효율적인 성능을 위해 LUCID 필터 드라이버(LUCIDLwf.sys)를 설치하면 DMA 패킷 전송을 통해 빠른 패킷 모니터링이 가능합니다. 예를 들어 Atlas10 10GigE 카메라 4대를 최대 대역폭으로 동시에 스트리밍할 경우 평균 CPU 리소스 사용률은 8%에 불과합니다.
LUCID의 UDP 필터 드라이버를 사용하면 최적화된 CPU 리소스로 여러 대의 10GigE Atlas10 카메라를 실행할 수 있습니다. PC 사양은 여기에서 확인하십시오.
그러나 일부 10GigE 애플리케이션, 특히 전체 프레임 전송을 위한 트리거링이 매우 중요한 애플리케이션에서는 GigE Vision UDP 기술이 한계에 도달할 수 있습니다. 10GigE에서 스트리밍되는 데이터가 크게 증가하면 신뢰성 문제가 발생할 수 있으며, 특히 호스트 PC 사양이 이상적이지 않은 멀티 카메라 10GigE 애플리케이션에서 더욱 그렇습니다(KB 문서 “여러 Atlas10 카메라 스트리밍을 위한 샘플 PC 구성” 참조). 카메라당 모니터링해야 하는 데이터가 10배 많아지면, 초기 문제로 인해 패킷 재전송이 발생한 후 호스트 PC와 카메라가 부담을 느끼기 시작할 수 있습니다. CPU가 데이터 스트림을 처리하느라 너무 바빠지면 패킷이 손실될 수 있습니다. 이는 손상되거나 부분적인 이미지로 이어집니다. 이미지 전송 대역폭이 증가할수록 더 많은 패킷이 손실될 가능성도 증가하며, CPU 사용률이 계속 증가하고 카메라에 패킷 재전송을 계속 요청하면서 악순환이 발생합니다. GigE Vision 표준은 UDP 위에 신뢰성 기능을 추가했지만, 현재 UDP와 패킷 재전송을 사용하는 방식은 CPU 리소스가 한계에 도달할 때 손상된 이미지가 연쇄적으로 발생하는 도미노 효과를 일으킬 수 있습니다.
UDP 전송 중 손상된 이미지의 예시입니다. 검은색 막대는 일반적으로 이미지 버퍼가 아직 사용되지 않은 스트림 시작 시점에 발생합니다(a). 패킷 손실이 발생한 움직이는 장면에서는 이미지 버퍼에 마지막으로 남아 있던 패킷으로 인해 이전 이미지가 표시됩니다(b).
TCP 신뢰성: 핸드셰이크에서 시작
UDP와 비교할 때 TCP에는 신뢰성 기능이 내장되어 있으며, 10GigE 카메라를 포함한 이더넷 카메라가 전체 프레임 전송을 보장할 수 있도록 합니다. 이것이 모든 프레임의 전송을 보장한다는 의미는 아니며, 하나의 프레임(이미지)을 구성하는 모든 패킷이 전송된다는 의미입니다. 즉, 애플리케이션은 손상되거나 부분적인 이미지(위 예시)를 만나지 않지만, 연결 또는 호스트 PC에 치명적인 문제가 있는 경우 프레임 손실은 여전히 발생할 수 있습니다.
전체 프레임 전송은 검사를 위해 카메라 트리거링이 필요한 애플리케이션에서 중요합니다. 이러한 상황에서는 손상된 이미지로 이어질 수 있는 패킷 손실이 발생하지 않는 것이 필수적이며, 이는 OCR 오독이나 낮은 객체 검출 성능과 같은 문제를 방지하는 데 중요합니다. UDP와 달리 TCP는 호스트 PC에 필터 드라이버를 설치할 필요가 없으며, 네트워크 인터페이스 카드(NIC)와 카메라의 FPGA를 사용해 하드웨어 레벨에서 패킷 재전송 및 추가 신뢰성 기능을 관리합니다. 신뢰성 높은 데이터 전송의 기반은 TCP의 3-way handshake에서 시작됩니다. 이 핸드셰이크는 TCP 소켓 연결을 생성하고, 시스템 리소스를 예약하며, 데이터 전송을 위한 TCP 윈도우 크기(버퍼)를 설정합니다. 시스템 리소스를 예약하기 때문에, 해당 리소스를 다른 작업에 사용하려면 먼저 연결을 종료해야 합니다.
UDP를 사용하는 GVSP에서는 프레임의 모든 데이터 패킷에 GVSP 헤더가 삽입되는 반면, TCP를 사용하는 GVSP에서는 프레임당 한 번만 GVSP 헤더가 삽입됩니다. 이를 통해 오버헤드가 줄어듭니다.
Atlas10 10GigE 카메라와의 TCP 핸드셰이크(SYN, SYN-ACK, ACK)는 TCP 소켓 연결을 설정하고, 시스템 리소스를 예약하며, 데이터 전송을 위한 TCP 윈도우 크기(버퍼)를 설정합니다.
카메라와 호스트 PC 간 TCP 연결이 설정되면, 애플리케이션은 더 안정적인 패킷 전송, 더 높은 프레임 속도, 지속적으로 낮은 CPU 사용률이라는 이점을 활용할 수 있습니다. 이 세 가지 장점은 다음 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를 보낼 수도 있습니다. 또한 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개를 보내 패킷 재전송을 시작합니다. 또한 “Retransmission Timer”가 만료될 때 ACK를 받지 못하면 카메라는 마지막 패킷을 자동으로 다시 전송합니다. 호스트는 TCP 윈도우에 있는 모든 데이터를 요청할 수 있습니다. 패킷 재전송이 TCP 하드웨어에서 관리되기 때문에 GigE Vision 패킷 재전송을 위한 대역폭 예약(DeviceLinkThroughputReserve)을 더 이상 설정할 필요가 없습니다. 이를 통해 약 10%의 대역폭(LUCID의 UDP 사용 시 기본 설정)이 확보되며, 카메라는 더 높은 프레임 속도*에 도달할 수 있습니다(*센서의 최대 프레임 속도에 따라 달라짐). 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 리소스를 확보하여 객체 검출이나 분류와 같은 다른 비전 작업에 집중할 수 있습니다.
위: Atlas10 카메라와 NIC는 16k 점보 프레임으로 설정되어 있지만, Linux의 Large Receive Offload 덕분에 NIC에서 30k(29928) 프레임으로 결합됩니다. 이를 통해 시스템이 처리해야 하는 패킷 세그먼트 수가 줄어듭니다. 패킷 병합은 TCP가 스트림 기반이기 때문에 TCP에서만 가능합니다.
위: Ubuntu 18.04에서 10GigE로 스트리밍하는 Atlas10 카메라 4대. LRO 없이 이미지 획득 중 CPU 사용률 약 2.2%.
위: Ubuntu 18.04에서 10GigE로 스트리밍하는 Atlas10 카메라 4대. LRO 활성화 상태에서 이미지 획득 중 CPU 사용률 약 1.9%.
위: Windows10에서 10GigE로 스트리밍하는 Atlas10 카메라 4대. RSC 없이 이미지 획득 중 CPU 사용률 약 13%.
위: Windows10에서 10GigE로 스트리밍하는 Atlas10 카메라 4대. 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로 변경하는 것은 간단합니다. 획득을 중지하고, 프로토콜을 변경한 다음 다시 시작하면 됩니다.
