文章目錄
1.TCP/IP的三次握手和四次揮手
2.http常用狀態碼(http-status-code):
3.從瀏覽器輸入URL按回車到頁面顯示都發生了什麼?
4.HTTPS和HTTP的區別主要如下?
5.瀏覽器緩存
強緩存：不會向服務器發送請求，直接從緩存中讀取資源，在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，繼續使用緩存。
6.ajax四步
- 創建 XMLHttpRequest 對象,也就是創建一個異步調用對象
- 創建一個新的 HTTP 請求,並指定該 HTTP 請求的方法、URL 及驗證信息
- 設置響應 HTTP 請求狀態變化的函數
- 發送 HTTP 請求
-
![]()
XMLHttpRequest通用屬性和方法
readyState:表示請求狀態的整數，取值：
- UNSENT（0）：對象已創建
- OPENED（1）：open()成功調用，在這個狀態下，可以爲xhr設置請求頭，或者使用send()發送請求
- HEADERS_RECEIVED(2)：所有重定向已經自動完成訪問，並且最終響應的HTTP頭已經收到
- LOADING(3)：響應體正在接收
- DONE(4)：數據傳輸完成或者傳輸產生錯誤
onreadystatechange：readyState改變時調用的函數status：服務器返回的HTTP狀態碼（如，200， 404）statusText:服務器返回的HTTP狀態信息（如，OK，No Content）responseText:作爲字符串形式的來自服務器的完整響應responseXML: Document對象，表示服務器的響應解析成的XML文檔abort():取消異步HTTP請求getAllResponseHeaders(): 返回一個字符串，包含響應中服務器發送的全部HTTP報頭。每個報頭都是一個用冒號分隔開的名/值對，並且使用一個回車/換行來分隔報頭行getResponseHeader(headerName):返回headName對應的報頭值open(method, url, asynchronous [, user, password]):初始化準備發送到服務器上的請求。method是HTTP方法，不區分大小寫；url是請求發送的相對或絕對URL；asynchronous表示請求是否異步；user和password提供身份驗證setRequestHeader(name, value):設置HTTP報頭send(body):對服務器請求進行初始化。參數body包含請求的主體部分，對於POST請求爲鍵值對字符串；對於GET請求，爲null
你使用過哪些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寫在這裏，這樣的話就不用每次請求都要寫這個參數
還會做一個數據格式的處理，假如某個參數需要統一處理 可以放在這裏
//設置請求攔截器
//TOKEN校驗（JWT）:接收服務器返回的token，存儲到vuex/本地存儲中，每一次向服務器發請求時，都把token帶上
axios.interceptor.request.use(config => {
let token = localStorage.getItem('token');
token && (config.headers.Authorization = token);
return config;
}, error => {
return Promise.reject(error)l
});
響應攔截一半會做一個判斷 請求失敗的話直接調用失敗提示框 這樣不用每個接口都寫同樣的代碼
也會在return時 return reponse.data;這樣就可以不用每個數據接受的時候都加一個data.data
//響應攔截器
axios.interceptors.response.use(response => {
return response.data;
}, error => {});
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
web開發中會話跟蹤的方法有哪些
- cookie
- session
- url重寫
- 隱藏input
- ip地址
Cookie 和 Session 的區別?
（見計算機網絡專欄）
• 安全性： Session 比 Cookie 安全，Session 是存儲在服務器端的，Cookie 是存儲在客戶端的。
• 存取值的類型不同：Cookie 只支持存字符串數據，想要設置其他類型的數據，需要將其轉換成字符串，Session 可以存任意數據類型。
• 有效期不同： Cookie 可設置爲長時間保持，比如我們經常使用的默認登錄功能，Session 一般失效時間較短，客戶端關閉（默認情況下）或者 Session 超時都會失效。
• 存儲大小不同： 單個 Cookie 保存的數據不能超過 4K，Session 可存儲數據遠高於 Cookie，但是當訪問量過多，會佔用過多的服務器資源。
Token 相關？
- 客戶端使用用戶名跟密碼請求登錄
- 服務端收到請求，去驗證用戶名與密碼
- 驗證成功後，服務端會簽發一個 token 並把這個 token 發送給客戶端
- 客戶端收到 token 以後，會把它存儲起來，比如放在 cookie 裏或者 localStorage 裏
- 客戶端每次向服務端請求資源的時候需要帶着服務端簽發的 token
- 服務端收到請求，然後去驗證客戶端請求裏面帶着的 token ，如果驗證成功，就向客戶端返回請求的數據
• 每一次請求都需要攜帶 token，需要把 token 放到 HTTP 的 Header 裏
• 基於 token 的用戶認證是一種服務端無狀態的認證方式，服務端不用存放 token 數據。用解析 token 的計算時間換取 session 的存儲空間，從而減輕服務器的壓力，減少頻繁的查詢數據庫
• token 完全由應用管理，所以它可以避開同源策略
什麼是同源策略？
同源策略：協議，域名，端口相同，同源策略是一種安全協議，指一段腳本只能讀取來自同一來源的窗口和文檔的屬性。
爲什麼要有同源限制？ 目的是防止某個文檔或腳本從多個不同源裝載。
我們舉例說明：比如一個黑客程序，他利用 Iframe 把真正的銀行登錄頁面嵌到他的頁面上，當你使用真實的用戶名，密碼登錄時，他的頁面就可以通過 Javascript 讀取到你的表單中 input 中的內容，這樣用戶名，密碼就輕鬆到手了
工作中是怎麼解決跨域的？
-
jsonp
-
CORS
-
proxy代理 （適用於本地開發）
-
frame也能忽略域的影響，可以在自己的頁面裏，把百度嵌入進來
必須主域相同，子域不同
總結：
• 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 對輸出內容進行有規則的過濾之後再輸出到頁面中。