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

• 表示層：圖像、視頻編碼解，數(shù)據(jù)加密。

• 會話層：建立會話，如 session 認證、斷點續(xù)傳。

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

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

三、對稱密鑰加密的優(yōu)點缺點？

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

• 優(yōu)點：運算速度快

• 缺點：無法安全地將密鑰傳輸給通信方

四、非對稱密鑰加密你了解嗎？優(yōu)缺點？

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

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

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

• 優(yōu)點：可以更安全地將公開密鑰傳輸給通信發(fā)送方；

• 缺點：運算速度慢。

五、HTTPS 是什么

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

六、HTTP 的缺點有哪些？

• 使用明文進行通信，內(nèi)容可能會被竊聽；

• 不驗證通信方的身份，通信方的身份有可能遭遇偽裝；

• 無法證明報文的完整性，報文有可能遭篡改。

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

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

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

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

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

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

Server 使用自己的私鑰，獲取 Client 發(fā)來的隨機數(shù)（Premaster secret）。

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

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

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

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

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

數(shù)字證書認證機構(gòu)（CA，Certificate Authority）是客戶端與服務(wù)器雙方都可信賴的第三方機構(gòu)。

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

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

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

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

禁止進行緩存

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

Cache-Control:?no-store

復(fù)制代碼

強制確認緩存

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

Cache-Control:?no-cache

復(fù)制代碼

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

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

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

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

post 理論上講是沒有大小限制的，HTTP 協(xié)議規(guī)范也沒有進行大小限制，但實際上 post 所能傳遞的數(shù)據(jù)量大小取決于服務(wù)器的設(shè)置和內(nèi)存大小。

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

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

十二、網(wǎng)絡(luò)層常見協(xié)議？可以說一下嗎？

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

四大算法

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

慢熱啟動算法 – Slow Start

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

慢啟動算法：

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

每當(dāng)收到一個 ACK，cwnd 大小加一，呈線性上升。

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

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

擁塞避免算法 – Congestion Avoidance

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

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

每當(dāng)過了一個往返延遲時間 RTT，cwnd 大小加一。

過了慢啟動閾值后，擁塞避免算法可以避免窗口增長過快導(dǎo)致窗口擁塞，而是緩慢的增加調(diào)整到網(wǎng)絡(luò)的最佳值。

擁塞發(fā)生狀態(tài)時的算法

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

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

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

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

• 由于發(fā)生丟包，將慢啟動閾值 ssthresh 設(shè)置為當(dāng)前 cwnd 的一半，即 ssthresh = cwnd / 2.

• cwnd 重置為 1

• 進入慢啟動過程

最為早期的 TCP Tahoe 算法就只使用上述處理辦法，但是由于一丟包就一切重來，導(dǎo)致 cwnd 又重置為 1，十分不利于網(wǎng)絡(luò)數(shù)據(jù)的穩(wěn)定傳遞。

所以，TCP Reno 算法進行了優(yōu)化。當(dāng)收到三個重復(fù)確認 ACK 時，TCP 開啟快速重傳 Fast Retransmit 算法，而不用等到 RTO 超時再進行重傳：

• cwnd 大小縮小為當(dāng)前的一半

• ssthresh 設(shè)置為縮小后的 cwnd 大小

• 然后進入快速恢復(fù)算法 Fast Recovery。

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

快速恢復(fù)算法 – Fast Recovery

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

• cwnd = cwnd + 3 MSS，加 3 MSS 的原因是因為收到 3 個重復(fù)的 ACK。

• 重傳 DACKs 指定的數(shù)據(jù)包。

• 如果再收到 DACKs，那么 cwnd 大小增加一。

• 如果收到新的 ACK，表明重傳的包成功了，那么退出快速恢復(fù)算法。將 cwnd 設(shè)置為 ssthresh，然后進入擁塞避免算法。

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

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

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

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

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

1）包 checksum 出錯

2）網(wǎng)絡(luò)擁塞

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

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

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

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

十五、對于 FIN_WAIT_2，CLOSE_WAIT 狀態(tài)和 TIME_WAIT 狀態(tài)？你知道多少?

