FMUSER 무선 전송 비디오 및 오디오가 더 쉬워졌습니다!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> 아프리칸스어
sq.fmuser.org -> 알바니아어
ar.fmuser.org -> 아랍어
hy.fmuser.org -> 아르메니아어
az.fmuser.org -> 아제르바이잔 어
eu.fmuser.org -> 바스크
be.fmuser.org -> 벨로루시 어
bg.fmuser.org -> 불가리아어
ca.fmuser.org -> 카탈로니아 어
zh-CN.fmuser.org -> 중국어 (간체)
zh-TW.fmuser.org -> 중국어 (번체)
hr.fmuser.org -> 크로아티아어
cs.fmuser.org -> 체코
da.fmuser.org -> 덴마크어
nl.fmuser.org -> 네덜란드어
et.fmuser.org -> 에스토니아어
tl.fmuser.org -> 필리피노
fi.fmuser.org -> 핀란드어
fr.fmuser.org -> 프랑스어
gl.fmuser.org -> 갈리시아어
ka.fmuser.org -> 조지아 어
de.fmuser.org -> 독일어
el.fmuser.org -> 그리스
ht.fmuser.org -> 아이티 크리올
iw.fmuser.org -> 히브리어
hi.fmuser.org -> 힌디어
hu.fmuser.org 헝가리어
is.fmuser.org -> 아이슬란드 어
id.fmuser.org -> 인도네시아어
ga.fmuser.org -> 아일랜드어
it.fmuser.org -> 이탈리아어
ja.fmuser.org -> 일본어
ko.fmuser.org -> 한국어
lv.fmuser.org -> 라트비아어
lt.fmuser.org 리투아니아어
mk.fmuser.org -> 마케도니아 어
ms.fmuser.org -> 말레이어
mt.fmuser.org -> 몰타어
no.fmuser.org -> 노르웨이어
fa.fmuser.org -> 페르시아어
pl.fmuser.org -> 폴란드어
pt.fmuser.org -> 포르투갈어
ro.fmuser.org -> 루마니아어
ru.fmuser.org -> 러시아어
sr.fmuser.org -> 세르비아어
sk.fmuser.org -> 슬로바키아어
sl.fmuser.org -> 슬로베니아어
es.fmuser.org -> 스페인어
sw.fmuser.org -> 스와힐리
sv.fmuser.org -> 스웨덴어
th.fmuser.org -> 태국
tr.fmuser.org -> 터키어
uk.fmuser.org -> 우크라이나어
ur.fmuser.org -> 우르두어
vi.fmuser.org -> 베트남어
cy.fmuser.org -> 웨일스 어
yi.fmuser.org -> 이디시어
5, RTSP 프로토콜
참조 문서 RFC2326
실시간 스트리밍 프로토콜 (Real Time Streaming Protocol)은 사운드 또는 비디오를 제어하는 데 사용되는 멀티미디어 스트리밍 프로토콜이며 동시 다중 스트리밍 요구 제어를 허용합니다. 전송 중에 사용 된 네트워크 통신 프로토콜이 정의 된 범위 내에 있지 않습니다. 서버 측 TCP 또는 UDP를 사용하여 스트리밍 콘텐츠를 전송하도록 선택할 수 있습니다. 구문과 작동은 HTTP 1.1과 유사하지만 시간 동기화가 특별히 강조되지 않으므로 네트워크 지연을 허용 할 수 있습니다. 앞서 언급 한 멀티 스트리밍 수요 제어 (Multicast)는 서버 측의 네트워크 사용량을 줄일 수있을뿐만 아니라 다자간 화상 회의 (Video Conference)도 지원할 수 있습니다. HTTP1.1과 유사하게 동작하기 때문에 프록시 서버 "Proxy"의 캐시 기능 "Cache"도 RTSP에 적용 할 수 있으며, RTSP는 리디렉션 기능이 있기 때문에 실제 부하에 따라 서비스를 제공하는 서버 전환이 가능합니다. 동일한 서버에 집중된 과도한 부하를 피하고 지연을 유발하는 상황.
Real Networks와 Netscape가 공동으로 제안했습니다. 이 프로토콜은 일대 다 애플리케이션이 IP 네트워크를 통해 멀티미디어 데이터를 효과적으로 전송할 수있는 방법을 정의합니다. RTSP는 오디오 및 비디오와 같은 실시간 데이터를 제어하고 주문형으로 실시간으로 제어 할 수있는 확장 가능한 프레임 워크를 제공합니다. 데이터 소스에는 라이브 데이터 및 클립에 저장된 데이터가 포함됩니다.
이 프로토콜의 목적은 여러 데이터 전송 연결을 제어하고 UDP, 멀티 캐스트 UDP 및 TCP와 같은 전송 채널을 선택하는 방법을 제공하고 RTP를 기반으로 전송 메커니즘을 선택하는 방법을 제공하는 것입니다.
RTSP와 RTP의 관계
RTP : 실시간 전송 프로토콜
RTP / RTCP는 실제 데이터 전송 프로토콜입니다.
RTP는 오디오 / 비디오 데이터를 전송합니다. PLAY이면 서버는이를 클라이언트로 보냅니다. RECORD 인 경우 클라이언트에서 서버로 전송할 수 있습니다. 전체 RTP 프로토콜은 밀접하게 관련된 두 부분으로 구성됩니다. RTP 데이터 프로토콜과 RTP 제어 프로토콜 (예 : RTCP) ;
RTCP : RTCP에는 오디오 / 비디오 동기화 및 기타 목적에 사용되는 Sender Report 및 Receiver Report가 포함되며 제어 프로토콜입니다.
RTSP : RTSP (실시간 스트리밍 프로토콜)
RTSP 요청에는 주로 DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, OPTIONS 등이 포함됩니다. 이름에서 알 수 있듯이 대화 및 제어 기능이라고 할 수 있습니다.
RTSP 대화 중에 SETUP은 RTP / RTCP가 사용하는 포트를 결정할 수 있고, PLAY / PAUSE / TEARDOWN은 RTP 전송을 시작하거나 중지 할 수 있습니다.
6. TCP 및 UDP 프로토콜
TCP 프로토콜
TCP, 전체 이름은 전송 제어 프로토콜, 중국어 이름은 전송 제어 프로토콜입니다. OSI 전송 계층에서 작동하며 연결 지향의 안정적인 전송 서비스를 제공합니다.
TCP의 작업은 주로 연결을 설정 한 다음 응용 프로그램 계층 프로그램에서 데이터를 수신하여 전송하는 것입니다. TCP는 가상 회로 연결을 사용하여 작동합니다. 데이터를 보내기 전에 발신자와 수신자 사이에 연결을 설정해야합니다. 데이터가 전송 된 후 발신자는 수신자가 확인 응답을 할 때까지 기다립니다. 그렇지 않으면 발신자는이 데이터가 손실되었다고 생각하고이 데이터를 다시 보냅니다.
RTP는 전체 동영상 파일을 완전히 다운로드 할 수있는 http 및 ftp와는 다릅니다. 고정 된 데이터 속도로 네트워크에서 데이터를 전송합니다. 클라이언트는 또한이 속도로 동영상 파일을 봅니다. 동영상 화면이 재생 된 후에는 반복해서 재생할 수 없습니다. , 서버에서 데이터를 다시 요청하지 않는 한.
RTSP와 RTP의 가장 큰 차이점은 다음과 같습니다. RTSP는 양방향 실시간 데이터 전송 프로토콜로, 클라이언트가 재생, 빨리 감기 및 역방향 작업과 같은 요청을 서버에 보낼 수 있습니다.
물론 RTSP는 RTP를 기반으로 데이터를 전송할 수 있으며 TCP, UDP, 멀티 캐스트 UDP 및 기타 채널을 선택하여 데이터를 전송할 수있어 확장 성이 좋습니다.
http 프로토콜과 유사한 네트워크 응용 프로그램 계층 프로토콜입니다.
소스 포트 : 보낸 사람의 포트가 지정됩니다.
대상 포트 : 수신단의 포트 번호가 지정됩니다.
시퀀스 번호 : 전송 될 세그먼트 시퀀스에서 세그먼트의 위치를 나타냅니다.
확인 번호 : 성공적으로 수신 된 세그먼트의 시퀀스 번호를 지정합니다. 확인 시퀀스 번호에는 확인을 보내는 쪽이 수신 할 것으로 예상하는 다음 시퀀스 번호가 포함됩니다.
TCP 오프셋 : 세그먼트 헤더의 길이를 지정합니다. 섹션 헤더의 길이는 섹션 헤더 옵션 필드에 설정된 옵션에 따라 다릅니다.
예약 됨 : 예약 된 필드는 향후 사용을 위해 지정됩니다.
징후 : SYN, ACK, PSH, RST, URG, FIN
SYN : 동기화를 의미합니다.
ACK : 확인을 의미합니다.
PSH : 데이터가 가능한 한 빨리 수신 프로세스로 전송 될 것임을 나타냅니다.
RST : 재설정 연결을 나타냅니다.
URG : 비상 포인터를 나타냅니다.
FIN : 발신자가 데이터 전송을 완료했음을 나타냅니다.
창 : 발신자가 전송할 수있는 다음 세그먼트의 크기에 대한 명령을 지정합니다.
체크섬 : 체크섬에는 세그먼트 헤더 및 데이터 부분의 신뢰성을 확인하는 데 사용되는 TCP 세그먼트 헤더 및 데이터 부분이 포함됩니다.
비상 : 세그먼트에 비상 정보가 포함되어 있음을 나타내며 비상 포인터는 URG 플래그가 1로 설정된 경우에만 유효합니다.
옵션 : 인식 된 세그먼트 크기, 타임 스탬프, 옵션 필드의 끝이 지정되고 옵션 필드의 경계 옵션이 지정됩니다.
TCP 작동 원리
TCP 연결 설정 : TCP 연결 설정 프로세스를 TCP XNUMX 방향 핸드 셰이크라고도합니다. 첫째, 송신자 호스트는 수신자 호스트에 대한 연결을 설정하기 위해 동기화 (SYN) 요청을 시작합니다. 수신자 호스트는이 요청을 수신 한 후 발신자 호스트에 동기화 / 승인 (SYN / ACK) 응답으로 응답합니다. 송신자 호스트는 이것을 수신합니다. 패킷이 수신자 호스트에 승인 (ACK)을 보낸 후,이 시점에서 TCP 연결이 성공적으로 설정됩니다.
TCP 연결 종료 : 송신자 호스트와 대상 호스트가 TCP 연결을 설정하고 데이터 전송을 완료 한 후 끝 플래그가 1로 설정된 데이터 패킷이 전송되어 TCP 연결을 닫고 연결이 차지하는 버퍼 공간을 해제합니다. 동시; TCP 재설정 설정 : TCP는 전송 중에 연결이 갑자기 중단되도록 허용하며이를 TCP 재설정이라고합니다.
TCP 데이터 정렬 및 확인 : TCP는 신뢰할 수있는 전송 프로토콜입니다. 전송 중에 데이터 수신을 추적하기 위해 시퀀스 번호와 확인 번호를 사용합니다.
TCP 재전송 : TCP 전송 과정에서 수신자 호스트가 재전송 타임 아웃 기간 내에 데이터 패킷에 대한 승인 응답을받지 못하면 송신자 호스트는 데이터 패킷이 손실 된 것으로 간주하고 데이터 패킷을 다시 수신자에게 보냅니다. TCP 재전송이라고합니다.
TCP 지연 확인 : TCP가 항상 d를 확인하지는 않습니다.ata를받은 직후. 호스트가 데이터를 수신하는 동안 상대방에게 자체 확인 메시지를 보낼 수 있습니다.
TCP 데이터 보호 (체크섬) : TCP는 전송 중에 데이터의 무결성을 실현하기 위해 체크섬 계산을 제공하는 신뢰할 수있는 전송 프로토콜입니다.
UDP 프로토콜
UDP 프로토콜은 영어 UserDatagramProtocol의 약자, 즉 사용자 데이터 그램 프로토콜로, 주로 컴퓨터간에 데이터를 전송해야하는 네트워크 응용 프로그램을 지원하는 데 사용됩니다. 네트워크 화상 회의 시스템을 포함한 수많은 클라이언트 / 서버 네트워크 애플리케이션은 UDP 프로토콜을 사용해야합니다. UDP 프로토콜은 처음부터 수년 동안 사용되었습니다. 초기의 탁월함은 유사한 프로토콜에 의해 가려졌지만 오늘날에도 UDP는 여전히 매우 실용적이고 실행 가능한 네트워크 전송 계층 프로토콜입니다.
잘 알려진 TCP (전송 제어 프로토콜) 프로토콜과 마찬가지로 UDP 프로토콜은 IP (인터넷 프로토콜) 프로토콜 바로 위에 있습니다. OSI (Open System Interconnection) 참조 모델에 따르면 UDP와 TCP는 모두 전송 계층 프로토콜입니다.
UDP 프로토콜의 주요 기능은 네트워크 데이터 트래픽을 데이터 그램 형식으로 압축하는 것입니다. 일반적인 데이터 그램은 이진 데이터의 전송 단위입니다. 각 데이터 그램의 처음 8 바이트는 헤더 정보를 포함하는 데 사용되고 나머지 바이트는 특정 전송 데이터를 포함하는 데 사용됩니다.
7. RTP / RTCP, RTMP, TCP, UDP 프로토콜 비교
TCP는 지점 간 프로토콜입니다. 즉, 각 클라이언트가 클라이언트 / 서버 링크를 분리해야하므로 여러 클라이언트에 대한 데이터 브로드 캐스팅을 네트워크 수준에서 실현할 수 없습니다. 데이터 스트림이 동시에 여러 클라이언트에 전송되어야하는 경우 서버는 데이터 스트림의 사본을 각 클라이언트에 전송해야합니다. TCP는 네트워크 대역폭과 혼잡 정도에 따라 전송 속도를 동적으로 조정하고 손실 된 데이터 패킷을 재전송 할 수 있습니다. 데이터 전송의 신뢰성은 보장되지만 서버 자원이 비싸고 데이터 스트림이 큰 경우 데이터 스트림 전송의 실시간 성능을 보장하기가 어렵습니다.
UDP는 신뢰할 수없는 전송 프로토콜입니다. 송신 측에서 UDP가 데이터를 전송하는 속도는 응용 프로그램이 데이터를 생성하는 속도, 컴퓨터의 용량 및 전송 대역폭에 의해서만 제한됩니다. 수신 측에서 UDP는 각 메시지 세그먼트를 대기열에 넣습니다. 애플리케이션은 매번 큐에서 메시지 세그먼트를 읽습니다. UDP 프로토콜은 연결 상태를 유지할 필요가 없으며 모든 데이터 패킷이 수신단에 도달해야한다고 생각하지 않으므로 네트워크로드가 TCP보다 작고 전송 속도가 TCP보다 빠릅니다. 네트워크가 혼잡할수록 더 많은 데이터 패킷이 손실됩니다.
UDP와 TCP 프로토콜의 주요 차이점은 정보를 안정적으로 전송하는 방법입니다. TCP 프로토콜에는 특별한 배달 보장 메커니즘이 포함되어 있습니다. 데이터 수신자가 발신자로부터 정보를 받으면 자동으로 발신자에게 확인 메시지를 보냅니다. 발신자는 확인 메시지를받은 후에 만 다른 정보를 계속 전송합니다. 그렇지 않으면 확인 메시지가 수신 될 때까지 대기합니다.
따라서 TCP는 UDP보다 연결을 설정하는 데 더 많은 시간이 있습니다. UDP에 비해 TCP는 더 높은 보안과 신뢰성을 가지고 있습니다. TCP 프로토콜 전송의 크기는 제한되지 않습니다. 연결이 설정되면 양 당사자는 특정 형식으로 많은 양의 데이터를 전송할 수 있지만 UDP는 매번 64K를 초과 할 수없는 크기 제한이있는 신뢰할 수없는 프로토콜입니다.
TCP 프로토콜과 비교할 때 UDP 프로토콜의 또 다른 차이점은 예기치 않은 여러 데이터 그램을 수신하는 방법입니다. TCP와 달리 UDP는 데이터 송수신 순서를 보장하지 않습니다.
RTP가 UDP보다 높습니다. UDP는 TCP만큼 신뢰할 수 없으며 서비스 품질을 보장 할 수 없습니다.실시간 서비스의 경우 RTCP는 데이터 전송 및 서비스 품질을 실시간으로 모니터링해야합니다. 그러나 UDP의 전송 지연이 TCP의 전송 지연보다 적기 때문에 영상 및 음성과의 호환성이 매우 뛰어납니다. 훌륭한 경기. 따라서 실제 응용에서 RTP / RTCP / UDP는 오디오 / 비디오 미디어에 사용되며 TCP는 데이터 전송 및 제어 시그널링에 사용됩니다.
RTMP 프로토콜은 비디오, 오디오 및 데이터의 효율적인 전송을 위해 특별히 설계된 프로토콜입니다. 바이너리 TCP 연결을 설정하거나 HTTP 터널을 연결하여 실시간 영상 및 음성 전송을 실현합니다.
RTMP는 기존 미디어 서버보다 더 많은 미디어 프로토콜을 지원합니다. 서버에서 클라이언트로, 클라이언트에서 서버로 오디오, 비디오 및 스크립트 데이터를 포함 할 수있는 여러 회선의 동적 전송을 지원합니다. RTMP는 오디오, 비디오 및 스크립트 데이터를 별도로 처리합니다.
사운드 및 비디오 데이터는 서버에서 별도로 버퍼링됩니다. 사운드 데이터가 사운드 버퍼의 특정 한도에 도달하면 버퍼의 모든 데이터가 삭제되고 가장 최근에 도착한 데이터는 버퍼에서 수집을 시작하여 각 클라이언트로 전송됩니다. 비디오 데이터는 유사한 방식으로 처리되지만 차이점은 새 키 프레임이 도착하면 버퍼의 데이터가 지워진다는 것입니다. 이전 프레임 데이터를 폐기 할 때 클라이언트의 데이터가 잘못되었음을 발견하면 새 프레임과 이전 프레임을 장착합니다.
RTMP는 데이터에 서로 다른 우선 순위 수준을 제공합니다. 실시간 대화에서는 사운드가 가장 중요하고 비디오는 낮은 우선 순위를 가지며 스크립트 데이터는 사운드와 비디오 사이의 우선 순위가 지정됩니다.
RTMP 프로토콜은 여러 데이터 스트림을 만들 수 있지만 각 데이터 스트림은 한 방향 만 가질 수 있습니다. RTMP를 사용하면 이러한 시스템을 구축 할 수 있으며 클라이언트는 RTMP 서버 및 응용 프로그램 서버와 동시에 상호 작용할 수 있으므로이 개선 된 시스템 구조에서는 RTMP 서버의 성능 요구 사항이 있지만 서버의로드를 분산시킬 수 있습니다. 상대적으로 높습니다.
8. 기타 계약
HTTP 프로토콜, 전체 이름은 HyperText Transfer Protocol, 중국어 이름은 HyperText Transfer Protocol입니다.
MMS 프로토콜, 전체 이름은 Microsoft Media Server Protocol, 중국어 이름은 Microsoft Media Server Protocol입니다.
HLS 프로토콜 (전체 이름 HTTP Live Streaming)은 Apple Inc.에서 구현 한 HTTP 기반의 스트리밍 미디어 전송 프로토콜입니다.
|
놀라움을 얻으려면 이메일을 입력하십시오.
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> 아프리칸스어
sq.fmuser.org -> 알바니아어
ar.fmuser.org -> 아랍어
hy.fmuser.org -> 아르메니아어
az.fmuser.org -> 아제르바이잔 어
eu.fmuser.org -> 바스크
be.fmuser.org -> 벨로루시 어
bg.fmuser.org -> 불가리아어
ca.fmuser.org -> 카탈로니아 어
zh-CN.fmuser.org -> 중국어 (간체)
zh-TW.fmuser.org -> 중국어 (번체)
hr.fmuser.org -> 크로아티아어
cs.fmuser.org -> 체코
da.fmuser.org -> 덴마크어
nl.fmuser.org -> 네덜란드어
et.fmuser.org -> 에스토니아어
tl.fmuser.org -> 필리피노
fi.fmuser.org -> 핀란드어
fr.fmuser.org -> 프랑스어
gl.fmuser.org -> 갈리시아어
ka.fmuser.org -> 조지아 어
de.fmuser.org -> 독일어
el.fmuser.org -> 그리스
ht.fmuser.org -> 아이티 크리올
iw.fmuser.org -> 히브리어
hi.fmuser.org -> 힌디어
hu.fmuser.org 헝가리어
is.fmuser.org -> 아이슬란드 어
id.fmuser.org -> 인도네시아어
ga.fmuser.org -> 아일랜드어
it.fmuser.org -> 이탈리아어
ja.fmuser.org -> 일본어
ko.fmuser.org -> 한국어
lv.fmuser.org -> 라트비아어
lt.fmuser.org 리투아니아어
mk.fmuser.org -> 마케도니아 어
ms.fmuser.org -> 말레이어
mt.fmuser.org -> 몰타어
no.fmuser.org -> 노르웨이어
fa.fmuser.org -> 페르시아어
pl.fmuser.org -> 폴란드어
pt.fmuser.org -> 포르투갈어
ro.fmuser.org -> 루마니아어
ru.fmuser.org -> 러시아어
sr.fmuser.org -> 세르비아어
sk.fmuser.org -> 슬로바키아어
sl.fmuser.org -> 슬로베니아어
es.fmuser.org -> 스페인어
sw.fmuser.org -> 스와힐리
sv.fmuser.org -> 스웨덴어
th.fmuser.org -> 태국
tr.fmuser.org -> 터키어
uk.fmuser.org -> 우크라이나어
ur.fmuser.org -> 우르두어
vi.fmuser.org -> 베트남어
cy.fmuser.org -> 웨일스 어
yi.fmuser.org -> 이디시어
FMUSER 무선 전송 비디오 및 오디오가 더 쉬워졌습니다!
Contact
주소:
No.305 Room HuiLan Building No.273 Huanpu Road 광저우 중국 510620
카테고리
MMCC 뉴스레터