七、計算機網(wǎng)絡(luò)

1.說說計算機網(wǎng)絡(luò)五層體系結(jié)構(gòu)

計算機網(wǎng)絡(luò)的五層架構(gòu)包括應用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層和物理層。

1. 應用層：是網(wǎng)絡(luò)結(jié)構(gòu)中的最高層，負責向用戶提供網(wǎng)絡(luò)服務(wù)，如文件傳輸、電子郵件、遠程登錄等。常見的應用層協(xié)議有HTTP、FTP、SMTP等，這些協(xié)議規(guī)定了應用程序接收的數(shù)據(jù)格式，使應用程序能夠解析數(shù)據(jù)并呈現(xiàn)到頁面上供用戶觀看。
2. 傳輸層：負責在源主機和目的主機之間提供端到端的數(shù)據(jù)傳輸服務(wù)，并解決諸如主機地址、端口號、數(shù)據(jù)傳輸狀態(tài)等問題。常見的傳輸層協(xié)議有TCP和UDP。
3. 網(wǎng)絡(luò)層：負責在多個主機之間傳送數(shù)據(jù)包，并為分組交換提供路由選擇功能。網(wǎng)絡(luò)層協(xié)議能夠確保數(shù)據(jù)包在網(wǎng)絡(luò)中正確傳輸，并選擇合適的路徑到達目的地。
4. 數(shù)據(jù)鏈路層：負責在物理層的傳輸介質(zhì)上傳送數(shù)據(jù)幀，并在源主機和目的主機之間建立邏輯鏈路。數(shù)據(jù)鏈路層通過幀的形式來傳輸數(shù)據(jù)，確保數(shù)據(jù)在傳輸過程中的完整性和可靠性。
5. 物理層：負責傳輸比特流的硬件部分，包括各種傳輸介質(zhì)（如銅線、光纖、無線信道）和傳輸設(shè)備（如集線器、交換機、路由器）。物理層為數(shù)據(jù)傳輸提供物質(zhì)基礎(chǔ)，確保數(shù)據(jù)能夠在不同的網(wǎng)絡(luò)設(shè)備之間順利傳輸。

2.請說一下socket網(wǎng)絡(luò)編程中客戶端和服務(wù)端用到哪些函數(shù)？

1）服務(wù)器端函數(shù)：

（1）socket創(chuàng)建一個套接字

（2）bind綁定ip和port

（3）listen使套接字變?yōu)榭梢员粍渔溄?/p>

（4）accept等待客戶端的鏈接

（5）write/read接收發(fā)送數(shù)據(jù)

（6）close關(guān)閉連接

2）客戶端函數(shù)：

（1）創(chuàng)建一個socket，用函數(shù)socket()

（2）bind綁定ip和port

（3）連接服務(wù)器，用函數(shù)connect()

（4）收發(fā)數(shù)據(jù)，用函數(shù)send()和recv()，或read()和write()

（5）close關(guān)閉連接

3.網(wǎng)絡(luò)四層模型

• 應用層 HTTP/TFTP

• 傳輸層 TCP/UDP

• 網(wǎng)絡(luò)層 IP/ICMP

• 網(wǎng)絡(luò)接口層

4.TCP如何保證可靠性？

（1) 檢驗和：

通過檢驗和的方式，接收端可以檢測出來數(shù)據(jù)是否有差錯和異常，假如有差錯就會直接丟棄TCP段，重新發(fā)送，TCP在計算檢驗和時，會在TCP首部加上一個12字節(jié)的偽首部。檢驗和總共計算三個部分：TCP首部、TCP數(shù)據(jù)、TCP偽首部；

（2) 序列號/確認應答、超時重傳：

數(shù)據(jù)到達接收方之后，接收方會發(fā)送一個確認應答，表示已經(jīng)收到數(shù)據(jù)段，并且確認序號會說明它下一次需要接收的數(shù)據(jù)序列號，如果發(fā)送方?jīng)]收到確認應答，那么發(fā)送方會進行重發(fā)，這個等待時間一般是2 * RTT（往返時間）+一個偏差值，如果一個包多次重發(fā)沒有收到接收端的確認包，就會強制關(guān)閉連接；

