計(jì)算機(jī)網(wǎng)絡(luò)的各層協(xié)議及作用？

計(jì)算機(jī)網(wǎng)絡(luò)體系可以大致分為一下三種，OSI七層模型、TCP/IP四層模型和五層模型。

• OSI七層模型：大而全，但是比較復(fù)雜、而且是先有了理論模型，沒有實(shí)際應(yīng)用。
• TCP/IP四層模型：是由實(shí)際應(yīng)用發(fā)展總結(jié)出來的，從實(shí)質(zhì)上講，TCP/IP只有最上面三層，最下面一層沒有什么具體內(nèi)容，TCP/IP參考模型沒有真正描述這一層的實(shí)現(xiàn)。
• 五層模型：五層模型只出現(xiàn)在計(jì)算機(jī)網(wǎng)絡(luò)教學(xué)過程中，這是對(duì)七層模型和四層模型的一個(gè)折中，既簡(jiǎn)潔又能將概念闡述清楚。
  
  七層網(wǎng)絡(luò)體系結(jié)構(gòu)各層的主要功能：

• 應(yīng)用層：為應(yīng)用程序提供交互服務(wù)。在互聯(lián)網(wǎng)中的應(yīng)用層協(xié)議很多，如域名系統(tǒng)DNS，支持萬維網(wǎng)應(yīng)用的 HTTP 協(xié)議，支持電子郵件的 SMTP 協(xié)議等。

• 表示層：主要負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換，如加密解密、轉(zhuǎn)換翻譯、壓縮解壓縮等。

• 會(huì)話層：負(fù)責(zé)在網(wǎng)絡(luò)中的兩節(jié)點(diǎn)之間建立、維持和終止通信，如服務(wù)器驗(yàn)證用戶登錄便是由會(huì)話層完成的。

• 運(yùn)輸層：有時(shí)也譯為傳輸層，向主機(jī)進(jìn)程提供通用的數(shù)據(jù)傳輸服務(wù)。該層主要有以下兩種協(xié)議：

  • TCP：提供面向連接的、可靠的數(shù)據(jù)傳輸服務(wù)；
  • UDP：提供無連接的、盡最大努力的數(shù)據(jù)傳輸服務(wù)，但不保證數(shù)據(jù)傳輸?shù)目煽啃浴?/li>

• 網(wǎng)絡(luò)層：選擇合適的路由和交換結(jié)點(diǎn)，確保數(shù)據(jù)及時(shí)傳送。主要包括 IP 協(xié)議。

• 數(shù)據(jù)鏈路層：數(shù)據(jù)鏈路層通常簡(jiǎn)稱為鏈路層。將網(wǎng)絡(luò)層傳下來的 IP 數(shù)據(jù)包組裝成幀，并再相鄰節(jié)點(diǎn)的鏈路上傳送幀。

• 物理層：實(shí)現(xiàn)相鄰節(jié)點(diǎn)間比特流的透明傳輸，盡可能屏蔽傳輸介質(zhì)和通信手段的差異。

TCP和UDP的區(qū)別？

	UDP	TCP
是否連接	無連接	面向連接
是否可靠	不可靠傳輸，不使用流量控制和擁塞控制	可靠傳輸，使用流量控制和擁塞控制
是否有序	無序	有序，消息在傳輸過程中可能會(huì)亂序，TCP 會(huì)重新排序
傳輸速度	快	慢
連接對(duì)象個(gè)數(shù)	支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多交互通信	只能是一對(duì)一通信
傳輸方式	面向報(bào)文	面向字節(jié)流
首部開銷	首部開銷小，僅8字節(jié)	首部最小20字節(jié)，最大60字節(jié)
適用場(chǎng)景	適用于實(shí)時(shí)應(yīng)用（IP電話、視頻會(huì)議、直播等）	適用于要求可靠傳輸?shù)膽?yīng)用，例如文件傳輸

總結(jié)：TCP 用于在傳輸層有必要實(shí)現(xiàn)可靠傳輸?shù)那闆r，UDP 用于對(duì)高速傳輸和實(shí)時(shí)性有較高要求的通信。TCP 和 UDP 應(yīng)該根據(jù)應(yīng)用目的按需使用。

UDP 和 TCP 對(duì)應(yīng)的應(yīng)用場(chǎng)景是什么？

