1、TCP/IP 模型

• TCP/IP 協(xié)議模型，包含了一系列構(gòu)成互聯(lián)網(wǎng)基礎(chǔ)的網(wǎng)絡(luò)協(xié)議，是 Internet 的核心協(xié)議。
• 基于 TCP/IP 協(xié)議?？煞譃樗膶踊蛭鍖?，轉(zhuǎn)換為 OSI 參考模型，可以分為七層，分別如下圖所示：
  
• 通常我們所說(shuō)的都是基于 TCP/TP 五層模型。

2、TCP/IP 協(xié)議棧每一層功能

• 應(yīng)用層：HTTP、FTP 等等我們熟悉的協(xié)議。
• 傳輸層：TCP 和 UDP 協(xié)議、HTTPS。
• 網(wǎng)絡(luò)層：IP 協(xié)議，它負(fù)責(zé)對(duì)數(shù)據(jù)加上 IP 地址和其他的數(shù)據(jù)以確定傳輸?shù)哪繕?biāo)。
• 數(shù)據(jù)鏈路層：為待傳送的數(shù)據(jù)加入一個(gè)以太網(wǎng)協(xié)議頭，并進(jìn)行 CRC 編碼，為最后的數(shù)據(jù)傳輸做準(zhǔn)備。
• 物理層：二進(jìn)制數(shù)據(jù)流傳輸。

3、IP 協(xié)議

• IP 協(xié)議 是TCP/IP 協(xié)議的核心，所有的 TCP、UDP、ICMP、IGCP 的數(shù)據(jù)都以 IP 數(shù)據(jù)格式傳輸。要注意的是，IP 不是可靠的協(xié)議，這是說(shuō)，IP 協(xié)議沒(méi)有提供一種數(shù)據(jù)未傳達(dá)以后的處理機(jī)制，這被認(rèn)為是上層協(xié)議 TCP 或 UDP 要做的事情。
• IP 協(xié)議屬于面向無(wú)連接協(xié)議。

4、IP 分片與重組

• 對(duì)于不同的數(shù)據(jù)鏈路，其最大傳輸單元（MTU，單位字節(jié)）不同。當(dāng) IP 數(shù)據(jù)包中的字節(jié)數(shù)無(wú)法在一個(gè)幀中發(fā)送，路由器就會(huì)將此 IP 數(shù)據(jù)報(bào)劃分成數(shù)個(gè)片。而這種分片處理只要路由器認(rèn)為有必要，就會(huì)周而復(fù)始的進(jìn)行。
• 經(jīng)過(guò)分片之后的 IP 數(shù)據(jù)報(bào)只能由目標(biāo)主機(jī)進(jìn)行重組，路由器不會(huì)處理。（如果路由器要處理重組的話(huà)，到下個(gè)路由器也可能被分片，這樣就會(huì)降低傳送效率。）
• 路徑 MTU 發(fā)現(xiàn)技術(shù)：路徑 MTU 是指從發(fā)送端主機(jī)到接收端主機(jī)之間不需要分片時(shí)最大的 MTU 大小。即路徑中存在的所有數(shù)據(jù)鏈路中最小的 MTU。該技術(shù)可以避免在中途的路由器上進(jìn)行分片處理，也可以針對(duì)傳輸層發(fā)送更大的包。提高傳送效率與網(wǎng)絡(luò)利用率，降低分片丟失分險(xiǎn)。

5、相關(guān)協(xié)議