（3) 窗口控制與重發(fā)控制/快速重傳(重復確認應答)

TCP會利用窗口控制來提高傳輸速度，意思是在一個窗口大小內(nèi)，不用一定等到應答才能發(fā)送下一段數(shù)據(jù)，窗口大小就是無需等待確認而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值，如果不使用窗口控制，每一個沒收到應答的數(shù)據(jù)都要重發(fā)。

5.簡述 TCP 滑動窗口以及重傳機制

1）滑動窗口協(xié)議是傳輸層進行流控的一種措施，接收方通過通告發(fā)送方自己的窗口大小，從而控制發(fā)送方的發(fā)送速度，從而達到防止發(fā)送方發(fā)送速度過快而導致自己被淹沒的目的。滑動可以理解為緩沖區(qū)的大小，告訴發(fā)送方，自己還能接受多少數(shù)據(jù)

TCP的滑動窗口解決了端到端的流量控制問題，允許接受方對傳輸進行限制，直到它擁有足夠的緩沖空間來容納更多的數(shù)據(jù)。

2）TCP在發(fā)送數(shù)據(jù)時會設(shè)置一個計時器，若到計時器超時仍未收到數(shù)據(jù)確認信息，則會引發(fā)相應的超時或基于計時器的重傳操作，計時器超時稱為重傳超時（RTO） 。另一種方式的重傳稱為快速重傳，通常發(fā)生在沒有延時的情況下。若TCP累積確認無法返回新的ACK，或者當ACK包含的選擇確認信息（SACK）表明出現(xiàn)失序報文時，快速重傳會推斷出現(xiàn)丟包，需要重傳。

6.簡述 TCP 慢啟動

TCP慢啟動是傳輸控制協(xié)議（TCP）使用的一種阻塞控制機制，也被稱為指數(shù)增長期。慢啟動機制通過以指數(shù)增加的速率增加發(fā)送窗口的大小來實現(xiàn)流量控制，旨在避免在建立連接初期因發(fā)送大量數(shù)據(jù)而導致的網(wǎng)絡(luò)擁塞。

在慢啟動過程中，發(fā)送方將初始的擁塞窗口大小設(shè)置為一個較小的值，例如2個數(shù)據(jù)包大小。每當發(fā)送方成功接收到一個確認，擁塞窗口大小就會加倍，這意味著發(fā)送方可以發(fā)送更多的數(shù)據(jù)。然而，當擁塞窗口大小達到一個閾值（通常是網(wǎng)絡(luò)的帶寬延遲乘積）時，發(fā)送方將進入擁塞避免階段，此時發(fā)送方將以一個較慢的速率遞增擁塞窗口大小，通常是每次收到一個確認就增加一個數(shù)據(jù)包大小。如果在慢啟動或擁塞避免階段，發(fā)送方檢測到網(wǎng)絡(luò)擁塞，例如發(fā)生丟包，它將減少擁塞窗口的大小，并重新開始慢啟動過程。

7.TCP建立連接和斷開連接過程？

三次握手和四次揮手

三次握手目的：是為了確認客戶端和服務(wù)器都能收發(fā)

1. 客戶端向服務(wù)器發(fā)送一個SYN包，請求建立連接，并包含自身的初始序列號，等待服務(wù)器確認；
2. 服務(wù)器收到SYN包后，回復一個ACK應答包表示確認，同時發(fā)送一個SYN包，即SYN+ACK包，也包含自身的初始序列號。此時，服務(wù)器進入SYN_RECV狀態(tài)，等待客戶端的確認；
3. 客戶端收到服務(wù)器的SYN+ACK包后，再次向服務(wù)器發(fā)送一個ACK確認包，此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。

在三次握手過程中，客戶端和服務(wù)器通過交換SYN和ACK包來確認對方的存在和初始序列號，從而建立TCP連接。注意，握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。