FIN_WAIT_2：

• 半關(guān)閉狀態(tài)。

• 發(fā)送斷開請求一方還有接收數(shù)據(jù)能力，但已經(jīng)沒有發(fā)送數(shù)據(jù)能力。

CLOSE_WAIT 狀態(tài)：

• 被動關(guān)閉連接一方接收到 FIN 包會立即回應(yīng) ACK 包表示已接收到斷開請求。

• 被動關(guān)閉連接一方如果還有剩余數(shù)據(jù)要發(fā)送就會進入 CLOSED_WAIT 狀態(tài)。

TIME_WAIT 狀態(tài)：

• 又叫 2MSL 等待狀態(tài)。

• 如果客戶端直接進入 CLOSED 狀態(tài)，如果服務(wù)端沒有接收到最后一次 ACK 包會在超時之后重新再發(fā) FIN 包，此時因為客戶端已經(jīng) CLOSED，所以服務(wù)端就不會收到 ACK 而是收到 RST。所以 TIME_WAIT 狀態(tài)目的是防止最后一次握手數(shù)據(jù)沒有到達對方而觸發(fā)重傳 FIN 準備的。

• 在 2MSL 時間內(nèi)，同一個 socket 不能再被使用，否則有可能會和舊連接數(shù)據(jù)混淆（如果新連接和舊連接的 socket 相同的話）。

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

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

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

• 發(fā)送窗：用來限制發(fā)送方可以發(fā)送的數(shù)據(jù)大小，其中發(fā)送窗口的大小由接收端返回的 TCP 報文段中窗口字段來控制，接收方通過此字段告知發(fā)送方自己的緩沖（受系統(tǒng)、硬件等限制）大小。

• 接收窗：用來標(biāo)記可以接收的數(shù)據(jù)大小。

TCP 是流數(shù)據(jù)，發(fā)送出去的數(shù)據(jù)流可以被分為以下四部分：已發(fā)送且被確認部分 | 已發(fā)送未被確認部分 | 未發(fā)送但可發(fā)送部分 | 不可發(fā)送部分，其中發(fā)送窗 = 已發(fā)送未確認部分 + 未發(fā)但可發(fā)送部分。接收到的數(shù)據(jù)流可分為：已接收 | 未接收但準備接收 | 未接收不準備接收。接收窗 = 未接收但準備接收部分。

發(fā)送窗內(nèi)數(shù)據(jù)只有當(dāng)接收到接收端某段發(fā)送數(shù)據(jù)的 ACK 響應(yīng)時才移動發(fā)送窗，左邊緣緊貼剛被確認的數(shù)據(jù)。接收窗也只有接收到數(shù)據(jù)且最左側(cè)連續(xù)時才移動接收窗口。

十七、建立 TCP 服務(wù)器的各個系統(tǒng)調(diào)用過程是怎樣的？

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

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

服務(wù)器：

• fd：accept 返回的連接描述字，每個連接有一個，生命周期為連接周期。

• 注：sockfd 是監(jiān)聽描述字，一個服務(wù)器只有一個，用于監(jiān)聽是否有連接；fd 是連接描述字，用于每個連接的操作。

• fd：連接描述字。

• buf：緩沖區(qū) buf。

• count：緩沖區(qū)長度。

• 注：大于 0 表示讀取的字節(jié)數(shù)，返回 0 表示文件讀取結(jié)束，小于 0 表示發(fā)生錯誤。

• sockfd：服務(wù)器 socket 描述字。

• addr：指向地址結(jié)構(gòu)指針。

• addrlen：協(xié)議地址長度。

• 注：一旦 accept 某個客戶機請求成功將返回一個全新的描述符用于標(biāo)識具體客戶的 TCP 連接。

• sockfd：要監(jiān)聽的 sock 描述字。

• backlog：socket 可以排隊的最大連接數(shù)。

• sockfd：socket 返回的套接字描述符，類似于文件描述符 fd。

• addr：有個 sockaddr 類型數(shù)據(jù)的指針，指向的是被綁定結(jié)構(gòu)變量。

• addrlen：地址長度。

