摘要：從前發送請求后需等待并收到響應，才能發送下一個請求。第二次握手接收到包后就返回一個，隨機數，包以及一個自己的包，然后等待的回復，進入狀態已接收狀態。

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用于從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。
HTTP 是基于 TCP/IP 協議通信協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。它不涉及數據包（packet）傳輸，主要規定了客戶端和服務器之間的通信格式，默認使用80端口
總結：建立了TCP連接，就可以基于http協議在服務端與客戶端之間傳遞數據

簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、PUT、DELETE、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快

靈活：HTTP允許傳輸任意類型的數據對象。

無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。

無狀態：HTTP協議是無狀態的，HTTP 協議自身不對請求和響應之間的通信狀態進行保存。任何兩次請求之間都沒有依賴關系。直觀地說，就是每個請求都是獨立的，與前面的請求和后面的請求都是沒有直接聯系的。協議本身并不保留之前一切的請求或 響應報文的信息。這是為了更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設計成如此簡單的。

請求報文包括4個部分

請求行（request line）

請求頭（header）

空行

請求體

請求行

請求行包括3個部分,用來說明請求類型,要訪問的資源以及所使用的HTTP版本

請求方法

請求url

http及版本

POST  /taobao.com/index.html HTTP/1.1

請求頭

由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。
Host，表示主機名，虛擬主機；
Connection,HTTP/1.1增加的，使用keepalive，即持久連接，一個連接可以發多個請求；
User-Agent，請求發出者，兼容性以及定制化需求。

空行

最后一個請求頭之后是一個空行，這個行非常重要，它表示請求頭已經結束，接下來的是請求正文。

請求體

可以承載多個請求參數的數據

name=tom&password=1234&realName=tomson

響應報文包括4個部分

狀態行

響應頭部

空行

響應體

狀態行

Status Code: 200 

響應頭部

響應體

GET 請求指定的頁面信息，并返回實體主體。

HEAD 類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭

POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。

PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。

DELETE 請求服務器刪除指定的頁面。

GET在瀏覽器回退時是無害的，而POST會再次提交請求

GET請求會被瀏覽器主動緩存，而POST不會，除非手動設置

GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留

GET請求在URL中傳送的參數是有長度限制的，而POST沒有限制

GET參數通過URL傳遞，POST放在Request body中

1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。以當年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題。可隨著 HTTP 的 普及，文檔中包含大量圖片的情況多了起來。比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請 求該 HTML 頁面里包含的其他資源。因此，每次的請求都會造成無謂的 TCP 連接建立和斷開，增加通信量的 開銷。

為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。

持久連接使得多數請求以管線化（pipelining）方式發送成為可能。從前發送請求后需等待并收到響應，才能 發送下一個請求。管線化技術出現后，不用等待響應亦可直接發送下一個請求。
這樣就能夠做到同時并行發送多個請求，而不需要一個接一個地等待響應了。通俗地講，請求打包一次傳輸過去，響應打包一次傳遞回來。管線化的前提是在持久連接下。

假如當請求一個包含 10 張圖片的 HTML Web 頁面，與挨個連接相比，用持久連接可以讓請求更快結束。 而管線化技術則比持久連接還要快。請求數越多，時間差就越明顯。客戶端需要請求這十個資源。以前的做法是，在同一個TCP連接里面，先發送A請求，然后等待服務器做出回應，收到后再發出B請求，以此類推，而管道機制則是允許瀏覽器同時發出這十個請求，但是服務器還是按照順序，先回應A請求，完成后再回應B請求。

于是在使用持久連接的情況下，某個連接上消息的傳遞類似于

請求1->響應1->請求2->響應2->請求3->響應3

管線化方式發送變成了類似這樣：

請求1->請求2->請求3->響應1->響應2->響應3

https://github.com/ljianshu/B...

在第一次通信過程中，A向B發送信息之后，B收到信息后可以確認自己的收信能力和A的發信能力沒有問題。

在第二次通信中，B向A發送信息之后，A可以確認自己的發信能力和B的收信能力沒有問題，但是B不知道自己的發信能力到底如何，所以就需要第三次通信。

在第三次通信中，A向B發送信息之后，B就可以確認自己的發信能力沒有問題。

持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外， 減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。
在 HTTP/1.1 中，所有的連接默認都是持久連接，但在 HTTP/1.0 內并未標準化。雖然有一部分服務器通過非 標準的手段實現了持久連接，但服務器端不一定能夠支持持久連接。毫無疑問，除了服務器端，客戶端也需 要支持持久連接。

client發送一個SYN(J)包給server，然后等待server的ACK回復，進入SYN-SENT狀態(syn已發送狀態)。p.s: SYN為synchronize的縮寫，理解為序列號，其實就是一個隨機數，ACK為acknowledgment的縮寫，理解為確認號。

server接收到SYN(seq=J)包后就返回一個ACK(J+1)，隨機數+1，包以及一個自己的SYN(K)包，然后等待client的ACK回復，server進入SYN-RECIVED狀態(syn已接收狀態)。

client接收到server發回的ACK(J+1)包后，進入ESTABLISHED狀態(建立連接狀態)。然后根據server發來的SYN(K)包，返回給等待中的server一個ACK(K+1)包。等待中的server收到ACK回復，也把自己的狀態設置為ESTABLISHED。到此TCP三次握手完成，client與server可以正常進行通信了。

