1. 網(wǎng)絡(luò)模型

1.1 OSI 七層參考模型

七層模型，亦稱 OSI（Open System Interconnection）參考模型，即開放式系統(tǒng)互聯(lián)，是網(wǎng)絡(luò)通信的標(biāo)準(zhǔn)模型。一般稱為 OSI 參考模型或七層模型。

它是一個(gè)七層的、抽象的模型體，不僅包括一系列抽象的術(shù)語或概念，也包括具體的協(xié)議。

1. 物理層：負(fù)責(zé)傳輸原始的比特流，數(shù)模轉(zhuǎn)換、模數(shù)轉(zhuǎn)換。
2. 數(shù)據(jù)鏈路層：負(fù)責(zé)在直接相連的節(jié)點(diǎn)之間可靠地傳輸數(shù)據(jù)幀，進(jìn)行錯(cuò)誤檢測(cè)和糾正，以及定義物理地址（MAC地址）。
3. 網(wǎng)絡(luò)層：負(fù)責(zé)在網(wǎng)絡(luò)中的不同節(jié)點(diǎn)之間進(jìn)行數(shù)據(jù)包的傳輸和路由選擇，使用邏輯地址（IP地址）進(jìn)行尋址。
4. 傳輸層：負(fù)責(zé)提供端到端的數(shù)據(jù)傳輸服務(wù)，確保數(shù)據(jù)可靠地傳輸，處理數(shù)據(jù)分段和重組，提供差錯(cuò)恢復(fù)和流量控制等功能。
5. 會(huì)話層：負(fù)責(zé)建立、管理和終止應(yīng)用程序之間的會(huì)話（Session），提供數(shù)據(jù)同步和會(huì)話恢復(fù)等功能。
6. 表示層：負(fù)責(zé)數(shù)據(jù)的格式化和解析，進(jìn)行數(shù)據(jù)的加密和解密，以及處理數(shù)據(jù)的壓縮和轉(zhuǎn)換等操作。
7. 應(yīng)用層：負(fù)責(zé)提供網(wǎng)絡(luò)應(yīng)用程序之間的通信服務(wù)，包括文件傳輸、電子郵件、遠(yuǎn)程登錄等各種應(yīng)用。

1.2 TCP/IP模型

TCP/IP模型，是?絡(luò)通信的事實(shí)模型，?下?上分為四層：

1. 數(shù)據(jù)鏈路層
2. ?絡(luò)層
3. 傳輸層
4. 應(yīng)?層

TCP/IP模型是工程中實(shí)際使用的模型，在工程實(shí)現(xiàn)中只需要關(guān)注傳輸層、應(yīng)用層即可！

TCP/IP模型體系結(jié)構(gòu)如下：

面試問題：OSI 模型與 TCP/IP 模型的區(qū)別是什么？

OSI（Open Systems Interconnection，開放系統(tǒng)互聯(lián)），是?絡(luò)通信的標(biāo)準(zhǔn)模型，但是TCP/IP模型是事實(shí)模型，對(duì)OSI模型進(jìn)?了簡(jiǎn)化。

TCP/IP模型與之的區(qū)別在于：下2層物理層和數(shù)據(jù)鏈路層合并為數(shù)據(jù)鏈路層；上3層會(huì)話層、表示層、應(yīng)?層合并為應(yīng)?層；

套接字（Socket）作為傳輸層以下?絡(luò)的封裝，為上?三層提供了統(tǒng)?的接口。之所以這么做，有如下好處：

1）上三層?于處理應(yīng)?的業(yè)務(wù)細(xì)節(jié)，?不關(guān)注通信細(xì)節(jié)，差異性較?；下四層實(shí)現(xiàn)通信細(xì)節(jié)，?不關(guān)注業(yè)務(wù)細(xì)節(jié)，更加通?；

2）上三層通常處于?戶進(jìn)程內(nèi)，?下四層作為OS內(nèi)核的?部分提供；

1.3 TCP/IP協(xié)議族

面試問題：TCP/IP包含哪些協(xié)議？分別有什么作?？

（1）傳輸層協(xié)議：

1. TCP：Transmission Control Protocol，傳輸控制協(xié)議。?個(gè)?向連接的協(xié)議，提供可靠全雙?字節(jié)流（全雙工（Full Duplex）是一種通信方式，允許數(shù)據(jù)同時(shí)在兩個(gè)方向上進(jìn)行雙向傳輸，即發(fā)送端和接收端可以同時(shí)發(fā)送和接收數(shù)據(jù)。），使?流套接字（流套接字適用于需要可靠數(shù)據(jù)傳輸和雙向通信的場(chǎng)景，如文件傳輸、HTTP通信等）。具有消息確認(rèn)、超時(shí)、重傳等機(jī)制；
2. UDP：User Datagram Protocol，?戶數(shù)據(jù)報(bào)協(xié)議。?個(gè)?連接協(xié)議，使?數(shù)據(jù)報(bào)套接字（數(shù)據(jù)報(bào)套接字適用于對(duì)實(shí)時(shí)性要求較高、對(duì)數(shù)據(jù)傳輸順序和可靠性要求較低的場(chǎng)景，如音視頻傳輸、DNS查詢等），不能保證消息遞送?定成功；
3. SCTP：Stream Control Transmission Protocol，流控制傳輸協(xié)議。提供可靠全雙??向連接的協(xié)議。SCTP是多宿的，通信的兩端可以涉及多組（IP，端?）通信。提供消息服務(wù)；（SCTP和TCP的主要區(qū)別是SCTP提供了多流和多宿的能力）

（2）網(wǎng)絡(luò)層協(xié)議：

1. IPv4：Internet Protocol version 4，使?32位地址（可用地址有限）；
2. ICMP：Internet Control Message Protocol，?絡(luò)控制消息協(xié)議，處理主機(jī)和路由之間的消息通信；
3. IGMP：Internet Group Management Protocol，?絡(luò)組管理協(xié)議，?于?播通信；
4. ARP：Address Resolution Protocol，地址解析協(xié)議，把IPv4地址映射成?個(gè)硬件地址（MAC地址），?于?播?絡(luò)；
5. RARP：Reverse Address Resolution Protocol，反向地址解析協(xié)議，把硬件地址（MAC地址）映射成IPv4地址；
6. IPv6：Internet Protocol version 6，使?64位地址（可用地址空間巨大）；
7. ICMPv6：Internet Control Message Protocol version 6，為IPv6協(xié)議提供地址解析、?絡(luò)組管理等功能，兼具ICMPv4、IGMP、ARP協(xié)議的功能；

（3）數(shù)據(jù)鏈路層協(xié)議（了解即可）：

1. BPF：BSD packet filter，BSD分組過濾器。提供數(shù)據(jù)鏈路層的訪問能?；（Berkeley內(nèi)核）；
2. DLPI：datalink provider interface，數(shù)據(jù)鏈路提供者接?。提供數(shù)據(jù)鏈路層的訪問能?；（SVR4內(nèi)核）；

1.4 TCP/UDP/SCTP協(xié)議

面試問題:TCP和UDP協(xié)議的區(qū)別是什么?

（1）UDP協(xié)議：無連接的傳輸協(xié)議，封裝應(yīng)用層數(shù)據(jù)到一個(gè)UDP數(shù)據(jù)報(bào)中，之后再將UDP數(shù)據(jù)報(bào)封裝到IP數(shù)據(jù)報(bào)中，發(fā)送出去；

1）UDP數(shù)據(jù)報(bào)具有長(zhǎng)度（消息長(zhǎng)度是用來告訴客戶端在讀取數(shù)據(jù)報(bào)時(shí)的起始和結(jié)束），消息長(zhǎng)度隨著報(bào)文傳遞到對(duì)端(而非TCP的流式消息)；

2）UDP協(xié)議不具備傳輸?shù)目煽啃?/span>：不提供確認(rèn)、序列號(hào)、R1TT估算、超時(shí)、重傳等機(jī)制；

1. 不保證UDP數(shù)據(jù)報(bào)一定到達(dá)最終目的地(無對(duì)端消息確認(rèn)機(jī)制、超時(shí)、重傳機(jī)制)；
2. 不保證各個(gè)UDP數(shù)據(jù)報(bào)到達(dá)目的地的先后順序(無消息序列號(hào))；
3. 不保證UDP數(shù)據(jù)報(bào)只送達(dá)一次(無消息序列號(hào))；

3）UDP協(xié)議是無連接的協(xié)議，兩端的套接字不具有綁定關(guān)系；