• domain：協(xié)議域，決定了 socket 的地址類型，IPv4 為 AF_INET。

• type：指定 socket 類型，SOCK_STREAM 為 TCP 連接。

• protocol：指定協(xié)議。IPPROTO_TCP 表示 TCP 協(xié)議，為 0 時自動選擇 type 默認協(xié)議。

• 創(chuàng)建 socket -> int socket(int domain, int type, int protocol);

• 綁定 socket 和端口號 -> int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

????//?IPv4的sockaddr地址結(jié)構(gòu)

復(fù)制代碼

• 監(jiān)聽端口號 -> 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);

• 關(guān)閉 socket -> int close(int fd);

客戶機：

• fd：同服務(wù)器端 fd。

• fd、buf、count：同 read 中意義。

• 大于 0 表示寫了部分或全部數(shù)據(jù)，小于 0 表示出錯。

• sockfd 客戶端的 sock 描述字。

• addr：服務(wù)器的地址。

• addrlen：socket 地址長度。

• 創(chuàng)建 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);

• 關(guān)閉 oscket -> int close(int fd);

十八、TCP 協(xié)議如何保證可靠傳輸？

第一種回答

• **確認和重傳：**接收方收到報文就會確認，發(fā)送方發(fā)送一段時間后沒有收到確認就會重傳。

• **數(shù)據(jù)校驗：**TCP 報文頭有校驗和，用于校驗報文是否損壞。

• 數(shù)據(jù)合理分片和排序：tcp 會按最大傳輸單元(MTU)合理分片，接收方會緩存未按序到達的數(shù)據(jù)，重新排序后交給應(yīng)用層。而 UDP：IP 數(shù)據(jù)報大于 1500 字節(jié)，大于 MTU。這個時候發(fā)送方的 IP 層就需要分片，把數(shù)據(jù)報分成若干片，是的每一片都小于 MTU。而接收方 IP 層則需要進行數(shù)據(jù)報的重組。由于 UDP 的特性，某一片數(shù)據(jù)丟失時，接收方便無法重組數(shù)據(jù)報，導(dǎo)致丟棄整個 UDP 數(shù)據(jù)報。

• **流量控制：**當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能通過滑動窗口，提示發(fā)送方降低發(fā)送的速率，防止包丟失。

• **擁塞控制：**當(dāng)網(wǎng)絡(luò)擁塞時，通過擁塞窗口，減少數(shù)據(jù)的發(fā)送，防止包丟失。

第二種回答

• 建立連接（標(biāo)志位）：通信前確認通信實體存在。

• 序號機制（序號、確認號）：確保了數(shù)據(jù)是按序、完整到達。

• 數(shù)據(jù)校驗（校驗和）：CRC 校驗全部數(shù)據(jù)。

• 超時重傳（定時器）：保證因鏈路故障未能到達數(shù)據(jù)能夠被多次重發(fā)。

• 窗口機制（窗口）：提供流量控制，避免過量發(fā)送。

• 擁塞控制：同上。

第三種回答

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

原因

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

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

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

解決方案

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

十九、UDP 是什么

提供無連接的，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃?/strong>）。

二十、TCP 和 UDP 的區(qū)別

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

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

3、TCP 面向字節(jié)流，實際上是 TCP 把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP 是面向報文的

UDP 沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用，如 IP 電話，實時視頻會議等）

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

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

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

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

TCP 是面向字節(jié)流的，它把上面應(yīng)用層交下來的數(shù)據(jù)看成無結(jié)構(gòu)的字節(jié)流會發(fā)送，可以想象成流水形式的，發(fā)送方 TCP 會將數(shù)據(jù)放入“蓄水池”（緩存區(qū)），等到可以發(fā)送的時候就發(fā)送，不能發(fā)送就等著 TCP 會根據(jù)當(dāng)前網(wǎng)絡(luò)的擁塞狀態(tài)來確定每個報文段的大小。

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

• UDP 是無連接的；

• UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復(fù)雜的鏈接狀態(tài)（這里面有許多參數(shù)）；

• UDP 是面向報文的；

• UDP 沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用，如 IP 電話，實時視頻會議等）；

