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

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

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

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

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

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

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

（2）bind綁定ip和port

（3）listen使套接字變?yōu)榭梢员粍?dòng)鏈接

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

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

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

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

（1）創(chuàng)建一個(gè)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ò)四層模型

• 應(yīng)用層 HTTP/TFTP

• 傳輸層 TCP/UDP

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

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

4.TCP如何保證可靠性？

（1) 檢驗(yàn)和：

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

（2) 序列號(hào)/確認(rèn)應(yīng)答、超時(shí)重傳：

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

（3) 窗口控制與重發(fā)控制/快速重傳(重復(fù)確認(rèn)應(yīng)答)

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

5.簡(jiǎn)述 TCP 滑動(dòng)窗口以及重傳機(jī)制

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

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

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

6.簡(jiǎn)述 TCP 慢啟動(dòng)

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

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

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

三次握手和四次揮手

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

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

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

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

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

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

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

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

TCP的二次握手是不足以建立可靠連接的。TCP協(xié)議中采用三次握手而非二次握手來建立連接，主要是因?yàn)槎挝帐譄o法解決以下問題：

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

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

9.TCP只進(jìn)行3次揮手可以嗎？

如果采用三次揮手來斷開TCP連接，可能會(huì)導(dǎo)致以下問題：

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

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

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

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

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

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

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

11.滑動(dòng)窗口過小怎么辦？

當(dāng)滑動(dòng)窗口過小時(shí)，可以通過以下方式進(jìn)行調(diào)整：

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

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

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

如果第一次握手消息丟失，那么請(qǐng)求方不會(huì)得到ack消息，超時(shí)后進(jìn)行重傳，

如果第二次握手消息丟失，那么請(qǐng)求方不會(huì)得到ack消息，超時(shí)后進(jìn)行重傳，

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

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

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

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

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

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

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

14.簡(jiǎn)述域名解析過程，本機(jī)如何干預(yù)域名解析

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

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

對(duì)于本機(jī)如何干預(yù)域名解析，以下是一些建議：

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

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

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

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

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

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

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

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

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

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

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

17.TCP為什么比UDP可靠

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

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

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

18.什么是HTTP/TFTP

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

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

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

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

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

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

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

20.什么時(shí)候用TCP，UDP？

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

21.什么是IP/ICMP？

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

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

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

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

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