這可能是最全面的TCP面試八股文了

電腦網路基礎，考驗一個程式員的基本功，也能更快的篩選出更優秀的人才。說說TCP的三次握手假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是CLOSED。第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端發送的欄位中包含標誌位SYN=1 ...

電腦網路基礎，考驗一個程式員的基本功，也能更快的篩選出更優秀的人才。

說說TCP的三次握手

假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是CLOSED。

第一次握手：客戶端向服務端發起建立連接請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端發送的欄位中包含標誌位SYN=1，序列號seq=x。第一次握手前客戶端的狀態為CLOSE，第一次握手後客戶端的狀態為SYN-SENT。此時服務端的狀態為LISTEN。
第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號y，然後給客戶端回覆一段報文，其中包括標誌位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手後服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）
第三次握手：客戶端收到服務端發來的報文後，會再向服務端發送報文，其中包含標誌位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手後客戶端和服務端的狀態都為ESTABLISHED。此時連接建立完成。

兩次握手可以嗎？

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸到了服務端，導致產生問題。

比如客戶端A發出連接請求，可能因為網路阻塞原因，A沒有收到確認報文，於是A再重傳一次連接請求。
然後連接成功，等待數據傳輸完畢後，就釋放了連接。
然後A發出的第一個連接請求等到連接釋放以後的某個時間才到達服務端B，此時B誤認為A又發出一次新的連接請求，於是就向A發出確認報文段。
如果不採用三次握手，只要B發出確認，就建立新的連接了，此時A不會響應B的確認且不發送數據，則B一直等待A發送數據，浪費資源。

本文已經收錄到Github倉庫，該倉庫包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github地址

如果訪問不了Github，可以訪問gitee地址。

gitee地址

為什麼需要TCP協議？

IP 層是「不可靠」的,它不保證網路包的交付、不保證網路包的按序交付、也不保證網路包中的數據的完整性。

因為 TCP 是一個工作在傳輸層的可靠數據傳輸的服務,它能確保接收端接收的網路包是無損壞、無間隔、非冗餘和按序的。

說說TCP的四次揮手

A的應用進程先向其TCP發出連接釋放報文段（FIN=1，seq=u），並停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
B收到連接釋放報文段後即發出確認報文段（ACK=1，ack=u+1，seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連接釋放。
A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。
B發送完數據，就會發出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。
A收到B的連接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL（最大報文段生存時間）後，A才進入CLOSED狀態。B收到A發出的確認報文段後關閉連接，若沒收到A發出的確認報文段，B就會重傳連接釋放報文段。

第四次揮手為什麼要等待2MSL？

保證A發送的最後一個ACK報文段能夠到達B。這個ACK報文段有可能丟失，B收不到這個確認報文，就會超時重傳連接釋放報文段，然後A可以在2MSL時間內收到這個重傳的連接釋放報文段，接著A重傳一次確認，重新啟動2MSL計時器，最後A和B都進入到CLOSED狀態，若A在TIME-WAIT狀態不等待一段時間，而是發送完ACK報文段後立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發送一次確認報文段，B就無法正常進入到CLOSED狀態。
防止已失效的連接請求報文段出現在本連接中。A在發送完最後一個ACK報文段後，再經過2MSL，就可以使這個連接所產生的所有報文段都從網路中消失，使下一個新的連接中不會出現舊的連接請求報文段。

為什麼是四次揮手？

因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。但是在關閉連接時，當Server端收到Client端發出的連接釋放報文時，很可能並不會立即關閉SOCKET，所以Server端先回覆一個ACK報文，告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發送完了，這時Server端才能發送連接釋放報文，之後兩邊才會真正的斷開連接。故需要四次揮手。

說說TCP報文首部有哪些欄位，其作用又分別是什麼？

