"你準(zhǔn)備好接受面試了嗎?"

"當(dāng)然是。請開始。"

"大。能否談?wù)勀銓τ嬎銠C(jī)網(wǎng)絡(luò)的了解?也許我們可以從TCP是什么以及它如何工作開始。"

"嗯……嗯……嗯……"

"好的，謝謝你今天的時間。請等待未來幾天的進(jìn)一步通知。"

這看起來和你的經(jīng)歷相似嗎?

不要放棄， 你絕對可以做得更好。

這是技術(shù)面試中會遇到的一些常見計算機(jī)網(wǎng)絡(luò)問題。它們大多數(shù)與應(yīng)用程序，傳輸和網(wǎng)絡(luò)層有關(guān)。你可以按照本指南從頭開始學(xué)習(xí)計算機(jī)網(wǎng)絡(luò)，并向面試官清楚地解釋它們。

[[358249]]

1. 計算機(jī)網(wǎng)絡(luò)的體系結(jié)構(gòu)是什么?

通常，計算機(jī)網(wǎng)絡(luò)概念通常分為5個主要層。這是OSI(開放系統(tǒng)互連)模型和TCP / IP模型的組合，分別具有7層和4層。

> Different Models of Computer Networks (Image by Author)

2. 每層的功能是什么?

以下介紹將基于OSI網(wǎng)絡(luò)模型：

• 應(yīng)用程序?qū)樱簯?yīng)用程序?qū)拥娜蝿?wù)是指定主機(jī)運行的應(yīng)用程序進(jìn)程之間的通信協(xié)議或接口。應(yīng)用層中有一些通用協(xié)議，例如HTTP(超文本傳輸協(xié)議)，DNS(域名系統(tǒng))和SMTP。
• 表示層：此層主要負(fù)責(zé)將來自應(yīng)用程序?qū)拥臄?shù)據(jù)轉(zhuǎn)換為所需的格式(例如ASCII)。此處完成了一些工作，例如數(shù)據(jù)加密/解密和壓縮。
• 會話層：此層負(fù)責(zé)在兩個進(jìn)程之間建立和維護(hù)連接或會話。它還允許進(jìn)程添加檢查點以進(jìn)行同步。
• 傳輸層：它通過網(wǎng)絡(luò)在應(yīng)用程序之間提供端到端的數(shù)據(jù)(段)傳輸服務(wù)。傳輸層最著名的協(xié)議是TCP(傳輸控制協(xié)議)和UDP(用戶數(shù)據(jù)報協(xié)議)。
• 網(wǎng)絡(luò)層：網(wǎng)絡(luò)層負(fù)責(zé)數(shù)據(jù)包(數(shù)據(jù)塊)的路由。具體來說，網(wǎng)絡(luò)層選擇合適的傳輸路徑，并從其他網(wǎng)絡(luò)發(fā)送和接收IP(互聯(lián)網(wǎng)協(xié)議)數(shù)據(jù)包。
• 數(shù)據(jù)鏈路層：該層將來自網(wǎng)絡(luò)層的IP數(shù)據(jù)包封裝為幀，并通過鏈路節(jié)點發(fā)送它們。幀傳輸取決于MAC(消息訪問控制)地址?？梢酝ㄟ^發(fā)送ARP(地址解析協(xié)議)請求來獲取接收者的MAC地址，以查看是否有任何節(jié)點具有所需的IP地址。
• 物理層：負(fù)責(zé)節(jié)點之間的位傳輸，這是物理連接(通過物理數(shù)據(jù)鏈路)，并盡可能消除設(shè)備之間的差異。

3. 傳輸層中的TCP和UDP是什么?他們有什么區(qū)別?

TCP(傳輸控制協(xié)議)是一種面向連接的服務(wù)，這意味著它在傳輸數(shù)據(jù)之前建立連接，并在傳輸之后關(guān)閉連接。

TCP的可靠性反映在通過三向握手建立連接，以及一些機(jī)制如錯誤檢測，流控制，擁塞控制和重傳。這些功能將花費大量開銷并占用處理器資源。

TCP通常用于文件傳輸，郵件的發(fā)送和接收以及遠(yuǎn)程登錄。

UDP(用戶數(shù)據(jù)報協(xié)議)不需要在數(shù)據(jù)傳輸之前建立連接，這意味著遠(yuǎn)程主機(jī)在接收到UDP段之后不需要進(jìn)行確認(rèn)。

