web前端面試題

前端面試總結 ：http、html和瀏覽器篇

1.http和https

 

https的SSL加密是在傳輸層實現的。

 

(1)http和https的基本概念

 

http: 超文本傳輸協議，是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

 

https: 是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

 

https協議的主要做用是：創建一個信息安全通道，來確保數組的傳輸，確保網站的真實性。

 

(2)http和https的區別？

 

http傳輸的數據都是未加密的，也就是明文的，網景公司設置了SSL協議來對http協議傳輸的數據進行加密處理，簡單來講https協議是由http和ssl協議構建的可進行加密傳輸和身份認證的網絡協議，比http協議的安全性更高。

主要的區別以下：

 

• Https協議須要ca證書，費用較高。

• http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

• 使用不一樣的連接方式，端口也不一樣，通常而言，http協議的端口爲80，https的端口爲443

• http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

 

(3)https協議的工做原理

 

客戶端在使用HTTPS方式與Web服務器通訊時有如下幾個步驟，如圖所示。

 

• 客戶使用https url訪問服務器，則要求web 服務器創建ssl連接。

• web服務器接收到客戶端的請求以後，會將網站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。

• 客戶端和web服務器端開始協商SSL連接的安全等級，也就是加密等級。

• 客戶端瀏覽器經過雙方協商一致的安全等級，創建會話密鑰，而後經過網站的公鑰來加密會話密鑰，並傳送給網站。

• web服務器經過本身的私鑰解密出會話密鑰。

• web服務器經過會話密鑰加密與客戶端之間的通訊。

 

(4)https協議的優勢

 

• 使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；

• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性。

• HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

• 谷歌曾在2014年8月份調整搜索引擎算法，並稱「比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高」。

 

(5)https協議的缺點

 

• https握手階段比較費時，會使頁面加載時間延長50%，增長10%~20%的耗電。

• https緩存不如http高效，會增長數據開銷。

• SSL證書也須要錢，功能越強大的證書費用越高。

• SSL證書須要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。

 

2.tcp三次握手，一句話歸納

 

客戶端和服務端都須要直到各自可收發，所以須要三次握手。

 

簡化三次握手：

 

 

從圖片能夠獲得三次握手能夠簡化爲：C發起請求鏈接S確認，也發起鏈接C確認咱們再看看每次握手的做用：第一次握手：S只能夠確認 本身能夠接受C發送的報文段第二次握手：C能夠確認 S收到了本身發送的報文段，而且能夠確認 本身能夠接受S發送的報文段第三次握手：S能夠確認 C收到了本身發送的報文段

 

3.TCP和UDP的區別

 

（1）TCP是面向鏈接的，udp是無鏈接的即發送數據前不須要先創建連接。

（2）TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付。 而且由於tcp可靠，面向鏈接，不會丟失數據所以適合大數據量的交換。

（3）TCP是面向字節流，UDP面向報文，而且網絡出現擁塞不會使得發送速率下降（所以會出現丟包，對實時的應用好比IP電話和視頻會議等）。

（4）TCP只能是1對1的，UDP支持1對1,1對多。

（5）TCP的首部較大爲20字節，而UDP只有8字節。

（6）TCP是面向鏈接的可靠性傳輸，而UDP是不可靠的。

 

4.WebSocket的實現和應用

 

(1)什麼是WebSocket?

 

WebSocket是HTML5中的協議，支持持久連續，http協議不支持持久性鏈接。Http1.0和HTTP1.1都不支持持久性的連接，HTTP1.1中的keep-alive，將多個http請求合併爲1個

 

(2)WebSocket是什麼樣的協議，具體有什麼優勢？

 

• HTTP的生命週期經過Request來界定，也就是Request一個Response，那麼在Http1.0協議中，此次Http請求就結束了。在Http1.1中進行了改進，是的有一個connection：Keep-alive，也就是說，在一個Http鏈接中，能夠發送多個Request，接收多個Response。可是必須記住，在Http中一個Request只能對應有一個Response，並且這個Response是被動的，不能主動發起。

• WebSocket是基於Http協議的，或者說借用了Http協議來完成一部分握手，在握手階段與Http是相同的。咱們來看一個websocket握手協議的實現，基本是2個屬性，upgrade，connection。

 

基本請求以下：

 

 

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

 

 

多了下面2個屬性：

 

 

Upgrade:webSocket
Connection:Upgrade
告訴服務器發送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

 

5.HTTP請求的方式，HEAD方式

 

• head：相似於get請求，只不過返回的響應中沒有具體的內容，用戶獲取報頭

• options：容許客戶端查看服務器的性能，好比說服務器支持的請求方式等等。

 

6.一個圖片url訪問後直接下載怎樣實現？

 

請求的返回頭裏面，用於瀏覽器解析的重要參數就是OSS的API文檔裏面的返回http頭，決定用戶下載行爲的參數。

 