1. 一個(gè)UDP客戶端可以創(chuàng)建套接字并發(fā)送數(shù)據(jù)報(bào)給一個(gè)服務(wù)器，然后立即使用同一個(gè)套接字發(fā)送另一個(gè)數(shù)據(jù)報(bào)給另一個(gè)服務(wù)器；
2. 一個(gè)UDP服務(wù)端可以使用同一個(gè)套接字從若干個(gè)不同的客戶戶端接收數(shù)據(jù)報(bào)；

4）UDP協(xié)議是全雙工協(xié)議；

補(bǔ)充：

數(shù)據(jù)報(bào)（Datagram）和數(shù)據(jù)流（Stream）是在網(wǎng)絡(luò)通信中常用的兩種數(shù)據(jù)傳輸方式，它們有以下區(qū)別：

1）數(shù)據(jù)報(bào)（Datagram）：

?? - 數(shù)據(jù)報(bào)是一種面向無連接的傳輸方式，每個(gè)數(shù)據(jù)報(bào)都是獨(dú)立的、自包含的數(shù)據(jù)單元。

?? - 每個(gè)數(shù)據(jù)報(bào)都有自己的目標(biāo)地址和源地址，可以獨(dú)立地通過網(wǎng)絡(luò)進(jìn)行傳輸。

?? - 數(shù)據(jù)報(bào)的傳輸是不可靠的，可能會(huì)發(fā)生丟包、重復(fù)、亂序等問題。

?? - 例子：UDP（用戶數(shù)據(jù)報(bào)協(xié)議）使用數(shù)據(jù)報(bào)傳輸方式。

2）數(shù)據(jù)流（Stream）：

?? - 數(shù)據(jù)流是一種面向連接的傳輸方式，數(shù)據(jù)在發(fā)送端和接收端之間建立一個(gè)持久的、有序的字節(jié)流。

?? - 數(shù)據(jù)流是連續(xù)的、無邊界的字節(jié)序列，沒有明確的分割單位。

?? - 數(shù)據(jù)流的傳輸是可靠的，確保數(shù)據(jù)的有序、完整和無錯(cuò)誤地傳輸。

?? - 例子：TCP（傳輸控制協(xié)議）使用數(shù)據(jù)流傳輸方式。

數(shù)據(jù)報(bào)和數(shù)據(jù)流是兩種不同的數(shù)據(jù)傳輸方式。數(shù)據(jù)報(bào)是獨(dú)立的、自包含的數(shù)據(jù)單元，每個(gè)數(shù)據(jù)報(bào)都有自己的目標(biāo)地址和源地址，傳輸是不可靠的。數(shù)據(jù)流是建立在連接上的持久字節(jié)流，傳輸是可靠的，確保數(shù)據(jù)的有序、完整和無錯(cuò)誤傳輸。選擇使用哪種方式取決于具體的應(yīng)用需求和通信方式的特點(diǎn)。

（2）TCP協(xié)議：有連接協(xié)議，基于數(shù)據(jù)流，會(huì)將上層消息封裝為多個(gè)個(gè)分節(jié)，每個(gè)分節(jié)以一個(gè)IP數(shù)據(jù)報(bào)發(fā)送；

1）TCP協(xié)議基于數(shù)據(jù)流傳輸，本身沒有消息長(zhǎng)度；

2）TCP協(xié)議保證傳輸?shù)目煽啃?#xff08;更加可靠，而非100%可靠）；

1. 提供對(duì)端消息確認(rèn)機(jī)制：消息發(fā)出后等待對(duì)端確認(rèn)，才視作成功；
2. 提供超時(shí)和重傳機(jī)制：消息發(fā)送后，超過一定時(shí)間未收到確認(rèn)，則重發(fā)消息；直至成功或者超過指定重試時(shí)間；
3. 提供RTT估算：提供動(dòng)態(tài)估算客戶端與服務(wù)器之間的RTT(round-triptime)算法，以便知道一次RTT大概耗時(shí)；
4. 提供消息序列號(hào)：對(duì)個(gè)分節(jié)提供一個(gè)序列號(hào)(字節(jié)偏移量)，以便對(duì)端在收到消息時(shí)，根據(jù)序列號(hào)進(jìn)行消息的排序和去重；
5. 提供流量控制：提供通告窗口(advertised window)告知對(duì)端，當(dāng)前能夠接收多少數(shù)據(jù)；從而確保發(fā)送端發(fā)送的數(shù)據(jù)量不會(huì)使接收緩沖區(qū)溢出;通告窗口隨著消息的接收動(dòng)態(tài)變化，當(dāng)為0時(shí)，表示接收緩沖區(qū)已滿，需要等待應(yīng)用從緩沖區(qū)讀取數(shù)據(jù)后，才能再次從對(duì)端接收數(shù)據(jù)；即TCP負(fù)反饋機(jī)制，通過接收端的速率限制發(fā)送端的速率；

注：TCP協(xié)議并不能保證100%的可靠性，而是在盡可能保證可靠性的前提下，能夠讓上層感知消息傳遞的異常；

3）TCP協(xié)議是有連接協(xié)議，兩端必須先建立連接才可以通信；

4）TCP協(xié)議是全雙工(full-duplex)協(xié)議，給定連接上應(yīng)用可以在任何時(shí)刻即發(fā)送數(shù)據(jù)又接收數(shù)據(jù)；

（3）SCTP協(xié)議：有連接協(xié)議，提供可靠性、排序、流控、全雙工的為數(shù)據(jù)傳送；通過關(guān)聯(lián)(association)表示兩端的通信方式，一個(gè)連接只涉及兩個(gè)IP地址間的通信；而一個(gè)關(guān)聯(lián)指代兩端的第一次通信，但不一定是兩個(gè)IP地址間的通信；

1）SCTP是面向消息的，有消息長(zhǎng)度，各個(gè)消息按順序送達(dá)對(duì)端(TCP不具有消息長(zhǎng)度，依靠上層應(yīng)用自行設(shè)計(jì)應(yīng)用層協(xié)議的長(zhǎng)度)；

2）每個(gè)關(guān)聯(lián)包含多個(gè)流(連接)，單個(gè)流上消息丟失，不會(huì)阻塞其它流上消息的傳輸(TCP只具有單個(gè)流，會(huì)阻塞)；

3）SCTP提供多宿特性，即兩端能夠支持多個(gè)IP地址，一個(gè)端點(diǎn)可以有多個(gè)冗余連接，走不同的基礎(chǔ)設(shè)施，從而增強(qiáng)應(yīng)對(duì)網(wǎng)絡(luò)故障的健壯性；

補(bǔ)充：

在SCTP（流控制傳輸協(xié)議）中，多流（Multi-Stream）和多宿（Multi-Homing）是其特性之一，提供了更靈活和高效的數(shù)據(jù)傳輸能力。

1）多流（Multi-Stream）：

?? - 多流是指在單個(gè)SCTP連接中可以同時(shí)傳輸多個(gè)獨(dú)立的數(shù)據(jù)流。

?? - SCTP允許應(yīng)用程序在同一個(gè)SCTP連接上創(chuàng)建多個(gè)邏輯流，每個(gè)流都有自己的序列號(hào)和傳輸控制。

?? - 多流特性使得應(yīng)用程序可以將不同類型的數(shù)據(jù)分組到不同的流中，實(shí)現(xiàn)并行傳輸和優(yōu)化網(wǎng)絡(luò)資源利用。

?? - 應(yīng)用程序可以根據(jù)需要?jiǎng)?chuàng)建、選擇和管理多個(gè)流，以滿足不同數(shù)據(jù)流的需求。

2）多宿（Multi-Homing）：

?? - 多宿是指在SCTP連接中可以同時(shí)使用多個(gè)網(wǎng)絡(luò)接口或IP地址進(jìn)行通信。

?? - SCTP允許一個(gè)端點(diǎn)（主機(jī)）在多個(gè)網(wǎng)絡(luò)接口上綁定多個(gè)IP地址，并在通信過程中根據(jù)網(wǎng)絡(luò)狀況選擇合適的地址進(jìn)行數(shù)據(jù)傳輸。

?? - 多宿特性提供了冗余和負(fù)載均衡的能力，當(dāng)一個(gè)網(wǎng)絡(luò)接口或IP地址不可用時(shí)，可以自動(dòng)切換到其他可用的接口或地址。

?? - 應(yīng)用程序可以利用多宿特性提高連接的可靠性和可用性，適應(yīng)多網(wǎng)絡(luò)環(huán)境下的數(shù)據(jù)傳輸需求。

1.5 TCP協(xié)議

1.5.1 TCP建鏈：三次握手

面試問題：什么是TCP的三次握手？過程是怎樣的？

TCP建鏈的?致過程如下：

