【前言】以下源于慕課網(wǎng)《大話HTTP協(xié)議》課程筆記

認(rèn)識HTTP協(xié)議

HTTP 基礎(chǔ)

通過TCP/IP看HTTP

TCP/IP 協(xié)議

1、HTTP協(xié)議是構(gòu)建在TCP/IP協(xié)議之上的恨旱，TCP/IP協(xié)議的一個子集

2、TCP/IP協(xié)議其實是一系列與互聯(lián)網(wǎng)相關(guān)聯(lián)的協(xié)議集合起來的總稱啃炸。

3肿嘲、分層管理是TCP/IP協(xié)議的重要特征匣屡。TCP/IP協(xié)議是由一個四層協(xié)議組成的系統(tǒng)，分別是：應(yīng)用層、傳輸層旭贬、網(wǎng)絡(luò)層瓦侮、數(shù)據(jù)鏈路層。

TCP/IP協(xié)議

應(yīng)用層：應(yīng)用層一般是我們編寫的應(yīng)用程序炫掐，決定了向用戶提供的應(yīng)用服務(wù)。應(yīng)用層協(xié)議有 FTP、DNS晒来、HTTP等朵诫。

傳輸層：傳輸層 向 應(yīng)用層 提供在網(wǎng)絡(luò)中數(shù)傳輸?shù)臄?shù)據(jù)。傳輸層中由兩個相知不用的協(xié)議：TCP和UDP面哥。

網(wǎng)絡(luò)層：網(wǎng)絡(luò)層處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包，數(shù)據(jù)包是網(wǎng)絡(luò)傳輸?shù)淖钚?shù)據(jù)單位县匠。該層規(guī)定了通過怎樣的路徑到達(dá)對方計算機顶瞳，并把數(shù)據(jù)包傳遞給對方闪彼。

鏈路層：鏈路層用來處理連接網(wǎng)絡(luò)的硬件部分。包括控制操作系統(tǒng)谚鄙、硬件設(shè)備驅(qū)動娘赴、NIC網(wǎng)卡腥放、網(wǎng)絡(luò)適配器昂芜、光纖等物理可見部分。

數(shù)據(jù)包的封裝和傳輸過程

上層協(xié)議的數(shù)據(jù)返帕，是怎么轉(zhuǎn)變成為下層協(xié)議數(shù)據(jù)的？這就是通過”封裝“來實現(xiàn)的儡陨。

數(shù)據(jù)包的封裝過程：
應(yīng)用程序的數(shù)據(jù)在發(fā)布到網(wǎng)絡(luò)層之前裙秋，數(shù)據(jù)會沿著TCP/IP協(xié)議棧，從上往下進(jìn)行傳遞旁趟，而每層協(xié)議都會在上層協(xié)議的基礎(chǔ)之上加上自己的頭部信息（在數(shù)據(jù)鏈路層還會加上尾部信息）蛾方，以此實現(xiàn)所有層的數(shù)據(jù)封裝庶溶，為到達(dá)網(wǎng)絡(luò)提供所有的必要信息夺巩。

數(shù)據(jù)包的封裝過程

數(shù)據(jù)包的傳輸過程：
發(fā)送端發(fā)出數(shù)據(jù)時人柿，數(shù)據(jù)會從上層傳輸?shù)较聦由瘢颐拷?jīng)過一層都會被打上該層的頭部信息瞒瘸。而接收端接收數(shù)據(jù)時丁侄，數(shù)據(jù)會從下層傳輸?shù)缴蠈优常瑐鬏斍皶严聦拥念^部信息刪除。

TCP/IP協(xié)議數(shù)據(jù)流

TCP的三次握手和四次揮手

前言：

在客戶端和web服務(wù)器端在發(fā)送一個http請求的發(fā)送和返回的過程當(dāng)中，需要創(chuàng)建一個 【TCP connection】。因為 HTTP 是沒有 【鏈接】的概念的慎陵，它只有【請求】和【響應(yīng)】的概念彤蔽，而請求和響應(yīng)都是數(shù)據(jù)包删性，它們之間是需要經(jīng)過一個傳輸?shù)耐ǖ溃敲催@個通道就是TCP 發(fā)起的從客戶端到服務(wù)器端的一個鏈接纵菌。http請求是在這個鏈接的基礎(chǔ)上去發(fā)送的 匈睁。
在TCP連接上，我們可以發(fā)送多個http請求嗎虐译？在不同的版本上情況不同：
在 HTTP1.0陨闹，一個HTTP請求就創(chuàng)建一個TCP連接塑娇，請求完成后扎筒，連接就斷開悯辙；
在 HTTP1.1蔫劣，可設(shè)置TCP連接不斷開
在 HTTP2外驱，在TCP連接上的http請求是可以并發(fā)的

為什么要進(jìn)行三次握手癣漆？

防止服務(wù)款開啟無用的連接较性。
因為網(wǎng)絡(luò)傳輸是有延時的攀操，中間可能隔著非常遠(yuǎn)的距離耸别，需要通過光纖和中間的各種代理服務(wù)器來進(jìn)行傳輸匾效。
在傳輸?shù)倪^程中，如果客戶端發(fā)起“SYN=1,Seq=X”創(chuàng)建連接的請求，服務(wù)器端就直接創(chuàng)建連接析砸，然后返回內(nèi)容給客戶端弦疮，如果這個數(shù)據(jù)因為網(wǎng)絡(luò)原因丟失了咏尝，那么客戶端就一直沒有接收到服務(wù)器返回的內(nèi)容，直到客戶端請求超時然后自動關(guān)閉連接啸罢，又發(fā)起一個新的創(chuàng)建連接的請求编检。
如果沒有三次握手在扰才，對服務(wù)器端來說允懂，就不能確認(rèn)客戶端是否有接收到我返回的信息，并且是沒有給我確認(rèn)是需要去創(chuàng)建 還是 關(guān)閉 這個請求衩匣。并且端口會一直開著來等客戶端發(fā)送請求蕾总。這樣服務(wù)端的開銷就浪費了，它不知道客戶端的請求已經(jīng)失敗了并且去創(chuàng)建新的連接去了琅捏。
所以生百，三次握手能幫我們確認(rèn)這個連接過程，讓客戶端和服務(wù)器端能夠及時的察覺到說可能因為網(wǎng)絡(luò)原因的一些問題導(dǎo)致數(shù)據(jù)客戶端關(guān)閉了請求服務(wù)器端卻一直在等待請求的情況午绳，規(guī)避網(wǎng)絡(luò)傳輸延時導(dǎo)致的一些服務(wù)器開銷的問題置侍。

三次握手

使用TCP協(xié)議進(jìn)行通信的雙方必須先建立連接，然后才能開始傳輸數(shù)據(jù)。為了確保連接雙方的可靠性蜡坊，在雙方建立連接時杠输，TCP協(xié)議采用三次握手策略。

第一次握手：建立連接秕衙〈兰祝客戶端發(fā)送連接請求報文段，將SYN位置為1据忘，Sequence Number為隨機值x鹦牛；然后，客戶端進(jìn)入SYN_SEND狀態(tài)勇吊，等待服務(wù)器的確認(rèn)曼追；

第二次握手：服務(wù)器收到客戶端的SYN報文段，需要對這個SYN報文段進(jìn)行確認(rèn)汉规，設(shè)置Acknowledgment Number為x+1(即收到的Sequence Number+1)礼殊；同時，自己還要發(fā)送SYN請求信息针史，將SYN位置為1晶伦，Sequence Number為隨機值y；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中啄枕，一并發(fā)送給客戶端婚陪，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段频祝。然后將Acknowledgment Number設(shè)置為y+1泌参，向服務(wù)器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后智润，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)及舍，完成TCP三次握手未辆。

完成了三次握手窟绷，客戶端和服務(wù)器端就可以開始傳送數(shù)據(jù)。以上就是TCP三次握手的總體介紹咐柜。通信結(jié)束客戶端和服務(wù)端就斷開連接兼蜈，需要經(jīng)過四次分手確認(rèn)。

第一次揮手：主機1（可以使客戶端拙友，也可以是服務(wù)器端）为狸，設(shè)置Sequence Number和Acknowledgment Number，向主機2發(fā)送一個FIN報文段遗契；此時辐棒，主機1進(jìn)入FIN_WAIT_1狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了（斷開連接示意）；

第二次揮手：主機2收到了主機1發(fā)送的FIN報文段漾根，向主機1回一個ACK報文段泰涂，Acknowledgment Number為Sequence Number加1；告訴主機1辐怕，我“收到”你的關(guān)閉請求了逼蒙；主機1進(jìn)入FIN_WAIT_2狀態(tài)；

第三次揮手：主機2處理好自己事務(wù)可以關(guān)閉連接后寄疏，向主機1發(fā)送FIN報文段是牢；告訴主機1，我“可以”關(guān)閉請求了陕截；同時主機2進(jìn)入LAST_ACK狀態(tài)驳棱；

第四次揮手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段农曲，然后主機1進(jìn)入TIME_WAIT狀態(tài)蹈胡；主機2收到主機1的ACK報文段以后，就關(guān)閉連接朋蔫；此時罚渐，主機1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉驯妄，那好荷并，主機1也可以關(guān)閉連接了。

可以看到一次tcp請求的建立及關(guān)閉至少進(jìn)行7次通信青扔，這還不包過數(shù)據(jù)的通信源织，而UDP不需3次握手和4次分手。

下圖為抓取的HTTP請求創(chuàng)建TCP連接三次握手?jǐn)?shù)據(jù)包的詳細(xì)過程：

附 關(guān)于TCP的一些問題

1．TCP服務(wù)器最大并發(fā)連接數(shù)是多少微猖？

關(guān)于TCP服務(wù)器最大并發(fā)連接數(shù)有一種誤解就是“因為端口號上限為65535,所以TCP服務(wù)器理論上的可承載的最大并發(fā)連接數(shù)也是65535”谈息。首先需要理解一條TCP連接的組成部分：客戶端IP、客戶端端口凛剥、服務(wù)端IP侠仇、服務(wù)端端口。所以對于TCP服務(wù)端進(jìn)程來說犁珠，他可以同時連接的客戶端數(shù)量并不受限于可用端口號逻炊，理論上一個服務(wù)器的一個端口能建立的連接數(shù)是全球的IP數(shù) x 每臺機器的端口數(shù)。實際并發(fā)連接數(shù)受限于linux可打開文件數(shù)犁享，這個數(shù)是可以配置的余素，可以非常大，所以實際上受限于系統(tǒng)性能炊昆。

附 TCP和UDP