四次揮手目的：是為了確認客戶端和服務(wù)器都結(jié)束收發(fā)

1. 客戶端向服務(wù)器發(fā)送一個FIN數(shù)據(jù)包，提出斷開連接的請求，并指定一個序列號。此時，客戶端進入FIN_WAIT1狀態(tài)，等待服務(wù)器的確認；
2. 服務(wù)器收到FIN包后，發(fā)送一個ACK應答包給客戶端，表示已經(jīng)收到并同意斷開連接。此時，客戶端進入FIN_WAIT2狀態(tài)，等待服務(wù)器完成數(shù)據(jù)傳輸并斷開連接；
3. 服務(wù)器在完成數(shù)據(jù)傳輸后，向客戶端發(fā)送一個FIN包，提出自己的斷開連接請求；
4. 客戶端收到服務(wù)器的FIN包后，回復一個ACK確認包給服務(wù)器，然后進入TIME_WAIT狀態(tài)，等待一段時間后最終關(guān)閉連接。而服務(wù)器在收到客戶端的ACK確認包后，直接關(guān)閉連接。

在四次揮手過程中，客戶端和服務(wù)器通過交換FIN和ACK包來逐步斷開連接。這種機制確保了雙方都能有序地關(guān)閉連接，并釋放相關(guān)資源，

需要注意的是，在斷開連接的過程中，客戶端需要等待一段時間（通常是2MSL，即最長報文段壽命的兩倍）才能最終關(guān)閉連接。這是為了防止已失效的連接請求報文段出現(xiàn)在新連接中，確保TCP連接的可靠關(guān)閉。

8.說說 TCP 2次握手行不行？為什么要3次

TCP的二次握手是不足以建立可靠連接的。TCP協(xié)議中采用三次握手而非二次握手來建立連接，主要是因為二次握手無法解決以下問題：

1. 確認雙方的通信能力：在二次握手中，只有發(fā)起方的序列號得到了確認，而服務(wù)器端的序列號得不到確認，因此，二次握手只能確定客戶端和服務(wù)器之間的連接是單向的，即客戶端可以向服務(wù)器發(fā)送數(shù)據(jù)，但服務(wù)器無法向客戶端發(fā)送數(shù)據(jù)。為了確保雙方的通信能力正常，需要引入第三次握手，使得客戶端能夠發(fā)送確認信息給服務(wù)器，從而確保雙方都可以正常發(fā)送和接收數(shù)據(jù)。
2. 避免歷史連接的干擾：二次握手無法防止歷史連接的干擾。在網(wǎng)絡(luò)中，可能存在舊的、失效的連接請求，如果僅采用二次握手，這些舊的請求可能會被錯誤地認為是新的連接請求，從而導致資源浪費和數(shù)據(jù)混亂。通過引入第三次握手，可以確保服務(wù)器在收到連接請求時能夠正確處理，避免重復連接的建立。
3. 確保數(shù)據(jù)包的傳輸和完整性：三次握手通過交換三個不同的數(shù)據(jù)包來確認雙方的序列號和窗口大小，從而確保后續(xù)的數(shù)據(jù)傳輸是可靠和完整的。如果只有二次握手，那么可能在某些情況下，數(shù)據(jù)傳輸?shù)目煽啃院屯暾詿o法得到保障。

因此，TCP協(xié)議選擇使用三次握手來建立連接，以確保數(shù)據(jù)傳輸?shù)目煽啃?、完整性和穩(wěn)定性。這種設(shè)計使得TCP成為一種高度可靠和廣泛應用的傳輸協(xié)議。

9.TCP只進行3次揮手可以嗎？

如果采用三次揮手來斷開TCP連接，可能會導致以下問題：

• 服務(wù)器在發(fā)送完ACK應答報文后直接關(guān)閉連接，但此時可能還有未處理完的數(shù)據(jù)或延遲的數(shù)據(jù)包，這些數(shù)據(jù)將會丟失。
• 客戶端在發(fā)送FIN報文后，沒有收到服務(wù)器的確認就直接關(guān)閉連接，無法保證服務(wù)器已經(jīng)正確接收到關(guān)閉請求。

