有以下幾個場景說明瀏覽器與客戶端通信過程
1.瀏覽器上輸入url之后發(fā)生了什么？
①url解析
②獲取ip地址
③建立tcp連接
④發(fā)送http請求
⑤返回http響應(yīng)
⑥建立dom樹和cssdom樹，進行頁面渲染
⑦斷開或者保持連接
這六個點都是一個知識點呀
url解析
判斷是輸入了待搜索的關(guān)鍵字還是url。根據(jù)輸入的內(nèi)容進行自動編碼，補全等工作。還有一些安全性檢查
重大問題！判斷緩存是在哪一步的呢？
對于比較強緩存來說，他是在dns查詢之前，但是協(xié)商緩存就在dns解析之后了
①向服務(wù)器請求之前先查看本地是否有緩存，沒有就直接請求客戶端資源
②有緩存，比較是否命中強緩存
通過比較cache-control：max-age（這個時間是客戶端的相對時間）
或者expires+last-modified(這個時間是服務(wù)端資源失效的絕對時間，所以需要和last-modified比較)
優(yōu)先級cache-control比expires-modified要高
有強緩存則不會發(fā)送http請求了
③沒有命中強緩存但是有協(xié)商緩存，就會發(fā)送get請求帶上一些cookies信息（
if-modified-since和if-None-Match）然后服務(wù)端進行通過比較Etag和if-None-Match,last-modified和if-modified-since進行決策，并返回last-modified和Etag這兩個字段，和狀態(tài)碼。如果Etag=if-None-Match并且if-modified-since>=last-modified那么會返回304，否則返回200
返回304就意味著可以直接使用本地緩存，服務(wù)器不會繼續(xù)發(fā)送這個資源
返回200意味緩存資源已經(jīng)被修改，需要重新向服務(wù)器請求該資源
服務(wù)器會優(yōu)先驗證ETag，一致的情況下，才會繼續(xù)比對Last-Modified，最后才決定是否返回304。
使用last-modified和Etag組合判斷資源是否被修改的意義？
①如果是在一秒內(nèi)多次修改資源，last-modified和last-modified-since不能準確標注資源修改時間，所有要有
etag和if-none-match
②一些動態(tài)內(nèi)容的生成，實際上資源沒變但是修改時間會發(fā)生變化，導(dǎo)致不能使用緩存
③一些圖片等靜態(tài)文件的修改，如果每次掃描內(nèi)容生成 ETag 來比較，顯然要比直接比較last-modified和last-modified-since慢很多
域名解析詳細：
①先看本地客戶端是否有這個域名緩存，未找到
②操作系統(tǒng)DNS緩存
③查詢本地域名服務(wù)器（一般成功率在80%）
④第③步查找失敗就發(fā)起一個迭代的dns請求
迭代的dns請求？？
本地域名服務(wù)器向根域名服務(wù)器（com,org,net等）發(fā)起請求，返回com域名服務(wù)器地址。
本地域名服務(wù)器向com域的頂級服務(wù)器發(fā)起請求，返回baidu.com域名服務(wù)器地址
本地域名服務(wù)器向baidu.com域名服務(wù)器，返回www.baidu.com的ip地址，返回給操作系統(tǒng)，同時緩存起來。
操作系統(tǒng)返回ip給瀏覽器，同時自身緩存起來
從客戶端到本地DNS服務(wù)器是屬于遞歸查詢，而DNS服務(wù)器之間就是的交互查詢就是迭代查詢。
渲染頁面過程
①解析html文檔，生成dom樹（不可見元素，注釋，script標簽內(nèi)容都會在dom樹中）
②解析css文件，生成css dom樹。CSS解析可以與DOM解析同進行。
③生成Render Tree。display:none元素不在Render Tree，visbility:hidden元素還在Render Tree里
④Render Tree布局。進行元素在屏幕的大小，位置的確定
float元素，absoulte元素，fixed元素會發(fā)生位置偏移
我們常說的脫離文檔流，其實就是脫離Render Tree
⑤Render Tree繪制
在繪制階段，瀏覽器會遍歷渲染樹，調(diào)用渲染器的paint()方法在屏幕上顯示其內(nèi)容
幾個注意點：
- 當(dāng)我們?yōu)g覽器獲得HTML文件后，會自上而下的加載，并在加載過程中進行解析和渲染。
- 加載說的就是獲取資源文件的過程，如果在加載過程中遇到外部CSS文件和圖片，瀏覽器會另外發(fā)送一個請求，去獲取CSS文件和相應(yīng)的圖片，這個請求是異步的，并不會影響HTML文件的加載。
- css解析不會阻礙dom解析，但是會阻礙瀏覽器渲染。這是為了性能和用戶體驗，要盡量減少渲染的次數(shù)，防止渲染之后又重新渲染更新
為什么js文件不能放在css文件之前進行解析?
但是如果遇到Javascript文件，HTML文件會掛起渲染的進程，等待JavaScript文件加載完畢后，再繼續(xù)進行渲染。
為什么HTML需要等待JavaScript呢？
因為JavaScript可能會修改DOM，導(dǎo)致后續(xù)HTML資源白白加載，所以HTML必須等待JavaScript文件加載完畢后，再繼續(xù)渲染，這也就是為什么JavaScript文件在寫在底部body標簽前的原因。
為什么要先解析css文件？
放在頭部，瀏覽器進行一部分渲染，減少白屏?xí)r間
如果放在底部的話，引發(fā)了回流，會有閃屏這種不好的體驗
2.用戶登錄過程
① 用戶輸入賬號密碼之后。登陸成功則服務(wù)器會返回setCookies字段，要求客戶端保存cookies信息。setCookies字段包括了登錄賬號密碼信息，domain，expires等信息。
②下一次登錄，瀏覽器就會自動帶上cookies信息
但是出于安全性的考慮，我們不會真的把賬戶密碼信息放在cookie，因為這樣每次登陸都要把賬號密碼信息傳送一次，這是十分不安全的。
所以現(xiàn)在一般返回senssionId代替登錄賬號密碼信息，第一次登陸成功，服務(wù)器會生成一個session，然后經(jīng)過加密生成了sessionId字段，通過cookie發(fā)回給客戶端，下次訪問的時候，帶上這個sessionId，服務(wù)器收到以后們就會解密，并且和session相比較。
如果瀏覽器禁用了cookie/不支持cookie，可以通過URL重寫的方式發(fā)送到服務(wù)。
這個時候，通過sessionId通信的弊端也產(chǎn)生了。這需要在服務(wù)端產(chǎn)生并保存每一個人的session，耗費了服務(wù)器的空間。同時當(dāng)服務(wù)器集群的時候，也很不好搞。于是新技術(shù)JSON Web Token（簡稱：JWT）（下文使用token代替）就產(chǎn)生了，他相當(dāng)于一個令牌，持有這個令牌就給予通過。這樣避免了頻繁去查詢賬號密碼表。
token的結(jié)構(gòu)包括了下面三部分，他們使用.隔開
Header（頭部）
Payload（負載）
Signature（簽名）
header：是這樣一個json對象，alg代表加密的算法，生成這個對象之后，使用base64Url轉(zhuǎn)化為字符串，typ屬性表示這個令牌（token）的類型（type）
{
"alg": "HS256",
"typ": "JWT"
}
Payload：也是一個json對象，用來存放實際的數(shù)據(jù)。比如：
過期時間等等信息
同樣使用使用base64Url進行加密
Signature通過一個密鑰（只有服務(wù)器知道）和header指定的簽名算法生成一個簽名（生成內(nèi)容也和Header、Payload內(nèi)容有關(guān)）
拼接好Header、Payload、Signature形成token然后發(fā)回給用戶
這個token 服務(wù)器不保存， 當(dāng)用戶把這個token 給服務(wù)器發(fā)過來的時候，服務(wù)器再用同樣的HMAC-SHA256 算法和同樣的密鑰，對數(shù)據(jù)再計算一次簽名， 和token 中的簽名做個比較， 如果相同， 我就知道小F已經(jīng)登錄過了，并且可以直接取到小F的user id , 如果不相同， 數(shù)據(jù)部分肯定被人篡改過， 我就告訴發(fā)送者： 對不起，沒有認證。
過程：
服務(wù)端只是生成token，驗證token，不會存儲token。使用簽名認證避免了別人惡意拼接獲取token，這樣就會安全許多
token最好放在請求頭的Authorization字段里面，因為放在cookies里面不能跨域
說到這里，不免要提一下refer。refer字段保存請求源的url，其實現(xiàn)在已經(jīng)有手段可以改變refer了，所以也不夠安全
https://segmentfault.com/a/1190000014527692?utm_source=tag-newest
