目錄
http2.0
Http與Https的基本概念和他們的區(qū)別
HTTPS工作原理
常用的HTTP方法
GET方法與POST方法的區(qū)別
HTTP請(qǐng)求報(bào)文與響應(yīng)報(bào)文格式
常見(jiàn)的HTTP狀態(tài)碼
一個(gè)頁(yè)面從輸入 URL 到頁(yè)面加載顯示完成，這個(gè)過(guò)程中都發(fā)生了什么？
HTTP優(yōu)化方案
localStorage. sessionStorage、 Cookie不同點(diǎn)
get和post請(qǐng)求在緩存方面的區(qū)別
cookie session區(qū)別
網(wǎng)絡(luò)中的ACK； SYN； FIN都是什么
http瀏覽器緩存機(jī)制
25. 304狀態(tài)碼500狀態(tài)碼具體場(chǎng)景
DNS原理
CND原理
osi七層模型每層分別是什么，http在哪層，tcp在哪層
滑動(dòng)窗口
35. 前端安全HTTPS為什么要使用一個(gè)對(duì)稱加密和非對(duì)稱加密相結(jié)合
39.Http與Https的基本概念和他們的區(qū)別tcp粘包
restful級(jí)別
1. http2.0
首先補(bǔ)充一下，http和https的區(qū)別，相比于http,https是基于ssl加密的http協(xié)議
簡(jiǎn)要概括：http2.0是基于1999年發(fā)布的http1.0之后的首次更新。
提升訪問(wèn)速度（可以對(duì)于，請(qǐng)求資源所需時(shí)間更少，訪問(wèn)速度更快，相比http1.0）
允許多路復(fù)用：多路復(fù)用允許同時(shí)通過(guò)單一的HTTP/2連接發(fā)送多重請(qǐng)求-響應(yīng)信息。改善了：在http1.1中，瀏覽器客戶端在同一時(shí)間，針對(duì)同一域名下的請(qǐng)求有一定數(shù)量限制（連接數(shù)量），超過(guò)限制會(huì)被阻塞。
二進(jìn)制分幀：HTTP2.0會(huì)將所有的傳輸信息分割為更小的信息或者幀，并對(duì)他們進(jìn)行二進(jìn)制編碼，他采用二進(jìn)制格式傳輸數(shù)據(jù)而不是1.x的文本格式。
頭部壓縮
1.x版本中，首部用文本格式傳輸
2.0版本采用HPACK壓縮格式壓縮頭部
（靜態(tài)字典）索引
服務(wù)器端推送
服務(wù)器端推送使得服務(wù)器可以預(yù)測(cè)客戶端需要的資源，主動(dòng)推送到客戶端。
例如：客戶端請(qǐng)求index.html，服務(wù)器端能夠額外推送script.js和style.css。
實(shí)現(xiàn)原理就是客戶端發(fā)出頁(yè)面請(qǐng)求時(shí)，服務(wù)器端能夠分析這個(gè)頁(yè)面所依賴的其他資源，主動(dòng)推送到客戶端的緩存，當(dāng)客戶端收到原始網(wǎng)頁(yè)的請(qǐng)求時(shí)，它需要的資源已經(jīng)位于緩存。
針對(duì)每一個(gè)希望發(fā)送的資源，服務(wù)器會(huì)發(fā)送一個(gè)PUSH_PROMISE幀，客戶端可以通過(guò)發(fā)送RST_STREAM幀來(lái)拒絕推送（當(dāng)資源已經(jīng)位于緩存）。這一步的操作先于父響應(yīng)（index.html），客戶端了解到服務(wù)器端打算推送哪些資源，就不會(huì)再為這些資源創(chuàng)建重復(fù)請(qǐng)求。當(dāng)客戶端收到index.html的響應(yīng)時(shí)，script.js和style.css已經(jīng)位于緩存。
2. TCP三次握手與四次揮手
三次握手
所謂的三次握手即TCP連接的建立。這個(gè)連接必須是一方主動(dòng)打開(kāi)，另一方被動(dòng)打開(kāi)的。以下為客戶端主動(dòng)發(fā)起連接的圖解：
確認(rèn)ACK：占1位，僅當(dāng)ACK=1時(shí)，確認(rèn)號(hào)字段才有效。ACK=0時(shí)，確認(rèn)號(hào)無(wú)效
同步SYN：連接建立時(shí)用于同步序號(hào)。當(dāng)SYN=1，ACK=0時(shí)表示：這是一個(gè)連接請(qǐng)求報(bào)文段。若同意連接，則在響應(yīng)報(bào)文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個(gè)連接請(qǐng)求，或連接接受報(bào)文。SYN這個(gè)標(biāo)志位只有在TCP建產(chǎn)連接時(shí)才會(huì)被置1，握手完成后SYN標(biāo)志位被置0。
握手之前主動(dòng)打開(kāi)連接的客戶端結(jié)束CLOSED階段，被動(dòng)打開(kāi)的服務(wù)器端也結(jié)束CLOSED階段，并進(jìn)入LISTEN階段。隨后開(kāi)始“三次握手”：
（1）首先客戶端向服務(wù)器端發(fā)送一段TCP報(bào)文，其中：
標(biāo)記位為SYN，表示“請(qǐng)求建立新連接”;
序號(hào)為Seq=X（X一般為1）；
隨后客戶端進(jìn)入SYN-SENT階段。
（2）服務(wù)器端接收到來(lái)自客戶端的TCP報(bào)文之后，結(jié)束LISTEN階段。并返回一段TCP報(bào)文，其中：
標(biāo)志位為SYN和ACK，表示“確認(rèn)客戶端的報(bào)文Seq序號(hào)有效，服務(wù)器能正常接收客戶端發(fā)送的數(shù)據(jù)，并同意創(chuàng)建新連接”（即告訴客戶端，服務(wù)器收到了你的數(shù)據(jù)）；
序號(hào)為Seq=y；
確認(rèn)號(hào)為Ack=x+1，表示收到客戶端的序號(hào)Seq并將其值加1作為自己確認(rèn)號(hào)Ack的值；隨后服務(wù)器端進(jìn)入SYN-RCVD階段。
（3）客戶端接收到來(lái)自服務(wù)器端的確認(rèn)收到數(shù)據(jù)的TCP報(bào)文之后，明確了從客戶端到服務(wù)器的數(shù)據(jù)傳輸是正常的，結(jié)束SYN-SENT階段。并返回最后一段TCP報(bào)文。其中：
標(biāo)志位為ACK，表示“確認(rèn)收到服務(wù)器端同意連接的信號(hào)”（即告訴服務(wù)器，我知道你收到我發(fā)的數(shù)據(jù)了）；
序號(hào)為Seq=x+1，表示收到服務(wù)器端的確認(rèn)號(hào)Ack，并將其值作為自己的序號(hào)值；
確認(rèn)號(hào)為Ack=y+1，表示收到服務(wù)器端序號(hào)Seq，并將其值加1作為自己的確認(rèn)號(hào)Ack的值；
隨后客戶端進(jìn)入ESTABLISHED階段。
服務(wù)器收到來(lái)自客戶端的“確認(rèn)收到服務(wù)器數(shù)據(jù)”的TCP報(bào)文之后，明確了從服務(wù)器到客戶端的數(shù)據(jù)傳輸是正常的。結(jié)束SYN-SENT階段，進(jìn)入ESTABLISHED階段。
在客戶端與服務(wù)器端傳輸?shù)腡CP報(bào)文中，雙方的確認(rèn)號(hào)Ack和序號(hào)Seq的值，都是在彼此Ack和Seq值的基礎(chǔ)上進(jìn)行計(jì)算的，這樣做保證了TCP報(bào)文傳輸?shù)倪B貫性。一旦出現(xiàn)某一方發(fā)出的TCP報(bào)文丟失，便無(wú)法繼續(xù)"握手"，以此確保了"三次握手"的順利完成。
此后客戶端和服務(wù)器端進(jìn)行正常的數(shù)據(jù)傳輸。這就是“三次握手”的過(guò)程。
為什么要進(jìn)行第三次握手？
為了防止服務(wù)器端開(kāi)啟一些無(wú)用的連接增加服務(wù)器開(kāi)銷以及防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
由于網(wǎng)絡(luò)傳輸是有延時(shí)的(要通過(guò)網(wǎng)絡(luò)光纖和各種中間代理服務(wù)器)，在傳輸?shù)倪^(guò)程中，比如客戶端發(fā)起了SYN=1創(chuàng)建連接的請(qǐng)求(第一次握手)。
如果服務(wù)器端就直接創(chuàng)建了這個(gè)連接并返回包含SYN、ACK和Seq等內(nèi)容的數(shù)據(jù)包給客戶端，這個(gè)數(shù)據(jù)包因?yàn)榫W(wǎng)絡(luò)傳輸?shù)脑騺G失了，丟失之后客戶端就一直沒(méi)有接收到服務(wù)器返回的數(shù)據(jù)包。
客戶端可能設(shè)置了一個(gè)超時(shí)時(shí)間，時(shí)間到了就關(guān)閉了連接創(chuàng)建的請(qǐng)求。再重新發(fā)出創(chuàng)建連接的請(qǐng)求，而服務(wù)器端是不知道的，如果沒(méi)有第三次握手告訴服務(wù)器端客戶端收的到服務(wù)器端傳輸?shù)臄?shù)據(jù)的話，
服務(wù)器端是不知道客戶端有沒(méi)有接收到服務(wù)器端返回的信息的。
這個(gè)過(guò)程可理解為：
這樣沒(méi)有給服務(wù)器端一個(gè)創(chuàng)建還是關(guān)閉連接端口的請(qǐng)求，服務(wù)器端的端口就一直開(kāi)著，等到客戶端因超時(shí)重新發(fā)出請(qǐng)求時(shí)，服務(wù)器就會(huì)重新開(kāi)啟一個(gè)端口連接。那么服務(wù)器端上沒(méi)有接收到請(qǐng)求數(shù)據(jù)的上一個(gè)端口就一直開(kāi)著，長(zhǎng)此以往，這樣的端口多了，就會(huì)造成服務(wù)器端開(kāi)銷的嚴(yán)重浪費(fèi)。
還有一種情況是已經(jīng)失效的客戶端發(fā)出的請(qǐng)求信息，由于某種原因傳輸?shù)搅朔?wù)器端，服務(wù)器端以為是客戶端發(fā)出的有效請(qǐng)求，接收后產(chǎn)生錯(cuò)誤。
所以我們需要“第三次握手”來(lái)確認(rèn)這個(gè)過(guò)程，讓客戶端和服務(wù)器端能夠及時(shí)地察覺(jué)到因?yàn)榫W(wǎng)絡(luò)等一些問(wèn)題導(dǎo)致的連接創(chuàng)建失敗，這樣服務(wù)器端的端口就可以關(guān)閉了不用一直等待。
也可以這樣理解：“第三次握手”是客戶端向服務(wù)器端發(fā)送數(shù)據(jù)，這個(gè)數(shù)據(jù)就是要告訴服務(wù)器，客戶端有沒(méi)有收到服務(wù)器“第二次握手”時(shí)傳過(guò)去的數(shù)據(jù)。若發(fā)送的這個(gè)數(shù)據(jù)是“收到了”的信息，接收后服務(wù)器就正常建立TCP連接，否則建立TCP連接失敗，服務(wù)器關(guān)閉連接端口。由此減少服務(wù)器開(kāi)銷和接收到失效請(qǐng)求發(fā)生的錯(cuò)誤。
抓包驗(yàn)證
下面是用抓包工具抓到的一些數(shù)據(jù)包，可用來(lái)分析TCP的三次握手：
圖中顯示的就是完整的TCP連接的”三次握手”過(guò)程。在52528 -> 80中，52528是本地(客戶端)端口，80是服務(wù)器的端口。80端口和52528端口之間的三次來(lái)回就是"三次握手"過(guò)程。
注意到”第一次握手”客戶端發(fā)送的TCP報(bào)文中以[SYN]作為標(biāo)志位，并且客戶端序號(hào)Seq=0；
接下來(lái)”第二次握手”服務(wù)器返回的TCP報(bào)文中以[SYN，ACK]作為標(biāo)志位；并且服務(wù)器端序號(hào)Seq=0；確認(rèn)號(hào)Ack=1(“第一次握手”中客戶端序號(hào)Seq的值+1);
最后”第三次握手”客戶端再向服務(wù)器端發(fā)送的TCP報(bào)文中以[ACK]作為標(biāo)志位；
其中客戶端序號(hào)Seq=1（“第二次握手”中服務(wù)器端確認(rèn)號(hào)Ack的值）；確認(rèn)號(hào)Ack=1(“第二次握手”中服務(wù)器端序號(hào)Seq的值+1)。
這就完成了”三次握手”的過(guò)程，符合前面分析的結(jié)果。
四次揮手
（1）首先客戶端想要釋放連接，向服務(wù)器端發(fā)送一段TCP報(bào)文，其中：
標(biāo)記位為FIN，表示“請(qǐng)求釋放連接“；
序號(hào)為Seq=U；
隨后客戶端進(jìn)入FIN-WAIT-1階段，即半關(guān)閉階段。并且停止在客戶端到服務(wù)器端方向上發(fā)送數(shù)據(jù)，但是客戶端仍然能接收從服務(wù)器端傳輸過(guò)來(lái)的數(shù)據(jù)。
注意：這里不發(fā)送的是正常連接時(shí)傳輸?shù)臄?shù)據(jù)(非確認(rèn)報(bào)文)，而不是一切數(shù)據(jù)，所以客戶端仍然能發(fā)送ACK確認(rèn)報(bào)文。
（2）服務(wù)器端接收到從客戶端發(fā)出的TCP報(bào)文之后，確認(rèn)了客戶端想要釋放連接，隨后服務(wù)器端結(jié)束ESTABLISHED階段，進(jìn)入CLOSE-WAIT階段（半關(guān)閉狀態(tài)）并返回一段TCP報(bào)文，其中：
標(biāo)記位為ACK，表示“接收到客戶端發(fā)送的釋放連接的請(qǐng)求”；
序號(hào)為Seq=V；
確認(rèn)號(hào)為Ack=U+1，表示是在收到客戶端報(bào)文的基礎(chǔ)上，將其序號(hào)Seq值加1作為本段報(bào)文確認(rèn)號(hào)Ack的值；
隨后服務(wù)器端開(kāi)始準(zhǔn)備釋放服務(wù)器端到客戶端方向上的連接。
客戶端收到從服務(wù)器端發(fā)出的TCP報(bào)文之后，確認(rèn)了服務(wù)器收到了客戶端發(fā)出的釋放連接請(qǐng)求，隨后客戶端結(jié)束FIN-WAIT-1階段，進(jìn)入FIN-WAIT-2階段
前"兩次揮手"既讓服務(wù)器端知道了客戶端想要釋放連接，也讓客戶端知道了服務(wù)器端了解了自己想要釋放連接的請(qǐng)求。于是，可以確認(rèn)關(guān)閉客戶端到服務(wù)器端方向上的連接了
（3）服務(wù)器端自從發(fā)出ACK確認(rèn)報(bào)文之后，經(jīng)過(guò)CLOSED-WAIT階段，做好了釋放服務(wù)器端到客戶端方向上的連接準(zhǔn)備，再次向客戶端發(fā)出一段TCP報(bào)文，其中：
標(biāo)記位為FIN，ACK，表示“已經(jīng)準(zhǔn)備好釋放連接了”。注意：這里的ACK并不是確認(rèn)收到服務(wù)器端報(bào)文的確認(rèn)報(bào)文。
序號(hào)為Seq=W；
確認(rèn)號(hào)為Ack=U+1；表示是在收到客戶端報(bào)文的基礎(chǔ)上，將其序號(hào)Seq值加1作為本段報(bào)文確認(rèn)號(hào)Ack的值。
隨后服務(wù)器端結(jié)束CLOSE-WAIT階段，進(jìn)入LAST-ACK階段。并且停止在服務(wù)器端到客戶端的方向上發(fā)送數(shù)據(jù)，但是服務(wù)器端仍然能夠接收從客戶端傳輸過(guò)來(lái)的數(shù)據(jù)。
（4）客戶端收到從服務(wù)器端發(fā)出的TCP報(bào)文，確認(rèn)了服務(wù)器端已做好釋放連接的準(zhǔn)備，結(jié)束FIN-WAIT-2階段，進(jìn)入TIME-WAIT階段，并向服務(wù)器端發(fā)送一段報(bào)文，其中：
標(biāo)記位為ACK，表示“接收到服務(wù)器準(zhǔn)備好釋放連接的信號(hào)”。
序號(hào)為Seq=U+1；表示是在收到了服務(wù)器端報(bào)文的基礎(chǔ)上，將其確認(rèn)號(hào)Ack值作為本段報(bào)文序號(hào)的值。
確認(rèn)號(hào)為Ack=W+1；表示是在收到了服務(wù)器端報(bào)文的基礎(chǔ)上，將其序號(hào)Seq值作為本段報(bào)文確認(rèn)號(hào)的值。
隨后客戶端開(kāi)始在TIME-WAIT階段等待2MSL
為什么要客戶端要等待2MSL呢？見(jiàn)后文。
服務(wù)器端收到從客戶端發(fā)出的TCP報(bào)文之后結(jié)束LAST-ACK階段，進(jìn)入CLOSED階段。由此正式確認(rèn)關(guān)閉服務(wù)器端到客戶端方向上的連接。
客戶端等待完2MSL之后，結(jié)束TIME-WAIT階段，進(jìn)入CLOSED階段，由此完成“四次揮手”。
后“兩次揮手”既讓客戶端知道了服務(wù)器端準(zhǔn)備好釋放連接了，也讓服務(wù)器端知道了客戶端了解了自己準(zhǔn)備好釋放連接了。于是，可以確認(rèn)關(guān)閉服務(wù)器端到客戶端方向上的連接了，由此完成“四次揮手”。
與“三次揮手”一樣，在客戶端與服務(wù)器端傳輸?shù)腡CP報(bào)文中，雙方的確認(rèn)號(hào)Ack和序號(hào)Seq的值，都是在彼此Ack和Seq值的基礎(chǔ)上進(jìn)行計(jì)算的，這樣做保證了TCP報(bào)文傳輸?shù)倪B貫性，一旦出現(xiàn)某一方發(fā)出的TCP報(bào)文丟失，便無(wú)法繼續(xù)"揮手"，以此確保了"四次揮手"的順利完成。
為什么“握手”是三次，“揮手”卻要四次？
TCP建立連接時(shí)之所以只需要"三次握手"，是因?yàn)樵诘诙?握手"過(guò)程中，服務(wù)器端發(fā)送給客戶端的TCP報(bào)文是以SYN與ACK作為標(biāo)志位的。SYN是請(qǐng)求連接標(biāo)志，表示服務(wù)器端同意建立連接；ACK是確認(rèn)報(bào)文，表示告訴客戶端，服務(wù)器端收到了它的請(qǐng)求報(bào)文。
即SYN建立連接報(bào)文與ACK確認(rèn)接收?qǐng)?bào)文是在同一次"握手"當(dāng)中傳輸?shù)模?三次握手"不多也不少，正好讓雙方明確彼此信息互通。
TCP釋放連接時(shí)之所以需要“四次揮手”,是因?yàn)镕IN釋放連接報(bào)文與ACK確認(rèn)接收?qǐng)?bào)文是分別由第二次和第三次"握手"傳輸?shù)?。為何建立連接時(shí)一起傳輸，釋放連接時(shí)卻要分開(kāi)傳輸？
建立連接時(shí)，被動(dòng)方服務(wù)器端結(jié)束CLOSED階段進(jìn)入“握手”階段并不需要任何準(zhǔn)備，可以直接返回SYN和ACK報(bào)文，開(kāi)始建立連接。
釋放連接時(shí)，被動(dòng)方服務(wù)器，突然收到主動(dòng)方客戶端釋放連接的請(qǐng)求時(shí)并不能立即釋放連接，因?yàn)檫€有必要的數(shù)據(jù)需要處理，所以服務(wù)器先返回ACK確認(rèn)收到報(bào)文，經(jīng)過(guò)CLOSE-WAIT階段準(zhǔn)備好釋放連接之后，才能返回FIN釋放連接報(bào)文。
為什么客戶端在TIME-WAIT階段要等2MSL?
為的是確認(rèn)服務(wù)器端是否收到客戶端發(fā)出的ACK確認(rèn)報(bào)文
當(dāng)客戶端發(fā)出最后的ACK確認(rèn)報(bào)文時(shí)，并不能確定服務(wù)器端能夠收到該段報(bào)文。所以客戶端在發(fā)送完ACK確認(rèn)報(bào)文之后，會(huì)設(shè)置一個(gè)時(shí)長(zhǎng)為2MSL的計(jì)時(shí)器。MSL指的是Maximum Segment Lifetime：一段TCP報(bào)文在傳輸過(guò)程中的最大生命周期。2MSL即是服務(wù)器端發(fā)出為FIN報(bào)文和客戶端發(fā)出的ACK確認(rèn)報(bào)文所能保持有效的最大時(shí)長(zhǎng)。
服務(wù)器端在1MSL內(nèi)沒(méi)有收到客戶端發(fā)出的ACK確認(rèn)報(bào)文，就會(huì)再次向客戶端發(fā)出FIN報(bào)文；
如果客戶端在2MSL內(nèi)，再次收到了來(lái)自服務(wù)器端的FIN報(bào)文，說(shuō)明服務(wù)器端由于各種原因沒(méi)有接收到客戶端發(fā)出的ACK確認(rèn)報(bào)文?？蛻舳嗽俅蜗蚍?wù)器端發(fā)出ACK確認(rèn)報(bào)文，計(jì)時(shí)器重置，重新開(kāi)始2MSL的計(jì)時(shí)；
否則客戶端在2MSL內(nèi)沒(méi)有再次收到來(lái)自服務(wù)器端的FIN報(bào)文，說(shuō)明服務(wù)器端正常接收了ACK確認(rèn)報(bào)文，客戶端可以進(jìn)入CLOSED階段，完成“四次揮手”。
所以，客戶端要經(jīng)歷時(shí)長(zhǎng)為2SML的TIME-WAIT階段；這也是為什么客戶端比服務(wù)器端晚進(jìn)入CLOSED階段的原因
3.HTTPS工作原理
1.Client發(fā)起一個(gè)HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請(qǐng)求，根據(jù)RFC2818的規(guī)定，Client知道需要連接Server的443（默認(rèn)）端口。
2.Server把事先配置好的公鑰證書(shū)（public key certificate）返回給客戶端。
3.Client驗(yàn)證公鑰證書(shū)：比如是否在有效期內(nèi)，證書(shū)的用途是不是匹配Client請(qǐng)求的站點(diǎn)，是不是在CRL吊銷列表里面，它的上一級(jí)證書(shū)是否有效，這是一個(gè)遞歸的過(guò)程，直到驗(yàn)證到根證書(shū)（操作系統(tǒng)內(nèi)置的Root證書(shū)或者Client內(nèi)置的Root證書(shū)）。如果驗(yàn)證通過(guò)則繼續(xù)，不通過(guò)則顯示警告信息。
4.Client使用偽隨機(jī)數(shù)生成器生成加密所使用的對(duì)稱密鑰，然后用證書(shū)的公鑰加密這個(gè)對(duì)稱密鑰，發(fā)給Server。
5.Server使用自己的私鑰（private key）解密這個(gè)消息，得到對(duì)稱密鑰。至此，Client和Server雙方都持有了相同的對(duì)稱密鑰。
6.Server使用對(duì)稱密鑰加密“明文內(nèi)容A”，發(fā)送給Client。
7.Client使用對(duì)稱密鑰解密響應(yīng)的密文，得到“明文內(nèi)容A”。
8.Client再次發(fā)起HTTPS的請(qǐng)求，使用對(duì)稱密鑰加密請(qǐng)求的“明文內(nèi)容B”，然后Server使用對(duì)稱密鑰解密密文，得到“明文內(nèi)容B”。
小結(jié)：
https就是使用了非對(duì)稱加密(一對(duì)公私鑰進(jìn)行加密解密)進(jìn)行公鑰傳輸,然后客戶端通過(guò)公鑰加密將自己的私鑰發(fā)給服務(wù)端,以后就可以使用這個(gè)私鑰進(jìn)行消息的收發(fā)了
4. 常用的HTTP方法
GET：用于請(qǐng)求訪問(wèn)已經(jīng)被URI（統(tǒng)一資源標(biāo)識(shí)符）識(shí)別的資源，可以通過(guò)URL傳參給服務(wù)器
POST：用于傳輸信息給服務(wù)器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT： 傳輸文件，報(bào)文主體中包含文件內(nèi)容，保存到對(duì)應(yīng)URI位置。
HEAD： 獲得報(bào)文首部，與GET方法類似，只是不返回報(bào)文主體，一般用于驗(yàn)證URI是否有效。
DELETE：刪除文件，與PUT方法相反，刪除對(duì)應(yīng)URI位置的文件。
OPTIONS：查詢相應(yīng)URI支持的HTTP方法。
5.GET方法與POST方法的區(qū)別
- get重點(diǎn)在從服務(wù)器上獲取資源，post重點(diǎn)在向服務(wù)器發(fā)送數(shù)據(jù)
- get傳輸數(shù)據(jù)是通過(guò)URL請(qǐng)求，以field（字段）= value的形式，置于URL后，并用"?"連接，多個(gè)請(qǐng)求數(shù)據(jù)間用"&"連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個(gè)過(guò)程用戶是可見(jiàn)的；
post傳輸數(shù)據(jù)通過(guò)Http的post機(jī)制，將字段與對(duì)應(yīng)值封存在請(qǐng)求實(shí)體中發(fā)送給服務(wù)器，這個(gè)過(guò)程對(duì)用戶是不可見(jiàn)的； - Get傳輸?shù)臄?shù)據(jù)量小，因?yàn)槭躑RL長(zhǎng)度限制，但效率較高；1024k
Post可以傳輸大量數(shù)據(jù)，所以上傳文件時(shí)只能用Post方式； - get是不安全的，因?yàn)閁RL是可見(jiàn)的，可能會(huì)泄露私密信息，如密碼等；
post較get安全性較高； - get方式只能支持ASCII字符，向服務(wù)器傳的中文字符可能會(huì)亂碼。
post支持標(biāo)準(zhǔn)字符集，可以正確傳遞中文字符。
6.HTTP請(qǐng)求報(bào)文與響應(yīng)報(bào)文格式
請(qǐng)求報(bào)文
響應(yīng)報(bào)文
通用首部字段（請(qǐng)求報(bào)文與響應(yīng)報(bào)文都會(huì)使用的首部字段）
- Date：創(chuàng)建報(bào)文時(shí)間
- Connection：連接的管理
- Cache-Control：緩存的控制
- Transfer-Encoding：報(bào)文主體的傳輸編碼方式
請(qǐng)求首部字段（請(qǐng)求報(bào)文會(huì)使用的首部字段）
- Host：請(qǐng)求資源所在服務(wù)器
- Accept：可處理的媒體類型
- Accept-Charset：可接收的字符集
- Accept-Encoding：可接受的內(nèi)容編碼
- Accept-Language：可接受的自然語(yǔ)言
響應(yīng)首部字段（響應(yīng)報(bào)文會(huì)使用的首部字段）
- Accept-Ranges：可接受的字節(jié)范圍
- Location：令客戶端重新定向到的URI
- Server：HTTP服務(wù)器的安裝信息
實(shí)體首部字段（請(qǐng)求報(bào)文與響應(yīng)報(bào)文的的實(shí)體部分使用的首部字段）
- Allow：資源可支持的HTTP方法
- Content-Type：實(shí)體主類的類型
- Content-Encoding：實(shí)體主體適用的編碼方式
- Content-Language：實(shí)體主體的自然語(yǔ)言
- Content-Length：實(shí)體主體的的字節(jié)數(shù)
- Content-Range：實(shí)體主體的位置范圍，一般用于發(fā)出部分請(qǐng)求時(shí)使用
7. 常見(jiàn)的HTTP狀態(tài)碼
2xx : 代表服務(wù)端已經(jīng)成功接收并處理了該請(qǐng)求
200——服務(wù)器成功返回網(wǎng)頁(yè)
201——提示知道新文件的URL
202——接受和處理、但處理未完成
203——返回信息不確定或不完整
204——請(qǐng)求收到，但返回信息為空
205——服務(wù)器完成了請(qǐng)求，用戶代理必須復(fù)位當(dāng)前已經(jīng)瀏覽過(guò)的文件
206——服務(wù)器已經(jīng)完成了部分用戶的GET請(qǐng)求
3xx : 通常代表客戶端需要進(jìn)行進(jìn)一步請(qǐng)求用,常用來(lái)進(jìn)行重定向的狀態(tài)碼
300——請(qǐng)求的資源可在多處得到
301——?jiǎng)h除請(qǐng)求數(shù)據(jù)
302——在其他地址發(fā)現(xiàn)了請(qǐng)求數(shù)據(jù)
303——建議客戶訪問(wèn)其他URL或訪問(wèn)方式
304——客戶端已經(jīng)執(zhí)行了GET，但文件未變化
305——請(qǐng)求的資源必須從服務(wù)器指定的地址得到
306——前一版本HTTP中使用的代碼，現(xiàn)行版本中不再使用
307——申明請(qǐng)求的資源臨時(shí)性刪除
4xx : 通常表示客戶端請(qǐng)求有問(wèn)題
400——錯(cuò)誤請(qǐng)求，如語(yǔ)法錯(cuò)誤
401——請(qǐng)求授權(quán)失敗
402——保留有效ChargeTo頭響應(yīng)
403——請(qǐng)求不允許
404——請(qǐng)求的網(wǎng)頁(yè)不存在
5xx : 通常表示服務(wù)端內(nèi)部錯(cuò)誤
- 500 : 服務(wù)端代碼出錯(cuò)
- 502 : 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從上游服務(wù)器接收到無(wú)效的響應(yīng)
- 503: 服務(wù)器正在維護(hù)或者訪問(wèn)過(guò)載,過(guò)一段時(shí)間可能恢復(fù)正常
- 504 : 作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，未能及時(shí)從上游服務(wù)器（URI標(biāo)識(shí)出的服務(wù)器，例如HTTP、FTP、LDAP）或者輔助服務(wù)器（例如DNS）收到響應(yīng)
https://www.cnblogs.com/xflonga/p/9368993.html
8. 一個(gè)頁(yè)面從輸入 URL 到頁(yè)面加載顯示完成，這個(gè)過(guò)程中都發(fā)生了什么？
1. 地址欄輸入地址，瀏覽器自動(dòng)補(bǔ)全url，如果瀏覽器中有緩存且未過(guò)期直接使用緩存呈現(xiàn)頁(yè)面。
2. DNS解析：
查詢順序：瀏覽器緩存 > 系統(tǒng)緩存 > 路由器緩存 > ISP DNS緩存
如果緩存中沒(méi)有找到，就會(huì)向DNS服務(wù)器發(fā)送URL對(duì)應(yīng)IP查找域名
3. 客戶端與服務(wù)器進(jìn)行三次握手建立連接
“三次握手”的目的是“為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤”。
①客戶端先發(fā)送一個(gè)帶有SYN（synchronize）標(biāo)志的數(shù)據(jù)包給服務(wù)端，在一定的延遲時(shí)間內(nèi)等待服務(wù)端的回復(fù)。
②服務(wù)端收到數(shù)據(jù)包后，傳回一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包以示傳達(dá)確認(rèn)信息。
③客戶端收到后再發(fā)送一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包給接收端以示握手成功。
在這個(gè)過(guò)程中，如果發(fā)送端在規(guī)定延遲時(shí)間內(nèi)沒(méi)有收到回復(fù)則默認(rèn)接收方?jīng)]有收到請(qǐng)求，而再次發(fā)送，直到收到回復(fù)為止。
4. 瀏覽器向服務(wù)器發(fā)送http請(qǐng)求
5. 服務(wù)器收到請(qǐng)求，并從文檔空間中找到資源返回http響應(yīng)
6. 瀏覽器接受到http響應(yīng)，檢查http header 狀態(tài)碼，做出不同的處理方式
- 404顯示錯(cuò)誤頁(yè)面
- 304使用緩存
- 204頁(yè)面不會(huì)發(fā)生更新
- 200進(jìn)行下一步
- ...
7. 根據(jù)首部字段判斷是否啟用緩存
cache-control 可緩存
no-cache 每次使用緩存前跟服務(wù)器確認(rèn)
no-store 禁止緩存
8. 拿到index.html進(jìn)行解析成DOM樹(shù)，遇到靜態(tài)文件css，js，image 向服務(wù)器請(qǐng)求下載，解析成對(duì)應(yīng)的DOM樹(shù)，css樹(shù)，開(kāi)始布局繪制
為達(dá)到更好的用戶體驗(yàn)，呈現(xiàn)引擎會(huì)力求盡快將內(nèi)容顯示在屏幕上。它不必等到整個(gè) HTML 文檔解析完畢之后，就會(huì)開(kāi)始構(gòu)建呈現(xiàn)樹(shù)和設(shè)置布局。在不斷接收和處理來(lái)自網(wǎng)絡(luò)的其余內(nèi)容的同時(shí)，呈現(xiàn)引擎會(huì)將部分內(nèi)容解析并顯示出來(lái)
9. 客戶端與服務(wù)器四次揮手?jǐn)嚅_(kāi)連接
終止TCP連接，就是指斷開(kāi)一個(gè)TCP連接時(shí)，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開(kāi)
①客戶端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)傳送，客戶端進(jìn)入FIN_WAIT_1狀態(tài)。
②服務(wù)端收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），服務(wù)端進(jìn)入CLOSE_WAIT狀態(tài)。
③服務(wù)端發(fā)送一個(gè)FIN，用來(lái)關(guān)閉服務(wù)端到客戶端的數(shù)據(jù)傳送，服務(wù)端進(jìn)入LAST_ACK狀態(tài)。
④客戶端收到FIN后，客戶端進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給服務(wù)端，確認(rèn)序號(hào)為收到序號(hào)+1，服務(wù)端進(jìn)入CLOSED狀態(tài)，完成四次揮手。
9. HTTP優(yōu)化方案
- TCP復(fù)用：TCP連接復(fù)用是將多個(gè)客戶端的HTTP請(qǐng)求復(fù)用到一個(gè)服務(wù)器端TCP連接上，而HTTP復(fù)用則是一個(gè)客戶端的多個(gè)HTTP請(qǐng)求通過(guò)一個(gè)TCP連接進(jìn)行處理。前者是負(fù)載均衡設(shè)備的獨(dú)特功能；而后者是HTTP 1.1協(xié)議所支持的新功能，目前被大多數(shù)瀏覽器所支持。
- 內(nèi)容緩存：將經(jīng)常用到的內(nèi)容進(jìn)行緩存起來(lái)，那么客戶端就可以直接在內(nèi)存中獲取相應(yīng)的數(shù)據(jù)了。
- 壓縮：將文本數(shù)據(jù)進(jìn)行壓縮，減少帶寬
- SSL加速（SSL Acceleration）：使用SSL協(xié)議對(duì)HTTP協(xié)議進(jìn)行加密，在通道內(nèi)加密并加速
- TCP緩沖：通過(guò)采用TCP緩沖技術(shù)，可以提高服務(wù)器端響應(yīng)時(shí)間和處理效率，減少由于通信鏈路問(wèn)題給服務(wù)器造成的連接負(fù)擔(dān)。
9. localStorage. sessionStorage、 Cookie不同點(diǎn)
-
存儲(chǔ)大小的不同:
- localStorage的大小一般為5M
- sessionStorage的大小一般為5M
- cookies的大小一般為4K
-
有效期不同:
- localStorage的有效期為永久有效，除非你進(jìn)行手動(dòng)刪除。
- sessionStorage在當(dāng)前會(huì)話下有效，關(guān)閉頁(yè)面或者瀏覽器時(shí)會(huì)被清空。
- cookies在設(shè)置的有效之前有效，當(dāng)超過(guò)有效期便會(huì)失效。
-
與服務(wù)器端的通信
- localStorage不參與服務(wù)器端的通信
- sessionStorage不參與服務(wù)器端的通信。
- cookies參與服務(wù)器端通信，每次都會(huì)存在http的頭信息中。(如果使用cookie保存過(guò)多數(shù)據(jù)會(huì)帶來(lái)性能問(wèn)題)
-
localStorage和sessionStorage的作用域的區(qū)別詳解
- 不同瀏覽器無(wú)法共享localStorage或sessionStorage中的信息。
- 相同瀏覽器的不同頁(yè)面間可以共享相同的localStorage (頁(yè)面屬于相同域名和端口)， 但是不同頁(yè)面或標(biāo)簽頁(yè)間無(wú)法共享sessionStorage的信息。
11. get和post請(qǐng)求在緩存方面的區(qū)別
- get請(qǐng)求類似于查找的過(guò)程，用戶獲取數(shù)據(jù)，可以不用每次都與數(shù)據(jù)庫(kù)連接，所以可以使用緩存。
- post不同，post做的一般是修改和刪除的工作，所以必須與數(shù)據(jù)庫(kù)交互，所以不能使用緩存。因此get請(qǐng)求適合于請(qǐng)求緩存。
12. cookie session區(qū)別
cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。
cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙
考慮到安全應(yīng)當(dāng)使用session。session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問(wèn)增多，會(huì)比較占用你服務(wù)器的性能
考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE。單個(gè)cookie保存的數(shù)據(jù)不能超過(guò)4K，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie。
13. cookie屬性
拓展https://www.chinaz.com/web/2012/0905/272814.shtml
httponly http://blog.itpub.net/31556438/viewspace-2557286/
samesite屬性http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html
14. https詳細(xì)過(guò)程
15. TCP擁塞控制
16. TCP和UDP
https://blog.csdn.net/weixin_42092787/article/details/107668987
17. 兩個(gè)不同tab頁(yè)面之間如何請(qǐng)求交互
18. tcp鏈接為什么不能為兩次握手
19. tcp攻擊與防范
20. 301和302狀態(tài)碼
21. http2.0頭部壓縮
22. TCP的三次握手和四次揮手，為什么不是兩次握手？為什么揮手多一次呢
23. 網(wǎng)絡(luò)中的ACK； SYN； FIN都是什么
- SYN表示建立連接，
- FIN表示關(guān)閉連接，
- ACK表示響應(yīng)
第一次握手：主機(jī)A發(fā)送位碼為syn＝1，隨機(jī)產(chǎn)生seq number=1234567的數(shù)據(jù)包到服務(wù)器，主機(jī)B由SYN=1知道，A要求建立聯(lián)機(jī)；
第二次握手：主機(jī)B收到請(qǐng)求后要確認(rèn)聯(lián)機(jī)信息，向A發(fā)送ack number=(主機(jī)A的seq+1)，syn=1，ack=1，隨機(jī)產(chǎn)生seq=7654321的包；
第三次握手：主機(jī)A收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1，以及位碼ack是否為1，若正確，主機(jī)A會(huì)再發(fā)送ack number=(主機(jī)B的seq+1)，ack=1，主機(jī)B收到后確認(rèn)seq值與ack=1則連接建立成功。 完成三次握手，主機(jī)A與主機(jī)B開(kāi)始傳送數(shù)據(jù)。
24. http瀏覽器緩存機(jī)制
25. 304狀態(tài)碼
200表示成功，服務(wù)器已成功處理了請(qǐng)求，通常表示為服務(wù)器提供了請(qǐng)求的網(wǎng)頁(yè)，304表示未修改，自從上次請(qǐng)求后，請(qǐng)求的網(wǎng)頁(yè)未修改過(guò)，服務(wù)器返回此響應(yīng)時(shí)不會(huì)返回網(wǎng)頁(yè)內(nèi)容
https://blog.csdn.net/huwei2003/article/details/70139062?utm_term=304%E7%8A%B6%E6%80%81%E7%A0%81%E6%98%AF%E4%BB%80%E4%B9%88&utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2allsobaiduweb~default-0-70139062&spm=3001.4430
26. 500狀態(tài)碼具體場(chǎng)景
http://www.xusseo.com/seoswgwsm/77367.html
27. DNS原理
https://www.cnblogs.com/gopark/p/8430916.html
28. CND原理
CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。CDN的基本原理是廣泛采用各種緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問(wèn)相對(duì)集中的地區(qū)或網(wǎng)絡(luò)中，在用戶訪問(wèn)網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)將用戶的訪問(wèn)指向距離最近的工作正常的緩存服務(wù)器上，由緩存服務(wù)器直接響
https://blog.csdn.net/xiangzhihong8/article/details/83147542
29. osi七層模型每層分別是什么，http在哪層，tcp在哪層
https://blog.csdn.net/weixin_42092787/article/details/107632967
30. HTTP協(xié)議的ETag
31. head和get的區(qū)別
32. *ssl握手過(guò)程，非對(duì)稱加密和對(duì)稱加密的區(qū)別
https://blog.csdn.net/qq_29689487/article/details/81634057
33. *前端緩存
34. 滑動(dòng)窗口
35. 前端安全
https://www.cnblogs.com/zhiying/p/11018331.html
XSS攻擊
DOS攻擊
https://blog.csdn.net/fengyinchao/article/details/52303118
sql注入
dos注入
36. 計(jì)算機(jī)網(wǎng)絡(luò)的五層協(xié)議
37. HTTPS為什么要使用一個(gè)對(duì)稱加密和非對(duì)稱加密相結(jié)合
38. 一文讀懂http緩存（超詳細(xì)）
39.Http與Https的基本概念和他們的區(qū)別
http的中文叫做超文本傳輸協(xié)議,它負(fù)責(zé)完成客戶端到服務(wù)端的一系列操作,是專門用來(lái)傳輸注入HTML的超媒體文檔等web內(nèi)容的協(xié)議,它是基于傳輸層的TCP協(xié)議的應(yīng)用層協(xié)議
https:https是基于安全套接字的http協(xié)議,也可以理解為是http+ssl/tls(數(shù)字證書(shū))的組合
http和https的區(qū)別:
- HTTP 的 URL 以 http:// 開(kāi)頭，而 HTTPS 的 URL 以 https:// 開(kāi)頭
- HTTP 是不安全的，而 HTTPS 是安全的
- HTTP 標(biāo)準(zhǔn)端口是 80 ，而 HTTPS 的標(biāo)準(zhǔn)端口是 443
- 在 OSI 網(wǎng)絡(luò)模型中，HTTPS的加密是在傳輸層完成的,因?yàn)镾SL是位于傳輸層的,TLS的前身是SSL,所以同理
- HTTP無(wú)需認(rèn)證證書(shū),而https需要認(rèn)證證書(shū)
小結(jié)：簡(jiǎn)單來(lái)說(shuō)http是用來(lái)進(jìn)行html等超媒體傳輸?shù)?但是http不安全,為了安全,使用證書(shū)SSL和HTTP的方式進(jìn)行數(shù)據(jù)傳輸,也就是HTTPS
40. TCP粘包
41. DNS解析過(guò)程
DNS根域名
由于 ICANN 管理著所有的頂級(jí)域名，所以它是最高一級(jí)的域名節(jié)點(diǎn)，被稱為根域名（root domain）。在有些場(chǎng)合，www.example.com 被寫成www.example.com. ，即最后還會(huì)多出一個(gè)點(diǎn)。這個(gè)點(diǎn)就是根域名。
理論上，所有域名查詢都必須先查詢根域名，因?yàn)橹挥懈蛎拍芨嬖V你，某個(gè)頂級(jí)域名由哪臺(tái)服務(wù)器管理。事實(shí)上也確實(shí)如此，ICANN 維護(hù)著一張列表，里面記載著頂級(jí)域名和對(duì)應(yīng)的托管商。
比如，我要訪問(wèn)www.example.com ，就必須先詢問(wèn) ICANN 的根域名列表，它會(huì)告訴我.com域名由 Verisign 托管，我必須去找 Verisign，它會(huì)告訴我example.com服務(wù)器在哪里。
再比如，我要訪問(wèn)abc.xyz，也必須先去詢問(wèn)根域名列表，它會(huì)告訴我.xyz域名由 CentralNic 公司托管。根域名列表還記載，.google由谷歌公司托管，.apple由蘋果公司托管等等。
由于根域名列表很少變化，大多數(shù) DNS 服務(wù)商都會(huì)提供它的緩存，所以根域名的查詢事實(shí)上不是那么頻繁。
保存 DNS 根區(qū)文件的服務(wù)器，就叫做 DNS 根域名服務(wù)器（root name server）。
1、在瀏覽器中輸入www.qq.com域名，操作系統(tǒng)會(huì)先檢查自己本地的hosts文件是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，就先調(diào)用這個(gè)IP地址映射，完成域名解析。
2、如果hosts里沒(méi)有這個(gè)域名的映射，則查找本地DNS解析器緩存，是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，直接返回，完成域名解析。
3、如果hosts與本地DNS解析器緩存都沒(méi)有相應(yīng)的網(wǎng)址映射關(guān)系，首先會(huì)找TCP/ip參數(shù)中設(shè)置的首選DNS服務(wù)器，在此我們叫它本地DNS服務(wù)器，此服務(wù)器收到查詢時(shí)，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性。
4、如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè)IP地址映射，完成域名解析，此解析不具有權(quán)威性。
5、如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進(jìn)行查詢，如果未用轉(zhuǎn)發(fā)模式，本地DNS就把請(qǐng)求發(fā)至13臺(tái)根DNS，根DNS服務(wù)器收到請(qǐng)求后會(huì)判斷這個(gè)域名(.com)是誰(shuí)來(lái)授權(quán)管理，并會(huì)返回一個(gè)負(fù)責(zé)該頂級(jí)域名服務(wù)器的一個(gè)IP。本地DNS服務(wù)器收到IP信息后，將會(huì)聯(lián)系負(fù)責(zé).com域的這臺(tái)服務(wù)器。這臺(tái)負(fù)責(zé).com域的服務(wù)器收到請(qǐng)求后，如果自己無(wú)法解析，它就會(huì)找一個(gè)管理.com域的下一級(jí)DNS服務(wù)器地址(qq.com)給本地DNS服務(wù)器。當(dāng)本地DNS服務(wù)器收到這個(gè)地址后，就會(huì)找qq.com域服務(wù)器，重復(fù)上面的動(dòng)作，進(jìn)行查詢，直至找到www.qq.com主機(jī)。
6、如果用的是轉(zhuǎn)發(fā)模式，此DNS服務(wù)器就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)至上一級(jí)DNS服務(wù)器，由上一級(jí)服務(wù)器進(jìn)行解析，上一級(jí)服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)請(qǐng)求轉(zhuǎn)至上上級(jí)，以此循環(huán)。不管是本地DNS服務(wù)器用是是轉(zhuǎn)發(fā)，還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器再返回給客戶機(jī)。
從客戶端到本地DNS服務(wù)器是屬于遞歸查詢，而DNS服務(wù)器之間就是的交互查詢就是迭代查詢。