下載的狀況下：

 

  1. x-oss-object-type:

         Normal

  2. x-oss-request-id:

         598D5ED34F29D01FE2925F41

  3. x-oss-storage-class:

         Standard

 

7.web Quality （無障礙）

 

可以被殘障人士使用的網站才能稱得上一個易用的（易訪問的）網站。

殘障人士指的是那些帶有殘疾或者身體不健康的用戶。

 

使用alt屬性：

 

<img src="person.jpg"  alt="this is a person"/>

 

有時候瀏覽器會沒法顯示圖像。具體的緣由有：

 

• 用戶關閉了圖像顯示

• 瀏覽器是不支持圖形顯示的迷你瀏覽器

• 瀏覽器是語音瀏覽器（供盲人和弱視人羣使用）

• 若是您使用了 alt 屬性，那麼瀏覽器至少能夠顯示或讀出有關圖像的描述。

 

8.幾個很實用的BOM屬性對象方法?

 

什麼是Bom? Bom是瀏覽器對象。有哪些經常使用的Bom屬性呢？

 

(1)location對象

 

location.href-- 返回或設置當前文檔的URL

location.search -- 返回URL中的查詢字符串部分。例如 http://www.dreamdu.com/dreamdu.php?id=5&name=dreamdu 返回包括(?)後面的內容?id=5&name=dreamdu

location.hash -- 返回URL#後面的內容，若是沒有#，返回空

location.host -- 返回URL中的域名部分，例如www.dreamdu.com

location.hostname -- 返回URL中的主域名部分，例如dreamdu.com

location.pathname -- 返回URL的域名後的部分。例如 http://www.dreamdu.com/xhtml/ 返回/xhtml/

location.port -- 返回URL中的端口部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回8080

location.protocol -- 返回URL中的協議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回(//)前面的內容http:

location.assign -- 設置當前文檔的URL

location.replace() -- 設置當前文檔的URL，而且在history對象的地址列表中移除這個URL location.replace(url);

location.reload() -- 重載當前頁面

 

(2)history對象

 

history.go() -- 前進或後退指定的頁面數 history.go(num);

history.back() -- 後退一頁

history.forward() -- 前進一頁

 

(3)Navigator對象

 

navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字符串)

navigator.cookieEnabled -- 返回瀏覽器是否支持(啓用)cookie

 

9.HTML5 drag api

 

• dragstart：事件主體是被拖放元素，在開始拖放被拖放元素時觸發，。

• darg：事件主體是被拖放元素，在正在拖放被拖放元素時觸發。

• dragenter：事件主體是目標元素，在被拖放元素進入某元素時觸發。

• dragover：事件主體是目標元素，在被拖放在某元素內移動時觸發。

• dragleave：事件主體是目標元素，在被拖放元素移出目標元素是觸發。

• drop：事件主體是目標元素，在目標元素徹底接受被拖放元素時觸發。

• dragend：事件主體是被拖放元素，在整個拖放操做結束時觸發

 

10.http2.0

 

首先補充一下，http和https的區別，相比於http,https是基於ssl加密的http協議

簡要歸納：http2.0是基於1999年發佈的http1.0以後的首次更新。

 

• 提高訪問速度（能夠對於，請求資源所需時間更少，訪問速度更快，相比http1.0）

• 容許多路複用：多路複用容許同時經過單一的HTTP/2鏈接發送多重請求-響應信息。改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制（鏈接數量），超過限制會被阻塞。

• 二進制分幀：HTTP2.0會將全部的傳輸信息分割爲更小的信息或者幀，並對他們進行二進制編碼

• 首部壓縮

• 服務器端推送

 

11.補充400和40一、403狀態碼

 

(1)400狀態碼：請求無效

 

產生緣由：

 

• 前端提交數據的字段名稱和字段類型與後臺的實體沒有保持一致

• 前端提交到後臺的數據應該是json字符串類型，可是前端沒有將對象JSON.stringify轉化成字符串。

 

解決方法：

 

• 對照字段的名稱，保持一致性

• 將obj對象經過JSON.stringify實現序列化

 

(2)401狀態碼：當前請求須要用戶驗證

(3)403狀態碼：服務器已經獲得請求，可是拒絕執行

 

12.fetch發送2次請求的緣由

 

fetch發送post請求的時候，老是發送2次，第一次狀態碼是204，第二次才成功？

 

緣由很簡單，由於你用fetch的post請求的時候，致使fetch 第一次發送了一個Options請求，詢問服務器是否支持修改的請求頭，若是服務器支持，則在第二次中發送真正的請求。

 

13.Cookie、sessionStorage、localStorage的區別

 

共同點：都是保存在瀏覽器端，而且是同源的

 

