[TOC] <details> <summary>一、你知道 DNS 協議嘛？描述一下從輸入域名到顯示的過程（從 DNS 解析到 HTTP 鏈接建立到內容返回瀏覽器渲染）</summary> ``` 1. 瀏覽器查詢 DNS，獲取域名對應的IP地址：具體過程包括瀏覽器搜索自身的DNS緩存、 搜索操作系統的DNS緩存、讀取本地的Host文件和向本地DNS服務器進行查詢等。對于向 本地DNS服務器進行查詢，如果要查詢的域名包含在本地配置區域資源中，則返回解析結果 給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地DNS服務器區域 解析，但該服務器已緩存了此網址映射關系，則調用這個IP地址映射，完成域名解析（此解 析不具有權威性）。如果本地域名服務器并未緩存該網址映射關系，那么將根據其設置發起 遞歸查詢或者迭代查詢； 2. 瀏覽器獲得域名對應的IP地址以后，瀏覽器向服務器請求建立鏈接，發起三次握手； 3. TCP/IP鏈接建立起來后，瀏覽器向服務器發送HTTP請求； 4. 服務器接收到這個請求，并根據路徑參數映射到特定的請求處理器進行處理，并將處理 結果及相應的視圖返回給瀏覽器； 5. 瀏覽器解析并渲染視圖，若遇到對js文件、css文件及圖片等靜態資源的引用，則重復上 述步驟并向服務器請求這些資源； 6. 瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。 ``` </details> <br /> <details> <summary>二、遞歸查詢和迭代查詢，具體說一說什么樣子的？</summary> ``` 1.主機向本地域名服務器的查詢一般都是采用遞歸查詢：如果主機所詢問的本地域名服務器 不知道被查詢的IP地址，那么本地域名服務器就以DNS客戶的身份，向其他根域名器繼續發 出查詢請求報文（即替該主機繼續查詢），而不是讓該主機自己進行下一步查詢。因此，遞 歸查詢返回的查詢結果或者是所要查詢的ip地址，或者是報錯，或者無法查詢到所需要的IP地址。 2.本地域名服務器向根域名服務器的查詢通常是采用迭代查詢（iterative query）迭代查詢的 特點是這樣的：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要么給出 所要查詢的IP地址，要么告訴本地域名服務器：“你下一步應當向哪一個域名服務器進行查詢”。 然后讓本地域名服務器進行后續的查詢（而不是替本地域名服務器進行后續的查詢）。根域 名服務器通常是把自己知道的頂級域名服務器的IP地址告訴本地域名服務器，讓本地域名服務 器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求后，要么給 出所要查詢的IP地址，要么告訴本地域名服務器下一步應當向哪一個權限域名服務器進行查詢， 本地域名服務器就這樣進行迭代查詢。最后，知道了所要解析的域名的IP地址，然后把這個結 果返回給發起查詢的主機。當然，本地域名服務器也可以采用遞歸查詢，這取決于最初的查詢 請求報文的設置是要求使用哪一種查詢方式。 ``` </details> <br /> <details> <summary>三、本地域名服務器向根服務器查詢的是什么？</summary> ``` 是要從輸入的域名檢驗根服務器中對應的域名服務器的 IP 地址 ``` </details> <br /> <details> <summary>四、TCP 的三次握手，詳細描述一下，最好包括它的一些狀態</summary>  ``` 第一次握手：Client將SYN置1，隨機產生一個初始序列號seq發送給Server，進入SYN_SENT狀態； 第二次握手：Server收到Client的SYN=1之后，知道客戶端請求建立連接，將自己的SYN置1，ACK 置1，產生一個ACKnum=Seq number+1，并隨機產生一個自己的初始序列號，發送給客戶端；進入 SYN_RCVD狀態； 第三次握手：客戶端檢查ACKnum是否為序列號+1，ACK是否為1，檢查正確之后將自己的ACK置為1， 產生一個ACKnum=服務器發的序列號+1，發送給服務器；進入ESTABLISHED狀態；服務器檢查ACK 為1和ACKnum為序列號+1之后，也進入ESTABLISHED狀態；完成三次握手，連接建立。 ``` </details> <br /> <details> <summary>五、DNS 用的 TCP 還是 UDP？為什么用 UDP？</summary> ``` 衡量計算機通信快慢的指標是“響應時間”，即從用戶發出通信指令（輸入網址敲回車鍵）開始， 到用戶看到完整頁面為止，所流逝的時間。 響應時間( Response Time) 以瀏覽器為例,這個響應時間大體分為三部分 響應時間 = DNS域名解析時間 + TCP連接建立時間 + HTTP交易時間 如果讓響應時間盡可能小,只有讓等號右側的三者盡可能小。 TCP連接是定的三次握手,所以很難有進一步縮小的空間。 HTTP交易,基于Request / Response,也很難有提升的空間。 所以,只能讓DNS域名解析的時間越小越好。 域名解析 釆用TCP傳輸,則域名解析時間為: DNS域名解析時間 = TCP連接時間 + DNS交易時間 釆用UDP傳輸,則域名解析時間為: DNS域名解析時間 = DNS交易時間 很顯然,采用UDP專輸,DNS域名解析時間更小。 DNS在進行區域傳輸的時候使用TCP協議，其它時候則使用UDP協議；? DNS的規范規定了2種類型的DNS服務器，一個叫主DNS服務器，一個叫輔助DNS服務器。 在一個區中主DNS服務器從自己本機的數據文件中讀取該區的DNS數據信息，而輔助 DNS服務器則從區的主DNS服務器中讀取該區的DNS數據信息。當一個輔助DNS服務器 啟動時，它需要與主DNS服務器通信，并加載數據信息，這就叫做區傳送（zone transfer）。? 為什么既使用TCP又使用UDP？? 首先了解一下TCP與UDP傳送字節的長度限制：? UDP報文的最大長度為512字節，而TCP則允許報文長度超過512字節。當DNS查詢超過 512字節時，協議的TC標志出現刪除標志，這時則使用TCP發送。通常傳統的UDP報文 一般不會大于512字節。? 區域傳送時使用TCP，主要有一下兩點考慮：? 1.輔域名服務器會定時（一般時3小時）向主域名服務器進行查詢以便了解數據是否有 變動。如有變動，則會執行一次區域傳送，進行數據同步。區域傳送將使用TCP而不是 UDP，因為數據同步傳送的數據量比一個請求和應答的數據量要多得多。? 2.TCP是一種可靠的連接，保證了數據的準確性。? 域名解析時使用UDP協議：? 客戶端向DNS服務器查詢域名，一般返回的內容都不超過512字節，用UDP傳輸即可。不用 經過TCP三次握手，這樣DNS服務器負載更低，響應更快。雖然從理論上說，客戶端也可 以指定向DNS服務器查詢的時候使用TCP，但事實上，很多DNS服務器進行配置的時候， 僅支持UDP查詢包。 ``` </details> <br /> <details> <summary>六、TCP和UDP的區別</summary> ``` 1. TCP是面向連接的，UDP是無連接的； 什么叫無連接？ 面向無連接 UDP 不需要與 TCP一樣在發送數據前進行三次握手建立連接，UDP想發數據 就直接發送了；并且UDP只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操作。 2. TCP是可靠的，UDP不可靠； UDP不可靠 首先不可靠性體現在無連接上，通信都不需要建立連接，想發就發，這樣的情況 肯定不可靠的；并且收到什么數據就傳遞什么數據，也不會備份數據，發送數據也不會關心 對方是否已經正確接收到數據； 再者網絡環境時好時壞，但是 UDP 因為沒有擁塞控制，一 直會以恒定的速度發送數據；即使網絡條件不好，也不會對發送速率進行調整，這樣實現 的弊端就是在網絡條件不好的情況下可能會導致丟包，但是優點也很明顯，在某些實時性要 求高的場景（比如直播、電話會議等）就需要使用 UDP 而不是 TCP； 3. TCP只支持點對點通信，UDP支持一對一、一對多、多對一、多對多； 由于 UDP 不會建立連接，因此它可以給任何人傳遞數據，不止支持一對一的傳輸方式，同樣 支持一對多、多對多、多對一的方式； 4. TCP是面向字節流的，UDP是面向報文的； UDP是面向報文的 發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付IP層 （UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界）； 面向字節流是指發送數據時以字節為單位，一個數據包可以拆分成若干組進行發送，而UDP 一個報文只能一次發完。 5. TCP有擁塞控制機制，UDP沒有。 網絡出現的擁塞不會使源主機的發送速率降低，這對某些實時應用是很重要的，比如媒體通信，游戲； 6. TCP首部開銷（20字節）比UDP首部開銷（8字節）要大 頭部開銷小，傳輸數據高效 UDP 的頭部開銷小，只有八字節，在傳輸數據報文時是比較高效 的（在某些實時性要求高的場景，例如直播、電話會議、媒體傳輸等場景經常使用UDP協議）； 7. UDP 的主機不需要維持復雜的連接狀態表 ``` </details> <br /> <details> <summary>七、TCP 和 UDP 的各自的應用，舉例子</summary> ``` 對某些實時性要求比較高的情況，選擇UDP，比如游戲，媒體通信，實時視頻流（直播）， 即使出現傳輸錯誤也可以容忍；其它大部分情況下，HTTP都是用TCP，因為要求傳輸的內 容可靠，不出現丟失。 ``` </details> <br /> <details> <summary>八、TCP 的四次揮手</summary>  ``` - 第一次揮手：Client將FIN置為1，發送一個序列號seq給Server；進入FIN_WAIT_1狀態； - 第二次揮手：Server收到FIN之后，發送一個ACK=1，ACKnum=收到的序列號+1；進入 CLOSE_WAIT狀態。此時客戶端已經沒有要發送的數據了，但仍可以接受服務器發來的數據。 - 第三次揮手：Server將FIN置1，發送一個序列號給Client；進入LAST_ACK狀態； - 第四次揮手：Client收到服務器的FIN后，進入TIME_WAIT狀態；接著將ACK置1，發送 一個ACKnum=序列號+1給服務器；服務器收到后，確認ACKnum后，變為CLOSED狀態，不再 向客戶端發送數據。客戶端等待2*MSL（報文段最長壽命）時間后，也進入CLOSED狀態。 完成四次揮手。 ``` </details> <br /> <details> <summary>九、2個MSL指的是什么？為什么要 2 個？</summary> ``` 第四次揮手時，客戶端發送給服務器的ACK有可能丟失，TIME_WAIT狀態就是用來重發可能 丟失的ACK報文。如果Server沒有收到ACK，就會重發FIN，如果Client在2*MSL的時間內 收到了FIN，就會重新發送ACK并再次等待2MSL，防止Server沒有收到ACK而不斷重發FIN。 MSL(Maximum Segment Lifetime)，指一個片段在網絡中最大的存活時間，2MSL就是一個 發送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client 推斷ACK已經被成功接收，則結束TCP連接。 ``` </details> <br /> <details> <summary>十、TCP 的一些擁塞控制算法了解多少？</summary> ``` 擁塞控制主要由四個算法組成：慢啟動（Slow Start）、擁塞避免（Congestion voidance）、 快重傳 （Fast Retransmit）、快恢復（Fast Recovery） 1. 慢啟動：剛開始發送數據時，先把擁塞窗口（congestion window）設置為一個最大報文段 MSS的數值，每收到一個新的確認報文之后，就把擁塞窗口加1個MSS。這樣每經過一個傳輸輪 次（或者說是每經過一個往返時間RTT），擁塞窗口的大小就會加倍 * 2. 擁塞避免：當擁塞窗口的大小達到慢開始門限(slow start threshold)時，開始執行擁塞避免 算法，擁塞窗口大小不再指數增加，而是線性增加，即每經過一個傳輸輪次只增加1MSS. > 無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到 確認），就要把慢開始門限ssthresh設置為出現擁塞時的發送方窗口值的一半（但不能小于2）。 然后把擁塞窗口cwnd重新設置為1，執行慢開始算法。（這是不使用快重傳的情況） 3. 快重傳：快重傳要求接收方在收到一個失序的報文段后就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。 4. 快恢復：當發送方連續收到三個重復確認時，就把慢開始門限減半，然后執行擁塞避免算法。不執行慢開始算法的原因：因為如果網絡出現擁塞的話就不會收到好幾個重復的確認，所以發送方認為現在網絡可能沒有出現擁塞。 也有的快重傳是把開始時的擁塞窗口cwnd值再增大一點，即等于 ssthresh + 3*MSS 。這樣做的理由是：既然發送方收到三個重復的確認，就表明有三個分組已經離開了網絡。這三個分組不再消耗網絡的資源而是停留在接收方的緩存中。可見現在網絡中減少了三個分組。因此可以適當把擁塞窗口擴大些。 ``` </details> <br /> <details> <summary>十一、HTTP請求方式 （http有哪些請求方法？）</summary> ``` 1.GET GET請求會顯示請求指定的資源。一般來說GET方法應該只用于數據的讀取，而不應當用于會產生副作用的 非冪等的操作中。它期望的應該是而且應該是安全的和冪等的。這里的安全指的是，請求不會影響到資源 的狀態。 2.HEAD HEAD方法與GET方法一樣，都是向服務器發出指定資源的請求。但是，服務器在響應HEAD請求時不會回傳 資源的內容部分，即：響應主體。這樣，我們可以不傳輸全部內容的情況下，就可以獲取服務器的響應頭 信息。HEAD方法常被用于客戶端查看服務器的性能。 3.POST POST請求會 向指定資源提交數據，請求服務器進行處理，如：表單數據提交、文件上傳等，請求數據會 被包含在請求體中。POST方法是非冪等的方法，因為這個請求可能會創建新的資源或/和修改現有資源。 4.PUT PUT請求會身向指定資源位置上傳其最新內容，PUT方法是冪等的方法。通過該方法客戶端可以將指定資源 的最新數據傳送給服務器取代指定的資源的內容。 5.DELETE DELETE請求用于請求服務器刪除所請求URI（統一資源標識符，Uniform Resource Identifier）所標識的 資源。DELETE請求后指定資源會被刪除，DELETE方法也是冪等的。 6.CONNECT CONNECT方法是HTTP/1.1協議預留的，能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的 鏈接與非加密的HTTP代理服務器的通信。 7.OPTIONS OPTIONS請求與HEAD類似，一般也是用于客戶端查看服務器的性能。 這個方法會請求服務器返回該資源所 支持的所有HTTP請求方法，該方法會用'\*'來代替資源名稱，向服務器發送OPTIONS請求，可以測試服務器 功能是否正常。JavaScript的XMLHttpRequest對象進行CORS跨域資源共享時，就是使用OPTIONS方法發送 嗅探請求，以判斷是否有對指定資源的訪問權限。 8.TRACE TRACE請求服務器回顯其收到的請求信息，該方法主要用于HTTP請求的測試或診斷。 9.PATCH PATCH方法出現的較晚，它在2010年的RFC 5789標準中被定義。PATCH請求與PUT請求類似，同樣用于資源 的更新。 二者有以下兩點不同： 1.PATCH一般用于資源的部分更新，而PUT一般用于資源的整體更新。 2.當資源不存在時，PATCH會創建一個新的資源，而PUT只會對已在資源進行更新。 ``` </details> <br /> <details> <summary>十二、POST與PUT區別</summary> ``` 1、PUT請求是向服務器端發送數據的，從而改變信息，該請求就像數據庫的update操作一樣，用來修改 數據的內容，但是不會增加數據的種類等，也就是說無論進行多少次PUT操作，其結果并沒有不同。 2、POST請求同PUT請求類似，都是向服務器端發送數據的，但是該請求會改變數據的種類等資源，就像 數據庫的insert操作一樣，會創建新的內容。幾乎目前所有的提交操作都是用POST請求的。 ``` </details> <br /> <details> <summary>十三、POST長度有限制嗎 </summary> asdsadasd </details> <br /> <details> <summary>十四、HTTP常見狀態碼</summary> ``` 200 OK 最常見的就是成功響應狀態碼200了， 這表明該請求被成功地完成，所請求的資源發送回客戶端。 302 Found 重定向，新的URL會在response 中的Location中返回，瀏覽器將會自動使用新的URL發出新的Request。 304 Not Modified 代表上次的文檔已經被緩存了， 還可以繼續使用。 400 Bad Request? 客戶端請求與語法錯誤，不能被服務器所理解。 403 Forbidden 服務器收到請求，但是拒絕提供服務 404 Not Found 請求資源不存在（輸錯了URL） 500 Internal Server Error 服務器發生了不可預期的錯誤 503 Server Unavailable 服務器當前不能處理客戶端的請求，一段時間后可能恢復正常。 ``` </details> <br /> <details> <summary>十五、HTTP請求中Content-Type</summary> ``` 1. Content-Type MediaType，即是Internet Media Type，互聯網媒體類型；也叫做MIME類型，在Http協議消息頭中， 使用Content-Type來表示具體請求中的媒體類型信息。 例如： Content-Type: text/html;charset:utf-8; 常見的媒體格式類型如下： text/html ： HTML格式 text/plain ：純文本格式 text/xml ： XML格式 image/gif ：gif圖片格式 image/jpeg ：jpg圖片格式 image/png：png圖片格式 以application開頭的媒體格式類型： application/xhtml+xml ：XHTML格式 application/xml ： XML數據格式 application/atom+xml ：Atom XML聚合格式 application/json ： JSON數據格式 application/pdf ：pdf格式 application/msword ： Word文檔格式 application/octet-stream ： 二進制流數據（如常見的文件下載） application/x-www-form-urlencoded ： <form encType=””>中默認的encType， form表單數據被編碼為key/value格式發送到服務器（表單默認的提交數據的格式） 另外一種常見的媒體格式是上傳文件之時使用的： multipart/form-data ： 需要在表單中進行文件上傳時，就需要使用該格式 以上就是我們在日常的開發中，經常會用到的若干content-type的內容格式。 通常你選擇raw，json類型瀏覽器或者postman會自動給你在請求中加上這些信息content-type類型 （json屬于raw類型） ``` </details> <br /> <details> <summary>十六、https加密是怎么實現（ca證書作用是什么 ）</summary> ``` HTTPS = HTTP + SSL / TLS HTTPS 的整個通信過程可以分為兩大階段：證書驗證和數據傳輸階段，數據傳輸階段又可以分為 非對稱加密和對稱加密兩個階段。具體流程按圖中的序號講解。 1.客戶端請求 HTTPS 網址，然后連接到 server 的 443 端口 (HTTPS 默認端口，類似于 HTTP 的80端口)。 2.采用 HTTPS 協議的服務器必須要有一套數字 CA (Certification Authority)證書，證書是需要 申請的，并由專門的數字證書認證機構(CA)通過非常嚴格的審核之后頒發的電子證書 (當然了是 要錢的，安全級別越高價格越貴)。頒發證書的同時會產生一個私鑰和公鑰。私鑰由服務端自己保存， 不可泄漏。公鑰則是附帶在證書的信息中，可以公開的。證書本身也附帶一個證書電子簽名，這個 簽名用來驗證證書的完整性和真實性，可以防止證書被篡改。 3.服務器響應客戶端請求，將證書傳遞給客戶端，證書包含公鑰和大量其他信息，比如證書頒發機構 信息，公司信息和證書有效期等。Chrome 瀏覽器點擊地址欄的鎖標志再點擊證書就可以看到證書詳 細信息。 4.客戶端解析證書并對其進行驗證。如果證書不是可信機構頒布，或者證書中的域名與實際域名不一 致，或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。 如果證書沒有問題，客戶端就會從服務器證書中取出服務器的公鑰A。然后客戶端還會生成一個隨機碼 KEY，并使用公鑰A將其加密。 5.客戶端把加密后的隨機碼 KEY 發送給服務器，作為后面對稱加密的密鑰。 6.服務器在收到隨機碼 KEY 之后會使用私鑰B將其解密。經過以上這些步驟，客戶端和服務器終于建立 了安全連接，完美解決了對稱加密的密鑰泄露問題，接下來就可以用對稱加密愉快地進行通信了。 7.服務器使用密鑰 (隨機碼 KEY)對數據進行對稱加密并發送給客戶端，客戶端使用相同的密鑰 (隨機碼 KEY)解密數據。 8.雙方使用對稱加密愉快地傳輸所有數據。 ``` </details> <br /> <details> <summary>十七、tcp擁塞，怎么避免擁塞</summary> ``` 發送方維持一個叫做擁塞窗口cwnd（congestion window）的狀態變量。 擁塞窗口的大小取決于網絡的擁塞程度，并且動態地在變化。發送方讓 自己的發送窗口等于擁塞窗口，另外考慮到接受方的接收能力，發送窗口 可能小于擁塞窗口。慢開始算法的思路就是，不要一開始就發送大量的數據， 先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小。 過程cwnd的大小呈指數增長，直到超過慢啟動門限，然后進入擁塞避免階段， cwnd的大小線性增長，當出現網絡擁塞(三個重復的ack或者超時)時候， 將慢啟動門限設置為出現擁塞時候大小的一半，cwnd的大小重新從0開始進入 慢啟動階段。 快重傳和快恢復：快重傳要求接收方在收到一個失序的報文段后就立即發出 重復確認（為的是使發送方及早知道有報文段沒有到達對方）而不要等到自己 發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重復確認就 應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。 ``` </details> <br /> <details> <summary>十八、tcp如何進行流量控制的 </summary> asdsadasd </details> <br /> <details> <summary>十九、瀏覽器輸入`www.baidu.com`后發生了什么？</summary> ``` 1、首先，在瀏覽器地址欄中輸入url，先解析url，檢測url地址是否合法 2、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存，如果緩存中有，會直接在屏幕中顯示頁面內容。若沒有，則跳到第三步操作。 瀏覽器緩存：瀏覽器會記錄DNS一段時間，因此，只是第一個地方解析DNS請求； 操作系統緩存：如果在瀏覽器緩存中不包含這個記錄，則會使系統調用操作系統，獲取操作系統的記錄(保存最近的DNS查詢緩存)； 路由器緩存：如果上述兩個步驟均不能成功獲取DNS記錄，繼續搜索路由器緩存； ISP緩存：若上述均失敗，繼續向ISP搜索。 3、在發送http請求前，需要域名解析(DNS解析)，解析獲取相應的IP地址。 4、瀏覽器向服務器發起tcp連接，與瀏覽器建立tcp三次握手。 5、握手成功后，瀏覽器向服務器發送http請求，請求數據包。 6、服務器處理收到的請求，將數據返回至瀏覽器 7、瀏覽器收到HTTP響應 8、瀏覽器解碼響應，如果響應可以緩存，則存入緩存。 9、瀏覽器發送請求獲取嵌入在HTML中的資源（html，css，javascript，圖片，音樂······），對于未知類型，會彈出對話框。 10、瀏覽器發送異步請求。 11、頁面全部渲染結束 ``` </details> <br /> <details> <summary>二十、網絡傳輸過程涉及哪些協議</summary> ``` 涉及到的協議： (1) 應用層：HTTP(WWW訪問協議)，DNS(域名解析服務) (2) 傳輸層：TCP(為HTTP提供可靠的數據傳輸)，UDP(DNS使用UDP傳輸) (3) 網絡層：IP(IP數據數據包傳輸和路由選擇)，ICMP(提供網絡傳輸過程中的差錯檢測)， ARP(將本機的默認網關IP地址映射成物理MAC地址) ``` </details> <br /> <details> <summary>二十一、tcp,http位于哪層</summary> ``` OSI的7層從上到下分別是 7 應用層(TELNET，HTTP，FTP，NFS，SMTP) 6 表示層 5 會話層 4 傳輸層 （TCP，UDP） 3 網絡層 （IP) 2 數據鏈路層 1 物理層 ``` </details> <br /> <details> <summary>二十二、說一下cookie 和 session</summary> ``` 1. 由于HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識具體的用戶， 這個機制就是Session.典型的場景比如購物車，當你點擊下單按鈕時，由于HTTP協議無狀態，所以并不知 道是哪個用戶操作的，所以服務端要為特定的用戶創建了特定的Session，用用于標識這個用戶，并且跟蹤 用戶，這樣才知道購物車里面有幾本書。這個Session是保存在服務端的，有一個唯一標識。在服務端保存 Session的方法很多，內存、數據庫、文件都有。集群的時候也要考慮Session的轉移，在大型的網站， 一般會有專門的Session服務器集群，用來保存用戶會話，這個時候 Session 信息都是放在內存的，使用 一些緩存服務比如Memcached之類的來放 Session。 2. 思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發送 相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次創建Session 的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 里面記錄一個Session ID，以后每次請求把這個 會話ID發送到服務器，我就知道你是誰了。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎么辦？一般這種情況 下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL后面都會被附加上一個諸如sid=xxxxx 這樣的參數，服務端據此來識別用戶。 3. Cookie其實還可以用在一些方便用戶的場景下，設想你某次登陸過一個網站，下次登錄的時候不想再次輸入 賬號了，怎么辦？這個信息可以寫到Cookie里面，訪問網站的時候，網站頁面的腳本可以讀取這個信息，就自動 幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。 所以，總結一下： Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據可以保存在集群、數據庫、文件中； Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式。 ``` </details> <br /> <details> <summary>二十三、TCP連接細節問題深挖，服務端突然崩潰后客戶端接下來的活動過程進行描述，客戶端會做什么以及原因。服務器又恢復正常后客戶端接下來又會做什么以及原因</summary> asdsadasd </details> <br /> <details> <summary>二十四、網絡協議分層介紹</summary> asdsadasd </details> <br /> <details> <summary>二十五、怎么樣讓UDP可靠</summary> asdsadasd </details> <br /> <details> <summary>二十六、http 協議各個版本的區別？演進的邏輯？ </summary> asdsadasd </details> <br /> <details> <summary>二十七、怎么確定數據包丟了？（冗余 ack）ACK 會不會丟掉呢？</summary> asdsadasd </details> <br /> <details> <summary>二十八、HTTP和HTTPS的區別，HTTP1.0、1.1和2的版本區別，HTTPS的請求過程</summary> asdsadasd </details> <br /> <details> <summary>二十九、滑動窗口機制 </summary> asdsadasd </details> <br /> <details> <summary>三十、DNS劫持</summary> asdsadasd </details> <br /> <details> <summary>三十一、HTTP是基于TCP還是UDP，為什么？</summary> asdsadasd </details> <br />