摘要：從前發(fā)送請(qǐng)求后需等待并收到響應(yīng)，才能發(fā)送下一個(gè)請(qǐng)求。第二次握手接收到包后就返回一個(gè)，隨機(jī)數(shù)，包以及一個(gè)自己的包，然后等待的回復(fù)，進(jìn)入狀態(tài)已接收狀態(tài)。

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

簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、PUT、DELETE、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快

靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。

無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)的，HTTP 協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。任何兩次請(qǐng)求之間都沒(méi)有依賴關(guān)系。直觀地說(shuō)，就是每個(gè)請(qǐng)求都是獨(dú)立的，與前面的請(qǐng)求和后面的請(qǐng)求都是沒(méi)有直接聯(lián)系的。協(xié)議本身并不保留之前一切的請(qǐng)求或 響應(yīng)報(bào)文的信息。這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性，而特意把 HTTP 協(xié)議設(shè)計(jì)成如此簡(jiǎn)單的。

請(qǐng)求報(bào)文包括4個(gè)部分

請(qǐng)求行（request line）

請(qǐng)求頭（header）

空行

請(qǐng)求體

請(qǐng)求行

請(qǐng)求行包括3個(gè)部分,用來(lái)說(shuō)明請(qǐng)求類型,要訪問(wèn)的資源以及所使用的HTTP版本

請(qǐng)求方法

請(qǐng)求url

http及版本

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

請(qǐng)求頭

由關(guān)鍵字/值對(duì)組成，每行一對(duì)，關(guān)鍵字和值用英文冒號(hào)“:”分隔。
Host，表示主機(jī)名，虛擬主機(jī)；
Connection,HTTP/1.1增加的，使用keepalive，即持久連接，一個(gè)連接可以發(fā)多個(gè)請(qǐng)求；
User-Agent，請(qǐng)求發(fā)出者，兼容性以及定制化需求。

空行

最后一個(gè)請(qǐng)求頭之后是一個(gè)空行，這個(gè)行非常重要，它表示請(qǐng)求頭已經(jīng)結(jié)束，接下來(lái)的是請(qǐng)求正文。

請(qǐng)求體

可以承載多個(gè)請(qǐng)求參數(shù)的數(shù)據(jù)

name=tom&password=1234&realName=tomson

響應(yīng)報(bào)文包括4個(gè)部分

狀態(tài)行

響應(yīng)頭部

空行

響應(yīng)體

狀態(tài)行

Status Code: 200 

響應(yīng)頭部

響應(yīng)體

GET 請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。

HEAD 類似于get請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭

POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。

PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。

DELETE 請(qǐng)求服務(wù)器刪除指定的頁(yè)面。

GET在瀏覽器回退時(shí)是無(wú)害的，而POST會(huì)再次提交請(qǐng)求

GET請(qǐng)求會(huì)被瀏覽器主動(dòng)緩存，而POST不會(huì)，除非手動(dòng)設(shè)置

GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留

GET請(qǐng)求在URL中傳送的參數(shù)是有長(zhǎng)度限制的，而POST沒(méi)有限制

GET參數(shù)通過(guò)URL傳遞，POST放在Request body中

1xx：指示信息--表示請(qǐng)求已接收，繼續(xù)處理
2xx：成功--表示請(qǐng)求已被成功接收、理解、接受
3xx：重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
4xx：客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

HTTP協(xié)議的初始版本中，每進(jìn)行一次HTTP通信就要斷開一次TCP連接。以當(dāng)年的通信情況來(lái)說(shuō)，因?yàn)槎际切┤萘亢苄〉奈谋緜鬏?，所以即使這樣也沒(méi)有多大問(wèn)題?？呻S著 HTTP 的 普及，文檔中包含大量圖片的情況多了起來(lái)。比如，使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML 頁(yè)面時(shí)，在發(fā)送請(qǐng)求訪問(wèn) HTML 頁(yè)面資源的同時(shí)，也會(huì)請(qǐng) 求該 HTML 頁(yè)面里包含的其他資源。因此，每次的請(qǐng)求都會(huì)造成無(wú)謂的 TCP 連接建立和斷開，增加通信量的 開銷。

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

持久連接使得多數(shù)請(qǐng)求以管線化（pipelining）方式發(fā)送成為可能。從前發(fā)送請(qǐng)求后需等待并收到響應(yīng)，才能 發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求。
這樣就能夠做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。通俗地講，請(qǐng)求打包一次傳輸過(guò)去，響應(yīng)打包一次傳遞回來(lái)。管線化的前提是在持久連接下。

假如當(dāng)請(qǐng)求一個(gè)包含 10 張圖片的 HTML Web 頁(yè)面，與挨個(gè)連接相比，用持久連接可以讓請(qǐng)求更快結(jié)束。 而管線化技術(shù)則比持久連接還要快。請(qǐng)求數(shù)越多，時(shí)間差就越明顯?？蛻舳诵枰?qǐng)求這十個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送A請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請(qǐng)求，以此類推，而管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出這十個(gè)請(qǐng)求，但是服務(wù)器還是按照順序，先回應(yīng)A請(qǐng)求，完成后再回應(yīng)B請(qǐng)求。

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