TCP 的全稱是Transmission Control Protocol 桨吊，傳輸控制協(xié)議威根。它能夠幫助你確定計算機連接到 Internet 以及它們之間的數(shù)據(jù)傳輸。通過三次握手來建立 TCP 連接视乐，三次握手就是用來啟動和確認(rèn) TCP 連接的過程医窿。一旦連接建立后，就可以發(fā)送數(shù)據(jù)了炊林，當(dāng)數(shù)據(jù)傳輸完成后姥卢，會通過關(guān)閉虛擬電路來斷開連接。

TCP 的主要特點有:

• TCP 能夠確保連接的建立和數(shù)據(jù)包的發(fā)送
• TCP 支持錯誤重傳機制
• TCP 支持擁塞控制渣聚，能夠在網(wǎng)絡(luò)擁堵的情況下延遲發(fā)送
• TCP 能夠提供錯誤校驗和独榴，甄別有害的數(shù)據(jù)包。

關(guān)于傳輸層TCP奕枝、UDP協(xié)議可能我們平時遇見的會比較多棺榔，有人說TCP是安全的，UDP是不安全的隘道，UDP傳輸比TCP快症歇，那為什么呢，我們先從TCP的連接建立的過程開始分析谭梗，然后解釋UDP和TCP的區(qū)別忘晤。

1、TCP是面向鏈接的激捏，雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性设塔，但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;而UDP不是面向連接的，UDP傳送數(shù)據(jù)前并不與對方建立連接远舅，對接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號闰蛔，發(fā)送端不知道數(shù)據(jù)是否會正確接收，當(dāng)然也不用重發(fā)图柏，所以說UDP是無連接的序六、不可靠的一種數(shù)據(jù)傳輸協(xié)議仁卷。

2眷篇、也正由于1所說的特點，使得UDP的開銷更小數(shù)據(jù)傳輸速率更高理卑，因為不必進(jìn)行收發(fā)數(shù)據(jù)的確認(rèn)距辆，所以UDP的實時性更好余佃。知道了TCP和UDP的區(qū)別，就不難理解為何采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢了跨算，但并不能說QQ的通信是不安全的，因為程序員可以手動對UDP的數(shù)據(jù)收發(fā)進(jìn)行驗證椭懊，比如發(fā)送方對每個數(shù)據(jù)包進(jìn)行編號然后由接收方進(jìn)行驗證啊什么的诸蚕，即使是這樣步势，UDP因為在底層協(xié)議的封裝上沒有采用類似TCP的“三次握手”而實現(xiàn)了TCP所無法達(dá)到的傳輸效率。

URI 背犯、URL 和 URN

URI （Uniform Resource Identifier ）統(tǒng)一資源標(biāo)識符
URL （Uniform Resource Locator） 統(tǒng)一資源定位符
URN（Uniform Resource Name ）統(tǒng)一資源名稱

• URI可以分為URL和URN兩部分坏瘩，URN確定了東西的身份，URL提供了找到它的方式漠魏。

• URL用地址定位倔矾，URN 用名稱定位。

• 格式：<協(xié)議>：//<主機>：<端口>/<路徑> （注：端口和路徑有時可以省略柱锹，HTTP默認(rèn)端口號是80）
  如：https://localhost:8080/index.html?key1=value1&keys2=value2哪自、http://www.magedu.com/downloads/nginx-1.5.tar.gz

DNS域名解析

DNS（Domain Name System，域名系統(tǒng)）禁熏，因特網(wǎng)上作為域名和IP地址相互映射的一個 分布式數(shù)據(jù)庫壤巷，能夠使用戶更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數(shù)串瞧毙。通過主機名胧华，最終得到該主機名對應(yīng)的IP地址的過程叫做域名解析（或主機名解析）。

通常我們訪問一個網(wǎng)站宙彪，使用的是主機名或域名來進(jìn)行訪問的矩动。因為相對于IP地址（一組純數(shù)字），域名更容易讓人記住释漆。但 ICP/IP 協(xié)議使用的是 IP 地址進(jìn)行反問的铅忿，所以需要有個機制或服務(wù)能幫我們把域名轉(zhuǎn)換層IP地址。DNS服務(wù)就是用來解決這個問題的灵汪，它提供域名到IP地址之間的解析服務(wù)檀训。

你是如何訪問慕課的？

訪問慕課與DNS域名解析

瀏覽器輸入域名https://www.imooc.com享言，首先瀏覽器會解析 www.imooc.com 這個域名（準(zhǔn)確的叫法應(yīng)該是主機名）對應(yīng)的IP地址峻凫，通過這個IP地址才能真正的訪問到慕課網(wǎng)的web服務(wù)器。怎么解析到對應(yīng)的IP地址览露？

1荧琼、瀏覽器首先搜索瀏覽器自身的DNS緩存（緩存時間比較短，大概只有1分鐘差牛，且只能容納1000條緩存）命锄，看自身的緩存中是否有 www.imooc.com 對應(yīng)的條目，而且沒有過期偏化，如果有且沒有過期則解析到此結(jié)束脐恩。
注：
① 怎么查看Chrome自身的緩存？可以使用 chrome://net-internals/#dns 來進(jìn)行查看
② 瀏覽器在訪問一個頁面的時侦讨，我們就要從URL中分解出協(xié)議名驶冒、主機名苟翻、端口、對象路徑等骗污。如從” https://www.imooc.com“ 分解出：協(xié)議為HTTP協(xié)議崇猫、主機名為www.imooc.com、端口默認(rèn)為80端口需忿、對象路徑為跟節(jié)點/

2诅炉、如果瀏覽器自身的緩存里面沒有找到對應(yīng)的條目，那么Chrome會搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒有過期則停止搜索解析到此結(jié)束.
注：怎么查看操作系統(tǒng)自身的DNS緩存屋厘，以Windows系統(tǒng)為例涕烧，可以在命令行下使用 ipconfig/displaydns 來進(jìn)行查看。每種操作系統(tǒng)都有自己的DNS緩存時間控制擅这，Windows DNS默認(rèn)值是 MaxCacheTTL澈魄，它的默認(rèn)值是86400s，也就是一天

3仲翎、如果在Windows系統(tǒng)的DNS緩存也沒有找到痹扇，那么嘗試讀取，看看這里面有沒有該域名對應(yīng)的IP地址溯香，如果有則解析成功鲫构。
注：hosts文件位于 C:\Windows\System32\drivers\etc

4、如果在hosts文件中也沒有找到對應(yīng)的條目玫坛，瀏覽器就會發(fā)起一個DNS的系統(tǒng)調(diào)用：
1） 如果在本地的 hosts 文件沒有能夠找到對應(yīng)的 ip 地址结笨，瀏覽器會發(fā)出一個 DNS請求到本地DNS服務(wù)器 。
注：
① 本地DNS服務(wù)器一般都是你的網(wǎng)絡(luò)接入服務(wù)器商提供湿镀，比如中國電信炕吸，中國移動。
② 瀏覽器發(fā)起的域名解析請求勉痴，通過的是UDP協(xié)議向DNS的53端口發(fā)起的

2）本地DNS服務(wù)器會首先查詢它的緩存記錄赫模，如果緩存中有此條記錄，就可以直接返回結(jié)果蒸矛，此過程是遞歸的方式進(jìn)行查詢瀑罗。如果沒有，本地DNS服務(wù)器還要向DNS根服務(wù)器進(jìn)行查詢雏掠。
注：先是找根DNS服務(wù)器的IP地址（這個DNS服務(wù)器都內(nèi)置13臺根域的DNS的IP地址）斩祭，找打根域的DNS地址，就會向其發(fā)起請求

3）根DNS服務(wù)器沒有記錄具體的域名和IP地址的對應(yīng)關(guān)系乡话，而是告訴本地DNS服務(wù)器摧玫，你可以到域服務(wù)器上去繼續(xù)查詢，并給出域服務(wù)器的地址蚊伞。這種過程是迭代的過程席赂。

4）本地DNS服務(wù)器繼續(xù)向域服務(wù)器發(fā)出請求吮铭，在這個例子中时迫，請求的對象是.com域服務(wù)器颅停。.com域服務(wù)器收到請求之后，也不會直接返回域名和IP地址的對應(yīng)關(guān)系掠拳，而是告訴本地DNS服務(wù)器癞揉，你的域名的解析服務(wù)器的地址。

5）最后溺欧，本地DNS服務(wù)器向域名的解析服務(wù)器發(fā)出請求喊熟，這時就能收到一個域名和IP地址對應(yīng)關(guān)系，本地DNS服務(wù)器不僅要把IP地址返回給用戶電腦姐刁，還要把這個對應(yīng)關(guān)系保存在緩存中芥牌，以備下次別的用戶查詢時，可以直接返回結(jié)果聂使，加快網(wǎng)絡(luò)訪問壁拉。

知識擴展：

1)hosts文件

host文件：我們本地電腦會把一些我們常用的域名和對應(yīng)的IP地址建立一個映射關(guān)系，并且保存到系統(tǒng)文件里柏靶，這個文件就是host文件弃理。

2)DNS查詢的兩種方式

當(dāng)局部DNS服務(wù)器自己不能回答客戶機的DNS查詢時，它就需要向其他DNS服務(wù)器進(jìn)行查詢屎蜓。此時有兩種方式：遞歸查詢和迭代查詢
1痘昌、遞歸解析
局部DNS服務(wù)器自己負(fù)責(zé)向其他DNS服務(wù)器進(jìn)行查詢，一般是先向該域名的根域服務(wù)器查詢炬转，再由根域名服務(wù)器一級級向下查詢辆苔。最后得到的查詢結(jié)果返回給局部DNS服務(wù)器，再由局部DNS服務(wù)器返回給客戶端扼劈。

2驻啤、迭代查詢
當(dāng)局部DNS服務(wù)器自己不能回答客戶機的DNS查詢時，局部DNS服務(wù)器不是自己向其他DNS服務(wù)器進(jìn)行查詢测僵，而是把能解析該域名的其他DNS服務(wù)器的IP地址返回給客戶端DNS程序街佑，客戶端DNS程序再繼續(xù)向這些DNS服務(wù)器進(jìn)行查詢，直到得到查詢結(jié)果為止捍靠。
也就是說沐旨，迭代解析只是幫你找到相關(guān)的服務(wù)器而已，而不會幫你去查榨婆。

3)DNS負(fù)載均衡

