計網核心面試彙總

HTTP狀態碼

• 1xx 消息
  這一類型的狀態碼，代表請求已被接受，需要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。由於HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，所以除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。
• 2xx 成功 這一類型的狀態碼，代表請求已成功被服務器接收、理解、並接受。
  • 200 　　請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
  • 202 　　服務器已接受請求，但尚未處理。正如它可能被拒絕一樣，最終該請求可能會也可能不會被執行。在異步操作的場合下，沒有比發送這個狀態碼更方便的做法了。
  • 205 　　服務器成功處理了請求，且沒有返回任何內容。但是與204響應不同，返 回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受 用戶輸入後，立即重置表單，以便用戶能夠輕鬆地開始另一次輸入。
    　　與204響應一樣，該響應也被禁止包含任何消息體，且以消息頭後的第 一個空行結束。
• 3xx 重定向
  這類狀態碼代表需要客戶端採取進一步的操作才能完成請求。通常，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的 Location 域中指明。
  　　當且僅當後續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器纔可以在沒有用戶介入的情況下自動提交所需要 的後續請求。客戶端應當自動監測無限循環重定向（例如：A->A，或者A->B->C->A），因爲這會導致服務器和客戶端大 量不必要的資源消耗。按照 HTTP/1.0 版規範的建議，瀏覽器不應自動訪問超過5次的重定向。
  • 301
    　　被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改爲從服務器反饋回來的地址。除非額外指定，否則這個響應也是可緩存的。 　　新的永久性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。 　　如果這不是一個 GET 或者 HEAD 請求，因此瀏覽器禁止自動進行重定向，除非得到用戶的確認，因爲請求的條件可能 因此發生變化。
• 302
  　　請求的資源現在臨時從不同的 URI 響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請 求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應纔是可緩存的。 　　新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明。 　　如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因爲請求的條件可能因此發生變化。
• 4xx 請求錯誤
  這類的狀態碼代表了客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個 HEAD 請求，否則服務器就應該返回一個解釋當前錯誤狀況的實體，以及這是臨時的還是永久性的狀況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。
  • 400
    　　1、語義有誤，當前請求無法被服務器理解。除非進行修改，否則客戶端不應該重複提交這個請求。
    　　2、請求參數有誤。
  • 403
    　　服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是一個 HEAD 請求，而且服務器希望能夠講清楚爲何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然服務器也可以返回一個404響應，假如它不希望讓客戶端獲得任何信息。
  • 404
    　　請求失敗，請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因爲某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底爲何請求被拒絕或者沒有其他適合的響應可用的情況下。
• 5xx 服務器錯誤
  這類狀態碼代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也 有可能是服務器意識到以當前的軟硬件資源無法
  完成對請求的處理。除非這是一個HEAD 請求，否則服務器應當包含一個解釋 當前錯誤狀態以及這個狀況是臨時的還是永
  久的解釋信息實體。瀏覽器應當向用戶展示任何在當前響應中被包含的實體。
  　　這些狀態碼適用於任何響應方法。
  • 500
    　　服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。一般來說，這個問題都會在服務器的程序碼出錯時出現。
  • 501
    　　服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。
  • 502
    　　作爲網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
  • 503
    　　由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是臨時的，並且將在一段時間以後恢復。如果能夠預計延遲時間，那麼響應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 信息 ，那麼客戶端應當以處理500響應的方式處理它。
  • 505
    　　服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不願使用與客戶端相同的版本。響應中應當包含一個描述了爲何版本不被支持以及服務器支持哪些協議的實體。

一般面試官會通過這樣的問題來考察你對計算機網絡知識體系的理解。

DNS解析過程

• 1、在瀏覽器中輸入www . qq .com 域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關係，如果有，就先調用這個IP地址映射，完成域名解析。

• 2、如果hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，如果有，直接返回，完成域名解析。

• 3、如果hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/ip參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。

• 4、如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具有權威性。