因此，四次揮手是為了更可靠地關(guān)閉TCP連接，確保雙方都能有序地釋放資源并關(guān)閉連接。

10.TCP連接和關(guān)閉的狀態(tài)轉(zhuǎn)移

在連接建立階段，狀態(tài)轉(zhuǎn)移如下：

1. CLOSED：這是TCP連接的初始狀態(tài)，表示尚未開始任何連接；
2. LISTEN：當服務(wù)器端調(diào)用listen()系統(tǒng)調(diào)用后，它進入LISTEN狀態(tài)，等待客戶端的連接請求；
3. SYN_SENT：當客戶端想要建立連接時，它會發(fā)送一個帶有SYN標志的TCP報文到服務(wù)器，并進入SYN_SENT狀態(tài)，等待服務(wù)器的確認；
4. SYN_RECEIVED：服務(wù)器一旦收到客戶端的SYN報文，會發(fā)送一個帶有SYN和ACK標志的響應報文給客戶端，并進入SYN_RCVD狀態(tài)；
5. ESTABLISHED：一旦客戶端收到服務(wù)器的SYN+ACK響應并發(fā)送ACK確認報文給服務(wù)器，雙方都進入ESTABLISHED狀態(tài)，這時連接已經(jīng)建立，可以進行數(shù)據(jù)傳輸。

在連接關(guān)閉階段，狀態(tài)轉(zhuǎn)移如下：

1. FIN_WAIT_1：當一方想要關(guān)閉連接時，它會發(fā)送一個FIN報文給另一方，并進入FIN_WAIT_1狀態(tài)，等待對方的確認；
2. CLOSE_WAIT：當另一方收到FIN報文后，它會發(fā)送一個ACK報文進行確認，并進入CLOSE_WAIT狀態(tài)，等待本地應用層關(guān)閉連接；
3. LAST_ACK：當本地應用層決定關(guān)閉連接時，它會發(fā)送一個FIN報文給對方，并進入LAST_ACK狀態(tài)，等待對方對FIN報文的最終確認；
4. FIN_WAIT_2：發(fā)送FIN報文的一方在收到對方的ACK報文后，會進入FIN_WAIT_2狀態(tài)，等待對方發(fā)送FIN報文來關(guān)閉連接；
5. TIME_WAIT：當發(fā)送最后一個ACK報文的一方，在發(fā)送完報文后會進入TIME_WAIT狀態(tài)，等待一段時間（通常是2MSL，即兩倍的最大段生命周期）以確保對方收到了ACK報文，然后最終進入CLOSED狀態(tài)；
6. CLOSED：當連接的所有過程都完成后，雙方最終都會進入CLOSED狀態(tài)，表示連接已經(jīng)關(guān)閉。

11.滑動窗口過小怎么辦？

當滑動窗口過小時，可以通過以下方式進行調(diào)整：

在TCP協(xié)議中，滑動窗口的大小是根據(jù)網(wǎng)絡(luò)擁塞情況動態(tài)調(diào)整的。當網(wǎng)絡(luò)出現(xiàn)擁塞時，發(fā)送方會減小窗口大小以降低數(shù)據(jù)發(fā)送速率，避免進一步加劇擁塞。相反，當網(wǎng)絡(luò)負載較輕時，發(fā)送方可以增大窗口大小以提高數(shù)據(jù)傳輸速率；

具體的調(diào)整過程包括慢啟動、擁塞避免、快重傳與快恢復等機制。慢啟動階段，TCP協(xié)議初始設(shè)置較小的滑動窗口大小，并隨著傳輸?shù)某晒Υ_認逐漸增大窗口大小。擁塞避免階段，滑動窗口以一定的速率增長，但增長速率更緩慢，以避免引發(fā)網(wǎng)絡(luò)擁塞。當接收方收到失序的數(shù)據(jù)時，會發(fā)送冗余的確認信息給發(fā)送方，觸發(fā)快重傳和快恢復機制，在此過程中，發(fā)送方將減小滑動窗口大小，以便重新發(fā)送丟失的數(shù)據(jù)，并恢復正常的發(fā)送速率。

