大家好，我是阿秀。

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

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

“

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

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

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

下面是本期 33 問 33 答。

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

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

迭代解析

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

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

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

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

Cache－Control： private

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

Cache－Control： public

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

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

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

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

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

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

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

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

瀏覽器原因就不說了，服務(wù)器是因?yàn)樘幚黹L URL 要消耗比較多的資源，為了性能和安全（防止惡意構(gòu)造長 URL 來攻擊）考慮，會給 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ù)報文。

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

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

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

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

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

40、Session是什么？

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

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

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

過程如下：

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

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

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

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

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

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

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

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

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

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

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

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