• 5、如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(http://qq.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找http://qq.com域服務器，重複上面的動作，進行查詢，直至找到www . qq .com主機。

• 6、如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。

從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。

解析順序

　　1） 瀏覽器緩存

　　當用戶通過瀏覽器訪問某域名時，瀏覽器首先會在自己的緩存中查找是否有該域名對應的IP地址（若曾經訪問過該域名且沒有清空緩存便存在）；

　　2） 系統緩存

　　當瀏覽器緩存中無域名對應IP則會自動檢查用戶計算機系統Hosts文件DNS緩存是否有該域名對應IP；

　　3） 路由器緩存

　　當瀏覽器及系統緩存中均無域名對應IP則進入路由器緩存中檢查，以上三步均爲客服端的DNS緩存；

　　4） ISP（互聯網服務提供商）DNS緩存

　　當在用戶客服端查找不到域名對應IP地址，則將進入ISP DNS緩存中進行查詢。比如你用的是電信的網絡，則會進入電信的DNS緩存服務器中進行查找；

　　5） 根域名服務器

　　當以上均未完成，則進入根服務器進行查詢。全球僅有13臺根域名服務器，1個主根域名服務器，其餘12爲輔根域名服務器。根域名收到請求後會查看區域文件記錄，若無則將其管轄範圍內頂級域名（如.com）服務器IP告訴本地DNS服務器；

　　6） 頂級域名服務器

　　頂級域名服務器收到請求後查看區域文件記錄，若無則將其管轄範圍內主域名服務器的IP地址告訴本地DNS服務器；

　　7） 主域名服務器

　　主域名服務器接受到請求後查詢自己的緩存，如果沒有則進入下一級域名服務器進行查找，並重復該步驟直至找到正確紀錄；

　　8）保存結果至緩存

　　本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時將該結果反饋給客戶端，客戶端通過這個IP地址與web服務器建立鏈接。

遞歸查詢與迭代查詢

一、主機向本地域名服務器的查詢一般都是採用遞歸查詢。

    所謂遞歸查詢就是：如果主機所詢問的本地域名服務器不知道被查詢的域名的IP地址，那麼本地域名服務器就以DNS客戶的身份，

    向其它根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。

    因此，遞歸查詢返回的查詢結果或者是所要查詢的IP地址，或者是報錯，表示無法查詢到所需的IP地址。

二、本地域名服務器向根域名服務器的查詢的迭代查詢。

   迭代查詢的特點：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要麼給出所要查詢的IP地址，要麼告訴本地服務器：“你下一步應當向哪一個域名服務器進行查詢”。

    然後讓本地服務器進行後續的查詢。根域名服務器通常是把自己知道的頂級域名服務器的IP地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。

    頂級域名服務器在收到本地域名服務器的查詢請求後，要麼給出所要查詢的IP地址，要麼告訴本地服務器下一步應當向哪一個權限域名服務器進行查詢。

    最後，知道了所要解析的IP地址或報錯，然後把這個結果返回給發起查詢的主機   ![迭代查詢和遞歸查詢](https://images2017.cnblogs.com/blog/858807/201708/858807-20170820124317600-1783749391.png)  

遞歸：客戶端只發一次請求，要求對方給出最終結果。

迭代：客戶端發出一次請求，對方如果沒有授權回答，它就會返回一個能解答這個查詢的其它名稱服務器列表，

      客戶端會再向返回的列表中發出請求，直到找到最終負責所查域名的名稱服務器，從它得到最終結果。

授權回答：向dns服務器查詢一個域名，剛好這個域名是本服務器負責，返 回的結果就是授權回答。
從遞歸和迭代查詢可以看出：
客戶端-本地dns服務端：這部分屬於遞歸查詢。
本地dns服務端—外網：這部分屬於迭代查詢。
遞歸查詢時，返回的結果只有兩種:查詢成功或查詢失敗.
迭代查詢，又稱作重指引,返回的是最佳的查詢點或者主機地址.