TCP 是面向連接，能保證數(shù)據(jù)的可靠性交付，因此經(jīng)常用于：

• FTP文件傳輸
• HTTP / HTTPS

UDP 面向無連接，它可以隨時(shí)發(fā)送數(shù)據(jù)，再加上UDP本身的處理既簡(jiǎn)單又高效，因此經(jīng)常用于：

• 包總量較少的通信，如 DNS 、SNMP等
• 視頻、音頻等多媒體通信
• 廣播通信

應(yīng)用層協(xié)議	應(yīng)用	傳輸層協(xié)議
SMTP	電子郵件	TCP
Telnet	遠(yuǎn)程終端接入	TCP
HTTP	萬維網(wǎng)	TCP
FTP	文件傳輸	TCP

應(yīng)用層協(xié)議	應(yīng)用	傳輸層協(xié)議
DNS	域名轉(zhuǎn)換	UDP
TFTP	文件傳輸	UDP
SNMP	網(wǎng)絡(luò)管理	UDP
NFS	遠(yuǎn)程文件服務(wù)器	UDP

詳細(xì)介紹一下 TCP 的三次握手機(jī)制？

• 第一次握手：客戶端請(qǐng)求建立連接，向服務(wù)端發(fā)送一個(gè)同步報(bào)文（SYN=1），同時(shí)選擇一個(gè)隨機(jī)數(shù) seq = x 作為初始序列號(hào)，并進(jìn)入 SYN_SENT 狀態(tài)，等待服務(wù)器確認(rèn)。

• 第二次握手：服務(wù)端收到連接請(qǐng)求報(bào)文后，如果同意建立連接，則向客戶端發(fā)送同步確認(rèn)報(bào)文（SYN=1，ACK=1），確認(rèn)號(hào)為 ack = x + 1，同時(shí)選擇一個(gè)隨機(jī)數(shù) seq = y 作為初始序列號(hào)，此時(shí)服務(wù)器進(jìn)入SYN_RECV 狀態(tài)。

• 第三次握手：客戶端收到服務(wù)端的確認(rèn)后，向服務(wù)端發(fā)送一個(gè)確認(rèn)報(bào)文（ACK=1），確認(rèn)號(hào)為 ack = y + 1，序列號(hào)為 seq = x + 1，客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)，完成三次握手。

為什么需要三次握手，而不是兩次？

• 一、防止已過期的連接請(qǐng)求報(bào)文突然又傳送到服務(wù)器，因而產(chǎn)生錯(cuò)誤和資源浪費(fèi)。
  在雙方兩次握手即可建立連接的情況下，假設(shè)客戶端發(fā)送 A 報(bào)文段請(qǐng)求建立連接，由于網(wǎng)絡(luò)原因造成 A 暫時(shí)無法到達(dá)服務(wù)器，服務(wù)器接收不到請(qǐng)求報(bào)文段就不會(huì)返回確認(rèn)報(bào)文段?？蛻舳嗽陂L(zhǎng)時(shí)間得不到應(yīng)答的情況下重新發(fā)送請(qǐng)求報(bào)文段 B，這次 B 順利到達(dá)服務(wù)器，服務(wù)器隨即返回確認(rèn)報(bào)文并進(jìn)入 ESTABLISHED 狀態(tài)，客戶端在收到確認(rèn)報(bào)文后也進(jìn)入 ESTABLISHED 狀態(tài)，雙方建立連接并傳輸數(shù)據(jù)，之后正常斷開連接。
  此時(shí)姍姍來遲的 A 報(bào)文段才到達(dá)服務(wù)器，服務(wù)器隨即返回確認(rèn)報(bào)文并進(jìn)入 ESTABLISHED 狀態(tài)，但是已經(jīng)進(jìn)入 CLOSED 狀態(tài)的客戶端無法再接受確認(rèn)報(bào)文段，更無法進(jìn)入 ESTABLISHED 狀態(tài)，這將導(dǎo)致服務(wù)器長(zhǎng)時(shí)間單方面等待，造成資源浪費(fèi)。

