經(jīng)過面試的同學(xué)經(jīng)常會遇到這樣的問題: 你是如何理解TCP/IP協(xié)議的,？

回答：通訊協(xié)議？三次握手 ? 四次揮手,？ 一臉懵逼,！

如果你感覺已經(jīng)被上述情景安排，那么有必要好好看看這篇文章,。

另外附上一篇tcp/ip面試中的問題視頻解答：面試中tcpip,，哪些容易被問到的及解答

1 、什么是協(xié)議

協(xié)議實際上就是一種約定,。好比說,，我們做一個石頭剪刀布的游戲，我們約定好：石頭>剪刀,、剪刀>布,、布>石頭，以此作為游戲規(guī)則。我們所有人都遵循這個約定,，那么就不需要任何的多余的溝通便可以完成這個游戲,。而這種方式形成的約定實際上就是一種協(xié)議了。

2,、TCP/IP協(xié)議簇

話聯(lián)網(wǎng)早期是,，盡管知道計算機連接的原理，但是沒有協(xié)議的時候,，就沒有辦法進行大規(guī)模的通信使用,。當(dāng)時就衍生出了很多為了解決當(dāng)時問題的協(xié)議，像TCP協(xié)議就是為了約定大家使用TCP連接時傳輸?shù)囊环N協(xié)議,，HTTP協(xié)議則是為了約定文本傳輸?shù)囊环N協(xié)議,。

而TCP/IP協(xié)議并不是指某一個具體的協(xié)議，它是指代一系列的協(xié)議棧,，因此也叫TCP/IP協(xié)議?；蛘逿CP/IP協(xié)議簇。

所以廣義上,，我們說的TCP/IP指的是4層的總和,。 而狹義上來說，指的是4層中的傳輸層和網(wǎng)絡(luò)互聯(lián)層,。

在 TCP/IP協(xié)議簇 中,，定義了包含對應(yīng) OSI 模型的每一層。但同時對 OSI 模型層做了簡化處理,?？纯催@種圖理解一下：

TCP/IP層和OSI參考模型層的對應(yīng)關(guān)系

也即是OSI模型中的7層,，在TCP/IP中使用4層代替了,。沒辦法，誰讓OSI那么復(fù)雜呢,。

在TCP/IP協(xié)議簇中每一層都有對應(yīng)的協(xié)議,，最終組成協(xié)議簇。

TCP/IP協(xié)議棧每一層的協(xié)議

我們經(jīng)常說的TCP和UDP在協(xié)議棧的傳輸層,，而IP協(xié)議則在協(xié)議棧的網(wǎng)絡(luò)互聯(lián)層。還有經(jīng)常被問到的HTTP協(xié)議實際上在協(xié)議棧的應(yīng)用層,。

TCP/IP協(xié)議棧被分作這么多的層級，目的是為了整理硬件間通信時的一個通用的模型,，因此它們每一層都和其上下層有關(guān)聯(lián)性的,，如下圖：

TCP/IP協(xié)議棧數(shù)據(jù)封包分層

上面就是'TCP/IP協(xié)議'的總體概念了,。但是其內(nèi)部還有這么多的協(xié)議,，這里挑幾個常見的講一講，從底層到上層:

IP協(xié)議

TCP協(xié)議

UDP協(xié)議

HTTP協(xié)議

2. 1 IP協(xié)議

IP協(xié)議處于TCP/IP協(xié)議簇的網(wǎng)絡(luò)互聯(lián)層,。它提供不可靠,、無連接的服務(wù)，也即依賴其他層的協(xié)議進行差錯控制,。在局域網(wǎng)環(huán)境,，IP協(xié)議往往被封裝在以太網(wǎng)幀中傳送。而所有的TCP,、UDP,、ICMP、IGMP數(shù)據(jù)都被封裝在IP數(shù)據(jù)包包中傳送,。

在IP協(xié)議中,，有兩個重要的內(nèi)容需要了解下。一是IP地址的概念,，二是IP協(xié)議的報頭,。

