當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

大厂面试题之计算机网络重点篇 (附答案)

發布時間：2023/12/16 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了大厂面试题之计算机网络重点篇 (附答案) 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

一、ISO 七層模型中表示層和會話層功能是什么？

表示層：圖像、視頻編碼解，數據加密。
會話層：建立會話，如 session 認證、斷點續傳。

二、三次握手四次揮手的變遷圖

《TCP/IP 詳解卷 1:協議》有一張 TCP 狀態變遷圖，很具有代表性，有助于大家理解三次握手和四次揮手的狀態變化。如下圖所示，粗的實線箭頭表示正常的客戶端狀態變遷，粗的虛線箭頭表示正常的服務器狀態變遷。

三、對稱密鑰加密的優點缺點？

對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。

優點：運算速度快
缺點：無法安全地將密鑰傳輸給通信方

四、非對稱密鑰加密你了解嗎？優缺點？

非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不同的密鑰。

公開密鑰所有人都可以獲得，通信發送方獲得接收方的公開密鑰之后，就可以使用公開密鑰進行加密，接收方收到通信內容后使用私有密鑰解密。

非對稱密鑰除了用來加密，還可以用來進行簽名。因為私有密鑰無法被其他人獲取，因此通信發送方使用其私有密鑰進行簽名，通信接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。

優點：可以更安全地將公開密鑰傳輸給通信發送方；
缺點：運算速度慢。

五、HTTPS 是什么

HTTPS 并不是新協議，而是讓?HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是說 HTTPS 使用了隧道進行通信。通過使用 SSL，HTTPS 具有了加密（防竊聽）、認證（防偽裝）和完整性保護（防篡改）。

六、HTTP 的缺點有哪些？

使用明文進行通信，內容可能會被竊聽；
不驗證通信方的身份，通信方的身份有可能遭遇偽裝；
無法證明報文的完整性，報文有可能遭篡改。

七、HTTPS 采用的加密方式有哪些？是對稱還是非對稱？

HTTPS 采用混合的加密機制，使用非對稱密鑰加密用于傳輸對稱密鑰來保證傳輸過程的安全性，之后使用對稱密鑰加密進行通信來保證通信過程的效率。

確保傳輸安全過程（其實就是 rsa 原理）：

Client 給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。

Server 確認雙方使用的加密方法，并給出數字證書、以及一個服務器生成的隨機數（Server random）。

Client 確認數字證書有效，然后生成呀一個新的隨機數（Premaster secret），并使用數字證書中的公鑰，加密這個隨機數，發給 Server。

Server 使用自己的私鑰，獲取 Client 發來的隨機數（Premaster secret）。

Client 和 Server 根據約定的加密方法，使用前面的三個隨機數，生成”對話密鑰”（session key），用來加密接下來的整個對話過程。

八、為什么有的時候刷新頁面不需要重新建立 SSL 連接？

TCP 連接有的時候會被瀏覽器和服務端維持一段時間，TCP 不需要重新建立，SSL 自然也會用之前的。

九、SSL 中的認證中的證書是什么？了解過嗎？

通過使用?證書?來對通信方進行認證。

數字證書認證機構（CA，Certificate Authority）是客戶端與服務器雙方都可信賴的第三方機構。

服務器的運營人員向 CA 提出公開密鑰的申請，CA 在判明提出申請者的身份之后，會對已申請的公開密鑰做數字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起。

進行 HTTPS 通信時，服務器會把證書發送給客戶端。客戶端取得其中的公開密鑰之后，先使用數字簽名進行驗證，如果驗證通過，就可以開始通信了。

十、HTTP 如何禁用緩存？如何確認緩存？

HTTP/1.1 通過 Cache-Control 首部字段來控制緩存。

禁止進行緩存

no-store 指令規定不能對請求或響應的任何一部分進行緩存。

Cache-Control:?no-store

復制代碼

強制確認緩存

no-cache 指令規定緩存服務器需要先向源服務器驗證緩存資源的有效性，只有當緩存資源有效時才能使用該緩存對客戶端的請求進行響應。

Cache-Control:?no-cache

復制代碼

十一、GET 與 POST 傳遞數據的最大長度能夠達到多少呢？

