1.tcp面向連線（三次握手建立）；udp發資料前無需建立連線
2.tcp可靠傳輸（原理在下面）；udp不保證資料可靠性；
3.tcp面向位元組流；udp面向報文，無擁塞控制，資料傳送速率高；
4.tcp只支援點到點；udp支援多對多，一對多等通訊；
udp如何去實現可靠傳輸？參考以下tcp的結構，①引入序列號，保證資料順序；②引入確認機制，保證對端收到了資料；③引入超時重傳，如果隔一段時間沒有應答，就重新傳送資料。
出現差錯或丟失的時候，傳送方會將自己備份的副本再重傳一次，直到收到接收的確認資訊；當接收方收到重複的資料時，會直接丟棄，但是會給傳送方請確認自己已經收到了。
為啥要流量控制：接收方應用程式讀取資料的速度小於傳送方的資料傳送速度，將導致接收方的接收快取溢位，造成資料丟失；
滑動視窗如何進行流量控制:接收端會在確認應答傳送ack報文時，將自己的即時視窗大小填入，並跟隨ack報文一起傳送過去。而傳送方根據ack報文裡的視窗大小的值的改變進而改變自己的傳送速度。如果接收到視窗大小的值為0，那麼傳送方將停止傳送資料。比如視窗大小值不為0了，傳送方將重新開始傳送資料；
傳送視窗:
接收視窗：
採用累積確認機制：傳送方不對收到的分組逐個傳送確認，而是對按序到達的最後乙個分組傳送確認，這樣表示：到這個分組為止的所有分組都已正確收到了。
何時會出現擁塞：資料傳輸過程中，網路中擁堵的情況，資料報可能會丟失，大量的超時重傳繼續影響傳輸出現阻塞；
如何解決：慢開始、擁塞避免、快重傳和快恢復；
慢開始：
先傳送少量資料探探路，定義了乙個擁塞視窗（初始為1），每次收到乙個ack應答（每經過乙個rtt往返時間），擁塞視窗加 1；在每次傳送資料前，根據之前傳送視窗取擁塞視窗與接送段接收視窗進行比較，選擇較小者作為實際傳送視窗大小；
擁塞避免：
因為擁塞視窗增長是指數級別的，為了控制增長速度，設定了乙個擁塞視窗的閾值；當擁塞視窗大小超過閾值時，不能再按照指數來增長，而是線性的增長；慢啟動剛開始時閾值等於擁塞視窗最大值，一旦造成擁塞發生超時重傳，慢啟動的閾值會為原來的一半，同時擁塞視窗重置為 1；
快重傳和快恢復(frr)：
有了 frr，如果接收機接收到乙個不按順序的資料段，它會立即給傳送機傳送乙個重複確認。如果傳送機接收到三個重複確認，它會假定確認件指出的資料段丟失了，並立即重傳這些丟失的資料段。有了 frr，就不會因為重傳時要求的暫停被耽誤。當有單獨的資料報丟失時，快速重傳和恢復（frr）能最有效地工作。當有多個資料資訊包在某一段很短的時間內丟失時，它則不能很有效地工作；
概念：mss(最大訊息長度)
在建立tcp連線的時候，雙方約定乙個最大的長度（mss）作為傳送的單位，重傳的時候也是以這個單位來進行重傳。理想的情況下是該長度的資料剛好不被網路層分塊；
幾個概念:
1.fin: 請求關閉報文
2.syn: 請求建立連線
3.ack: 確認收到
4.msl: 最大報文生存時間
第一步: 客戶端想要與伺服器建立連線, 於是向伺服器傳送syn報文請求連線.
第二步: 伺服器收到客戶端的連線請求之後, 伺服器向客戶端傳送確認報文ack及請求連線報文syn
第三步: 客戶端收到伺服器的連線請求, 向伺服器傳送確認報文ack
為什麼需要第三次客戶端向服務端傳送ack確認請求呢？
如果只有兩次握手的話，當出現網路阻塞時，客戶端傳送的連線請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收(第二次重傳請求)並確認應答，雙方便開始通訊，通訊結束後釋放連線；這個之前被a認為」失效的訊息「慢吞吞到達了b，而對於b而言，以為這是乙個新的請求連線訊息，就向a發了一次確認，而對於a而言，他認為他沒有給b再次的發訊息（上次傳送完訊息後進入closed狀態），所以a不會理睬這條確認，但是b則會一直在等待著a的訊息浪費資源；
第一次揮手:客戶端主動請求關閉，並向服務端傳送fin關閉請求；
第二次揮手:服務端收到並傳送ack確認告訴客戶端已經收到關閉請求；
第三次揮手:服務端將之前需要傳送的資料全部傳送完畢後，主動向客戶端傳送fin關閉請求；
第四次揮手:客戶端收到並傳送ack確認請求，服務端收到ack後直接關閉;而客戶端是不知道伺服器是否收到了這次ack的，客戶端這邊需要再等待2msl再進行關閉。如果2msl內沒有收到服務端重發的fin，預設服務端收到ack，則客戶端關閉；
1. 為什麼第二次跟第三次不能合併, 第二次和第三次之間的等待是什麼?:
當伺服器執行第二次揮手之後, 此時證明客戶端不會再向伺服器請求任何資料, 但是伺服器可能還正在給客戶端傳送資料(可能是客戶端上一次請求的資源還沒有傳送完畢), 所以此時伺服器會等待把之前未傳輸完的資料傳輸完畢之後再傳送關閉請求.
上邊我們說了伺服器收到了最後一次的ack報文之後就會關閉, 那客戶端是不知道伺服器是否收到了這次ack的, 所以客戶端只能在這等待,如果伺服器在"超時時間"內真的沒有收到最後一次的ack,就會重新傳送一次fin; 那麼在網路極端情況下(網路沒斷, 但是速度極慢, 需要整整1msl的時間才能把報文傳送過去),這次重發fin需要1msl的時間, 這一來一回需要的時間總和為:伺服器超時時間+1msl, 那為了保險起見,直接讓客戶端等待2msl的時間, 如果2msl之內客戶端沒有收到重發的fin, 則預設為伺服器收到了最後一次ack,此時客戶端就可以執行關閉了.
TCP和UDP及三次握手協議
10.三次握手的過程要清楚 第一次握手 建立連線時，客戶端傳送syn包 syn j 到伺服器，並進入syn send狀態，等待伺服器確認 第二次握手 伺服器收到syn包，必須確認客戶的syn ack j 1 同時自己也傳送乙個syn包 syn k 即syn ack包，此時伺服器進入syn recv狀...
TCP三次握手以及與UDP的區別
tcp 簡介 tcp是一種面向連線的 可靠的 基於位元組流的傳輸層通訊協議。tcp三次握手 第一次 客戶端傳送syn給server，客戶端進入syn sent 第二次 server傳送ack和fin給客戶端，server進入syn rcvd 第三次 客戶端傳送ack給server，雙方進入estab...
TCP 和 UDP 的區別，三次握手，四次揮手
大寫ack是確認值 acknowledgement 為1便是確認連線。小寫ack是確認編號 acknowledgement number 即接收到的上一次遠端主機傳來的seq然後 1 客戶端和服務端都有自己seq，每次請求，都是在自己上次seq請求加1 大寫ack是確認值 acknowledgeme...