• UDP 支持一對一、一對多、多對一和多對多的交互通信；

• UDP 的首部開銷小，只有 8 個字節(jié)，比 TCP 的 20 個字節(jié)的首部要短。

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

• TCP 是面向連接的。（就好像打電話一樣，通話前需要先撥號建立連接，通話結(jié)束后要掛機釋放連接）；

• 每一條 TCP 連接只能有兩個端點，每一條 TCP 連接只能是點對點的（一對一）；

• TCP 提供可靠交付的服務(wù)。通過 TCP 連接傳送的數(shù)據(jù)，無差錯、不丟失、不重復(fù)、并且按序到達；

• TCP 提供全雙工通信。TCP 允許通信雙方的應(yīng)用進程在任何時候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接收緩存，用來臨時存放雙方通信的數(shù)據(jù)；

• 面向字節(jié)流。TCP 中的“流”（stream）指的是流入進程或從進程流出的字節(jié)序列。“面向字節(jié)流”的含義是：雖然應(yīng)用程序和 TCP 的交互是一次一個數(shù)據(jù)塊（大小不等），但 TCP 把應(yīng)用程序交下來的數(shù)據(jù)僅僅看成是一連串的無結(jié)構(gòu)的字節(jié)流。

二十二、TCP 對應(yīng)的應(yīng)用層協(xié)議

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

二十三、UDP 對應(yīng)的應(yīng)用層協(xié)議

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

二十四、數(shù)據(jù)鏈路層常見協(xié)議？可以說一下嗎？

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

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

ping 命令基于網(wǎng)絡(luò)層的命令，是基于 ICMP 協(xié)議工作的。

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

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

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

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

所以,事實上,這個 1500 字節(jié)就是網(wǎng)絡(luò)層 IP 數(shù)據(jù)報的長度限制。因為 IP 數(shù)據(jù)報的首部為 20 字節(jié),所以 IP 數(shù)據(jù)報的數(shù)據(jù)區(qū)長度最大為 1480 字節(jié).而這個 1480 字節(jié)就是用來放 TCP 傳來的 TCP 報文段或 UDP 傳來的 UDP 數(shù)據(jù)報的.又因為 UDP 數(shù)據(jù)報的首部 8 字節(jié),所以 UDP 數(shù)據(jù)報的數(shù)據(jù)區(qū)最大長度為 1472 字節(jié).這個 1472 字節(jié)就是我們可以使用的字節(jié)數(shù)。

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

因此,在普通的局域網(wǎng)環(huán)境下，我建議將 UDP 的數(shù)據(jù)控制在 1472 字節(jié)以下為好.

進行 Internet 編程時則不同,因為 Internet 上的路由器可能會將 MTU 設(shè)為不同的值. 如果我們假定 MTU 為 1500 來發(fā)送數(shù)據(jù)的,而途經(jīng)的某個網(wǎng)絡(luò)的 MTU 值小于 1500 字節(jié),那么系統(tǒng)將會使用一系列的機 制來調(diào)整 MTU 值,使數(shù)據(jù)報能夠順利到達目的地,這樣就會做許多不必要的操作.

鑒于 Internet 上的標(biāo)準 MTU 值為 576 字節(jié),所以我建議在進行 Internet 的 UDP 編程時. 最好將 UDP 的數(shù)據(jù)長度控件在 548 字節(jié)(576-8-20)以內(nèi)

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

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

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

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

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

• 超時重傳：發(fā)送端發(fā)送報文后若長時間未收到確認的報文則需要重發(fā)該報文。可能有以下幾種情況：發(fā)送的數(shù)據(jù)沒能到達接收端，所以對方?jīng)]有響應(yīng)。接收端接收到數(shù)據(jù)，但是 ACK 報文在返回過程中丟失。接收端拒絕或丟棄數(shù)據(jù)。

• RTO：從上一次發(fā)送數(shù)據(jù)，因為長期沒有收到 ACK 響應(yīng)，到下一次重發(fā)之間的時間。就是重傳間隔。通常每次重傳 RTO 是前一次重傳間隔的兩倍，計量單位通常是 RTT。例：1RTT，2RTT，4RTT，8RTT…重傳次數(shù)到達上限之后停止重傳。