• 二、三次握手才能讓雙方均確認(rèn)自己和對(duì)方的發(fā)送和接收能力都正常。
  第一次握手：客戶端只是發(fā)送處請(qǐng)求報(bào)文段，什么都無法確認(rèn)，而服務(wù)器可以確認(rèn)自己的接收能力和對(duì)方的發(fā)送能力正常；
  第二次握手：客戶端可以確認(rèn)自己發(fā)送能力和接收能力正常，對(duì)方發(fā)送能力和接收能力正常；
  第三次握手：服務(wù)器可以確認(rèn)自己發(fā)送能力和接收能力正常，對(duì)方發(fā)送能力和接收能力正常；
  可見三次握手才能讓雙方都確認(rèn)自己和對(duì)方的發(fā)送和接收能力全部正常，這樣就可以愉快地進(jìn)行通信了。

• 三、告知對(duì)方自己的初始序號(hào)值，并確認(rèn)收到對(duì)方的初始序號(hào)值。
  TCP 實(shí)現(xiàn)了可靠的數(shù)據(jù)傳輸，原因之一就是 TCP 報(bào)文段中維護(hù)了序號(hào)字段和確認(rèn)序號(hào)字段，通過這兩個(gè)字段雙方都可以知道在自己發(fā)出的數(shù)據(jù)中，哪些是已經(jīng)被對(duì)方確認(rèn)接收的。這兩個(gè)字段的值會(huì)在初始序號(hào)值得基礎(chǔ)遞增，如果是兩次握手，只有發(fā)起方的初始序號(hào)可以得到確認(rèn)，而另一方的初始序號(hào)則得不到確認(rèn)。

為什么要三次握手，而不是四次？

三次握手已經(jīng)可以確認(rèn)雙方的發(fā)送接收能力正常，雙方都知道彼此已經(jīng)準(zhǔn)備好，而且也可以完成對(duì)雙方初始序號(hào)值得確認(rèn)，也就無需再第四次握手了。

• 第一次握手：服務(wù)端確認(rèn)“自己收、客戶端發(fā)”報(bào)文功能正常。
• 第二次握手：客戶端確認(rèn)“自己發(fā)、自己收、服務(wù)端收、客戶端發(fā)”報(bào)文功能正常，客戶端認(rèn)為連接已建立。
• 第三次握手：服務(wù)端確認(rèn)“自己發(fā)、客戶端收”報(bào)文功能正常，此時(shí)雙方均建立連接，可以正常通信。

什么是 SYN洪泛攻擊？如何防范？

SYN 洪泛攻擊屬于 DOS 攻擊的一種，它利用 TCP 協(xié)議缺陷，通過發(fā)送大量的半連接請(qǐng)求，耗費(fèi) CPU 和內(nèi)存資源。

原理：

• 在三次握手過程中，第二步：服務(wù)器發(fā)送 [SYN/ACK] 包（第二個(gè)包）之后、收到客戶端的 [ACK] 包（第三個(gè)包）之前的 TCP 連接稱為半連接（half-open connect），此時(shí)服務(wù)器處于 SYN_RECV（同步已收到，等待客戶端響應(yīng)）狀態(tài)。如果接收到客戶端的 [ACK]，則 TCP 連接成功，如果未接受到，則會(huì)不斷重發(fā)請(qǐng)求直至成功。
• SYN 攻擊的攻擊者在短時(shí)間內(nèi)偽造大量不存在的 IP 地址，向服務(wù)器不斷地發(fā)送 [SYN] 包，服務(wù)器回復(fù) [SYN/ACK] 包，并等待客戶的確認(rèn)。由于源地址是不存在的，服務(wù)器需要不斷的重發(fā)直至超時(shí)。
• 這些偽造的 [SYN] 包將長(zhǎng)時(shí)間占用未連接隊(duì)列，影響了正常的 SYN，導(dǎo)致目標(biāo)系統(tǒng)運(yùn)行緩慢、網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓。

檢測(cè)：當(dāng)在服務(wù)器上看到大量的半連接狀態(tài)時(shí)，特別是源 IP 地址是隨機(jī)的，基本上可以斷定這是一次 SYN 攻擊。

防范：

• 通過防火墻、路由器等過濾網(wǎng)關(guān)防護(hù)。
• 通過加固 TCP/IP 協(xié)議棧防范，如增加最大半連接數(shù)，縮短超時(shí)時(shí)間。
• SYN cookies技術(shù)。SYN Cookies 是對(duì) TCP 服務(wù)器端的三次握手做一些修改，專門用來防范 SYN 洪泛攻擊的一種手段。

