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

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

• 會(huì)話層：建立會(huì)話，如 session 認(rèn)證、斷點(diǎn)續(xù)傳。

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

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

三、對(duì)稱密鑰加密的優(yōu)點(diǎn)缺點(diǎn)？

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

• 優(yōu)點(diǎn)：運(yùn)算速度快

• 缺點(diǎn)：無(wú)法安全地將密鑰傳輸給通信方

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

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

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

非對(duì)稱密鑰除了用來(lái)加密，還可以用來(lái)進(jìn)行簽名。因?yàn)樗接忻荑€無(wú)法被其他人獲取，因此通信發(fā)送方使用其私有密鑰進(jìn)行簽名，通信接收方使用發(fā)送方的公開密鑰對(duì)簽名進(jìn)行解密，就能判斷這個(gè)簽名是否正確。

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

• 缺點(diǎn)：運(yùn)算速度慢。

五、HTTPS 是什么

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

六、HTTP 的缺點(diǎn)有哪些？

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

• 不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝；

• 無(wú)法證明報(bào)文的完整性，報(bào)文有可能遭篡改。

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

HTTPS 采用混合的加密機(jī)制，使用非對(duì)稱密鑰加密用于傳輸對(duì)稱密鑰來(lái)保證傳輸過(guò)程的安全性，之后使用對(duì)稱密鑰加密進(jìn)行通信來(lái)保證通信過(guò)程的效率。

確保傳輸安全過(guò)程（其實(shí)就是 rsa 原理）：

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

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

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

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

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

八、為什么有的時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接？

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

九、SSL 中的認(rèn)證中的證書是什么？了解過(guò)嗎？

通過(guò)使用?證書?來(lái)對(duì)通信方進(jìn)行認(rèn)證。

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

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

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

十、HTTP 如何禁用緩存？如何確認(rèn)緩存？

HTTP/1.1 通過(guò) Cache-Control 首部字段來(lái)控制緩存。

禁止進(jìn)行緩存

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

Cache-Control:?no-store

復(fù)制代碼

強(qiáng)制確認(rèn)緩存

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

Cache-Control:?no-cache

復(fù)制代碼

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

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

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

這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制，比如 IE 對(duì) URL 長(zhǎng)度的限制是 2083 字節(jié)(2K+35 字節(jié))。對(duì)于其他瀏覽器，如 FireFox，Netscape 等，則沒有長(zhǎng)度限制，這個(gè)時(shí)候其限制取決于服務(wù)器的操作系統(tǒng)；即如果 url 太長(zhǎng)，服務(wù)器可能會(huì)因?yàn)榘踩矫娴脑O(shè)置從而拒絕請(qǐng)求或者發(fā)生不完整的數(shù)據(jù)請(qǐng)求。

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

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

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

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

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

四大算法

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

慢熱啟動(dòng)算法 – Slow Start

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

慢啟動(dòng)算法：

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

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

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

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

擁塞避免算法 – Congestion Avoidance

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

收到一個(gè) ACK，則 cwnd = cwnd + 1 / cwnd

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

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

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

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

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

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

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

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

• cwnd 重置為 1

• 進(jìn)入慢啟動(dòng)過(guò)程

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

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

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

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

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(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 算法有。在進(jìn)入快速恢復(fù)之前，cwnd 和 ssthresh 已經(jīng)被更改為原有 cwnd 的一半。快速恢復(fù)算法的邏輯如下：

• cwnd = cwnd + 3 MSS，加 3 MSS 的原因是因?yàn)槭盏?3 個(gè)重復(fù)的 ACK。

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

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

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

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

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

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

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

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

1）包 checksum 出錯(cuò)

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

3）網(wǎng)絡(luò)斷，包括路由重收斂，但是發(fā)送方無(wú)法判斷是哪一種情況，于是采用最笨的辦法，就是將自己的發(fā)送速率減半，即 CWND 減為 1/2，這樣的方法對(duì) 2 是有效的，可以緩解網(wǎng)絡(luò)擁塞，3 則無(wú)所謂，反正網(wǎng)絡(luò)斷了，無(wú)論發(fā)快發(fā)慢都會(huì)被丟；但對(duì)于 1 來(lái)說(shuō)，丟包是因?yàn)榕紶柕某鲥e(cuò)引起，一丟包就對(duì)半減速不合理。

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

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

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

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

FIN_WAIT_2：

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

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

CLOSE_WAIT 狀態(tài)：

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

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

TIME_WAIT 狀態(tài)：

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

• 如果客戶端直接進(jìn)入 CLOSED 狀態(tài)，如果服務(wù)端沒有接收到最后一次 ACK 包會(huì)在超時(shí)之后重新再發(fā) FIN 包，此時(shí)因?yàn)榭蛻舳艘呀?jīng) CLOSED，所以服務(wù)端就不會(huì)收到 ACK 而是收到 RST。所以 TIME_WAIT 狀態(tài)目的是防止最后一次握手?jǐn)?shù)據(jù)沒有到達(dá)對(duì)方而觸發(fā)重傳 FIN 準(zhǔn)備的。

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

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

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

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

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

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

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

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

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

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

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