盡管UDP無法提供可靠的傳輸，但它在某些情況下(通常是即時消息傳遞)是最有效的服務(wù)，例如實時音頻和視頻流。

> TCP v.s. UDP (Image by Author)

4. TCP如何建立和終止連接?

我們首先來看一下如何在客戶端/服務(wù)器模型中建立TCP連接，該模型通常稱為三向握手：

• 客戶端：它發(fā)送一個SYN段，該段請求服務(wù)器將其序列號與客戶端的序列號同步。
• 服務(wù)器：從客戶端接收到數(shù)據(jù)包后，服務(wù)器將返回SYN和ACK段，這會通知客戶端已收到該數(shù)據(jù)包，并要求其提供用于確認(rèn)的預(yù)期序列號。
• 客戶端：它發(fā)送回帶有ACK段的數(shù)據(jù)包，該數(shù)據(jù)包通知服務(wù)器已正確接收了返回的數(shù)據(jù)包。

> TCP Connection Establishment (Image by Author)

SYN段確認(rèn)從發(fā)送方到接收方的路由沒有問題，但是從接收方到發(fā)送方的路由應(yīng)由ACK段確認(rèn)。

接下來，我們將討論TCP如何在"客戶端/服務(wù)器"模型中終止連接，這是一個四次握手過程：

• 客戶端：決定關(guān)閉連接后，客戶端將向服務(wù)器發(fā)送FIN段。然后，客戶端將進(jìn)入FIN_WAIT_1狀態(tài)，等待來自服務(wù)器的確認(rèn)。
• 服務(wù)器：一旦接收到來自客戶端的FIN段，它將發(fā)送回ACK段。
• 客戶端：從服務(wù)器接收到ACK段后，它進(jìn)入FIN_WAIT_2狀態(tài)，服務(wù)器正在等待另一端發(fā)送的FIN段。
• 服務(wù)器：它還會關(guān)閉與客戶端的連接，并在發(fā)送ACK段后發(fā)送FIN段。
• 客戶端：接收到來自服務(wù)器的ACK段后，客戶端會發(fā)回最終的ACK段進(jìn)行確認(rèn)。之后，客戶端將進(jìn)入TIME_WAIT狀態(tài)，如果另一端未收到最終的ACK段，則客戶端將在一段時間后正式關(guān)閉。

5. 什么是ARQ(自動重復(fù)請求)?

ARQ是一種錯誤控制方法，用于在傳輸層和數(shù)據(jù)鏈路層中進(jìn)行數(shù)據(jù)傳輸。

確認(rèn)和超時用于確保可靠的數(shù)據(jù)傳輸。如果接收方在給定時間內(nèi)沒有收到確認(rèn)，它將重新發(fā)送同一數(shù)據(jù)包，直到返回確認(rèn)或超出預(yù)定義的重傳時間為止。

有兩種類型的ARQ，包括：

• 停止等待ARQ：停止等待ARQ的基本思想是發(fā)送方每次發(fā)送數(shù)據(jù)包后都會停止數(shù)據(jù)傳輸。如果在給定時間后未收到接收方的確認(rèn)，則傳輸將被視為失敗。這意味著應(yīng)該重新傳輸數(shù)據(jù)，直到收到確認(rèn)為止。如果接收方收到重復(fù)的數(shù)據(jù)包，則應(yīng)放棄此數(shù)據(jù)包并同時發(fā)送回確認(rèn)。
• Go-Back-N ARQ：發(fā)件人維護(hù)一個滑動窗口，該窗口中的數(shù)據(jù)包可以連續(xù)發(fā)送，無需等待確認(rèn)。接收器通常僅接收有序數(shù)據(jù)包，并在最后一個數(shù)據(jù)包到達(dá)后發(fā)回累積ACK。

6. TCP如何實現(xiàn)流量控制?

流控制的目的是控制數(shù)據(jù)包發(fā)送的速度，以確保接收方可以及時接收到它。

TCP可以通過滑動窗口來實現(xiàn)流控制。發(fā)送方的滑動窗口大小可以由接收方返回的ACK段控制，這也可能影響發(fā)送速度。

7. TCP如何實現(xiàn)擁塞控制?

當(dāng)對網(wǎng)絡(luò)資源的請求超出其可以處理的數(shù)據(jù)量時，就會發(fā)生網(wǎng)絡(luò)擁塞。