12.說說三次握手中每次握手信息對方?jīng)]有收到會怎樣？

如果第一次握手消息丟失，那么請求方不會得到ack消息，超時后進行重傳，

如果第二次握手消息丟失，那么請求方不會得到ack消息，超時后進行重傳，

如果第三次握手消息丟失，那么Server 端該TCP連接的狀態(tài)為SYN_RECV,并且會根據(jù) TCP的超時重傳機制，會等待3秒、6秒、12秒后重新發(fā)送SYN+ACK包，以便Client重新發(fā)送ACK包，如果重發(fā)指定次數(shù)之后，仍然未收到 client 的ACK應答，那么一段時間后，Server自動關(guān)閉這個連接。

13.簡述 TCP 和 UDP 的區(qū)別，它們的頭部結(jié)構(gòu)是什么樣的

TCP協(xié)議是有連接的，有連接的意思是開始傳輸實際數(shù)據(jù)之前TCP的客戶端和服務(wù)器端必須通過三次握手建立連接，會話結(jié)束之后也要結(jié)束連接，而UDP是無連接的，

TCP首部需20個字節(jié)（不算可選項），UDP首部字段只需8個字節(jié)，

TCP有流量控制和擁塞控制，UDP沒有，網(wǎng)絡(luò)擁堵不會影響發(fā)送端的發(fā)送速率，

TCP是一對一的連接，而UDP則可以支持一對一，多對多，一對多的通信，

TCP面向的是字節(jié)流的服務(wù)，UDP面向的是報文的服務(wù)。

14.簡述域名解析過程，本機如何干預域名解析

域名解析的基本過程如下：

1. 客戶機提出域名解析請求，并將該請求發(fā)送給本地的域名服務(wù)器；
2. 當本地的域名服務(wù)器收到請求后，先查詢本地的緩存。如果有該記錄項，則直接把查詢的結(jié)果返回給客戶機；
3. 如果本地的緩存中沒有該記錄，則本地域名服務(wù)器直接把請求發(fā)給根域名服務(wù)器，根域名服務(wù)器再返回給本地域名服務(wù)器一個所查詢域（根的子域）的主域名服務(wù)器的地址；
4. 本地服務(wù)器再向上一步返回的域名服務(wù)器發(fā)送請求，然后接受請求的服務(wù)器查詢自己的緩存，如果沒有該記錄，則返回相關(guān)的下級的域名服務(wù)器的地址；
5. 重復上一步驟，直到找到正確的記錄；
6. 本地域名服務(wù)器把返回的結(jié)果保存到緩存，以備下一次使用，同時還將結(jié)果返回給客戶機。

對于本機如何干預域名解析，以下是一些建議：

1. 清除瀏覽器緩存：瀏覽器有時會緩存域名解析結(jié)果，如果緩存的結(jié)果有誤，可能導致訪問問題，因此，清除瀏覽器緩存可能有助于解決域名解析相關(guān)的問題；
2. 檢查并更改DNS設(shè)置：用戶可以檢查電腦或路由器的DNS設(shè)置是否正確。如果DNS設(shè)置不正確，可能會導致域名解析錯誤。此時，可以嘗試更改DNS設(shè)置，然后重新訪問網(wǎng)站，看是否能夠解決問題；
3. 更換DNS服務(wù)器：如果懷疑當前的DNS服務(wù)器存在問題，可以嘗試更換為其他的公共DNS服務(wù)器，如Google DNS或OpenDNS，然后重新訪問網(wǎng)站，看是否能夠解決問題；
4. 檢查域名注冊信息：域名注冊信息的過期或錯誤也可能導致域名解析問題。用戶可以檢查域名注冊信息是否正確，是否過期，如果有問題，需要及時更新。

15.說說什么是 TCP 粘包和拆包？