1）被動(dòng)打開（passive open）：服務(wù)端調(diào)?socket、bind、listen 3 個(gè)函數(shù)，啟動(dòng)監(jiān)聽；

2）主動(dòng)打開（active open）：客戶端調(diào)?connect函數(shù)連接服務(wù)端：客戶端發(fā)送SYN分節(jié)，告知客戶端發(fā)送初始序列號(hào)；SYN分節(jié)不攜帶數(shù)據(jù)，故其所在的IP數(shù)據(jù)報(bào)只包含?個(gè)IP頭、?個(gè)TCP頭和可選的TCP選項(xiàng)；

3）服務(wù)端發(fā)送ACK，確認(rèn)客戶端發(fā)來的SYN，同時(shí)發(fā)送??的SYN給客戶端，告知服務(wù)端發(fā)送初始序列號(hào)；

4）客戶端發(fā)送ACK，確認(rèn)服務(wù)端發(fā)來的SYN；

注1：服務(wù)端在同?個(gè)分節(jié)中發(fā)送ACK和SYN；

注2：服務(wù)端的初始序列化序列號(hào)和客戶端的初始化序列號(hào)是2個(gè)獨(dú)?字段，分別代表各?發(fā)送的消息序列號(hào)；

注3：每次發(fā)送SYN，都會(huì)攜帶當(dāng)前的序列號(hào)；每次回復(fù)ACK，都會(huì)攜帶下?次消息的序列號(hào)，即當(dāng)前序列號(hào)+1；

?

場(chǎng)景舉例：好像兩個(gè)?開始電話前，先確認(rèn)對(duì)?是否可以聽到

Client：你好，可以聽到嗎？（SYN）

Server：我可以聽到，你可以聽到嗎？（ACK + SYN）

Client：可以聽到（ACK）

... ...（開始后續(xù)談話）

什么是TCP選項(xiàng)？

TCP建鏈時(shí)，攜帶的連接控制參數(shù)。

TCP_MAXSEG：設(shè)置MSS（Max Segment Size），發(fā)送SYN時(shí)，告知對(duì)端可以接受的最?分節(jié)??；即在當(dāng)前連接中每個(gè)TCP分節(jié)中可以接受的最?數(shù)據(jù)量，接收SYN的?端會(huì)據(jù)此設(shè)置發(fā)送分節(jié)的 最???。通過TCP_MAXSEG設(shè)置；

SO_RCVBUF：設(shè)置接收緩沖區(qū)??，據(jù)此告知對(duì)端通告窗?的??；

SO_SNDBUF：設(shè)置發(fā)送緩沖區(qū)??；

1.5.2 TCP關(guān)閉連接：四次揮?

?試問題：什么是TCP的四次揮?？過程是怎樣的？

TCP關(guān)閉連接的過程：

1）主動(dòng)關(guān)閉（active close）：A端調(diào)?close函數(shù)，發(fā)送?個(gè)FIN分節(jié)，帶序列號(hào)，告知B端數(shù)據(jù)發(fā)送完畢；

2）被動(dòng)關(guān)閉（passive close）：B端收到FIN后，回復(fù)ACK分節(jié)給A端；同時(shí)將接收數(shù)據(jù)作為?個(gè)

EOF（?件結(jié)束符）傳遞給上層應(yīng)?，通知上層應(yīng)?數(shù)據(jù)發(fā)送完畢；

3）B端上層應(yīng)?收到EOF后，調(diào)?close函數(shù)，同樣發(fā)送?個(gè)FIN分節(jié)，告知A端數(shù)據(jù)發(fā)送完畢；

4）A端收到FIN分節(jié)后，回復(fù)?個(gè)ACK分節(jié)給B端；?此兩端都已關(guān)閉；

?

注1：之所以要兩端都發(fā)送FIN，是因?yàn)門CP是全雙?，兩端都可能發(fā)送數(shù)據(jù)，因此需要兩端都發(fā)送FIN，告知對(duì)端發(fā)送完畢；

注2：每次發(fā)送FIN，都會(huì)攜帶當(dāng)前的序列號(hào)；每次回復(fù)ACK，都會(huì)攜帶下?次消息的序列號(hào)，即當(dāng)前序列號(hào)+1；

注3：執(zhí)?完1），2）兩步后，被動(dòng)關(guān)閉的?端（B端）仍然可以向主動(dòng)關(guān)閉的?端（A端）發(fā)送數(shù)據(jù)，此時(shí)稱為半關(guān)閉（half-close）；

注4：當(dāng)?個(gè)Unix進(jìn)程?論?愿的終?（調(diào)?exit或者從main返回）還是??愿的終?（收到?個(gè)進(jìn)程終?信號(hào)），所有打開的?件句柄都會(huì)被關(guān)閉，這也會(huì)導(dǎo)致任何打開的TCP連接上也發(fā)送?個(gè)FIN分???? 節(jié)，告知對(duì)端關(guān)閉；（內(nèi)核?為，這也是進(jìn)程掛掉，?操作系統(tǒng)未宕機(jī)時(shí)，對(duì)端能夠?上感知到斷鏈???? 的原因）

注5：?論客戶端還是服務(wù)端，都可以主動(dòng)關(guān)閉連接（調(diào)?close函數(shù)）；

場(chǎng)景舉例：好像兩個(gè)?結(jié)束電話前，彼此告別

A：我這邊沒事了，掛電話了（FIN）

B：好的（ACK）

B：我這邊也沒事了，可以掛電話了（FIN）

A：好的（ACK，談話結(jié)束）

問：為什么三次握?時(shí)，服務(wù)端可以在?個(gè)分節(jié)同時(shí)回復(fù)ACK，SYN。?在四次揮?中，被動(dòng)關(guān)閉的

?端要分兩個(gè)分節(jié)發(fā)送ACK和FIN？

因?yàn)門CP是全雙?的，四次揮?時(shí)，兩端的關(guān)閉是獨(dú)?動(dòng)作，可以各?控制是否關(guān)閉??發(fā)送消息的 ?通道。因?分為2組消息（?條FIN和?條ACK）；

補(bǔ)充：

1）三次握手在第二步中，服務(wù)端可以將ACK和SYN的響應(yīng)合并在一個(gè)分節(jié)中發(fā)送。這是因?yàn)榉?wù)端在收到客戶端的SYN分節(jié)后，已經(jīng)知道了客戶端的初始序列號(hào)（ISN），并且服務(wù)端也需要發(fā)送自己的初始序列號(hào)（ISN）給客戶端。因此，服務(wù)端可以將ACK和SYN的響應(yīng)合并在一個(gè)分節(jié)中發(fā)送，以減少通信的往返時(shí)間（RTT）。

2）因?yàn)橹鲃?dòng)斷開連接方在斷開連接后能收數(shù)據(jù)但不能發(fā)送數(shù)據(jù)，此時(shí)被動(dòng)斷開連接方還沒有斷開連接，既能接收數(shù)據(jù)又能發(fā)送數(shù)據(jù)。被動(dòng)斷開連接方和主動(dòng)斷開連接方可能還有別的需求，因此需要單獨(dú)執(zhí)行ACK和SYN

1.6 TCP狀態(tài)機(jī)

?試問題：TCP連接有哪些狀態(tài)？分別有哪些含義？

服務(wù)端建鏈狀態(tài)機(jī)

CLOSED -> LISTEN：服務(wù)端調(diào)?listen函數(shù)，被動(dòng)打開；

LISTEN -> SYN_RCVD：服務(wù)端接收SYN，發(fā)送SYN + ACK；

SYN_RCVD -> ESTABLISHED：服務(wù)端收到ACK，完成建鏈；

?

?客戶端建鏈狀態(tài)機(jī)

CLOSED -> SYN_SENT：客戶端發(fā)送SYN；

SYN_SENT -> CLOSED：客戶端等待超時(shí)，未收到ACK + SYN；

SYN_SENT -> ESTABLISHED：客戶端收到ACK + SYN，發(fā)送ACK；

?

主動(dòng)關(guān)閉狀態(tài)機(jī)

ESTABLISHED -> FIN_WAIT_1：A端調(diào)?close函數(shù)，發(fā)送FIN，主動(dòng)關(guān)閉連接；

FIN_WAIT_1 -> FIN_WAIT_2：A端收到ACK；

FIN_WAIT_1 -> CLOSING：A端收到FIN，可能是B端同時(shí)調(diào)?了close函數(shù)，同時(shí)關(guān)閉連接；

FIN_WAIT_1 -> TIME_WAIT：A端收到SYN + ACK，回復(fù)ACK，表示B端主動(dòng)建鏈；