請(qǐng)求1->響應(yīng)1->請(qǐng)求2->響應(yīng)2->請(qǐng)求3->響應(yīng)3

管線化方式發(fā)送變成了類似這樣：

請(qǐng)求1->請(qǐng)求2->請(qǐng)求3->響應(yīng)1->響應(yīng)2->響應(yīng)3

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

在第一次通信過(guò)程中，A向B發(fā)送信息之后，B收到信息后可以確認(rèn)自己的收信能力和A的發(fā)信能力沒(méi)有問(wèn)題。

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

在第三次通信中，A向B發(fā)送信息之后，B就可以確認(rèn)自己的發(fā)信能力沒(méi)有問(wèn)題。

持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額外開銷，減輕了服務(wù)器端的負(fù)載。另外， 減少開銷的那部分時(shí)間，使 HTTP 請(qǐng)求和響應(yīng)能夠更早地結(jié)束，這樣 Web 頁(yè)面的顯示速度也就相應(yīng)提高了。
在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接，但在 HTTP/1.0 內(nèi)并未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過(guò)非 標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接，但服務(wù)器端不一定能夠支持持久連接。毫無(wú)疑問(wèn)，除了服務(wù)器端，客戶端也需 要支持持久連接。

client發(fā)送一個(gè)SYN(J)包給server，然后等待server的ACK回復(fù)，進(jìn)入SYN-SENT狀態(tài)(syn已發(fā)送狀態(tài))。p.s: SYN為synchronize的縮寫，理解為序列號(hào)，其實(shí)就是一個(gè)隨機(jī)數(shù)，ACK為acknowledgment的縮寫，理解為確認(rèn)號(hào)。

server接收到SYN(seq=J)包后就返回一個(gè)ACK(J+1)，隨機(jī)數(shù)+1，包以及一個(gè)自己的SYN(K)包，然后等待client的ACK回復(fù)，server進(jìn)入SYN-RECIVED狀態(tài)(syn已接收狀態(tài))。

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

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

FIN：希望斷開連接

client發(fā)送一個(gè)FIN(M)包，此時(shí)client進(jìn)入FIN-WAIT-1狀態(tài)（終止等待1），這表明client已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了。

server收到了client發(fā)來(lái)的FIN(M)包后，向client發(fā)回一個(gè)ACK(M+1)包，此時(shí)server進(jìn)入CLOSE-WAIT狀態(tài)(關(guān)閉等待)，client進(jìn)入FIN-WAIT-2狀態(tài)(終止等待2)。

server向client發(fā)送FIN(N)包，請(qǐng)求關(guān)閉連接，同時(shí)server進(jìn)入LAST-ACK狀態(tài)(最后確認(rèn))。

client收到server發(fā)送的FIN(N)包，進(jìn)入TIME-WAIT狀態(tài)(時(shí)間等待)。向server發(fā)送ACK(N+1)包，server收到client的ACK(N+1)包以后，進(jìn)入CLOSE狀態(tài)；client等待一段時(shí)間還沒(méi)有得到回復(fù)后判斷server已正式關(guān)閉，進(jìn)入CLOSE狀態(tài)。

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

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

同源策略限制內(nèi)容有

Cookie、LocalStorage、IndexedDB 等存儲(chǔ)性內(nèi)容

DOM 節(jié)點(diǎn)

AJAX 請(qǐng)求發(fā)送后，結(jié)果被瀏覽器攔截了

但是有三個(gè)標(biāo)簽是允許跨域加載資源

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

但是對(duì)于顯示富文本來(lái)說(shuō)，顯然不能通過(guò)上面的辦法來(lái)轉(zhuǎn)義所有字符，因?yàn)檫@樣會(huì)把需要的格式也過(guò)濾掉。對(duì)于這種情況，通常采用白名單過(guò)濾的辦法，當(dāng)然也可以通過(guò)黑名單過(guò)濾，但是考慮到需要過(guò)濾的標(biāo)簽和標(biāo)簽屬性實(shí)在太多，更加推薦使用白名單的方式。

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

以上示例使用了 js-xss 來(lái)實(shí)現(xiàn)，可以看到在輸出中保留了 h1 標(biāo)簽且過(guò)濾了 script 標(biāo)簽。

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

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

完成 CSRF 攻擊必須要有三個(gè)條件

用戶已經(jīng)登錄了站點(diǎn) A，并在本地記錄了 cookie

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

站點(diǎn) A 沒(méi)有做任何 CSRF 防御

例子： 當(dāng)我們登入轉(zhuǎn)賬頁(yè)面后，突然眼前一亮驚現(xiàn)"XXX隱私照片，不看后悔一輩子"的鏈接，耐不住內(nèi)心躁動(dòng)，立馬點(diǎn)擊了該危險(xiǎn)的網(wǎng)站（頁(yè)面代碼如下圖所示），但當(dāng)這頁(yè)面一加載，便會(huì)執(zhí)行submitForm這個(gè)方法來(lái)提交轉(zhuǎn)賬請(qǐng)求，從而將10塊轉(zhuǎn)給黑客。

