비디오 스트림의 TCP 대 UDP

네트워크 프로그래밍 시험에서 방금 집으로 돌아 왔는데, 그들이 우리에게 묻는 질문 중 하나는 "비디오를 스트리밍하려면 TCP 또는 UDP를 사용 하시겠습니까? 저장된 비디오와 라이브 비디오 스트림 모두에 대해 설명하십시오"였습니다. . 이 질문에 대해 그들은 단순히 저장된 비디오를위한 TCP와 라이브 비디오를위한 UDP의 짧은 대답을 기대했지만, 집으로가는 길에 이것에 대해 생각했고, 라이브 비디오 스트리밍에 UDP를 사용하는 것이 반드시 더 낫습니까? 대역폭이 있고 축구 경기 나 콘서트를 스트리밍한다고하면 정말 UDP를 사용해야합니까?

이 콘서트 또는 TCP를 사용하는 모든 것을 스트리밍하는 동안 패킷이 손실되기 시작하고 (사용자와 발신자 사이의 일부 네트워크에서 잘못된 일이 발생했습니다) 1 분 동안 패킷을받지 못한다고 가정 해 보겠습니다. 비디오 스트림이 일시 중지되고 1 분이 지나면 패킷이 다시 통과하기 시작합니다 (IP가 새 경로를 찾았습니다). 그러면 TCP가 잃어버린 순간을 재전송하고 라이브 스트림을 계속 전송합니다. 가정하면 대역폭이 스트림의 비트 전송률보다 높고 핑이 너무 높지 않으므로 짧은 시간 내에 손실 된 1 분이 스트림의 버퍼 역할을합니다. , 패킷 손실이 다시 발생하면 알 수 없습니다.

예를 들어 화상 회의와 같이 항상 스트림의 끝에 있어야 하는 일부 기기를 생각할 수 있습니다 . 화상 채팅 중 지연이 끔찍하지만 축구 경기 나 콘서트 도중 스트림 뒤에서 1 분 뒤에있는 것이 중요합니까? 또한 모든 데이터를 얻을 수 있으며 오류없이 데이터가 들어올 때 나중에 볼 수 있도록 저장하는 것이 좋습니다.

그래서 이것은 저에게 제 질문을 던집니다. 라이브 스트리밍을 위해 TCP를 사용하는 것에 대해 모르는 단점이 있습니까? 아니면 대역폭이있는 경우 네트워크 (흐름 제어)에 "더 좋은"TCP를 사용해야합니까?

라이브 비디오에 TCP 사용의 단점 :

1. 일반적으로 라이브 비디오 스트리밍 어플라이언스는 TCP 스트리밍을 염두에두고 설계되지 않았습니다. TCP를 사용하는 경우 OS는 모든 클라이언트에 대해 승인되지 않은 세그먼트를 버퍼링해야합니다. 이는 특히 라이브 이벤트의 경우 바람직하지 않습니다. 아마도 이벤트의 특이점으로 인해 동시 클라이언트 목록이 길 것입니다. 미리 녹화 된 비디오 캐스트는 일반적으로 시청자가 자신의 재생 활동을 엇갈리게하기 때문에 이와 관련하여 그다지 문제가 없습니다. 따라서 TCP는 주문형 비디오를 재생하는 데 더 적합합니다.
2. IP 멀티 캐스트는 많은 청중을위한 비디오 대역폭 요구 사항을 크게 줄입니다. TCP는 IP 멀티 캐스트 사용을 방지하지만 UDP는 IP 멀티 캐스트에 적합합니다.
3. 라이브 비디오는 일반적으로 카메라에서 녹화 된 일정한 대역폭 스트림입니다. 미리 녹화 된 비디오 스트림은 디스크에서 나옵니다. TCP의 손실 백 오프 역학은 소스 스트림이 일정한 대역폭에있을 때 (라이브 이벤트에서 발생하는 것처럼) 라이브 비디오를 제공하기 어렵게 만듭니다. 카메라에서 디스크로 버퍼링하는 경우 예측할 수없는 네트워크 이벤트 및 가변 TCP 전송 / 백 오프 속도를위한 충분한 버퍼가 있는지 확인하십시오. UDP는 네트워크 전송 계층 드롭에 대해 신경 쓰지 않기 때문에 UDP를 사용하면이 애플리케이션에 대해 훨씬 더 많은 제어를 할 수 있습니다.

