Protokół TCP nie gwarantuje jednak czasu, w jakim dane zostaną przekazane. Przy dużym ruchu w sieci, kiedy łącza są "zapchane", transmisja ulega znacznemu spowolnieniu, a nawet okresowo zatrzymuje się zupełnie; jest to spowodowane właśnie dużą ilością błędnie przetransmitowanych pakietów i wysyłanymi do serwera żądaniami ich retransmisji.
W przeciwieństwie do TCP, drugi z głównych protokołów internetowych - UDP (User Datagram Protocol) - przesyła pakiety bez gwarancji, że dotrą one do docelowego komputera, i bez sprawdzania tego faktu. W przypadku tłoku w sieci pakiet UDP może po prostu "zginąć" po drodze. Nie powoduje to jednak przerwy w przesyłaniu następnych pakietów, które wysyłane są niezależnie od tego, czy poprzednie pakiety doszły do celu, czy nie.
Jeżeli plik dźwiękowy lub wideo strumieniowany jest ze zwykłego serwera WWW, stosowany jest oczywiście protokół TCP. W przypadku "zgubienia" jakiegokolwiek pakietu protokół ten wymusza "do skutku" jego retransmisję przez serwer, co przy wolnych lub zatłoczonych łączach może spowodować odtwarzanie nagrania w sposób "szarpany" - z licznymi przerwami i zatrzymaniami nieokreślonej długości.
W przeciwieństwie do serwerów WWW, specjalizowane serwery multimediów strumieniowych (takie jak RealServer) opierają się zwykle na protokole UDP. Zastosowanie tego protokołu w przekazie audiowizualnym wydaje się być dużo bardziej odpowiednie niż TCP - "zgubienie" jednego bądź kilku pakietów w transmisji spowoduje co najwyżej chwilowe zakłócenia (podobne do tych, jakie występują w radiu lub telewizji) bądź "przeskok" dźwięku i obrazu, nie przerywa natomiast ciągłości transmisji. Dodatkowo, dla lepszej kontroli jakości przekazu, w większości systemów multimediów strumieniowych stosuje się dodatkowy "kanał sterujący", którym odtwarzacz przesyła do serwera zwrotną informację o stanie połączenia. Pozwala to serwerowi na dynamiczne dostosowywanie się do warunków panujących na łączach i ograniczanie liczby nadawanych pakietów (np. poprzez zmniejszenie liczby klatek na sekundę w przekazie wideo).
W ostatnich latach zaobserwować można intensywne prace zmierzające w kierunku standaryzacji protokołów internetowych używanych do strumieniowej transmisji multimediów - m.in. w kwietniu 1998 r. ukazała się specyfikacja protokołu RTSP (Real-Time Streaming Protocol - RFC 2326), określającego format wspomnianego "kanału sterującego" między odtwarzaczem i serwerem (protokół ten wykorzystuje między innymi najnowsza wersja G2 oprogramowania RealMedia). Protokół RTSP nie opisuje samego sposobu transmisji danych, lecz jedynie sterowanie tą transmisją; proponowanym protokołem służącym do samego przesyłania strumienia danych jest natomiast opublikowany w 1996 roku protokół RTP (Real-time Transport Protocol - RFC 1889), choć spora część programów używa zamiast niego własnych, niestandardowych protokołów.