前言

目前我們比較常用的計算機網路的體系結構為TCP/IP五層網路結構從上而下為應用層，傳輸層，網路層，資料鏈路層，物理層，今天介紹的TCP和UDP就是傳輸層的兩種協議，傳輸層來負責端到端的資料傳輸，傳輸層是通過作業系統內核實作的.

一、UDP

首先UDP是傳輸層的一種協議，先說特點：無連接， 不可靠傳輸 （不知道資料發送成功與否，和安全沒關系），面向資料報（傳輸的基本單位是資料報，一個資料報由若干個位元組組成）

首先我們先了解一下UDP報頭的結構：

可以看到UDP報文結構，第一個為源埠號能表示的范圍為（0~65535），
第二個為目的埠號，UDP通過二進制把埠號表示出來了，
接下來是UDP的長度，UDP的長度就是整個UDP資料報的長度，用兩個位元組表示，能表示的數字范圍為0 ~ 65535
位元組，所以說資料部分的長度應該是65535-8-20（ip報頭大小）約等于65507位元組，大概就是64Kb的資料，所以說UDP傳輸的資料大小比較小，
最后一個也是UDP檢驗和也是兩個位元組,驗證資料準確無誤，不能一定能檢驗出錯誤

可以看出UDP是一種簡單的協議，由于自身的限制（不可靠，傳輸檔案小）等在實際開發使用中并不常見，很多場景都是需要可靠傳輸，但是UDP也是有優點的，就是（1）傳輸速率快，（2）能夠支持廣播
應用場景：對效率要求高，但是對可靠性要求不高等

二、TCP

首先TCP是傳輸層的協議，特點是有連接，可靠傳輸，面向位元組流
先了解TCP的報文結構

報文結構我們不需要全部了解，掌握重點的就可以了，
32位序號用來確保資料之間的先后順序，
4位首部長度單位是4個位元組，能表示的資料范圍是0~15，如果是15，則表示TCP首部長度就是60個位元組
TCP的六個標志位，每個標志位是1個bit 后面會介紹重要的幾個

TCP的核心機制

2.1確認應答

確認應答機制是確保TCP可靠性的核心機制，
TPC將每一個位元組的資料進行了編號，當主機A向主機B發送資料時，主機B回復一個確認收到的回應（ACK），當發送方收到應答資料時，如果應答報文的確認序號為1001，這時候發送方就知道了 1—1000的資料已經順利抵達，并且接下來發送的資料就是從1001開始，但是可能會發生丟包情況，等待一點時間后，進行重傳（超時重傳），到一定限制后就不會進行重傳了，
但是可能會發生一份資料多次發送的情況，TCP自身已經處理了這種情況，TCP中有一個“接識訓沖區”TCP就會通過序號檢查是否重復，
TCP協議通過確認應答和超時重傳的方式來確保資料TCP的可靠性

2.2超時重傳

如果多次沒有收到該資料包的回應，就會觸發超時重傳機制，重新將沒有收到的回應發送一遍，如果還是沒有收到回應就繼續重發，并且等待時間成指數增長，可能第一次是500ms,下一次就是2 * 500ms,下一次就是2^2 * 500ms,到達一定的次數之后TCP就認為網路或者目的主機出問題，就強制進行關閉，

2.3連接管理

2.3.1三次握手

三次握手的本質就是確認通信雙方的發送能力和接收能力都是正常的

第一次握手發送SYN（建立連接）主機B就知道自己的接收能力時正常的以及主機A的發送能力時正常的，
第二次握手，主機A收到SYN+ACK（確認應答）就知道主機B的發送能力是正常的，以及自己的接收能力是正常的，并且還有隱性條件就是主機A的發送能力是正常的，主機B的接收能力是正常的，通過第二次握手主機A就已經知道通信雙方的接收和發送能力是正常的，但是主機B不確定
第三次握手，主機A向主機B發送應答回應，這時主機B收到后，就知道自己的發送能力以及主機A的接收能力時正常的，至此通信雙方接收能力和發送能力都正常，

2.3.2為什么是三次握手，四次不行嗎？兩次？

首先四次握手就是將主機B的應答報文和建立連接報文分開，四次也能建立連接，但是沒有必要，傳輸效率低了，
如果是兩次呢? 不行，三次握手就是讓通信雙方確認接收能力和發送能力都正常，但是兩次握手主機B不能確認自己的發送能力和主機A的接收能力是否正常，如果第一次發送SYN由于其他原因（網路延遲等）沒有發送到主機B，等待了一定時間后，主機A重新發送了一個SYN，和主機B建立了連接，在傳輸資料中，第一次的SYN又經歷種種困難，重新發送到主機B了，這時主機B就會以為建立了新的連接，造成了剛才的連接中斷，資料丟失，

