1.TCP/IP的三次握手和四次揮手

• 三次握手:   
  第一次握手：客戶端向服務端傳送SYN碼資料包，表示客戶端要求和服務端建立連線；
  第二次握手：服務端收到客戶端的連線請求後，會發送ACK資料包給客戶端，表示你的連線 請求已經收到，詢問客戶端是否真的需要建立連線；
  第三次握手：客戶端收到ACK碼以後會檢驗是否正確，如果正確，客戶端會再次傳送ACK碼給 服務端，表示確認建立連線； (三次握手都成功以後才會建立連線，然後才會傳送資料；)
• 四次揮手：
  第一次揮手：當客戶端傳送資料結束後，會發送FIN碼資料包給服務端，表示告知服務端客 戶端的資料已經傳遞完了。
  第二次揮手：當服務端收到FIN後，會發送ACK給客戶端，表示服務端已經知道客戶端傳完 了。客戶端收到ACK以後就會把傳遞資料給服務端的通道關閉；
  第三次揮手：當服務端把響應的資料傳送完畢後，會發送一個FIN給客戶端，告知客戶端響 應的資料已經發送完畢；
  第四次揮手：當客戶端收到FIN後，會發送一個ACK碼資料包給服務端，告知服務端客戶端已 經知道資料傳送完畢；服務端收到ACK碼後，可以安心的把資料傳遞通道關閉掉。

2.HTTPS和HTTP的區別主要如下?

• HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全。
  1、https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
  2、http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
  3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
  4、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。

• https主要解決三個安全問題：
  1.內容隱私
  2.防篡改
  3.確認對方身份

https並不是直接通過非對稱加密傳輸過程，而是有握手過程，握手過程主要是和伺服器做通訊，生成私有祕鑰，最後通過該祕鑰對稱加密傳輸資料。
還有驗證證書的正確性。 證書驗證過程保證了對方是合法的，並且中間人無法通過偽造證書方式進行攻擊。

3.從瀏覽器輸入URL按回車到頁面顯示都發生了什麼?

•瀏覽器根據URL進行DNS查詢
•首先從DNS快取中查詢
•若未在快取中找到，則不停的向上一級級請求DNS伺服器
•取得IP地址，建立TCP連線
•構造HTTP請求報
•新增一些HTTP首部
•根據同源策略新增cookie
•在TCP連線上傳送HTTP報文，等待響應
•伺服器處理HTTP請求報文，返回響應HTTP響應報文
•瀏覽器處理伺服器返回的HTTP響應報文，若為HTML則渲染頁面，不包括指令碼的簡單渲染流程如下

1.解析DOM、CSSOM
2.根據DOM、CSSOM計算render tree
3.根據render tree進行layout
4.paint，至此，使用者可以看到頁面了

4.瀏覽器快取？

強快取：不會向伺服器傳送請求，直接從快取中讀取資源，在chrome控制檯的Network選項中可以看到該請求返回200的狀態碼，
並且Size顯示from disk cache或from memory cache。強快取可以通過設定兩種 HTTP Header 實現：Expires 和 Cache-Control。

協商快取：就是強制快取失效後，瀏覽器攜帶快取標識向伺服器發起請求，由伺服器根據快取標識決定是否使用快取的過程，主要有以下兩種情況：
協商快取生效，返回304和Not Modified
協商快取失效，返回200和請求結果協商快取可以通過設定兩種 HTTP Header 實現：Last-Modified 和 ETag 。


強制快取優先於協商快取進行，若強制快取(Expires和Cache-Control)生效則直接使用快取，若不生效則進行協商快取(Last-Modified / If-Modified-Since和Etag / If-None-Match)，協商快取由伺服器決定是否使用快取，若協商快取失效，那麼代表該請求的快取失效，返回200，重新返回資源和快取標識，再存入瀏覽器快取中；生效則返回304，繼續使用快取。

5.ajax四步

