請求相關總結（HTTP，跨域，安全）

時間 2019-11-29

原文原文鏈接

總結了一些前端請求相關知識。css

HTTP

大體的HTTP請求過程：前端

一、輸入Url，第一次登錄的時候會本地留一個cookie
二、查看緩存，包括瀏覽器->系統緩存->路由緩存，存在緩存則顯示
三、 DNS域名解析，解析域名得到IP地址，然後根據IP地址向服務器發起tcp連接，創建三次握手。
四、握手成功後瀏覽器向服務器發送http請求，請求數據包。
五、服務器處理請求返回數據
六、瀏覽器收到http響應而後處理數據，渲染頁面，包括dom樹，css,js等。vue

HTTPS 和 HTTPnode

HTTP+加密+認證+完整性保護 = HTTPS，HTTP協議採用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議TLS/SSL具備身份驗證、信息加密和完整性校驗的功能，能夠避免此類問題發生。
TLS/SSL全稱安全傳輸層協議Transport Layer Security, 是介於TCP和HTTP之間的一層安全協議，不影響原有的TCP協議和HTTP協議，因此使用HTTPS基本上不須要對HTTP頁面進行太多的改造。react

http狀態碼

1xx 信息響應webpack

100 Continue，這個臨時響應代表，迄今爲止的全部內容都是可行的，客戶端應該繼續請求，若是已經完成，則忽略它。

101 Switching Protocol，該代碼是響應客戶端的 Upgrade 標頭髮送的，而且指示服務器也正在切換的協議。

102 Processing (WebDAV)，此代碼表示服務器已收到並正在處理該請求，但沒有響應可用。

103 Early Hints ，此狀態代碼主要用於與Link 連接頭一塊兒使用，以容許用戶代理在服務器仍在準備響應時開始預加載資源。

2XX 成功響應（請求正常處理完畢）ios

200 OK，表示從客戶端發來的請求在服務器端被正確處理

201 Created，該請求已成功，並所以建立了一個新的資源。這一般是在POST請求，或是某些PUT請求以後返回的響應。

202 Accepted，請求已經接收到，但還沒有執行。和異步請求和批處理有關。

203 Non-Authoritative Information，此響應代碼表示返回的元信息與原始服務器提供的信息並不徹底相同，而是從本地或第三方副本中收集的。除該特定狀況外，200 響應優先於此狀態。

204 No content，表示請求成功，但響應報文不含實體的主體部分（可能經過頭部信息返回）

205 Reset Content，請求成功但沒有返回任何內容，要求請求者重置文檔視圖，一般用於重置表單。

206 Partial Content，從客戶端發送Range標頭僅請求資源的一部分時，將使用此響應代碼。

207 Multi-Status (WebDAV)

208 Multi-Status (WebDAV)

226 IM Used (HTTP Delta encoding)

3XX 重定向（須要進行附加操做以完成請求）nginx

300 Multiple Choice 有多種可能響應可選。

301 Moved Permanently，永久性重定向，表示資源已被分配了新的 URL

302 Found，臨時性重定向，應當繼續訪問此地址

303 See Other，表示資源存在着另外一個 URL，應使用 GET 方法定向獲取資源

304 Not Modified，表示服務器容許訪問資源，但資源和以前沒有改變

305 Use Proxy，被請求的資源必須經過指定的代理才能被訪問，只有原始服務器才能創建305響應

307 Temporary Redirect，臨時重定向，和302含義相同，區別是用戶不能改變請求方法。

308 Permanent Redirect，和301含義相同，區別也是用戶不能改變請求方法。

4XX 客戶端錯誤（服務器沒法處理請求）web

400 Bad Request，請求報文存在語法錯誤

401 Unauthorized，未認證，客戶端必須對本身進行身份驗證才能得到請求的響應

403 Forbidden，表示對請求資源的訪問被服務器拒絕（知道客戶端身份，且其無權訪問）

404 Not Found，表示在服務器上沒有找到請求的資源，一般是請求路徑錯誤。

405 Method Not Allowed 禁用的請求方法，通常遇到這種狀況是服務器配置問題。

406 Not Acceptable 沒有找到符合條件的內容，可是路徑是對的，好比request的Accept和response的Content-Type不匹配