當(dāng)一個網(wǎng)站有足夠多的用戶的時候磁携，假如每次請求的資源都位于同一臺機器上面，那么這臺機器隨時可能會蹦掉良风。處理辦法就是用DNS負(fù)載均衡技術(shù)谊迄，它的原理是在DNS服務(wù)器中為同一個主機名配置多個IP地址,在應(yīng)答DNS查詢時,DNS服務(wù)器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結(jié)果,將客戶端的訪問引導(dǎo)到不同的機器上去,使得不同的客戶端訪問不同的服務(wù)器,從而達(dá)到負(fù)載均衡的目的?例如可以根據(jù)每臺機器的負(fù)載量闷供，該機器離用戶地理位置的距離等等。

HTTP事務(wù)處理

當(dāng)客戶端訪問Web站點時统诺，首先會通過DNS服務(wù)查詢到域名的IP地址歪脏。讓后瀏覽器發(fā)起HTTP請求，通過TCP/IP協(xié)議三次握手建立TCP連接粮呢，再把消息發(fā)送到Web服務(wù)器婿失。Web服務(wù)器接收到請求后會根據(jù)請求生成響應(yīng)內(nèi)容，再通過TCP/IP協(xié)議返回給客戶端啄寡。

HTTP事務(wù)處理過程

當(dāng)我們在瀏覽器的地址欄輸入 www.linux178.com 豪硅，然后回車，回車這一瞬間到看到頁面到底發(fā)生了什么呢挺物？

簡要概況為：域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請求 --> 服務(wù)器響應(yīng)http請求懒浮，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請求html代碼中的資源（如js识藤、css砚著、圖片等） --> 瀏覽器對頁面進(jìn)行渲染呈現(xiàn)給用戶

1、DNS將域名解析出對應(yīng)IP蹋岩。

瀏覽器自身的DNS緩存 - 系統(tǒng)自身的DNS緩存 - 系統(tǒng)hosts文件 - 本地DNS服務(wù)器（遞歸） - 根服務(wù)器（無緩存赖草，告域服務(wù)器地址，迭代） - 域服務(wù)（無緩存剪个，告知域名的解析服務(wù)器的地址）- 域名的解析服務(wù)器 - 查找到域名對應(yīng)ip秧骑，本地DNS服務(wù)器返回ip地址給瀏覽器且保存該條目到緩存中

2、建立TCP連接扣囊。

拿到域名對應(yīng)的IP地址之后乎折，User-Agent（一般是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務(wù)器的WEB程序（常用的有httpd,nginx等）80端口發(fā)起TCP的連接請求。這個連接請求（原始的http請求經(jīng)過TCP/IP4層模型的層層封包）到達(dá)服務(wù)器端后（這中間通過各種路由設(shè)備侵歇，局域網(wǎng)內(nèi)除外）骂澄，進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧（用于識別該連接請求惕虑，解封包坟冲，一層一層的剝開），還有可能要經(jīng)過Netfilter防火墻（屬于內(nèi)核的模塊）的過濾溃蔫，最終到達(dá)WEB程序（本文就以Nginx為例）健提，最終建立了TCP/IP的連接

問：
1）TCP 為什么需要3次握手？

2）為什么建立連接是三次握手伟叛，而關(guān)閉連接卻是四次揮手呢私痹？

3）為什么HTTP協(xié)議要基于TCP來實現(xiàn)？
目前在Internet中所有的傳輸都是通過TCP/IP進(jìn)行的，HTTP協(xié)議作為TCP/IP模型中應(yīng)用層的協(xié)議也不例外紊遵，TCP是一個端到端的可靠的面向連接的協(xié)議账千，所以HTTP基于傳輸層TCP協(xié)議不用擔(dān)心數(shù)據(jù)的傳輸?shù)母鞣N問題。

因為HTTP在最上層的應(yīng)用層暗膜，再往下的才是傳輸層匀奏。所以再把這個數(shù)據(jù)包封裝成TCP包，建立TCP連接（三次握手）桦山。

HTTP是基于傳輸層的TCP協(xié)議攒射，而TCP是一個端到端的面向連接的協(xié)議醋旦。所謂的端到端可以理解為進(jìn)程到進(jìn)程之間的通信恒水。所以HTTP在開始傳輸之前，首先需要建立TCP連接饲齐，而TCP連接的過程需要所謂的“三次握手”钉凌。

在HTTP開始工作之前，客戶端需要通過網(wǎng)絡(luò)與服務(wù)器進(jìn)行連接捂人，這個連接就是TCP來完成的御雕。TCP協(xié)議與IP協(xié)議共同構(gòu)建了我們的互聯(lián)網(wǎng)，也就是TCP/IP協(xié)議族滥搭，所以互聯(lián)網(wǎng)也被稱作TCP/IP酸纲。HTTP因為是比TCP/IP更高層次，所以只有底層協(xié)議建立之后才能進(jìn)行更高層次的協(xié)議瑟匆。

3闽坡、發(fā)送http請求。

進(jìn)過TCP3次握手之后愁溜，瀏覽器發(fā)起了http的請求疾嗅。

請求的數(shù)據(jù)格式為HTTP請求報文格式。

4冕象、服務(wù)器接到http請求后代承，給予相應(yīng)的響應(yīng)信息。

服務(wù)器端WEB程序接收到http請求以后渐扮，就開始處理該請求论悴，處理之后就返回給瀏覽器html文件。

響應(yīng)的格式為HTTP響應(yīng)報文格式墓律。

5. 瀏覽器解析html代碼膀估，并請求html代碼中的資源

瀏覽器拿到index.html文件后，就開始解析其中的html代碼只锻，遇到j(luò)s/css/image等靜態(tài)資源時玖像，就向服務(wù)器端去請求下載（會使用多線程下載，每個瀏覽器的線程數(shù)不一樣），這個時候就用上keep-alive特性了捐寥，建立一次HTTP連接笤昨，可以請求多個資源，下載資源的順序就是按照代碼里的順序握恳，但是由于每個資源大小不一樣瞒窒，而瀏覽器又多線程請求請求資源，所以從下圖看出乡洼，這里顯示的順序并不一定是代碼里面的順序崇裁。

瀏覽器在請求靜態(tài)資源時（在未過期的情況下），向服務(wù)器端發(fā)起一個http請求（詢問自從上一次修改時間到現(xiàn)在有沒有對資源進(jìn)行修改）束昵，如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒有修改）拔稳，那么瀏覽器會直接讀取本地的該資源的緩存文件。

6.瀏覽器對頁面進(jìn)行渲染呈現(xiàn)給用戶

最后锹雏，瀏覽器利用自己內(nèi)部的工作機制巴比，把請求到的靜態(tài)資源和html代碼進(jìn)行渲染，渲染之后呈現(xiàn)給用戶礁遵。

7轻绞、釋放TCP連接（四次揮手）。

客戶端接收服務(wù)器所返回的信息通過瀏覽器顯示在用戶的顯示屏上佣耐，然后客戶機與服務(wù)器斷開連接政勃。

如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端兼砖，有顯示屏輸出奸远。對于用戶來說，這些過程是由HTTP自己完成的掖鱼，用戶只要用鼠標(biāo)點擊拢肆，等待信息顯示就可以了疆前。

HTTP無狀態(tài)協(xié)議

HTTP協(xié)議是無狀態(tài)協(xié)議超燃。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力左权。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳褐墅，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大拆檬。

無狀態(tài)協(xié)議：

協(xié)議的狀態(tài)是指下一次傳輸可以“記住”這次傳輸信息的能力。

為了保證服務(wù)器內(nèi)存妥凳，http是不會為了下一次連接而維護(hù)這次連接所傳輸?shù)男畔ⅰ?/p>

比如客戶獲得一張網(wǎng)頁之后關(guān)閉瀏覽器竟贯，然后再一次啟動瀏覽器，再登陸該網(wǎng)站逝钥，但是服務(wù)器并不知道客戶關(guān)閉了一次瀏覽器屑那。

HTTP”無狀態(tài)“ 和 ”無連接“ 的區(qū)別：

無狀態(tài)指：協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。從另一方面講持际，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系沃琅。

無連接指：每次HTTP請求都需要建立一次TCP連接，請求完成后連接就斷開蜘欲。

兩者并沒有什么聯(lián)系益眉，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）姥份。

對HTTP的無狀態(tài)特征該怎么解決：

既然HTTP是無狀態(tài)的郭脂，那為何當(dāng)我們輸入用戶名密碼登陸一個網(wǎng)站后，關(guān)閉瀏覽器澈歉，下次再打開頁面時登錄狀態(tài)還在展鸡？

我們可以通過一些策略/方法，讓瀏覽器擁有”記憶“能力：

1. 通過Cookie & Session 保持狀態(tài)

2. JWT 機制
   還有一種方式是使用 JWT 機制闷祥，它也是能夠讓你的瀏覽器具有記憶能力的一種機制娱颊。與 Cookie 不同，JWT 是保存在客戶端的信息凯砍，它廣泛的應(yīng)用于單點登錄的情況。JWT 具有兩個特點：
   1）JWT 的 Cookie 信息存儲在客戶端拴竹，而不是服務(wù)端內(nèi)存中悟衩。也就是說，JWT 直接本地進(jìn)行驗證就可以栓拜，驗證完畢后座泳，這個 Token 就會在 Session 中隨請求一起發(fā)送到服務(wù)器，通過這種方式幕与，可以節(jié)省服務(wù)器資源挑势，并且 token 可以進(jìn)行多次驗證。
   2）JWT 支持跨域認(rèn)證啦鸣，Cookies 只能用在單個節(jié)點的域或者它的子域中有效潮饱。如果它們嘗試通過第三個節(jié)點訪問，就會被禁止诫给。使用 JWT 可以解決這個問題香拉，使用 JWT 能夠通過多個節(jié)點進(jìn)行用戶認(rèn)證，也就是我們常說的跨域認(rèn)證中狂。

Cookie & Session

Cookie

Cookie就是一小段文本信息凫碌。當(dāng)客戶端請求服務(wù)器，如果服務(wù)器需要記錄改用戶狀態(tài)胃榕，就向客戶端瀏覽器頒發(fā)一個Cookie盛险。瀏覽器把Cookie保存起來，當(dāng)瀏覽器再次請求改網(wǎng)站時帶上該Cookie，以供服務(wù)器辨認(rèn)用戶狀態(tài)苦掘。

如果你的瀏覽器允許 cookie 的話泉褐，查看方式 chrome://settings/content/cookies

Session

Session機制是一種服務(wù)器端的機制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)來保存信息鸟蜡。