get 是通過 URL 提交數據，因此 GET 可提交的數據量就跟 URL 所能達到的最大長度有直接關系。

很多文章都說 GET 方式提交的數據最多只能是 1024 字節，而實際上，URL 不存在參數上限的問題，HTTP 協議規范也沒有對 URL 長度進行限制。

這個限制是特定的瀏覽器及服務器對它的限制，比如 IE 對 URL 長度的限制是 2083 字節(2K+35 字節)。對于其他瀏覽器，如 FireFox，Netscape 等，則沒有長度限制，這個時候其限制取決于服務器的操作系統；即如果 url 太長，服務器可能會因為安全方面的設置從而拒絕請求或者發生不完整的數據請求。

post 理論上講是沒有大小限制的，HTTP 協議規范也沒有進行大小限制，但實際上 post 所能傳遞的數據量大小取決于服務器的設置和內存大小。

因為我們一般 post 的數據量很少超過 MB 的，所以我們很少能感覺的到 post 的數據量限制，但實際中如果你上傳文件的過程中可能會發現這樣一個問題，即上傳個頭比較大的文件到服務器時候，可能上傳不上去。

以 php 語言來說，查原因的時候你也許會看到有說 PHP 上傳文件涉及到的參數 PHP 默認的上傳有限定，一般這個值是 2MB，更改這個值需要更改 php.conf 的 post_max_size 這個值。這就很明白的說明了這個問題了。

十二、網絡層常見協議？可以說一下嗎？

十三、TCP 四大擁塞控制算法總結？（極其重要）

四大算法

擁塞控制主要是四個算法：1）慢啟動，2）擁塞避免，3）擁塞發生，4）快速恢復。這四個算法不是一天都搞出來的，這個四算法的發展經歷了很多時間，到今天都還在優化中。

慢熱啟動算法 – Slow Start

所謂慢啟動，也就是 TCP 連接剛建立，一點一點地提速，試探一下網絡的承受能力，以免直接擾亂了網絡通道的秩序。

慢啟動算法：

連接建好的開始先初始化擁塞窗口 cwnd 大小為 1，表明可以傳一個 MSS 大小的數據。

每當收到一個 ACK，cwnd 大小加一，呈線性上升。

每當過了一個往返延遲時間 RTT(Round-Trip Time)，cwnd 大小直接翻倍，乘以 2，呈指數讓升。

還有一個 ssthresh（slow start threshold），是一個上限，當 cwnd >= ssthresh 時，就會進入“擁塞避免算法”（后面會說這個算法）

擁塞避免算法 – Congestion Avoidance

如同前邊說的，當擁塞窗口大小 cwnd 大于等于慢啟動閾值 ssthresh 后，就進入擁塞避免算法。算法如下：

收到一個 ACK，則 cwnd = cwnd + 1 / cwnd

每當過了一個往返延遲時間 RTT，cwnd 大小加一。

過了慢啟動閾值后，擁塞避免算法可以避免窗口增長過快導致窗口擁塞，而是緩慢的增加調整到網絡的最佳值。

擁塞發生狀態時的算法

一般來說，TCP 擁塞控制默認認為網絡丟包是由于網絡擁塞導致的，所以一般的 TCP 擁塞控制算法以丟包為網絡進入擁塞狀態的信號。對于丟包有兩種判定方式，一種是超時重傳 RTO[Retransmission Timeout]超時，另一個是收到三個重復確認 ACK。

超時重傳是 TCP 協議保證數據可靠性的一個重要機制，其原理是在發送一個數據以后就開啟一個計時器，在一定時間內如果沒有得到發送數據報的 ACK 報文，那么就重新發送數據，直到發送成功為止。

但是如果發送端接收到 3 個以上的重復 ACK，TCP 就意識到數據發生丟失，需要重傳。這個機制不需要等到重傳定時器超時，所以叫做快速重傳，而快速重傳后沒有使用慢啟動算法，而是擁塞避免算法，所以這又叫做快速恢復算法。

超時重傳 RTO[Retransmission Timeout]超時，TCP 會重傳數據包。TCP 認為這種情況比較糟糕，反應也比較強烈：

由于發生丟包，將慢啟動閾值 ssthresh 設置為當前 cwnd 的一半，即 ssthresh = cwnd / 2.
cwnd 重置為 1
進入慢啟動過程

