大家好，我是阿秀。

直接進(jìn)入今天正文，不多逼逼。

上期已經(jīng)更新了 33 問 33 答，那今天再來更新 33 問 33 答好了哈哈，這是整個(gè)系列的第八期了，也是計(jì)網(wǎng)系列的第二期，計(jì)網(wǎng)還有一期就更新完了。

“

本期內(nèi)容已同步至 github 倉庫，歡迎大家 star。

點(diǎn)擊文末左側(cè)的閱讀原文即可直達(dá)倉庫地址，倉庫地址：https：／／github．com／forthespada／InterviewGuide

PDF 暫時(shí)還沒更新過來，等下期第九期，也就是計(jì)算機(jī)網(wǎng)絡(luò)最后一期，再出 PDF 好了。

下面是本期 33 問 33 答。

34、DNS查詢方式有哪些？遞歸解析

當(dāng)局部DNS服務(wù)器自己不能回答客戶機(jī)的DNS查詢時(shí)，它就需要向其他DNS服務(wù)器進(jìn)行查詢。此時(shí)有兩種方式。局部DNS服務(wù)器自己負(fù)責(zé)向其他DNS服務(wù)器進(jìn)行查詢，一般是先向該域名的根域服務(wù)器查詢，再由根域名服務(wù)器一級(jí)級(jí)向下查詢。最后得到的查詢結(jié)果返回給局部DNS服務(wù)器，再由局部DNS服務(wù)器返回給客戶端。

迭代解析

當(dāng)局部DNS服務(wù)器自己不能回答客戶機(jī)的DNS查詢時(shí)，也可以通過迭代查詢的方式進(jìn)行解析。局部DNS服務(wù)器不是自己向其他DNS服務(wù)器進(jìn)行查詢，而是把能解析該域名的其他DNS服務(wù)器的IP地址返回給客戶端DNS程序，客戶端DNS程序再繼續(xù)向這些DNS服務(wù)器進(jìn)行查詢，直到得到查詢結(jié)果為止。

也就是說，迭代解析只是幫你找到相關(guān)的服務(wù)器而已，而不會(huì)幫你去查。比如說：baidu．com的服務(wù)器ip地址在192．168．4．5這里，你自己去查吧，本人比較忙，只能幫你到這里了。

35、HTTP中緩存的私有和共有字段？知道嗎？

private 指令規(guī)定了將資源作為私有緩存，只能被單獨(dú)用戶使用，一般存儲(chǔ)在用戶瀏覽器中。

Cache－Control： private

public 指令規(guī)定了將資源作為公共緩存，可以被多個(gè)用戶使用，一般存儲(chǔ)在代理服務(wù)器中。

Cache－Control： public

36、GET 方法參數(shù)寫法是固定的嗎？

在約定中，我們的參數(shù)是寫在 ？ 后面，用 ＆ 分割。

我們知道，解析報(bào)文的過程是通過獲取 TCP 數(shù)據(jù)，用正則等工具從數(shù)據(jù)中獲取 Header 和 Body，從而提取參數(shù)。

比如header請(qǐng)求頭中添加token，來驗(yàn)證用戶是否登錄等權(quán)限問題。

也就是說，我們可以自己約定參數(shù)的寫法，只要服務(wù)端能夠解釋出來就行，萬變不離其宗。

37、GET 方法的長度限制是怎么回事？

網(wǎng)絡(luò)上都會(huì)提到瀏覽器地址欄輸入的參數(shù)是有限的。

首先說明一點(diǎn)，HTTP 協(xié)議沒有 Body 和 URL 的長度限制，對(duì) URL 限制的大多是瀏覽器和服務(wù)器的原因。

瀏覽器原因就不說了，服務(wù)器是因?yàn)樘幚黹L URL 要消耗比較多的資源，為了性能和安全（防止惡意構(gòu)造長 URL 來攻擊）考慮，會(huì)給 URL 長度加限制。

38、POST 方法比 GET 方法安全？

有人說POST 比 GET 安全，因?yàn)閿?shù)據(jù)在地址欄上不可見。

然而，從傳輸?shù)慕嵌葋碚f，他們都是不安全的，因?yàn)?HTTP 在網(wǎng)絡(luò)上是明文傳輸?shù)模�只要在網(wǎng)絡(luò)節(jié)點(diǎn)上捉包，就能完整地獲取數(shù)據(jù)報(bào)文。