TCP粘包和拆包是在網(wǎng)絡(luò)通信中常見的問題，與數(shù)據(jù)的發(fā)送和接收方式密切相關(guān)；

TCP粘包是指發(fā)送方發(fā)送的多個小數(shù)據(jù)包被接收方一次性接收的情況，這可能是因為發(fā)送方發(fā)送數(shù)據(jù)的速度過快，接收方無法及時處理，從而多個數(shù)據(jù)包被合并成一個大的數(shù)據(jù)包一起接收。具體來說，當發(fā)送方連續(xù)發(fā)送多個數(shù)據(jù)包時，TCP協(xié)議可能會將這些數(shù)據(jù)包打包成一個TCP報文發(fā)送出去，這樣，接收方在讀取緩沖區(qū)時，可能會發(fā)現(xiàn)原本應該分開讀取的數(shù)據(jù)包粘在了一起；

而TCP拆包則是指發(fā)送方發(fā)送的一個大數(shù)據(jù)包被接收方拆分成多個小的數(shù)據(jù)包接收的情況，這可能是由于網(wǎng)絡(luò)中的路由器、交換機等設(shè)備的限制，導致大的數(shù)據(jù)包在傳輸過程中被分割成多個小的數(shù)據(jù)包，接收方需要能夠正確地組裝這些小數(shù)據(jù)包以還原原始的大數(shù)據(jù)包；

TCP粘包和拆包問題通常與網(wǎng)絡(luò)狀況、數(shù)據(jù)包大小、發(fā)送和接收方的處理速度等因素有關(guān)，為了避免這些問題，可以采取一些策略，如設(shè)置合適的數(shù)據(jù)包大小、使用應用層協(xié)議來處理數(shù)據(jù)包的邊界等；

總之，TCP粘包和拆包是網(wǎng)絡(luò)通信中需要注意和處理的問題，以確保數(shù)據(jù)的正確傳輸和接收。

16.如何解決粘包和拆包問題

TCP粘包和拆包問題可以通過以下幾種方式來解決：

1. 消息定長：這是一種簡單的解決方案，它要求所有的數(shù)據(jù)包都是固定長度的。這樣，接收方就可以按照固定長度來進行接收，從而避免了粘包和拆包問題。然而，這種方法對于不固定長度的數(shù)據(jù)無法解決粘包和拆包問題。
2. 消息分隔符：在每個數(shù)據(jù)包的結(jié)尾加上一個特定的分隔符，接收方可以根據(jù)這個分隔符來判斷每個數(shù)據(jù)包的結(jié)束位置，從而解決粘包和拆包問題。這種方法需要保證分隔符在數(shù)據(jù)包中不會出現(xiàn)，或者即使出現(xiàn)也不會引起混淆。
3. 使用定長協(xié)議：規(guī)定每次發(fā)送的數(shù)據(jù)包都是固定長度，例如每次發(fā)送100個字節(jié)。如果發(fā)送的數(shù)據(jù)長度不足100字節(jié)，則在后面填充空格或者其他特定字符；如果超過100字節(jié)，則進行截斷處理。這樣可以保證每次接收到的數(shù)據(jù)都是固定長度的，從而解決了TCP粘包和拆包問題。但是，這種方法需要預先約定每次發(fā)送的數(shù)據(jù)包長度，因此不太靈活，無法適應數(shù)據(jù)長度不固定的情況。

需要注意的是，這些方法并非完美無缺，每種方法都有其適用的場景和局限性。在實際應用中，需要根據(jù)具體的需求和網(wǎng)絡(luò)環(huán)境來選擇合適的解決方案。同時，對于復雜的數(shù)據(jù)傳輸任務(wù)，可能需要結(jié)合使用多種方法來更好地解決TCP粘包和拆包問題。

17.TCP為什么比UDP可靠

TCP比UDP更可靠的原因主要在于TCP協(xié)議設(shè)計了一套復雜的機制來保證數(shù)據(jù)傳輸?shù)目煽啃?#xff0c;具體如下：

