TCP：
TCP即傳輸控制協議，是一種面向連接的、可靠的、基於字節流的通信協議。簡單來說TCP就是有確認機制的UDP協議，每發出一個數據包都要求確認，如果有一個數據包丟失，就收不到確認，發送方就必須重發這個數據包。爲了保證傳輸的可靠性，TCP協議在UDP基礎之上建立了三次對話的確認機制，即在正式收發數據前，必須和對方建立可靠的連接。TCP數據包和UDP一樣，都是由首部和數據兩部分組成，唯一不同的是，TCP數據包沒有長度限制，理論上可以無限長，但是爲了保證網絡的效率，通常TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。
tcp報文格式
標誌位含義
ACK：確認序號有效。僅當ACK=1時，確認號字段纔有效。TCP規定，在連接建立後所有報文的傳輸都必須把ACK置1；
SYN：發起一個新連接。當SYN=1，ACK=0，表明是連接請求報文；若同意連接，則響應報文中應該使SYN=1，ACK=1。
FIN：釋放一個連接。當FIN=1，表明此報文的發送方的數據已經發送完畢，並且要求釋放。
URG：當URG=1，表明緊急指針字段有效。告訴系統此報文段中有緊急數據。
PSH：當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應，這時候就將PSH=1。
RST：當RST=1，表明TCP連接中出現嚴重差錯，必須釋放連接，然後再重新建立連接。
三次握手的過程
注意：三次握手的最主要目的是保證連接是雙工的，可靠更多的是通過重傳機制來保證的
- TCP服務器進程先創建傳輸控制塊TCB，時刻準備接受客戶進程的連接請求，此時服務器就進入了LISTEN（監聽）狀態；
- TCP客戶進程也是先創建傳輸控制塊TCB，然後向服務器發出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。
- TCP服務器收到請求報文後，如果同意連接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，但是同樣要消耗一個序號。
- TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。TCP規定，ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。
- 當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就可以開始通信了。
爲什麼建立連接是三次握手，四次不可以嗎？
第一次握手
1. Client什麼都不能確認
2. Server確認了對方發送正常
第二次握手1.Client確認：自己發送/接收正常，對方發送/接收正常
2. Server確認：自己接收正常 ，對方發送正常
第三次握手1. Client確認：自己發送/接收正常， 對方發送/接收正常
2.Server確認：自己發送/接收正常，對方發送/接收正常所以通過三次握手確認雙方收發功能都正常，四次也可以但是顯得比較多餘。
如果兩次握手會怎麼樣？
一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。
如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接並且沒有丟失，只是因爲在網絡結點中滯留的時間太長了，由於TCP的客戶端遲遲沒有收到確認報文，以爲服務器沒有收到，此時重新向服務器發送這條報文，此後客戶端和服務器經過兩次握手完成連接，傳輸數據，然後關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。
如果採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文並且回覆了確認報文，但是客戶端不會再次發出確認。由於服務器收不到確認，就知道客戶端並沒有請求連接。
TCP連接的釋放（四次揮手）
- 客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
- 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
- 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最後的數據）。
- 服務器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
- 客戶端收到服務器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗ *∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
- 服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
爲什麼建立連接是三次握手，關閉連接確是四次揮手呢？
- 建立連接的時候， 服務器在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。
- 而關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。
爲什麼需要TIME_WAIT狀態 ，等待2MSL
MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設置不同的MSL值。
第一，保證客戶端發送的最後一個 ACK 報文能夠到達服務器，因爲這個 ACK 報文可能丟失，站在服務器的角度看來，我已經發送了 FIN+ACK 報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，於是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，並且會重啓 2MSL 計時器。
第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。