Протокол за поточно предаване в реално време, блог за шифроване
Протоколът RTSP позволява на клиента да иска живи или предварително записани потоци от медийни сървъри, подобно на HTTP позволява на клиентите да издават заявки към уеб сървъри. Всъщност RTSP пое голяма част от синтаксиса и семантиката си от HTTP/1.1, тъй като и двата протокола формално изпълняват подобни функции. Приликите подчертават общия характер на много от концепциите, внедрени в HTTP. Протоколите обаче имат редица ключови разлики, които са свързани с уникалните изисквания за мултимедийни потоци и ограничените възможности на HTTP/1.1 за прехвърляне на мултимедийни данни. В този раздел ще сравним и сравним RTSP и HTTP. След това описваме методите за заявка RTSP, кодовете за отговор и заглавията в сравнение и контраст с HTTP/1.1. Дискусията се основава на материала в глава 7 (раздел 7.2), който описва синтаксиса на HTTP/1.1.
Прилики и разлики
Всеки от разглежданите протоколи може по принцип да изпълни цялата задача за извличане на описанието на медийната сесия и искане на медийните данни. Въпреки че HTTP може да не е най-добрият протокол за извършване на всички тези неща, op може да се използва за предаване на описание на сесия. В отговор на потребител, щракнал върху хипертекстова връзка, браузърът може да издаде HTTP заявка за информация, описваща сесията (например http://www.foo.com/bar.sdp). Отговорът на уеб сървъра ще включва информация, описваща сесията, във формат SDP, както е показано по-долу:
НТТР/1.1 200 OK Тип съдържание: application/sdp
o = - 2890844526 2890842807 IN IP4 192.16.24.202 s = RTSP сесия
m = аудио 0 RTP/AVP 0
m = видео 0 RTP/AVP 31
На този етап уеб браузърът вече може да активира медийния плейър за извършване на други действия, както е описано в раздел 12.3.3. В допълнение, медийният плейър може да предостави на потребителя интерфейс за избор на мултимедийни сесии. В този случай медийният плейър може директно да взаимодейства със сървъра RTSP, за да извлече описания на сесии, без да включва уеб браузър.
Въпреки многото прилики между двата протокола, RTSP се различава от HTTP 110 по редица ключови начини.
Отделни връзки за данни и команди. За разлика от HTTP, RTSP сървърът създава отделна връзка за прехвърляне на данни. В този смисъл RTSP е близък до FTP. Клиентът и сървърът обменят RTSP съобщения по контролната връзка. Други протоколи като RTP и RTCP изпълняват задачата за прехвърляне на данни. Това разделяне позволява на клиента и сървъра да продължат да обменят RTSP съобщения по време на трансфери на данни, за да се адаптират към текущата среда или да инициират допълнителни трансфери. Освен това предаването на команди и предаването на данни могат да използват различни транспортни протоколи. RTSP съобщения Обикновено се изпращат през TCP, въпреки че може да се използва и UDP. Обмен на пакети RTP и RTCP Обикновено rio UDP, въпреки че е възможен и TCP.
Различни URI формати. За RTSP е запазен Norg 554. Изборът на протокол (UDP или TCP) може да бъде определен в схемата на URI. Схемите rtsp и rtspu се отнасят съответно за TCP и UDP. Например rtsp: //foo.com/bar идентифицира сесията, която се изисква и контролира от rio RTSP през TCP връзка. От друга страна, rtspu: //foo.com/bar показва, че клиентът трябва да издава RTSP заявка през UDP. Исканият URI в RTSP може да се отнася както до цялата сесия, така и до отделни медийни потоци. Низът на заявката в заявката RTSP трябва да съдържа абсолютния път, включително името на хоста. Това избягва неяснотата кой RTSP сървър трябва да получи заявката. За разлика от това, HTTP/1.1 има отделна заглавка на хоста за тази цел, за да поддържа обратна съвместимост с HTTP/1.0, както беше обсъдено по-рано в Глава 7 (Раздел 7.8).