1. 建立 XMLHttpRequest 物件,也就是建立一個非同步呼叫物件
2. 建立一個新的 HTTP 請求,並指定該 HTTP 請求的方法、URL 及驗證資訊
3. 設定響應 HTTP 請求狀態變化的函式
4. 傳送 HTTP 請求
   你使用過哪些ajax?
   從原生的XHR到jquery ajax，再到現在的axios和fetch。
   axios和fetch都是基於Promise的，一般我們在使用時都會進行二次封裝
   講到fetch跟jquery ajax的區別，這也是它很奇怪的地方
   當接收到一個代表錯誤的 HTTP 狀態碼時，從 fetch()返回的 Promise 不會被標記為 reject， 即使該 HTTP 響應的狀態碼是 404 或 500。相反，它會將 Promise 狀態標記為 resolve （但是會將 resolve 的返回值的 ok 屬性設定為 false ）， 僅當網路故障時或請求被阻止時，才會標記為 reject。 預設情況下, fetch 不會從服務端傳送或接收任何 cookies, 如果站點依賴於使用者 session，則會導致未經認證的請求（要傳送 cookies，必須設定 credentials 選項）

一般我們再攔截器中都會寫什麼程式碼？
請求攔截中我們一半會把token寫在這裡，這樣的話就不用每次請求都要寫這個引數
還會做一個數據格式的處理，假如某個引數需要統一處理 可以放在這裡，
響應攔截一半會做一個判斷 請求失敗的話直接呼叫失敗提示框 這樣不用每個介面都寫同樣的程式碼
也會再return時 return reponse.data;這樣就可以不用每個資料接受的時候都加一個data.data

get請求和post請求有什麼區別？什麼時候使用post?

GET：一般用於資訊獲取，使用 URL 傳遞引數，對所傳送資訊的數量也有限制，一般在 2000 個字元
  POST：一般用於修改伺服器上的資源，對所傳送的資訊沒有限制  
在以下情況中，請使用 POST 請求： 1. 無法使用快取檔案（更新伺服器上的檔案或資料庫） 2. 向伺服器傳送大量資料（POST 沒有資料量限制） 3. 傳送包含未知字元的使用者輸入時，POST 比 GET 更穩定也更可靠
實際上HTTP 協議從未規定 GET/POST 的請求長度限制是多少。對get請求引數的限制是來源與瀏覽器或web伺服器，瀏覽器或web伺服器限制了url的長度。為了明確這個概念，我們必須再次強調下面幾點:
1、HTTP 協議 未規定 GET 和POST的長度限制
2、GET的最大長度顯示是因為 瀏覽器和 web伺服器限制了 URI的長度
3、不同的瀏覽器和WEB伺服器，限制的最大長度不一樣
4、要支援IE，則最大長度為2083byte，若只支援Chrome，則最大長度 8182byte

Cookie 和 Session 的區別?

• 安全性： Session 比 Cookie 安全，Session 是儲存在伺服器端的，Cookie 是儲存在客戶端的。
• 存取值的型別不同：Cookie 只支援存字串資料，想要設定其他型別的資料，需要將其轉換成字串，Session 可以存任意資料型別。
• 有效期不同： Cookie 可設定為長時間保持，比如我們經常使用的預設登入功能，Session 一般失效時間較短，客戶端關閉（預設情況下）或者 Session 超時都會失效。
• 儲存大小不同： 單個 Cookie 儲存的資料不能超過 4K，Session 可儲存資料遠高於 Cookie，但是當訪問量過多，會佔用過多的伺服器資源。

Token 相關？

1. 客戶端使用使用者名稱跟密碼請求登入
2. 服務端收到請求，去驗證使用者名稱與密碼
3. 驗證成功後，服務端會簽發一個 token 並把這個 token 傳送給客戶端
4. 客戶端收到 token 以後，會把它儲存起來，比如放在 cookie 裡或者 localStorage 裡
5. 客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 token
6. 服務端收到請求，然後去驗證客戶端請求裡面帶著的 token ，如果驗證成功，就向客戶端返回請求的資料

• 每一次請求都需要攜帶 token，需要把 token 放到 HTTP 的 Header 裡
• 基於 token 的使用者認證是一種服務端無狀態的認證方式，服務端不用存放 token 資料。用解析 token 的計算時間換取 session 的儲存空間，從而減輕伺服器的壓力，減少頻繁的查詢資料庫
• token 完全由應用管理，所以它可以避開同源策略

什麼是同源策略？

同源策略是客戶端指令碼（尤其是 Javascript）的重要的安全度量標準。其目的是防止某個文件或指令碼從多個不同源裝載。
 這裡的同源策略指的是：協議，域名，埠相同，同源策略是一種安全協議，指一段指令碼只能讀取來自同一來源的視窗和文件的屬性。

為什麼要有同源限制？