當(dāng)你向服務(wù)端發(fā)送請求時膜赃，服務(wù)端會給你發(fā)送一個認(rèn)證信息，服務(wù)器第一次接收到請求時揉忘，開辟了一塊 Session 空間（創(chuàng)建了Session對象）跳座，同時生成一個 sessionId ，并通過響應(yīng)頭的 Set-Cookie：JSESSIONID=XXXXXXX 命令泣矛，向客戶端發(fā)送要求設(shè)置 Cookie 的響應(yīng)疲眷；客戶端收到響應(yīng)后，在本機客戶端設(shè)置了一個 JSESSIONID=XXXXXXX 的 Cookie 信息您朽，該 Cookie 的過期時間為瀏覽器會話結(jié)束狂丝；
接下來客戶端每次向同一個網(wǎng)站發(fā)送請求時，請求頭都會帶上該 Cookie信息（包含 sessionId ）哗总， 然后几颜，服務(wù)器通過讀取請求頭中的 Cookie 信息，獲取名稱為 JSESSIONID 的值讯屈，得到此次請求的 sessionId蛋哭。這樣，你的瀏覽器才具有了記憶能力涮母。

保持 Session ID 的方式：

1谆趾、使用Cookie來實現(xiàn)
服務(wù)器給每個Session分配一個唯一的JSESSIONID，并通過Cookie發(fā)送給客戶端叛本。
當(dāng)客戶端發(fā)起新的請求的時候沪蓬，將在Cookie頭中攜帶這個JSESSIONID。這樣服務(wù)器能夠找到這個客戶端對應(yīng)的Session来候。

Cookie在瀏覽器中是可以手動禁用的跷叉，用戶選擇禁用Cookie后， Session ID 的機制還有其他實現(xiàn)方法嗎吠勘？

2性芬、使用URL回寫來實現(xiàn)
URL回寫是指服務(wù)器在發(fā)送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數(shù)，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶會服務(wù)器剧防。
以路徑附加信息形式：http://xxx;Sessionid=xxx
以查詢參數(shù)的形式：http://xxx?Sessionid=xxx

3植锉、隱藏表單方式實現(xiàn)
這個原理和Cookies大同小異，只是每次請求和響應(yīng)所附帶的信息變成了表單變量峭拘。

HTTP長連接和短連接

HTTP長連接和短連接的原理與本質(zhì)

HTTP協(xié)議是基于請求/響應(yīng)模式的俊庇，只要客戶端得到服務(wù)器端的響應(yīng)狮暑，客戶端就關(guān)閉連接，本次HTTP請求就結(jié)束了辉饱。“HTTP中長連接和短連接”本質(zhì)上指的是TCP的連接搬男。

例如當(dāng)打開imooc.com 時，需要加載很多css彭沼、js缔逛、圖片，靜態(tài)網(wǎng)頁等姓惑，如果使用的是短鏈接褐奴，每個資源的請求都要建立一個TCP連接，而使用長連接時于毙，這些請求都可以在一個TCP連接上完成敦冬，就可以節(jié)省很多消耗。

短連接：
建立連接 —— 數(shù)據(jù)傳輸 —— 關(guān)閉連接...建立連接 —— 數(shù)據(jù)傳輸 —— 關(guān)閉連接
長連接：
建立連接 —— 數(shù)據(jù)傳輸...（保持連接）...數(shù)據(jù)傳輸 —— 關(guān)閉連接

HTTP/1.0中唯沮，默認(rèn)使用的時短連接脖旱。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作介蛉，就建立一次連接萌庆，請求完成就斷開連接。
HTTP/1.1起甘耿，默認(rèn)使用長連接踊兜，用以保持連接性（可在 Response Headers 中 的 Connection: keep-alive 設(shè)置）。

短連接對于服務(wù)器來說佳恬，管理較為簡單，存在的連接都是有用的連接于游，不需要額外的控制手段毁葱。但如果客戶請求頻繁，將在TCP建立和關(guān)閉的操作上浪費時間和帶寬贰剥，那么客戶端上響應(yīng)速度就會變慢倾剿，降低了用戶體驗。對于這種需要頻繁請求資源的場景蚌成，就比較適合使用長連接模式了前痘。

client 和 server 端都可以發(fā)起關(guān)閉連接請求，不過在短連接上担忧，關(guān)閉連接請求一般由 client 發(fā)出芹缔，長連接上則一般由 server 發(fā)起。長連接模式下瓶盛，client 和 server 的連接如果一直不關(guān)閉的話最欠，隨著客戶端連接的越來越多示罗，會給 server 造成一定的負(fù)擔(dān)和壓力，所以 server 需要有些策略芝硬，例如關(guān)閉一些長時間沒有讀寫操作的連接蚜点、限制客戶端的最大連接數(shù)等等，避免一些惡意連接導(dǎo)致 server 端服務(wù)受損拌阴。

所以長連接和短連接的產(chǎn)生绍绘，其實是 server 和client采取的關(guān)閉策略，根據(jù)不同的應(yīng)用場景而采用不用的策略迟赃。

當(dāng)前在HTTP1.1 下陪拘，使用長連接更更更為廣泛。

HTTP長連接和短連接的設(shè)置 Connection

Connection：請求頭捺氢，決定當(dāng)前事務(wù)（一次三次握手和四次揮手）完成后是否會關(guān)閉網(wǎng)絡(luò)連接藻丢。屬性值有兩種，持久性連接 和 非持久性連接摄乒。

• keep-alive：
  當(dāng)一個網(wǎng)頁打開完成后悠反，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁馍佑，斋否，或者請求這個頁面上的其他資源，會繼續(xù)使用這一條已經(jīng)建立的連接拭荤。
  HTTP1.1 默認(rèn)進(jìn)行持久連接茵臭。
  默認(rèn)keep-alive的時間是兩個小時，超過這個時間后會自動回收舅世，就是希望盡可能的節(jié)約資源并且又不會造成浪費旦委。當(dāng)然，服務(wù)端可以修改這個背牵活時間缨硝。
• close:
  代表一個Request完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉罢低，當(dāng)客戶端再次發(fā)送Request查辩，需要重新建立TCP連接。

HTTP緩存

WEB緩存(cache)位于Web服務(wù)器和客戶端之間网持。

緩存會根據(jù)請求保存輸出內(nèi)容的副本宜岛，例如html頁面，圖片功舀，文件萍倡，當(dāng)下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應(yīng)訪問請求日杈，而不是向源服務(wù)器再次發(fā)送請求遣铝。
（注意：緩存的是 css佑刷、JavaScript腳本、圖片 等更新頻率不大的靜態(tài)資源文件酿炸，而不是某個http請求的響應(yīng)瘫絮。
）

HTTP 協(xié)議定義了相關(guān)的消息頭來使WEB緩存盡可能好的工作。

為什么要用HTTP緩存

減少相應(yīng)延遲 / 減緩端壓力 / 客戶端渲染優(yōu)化：因為請求從緩存服務(wù)器（離客戶端更近）而不是源服務(wù)器被響應(yīng)填硕，這個過程耗時更少麦萤，讓web服務(wù)器看上去相應(yīng)更快。

減少網(wǎng)絡(luò)帶寬消耗：當(dāng)副本被重用時會減低客戶端的帶寬消耗扁眯；客戶可以節(jié)省帶寬費用壮莹，控制帶寬的需求的增長并更易于管理。

Web 緩存機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請求姻檀，同時在許多情況下可以不需要發(fā)送完整響應(yīng)命满。前者減少了網(wǎng)絡(luò)回路的數(shù)量，HTTP利用一個“過期（expiration）”機制來為此目的绣版；后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬胶台，HTTP用“驗證（validation）”機制來為此目的。

HTTP定義了3種緩存機制：

• Freshness：允許一個回應(yīng)消息可以在源服務(wù)器不被重新檢查杂抽，并且可以由服務(wù)器和客戶端來控制诈唬。例如，Expires回應(yīng)頭給了一個文檔不可用的時間缩麸。Cache-Control中的max-age標(biāo)識指明了緩存的最長時間铸磅；

• Validation：用來檢查以一個緩存的回應(yīng)是否仍然可用。例如杭朱，如果一個回應(yīng)有一個Last-Modified回應(yīng)頭阅仔，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據(jù)情況發(fā)送請求弧械；

• Invalidation：在另一個請求通過緩存的時候霎槐，常常有一個副作用。例如梦谜，如果一個URL關(guān)聯(lián)到一個緩存回應(yīng)，但是其后跟著POST袭景、PUT和DELETE的請求的話唁桩，緩存就會過期。

HTTP緩存的設(shè)置

Cache-Control

Cache-Control：請求/響應(yīng)頭耸棒，通用標(biāo)頭荒澡，緩存控制字段。
可設(shè)置的值有：

• no-store：所有內(nèi)容都不緩存与殃。
• no-cache：緩存单山，但是瀏覽器使用緩存前碍现，都會請求服務(wù)器判斷緩存資源是否是最新。
• max-age=x(單位秒)：請求緩存后的X秒不再發(fā)起請求米奸。
• s-maxage=x(單位秒)：代理服務(wù)器請求源站緩存后的X秒不再發(fā)起請求昼接，只對CDN緩存起效。
• public：客戶端和代理服務(wù)器（CDN）都可緩存悴晰。
• private：只有客戶端可以緩存慢睡。

Expires

Expires：響應(yīng)頭，代表資源過期時間铡溪，由服務(wù)器返回提供漂辐；是 http1.0的屬性；

在與http1.1的 Cache-Control:max-age 共存的情況下棕硫，優(yōu)先級較低髓涯。

Expires的缺點：

1. 如果緩存時間沒過期，那么瀏覽器會被攔截哈扮，無法拿到最新的文件纬纪。HTTP1.1的客戶端和緩存會將非法的日期格式（包括0）看作已經(jīng)過期。所以如果像想瀏覽器不要緩存頁面灶泵，也可以將Expires設(shè)置為0育八。
2. Expires指定一個絕對的過期時間(GMT格式),這么做會導(dǎo)致至少2個問題
   1）客戶端和服務(wù)器時間不同步導(dǎo)致Expires的配置出現(xiàn)問題
   2）很容易在配置后忘記具體的過期時間
   max-age 指定的是從文檔被訪問后的存活時間，這個時間是個相對值(比如:3600s),相對的是文檔第一次被請求時服務(wù)器記錄的Request_time(請求時間)

If-Modified-Since 和 Last-Modified

If-Modified-Since：請求頭赦邻，資源最新修改時間髓棋，由瀏覽器告知服務(wù)器。
Last-Modified：響應(yīng)頭惶洲，資源最新修改時間按声，由服務(wù)器告知瀏覽器。

image.png

