客户端传输的质量受到包括接入网络、接入服务器、设备硬件和网络环境等影响，很难做到100%不出现丢包、延时、抖动等网络质量波动。因此，在实时通信RTC应用的发展历程上，出现过多种不同的网络传输协议来对抗网络中出现的质量问题，简化RTC上层应用应对不同网络情况时所面临的复杂性。
主流的媒体相关网络传输协议包括以下几种。
1）RTMP协议
RTMP协议最初是由Macromedia（后被Adobe收购）创建的一个专有协议，用于Flash播放器与服务器之间的流媒体音视频与数据传输，该协议也发布了面向公众使用的规范。RTMP协议本身基于TCP协议，其通用性很好。但RTMP也存在一些缺陷。首先，由于TCP作为一个可靠保序的传输协议，也带来了TCP容易导致队头阻塞的问题，即当网络中出现丢包或乱序时，如果第一个数据包发生丢失或延迟到达，后续的包即使收到也无法向上层返回，从而导致整列数据包受阻的现象。其次，由于大部分操作系统已经将TCP固化实现在内核中，且网络中也存在大量已对TCP协议具备针对性策略的设备，在实时应用中对TCP传输策略的优化会受到比较多的限制，优化方案比较少。此外，RTMP协议不支持多路复用，无法同时在一个连接中传输多个不同数据流。RTMP在传统的CDN媒体分发和直播中有着较多的应用，但更适用于延时不敏感的场景。
2）RTP/RTCP协议
RTP/RTCP作为一对孪生协议，通常搭配使用，目的是为了在IP网络的基础上提供音视频媒体数据的实时传输能力，许多流媒体、视频会议应用以及WebRTC的底层媒体传输都在使用RTP/RTCP。RTP协议基于UDP，能够根据应用的场景进行定制化的传输策略，能适用于类似于RTC的低延时场景。RTP协议本身只保证实时数据传输，并不提供可靠传输、流量控制和拥塞控制等服务质量保证，而这些由RTCP协议来提供服务。RTP/RTCP也不支持多路复用能力。
3）SRT协议
SRT是在基于UDP基础上的传输协议UDT上针对音视频实时性提出的一套协议。SRT内置了一定的弱网对抗机制，例如其包含不同的丢包重传控制消息，同时支持ACK、ACKACK、NACK等。不过虽然SRT对上层提供了一定的拥塞控制统计信息，如RTT、丢包率、发送和接收的码率等，可以让上层应用去进行更灵活的策略，但也因此缺少了独立完整的拥塞控制，内置的拥塞控制策略太简单。此外，SRT协议也不支持多路复用能力。
4）QUIC协议
QUIC是Google开发的一种基于UDP的传输层协议，原本设计用于提升Web应用的网络连接速度与可靠性，用以取代目前互联网基础设施中广泛使用的TCP协议。由于其拥有连接快、具备多路复用、优先级管理和防队头阻塞、可插拔的拥塞控制等多个优点，目前也被一些厂商用于音视频传输，用于解决类似原先RTMP协议在TCP协议基础上遇到的问题，例如业界部分CDN厂商提供了RTMP over QUIC的能力。不过QUIC作为一个通用的传输层TCP协议替代的目的出现，协议大而全，其默认策略并不适用于实时通信RTC场景，针对RTC场景需要去专门的调校和优化。另外原生的QUIC协议作为一个可靠协议也不提供实时非可靠数据流的传输支持，不过目前也有相关的标准化工作正在为QUIC添加不可靠传输的扩展。
5）专有RTC协议
一些RTC云服务厂商也有针对RTC场景专门设计相应的传输协议，由于RTC实时场景的业务特点，通常此类传输协议都基于UDP协议打造，从而能够更容易针对RTC场景进行相关传输策略的适配。例如声网的RTC服务内置了其自研的AUT协议，该协议能在一个连接上同时支持不同可靠性、吞吐量、优先级的不同类型数据，能够支持多路复用与优先级管理，并提供准确的网络质量评估与丰富的自适应拥塞控制算法。不过此类协议由于未私有协议，通常需要通过集成相关云服务厂商的开发包（SDK）才能获得相关的特性。