緣起
1、什麼是一對一 什麼是一對多？
2、tcp爲什麼是三次握手四次揮手？爲什麼不是別的次數
3、每次握手和揮手都是做了什麼操作？
4、爲什麼HTTP是基於tcp的 可以基於udp麼？
5、什麼是連接？爲什麼tcp是面相連接的udp則不是？
連接是什麼？
是爲了在客戶端和服務端維護連接，而建立一定的數據結構來維護雙方交互的狀態，
用這樣的數據結構來保證所謂的面向連接的特性
三次握手
四次揮手
建立連接有什麼特徵表現？
1、tcp是面向字節流的，沒頭沒尾，這也是導致粘包和拆包的問題，udp是發送ip包
2、tcp支持擁塞控制，會根據網絡情況去調整自己的發送行爲
3、tcp是有狀態的服務 會標記是否發送和是否接受，udp則是無狀態的，不知道是否接受到了，
4、TCP提供可靠交付。通過TCP連接傳輸的數據，無差錯、不丟失、不重複、並且按序到達。我們
都知道IP包是沒有任何可靠性保證的，一旦發出去，就像西天取經，走丟了、被妖怪吃了，都只能隨它
去。 而 UDP繼承了IP包 的特性，不保證不丟失，不保證按順序到達。
udp使用的場景
概覽
-
需要資源少，在網絡情況比較好的內網，或者對於丟包不敏感的應用
-
不需要一對一溝通，建立連接，而是可以廣播的應用
UDP的不面向連接的功能，可以使得可以承載廣播或者多播的協議。DHCP就是一種廣播的形式，就是
基於UDP協議的
-
需要處理速度快，時延低，可以容忍少數丟包，但是要求即便網絡擁塞，也毫不退縮，一往無前的時候
具體例子
- QUIC （全稱 Quick UDP Internet Connections**，快速UDP互聯網連接）是Google提出的一種基
於UDP改進的通信協議，其目的是降低網絡通信的延遲，提供更好的用戶互動體驗。QUIC在應用層上，會自己實現快速連接建立、減少重傳時延，自適應擁塞控制
-
流媒體的協議
直播協議多使用RTMP，而這個RTMP協議也是基於TCP的。TCP的嚴格順序傳輸要保證前一個收到了，下一個才能確認，如果前一個收不到，下一個就算包已經收到了，在緩存裏面，也需要等着。對於直播來講，這顯然是不合適的，因爲老的視頻幀丟了其實也就丟了，就算再傳過來用戶也不在意了，他們要看新的了，如果老是沒來就等着，卡頓了，新的也看不了，那就會丟失客戶，所以直播，實時性比較比較重要，寧可丟包，也不要卡頓的。另外，對於丟包，其實對於視頻播放來講，有的包可以丟，有的包不能丟，因爲視頻的連續幀裏面，有的幀重要，有的不重要，如果必須要丟包，隔幾個幀丟一個，其實看視頻的人不會感知，但是如果連續丟幀，就會感知了，因而在網絡不好的情況下，應用希望選擇性的丟幀。還有就是當網絡不好的時候，TCP協議會主動降低發送速度，這對本來當時就卡的看視頻來講是要命的，應該應用層馬上重傳，而不是主動讓步。因而，很多直播應用，都基於UDP實現了自己的視頻傳輸協議。
-
實時遊戲
遊戲有一個特點，就是實時性比較高。快一秒你幹掉別人，慢一秒你被別人爆頭，所以很多職業玩家會
買非常專業的鼠標和鍵盤，爭分奪秒。
因而，實時遊戲中客戶端和服務端要建立長連接，來保證實時傳輸。但是遊戲玩家很多，服務器卻不
多。由於維護TCP連接需要在內核維護一些數據結構，因而一臺機器能夠支撐的TCP連接數目是有限
的，然後UDP由於是沒有連接的，在異步IO機制引入之前，常常是應對海量客戶端連接的策略。
另外還是TCP的強順序問題，對戰的遊戲，對網絡的要求很簡單，玩家通過客戶端發送給服務器鼠標和
鍵盤行走的位置，服務器會處理每個用戶發送過來的所有場景，處理完再返回給客戶端，客戶端解析響
應，渲染最新的場景展示給玩家。
如果出現一個數據包丟失，所有事情都需要停下來等待這個數據包重發。客戶端會出現等待接收數據，
然而玩家並不關心過期的數據，激戰中卡1秒，等能動了都已經死了。
遊戲對實時要求較爲嚴格的情況下，採用自定義的可靠UDP協議（🤔 udp不是需要建立連接的嗎），自定義重傳策略，能夠把丟包產生的延遲降到最低，儘量減少網絡問題對遊戲性造成的影響
-
IOT 物聯網
一方面，物聯網領域終端資源少，很可能只是個內存非常小的嵌入式系統，而維護TCP協議代價太大；
另一方面，物聯網對實時性要求也很高，而TCP還是因爲上面的那些原因導致時延大。Google旗下
的Nest建立Thread Group，推出了物聯網通信協議Thread，就是基於UDP協議的
-
移動通信領域
在4G網絡裏，移動流量上網的數據面對的協議GTP-U是基於UDP的。因爲移動網絡協議比較複雜，
而GTP協議本身就包含複雜的手機上線下線的通信協議。如果基於TCP，TCP的機制就顯得非常多餘，
-
UDP沒有服務端和客戶端的概念
參考
https://mp.weixin.qq.com/s/iQgqmCJp9FBqgxbgJ7wHJg
參考
http://www.52im.net/thread-560-1-1.html
極客時間趣談網絡協議