2.1.1 IP地址的概念

其實對于IP地址我們?nèi)粘＝佑|還是挺多的。它給每一個接入互聯(lián)網(wǎng)的計算器一個地址,，從而使得其他的計算機能夠訪問到它,。與此同時，當(dāng)計算機有了地址之后,，才能遵循IP協(xié)議,，和其他的計算機進行數(shù)據(jù)的傳遞。

目前有兩種IP版本,，分別是IPV4和IPV6,。IPV4占用8個字節(jié)32bit，而IPV6則是32個字節(jié)128bit,。IPV6的可用的數(shù)量極其龐大,，大到全球每一粒沙子都可以分配一個IPV6地址,。

以IPV4為例, IPV4的32bit地址中,分為兩個部分：網(wǎng)絡(luò)號和主機號。同時根據(jù)不同的內(nèi)容開頭,，又分為A,、B、C,、D,、E類。

IPV4

網(wǎng)絡(luò)號用于區(qū)分不同的網(wǎng)絡(luò)點,，比如一個公司是一個網(wǎng)絡(luò)集群，我們可以通過他的網(wǎng)絡(luò)號確定該公司網(wǎng)關(guān),，再通過主機號確定每一臺計算,。

假如一個C類的IP地址類型，包含了21位網(wǎng)絡(luò)號,，實際上就能區(qū)分出 2^21 個網(wǎng)絡(luò)號,，而在每一個網(wǎng)絡(luò)號中，可以區(qū)分 2^8 -2 = 254（起始的網(wǎng)絡(luò)號地址和最后一個為廣播地址都不可用于主機）個主機號,。如果一個網(wǎng)吧采用這種方式的話,，那么他最多能安裝254臺機器。如果我們想要得到更多的主機號,，應(yīng)該延長主機號的位數(shù),，但是相應(yīng)的，網(wǎng)絡(luò)號的數(shù)量將減少,，因為兩者的總長度是不變的,。

通過掩碼能夠改變網(wǎng)絡(luò)號和主機號的位數(shù)。

通常,，我們看到的掩碼類似：

二進制表示：

11111111.11111111.11111111.00000000

如果一個IPV4地址為：192.168.1.12 那么IP地址和掩碼經(jīng)過與運算之后的結(jié)果為：192.168.1.0（192.168.001.000）, 這就是我們常說的網(wǎng)關(guān),！ 而從 192.168.1.1~192.168.1.254都可作為主機號。也即是這個網(wǎng)關(guān)下,，可以容納 254 臺機器,。

如果將掩碼更改為：

二進制表示：

11111111.11111111.11111110.00000000

那么與運算的結(jié)果為：192.168.0.0 ，這時候可以使用的主機號就變成了 192.168.0.0 ~ 192.168.1.254, 即可容納 510 臺機器,。

2.1.2 IP尋址

當(dāng)一個 IP 包從一臺計算機被發(fā)送,，它會到達一個 IP 路由器。

IP 路由器負責(zé)將這個包路由至它的目的地,，直接地或者通過其他的路由器,。

在一個相同的通信中,，一個包所經(jīng)由的路徑可能會和其他的包不同。而路由器負責(zé)根據(jù)通信量,、網(wǎng)絡(luò)中的錯誤或者其他參數(shù)來進行正確地尋址,。

2.1.3 IP協(xié)議的報頭

在上面的數(shù)據(jù)分層中，我們看到IP協(xié)議的構(gòu)成實際上是 IP報頭 + TCP協(xié)議內(nèi)容,。

因此決定一個IP協(xié)議屬性的的關(guān)鍵是 IP報頭的內(nèi)容,。 下面我們來看下IP協(xié)議的組成，IPV4中普通的IP首部長20個字節(jié),。其中有32位的源IP地址和32位的目的IP地址。

TTL：生存時間,。代表了數(shù)據(jù)包可以經(jīng)過的最多路由器數(shù),。比如TTL為10，意思是如果經(jīng)過10次路由器轉(zhuǎn)發(fā),，仍然未找到目的地址,，則報文丟棄

