CDN协议可以采用TCP传输，也可以采用UDP传输。这取决于服务器端对于客户端之间的网络情况的判断，如果服务器认为网络条件良好，响应时间正常，且丢包率在可承受范围之内，就可以采用RTP over TCP的方式发送数据。由于TCP不会丢包（其自身具有重传机制），网络条件又好，因此客户端将获得较高的视听享受。如果服务器认为网络情况不理想，就会采用UDP协议，这可能会产生丢包，造成客户端播放过程中有马赛克等轻微体验劣化。但从整体而言，UDP传输消耗的带宽要比TCP小许多，所以一般情况下使用RTP over UDP进行传送是完全可以满足要求的，如果开展IDC业务，需要了解数据中心机房。
CDN协议对每一次资源访问建立一个会话（session），从客户端第一次请求访问对象开始，到媒体播放器送出一个“TEARDOWN”信息结束。表6-2中列举了一些与状态相关的重要方法（RTSP中很多方法与状态无关）：SETUP、PLAY、RECORD、PAUSE和TEARDOWN。
CDN协议消息由客户端到服务器的请求（Request）和由服务器到客户端的响应（Response）组成。请求和响应消息都使用RFC 822中实体传输部分规定（作为消息中的有效载荷）的消息格式。两者的消息都可能包括一行起始行、一个或多个头部域（headers）、一行表示头部域结束的空行（即CRLF前没有内容的行）和一个消息主体（message-body，可选）。
下面我们看一个实际的RTSP会话交互：
在这个例子中，Client端通过SETUP请求发起这个会话，提供需要的文件URL为rtsp：//audio.example.com/shower/audio.en/lofi，RTSP版本1.0。还指示应该在UDP上使用RTP协议进行传送，使用端口号为3056。Server端收到这个请求后，用一个RTSP应答回复。每个请求-应答组都有一个Cseq编号。随后Client 端又发起 PLAY请求，Server 应答后开始发送媒体流，最后以 Client端的TEARDOWN请求结束这次会话。 RTSP协议实际上能做的工作比这要多得多，关于RTSP协议更为详细的描述，读者可以查阅RFC 2326。