FIN_WAIT_2 -> TIME_WAIT：A端收到FIN，回復(fù)ACK；

CLOSING-> TIME_WAIT：A 端 收 到 ACK；

TIME_WAIT-> CLOSED：A端等待2MSL超時(shí)；

?

被動(dòng)關(guān)閉狀態(tài)機(jī)

ESTABLISHED -> CLOSE_WAIT：A端收到FIN，恢復(fù)ACK，表示關(guān)閉B端到A端連接；

CLOSE_WAIT -> LAST_ACK：A端發(fā)送FIN，表示關(guān)閉A端到B端連接；

LAST_ACK -> CLOSED：A端收到ACK；

TCP完整數(shù)據(jù)收發(fā)過程如下：

注1：建鏈后，服務(wù)端對(duì)客戶端請(qǐng)求的ACK是隨著要寫的數(shù)據(jù)?起發(fā)送的，該過程減少?次IO交互，稱為捎帶發(fā)送（piggybacking）；捎帶發(fā)送有時(shí)間窗?，如果超過該窗?，則獨(dú)?發(fā)送ACK分組；

注2：關(guān)閉連接時(shí)，主動(dòng)關(guān)閉的?端會(huì)經(jīng)歷TIME_WAIT狀態(tài)，?被動(dòng)關(guān)閉的?端會(huì)經(jīng)歷CLOSE_WAIT?? 狀態(tài)；

補(bǔ)充：

時(shí)間窗口的意思是說，如果當(dāng)時(shí)沒有要發(fā)送的數(shù)據(jù)，ACK的發(fā)送不會(huì)等待太長(zhǎng)時(shí)間(如果等待時(shí)間太長(zhǎng)，客戶端收不到ACK會(huì)超市重傳)，則獨(dú)立發(fā)送ACK；

?

如果單獨(dú)發(fā)送和接收?個(gè)分組，使?TCP協(xié)議需要?少8個(gè)分組（3次握?+4次揮?+1次發(fā)送），?使?UDP協(xié)議只需要2個(gè)分組（1個(gè)請(qǐng)求分組+1個(gè)應(yīng)答分組）。可以看到使?UDP?使?TCP協(xié)議，交互過程數(shù)據(jù)量較少，故?性能更好，但也犧牲了可靠性；

1.7 TIME_WAIT狀態(tài)

?試問題：TCP協(xié)議中的TIME_WAIT是什么狀態(tài)？為什么要有該狀態(tài)？

主動(dòng)關(guān)閉連接的?端會(huì)經(jīng)歷TIME_WAIT狀態(tài)，該狀態(tài)會(huì)持續(xù)2MSL時(shí)?后，才變?yōu)镃LOSED狀態(tài)； TIME_WAIT建議值為2min，但通常為1~4min；

MSL（Maximum Segment Lifetime）：最?分節(jié)?命周期，表示IP數(shù)據(jù)報(bào)能夠在?絡(luò)中存活的最?時(shí)間，超過該時(shí)間的IP數(shù)據(jù)報(bào)將被忽略；

跳限（hop limit）：每個(gè)IP數(shù)據(jù)報(bào)中包含?個(gè)跳數(shù)限制，即該數(shù)據(jù)報(bào)在鏈路中最?可跨過的路由器數(shù)，超過該數(shù)量，IP數(shù)據(jù)報(bào)會(huì)被忽略；跳限字段為8位，故最?值為255；

迷途重復(fù)分組（lost duplicate）/ 漫游重復(fù)分組（wandering duplicate）：由于路由異常，?徘徊在?絡(luò)中的TCP分節(jié)，導(dǎo)致超時(shí)后，?重復(fù)發(fā)送了該分節(jié)，造成重復(fù)；

TIME_WAIT狀態(tài)存在的意義：

1）實(shí)現(xiàn)可靠的TCP全雙?連接終?：最后?個(gè)ACK丟失后，可能需要重傳，因?需要TIME_WAIT狀態(tài)進(jìn)?中轉(zhuǎn)；

2）允許?的重復(fù)分節(jié)在?絡(luò)中消逝：如果TCP連接斷鏈后，?上?使?相同的IP和端?建??個(gè)連 接，則新建連接有可能收到舊連接的報(bào)；為了防?這種情況的發(fā)?，需要在TIME_WAIT狀態(tài)等待2MSL時(shí)?，以保證上?個(gè)連接的包全部消逝后，再啟?新的連接；

1.8 連接端?號(hào)

TCP、UDP、SCTP協(xié)議，均有端?號(hào)的概念，都使?16位整數(shù)表示端?號(hào)范圍；

不同協(xié)議之間的端?號(hào)不存在沖突，故可以同時(shí)開啟TCP、UDP、SCTP的相同端?號(hào)；

與服務(wù)端指定端?建鏈時(shí)，客戶端同樣需要使??個(gè)臨時(shí)端?與服務(wù)端進(jìn)?通信，該臨時(shí)端?由協(xié)議??? 棧?動(dòng)分配；

套接字對(duì)：?個(gè)TCP的通信鏈路，包含?對(duì)套接字（IP+端?），是定義兩個(gè)連接端點(diǎn)的四元組（本地IP地址，本地TCP端?號(hào)，外地IP地址，外地TCP端?號(hào)）；

常?端?號(hào)范圍：

1）0~1023，公共服務(wù)的端?號(hào)，?如ssh的端?號(hào)22；

2）1024~49151，?于登記開啟的監(jiān)聽端?號(hào)，?如web服務(wù)的8080端?；

3）49152~65535，?于開啟臨時(shí)端?號(hào)，與服務(wù)端進(jìn)?通信；

注：端?號(hào)的范圍根據(jù)不同的OS可能不同，?般約定1024之前的端?為預(yù)留端口，不可以?由使?；

問：?個(gè)服務(wù)端能夠承載多少連接，是由什么決定的？

對(duì)于客戶端??在物理層面，由于?個(gè)Socket連接也被視作?個(gè)?件，故會(huì)占??個(gè)?件句柄（客戶端側(cè)機(jī)器）；

在邏輯層面，使?(協(xié)議，源IP，源端?，?標(biāo)IP，?標(biāo)端?)這個(gè)五元組來唯?標(biāo)識(shí)?個(gè)連接，故能夠開啟的連接多少，取決于五元組中的組合有多少種。

理解誤區(qū)：由于機(jī)器可以開啟的端?范圍總是?于65535的，因?容易理解為?臺(tái)客戶端機(jī)器上能夠

建?到服務(wù)器的連接上限，即為可以開啟的端?數(shù)。實(shí)際上，端?是邏輯概念，建?連接的數(shù)量，取 決于上述五元組中各個(gè)元素取值的組合。

?

問：假設(shè)有固定數(shù)量的客戶端機(jī)器，想要發(fā)起上百萬個(gè)連接，到同?個(gè)服務(wù)器，如何突破端?限制？??

由于機(jī)器數(shù)量固定，故（協(xié)議，源IP，源端口，?標(biāo)IP，目標(biāo)端口）五元組中，協(xié)議、源IP、?標(biāo)IP即已 固定。而對(duì)于同?個(gè)目標(biāo)端口（服務(wù)器端口），同?個(gè)客戶端機(jī)器能夠開啟的最?端口數(shù)不會(huì)超過65535個(gè)，因而想要發(fā)起上百萬的連接，需要提供多個(gè)目標(biāo)端口（服務(wù)器端口），每個(gè)端口承擔(dān)6w多 個(gè)客戶端連接，突破端口限制。

1.9 TCP數(shù)據(jù)發(fā)送過程（了解）

每個(gè)TCP套接字有?個(gè)發(fā)送緩沖區(qū)（只有發(fā)送緩沖區(qū)滿了，才會(huì)發(fā)送數(shù)據(jù)(如果一個(gè)字節(jié)一個(gè)字節(jié)的發(fā)送數(shù)據(jù)，效率較低)；就好像往池子里灌水，一瓢一瓢的灌比一滴一滴的灌效率更高），通過SO_SNDBUF選項(xiàng)設(shè)置；數(shù)據(jù)的發(fā)送過程如下：

1）TCP層：當(dāng)應(yīng)?調(diào)?write時(shí)，內(nèi)核從該應(yīng)?進(jìn)程的緩沖區(qū)中復(fù)制所有數(shù)據(jù)寫到套接字的發(fā)送緩沖區(qū) ?中；