If-Modified-Since 通常與 Last-Modified 搭配使用恬吕，通過文件最新修改時間的對比來確認(rèn)是否使用緩存签则。
If-Modified-Since 把瀏覽器端緩存頁面的最后修改時間發(fā)送到服務(wù)器去，服務(wù)器會把這個時間與服務(wù)器上實際文件的最后修改時間 Last-Modified 進(jìn)行對比铐料。如果時間一致渐裂，那么返回304，客戶端就直接使用本地緩存文件钠惩。如果時間不一致柒凉，就會返回200和新的文件內(nèi)容÷耍客戶端接到之后膝捞，會丟棄舊文件，把新文件緩存起來愧沟，并顯示在瀏覽器中蔬咬。

If-None-Match 和 Etag

If-None-Match：請求頭鲤遥，緩存資源標(biāo)識，由瀏覽器告知服務(wù)器（其實就是上次服務(wù)器給的Etag）林艘。
Etag：響應(yīng)頭盖奈，資源標(biāo)識佳镜，由服務(wù)器告知瀏覽器索烹。

If-None-Match 通常與 ETag一起工作膘盖。
工作原理是在HTTP Response中添加ETag信息托酸。 當(dāng)用戶再次請求該資源時史辙，將在HTTP Request 中加入If-None-Match信息(ETag的值)发笔。如果服務(wù)器驗證資源的ETag沒有改變（該資源沒有更新）押框，將返回一個304狀態(tài)告訴客戶端使用本地緩存文件敢辩。否則將返回200狀態(tài)和新的資源和Etag懈涛。使用這樣的機制將提高網(wǎng)站的性能逛万。

（當(dāng)前常用方式。）

HTTP緩存的缺點和可改進(jìn)方案

從上面可知HTTP緩存的設(shè)置有
1.客戶端緩存時間的設(shè)置（Expires 或 Cache-Control:max-age ）批钠；
2.服務(wù)器與瀏覽器的文件修改時間去做對比（If-Modified-Since 與 Last-Modified）宇植；
3.文件標(biāo)識對比（If-None-Match 與 ETag）
三者都有一個前提，就是需是在兩者文件路徑完全相同的情況下埋心，否則就直接獲取新的文件了指郁。

除了HTTP自身的緩存，我們還可以有其他緩存方案：

1. md5/hash緩存
   通過不緩存html拷呆，為靜態(tài)文件添加md5或hash標(biāo)識闲坎，解決瀏覽器無法跳過緩存過期時間主動感知文化變化問題。
2. CDN緩存
   CDN是構(gòu)建在網(wǎng)絡(luò)之上的內(nèi)容發(fā)布網(wǎng)絡(luò)茬斧，依靠部署在各地的邊緣服務(wù)器腰懂，通過中心平臺的負(fù)載均衡、內(nèi)容發(fā)布项秉、調(diào)度等功能模塊绣溜，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞娄蔼，提高用戶訪問響應(yīng)速度和命中率怖喻。

HTTP內(nèi)容協(xié)商機制

指客戶端和服務(wù)器端就響應(yīng)的資源內(nèi)容進(jìn)行交涉，然后提供給客戶端最為適合的資源岁诉。內(nèi)容協(xié)商會以響應(yīng)資源的語言罢防，字符集，編碼方式等作為判斷的基準(zhǔn)唉侄。
例如，開發(fā)了一個中文的網(wǎng)址野建，希望也能支持英文等其他語言属划，就是根據(jù)HTTP內(nèi)容協(xié)商機制來做的恬叹。

內(nèi)容協(xié)商的三種方式：

1. 客戶端驅(qū)動
   客戶端發(fā)起請求，服務(wù)器發(fā)送可選項列表同眯，客戶端作出選擇后在發(fā)送第二次請求绽昼。
   缺點：需要發(fā)送兩次請求
2. 服務(wù)器驅(qū)動
   服務(wù)器檢查客戶端的請求頭部集并決定提供哪個版本的頁面。
   缺點：當(dāng)頭部集都不匹配時须蜗，服務(wù)器要做猜測硅确，所有一般服務(wù)器上都設(shè)置個默認(rèn)值。
3. 透明協(xié)商
   某個中間設(shè)備（通常是緩存代理）代表客戶端進(jìn)行協(xié)商明肮。
   缺點：不是標(biāo)準(zhǔn)的HTTP機制菱农，沒有相應(yīng)的規(guī)范

當(dāng)前使用最廣的應(yīng)當(dāng)是，服務(wù)器驅(qū)動了柿估，下面就來說說服務(wù)器驅(qū)動循未。

服務(wù)器驅(qū)動內(nèi)容協(xié)商 - 請求首部集

