TCP與UDP差異對比分析
本文原創(chuàng)，轉載請注明出處。
歡迎關注我的 簡書 待牵，關注我的專題 Android Class 我會長期堅持為大家收錄簡書上高質量的 Android 相關博文龄恋。
寫在前面：
公司在做智能硬件方向，所以使用了 TCP溺森、UDP 協(xié)議來做通信。過幾天我會整理一下兩種協(xié)議在 Android 上的使用，不過在此之前扑庞，還是想先了解一下這兩種協(xié)議有哪些異同，又有哪些值得注意的地方拒逮。本文通過對比分析 TCP 和 UDP 有哪些區(qū)別罐氨，來幫助這些比較基礎的知識點，遇到相應的問題滩援，便可以快速地解決栅隐。
建立連接方式
TCP：
說到 TCP 建立連接，相信大多數(shù)人腦海里肯定可以浮現(xiàn)出一個詞，沒錯就是--“三次握手”租悄。TCP 通過“三次握手”來建立連接谨究，再通過“四次揮手”斷開一個連接。在每次揮手中 TCP 做了哪些操作呢泣棋？繼續(xù)往下看：
上圖就從客戶端和服務端的角度胶哲，清楚的展示了 TCP 的三次握手和四次揮手。
可以看到潭辈，當 TCP 試圖建立連接時鸯屿，三次握手指的是客戶端主動觸發(fā)了兩次，服務端觸發(fā)了一次萎胰。
我們可以先明確一下 TCP 建立連接并且初始化的目標是什么呢碾盟？1. 初始化資源 2. 告訴對方我的序列號。
所以三次握手的次序是這樣子的：
1）client端首先發(fā)送一個SYN包告訴Server端我的初始序列號是X技竟。
2）Server端收到SYN包后回復給client一個ACK確認包冰肴，告訴client說我收到了。
3）接著Server端也需要告訴client端自己的初始序列號榔组，于是Server也發(fā)送一個SYN包告訴client我的初始序列號是Y熙尉。
4）Client收到后，回復Server一個ACK確認包說我知道了搓扯。
其中的 2 检痰、3 步驟可以簡化為一步，也就是說將 ACK 確認包和 SYN 序列化包一同發(fā)送給 Client 端锨推。到此我們就比較簡單的解釋了 TCP 建立連接的“三次握手”铅歼。
UDP：
我們都知道 TCP 是面向連接的、可靠的换可、有序的傳輸層協(xié)議椎椰，而 UDP 是面向數(shù)據報的、不可靠的沾鳄、無序的傳輸協(xié)議慨飘，所以 UDP 壓根不會建立什么連接。
就好比發(fā)短信一樣译荞，UDP 只需要知道對方的 ip 地址瓤的，將數(shù)據報一份一份的發(fā)送過去就可以了，其他的作為發(fā)送方吞歼，都不需要關心圈膏。
數(shù)據發(fā)送
關于 TCP、UDP 之間數(shù)據發(fā)送的差異篙骡，可以體現(xiàn)二者最大的不同之處：
TCP：
由于 TCP 是建立在兩端連接之上的協(xié)議本辐，所以理論上發(fā)送的數(shù)據流不存在大小的限制桥帆。但是由于緩沖區(qū)有大小限制，所以你如果用 TCP 發(fā)送一段很大的數(shù)據慎皱，可能會截斷成好幾段老虫，接收方依次的接收。
UDP：
由于 UDP 本身發(fā)送的就是一份一份的數(shù)據報茫多，所以自然而然的就有一個上限的大小祈匙，這個每次 UDP 發(fā)送的數(shù)據報大小由哪些因素共同決定呢？
UDP協(xié)議本身天揖，UDP協(xié)議中有16位的UDP報文長度夺欲，那么UDP報文長度不能超過2^16=65536。
以太網(Ethernet)數(shù)據幀的長度今膊，數(shù)據鏈路層的MTU(最大傳輸單元)些阅。
socket的UDP發(fā)送緩存區(qū)大小
先來看第一個因素，UDP 本身協(xié)議的報文長度為 2^16 - 1斑唬，UDP 包頭占 8 個字節(jié)市埋，IP 協(xié)議本身封裝后包頭占 20 個字節(jié)，所以最終長度為： 2^16 - 1 - 20 - 8 = 65507 字節(jié)恕刘。
只看第一個因素有點理想化了缤谎，因為 UDP 屬于不可靠協(xié)議，我們應該盡量避免在傳輸過程中褐着，數(shù)據包被分割坷澡。所以這里有一個非常重要的概念 MTU -- 也就是最大傳輸單元。
在 Internet 下 MTU 的值為 576 字節(jié)含蓉，所以在 internet 下使用 UDP 協(xié)議频敛，每個數(shù)據報最大的字節(jié)數(shù)為： 576 - 20 - 8 = 548
TCP：
我們再來談談數(shù)據的有序性。
對于 TCP 來說馅扣，本身 TCP 有著超時重傳斟赚、錯誤重傳、還有等等一系列復雜的算法保證了 TCP 的數(shù)據是有序的岂嗓，假設你發(fā)送了數(shù)據 1、2鹊碍、3厌殉，則只要發(fā)送端和接收端保持連接時，接收端收到的數(shù)據始終都是 1侈咕、2公罕、3。
UDP：
而 UDP 協(xié)議則要奔放的多耀销，無論 server 端無論緩沖池的大小有多大楼眷，接收 client 端發(fā)來的消息總是一個一個的接收。并且由于 UDP 本身的不可靠性以及無序性，如果 client 發(fā)送了 1罐柳、2掌腰、3 這三個數(shù)據報過來，server 端接收到的可能是任意順序张吉、任意個數(shù)三個數(shù)據報的排列組合齿梁。
可靠性
其實大家都知道 TCP 本身是可靠的協(xié)議，而 UDP 是不可靠的協(xié)議肮蛹。
TCP：
TCP 內部的很多算法機制讓他保持連接的過程中是很可靠的勺择。比如：TCP 的超時重傳、錯誤重傳伦忠、TCP 的流量控制省核、阻塞控制、慢熱啟動算法昆码、擁塞避免算法气忠、快速恢復算法 等等。
所以 TCP 是一個內部原理復雜未桥，但是使用起來比較簡單的這么一個協(xié)議笔刹。
UDP：
UDP 是一個面向非連接的協(xié)議，UDP 發(fā)送的每個數(shù)據報帶有自己的 IP 地址和接收方的 IP 地址冬耿，它本身對這個數(shù)據報是否出錯舌菜，是否到達不關心，只要發(fā)出去了就好了亦镶。所以來研究下日月，什么情況會導致 UDP 丟包：
數(shù)據報分片重組丟失：
在文章之前我們就說過，UDP 的每個數(shù)據報大小多少最合適缤骨，事實上 UDP 協(xié)議本身規(guī)定的大小是 64kb爱咬，但是在數(shù)據鏈路層有 MTU 的限制，大小大概在 5kb绊起，所以當你發(fā)送一個很大的 UDP 包的時候精拟，這個包會在 IP 層進行分片，然后重組虱歪。這個過程就有可能導致分片的包丟失蜂绎。UDP 本身有 CRC 檢測機制，會拋棄掉丟失的 UDP 包笋鄙。UDP 緩沖區(qū)填滿
當 UDP 的緩沖區(qū)已經被填滿的時候师枣，接收方還沒有處理這部分的 UDP 數(shù)據報，這個時候再過來的數(shù)據報就沒有地方可以存了萧落，自然就都被丟棄了践美。
使用場景
在文章最后的一部分洗贰，聊聊 TCP、UDP 使用場景陨倡。
先來說 UDP 的吧敛滋，有很多人都會覺得 UDP 與 TCP 相比，在性能速度上是占優(yōu)勢的玫膀。因為 UDP 并不用保持一個持續(xù)的連接矛缨，也不需要對收發(fā)包進行確認。但事實上經過這么多年的發(fā)展 TCP 已經擁有足夠多的算法和優(yōu)化帖旨，在網絡狀態(tài)不錯的情況下箕昭，TCP 的整體性能是優(yōu)于 UDP 的。
那在什么時候我們非用 UDP 不可呢解阅？
對實時性要求高
比如實時會議落竹，實時視頻這種情況下，如果使用 TCP货抄，當網絡不好發(fā)生重傳時述召，畫面肯定會有延時，甚至越堆越多蟹地。如果使用 UDP 的話积暖，即使偶爾丟了幾個包，但是也不會影響什么怪与，這種情況下使用 UDP 比較好夺刑。多點通信
TCP 需要保持一個長連接，那么在涉及多點通訊的時候分别，肯定需要和多個通信節(jié)點建立其雙向連接遍愿，然后有時在NAT環(huán)境下，兩個通信節(jié)點建立其直接的 TCP 連接不是一個容易的事情耘斩，而 UDP 可以無需保持連接沼填，直接發(fā)就可以了，所以成本會很低括授，而且穿透性好坞笙。這種情況下使用 UDP 也是沒錯的。
以上我們說了 UDP 的使用場景荚虚，在此之外的其他情況薛夜，使用 TCP 準沒錯。畢竟有一句話嘛曲管。
when in doubt,use TCP.
寫在后面：
本文主要是介紹概念却邓，未來會從 Android 的角度來總結 TCP 和 UDP 的使用硕糊。