2）TCP層：若發(fā)送緩沖區(qū)?法存放全部數(shù)據(jù)時(shí)，則將應(yīng)?進(jìn)程置于休眠狀態(tài)，對(duì)于阻塞IO，內(nèi)核將不 從write系統(tǒng)調(diào)?中返回，直到發(fā)送緩沖區(qū)騰出空間，應(yīng)?進(jìn)程所有數(shù)據(jù)都拷?到發(fā)送緩沖區(qū)中；

注：僅當(dāng)收到對(duì)端的ACK之后，才能夠不斷清理發(fā)送緩沖區(qū)中已確認(rèn)的數(shù)據(jù)；

3）TCP層：本端TCP以MSS??或者更?的塊，把數(shù)據(jù)傳遞給IP層；每個(gè)數(shù)據(jù)塊上有?個(gè)TCP頭（20字節(jié)）；（MSS值由對(duì)端MSS選項(xiàng)傳遞）

4）IP層：給TCP分節(jié)安裝?個(gè)IP頭，組成IP數(shù)據(jù)報(bào)，并按照?的IP地址查找路由表，確定外出接?； 之后把數(shù)據(jù)發(fā)送給相應(yīng)的數(shù)據(jù)鏈路，期間IP層可能會(huì)對(duì)IP數(shù)據(jù)報(bào)分為多個(gè)分?發(fā)送；

5）數(shù)據(jù)鏈路層：每個(gè)數(shù)據(jù)鏈路維護(hù)?個(gè)輸出隊(duì)列，如果隊(duì)列已滿，則新到分組會(huì)被丟棄，并沿著協(xié)議 ?棧向上返回錯(cuò)誤；TCP層捕獲該錯(cuò)誤，并嘗試重傳相應(yīng)分節(jié)；該過程并不會(huì)被上層應(yīng)?感知；

注：?次write系統(tǒng)調(diào)?成功返回，僅表示發(fā)送緩沖區(qū)可以復(fù)?，并不表示對(duì)端已經(jīng)接收到發(fā)送的數(shù)據(jù)；

?

1.10 超時(shí)重傳和快速重傳

超時(shí)重傳（Timeout Retransmission）和快速重傳（Fast Retransmission）是在計(jì)算機(jī)?絡(luò)中?于處

理丟失數(shù)據(jù)包和?絡(luò)擁塞的兩種重傳機(jī)制。

1）超時(shí)重傳

超時(shí)重傳（Timeout Retransmission）是指發(fā)送?在發(fā)送數(shù)據(jù)包后設(shè)置?個(gè)定時(shí)器，如果在規(guī)定的時(shí)間內(nèi)沒有收到確認(rèn)（ACK）或者重復(fù)確認(rèn)（Duplicate ACK），發(fā)送?會(huì)認(rèn)為該數(shù)據(jù)包丟失，然后重新發(fā)送該數(shù)據(jù)包。這種機(jī)制基于超時(shí)的假設(shè)，即數(shù)據(jù)包丟失的原因可能是?絡(luò)擁塞、傳輸延遲等。超時(shí)重傳的缺點(diǎn)是它需要等待超時(shí)時(shí)間才能重傳數(shù)據(jù)包，這會(huì)導(dǎo)致?絡(luò)傳輸效率低下。

?

行為：如果在超時(shí)時(shí)間內(nèi)沒有接收到確認(rèn)，發(fā)送?會(huì)假設(shè)該數(shù)據(jù)包丟失，然后重新發(fā)送該數(shù)據(jù)包。

觸發(fā)條件：超時(shí)重傳通常發(fā)?在?絡(luò)擁塞或傳輸延遲導(dǎo)致數(shù)據(jù)包丟失的情況下。

2）快速重傳

快速重傳（Fast Retransmission）是?種基于接收?的反饋機(jī)制的重傳機(jī)制。當(dāng)發(fā)送?發(fā)送?個(gè)數(shù)據(jù)包后，接收?會(huì)發(fā)送確認(rèn)（ACK）給發(fā)送?，表示已經(jīng)成功接收到該數(shù)據(jù)包。但是，如果接收?收到了?個(gè)不按順序的數(shù)據(jù)包（例如，接收?已經(jīng)收到了數(shù)據(jù)包5，但是卻未收到數(shù)據(jù)包3，此時(shí)會(huì)重復(fù)確認(rèn)數(shù)據(jù)包4，連發(fā)3次數(shù)據(jù)包4后，發(fā)送端重傳數(shù)據(jù)包3），接收?會(huì)發(fā)送?個(gè)重復(fù)確認(rèn)（Duplicate ACK）給發(fā)送?，指示發(fā)送?某個(gè)數(shù)據(jù)包丟失。當(dāng)發(fā)送?連續(xù)收到3次重復(fù)確認(rèn)時(shí)，它會(huì)?即重傳相應(yīng)的數(shù)據(jù)包，?不必等待超時(shí)時(shí)間。這樣可以快速恢復(fù)丟失的數(shù)據(jù)包，提??絡(luò)傳輸效率。

?

原理：接收?在收到?個(gè)亂序的數(shù)據(jù)包后，會(huì)發(fā)送重復(fù)確認(rèn)（Duplicate ACK）給發(fā)送?。

行為：發(fā)送?在連續(xù)收到?定數(shù)量的重復(fù)確認(rèn)時(shí)（通常是3個(gè)），?即重傳對(duì)應(yīng)的數(shù)據(jù)包，?不必等待超時(shí)。

觸發(fā)條件：快速重傳通常發(fā)?在?絡(luò)丟包引起數(shù)據(jù)包亂序的情況下。接收?通過發(fā)送重復(fù)確認(rèn)來指示發(fā)送?某個(gè)數(shù)據(jù)包丟失。

總結(jié)來說，超時(shí)重傳是在發(fā)送?設(shè)置的定時(shí)器超時(shí)后重新發(fā)送數(shù)據(jù)包，?快速重傳是在接收?發(fā)送重復(fù)確認(rèn)后?即重傳數(shù)據(jù)包。這兩種重傳機(jī)制在不同的情況下使?，以提?數(shù)據(jù)傳輸?shù)目煽啃院托省?/p>

1.11 TCP Header結(jié)構(gòu)

技巧：數(shù)據(jù)傳輸時(shí)間估算

使?ping()估算TCP數(shù)據(jù)傳輸時(shí)間，?次ping()使?84字節(jié)的IP數(shù)據(jù)報(bào)；

假設(shè)30次ping()測(cè)量的平均RTT時(shí)?為175ms，且要發(fā)送2000字節(jié)數(shù)據(jù)，每次發(fā)送40字節(jié)，則?共發(fā)送50次；

每次發(fā)送時(shí)，除了40字節(jié)數(shù)據(jù)，還包含 20字節(jié)的IP Header，20字節(jié)的TCP Header，?共80字節(jié)； 則可以估算發(fā)送這2000字節(jié)的?概耗時(shí)為：175ms * 50次 = 8750ms；

1.12 TCP可靠傳輸

（1）什么是可靠傳輸？

對(duì)于?絡(luò)中的兩個(gè)節(jié)點(diǎn)通信，中間要經(jīng)過很?的鏈路，期間可能存在很多問題，因?我們認(rèn)為直接在?絡(luò)中傳輸數(shù)據(jù)是不可靠的。

所謂可靠，就是數(shù)據(jù)能夠正常、完整、有序的被對(duì)端收到。TCP協(xié)議依靠如下機(jī)制，實(shí)現(xiàn)可靠通信：

1. ACK機(jī)制
2. 序列號(hào)機(jī)制
3. 重排機(jī)制
4. 窗?機(jī)制

補(bǔ)充：

在TCP（傳輸控制協(xié)議）的可靠傳輸中，有兩個(gè)重要的機(jī)制：重排（reordering）和窗口（window）。

1）重排機(jī)制：

?? 重排指的是網(wǎng)絡(luò)中的數(shù)據(jù)包可能以非順序的方式到達(dá)接收方。這可能是由于網(wǎng)絡(luò)拓?fù)?、路由選擇、擁塞等原因造成的。TCP使用序列號(hào)來標(biāo)識(shí)發(fā)送的數(shù)據(jù)包，接收方根據(jù)序列號(hào)來恢復(fù)數(shù)據(jù)的正確順序。

?? 當(dāng)接收方收到亂序的數(shù)據(jù)包時(shí)，它會(huì)將這些數(shù)據(jù)包緩存起來，然后按照序列號(hào)對(duì)它們進(jìn)行排序，以確保數(shù)據(jù)包按正確的順序交付給上層應(yīng)用程序。TCP使用接收窗口來管理亂序數(shù)據(jù)包的緩存和排序。

2）窗口機(jī)制：

?? 窗口機(jī)制是TCP中的流量控制和擁塞控制的基礎(chǔ)。發(fā)送方和接收方都有一個(gè)窗口大小（window size）的概念。

