大家好，我是阿秀。

本期是計(jì)網(wǎng)系列的最后一期啦，下一期開(kāi)坑數(shù)據(jù)結(jié)構(gòu)與算法的八股文

。

是不是很多人以為上期沒(méi)有答案啊哈哈，是有的哈，上期是有答案的，沒(méi)看過(guò)的可以去溫習(xí)溫習(xí)。

《逆襲進(jìn)大廠》第八彈之計(jì)算機(jī)網(wǎng)絡(luò)（中）33問(wèn)33答｜下期再更新PDF版本

本期是計(jì)網(wǎng)系列的最后一期了，整個(gè)計(jì)網(wǎng)系列一共是 100 問(wèn) 100 答，已經(jīng)全部更新完畢！

另外由于不少小伙伴希望我能開(kāi)放 逆襲進(jìn)大廠PDF 的編輯權(quán)限，我簡(jiǎn)單思考了了一下，安排上！

別問(wèn)，問(wèn)就是答應(yīng)！問(wèn)就是安排！

下次 PDF 更新大家就可以任意編輯了！相關(guān) PDF 正在整理中，但阿秀近期瑣事較多，PDF更新得可能會(huì)比較慢，這兩期八股文暫時(shí)辛苦大家在線看吧

抱歉抱歉！

另外本期內(nèi)容已同步至 github 倉(cāng)庫(kù)，歡迎大家 star。點(diǎn)擊文末左側(cè)的閱讀原文即可直達(dá)倉(cāng)庫(kù)地址，倉(cāng)庫(kù)地址：https：／／github．com／forthespada／InterviewGuide

老規(guī)矩，來(lái)看看你會(huì)幾道吧。

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

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

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

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

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

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

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

優(yōu)點(diǎn)：運(yùn)算速度快缺點(diǎn)：無(wú)法安全地將密鑰傳輸給通信方

70、非對(duì)稱(chēng)密鑰加密你了解嗎？?jī)?yōu)缺點(diǎn)？

非對(duì)稱(chēng)密鑰加密，又稱(chēng)公開(kāi)密鑰加密（Public－Key Encryption），加密和解密使用不同的密鑰。

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

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

優(yōu)點(diǎn)：可以更安全地將公開(kāi)密鑰傳輸給通信發(fā)送方；缺點(diǎn)：運(yùn)算速度慢。

71、HTTPS是什么？

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

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

使用明文進(jìn)行通信，內(nèi)容可能會(huì)被竊聽(tīng)；不驗(yàn)證通信方的身份，通信方的身份有可能遭遇偽裝；無(wú)法證明報(bào)文的完整性，報(bào)文有可能遭篡改。

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

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

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

Client給出協(xié)議版本號(hào)、一個(gè)客戶(hù)端生成的隨機(jī)數(shù)（Client random），以及客戶(hù)端支持的加密方法。Server確認(rèn)雙方使用的加密方法，并給出數(shù)字證書(shū)、以及一個(gè)服務(wù)器生成的隨機(jī)數(shù)（Server random）。Client確認(rèn)數(shù)字證書(shū)有效，然后生成呀一個(gè)新的隨機(jī)數(shù)（Premaster secret），并使用數(shù)字證書(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ò)程。

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

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

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

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

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

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

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

76、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

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

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

Cache－Control： no－cache、

77、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ī)范也沒(méi)有對(duì)URL長(zhǎng)度進(jìn)行限制。

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

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

因?yàn)槲覀円话鉷ost的數(shù)據(jù)量很少超過(guò)MB的，所以我們很少能感覺(jué)的到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)題了。

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

協(xié)議名稱(chēng)作用IP網(wǎng)際協(xié)議IP協(xié)議不但定義了數(shù)據(jù)傳輸時(shí)的基本單元和格式，還定義了數(shù)據(jù)報(bào)的遞交方法和路由選擇ICMP超文本傳輸安全協(xié)議ICMP就是一個(gè)“錯(cuò)誤偵測(cè)與回報(bào)機(jī)制”，其目的就是讓我們能夠檢測(cè)網(wǎng)路的連線狀況﹐也能確保連線的準(zhǔn)確性，是ping和traceroute的工作協(xié)議RIP路由信息協(xié)議使用“跳數(shù)”（即metric）來(lái)衡量到達(dá)目標(biāo)地址的路由距離IGMPInternet組管理協(xié)議用于實(shí)現(xiàn)組播、廣播等通信。