1.localStorage和sessionStorage
共同點(diǎn)：二者都是以key-value的鍵值對方式存儲在瀏覽器端，大小大概在5M。
區(qū)別：
（1）數(shù)據(jù)有效期不同：sessionStorage僅在當(dāng)前瀏覽器窗口關(guān)閉之前有效；localStorage始終有效，窗口或瀏覽器關(guān)閉也一直保存，因此用作持久數(shù)據(jù)；
（2）作用域不同：sessionStorage數(shù)據(jù)只能在同一個域的同一頁面使用；localstorage在所有同源窗口中都是共享的，用在多窗口（頁面）共享數(shù)據(jù)。需要注意的頁面僅指頂級窗口，如果一個頁面包含多個iframe且他們屬于同源頁面，那么他們之間可以共享sessionStorage。
（3）使用場景：localStoragese常用于長期登錄（+判斷用戶是否已登錄），適合長期保存在本地的數(shù)據(jù)。sessionStorage敏感賬號一次性登錄。
2.cookie、session、localStorage和sessionStorage
會話（Session）跟蹤是Web程序中常用的技術(shù)，用來跟蹤用戶的整個會話。常用的會話跟蹤技術(shù)是Cookie與Session。Cookie通過在客戶端記錄信息確定用戶身份，Session通過在服務(wù)器端記錄信息確定用戶身份。
（1）存放位置不同：Cookie、localStorage、sessionStroge保存在客戶端，Session保存在服務(wù)端。
（2）存儲大小限制不同：cookie數(shù)據(jù)不能超過4K，同時因為每次http請求都會攜帶cookie、所以cookie只適合保存很小的數(shù)據(jù)，如會話標(biāo)識。Session一般情況下沒有上限，不過建議不要存放太多東西，否則影響性能；sessionStorage和localStorage雖然也有存儲大小的限制，但比cookie大得多，可以達(dá)到5M或更大?
（3）數(shù)據(jù)共享/作用域不同：cookie?localStorage?sessionStorage數(shù)據(jù)遵循同源原則；?SessionStorage還限制必須是同一個頁面。
（4）數(shù)據(jù)有效期不同：cookie：只在設(shè)置的cookie過期時間之前有效，即使窗口關(guān)閉或瀏覽器關(guān)閉?；由于Session依賴于名為JSESSIONID的Cookie，而Cookie?JSESSIONID的過期時間默許為–1，只需關(guān)閉了瀏覽器（一次會話結(jié)束），該Session就會失效；sessionStorage：僅在當(dāng)前瀏覽器窗口關(guān)閉之前有效；localStorage：始終有效，窗口或瀏覽器關(guān)閉也一直保存，因此用作持久數(shù)據(jù)；
（5）安全性（隱私策略）不同?：Cookie存儲在瀏覽器中，對客戶端是可見的，客戶端的一些程序可能會窺探、復(fù)制以至修正Cookie中的內(nèi)容。而Session存儲在服務(wù)器上，對客戶端是透明的，不存在敏感信息泄露的風(fēng)險。?假如選用Cookie，比較好的方法是，敏感的信息如賬號密碼等盡量不要寫到Cookie中。Cookie信息最好加密，提交到服務(wù)器后再進(jìn)行解密。而假如選擇Session就省事多了，反正是放在服務(wù)器上，Session里任何隱私都能夠有效的保護(hù)。
（6）對服務(wù)器造成的壓力不同?：Cookie保管在客戶端，不占用服務(wù)器資源。假如并發(fā)閱讀的用戶十分多，Cookie是很好的選擇。Session是保管在服務(wù)器端的，每個用戶都會產(chǎn)生一個Session。假如并發(fā)訪問的用戶十分多，會產(chǎn)生十分多的Session，耗費(fèi)大量的內(nèi)存。
（7）是否參與http通信：cookie和session都是參與服務(wù)器通信的，而localStorage和sessionStorage不參與服務(wù)器通信。
（8）web?Storage支持事件通知機(jī)制，可以將數(shù)據(jù)更新的通知發(fā)送給監(jiān)聽者。
（9）web?Storage的api接口使用更方便，localStorage，?sessionStorage有現(xiàn)成的API，?cookie需要程序員手動封裝，Web?Storage擁有setItem,getItem等方法，cookie需要前端開發(fā)者自己封裝setCookie，getCookie
3.常用瀏覽器內(nèi)核
- IE瀏覽器內(nèi)核：Trident內(nèi)核，也是俗稱的IE內(nèi)核；
- Chrome瀏覽器內(nèi)核：統(tǒng)稱為Chromium內(nèi)核或Chrome內(nèi)核，以前是Webkit內(nèi)核，現(xiàn)在是Blink內(nèi)核；
- Firefox瀏覽器內(nèi)核：Gecko內(nèi)核，俗稱Firefox內(nèi)核；
- Safari瀏覽器內(nèi)核：Webkit內(nèi)核；
- Opera瀏覽器內(nèi)核：最初是自己的Presto內(nèi)核，后來是Webkit，現(xiàn)在是Blink內(nèi)核；
- 360瀏覽器、獵豹瀏覽器內(nèi)核：IE+Chrome雙內(nèi)核；
- 搜狗、遨游、QQ瀏覽器內(nèi)核：Trident（兼容模式）+Webkit（高速模式）。
4.對瀏覽器內(nèi)核的理解
主要分成兩部分：渲染引擎(layout?engineer或Rendering?Engine)和JS引擎。
渲染引擎：負(fù)責(zé)取得網(wǎng)頁的內(nèi)容（HTML、XML、圖像等等）、整理訊息（例如加入CSS等），以及計算網(wǎng)頁的顯示方式，然后會輸出至顯示器或打印機(jī)。
瀏覽器的內(nèi)核的不同對于網(wǎng)頁的語法解釋會有不同，所以渲染的效果也不相同。所有網(wǎng)頁瀏覽器、電子郵件客戶端以及其它需要編輯、顯示網(wǎng)絡(luò)內(nèi)容的應(yīng)用程序都需要內(nèi)核。
JS引擎：解析和執(zhí)行javascript來實現(xiàn)網(wǎng)頁的動態(tài)效果。
最開始渲染引擎和JS引擎并沒有區(qū)分的很明確，后來JS引擎越來越獨(dú)立，內(nèi)核就傾向于只指渲染引擎。
5.瀏覽器緩存機(jī)制
緩存可以顯著減少網(wǎng)絡(luò)傳輸所帶來的損耗，是性能優(yōu)化中簡單高效的一種優(yōu)化方式。
對于一個數(shù)據(jù)請求來說，可以分為發(fā)起網(wǎng)絡(luò)請求、后端處理、瀏覽器響應(yīng)三個步驟。瀏覽器緩存可以幫助我們在第一和第三步驟中優(yōu)化性能。比如說直接使用緩存而不發(fā)起請求，或者發(fā)起了請求但后端存儲的數(shù)據(jù)和前端一致，那么就沒有必要再將數(shù)據(jù)回傳回來，這樣就減少了響應(yīng)數(shù)據(jù)。
從緩存位置上來說分為四種，并且各自有優(yōu)先級，當(dāng)依次查找緩存且都沒有命中的時候，才會去請求網(wǎng)絡(luò)
（Service?Worker-》Memory?Cache-》Disk?Cache-》Push?Cache）-》網(wǎng)絡(luò)請求
通常瀏覽器緩存策略分為兩種：強(qiáng)緩存和協(xié)商緩存，并且緩存策略都是通過設(shè)置?HTTP?Header?來實現(xiàn)的。
6.http緩存
http---HTTP緩存_http緩存csdn-CSDN博客
HTTP?緩存是web性能優(yōu)化的重要手段，通過復(fù)用緩存資源，減少了服務(wù)器和客戶端的通信次數(shù)，降低網(wǎng)絡(luò)延遲，加速頁面加載，降低服務(wù)器端的壓力。顯著提升網(wǎng)站和應(yīng)用的性能，提高用戶體驗。缺點(diǎn)：占內(nèi)存。
http緩存主要是針對html，css，img等靜態(tài)資源，常規(guī)情況下，我們不太會去緩存一些動態(tài)資源，因為緩存動態(tài)資源的話，數(shù)據(jù)的實時性就不能保證，所以我們一般都只會去緩存一些不太容易被改變的靜態(tài)資源。
HTTP?緩存策略分為兩種：強(qiáng)緩存和協(xié)商緩存?，優(yōu)先級:?強(qiáng)緩存?>?協(xié)商緩存
強(qiáng)緩存：強(qiáng)緩存即強(qiáng)制直接使用緩存 Exipres，Cache-Control
cache-control是expires的完全替代方案，在可以使用cache-control的情況下就不要使用expires
強(qiáng)緩存不會向服務(wù)器發(fā)送請求，直接從緩存中讀取資源，狀態(tài)碼200，并且size顯示from?disk?cache或from?memory?cache；
Expires:new?Date("2023-2-2?23:59:59")；設(shè)置一個過期時間（服務(wù)器端返回，在響應(yīng)頭中攜帶該參數(shù)），存在問題：本地時間和服務(wù)器時間不同步的問題.
Cache-control:max-age=N,N就是需要緩存的秒數(shù)（服務(wù)器端返回，在響應(yīng)頭中攜帶該參數(shù)）。從第一次請求資源的時候開始，往后N秒內(nèi)，資源若再次請求，則直接從磁盤（或內(nèi)存）中讀取，不與服務(wù)器做任何交互。
協(xié)商緩存：協(xié)商緩存就得和服務(wù)器協(xié)商確認(rèn)下這個緩存能不能用。?Last-Modified?/?If-Modified-Since，?Etag?/If-None-Match
ETag并不是last-modified的完全替代方案，而是補(bǔ)充方案，具體用哪一個，取決于項目業(yè)務(wù)場景，無孰好孰壞之分
協(xié)商緩存會先向服務(wù)器發(fā)送一個請求，服務(wù)器會根據(jù)這個請求的?request?header?的一些參數(shù)來判斷是否命中協(xié)商緩存，如果命中，則返回?304?狀態(tài)碼并帶上新的?response?header?通知瀏覽器從緩存中讀取資源。
基于last-modified的協(xié)商緩存（通過比對資源文件的修改時間進(jìn)行協(xié)商緩存）
Response?Headers攜帶：Last-Modified:<昨天>
Request?Headers攜帶：IF-Modified-Since:<昨天>
缺點(diǎn)：
- 在文件內(nèi)容本身不修改的情況下，依然有可能更新文件修改時間（比如修改文件名再改回來），此時文件內(nèi)容并沒有修改，緩存依然失效了
- 因為文件修改時間記錄的最小單位是秒，所以當(dāng)文件在幾百毫秒內(nèi)完成修改的時候，文件修改時間并不會改變，這樣，即使文件內(nèi)容修改了，依然不會返回新的文件
基于ETag的協(xié)商緩存（通過生成文件內(nèi)容的唯一哈希值，即文件指紋進(jìn)行協(xié)商緩存）
采用了一串編碼來標(biāo)記內(nèi)容，稱為ETag
Response?Headers攜帶：E-Tag:1234567
Request?Headers攜帶：If-None-Match:1234567
ETag就是將原先協(xié)商緩存的比較時間戳的形式修改成了比較文件指紋。
如果兩個文件指紋完全吻合，說明文件沒有被改變，則直接返回304狀態(tài)碼和一個空的響應(yīng)體并return。如果兩個文件指紋不吻合，則說明文件被更改，那么將新的文件指紋重新存儲到響應(yīng)頭的ETag中并返回給客戶端
缺點(diǎn)：
- 需要文件尺寸大，數(shù)量多，并且計算頻繁，那么服務(wù)端就需要更多的計算開銷，從而影響服務(wù)器的性能
- ETag有強(qiáng)驗證和弱驗證，所謂強(qiáng)驗證，ETag生成的哈希值深入到每個字節(jié)，從而保證文件內(nèi)容絕對的不變，非常消耗計算量；弱驗證則是提取文件的部分屬性來生成哈希值，因此不必精確到每個字節(jié)，所以整體速度會比強(qiáng)驗證快，但是精確率不高，會降低協(xié)商緩存的有效性
7.從輸入URL?到網(wǎng)頁顯示的完整過程
- DNS域名解析,解析到真正的IP地址；
- 客戶端與服務(wù)端建立TCP連接TCP/IP連接（通過三次握手）；
- 客戶端發(fā)送Http請求（封裝HTTP報文，TCP報文頭，IP報文頭...）；
- 服務(wù)器接收到http請求，根據(jù)請求報文頭中的信息執(zhí)行對應(yīng)的處理，并返回HTML文件給客戶端瀏覽器；
- 客戶端接收到HTML文件后，開始解析、渲染并展示網(wǎng)頁（DOM樹、STYLE樹、渲染樹、繪制頁面）；
- 數(shù)據(jù)傳輸完畢，關(guān)閉客戶端與服務(wù)器端的雙工連接（通過四次揮手）。
8.重排和重繪
重排（reflow）：重新生成布局，重新排列元素。
當(dāng)DOM的變化影響了元素的幾何信息(元素的的位置和尺寸大小)，瀏覽器需要重新計算元素的幾何屬性，將其安放在界面中的正確位置，這個過程叫做重排。重排也叫回流，簡單的說就是重新生成布局，重新排列元素。
重繪（repaint）：某些元素的外觀被改變，例如：元素的填充顏色，?背景色。
當(dāng)一個元素的外觀發(fā)生改變，但沒有改變布局，重新把元素外觀繪制出來的過程，叫做重繪。
注意：重繪不一定導(dǎo)致重排，但重排一定會導(dǎo)致重繪。重排開銷更大。
如何避免重繪或者重排？
- 集中改變樣式，不要一條一條地修改?DOM?的樣式，集中改樣式可先把所有樣式給class，然后再給標(biāo)簽。
- 不要把?DOM?結(jié)點(diǎn)的屬性值放在循環(huán)里當(dāng)成循環(huán)里的變量。
- 為動畫的?HTML?元件使用?固定定位（fixed）?或?絕對定位(absoult)?，那么修改他們的?CSS?是不會?重排的。
- 不使用?table?布局。因為可能很小的一個小改動會造成整個?table?的重新布局。
- 盡量只修改固定定位（fixed）?或?絕對定位(absoult)?元素，對其他元素影響不大
- 使用BFC特性，不影響其他元素位置
- 頻繁觸發(fā)（resize、scroll）使用節(jié)流和防抖
- 使用createDocumentFragment批量操作DOM
- 編碼上，避免連續(xù)多次修改，可通過合并修改，一次觸發(fā)
- 對于大量不同的?dom?修改，可以先將其脫離文檔流，比如使用絕對定位，或者?display:none，在文檔流外修改完成后再放回文檔里中。
- 動畫實現(xiàn)的速度的選擇，動畫速度越快，回流次數(shù)越多，也可以選擇使用?requestAnimationFrame。
- css3?硬件加速，transform、opacity、filters，開啟后，會新建渲染層
9.跨域
跨域：指的是瀏覽器不能執(zhí)行其他網(wǎng)站的腳本。它是由瀏覽器的同源策略造成的，是瀏覽器對javascript施加的安全限制。當(dāng)一個請求url的協(xié)議、域名、端口三者之間任意一個與當(dāng)前頁面url不同即為跨域。
注意：跨域限制訪問，其實是瀏覽器的限制。理解這一點(diǎn)很重要?。?！
同源策略：是指協(xié)議，域名，端口都要相同，其中有一個不同都會產(chǎn)生跨域；
（1）vue正向代理
vue正向代理（proxy）：利用瀏覽器有跨域，但是服務(wù)器沒有跨域限制，通過中間服務(wù)器轉(zhuǎn)發(fā)數(shù)據(jù)。
當(dāng)進(jìn)行跨域訪問時，vue會生成一個同源的虛擬服務(wù)器，請求將發(fā)送到虛擬服務(wù)器，由虛擬服務(wù)器訪問目標(biāo)服務(wù)器并轉(zhuǎn)發(fā)數(shù)據(jù)。
在vue.js開發(fā)環(huán)境下調(diào)用接口，如何避免跨域？
借助vue-cli腳手架開啟代理服務(wù)器，在vue.config.js文件中配置proxy
在工程目錄【config/index.js】中對proxyTable項進(jìn)行如下配置
proxyTable:?{
???"/api":?{
????????target:?"http://192.168.43.37:80/",
????????changeOrigin:?true,
????????pathRewrite:?{
??????????"^/api":?""
????????}
?????}
?},如上述配置后，調(diào)用接口，http://xxxx:80/login可以簡寫成/api/login，本地會虛擬化一個服務(wù)器并幫你把這個請求轉(zhuǎn)發(fā)給后臺，從而避免跨域問題。
（2）Nginx反向代理
跨域請求限制是瀏覽器的安全策略，服務(wù)器端并不存在跨域訪問這一說。利用Nginx的地址映射，將請求發(fā)送在一個同源的中間層，但是服務(wù)器實際請求地址為目標(biāo)服務(wù)器，這樣就不存在跨域訪問了。
例如前端項目放在"地址A"，接口放在"地址B"，Nginx服務(wù)器放在"nginxIpAddress:3000"地址。
當(dāng)訪問項目的時候，你訪問的是nginxIpAddress:3000，nginx將你的請求映射到項目的真實地址A，同理項目中的接口請求例如nginxIpAddress:3000/api/*，nginx將接口請求映射到接口服務(wù)的真實地址B。你始終訪問的是nginxIpAddress:3000端口下的地址，自然不會存在跨域問題。
（3）利用Nginx為響應(yīng)添加跨域頭解決
將原本要請求的服務(wù)地址，改為請求nginx服務(wù)器，利用nginx地址映射將請求映射到真實的服務(wù)地址，同時需要添加兩個響應(yīng)頭信息，一個是Access-Control-Allow-Origin，Access-Control-Allow-Methods。
Access-Control-Allow-Origin：直譯過來是允許跨域訪問的源地址信息，可以配置多個(多個用逗號分隔)，也可以使用*代表所有源。
Access-Control-Allow-Methods：直譯過來是允許跨域訪問的請求方式，值可以為?GET?POST?PUT?DELETE…,可以全部設(shè)置，也可以根據(jù)需要設(shè)置，多個用逗號分隔。
（4）cors（Cross-Origin?Resource?Sharing，跨域資源共享）?
原理：它允許瀏覽器向跨源服務(wù)器，發(fā)出XMLHttpRequest請求（配置響應(yīng)頭Accesse-Control-Allow-Origin:"*",違背任意一條同源策略都能訪問響應(yīng)數(shù)據(jù)），從而克服了AJAX只能同源使用的限制。缺點(diǎn)：這樣會造成任何人都能向這臺服務(wù)器要數(shù)據(jù)。
（5）jsonp跨域：利用script標(biāo)簽可以跨域請求資源，將回調(diào)函數(shù)作為參數(shù)拼接在url中。后端收到請求，調(diào)用該回調(diào)函數(shù)，并將數(shù)據(jù)作為參數(shù)返回回去，注意設(shè)置響應(yīng)頭返回文檔類型，應(yīng)該設(shè)置成javascript；請求數(shù)據(jù)類型dataType為jsonp。缺陷是只支持get請求，且存在一些安全隱患。
ps:不存在跨域問題的幾個標(biāo)簽<link>?,<script>,<img>,<iframe>
（6）websocket
（7）postMessage
10.常見的web前端攻擊方式有哪些
XSS、CSRF（Cross?Site?Request?Forgery?跨站請求偽造）、DDOS、SQL注入
11.優(yōu)雅降級和漸進(jìn)增強(qiáng)
漸進(jìn)增強(qiáng)?progressive?enhancement：
針對低版本瀏覽器進(jìn)行構(gòu)建頁面，保證最基本的功能，然后再針對高級瀏覽器進(jìn)行效果、交互等改進(jìn)和追加功能達(dá)到更好的用戶體驗。
優(yōu)雅降級?graceful?degradation：
一開始就構(gòu)建完整的功能，然后再針對低版本瀏覽器進(jìn)行兼容。
區(qū)別：
a.?優(yōu)雅降級是從復(fù)雜的現(xiàn)狀開始，并試圖減少用戶體驗的供給
b.?漸進(jìn)增強(qiáng)則是從一個非?；A(chǔ)的，能夠起作用的版本開始，并不斷擴(kuò)充，以適應(yīng)未來環(huán)境的需要
c.?降級（功能衰減）意味著往回看；而漸進(jìn)增強(qiáng)則意味著朝前看，同時保證其根基處于安全地帶
12.get和post的區(qū)別
（1）傳參方式：GET把參數(shù)放在URL里面，而POST放在請求體(request?body)中；
（2）傳參長度限制：GET請求在URL中傳遞的參數(shù)是有長度限制的，而POST沒有
（3）安全性：GET請求沒有POST請求安全,因為參數(shù)直接暴露在URL上面?所以不能用來傳遞敏感信息；POST?比?GET?安全，因為數(shù)據(jù)在地址欄上不可見。?然而，從傳輸?shù)慕嵌葋碚f，他們都是不安全的，因為?HTTP?在網(wǎng)絡(luò)上是明文傳輸?shù)?，只要在網(wǎng)絡(luò)節(jié)點(diǎn)上捉包，就能完整地獲取數(shù)據(jù)報文。
要想安全傳輸，就只有加密，也就是?HTTPS。
（4）緩存：GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置
GET產(chǎn)生的URL地址可以被Bookmarks,而POST不可以，GET請求的參數(shù)會被完整保存在瀏覽器歷史記錄里面,而POST參數(shù)不會被保留
GET在瀏覽器回退時候是無害的,而POST會再次請求
GET請求只能進(jìn)行url編碼,而POST可以支持多種編碼
GET請求的參數(shù)類型只接受ASCII字符,而POST沒有限制
13.http狀態(tài)碼
http狀態(tài)碼是用來表示網(wǎng)頁服務(wù)器超文本傳輸協(xié)議響應(yīng)狀態(tài)的3位數(shù)字代碼。
1XX?消息：代表請求已被接受，需要繼續(xù)處理
- 100?Continue客戶端應(yīng)當(dāng)繼續(xù)發(fā)送請求
- 101?Switching?Protocols?切換協(xié)議。服務(wù)器根據(jù)客戶端的請求切換協(xié)議。只能切換到更高級的協(xié)議
2XX?成功：操作被成功接收并處理
- 200?OK請求成功。一般用于GET與POST請求
- 201?Created?已創(chuàng)建。成功請求并創(chuàng)建了新的資源
- 202?Accepted?已接受。已經(jīng)接受請求，但未處理完成
3XX?重定向：需要進(jìn)一步的操作以完成請求
- 301?Moved?Permanently?永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應(yīng)使用新的URI代替
- 302?Found?臨時移動。與301類似。但資源只是臨時被移動?？蛻舳藨?yīng)繼續(xù)使用原有URI
- 304?Not?Modified?未修改。所請求的資源未修改，服務(wù)器返回此狀態(tài)碼時，不會返回任何資源?？蛻舳送ǔ?/span>緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
- 305?Use?Proxy?使用代理。所請求的資源必須通過代理訪問
- 306?Unused?已經(jīng)被廢棄的HTTP狀態(tài)碼
- 307?Temporary?Redirect?臨時重定向。與302類似。使用GET請求重定向
4XX請求錯誤：請求包含語法錯誤或無法完成請求
- 400?Bad?Request?客戶端請求的語法錯誤，服務(wù)器無法理解
- 401?Unauthorized??請求要求用戶的身份認(rèn)證
- 402?Payment?Required?保留，將來使用
- 403?Forbidden?服務(wù)器理解請求客戶端的請求，但是拒絕執(zhí)行此請求
- 404?Not?Found?請求的資源（網(wǎng)頁等）不存在
- 405?Method?Not?Allowed?客戶端請求中的方法被禁止
5XX服務(wù)器錯誤：服務(wù)器在處理請求的過程中發(fā)生了錯誤
- 500?Internal?Server?Error?服務(wù)器內(nèi)部錯誤，無法完成請求
- 501?Not?Implemented?服務(wù)器不支持請求的功能，無法完成請求
- 502?Bad?Gateway?作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請求時，從遠(yuǎn)程服務(wù)器接收到了一個無效的響應(yīng)
- 503?Service?Unavailable?由于超載或系統(tǒng)維護(hù)，服務(wù)器暫時的無法處理客戶端的請求。延時的長度可包含在服務(wù)器的Retry-After頭信息中
- 504?Gateway?Time-out?充當(dāng)網(wǎng)關(guān)或代理的服務(wù)器，未及時從遠(yuǎn)端服務(wù)器獲取請求
14.HTTP和HTTPS
（1）默認(rèn)端口：http協(xié)議的默認(rèn)端口為80，https的默認(rèn)端口為443
（2）安全性：http傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的。https協(xié)議是由http和ssl協(xié)議構(gòu)建的可進(jìn)行加密傳輸和身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議的安全性更高。
（3）費(fèi)用：Https協(xié)議需要ca證書，費(fèi)用較高。
15.為什么HTTPS安全
因為網(wǎng)絡(luò)請求需要中間有很多的服務(wù)器路由器的轉(zhuǎn)發(fā)。中間的節(jié)點(diǎn)都可能篡改信息，而如果使用HTTPS，密鑰在你和終點(diǎn)站才有。https之所以比http安全，是因為他利用ssl/tls協(xié)議傳輸。它包含證書，卸載，流量轉(zhuǎn)發(fā)，負(fù)載均衡，頁面適配，瀏覽器適配，refer傳遞等。保障了傳輸過程的安全性。
16.http報文
HTTP?報文是在應(yīng)用程序之間發(fā)送的數(shù)據(jù)塊,這些數(shù)據(jù)塊將通過以文本形式的元信息開頭，用于?HTTP?協(xié)議交互。請求端(客戶端)的?HTTP?報文叫做請求報文，響應(yīng)端(服務(wù)器端)的叫做響應(yīng)報文。?HTTP?報文本身是由多行(用?CR+LF?作換行符)數(shù)據(jù)構(gòu)成的字符串文本。
HTTP?請求報文由請求行、請求頭和請求體組成
請求行：由三部分構(gòu)成：請求方法：如?GET、POST；請求目標(biāo)：通常是一個?URL?，表明了要操作的資源；版本號：表示報文使用的?HTTP?協(xié)議版本。
請求頭：HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務(wù)端據(jù)此獲取客戶端的信息。與緩存相關(guān)的規(guī)則信息，均包含在header中。
請求體：就是?HTTP?要傳輸?shù)膬?nèi)容，HTTP?可以承載很多類型的數(shù)字?jǐn)?shù)據(jù):圖片、音頻、視頻、HTML?文檔等。
HTTP?響應(yīng)報文由狀態(tài)行、響應(yīng)頭和響應(yīng)體組成
狀態(tài)行包含了?協(xié)議版本、狀態(tài)碼以及狀態(tài)描述。
和請求報文的請求頭類似，響應(yīng)頭也由鍵值對組成，每行一對，鍵和值用英文冒號?:?分隔。響應(yīng)頭域允許服務(wù)器傳遞不能放在狀態(tài)行的附加信息，這些域主要描述服務(wù)器的信息和Request-URI進(jìn)一步的信息
響應(yīng)體：服務(wù)器返回給瀏覽器的響應(yīng)信息，響應(yīng)數(shù)據(jù)的格式是根據(jù)服務(wù)器來的，常見的響應(yīng)數(shù)據(jù)格式有：text/html、application/json、multipart/form-data等。
HTTP?首部字段
在?HTTP?的請求頭和響應(yīng)頭中都是由首部字段來表示的，首部內(nèi)容可以為客戶端和服務(wù)器分別處理請求和響應(yīng)提供所需要的信息。
首部字段可以分為通用首部字段、請求首部字段、響應(yīng)首部字段、實體首部字段
通用首部：這個是客戶端和服務(wù)器都可以使用的首部，提供了報文相關(guān)的最基本信息。不管是響應(yīng)報文和還是請求報文。例如
connection???允許客戶端和服務(wù)器指定與請求/響應(yīng)連接有關(guān)的選項
Date???????????提供日期和事件標(biāo)識，說明報文創(chuàng)建時間?
請求首部：請求報文特有的首部。
Host????????????給出了接收請求的服務(wù)器的主機(jī)名和端口
Referer????????提供包含當(dāng)前請求URI的文檔的URL
User-Agent???將發(fā)起請求的應(yīng)用程序名告訴服務(wù)器。
Accept首部：將客戶端提供了一種將其喜好和能力告知服務(wù)器的方式，包括他們想要什么，可以使用什么，他們不想要什么。
?????Accept????????????????告訴服務(wù)器能發(fā)送哪些媒體類型。
?????Accept-Charset????告訴服務(wù)器能發(fā)送哪些字符集。
?????Accept-Encoding??告訴服務(wù)器能夠發(fā)送哪些編碼。
條件請求首部：在客戶端需要為請求加上限制時使用，具有分支判斷功能
????Expect???????????允許客戶端列出某請求所學(xué)要的服務(wù)器行為。
????If-Match????????如果實體標(biāo)記與文檔當(dāng)前的實體標(biāo)記相匹配，就獲取這個文檔（緩存相關(guān)）
????If-Modified-Since??如果資源在指定日期之后修改過，那么就獲取這個文檔。（緩存相關(guān)）
安全請求首部：簡單的安全機(jī)制，要求客戶端在獲取特定的資源之前，先對自身進(jìn)行驗證。
???Authorization????????包含了客戶端提供給服務(wù)器，以便對其自身進(jìn)行認(rèn)證的數(shù)據(jù)。
???Cookie????????客戶端用它向服務(wù)器傳送了一個令牌——他并不是真正的安全首部，但確實包含了安全功能
代理請求首部：關(guān)于代理控制的首部。
???Max—Forward???????在通往源服務(wù)器的路徑上，將請求轉(zhuǎn)發(fā)給其他代理或者網(wǎng)關(guān)的最大次數(shù)，與TRACE方法一起使用。
響應(yīng)首部：響應(yīng)報文特有的首部。
Age???????????從最初創(chuàng)建開始響應(yīng)持續(xù)時間。
Public????????服務(wù)器為其資源支持的請求方法列表
Server????????服務(wù)器應(yīng)用程序軟件的名稱和版本。
協(xié)商首部：如果資源有多重表示方法，如某文檔有中文和英文兩個版本，就可以通過這些首部與服務(wù)器進(jìn)行協(xié)商。
Accept-Ranges???對此資源來說，服務(wù)器可接受的范圍類型。
安全響應(yīng)首部：與安全響應(yīng)首部相關(guān)，實現(xiàn)安全功能。
實體首部：用來描述HTTP報文的負(fù)荷，請求響應(yīng)報文都可能出現(xiàn)。
Allow????????????????列出了可以對此實體執(zhí)行的請求方法
Location????????????告知客戶端實體處于何處;用于將接收端定向到資源的（可能是新的）位置（URL）上去。
內(nèi)容首部：提供了與實體內(nèi)容有關(guān)的特定信息，說明了其類型尺寸以及處理它所需的有用信息。
??content-Base???????解析主體中的相對URL時使用的基礎(chǔ)URL。
??content-Encoding??對主體執(zhí)行的任意編碼方式
???content-Language?理解主體時最合適的自然語言。
???content-Length?????主體的長度或尺寸
??content-Type????????這個主體的對象類型
實體緩存首部：說明何時如何進(jìn)行緩存。
??ETag????????????????????與此實體相關(guān)的實體標(biāo)記
??Expires?????????????????實體不再有效，要從原始的源再次獲取此實體的日期和事件
??Last-Modified?????????這個實體最后一次被修改的日期和時間。
擴(kuò)展首部：用戶自定義的首部。
17.安全傳輸，加密算法
crypto-js是谷歌開發(fā)的一個純JavaScript的加密算法類庫，可以非常方便的在前端進(jìn)行其所支持的加解密操作。目前crypto-js已支持的算法有：MD5、SHA-1、SHA-256、AES(對稱)、RSA（非對稱，公鑰私鑰）、Rabbit、MARC4、HMAC、HMAC-MD5、HMAC-SHA1、HMAC-SHA256、PBKDF2等。使用時可以引用總文件，也可以單獨(dú)引用某一文件。文章來源：http://www.zghlxwxcb.cn/news/detail-835893.html
CryptoJS提供ECB,CBC（必須有iv向量）,CFB,OFB,CTR五種模式文章來源地址http://www.zghlxwxcb.cn/news/detail-835893.html
到了這里，關(guān)于瀏覽器---瀏覽器/http相關(guān)面試題的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