16位埠號：源埠號，主機該報文段是來自哪裡；目標埠號，要傳給哪個上層協議或應用程式
32位序號：一次TCP通信（從TCP連接建立到斷開）過程中某一個傳輸方向上的位元組流的每個位元組的編號。
32位確認號：用作對另一方發送的tcp報文段的響應。其值是收到的TCP報文段的序號值加1。
4位頭部長度：表示tcp頭部有多少個32bit字（4位元組）。因為4位最大能標識15，所以TCP頭部最長是60位元組。
6位標誌位：URG(緊急指針是否有效)，ACk（表示確認號是否有效），PSH（緩衝區尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標誌接），FIN（表示告知對方本端要關閉連接了）
16位視窗大小：是TCP流量控制的一個手段。這裡說的視窗，指的是接收通告視窗。它告訴對方本端的TCP接收緩衝區還能容納多少位元組的數據，這樣對方就可以控制發送數據的速度。
16位校驗和：由發送端填充，接收端對TCP報文段執行CRC演算法以檢驗TCP報文段在傳輸過程中是否損壞。註意，這個校驗不僅包括TCP頭部，也包括數據部分。這也是TCP可靠傳輸的一個重要保障。
16位緊急指針：一個正的偏移量。它和序號欄位的值相加表示最後一個緊急數據的下一位元組的序號。因此，確切地說，這個欄位是緊急指針相對當前序號的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發送端向接收端發送緊急數據的方法。

最全面的Java面試網站

TCP有哪些特點？

TCP是面向連接的運輸層協議。
點對點，每一條TCP連接只能有兩個端點。
TCP提供可靠交付的服務。
TCP提供全雙工通信。
面向位元組流。

TCP和UDP的區別？

TCP面向連接；UDP是無連接的，即發送數據之前不需要建立連接。
TCP提供可靠的服務；UDP不保證可靠交付。
TCP面向位元組流，把數據看成一連串無結構的位元組流；UDP是面向報文的。
TCP有擁塞控制；UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如實時視頻會議等）。
每一條TCP連接只能是點到點的；UDP支持一對一、一對多、多對一和多對多的通信方式。
TCP首部開銷20位元組；UDP的首部開銷小，只有8個位元組。

TCP 和 UDP 分別對應的常見應用層協議有哪些？

基於TCP的應用層協議有：HTTP、FTP、SMTP、TELNET、SSH

HTTP：HyperText Transfer Protocol（超文本傳輸協議），預設埠80
FTP: File Transfer Protocol (文件傳輸協議), 預設埠(20用於傳輸數據，21用於傳輸控制信息)
SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協議) ,預設埠25
TELNET: Teletype over the Network (網路電傳), 預設埠23
SSH：Secure Shell（安全外殼協議），預設埠 22

基於UDP的應用層協議：DNS、TFTP、SNMP

DNS : Domain Name Service (功能變數名稱服務),預設埠 53
TFTP: Trivial File Transfer Protocol (簡單文件傳輸協議)，預設埠69
SNMP：Simple Network Management Protocol（簡單網路管理協議），通過UDP埠161接收，只有Trap信息採用UDP埠162。

TCP的粘包和拆包

TCP是面向流，沒有界限的一串數據。TCP底層並不瞭解上層業務數據的具體含義，它會根據TCP緩衝區的實際情況進行包的劃分，所以在業務上認為，一個完整的包可能會被TCP拆分成多個包進行發送，也有可能把多個小的包封裝成一個大的數據包發送，這就是所謂的TCP粘包和拆包問題。

為什麼會產生粘包和拆包呢?

要發送的數據小於TCP發送緩衝區的大小，TCP將多次寫入緩衝區的數據一次發送出去，將會發生粘包；
接收數據端的應用層沒有及時讀取接收緩衝區中的數據，將發生粘包；
要發送的數據大於TCP發送緩衝區剩餘空間大小，將會發生拆包；
待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

發送端將每個數據包封裝為固定長度
在數據尾部增加特殊字元進行分割
將數據分為兩部分，一部分是頭部，一部分是內容體；其中頭部結構大小固定，且有一個欄位聲明內容體的大小。

說說TCP是如何確保可靠性的呢？

