RTSP over TCP部分浅谈

RTSP Over Tcp-RFC2326

这周因为工作上的需要，查看了一些有关RTSP的一些知识，看的不算深，对RTSP也就算是初识吧，很多东西也是在摸索中学习，因为意外翻看了下rfc中的部分说明，加上对tcp的一点了解，又看到网上对这个的说明不是很多，所以想把这点记录一下，也算日后翻看有个参照吧。先贴一段rfc的原文。

If a reliable transport protocol is used to carry RTSP, requests MUST
NOT be retransmitted; the RTSP application MUST instead rely on the

underlying transport to provide reliability.

If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, it is possible that each packet
loss results in two retransmissions. The receiver cannot typically
take advantage of the application-layer retransmission since the

transport stack will not deliver the application-layer retransmission

before the first attempt has reached the receiver.

If the packet loss is caused by congestion, multiple

retransmissions at different layers will exacerbate the congestion

1. 这段话是rfc2326 9.6节的部分内容，讲了一些和rtsp可靠性的相关内容，其中rfc指出，当rtsp使用可靠的传输协议时，请求不允许被重传，rtsp应用必须代替底层传输层来提供可靠性。
2.  为什么要规定这个机制呢？ 按照rfc的解释是，如果底层使用了例如tcp这样的可靠传输协议，并且rtsp应用也重传请求的话，那么每个包的丢失都会导致两次重传，那么接收者通常无法发挥应用层重传的优势因为运输协议栈在第一次尝试到达接收者前不会处理应用层重传。如果丢包由拥塞造成，那么在不同层进行多次重传会加重拥塞。

之上大概是对rfc的一个简单的翻译，也可能有不准确的地方，下面说下我对这段话的理解。

• 首先，来说下应用层重传这个问题，一开始我不理解既然tcp这样的运输层协议已经提供了可靠性传输，为什么还要在应用层进行这样的一个看似画蛇添足的动作，我在网上也查看了一些帖子，最后找到了这个比较信服的答案，那就是尽管tcp可以保证报文正确可靠的交付给对端运输层，但不能保证上层应用可以正确处理或者说已处理了这段数据，因为可能有应用崩溃的情况发生，这样发送者确实受到对端的ACK，但其实并不知道对端应用已崩溃，那么从逻辑处理上来说，这个过程是不完整的，因为数据其实并没有被正确的处理，那么就需要应用层来保证这些逻辑的正确性；同时，一些重要的数据也需要应用层进行及时的确认和处理。

• 那么，怎么理解两次重传，根据rtsp请求的方式，当一个请求发出而未收到回应的时候，客户会再次发送请求，而有可能在此之前，运输层也因为迟迟没有收到ack而进行过了重传，那么就是说这次的丢包其实产生了两次的重传，一次是运输层，一次的应用层，这也就是rfc上说的当rtsp底层使用像tcp这样的可靠的协议时，要将底层的重传请求屏蔽掉，不然多次的重传在拥塞的情况下会更加加重网络的拥塞，导致更多的丢包和重传，加重整个网络负担。

• 其中有句话很难理解，我进行了高亮，什么意思呢，我是这样理解的，假如发生了丢包，好的，运输层在不停的尝试重传这个丢失的包给对端，但仍迟迟没有回应，知道应用层也意识到发生了请求的丢失，好的，应用意识到应该重发一遍请求，那么这个请求到了传输层发生了什么呢，除非之前的那次尝试已到达对端，那么这个新的应用层重传包是不会被发出去的，因为传输层一直在忙着传那么丢了的包，这也就是说其实应用层重传变成了一个重复的动作，因为这样当网络恢复正常，接收者会受到两个请求，而旧的那个会被新的覆盖掉。

这从整体上来看会导致应用的效率问题，尤其是当网络环境不好的时候，就更加明显。如果哪里描述的有问题，或者理解有偏差，或者补充的地方，还请无意看到这篇文章的童鞋么帮助纠正，谢谢。