html面试题
HTTP
請求報文由請求行(request line)、請求頭(header)、請求體三個部分組成,即URI + header + body
基本請求類型: HEAD , GET , POST
三次握手和四次揮手:
基本請求和復雜請求
簡單請求
滿足一下兩個條件的請求。
請求方法是以下三種方法之一:
HEAD
GET
POST
HTTP的頭信息不超出以下幾種字段:
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type:只限于三個值application/x-www-form-urlencoded、multipart/form-data、text/plain
復雜請求:
非簡單請求就是復雜請求。
復雜請求在正式請求前都會有預檢請求,在瀏覽器中都能看到有OPTIONS請求,用于向服務器請求權限信息的。
axios 都是復雜請求,ajax 可以是簡單請求
HTTPS建立過程:
瀏覽器請求服務器:瀏覽器去到DNS服務器獲取此url對應的ip,然后客戶端連接上服務端的443端口,將此請求發送給到服務端,此時客戶端同時將自己支持的加密算法帶給服務端;
服務端收到這套加密算法的時候,和自己支持的加密算法進行對比(也就是和自己的私鑰進行對比),如果不符合,就斷開連接;如果符合,服務端就將SSL證書發送給客戶端,此證書中包括了數字證書包含的內容:1、證書頒發機構;2、使用機構;3、公鑰;4、有效期;5、簽名算法;6、指紋算法;7、指紋。
客戶端驗證服務端發來的證書,并回傳信息:
驗證證書
生成隨機數(此隨機數就是后面用的對稱加密的私鑰):此隨機數只有服務端的私鑰能解開了、
生成握手信息:生成hash值,目的是確保傳輸過程中信息不被篡改
服務端接收隨機數加密的信息,并解密得到隨機數,驗證握手信息是否被篡改。
客戶端驗證服務端發送回來的握手信息,完成握手
客戶端收到服務端發送過來的握手信息后,用開始自己生成的隨機數進行解密,驗證被隨機數加密的握手信息和握手信息hash值。
驗證無誤后,握手過程就完成了,從此服務端和客戶端就開始用那串隨機數進行對稱加密通信了(常用的對稱加密算法有AES)。
HTTP2
http2新特性總結:這里是參考
響應多路復用,請求信息和相應信息復用同一個TCP鏈接
頭部的壓縮頭部域來減小頭部的體積,
添加了請求優先級, 讓更重要的請求更早的完成
服務端推送.
Specifically, it allows interleaving of request and response messages on the same connection and uses an efficient coding for HTTP header fields.
底層原理
與http1.0采用ASCII報文傳輸信息不同的是,2.0采用了二進制frame
采用流的方式進行多路復用
每個流都有對應的優先級,優先級高的先分配資源
一個典型的Web應用程序由幾十個資源組成,所有這些資源都是客戶端通過檢查服務器提供的文檔發現的。因此,為什么不消除額外的延遲并讓服務器提前推送相關資源?服務器已經知道客戶端需要哪些資源;這是服務器推動。
優點:快!減少了TCP連接,同時也提高了HTTPS的性能,因為僅需要更少的TLS層的握手.
HTML語意化標簽的好處
為了在沒有CSS的情況下,頁面也能呈現出很好地內容結構、代碼結構:為了裸奔時好看;
用戶體驗:例如title、alt用于解釋名詞或解釋圖片信息、label標簽的活用;
有利于SEO:和搜索引擎建立良好溝通,有助于爬蟲抓取更多的有效信息:爬蟲依賴于標簽來確定上下文和各個關鍵字的權重;
方便其他設備解析(如屏幕閱讀器、盲人閱讀器、移動設備)以意義的方式來渲染網頁;
便于團隊開發和維護,語義化更具可讀性,是下一步吧網頁的重要動向,遵循W3C標準的團隊都遵循這個標準,可以減少差異化。
post請求發送數據的幾種類型
默認post數據類型 -- Content-Type: application/x-www-form-urlencoded
這個類型是我們使用ajax請求或者 curl 等工具的默認post數據類型。
除非使用curl -H 'Content-Type:application/json'等方式聲明類型。
瀏覽器的原生 form 表單,如果不設置 enctype 屬性,那么最終就會以 application/x-www-form-urlencoded 方式提交數據。
Content-Type: application/json
使用最廣
Content-Type: multipart/form-data
此類型一般用來發送文件/圖片,不同part會有各自的content-type,有各自的編碼類型
Content-Type: text/xml
http緩存
瀏覽器緩存分為強緩存和協商緩存,瀏覽器加載一個頁面的簡單流程如下:
瀏覽器先根據這個資源的http頭信息來判斷是否命中強緩存。如果命中則直接加在緩存中的資源,并不會將請求發送到服務器。
如果未命中強緩存,則瀏覽器會將資源加載請求發送到服務器。服務器來判斷瀏覽器本地緩存是否失效。若可以使用,則服務器并不會返回資源信息(而是304),瀏覽器繼續從緩存加載資源。
如果未命中協商緩存,則服務器會將完整的資源返回給瀏覽器,瀏覽器加載新資源,并更新緩存。
命中強緩存時,瀏覽器并不會將請求發送給服務器。在Chrome的開發者工具中看到http的返回碼是200,但是在Size列會顯示為(from cache)。
詳細來講:
是否命中強緩存:
強緩存是利用http的返回頭中的Expires或者Cache-Control兩個字段來控制的,用來表示資源的緩存時間。cache-control的優先級更高。Expire是絕對時間(容易產生客戶端和服務器時間不一致問題),Cache-Control是一個相對時間,單位是秒
當未命中強緩存,需要發送請求到服務器,進行協商緩存。具體來講,服務器根據http頭信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match來判斷是否命中協商緩存。如果命中,則http返回碼為304,瀏覽器從緩存中加載資源。
Last-Modify/If-Modify-Since
瀏覽器第一次請求一個資源的時候,服務器返回的header中會加上Last-Modify,Last-modify是一個時間標識該資源的最后修改時間。當瀏覽器再次請求該資源時,發送的請求頭中會包含If-Modify-Since,該值為緩存之前返回的Last-Modify。服務器收到If-Modify-Since后,根據資源的最后修改時間判斷是否命中緩存。
ETag/If-None-Match
與Last-Modify/If-Modify-Since不同的是,Etag/If-None-Match返回的是一個校驗碼(ETag: entity tag)。ETag可以保證每一個資源是唯一的,資源變化都會導致ETag變化
⚠️ 瀏覽器緩存行為還有用戶的行為有關!!!
| 用戶操作 | Expires/Cache-Control | Last-Modified/Etag |
|---|---|---|
| 地址欄回車 | 有效 | 有效 |
| 頁面鏈接跳轉 | 有效 | 有效 |
| 新開窗口 | 有效 | 有效 |
| 前進、后退 | 有效 | 有效 |
| F5****刷新 | 無效 | 有效 |
| Ctrl+F5****刷新 | 無效 | 無效 |
t c p/ip的四個層次
網絡接口層、網絡層、傳輸層、應用層
OSI
七層模型:應用層(HTTP、STMP)、表示層(壓縮與解縮)、會話層(SSL、TLS)、傳輸層(TCP、UDP)、網絡層(IP、ICMP)、數據鏈路層(ARP、網卡)、物理層
網卡實現的主要功能在于: 物理層和數據鏈路層
總結
- 上一篇: Python基于nginx访问日志并统计
- 下一篇: JavaScript解析Json字符串