爲什麼RTP使用UDP而不是TCP？

Question

我想知道爲什麼UDP在RTP而不是TCP中使用？主要的VoIP工具只使用UDP，因爲我侵入了一些VoIP OSS。

Answer 1

正如DJ指出的那樣，TCP是要獲得可靠的數據流，並且會減慢傳輸速度，並重新傳輸損壞的數據包，以實現這一目標。

UDP不關心通信的可靠性，也不會減慢或重新傳輸數據。

如果您的應用程序需要可靠的數據流，例如，從Web服務器檢索文件，請選擇TCP。

如果您的應用程序不關心損壞或丟失的數據包，並且您不需要額外開銷以提供額外的可靠性，則可以選擇UDP。

可靠的數據包傳輸並未顯着改善VOIP，事實上，在某些情況下，TCP中的情況如重傳和指數退避實際上可能會影響VOIP質量。因此，UDP是一個更好的選擇。

Answer 2

UDP通常用於各種類型的實時流量，不需要嚴格的排序即可使用。這是因爲TCP在將數據傳遞給應用程序之前強制執行排序（默認情況下，您可以通過設置URG指針來解決此問題，但似乎沒有人會這麼做），並且在您希望的環境中而是獲取當前的實時數據，而不是可靠地獲取舊數據。

Answer 3

RTP對數據包丟失相當不敏感，所以它不需要TCP的可靠性。

UDP的頭部開銷較小，因此一個數據包可以承載更多的數據，因此可以更高效地利用網絡帶寬。

UDP也提供了快速的數據傳輸。

因此UDP在這種情況下是明顯的選擇。

Answer 4

UDP用於任何發送數據，不需要在目標上準確接收，或者不需要穩定連接的地方。

如果需要準確接收數據，按位，不丟失位，則使用TCP。

對於視頻和聲音流，在路上丟失的某些位不會影響結果的方式，這是值得一提的，某些像素在流的圖片中失敗，沒有任何影響用戶，在DVD上丟失比特率更高。

Answer 5

了很多很好的答案已經給出，但我想指出一點了明確：

基本上是一個完整的數據流是有實時音頻/視頻一件好事，但其並非嚴格必要（正如其他人所指出的那樣）：

重要的事實是，一些到達太晚的數據是毫無價值的。應該在第二天之前顯示的幀的丟失數據有什麼好處？

如果您要使用TCP（它也保證所有數據的正確順序），那麼您將無法獲取更新的數據，直到舊的數據正確傳輸。這是一個非常糟糕的情況：您必須等待重新傳輸舊數據和新數據（現在已經延遲）可能會毫無價值。

因此RTP做了某種盡力傳輸，因爲它試圖及時傳輸所有可用數據，但不會嘗試重新傳輸在傳輸（*）過程中丟失/損壞的數據。它只是繼續生活，並希望更重要的當前數據正確地到達那裏。

（*）其實我不知道RTP的細節。也許它確實嘗試重新傳輸，但是如果確實如此，它就不會像TCP那樣具有侵略性（它永遠不會接受任何丟失的數據）。

Answer 6

除了所有其他人以外，正確的答案this article可以很好地理解TCP和UDP之間的區別。

Answer 7

其他人是正確的，但是並沒有真正告訴你真正的原因。 Saua提示它，但這是一個更完整的答案。

音頻和視頻是實時的。如果您正在收聽收音機，或收看電視，並且信號被中斷，那麼它就不會在您離開的地方繼續播放。您只是在信號流動時「觀察」信號，並且如果您無法觀察它在任何時候都會失去它。

原因，很簡單。延遲。 VOIP非常努力地儘量減少從某人說話到某一端的時間延遲，並且在您結束時得到它，並且您的響應回來。否則，當發生錯誤時，人們說話的時間與接收到信號的時間之間的延遲量將持續增長，直到它變得毫無用處。請記住，每次從重傳延遲都必須重播，並導致進一步的數據被延遲，然後另一個錯誤會導致更大的延遲。唯一可行的解​​決方案是簡單地刪除任何無法實時顯示的數據。

從重傳延遲1秒將意味着它現在將從我說的東西到聽到它的時間爲1秒。現在，第二秒的延遲意味着它從我說的事情開始到聽到它爲止的時間爲2秒。這是累積的，因爲數據以相同的速度播放，等等。

RTP可能是面向連接的，但它必須刪除（或跳過）數據才能跟上無論如何，重傳錯誤，所以爲什麼要打擾額外的開銷？

Answer 8

只是說了一句話： 在RTP流中發送的每個數據包被賦予比其前一個更高的數字。這允許thr目標確定是否有數據包丟失。 如果數據包正在發送，目標服務器的最佳操作是通過插值來近似缺少的值。 重新分配不是一個有效的選擇，因爲重新發送的數據包太遲而無法使用。

Answer 9

我想快速添加到馬特H迴應斯托博爾的答案時說。馬特H提到UDP數據包上的RTP可以進行校驗，這樣如果它們被破壞，它們將會被重新發送。這實際上是大多數PBX上的可選功能。在星號，例如，你可以用下面這行啓用/在你的RTP在UDP流量rtp.conf配置文件中禁用校驗：

rtpchecksums=yes ; or no if you prefer 

乾杯！

Answer 10

技術上說，RTP包可以通過TCP連接進行交織。這裏給出了很多很好的答案。另外兩個小點：

RFC 4588描述瞭如何使用RTP數據重傳。大多數接收RTP流的客戶端都會使用緩衝區來解決網絡中的抖動，通常爲1-5秒，這意味着有足夠的時間用於重新傳輸以接收所需的數據。

RTP流量可以通過TCP連接進行交織。在實踐中，當完成時，Interleaved RTP（即，通過TCP）和通過UDP發送的RTP之間的區別在於這兩者如何在用戶可用帶寬不足的有損網絡上執行。隨着播放器不斷等待數據包到達緩衝狀態，Interleaved TCP流將最終變得不穩定。根據玩家的不同，它可能會提前趕上。通過RTP連接，您將在視頻中看到僞影（拖尾/撕裂）。