https://juejin.im/post/5a7835...

FIN：希望斷開連接

client發送一個FIN(M)包，此時client進入FIN-WAIT-1狀態（終止等待1），這表明client已經沒有數據要發送了。

server收到了client發來的FIN(M)包后，向client發回一個ACK(M+1)包，此時server進入CLOSE-WAIT狀態(關閉等待)，client進入FIN-WAIT-2狀態(終止等待2)。

server向client發送FIN(N)包，請求關閉連接，同時server進入LAST-ACK狀態(最后確認)。

client收到server發送的FIN(N)包，進入TIME-WAIT狀態(時間等待)。向server發送ACK(N+1)包，server收到client的ACK(N+1)包以后，進入CLOSE狀態；client等待一段時間還沒有得到回復后判斷server已正式關閉，進入CLOSE狀態。

https://blog.csdn.net/qq_3895...

同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，瀏覽器很容易受到XSS、CSRF等攻擊。所謂同源是指"協議+域名+端口"三者相同，即便兩個不同的域名指向同一個ip地址，也非同源。

同源策略限制內容有

Cookie、LocalStorage、IndexedDB 等存儲性內容

DOM 節點

AJAX 請求發送后，結果被瀏覽器攔截了

但是有三個標簽是允許跨域加載資源

/g, ">")
  str = str.replace(/"/g, "&quto;")
  str = str.replace(/"/g, "'")
  str = str.replace(/`/g, "`")
  str = str.replace(///g, "/")
  return str
}

但是對于顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因為這樣會把需要的格式也過濾掉。對于這種情況，通常采用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標簽和標簽屬性實在太多，更加推薦使用白名單的方式。

const xss = require("xss")
let html = xss("
XSS Demo
")
console.log(html)   // -> 
XSS Demo

以上示例使用了 js-xss 來實現，可以看到在輸出中保留了 h1 標簽且過濾了 script 標簽。

3. HttpOnly Cookie。
這是預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

CSRF(Cross Site Request Forgery)，即跨站請求偽造
它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。

完成 CSRF 攻擊必須要有三個條件

用戶已經登錄了站點 A，并在本地記錄了 cookie

在用戶沒有登出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。

站點 A 沒有做任何 CSRF 防御

例子： 當我們登入轉賬頁面后，突然眼前一亮驚現"XXX隱私照片，不看后悔一輩子"的鏈接，耐不住內心躁動，立馬點擊了該危險的網站（頁面代碼如下圖所示），但當這頁面一加載，便會執行submitForm這個方法來提交轉賬請求，從而將10塊轉給黑客。

防范 CSRF 攻擊可以遵循以下幾種規則

Get 請求不對數據進行修改

不讓第三方網站訪問到用戶 Cookie

阻止第三方網站請求接口

請求時附帶驗證信息，比如驗證碼或者 Token

1.SameSite

可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送，可以很大程度減少 CSRF 的攻擊，但是該屬性目前并不是所有瀏覽器都兼容。

2. Referer Check

HTTP Referer是header的一部分，當瀏覽器向web服務器發送請求時，一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的，服務器籍此可以獲得一些信息用于處理。可以通過檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。

但在某些情況下如從https跳轉到http，瀏覽器處于安全考慮，不會發送referer，服務器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那么攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出于以上原因，無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。

3. Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，并在服務器建立一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。

這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產生并放于session或cookie中，然后在每次請求時服務器把token從session或cookie中拿出，與本次請求中的token 進行比對。由于token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。

4.驗證碼
應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設置驗證碼。

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中，并將 iframe 設置為透明，在頁面中透出一個按鈕誘導用戶點擊。

隱蔽性較高，騙取用戶操作

"UI-覆蓋攻擊"

利用iframe或者其它標簽的屬性

用戶在登陸 A 網站的系統后，被攻擊者誘惑打開第三方網站，而第三方網站通過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），實際上是點擊了 A 網站的按鈕。
接下來我們舉個例子：我在優酷發布了很多視頻，想讓更多的人關注它，就可以通過點擊劫持來實現

    
    
    
    
    



    點擊脫衣
    

    
Password: 
    

這是我們經常見到的登錄頁面，但如果有一個惡意攻擊者輸入的用戶名是 admin" --，密碼隨意輸入，就可以直接登入系統了。why! ----這就是SQL注入

我們之前預想的SQL 語句是:

SELECT * FROM user WHERE username="admin" AND password="123456"

但是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了如下形式：

SELECT * FROM user WHERE username="admin" -- AND password = "123456"

在 SQL 中," --是閉合和注釋的意思，-- 是注釋后面的內容的意思，所以查詢語句就變成了

SELECT * FROM user WHERE username="admin"

嚴格限制Web應用的數據庫的操作權限，給此用戶提供僅僅能夠滿足其工作的最低權限，從而最大限度的減少注入攻擊對數據庫的危害

后端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。

對進入數據庫的特殊字符（"，"，，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上所有的后端語言都有對字符串進行轉義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫。

所有的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 占位參數。

https://blog.csdn.net/zhangha...
https://juejin.im/post/5c737a...

https://www.oschina.net/trans...

https://mp.weixin.qq.com/s?__...

代理

判斷pc還是移動端

二級域名(一個端口對應一個二級域名)

gzip

過濾，禁止某些ip仿問

負載均衡

https