• DNS：將網(wǎng)址轉(zhuǎn)換為 IP。即域名解析，通過(guò)域名服務(wù)器查詢(xún)網(wǎng)址對(duì)應(yīng)的 IP。
• ARP：將 IP 定位到對(duì)應(yīng)的 MAC 地址。（通過(guò)廣播發(fā)送一個(gè)ARP請(qǐng)求包（包含目標(biāo)I P 地址），發(fā)送到鏈路上的所有主機(jī)或者路由器，如果某個(gè)節(jié)點(diǎn)的 IP 與其一致，則將自己的 MAC 地址塞入 ARP 響應(yīng)包中返回給發(fā)送者。）
• RARP：將 MAC 對(duì)應(yīng)上 IP 地址。（需要對(duì)應(yīng)的 RARP 服務(wù)器，當(dāng)物理設(shè)備接入后，告訴服務(wù)器自己的 MAC 地址，然后服務(wù)器分配對(duì)應(yīng)的 IP 地址。）
• ICMP：確認(rèn) IP 包是否成功到達(dá)目標(biāo)地址，通知在發(fā)送過(guò)程中 IP 包被廢棄的具體原因，改善網(wǎng)絡(luò)設(shè)置等。當(dāng)某個(gè)路由器持有 IP 包，且發(fā)現(xiàn)問(wèn)題后，如未能發(fā)現(xiàn)目標(biāo)主機(jī)存在，則會(huì)像發(fā)送方反饋一個(gè) ICMP 包，說(shuō)明問(wèn)題原因。
• DCHP：為設(shè)備自動(dòng)設(shè)置 IP 地址，統(tǒng)一管理 IP 地址分配。實(shí)現(xiàn)即插即用?；?DCHP 服務(wù)器，將要分配的 IP 地址、相應(yīng)的子網(wǎng)掩碼、路由控制信息、DNS 服務(wù)器的地址等設(shè)置到服務(wù)器上，設(shè)備接入后，就自動(dòng)為其分配事先配置的 IP 地址。
• NAT：將本地網(wǎng)絡(luò)中的私有地址，在連接互聯(lián)網(wǎng)時(shí)轉(zhuǎn)而使用全局 IP 地址的技術(shù)。通過(guò) NAT 路由映射私有 IP 地址與全局 IP 地址。

5、TCP/UDP

• TCP/UDP 都是是傳輸層協(xié)議，但是兩者具有不同的特性，同時(shí)也具有不同的應(yīng)用場(chǎng)景，下面以圖表的形式對(duì)比分析。

• 面向字節(jié)流：面向字節(jié)流的話(huà)，雖然應(yīng)用程序和 TCP 的交互是一次一個(gè)數(shù)據(jù)塊（大小不等），但 TCP 把應(yīng)用程序看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。TCP 有一個(gè)緩沖，當(dāng)應(yīng)用程序傳送的數(shù)據(jù)塊太長(zhǎng)，TCP 就可以把它劃分短一些再傳送。
• 面向報(bào)文：面向報(bào)文的傳輸方式是應(yīng)用層交給 UDP 多長(zhǎng)的報(bào)文，UDP 發(fā)送多長(zhǎng)的報(bào)文，即一次發(fā)送一個(gè)報(bào)文。因此應(yīng)用程序必須選擇合適大小的報(bào)文，若報(bào)文太長(zhǎng)，則 IP 層需要分片，降低效率，若太短，會(huì)使 IP 數(shù)據(jù)報(bào)太小。

6、什么時(shí)候使用 TCP？什么時(shí)候使用 UDP？

• 當(dāng)對(duì)網(wǎng)絡(luò)通訊質(zhì)量有要求的時(shí)候，比如：整個(gè)數(shù)據(jù)要準(zhǔn)確無(wú)誤的傳遞給對(duì)方，這往往用于一些要求可靠的應(yīng)用，比如： HTTP、HTTPS、FTP 等傳輸文件的協(xié)議，POP、SMTP 等郵件傳輸?shù)膮f(xié)議。
• 當(dāng)對(duì)網(wǎng)絡(luò)通訊質(zhì)量要求不高的時(shí)候，要求網(wǎng)絡(luò)通訊速度能盡量的快，這時(shí)就可以使用 UDP，比如：微信語(yǔ)音、微信視頻、直播等。

7、TCP 連接的建立與終止

（1）TCP 三次捂手建立連接

• 三次握手的主要作用：確認(rèn)雙方的接收能力和發(fā)送能力是否正常、指定自己的初始序列號(hào)（ISN）為后面的可靠性傳輸做準(zhǔn)備。

