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