비디오 스트림의 TCP 대 UDP

비디오 스트림의 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는 모든 클라이언트에 대해 승인되지 않은 세그먼트를 버퍼링해야합니다. 이는 특히 라이브 이벤트의 경우 바람직하지 않습니다."

This buffer must exist in some form. Same is true for jitter buffer on player side. It is called "socket buffer" and server software can know when this buffer is full and discard proper video frames for live streams. It is better to use unicast/TCP method because server software can implement proper frame dropping logic. Random missing packets in UDP case will just create bad user experience. like in this video: http://tinypic.com/r/2qn89xz/9

"IP multicast significantly reduces video bandwidth requirements for large audiences"

This is true for private networks, Multicast is not enabled over internet.

"Note that if TCP loses too many packets, the connection dies; thus, UDP gives you much more control for this application since UDP doesn't care about network transport layer drops."

UDP also doesn't care about dropping entire frames or group-of-frames so it does not give any more control over user experience.

"Usually a video stream is somewhat fault tolerant"

Encoded video is not fault tolerant. When transmitted over unreliable transport then forward error correction is added to video container. Good example is MPEG-TS container used in satellite video broadcast that carry several audio, video, EPG, etc. streams. This is necessary as satellite link is not duplex communication, meaning receiver can't request re-transmission of lost packets.

When you have duplex communication available it is always better to re-transmit data only to clients having packet loss then to include overhead of forward-error-correction in stream sent to all clients.

In any case lost packets are unacceptable. Dropped frames are ok in exceptional cases when bandwidth is hindered.

The result of missing packets are artifacts like this one:

Some decoders can break on streams missing packets in critical places.

---

I recommend you to look at new p2p live protocol Bittorent Live.

As for streaming it's better to use UDP, first because it lowers the load on servers, but mostly because you can send packets with multicast, it's simpler than sending it to each connected client.

---

It depends. How critical is the content you are streaming? If critical use TCP. This may cause issues in bandwidth, video quality (you might have to use a lower quality to deal with latency), and latency. But if you need the content to guaranteed get there, use it.

Otherwise UDP should be fine if the stream is not critical and would be preferred because UDP tends to have less overhead.

---

One of the biggest problems with delivering live events on Internet is 'scale', and TCP doesn’t scale well. For example when you are beaming a live football match -as opposed to an on demand movie playback- the number of people watching can easily be 1000 times more. In such a scenario using TCP is a death sentence for the CDNs (content delivery networks).

There are a couple of main reasons why TCP doesn't scale well:

1. One of the largest tradeoffs of TCP is the variability of throughput achievable between the sender and the receiver. When streaming video over the Internet the video packets must traverse multiple routers over the Internet, each of these routers is connected with different speed connections. The TCP algorithm starts with TCP window off small, then grows until packet loss is detected, the packet loss is considered a sign of congestion and TCP responds to it by drastically reducing the window size to avoid congestion. Thus in turn reducing the effective throughput immediately. Now imagine a network with TCP transmission using 6-7 router hops to the client (a very normal scenario), if any of the intermediate router looses any packet, the TCP for that link will reduce the transmission rate. In-fact The traffic flow between routers follow an hourglass kind of a shape; always gong up and down in-between one of the intermediate routers. Rendering the effective through put much lower compared to best-effort UDP.

2. As you may already know TCP is an acknowledgement-based protocol. Lets for example say a sender is 50ms away (i.e. latency btw two points). This would mean time it takes for a packet to be sent to a receiver and receiver to send an acknowledgement would be 100ms; thus maximum throughput possible as compared to UDP based transmission is already halved.

3. The TCP doesn’t support multicasting or the new emerging standard of multicasting AMT. Which means the CDNs don’t have the opportunity to reduce network traffic by replicating the packets -when many clients are watching the same content. That itself is a big enough reason for CDNs (like Akamai or Level3) to not go with TCP for live streams.

---

For video streaming bandwidth is likely the constraint on the system. Using multicast you can greatly reduce the amount of upstream bandwidth used. With UDP you can easily multicast your packets to all connected terminals. You could also use a reliable multicast protocol, one is called Pragmatic General Multicast (PGM), I don't know anything about it and I guess it isn't widespread in its use.

---

While reading the TCP UDP debate I noticed a logical flaw. A TCP packet loss causing a one minute delay that's converted into a one minute buffer cant be correlated to UDP dropping a full minute while experiencing the same loss. A more fair comparison is as follows.

TCP experiences a packet loss. The video is stopped while TCP resend's packets in an attempt to stream mathematically perfect packets. Video is delayed for one minute and picks up where it left off after missing packet makes its destination. We all wait but we know we wont miss a single pixel.

UDP experiences a packet loss. For a second during the video stream a corner of the screen gets a little blurry. No one notices and the show goes on without looking for the lost packets.

Anything that streams gains the most benefits from UDP. The packet loss causing a one minute delay to TCP would not cause a one minute delay to UDP. Considering that most systems use multiple resolution streams making things go blocky when starving for packets, makes even more sense to use UDP.

UDP FTW when streaming.

---

If the bandwidth is far higher than the bitrate, I would recommend TCP for unicast live video streaming.

Case 1: Consecutive packets are lost for a duration of several seconds. => live video will stop on the client side whatever the transport layer is (TCP or UDP). When the network recovers: - if TCP is used, client video player can choose to restart the stream at the first packet lost (timeshift) OR to drop all late packets and to restart the video stream with no timeshift. - if UDP is used, there is no choice on the client side, video restart live without any timeshift. => TCP equal or better.

Case 2: some packets are randomly and often lost on the network. - if TCP is used, these packets will be immediately retransmitted and with a correct jitter buffer, there will be no impact on the video stream quality/latency. - if UDP is used, video quality will be poor. => TCP much better

---

All the 'use UDP' answers assume an open network and 'stuff it as much as you can' approach. Good for old-style closed-garden dedicated audio/video networks, which are a vanishing sort.

In the actual world, your transmission will go through firewalls (that will drop multicast and sometimes udp), the network is shared with others more important ($$$) apps, so you want to punish abusers with window scaling.

---

Besides all the other reasons, UDP can use multicast. Supporting 1000s of TCP users all transmitting the same data wastes bandwidth. However, there is another important reason for using TCP.

TCP can much more easily pass through firewalls and NATs. Depending on your NAT and operator, you may not even be able to receive a UDP stream due to problems with UDP hole punching.

---

This is the thing, it is more a matter of content than it is a time issue. The TCP protocol requires that a packet that was not delivered must be check, verified and redelivered. UDP does not use this requirement. So if you sent a file which contains millions of packets using UDP, like a video, if some of the packets are missing upon delivery, they will most likely go unmissed.

참고URL : https://stackoverflow.com/questions/6187456/tcp-vs-udp-on-video-stream