文章目錄
1 HTTP與HTTPS協議
參考 https://juejin.im/entry/58d7635e5c497d0057fae036#comment
HTTPS和HTTP的區別主要如下：
1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2、http是超文本傳輸協議，信息是明文傳輸，連接很簡單，是無狀態的；https協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，可建立一個信息安全通道，來確保數據的傳輸，確保網站的真實性，比http協議安全。
3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
HTTPS協議缺點：
1、頁面加載時間：https握手階段比較費時，會使頁面加載時間延長50%，增加10%~20%的耗電。
2、緩存：https緩存不如http高效，會增加數據開銷。
3、費用：SSL證書費用高
4、IP綁定：SSL證書需要綁定IP，不能再同一個ip上綁定多個域名，ipv4資源支持不了這種消耗。
2 TCP與UDP
參考
https://blog.csdn.net/silenceoo/article/details/77508439
https://blog.fundebug.com/2019/03/22/differences-of-tcp-and-udp/
TCP的三次握手和四次揮手？爲什麼？
三次握手 TCP建立連接
(1) 客戶端發送連接請求，報文段包括自身數據初始序號
(2) 服務端收到後如果同意連接則會發送應答，報文段包括自身數據初始序號和確認號
(3) 客戶端收到應答後還要向服務端發送確認報文。完畢後客戶端和服務器都進入ESTABLISHED狀態，建立成功。
四次揮手 TCP釋放連接
(1) 客戶端認爲數據發送完成，發送連接釋放請求
(2) 服務端收到後發送確認包，表示不再接收客戶端發送的數據
(3) 服務端沒發送完的數據還可繼續發生，完畢後發送連接釋放請求
(4) 客戶端收到後發送確認包。該狀態持續2MSL(報文段在網絡中生存的時間，超時被拋棄)，若沒有服務端重發請求則進入CLOSED狀態，服務端收到後也進入CLOSED狀態
爲什麼不是兩次握手 三次揮手
不是兩次握手的原因在於避免失效報文又傳送到服務器後產生錯誤
不是三次揮手的原因在於TCP是全雙工通信，第一次輪迴代表客戶端沒有數據發送，第二次輪迴代表服務端也沒有數據發送，才能斷開連接
3 WebSocket
參考 http://www.ruanyifeng.com/blog/2017/05/websocket.html
websocket是什麼？有什麼優點?應用？
(1) HTTP有一個缺陷，就是連接只能由客戶端發起，做不到服務器端主動推送。而websocket正是避免這樣缺陷的一個全雙工通信方式。
(2) WebSocket是HTML5中的協議，支持持久連續，http協議不支持持久性連接。
(3) WebSocket是基於Http協議的，或者說借用了Http協議來完成一部分握手，在握手階段與Http是相同的。
其他特點包括：
(1) 建立在 TCP 協議之上，服務器端的實現比較容易。
(2) 與 HTTP 協議有着良好的兼容性。默認端口也是80和443，並且握手階段採用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務器。
(3) 數據格式比較輕量，性能開銷小，通信高效。
(4) 可以發送文本，也可以發送二進制數據。
(5) 沒有同源限制，客戶端可以與任意服務器通信。
(6) 協議標識符是ws（如果加密，則爲wss），服務器網址就是 URL。
4 HTTP請求的方式
一共7種 針對HTTP/1.1
GET 獲取資源
POST 傳輸實體主體
PUT 傳輸文件
DELETE
HEAD 獲得報文首部 （HEAD和GET一樣，只是不返回報文主體部分，用於確認URI的有效性及資源更新的日期時間等。）
OPTIONS 詢問支持的方法
TRACE 讓服務器將之前的請求環回給客戶端，可以查詢發送出去的數據是怎樣被加工修改的 容易引起跨站追蹤攻擊
CONNECT 要求用隧道協議連接代理
5 圖片URL訪問後直接下載
服務器端 修改HTTP響應頭，告訴返回的是一個文件。設置content-disposition爲attachment，它是MIME協議的擴展，指示在客戶端瀏覽或顯示圖片的時候彈出下載框。同時注意跨域資源共享設置Access-Control-Allow-Origin爲*。
前端 設置a標籤的download屬性，但存在瀏覽器兼容性問題，而且href指向的地址必須與當前地址同源，否則會出現只能下載不能改名或者download屬性失效等問題。
6 BOM常見對象屬性
BOM(Browser Object Model) 是指瀏覽器對象模型，瀏覽器對象模型提供了獨立於內容的、可以與瀏覽器窗口進行互動的對象結構。BOM由多個對象組成，其中代表瀏覽器窗口的Window對象是BOM的頂層對象，其他對象都是該對象的子對象。
window對象有一個特殊屬性name ‘’
loaction對象 host域名 port端口 href返回/設置當前文檔的URL
history對象 back() forword() go()可前進/後退
Navigator對象 userAgent返回瀏覽器類型、版本信息等 cookieEnabled瀏覽器是否支持(啓用)cookie
7 http2.0
http2.0是基於1999年發佈的http1.0之後的首次更新
提升了訪問速度
允許多路複用 多路複用允許同時通過單一的連接發送多重請求-響應信息。改善了http1.1中瀏覽器客戶端在同一時間針對同一域名下的請求有一定數量限制，連接數量超過限制會被阻塞
二進制分幀 http2.0將所有的傳輸信息分割爲更小的信息或者幀，並對他們進行二進制編碼
首部壓縮
服務器推送 http2.0中服務器端可以在客戶端某個請求之後主動推送其他資源
更安全 禁用了幾百種不再安全的加密算法
8 http狀態碼
HTTP狀態碼錶示客戶端HTTP請求的返回結果，標記服務器端的處理是否正常、通知出現的錯誤等。
8.1 告知請求結果
狀態碼=3位數字+原因短語。數字第一位指定了響應類別，後兩位無分類。響應類別有5種。
| 數字 | 類別 | 原因短語 |
|---|---|---|
| 1XX | Informational(信息) | 接收的請求正在處理 |
| 2XX | Success(成功) | 請求正常處理完畢 |
| 3XX | Redirection(重定向) | 需要進行附加操作以完成請求 |
| 4XX | Client Error(客戶端錯誤狀態) | 服務器無法處理請求 |
| 5XX | Server Error(服務器錯誤狀態) | 服務器處理請求出錯 |
400 Bad Request
(1) 請求報文存在語法錯誤。需要修改內容再次發送請求。比如前後端字段類型沒有保持一致或者前端提交到後臺的數據不是JSON字符串，沒有使用JSON.stringify序列化
(2) 瀏覽器會像200 OK一樣對待該狀態碼。
401 Unauthorized
(1) 表示發送的請求需要有通過HTTP認證(BASIC認證、DIGEST認證)的認證信息。若之前已進行過一次請求，則表示用戶認證失敗。
(2) 返回含有401的響應必須包含一個適用於被請求資源的WWW-Authenticate首部以質詢用戶信息。瀏覽器初次收到401會彈出認證用的對話窗口。
403 Forbidden
(1) 請求資源的訪問被服務器拒絕了。
(2) 未獲得文件系統的訪問授權/從未授權的源IP試圖訪問等都可能是403發生的原因。
總之：401側重身份認證，403側重訪問權限
404 Not Found
(1) 無法找到請求的資源。
(2) 或者服務器端拒絕請求並且不想說明原因。
9 XSS和CSRF
參考 https://juejin.im/post/5c6d142151882503b3271f4b#comment
XSS跨站腳本攻擊，是一種代碼注入攻擊。攻擊者通過在目標網站上注入惡意腳本，使之在用戶的瀏覽器上運行。
分類：存儲型、反射型、DOM型
三者的惡意代碼存儲位置分別在後端數據庫，URL，後端數據庫/前端存儲/URL
前兩者屬於服務端的安全漏洞，後者觸發靠的是瀏覽器端的DOM解析
場景：打開URL都可能發生，特別是頁面跳轉等。只要有數據輸入的地方，就可能存在XSS危險。
防禦：
(1) httpOnly：在cookie中設置HttpOnly屬性後，js腳本將無法讀取到cookie信息。secure：這個屬性告訴瀏覽器僅僅在請求爲https的時候發送cookie。
(2) 輸入過濾：對於輸入格式進行檢查，比如郵箱電話等，不僅前端需要，後端也需要。
(3) 轉義HTML：對尖括號、斜槓、引號等進行轉義
(4) 白名單：過濾標籤等
預防存儲型/反射型(服務端取出惡意代碼插入到響應HTML中)：
改成純前端渲染，代碼和數據分開(靜態頁面+Ajax獲取數據+DOM API更新頁面)+對HTML做充分轉義
預防DOM型：
避免JavaScript代碼不夠嚴謹。使用.innerHTML、.outerHTML、document.write()要小心，儘量使用.textContent、setAttribute()等方法。eval()、setTimeout()等都能把字符串作爲代碼運行，要確保數據可信的前提再使用。
CSRF跨站請求僞造，是一種挾持用戶在當前已登錄的Web應用程序上執行非本意操作的攻擊方法。
(1) 登錄受信任網站A，並在本地生成Cookie。
(2) 在不登出A的情況下，訪問危險網站B。
場景：CSRF通常是跨域的，更容易被掌控。但在可以發圖的論壇和評論區，攻擊可以直接在本域中進行。
防禦：
(1) 驗證碼：強制用戶和應用進行交互。
(2) token驗證：服務器頒發token隨機數給客戶端under，發送請求時攜帶驗證。
總結
本質上講，XSS是代碼注入問題，CSRF是HTTP問題。XSS是內容沒有過濾導致的瀏覽器將攻擊者的輸入當作代碼執行。CSRF則是因爲瀏覽器在發送HTTP請求的時候自動帶上cookie，而一般網站的session都存在cookie裏面。(Token驗證可以避免)
10 Cookie和Session區別
Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。
Session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。
簡單地說，Cookies保存在客戶端，Session保存在服務端
當程序需要爲某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲session id），如果已包含則說明以前已經爲此客戶端創建過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含session id，則爲此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。
11 CORS
CORS定義了在訪問跨域資源的時候瀏覽器與服務器應該如何溝通，思想是使用自定義的HTTP頭部讓瀏覽器與服務器進行溝通。
瀏覽器：
(1) IE XDomainRequest Chrome、Firefox等 XMLHttpRequest
都是new然後定義onload(),open(),send(),XHR支持查看status、statusText屬性,也支持同步。
XDR：
不發送和返回cookie，只支持GET/POST，不能訪問響應頭部失敗則觸發error事件，只能設置頭部中的Content-Type字段。
跨域XHR：
不能發送和接受cookie,不能使用setRequestHeader()自定義頭部，調用getAllResponseHeaders()方法返回空字符串。
(2) 自定義頭部，GET/POST之外的方法，則附加額外的Origin頭部，包含請求頁面的源信息(協議、域名、端口)
Origin：http://www.nczonline.net
檢測XHR是否支持CORS，可檢測是否存在withCredentials屬性，再結合檢測XDR對象，就可兼顧所有瀏覽器了。
服務器：如果服務器認爲請求可接受，就在Access-Control-Allow-Origin頭部中回發相同信息，公共資源就用通配符。
XHR提交表單
xhr.setRequestHeader(‘Content-Type’,‘application/x-www-form-urlencoded’);
xhr.send(serialize(form));
12 圖層
一般可以把普通文檔流看作一個圖層，特定屬性可以生成一個新的圖層，不同圖層的渲染互不影響。
通常以下屬性可以生成一個新的圖層
(1) position:fixed
(2) video、frame標籤
(3) 通過動畫實現的opacity轉換
(4) 3D變換：translate3D、translateZ
重繪和迴流：
重繪是指當前節點需要更改外觀而不會影響佈局的，比如改變color。
迴流是指佈局或者幾何屬性需要改變。比如定位浮動盒子模型、改變window大小
requestAnimationFrame(callback)定義的是下次重繪之前要執行的動畫
減少迴流：
(1) 使用translate替代top這類偏移屬性。
(2) 使用visibility:hidden替代display:none,因爲後者引發了迴流。
(3) 不適用table佈局，可能很小的改動會引起table的重新佈局。
(4) 將頻繁運行的動畫變成圖層，圖層能夠阻止該節點回流影響別的元素。比如video標籤。
(5) 不把DOM節點的屬性值放在循環中，每次獲取offsetTop會導致迴流。
(6) 避免DOM層數過深。