http、html和瀏覽器篇
1.http和https
https的SSL加密是在傳輸層實現(xiàn)的。
(1)http和https的基本概念
http: 超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議，是一個客戶端和服務器端請求和應答的標準（TCP），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡傳輸減少。
https: 是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內(nèi)容就需要SSL。
https協(xié)議的主要作用是：建立一個信息安全通道，來確保數(shù)組的傳輸，確保網(wǎng)站的真實性。
(2)http和https的區(qū)別？
http傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，網(wǎng)景公司設置了SSL協(xié)議來對http協(xié)議傳輸?shù)臄?shù)據(jù)進行加密處理，簡單來說https協(xié)議是由http和ssl協(xié)議構(gòu)建的可進行加密傳輸和身份認證的網(wǎng)絡協(xié)議，比http協(xié)議的安全性更高。
主要的區(qū)別如下：
- Https協(xié)議需要ca證書，費用較高。
- http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
- 使用不同的鏈接方式，端口也不同，一般而言，http協(xié)議的端口為80，https的端口為443
- http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。
(3)https協(xié)議的工作原理
客戶端在使用HTTPS方式與Web服務器通信時有以下幾個步驟，如圖所示。
- 客戶使用https url訪問服務器，則要求web 服務器建立ssl鏈接。
- web服務器接收到客戶端的請求之后，會將網(wǎng)站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。
- 客戶端和web服務器端開始協(xié)商SSL鏈接的安全等級，也就是加密等級。
- 客戶端瀏覽器通過雙方協(xié)商一致的安全等級，建立會話密鑰，然后通過網(wǎng)站的公鑰來加密會話密鑰，并傳送給網(wǎng)站。
- web服務器通過自己的私鑰解密出會話密鑰。
- web服務器通過會話密鑰加密與客戶端之間的通信。
(4)https協(xié)議的優(yōu)點
- 使用HTTPS協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；
- HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
- HTTPS是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
- 谷歌曾在2014年8月份調(diào)整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結(jié)果中的排名將會更高”。
(5)https協(xié)議的缺點
- https握手階段比較費時，會使頁面加載時間延長50%，增加10%~20%的耗電。
- https緩存不如http高效，會增加數(shù)據(jù)開銷。
- SSL證書也需要錢，功能越強大的證書費用越高。
- SSL證書需要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。
2.tcp三次握手，一句話概括
客戶端和服務端都需要直到各自可收發(fā)，因此需要三次握手。
簡化三次握手：
<img width="487" alt="2018-07-10 3 42 11" src="https://user-gold-cdn.xitu.io...;h=1038&f=png&s=94703">
從圖片可以得到三次握手可以簡化為：C發(fā)起請求連接S確認，也發(fā)起連接C確認我們再看看每次握手的作用：第一次握手：S只可以確認 自己可以接受C發(fā)送的報文段第二次握手：C可以確認 S收到了自己發(fā)送的報文段，并且可以確認 自己可以接受S發(fā)送的報文段第三次握手：S可以確認 C收到了自己發(fā)送的報文段
3.TCP和UDP的區(qū)別
（1）TCP是面向連接的，udp是無連接的即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
（2）TCP提供可靠的服務。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付。 并且因為tcp可靠，面向連接，不會丟失數(shù)據(jù)因此適合大數(shù)據(jù)量的交換。
（3）TCP是面向字節(jié)流，UDP面向報文，并且網(wǎng)絡出現(xiàn)擁塞不會使得發(fā)送速率降低（因此會出現(xiàn)丟包，對實時的應用比如IP電話和視頻會議等）。
（4）TCP只能是1對1的，UDP支持1對1,1對多。
（5）TCP的首部較大為20字節(jié)，而UDP只有8字節(jié)。
（6）TCP是面向連接的可靠性傳輸，而UDP是不可靠的。
4.WebSocket的實現(xiàn)和應用
(1)什么是WebSocket?
WebSocket是HTML5中的協(xié)議，支持持久連續(xù)，http協(xié)議不支持持久性連接。Http1.0和HTTP1.1都不支持持久性的鏈接，HTTP1.1中的keep-alive，將多個http請求合并為1個
(2)WebSocket是什么樣的協(xié)議，具體有什么優(yōu)點？
- HTTP的生命周期通過Request來界定，也就是Request一個Response，那么在Http1.0協(xié)議中，這次Http請求就結(jié)束了。在Http1.1中進行了改進，是的有一個connection：Keep-alive，也就是說，在一個Http連接中，可以發(fā)送多個Request，接收多個Response。但是必須記住，在Http中一個Request只能對應有一個Response，而且這個Response是被動的，不能主動發(fā)起。
- WebSocket是基于Http協(xié)議的，或者說借用了Http協(xié)議來完成一部分握手，在握手階段與Http是相同的。我們來看一個websocket握手協(xié)議的實現(xiàn)，基本是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
告訴服務器發(fā)送的是websocket
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
5.HTTP請求的方式，HEAD方式
- head：類似于get請求，只不過返回的響應中沒有具體的內(nèi)容，用戶獲取報頭
- options：允許客戶端查看服務器的性能，比如說服務器支持的請求方式等等。
6.一個圖片url訪問后直接下載怎樣實現(xiàn)？
請求的返回頭里面，用于瀏覽器解析的重要參數(shù)就是OSS的API文檔里面的返回http頭，決定用戶下載行為的參數(shù)。
下載的情況下：
1. x-oss-object-type:
Normal
2. x-oss-request-id:
598D5ED34F29D01FE2925F41
3. x-oss-storage-class:
Standard
7.web Quality （無障礙）
能夠被殘障人士使用的網(wǎng)站才能稱得上一個易用的（易訪問的）網(wǎng)站。
殘障人士指的是那些帶有殘疾或者身體不健康的用戶。
使用alt屬性：
<img src="person.jpg" alt="this is a person"/>
有時候瀏覽器會無法顯示圖像。具體的原因有：
- 用戶關(guān)閉了圖像顯示
- 瀏覽器是不支持圖形顯示的迷你瀏覽器
- 瀏覽器是語音瀏覽器（供盲人和弱視人群使用）
如果您使用了 alt 屬性，那么瀏覽器至少可以顯示或讀出有關(guān)圖像的描述。
8.幾個很實用的BOM屬性對象方法?
什么是Bom? Bom是瀏覽器對象。有哪些常用的Bom屬性呢？
(1)location對象
location.href-- 返回或設置當前文檔的URL
location.search -- 返回URL中的查詢字符串部分。例如 http://www.dreamdu.com/dreamd... 返回包括(?)后面的內(nèi)容?id=5&name=dreamdu
location.hash -- 返回URL#后面的內(nèi)容，如果沒有#，返回空
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中的協(xié)議部分。例如 http://www.dreamdu.com:8080/xhtml/ 返回(//)前面的內(nèi)容http:
location.assign -- 設置當前文檔的URL
location.replace() -- 設置當前文檔的URL，并且在history對象的地址列表中移除這個URL location.replace(url);
location.reload() -- 重載當前頁面
(2)history對象
history.go() -- 前進或后退指定的頁面數(shù) history.go(num);
history.back() -- 后退一頁
history.forward() -- 前進一頁
(3)Navigator對象
navigator.userAgent -- 返回用戶代理頭的字符串表示(就是包括瀏覽器版本信息等的字符串)
navigator.cookieEnabled -- 返回瀏覽器是否支持(啟用)cookie
9.HTML5 drag api
- dragstart：事件主體是被拖放元素，在開始拖放被拖放元素時觸發(fā)，。
- darg：事件主體是被拖放元素，在正在拖放被拖放元素時觸發(fā)。
- dragenter：事件主體是目標元素，在被拖放元素進入某元素時觸發(fā)。
- dragover：事件主體是目標元素，在被拖放在某元素內(nèi)移動時觸發(fā)。
- dragleave：事件主體是目標元素，在被拖放元素移出目標元素是觸發(fā)。
- drop：事件主體是目標元素，在目標元素完全接受被拖放元素時觸發(fā)。
- dragend：事件主體是被拖放元素，在整個拖放操作結(jié)束時觸發(fā)
10.http2.0
首先補充一下，http和https的區(qū)別，相比于http,https是基于ssl加密的http協(xié)議
簡要概括：http2.0是基于1999年發(fā)布的http1.0之后的首次更新。
- 提升訪問速度（可以對于，請求資源所需時間更少，訪問速度更快，相比http1.0）
- 允許多路復用：多路復用允許同時通過單一的HTTP/2連接發(fā)送多重請求-響應信息。改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數(shù)量限制（連接數(shù)量），超過限制會被阻塞。
- 二進制分幀：HTTP2.0會將所有的傳輸信息分割為更小的信息或者幀，并對他們進行二進制編碼
- 首部壓縮
- 服務器端推送
11.補充400和401、403狀態(tài)碼
(1)400狀態(tài)碼：請求無效
產(chǎn)生原因：
- 前端提交數(shù)據(jù)的字段名稱和字段類型與后臺的實體沒有保持一致
- 前端提交到后臺的數(shù)據(jù)應該是json字符串類型，但是前端沒有將對象JSON.stringify轉(zhuǎn)化成字符串。
解決方法：
- 對照字段的名稱，保持一致性
- 將obj對象通過JSON.stringify實現(xiàn)序列化
(2)401狀態(tài)碼：當前請求需要用戶驗證
(3)403狀態(tài)碼：服務器已經(jīng)得到請求，但是拒絕執(zhí)行
12.fetch發(fā)送2次請求的原因
fetch發(fā)送post請求的時候，總是發(fā)送2次，第一次狀態(tài)碼是204，第二次才成功？
原因很簡單，因為你用fetch的post請求的時候，導致fetch 第一次發(fā)送了一個Options請求，詢問服務器是否支持修改的請求頭，如果服務器支持，則在第二次中發(fā)送真正的請求。
13.Cookie、sessionStorage、localStorage的區(qū)別
共同點：都是保存在瀏覽器端，并且是同源的
- Cookie：cookie數(shù)據(jù)始終在同源的http請求中攜帶（即使不需要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數(shù)據(jù)發(fā)給服務器，僅在本地保存。cookie數(shù)據(jù)還有路徑（path）的概念，可以限制cookie只屬于某個路徑下,存儲的大小很小只有4K左右。 （key：可以在瀏覽器和服務器端來回傳遞，存儲容量小，只有大約4K左右）
- sessionStorage：僅在當前瀏覽器窗口關(guān)閉前有效，自然也就不可能持久保持，localStorage：始終有效，窗口或瀏覽器關(guān)閉也一直保存，因此用作持久數(shù)據(jù)；cookie只在設置的cookie過期時間之前一直有效，即使窗口或瀏覽器關(guān)閉。（key：本身就是一個回話過程，關(guān)閉瀏覽器后消失，session為一個回話，當頁面不同即使是同一頁面打開兩次，也被視為同一次回話）
- localStorage：localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。（key：同源窗口都會共享，并且不會失效，不管窗口或者瀏覽器關(guān)閉與否都會始終生效）
補充說明一下cookie的作用：
- 保存用戶登錄狀態(tài)。例如將用戶id存儲于一個cookie內(nèi)，這樣當用戶下次訪問該頁面時就不需要重新登錄了，現(xiàn)在很多論壇和社區(qū)都提供這樣的功能。 cookie還可以設置過期時間，當超過時間期限后，cookie就會自動消失。因此，系統(tǒng)往往可以提示用戶保持登錄狀態(tài)的時間：常見選項有一個月、三個 月、一年等。
- 跟蹤用戶行為。例如一個天氣預報網(wǎng)站，能夠根據(jù)用戶選擇的地區(qū)顯示當?shù)氐奶鞖馇闆r。如果每次都需要選擇所在地是煩瑣的，當利用了 cookie后就會顯得很人性化了，系統(tǒng)能夠記住上一次訪問的地區(qū)，當下次再打開該頁面時，它就會自動顯示上次用戶所在地區(qū)的天氣情況。因為一切都是在后 臺完成，所以這樣的頁面就像為某個用戶所定制的一樣，使用起來非常方便
- 定制頁面。如果網(wǎng)站提供了換膚或更換布局的功能，那么可以使用cookie來記錄用戶的選項，例如：背景色、分辨率等。當用戶下次訪問時，仍然可以保存上一次訪問的界面風格。
14.web worker
在HTML頁面中，如果在執(zhí)行腳本時，頁面的狀態(tài)是不可相應的，直到腳本執(zhí)行完成后，頁面才變成可相應。web worker是運行在后臺的js，獨立于其他腳本，不會影響頁面你的性能。并且通過postMessage將結(jié)果回傳到主線程。這樣在進行復雜操作的時候，就不會阻塞主線程了。
如何創(chuàng)建web worker：
- 檢測瀏覽器對于web worker的支持性
- 創(chuàng)建web worker文件（js，回傳函數(shù)等）
- 創(chuàng)建web worker對象
15.對HTML語義化標簽的理解
HTML5語義化標簽是指正確的標簽包含了正確的內(nèi)容，結(jié)構(gòu)良好，便于閱讀，比如nav表示導航條，類似的還有article、header、footer等等標簽。
16.iframe是什么？有什么缺點？
定義：iframe元素會創(chuàng)建包含另一個文檔的內(nèi)聯(lián)框架
提示：可以將提示文字放在<iframe></iframe>之間，來提示某些不支持iframe的瀏覽器
缺點：
- 會阻塞主頁面的onload事件
- 搜索引擎無法解讀這種頁面，不利于SEO
- iframe和主頁面共享連接池，而瀏覽器對相同區(qū)域有限制所以會影響性能。
17.Doctype作用? 嚴格模式與混雜模式如何區(qū)分？它們有何意義?
Doctype聲明于文檔最前面，告訴瀏覽器以何種方式來渲染頁面，這里有兩種模式，嚴格模式和混雜模式。
- 嚴格模式的排版和 JS 運作模式是 以該瀏覽器支持的最高標準運行。
- 混雜模式，向后兼容，模擬老式瀏覽器，防止瀏覽器無法兼容頁面。
18.Cookie如何防范XSS攻擊
XSS（跨站腳本攻擊）是指攻擊者在返回的HTML中嵌入javascript腳本，為了減輕這些攻擊，需要在HTTP頭部配上，set-cookie：
- httponly-這個屬性可以防止XSS,它會禁止javascript腳本來訪問cookie。
- secure - 這個屬性告訴瀏覽器僅在請求為https的時候發(fā)送cookie。
結(jié)果應該是這樣的：Set-Cookie=<cookie-value>.....
19.Cookie和session的區(qū)別
HTTP是一個無狀態(tài)協(xié)議，因此Cookie的最大的作用就是存儲sessionId用來唯一標識用戶
20. 一句話概括RESTFUL
就是用URL定位資源，用HTTP描述操作
21.講講viewport和移動端布局
可以參考我的這篇文章：
響應式布局的常用解決方案對比(媒體查詢、百分比、rem和vw/vh）
22. click在ios上有300ms延遲，原因及如何解決？
(1)粗暴型，禁用縮放
<meta name="viewport" content="width=device-width, user-scalable=no">
(2)利用FastClick，其原理是：
檢測到touchend事件后，立刻出發(fā)模擬click事件，并且把瀏覽器300毫秒之后真正出發(fā)的事件給阻斷掉