2.3.3四次揮手

通過四次揮手來斷開連接

首先主機A向主機B發送結束報文段FIN，
中間的二次互動能不能和為一次？只能說有可能會，因為斷開連接的時候主機B發送的ACK是作業系統內核的行為，就在收到FIN的第一時間就會回復，而發送FIN是應用程式的行為，在代碼中執行到close（）才會觸發FIN，是合并的理由是如果close()很快就會被呼叫，那么就會觸發延時回答和捎帶應答，這樣就把兩個資料變為一條了，所有說四次揮手有可能是三次揮手，但是大概率是四次揮手，
TCP連接中一些核心的狀態
E STABLISHED （穩定）連接建立成功
LISTEN 服務器端的狀態，服務器準備就緒，允許客戶端隨時來建立連接
CLOSE_WAIT (四次揮手中) 等待關閉，出現在收到FIN ，回傳ACK,到發送FIN這個時間間隙中，
在三次握手和四次揮手之間也會涉及到超時重傳，和確認應答
TIME_WAIT 誰主動建立連接，誰有這個狀態（注意建立連接是客戶端實作的，而斷開連接客戶端和服務器都可以實作）為了防止最后一個ACK丟包做準備的，即進行最后一個ACK發送完畢后，不會立即銷毀連接，而是以TIME_WAIT的狀態等待一定時間，如果沒有收到對方的FIN就認為ACK沒有丟包，就真正釋放連接，如果一定時間內對方重傳了FIN就認為ACK丟了，就進行重傳ACK TIME_WAIT 等待時間是2 MSL，MSL是表示網路中，兩個主機傳輸資料的最大時間間隔

2.4 滑動視窗

通過前面的描述我們了解到每次發送資料時都是等待應答到了才會發送下一個資料，這樣確保了可靠性，但是我們想在確保可靠性的條件下也能讓效率更高，通過滑動視窗來實作提高效率，
滑動視窗就是我們通過連續發送一組資料，等待這一組的ACK，之后再發下一組的資料，這樣就能做到節約時間了，這一組資料能發多少，這個資料量，就稱為“視窗大小”，即視窗大小指的是無需確認等待而可以繼續發送的資料最大值，發送視窗大小的資料，不需要等待ACK直接發送，收到第一個ACK后，視窗向后移動，類似于滑動視窗，作業系統的內核為了維護這個滑動視窗，需要開辟發送緩沖區來記錄當前資料還有哪些沒有被應答，只有確認應答后的資料才被發送緩沖區刪掉，視窗越大，網路的吞吐率就越高，
問題：滑動視窗提高了效率但是如何保證可靠性，以及發生丟包情況怎么處理
ACK丟失，只要后續的收到了ACK就能知道前面資料傳輸效果怎么樣，即丟失ACK后，序號確認機制就能彌補這樣的錯誤，只要后續的序號到達之后，就能證明前的資料傳輸正常，即使ACK丟了也沒關系，
資料包丟失，ACK確認序號就是再已經到達的序號基礎上加1，如果中間的資料包丟失，ACK就會一直回傳的回應序號為丟失前序號的下一個，如果1~1000序號資料包正常到達，1001 ~ 2000資料包丟失，即使后面發送了2001 ~ 3000的資料包，ACK也只會重復回應1001， 客戶端這邊收到了多次的1001序號，就知道1001 ~ 2000資料包丟失了，就只重傳這部分的資料，所以不會重復重傳資料，
重傳機制得益于確認序號的加持，即保證了傳輸效率是比較高的，重傳效率也是比較高的，因為沒有重復的資料重傳–快速重傳

滑動視窗可靠性也有，效率也提高了，所以滑動視窗的大小，到底多少合適，視窗大了，效率提高了，但是記憶體消耗大
視窗太小，效率減少，但是記憶體占用少，還有接受方的處理速度也會影響視窗大小，所以我們就要對視窗大小進行限制，就是根據接受方的處理能力，來限制就引出了流量控制

2.5 流量控制

主機A向主機B發送資料，主機B回傳的資料除了有ACK以外還有接收方緩沖區的空余大小，如果接受方緩沖區空余大小為等，主機A就會等待一定的時機，過了重發超時的時間以后，如果還沒有收到視窗更新的訊息，主機A救會發送一個視窗探測來確實當前接收方緩沖區剩余大小
流量控制的目的就是讓發送方和接收方的速率盡可能一致，才能做到盡可能可靠并且高效，根據這個大小，發送發就能確定接下來的視窗大小為多少，所以視窗的大小是動態變化的，實際情況下，網路傳輸中取決于中間處理最慢的設備，還要考慮中間設備的處理能力，所以引出了擁塞控制