1. 確認應答機制：TCP使用確認應答機制來確保數(shù)據(jù)包的正確傳輸。發(fā)送方每發(fā)送一個數(shù)據(jù)包，都需要等待接收方的確認應答。只有當收到確認應答后，發(fā)送方才會繼續(xù)發(fā)送下一個數(shù)據(jù)包。這種機制確保了數(shù)據(jù)的可靠傳輸，避免了數(shù)據(jù)的丟失；
2. 超時重傳機制：如果發(fā)送方在一段時間內(nèi)沒有收到接收方的確認應答，它會認為數(shù)據(jù)包已經(jīng)丟失，并會重新發(fā)送該數(shù)據(jù)包。這種超時重傳機制進一步保證了數(shù)據(jù)的可靠性；
3. 連接管理：TCP在數(shù)據(jù)傳輸前需要進行三次握手來建立連接，確保雙方通信的正常。這種連接管理不僅為數(shù)據(jù)傳輸提供了通道，還增加了數(shù)據(jù)傳輸?shù)目煽啃?#xff1b;
4. 流量控制和擁塞控制：TCP協(xié)議通過流量控制和擁塞控制機制，避免了數(shù)據(jù)傳輸過程中的丟失和擁塞。流量控制使得發(fā)送方可以根據(jù)接收方的接收能力來發(fā)送數(shù)據(jù)，避免數(shù)據(jù)過快發(fā)送導致接收方無法處理。而擁塞控制則使得發(fā)送方在網(wǎng)絡(luò)擁塞時能夠降低發(fā)送速率，從而避免數(shù)據(jù)的丟失。

相比之下，UDP協(xié)議則是一種無連接的協(xié)議，它不需要建立連接，也不進行確認應答和重傳。因此，UDP在傳輸數(shù)據(jù)時可能會出現(xiàn)數(shù)據(jù)的丟失、亂序等問題，可靠性較差。然而，UDP協(xié)議由于其無連接性質(zhì)和簡單性，在某些對實時性要求較高或需要一對多、多對多通信的場景中仍具有優(yōu)勢。

18.什么是HTTP/TFTP

HTTP和TFTP都是網(wǎng)絡(luò)傳輸協(xié)議。

HTTP，全稱Hypertext Transfer Protocol，即超文本傳輸協(xié)議，是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。它建立在TCP之上，是基于請求與響應范式的、無狀態(tài)的、應用層的協(xié)議。HTTP協(xié)議以鏈接從一個超文本服務(wù)器傳輸?shù)搅硪粋€超文本服務(wù)器、從一個鏈接到一個鏈接從一個資源到另一個資源。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示（如文本先于圖形）等。

TFTP則是Trivial File Transfer Protocol的簡稱，即簡單文件傳輸協(xié)議。它用于在客戶機與服務(wù)器之間進行簡單文件傳輸，提供不復雜、開銷不大的文件傳輸服務(wù)。TFTP建立在UDP之上，提供不可靠的數(shù)據(jù)流傳輸服務(wù)，不提供存取授權(quán)與認證機制，使用超時重傳方式來保證數(shù)據(jù)的到達。

總的來說，HTTP和TFTP在網(wǎng)絡(luò)傳輸中各有其用，前者主要用于超文本傳輸，后者則主要用于簡單的文件傳輸。

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

客戶端在發(fā)送最后一個ACK包后，需要等待2MSL（兩倍的報文最大生存時間）的原因主要有以下幾點：