407 Proxy Authentication Required 相似於401，但須要由代理進行身份驗證

408 Request Timeout ... 429,431,451 諸多不常見錯誤，參見MDN

5XX 服務器錯誤（服務器處理請求出錯）

500 internal sever error，表示服務器端在執行請求時發生了錯誤

501 Not Implemented，此請求方法不被服務器支持且沒法被處理。

502 bad getway，網關錯誤，好比沒起nginx，nginx掛了一類的

503 Service Unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求

504 Gateway Timeout，請求超時

505 HTTP Version Not Supported 服務器不支持請求中所使用的HTTP協議版本

50六、50七、50八、5十、511 更不常見，同上

請求方法

GET 方法，請求一個指定資源的表示形式. 使用GET的請求應該只被用於獲取數據.
HEAD 方法，請求一個與GET請求的響應相同的響應，但沒有響應體.
POST 方法，用於將實體提交到指定的資源，一般致使在服務器上的狀態變化或反作用.
PUT 方法，用請求有效載荷替換目標資源的全部當前表示。
DELETE 方法，刪除指定的資源。
CONNECT 方法，創建一個到由目標資源標識的服務器的隧道。
OPTIONS 方法，用於描述目標資源的通訊選項。
TRACE 方法，沿着到目標資源的路徑執行一個消息環回測試。
PATCH 方法，用於對資源應用部分修改。

請求超時

瀏覽器默認超時不一樣瀏覽器不一樣，和版本有影響，好比chrome 是4 分鐘，safari 12分鐘等。 http請求默認不會有超時，不少服務器會設置超時，如PHP服務默認的請求響應最長處理時間爲30s，若是超過30s，將會返回504，nginx 也能夠配置。axios npm 文檔支持配置參數設置timeout 並作攔截處理，拋錯等。whatwg-fetch是不支持超時設置的，能夠經過promise 改造等可是看來很差用，我的也沒用過。

常見協議對應端口：

Telnet：tcp 23
ssh：tcp 22
ftp：tcp 21
http：tcp 80
https：tcp 443
dns：tcp 53，udp 53

跨域

同源策略

同源須要：(<img><link><script>三種標籤不受限制)

協議相同
域名相同（子域名、主域名）端口號相同

同源策略限制內容有：

Cookie、LocalStorage、IndexedDB 等存儲性內容沒法讀取
DOM 沒法得到
AJAX 請求不能發送

跨域方法：

非ajax

設置document.domain
經過url hash段傳值
window.name
window.postMessage
...

ajax 跨域

JSONP

利用 <script> 標籤沒有跨域限制的漏洞，網頁能夠獲得從其餘來源動態產生的 JSON 數據。JSONP請求必定須要對方的服務器作支持才能夠。優勢是兼容老式瀏覽器，可是隻支持get並且不太安全，通常不用。

CORS

CORS （跨域資源共享 Cross-origin resource sharing）須要瀏覽器和後端同時支持。IE 8 和 9 須要經過 XDomainRequest 來實現。
瀏覽器端會自動向請求頭添加origin字段，代表當前請求來源。
服務器端須要設置響應頭的Access-Control-Allow-Methods，Access-Control-Allow-Headers，Access-Control-Allow-Origin等字段，指定容許的方法，頭部，源等信息。
請求分爲簡單請求和非簡單請求，非簡單請求會先進行一次OPTION方法進行預檢，看是否容許當前跨域請求。

node 中間層
nginx 代理，詳見下文
webpack 配置 proxy，好比vue 的proxyTable or devServer.proxy

配置proxy 寫法爲：

devServer: {
	proxy: 'http://localhost:4000' // 會將任何未知請求 (沒有匹配到靜態文件的請求) 代理到http://localhost:4000
}
一般會用對象模式增長更多可配置項目
proxy: {
  '/api': { //匹配路由
    target: 'http://www.example.org', // 目標主機
    changeOrigin: true//默認保留主機頭來源，設爲true 會覆蓋，跨域的時候須要如此設置
    ws: true,//代理websockets
    secure: false,// 若是須要支持https且證書無效的服務器
    pathRewrite: {
	    '^/api/old-path': '/api/new-path', // 重寫路徑，好比不但願傳遞/api
	    '^/api/remove/path': '/path' // 或者移除某基本路徑
	  },
  },
  '/foo': {//對另外一個路由的配置
    target: '<other_url>'
  }
}
複製代碼

