大家好，我是阿秀。

直接進入今天正文，不多逼逼。

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

“

本期內容已同步至 github 倉庫，歡迎大家 star。

點擊文末左側的閱讀原文即可直達倉庫地址，倉庫地址：https：／／github．com／forthespada／InterviewGuide

PDF 暫時還沒更新過來，等下期第九期，也就是計算機網絡最后一期，再出 PDF 好了。

下面是本期 33 問 33 答。

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

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

迭代解析

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

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

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

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

Cache－Control： private

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

Cache－Control： public

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

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

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

比如header請求頭中添加token，來驗證用戶是否登錄等權限問題。

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

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

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

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

瀏覽器原因就不說了，服務器是因為處理長 URL 要消耗比較多的資源，為了性能和安全（防止惡意構造長 URL 來攻擊）考慮，會給 URL 長度加限制。

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

有人說POST 比 GET 安全，因為數(shù)據在地址欄上不可見。

然而，從傳輸?shù)慕嵌葋碚f，他們都是不安全的，因為 HTTP 在網絡上是明文傳輸?shù)�，只要在網絡節(jié)點上捉包，就能完整地獲取數(shù)據報文。

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

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

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

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

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

40、Session是什么？

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

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

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

過程如下：

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

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

42、Session和cookie應該如何去選擇（適用場景）？

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

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

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

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

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

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

4，生命周期的控制cookie的生命周期當瀏覽器關閉的時候，就消亡了

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

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