傳輸速度快，tcp 3次握手後建立連線 終止需要4次握手
沒公網ip、做nat穿透
需要更高的頻寬搶占能力
解決高延遲高丟包下、頻寬利用率低問題
連線頻繁變動。如手機經常更換基站
高實時 延遲<1s
準實時1~3s
偽實時》3s
資料量大，不需要高實時，可以推遲重傳時間
通訊雙方無法直接連線（ip、埠被封、連線干擾、nat等），可通過**對通訊鏈路進行重新構建；
通訊雙方直接通訊效能差，可通過**加速
可以在丟包處理、流量控制、擁塞控制、資料統計、狀態反饋、狀態反饋、流量偽裝、路徑優化等方面
rudp
rtpudt
消極重傳
激進重傳
主要為了防止報文丟失或者阻塞。當a向b傳送報文時，就會啟動重傳定時器，若在定時器到達之後，仍沒有收到b的確認報文，則a會重新傳送上次傳送的報文。同時，令重傳定時器復位。繼續計時。
當b向a傳送了0視窗報文，b此時已經沒有空間接受a傳送的資料了，通知a停止傳送。a在收到後即停止傳送，等待一段時間後，b有了一些空間，可以繼續接收了。此時再向a傳送非0視窗報文。如果此非0視窗報文在網路中阻塞或者丟失了,那麼a將永遠以為b沒有空間接收資料，b也永遠在等待a發來的資料。這樣就會造成死鎖的局面。
在a接收到b傳送的0視窗報文後，就設立堅持定時器，當定時器到達後，a就像b傳送乙個探測報文。b收到探測報文後會給出a確認報文。
應用場景：客戶機因為某些故障退出，而伺服器並不知道，還在一直等待客戶機發來的資料，這樣就白白浪費了計算機資源。
在伺服器端設定保活計時器，伺服器每收到客戶機的一次訊息，就重置保活計時器，時間通常為2小時。若2個小時都沒有收到客戶機發來的訊息，伺服器就像客戶機傳送乙個探測報文，以後每隔75分鐘傳送一次。若連續傳送了10個探測報文後客戶機仍無響應，則伺服器就會認為客戶機故障，並斷開這次連線。
時間等待及時器用於tcp「四次揮手」階段。當客戶端向伺服器傳送最後一次確認報文時，就設定乙個時間等待及時器，等待2msl時間後再結束連線。
msl：最長報文段壽命，大小為30s~2分鐘。根據不同的應用有不同的設定。
①為了保證伺服器能夠收到客戶機傳送的最後乙個確認報文。
因為這個最後報文可能丟失，伺服器收不到客戶機的確認資訊，就無法進入closed狀態。就會在重傳定時器到達後重新傳送上一次的報文（此時會重置時間等待計時器，再次等待2msl時間），這樣客戶機在等待2msl時間過程中就可以收到這個重傳報文，並重新傳送確認報文。
②防止出現「已失效的連線請求報文」再次出現的情況。
客戶機在等待的這2msl時間中，就可以使此次連線的所有報文都從網路中消失，這樣在下一次新的連線中就不會出現舊的連線請求報文。
**：注意：在伺服器傳送了fin-ack之後，會立即啟動超時重傳計時器。客戶端在傳送最後乙個ack之後會立即啟動時間等待計時器。
參考：參考：
提公升：參考：
在丟包率25%下tcp已經沒有傳輸能力
rtt：來回通訊延遲
rto：根據rtt計算出重傳超時時間
bandwidth：網路頻寬
mss：最大分段大小（有效資料部分大小）
傳輸超時或者tcp重傳定時器溢位
接收到重複的確認報文
參考：20%
統計資訊：
頻寬rtt
丟包率接收端埠
擁塞演算法及引數
Android Socket基於UDP傳輸
接收方建立步驟 1.建立乙個datagramsocket物件，並指定監聽的埠號 datagramsocket socket new datagramsocket 4567 2.建立乙個byte陣列用於接收 byte data new byte 1024 3.建立乙個空的datagrampackage...
C 基於Udp的分包傳輸
因為要遠做程攝像頭監控，要用到網路資料傳輸，了一下，很多就是基於tcp的，因為qq是用udp，所有我也嘗試用udp。要用udp傳輸資料，就免不了分包和重包，因為udp最大只能傳輸64kb的資料！下面給出分包的 首先定義乙個包類 using system using system.collection...
基於UDP的檔案傳輸軟體 C
完成乙個區域網內的基於udp的檔案傳輸系統，該軟體有客戶端與服務端，服務端繫結ip 埠，監聽接收檔案的訊息，客戶端連線服務端，向其傳送選中檔案，傳送檔案過程中允許兩端終端檔案傳輸。同時需要支援多個客戶端的檔案傳送。附兩張老師需求文件中介面的截圖 在專案要求和中把很多點都列舉出來了，這裡列個表 基於u...