要想安全傳輸，就只有加密，也就是 HTTPS。

39、POST 方法會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包？你了解嗎？

有些文章中提到，POST 會(huì)將 header 和 body 分開發(fā)送，先發(fā)送 header，服務(wù)端返回 100 狀態(tài)碼再發(fā)送 body。

HTTP 協(xié)議中沒有明確說明 POST 會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包，而且實(shí)際測試（Chrome）發(fā)現(xiàn)，header 和 body 不會(huì)分開發(fā)送。

所以，header 和 body 分開發(fā)送是部分瀏覽器或框架的請(qǐng)求方法，不屬于 post 必然行為。

40、Session是什么？

除了可以將用戶信息通過 Cookie 存儲(chǔ)在用戶瀏覽器中，也可以利用 Session 存儲(chǔ)在服務(wù)器端，存儲(chǔ)在服務(wù)器端的信息更加安全。

Session 可以存儲(chǔ)在服務(wù)器上的文件、數(shù)據(jù)庫或者內(nèi)存中。也可以將 Session 存儲(chǔ)在 Redis 這種內(nèi)存型數(shù)據(jù)庫中，效率會(huì)更高。

41、使用 Session 的過程是怎樣的？

過程如下：

用戶進(jìn)行登錄時(shí)，用戶提交包含用戶名和密碼的表單，放入 HTTP 請(qǐng)求報(bào)文中；服務(wù)器驗(yàn)證該用戶名和密碼，如果正確則把用戶信息存儲(chǔ)到 Redis 中，它在 Redis 中的 Key 稱為 Session ID；服務(wù)器返回的響應(yīng)報(bào)文的 Set－Cookie 首部字段包含了這個(gè) Session ID，客戶端收到響應(yīng)報(bào)文之后將該 Cookie 值存入瀏覽器中；客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求時(shí)會(huì)包含該 Cookie 值，服務(wù)器收到之后提取出 Session ID，從 Redis 中取出用戶信息，繼續(xù)之前的業(yè)務(wù)操作。

注意：Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取，那么就不能產(chǎn)生一個(gè)容易被猜到的 Session ID 值。此外，還需要經(jīng)常重新生成 Session ID。在對(duì)安全性要求極高的場景下，例如轉(zhuǎn)賬等操作，除了使用 Session 管理用戶狀態(tài)之外，還需要對(duì)用戶進(jìn)行重新驗(yàn)證，比如重新輸入密碼，或者使用短信驗(yàn)證碼等方式。

42、Session和cookie應(yīng)該如何去選擇（適用場景）？

Cookie 只能存儲(chǔ) ASCII 碼字符串，而 Session 則可以存儲(chǔ)任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復(fù)雜性時(shí)首選 Session；Cookie 存儲(chǔ)在瀏覽器中，容易被惡意查看。如果非要將一些隱私數(shù)據(jù)存在 Cookie 中，可以將 Cookie 值進(jìn)行加密，然后在服務(wù)器進(jìn)行解密；對(duì)于大型網(wǎng)站，如果用戶所有的信息都存儲(chǔ)在 Session 中，那么開銷是非常大的，因此不建議將所有的用戶信息都存儲(chǔ)到 Session 中。

43、Cookies和Session區(qū)別是什么？

Cookie和Session都是客戶端與服務(wù)器之間保持狀態(tài)的解決方案

1，存儲(chǔ)的位置不同，cookie：存放在客戶端，session：存放在服務(wù)端。Session存儲(chǔ)的數(shù)據(jù)比較安全

2，存儲(chǔ)的數(shù)據(jù)類型不同兩者都是key－value的結(jié)構(gòu)，但針對(duì)value的類型是有差異的cookie：value只能是字符串類型，session：value是Object類型

3，存儲(chǔ)的數(shù)據(jù)大小限制不同cookie：大小受瀏覽器的限制，很多是是4K的大小， session：理論上受當(dāng)前內(nèi)存的限制

4，生命周期的控制cookie的生命周期當(dāng)瀏覽器關(guān)閉的時(shí)候，就消亡了

（1）cookie的生命周期是累計(jì)的，從創(chuàng)建時(shí)，就開始計(jì)時(shí)，20分鐘后，cookie生命周期結(jié)束，

（2）session的生命周期是間隔的，從創(chuàng)建時(shí)，開始計(jì)時(shí)如在20分鐘，沒有訪問session，那么session生命周期被銷毀。