以下內容源于網絡資料的學習整理。很多資料網上都有，但只有整理過一遍才屬于自己的。

參考博客

http://www.cnblogs.com/BlueTzar/articles/811160.html（OSI參考模型和TCP模型的詳解，包括格式）

https://blog.csdn.net/baidu_35692628/article/details/78255476?locationNum=4&fps=1（為什么可靠及優缺點）

https://blog.csdn.net/qzcsu/article/details/72861891（動圖很詳細，三次握手四次揮手過程）

https://blog.csdn.net/starsionblog/article/details/62040067（代碼實踐）

?

1、OSI參考模型和TCP模型

ISO制定的OSI參考模型的過于龐大復雜，招致了許多批評。（記憶：應、表示、會、傳輸、網絡，數據、物理）

與此對照，由技術人員自己開發的TCP/IP協議棧獲得了更為廣泛的應用。

? ? ?

在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合并到應用層實現）。同時將OSI參考模型中的數據鏈路層和物理層合并為主機到網絡層。

（1）主機到網絡層

實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。由于這一層次未被定義，所以其具體的實現方法將隨著網絡類型的不同而不同。　　

（2）網絡互連層　　

網絡互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，為了盡快地發送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和發送的順序可能不同，這就需要上層必須對分組進行排序。　　

網絡互連層定義了分組格式和協議，即IP協議（Internet Protocol）。　　

網絡互連層除了需要完成路由的功能外，也可以完成將不同類型的網絡（異構網）互連的任務。除此之外，網絡互連層還需要完成擁塞控制的功能。

（3）傳輸層　　

在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。

在傳輸層定義了兩種服務質量不同的協議：傳輸控制協議TCP（transmission control protocol）、用戶數據報協議UDP（user datagram protocol）。

TCP協議是一個面向連接的、可靠的協議。它將一臺主機發出的字節流無差錯地發往互聯網上的其他主機。在發送端，它負責把上層傳送下來的字節流分成報文段并傳遞給下層。在接收端，它負責把收到的報文進行重組后遞交給上層。TCP協議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩沖區接收發送方發送的大量數據。　　

UDP協議是一個不可靠的、無連接協議，主要適用于不需要對報文進行排序和流量控制的場合。　　

（4）應用層

TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應用層實現。

應用層面向不同的網絡應用引入了不同的應用層協議。其中，有基于TCP協議的，如文件傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文本鏈接協議（Hyper Text Transfer Protocol，HTTP），也有基于UDP協議的。

?

2、簡述TCP為何可靠？

（1）確認和重傳機制

• 建立連接時三次握手來同步雙方的“序列號 + 確認號 + 窗口大小信息”，是確認重傳、流控的基礎。
• 傳輸過程中，如果Checksum校驗失敗、丟包或延時，發送端重傳。

（2）數據排序

• TCP有專門的序列號SN字段，可提供數據re-order。

（3）流量控制

• 滑動窗口和計時器的使用。TCP窗口中會指明雙方能夠發送接收的最大數據量。

（4）擁塞控制

• TCP的擁塞控制由4個核心算法組成：“慢啟動”（Slow Start），“擁塞避免”（Congestion avoidance），“快速重傳 ”（Fast Retransmit），“快速恢復”（Fast Recovery）。

?

3、簡述TCP和UDP的優缺點

（1）TCP缺點

• 三次握手四次揮手，傳輸更多包，浪費一些帶寬。
• 為了進行可靠通信，雙方都要維持在線，服務器server可能出現非常大的并發連接，浪費了系統資源，甚至會出現宕機。
• 確認重傳也會浪費一些帶寬，且在不好的網絡中，會不斷的斷開和連接，降低了傳輸效率。

（2）UDP優點

• 沒有握手，起步快延時小。
• 不需要維持雙方在線，server不用維護巨量并發連接，節省了系統資源。
• 沒有重傳機制，在不影響使用的情況下，能更高效的利用網絡帶寬。

?

4、簡述三次握手和四次握手

內容部分源于https://blog.csdn.net/qzcsu/article/details/72861891，很棒的一篇博文。

一些符號含義

（1）序號：seq序號，占32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。

（2）確認序號：ack序號，占32位，只有ACK標志位為1時，確認序號字段才有效，ack=seq+1。

（3）標志位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義如下：

• URG：緊急指針（urgent pointer）有效。
• ACK：確認序號有效。
• PSH：接收方應該盡快將這個報文交給應用層。
• RST：重置連接。
• SYN：發起一個新連接。
• FIN：釋放一個連接。

需要注意：不要將確認序號ack與標志位中的ACK搞混了；確認方ack=發起方req+1，兩端配對。

（1）三次握手

最開始的時候客戶端和服務器都是處于CLOSED狀態。主動打開連接的為客戶端，被動打開連接的是服務器。

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狀態，此后雙方就可以開始通信了。

為什么TCP客戶端最后還要發送一次確認呢？

一句話，主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。

如果使用的是兩次握手建立連接，假設有這樣一種場景，客戶端發送了第一個請求連接并且沒有丟失，只是因為在網絡結點中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸數據，然后關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費。

如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文并且回復了確認報文，但是客戶端不會再次發出確認。由于服務器收不到確認，就知道客戶端并沒有請求連接。

?

（2）四次揮手

數據傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處于ESTABLISHED狀態，然后客戶端主動關閉，服務器被動關閉。

客戶端進程發出連接釋放報文，并且停止發送數據。釋放數據報文首部，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連接的時間要比客戶端早一些。

為什么客戶端最后還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設置不同的MSL值。

第一，保證客戶端發送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，于是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器。

第二，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。

為什么建立連接是三次握手，關閉連接確是四次揮手呢？

建立連接的時候， 服務器在LISTEN狀態下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發送給客戶端。
而關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。

如果已經建立了連接，但是客戶端突然出現故障了怎么辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

?

總結

以上是生活随笔為你收集整理的TCP相关的面试内容整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。