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