참고로 네트워크를 설명 할 때 "패키지"라는 단어를 사용하지 마십시오. 네트워크는 "패킷"을 보냅니다.

하지만 축구 경기 나 콘서트 중에 스트림이 1 분 뒤쳐진다면 무엇이 중요합니까?

일부 축구 팬에게는 상당히. 디지털 비디오 스트림에 인코딩 (또는 기타)으로 인해 몇 초만 지연되는 것도 월드컵 경기와 같은 주목할만한 이벤트 중에 사람들의 환호와 신음 소리를들을 수있을 때 매우 성 가실 수 있습니다. 당신이 그들을 일으킨 게임 움직임을보기 전에 옆집 (무정한 아날로그 프로그램을보고있는 사람).

스포츠에 관심이 많은 사람 (최소한 여기 독일에서는 디지털 TV를 구매하는 가장 큰 고객 그룹)에게 라이브 비디오 스트림에서 1 분 뒤처지는 것은 완전히 용납되지 않을 것이라고 생각합니다. d 이런 일이 발생하지 않는 경쟁자로 전환).

일반적으로 비디오 스트림은 다소 내결함성이 있습니다. 따라서 일부 패키지가 손실되는 경우 (예 : 과부하가 걸리는 일부 라우터로 인해) 콘텐츠를 계속 표시 할 수 있지만 품질이 저하됩니다.

라이브 스트림이 TCP / IP를 사용하는 경우, 것입니다 강제 하는 떨어 패키지를 기다려야 하기 전에 이 새로운 데이터를 처리 할 수있었습니다.

두 배로 나쁩니다.

• 이전 데이터는 재 전송 (즉, 이미 때문에 쓸모 표시 한 프레임 아마) 및
• 새로운 데이터까지 도착하지 수 후 이전 데이터는 다시 전송 된

목표가 가능한 한 최신 정보를 표시하는 것이라면 (그리고 라이브 스트림의 경우 프레임이 좀 더 나빠 보이더라도 일반적으로 최신 상태를 유지하려는 경우) TCP가 작동하지 않습니다.

녹화 된 스트림의 경우 상황은 약간 다릅니다. 아마도 훨씬 더 많은 버퍼링 (아마도 몇 분!)이 될 것이고 패키지 손실로 인해 일부 아티팩트가 발생하는 것보다 데이터를 재전송하는 것이 좋습니다. 이 경우 TCP는 좋은 일치입니다 (물론 UDP에서 구현할 수 있지만 TCP에는 라이브 스트림의 경우만큼 많은 단점이 없습니다).

UDP 전송에 적합한 사용 사례와 TCP 전송에 적합한 사용 사례가 있습니다.

사용 사례는 비디오의 인코딩 설정도 지정합니다. 축구 경기를 방송 할 때는 품질에 중점을두고 화상 회의의 경우 지연 시간에 중점을 둡니다.

멀티 캐스트를 사용하여 고객에게 비디오를 전달할 때 UDP가 사용됩니다.

멀티 캐스트에 대한 요구 사항은 방송 서버와 고객 간의 값 비싼 네트워킹 하드웨어입니다. 실제로 이는 회사가 네트워크 인프라를 소유하고있는 경우 라이브 비디오 스트리밍에 UDP 및 멀티 캐스트를 사용할 수 있음을 의미합니다. 그런 다음에도 서비스 품질이 구현되어 비디오 패킷을 표시하고 우선 순위를 지정하여 패킷 손실이 발생하지 않습니다.

멀티 캐스트는 네트워크 하드웨어가 고객에게 패킷 배포를 처리하므로 브로드 캐스트 소프트웨어를 단순화합니다. 고객은 멀티 캐스트 채널을 구독하고 네트워크는 패킷을 새 구독자에게 라우팅하도록 재구성됩니다. 기본적으로 모든 채널은 모든 고객이 사용할 수 있으며 최적으로 라우팅 될 수 있습니다.