擁塞控制是為了防止過多的數(shù)據(jù)注入網(wǎng)絡(luò)，以使網(wǎng)絡(luò)鏈接或節(jié)點不會過載。

TCP擁塞控制采用多種策略，包括：

• 啟動緩慢：TCP不會首先將少量數(shù)據(jù)發(fā)送并在每個RTT(往返時間)后按指數(shù)方式逐漸增加擁塞窗口(cwnd)大小，而不是將大量數(shù)據(jù)吸收到網(wǎng)絡(luò)中。
• 避免擁塞：擁塞窗口(cwnd)大小達(dá)到閾值后，它開始累加地增加以避免網(wǎng)絡(luò)擁塞。
• 擁塞檢測：這發(fā)生在發(fā)生擁塞時，擁塞窗口大小將成倍減小。假定在需要重發(fā)分組時發(fā)生擁塞。
• 快速重傳和恢復(fù)(FRR)：這是一種擁塞控制算法，可以快速恢復(fù)丟失的數(shù)據(jù)包。如果沒有FRR，TCP將通過計時器暫停傳輸。在暫停期間，不會傳輸新的數(shù)據(jù)包。使用FRR，如果接收器收到一個分段，它將立即返回一個重復(fù)的ACK分段。發(fā)送方將在接收到三個重復(fù)的ACK段后假定該段丟失。FRR減少了重傳的延遲。

8. 從輸入URL到顯示網(wǎng)頁的過程是什么?

此過程可以分為幾個步驟：

• DNS解析。
• 建立一個TCP連接。
• 發(fā)送HTTP請求。
• 服務(wù)器處理該請求并返回HTTP響應(yīng)。
• 瀏覽器呈現(xiàn)網(wǎng)頁。
• 緊密連接。

> The Process of Accessing URL and Protocols Used (Image by Author)

8. HTTP如何保存用戶狀態(tài)?

HTTP是一種"無狀態(tài)"協(xié)議，這意味著它不會保存請求和響應(yīng)本身之間的連接狀態(tài)。

那么我們?nèi)绾伪４嬗脩魻顟B(tài)?

管理會話以解決此問題。會話的主要功能是從服務(wù)器端記錄用戶狀態(tài)。

例如，當(dāng)您將一些產(chǎn)品放入亞馬遜購物車，并考慮以后再購買時。由于實際上是無狀態(tài)的，因此系統(tǒng)實際上不知道是誰通過HTTP保存這些項目。因此，服務(wù)器將為您創(chuàng)建并保留一個特定的會話，從而可以跟蹤您的購物信息。

9. 什么是計算機(jī)網(wǎng)絡(luò)中的cookie?Cookies和會話之間有什么區(qū)別?

Cookie和會話都可以跟蹤和存儲用戶身份，但是它們通常用于不同的情況。

Cookies通常用于存儲用戶信息。例如，在登錄網(wǎng)站后，下次無需再次登錄，因為我們的安全詳細(xì)信息已作為令牌存儲在cookie中。系統(tǒng)僅需根據(jù)令牌值查找用戶。

會話通過服務(wù)器記錄用戶狀態(tài)。使用會話的典型場景是在線購物車。由于HTTP是無狀態(tài)的，因此服務(wù)器將通過將用戶標(biāo)記為會話來跟蹤用戶狀態(tài)。

Cookie數(shù)據(jù)存儲在客戶端(瀏覽器)上，而會話數(shù)據(jù)存儲在服務(wù)器端。這意味著與cookie相比，會話具有更高的安全級別。

10. HTTP和HTTPS有什么區(qū)別?

HTTP超出了TCP的范圍，并使用純文本傳輸內(nèi)容?？蛻舳撕头?wù)器端都無法驗證彼此的身份。

HTTPS(安全超文本傳輸協(xié)議)是運行在SSL / TLS之外的HTTP，而SSL / TLS運行在TCP / IP之外。傳輸?shù)乃袃?nèi)容均已加密。

因此，HTTPS的安全性高于HTTP，但是HTTPS比HTTP需要更多的資源。

需要明確的是，仍然有許多與計算機(jī)網(wǎng)絡(luò)有關(guān)的知識。由于常見的技術(shù)面試，尤其是初級軟件工程師的面試通常集中在網(wǎng)絡(luò)層的上半部分，因此我們所看到的那些問題只是該領(lǐng)域的一小部分。