首先，TCP的連接是基於三次握手，而斷開則是基於四次揮手。確保連接和斷開的可靠性。
其次，TCP的可靠性，還體現在有狀態;TCP會記錄哪些數據發送了，哪些數據被接收了，哪些沒有被接受，並且保證數據包按序到達，保證數據傳輸不出差錯。
再次，TCP的可靠性，還體現在可控制。它有數據包校驗、ACK應答、超時重傳(發送方)、失序數據重傳（接收方）、丟棄重覆數據、流量控制（滑動視窗）和擁塞控制等機制。

說下TCP的滑動視窗機制

TCP 利用滑動視窗實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護一個發送視窗和一個接收視窗。接收視窗大小取決於應用、系統、硬體的限制。發送視窗則取決於對端通告的接收視窗。接收方發送的確認報文中的window欄位可以用來控制發送方視窗大小，從而影響發送方的發送速率。將接收方的確認報文window欄位設置為 0，則發送方不能發送數據。

TCP頭包含window欄位，16bit位，它代表的是視窗的位元組容量，最大為65535。這個欄位是接收端告訴發送端自己還有多少緩衝區可以接收數據。於是發送端就可以根據這個接收端的處理能力來發送數據，而不會導致接收端處理不過來。接收視窗的大小是約等於發送視窗的大小。

詳細講一下擁塞控制？

防止過多的數據註入到網路中。幾種擁塞控制方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復( fast recovery )。

慢開始

把擁塞視窗 cwnd 設置為一個最大報文段MSS的數值。而在每收到一個對新的報文段的確認後，把擁塞視窗增加至多一個MSS的數值。每經過一個傳輸輪次，擁塞視窗 cwnd 就加倍。為了防止擁塞視窗cwnd增長過大引起網路擁塞，還需要設置一個慢開始門限ssthresh狀態變數。

當 cwnd < ssthresh 時，使用慢開始演算法。

當 cwnd > ssthresh 時，停止使用慢開始演算法而改用擁塞避免演算法。

當 cwnd = ssthresh 時，既可使用慢開始演算法，也可使用擁塞控制避免演算法。

擁塞避免

讓擁塞視窗cwnd緩慢地增大，每經過一個往返時間RTT就把發送方的擁塞視窗cwnd加1，而不是加倍。這樣擁塞視窗cwnd按線性規律緩慢增長。

無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網路出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方視窗值的一半（但不能小於2）。然後把擁塞視窗cwnd重新設置為1，執行慢開始演算法。這樣做的目的就是要迅速減少主機發送到網路中的分組數，使得發生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

最全面的Java面試網站

快重傳

有時個別報文段會在網路中丟失，但實際上網路並未發生擁塞。如果發送方遲遲收不到確認，就會產生超時，就會誤認為網路發生了擁塞。這就導致發送方錯誤地啟動慢開始，把擁塞視窗cwnd又設置為1，因而降低了傳輸效率。

快重傳演算法可以避免這個問題。快重傳演算法首先要求接收方每收到一個失序的報文段後就立即發出重覆確認，使發送方及早知道有報文段沒有到達對方。

發送方只要一連收到三個重覆確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待重傳計時器到期。由於發送方儘早重傳未被確認的報文段，因此採用快重傳後可以使整個網路吞吐量提高約20%。

快恢復

當發送方連續收到三個重覆確認，就會把慢開始門限ssthresh減半，接著把cwnd值設置為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法，使擁塞視窗緩慢地線性增大。

在採用快恢復演算法時，慢開始演算法只是在TCP連接建立時和網路出現超時時才使用。採用這樣的擁塞控制方法使得TCP的性能有明顯的改進。

什麼是 SYN 攻擊?

我們都知道 TCP 連接建立是需要三次握手,假設攻擊者短時間偽造不同 IP 地址的 SYN 報文,服務端每接收到一個 SYN 報文,就進入 SYN_RCVD 狀態,但服務端發送出去的 ACK + SYN 報文,無法得到未知 IP 主機的ACK 應答,久而久之就會占滿服務端的 SYN 接收隊列(未連接隊列),使得伺服器不能為正常用戶服務。