TCP（Transmission Control Protocol，傳輸控制協議）是面向連線的協議，也就是說，在收發資料前，必須和對方建立可靠的連線。一個TCP連線必須要經過三次“對話”才能建立起來，其中的過程非常複雜，只簡單的描述下這三次對話的簡單過程：主機A向主機B發出連線請求資料包：“我想給你發資料，可以嗎？”，這是第一次對話；主機B向主機A傳送同意連線和要求同步（同步就是兩臺主機一個在傳送，一個在接收，協調工作）的資料包：“可以，你什麼時候發？”，這是第二次對話；主機A再發出一個數據包確認主機B的要求同步：“我現在就發，你接著吧！”，這是第三次對話。三次“對話”的目的是使資料包的傳送和接收同步，經過三次“對話”之後，主機A才向主機B正式傳送資料。

詳細點說就是：

TCP三次握手過程
1 主機A通過向主機B 傳送一個含有同步序列號的標誌位的資料段給主機B ,向主機B 請求建立連線,通過這個資料段,
主機A告訴主機B 兩件事:我想要和你通訊;你可以用哪個序列號作為起始資料段來回應我.
2 主機B 收到主機A的請求後,用一個帶有確認應答(ACK)和同步序列號(SYN)標誌位的資料段響應主機A,也告訴主機A兩件事:
我已經收到你的請求了,你可以傳輸資料了;你要用哪佧序列號作為起始資料段來回應我
3 主機A收到這個資料段後,再發送一個確認應答,確認已收到主機B 的資料段:"我已收到回覆,我現在要開始傳輸實際資料了

這樣3次握手就完成了,主機A和主機B 就可以傳輸資料了.
3次握手的特點
沒有應用層的資料
SYN這個標誌位只有在TCP建產連線時才會被置1
握手完成後SYN標誌位被置0

TCP建立連線要進行3次握手,而斷開連線要進行4次

1 當主機A完成資料傳輸後,將控制位FIN置1,提出停止TCP連線的請求
2  主機B收到FIN後對其作出響應,確認這一方向上的TCP連線將關閉,將ACK置1
3 由B 端再提出反方向的關閉請求,將FIN置1
4 主機A對主機B的請求進行確認,將ACK置1,雙方向的關閉結束.
由TCP的三次握手和四次斷開可以看出,TCP使用面向連線的通訊方式,大大提高了資料通訊的可靠性,使傳送資料端
和接收端在資料正式傳輸前就有了互動,為資料正式傳輸打下了可靠的基礎
名詞解釋
ACK  TCP報頭的控制位之一,對資料進行確認.確認由目的端發出,用它來告訴傳送端這個序列號之前的資料段
都收到了.比如,確認號為X,則表示前X-1個數據段都收到了,只有當ACK=1時,確認號才有效,當ACK=0時,確認號無效,這時會要求重傳資料,保證資料的完整性.
SYN

TCP的包頭結構：
源埠 16位
目標埠 16位
序列號 32位
迴應序號 32位
TCP頭長度 4位
reserved 6位
控制程式碼 6位
視窗大小 16位
偏移量 16位
校驗和 16位
選項  32位(可選)
這樣我們得出了TCP包頭的最小長度，為20位元組。

UDP（User Data Protocol，使用者資料報協議）

（1） UDP是一個非連線的協議，傳輸資料之前源端和終端不建立連線，當它想傳送時就簡單地去抓取來自應用程式的資料，並儘可能快地把它扔到網路上。在傳送端，UDP傳送資料的速度僅僅是受應用程式生成資料的速度、計算機的能力和傳輸頻寬的限制；在接收端，UDP把每個訊息段放在佇列中，應用程式每次從佇列中讀一個訊息段。

（2） 由於傳輸資料不建立連線，因此也就不需要維護連線狀態，包括收發狀態等，因此一臺服務機可同時向多個客戶機傳輸相同的訊息。

（3） UDP資訊包的標題很短，只有8個位元組，相對於TCP的20個位元組資訊包的額外開銷很小。

（4） 吞吐量不受擁擠控制演算法的調節，只受應用軟體生成資料的速率、傳輸頻寬、源端和終端主機效能的限制。

（5）UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的連結狀態表（這裡面有許多引數）。

（6）UDP是面向報文的。傳送方的UDP對應用程式交下來的報文，在新增首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，因此，應用程式需要選擇合適的報文大小。

我們經常使用“ping”命令來測試兩臺主機之間TCP/IP通訊是否正常，其實“ping”命令的原理就是向對方主機發送UDP資料包，然後對方主機確認收到資料包，如果資料包是否到達的訊息及時反饋回來，那麼網路就是通的。

UDP的包頭結構：
源埠 16位
目的埠 16位
長度 16位
校驗和 16位

小結TCP與UDP的區別：

1.基於連線與無連線；
2.對系統資源的要求（TCP較多，UDP少）；
3.UDP程式結構較簡單；
4.流模式與資料報模式 ；

5.TCP保證資料正確性，UDP可能丟包，TCP保證資料順序，UDP不保證。

這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的連線請求後，它可以把ACK和SYN(ACK起應答作用，而SYN起同步作用)放在一個報文裡來發送。但關閉連線時，當收到對方的FIN報文通知時，它僅僅表示對方沒有資料傳送給你了；但未必你所有的資料都全部發送給對方了，所以你可能未必會馬上會關閉SOCKET,也即你可能還需要傳送一些資料給對方之後，再發送FIN報文給對方來表示你同意現在可以關閉連線了，所以它這裡的ACK報文和FIN報文多數情況下都是分開發送的。

2．為什麼TIME_WAIT狀態還需要等2MSL後才能返回到CLOSED狀態？

這是因為雖然雙方都同意關閉連線了，而且握手的4個報文也都協調和傳送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；但是因為我們必須要假想網路是不可靠的，你無法保證你最後傳送的ACK報文會一定被對方收到，因此對方處於LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。

3. 為什麼不能用兩次握手進行連線？

我們知道，3次握手完成兩個重要的功能，既要雙方做好傳送資料的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被髮送和確認。
    現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通訊，假定C給S傳送一個連線請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認為連線已經成功地建立了，可以開始傳送資料分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連線請求分組。在這種情況下，C認為連線還未建立成功，將忽略S發來的任何資料分組，只等待連線確認應答分組。而S在發出的分組超時後，重複傳送同樣的分組。這樣就形成了死鎖。