TCP協議和UDP協議的區別

轉載：http://www.cnblogs.com/obama/p/3292335.html  做者： 曾見絕美的陽光

• 第一部分：TCP/IP相關知識點
• 對TCP/IP的總體認
• 鏈路層知識點
• IP層知識點
• 運輸層知識點
• 應用層知識點
• （這些知識點均可以參考：http://www.cnblogs.com/newwy/p/3234536.html）
• 第二部分：常見面試題
• TCP協議和UDP協議的區別是什麼
• TCP協議是有鏈接的，有鏈接的意思是開始傳輸實際數據以前TCP的客戶端和服務器端必須經過三次握手創建鏈接，會話結束以後也要結束鏈接。而UDP是無鏈接的
• TCP協議保證數據按序發送，按序到達，提供超時重傳來保證可靠性，可是UDP不保證按序到達，甚至不保證到達，只是努力交付，即使是按序發送的序列，也不保證按序送到。
• TCP協議所需資源多，TCP首部需20個字節（不算可選項），UDP首部字段只需8個字節。
• TCP有流量控制和擁塞控制，UDP沒有，網絡擁堵不會影響發送端的發送速率
• TCP是一對一的鏈接，而UDP則能夠支持一對一，多對多，一對多的通訊。
• TCP面向的是字節流的服務，UDP面向的是報文的服務。
• TCP介紹和UDP介紹
• 請詳細介紹一下TCP協議創建鏈接和終止鏈接的過程？
• 助於理解的一段話
• 兩幅圖（來源）：
• 創建鏈接：三次握手
• 關閉鏈接：四次揮手
• 三次握手創建鏈接時，發送方再次發送確認的必要性？
• 主要是爲了防止已失效的鏈接請求報文段忽然又傳到了B,於是產生錯誤。假定出現一種異常狀況，即A發出的第一個鏈接請求報文段並無丟失，而是在某些網絡結點長時間滯留了，一直延遲到鏈接釋放之後的某個時間纔到達B，原本這是一個早已失效的報文段。但B收到此失效的鏈接請求報文段後，就誤認爲是A又發出一次新的鏈接請求，因而就向A發出確認報文段，贊成創建鏈接。假定不採用三次握手，那麼只要B發出確認，新的鏈接就創建了，這樣一直等待A發來數據，B的許多資源就這樣白白浪費了。
• 四次揮手釋放鏈接時，等待2MSL的意義？
• 第一，爲了保證A發送的最有一個ACK報文段可以到達B。這個ACK報文段有可能丟失，於是使處在LAST-ACK狀態的B收不到對已發送的FIN和ACK報文段的確認。B會超時重傳這個FIN和ACK報文段，而A就能在2MSL時間內收到這個重傳的ACK+FIN報文段。接着A重傳一次確認。
• 第二，就是防止上面提到的已失效的鏈接請求報文段出如今本鏈接中，A在發送完最有一個ACK報文段後，再通過2MSL，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。

 

• 常見的應用中有哪些是應用TCP協議的，哪些又是應用UDP協議的，爲何它們被如此設計？
• 如下應用通常或必須用udp實現？
• 多播的信息必定要用udp實現，由於tcp只支持一對一通訊。
• 若是一個應用場景中大可能是簡短的信息，適合用udp實現，由於udp是基於報文段的，它直接對上層應用的數據封裝成報文段，而後丟在網絡中，若是信息量太大，會在鏈路層中被分片，影響傳輸效率。
• 若是一個應用場景重性能甚於重完整性和安全性，那麼適合於udp，好比多媒體應用，缺一兩幀不影響用戶體驗，可是須要流媒體到達的速度快，所以比較適合用udp
• 若是要求快速響應，那麼udp聽起來比較合適
• 若是又要利用udp的快速響應優勢，又想可靠傳輸，那麼只能考上層應用本身制定規則了。
• 常見的使用udp的例子：ICQ,QQ的聊天模塊。
• 以qq爲例的一個說明（轉載自知乎）

登錄採用TCP協議和HTTP協議，你和好友之間發送消息，主要採用UDP協議，內網傳文件採用了P2P技術。總來的說： 
1.登錄過程，客戶端client 採用TCP協議向服務器server發送信息，HTTP協議下載信息。登錄以後，會有一個TCP鏈接來保持在線狀態。 
2.和好友發消息，客戶端client採用UDP協議，可是須要經過服務器轉發。騰訊爲了確保傳輸消息的可靠，採用上層協議來保證可靠傳輸。若是消息發送失敗，客戶端會提示消息發送失敗，並可從新發送。 
3.若是是在內網裏面的兩個客戶端傳文件，QQ採用的是P2P技術，不須要服務器中轉。

• 第三部分：相關協議
• http協議：
• http協議比較通俗的解釋
• http協議的具體細節

 

參考1：常見的TCP/IP問題