이 워크 플로는 인증 프로세스에 어려움을줍니다. 네트워크 하드웨어는 가입 한 사용자를 다른 사용자와 구별하지 않습니다. 승인에 대한 해결책은 구독이 유효 할 때 비디오 콘텐츠를 암호화하고 플레이어 소프트웨어에서 암호 해독을 활성화하는 것입니다.

유니 캐스트 (TCP) 워크 플로를 통해 서버는 클라이언트의 자격 증명을 확인하고 유효한 구독 만 허용 할 수 있습니다. 특정 수의 동시 연결 만 허용합니다.

멀티 캐스트는 인터넷을 통해 활성화되지 않습니다.

인터넷을 통해 비디오를 전송하려면 TCP를 사용해야합니다. UDP가 사용되면 개발자는 패킷 재전송을 다시 구현하게됩니다. Bittorrent p2p 라이브 프로토콜.

"TCP를 사용하는 경우 OS는 모든 클라이언트에 대해 승인되지 않은 세그먼트를 버퍼링해야합니다. 이는 특히 라이브 이벤트의 경우 바람직하지 않습니다."

이 버퍼는 어떤 형태로 존재해야합니다. 플레이어 측의 지터 버퍼도 마찬가지입니다. 이를 "소켓 버퍼"라고하며 서버 소프트웨어는이 버퍼가 가득 차면이를 알 수 있으며 라이브 스트림에 적합한 비디오 프레임을 버릴 수 있습니다. 서버 소프트웨어는 적절한 프레임 삭제 로직을 구현할 수 있으므로 유니 캐스트 / TCP 방식을 사용하는 것이 좋습니다. UDP 케이스에서 무작위로 누락 된 패킷은 나쁜 사용자 경험을 생성합니다. 이 비디오처럼 : http://tinypic.com/r/2qn89xz/9

"IP 멀티 캐스트는 많은 청중의 비디오 대역폭 요구 사항을 크게 줄여줍니다."

이것은 사설 네트워크에 해당되며, 멀티 캐스트는 인터넷을 통해 활성화되지 않습니다.

"TCP가 너무 많은 패킷을 잃으면 연결이 끊어집니다. 따라서 UDP는 네트워크 전송 계층 삭제를 고려하지 않기 때문에 UDP는이 응용 프로그램에 대해 훨씬 더 많은 제어를 제공합니다."

UDP는 또한 전체 프레임 또는 프레임 그룹을 삭제하는 데 신경 쓰지 않으므로 사용자 경험을 더 이상 제어 할 수 없습니다.

"보통 비디오 스트림은 내결함성이 있습니다."

인코딩 된 비디오는 내결함성 이 없습니다 . 신뢰할 수없는 전송을 통해 전송되면 순방향 오류 수정이 비디오 컨테이너에 추가됩니다. 좋은 예는 여러 오디오, 비디오, EPG 등의 스트림을 전달하는 위성 비디오 방송에 사용되는 MPEG-TS 컨테이너입니다. 이는 위성 링크가 이중 통신이 아니므로 수신기가 손실 된 패킷의 재전송을 요청할 수 없기 때문에 필요합니다.

이중 통신을 사용할 수있는 경우 패킷 손실이있는 클라이언트에만 데이터를 재전송 한 다음 모든 클라이언트에 전송되는 스트림에 순방향 오류 수정의 오버 헤드를 포함하는 것이 좋습니다.

어쨌든 손실 된 패킷은 허용되지 않습니다. 손실 된 프레임은 대역폭이 방해되는 예외적 인 경우에 괜찮습니다.

누락 된 패킷의 결과는 다음과 같은 아티팩트입니다.

일부 디코더는 중요한 위치에서 패킷이 누락 된 스트림에서 중단 될 수 있습니다.

새로운 p2p 라이브 프로토콜 인 Bittorent Live 를 살펴 보시기 바랍니다 .

스트리밍의 경우 UDP를 사용하는 것이 좋습니다. 먼저 서버의 부하를 낮추기 때문입니다. 그러나 대부분 멀티 캐스트로 패킷을 보낼 수 있기 때문에 연결된 각 클라이언트에 보내는 것보다 간단합니다.