我們舉例說明：比如一個黑客程式，他利用 Iframe 把真正的銀行登入頁面嵌到他的頁面上，當你使用真實的使用者名稱，密碼登入時，他的頁面就可以通過 Javascript 讀取到你的表單中 input 中的內容，這樣使用者名稱，密碼就輕鬆到手了

工作中是怎麼解決跨域的？

1.jsonp

1. JSONP原理
   利用 <script> 標籤沒有跨域限制的漏洞，網頁可以得到從其他來源動態產生的 JSON 資料。JSONP請求一定需要對方的伺服器做支援才可以。

2.cors
CORS 需要瀏覽器和後端同時支援。瀏覽器會自動進行 CORS 通訊，實現 CORS 通訊的關鍵是後端。只要後端實現了 CORS，就實現了跨域。服務端設定 Access-Control-Allow-Origin 就可以開啟 CORS。

3.proxy代理 （適用於本地開發）
。。。（其他的方式 可自行去掘金上搜 9種跨域的方式）
• CORS支援所有型別的HTTP請求，是跨域HTTP請求的根本解決方案
• JSONP只支援GET請求，JSONP的優勢在於支援老式瀏覽器，以及可以向不支援CORS的網站請求資料。
• 不管是Node中介軟體代理還是nginx反向代理，主要是通過同源策略對伺服器不加限制。
• 日常工作中，用得比較多的跨域方案是cors和nginx反向代理

XSS和CSRF區別

跨站指令碼攻擊（Cross Site Scripting)，為了不和層疊樣式表 CSS 混淆，故將跨站指令碼攻擊縮寫為 XSS。惡意攻擊者往 Web 頁面裡插入惡意 Script 程式碼，當用戶瀏覽該頁之時，嵌入其中 Web 裡面的 Script 程式碼會被執行，從而達到惡意攻擊使用者的目的。
跨站請求偽造（Cross-site request forgery），是偽造請求，冒充使用者在站內的正常操作。我們知道，絕大多數網站是通過 cookie 等方式辨識使用者身份，再予以授權的。所以要偽造使用者的正常操作，最好的方法是通過 XSS 或連結欺騙等途徑，讓使用者在本機（即擁有身份 cookie 的瀏覽器端）發起使用者所不知道的請求。

區別：
原理不同，CSRF是利用網站A本身的漏洞，去請求網站A的api；XSS是向目標網站注入JS程式碼，然後執行JS裡的程式碼。
CSRF需要使用者先登入目標網站獲取cookie，而XSS不需要登入
CSRF的目標是使用者，XSS的目標是伺服器
XSS是利用合法使用者獲取其資訊，而CSRF是偽造成合法使用者發起請求
XSS 攻擊的防範
現在主流的瀏覽器內建了防範 XSS 的措施，例如 CSP。但對於開發者來說，也應該尋找可靠的解決方案來防止 XSS 攻擊。
HttpOnly 防止劫取 Cookie
HttpOnly 最早由微軟提出，至今已經成為一個標準。瀏覽器將禁止頁面的Javascript 訪問帶有 HttpOnly 屬性的Cookie。
上文有說到，攻擊者可以通過注入惡意指令碼獲取使用者的 Cookie 資訊。通常 Cookie 中都包含了使用者的登入憑證資訊，攻擊者在獲取到 Cookie 之後，
則可以發起 Cookie 劫持攻擊。所以，嚴格來說，HttpOnly 並非阻止 XSS 攻擊，而是能阻止 XSS 攻擊後的 Cookie 劫持攻擊。
輸入檢查
不要相信使用者的任何輸入。 對於使用者的任何輸入要進行檢查、過濾和轉義。建立可信任的字元和 HTML 標籤白名單，對於不在白名單之列的字元或者標籤進行過濾或編碼。
在 XSS 防禦中，輸入檢查一般是檢查使用者輸入的資料中是否包含 <，> 等特殊字元，如果存在，則對特殊字元進行過濾或編碼，這種方式也稱為 XSS Filter。
而在一些前端框架中，都會有一份 decodingMap， 用於對使用者輸入所包含的特殊字元或標籤進行編碼或過濾，如 <，>，script，防止 XSS 攻擊
輸出檢查
使用者的輸入會存在問題，服務端的輸出也會存在問題。一般來說，除富文字的輸出外，在變數輸出到 HTML 頁面時，可以使用編碼或轉義的方式來防禦 XSS 攻擊。例如利用 sanitize-html對輸出內容進行有規則的過濾之後再輸出到頁面中。