TCP/IP：因特網整個 TCP/IP 協議族
TCP/IP(Transmission Control Protocol/Internet Protocol)傳輸控制協議/因特網互聯協議，又名網絡通訊協議。由網絡層的 IP 協議和傳輸層的 TCP 協議組成。
TCP 負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而 IP 是給因特網的每一臺聯網設備規定一個地址。
TCP/IP 參考模型：應用層、傳輸層、網絡層、網絡接口層。但是網絡接口層並沒有嚴格的劃分。所以有時候也有人把網絡接口層拆分成兩層：數據鏈路層、物理層。
“三次握手”：建立 TCP 連接過程
目的：爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。————謝希仁《計算機網絡》
“已失效的連接請求報文段”的產生在這樣一種情況下：服務端 發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達 服務端。本來這是一個早已失效的報文段。但 服務端 收到此失效的連接請求報文段後，就誤認爲是 服務端 再次發出的一個新的連接請求。於是就向 服務端 發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要 服務端 發出確認，新的連接就建立了。由於現在 服務端 並沒有發出建立連接的請求，因此不會理睬 服務端 的確認，也不會向 服務端 發送數據。但 服務端 卻以爲新的運輸連接已經建立，並一直等待 服務端 發來數據。這樣，服務端 的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，服務端 不會向 服務端 的確認發出確認。服務端 由於收不到確認，就知道 服務端 並沒有要求建立連接。”。主要目的防止 服務端 端一直等待，浪費資源。
【動圖轉自：https://blog.csdn.net/qzcsu/article/details/72861891】
標誌位含義：
ACK：確認序號有效，表示響應。
SYN：發起一個新連接。
FIN：釋放一個連接，關閉連接。
PSH：有數據傳輸
RST：連接重置
第一次握手
Client 將標誌位 SYN 置 1，隨機產生一個值 seq=J,並將數據包發給 Server
Client 進入 SYN*SENT 狀態，等待 Server 確認
第二次握手
Server 收到數據包後標誌位 SYN=1 知道 Client 請求建立連接，Server 將標誌位 SYN 和 ACK 都置 1，隨機產生一個值,並將數據包發給 Client 確認連接請求，Server 進入 SYN_RCVD 狀態
第三次握手
Client 收到確認後若 ACK 爲 1，則將該數據包發送給 Server，Server 檢查 ACK 爲 1 則連接建立成功，Client 與 Server 進入 ESTABLISHED 狀態完成三次握手，可以傳輸數據
簡述：
服務端發送一個帶 SYN 標誌的數據包給對方。服務端收到後，回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。 最後，服務端再回傳一個帶 ACK 標誌的數據包，代表“握手”結束。
爲什麼是三次不是兩次
防止已失效的請求報文段突然又傳送到了服務端而產生連接的誤判
“四次揮手”：終止 TCP 連接過程
原因：由於 TCP 連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個 FIN 來終止這一方向的連接，收到一個 FIN 只是意味着這一方向上沒有數據流動了，即不會再收到數據了，但是在這個 TCP 連接上仍然能夠發送數據，直到這一方向也發送了 FIN。
【動圖轉自：https://blog.csdn.net/qzcsu/article/details/72861891】
第一次揮手：
Client 發送一個 FIN，用來關閉 Client 到 Server 的數據傳送，Client 進入 FIN_WAIT_1 狀態。
第二次揮手：
Server 收到 FIN 後，發送一個 ACK 給 Client,Server 進入 CLOSE_WAIT 狀態。
第三次揮手：
Server 發送一個 FIN，用來關閉 Server 到 Client 的數據傳送，Server 進入 LAST_ACK 狀態。
第四次揮手：
Client 收到 FIN 後，Client 進入 TIME_WAIT 狀態，發送 ACK 給 Server，Server 進入 CLOSED 狀態，完成四次握手。
簡述：
服務端發送 FIN；服務端接收 FIN 併發送 ACK 給服務端；服務端發送 FIN；服務端接收 FIN 併發送 ACK 給服務端，
參考連接:
https://blog.csdn.net/yu876876/article/details/81560122
http://www.imooc.com/article/79180
https://blog.51cto.com/13871180/2162062
https://blog.csdn.net/qzcsu/article/details/72861891