때에 따라 다르지. 스트리밍하는 콘텐츠가 얼마나 중요합니까? 중요한 경우 TCP를 사용하십시오. 이로 인해 대역폭, 비디오 품질 (대기 시간을 처리하기 위해 더 낮은 품질을 사용해야 할 수 있음) 및 대기 시간에 문제가 발생할 수 있습니다. 그러나 거기에 도달하기 위해 콘텐츠가 필요한 경우 사용하십시오.

그렇지 않으면 스트림이 중요하지 않고 UDP가 오버 헤드가 적은 경향이 있기 때문에 UDP가 선호됩니다.

인터넷에서 라이브 이벤트를 제공하는 데있어 가장 큰 문제 중 하나는 '확장'이며 TCP는 제대로 확장되지 않습니다. 예를 들어 주문형 영화 재생과 달리 라이브 축구 경기를 전송하는 경우 시청하는 사람의 수는 쉽게 1000 배 더 늘어날 수 있습니다. TCP를 사용하는 이러한 시나리오에서 CDN (콘텐츠 전송 네트워크)에 대한 사형 선고가 있습니다.

TCP가 제대로 확장되지 않는 몇 가지 주요 이유가 있습니다.

1. TCP의 가장 큰 장단점 중 하나는 발신자와 수신자간에 달성 할 수있는 처리량의 가변성입니다. 인터넷을 통해 비디오를 스트리밍 할 때 비디오 패킷은 인터넷을 통해 여러 라우터를 통과해야하며 각 라우터는 서로 다른 속도 연결로 연결됩니다. TCP 알고리즘은 TCP 창을 작게 설정 한 다음 패킷 손실이 감지 될 때까지 증가하고 패킷 손실은 정체의 신호로 간주되며 TCP는 정체를 피하기 위해 창 크기를 대폭 줄여 응답합니다. 따라서 효과적인 처리량을 즉시 줄입니다. 이제 클라이언트에 6-7 개의 라우터 홉을 사용하여 TCP를 전송하는 네트워크를 상상해보십시오 (매우 일반적인 시나리오). 중간 라우터가 패킷을 잃으면 해당 링크의 TCP가 전송 속도를 줄입니다. 사실 라우터 간의 트래픽 흐름은 모래 시계 모양을 따릅니다. 항상 중간 라우터 중 하나 사이에서 위아래로 공을칩니다. 최선형 UDP에 비해 효과적인 처리량을 훨씬 낮게 렌더링합니다.

2. 이미 알고 계시 겠지만 TCP는 승인 기반 프로토콜입니다. 예를 들어 발신자가 50ms 떨어져 있다고 가정 해 보겠습니다 (예 : 지연 시간 btw 2 포인트). 이는 패킷이 수신자에게 전송되고 수신자가 승인을 전송하는 데 걸리는 시간이 100ms임을 의미합니다. 따라서 UDP 기반 전송에 비해 가능한 최대 처리량은 이미 절반으로 떨어졌습니다.

3. TCP는 멀티 캐스팅 또는 새로운 멀티 캐스팅 AMT 표준을 지원하지 않습니다. 즉, 많은 클라이언트가 동일한 콘텐츠를 시청할 때 CDN이 패킷을 복제하여 네트워크 트래픽을 줄일 기회가 없습니다. 그 자체로 CDN (예 : Akamai 또는 Level3)이 라이브 스트림을 위해 TCP를 사용하지 않는 충분한 이유입니다.

TCP UDP 토론을 읽는 동안 논리적 결함을 발견했습니다. 1 분 버퍼로 변환되는 1 분 지연을 유발하는 TCP 패킷 손실은 동일한 손실을 경험하는 동안 UDP가 1 분을 삭제하는 것과 관련이 없습니다. 보다 공정한 비교는 다음과 같습니다.

TCP에서 패킷 손실이 발생합니다. TCP가 수학적으로 완벽한 패킷을 스트리밍하기 위해 패킷을 재전송하는 동안 비디오가 중지됩니다. 비디오는 1 분 동안 지연되고 누락 된 패킷이 목적지에 도달 한 후 중단 된 지점에서 선택됩니다. 우리는 모두 기다리지 만 우리는 단일 픽셀을 놓치지 않을 것임을 압니다.