• RTT：數(shù)據(jù)從發(fā)送到接收到對方響應(yīng)之間的時間間隔，即數(shù)據(jù)報在網(wǎng)絡(luò)中一個往返用時。大小不穩(wěn)定。

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

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

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

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

如何防范 CSRF 攻擊？

安全框架，例如 Spring Security。

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

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

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

1）驗證請求來源地址；

2）關(guān)鍵操作添加驗證碼；

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

三十一、文件上傳漏洞是如何發(fā)生的？你有經(jīng)歷過嗎？

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

如何防范文件上傳漏洞？

文件上傳的目錄設(shè)置為不可執(zhí)行。

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

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

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

5）單獨設(shè)置文件服務(wù)器的域名。

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

• 擁塞控制目的是防止數(shù)據(jù)被過多注網(wǎng)絡(luò)中導(dǎo)致網(wǎng)絡(luò)資源（路由器、交換機等）過載。因為擁塞控制涉及網(wǎng)絡(luò)鏈路全局，所以屬于全局控制。控制擁塞使用擁塞窗口。

• TCP 擁塞控制算法：慢開始 & 擁塞避免：先試探網(wǎng)絡(luò)擁塞程度再逐漸增大擁塞窗口。每次收到確認后擁塞窗口翻倍，直到達到閥值 ssthresh，這部分是慢開始過程。達到閥值后每次以一個 MSS 為單位增長擁塞窗口大小，當(dāng)發(fā)生擁塞（超時未收到確認），將閥值減為原先一半，繼續(xù)執(zhí)行線性增加，這個過程為擁塞避免。快速重傳 & 快速恢復(fù)：略。最終擁塞窗口會收斂于穩(wěn)定值。

三十三、如何區(qū)分流量控制和擁塞控制？

• 流量控制屬于通信雙方協(xié)商；擁塞控制涉及通信鏈路全局。

• 流量控制需要通信雙方各維護一個發(fā)送窗、一個接收窗，對任意一方，接收窗大小由自身決定，發(fā)送窗大小由接收方響應(yīng)的 TCP 報文段中窗口值確定；擁塞控制的擁塞窗口大小變化由試探性發(fā)送一定數(shù)據(jù)量數(shù)據(jù)探查網(wǎng)絡(luò)狀況后而自適應(yīng)調(diào)整。

• 實際最終發(fā)送窗口 = min{流控發(fā)送窗口，擁塞窗口}。

三十四、常見的 HTTP 狀態(tài)碼有哪些？

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

1xx 信息

100 Continue ：表明到目前為止都很正常，客戶端可以繼續(xù)發(fā)送請求或者忽略這個響應(yīng)。

2xx 成功

• 200 OK

• 204 No Content ：請求已經(jīng)成功處理，但是返回的響應(yīng)報文不包含實體的主體部分。一般在只需要從客戶端往服務(wù)器發(fā)送信息，而不需要返回數(shù)據(jù)時使用。

• 206 Partial Content ：表示客戶端進行了范圍請求，響應(yīng)報文包含由 Content-Range 指定范圍的實體內(nèi)容。

3xx 重定向

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時性重定向

• 303 See Other ：和 302 有著相同的功能，但是 303 明確要求客戶端應(yīng)該采用 GET 方法獲取資源。

• 304 Not Modified ：如果請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不滿足條件，則服務(wù)器會返回 304 狀態(tài)碼。

• 307 Temporary Redirect ：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法。

4xx 客戶端錯誤

• 400 Bad Request ：請求報文中存在語法錯誤。

• 401 Unauthorized ：該狀態(tài)碼表示發(fā)送的請求需要有認證信息（BASIC 認證、DIGEST 認證）。如果之前已進行過一次請求，則表示用戶認證失敗。

• 403 Forbidden ：請求被拒絕。

• 404 Not Found

5xx 服務(wù)器錯誤

• 500 Internal Server Error ：服務(wù)器正在執(zhí)行請求時發(fā)生錯誤。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。