• TCP是面向連接的，無(wú)論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，連接是通過(guò)三次握手進(jìn)行初始化的。三次握手的目的是同步連接雙方的序列號(hào)和確認(rèn)號(hào)并交換 TCP窗口大小信息。
  

• 第一次握手：客戶(hù)端向服務(wù)端發(fā)送一個(gè) SYN 報(bào)文（SYN = 1），并指明客戶(hù)端的初始序列號(hào) ISN(x)，即圖中的 seq = x，表示本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)。此時(shí)客戶(hù)端處于 SYN 發(fā)送(SYN_Send)狀態(tài)。

• 第二次握手：服務(wù)器收到客戶(hù)端的 SYN 報(bào)文之后，會(huì)發(fā)送 SYN 和 ACK 報(bào)文作為應(yīng)答（SYN = 1 , ACK = 1），并且指定自己的初始序列號(hào) ISN(y)，即圖中的 seq = y。同時(shí)會(huì)把客戶(hù)端的 ISN + 1 作為確認(rèn)號(hào) ack 的值，表示已經(jīng)收到了客戶(hù)端發(fā)來(lái)的的 SYN 報(bào)文，希望收到的下一個(gè)數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是 x + 1，此時(shí)服務(wù)器處于 SYN 收到(SYN_RECV => SYN_RECEIVED)的狀態(tài)。

• 第三次握手：客戶(hù)端收到服務(wù)器端響應(yīng)的 SYN 報(bào)文之后，會(huì)發(fā)送一個(gè) ACK 報(bào)文，也是一樣把服務(wù)器的 ISN + 1 作為 ack 的值，表示已經(jīng)收到了服務(wù)端發(fā)來(lái)的的 SYN 報(bào)文，希望收到的下一個(gè)數(shù)據(jù)的第一個(gè)字節(jié)的序號(hào)是 y + 1，并指明此時(shí)客戶(hù)端的序列號(hào) seq = x + 1（初始為 seq = x，所以第二個(gè)報(bào)文段要 +1），此時(shí)客戶(hù)端處于建立連接(ESTABLISHED)狀態(tài)，同時(shí)服務(wù)器收到 ACK 報(bào)文之后，也處于建立連接(ESTABLISHED)狀態(tài)，至此雙方建立起了 TCP 連接。

（2）TCP 四次揮手釋放連接

• 當(dāng)客戶(hù)端和服務(wù)端通過(guò)三次握手建立了 TCP 連接以后，且數(shù)據(jù)傳送完畢，肯定是要斷開(kāi) TCP 連接的。那對(duì)于TCP的斷開(kāi)連接，這里就有了神秘的“四次揮手”。

• 注意：客戶(hù)端和服務(wù)端均可主動(dòng)發(fā)起揮手動(dòng)作。
  

• 第一次揮手：客戶(hù)端發(fā)送一個(gè) FIN 報(bào)文（請(qǐng)求連接終止：FIN = 1），報(bào)文中會(huì)指定一個(gè)序列號(hào) seq = u。并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP 連接。此時(shí)客戶(hù)端處于 FIN_WAIT1 狀態(tài)，等待服務(wù)端的確認(rèn)。

• 第二次揮手：服務(wù)端收到 FIN 之后，會(huì)發(fā)送 ACK 報(bào)文，且把客戶(hù)端的序列號(hào)值 u + 1 作為 ACK 報(bào)文的序列號(hào)值，表明已經(jīng)收到客戶(hù)端的報(bào)文了，此時(shí)服務(wù)端處于 CLOSE_WAIT 狀態(tài)。此時(shí)的 TCP 處于半關(guān)閉狀態(tài)，客戶(hù)端到服務(wù)端的連接釋放。客戶(hù)端收到服務(wù)端的確認(rèn)后，進(jìn)入FIN_WAIT2（終止等待 2）狀態(tài)，等待服務(wù)端發(fā)出的連接釋放報(bào)文段。