三次握手連接階段，最后一次ACK包丟失，會(huì)發(fā)生什么？

服務(wù)端：

• 第三次的ACK在網(wǎng)絡(luò)中丟失，那么服務(wù)端該TCP連接的狀態(tài)為 SYN_RECV （同步已收到）,并且會(huì)根據(jù) TCP的超時(shí)重傳機(jī)制，會(huì)等待3秒、6秒、12秒后重新發(fā)送 SYN+ACK 包，以便客戶端重新發(fā)送 ACK 包。
• 如果重發(fā)指定次數(shù)之后，仍然未收到 客戶端的ACK應(yīng)答，那么一段時(shí)間后，服務(wù)端自動(dòng)關(guān)閉這個(gè)連接。

客戶端：

客戶端認(rèn)為這個(gè)連接已經(jīng)建立，如果客戶端向服務(wù)端發(fā)送數(shù)據(jù)，服務(wù)端將以 RST包（Reset，標(biāo)示復(fù)位，用于異常的關(guān)閉連接）響應(yīng)。此時(shí)，客戶端知道第三次握手失敗。

詳細(xì)介紹一下 TCP 的四次揮手過程？

• 第一次揮手：客戶端向服務(wù)端發(fā)送連接釋放報(bào)文（FIN=1，ACK=1），主動(dòng)關(guān)閉連接，同時(shí)等待服務(wù)端的確認(rèn)。

  • 序列號(hào) seq = m，即客戶端上次發(fā)送的報(bào)文的最后一個(gè)字節(jié)的序號(hào) + 1
  • 確認(rèn)號(hào) ack = n, 即服務(wù)端上次發(fā)送的報(bào)文的最后一個(gè)字節(jié)的序號(hào) + 1

• 第二次揮手：服務(wù)端收到連接釋放報(bào)文后，立即發(fā)出確認(rèn)報(bào)文（ACK=1），序列號(hào) seq = n，確認(rèn)號(hào) ack = m + 1。

  • 這時(shí) TCP 連接處于半關(guān)閉狀態(tài)，即客戶端到服務(wù)端的連接已經(jīng)釋放了，但是服務(wù)端到客戶端的連接還未釋放。這表示客戶端已經(jīng)沒有數(shù)據(jù)發(fā)送了，但是服務(wù)端可能還要給客戶端發(fā)送數(shù)據(jù)。

• 第三次揮手：服務(wù)端向客戶端發(fā)送連接釋放報(bào)文（FIN=1，ACK=1），主動(dòng)關(guān)閉連接，同時(shí)等待 A 的確認(rèn)。

  • 序列號(hào) seq = p，即服務(wù)端上次發(fā)送的報(bào)文的最后一個(gè)字節(jié)的序號(hào) + 1。
  • 確認(rèn)號(hào) ack = m + 1，與第二次揮手相同，因?yàn)檫@段時(shí)間客戶端沒有發(fā)送數(shù)據(jù)

• 第四次揮手：客戶端收到服務(wù)端的連接釋放報(bào)文后，立即發(fā)出確認(rèn)報(bào)文（ACK=1），序列號(hào) seq = m + 1，確認(rèn)號(hào)為 ack = p + 1。

  • 此時(shí)，客戶端就進(jìn)入了 TIME-WAIT 狀態(tài)。注意此時(shí)客戶端到 TCP 連接還沒有釋放，必須經(jīng)過 2*MSL（最長(zhǎng)報(bào)文段壽命）的時(shí)間后，才進(jìn)入 CLOSED 狀態(tài)。而服務(wù)端只要收到客戶端發(fā)出的確認(rèn)，就立即進(jìn)入 CLOSED 狀態(tài)。可以看到，服務(wù)端結(jié)束 TCP 連接的時(shí)間要比客戶端早一些。

為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？

服務(wù)器在收到客戶端的 FIN 報(bào)文段（第一次揮手）后，可能還有一些數(shù)據(jù)要傳輸，所以不能馬上關(guān)閉連接，但是會(huì)做出應(yīng)答，返回 ACK 報(bào)文段（第二次揮手）。接下來可能會(huì)繼續(xù)發(fā)送數(shù)據(jù)，在數(shù)據(jù)發(fā)送完后，服務(wù)器會(huì)向客戶端發(fā)送 FIN 報(bào)文（第三次揮手），表示數(shù)據(jù)已經(jīng)發(fā)送完畢，請(qǐng)求關(guān)閉連接。服務(wù)器的 ACK和FIN一般都會(huì)分開發(fā)送，從而導(dǎo)致多了一次，因此一共需要四次揮手。

