FMUSER Wirless Transmituj wideo i audio łatwiejsze!
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
5, protokół RTSP
Dokument referencyjny RFC2326
Real Time Streaming Protocol (Real Time Streaming Protocol) jest protokołem strumieniowania multimediów używanym do sterowania dźwiękiem lub wideo i umożliwia jednoczesną kontrolę zapotrzebowania na wiele strumieni. Protokół komunikacji sieciowej używany podczas transmisji nie mieści się w zdefiniowanym zakresie. Strona serwera Do przesyłania strumieniowej zawartości możesz użyć protokołu TCP lub UDP. Jego składnia i działanie są podobne do HTTP 1.1, ale synchronizacja czasu nie jest szczególnie podkreślana, więc może tolerować opóźnienia w sieci. Wspomniana wcześniej wielostrumieniowa kontrola popytu (Multicast) może nie tylko zmniejszyć wykorzystanie sieci po stronie serwera, ale także obsługiwać wielostronne wideokonferencje (wideokonferencje). Ponieważ działa podobnie do HTTP1.1, funkcja pamięci podręcznej „Pamięć podręczna” serwera proxy „Proxy” ma również zastosowanie do RTSP, a ponieważ RTSP ma funkcję przekierowania, serwer, który świadczy usługę, może być przełączany zgodnie z rzeczywistym obciążeniem sytuacja, aby uniknąć nadmiernego obciążenia skoncentrowanego na tym samym serwerze i spowodować opóźnienia.
został zaproponowany wspólnie przez Real Networks i Netscape. Protokół określa, w jaki sposób aplikacje typu „jeden do wielu” mogą efektywnie przesyłać dane multimedialne przez sieć IP. RTSP zapewnia rozszerzalną strukturę, która umożliwia kontrolowanie danych w czasie rzeczywistym na żądanie, takich jak audio i wideo. Źródła danych obejmują dane na żywo i dane przechowywane w klipach.
Celem tego protokołu jest sterowanie wieloma połączeniami transmisji danych, zapewnienie sposobu wyboru kanałów transmisji, takich jak UDP, multiemisja UDP i TCP, oraz zapewnienie metod wyboru mechanizmu transmisji opartego na protokole RTP.
Związek między RTSP i RTP
RTP: protokół transportu w czasie rzeczywistym
RTP / RTCP to rzeczywisty protokół transmisji danych;
RTP przesyła dane audio / wideo. Jeśli jest to PLAY, serwer wysyła go do klienta. Jeśli jest to REKORD, może zostać wysłany na serwer przez klienta. Cały protokół RTP składa się z dwóch ściśle powiązanych części: protokołu danych RTP i protokołu kontrolnego RTP (tj. RTCP) ;
RTCP: RTCP zawiera raport nadawcy i raport odbiorcy, używany do synchronizacji audio / wideo i do innych celów oraz jest protokołem kontrolnym;
RTSP: Protokół przesyłania strumieniowego w czasie rzeczywistym (RTSP)
Żądania RTSP obejmują głównie DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, OPTIONS, itp., Jak sama nazwa wskazuje, można to nazwać funkcją dialogu i sterowania;
Podczas konwersacji RTSP, SETUP może określić port używany przez RTP / RTCP, PLAY / PAUSE / TEARDOWN może rozpocząć lub zatrzymać wysyłanie RTP itp .;
6. Protokół TCP i UDP
Protokół TCP
TCP, pełna nazwa to Protokół kontroli transferu, a chińska nazwa to Transmission Control Protocol. Działa w warstwie transportowej OSI i zapewnia niezawodne usługi transmisji zorientowane na połączenie.
Praca TCP polega głównie na nawiązywaniu połączenia, a następnie odbieraniu danych z programu warstwy aplikacji i przesyłaniu. TCP używa połączenia obwodu wirtualnego do pracy. Przed wysłaniem danych musi nawiązać połączenie między nadawcą a odbiorcą. Po wysłaniu danych nadawca będzie czekał, aż odbiorca udzieli odpowiedzi potwierdzającej, w przeciwnym razie nadawca uzna, że dane zostały utracone i ponownie wyśle te dane.
RTP to nie http i ftp, które mogą w całości pobrać cały plik filmu. Wysyła dane w sieci ze stałą szybkością transmisji danych. Klient ogląda również plik filmowy z tą prędkością. Po odtworzeniu ekranu filmu nie można go odtwarzać wielokrotnie. , Chyba że ponownie zażądasz danych z serwera.
Największą różnicą między RTSP i RTP jest to, że: RTSP to dwukierunkowy protokół transmisji danych w czasie rzeczywistym, który umożliwia klientowi wysyłanie żądań do serwera, takich jak odtwarzanie, przewijanie do przodu i operacje do tyłu.
Oczywiście RTSP może przesyłać dane w oparciu o RTP, a także może wybrać TCP, UDP, UDP multiemisji i inne kanały do wysyłania danych, które mają dobrą skalowalność.
Jest to sieciowy protokół warstwy aplikacji podobny do protokołu http.
Port źródłowy: określono port nadawcy
Port docelowy: określono numer portu strony odbierającej
Numer sekwencji: wskazuje pozycję segmentu w sekwencji segmentów do przesłania
Numer potwierdzenia: określa numer kolejny pomyślnie odebranego segmentu, numer kolejny potwierdzenia zawiera następny numer sekwencyjny, którego oczekuje odbiorca wysyłający potwierdzenie
Przesunięcie TCP: określa długość nagłówka segmentu. Długość nagłówka sekcji zależy od opcji ustawionej w polu opcji nagłówka sekcji
Zarezerwowane: zarezerwowane pole jest przeznaczone do wykorzystania w przyszłości
Znaki: SYN, ACK, PSH, RST, URG, FIN
SYN: oznacza synchronizację
ACK: oznacza potwierdzenie
PSH: Wskazuje, że dane zostaną przesłane do procesu odbioru tak szybko, jak to możliwe
RST: Wskazuje zresetowanie połączenia
URG: Wskazuje wskaźnik awaryjny
FIN: Wskazuje, że nadawca zakończył transmisję danych
Okno: określ polecenie dotyczące rozmiaru następnego segmentu, który może przesłać nadawca
Suma kontrolna: suma kontrolna zawiera nagłówek segmentu TCP i część danych, używane do weryfikacji niezawodności nagłówka segmentu i części danych
Emergency: wskazuje, że segment zawiera informacje alarmowe, a wskaźnik awaryjny jest ważny tylko wtedy, gdy flaga URG jest ustawiona na 1.
Opcje: określany jest rozpoznawany rozmiar segmentu, sygnatura czasowa, koniec pola opcji oraz opcja granicy pola opcji
Jak działa TCP
Nawiązywanie połączenia TCP: Proces nawiązywania połączenia TCP jest również nazywany potrójnym uzgadnianiem TCP. Najpierw host wysyłający inicjuje żądanie synchronizacji (SYN) w celu ustanowienia połączenia z hostem odbierającym; host odbierający odpowiada z odpowiedzią na synchronizację / potwierdzenie (SYN / ACK) do hosta nadawcy po odebraniu tego żądania; odbiera go host nadawca Po wysłaniu pakietu potwierdzenia (ACK) do hosta odbierającego, w tym czasie połączenie TCP jest pomyślnie ustanowione;
Zamknięcie połączenia TCP: po ustanowieniu połączenia TCP przez hosta nadawcy i hosta docelowego i zakończeniu transmisji danych zostanie wysłany pakiet danych z flagą końca ustawioną na 1, aby zamknąć połączenie TCP i zwolnić miejsce w buforze zajmowane przez połączenie w o tym samym czasie; Ustawienie resetowania TCP: TCP umożliwia nagłe przerwanie połączenia podczas transmisji, co nazywa się resetowaniem TCP;
Sortowanie i potwierdzanie danych TCP: TCP jest niezawodnym protokołem transmisji. Wykorzystuje numery sekwencyjne i numery potwierdzeń do śledzenia odbioru danych podczas transmisji;
Retransmisja TCP: w procesie transmisji TCP, jeśli host odbierający nie otrzyma odpowiedzi potwierdzającej pakiet danych w okresie limitu czasu retransmisji, host nadawcy uważa pakiet danych za utracony i ponownie wysyła pakiet danych do odbiorcy. nazywa się retransmisją TCP;
Potwierdzenie opóźnienia TCP: TCP nie zawsze potwierdza data natychmiast po otrzymaniu. Pozwala to hostowi na wysyłanie własnej wiadomości potwierdzającej do drugiej strony podczas odbierania danych.
Ochrona danych TCP (suma kontrolna): TCP to niezawodny protokół transmisji, który zapewnia obliczanie sumy kontrolnej w celu uzyskania integralności danych podczas transmisji.
Protokół UDP
Protokół UDP to skrót od angielskiego UserDatagramProtocol, czyli protokołu datagramów użytkownika, który jest używany głównie do obsługi aplikacji sieciowych, które muszą przesyłać dane między komputerami. Wiele aplikacji sieciowych typu klient / serwer, w tym sieciowe systemy wideokonferencyjne, musi korzystać z protokołu UDP. Protokół UDP jest używany od wielu lat od momentu powstania. Chociaż jego początkowa świetność została przesłonięta przez niektóre podobne protokoły, nawet dzisiaj UDP jest nadal bardzo praktycznym i wykonalnym protokołem warstwy transportowej sieci.
Podobnie jak dobrze znany protokół TCP (protokół kontroli transmisji), protokół UDP znajduje się bezpośrednio na protokole IP (protokół internetowy). Zgodnie z modelem odniesienia OSI (Open System Interconnection), UDP i TCP są protokołami warstwy transportowej.
Główną funkcją protokołu UDP jest kompresja ruchu danych w sieci do postaci datagramów. Typowy datagram to jednostka transmisji danych binarnych. Pierwsze 8 bajtów każdego datagramu służy do przechowywania informacji nagłówka, a pozostałe bajty są używane do przechowywania określonych danych transmisji.
7. Porównanie protokołów RTP/RTCP, RTMP, TCP, UDP
TCP jest protokołem typu punkt-punkt, co oznacza, że każdy klient musi oddzielić łącze klient / serwer, więc transmisja danych do wielu klientów nie może być realizowana na poziomie sieci. Jeśli strumień danych musi być przesłany do wielu klientów w tym samym czasie, serwer musi przesłać kopię strumienia danych do każdego klienta. TCP może dynamicznie dostosowywać prędkość transmisji zgodnie z przepustowością sieci i stopniem przeciążenia oraz ponownie wysyłać utracone pakiety danych. Zapewniona jest niezawodność transmisji danych, ale zasoby serwera są drogie i trudno jest zapewnić wydajność transmisji strumienia danych w czasie rzeczywistym, gdy strumień danych jest duży.
UDP to zawodny protokół transmisji. Na końcu wysyłania prędkość, z jaką UDP przesyła dane, jest ograniczona jedynie szybkością, z jaką aplikacja generuje dane, pojemnością komputera i szerokością pasma transmisji; na końcu odbiorczym UDP umieszcza każdy segment wiadomości w kolejce. Aplikacja za każdym razem odczytuje segment wiadomości z kolejki; protokół UDP nie musi utrzymywać stanu połączenia i nie uważa, że każdy pakiet danych musi dotrzeć do odbiorcy, więc obciążenie sieci jest mniejsze niż TCP, a prędkość transmisji jest większa niż TCP; Im bardziej zatłoczona sieć, tym więcej pakietów danych jest traconych.
Główna różnica między protokołami UDP i TCP polega na tym, jak uzyskać niezawodną transmisję informacji. Protokół TCP zawiera specjalny mechanizm gwarancji dostawy. Gdy odbiorca danych otrzyma informacje od nadawcy, automatycznie wyśle do nadawcy wiadomość z potwierdzeniem; nadawca będzie kontynuował przesyłanie innych informacji dopiero po otrzymaniu wiadomości potwierdzającej. W przeciwnym razie zaczeka na otrzymanie wiadomości potwierdzającej.
Dzięki temu TCP ma więcej czasu na nawiązanie połączenia niż UDP. W porównaniu z UDP, TCP ma większe bezpieczeństwo i niezawodność. Rozmiar transmisji protokołu TCP nie jest ograniczony. Po nawiązaniu połączenia obie strony mogą przesyłać duże ilości danych w określonym formacie, podczas gdy UDP jest niewiarygodnym protokołem z limitem rozmiaru, który nie może za każdym razem przekraczać 64 KB.
W porównaniu z protokołem TCP inną różnicą w protokole UDP jest sposób odbierania wielu nieoczekiwanych datagramów. W przeciwieństwie do TCP, UDP nie gwarantuje kolejności wysyłania i odbierania danych.
RTP jest powyżej UDP. Chociaż UDP nie jest tak niezawodny jak TCP i nie może zagwarantować jakości usługiusług czasu rzeczywistego, RTCP musi monitorować transmisję danych i jakość usług w czasie rzeczywistym. Jednak ponieważ opóźnienie transmisji UDP jest mniejsze niż TCP, może być bardzo kompatybilny z obrazem i dźwiękiem. Dobry mecz. Dlatego w praktycznych zastosowaniach RTP/RTCP/UDP jest używany do mediów audio/wideo, a TCP do transmisji danych i sygnalizacji sterującej.
Protokół RTMP to protokół zaprojektowany specjalnie do wydajnej transmisji obrazu, dźwięku i danych. Realizuje transmisję obrazu i dźwięku w czasie rzeczywistym poprzez ustanowienie binarnego połączenia TCP lub podłączenie tunelu HTTP.
RTMP obsługuje więcej protokołów multimedialnych niż tradycyjne serwery multimedialne. Obsługuje dynamiczną transmisję wielu linii, które mogą zawierać dane audio, wideo i skryptowe z serwera do klienta i od klienta do serwera. RTMP osobno przetwarza dane audio, wideo i skryptów.
Dane dźwiękowe i wideo są oddzielnie buforowane na serwerze. Jeśli dane dźwiękowe osiągną pewien limit w buforze dźwięku, wszystkie dane w buforze zostaną odrzucone, a ostatnio otrzymane dane będą mogły rozpocząć gromadzenie w buforze i wysłane do każdego klienta. Dane wideo są przetwarzane w podobny sposób, różnica polega na tym, że po nadejściu nowej klatki kluczowej dane w buforze są usuwane. Podczas odrzucania starych danych ramki, jeśli okaże się, że dane klienta są nieprawidłowe, dopasowywane są nowe i stare ramki.
RTMP nadaje danym różne poziomy priorytetów. W rozmowach w czasie rzeczywistym dźwięk jest najważniejszy, wideo ma niski priorytet, a dane skryptu mają pierwszeństwo między dźwiękiem a wideo.
Protokół RTMP może tworzyć wiele strumieni danych, ale każdy strumień danych może mieć tylko jeden kierunek. Korzystając z RTMP można zbudować taki system, klient może jednocześnie współdziałać z serwerem RTMP i serwerem aplikacji, dzięki czemu obciążenie serwera może być rozproszone, chociaż w tej ulepszonej strukturze systemu wymagania wydajnościowe serwera RTMP są stosunkowo wysokie.
8. Inne umowy
Protokół HTTP, pełna nazwa to HyperText Transfer Protocol, a chińska nazwa to HyperText Transfer Protocol;
Protokół MMS, pełna nazwa to Microsoft Media Server Protocol, a chińska nazwa to Microsoft Media Server Protocol;
Protokół HLS, pełna nazwa HTTP Live Streaming, to protokół transmisji mediów strumieniowych oparty na protokole HTTP zaimplementowanym przez firmę Apple Inc .;
|
Wpisz e-mail, aby otrzymać niespodziankę
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org -> Afrikaans
sq.fmuser.org -> albański
ar.fmuser.org -> arabski
hy.fmuser.org -> Armeński
az.fmuser.org -> Azerbejdżański
eu.fmuser.org -> baskijski
be.fmuser.org -> białoruski
bg.fmuser.org -> bułgarski
ca.fmuser.org -> kataloński
zh-CN.fmuser.org -> chiński (uproszczony)
zh-TW.fmuser.org -> chiński (tradycyjny)
hr.fmuser.org -> chorwacki
cs.fmuser.org -> czeski
da.fmuser.org -> duński
nl.fmuser.org -> holenderski
et.fmuser.org -> estoński
tl.fmuser.org -> filipiński
fi.fmuser.org -> fiński
fr.fmuser.org -> francuski
gl.fmuser.org -> galicyjski
ka.fmuser.org -> gruziński
de.fmuser.org -> niemiecki
el.fmuser.org -> grecki
ht.fmuser.org -> kreolski haitański
iw.fmuser.org -> hebrajski
hi.fmuser.org -> hindi
hu.fmuser.org -> węgierski
is.fmuser.org -> islandzki
id.fmuser.org -> indonezyjski
ga.fmuser.org -> irlandzki
it.fmuser.org -> włoski
ja.fmuser.org -> japoński
ko.fmuser.org -> koreański
lv.fmuser.org -> łotewski
lt.fmuser.org -> litewski
mk.fmuser.org -> macedoński
ms.fmuser.org -> malajski
mt.fmuser.org -> maltański
no.fmuser.org -> norweski
fa.fmuser.org -> perski
pl.fmuser.org -> polski
pt.fmuser.org -> portugalski
ro.fmuser.org -> rumuński
ru.fmuser.org -> rosyjski
sr.fmuser.org -> serbski
sk.fmuser.org -> słowacki
sl.fmuser.org -> słoweński
es.fmuser.org -> hiszpański
sw.fmuser.org -> suahili
sv.fmuser.org -> szwedzki
th.fmuser.org -> Tajski
tr.fmuser.org -> turecki
uk.fmuser.org -> ukraiński
ur.fmuser.org -> Urdu
vi.fmuser.org -> wietnamski
cy.fmuser.org -> walijski
yi.fmuser.org -> jidysz
FMUSER Wirless Transmituj wideo i audio łatwiejsze!
Kontakt
Adres:
Nr 305 Pokój HuiLan Budynek nr 273 Huanpu Road Guangzhou Chiny 510620
Kategorie
Newsletter