• 第三次揮手：如果服務(wù)端也想斷開(kāi)連接了（沒(méi)有要向客戶(hù)端發(fā)出的數(shù)據(jù)），和客戶(hù)端的第一次揮手一樣，發(fā)送 FIN 報(bào)文，且指定一個(gè)序列號(hào)。此時(shí)服務(wù)端處于 LAST_ACK 的狀態(tài)，等待客戶(hù)端的確認(rèn)。

• 第四次揮手：客戶(hù)端收到 FIN 之后，一樣發(fā)送一個(gè) ACK 報(bào)文作為應(yīng)答（ack = w+1），且把服務(wù)端的序列值 +1 作為自己 ACK 報(bào)文的序號(hào)值（seq=u+1），此時(shí)客戶(hù)端處于 TIME_WAIT （時(shí)間等待）狀態(tài)，等待 2MSL（一個(gè)報(bào)文的來(lái)回時(shí)間）后依然沒(méi)有收到回復(fù)，則證明服務(wù)端已經(jīng)正常關(guān)閉，那么客戶(hù)端也可以關(guān)閉連接了。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-657925.html

8、為什么要三次握手？為什么不能進(jìn)行兩次握手連接？

• 三次握手最主要的目的是需要確認(rèn)客戶(hù)端和服務(wù)端都有發(fā)送和接受的能力。
• 如果只采用兩次捂手，服務(wù)端不能判斷客戶(hù)端是否能接受數(shù)據(jù)的能力，并且如果采用兩次握手的話(huà)，已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，服務(wù)端返回確認(rèn)報(bào)文段給客戶(hù)端，以為雙方再次確立連接，等待客戶(hù)端的數(shù)據(jù)。但客戶(hù)端實(shí)際上并沒(méi)有發(fā)送連接請(qǐng)求報(bào)文段，不會(huì)傳送數(shù)據(jù)給服務(wù)端，服務(wù)端就會(huì)等著，浪費(fèi)資源。（雖說(shuō) TCP 還有?；钣?jì)時(shí)器）

9、ISN（初始序列號(hào)）是固定的嗎？

• 不是固定的，三次握手的其中一個(gè)重要功能是客戶(hù)端和服務(wù)端交換 ISN（初始序列號(hào)），以便讓對(duì)方知道接下來(lái)接收數(shù)據(jù)的時(shí)候如何按序列號(hào)組裝數(shù)據(jù)。
• 當(dāng)一端為建立連接而發(fā)送它的 SYN 時(shí)，它會(huì)為連接選擇一個(gè)初始序號(hào)。ISN 隨時(shí)間而變化，因此每個(gè)連接都將具有不同的 ISN。如果 ISN 是固定的，攻擊者很容易猜出后續(xù)的確認(rèn)號(hào)，因此 ISN 是動(dòng)態(tài)生成的。

10、三次握手過(guò)程中可以攜帶數(shù)據(jù)嗎？

• 第三次握手的時(shí)候是可以攜帶數(shù)據(jù)，但是第一次和第二次絕對(duì)不可以攜帶數(shù)據(jù)。
• 假如第一次握手可以攜帶數(shù)據(jù)的話(huà)，如果有人要惡意攻擊服務(wù)器，那他每次都在第一次握手中的 SYN 報(bào)文中放入大量的數(shù)據(jù)，然后瘋狂重復(fù)發(fā) SYN 報(bào)文的話(huà)（因?yàn)楣粽吒揪筒挥霉芊?wù)器的接收、發(fā)送能力是否正常，它就是要攻擊你），這會(huì)讓服務(wù)器花費(fèi)很多時(shí)間、內(nèi)存空間來(lái)接收這些報(bào)文。而對(duì)于第三次的話(huà)，此時(shí)客戶(hù)端已經(jīng)處于建立連接狀態(tài)（ESTABLISHED），并且也已經(jīng)知道服務(wù)器的接收、發(fā)送能力是正常的了，所以當(dāng)然能正常發(fā)送/攜帶數(shù)據(jù)了。