為什么客戶端的 TIME-WAIT 狀態(tài)必須等待 2MSL （最長(zhǎng)報(bào)文段壽命）？

1. 確保 ACK 報(bào)文能夠到達(dá)服務(wù)端，從而使服務(wù)端正常關(guān)閉連接。
   第四次揮手時(shí)，客戶端第四次揮手的 ACK 報(bào)文不一定會(huì)到達(dá)服務(wù)端。服務(wù)端會(huì)超時(shí)重傳 FIN/ACK 報(bào)文，此時(shí)如果客戶端已經(jīng)斷開了連接，那么就無法響應(yīng)服務(wù)端的二次請(qǐng)求，這樣服務(wù)端遲遲收不到 FIN/ACK 報(bào)文的確認(rèn)，就無法正常斷開連接。

   MSL 是報(bào)文段在網(wǎng)絡(luò)上存活的最長(zhǎng)時(shí)間?？蛻舳说却?2MSL 時(shí)間，即【客戶端 ACK 報(bào)文 1MSL 超時(shí) + 服務(wù)端 FIN 報(bào)文 1MSL 傳輸】，就能夠收到服務(wù)端重傳的 FIN/ACK 報(bào)文，然后客戶端重傳一次 ACK 報(bào)文，并重新啟動(dòng) 2MSL 計(jì)時(shí)器。如此保證服務(wù)端能夠正常關(guān)閉。

   如果服務(wù)端重發(fā)的 FIN 沒有成功地在 2MSL 時(shí)間里傳給客戶端，服務(wù)端則會(huì)繼續(xù)超時(shí)重試直到斷開連接。

2. 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在之后的連接中。

   TCP 要求在 2MSL 內(nèi)不使用相同的序列號(hào)。
   客戶端在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過時(shí)間 2MSL，就可以保證本連接持續(xù)的時(shí)間內(nèi)產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段。或者即使收到這些過時(shí)的報(bào)文，也可以不處理它。

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

通過定時(shí)器 + 超時(shí)重試機(jī)制，嘗試獲取確認(rèn)，直到最后會(huì)自動(dòng)斷開連接。具體而言，TCP 設(shè)有一個(gè)?；钣?jì)時(shí)器。服務(wù)器每收到一次客戶端的數(shù)據(jù)，都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為 2 小時(shí)。
若 2 小時(shí)還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就開始重試：每隔 75 分鐘發(fā)送一個(gè)探測(cè)報(bào)文段，若一連發(fā)送 10 個(gè)探測(cè)報(bào)文后客戶端依然沒有回應(yīng)，那么服務(wù)器就認(rèn)為連接已經(jīng)斷開了。

TIME-WAIT 狀態(tài)過多會(huì)產(chǎn)生什么后果？怎樣處理？

從服務(wù)器來講，短時(shí)間內(nèi)關(guān)閉了大量的 Client 連接，就會(huì)造成服務(wù)器上出現(xiàn)大量的 TIME_WAIT 連接，嚴(yán)重消耗著服務(wù)器的資源，此時(shí)部分客戶端就會(huì)顯示連接不上。
從客戶端來講，客戶端 TIME_WAIT 過多，就會(huì)導(dǎo)致端口資源被占用，因?yàn)槎丝诰?65536 個(gè)，被占滿就會(huì)導(dǎo)致無法創(chuàng)建新的連接。
解決辦法：

• 服務(wù)器可以設(shè)置 SO_REUSEADDR 套接字選項(xiàng)來避免 TIME_WAIT狀態(tài)，此套接字選項(xiàng)告訴內(nèi)核，即使此端口正忙（處于
  TIME_WAIT狀態(tài)），也請(qǐng)繼續(xù)并重用它。

• 調(diào)整系統(tǒng)內(nèi)核參數(shù)，修改/etc/sysctl.conf文件，即修改net.ipv4.tcp_tw_reuse 和 tcp_timestamps

  # 表示開啟重用。允許將 TIME-WAIT sockets 重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；
  net.ipv4.tcp_tw_reuse = 1 
  # 表示開啟 TCP 連接中 TIME-WAIT sockets 的快速回收，默認(rèn)為0，表示關(guān)閉。
  net.ipv4.tcp_tw_recycle = 1 
  