CORS 簡單請求和非簡單請求：

簡單請求

請求方法是如下三種方法之一：

HEAD
GET
POST

HTTP的請求頭信息不超出如下幾種字段：

Accept
Accept-Language
Content-Language
Content-Type （須要注意額外的限制）
DPR
Downlink
Save-Data
Viewport-Width
Width

Content-Type：只限於三個值

application/x-www-form-urlencoded
multipart/form-data
text/plain

請求中的任意XMLHttpRequestUpload 對象均沒有註冊任何事件監聽器；XMLHttpRequestUpload 對象可使用 XMLHttpRequest.upload 屬性訪問。

請求中沒有使用 ReadableStream 對象。

後端的響應頭信息：

Access-Control-Allow-Origin：必須。請求時Origin字段的值，或者*，表示接受任意域名的請求。
Access-Control-Allow-Credentials：可選，只能設爲true，表示容許發送Cookie，這種狀況下Access-Control-Allow-Origin 設置不能是*，若是不容許發送cookie，可刪除此字段。
Access-Control-Expose-Headers：可選。CORS請求時，XMLHttpRequest對象的getResponseHeader()方法只能拿到6個基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。若是想拿到其餘字段，就必須在Access-Control-Expose-Headers裏面指定。

非簡單請求

非簡單請求是對服務器有特殊要求的請求，好比：

請求方法是PUT或DELETE，（或使用了CONNECT、OPTIONS、TRACE、PATCH）
Content-Type字段的類型是application/json
人爲設置了其餘首部字段。

非簡單請求的CORS請求，會在正式通訊以前，增長一次HTTP查詢請求，稱爲"預檢"請求（preflight）（OPTIONS）。

nginx 使用