8位協(xié)議指示的是傳輸層承載的協(xié)議

16位總長度：指IP數(shù)據(jù)包的最大長度。16bit那么最長可達65535字節(jié),。但是通過鏈路的MTU不會有這么大,。因此如果數(shù)據(jù)包長度超過了MTU，數(shù)據(jù)包會被分片,。如果發(fā)生了分片,，則需要用到16位標識以及13位片偏移來找到分片的報文。

IP協(xié)議報頭

2.2 TCP協(xié)議

2.2.1 TCP協(xié)議作用

TCP協(xié)議位于協(xié)議棧的傳輸層,。當(dāng)應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)摹⒂?位字節(jié)表示的數(shù)據(jù)流,，TCP則把數(shù)據(jù)流分割成適當(dāng)長度的報文段,，最大傳輸段大小（MSS）通常受該計算機連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳送單元（MTU）限制,。之后TCP把數(shù)據(jù)包傳給IP層,，由它來通過網(wǎng)絡(luò)將包傳送給接收端實體的TCP層。

TCP為了保證報文傳輸?shù)目煽?，就給每個包一個序號,，同時序號也保證了傳送到接收端實體的包的按序接收。然后接收端實體對已成功收到的字節(jié)發(fā)回一個相應(yīng)的確認(ACK),；如果發(fā)送端實體在合理的往返時延(RTT)內(nèi)未收到確認,，那么對應(yīng)的數(shù)據(jù)（假設(shè)丟失了）將會被重傳,。

• 在數(shù)據(jù)正確性與合法性上，TCP用一個校驗和函數(shù)來檢驗數(shù)據(jù)是否有錯誤,，在發(fā)送和接收時都要計算校驗和,；同時可以使用md5認證對數(shù)據(jù)進行加密。

• 在保證可靠性上,，采用超時重傳和捎帶確認機制,。

• 在流量控制上，采用滑動窗口協(xié)議,，協(xié)議中規(guī)定,，對于窗口內(nèi)未經(jīng)確認的分組需要重傳。

在擁塞控制上,，采用廣受好評的TCP擁塞控制算法（也稱AIMD算法）,。 該算法主要包括三個主要部分： （1）加性增、乘性減,； （2）慢啟動,； （3）對超時事件做出反應(yīng)。

2.2.2 TCP的報頭

和IP協(xié)議一樣,，TCP協(xié)議也有他的報頭部分,。

以下即是圖示：

TCP報頭

• 源端口：發(fā)送方的端口號

• 目的端口：接受方的端口號

• 序號：發(fā)送方的序號

• 確認序號：接受方得到序號之后回復(fù)的確認序號

• TCP 首部長度：4 bits,，以32-bit字為單位,。TCP首部長短，也是TCP報文數(shù)據(jù)部分的偏移量,。范圍5~15,，即20 bytes ~ 60 bytes?？蛇x項部分最多允許40 bytes,。

標志位，標志位主要用戶標志該報文當(dāng)前的狀態(tài),。

URG：指示報文中有緊急數(shù)據(jù),，應(yīng)盡快傳送（相當(dāng)于高優(yōu)先級的數(shù)據(jù)）。 ACK：確認序號（AN）有效,。 PSH：接到后盡快交付給接收的應(yīng)用進程,。 RST：TCP連接中出現(xiàn)嚴重差錯（如主機崩潰），必須釋放連接,，再重新建立連接,。 SYN：處于TCP連接建立過程,。 FIN：發(fā)送端已完成數(shù)據(jù)傳輸，請求釋放連接,。

2.2.2 TCP協(xié)議的連接時候的三次握手

TCP是一個面向連接的協(xié)議,，在每一次傳輸數(shù)據(jù)前，客戶端和服務(wù)端需要進行連接,，這個鏈接就是著名的三次握手,。

第一次：客戶端向服務(wù)端發(fā)送一個 SYN（SEQ=x 客戶端序號）報文給服務(wù)器端，進入SYN_SEND狀態(tài),。