• 強(qiáng)制關(guān)閉，發(fā)送 RST 包越過 TIME_WAIT狀態(tài)，直接進(jìn)入CLOSED狀態(tài)。RST包是用于強(qiáng)制關(guān)閉TCP連接的，當(dāng)主機(jī)需要盡快關(guān)閉連接（或連接超時(shí)，端口或主機(jī)不可達(dá)）時(shí)，就會(huì)發(fā)送RST包。

TIME_WAIT 是服務(wù)器端的狀態(tài)?還是客戶端的狀態(tài)?

TIME_WAIT 是主動(dòng)斷開連接的一方會(huì)進(jìn)入的狀態(tài)，一般情況下，都是客戶端所處的狀態(tài)；服務(wù)器端一般設(shè)置不主動(dòng)關(guān)閉連接。

TIME_WAIT 需要等待 2MSL，在大量短連接的情況下，TIME_WAIT 會(huì)太多，這也會(huì)消耗很多系統(tǒng)資源。對(duì)于服務(wù)器來說，在 HTTP 協(xié)議里指定 KeepAlive（瀏覽器重用一個(gè) TCP 連接來處理多個(gè) HTTP 請(qǐng)求），由瀏覽器來主動(dòng)斷開連接，可以一定程度上減少服務(wù)器的這個(gè)問題。

TCP協(xié)議如何保證可靠性？

TCP主要提供了檢驗(yàn)和、序列號(hào)/確認(rèn)應(yīng)答、超時(shí)重傳、滑動(dòng)窗口、擁塞控制和流量控制等方法實(shí)現(xiàn)了可靠性傳輸。

• 檢驗(yàn)和：通過檢驗(yàn)和的方式，接收端可以檢測(cè)出來數(shù)據(jù)是否有差錯(cuò)和異常，假如有差錯(cuò)就會(huì)直接丟棄TCP段，重新發(fā)送。

• 序列號(hào)/確認(rèn)應(yīng)答：

  序列號(hào)的作用不僅僅是應(yīng)答的作用，有了序列號(hào)能夠?qū)⒔邮盏降臄?shù)據(jù)根據(jù)序列號(hào)排序，并且去掉重復(fù)序列號(hào)的數(shù)據(jù)。
  TCP傳輸?shù)倪^程中，每次接收方收到數(shù)據(jù)后，都會(huì)對(duì)傳輸方進(jìn)行確認(rèn)應(yīng)答。也就是發(fā)送ACK報(bào)文，這個(gè)ACK報(bào)文當(dāng)中帶有對(duì)應(yīng)的確認(rèn)序列號(hào)，告訴發(fā)送方，接收到了哪些數(shù)據(jù)，下一次的數(shù)據(jù)從哪里發(fā)。

• 滑動(dòng)窗口：滑動(dòng)窗口既提高了報(bào)文傳輸?shù)男?#xff0c;也避免了發(fā)送方發(fā)送過多的數(shù)據(jù)而導(dǎo)致接收方無法正常處理的異常。

• 超時(shí)重傳：超時(shí)重傳是指發(fā)送出去的數(shù)據(jù)包到接收到確認(rèn)包之間的時(shí)間，如果超過了這個(gè)時(shí)間會(huì)被認(rèn)為是丟包了，需要重傳。最大超時(shí)時(shí)間是動(dòng)態(tài)計(jì)算的。

• 擁塞控制：在數(shù)據(jù)傳輸過程中，可能由于網(wǎng)絡(luò)狀態(tài)的問題，造成網(wǎng)絡(luò)擁堵，此時(shí)引入擁塞控制機(jī)制，在保證 TCP 可靠性的同時(shí)，提高性能。