2.6 擁塞控制

滑動視窗的大小取決于擁塞控制和流量控制一起決定的，發送方，采用一個動態變化的程序，來試探出當前視窗大小多少合適，發送方在初始的情況下先設定一個比較小的視窗大小（慢開始），如果沒有丟包就說明網路暢通就增大視窗大小，一直到出現丟包了就縮小視窗大小，
滑動視窗的大小就是擁塞控制和流量控制的較小值
所以TCP 并不適合效率要求特別高的場景，

2.7 延時應答

延時應答也是一個提高效率的方式，就是在應答ACK時，并不是立刻回傳ACK而是等待一會（500ms），之后再回傳ACK，這樣可能，ACK攜帶的滑動視窗的大小可能更大了（接識訓沖區在等待的時間里處理了一些資料），這樣傳輸的效率又會變得更大了，
所有的包適合延時應答嗎？不是的，數量限制：每隔n個包就延時應答一次，時間限制：超過最大延時時間就應答一次，

2.8 捎帶應答

當前我們最常見的服務器通信模式就是一問一答，在一問一答的情況下，我們需要四次TCP資料的互動，一問回傳一個ACK，一答回傳一個ACK，主要是回傳ACK是作業系統的內核實作的，接收到立刻回傳ACK，而產生回答是代碼回應的，按理說二者是有時間的間隔，但是TCP中有延時應答，所以理論上二者有可能同一時間應答，所以說捎帶應答就是建立在延時應答的基礎上

2.9 粘包問題

應用程式可以以位元組為單位來讀取、發送資料~ 核心在于TCP的緩沖區
三次握手建立連接后，通信雙方各自在內核中維護一對緩沖區，發送緩沖區，和接受緩沖區，在發送資料時，接識訓沖區可能無法分辨資料 如下圖

這個問題就是粘包問題，粘包問題是面向位元組流都會涉及到粘包問題，而UDP就會不會發生這種情況，因為UDP是資料包的形式傳輸的
如何應對粘包問題，粘包是粘的應用層的資料包，設計應用層協議的時候，能夠顯式的區分出來資料包的邊界
1.在應用層里顯式的指定包的長度
2.顯式的指定包和包之間的分割符（結束標記）

2.10 TCP對例外情況的處理

1.行程終止
把程式關掉了，或者行程奔潰了，就會導致四次揮手，正常關閉
2.機器重啟
就是按照正常的流程重啟，這是系統會先殺死行程，也會觸發四次揮手，但是如果主機關的快，四次揮手就會中斷，對方主機就會殘留一個四次揮手的程序，對方主機沒有收到回應，就會重傳FIN，重傳到一定的次數后，就自己斷開連接了，
3.機器斷開或者網線斷開
如果主機A斷電了，主機B（發送方）沒有收到ACK就會觸發超時重傳，達到一定次數，就會重置連接，如果重置連接沒有相應就會釋放連接，
如果主機B是接收方，主機A下線了，主機B就等待，連接無法釋放，但是TCP協議中內置了保活機制（心跳包），就是每隔一定時間，主機B會給主機A發送一個很短小的報文，期待對方回傳一個回應，就是判斷主機A是否在線情況，

在平時的開發中，我們通過負載均衡的方式來判斷哪些節點是正常的作業，哪些節點是出現問題的，都是通過心跳包，的方式來判斷，負載均衡體系可以在服務器不中斷的情況下，對服務器進行重啟和升級，

總結：

TCP/UDP對比

TCP是有連接，可靠傳輸，面向位元組流，而UDP是無連接，不可靠傳輸，面向資料報
應用的場景也是不同的：
TCP適用于可靠傳輸的情況，應用于檔案傳輸，重要狀態更新等場景
UDP使用于高速傳輸和實時性，例如 早早期的qq，視頻傳輸等，另外UDP適用于廣播

如何基于UDP來實作可靠傳輸

在應用層（應用程式中）保證可靠性，通過模擬TCP的可靠性來實作UDP可靠性，即可以設定確認應答機制和超時重傳機制來確保UDP的可靠性，在程式中添加相應的欄位來確保確認應答機制，也通過建立連接機制，通過三次握手和四次揮手來確保建立連接網路的可靠性，引入序列號來確保資料的順序傳輸，通過引入滑動視窗來提高傳輸效率等等就是模仿TCP的方式來使得UDP能夠進行可靠傳輸，