第二次：服務(wù)器端收到SYN報文,，回應(yīng)一個SYN （SEQ=y 服務(wù)端序號）ACK(ACK=x+1 確認號=客戶端序號+1）報文，進入SYN_RECV狀態(tài),。

第三次：客戶端收到服務(wù)器端的SYN報文,，回應(yīng)一個ACK(ACK=y+1）報文，進入Established狀態(tài),。

圖解：

TCP的三次握手

思考：為什么要進行三次握手,，而不是兩次呢,？ 比如在第一次握手之后，服務(wù)器進入準備狀態(tài),，然后發(fā)送消息給客戶端,，客戶端也進入準備狀態(tài)，這就完成了雙方的確認了,。

• 回答：兩次握手時,，服務(wù)器提前進入準備狀態(tài)之后，如果中途遇到網(wǎng)絡(luò)中斷,，消息并沒有傳回給客戶端,，客戶端將永遠接不到服務(wù)器的給入狀態(tài)，那么服務(wù)端將資源浪費在一個不存在的連接之上了,。

思考2：三次握手就很安全了嗎,？

• 回答：在三次握手過程中，Server發(fā)送SYN-ACK之后,，收到Client的ACK之前的TCP連接稱為半連接（half-open connect）,，此時Server處于SYN_RCVD狀態(tài)，當(dāng)收到ACK后,，Server轉(zhuǎn)入ESTABLISHED狀態(tài),。SYN攻擊就是Client在短時間內(nèi)偽造大量不存在的IP地址,，并向Server不斷地發(fā)送SYN包，Server回復(fù)確認包,，并等待Client的確認,，由于源地址是不存在的，因此,，Server需要不斷重發(fā)直至超時,，這些偽造的SYN包將長時間占用未連接隊列，導(dǎo)致正常的SYN請求因為隊列滿而被丟棄,，從而引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓,。SYN攻擊是一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單,，即當(dāng)Server上有大量半連接狀態(tài)且源IP地址是隨機的,，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現(xiàn)行：

2.2.3 TCP協(xié)議的斷開連接時候的四次揮手

既然TCP面向連接,，那么肯定也有斷開連接的操作,。一個TCP完整的斷開需要進行四次揮手。

第一次：客戶端向服務(wù)端發(fā)送 FIN + ACK 報文,，同時攜帶序號為 X,。 客戶端進入 FIN-WAIT1

第二次：服務(wù)器端回復(fù) ACK 報文。附帶序號Z和確認序號X+1,，表示服務(wù)器已經(jīng)接受到了客服端的報文,。但是由于服務(wù)器可能還在處理事務(wù)，因此,，報文并不會攜帶FIN標志,。狀態(tài)：CLOSE WAIT

第三次：在一段時間之后，服務(wù)器已經(jīng)處理完畢,，發(fā)送帶有 FIN和ACK的報文,，序號為Y，確認序號為 X + 1 ,。 狀態(tài)： ACK-LAST

第四次：客戶端發(fā)送ACK報文,，序號為 X+1，確認號Y+1 ,。 客戶端進入： TIME_WAIT,。服務(wù)端進圖CLOSE（初始狀態(tài)）

TCP四次揮手

思考：為什么建立連接是三次握手，而關(guān)閉連接卻是四次揮手呢,？

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

思考：為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài),？

• 原因有二：
  一、保證TCP協(xié)議的全雙工連接能夠可靠關(guān)閉
  二,、保證這次連接的重復(fù)數(shù)據(jù)段從網(wǎng)絡(luò)中消失

2.3 UDP協(xié)議

UDP協(xié)議全稱是用戶數(shù)據(jù)包協(xié)議,，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，兩者同處于協(xié)議棧的傳輸層,，和TCP不同的是,，UDP是一種無連接的協(xié)議。

因為UDP是無連接的,，所以相對來說,，UDP的報頭比TCP要簡單多了,。

UDP報頭

UDP 特點 （1） UDP是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接,，當(dāng)它想傳送時就簡單地去抓取來自應(yīng)用程序的數(shù)據(jù),，并盡可能快地把它扔到網(wǎng)絡(luò)上。在發(fā)送端,，UDP傳送數(shù)據(jù)的速度僅僅是受應(yīng)用程序生成數(shù)據(jù)的速度,、計算機的能力和傳輸帶寬的限制；在接收端,，UDP把每個消息段放在隊列中,，應(yīng)用程序每次從隊列中讀一個消息段。 （2） 由于傳輸數(shù)據(jù)不建立連接，因此也就不需要維護連接狀態(tài),，包括收發(fā)狀態(tài)等,，因此一臺服務(wù)機可同時向多個客戶機傳輸相同的消息。 （3） UDP信息包的標題很短,，只有8個字節(jié),，相對于TCP的20個字節(jié)信息包的額外開銷很小。 （4） 吞吐量不受擁擠控制算法的調(diào)節(jié),，只受應(yīng)用軟件生成數(shù)據(jù)的速率,、傳輸帶寬、源端和終端主機性能的限制,。 （5）UDP使用盡最大努力交付,，即不保證可靠交付，因此主機不需要維持復(fù)雜的鏈接狀態(tài)表（這里面有許多參數(shù)）,。 （6）UDP是面向報文的,。發(fā)送方的UDP對應(yīng)用程序交下來的報文，在添加首部后就向下交付給IP層,。既不拆分,，也不合并，而是保留這些報文的邊界,，因此,，應(yīng)用程序需要選擇合適的報文大小。

我們經(jīng)常使用“ping”命令來測試兩臺主機之間TCP/IP通信是否正常,，其實“ping”命令的原理就是向?qū)Ψ街鳈C發(fā)送UDP數(shù)據(jù)包,，然后對方主機確認收到數(shù)據(jù)包，如果數(shù)據(jù)包是否到達的消息及時反饋回來,，那么網(wǎng)絡(luò)就是通的,。