最為早期的 TCP Tahoe 算法就只使用上述處理辦法，但是由于一丟包就一切重來，導致 cwnd 又重置為 1，十分不利于網絡數據的穩定傳遞。

所以，TCP Reno 算法進行了優化。當收到三個重復確認 ACK 時，TCP 開啟快速重傳 Fast Retransmit 算法，而不用等到 RTO 超時再進行重傳：

cwnd 大小縮小為當前的一半
ssthresh 設置為縮小后的 cwnd 大小
然后進入快速恢復算法 Fast Recovery。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-3YbvAruW-1668422170817)(https://upload-images.jianshu.io/upload_images/26756112-758a3df884c2db51?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

快速恢復算法 – Fast Recovery

TCP Tahoe 是早期的算法，所以沒有快速恢復算法，而 Reno 算法有。在進入快速恢復之前，cwnd 和 ssthresh 已經被更改為原有 cwnd 的一半。快速恢復算法的邏輯如下：

cwnd = cwnd + 3 MSS，加 3 MSS 的原因是因為收到 3 個重復的 ACK。
重傳 DACKs 指定的數據包。
如果再收到 DACKs，那么 cwnd 大小增加一。
如果收到新的 ACK，表明重傳的包成功了，那么退出快速恢復算法。將 cwnd 設置為 ssthresh，然后進入擁塞避免算法。

如圖所示，第五個包發生了丟失，所以導致接收方接收到三次重復 ACK，也就是 ACK5。所以將 ssthresh 設置當當時 cwnd 的一半，也就是 6/2 = 3，cwnd 設置為 3 + 3 = 6。然后重傳第五個包。當收到新的 ACK 時，也就是 ACK11，則退出快速恢復階段，將 cwnd 重新設置為當前的 ssthresh，也就是 3，然后進入擁塞避免算法階段。

十四、為何快速重傳是選擇 3 次 ACK？

主要的考慮還是要區分包的丟失是由于鏈路故障還是亂序等其他因素引發。

兩次 duplicated ACK 時很可能是亂序造成的！三次 duplicated ACK 時很可能是丟包造成的！四次 duplicated ACK 更更更可能是丟包造成的，但是這樣的響應策略太慢。丟包肯定會造成三次 duplicated ACK!綜上是選擇收到三個重復確認時窗口減半效果最好，這是實踐經驗。

在沒有 fast retransmit / recovery 算法之前，重傳依靠發送方的 retransmit timeout，就是在 timeout 內如果沒有接收到對方的 ACK，默認包丟了，發送方就重傳，包的丟失原因

1）包 checksum 出錯

2）網絡擁塞

3）網絡斷，包括路由重收斂，但是發送方無法判斷是哪一種情況，于是采用最笨的辦法，就是將自己的發送速率減半，即 CWND 減為 1/2，這樣的方法對 2 是有效的，可以緩解網絡擁塞，3 則無所謂，反正網絡斷了，無論發快發慢都會被丟；但對于 1 來說，丟包是因為偶爾的出錯引起，一丟包就對半減速不合理。

于是有了 fast retransmit 算法，基于在反向還可以接收到 ACK，可以認為網絡并沒有斷，否則也接收不到 ACK，如果在 timeout 時間內沒有接收到> 2 的 duplicated ACK，則概率大事件為亂序，亂序無需重傳，接收方會進行排序工作；

而如果接收到三個或三個以上的 duplicated ACK，則大概率是丟包，可以邏輯推理，發送方可以接收 ACK，則網絡是通的，可能是 1、2 造成的，先不降速，重傳一次，如果接收到正確的 ACK，則一切 OK，流速依然（包出錯被丟）。

而如果依然接收到 duplicated ACK，則認為是網絡擁塞造成的，此時降速則比較合理。

十五、對于 FIN_WAIT_2，CLOSE_WAIT 狀態和 TIME_WAIT 狀態？你知道多少?

FIN_WAIT_2：

半關閉狀態。
發送斷開請求一方還有接收數據能力，但已經沒有發送數據能力。

CLOSE_WAIT 狀態：

被動關閉連接一方接收到 FIN 包會立即回應 ACK 包表示已接收到斷開請求。
被動關閉連接一方如果還有剩余數據要發送就會進入 CLOSED_WAIT 狀態。

TIME_WAIT 狀態：

又叫 2MSL 等待狀態。
如果客戶端直接進入 CLOSED 狀態，如果服務端沒有接收到最后一次 ACK 包會在超時之后重新再發 FIN 包，此時因為客戶端已經 CLOSED，所以服務端就不會收到 ACK 而是收到 RST。所以 TIME_WAIT 狀態目的是防止最后一次握手數據沒有到達對方而觸發重傳 FIN 準備的。
在 2MSL 時間內，同一個 socket 不能再被使用，否則有可能會和舊連接數據混淆（如果新連接和舊連接的 socket 相同的話）。

十六、你了解流量控制原理嗎？

目的是接收方通過 TCP 頭窗口字段告知發送方本方可接收的最大數據量，用以解決發送速率過快導致接收方不能接收的問題。所以流量控制是點對點控制。

TCP 是雙工協議，雙方可以同時通信，所以發送方接收方各自維護一個發送窗和接收窗。

發送窗：用來限制發送方可以發送的數據大小，其中發送窗口的大小由接收端返回的 TCP 報文段中窗口字段來控制，接收方通過此字段告知發送方自己的緩沖（受系統、硬件等限制）大小。
接收窗：用來標記可以接收的數據大小。

發送窗內數據只有當接收到接收端某段發送數據的 ACK 響應時才移動發送窗，左邊緣緊貼剛被確認的數據。接收窗也只有接收到數據且最左側連續時才移動接收窗口。

十七、建立 TCP 服務器的各個系統調用過程是怎樣的？

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-v8XmRB5k-1668422170818)(https://upload-images.jianshu.io/upload_images/26756112-4813e62902863611?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-OGeLNvMR-1668422170819)(https://upload-images.jianshu.io/upload_images/26756112-c50ed983bf5e51a1?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

服務器：

fd：accept 返回的連接描述字，每個連接有一個，生命周期為連接周期。
注：sockfd 是監聽描述字，一個服務器只有一個，用于監聽是否有連接；fd 是連接描述字，用于每個連接的操作。
fd：連接描述字。
buf：緩沖區 buf。
count：緩沖區長度。
注：大于 0 表示讀取的字節數，返回 0 表示文件讀取結束，小于 0 表示發生錯誤。
sockfd：服務器 socket 描述字。
addr：指向地址結構指針。
addrlen：協議地址長度。
注：一旦 accept 某個客戶機請求成功將返回一個全新的描述符用于標識具體客戶的 TCP 連接。
sockfd：要監聽的 sock 描述字。
backlog：socket 可以排隊的最大連接數。
sockfd：socket 返回的套接字描述符，類似于文件描述符 fd。
addr：有個 sockaddr 類型數據的指針，指向的是被綁定結構變量。
addrlen：地址長度。
domain：協議域，決定了 socket 的地址類型，IPv4 為 AF_INET。
type：指定 socket 類型，SOCK_STREAM 為 TCP 連接。
protocol：指定協議。IPPROTO_TCP 表示 TCP 協議，為 0 時自動選擇 type 默認協議。
創建 socket -> int socket(int domain, int type, int protocol);
綁定 socket 和端口號 -> int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

????//?IPv4的sockaddr地址結構

復制代碼

監聽端口號 -> int listen(int sockfd, int backlog);
接收用戶請求 -> int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
從 socket 中讀取字符 -> ssize_t read(int fd, void *buf, size_t count);
關閉 socket -> int close(int fd);

客戶機：

fd：同服務器端 fd。
fd、buf、count：同 read 中意義。
大于 0 表示寫了部分或全部數據，小于 0 表示出錯。
sockfd 客戶端的 sock 描述字。
addr：服務器的地址。
addrlen：socket 地址長度。
創建 socket -> int socket(int domain, int type, int protocol);
連接指定計算機 -> int connect(int sockfd, struct sockaddr* addr, socklen_t addrlen);
向 socket 寫入信息 -> ssize_t write(int fd, const void *buf, size_t count);
關閉 oscket -> int close(int fd);

十八、TCP 協議如何保證可靠傳輸？

第一種回答

**確認和重傳：**接收方收到報文就會確認，發送方發送一段時間后沒有收到確認就會重傳。
**數據校驗：**TCP 報文頭有校驗和，用于校驗報文是否損壞。
數據合理分片和排序：tcp 會按最大傳輸單元(MTU)合理分片，接收方會緩存未按序到達的數據，重新排序后交給應用層。而 UDP：IP 數據報大于 1500 字節，大于 MTU。這個時候發送方的 IP 層就需要分片，把數據報分成若干片，是的每一片都小于 MTU。而接收方 IP 層則需要進行數據報的重組。由于 UDP 的特性，某一片數據丟失時，接收方便無法重組數據報，導致丟棄整個 UDP 數據報。
**流量控制：**當接收方來不及處理發送方的數據，能通過滑動窗口，提示發送方降低發送的速率，防止包丟失。
**擁塞控制：**當網絡擁塞時，通過擁塞窗口，減少數據的發送，防止包丟失。

第二種回答

建立連接（標志位）：通信前確認通信實體存在。
序號機制（序號、確認號）：確保了數據是按序、完整到達。
數據校驗（校驗和）：CRC 校驗全部數據。
超時重傳（定時器）：保證因鏈路故障未能到達數據能夠被多次重發。
窗口機制（窗口）：提供流量控制，避免過量發送。
擁塞控制：同上。

第三種回答

首部校驗這個校驗機制能夠確保數據傳輸不會出錯嗎？答案是不能。

原因

TCP 協議中規定，TCP 的首部字段中有一個字段是校驗和，發送方將偽首部、TCP 首部、TCP 數據使用累加和校驗的方式計算出一個數字，然后存放在首部的校驗和字段里，接收者收到 TCP 包后重復這個過程，然后將計算出的校驗和和接收到的首部中的校驗和比較，如果不一致則說明數據在傳輸過程中出錯。

這就是 TCP 的數據校驗機制。但是這個機制能夠保證檢查出一切錯誤嗎？顯然不能。

因為這種校驗方式是累加和，也就是將一系列的數字（TCP 協議規定的是數據中的每 16 個比特位數據作為一個數字）求和后取末位。但是小學生都知道 A+B=B+A，假如在傳輸的過程中有前后兩個 16 比特位的數據前后顛倒了（至于為什么這么巧合？我不知道，也許路由器有 bug？也許是宇宙中的高能粒子擊中了電纜？反正這個事情的概率不為零，就有可能會發生），那么校驗和的計算結果和顛倒之前是一樣的，那么接收端肯定無法檢查出這是錯誤的數據。

解決方案

傳輸之前先使用 MD5 加密數據獲得摘要，跟數據一起發送到服務端，服務端接收之后對數據也進行 MD5 加密，如果加密結果和摘要一致，則認為沒有問題

十九、UDP 是什么

提供無連接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

二十、TCP 和 UDP 的區別

1、TCP 面向連接（如打電話要先撥號建立連接）;UDP 是無連接的，即發送數據之前不需要建立連接

2、TCP 提供可靠的服務。也就是說，通過 TCP 連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP 盡最大努力交付，即不保證可靠交付

3、TCP 面向字節流，實際上是 TCP 把數據看成一連串無結構的字節流;UDP 是面向報文的

UDP 沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如 IP 電話，實時視頻會議等）

4、每一條 TCP 連接只能是點到點的;UDP 支持一對一，一對多，多對一和多對多的交互通信

5、TCP 首部開銷 20 字節;UDP 的首部開銷小，只有 8 個字節

6、TCP 的邏輯通信信道是全雙工的可靠信道，UDP 則是不可靠信道

7、UDP 是面向報文的，發送方的 UDP 對應用層交下來的報文，不合并，不拆分，只是在其上面加上首部后就交給了下面的網絡層，論應用層交給 UDP 多長的報文，它統統發送，一次發送一個。而對接收方，接到后直接去除首部，交給上面的應用層就完成任務了。因此，它需要應用層控制報文的大小

TCP 是面向字節流的，它把上面應用層交下來的數據看成無結構的字節流會發送，可以想象成流水形式的，發送方 TCP 會將數據放入“蓄水池”（緩存區），等到可以發送的時候就發送，不能發送就等著 TCP 會根據當前網絡的擁塞狀態來確定每個報文段的大小。

二十一、UDP 的特點有哪些（附贈 TCP 的特點）？

UDP 是無連接的；
UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態（這里面有許多參數）；
UDP 是面向報文的；
UDP 沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如 IP 電話，實時視頻會議等）；
UDP 支持一對一、一對多、多對一和多對多的交互通信；
UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要短。

那么，再說一次 TCP 的特點：

TCP 是面向連接的。（就好像打電話一樣，通話前需要先撥號建立連接，通話結束后要掛機釋放連接）；
每一條 TCP 連接只能有兩個端點，每一條 TCP 連接只能是點對點的（一對一）；
TCP 提供可靠交付的服務。通過 TCP 連接傳送的數據，無差錯、不丟失、不重復、并且按序到達；
TCP 提供全雙工通信。TCP 允許通信雙方的應用進程在任何時候都能發送數據。TCP 連接的兩端都設有發送緩存和接收緩存，用來臨時存放雙方通信的數據；
面向字節流。TCP 中的“流”（stream）指的是流入進程或從進程流出的字節序列。“面向字節流”的含義是：雖然應用程序和 TCP 的交互是一次一個數據塊（大小不等），但 TCP 把應用程序交下來的數據僅僅看成是一連串的無結構的字節流。

二十二、TCP 對應的應用層協議

FTP：定義了文件傳輸協議，使用 21 端口. Telnet：它是一種用于遠程登陸的端口,23 端口 SMTP：定義了簡單郵件傳送協議，服務器開放的是 25 號端口。POP3：它是和 SMTP 對應，POP3 用于接收郵件。

二十三、UDP 對應的應用層協議

DNS：用于域名解析服務，用的是 53 號端口 SNMP：簡單網絡管理協議，使用 161 號端口 TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，69

二十四、數據鏈路層常見協議？可以說一下嗎？

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-YqrYsdoE-1668422170820)(https://upload-images.jianshu.io/upload_images/26756112-853f0833c4a02441?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

二十五、Ping 命令基于哪一層協議的原理是什么？

ping 命令基于網絡層的命令，是基于 ICMP 協議工作的。

二十六、在進行 UDP 編程的時候，一次發送多少 bytes 好?

當然,這個沒有唯一答案，相對于不同的系統,不同的要求,其得到的答案是不一樣的。

我這里僅對像 ICQ 一類的發送聊天消息的情況作分析，對于其他情況，你或許也能得到一點幫助:首先,我們知道,TCP/IP 通常被認為是一個四層協議系統,包括鏈路層,網絡層,運輸層,應用層.UDP 屬于運輸層,

下面我們由下至上一步一步來看:以太網(Ethernet)數據幀的長度必須在 46-1500 字節之間,這是由以太網的物理特性決定的.這個 1500 字節被稱為鏈路層的 MTU(最大傳輸單元).但這并不是指鏈路層的長度被限制在 1500 字節,其實這這個 MTU 指的是鏈路層的數據區.并不包括鏈路層的首部和尾部的 18 個字節.

所以,事實上,這個 1500 字節就是網絡層 IP 數據報的長度限制。因為 IP 數據報的首部為 20 字節,所以 IP 數據報的數據區長度最大為 1480 字節.而這個 1480 字節就是用來放 TCP 傳來的 TCP 報文段或 UDP 傳來的 UDP 數據報的.又因為 UDP 數據報的首部 8 字節,所以 UDP 數據報的數據區最大長度為 1472 字節.這個 1472 字節就是我們可以使用的字節數。

當我們發送的 UDP 數據大于 1472 的時候會怎樣呢？這也就是說 IP 數據報大于 1500 字節,大于 MTU.這個時候發送方 IP 層就需要分片(fragmentation). 把數據報分成若干片,使每一片都小于 MTU.而接收方 IP 層則需要進行數據報的重組. 這樣就會多做許多事情,而更嚴重的是,由于 UDP 的特性,當某一片數據傳送中丟失時,接收方便無法重組數據報.將導致丟棄整個 UDP 數據報。

因此,在普通的局域網環境下，我建議將 UDP 的數據控制在 1472 字節以下為好.

進行 Internet 編程時則不同,因為 Internet 上的路由器可能會將 MTU 設為不同的值. 如果我們假定 MTU 為 1500 來發送數據的,而途經的某個網絡的 MTU 值小于 1500 字節,那么系統將會使用一系列的機制來調整 MTU 值,使數據報能夠順利到達目的地,這樣就會做許多不必要的操作.

鑒于 Internet 上的標準 MTU 值為 576 字節,所以我建議在進行 Internet 的 UDP 編程時. 最好將 UDP 的數據長度控件在 548 字節(576-8-20)以內

二十七、TCP 利用滑動窗口實現流量控制的機制？

“流量控制是為了控制發送方發送速率，保證接收方來得及接收。TCP 利用滑動窗口實現流量控制。

TCP 中采用滑動窗口來進行傳輸控制，滑動窗口的大小意味著接收方還有多大的緩沖區可以用于接收數據。發送方可以通過滑動窗口的大小來確定應該發送多少字節的數據。當滑動窗口為 0 時，發送方一般不能再發送數據報，但有兩種情況除外，一種情況是可以發送緊急數據。

“例如，允許用戶終止在遠端機上的運行進程。另一種情況是發送方可以發送一個 1 字節的數據報來通知接收方重新聲明它希望接收的下一字節及發送方的滑動窗口大小。

二十八、可以解釋一下 RTO，RTT 和超時重傳分別是什么嗎？

超時重傳：發送端發送報文后若長時間未收到確認的報文則需要重發該報文。可能有以下幾種情況：發送的數據沒能到達接收端，所以對方沒有響應。接收端接收到數據，但是 ACK 報文在返回過程中丟失。接收端拒絕或丟棄數據。
RTO：從上一次發送數據，因為長期沒有收到 ACK 響應，到下一次重發之間的時間。就是重傳間隔。通常每次重傳 RTO 是前一次重傳間隔的兩倍，計量單位通常是 RTT。例：1RTT，2RTT，4RTT，8RTT…重傳次數到達上限之后停止重傳。
RTT：數據從發送到接收到對方響應之間的時間間隔，即數據報在網絡中一個往返用時。大小不穩定。

二十九、XSS 攻擊是什么？（低頻）

跨站點腳本攻擊，指攻擊者通過篡改網頁，嵌入惡意腳本程序，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操作的一種攻擊方式。如何防范 XSS 攻擊 1）前端，服務端，同時需要字符串輸入的長度限制。2）前端，服務端，同時需要對 HTML 轉義處理。將其中的”<”,”>”等特殊字符進行轉義編碼。防 XSS 的核心是必須對輸入的數據做過濾處理。

三十、CSRF 攻擊？你知道嗎？

跨站點請求偽造，指攻擊者通過跨站請求，以合法的用戶的身份進行非法操作。可以這么理解 CSRF 攻擊：攻擊者盜用你的身份，以你的名義向第三方網站發送惡意請求。CRSF 能做的事情包括利用你的身份發郵件，發短信，進行交易轉賬，甚至盜取賬號信息。

如何防范 CSRF 攻擊？

安全框架，例如 Spring Security。

token 機制。在 HTTP 請求中進行 token 驗證，如果請求中沒有 token 或者 token 內容不正確，則認為 CSRF 攻擊而拒絕該請求。

驗證碼。通常情況下，驗證碼能夠很好的遏制 CSRF 攻擊，但是很多情況下，出于用戶體驗考慮，驗證碼只能作為一種輔助手段，而不是最主要的解決方案。

referer 識別。在 HTTP Header 中有一個字段 Referer，它記錄了 HTTP 請求的來源地址。如果 Referer 是其他網站，就有可能是 CSRF 攻擊，則拒絕該請求。但是，服務器并非都能取到 Referer。很多用戶出于隱私保護的考慮，限制了 Referer 的發送。在某些情況下，瀏覽器也不會發送 Referer，例如 HTTPS 跳轉到 HTTP。

1）驗證請求來源地址；

2）關鍵操作添加驗證碼；

3）在請求地址添加 token 并驗證。

三十一、文件上傳漏洞是如何發生的？你有經歷過嗎？

文件上傳漏洞，指的是用戶上傳一個可執行的腳本文件，并通過此腳本文件獲得了執行服務端命令的能力。許多第三方框架、服務，都曾經被爆出文件上傳漏洞，比如很早之前的 Struts2，以及富文本編輯器等等，可被攻擊者上傳惡意代碼，有可能服務端就被人黑了。

如何防范文件上傳漏洞？

文件上傳的目錄設置為不可執行。

1）判斷文件類型。在判斷文件類型的時候，可以結合使用 MIME Type，后綴檢查等方式。因為對于上傳文件，不能簡單地通過后綴名稱來判斷文件的類型，因為攻擊者可以將可執行文件的后綴名稱改為圖片或其他后綴類型，誘導用戶執行。2）對上傳的文件類型進行白名單校驗，只允許上傳可靠類型。

3）上傳的文件需要進行重新命名，使攻擊者無法猜想上傳文件的訪問路徑，將極大地增加攻擊成本，同時向 shell.php.rar.ara 這種文件，因為重命名而無法成功實施攻擊。

4）限制上傳文件的大小。

5）單獨設置文件服務器的域名。

三十二、擁塞控制原理聽說過嗎？

擁塞控制目的是防止數據被過多注網絡中導致網絡資源（路由器、交換機等）過載。因為擁塞控制涉及網絡鏈路全局，所以屬于全局控制。控制擁塞使用擁塞窗口。
TCP 擁塞控制算法：慢開始 & 擁塞避免：先試探網絡擁塞程度再逐漸增大擁塞窗口。每次收到確認后擁塞窗口翻倍，直到達到閥值 ssthresh，這部分是慢開始過程。達到閥值后每次以一個 MSS 為單位增長擁塞窗口大小，當發生擁塞（超時未收到確認），將閥值減為原先一半，繼續執行線性增加，這個過程為擁塞避免。快速重傳 & 快速恢復：略。最終擁塞窗口會收斂于穩定值。

三十三、如何區分流量控制和擁塞控制？

流量控制屬于通信雙方協商；擁塞控制涉及通信鏈路全局。
流量控制需要通信雙方各維護一個發送窗、一個接收窗，對任意一方，接收窗大小由自身決定，發送窗大小由接收方響應的 TCP 報文段中窗口值確定；擁塞控制的擁塞窗口大小變化由試探性發送一定數據量數據探查網絡狀況后而自適應調整。
實際最終發送窗口 = min{流控發送窗口，擁塞窗口}。

三十四、常見的 HTTP 狀態碼有哪些？

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Gbcs7W7q-1668422170820)(https://upload-images.jianshu.io/upload_images/26756112-49a6fb4d869016a7?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]

1xx 信息

100 Continue ：表明到目前為止都很正常，客戶端可以繼續發送請求或者忽略這個響應。

2xx 成功

200 OK
204 No Content ：請求已經成功處理，但是返回的響應報文不包含實體的主體部分。一般在只需要從客戶端往服務器發送信息，而不需要返回數據時使用。
206 Partial Content ：表示客戶端進行了范圍請求，響應報文包含由 Content-Range 指定范圍的實體內容。

3xx 重定向

301 Moved Permanently ：永久性重定向
302 Found ：臨時性重定向
303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應該采用 GET 方法獲取資源。
304 Not Modified ：如果請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務器會返回 304 狀態碼。
307 Temporary Redirect ：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法。

4xx 客戶端錯誤

400 Bad Request ：請求報文中存在語法錯誤。
401 Unauthorized ：該狀態碼表示發送的請求需要有認證信息（BASIC 認證、DIGEST 認證）。如果之前已進行過一次請求，則表示用戶認證失敗。
403 Forbidden ：請求被拒絕。
404 Not Found

5xx 服務器錯誤

500 Internal Server Error ：服務器正在執行請求時發生錯誤。
503 Service Unavailable ：服務器暫時處于超負載或正在進行停機維護，現在無法處理請求。
【這里想說，因為自己也走了很多彎路過來的，所以才下定決心整理，收集過程雖不易，但想到能幫助到一部分自學或者是想提升java技術、成為Java架構師，提升技術P5-P6-P7-P8 的人，心里也是甜的！有需要的伙伴請點?方】↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

總結

以上是生活随笔為你收集整理的大厂面试题之计算机网络重点篇 (附答案)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：织梦手机站站内搜索
下一篇： after meet KeyNi liu