目錄
我們在學習計算機網絡的過程中肯定會學習到它的傳輸方式，以及他的工作模型等。下面給大家分享自己借鑑總結的相關知識點，跟大家分享，大自然的搬運工。
一、網絡協議模型
首先，我們先了解下TCP/IP協議模型，並與OSI模型的對比參考
| 應用層 | 應用層 | |
| 表示層 | ||
| 會話層 | ||
| 傳輸層 | 傳輸層 | |
| 網絡層 | 網絡層 | |
| 數據鏈路層 | 網絡接口層 | |
| 物理層 |
二、TCP/UDP
這次我們要分析的TCP屬於網絡層協議，其中還包括UDP（後邊一起吐槽），雖然都在網絡層，但也有不同的特性，同時也具有不同的應用場景，下邊對比分析。
| TCP | UDP | |
| 可靠性 | 可靠 | 不可靠 |
| 連續性 | 面向連接 | 無連接 |
| 報文 | 面向字節流 | 面向報文 |
| 效率 | 傳輸效率低 | 傳輸效率高 |
| 雙工性 | 全雙工 | 一對一、一對多、多對一、多對多 |
| 流量控制 | 滑動窗口控制 | 無控制 |
| 擁塞控制 | 慢開始、擁塞避免、快重傳、快恢復 | 無 |
| 傳輸速度 | 慢 | 快 |
| 應用場景 | 對效率要求低，對準確性要求高或者要求有連接的場景 | 對效率要求高，對準確性要求低 |
| 應用協議層 | SMTP、TELNET、HTTP、FTP等 | DNS、TFTP、SNMP、NFS等 |
什麼時候應該使用TCP？
當對網絡通訊質量有要求的時候，比如：整個數據要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。
什麼時候應該使用UDP？
當對網絡通訊質量要求不高的時候，要求網絡通訊速度能儘量的快，這時就可以使用UDP。
三、TCP報文
| 16位 | 16位 | ||||||||||
| TCP首部 | 源 端 口 | 目 的 端 口 | 20字節的固定首部 | ||||||||
| 序 號 | |||||||||||
| 確 認 號 | |||||||||||
| 數據偏移 | 保留 | URG | ACK | PSH | RST | SYN | FIN | 窗 口 | |||
| 校 驗 | 緊 急 指 針 | ||||||||||
| 選項（長度可變） | 填 充 | ||||||||||
| 數 據 | |||||||||||
URG（urgent） ：緊急指針是否有效。爲1，表示某一位需要被優先處理
ACK（acknowledgement）：確認號是否有效，一般置爲1
PSH（push）：提示接收端應用程序立即從TCP緩衝區把數據讀走
RST（reset）：對方要求重新建立連接，復位。
SYN（synchronous）：請求建立連接，並在其序列號的字段進行序列號的初始值設定。建立連接，設置爲1
FIN （finish）：希望斷開連接。
四、TCP三次握手
第一次握手：建立連接。客戶端發送連接請求報文段，將SYN位置爲1，Sequence Number爲x；然後，客戶端進入SYN_SEND狀態，等待服務器的確認；
第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，自己自己還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK報文段。然後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢以後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。
TCP三次握手就好比兩個人在街上隔着50米看見了對方，但是因爲霧霾等原因不能100%確認，所以要通過招手的方式相互確定對方是否認識自己。
- 張三首先向李四招手(syn)，李四看到張三向自己招手後，向對方點了點頭擠出了一個微笑(ack)。張三看到李四微笑後確認了李四成功辨認出了自己(進入estalished狀態)。
- 但是李四還有點狐疑，向四周看了一看，有沒有可能張三是在看別人呢，他也需要確認一下。
- 所以李四也向張三招了招手(syn)，張三看到李四向自己招手後知道對方是在尋求自己的確認，於是也點了點頭擠出了微笑(ack)，李四看到對方的微笑後確認了張三就是在向自己打招呼(進入established狀態)。
- 於是兩人加快步伐，走到了一起，相互擁抱
爲什麼要三次握手？
爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。
具體例子：“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。
五、四次分手
第一次分手：主機1（可以使客戶端，也可以是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；
第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
第三次分手：主機2向主機1發送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK狀態；
第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連接；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連接了。
TCP斷開鏈接的過程和建立鏈接的過程比較類似，只不過中間的兩部並不總是會合成一步走，所以它分成了4個動作，張三揮手(fin)——李四傷感地微笑(ack)——李四揮手(fin)——張三傷感地微笑(ack)。
- 之所以中間的兩個動作沒有合併，是因爲tcp存在「半關閉」狀態，也就是單向關閉。
- 張三已經揮了手，可是人還沒有走，只是不再說話，但是耳朵還是可以繼續聽，李四呢繼續喊話。等待李四累了，也不再說話了，超張三揮了揮手，張三傷感地微笑了一下，才徹底結束了。
爲什麼要四次分手？
TCP協議是一種面向連接的、可靠的、基於字節流的運輸層通信協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經全部發送完畢了；但是，這個時候主機1還是可以接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，之後彼此就會愉快的中斷這次TCP連接。
爲什麼要等待2MSL？
MSL：報文段最大生存時間，它是任何報文段被丟棄前在網絡內的最長時間。原因有二：
保證TCP協議的全雙工連接能夠可靠關閉
保證這次連接的重複數據段從網絡中消失
第一點：如果主機1直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網絡原因，導致主機2沒有收到主機1最後回覆的ACK。那麼主機2就會在超時之後繼續發送FIN，此時由於主機1已經CLOSED了，就找不到與重發的FIN對應的連接。所以，主機1不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正確的關閉連接。
第二點：如果主機1直接CLOSED，然後又再向主機2發起一個新連接，我們不能保證這個新連接與剛關閉的連接的端口號是不同的。也就是說有可能新連接和老連接的端口號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連接和已經關閉的老連接端口號是一樣的，如果前一次連接的某些數據仍然滯留在網絡中，這些延遲數據在建立新連接之後纔到達主機2，由於新連接和老連接的端口號是一樣的，TCP協議就認爲那個延遲的數據是屬於新連接的，這樣就和真正的新連接的數據包發生混淆了。所以TCP連接還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連接的所有數據都從網絡中消失。
————————————————
借鑑原文鏈接：
掘金：https://juejin.im/post/598ba1d06fb9a03c4d6464ab（關於 TCP/IP，運維必知必會的十個問題）
CSDN：https://blog.csdn.net/qq_25948717/article/details/80382766（TCP三次握手中SYN，ACK，Seq含義）
簡書：https://www.jianshu.com/p/573700560be0（TCP報文格式說明）
知乎：https://zhuanlan.zhihu.com/p/40667482（【TCP】詳解TCP 三次握手和四次揮手）