?? 發(fā)送方的窗口大小表示可以發(fā)送但尚未收到確認(rèn)的數(shù)據(jù)量。發(fā)送方根據(jù)接收方發(fā)送的確認(rèn)信息來動(dòng)態(tài)調(diào)整窗口大小，以控制發(fā)送的速率，避免發(fā)送過多的數(shù)據(jù)導(dǎo)致接收方無法及時(shí)處理。

?? 接收方的窗口大小表示它能夠接收的數(shù)據(jù)量。接收方通過發(fā)送窗口大小信息給發(fā)送方，告知發(fā)送方它目前的接收能力。發(fā)送方根據(jù)接收方的窗口大小來控制發(fā)送的速率，以避免發(fā)送過多的數(shù)據(jù)導(dǎo)致接收方緩沖區(qū)溢出。

?? 窗口機(jī)制使得發(fā)送方和接收方能夠協(xié)調(diào)數(shù)據(jù)傳輸?shù)乃俾?#xff0c;以適應(yīng)網(wǎng)絡(luò)的狀況和接收方的處理能力，從而實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。

綜上所述，TCP通過重排機(jī)制和窗口機(jī)制來實(shí)現(xiàn)可靠傳輸。重排機(jī)制確保接收方能夠正確排序亂序的數(shù)據(jù)包，窗口機(jī)制用于流量控制和擁塞控制，確保發(fā)送方和接收方之間的數(shù)據(jù)傳輸能夠合理、高效地進(jìn)行。

（2）什么是ARQ協(xié)議？

ARQ（Automatic Repeat Request）協(xié)議是?種?于可靠數(shù)據(jù)傳輸?shù)膮f(xié)議，位于傳輸層。它是在數(shù)據(jù)通信中處理和糾正傳輸錯(cuò)誤和丟失數(shù)據(jù)的?種機(jī)制。

ARQ協(xié)議的主要?標(biāo)是確保數(shù)據(jù)的可靠傳輸，通過引?ACK確認(rèn)和超時(shí)重傳機(jī)制 實(shí)現(xiàn)這??標(biāo)：

1. ACK確認(rèn)：發(fā)送?在發(fā)送數(shù)據(jù)包后等待接收?的確認(rèn)；
2. 超時(shí)重傳機(jī)制：如果發(fā)送?在?定時(shí)間內(nèi)未收到確認(rèn)，或者接收?通知數(shù)據(jù)包有錯(cuò)誤，則發(fā)送?會(huì)重新發(fā)送數(shù)據(jù)包。

ARQ協(xié)議主要有3種模式：

1）停等 ARQ（Stop-and-Wait? ARQ）：發(fā)送?發(fā)送?個(gè)數(shù)據(jù)包，然后停?等待接收?的確認(rèn)。只有在接收到確認(rèn)后，發(fā)送?才發(fā)送下?個(gè)數(shù)據(jù)包。

2）連續(xù) ARQ（Continuous ARQ）：發(fā)送?連續(xù)發(fā)送多個(gè)數(shù)據(jù)包?不等待每個(gè)數(shù)據(jù)包的確認(rèn)。接收?收到數(shù)據(jù)包后，發(fā)送累積確認(rèn)，指示已成功接收到?系列數(shù)據(jù)包。如果發(fā)送?未收到確認(rèn)或收到確認(rèn)指示有錯(cuò)誤，它將重傳相應(yīng)的數(shù)據(jù)包。（類似pipeline）

1. Go-Back-N：在接收?發(fā)現(xiàn)錯(cuò)誤或數(shù)據(jù)包丟失時(shí)，發(fā)送?會(huì)重新發(fā)送整個(gè)窗?中未確認(rèn)的數(shù)據(jù)包。
2. Selective-Repeat（選擇重傳）：在接收?發(fā)現(xiàn)錯(cuò)誤或數(shù)據(jù)包丟失時(shí)，發(fā)送?只會(huì)重傳具有問題的數(shù)據(jù)包，?不是整個(gè)窗?中的所有數(shù)據(jù)包。

3）反饋 ARQ（Feedback ARQ）：接收?會(huì)周期性地發(fā)送確認(rèn)消息，以指示已成功接收到的數(shù)據(jù)包。發(fā)送?會(huì)根據(jù)接收到的確認(rèn)信息進(jìn)?重傳處理。

?

注1：停等 ARQ需要逐條處理消息的請(qǐng)求-響應(yīng)，可能產(chǎn)?性能問題，因?較少被采?；

注2：kafka在應(yīng)?層確保消息傳遞?致性時(shí)，也使?了類似 Continuous ARQ 和 Feedback ARQ 的實(shí)現(xiàn)機(jī)制；?

（3）Stop-and-Wait ARQ

停等 ARQ 的?作原理如下：

1）發(fā)送?對(duì)接收?發(fā)送數(shù)據(jù)包，然后等待接收?回復(fù)ACK并且開始計(jì)時(shí)；

2）在等待過程中，發(fā)送?停?發(fā)送新的數(shù)據(jù)包；

3）當(dāng)數(shù)據(jù)包沒有成功被接收?接收，接收?不會(huì)發(fā)送ACK。發(fā)送?在等待?定時(shí)間后，重新發(fā)送數(shù)據(jù)包；

缺點(diǎn)：?的等待時(shí)間導(dǎo)致低的數(shù)據(jù)傳輸速度；

（4）Go-Back-N

為了克服停等 ARQ 協(xié)議?時(shí)間等待ACK的缺陷，連續(xù) ARQ 協(xié)議會(huì)連續(xù)發(fā)送?組數(shù)據(jù)包，然后再等待這些數(shù)據(jù)包的ACK。

什么是滑動(dòng)窗?？

發(fā)送?和接收?都會(huì)維護(hù)?個(gè)數(shù)據(jù)幀的序列，這個(gè)序列被稱作窗?。發(fā)送?的窗???由接收?確定，?的在于控制發(fā)送速度，以免接收?的緩存不夠?，?導(dǎo)致溢出，同時(shí)控制流量也可以避免?絡(luò)??? 擁塞。協(xié)議中規(guī)定，對(duì)于窗?內(nèi)未經(jīng)確認(rèn)的分組需要重傳。

什么是Go-Back-N？

回退N步協(xié)議允許發(fā)送?在等待超時(shí)的間歇，可以繼續(xù)發(fā)送分組。所有發(fā)送的分組，都帶有序號(hào)。在Go-Back-N協(xié)議中：

發(fā)送?需響應(yīng)以下三種事件：

1）上層業(yè)務(wù)發(fā)送數(shù)據(jù)，調(diào)?send()時(shí)，發(fā)送??先要檢查發(fā)送窗?是否已滿；

2）發(fā)送?接收ACK：在該協(xié)議中，對(duì)序號(hào)為n的分組的確認(rèn)采取累積確認(rèn)的?式，表明接收?已正確接收到序號(hào)n以前(包括n)的所有分組；

3）發(fā)送?等待超時(shí)：若出現(xiàn)超時(shí)，發(fā)送?將重傳所有已發(fā)出但還未被確認(rèn)的分組；發(fā)送?在發(fā)完?個(gè)窗??的所有分組后，會(huì)檢查最?的有效確認(rèn)，然后從最?有效確認(rèn)的后?個(gè)分組開始重傳；

對(duì)于接收方而言，處理動(dòng)作如下：

1）若?個(gè)序號(hào)為n的分組被正確接收，并且符合順序，則接收?會(huì)為該分組回復(fù)?個(gè)ACK，并將該分組交由上層業(yè)務(wù)? 處理；否則，丟棄分組；

2）若分組n已被接收并且交由上層業(yè)務(wù)處理，則說明?n?的所有分組均已正確接收并交付處理；

?

比如：發(fā)送方一次性發(fā)送了序號(hào)為：1、2、3、4、5的分組，如果序號(hào)為2的分組丟失，即便序號(hào)為3、4、5的分組都被正確接收（但是不符合接收順序），發(fā)送方依然會(huì)重傳2、3、4、5分組；

?

Go-Back-N采?的技術(shù)包括：序號(hào)、累積確認(rèn)、檢驗(yàn)以及超時(shí)重傳等；

?

缺點(diǎn)：Go-Back-N改善了停等協(xié)議中等待時(shí)間較?的問題，但仍然存在性能問題：當(dāng)窗?很?時(shí)，如果發(fā)?重傳，則增加了重發(fā)消息的區(qū)間，會(huì)??降低效率；

（5）Selective-Repeat（選擇重傳）