2.4 HTTP協(xié)議

HTTP協(xié)議名為超文本傳輸協(xié)議。這個協(xié)議在 TCP/IP 協(xié)議棧的應(yīng)用層,，因此我們無需操心HTTP是如何傳輸?shù)?，只需要關(guān)心，我們傳輸?shù)膬?nèi)容,，能否正確的被接收端識別,。

HTTP 基于TCP實現(xiàn)，簡單來說,，TCP協(xié)議負責(zé)可靠的內(nèi)容傳輸,，HTTP協(xié)議負責(zé)識別內(nèi)容，兩者本身不在一個層面,，沒有可比性,。

HTTP無狀態(tài)的意思是,，每一次的內(nèi)容解析是沒有關(guān)聯(lián)的。TCP有狀態(tài)是指兩端在連接過程的,。

HTTP包含兩種報文類型：請求報文,、響應(yīng)報文。請求報文用在客戶端對服務(wù)器的請求時使用的報文格式,，響應(yīng)用在服務(wù)器響應(yīng)請求的報文格式,。

2.4.1 HTTP協(xié)議請求消息結(jié)構(gòu)

客戶端發(fā)送一個HTTP請求到服務(wù)器的請求消息包括以下格式：請求行（request line）、請求頭部（header）,、空行和請求數(shù)據(jù)四個部分組成,，下圖給出了請求報文的一般格式。

HTTP請求消息體結(jié)構(gòu)

HTTP消息體主要包含以下實質(zhì)內(nèi)容（空格和換行也必不可少）：

請求方法 URL：統(tǒng)一資源定位符 HTTP請求頭部 HTTP請求體

以下是一個HTTP請求的例子：

HTTP請求實例

2.4.1.1 HTTP請求方法

HTTP包含了多種不同的請求方式，每一種請求方式用在不同的場景,。

HTTP請求方法

2.4.1.2 URL —— 統(tǒng)一資源定位符

URL由三部分組成：資源類型、存放資源的主機域名,、資源文件名,。