UDP에서 패킷 손실이 발생합니다. 비디오 스트리밍 중 잠시 동안 화면 모서리가 약간 흐릿 해집니다. 아무도 알아 차리지 못하고 쇼는 잃어버린 패킷을 찾지 않고 계속됩니다.

스트리밍되는 모든 것이 UDP에서 가장 많은 이점을 얻습니다. 패킷 손실로 인해 TCP에 1 분 지연이 발생해도 UDP에 1 분 지연이 발생하지 않습니다. 대부분의 시스템이 다중 해상도 스트림을 사용하여 패킷이 부족할 때 상황을 막는다는 점을 고려하면 UDP를 사용하는 것이 훨씬 더 합리적입니다.

스트리밍시 UDP FTW.

대역폭이 비트 전송률보다 훨씬 높으면 유니 캐스트 라이브 비디오 스트리밍에 TCP를 권장합니다.

사례 1 : 연속 패킷이 몇 초 동안 손실됩니다. => 실시간 비디오는 전송 계층 (TCP 또는 UDP)이 무엇이든 클라이언트 측에서 중지됩니다. 네트워크가 복구 될 때 :-TCP를 사용하는 경우 클라이언트 비디오 플레이어는 첫 번째 패킷 손실 (시간 이동)시 스트림을 다시 시작하거나 모든 늦은 패킷을 삭제하고 시간 이동없이 비디오 스트림을 다시 시작할 수 있습니다. -UDP를 사용하는 경우 클라이언트 측에서 선택의 여지가 없으며 타임 시프트없이 라이브로 비디오를 다시 시작합니다. => TCP 같거나 더 좋습니다.

사례 2 : 일부 패킷은 네트워크에서 무작위로 손실되는 경우가 많습니다. -TCP를 사용하는 경우 이러한 패킷은 즉시 재전송되며 올바른 지터 버퍼를 사용하여 비디오 스트림 품질 / 대기 시간에 영향을 미치지 않습니다. -UDP를 사용하면 화질이 나빠집니다. => 훨씬 나은 TCP

비디오 스트리밍 대역폭은 시스템의 제약 일 가능성이 높습니다. 멀티 캐스트를 사용하면 사용되는 업스트림 대역폭의 양을 크게 줄일 수 있습니다. UDP를 사용하면 연결된 모든 터미널에 패킷을 쉽게 멀티 캐스트 할 수 있습니다. 신뢰할 수있는 멀티 캐스트 프로토콜을 사용할 수도 있습니다. 하나는 PGM (Pragmatic General Multicast)이라고합니다. 저는 그것에 대해 전혀 알지 못하며 널리 사용되지 않는 것 같습니다.

다른 모든 이유 외에도 UDP는 멀티 캐스트를 사용할 수 있습니다. 동일한 데이터를 전송하는 1000 명의 TCP 사용자를 지원하면 대역폭이 낭비됩니다. 그러나 TCP를 사용하는 또 다른 중요한 이유가 있습니다.

TCP는 방화벽과 NAT를 훨씬 더 쉽게 통과 할 수 있습니다. NAT 및 운영자에 따라 UDP 홀 펀칭 문제로 인해 UDP 스트림을 수신하지 못할 수도 있습니다.

모든 'UDP 사용'답변은 개방형 네트워크를 가정하고 '가능한 한 많이 채우는'접근 방식입니다. 사라지는 종류 인 구식 폐쇄 정원 전용 오디오 / 비디오 네트워크에 적합합니다.

실제 세계에서는 전송이 방화벽을 통과하고 (멀티 캐스트 및 때때로 udp가 삭제됨) 네트워크가 더 중요한 다른 앱 ($$$)과 공유되므로 창 크기 조정으로 남용자를 처벌 하고 싶습니다 .

이것은 시간 문제 라기보다 내용의 문제입니다. TCP 프로토콜을 사용하려면 배달되지 않은 패킷을 확인, 확인 및 재전송해야합니다. UDP는이 요구 사항을 사용하지 않습니다. 따라서 비디오와 같이 UDP를 사용하여 수백만 개의 패킷이 포함 된 파일을 보낸 경우 일부 패킷이 배달시 누락되면 누락 될 가능성이 높습니다.