相?于Go-Back-N協(xié)議，Selective-Repeat協(xié)議通過讓發(fā)送?僅重傳在接收?丟失或損壞了的分組，從?避免了不必要的重傳，從?提?效率。

在Selective-Repeat協(xié)議下，發(fā)送方需響應(yīng)以下三種事件:

1）從上層收到數(shù)據(jù)。當(dāng)從上層收到數(shù)據(jù)后，發(fā)送?需檢查下?個(gè)可?于該分組的序號(hào)。若序號(hào)在窗?中則將數(shù)據(jù)發(fā)送；

2）接收ACK；

1. 若收到ACK，且該分組在窗?內(nèi)，則發(fā)送?將那個(gè)被確認(rèn)的分組標(biāo)記 為已接收；
2. 若該分組序號(hào)等于基序號(hào)，則窗?序號(hào)向前移動(dòng)到具有最?序號(hào)的未確認(rèn)分組處；
3. 若窗?移動(dòng)后并且有序號(hào)落在窗?內(nèi)的未發(fā)送分組，則發(fā)送這些分組；

3）超時(shí)。若出現(xiàn)超時(shí)，發(fā)送?將重傳已發(fā)出但還未確認(rèn)的分組。

注：與GBN不同， SR協(xié)議中的每個(gè)分組都有獨(dú)?的計(jì)時(shí)器；

假設(shè)接收窗?的基序號(hào)為4，分組?度也為4；接收?需響應(yīng)以下三種事件:

1）序號(hào)在[4,7]內(nèi)的分組被正確接收。該情況下，

1. 若收到的分組落在接收?的窗?內(nèi)（序號(hào)在 (4, 7] 區(qū)間），將發(fā)送?個(gè)ACK；
2. 若該分組是以前沒收到的分組（序號(hào)?于4），則被緩存；
3. 若該分組的序號(hào)等于基序號(hào)4，則該分組以及以前緩存的序號(hào)連續(xù)的分組都交付給上層，然后，接收窗?將向前移動(dòng)。

2）序號(hào)在[0,3]內(nèi)的分組被正確接收。在該情況下，必須產(chǎn)??個(gè)ACK，盡管該分組是接收?以前已確認(rèn)過的分組。若接收?不確認(rèn)該分組，發(fā)送?窗?將不能向前移動(dòng)。

3）其他情況，忽略該分組。

對(duì)于接收?來說，若?個(gè)分組正確接收?不管其是否按序，則接收?會(huì)為該分組返回?個(gè)ACK給發(fā)送?。失序的分組將被緩存，直到所有丟失的分組都被收到，這時(shí)才可以將?批分組按序交付給上層，并向前滑動(dòng)接收窗?；

?

?如：上?圖示中，序號(hào)為2的分組丟失，則接收?每次收到消息后，回復(fù)已確認(rèn)的最?ACK 1；發(fā)送?收到ACK后，重發(fā)分組2；接收?收到分組2后，向前滑動(dòng)接收窗?，返回ACK5；此時(shí)[0, 5]區(qū)間的消息已經(jīng)全部正常接收，并可以處理；

（6）TCP協(xié)議和ARQ協(xié)議是什么關(guān)系？

TCP是基于ARQ協(xié)議的，它使?了ARQ的確認(rèn)和重傳機(jī)制來實(shí)現(xiàn)可靠的數(shù)據(jù)傳輸。TCP協(xié)議使?了?種ARQ協(xié)議的變體；在TCP中，發(fā)送?將數(shù)據(jù)分割成?的數(shù)據(jù)段，并使?ARQ機(jī)制確保它們的可靠傳輸。發(fā)送?會(huì)等待接收?的確認(rèn)，并在需要時(shí)進(jìn)?重傳。接收?會(huì)對(duì)接收到的數(shù)據(jù)進(jìn)?校驗(yàn)，并發(fā)送 確認(rèn)或請(qǐng)求重傳的消息。

（7）如何理解RTT和RTO？

RTT（Round-Trip Time）：往返時(shí)延。表示從發(fā)送端發(fā)送數(shù)據(jù)開始，到發(fā)送端收到接收端的確認(rèn)（假設(shè)接收端收到數(shù)據(jù)后便?即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延； 由三部分組成：

1. 鏈路的傳播時(shí)間（propagation delay）；（鏈路傳播時(shí)間（Link propagation time）是指信號(hào)在物理鏈路上傳播所需的時(shí)間。它是從信號(hào)從發(fā)送端發(fā)送出去到達(dá)接收端的時(shí)間延遲。）
2. 末端系統(tǒng)的處理時(shí)間；（末端系統(tǒng)處理時(shí)間（End-system processing time）是指在網(wǎng)絡(luò)通信中，數(shù)據(jù)到達(dá)接收端的末端系統(tǒng)后，經(jīng)過處理和操作所需的時(shí)間延遲。）
3. 路由器緩存中的排隊(duì)和處理時(shí)間（queuing delay）；（在路由器的緩存中，排隊(duì)和處理時(shí)間是指數(shù)據(jù)包在進(jìn)入路由器后等待被處理和轉(zhuǎn)發(fā)的時(shí)間延遲。）

其中，前兩個(gè)部分的值對(duì)于?個(gè)TCP連接相對(duì)固定，路由器緩存中的排隊(duì)和處理時(shí)間會(huì)隨著整個(gè)?絡(luò)? 擁塞程度的變化?變化。 所以RTT的變化在?定程度上反應(yīng)?絡(luò)的擁塞程度。

?

RTO（Retransmission TimeOut）：重傳超時(shí)時(shí)間；超時(shí)重傳時(shí)間，根據(jù)RTT動(dòng)態(tài)調(diào)整，由協(xié)議棧?動(dòng)控制；?般RTO?少為1.5倍RTT；RTO過?，則可能過于頻繁的發(fā)起重傳；RTO過?，則重傳等待的時(shí)間可能過?；

1.13 TCP流量控制

（1）什么是流量控制？

雙?在通信的時(shí)候，發(fā)送?的速率與接收?的速率不?定相等，如果發(fā)送?的發(fā)送速率太快，會(huì)導(dǎo)致接收?處理不過來，這時(shí)候接收?只能把處理不過來的數(shù)據(jù)存在緩存區(qū)?（失序的數(shù)據(jù)包也會(huì)被存放在緩存區(qū)?）；如果緩存區(qū)已滿，發(fā)送?還在發(fā)送數(shù)據(jù)，接收?只能把收到的數(shù)據(jù)包丟掉；?量的丟包會(huì)極?浪費(fèi)?絡(luò)資源，因此，我們需要控制發(fā)送?的發(fā)送速率，?? 讓接收?與發(fā)送?處于?種動(dòng)態(tài)平衡才好； 對(duì)發(fā)送?發(fā)送速率的控制，稱之為流量控制。

（2）如何進(jìn)?流量控制？

通信的雙?都擁有兩個(gè)滑動(dòng)窗口：

1. ?個(gè)?于接收數(shù)據(jù)，稱之為接收窗口；
2. ?個(gè)?于發(fā)送數(shù)據(jù)，稱之為擁塞窗口（即發(fā)送窗口）；

?于反饋接收窗口??的ACK通知，稱為窗口通告；

接收?每次收到數(shù)據(jù)包后，可在發(fā)送ACK時(shí)，同時(shí)告訴發(fā)送???的緩存區(qū)還剩多少空間。我們也把 緩存區(qū)的剩余空間??稱之為接收窗口??，?變量win來表示。

發(fā)送?收到之后，便會(huì)調(diào)整??的發(fā)送速率，也就是調(diào)整??發(fā)送窗???，當(dāng)發(fā)送?收到的接收窗口的??為0時(shí)，發(fā)送?就會(huì)停?發(fā)送數(shù)據(jù)，防??量丟包；

上述過程即為TCP的負(fù)反饋機(jī)制：通過接收端的反饋，決定發(fā)送端的速率；

?

注：接收端?法直接主動(dòng)告知發(fā)送端??的接收窗???，但通過發(fā)送窗?和接收窗?的動(dòng)態(tài)調(diào)整，接收端可以間接地影響發(fā)送端的發(fā)送速率，實(shí)現(xiàn)流量控制。

?

問1：若發(fā)送端因接收窗口為0?停?發(fā)送數(shù)據(jù)后，如何判斷是否可以再次發(fā)送數(shù)據(jù)？

1）當(dāng)發(fā)送?收到接受窗口 win = 0 時(shí)，則停?發(fā)送報(bào)?，并且同時(shí)開啟?個(gè)定時(shí)器，每隔?段時(shí)間向

接收端發(fā)送試探報(bào)?。

