☰

TCP 대신 UDP를 통해 프로세스를 강제로 전송하는 방법은 무엇입니까?

tag-icon • tag-icon networking port tcp udp
TCP 대신 UDP를 통해 프로세스를 강제로 전송하는 방법은 무엇입니까?

나는 다음을 통해 비디오 스트리밍을 달성하기 위해 Linux 시스템에서 ffserver 프로세스를 실행하고 있습니다.ffmpeg. 그러나 비디오 스트리밍에는 지연이 있습니다. ~에ffserver 구성 파일나는 정의한다 Port 8090.

명령netstat -tulnap나에게 이것을 제공합니다 :

root@beagleboard:/etc# netstat -tulnap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             Stat                                                                             e       PID/Program name
tcp        0      0 0.0.0.0:68                  0.0.0.0:*                   LIST                                                                             EN      654/pump
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LIST                                                                             EN      662/portmap
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LIST                                                                             EN      698/dropbear
tcp        0      0 0.0.0.0:8090                0.0.0.0:*                   LIST                                                                             EN      744/ffserver
tcp        0     52 192.168.1.104:22            192.168.1.111:10838         ESTA                                                                             BLISHED 724/dropbear
udp        0      0 0.0.0.0:514                 0.0.0.0:*                                                                                                            703/syslog-ng
udp        0      0 0.0.0.0:111                 0.0.0.0:*                                                                                                            662/portmap
udp        0      0 0.0.0.0:60628               0.0.0.0:*                                                                                                            709/avahi-daemon: r
udp        0      0 0.0.0.0:5353                0.0.0.0:*                                                                                                            709/avahi-daemon: r

보시다시피 ffserver 프로세스는 TCP 프로토콜을 사용하여 전송하는데 이것이 비디오 스트리밍 지연의 원인이 아닐까 의심됩니다. 프로세스가 UDP 프로토콜을 사용하도록 하려면 어떻게 해야 합니까? 포트를 바꿔야 할까요?

답변1

프로그램 자체의 일부를 다시 작성하지 않고 프로그램이 TCP 대신 UDP를 사용하도록 강제할 수는 없습니다. 이러한 프로토콜은 상호 교환이 불가능할 정도로 다릅니다.

  • TCP는 스트림 지향적입니다(수신자는 모든 것을 송신자가 출력한 정확한 순서대로 연속 스트림으로 간주합니다). UDP는 데이터그램 지향적입니다(각 데이터그램은 별도의 패킷으로 전송되며 재정렬될 수도 있음).

  • TCP에는 흐름 제어 기능이 있으므로 보낸 사람(또는 보낸 사람의 OS)은 링크 오버플로나 다른 연결에 큰 영향을 주지 않고 데이터를 얼마나 빨리 보내야 하는지 정확히 알 수 있습니다. UDP는 이 중 어떤 것도 수행하지 않습니다. 제대로 "강제된" 프로그램은 링크 속도에 관계없이 UDP를 통해 초당 기가바이트의 데이터를 보내기 시작할 수 있습니다.

  • TCP에는 재전송이 있으므로 패킷이 중간에 삭제되면(예: 네트워크에 과부하가 걸리거나 다른 문제가 있는 경우) 재전송됩니다. 프로토콜이 신뢰할 수 있는 전송에 의존하고 UDP를 강제로 통과하도록 하는 경우, 최소한 단일 패킷이 손실되자마자 연결이 완전히 중단될 수 있습니다. (그리고 패킷~ 할 것이다길을 잃다; 위의 1번과 2번 항목을 참조하세요.)

답변2

다른 사람들이 언급했듯이 UDP와 TCP는 근본적으로 다른 프로토콜입니다.

그러나 만약 당신이~ 해야 하다TCP 대신 UDP를 통해 데이터를 전송하려면 다음과 같은 릴레이 도구를 사용할 수 있습니다.소캣. TCP 연결을 수신하고 TCP 스트림의 내용을 UDP 스트림으로 다른 호스트에 전달하도록 socat를 구성할 수 있습니다. 다른 호스트가 TCP 트래픽을 예상하는 경우 해당 릴레이의 다른 인스턴스를 사용하여 다시 TCP로 변환할 수 있습니다. 이렇게 하면 호스트 간 링크에서 재시도 및 확인 동작이 제거됩니다. 재시도 및 승인은 로컬 릴레이 도구와 로컬 애플리케이션 사이에 계속 존재하지만 로컬 루프백 링크에서는 재시도를 볼 가능성이 거의 없습니다.

그러나 이 방법으로는 지연 문제가 해결되지 않을 것입니다. 애플리케이션이 UDP 대신 TCP를 사용하도록 구축된 경우 패킷 삭제를 허용하지 않을 수 있으며, 이 경우 해킹으로 인해 불안정한 동작이 발생할 수 있습니다.

답변3

매우 느린 연결을 사용하지 않는 한 지연 문제는 비디오 코덱으로 인한 것일 가능성이 높습니다.

비디오를 효율적으로 압축하려면 예측 인코딩을 사용해야 합니다(참조:위키피디아에 있는 이 기사).

예측 코딩은 기본적으로 이전 또는 이후 이미지에서 이미지를 계산합니다. 이는 다음과 같은 의미를 갖습니다.

  1. 이전 프레임에서 계산된 P-프레임을 많이 사용하는 경우 비디오가 표시되기 전에 지연이 발생합니다.시작하다, 클라이언트가 다음 전체 비디오 프레임(I-프레임)을 기다려야 하기 때문입니다. 그러나 일단 스트림이 설정되면 비교적 지연 없이 비디오를 시청할 수 있습니다.

  2. B-프레임(이전 및 이후 이미지에서 계산됨)을 사용하는 경우 매우 큰 지연이 발생합니다. 위의 초기 지연 외에도 클라이언트는 마지막 I에서 재생을 시작할 다음 I-프레임을 기다려야 합니다. -액자. 이로 인해 지연이 발생합니다(클라이언트는 서버가 비디오를 녹화/전송하는 것보다 눈에 띄게 늦게 비디오를 재생하며 종종 몇 초 정도 걸립니다). 즉석에서 비디오를 인코딩하는 경우 서버에서도 지연이 발생합니다. 즉, 이전 I-프레임에서 시작하는 모든 내용을 전송하려면 다음 I-프레임을 기다려야 합니다.

대부분의 코덱의 경우 필요에 따라 B 프레임과 P 프레임의 사용을 조정할 수 있지만 지연과 압축 효율성 사이에는 절충점이 있습니다.

대역폭이 충분하다면 다음과 같이 B-/P-프레임 없이 코덱을 사용할 수도 있습니다.MJPEG

지연의 또 다른 이유는 플레이어 측의 버퍼링이므로 불안한 네트워크 전송이 있어도 왜곡이 발생하지 않습니다. 많은 비디오 플레이어에서는 버퍼 크기를 조정할 수 있습니다.

관련 정보