• Cookie：cookie數據始終在同源的http請求中攜帶（即便不須要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。cookie數據還有路徑（path）的概念，能夠限制cookie只屬於某個路徑下,存儲的大小很小隻有4K左右。 （key：能夠在瀏覽器和服務器端來回傳遞，存儲容量小，只有大約4K左右）

• sessionStorage：僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持，localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。（key：自己就是一個回話過程，關閉瀏覽器後消失，session爲一個回話，當頁面不一樣即便是同一頁面打開兩次，也被視爲同一次回話）

• localStorage：localStorage 在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的。（key：同源窗口都會共享，而且不會失效，無論窗口或者瀏覽器關閉與否都會始終生效）

 

補充說明一下cookie的做用：

 

• 保存用戶登陸狀態。例如將用戶id存儲於一個cookie內，這樣當用戶下次訪問該頁面時就不須要從新登陸了，如今不少論壇和社區都提供這樣的功能。 cookie還能夠設置過時時間，當超過期間期限後，cookie就會自動消失。所以，系統每每能夠提示用戶保持登陸狀態的時間：常見選項有一個月、三個 月、一年等。

• 跟蹤用戶行爲。例如一個天氣預報網站，可以根據用戶選擇的地區顯示當地的天氣狀況。若是每次都須要選擇所在地是煩瑣的，當利用了 cookie後就會顯得很人性化了，系統可以記住上一次訪問的地區，當下次再打開該頁面時，它就會自動顯示上次用戶所在地區的天氣狀況。由於一切都是在後 臺完成，因此這樣的頁面就像爲某個用戶所定製的同樣，使用起來很是方便

• 定製頁面。若是網站提供了換膚或更換佈局的功能，那麼可使用cookie來記錄用戶的選項，例如：背景色、分辨率等。當用戶下次訪問時，仍然能夠保存上一次訪問的界面風格。

 

14.web worker

 

在HTML頁面中，若是在執行腳本時，頁面的狀態是不可相應的，直到腳本執行完成後，頁面才變成可相應。web worker是運行在後臺的js，獨立於其餘腳本，不會影響頁面你的性能。而且經過postMessage將結果回傳到主線程。這樣在進行復雜操做的時候，就不會阻塞主線程了。

 

如何建立web worker：

 

• 檢測瀏覽器對於web worker的支持性

• 建立web worker文件（js，回傳函數等）

• 建立web worker對象

 

15.對HTML語義化標籤的理解

 

HTML5語義化標籤是指正確的標籤包含了正確的內容，結構良好，便於閱讀，好比nav表示導航條，相似的還有article、header、footer等等標籤。

 

16.iframe是什麼？有什麼缺點？

 

定義：iframe元素會建立包含另外一個文檔的內聯框架

提示：能夠將提示文字放在<iframe></iframe>之間，來提示某些不支持iframe的瀏覽器

 

缺點：

 

• 會阻塞主頁面的onload事件

• 搜索引擎沒法解讀這種頁面，不利於SEO

• iframe和主頁面共享鏈接池，而瀏覽器對相同區域有限制因此會影響性能。

 

17.Doctype做用? 嚴格模式與混雜模式如何區分？它們有何意義?

 

Doctype聲明於文檔最前面，告訴瀏覽器以何種方式來渲染頁面，這裏有兩種模式，嚴格模式和混雜模式。

 

• 嚴格模式的排版和 JS 運做模式是 以該瀏覽器支持的最高標準運行。

• 混雜模式，向後兼容，模擬老式瀏覽器，防止瀏覽器沒法兼容頁面。

 

18.Cookie如何防範XSS攻擊

 

XSS（跨站腳本攻擊）是指攻擊者在返回的HTML中嵌入javascript腳本，爲了減輕這些攻擊，須要在HTTP頭部配上，set-cookie：

 

• httponly-這個屬性能夠防止XSS,它會禁止javascript腳原本訪問cookie。

• secure - 這個屬性告訴瀏覽器僅在請求爲https的時候發送cookie。

 

結果應該是這樣的：Set-Cookie=.....

 

19.Cookie和session的區別

 

HTTP是一個無狀態協議，所以Cookie的最大的做用就是存儲sessionId用來惟一標識用戶

 

20. 一句話歸納RESTFUL

 

就是用URL定位資源，用HTTP描述操做

 

21.講講viewport和移動端佈局

 

能夠參考個人這篇文章：

 

響應式佈局的經常使用解決方案對比(媒體查詢、百分比、rem和vw/vh）（https://github.com/forthealllight/blog/issues/13）

 

22. click在ios上有300ms延遲，緣由及如何解決？

 

(1)粗暴型，禁用縮放

 <meta name="viewport" content="width=device-width, user-scalable=no"> 

(2)利用FastClick，其原理是：

檢測到touchend事件後，馬上出發模擬click事件，而且把瀏覽器300毫秒以後真正出發的事件給阻斷掉。