nginx 經常使用功能：
反向代理，負載均衡，跨域配置，訪問限制，資源處理等。[基本配置解說] (www.nginx.cn/76.html )
可經過homebrew 安裝 brew install nginx，默認位於 /usr/local/etc/nginx，配置見nginx.conf，此配置最後 include servers/* ，在etc/nginx/servers文件夾下添加xxx.conf 文件內容會默認加到nginx.conf，能夠直觀的針對不一樣網站作不一樣配置。

經常使用命令：
sudo nginx -t //nginx 啓動測試，檢查配置是否正常，可否正常啓動
sudo nginx //啓動nginx
sudo nginx -s reload //從新啓動
nginx -s stop //關閉

代理，反向代理

代理是在服務器和客戶端之間假設的一層服務器，代理將接收客戶端的請求並將它轉發給服務器，而後將服務端的響應轉發給客戶端。

正向代理
將訪問服務器server的網頁請求，代理到一個能夠訪問該網站的代理服務器proxy，代理服務器proxy把服務器server上的網頁內容獲取，轉發給客戶。客戶端能夠根據正向代理訪問到它自己沒法訪問到的服務器資源
反向代理
指代理服務器，客戶端發送的請求，須要先發送到一個代理服務器proxy，經過proxy將請求發到和本身屬於同一個LAN下的內部服務器（一般多臺）。對服務端透明，對用戶非透明，也就是加不加代理用戶無感知，這樣用戶不能直接訪問真正的內容服務器，增長安全性，可作負載均衡，健康檢查，若是出問題將不會分配代理請求。

nginx 跨域配置

攔截local請求代理回server name 指定網址，瀏覽器使用 test.server.com 至關於 http://localhost:9997，這樣請求就是以 test.server.com 域名請求接口，達到同源訪問效果。

server {
    listen       80;
    server_name  test.server.com;
    location / {
            proxy_pass http://localhost:9997;
    }
}
# 若是https
server {
    listen       443 ssl;
    # https證書本地路徑
    ssl_certificate xxxx;
     ssl_certificate_key xxxx;
     
     # 連接超時設置
     keepalive_timeout   70; 
     
    server_name  test.server.com;
    location / {
            proxy_pass http://localhost:9997;
    }
}
複製代碼

網站安全

網站安全問題有不少可能，總結的防護措施：

永遠不要相信來自客戶端（用戶）的輸入，先後端都須要驗證過濾轉義用戶輸入，包括用戶上傳的文件須要作格式限制。輸出檢查轉義。
執行關鍵操做前必須驗證用戶身份，多階段功能的每一步都要驗證用戶身份。
對於直接對象引用，加密資源ID，以防止攻擊者對ID進行枚舉。本地存儲與接口參數的敏感信息更要加密處理，包括數據庫也是，不能把機密信息直接存放，加密或者 hash 掉密碼和敏感的信息。
不使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接，不使用動態拼裝 SQL，可使用參數化的 SQL或者直接使用存儲過程進行數據查詢存取，保護數據安全。
使用安全的第三方依賴。

我的上來講：注意密碼複雜度，不一樣網站儘可能不要重複，密碼中儘可能不要包括我的信息。謹慎點擊各種可疑連接，不要鏈接可疑wifi等。防止劫持、撞庫、釣魚這類操做。

XSS

即 Cross Site Script，中譯是跨站腳本攻擊；其本來縮寫是 CSS，但爲了和層疊樣式表(Cascading Style Sheet)有所區分，於是在安全領域叫作 XSS。
XSS 攻擊是指攻擊者在網站上注入惡意的客戶端代碼，經過惡意腳本對客戶端網頁進行篡改，從而在用戶瀏覽網頁時，對用戶瀏覽器進行控制或者獲取用戶隱私數據的一種攻擊方式。
攻擊者對客戶端網頁注入的惡意腳本通常包括 JavaScript，有時也會包含 HTML 和 Flash。有不少種方式進行 XSS 攻擊，但它們的共同點爲：將一些隱私數據像 cookie、session 發送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操做。

XSS攻擊能夠分爲3類：

反射型（非持久型）：誘使用戶點擊一個惡意連接，或者提交一個表單，或者進入一個惡意網站時，注入腳本進入被攻擊者的網站。好比經過覆蓋透明層加惡意連接，假裝接近的正常連接短信誘騙點擊等。
存儲型（持久型）：把用戶輸入的數據 "存儲" 在服務器端，當瀏覽器請求數據時，腳本從服務器上傳回並執行。這種 XSS 攻擊具備很強的穩定性。
比較常見的一個場景是攻擊者在社區或論壇上寫下一篇包含惡意 JavaScript 代碼的文章或評論，文章或評論發表後，全部訪問該文章或評論的用戶，都會在他們的瀏覽器中執行這段惡意的 JavaScript 代碼。
基於DOM：是指經過惡意腳本修改頁面的 DOM 結構，是純粹發生在客戶端的攻擊。

XSS的防範

HttpOnly 防止劫取 Cookie
輸入檢查用於對用戶輸入所包含的特殊字符或標籤進行編碼或過濾，這樣腳本就轉爲文本不會執行
輸出檢查通常來講，除富文本的輸出外，在變量輸出到 HTML 頁面時，可使用編碼或轉義的方式來防護 XSS 攻擊。例如利用 sanitize-html 對輸出內容進行有規則的過濾以後再輸出到頁面中，vue 和 react 自己是轉義的。

CSRF

CSRF，即 Cross Site Request Forgery，中譯是跨站請求僞造，是一種劫持受信任用戶向服務器發送非預期請求的攻擊方式。
好比借用戶的cookie騙取服務器信任，給服務器發送請求，這種不能解析cookie內容也不能竊取改變返回數據。常見狀況好比盜用用戶信息給本身轉帳；假裝管理員用戶增長管理員權限人員，以自由得到管理員權限；重置帳號修改成本身信息等等。
防範：

使用驗證碼，在請求前加上用戶交互，可是顯然不能全部請求都這麼作。
對http 頭作Referer Check，能夠檢查請求是否來自合法的」源」。
在http請求中加入與cookie無關的token驗證。當用戶第一次進行登陸的時候，客戶端會經過用戶名和密碼去請求服務器登陸，服務端在收到請求後會驗證客戶端傳來的用戶名和密碼，若是驗證經過，服務器就會簽發一個token發給客戶端，而且將token放到session或者報文中，客戶端收到token後存儲到本地，之後客戶端只要每次請求服務器就要帶上token，通過服務器驗證經過後纔會返回響應數據，不然報錯。