這個問題看似很難解釋，但是通過多年研究，測試，總結出以幾個看法，其他同學如果覺得不妥當，可以補充。
要解釋好這個問題，首先我們分析一下TCP,TCP相信很多人已經比較熟悉，因爲介紹使用及原理的文檔太多了，但是相當一部分人，就算是網絡編程很好的IT從業者，也不太清楚，原因主要都是停留在應用層，沒有深入理解TCP設計的原理，歷史及他的目的。
TCP基於IP協議上實現了可靠傳輸，所以，他發送的數據都是一個個小的IP包，IP包的大小取決於各種設備的MTU.
網關，路由設備完成，分包，組包，及校驗工作。這些和我們的主題無關，可以忽略，大家可以參靠相關內容。TCP出於友好性及算法上的一些歷史實現原因，協議在設計上有很多不是非常精確控制的地方，雖然後面有很多改進，選擇性重傳，快速重傳和恢復，包括SACK選項等。但是這些改進也不能完全解決，現在網絡的問題。
對於高延遲及高丟包的環境，TCP在重傳方面，顯得很乏力。主要原因是，當丟包產生後，需要通過2個ACK觸發快速重傳和快速恢復，顯然，耽誤了二個往返時間(RTT)
另外，當丟包時，發送速度會很快的遞減，最主要的是折半法，雖然當有新的ACK到達時，可以快速恢復到歷史窗口，但是這一機制在很多情況下，不能湊效。
超時重傳，更是TCP的最大問題，超時計算是指數退避算法，也就是說，先前可能是等待一個RTT重傳，但是，當第二次，第三次重傳時，可能是要等待幾秒鐘以後，或幾分鐘或更長時間，顯然，這對代寬是大大的浪費。
通過上面的分析，我們知道了問題的關見，當然就知道如何改進了。這些很多人，很多學者已經想到了，就出現了各種TCP的加強版本。
但是由於TCP的包格式及協議的歷史問題，在老的框架下，要變動起來非常不容易，包括要兼容以往的TCP.
UDX是在UDP協議上實現的一種可靠協議，在原理的本質上和TCP是完全一樣的。一個是基於IP,一個是基於UDP,當然他們都是IP之上，爲了從邏輯上區分，我們可以暫且認爲差不多吧。
我們知道了問題的原因，針對這種情況，我們主要改進了，重傳，恢復及ACK方式。重要改進是，我們在重傳策略上基本沒有超時重傳的說法，我們可以在理想情況下，只需要一個RTT+最近二個包之間的發送間隔時間，就可以確定哪個包需要重傳。
這是對實時性最大的性能提升，是TCP完全不具備的。
在應答方面，我們也有改進，不再等相同的ACK序號，而是改用發送序號差值（這個有點複雜，可能難以理解，你可以理解爲一種全新方式）來確定重傳，包括ACK被償，這些機制增強ACK的能力。
我們對應答ACK也作了處理，能應答更多的包，不象TCP的SACK選項，也最多能支持四組序號。
在發送流程上，我們也是非常均勻的發送，保證，投遞到網絡設備的均勻性，這樣從概率上來說，成功發送的機率會增大很多。
實際測試數據，怎麼樣呢？如下圖
結論：
在高延遲>50ms,丟包率>1%的情況下，比其他協議tcp,或類似UDP可靠協議,或軟件iperf,fbench在吞吐量，實時性上有顯著優勢
在視頻傳輸中，目前主流的傳輸方法，還是RTP，甚至是一些某些行業的標準都是RTP,RTP的實時性當然是最好的，但是，大家忽略了一點----丟包。
在大多數行業內的人認爲，視頻丟點數據並不重要，在某些場合確實是這樣，屏目花一下也無所謂，比如現在的公交系統，我們在乘坐BUS時，確實有時會看到有些廠家的視頻設備畫面會卡死，在信號不好的路段。但是信號一但好起來，又流暢起來。
而今天的行業竟爭激烈，大家都要求設備能提供良好的服務質量，如果你們家的設備出現花屏，而別人家的沒有，那麼你的產品就大打折扣了。
這會又有人說了，直接用TCP,確實目前主流的監控廠家在外網上都還是採用的TCP,而我提出這個新協議是對現有行業的一種激進，多一種選擇。
通過這些增強，那這個協議能做啥呢？
1，實時性---》視頻監控，遠程控制，白板，IM等。
2，吞吐量---》文件傳輸，特別是跨國之間，大數據傳輸等。
3.流量穩定---》可用於無線wifi,3g系統的數據傳輸，實時性，吞吐量都會比其他協議有明顯改善。
先拋幾塊磚，希望引出一些雞蛋，蘿蔔扔過來。
歡迎討論，比較，共同進步！
更多瞭解，請訪問我的個人網站www.goodudx.com,下載實現的可執行程序。