11、什么叫半連接隊(duì)列？

• 服務(wù)器第一次收到客戶(hù)端的 SYN 之后，就會(huì)處于 SYN 收到狀態(tài)（SYN_RCVD），此時(shí)雙方還沒(méi)有完全建立其連接，服務(wù)器會(huì)把這種狀態(tài)下的請(qǐng)求連接放在一個(gè)隊(duì)列里，我們把這種隊(duì)列稱(chēng)之為半連接隊(duì)列。
• 當(dāng)然還有一個(gè)全連接隊(duì)列，完成三次握手后建立起的連接就會(huì)放在全連接隊(duì)列中。如果隊(duì)列滿(mǎn)了就有可能會(huì)出現(xiàn)丟包現(xiàn)象。

12、什么是 SYN 洪泛攻擊？

• SYN 攻擊就是客戶(hù)端在短時(shí)間內(nèi)偽造大量不存在的 IP 地址，并向服務(wù)端不斷地發(fā)送 SYN 包，服務(wù)端則回復(fù)確認(rèn)包，并等待客戶(hù)端確認(rèn)，由于源地址不存在，因此服務(wù)端需要不斷重發(fā)直至超時(shí)，這些偽造的 SYN 包將長(zhǎng)時(shí)間占用半連接隊(duì)列，導(dǎo)致正常的 SYN 請(qǐng)求因?yàn)殛?duì)列滿(mǎn)而被丟棄，從而引起網(wǎng)絡(luò)擁塞甚至系統(tǒng)癱瘓。

13、如果第三次握手丟失了，客戶(hù)端服務(wù)端會(huì)如何處理？

• 服務(wù)器發(fā)送完 SYN-ACK 包，如果未收到客戶(hù)端響應(yīng)的確認(rèn)包，也即第三次握手丟失。那么服務(wù)器就會(huì)進(jìn)行首次重傳，若等待一段時(shí)間仍未收到客戶(hù)確認(rèn)包，就進(jìn)行第二次重傳。如果重傳次數(shù)超過(guò)系統(tǒng)規(guī)定的最大重傳次數(shù)，則系統(tǒng)將該連接信息從半連接隊(duì)列中刪除。
• 注意，每次重傳等待的時(shí)間不一定相同，一般會(huì)是指數(shù)增長(zhǎng)，例如間隔時(shí)間為 1s，2s，4s，8s…

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

• TCP 設(shè)置有一個(gè)?；钣?jì)時(shí)器，服務(wù)器每一次收到數(shù)據(jù)就會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，若計(jì)時(shí)器走完，沒(méi)有收到客戶(hù)端的數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送探測(cè)報(bào)文，75秒一個(gè)探測(cè)報(bào)文，連續(xù)10個(gè)探測(cè)報(bào)文沒(méi)有收到回復(fù)，就認(rèn)為客戶(hù)端故障，斷開(kāi)連接。

15、為什么要四次揮手？

• TCP 協(xié)議是一種面向連接的、可靠的、基于字節(jié)流的運(yùn)輸層通信協(xié)議，且 TCP 是全雙工模式，這就意味著當(dāng)客戶(hù)端發(fā)出 FIN 報(bào)文段時(shí)，只是表示客戶(hù)端數(shù)據(jù)已全部發(fā)送完畢了，但是這個(gè)時(shí)候客戶(hù)端還是可以接受來(lái)自服務(wù)端的數(shù)據(jù)；當(dāng)服務(wù)端返回 ACK 報(bào)文段時(shí)，表示它已經(jīng)知道客戶(hù)端沒(méi)有數(shù)據(jù)發(fā)送了，但是服務(wù)端還是可以發(fā)送數(shù)據(jù)到客戶(hù)端的；當(dāng)服務(wù)端也發(fā)送了 FIN 報(bào)文段時(shí)，這個(gè)時(shí)候就表示服務(wù)端也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴客戶(hù)端我也沒(méi)有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次 TCP 連接。