防范 CSRF 攻擊可以遵循以下幾種規(guī)則

Get 請(qǐng)求不對(duì)數(shù)據(jù)進(jìn)行修改

不讓第三方網(wǎng)站訪問(wèn)到用戶 Cookie

阻止第三方網(wǎng)站請(qǐng)求接口

請(qǐng)求時(shí)附帶驗(yàn)證信息，比如驗(yàn)證碼或者 Token

1.SameSite

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

2. Referer Check

HTTP Referer是header的一部分，當(dāng)瀏覽器向web服務(wù)器發(fā)送請(qǐng)求時(shí)，一般會(huì)帶上Referer信息告訴服務(wù)器是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的，服務(wù)器籍此可以獲得一些信息用于處理?？梢酝ㄟ^(guò)檢查請(qǐng)求的來(lái)源來(lái)防御CSRF攻擊。正常請(qǐng)求的referer具有一定規(guī)律，如在提交表單的referer必定是在該頁(yè)面發(fā)起的請(qǐng)求。所以通過(guò)檢查http包頭referer的值是不是這個(gè)頁(yè)面，來(lái)判斷是不是CSRF攻擊。

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

3. Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發(fā)送請(qǐng)求時(shí)在HTTP 請(qǐng)求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的token，并在服務(wù)器建立一個(gè)攔截器來(lái)驗(yàn)證這個(gè)token。服務(wù)器讀取瀏覽器當(dāng)前域cookie中這個(gè)token值，會(huì)進(jìn)行校驗(yàn)該請(qǐng)求當(dāng)中的token和cookie當(dāng)中的token值是否都存在且相等，才認(rèn)為這是合法的請(qǐng)求。否則認(rèn)為這次請(qǐng)求是違法的，拒絕該次服務(wù)。

這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產(chǎn)生并放于session或cookie中，然后在每次請(qǐng)求時(shí)服務(wù)器把token從session或cookie中拿出，與本次請(qǐng)求中的token 進(jìn)行比對(duì)。由于token的存在，攻擊者無(wú)法再構(gòu)造出一個(gè)完整的URL實(shí)施CSRF攻擊。但在處理多個(gè)頁(yè)面共存問(wèn)題時(shí)，當(dāng)某個(gè)頁(yè)面消耗掉token后，其他頁(yè)面的表單保存的還是被消耗掉的那個(gè)token，其他頁(yè)面的表單提交時(shí)會(huì)出現(xiàn)token錯(cuò)誤。

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

點(diǎn)擊劫持是一種視覺(jué)欺騙的攻擊手段。攻擊者將需要攻擊的網(wǎng)站通過(guò) iframe 嵌套的方式嵌入自己的網(wǎng)頁(yè)中，并將 iframe 設(shè)置為透明，在頁(yè)面中透出一個(gè)按鈕誘導(dǎo)用戶點(diǎn)擊。

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

"UI-覆蓋攻擊"

利用iframe或者其它標(biāo)簽的屬性

用戶在登陸 A 網(wǎng)站的系統(tǒng)后，被攻擊者誘惑打開第三方網(wǎng)站，而第三方網(wǎng)站通過(guò) iframe 引入了 A 網(wǎng)站的頁(yè)面內(nèi)容，用戶在第三方網(wǎng)站中點(diǎn)擊某個(gè)按鈕（被裝飾的按鈕），實(shí)際上是點(diǎn)擊了 A 網(wǎng)站的按鈕。
接下來(lái)我們舉個(gè)例子：我在優(yōu)酷發(fā)布了很多視頻，想讓更多的人關(guān)注它，就可以通過(guò)點(diǎn)擊劫持來(lái)實(shí)現(xiàn)

    
    
    
    
    



    點(diǎn)擊脫衣
    

    
Password: 
    

這是我們經(jīng)常見(jiàn)到的登錄頁(yè)面，但如果有一個(gè)惡意攻擊者輸入的用戶名是 admin" --，密碼隨意輸入，就可以直接登入系統(tǒng)了。why! ----這就是SQL注入

我們之前預(yù)想的SQL 語(yǔ)句是:

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

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

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

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

SELECT * FROM user WHERE username="admin"

嚴(yán)格限制Web應(yīng)用的數(shù)據(jù)庫(kù)的操作權(quán)限，給此用戶提供僅僅能夠滿足其工作的最低權(quán)限，從而最大限度的減少注入攻擊對(duì)數(shù)據(jù)庫(kù)的危害

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

對(duì)進(jìn)入數(shù)據(jù)庫(kù)的特殊字符（"，"，，<，>，&，*，; 等）進(jìn)行轉(zhuǎn)義處理，或編碼轉(zhuǎn)換。基本上所有的后端語(yǔ)言都有對(duì)字符串進(jìn)行轉(zhuǎn)義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫(kù)。

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

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

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

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

代理

判斷pc還是移動(dòng)端

二級(jí)域名(一個(gè)端口對(duì)應(yīng)一個(gè)二級(jí)域名)

gzip

過(guò)濾，禁止某些ip仿問(wèn)

負(fù)載均衡

https