TCP(Transmission Control Protocol) 傳輸控制協議
1. 三次握手協議（建立連接）
TCP是主機對主機層的傳輸控制協議，提供可靠的連接服務，采用三次握手確認建立一個連接:
位碼即tcp標志位,有6種標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)
Sequence number(順序號碼) Acknowledge number(確認號碼)
第一次握手：主機A發送位碼為syn＝1,隨機產生seq number=1234567的數據包到服務器，主機B由SYN=1知道，A要求建立聯機；
第二次握手：主機B收到請求后要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包
第三次握手：主機A收到后檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否為1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到后確認seq值與ack=1則連接建立成功。
完成三次握手，主機A與主機B開始傳送數據。
2、四次揮手（釋放連接）
第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但此時主動關閉方還可以接受數據。
第二次揮手：被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號）。
第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
第四次揮手：主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。
特點：
a) 面向連接: 是指發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”，這樣能建立可靠的連接。建立連接，是為數據的可靠傳輸打下了基礎
b) 僅支持單播傳輸: 每條TCP傳輸連接只能有兩個端點，只能進行點對點的數據傳輸，不支持多播和廣播傳輸方式。
c) 面向字節流 : TCP不像UDP一樣那樣一個個報文獨立地傳輸，而是在不保留報文邊界的情況下以字節流方式進行傳輸。
d) 可靠傳輸 :
對於可靠傳輸，判斷丟包，誤碼靠的是TCP的段編號以及確認號。TCP為了保證報文傳輸的可靠，就給每個包一個序號，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節發回一個相應的確認(ACK)；如果發送端實體在合理的往返時延(RTT)內未收到確認，那么對應的數據（假設丟失了）將會被重傳。
e) 提供擁塞控制: 當網絡出現擁塞的時候，TCP能夠減小向網絡注入數據的速率和數量，緩解擁塞
f) TCP提供全雙工通信: TCP允許通信雙方的應用程序在任何時候都能發送數據，因為TCP連接的兩端都設有緩存，用來臨時存放雙向通信的數據。當然，TCP可以立即發送一個數據段，也可以緩存一段時間以便一次發送更多的數據段（最大的數據段大小取決於MSS）
疑問
1. 為什么是三次握手，而不是兩次握手？ server端同意建立連接之后為什么不能直接通信，而是再進行一次確認。
其實二次握手理論上也是行的通的，但是會帶來一個問題：
a) 假定A向B發送一個連接請求，由於一些原因，導致A發出的連接請求在一個網絡節點逗留了比較多的時間。此時A會將此連接請求作為無效處理 又重新向B發起了一次新的連接請求，B正常收到此連接請求后建立了連接，數據傳輸完成后釋放了連接。如果此時A發出的第一次請求又到達了B，B會以為A又發起了一次連接請求，如果是兩次握手：此時連接就建立了，B會一直等待A發送數據，從而白白浪費B的資源。
那為什三次握手就能解決上述問題呢？如果最后一次確認也存在延遲，若干時間之后才到到服務端的，不會同樣白白建立連接么？
b) 猜測服務端會進行一個判斷，如果SYNC-RCVD狀態（即收到客戶端建立連接請求到收到確認之間）時間過長，則可以放棄這次連接的建立。
2.第二次揮手和第三次揮手能不能合並？
第二次揮手和第三次揮手中間過程用來傳輸未傳遞完的數據。
a) 如果沒有待傳遞數據，其實第二次揮手和第三次揮手是可以合並的
b) 如果有待傳遞數據則不可以。
3. TCP第四次揮手失敗怎么辦？
第四次揮手失敗，此時客戶端的狀態為TIME_WAIT，會等待一段時間，服務器端狀態仍然為LAST_ACK，超時一段時間仍然沒有響應的話，服務器端會再發起一次FIN包，告訴客戶端服務器端也要斷開連接的請求，客戶端收到后會再次發生ACK包確認斷開連接。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。
4. TIME_WAIT的時間為什么是2MSL？
MSL： 最大報文生存時間。 如果超過這個時間還沒有收到服務端的FIN包，則可以正常關閉。
發送報文到服務端時間 + 服務端發送FIN包到客戶端 肯定小於 2MSL
UDP（戶數據報協議）
1. 面向無連接
首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的，想發數據就可以開始發送了。並且也只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。
具體來說就是：
- 在發送端，應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增加一個 UDP 頭標識下是 UDP 協議，然后就傳遞給網絡層了
- 在接收端，網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操作
2. 有單播，多播，廣播的功能
UDP 不止支持一對一的傳輸方式，同樣支持一對多，多對多，多對一的方式，也就是說 UDP 提供了單播，多播，廣播的功能。
3. UDP是面向報文的
發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。因此，應用程序必須選擇合適大小的報文
4. 不可靠性
首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況肯定不可靠。
並且收到什么數據就傳遞什么數據，並且也不會備份數據，發送數據也不會關心對方是否已經正確接收到數據了。
再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一直會以恆定的速度發送數據。即使網絡條件不好，也不會對發送速率進行調整。這樣實現的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要求高的場景（比如電話會議）就需要使用 UDP 而不是 TCP。
5. 頭部開銷小，傳輸數據報文時是很高效的。
UDP 頭部包含了以下幾個數據：
- 兩個十六位的端口號，分別為源端口（可選字段）和目標端口
- 整個數據報文的長度
- 整個數據報文的檢驗和（IPv4 可選 字段），該字段用於發現頭部信息和數據中的錯誤
因此 UDP 的頭部開銷小，只有八字節，相比 TCP 的至少二十字節要少得多，在傳輸數據報文時是很高效的
總結：
1. 對比
| UDP | TCP | |
|---|---|---|
| 是否連接 | 無連接 | 面向連接 |
| 是否可靠 | 不可靠傳輸，不使用流量控制和擁塞控制 | 可靠傳輸，使用流量控制和擁塞控制 |
| 連接對象個數 | 支持一對一，一對多，多對一和多對多交互通信 | 只能是一對一通信 |
| 傳輸方式 | 面向報文 | 面向字節流 |
| 首部開銷 | 首部開銷小，僅8字節 | 首部最小20字節，最大60字節 |
| 適用場景 | 適用於實時應用（IP電話、視頻會議、直播等） | 適用於要求可靠傳輸的應用，例如文件傳輸 |
參考：
http://www.cnblogs.com/rootq/articles/1377355.html
http://www.cnblogs.com/renyuan/p/3431022.html