16、為什么第四次揮手要等待 2MSL？

• MSL：報(bào)文段最大生存時(shí)間，它是任何報(bào)文段被丟棄前在網(wǎng)絡(luò)內(nèi)的最長(zhǎng)時(shí)間。
• 原因有二：（1）保證 TCP 協(xié)議的全雙工連接能夠可靠關(guān)閉；（2）保證本次連接的所有數(shù)據(jù)從網(wǎng)絡(luò)中消失。
• 第一點(diǎn)：如果客戶(hù)端直接關(guān)閉了，那么由于 IP 協(xié)議的不可靠性或者是其它網(wǎng)絡(luò)原因，導(dǎo)致服務(wù)端沒(méi)有收到客戶(hù)端最后回復(fù)的 ACK 報(bào)文。那么服務(wù)端就會(huì)在超時(shí)之后繼續(xù)發(fā)送 FIN，此時(shí)由于客戶(hù)端已經(jīng)關(guān)閉了，就找不到與重發(fā)的 FIN 對(duì)應(yīng)的連接。所以客戶(hù)端不是直接進(jìn)入關(guān)閉狀態(tài)，而是要保持 TIME_WAIT 狀態(tài)。當(dāng)再次收到 FIN 的時(shí)候，能夠保證對(duì)方收到 ACK，最后正確的關(guān)閉連接。
• 第二點(diǎn)：如果客戶(hù)端直接關(guān)閉，然后又再向服務(wù)端發(fā)起一個(gè)新連接，我們不能保證這個(gè)新連接與剛關(guān)閉的連接的端口號(hào)是不同的。也就是說(shuō)有可能新連接和老連接的端口號(hào)是相同的。一般來(lái)說(shuō)不會(huì)發(fā)生什么問(wèn)題，但是還是有特殊情況出現(xiàn)：假設(shè)新連接和已經(jīng)關(guān)閉的老連接端口號(hào)是一樣的，如果前一次連接的某些數(shù)據(jù)仍然滯留在網(wǎng)絡(luò)中（稱(chēng)為 Lost Duplicate），這些延遲數(shù)據(jù)在建立新連接之后才到達(dá)服務(wù)端，由于新連接和老連接的端口號(hào)是一樣的，TCP 協(xié)議就認(rèn)為那個(gè)延遲的數(shù)據(jù)是屬于新連接的，這樣就和真正的新連接的數(shù)據(jù)包發(fā)生混淆了。所以 TCP 連接要在 TIME_WAIT 狀態(tài)等待 2MSL，保證本次連接的所有數(shù)據(jù)都從網(wǎng)絡(luò)中消失。

17、打開(kāi)一個(gè)網(wǎng)頁(yè)會(huì)經(jīng)歷什么？

• 首先在瀏覽器地址欄輸入一個(gè) URL，然后瀏覽器根據(jù)你輸入的 URL 去查看瀏覽器緩存器緩存信息，如果緩存中有則直接從緩存中取出相對(duì)于的 IP 地址，如果沒(méi)有則進(jìn)行 DNS 域名解析，然后獲取到相對(duì)于的 IP 地址。
• 解析出 IP 地址后，再根據(jù) IP 地址和默認(rèn)端口跟服務(wù)端開(kāi)始嘗試建立 TCP 連接。
• 通過(guò) TCP 三次握手之后，成功與服務(wù)端建立連接，并發(fā)出響應(yīng)的數(shù)據(jù)請(qǐng)求。
• 服務(wù)端收到請(qǐng)求，并對(duì)瀏覽器做出相應(yīng)的響應(yīng)，并發(fā)送給瀏覽器。
• 通過(guò) TCP 四次揮手釋放連接。
• 瀏覽器收到 Response 數(shù)據(jù)，然后將數(shù)據(jù)解析并渲染到頁(yè)面上。

到了這里，關(guān)于【網(wǎng)絡(luò)協(xié)議】TCP/IP 協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！