1. 確保最后一個ACK包傳輸成功：在TCP協(xié)議中，發(fā)送的每個數(shù)據(jù)包都有一個TTL（Time To Live）屬性。當網(wǎng)絡(luò)發(fā)生擁塞時，報文可能會被重傳或丟棄。因此，客戶端發(fā)送最后一個ACK包后，需要等待一段時間以確保這個ACK包已經(jīng)順利被服務(wù)器接收到并處理完畢。如果等待時間不夠，可能由于網(wǎng)絡(luò)延遲或丟包導致服務(wù)器未收到ACK，從而引發(fā)不必要的重傳或其他問題。
2. 避免“舊連接”數(shù)據(jù)混亂：在網(wǎng)絡(luò)中，可能存在新舊連接使用相同端口和IP地址的情況。如果舊連接的某些信息沒有及時清除，就可能產(chǎn)生數(shù)據(jù)混亂。等待2MSL可以確保舊連接的狀態(tài)信息完全釋放，避免新連接使用到還未完全釋放的舊連接資源，從而確保數(shù)據(jù)傳輸?shù)恼_性和可靠性。
3. 保證TCP協(xié)議的全雙工連接可靠關(guān)閉：TCP協(xié)議要求全雙工連接的可靠關(guān)閉。等待2MSL是TCP協(xié)議關(guān)閉連接過程中的一個必要步驟，它確保了連接的雙方都能夠正確地關(guān)閉連接，避免了因連接未完全關(guān)閉而導致的各種問題。

20.什么時候用TCP，UDP？

當需要確保數(shù)據(jù)的完整性和可靠性時，應使用TCP；而當對實時性要求較高且可以容忍少量數(shù)據(jù)丟失時，可以使用UDP，不過具體的選擇應根據(jù)應用的需求和網(wǎng)絡(luò)環(huán)境來確定。

21.什么是IP/ICMP？

IP（Internet Protocol）即網(wǎng)際互連協(xié)議，是TCP/IP體系中的網(wǎng)絡(luò)層協(xié)議。設(shè)計IP的目的是提高網(wǎng)絡(luò)的可擴展性，實現(xiàn)大規(guī)模、異構(gòu)網(wǎng)絡(luò)的互聯(lián)互通，并分割頂層網(wǎng)絡(luò)應用和底層網(wǎng)絡(luò)技術(shù)之間的耦合關(guān)系，以利于兩者的獨立發(fā)展。IP為主機提供一種無連接、不可靠的、盡力而為的數(shù)據(jù)包傳輸服務(wù)。

ICMP（Internet Control Message Protocol）即互聯(lián)網(wǎng)控制報文協(xié)議，是TCP/IP協(xié)議簇的一個子協(xié)議，用于在IP主機、路由器之間傳遞控制消息。這些控制消息主要涉及網(wǎng)絡(luò)通不通、主機是否可達、路由是否可用等網(wǎng)絡(luò)本身的消息。雖然ICMP并不傳輸用戶數(shù)據(jù)，但它對于用戶數(shù)據(jù)的傳遞起著重要的作用。ICMP協(xié)議是一個無連接的協(xié)議，它并不提供可靠的數(shù)據(jù)傳輸，主要用于在IP網(wǎng)絡(luò)上進行錯誤報告和診斷，以便源地址得知數(shù)據(jù)包傳輸失敗的原因并進行相應的處理。

簡而言之，IP協(xié)議負責在網(wǎng)絡(luò)層進行數(shù)據(jù)包的傳輸，而ICMP協(xié)議則在網(wǎng)絡(luò)層提供控制和診斷功能，兩者共同協(xié)作以確保網(wǎng)絡(luò)數(shù)據(jù)的正確和高效傳輸。

22. 什么是字節(jié)序 ？

字節(jié)序，又稱端序或端模式，是字節(jié)順序的一種。在多字節(jié)數(shù)據(jù)類型的值中，字節(jié)序用于標示存放順序。常見的字節(jié)序有小端字節(jié)序（little-endian）和大端字節(jié)序（big-endian）。小端字節(jié)序?qū)⒌托蜃止?jié)存儲在起始地址處，即最前面的字節(jié)是最低有效字節(jié)；而大端字節(jié)序則是將高序字節(jié)存儲在起始地址處，即最前面的字節(jié)是最高有效字節(jié)，這兩種字節(jié)序在網(wǎng)絡(luò)通信和數(shù)據(jù)存儲中都有廣泛的應用，理解字節(jié)序?qū)τ谡_處理跨平臺數(shù)據(jù)和網(wǎng)絡(luò)通信中的數(shù)據(jù)交換至關(guān)重要。