URL的一般語法格式為：

(帶方括號[]的為可選項)：

protocol :// hostname[:port] / path / [;parameters][?query]#fragment

protocol：https

hostname：baijiahao.baidu.com

parameters：id=1603848351636567407&wfr=spider&for=pc （使用&分割參數(shù)）

總結(jié)一下如下圖：

附一張解析圖

2.4.1.3 HTTP請求頭

請求頭中主要包含本次請求的附加信息,，其中常用的字段如：

• Accept： 指定客戶端能夠接收的內(nèi)容類型

• Accept-Encoding： 指定瀏覽器可以支持的web服務(wù)器返回內(nèi)容壓縮編碼類型。

• Accept-Language： 瀏覽器可接受的語言

• Content-Length 請求的內(nèi)容長度 如：Content-Length: 348

• Content-Type 請求的與實體對應(yīng)的MIME信息,，常用的類型

Date 請求發(fā)送的日期和時間
更多的請求頭字段參考 HTTP響應(yīng)頭和請求頭信息對照表

2.4.1.4 HTTP請求體

在整個報文中，請求頭之后，隔一行空格,，以下部分就是HTTP的請求體了,。 請求體是我們發(fā)送請求的時候需要傳給接收端的內(nèi)容。其格式需要和請求頭中的Content-Type對應(yīng),。不然會導(dǎo)致接受無法識別,。

如上圖中的請求題： name=tom&password=1234

2.4.2 HTTP響應(yīng)

HTTP的響應(yīng)同樣分為：響應(yīng)行、響應(yīng)頭,、響應(yīng)體,。和請求報文有點類似。

總體結(jié)構(gòu)如圖：

HTTP響應(yīng)報文

2.4.2.1 HTTP響應(yīng)行

響應(yīng)行中包含了HTTP的版本和本次請求的狀態(tài),。請求狀態(tài)的對應(yīng)值見 HTTP響應(yīng)碼大全.

2.4.2.2 HTTP響應(yīng)頭

響應(yīng)頭用于描述服務(wù)器的基本信信息、數(shù)據(jù)的描述,，這些信息將告知客戶端如何處理響應(yīng)題中的內(nèi)容,。

• Allow 服務(wù)器支持哪些請求方法（如GET、POST等）,。

• Content-Encoding 文檔的編碼（Encode）方法,。只有在解碼之后才可以得到Content-Type頭指定的內(nèi)容類型。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間,。Java的GZIPOutputStream可以很方便地進行g(shù)zip壓縮,，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它,。因此,，Servlet應(yīng)該通過查看Accept-Encoding頭（即request.getHeader('Accept-Encoding')）檢查瀏覽器是否支持gzip，為支持gzip的瀏覽器返回經(jīng)gzip壓縮的HTML頁面,，為其他瀏覽器返回普通頁面,。

• Content-Length 表示內(nèi)容長度。只有當(dāng)瀏覽器使用持久HTTP連接時才需要這個數(shù)據(jù),。如果你想要利用持久連接的優(yōu)勢,，可以把輸出文檔寫入 ByteArrayOutputStream，完成后查看其大小,，然后把該值放入Content-Length頭,，最后通過byteArrayStream.writeTo(response.getOutputStream()發(fā)送內(nèi)容。

• Content-Type 表示后面的文檔屬于什么MIME類型,。Servlet默認為text/plain,，但通常需要顯式地指定為text/html,。由于經(jīng)常要設(shè)置Content-Type，因此HttpServletResponse提供了一個專用的方法setContentType,。

2.4.2.3 HTTP響應(yīng)實體

響應(yīng)實體中包含的就是客戶端從服務(wù)器中獲取的數(shù)據(jù)了,。數(shù)據(jù)的格式和長度都會在響應(yīng)體頭中描述。

文末給大家分享一波Linux后臺服務(wù)器高階開發(fā)的學(xué)習(xí)視頻資料,，需要的朋友可以后臺私信【架構(gòu)】獲取