2）接收?收到報(bào)?后，通過ACK反饋當(dāng)前接收窗口 win 的??；

3）發(fā)送?收到ACK后，判斷接收窗口 win 的??；

1. 如果 win = 0，則再次刷新定時(shí)器，等待下?次發(fā)送試探報(bào)?；
2. 如果 win > 0，則根據(jù)窗口??，發(fā)送適量的數(shù)據(jù)；

問2：接收窗?的??固定嗎？

不固定，接收窗?的??是根據(jù)某種算法動(dòng)態(tài)調(diào)整的；

?

問3：接收窗?越大越好嗎？

不是，根據(jù)邊際收益遞減規(guī)律，當(dāng)接收窗?達(dá)到某個(gè)值的時(shí)候，再增?的話也不怎么會(huì)減少丟包率的??? 了，?且還會(huì)消耗內(nèi)存。所以接收窗?的??必須根據(jù)?絡(luò)環(huán)境以及發(fā)送發(fā)的的擁塞窗口來動(dòng)態(tài)調(diào)整。

?

問4：發(fā)送窗?和接收窗?相等嗎？

不?定相等，接收?在發(fā)送ACK報(bào)?的時(shí)候，會(huì)告訴發(fā)送發(fā)??的接收窗口??，?發(fā)送?的發(fā)送窗口會(huì)據(jù)此來設(shè)置??的發(fā)送窗口，但并不?定相等；因?yàn)榻邮?把ACK報(bào)?發(fā)出去的那?刻，就已經(jīng)? 在?邊處理堆在??緩存區(qū)的數(shù)據(jù)了，所以?般情況下接收窗? >= 發(fā)送窗口。

1.14 TCP擁塞控制

擁塞控制和流量控制采取的動(dòng)作很相似，但?者針對(duì)不同的問題：

1. 擁塞控制與?絡(luò)的擁堵情況相關(guān)聯(lián)；
2. ?流量控制與接收?的緩存狀態(tài)相關(guān)聯(lián)；

（1）什么是擁塞控制？

假設(shè)主機(jī)A給主機(jī)B傳輸數(shù)據(jù)。兩臺(tái)主機(jī)在傳輸數(shù)據(jù)包的時(shí)候，如果發(fā)送?遲遲沒有收到接收?反饋的ACK，那么發(fā)送?就會(huì)認(rèn)為它發(fā)送的數(shù)據(jù)包丟失了，進(jìn)?會(huì)重新傳輸這個(gè)丟失的數(shù)據(jù)包。

然?實(shí)際情況有可能此時(shí)有太多主機(jī)正在使?信道資源，導(dǎo)致網(wǎng)絡(luò)擁塞了，?A發(fā)送的數(shù)據(jù)包被堵在了半路，遲遲沒有到達(dá)B。這個(gè)時(shí)候A誤認(rèn)為是發(fā)?了丟包情況，會(huì)重新傳輸這個(gè)數(shù)據(jù)包。

結(jié)果就是不僅浪費(fèi)了信道資源，還會(huì)使?絡(luò)更加擁塞。因此需要進(jìn)?擁塞控制。

（2）如何知道?絡(luò)的擁塞情況？

A與B建?連接之后，就可以向B發(fā)送數(shù)據(jù)了，然?這個(gè)時(shí)候A并不知道此時(shí)的?絡(luò)擁塞情況如何，此時(shí)?? A不知道?次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包。

擁塞窗口：把A?次性連續(xù)發(fā)送多少個(gè)數(shù)據(jù)包稱之為擁塞窗?，? N 代表此時(shí)擁塞窗?的??； 為了探測(cè)?絡(luò)的擁塞情況，可以采取2種策略：

1）線性增?：先發(fā)送?個(gè)數(shù)據(jù)包試探下，如果該數(shù)據(jù)包沒有發(fā)?超時(shí)（沒有丟包）。則下次發(fā)送時(shí)就發(fā)送2個(gè)，如果 還是沒有發(fā)?超時(shí)事件，下次就發(fā)送3個(gè)，以此類推，即N = 1, 2, 3, 4, 5.....

2）指數(shù)增?：?個(gè)?個(gè)增加實(shí)在是太慢了，所以可以剛開始發(fā)送1個(gè)，如果沒有發(fā)?超時(shí)，就發(fā)送2個(gè)，如果還是沒有發(fā)送超時(shí)事件就發(fā)送4個(gè)，接著8個(gè)...，?翻倍的速度類推，即 N = 1, 2, 4, 8, 16...

缺點(diǎn)：?論是第?種?法還是第?種?法，最后都會(huì)出現(xiàn)瓶頸值。但第?種情況的增?速率過慢，可

能很慢到達(dá)瓶頸值；?第?種情況增?速度過快，可能很快到達(dá)瓶頸值；

為了解決探測(cè)過慢或過快的問題，可以把第?種?法和第?種?法結(jié)合起來：剛開始使?指數(shù)增?，?? 增?到某?個(gè)閾值（記為ssthresh）后，就改為線性增?。我們把指數(shù)增?階段稱之為慢啟動(dòng)，線性增?階段稱之為擁塞避免；

?（3）如果到達(dá)瓶頸，如何處理？

?論是指數(shù)增?還是?個(gè)?個(gè)增?，最終肯定會(huì)出現(xiàn)超時(shí)事件；當(dāng)出現(xiàn)超時(shí)事件時(shí)，我們就認(rèn)為此時(shí)

?絡(luò)出現(xiàn)了擁塞了，不能再繼續(xù)增?了。把此時(shí)的N值稱之為瓶頸值（記為MAX）；

當(dāng)?shù)竭_(dá) MAX 后，調(diào)? ssthresh = MAX / 2，然后回到最初的最初的狀態(tài)，從1，2，4，8.. 開始發(fā)

送數(shù)據(jù)包；

示例：初始閾值為8，瓶頸值是14；超時(shí)事件發(fā)?后，調(diào)整閾值為14 / 2 = 7；

?（4）什么是快速恢復(fù)？

發(fā)?超時(shí)事件，不?定是?絡(luò)出現(xiàn)了擁堵。也有可能是因?yàn)槟硞€(gè)數(shù)據(jù)包出現(xiàn)了丟失或者損壞。如果視作擁塞控制，從最初狀態(tài)開始，則可能導(dǎo)致控制較為嚴(yán)格，降低發(fā)送速率；

為了上述情況，我們通過冗余ACK來處理：即連續(xù)3次收到重復(fù)確認(rèn)，表明數(shù)據(jù)包丟失了，可以快速重 傳丟失的數(shù)據(jù)包；

假設(shè)A給B發(fā)送M1, M2, M3, M4, M5...N個(gè)數(shù)據(jù)包，如果B收到了M1, M2, M4... 卻始終沒有收到M3，這個(gè)時(shí)候就會(huì)重復(fù)確認(rèn)M2，意在告訴A，M3還沒收到，可能是丟失了。

當(dāng)A連續(xù)收到了三個(gè)確認(rèn)M2的ACK，且M3超時(shí)事件還沒發(fā)?。A就知道M3可能丟失了，這個(gè)時(shí)候A就不必等待M3設(shè)置的計(jì)時(shí)器到期了，?是快速重傳M3。并且調(diào)整 ssthresh = MAX / 2，但是這個(gè)時(shí)候并?把控制窗? N 重置為1，?是直接讓 N = ssthresh，并線性增?。該過程稱為快速恢復(fù)，具有快速恢復(fù)的TCP版本稱之為TCP Reno。

?

注：另外?種TCP版本，?論是收到三個(gè)相同的ACK還是發(fā)?超時(shí)事件，都把擁塞窗?的??設(shè)為1， 從最初狀態(tài)開始，這種版本稱為TCP Tahoe。

1.15 TCP/IP 協(xié)議棧報(bào)?格式舉例

以UDP通信為例，查看TCP/IP模型各層報(bào)?結(jié)構(gòu)：

（1）?鏈路層

（2）?絡(luò)層（IP協(xié)議）

（3）傳輸層（UDP協(xié)議）

結(jié)論：

MAC地址是以太?產(chǎn)物

IP地址是?絡(luò)層產(chǎn)物

端?是傳輸層產(chǎn)物

（4）ARP協(xié)議（網(wǎng)絡(luò)層）

Address Resolution Protocol，地址解析協(xié)議，把IPv4地址映射成?個(gè)硬件地址（MAC地址），?于

?播?絡(luò)；

?（5）ICMP協(xié)議（網(wǎng)絡(luò)層）

?Internet Control Message Protocol，?絡(luò)控制消息協(xié)議，處理主機(jī)和路由之間的消息通信；