以下自言自語烹笔，提建議感激不盡裳扯，挑毛病我就不聽
UDP與TCP
UDP是個協議。谤职。饰豺。
TCP也是個協議。允蜈。冤吨。
那么這兩個協議之間的區(qū)別是什么呢？曾經我被問到這個問題饶套，就開始眉飛色舞地侃侃而談漩蟆。“UDP就像是個廣播喇叭凤跑，遵循UDP的數據報發(fā)送后爆安，是無連接的叛复，任何接收端都可以收到仔引；UDP又是不可靠的，為什么褐奥？廣播喇叭里的話咖耘，不是誰都聽得見的。TCP是面向連接的撬码，就像是兩個人打電話一樣儿倒，也是可靠的。。夫否〕估纾”
今天重溫TCP與UDP，雖然理解的還是不怎么透徹凰慈，但是相比以前汞幢，總算是有了進步，記錄下來微谓。
UDP
UDP是傳輸層協議森篷。傳輸層協議所需要做的工作很多，但是UDP卻做了其中最少的工作豺型。UDP得的要傳輸的數據以后仲智，僅僅在數據的原有基礎上，附加了目的端口號姻氨，以及其他兩個小字段钓辆。然后這個極其簡陋的數據報文段就被發(fā)出去了。在這個過程中肴焊，UDP并沒有要求發(fā)送方和接收方彼此先認識認識岩馍，握個手什么的完全沒做，因為這個抖韩，UDP被稱為是無連接的蛀恩。
緊接著，根據以上原理茂浮，可以記錄用UDP的優(yōu)勢：
其一双谆，時間控制精確。怎么精確了席揽？畢竟UDP拿到數據后顽馋，就只是給數據加上個端口號，就“嗖”的一下幌羞，把數據報文段發(fā)出去嘍寸谜！沒耽擱時間啊属桦！對于那種對數據何時發(fā)送很看重的主兒熊痴，這是至關重要的啊聂宾！相比于TCP果善，省去了握握手、等等人的環(huán)節(jié)系谐，時間已經很精確了巾陕。當然了，是有可能數據沒送到，也是有可能數據送到不完整鄙煤，怕這些你別用啊晾匠。。梯刚。
其二混聊，無需建立連接。這點就是上面加黑的字體乾巧，無連接的句喜。那有什么優(yōu)勢呢？建立連接需要時間沟于，需要資源啊咳胃。倆人先認識認識握個手不得需要點時間嗎？就算是壓馬路還對鞋子有磨損呢旷太，何況現在倆人見面都需要喝個咖啡廳什么的展懈，高消費，耗資源肮╄怠存崖！
其三，沒有連接狀態(tài)（WTF睡毒？都不用建立連接了来惧，自然沒有連接狀態(tài)了）。連接狀態(tài)需要維護很多號啊演顾、參數什么的供搀，不寫了，寫了也記不住钠至。由此可見葛虐，沒有連接狀態(tài)是很大的優(yōu)勢。
其四棉钧，開銷小屿脐。每個TCP報文段的首部開銷為20字節(jié)，每個UDP報文段的首部開銷為8字節(jié)宪卿。
TCP
面向連接的運輸的诵，TCP。
序號（Seq）和確認號（ACK）愧捕。這倆個號在TCP報文段中可是很拽的奢驯。為什么他倆這么拽呢申钩，因為沒有他倆不行次绘。。。數據是由很多報文段運送的邮偎，每個報文段都有自己的序號管跺，并且整體來看，這個序號是遞增的且獨一無二的禾进。比如第一個報文段序號是0豁跑，第二個是1000，第三個是2000泻云。艇拍。。沒錯宠纯，是遞增卸夕，未必是差值為1的等差數列。人之立于世婆瓜，必循其規(guī)快集。有個序號，大家都按照序號來廉白，公平公正公開个初，誰也沒偏袒，有效避免了爭斗猴蹂，維護了世界和平院溺，看吧，序號就是這么有用磅轻，就是這么拽覆获！那確認號呢？確認號是接受端返回給發(fā)送端的瓢省，這個號代表了序號弄息，就是下一個可以發(fā)過來的報文段的序號。比如確認號是2000勤婚，那發(fā)送端如果是個遵紀守法的好公民摹量，就得發(fā)序號是2000的報文段，所以確認號也很拽啊馒胆。
A：seq=22缨称，ACK=15，data=‘wtf’——>B祝迂；B：seq=15,ACK=22+1=23,data=‘wtf’——>A睦尽；A：seq=23，ACK=15+1=16——>B
TCP的連接管理型雳。TCP是個靠譜的講究人当凡。介紹客戶端和服務端相互認識山害，要讓他們首先握手，然后握手沿量，最后握手浪慌。握手的時候，怎么也得做點什么吧朴则，第一次握手的時候啊权纤，客戶端把提前準備的特殊報文段給服務端。這個特殊報文段里有SYN乌妒，所以就被大眾稱為SYN報文段汹想。SYN報文段除了有SYN，還有客戶端隨機生成的一個初始序號（client_isn）撤蚊，沒錯欧宜，是序號，很拽的序號拴魄。
第二次握手了冗茸，服務端拿到了客戶端的SYN報文段了，想了半天才反應過來匹中，這得表示表示跋氖！就也發(fā)了一個有SYN的報文段顶捷，同時挂绰，客戶端的SYN報文段里有序號啊服赎！序號葵蒂！需要確認號呀！服務端就給客戶端的序號加一重虑，然后做確認號了践付，ACK！最后缺厉，也帶上了一個自己的序號永高。這個報文段叫做SYNACK報文段馁害。
第三次握手的時候激挪，客戶端拿到了服務端的SYNACK報文段，一看這事有門啊周荐，就不客氣啦辐脖，直接帶上了序號和確認號饲宛，去建立連接了。
斷開連接的過程中嗜价，更加體現了TCP的講究之處艇抠，四次告別幕庐！足足四次！首先客戶端發(fā)了個FIN說要斷開鏈接了练链，然后等服務端消息翔脱，這叫FIN_WAIT_1奴拦，服務端收到后返回一個ACK說我知道了媒鼓。這時候，講究這個特性就提現出來了错妖÷堂客戶端這時候不走，人家進入等待暂氯，叫做FIN_WAIT_2潮模，收到服務端的FIN后，給服務端返回一個ACK痴施，更講究的是擎厢，這時候了，還不走辣吃《猓客戶端進入TIME_WAIT階段，等個1分鐘或者30秒的才緩步離開神得。
與此同時的服務端厘惦，一聽說客戶端要走，為了不耽誤客戶端的時間哩簿，趕緊接受FIN并且返回ACK宵蕉，然后服務端也很講究啊，進入等待階段节榜，這個階段叫做CLOSE_WAIT羡玛，服務端在這個階段發(fā)送了FIN，等著接受客戶端返回的ACK宗苍，然后就斷開連接了缝左。
最后我就想了啊，這TCP這么講究干什么芭ㄈ簟渺杉？難道就是為了講究才講究的嗎？這個時候挪钓，搜索引擎的強大實力顯露無遺是越。
講究的三次握手原因：謝希仁版《計算機網絡》中的例子是這樣的，“已失效的連接請求報文段”的產生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失碌上，而是在某個網絡結點長時間的滯留了倚评，以致延誤到連接釋放以后的某個時間才到達server浦徊。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后天梧，就誤認為是client再次發(fā)出的一個新的連接請求盔性。于是就向client發(fā)出確認報文段，同意建立連接呢岗。假設不采用“三次握手”冕香，那么只要server發(fā)出確認，新的連接就建立了后豫。由于現在client并沒有發(fā)出建立連接的請求悉尾，因此不會理睬server的確認，也不會向server發(fā)送數據挫酿。但server卻以為新的運輸連接已經建立构眯，并一直等待client發(fā)來數據。這樣早龟，server的很多資源就白白浪費掉了惫霸。采用“三次握手”的辦法可以防止上述現象發(fā)生。例如剛才那種情況葱弟，client不會向server的確認發(fā)出確認壹店。server由于收不到確認，就知道client并沒有要求建立連接翘悉∶４颍”
來源：知呼，作者：做好自己
講究的四次揮手是因為TCP有個半關閉狀態(tài)妖混，假設A.B要釋放連接老赤，那么A發(fā)送一個釋放連接報文給B，B收到后發(fā)送確認制市，這個時候A不發(fā)數據抬旺，但是B如果發(fā)數據A還是要接受，這叫半關閉祥楣。然后B還要發(fā)給A連接釋放報文开财，然后A發(fā)確認，所以是4次误褪。
來源：百度知道责鳍，作者：yehua131969