• Accept ：告知服務(wù)器發(fā)送何種媒體類型 。
  例如 Accept: text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html 也就是我們常說的html文檔秫舌，如果服務(wù)器無法返回text/html類型的數(shù)據(jù)的妖，服務(wù)器應(yīng)該返回一個406錯誤(non acceptable)。通配符 * 代表任意類型足陨，如 Accept: */* 代表瀏覽器可以處理所有類型嫂粟。

• Accept-Encoding ：告知服務(wù)器采用何種編碼
  瀏覽器申明自己可接收的編碼方法，通常指定壓縮方法墨缘，是否支持壓縮星虹，支持什么壓縮方法。
  常見的內(nèi)容編碼有這幾種： gzip飒房、compress搁凸、deflate、identity狠毯，可應(yīng)用在請求報文和響應(yīng)報文中护糖。
  如Accept-Encoding: gzip, deflate

• Accept-Language ：告知服務(wù)器發(fā)送何種語言

• Accept-Charset ：告知服務(wù)器發(fā)送何種字符集

服務(wù)端會根據(jù)請求的這些設(shè)置進(jìn)行匹配，并返回幾個對應(yīng)的實體回復(fù)：Content-Type嚼松、Content-Language嫡良、Content-Type、Content-Encoding献酗。

服務(wù)器驅(qū)動內(nèi)容協(xié)商 - 近似匹配q

HTTP 提供q機制寝受，允許服務(wù)器近似匹配。q機制可在Accept罕偎、Accept-Language很澄、Accept-Charset、Accept-Encoding中使用，以Accept-Encoding來舉例：

Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0, tr;q=0.0

譯：客戶端提出的是甩苛，用戶最愿意接受的是nl(荷蘭)語蹂楣，其次是en(英)語，不愿接受fr(法)語或tr(土耳其)語讯蒲。
q痊土，權(quán)重，值的范圍是0~1墨林，表示偏好優(yōu)先級赁酝；
當(dāng)客戶端提出了用戶的語言偏好的時候，服務(wù)器端能根據(jù)該偏好做出相應(yīng)的匹配旭等。

HTTP的斷點續(xù)傳和多線程下載

當(dāng)我們在下載一個大文件時酌呆，HTTP是如何實現(xiàn)斷點續(xù)傳或多線程分塊下載的？

HTTP是通過在 Header 的兩個參數(shù)實現(xiàn)的辆雾，客戶端發(fā)送請求時對應(yīng)的是 Range肪笋，服務(wù)器端響應(yīng)時對應(yīng)的是 Content-Range。
Range：
用于請求頭中度迂，指定第一個字節(jié)的位置和最后一個字節(jié)的位置藤乙。
例如：
Range: bytes=0-499 表示頭500個字節(jié)
Range: bytes=500-999 表示第二個500字節(jié)
Range: bytes=-500 表示最后500個字節(jié)
Range: bytes=500- 表示500字節(jié)開始到文件結(jié)束
Range: bytes=500-600,601-999 同時指定幾個范圍

Content-Range：
用戶響應(yīng)頭中，在發(fā)出帶Range的請求后惭墓，服務(wù)器會在Content-Range 頭部返回當(dāng)前接受的范圍和文件總大小坛梁。
而在響應(yīng)的完成后，返回的響應(yīng)頭內(nèi)容也不同：
不使用斷點續(xù)傳方式: HTTP/1.1 200 OK
使用斷點續(xù)傳方式: HTTP/1.1 206 Partial Content
如果續(xù)傳成功（或者多線程分塊下載成功）服務(wù)器返回206腊凶，如果文件有變動划咐，服務(wù)器返回200和新文件的內(nèi)容（之前說過HTTP狀態(tài)嗎206表示的是部分內(nèi)容下載）。

斷點續(xù)傳過程

1.客戶端下載一個 1024K 的文件钧萍，當(dāng)下載了其中 512K時褐缠，網(wǎng)絡(luò)因某些原因中斷了（或用戶主動暫停了下載）。
2.網(wǎng)絡(luò)重連（或用戶選擇了繼續(xù)下載）
3.客戶端請求續(xù)傳风瘦，因此需要在HTTP頭中申明本次需要續(xù)傳的片段： "Range: bytes = 512000-" 队魏，這個頭通知服務(wù)端從文件的 512K 位置開始傳輸文件。
4.服務(wù)端收到斷點續(xù)傳請求万搔，從文件的 512K 位置開始傳輸胡桨，并且在HTTP頭中增加： "Content-Range : bytes 512000-/1024000" ，512000-表示從文件的512000位置開始傳輸?shù)轿募Y(jié)束瞬雹，1024000表示文件的總大小昧谊。 此時服務(wù)端返回的HTTP狀態(tài)碼應(yīng)該是 206 ，而不是 200酗捌。

多線程下載

多線程下載類似于斷點續(xù)傳呢诬，只不過斷點續(xù)傳是被動的增量下載涌哲，而多線程下載是主動的分片下載，同樣都是使用Range模式馅巷。例如把100M的文件分為100個片來下載膛虫，那么第一個片的Range為0-1024000，第二個片的Range為1024001-2048000钓猬，以這樣的模式不斷向下疊加，主動的把他分成了100片撩独。

HTTP與HTTPS

HTTP與HTTPS

HTTPS(Hypertext Transfer Protocol Secure) 從名稱我們可以看出 HTTPS 要比 HTTPS 多了 secure 安全性這個概念敞曹。實際上， HTTPS 并不是一個新的應(yīng)用層協(xié)議综膀，它其實就是 HTTP + TLS/SSL 協(xié)議組合而成澳迫，而安全性的保證正是 TLS/SSL 所做的工作。

那么剧劝，HTTP 和 HTTPS 的主要區(qū)別是什么呢橄登？

• 最簡單的，HTTP 在地址欄上的協(xié)議是以 http:// 開頭讥此，而 HTTPS 在地址欄上的協(xié)議是以 https:// 開頭拢锹；

• HTTP 的默認(rèn)端口是 80，而 HTTPS 的默認(rèn)端口是 443萄喳；

• HTTP 是未經(jīng)安全加密的協(xié)議卒稳，它的傳輸過程容易被攻擊者監(jiān)聽、數(shù)據(jù)容易被竊取他巨、發(fā)送方和接收方容易被偽造充坑；而 HTTPS 是安全的協(xié)議，它通過 密鑰交換算法 - 簽名算法 - 對稱加密算法 - 摘要算法 能夠解決上面這些問題染突。

TLS

TLS是傳輸加密協(xié)議捻爷，它的前身是SSL協(xié)議。

SSL(Secure Sockets Layer：安全套階層)：對傳輸層數(shù)據(jù)進(jìn)行加密后傳輸份企，保證數(shù)據(jù)的安全(不被泄露)和完整(不被篡改)也榄。

TLS建立在應(yīng)用層和傳輸層中間，在TCP之上建立了一個加密通道薪棒。TLS協(xié)議主要有5個部分：應(yīng)用數(shù)據(jù)層協(xié)議手蝎、握手協(xié)議、報警協(xié)議俐芯、加密消息確認(rèn)協(xié)議棵介、心跳協(xié)議。

因為我們知道 HTTPS 不是一種新出現(xiàn)的協(xié)議吧史，而是 HTTP + TLS/SSL邮辽。所以，我們探討 HTTPS 的握手過程，其實就是 SSL/TLS 的握手過程吨述。

TLS 旨在為 Internet 提供通信安全的加密協(xié)議岩睁。TLS 握手是啟動和使用 TLS 加密的通信會話的過程。在 TLS 握手期間揣云，Internet 中的通信雙方會彼此交換信息捕儒，驗證密碼套件，交換會話密鑰邓夕。

每當(dāng)用戶通過 HTTPS 導(dǎo)航到具體的網(wǎng)站并發(fā)送請求時刘莹，就會進(jìn)行 TLS 握手。除此之外焚刚，每當(dāng)其他任何通信使用HTTPS（包括 API 調(diào)用和在 HTTPS 上查詢 DNS）時点弯，也會發(fā)生 TLS 握手。TLS 具體的握手過程會根據(jù)所使用的密鑰交換算法的類型和雙方支持的密碼套件而不同矿咕。

HTTPS功能介紹

HTTPS提供了三個功能抢肛，來對抗HTTP不安全、可能被劫持的缺陷碳柱。

• 內(nèi)容加密：瀏覽器到服務(wù)器的數(shù)據(jù)捡絮，都是以加密形式來傳輸?shù)模虚g者無法直接查看原始內(nèi)容士聪。
  =》對稱內(nèi)容加密锦援、非對稱密鑰交換
  • 對稱內(nèi)容加密：對稱加密的第一步是需要協(xié)商加密算法的密鑰，中間人依然可以在第一次通信的時候截獲加密方式和密鑰剥悟。
  • 非對稱密鑰交換：非對稱交換灵寺，用公鑰和私鑰的方式，把正常通信的密鑰key2協(xié)商好区岗。但是在協(xié)商過程中略板，有一步是服務(wù)器把自己的公鑰key1用明文傳給客戶端。此時中間人可以截獲key1慈缔，換成自己的公鑰key3叮称，這樣一來中間人就可以獲取正常通信的密鑰，通信仍然不安全
• 身份驗證：由于證書的存在藐鹤，保證了用戶訪問的是你想問的服務(wù)瓤檐，若訪問站點被劫持，會給用戶相應(yīng)提示娱节。
  =》數(shù)字證書
  • 數(shù)字證書：服務(wù)端向權(quán)威機構(gòu)申請證書（證書包含 證書機構(gòu)挠蛉、服務(wù)器網(wǎng)址、機構(gòu)加密的私鑰肄满、私鑰加密過的公鑰谴古、證書簽名等等）质涛。在客戶端和服務(wù)器端通信時，服務(wù)器端先把證書傳遞為客戶端掰担，客戶端收到證書后汇陆，用證書的公鑰解密證書簽名，然后用簽名生成規(guī)則再生成一個簽名來對比带饱，一致的是真證書毡代，反正為假證書。如果為真證書勺疼，就解密服務(wù)器公鑰key1月趟，再生成通信用的密鑰key2，再用服務(wù)器端的公鑰key1加密發(fā)給服務(wù)端恢口。
    這個權(quán)威證書，也稱為CA證書穷躁。CA證書就是可信的嗎耕肩？廠商和瀏覽器、操作系統(tǒng)都是有合作的问潭，它們的公鑰都默認(rèn)裝在瀏覽器猿诸、操作系統(tǒng)的環(huán)境里。
• 數(shù)據(jù)完整性：防止傳輸?shù)臄?shù)據(jù)被第三方冒充或篡改狡忙。

HTTPS對性能的影響

1梳虽、協(xié)議交互所增加的網(wǎng)絡(luò)RTT <=> 網(wǎng)絡(luò)耗時

RTT：RTT表示從 “發(fā)送端” 發(fā)送數(shù)據(jù)開始，到 “發(fā)送端” 收到來自 “接收端” 的確認(rèn)灾茁，這個過程中總共花費的時間

下面來比較下HTTP和HTTPS在網(wǎng)絡(luò)訪問和往返時延上的區(qū)別（以下忽略DNS的域名解析）：

HTTP

HTTP：只需完成TCP三次握手建立TCP連接窜觉，就能夠發(fā)送HTTP請求，獲取應(yīng)用層數(shù)據(jù)北专。除此無需消耗其他的計算資源禀挫。

HTTPS：

HTTPS

第一步：三次握手往返，耗時一個RTT拓颓。

第二步：一般是由一個HTTP GET請求语婴，服務(wù)端返回302跳轉(zhuǎn)到https，這里耗時一個RTT驶睦。（通常用戶訪問網(wǎng)站時不會手動的去輸入https砰左，例如訪問百度時，我們一般是直接在瀏覽器輸入baidu.com场航，所有服務(wù)端只能返回302缠导，讓瀏覽器跳轉(zhuǎn)到 https:www.baidu.com

第三步：服務(wù)器跳轉(zhuǎn)到HTTPS之后，由于和服務(wù)器不一樣旗闽，所有需要重新完成三次握手建立TCP連接酬核，耗時一個RTT蜜另。

第四步：接下來是 TLS完全握手階段1，耗時一個RTT嫡意。這個階段主要是完成 加密套件的協(xié)商 和 證書的身份確認(rèn)举瑰。

這個階段里服務(wù)器和瀏覽器會協(xié)商出 密鑰交換算法、對稱加密算法蔬螟、內(nèi)容一致性加密算法此迅、證書簽名算法等等。

瀏覽器獲取到證書后旧巾，需要校驗證書的有效性：
1）CA站點的域名DNS解析耸序，耗時一個RTT。
2）CA站點三次握手建立TCP連接鲁猩，耗時一個RTT坎怪。
3）瀏覽器發(fā)送Ocsp(在線證書狀態(tài)協(xié)議)請求，查詢證書狀態(tài)(有效廓握？過期搅窿？未知)，耗時一個RTT隙券。

第五步：最后是 TLS完全握手階段2男应。這個階段主要是密鑰協(xié)商侵续，耗時一個RTT嗤锉。這個握手結(jié)束后瀏覽器和服務(wù)器就能就行應(yīng)用層的數(shù)據(jù)傳輸了。

從以上可以看到雹姊，這些步驟最多會耗費7個RTT牲迫，當(dāng)然不是每個請求都需要耗費7個RTT來完成HTTPS首次請求交互耐朴。例如如果CA站點域名解析，DNS有緩存的話都能在一定程度上減少RTT的消耗恩溅。

可以確定的是隔箍，HTTPS在網(wǎng)絡(luò)上的消耗是略大于HTTP的。

以上是HTTPS在網(wǎng)絡(luò)路徑上必須消耗的存網(wǎng)絡(luò)耗時脚乡，還不包括CUP資源的計算耗時蜒滩，大概會在30毫秒以上，主要看設(shè)備性能而定奶稠。

2俯艰、加解密相關(guān)的計算耗時 <=> 計算耗時

計算耗時可以分外兩個方面：
瀏覽器計算耗時：包括瀏覽器解析證書簽名、各種密鑰交換锌订、應(yīng)用層數(shù)據(jù)加解密等的耗時
服務(wù)器計算耗時：同樣包括密鑰交換竹握、應(yīng)用層數(shù)據(jù)加解密等的耗時

SSL安全通信握手

數(shù)字證書

SSL安全通信握手

• 綜合使用對稱加密、非對稱加密
  在進(jìn)行隨機數(shù)交流的階段辆飘，使用的是非對稱加密來進(jìn)行通信的啦辐，等雙發(fā)都確定了隨機數(shù)之后谓传，就可以使用對稱的加密了。
• 雙發(fā)分別生成密鑰芹关，沒有經(jīng)過傳輸
  減少了密鑰泄露的可能性续挟。

ASE加密

ASE對稱加密：
缺點：
“第一次約定加密方式”　和　“約定加密方式的密鑰的通信”　仍然還是用明文，如果第一次通信時就已經(jīng)被攔截侥衬，那么密鑰就會泄露給中間人诗祸，中間人就可以解密后續(xù)所有的通信內(nèi)容。
ASE非對稱加密：　
明文可以用公鑰加密轴总，私鑰解密直颅。也可以用私鑰加密，公鑰解密怀樟。

基于 HTTP 的功能追加協(xié)議

HTTP協(xié)議的瓶頸

1）條連接上只可發(fā)送一個請求
2）請求只從客戶端開始（解決方法：long poll 和 ajax輪詢）
3）客戶端不可以接受除響應(yīng)以外的指令
4）請求／響應(yīng)頭部不經(jīng)壓縮就發(fā)送
5）每次互相發(fā)送相同的頭部造成的浪費較多
6）非強制壓縮發(fā)送

=》
1）單鏈路功偿，請求低效
2）HTTP只允許由客戶端主動發(fā)起請求
3）HTTP頭部冗余

一、雙工通信的WebScocket

WebSocket 是基于HTTP協(xié)議的往堡，或者說脖含，接用了HTTP協(xié)議來完成一部分握手。當(dāng)HTTP升級為Websocket協(xié)議時投蝉，服務(wù)器端可以主動推送消息給客戶端。

WebSocket 請求

WebSocket 響應(yīng)

WebSocket 的特點

1）正真的全雙工方式
2）減少通信量
客戶端和服務(wù)器端只需要建立一次握手征堪，就可以建立持久性的連接瘩缆。傳統(tǒng)的客戶端輪詢需要不斷的建立、關(guān)閉HTTP連接佃蚜，由于HTTP是無狀態(tài)協(xié)議庸娱，每次都要傳遞鑒別消息，服務(wù)端也是每次都要處理鑒別消息谐算。
3）應(yīng)用：聊天室熟尉、社交網(wǎng)站、股票行情

WebSocket 通信過程

long poll 洲脂、 ajax 和 WebScocket 之間的區(qū)別

long poll 其實原理跟 ajax輪詢 差不多斤儿，都是采用輪詢的方式，不過采取的是阻塞模型（類似于一直打電話恐锦，沒收到就不掛電話）

Ajax輪詢與long poll都屬于不斷發(fā)送http請求往果，然后等待服務(wù)器處理，服務(wù)端不能主動聯(lián)系客戶端一铅，只有客戶端發(fā)起陕贮。

webSocket實現(xiàn)了瀏覽器與服務(wù)器之間的全雙工通信，能很好的節(jié)省服務(wù)器資源與帶寬潘飘，并在服務(wù)器端與瀏覽器端實現(xiàn)實時通行肮之，他建立在TCP之上掉缺， 同http一樣，通過tcp來傳輸數(shù)據(jù)戈擒。

只需要一次HTTP握手眶明，所以說整個通訊過程是建立在一次連接/狀態(tài)中，服務(wù)器端會知道連接的信息峦甩，知道客戶端關(guān)閉請求赘来，同時由服務(wù)器主動推送，當(dāng)有信息需要發(fā)送時凯傲，直接發(fā)送犬辰。客戶端的連接通過session對象存儲冰单，能夠?qū)崿F(xiàn)實時推送幌缝。

所以實際上整個底層的思路是完全不同的。

二诫欠、SPDY 與 HTTP2.0

SPDY

SPDY是Google開發(fā)的基于TCP的會話層協(xié)議涵卵，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度荒叼，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗轿偎。SPDY并不是一種用于替代HTTP的協(xié)議，而是對HTTP協(xié)議的增強被廓。新協(xié)議的功能包括數(shù)據(jù)流的多路復(fù)用坏晦、請求優(yōu)先級以及HTTP報頭壓縮。谷歌表示嫁乘，引入SPDY協(xié)議后昆婿，在實驗室測試中頁面加載速度比原先快64%。

SPDY

SPDY的改進(jìn)：
1）多路復(fù)用請求優(yōu)化
2）支持服務(wù)器推送技術(shù)
3）SPDY 壓縮了 HTTP 頭
4）強制使用 SSL 傳輸協(xié)議

HTTP2.0

HTTP2.0

HTTP2.0的改進(jìn)：
1）二進(jìn)制分幀

2）首部壓縮

3）多路復(fù)用
資源合并蜓斧，減少請求（雪碧圖、文件合并等）優(yōu)化的手段挎春，對于HTTP2.0來說看疙，只會增大無用的工作量，并沒有特別大的意義直奋。
單鏈接多資源的優(yōu)勢：
1.可以減少服務(wù)鏈接壓力狼荞，內(nèi)存占用少了，連接吞吐量大了
2.由于TCP 連接減少而使網(wǎng)絡(luò)擁塞狀況得以改觀
3.慢啟動時間減少帮碰，擁塞和丟包恢復(fù)速度更快

4）并行雙向字節(jié)流的請求和響應(yīng)
1.并行交錯地發(fā)送請求相味，請求之間互不影響
2.并行交錯地發(fā)送響應(yīng)，響應(yīng)之間互不干擾
3.只使用一個連接即可并行發(fā)送多個請求和響應(yīng)殉挽，消除不必要的延遲丰涉，減少頁面加載的時間

5）請求優(yōu)先級
1.高優(yōu)先級的流都應(yīng)該優(yōu)先發(fā)送
2.優(yōu)先級不是絕對的
3.不同優(yōu)先級混合也是必須的

6）服務(wù)器推送

三拓巧、管理WB服務(wù)器文件的WebDAV協(xié)議

在客戶端通過WebDAV協(xié)議可以直接對服務(wù)器上的文件進(jìn)行操作，實現(xiàn)遠(yuǎn)程文件管理一死。

四肛度、QUIC 與 HTTP3.0

HTTP3.0

HTTP2.0的問題：
1）多路復(fù)用的隊頭阻塞
2）TCP建立連接的握手延遲大

QUIC的特性：
1）0 RTT

2）沒有隊頭阻塞的多路復(fù)用

3）前向糾錯

Web安全威脅解析

Web應(yīng)用安全威脅分為六大類：

WASC(Web Application Security Consortium) 一個負(fù)責(zé)為 WWW指定應(yīng)用安全標(biāo)準(zhǔn)的組織，將Web應(yīng)用安全威脅分為六大類投慈。
1）Authentication（驗證）：用來確認(rèn)某用戶承耿、服務(wù)或是應(yīng)用本身份的攻擊手段。如 登錄伪煤、注冊加袋、忘記密碼等。
2）Authorization（授權(quán)/會話管理）：用來決定是否某用戶抱既、服務(wù)职烧、或是應(yīng)用具有執(zhí)行請求動作必要權(quán)限的攻擊手段。
3）Client-Side Attacks（客戶側(cè)攻擊）：用來擾亂或是探測Web站點用戶的攻擊手段防泵。
4）Command Execution（命令執(zhí)行）：在Web站點上執(zhí)行遠(yuǎn)程命令的攻擊手段蚀之。如SQL注入。
5）Information Disclosure（信息暴露）：用來獲取Web站點具體系統(tǒng)信息的攻擊手段捷泞。
6）Logical Attacks（邏輯性攻擊）：用來擾亂或是探測Web應(yīng)用邏輯流程的攻擊手段足删。

驗證技術(shù)

1）基于HTML表單的驗證（賬號密碼等）
2）多元機制，如組合型密碼
3）客戶端ssl證書

一锁右、驗中機制安全

image.png

二壹堰、會話管理安全

會話管理漏洞的防御：

1. 令牌傳輸安全
   令牌只能通過HTTPS傳送；
   如果使用HTTP cookie傳送令牌骡湖，應(yīng)該將這些cookie標(biāo)記為secure，以防止用戶瀏覽器通過HTTP傳送它們

2. 增加會話過期
   軟會話過期峻厚，它指的是用戶在一定的時間內(nèi)與應(yīng)用系統(tǒng)沒有交互响蕴，則會話過期，也就是我們常說的** session 失效**惠桃；
   硬會話過期浦夷，它指的是用戶登錄到系統(tǒng)中經(jīng)過一定的時間，不管用戶做什么辜王，該會話都會過期

3. 提供完善的注銷功能
   用戶可以手動地使當(dāng)前會話過期劈狐，如 退出登錄按鈕；
   TlpS ：要保證注銷不存在會話終止漏洞呐馆，如退出登錄操作應(yīng)在客戶端和服務(wù)器端保持同步肥缔。

三、SQL注入攻擊

SQL注入防御 —— 參數(shù)化查詢汹来。

參數(shù)化查詢是對SQL注入根本性的防御策略续膳，也叫預(yù)處理語句改艇，在建立一個包含用戶名輸入的SQL語句時分為兩步：
第一步：指定查詢結(jié)構(gòu)，用戶輸入預(yù)留占位符
第二步：指定占位符的內(nèi)容

四坟岔、XSS 跨站腳本攻擊

XSS攻擊原理：

跨腳本攻擊（Cross Site Scripting）,XSS 是一種經(jīng)常出現(xiàn)在web應(yīng)用中的計算機安全漏洞谒兄。它允許惡意web用戶將代碼植入到提供給其他用戶使用的頁面中，其他用戶在觀看網(wǎng)頁時社付，惡意腳本會執(zhí)行承疲。
這里攻擊通常通過注入HTML或JS腳本發(fā)動攻擊。
攻擊成功后鸥咖，攻擊者可以得到網(wǎng)頁內(nèi)容和cookie等燕鸽。

XSS防御措施：

1. 輸入驗證

• 數(shù)據(jù)不是太長
• 數(shù)據(jù)僅包含某組合法字符
• 數(shù)據(jù)與一個特殊的正規(guī)表達(dá)式相匹配
• 根據(jù)應(yīng)用程序希望在每個字段中收到的數(shù)據(jù)類型，應(yīng)盡可能限制性地對姓名扛或、電子郵件地址绵咱、賬號等應(yīng)用不同的確認(rèn)規(guī)則

2. 輸出編碼

• 如果應(yīng)用程序?qū)⒛澄挥脩艋虻谌教峤坏臄?shù)據(jù)復(fù)制到它的響應(yīng)中，那么應(yīng)用程序應(yīng)對這些數(shù)據(jù)進(jìn)行HTML編碼熙兔，以凈化可能的惡意字符悲伶。
• HTML編碼指對應(yīng)的HTML實體代替字面量字符。這樣做可確保瀏覽器安全處理可能是惡意的字符住涉，把它們當(dāng)作HTML文檔的內(nèi)容而非結(jié)構(gòu)處理麸锉。
• 經(jīng)常造成問題的字符的HTML編碼如下：
  " => "
' => '
< => <
> => >
/=> x2F
• 在這兩種防御中，輸出確認(rèn)最為重要舆声，必不可少花沉。實施嚴(yán)格的輸入確認(rèn)應(yīng)被視為一種次要故障恢復(fù)。

五媳握、CSRF 跨站請求偽造攻擊

跨站請求偽造（Cross-site Request Forgery）碱屁，通常被縮寫為 CSRF 或 XSRF。

聽起來像XSS（跨站腳本）蛾找，但卻與XSS不盡相同娩脾。 XSS 利用站點內(nèi)的信任用戶（受害者），而 CSRF 通過偽裝來自受信任用戶的請求來利用受信任的網(wǎng)站打毛。今通過社會工程學(xué)的手段（如通過電子郵件發(fā)送一個鏈接）來蠱惑受害者進(jìn)行一些敏感性的操作柿赊，如修改密碼、修改E-mail 幻枉、轉(zhuǎn)賬等碰声，而受害者還不知道他已經(jīng)中招。

CSRF攻擊原因：

1. web瀏覽器對于 Cookie 和 HTTP 身份驗證信息之類的會話信息的處理方式熬甫。
   瀏覽器收到站點設(shè)置的 Cookie 后胰挑，每當(dāng)向該站點發(fā)送請求的時候，瀏覽器都會 ”自動地“ 連同 Cookie 一起發(fā)出。
2. 應(yīng)用程序依賴以管理會話的信息對瀏覽器的透明性問題洽腺。
   為提高Web應(yīng)用的便利性脚粟，用來管理會話的信息，如 Cookie 或基于HTTP的身份驗證等敏感信息蘸朋，都是由瀏覽器來存放的核无；并在每當(dāng)向需要身份驗證的應(yīng)用程序發(fā)送請求時自動捎帶上。也就是說藕坯，瀏覽器可以訪問會話管理信息团南，如果 Web 應(yīng)用程序完全依賴于這類信息來識別一個用戶會話，就為跨站請求偽造創(chuàng)造了條件炼彪。因為 Web 應(yīng)用程序不會判斷這個請求到底是否是合法用戶發(fā)送的吐根。

CSRF攻擊預(yù)防：

1. 增加一些確認(rèn)操作。
   如支付之前的確認(rèn)支付提示框辐马；
2. 重新認(rèn)證拷橘。
   如在做一些敏感操作時，要求用戶重新輸入密碼來進(jìn)行二次驗證喜爷；
3. 使用Token冗疮。
   提交此請求的時候，在服務(wù)器端檢查提交的 Token 與用戶 session 中的 Token 是否一致檩帐，如果一致术幔，繼續(xù)處理請求，否則返回一個錯誤信息給用戶湃密。在用戶退出或者 session 過期的時候诅挑，用戶信息（包括 CSRF Token ）從 session 中移除并且銷毀 session 。

HTTP協(xié)議認(rèn)證

HTTP常見認(rèn)證方式

• BASIC認(rèn)證（基本認(rèn)證）
• DIGEST認(rèn)證（摘要認(rèn)證）
• SSL客戶端認(rèn)證
• FormBase認(rèn)證（基于表單認(rèn)證）

BASIC認(rèn)證

HTTP請求報頭： Authorization

HTTP響應(yīng)報頭： WWW-Authenticate

認(rèn)證模式：基于質(zhì)詢/響應(yīng)(challenge/response)的認(rèn)證模式
質(zhì)詢/響應(yīng)(challenge/response)：一方先返送認(rèn)證要求給另一方泛源，接著使用從另一方接受到的質(zhì)詢碼計算生成響應(yīng)碼拔妥，再進(jìn)響應(yīng)碼返回給對方進(jìn)行認(rèn)證。

基本認(rèn)證是一種用來允許Web瀏覽器或其他客戶端程序在請求時提供用戶名和口令形式的身份憑證的一種登錄驗證方式达箍。把 "用戶名+冒號+密碼"用BASE64算法加密后的字符串放在http request 中的header Authorization中發(fā)送給服務(wù)端没龙。
客戶端對于每一個realm，通過提供用戶名和密碼來進(jìn)行認(rèn)證的方式幻梯。

當(dāng)瀏覽器訪問使用基本認(rèn)證的網(wǎng)站的時候， 瀏覽器會提示你輸入用戶名和密碼：

假如用戶名密碼錯誤的話努释，服務(wù)器會返回401：

支持：HTTP1.0就被定義的一種認(rèn)證方式碘梢。

優(yōu)點：較容易實現(xiàn)、基本上所有流行的網(wǎng)頁瀏覽器都支持基本認(rèn)證伐蒂∩饭基本認(rèn)證很少在可公開訪問的互聯(lián)網(wǎng)網(wǎng)站上使用，有時候會在小的私有系統(tǒng)中使用（如路由器網(wǎng)頁管理接口）。

缺點：采用的是Base64編碼方式恩沛，可對其進(jìn)行解碼得到用戶名和密碼在扰。在HTTP這樣非加密通信的線路上，如果沒有使用SSL/TLS這樣的傳輸層安全的協(xié)議雷客，那么以明文傳輸?shù)拿荑€和口令很容易被攔截芒珠。安全性不夠。

認(rèn)證步驟：
1搅裙、客戶端訪問一個受http基本認(rèn)證保護(hù)的資源皱卓。

2、服務(wù)器返回401狀態(tài) 和 Authoriz ation Required部逮，告知客戶端需要進(jìn)行身份認(rèn)證娜汁。同時響應(yīng)頭會帶上WWW-Authenticate 字段，如：WWW-Authenticate： Basic realm="請求域" 兄朋。

3掐禁、客戶端將輸入的用戶名密碼以 ”用戶名:密碼“ 字符串形式再Base64進(jìn)行編碼后，采用非加密的明文方式傳送給服務(wù)器颅和。如：Authorization: Basic xxxxxxxxxx.

4傅事、服務(wù)器將Authorization頭中的用戶名密碼解碼并取出，進(jìn)行驗證融虽，如果認(rèn)證成功享完，則返回相應(yīng)的資源。如果認(rèn)證失敗有额，則仍返回401狀態(tài)般又，要求重新進(jìn)行認(rèn)證。

BASIC認(rèn)證過程

DIGEST認(rèn)證（基本認(rèn)證）

Digest認(rèn)證也是采用質(zhì)詢/響應(yīng)的認(rèn)證模式巍佑，可以看做是基本認(rèn)證的增強版本茴迁。
Digest用了一種nonce隨機數(shù)字符串，雙方約好對哪些信息進(jìn)行哈希運算即可完成雙方身份的驗證萤衰。Digest模式避免了密碼在網(wǎng)絡(luò)上明文傳輸堕义，提高了安全性，但它仍然存在缺點脆栋，例如認(rèn)證報文被攻擊者攔截到攻擊者可以獲取到資源倦卖，Digest認(rèn)證提供了高于 BASIC 認(rèn)證的安全等級。

支持： HTTP1.1提出的基本認(rèn)證的替代方法椿争。

優(yōu)點：提供了密碼被竊聽的保護(hù)機制怕膛。

缺點：DIGEST認(rèn)證安全等級雖高于 BASIC認(rèn)證，提供了密碼被竊聽的保護(hù)機制秦踪，但并不能防止用戶偽裝褐捻。安全性不夠掸茅。

認(rèn)證步驟：
認(rèn)證步驟與BASEC認(rèn)證步驟大致一樣，不同第方法在第2柠逞、3 步：

第2步：WWW-Authenticate 的內(nèi)容不一樣昧狮，提供 認(rèn)證域(realm)、隨機生成且只使用一次的隨機數(shù)字符串(nonce)板壮、加密方法(algorithm)逗鸣、保護(hù)質(zhì)量(qop) 等。

第3步：客戶端消息頭Authorization 返回進(jìn)行 DIGEST 認(rèn)證需要的字段：realm个束、nonce慕购、url、response茬底。因服務(wù)器在接受到 Authorization 后沪悲，就擁有與客戶端同樣的信息，因此服務(wù)器可以進(jìn)行同樣的計算阱表，以驗證客戶端提交的 response 值的正確性殿如。

response 值由三步計算而成：
1）對用戶名、認(rèn)證域(realm)以及密碼的合并值（使用冒號：作為分割符）計算 MD5 哈希值最爬，結(jié)果稱為 HA1涉馁。
2）對HTTP方法以及URI的摘要的合并值計算 MD5 哈希值，例如爱致，"GET" 和 "/dir/index.html"烤送，結(jié)果稱為 HA2。
3）對HA1糠悯、服務(wù)器密碼隨機數(shù)(nonce)帮坚、請求計數(shù)(nc)、客戶端密碼隨機數(shù)(nonce)互艾、保護(hù)質(zhì)量(qop)以及 HA2 的合并值計算 MD5 哈希值试和。結(jié)果即為客戶端提供的response 值。

response生成方式

DIGEST認(rèn)證過程

SSL客戶端認(rèn)證

借由HTTPS的客戶端證書完成認(rèn)證的方式纫普。憑借客戶端證書認(rèn)證阅悍，服務(wù)器可確認(rèn)訪問是否來自自己登錄的客戶端。
優(yōu)點：安全性高昨稼。
缺點：成本高节视，一般使用在銀行、金融 方面假栓。

FormBase認(rèn)證（基于表單認(rèn)證）

基于表單認(rèn)證方式并不是 HTTP 協(xié)議中定義的寻行，而是使用由web應(yīng)用程序各自實現(xiàn)基于表單的認(rèn)證方式，在通過Cookie和Session的方式來保持用戶的狀態(tài)但指。

HTTP中介—— 代理 和 網(wǎng)關(guān)

HTTP代理服務(wù)器

代理服務(wù)器（Proxy Server）寡痰，其功能就是代理網(wǎng)絡(luò)用戶去取得網(wǎng)絡(luò)信息∑宓剩可理解為拦坠，網(wǎng)絡(luò)信息的中轉(zhuǎn)站。

對于web客戶端來說剩岳，代理扮演的是服務(wù)器的角色贞滨，接受 Request，返回 Response拍棕；
對于web服務(wù)器來說晓铆，代理扮演的是客戶端的角色，發(fā)送 Request绰播，接受 Response骄噪；

代理服務(wù)器是介于瀏覽器和Web服務(wù)器之間的一臺服務(wù)器，有了它之后蠢箩，瀏覽器不是直接到Web服務(wù)器去取回網(wǎng)頁而是向代理服務(wù)器發(fā)出請求链蕊，Request信號會先送到代理服務(wù)器，由代理服務(wù)器來取回瀏覽器所需要的信息并傳送給你的瀏覽器谬泌。

而且滔韵，大部分代理服務(wù)器都具有緩沖的功能，就好象一個大的Cache掌实，它有很大的存儲空間陪蜻，它不斷將新取得數(shù)據(jù)儲存到它本機的存儲器上，如果瀏覽器所請求的數(shù)據(jù)在它本機的存儲器上已經(jīng)存在而且是最新的贱鼻，那么它就不重新從Web服務(wù)器取數(shù)據(jù)宴卖，而直接將存儲器上的數(shù)據(jù)傳送給用戶的瀏覽器，這樣就能顯著提高瀏覽速度和效率忱嘹。

代理的作用

抓包嘱腥、FQ、匿名訪問拘悦、過濾器 等

HTTP網(wǎng)關(guān)

網(wǎng)關(guān)扮演的是“協(xié)議轉(zhuǎn)換器”的角色齿兔，它抽象出了一種能夠到達(dá)資源的方法；

代理連接的是兩個或多個始終相同的應(yīng)用程序础米，而網(wǎng)關(guān)連接的是兩個或多個使用不同協(xié)議的端點分苇；

web網(wǎng)關(guān)在一側(cè)使用HTTP協(xié)議，在另一側(cè)使用另一種協(xié)議
第一種：（HTTP/）服務(wù)器端網(wǎng)關(guān)：通過HTTP協(xié)議與客戶端對話屁桑，通過其他協(xié)議與服務(wù)器通信（例如發(fā)郵件）医寿；
第二種：（/HTTP）客戶端網(wǎng)關(guān)：通過其他協(xié)議與客戶端對話，通過HTTP協(xié)議與服務(wù)器通信（例如查收有郵件）蘑斧。

常見網(wǎng)關(guān)類型：
（HTTP/*）服務(wù)器端web網(wǎng)關(guān)靖秩、（HTTP/HTTPS）服務(wù)器端安全網(wǎng)關(guān)须眷、（HTTPS/HTTP）客戶端安全加速器網(wǎng)關(guān)、資源網(wǎng)關(guān)