服務(wù)器：

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

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

• fd：連接描述字。

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

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

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

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

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

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

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

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

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

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

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

• addrlen：地址長(zhǎng)度。

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

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

• protocol：指定協(xié)議。IPPROTO_TCP 表示 TCP 協(xié)議，為 0 時(shí)自動(dòng)選擇 type 默認(rèn)協(xié)議。

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

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

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

復(fù)制代碼

• 監(jiān)聽端口號(hào) -> int listen(int sockfd, int backlog);

• 接收用戶請(qǐng)求 -> 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);

客戶機(jī)：

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

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

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

• sockfd 客戶端的 sock 描述字。

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

• addrlen：socket 地址長(zhǎng)度。

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

• 連接指定計(jì)算機(jī) -> 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é)議如何保證可靠傳輸？

第一種回答

• **確認(rèn)和重傳：**接收方收到報(bào)文就會(huì)確認(rèn)，發(fā)送方發(fā)送一段時(shí)間后沒有收到確認(rèn)就會(huì)重傳。

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

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

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

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

第二種回答

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

• 序號(hào)機(jī)制（序號(hào)、確認(rèn)號(hào)）：確保了數(shù)據(jù)是按序、完整到達(dá)。

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

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

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

• 擁塞控制：同上。

第三種回答

首部校驗(yàn)這個(gè)校驗(yàn)機(jī)制能夠確保數(shù)據(jù)傳輸不會(huì)出錯(cuò)嗎？答案是不能。

原因

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

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

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

解決方案

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

十九、UDP 是什么

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

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

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

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

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

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

4、每一條 TCP 連接只能是點(diǎn)到點(diǎn)的;UDP 支持一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多的交互通信

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

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

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

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

二十一、UDP 的特點(diǎn)有哪些（附贈(zèng) TCP 的特點(diǎn)）？

• UDP 是無(wú)連接的；

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

• UDP 是面向報(bào)文的；

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

• UDP 支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信；

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

那么，再說(shuō)一次 TCP 的特點(diǎn)：

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

• 每一條 TCP 連接只能有兩個(gè)端點(diǎn)，每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）；

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

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

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

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

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

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

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

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(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é)議工作的。

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

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

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

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

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

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

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

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

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

二十七、TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制的機(jī)制？

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

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

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

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

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

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

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

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

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

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

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

如何防范 CSRF 攻擊？

安全框架，例如 Spring Security。

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

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

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

1）驗(yàn)證請(qǐng)求來(lái)源地址；

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

3）在請(qǐng)求地址添加 token 并驗(yàn)證。

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

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

如何防范文件上傳漏洞？

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

1）判斷文件類型。在判斷文件類型的時(shí)候，可以結(jié)合使用 MIME Type，后綴檢查等方式。因?yàn)閷?duì)于上傳文件，不能簡(jiǎn)單地通過(guò)后綴名稱來(lái)判斷文件的類型，因?yàn)楣粽呖梢詫⒖蓤?zhí)行文件的后綴名稱改為圖片或其他后綴類型，誘導(dǎo)用戶執(zhí)行。2）對(duì)上傳的文件類型進(jìn)行白名單校驗(yàn)，只允許上傳可靠類型。

3）上傳的文件需要進(jìn)行重新命名，使攻擊者無(wú)法猜想上傳文件的訪問(wèn)路徑，將極大地增加攻擊成本，同時(shí)向 shell.php.rar.ara 這種文件，因?yàn)橹孛鵁o(wú)法成功實(shí)施攻擊。

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

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

三十二、擁塞控制原理聽說(shuō)過(guò)嗎？

• 擁塞控制目的是防止數(shù)據(jù)被過(guò)多注網(wǎng)絡(luò)中導(dǎo)致網(wǎng)絡(luò)資源（路由器、交換機(jī)等）過(guò)載。因?yàn)閾砣刂粕婕熬W(wǎng)絡(luò)鏈路全局，所以屬于全局控制。控制擁塞使用擁塞窗口。

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

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

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

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

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

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

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(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ā)送請(qǐng)求或者忽略這個(gè)響應(yīng)。

2xx 成功

• 200 OK

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

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

3xx 重定向

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時(shí)性重定向

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

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

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

4xx 客戶端錯(cuò)誤

• 400 Bad Request ：請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤。

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

• 403 Forbidden ：請(qǐng)求被拒絕。

• 404 Not Found

5xx 服務(wù)器錯(cuò)誤

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

• 503 Service Unavailable ：服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無(wú)法處理請(qǐng)求。
  【這里想說(shuō)，因?yàn)樽约阂沧吡撕芏鄰澛愤^(guò)來(lái)的，所以才下定決心整理，收集過(guò)程雖不易，但想到能幫助到一部分自學(xué)或者是想提升java技術(shù)、成為Java架構(gòu)師，提升技術(shù)P5-P6-P7-P8 的人，心里也是甜的！有需要的伙伴請(qǐng)點(diǎn)?方】↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

總結(jié)

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

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