• 流量控制：如果主機(jī) A 一直向主機(jī) B 發(fā)送數(shù)據(jù)，不考慮主機(jī) B 的接受能力，則可能導(dǎo)致主機(jī) B 的接受緩沖區(qū)滿了而無法再接受數(shù)據(jù)，從而會(huì)導(dǎo)致大量的數(shù)據(jù)丟包，引發(fā)重傳機(jī)制。而在重傳的過程中，若主機(jī) B 的接收緩沖區(qū)情況仍未好轉(zhuǎn)，則會(huì)將大量的時(shí)間浪費(fèi)在重傳數(shù)據(jù)上，降低傳送數(shù)據(jù)的效率。所以引入流量控制機(jī)制，主機(jī) B 通過告訴主機(jī) A 自己接收緩沖區(qū)的大小，來使主機(jī) A 控制發(fā)送的數(shù)據(jù)量。流量控制與TCP協(xié)議報(bào)頭中的窗口大小有關(guān)。

詳細(xì)講一下TCP的滑動(dòng)窗口？

在進(jìn)行數(shù)據(jù)傳輸時(shí)，如果傳輸?shù)臄?shù)據(jù)比較大，就需要拆分為多個(gè)數(shù)據(jù)包進(jìn)行發(fā)送。TCP 協(xié)議需要對(duì)數(shù)據(jù)進(jìn)行確認(rèn)后，才可以發(fā)送下一個(gè)數(shù)據(jù)包。這樣一來，就會(huì)在等待確認(rèn)應(yīng)答包環(huán)節(jié)浪費(fèi)時(shí)間。為了避免這種情況，TCP引入了窗口概念。窗口大小指的是不需要等待確認(rèn)應(yīng)答包而可以繼續(xù)發(fā)送數(shù)據(jù)包的最大值。

滑動(dòng)窗口左邊的是已發(fā)送并且被確認(rèn)的分組，滑動(dòng)窗口右邊是還沒有輪到的分組。

滑動(dòng)窗口里面也分為兩塊：一塊是已經(jīng)發(fā)送但是未被確認(rèn)的分組，另一塊是窗口內(nèi)等待發(fā)送的分組。
隨著已發(fā)送的分組不斷被確認(rèn)，窗口內(nèi)等待發(fā)送的分組也會(huì)不斷被發(fā)送。整個(gè)窗口就會(huì)往右移動(dòng)，讓還沒輪到的分組進(jìn)入窗口內(nèi)。

可以看到滑動(dòng)窗口起到了一個(gè)限流的作用，也就是說當(dāng)前滑動(dòng)窗口的大小決定了當(dāng)前 TCP 發(fā)送包的速率，而滑動(dòng)窗口的大小取決于擁塞控制窗口和流量控制窗口的兩者間的最小值。

詳細(xì)講一下?lián)砣刂?#xff1f;

TCP 一共使用了四種算法來實(shí)現(xiàn)擁塞控制：

• 慢開始 (slow-start)；

• 擁塞避免 (congestion avoidance)；

• 快速重傳 (fast retransmit)；

• 快速恢復(fù) (fast recovery)。

發(fā)送方維持一個(gè)叫做擁塞窗口cwnd（congestion window）的狀態(tài)變量。當(dāng)當(dāng)cwnd的值減小到擁塞窗口縮小起始閾值 cwndssthresh時(shí)，改用擁塞避免算法。

慢開始：不要一開始就發(fā)送大量的數(shù)據(jù)，由小到大逐漸增加擁塞窗口的大小。

擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長(zhǎng)，即每經(jīng)過一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd+1 而不是加倍。這樣擁塞窗口按線性規(guī)律緩慢增長(zhǎng)。

快重傳：我們可以剔除一些不必要的擁塞報(bào)文，提高網(wǎng)絡(luò)吞吐量。比如接收方在收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)，而不要等到自己發(fā)送數(shù)據(jù)時(shí)捎帶確認(rèn)。快重傳規(guī)定：發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對(duì)方尚未收到的報(bào)文段，而不必繼續(xù)等待設(shè)置的重傳計(jì)時(shí)器時(shí)間到期。

快恢復(fù)：主要是配合快重傳。當(dāng)發(fā)送方連續(xù)收到三個(gè)重復(fù)確認(rèn)時(shí)，就執(zhí)行 “乘法減小” 算法，把ssthresh門限減半（為了預(yù)防網(wǎng)絡(luò)發(fā)生擁塞），但接下來并不執(zhí)行慢開始算法，因?yàn)槿绻W(wǎng)絡(luò)出現(xiàn)擁塞的話就不會(huì)收到好幾個(gè)重復(fù)的確認(rèn)，收到三個(gè)重復(fù)確認(rèn)說明網(wǎng)絡(luò)狀況還可以。