以下內(nèi)容源于網(wǎng)絡(luò)資料的學(xué)習(xí)整理。很多資料網(wǎng)上都有，但只有整理過一遍才屬于自己的。

參考博客

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

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

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

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

?

1、OSI參考模型和TCP模型

ISO制定的OSI參考模型的過于龐大復(fù)雜，招致了許多批評。（記憶：應(yīng)、表示、會、傳輸、網(wǎng)絡(luò)，數(shù)據(jù)、物理）

與此對照，由技術(shù)人員自己開發(fā)的TCP/IP協(xié)議棧獲得了更為廣泛的應(yīng)用。

? ? ?

在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合并到應(yīng)用層實現(xiàn)）。同時將OSI參考模型中的數(shù)據(jù)鏈路層和物理層合并為主機(jī)到網(wǎng)絡(luò)層。

（1）主機(jī)到網(wǎng)絡(luò)層

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

（2）網(wǎng)絡(luò)互連層　　

網(wǎng)絡(luò)互連層是整個TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標(biāo)網(wǎng)絡(luò)或主機(jī)。同時，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時進(jìn)行分組傳遞。因此，分組到達(dá)的順序和發(fā)送的順序可能不同，這就需要上層必須對分組進(jìn)行排序。　　

網(wǎng)絡(luò)互連層定義了分組格式和協(xié)議，即IP協(xié)議（Internet Protocol）。　　

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

（3）傳輸層　　

在TCP/IP模型中，傳輸層的功能是使源端主機(jī)和目標(biāo)端主機(jī)上的對等實體可以進(jìn)行會話。

在傳輸層定義了兩種服務(wù)質(zhì)量不同的協(xié)議：傳輸控制協(xié)議TCP（transmission control protocol）、用戶數(shù)據(jù)報協(xié)議UDP（user datagram protocol）。

TCP協(xié)議是一個面向連接的、可靠的協(xié)議。它將一臺主機(jī)發(fā)出的字節(jié)流無差錯地發(fā)往互聯(lián)網(wǎng)上的其他主機(jī)。在發(fā)送端，它負(fù)責(zé)把上層傳送下來的字節(jié)流分成報文段并傳遞給下層。在接收端，它負(fù)責(zé)把收到的報文進(jìn)行重組后遞交給上層。TCP協(xié)議還要處理端到端的流量控制，以避免緩慢接收的接收方?jīng)]有足夠的緩沖區(qū)接收發(fā)送方發(fā)送的大量數(shù)據(jù)。　　

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

（4）應(yīng)用層

TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應(yīng)用層實現(xiàn)。

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

?

2、簡述TCP為何可靠？

（1）確認(rèn)和重傳機(jī)制

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

（2）數(shù)據(jù)排序

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

（3）流量控制

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

（4）擁塞控制

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

?

3、簡述TCP和UDP的優(yōu)缺點

（1）TCP缺點

• 三次握手四次揮手，傳輸更多包，浪費一些帶寬。
• 為了進(jìn)行可靠通信，雙方都要維持在線，服務(wù)器server可能出現(xiàn)非常大的并發(fā)連接，浪費了系統(tǒng)資源，甚至?xí)霈F(xiàn)宕機(jī)。
• 確認(rèn)重傳也會浪費一些帶寬，且在不好的網(wǎng)絡(luò)中，會不斷的斷開和連接，降低了傳輸效率。

（2）UDP優(yōu)點

• 沒有握手，起步快延時小。
• 不需要維持雙方在線，server不用維護(hù)巨量并發(fā)連接，節(jié)省了系統(tǒng)資源。
• 沒有重傳機(jī)制，在不影響使用的情況下，能更高效的利用網(wǎng)絡(luò)帶寬。

?

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

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

一些符號含義

（1）序號：seq序號，占32位，用來標(biāo)識從TCP源端向目的端發(fā)送的字節(jié)流，發(fā)起方發(fā)送數(shù)據(jù)時對此進(jìn)行標(biāo)記。

（2）確認(rèn)序號：ack序號，占32位，只有ACK標(biāo)志位為1時，確認(rèn)序號字段才有效，ack=seq+1。

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

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

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

（1）三次握手

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

TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB，時刻準(zhǔn)備接受客戶進(jìn)程的連接請求，此時服務(wù)器就進(jìn)入了LISTEN（監(jiān)聽）狀態(tài)；

TCP客戶進(jìn)程也是先創(chuàng)建傳輸控制塊TCB，然后向服務(wù)器發(fā)出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進(jìn)程進(jìn)入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號。

TCP服務(wù)器收到請求報文后，如果同意連接，則發(fā)出確認(rèn)報文。確認(rèn)報文中應(yīng)該 ACK=1，SYN=1，確認(rèn)號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP服務(wù)器進(jìn)程進(jìn)入了SYN-RCVD（同步收到）狀態(tài)。這個報文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號。

TCP客戶進(jìn)程收到確認(rèn)后，還要向服務(wù)器給出確認(rèn)。確認(rèn)報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進(jìn)入ESTABLISHED（已建立連接）狀態(tài)。TCP規(guī)定，ACK報文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號。

當(dāng)服務(wù)器收到客戶端的確認(rèn)后也進(jìn)入ESTABLISHED狀態(tài)，此后雙方就可以開始通信了。

為什么TCP客戶端最后還要發(fā)送一次確認(rèn)呢？

一句話，主要防止已經(jīng)失效的連接請求報文突然又傳送到了服務(wù)器，從而產(chǎn)生錯誤。

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

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

?

（2）四次揮手

數(shù)據(jù)傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端和服務(wù)器都是處于ESTABLISHED狀態(tài)，然后客戶端主動關(guān)閉，服務(wù)器被動關(guān)閉。

客戶端進(jìn)程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，FIN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，FIN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。

服務(wù)器收到連接釋放報文，發(fā)出確認(rèn)報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

客戶端收到服務(wù)器的確認(rèn)請求后，此時，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。

服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，FIN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。

客戶端收到服務(wù)器的連接釋放報文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。

服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時間要比客戶端早一些。

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

MSL（Maximum Segment Lifetime），TCP允許不同的實現(xiàn)可以設(shè)置不同的MSL值。

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

第二，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中。客戶端發(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

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

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

如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

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

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。