CDN訪問(wèn)異常篇之502/503/504錯(cuò)誤

一. 源站不通或源站域名無(wú)法解析

CDN 都是公網(wǎng)上的節(jié)點(diǎn)寺擂，CDN配置的源站必須要公網(wǎng)可達(dá)。如果配置的源站IP公網(wǎng)不可達(dá)锨匆、端口不通或者源站域名沒(méi)有解析褥紫，則會(huì)導(dǎo)致CDN回源請(qǐng)求源站失敗姜性，報(bào)錯(cuò)5xx。

常見(jiàn)的幾種異常情況如下：

(1)源站網(wǎng)絡(luò)不通髓考，測(cè)試無(wú)法ping通源站IP部念。ping測(cè)試命令：ping 源站IP

(2)源站端口不通或源站直接響應(yīng)5xx錯(cuò)誤。例如以下案例氨菇，telnet端口報(bào)錯(cuò)Connection timed out

i)如果源站端口配置的是80儡炼，則測(cè)試80端口是否通：telnet 源站IP 80

ii)如果源站端口配置的是443，則測(cè)試443端口是否通查蓉。如果源站端口配置的是自定義端口乌询，則測(cè)試自定義端口是否通。

iii)可以在CDN控制臺(tái)獲取配置的源站地址和端口豌研，然后本地host綁定到源站妹田，固定源站做七層測(cè)試，查看是否是源站直接無(wú)響應(yīng)或源站直接響應(yīng)5xx鹃共，具體可以參考

二.CDN配置了HTTPS回源鬼佣，但源站不支持HTTPS

（1）源站端口配置成443，但源站不支持HTTPS

在CDN控制臺(tái)的源站配置界面霜浴，如果源站端口配置成443晶衷，則CDN回源的時(shí)候是HTTPS回源到源站的443端口。源站需要開(kāi)放443端口阴孟，且配置HTTPS證書(shū)房铭。如果源站不支持HTTPS訪問(wèn)，則CDN回源失敗温眉，報(bào)錯(cuò)5xx缸匪。對(duì)于這種情況，可以把回源端口改成80类溢；如果業(yè)務(wù)需要443回源的話凌蔬，那么需要在源站配置HTTPS證書(shū)露懒。

（2）CDN配置了協(xié)議跟隨回源，但是源站不支持HTTPS訪問(wèn)砂心。

協(xié)議跟隨回源如果設(shè)置成“HTTPS”懈词，則CDN是以HTTPS回源；協(xié)議跟隨回源如果設(shè)置成“跟隨”辩诞，則當(dāng)客戶(hù)端是HTTPS訪問(wèn)的時(shí)候坎弯，CDN是HTTPS回源。源站不支持HTTPS的情況下译暂，會(huì)出現(xiàn)訪問(wèn)失敗抠忘。對(duì)于這種情況，需要關(guān)閉協(xié)議跟隨回源功能外永，或設(shè)置為HTTP回源崎脉。

三.源站開(kāi)啟了SNI校驗(yàn)，但是CDN沒(méi)有開(kāi)啟“回源SNI”

CDN回源默認(rèn)是不帶SNI信息的伯顶，如果您的源站IP綁定了多個(gè)域名囚灼，當(dāng)CDN節(jié)點(diǎn)以HTTPS協(xié)議訪問(wèn)您的源站時(shí)，由于沒(méi)有帶SNI信息祭衩，會(huì)導(dǎo)致源站無(wú)法正確響應(yīng)HTTPS證書(shū)灶体，導(dǎo)致回源失敗。因?yàn)檫@個(gè)問(wèn)題導(dǎo)致的錯(cuò)誤掐暮，一般是503 Service Temporarily Unavailable錯(cuò)誤赃春，而且很快就會(huì)返回這個(gè)錯(cuò)誤兄纺。您可以在CDN控制臺(tái)設(shè)置開(kāi)啟回源SNI鼎姊，指明具體訪問(wèn)域名澄者。具體SNI的介紹以及配置方法參考這里。

四.源站存在安全防護(hù)規(guī)則

源站的相關(guān)安全防護(hù)規(guī)則導(dǎo)致的CDN回源異常衷戈，通常會(huì)在10秒以?xún)?nèi)就返回5xx錯(cuò)誤，大部分情況會(huì)返回503 Service Temporarily Unavailable的錯(cuò)誤层坠，具體的排查方法和解決方案可以參考文檔源站安全策略導(dǎo)致5xx殖妇。

（1）源站服務(wù)器開(kāi)啟了安全組限制，限制了CDN節(jié)點(diǎn)的訪問(wèn)

（2）源站服務(wù)器配置了單IP訪問(wèn)次數(shù)限制破花，把CDN的回源IP當(dāng)成了異常IP

（3）源站存在云鎖谦趣、安全狗、防火墻等安全策略座每，攔截了CDN的回源IP

（4）源站W(wǎng)eb服務(wù)異城岸欤或服務(wù)器超載

五. 源站超時(shí)無(wú)響應(yīng)導(dǎo)致CDN回源超時(shí)

CDN 回源有嚴(yán)格的超時(shí)時(shí)間，四層 TCP 是 10 秒超時(shí)峭梳，七層HTTP / HTTPS是 30 秒超時(shí)舰绘，當(dāng)超過(guò)該時(shí)間時(shí)即使后續(xù)源站響應(yīng)正常也是會(huì)返回 5xx錯(cuò)誤蹂喻，通常因CDN回源超時(shí)導(dǎo)致的問(wèn)題，會(huì)響應(yīng)504Gateway Time-out錯(cuò)誤捂寿】谒模可以綁定源站去測(cè)試源站的響應(yīng)速度，如果超過(guò)30秒秦陋，需要檢查源站服務(wù)蔓彩，優(yōu)化源站的響應(yīng)速度，確保源站返回請(qǐng)求時(shí)間控制在一個(gè)較短的時(shí)間內(nèi)驳概，另外也可以申請(qǐng)延長(zhǎng)CDN域名的默認(rèn)超時(shí)時(shí)長(zhǎng)赤嚼，詳細(xì)請(qǐng)參考配置回源請(qǐng)求超時(shí)時(shí)間。

六. 跨境回源或源站側(cè)網(wǎng)絡(luò)異常

回源存在跨境鏈路導(dǎo)致的CDN回源超時(shí)抡句，響應(yīng)5xx錯(cuò)誤探膊。例如源站在境外，中國(guó)大陸的用戶(hù)訪問(wèn)的時(shí)候待榔，是先訪問(wèn)到中國(guó)大陸的CDN節(jié)點(diǎn)逞壁，然后中國(guó)大陸的CDN節(jié)點(diǎn)走跨境鏈路，回源到境外的源站锐锣；亦或者源站在中國(guó)大陸腌闯，境外用戶(hù)訪問(wèn)的時(shí)候先請(qǐng)求到境外的CDN節(jié)點(diǎn)，境外的CDN節(jié)點(diǎn)走跨境鏈路雕憔，回源到中國(guó)大陸的源站姿骏。由于CDN回源走的都是公網(wǎng)，這種情況涉及到跨境鏈路斤彼，需要走國(guó)際互聯(lián)網(wǎng)出口以及境外運(yùn)營(yíng)商的鏈路分瘦，本身就存在一定的不穩(wěn)定因素。還有一種情況是源站側(cè)機(jī)房的網(wǎng)絡(luò)差琉苇，或源站側(cè)網(wǎng)絡(luò)不穩(wěn)定嘲玫。

1.HTTP Get 和 Post 區(qū)別

get 方法一般用于請(qǐng)求，比如你在瀏覽器地址欄輸入www.cxuanblog.com其實(shí)就是發(fā)送了一個(gè) get 請(qǐng)求并扇，它的主要特征是請(qǐng)求服務(wù)器返回資源去团，而 post 方法一般用于

表單的提交，相當(dāng)于是把信息提交給服務(wù)器穷蛹，等待服務(wù)器作出響應(yīng)土陪，get 相當(dāng)于一個(gè)是 pull/拉的操作，而 post 相當(dāng)于是一個(gè) push/推的操作肴熏。

get 方法是不安全的鬼雀，因?yàn)槟阍诎l(fā)送請(qǐng)求的過(guò)程中，你的請(qǐng)求參數(shù)會(huì)拼在 URL 后面蛙吏，從而導(dǎo)致容易被攻擊者竊取取刃，對(duì)你的信息造成破壞和偽造蹋肮；

而 post 方法是把參數(shù)放在請(qǐng)求體 body 中的，這對(duì)用戶(hù)來(lái)說(shuō)不可見(jiàn)璧疗。

get 請(qǐng)求的 URL 有長(zhǎng)度限制坯辩，而 post 請(qǐng)求會(huì)把參數(shù)和值放在消息體中，對(duì)數(shù)據(jù)長(zhǎng)度沒(méi)有要求崩侠。

get 請(qǐng)求會(huì)被瀏覽器主動(dòng) cache漆魔，而 post 不會(huì)，除非手動(dòng)設(shè)置却音。

get 請(qǐng)求在瀏覽器反復(fù)的回退/前進(jìn)操作是無(wú)害的改抡，而 post 操作會(huì)再次提交表單請(qǐng)求。

get 請(qǐng)求在發(fā)送過(guò)程中會(huì)產(chǎn)生一個(gè) TCP 數(shù)據(jù)包系瓢；post 在發(fā)送過(guò)程中會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包阿纤。對(duì)于 get 方式的請(qǐng)求，瀏覽器會(huì)把 http header 和 data 一并發(fā)送出去夷陋，服務(wù)器響應(yīng) 200（返回?cái)?shù)據(jù)）欠拾；而對(duì)于 post，瀏覽器先發(fā)送 header骗绕，服務(wù)器響應(yīng) 100 continue藐窄，瀏覽器再發(fā)送 data，服務(wù)器響應(yīng) 200 ok（返回?cái)?shù)據(jù)）

無(wú)狀態(tài)協(xié)議(Stateless Protocol)就是指瀏覽器對(duì)于事務(wù)的處理沒(méi)有記憶能力酬土。舉個(gè)例子來(lái)說(shuō)就是比如客戶(hù)請(qǐng)求獲得網(wǎng)頁(yè)之后關(guān)閉瀏覽器荆忍，然后再次啟動(dòng)瀏覽器，登錄該網(wǎng)站撤缴，但是服務(wù)器并不知道客戶(hù)關(guān)閉了一次瀏覽器刹枉。

HTTP 就是一種無(wú)狀態(tài)的協(xié)議，他對(duì)用戶(hù)的操作沒(méi)有記憶能力屈呕∥⒈Γ可能大多數(shù)用戶(hù)不相信，他可能覺(jué)得每次輸入用戶(hù)名和密碼登陸一個(gè)網(wǎng)站后凉袱，下次登陸就不再重新輸入用戶(hù)名和密碼了。這其實(shí)不是 HTTP 做的事情侦铜，起作用的是一個(gè)叫做小甜餅(Cookie)的機(jī)制吉懊。它能夠讓瀏覽器具有記憶能力蕉鸳。

數(shù)字證書(shū)的有效性如何驗(yàn)證

主要從三個(gè)方面：

1,數(shù)字證書(shū)有效期驗(yàn)證，2,根證書(shū)驗(yàn)證，3,CRL驗(yàn)證

1羡疗，數(shù)字證書(shū)有效期驗(yàn)證

就是說(shuō)證書(shū)的使用時(shí)間要在起始時(shí)間和結(jié)束時(shí)間之內(nèi)。通過(guò)解析證書(shū)很容易得到證書(shū)的有效期

2汹族，根證書(shū)驗(yàn)證

普通的證書(shū)一般包括三部分：用戶(hù)信息，用戶(hù)公鑰蒙袍，以及CA簽名

那么我們要驗(yàn)證這張證書(shū)就需要驗(yàn)證CA簽名的真?zhèn)巍Ｄ敲淳托枰狢A公鑰嫩挤。而CA公鑰存在于另外一張證書(shū)（稱(chēng)這張證書(shū)是對(duì)普通證書(shū)簽名的證書(shū)）中害幅。因此我們又需要驗(yàn)證這另外一張證書(shū)的真?zhèn)巍Ｒ虼擞中枰?yàn)證另另外證書(shū)（稱(chēng)這張證書(shū)是對(duì)另外一張證書(shū)簽名的證書(shū)）的真?zhèn)纹裾选Ｒ来瓮禄厮菀韵郑偷玫揭粭l證書(shū)鏈。那么這張證書(shū)鏈從哪里結(jié)束呢约啊？就是在根證書(shū)結(jié)束（即驗(yàn)證到根證書(shū)結(jié)束）邑遏。根證書(shū)是個(gè)很特別的證書(shū)，它是CA中心自己給自己簽名的證書(shū)（即這張證書(shū)是用CA公鑰對(duì)這張證書(shū)進(jìn)行簽名）恰矩。信任這張證書(shū)记盒，就代表信任這張證書(shū)下的證書(shū)鏈。

所有用戶(hù)在使用自己的證書(shū)之前必須先下載根證書(shū)外傅。所謂根證書(shū)驗(yàn)證就是：用根證書(shū)公鑰來(lái)驗(yàn)證該證書(shū)的頒發(fā)者簽名纪吮。所以首先必須要有根證書(shū)，并且根證書(shū)必須在受信任的證書(shū)列表（即信任域)

3栏豺，CRL驗(yàn)證

CRL是經(jīng)過(guò)CA簽名的證書(shū)作廢列表彬碱，用于證書(shū)凍結(jié)和撤銷(xiāo)。一般來(lái)說(shuō)證書(shū)中有CRL地址奥洼，供HTTP或者LDAP方式訪問(wèn)巷疼，通過(guò)解析可得到CRL地址，然后下載CRL進(jìn)行驗(yàn)證灵奖。

并且證書(shū)中有CRL生效日期以及下次更新的日期嚼沿，因此CRL是自動(dòng)更新的，因此會(huì)有延遲性瓷患。

于是呢骡尽，還有另外一種方式OSCP證書(shū)狀態(tài)在線查詢(xún)，可以即時(shí)的查詢(xún)證書(shū)狀態(tài)擅编。

兩種證書(shū)狀態(tài)查詢(xún)方式的比較：

如何向CA申請(qǐng)證書(shū)：

1.自己本地先生成一對(duì)密匙攀细，然后拿著自己的公匙以及其他信息（比如說(shuō)企業(yè)名稱(chēng)啊什么的）去CA申請(qǐng)數(shù)字證書(shū)。

2.CA在拿到這些信息后爱态，會(huì)選擇一種單向Hash算法（比如說(shuō)常見(jiàn)的MD5）對(duì)這些信息進(jìn)行加密谭贪，加密之后的東西我們稱(chēng)之為摘要。單向Hash算法有一種特點(diǎn)就是單向不可逆的锦担，只要原始內(nèi)容有一點(diǎn)變化俭识，加密后的數(shù)據(jù)都將會(huì)是千差萬(wàn)別（當(dāng)然也有很小的可能性會(huì)重復(fù)，有興趣的小伙伴鴿巢原理了解一下）洞渔，這樣就防止了信息被篡改套媚。

3.生成摘要后還不算完缚态，CA還會(huì)用自己的私匙對(duì)摘要進(jìn)行加密，摘要加密后的數(shù)據(jù)我們稱(chēng)之為數(shù)字簽名堤瘤。

4.最后玫芦，CA將會(huì)把我們的申請(qǐng)信息（包含服務(wù)器的公匙）和數(shù)字簽名整合在一起，由此而生成數(shù)字證書(shū)宙橱。然后CA將數(shù)字證書(shū)傳遞給我們姨俩。

數(shù)字證書(shū)怎么起作用呢？

服務(wù)器在獲取到數(shù)字證書(shū)后师郑，服務(wù)器會(huì)將數(shù)字證書(shū)發(fā)送給客戶(hù)端环葵，客戶(hù)端就需要用CA的公匙解密數(shù)字證書(shū)并驗(yàn)證數(shù)字證書(shū)的合法性。

那我們?nèi)绾文苣玫紺A的公匙呢宝冕？我們的電腦和瀏覽器中已經(jīng)內(nèi)置了一部分權(quán)威機(jī)構(gòu)的根證書(shū)张遭，這些根證書(shū)中包含了CA的公匙。之所以是根證書(shū)地梨，是因?yàn)楝F(xiàn)實(shí)生活中菊卷，認(rèn)證中心是分層級(jí)的，也就是說(shuō)有頂級(jí)認(rèn)證中心宝剖，也有下面的各個(gè)子級(jí)的認(rèn)證中心洁闰，是一個(gè)樹(shù)狀結(jié)構(gòu)，計(jì)算機(jī)中內(nèi)置的是最頂級(jí)機(jī)構(gòu)的根證書(shū)万细，不過(guò)不用擔(dān)心扑眉，根證書(shū)的公匙在子級(jí)也是適用的±党客戶(hù)端用CA的公匙解密數(shù)字證書(shū)腰素，如果解密成功則說(shuō)明證書(shū)來(lái)源于合法的認(rèn)證機(jī)構(gòu)。解密成功后雪营，客戶(hù)端就拿到了摘要弓千。此時(shí)，客戶(hù)端會(huì)按照和CA一樣的Hash算法將申請(qǐng)信息生成一份摘要献起，并和解密出來(lái)的那份做對(duì)比洋访，如果相同則說(shuō)明內(nèi)容完整，沒(méi)有被篡改谴餐。 最后姻政，客戶(hù)端安全的從證書(shū)中拿到服務(wù)器的公匙就可以和服務(wù)器進(jìn)行安全的非對(duì)稱(chēng)加密通信了。服務(wù)器想獲得客戶(hù)端的公匙也可以通過(guò)相同方式总寒。

什么是加密套件扶歪？

　　加密套件是用于在SSL / TLS握手期間協(xié)商安全設(shè)置的算法的組合理肺。在ClientHello和ServerHello消息交換之后摄闸，客戶(hù)端發(fā)送優(yōu)先級(jí)列表的密碼支持套件善镰。然后，服務(wù)器使用從列表中選擇的密碼套件進(jìn)行響應(yīng)年枕。

TLS算法組合：

在TLS中炫欺，5類(lèi)算法組合在一起，稱(chēng)為一個(gè)CipherSuite：

認(rèn)證算法熏兄，加密算法品洛，消息認(rèn)證碼算法 簡(jiǎn)稱(chēng)MAC，密鑰交換算法摩桶，密鑰衍生算法

比較常見(jiàn)的算法組合是 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 和 ?TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256桥状， 都是ECDHE 做密鑰交換，使用RSA做認(rèn)證硝清，SHA256做PRF算法辅斟。

一個(gè)使用AES128-CBC做加密算法，用HMAC做MAC芦拿。

一個(gè)使用AES128-GCM做加密算法士飒，MAC由于GCM作為一種AEAD模式并不需要。

這里是一個(gè)加密套件的例子：

TLS _ECDHE_ RSA _ WITH_AES_128_GCM _ SHA256

2.HTTPS 的工作原理

HTTPS并非是應(yīng)用層的一種新協(xié)議蔗崎。只是HTTP通信接口部分用SSL和TLS協(xié)議代替而已酵幕。

通常，HTTP直接和TCP通信缓苛。當(dāng)使用SSL時(shí)芳撒，則演變成先和SSL通信，再由SSL和TCP通信了他嫡。簡(jiǎn)言之番官，所謂HTTPS，其實(shí)就是身披SSL協(xié)議這層外殼的HTTP钢属。

在采用SSL后徘熔，HTTP就擁有了HTTPS的加密、證書(shū)和完整性保護(hù)這些功能淆党。也就是說(shuō)HTTP加上加密處理和認(rèn)證以及完整性保護(hù)后即是HTTPS酷师。

HTTPS 協(xié)議的主要功能基本都依賴(lài)于 TLS/SSL 協(xié)議，TLS/SSL 的功能實(shí)現(xiàn)主要依賴(lài)于三類(lèi)基本算法：散列函數(shù) 染乌、對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密山孔，其利用非對(duì)稱(chēng)加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱(chēng)加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密荷憋，基于散列函數(shù)驗(yàn)證信息的完整性台颠。

TLS 具體的握手過(guò)程會(huì)根據(jù)所使用的密鑰交換算法的類(lèi)型和雙方支持的密碼套件而不同。我們以RSA 非對(duì)稱(chēng)加密來(lái)討論這個(gè)過(guò)程。整個(gè) TLS 通信流程圖如下

采用單鑰密碼系統(tǒng)的加密方法串前，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密瘫里，這種加密方法稱(chēng)為對(duì)稱(chēng)加密，也稱(chēng)為單密鑰加密荡碾。

采用單鑰密碼的加密方法谨读，同一個(gè)密鑰可以同時(shí)用來(lái)加密和解密，這種加密方法稱(chēng)為對(duì)稱(chēng)加密坛吁，也稱(chēng)為單密鑰加密劳殖。常用的單向加密算法：

1、DES（Data Encryption Standard）：數(shù)據(jù)加密標(biāo)準(zhǔn)拨脉，速度較快哆姻，適用于加密大量數(shù)據(jù)的場(chǎng)合；

2玫膀、3DES（Triple DES）：是基于DES填具，對(duì)一塊數(shù)據(jù)用三個(gè)不同的密鑰進(jìn)行三次加密，強(qiáng)度更高匆骗；

3劳景、AES（Advanced Encryption Standard）：高級(jí)加密標(biāo)準(zhǔn)，是下一代的加密算法標(biāo)準(zhǔn)碉就，速度快，安全級(jí)別高瓮钥，支持128筋量、192、256碉熄、512位密鑰的加密桨武；

對(duì)稱(chēng)加密+非對(duì)稱(chēng)加密(HTTPS采用這種方式)

使用對(duì)稱(chēng)密鑰的好處是解密的效率比較快，使用非對(duì)稱(chēng)密鑰的好處是可以使得傳輸?shù)膬?nèi)容不能被破解锈津，因?yàn)榫退隳銛r截到了數(shù)據(jù)呀酸，但是沒(méi)有對(duì)應(yīng)的私鑰，也是不能破解內(nèi)容的琼梆。就比如說(shuō)你搶到了一個(gè)保險(xiǎn)柜性誉，但是沒(méi)有保險(xiǎn)柜的鑰匙也不能打開(kāi)保險(xiǎn)柜。那我們就將對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密結(jié)合起來(lái),充分利用兩者各自的優(yōu)勢(shì)茎杂，在交換密鑰環(huán)節(jié)使用非對(duì)稱(chēng)加密方式乎赴，之后的建立通信交換報(bào)文階段則使用對(duì)稱(chēng)加密方式狞洋。

具體做法是：發(fā)送密文的一方使用對(duì)方的公鑰進(jìn)行加密處理“對(duì)稱(chēng)的密鑰”锅论，然后對(duì)方用自己的私鑰解密拿到“對(duì)稱(chēng)的密鑰”糠爬，這樣可以確保交換的密鑰是安全的前提下，使用對(duì)稱(chēng)加密方式進(jìn)行通信。所以羞海，HTTPS采用對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密兩者并用的混合加密機(jī)制

1.Client發(fā)起一個(gè)HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的請(qǐng)求闲勺，根據(jù)RFC2818的規(guī)定，Client知道需要連接Server的443（默認(rèn)）端口扣猫。

2.Server把事先配置好的公鑰證書(shū)（public key certificate）返回給客戶(hù)端。

3.Client驗(yàn)證公鑰證書(shū)：比如是否在有效期內(nèi)翘地，證書(shū)的用途是不是匹配Client請(qǐng)求的站點(diǎn)申尤，是不是在CRL吊銷(xiāo)列表里面，它的上一級(jí)證書(shū)是否有效衙耕，這是一個(gè)遞歸的過(guò)程昧穿，直到驗(yàn)證到根證書(shū)（操作系統(tǒng)內(nèi)置的Root證書(shū)或者Client內(nèi)置的Root證書(shū)）。如果驗(yàn)證通過(guò)則繼續(xù)橙喘，不通過(guò)則顯示警告信息时鸵。

4.Client使用偽隨機(jī)數(shù)生成器生成加密所使用的對(duì)稱(chēng)密鑰，然后用證書(shū)的公鑰加密這個(gè)對(duì)稱(chēng)密鑰厅瞎，發(fā)給Server饰潜。

5.Server使用自己的私鑰（private key）解密這個(gè)消息，得到對(duì)稱(chēng)密鑰和簸。至此彭雾，Client和Server雙方都持有了相同的對(duì)稱(chēng)密鑰。

6.Server使用對(duì)稱(chēng)密鑰加密“明文內(nèi)容A”锁保，發(fā)送給Client薯酝。

7.Client使用對(duì)稱(chēng)密鑰解密響應(yīng)的密文，得到“明文內(nèi)容A”爽柒。

8.Client再次發(fā)起HTTPS的請(qǐng)求吴菠，使用對(duì)稱(chēng)密鑰加密請(qǐng)求的“明文內(nèi)容B”，然后Server使用對(duì)稱(chēng)密鑰解密密文浩村，得到“明文內(nèi)容B”做葵。

HTTPS的結(jié)構(gòu)圖

1. 客戶(hù)使用https的URL訪問(wèn)Web服務(wù)器，要求與Web服務(wù)器建立SSL連接（通知可加密的算法）心墅。

2. Web服務(wù)器收到客戶(hù)端請(qǐng)求后蜂挪，會(huì)將網(wǎng)站的電子證書(shū)（證書(shū)中包含公鑰）傳送一份給客戶(hù)端。

3. 客戶(hù)端確認(rèn)電子證書(shū)是否剛才訪問(wèn)網(wǎng)站所屬

4. 客戶(hù)端的瀏覽器根據(jù)雙方同意的安全等級(jí)嗓化，建立會(huì)話密鑰棠涮，然后利用網(wǎng)站的公鑰將會(huì)話密鑰加密，并傳送給網(wǎng)站刺覆。

5. Web服務(wù)器利用自己的私鑰解密出會(huì)話密鑰（客戶(hù)端發(fā)來(lái)的對(duì)稱(chēng)加密密鑰）严肪。

6. Web服務(wù)器利用對(duì)稱(chēng)密鑰加密與客戶(hù)端之間的通信。

2.2.1 客戶(hù)端訪問(wèn)https連接

這一步，就是相當(dāng)于我們?cè)跒g覽器上輸入url回車(chē)的過(guò)程驳糯。這個(gè)時(shí)候?yàn)g覽器或者客戶(hù)端（接下來(lái)統(tǒng)一為客戶(hù)端）會(huì)把我們客戶(hù)端支持的加密算法Cipher Suite（密鑰算法套件）帶給服務(wù)端篇梭。

2.2.2 - 2.2.3 服務(wù)端發(fā)送證書(shū)（公鑰）給客戶(hù)端

服務(wù)端接收Cipher后，和自己支持的加密算法進(jìn)行比對(duì)酝枢，如果不符合恬偷，則斷開(kāi)連接。否則帘睦，服務(wù)端會(huì)把符合的算法和證書(shū)發(fā)給客戶(hù)端袍患，包括證書(shū)時(shí)間、證書(shū)日期竣付、證書(shū)頒發(fā)的機(jī)構(gòu)诡延。

2.2.4- 2.2.5 客戶(hù)端驗(yàn)證服務(wù)端的證書(shū)

1、客戶(hù)端驗(yàn)證證書(shū)古胆，包括頒發(fā)證書(shū)的機(jī)構(gòu)是否合法與是否過(guò)期肆良，證書(shū)中包含的網(wǎng)站地址是否與正在訪問(wèn)的地址一致等

2、驗(yàn)證通過(guò)后（或者用戶(hù)接受了不信任的證書(shū)）逸绎，客戶(hù)端會(huì)生成一個(gè)隨機(jī)字符串惹恃，然后用服務(wù)端的公鑰進(jìn)行加密。這里就保證了只有服務(wù)端才能看到這串隨機(jī)字符串（因?yàn)榉?wù)端擁有公鑰對(duì)應(yīng)的私鑰棺牧，RSA解密座舍，可以知道客戶(hù)端的隨機(jī)字符串）。

3陨帆、生成握手信息? 用約定好的HASH算法曲秉，對(duì)握手信息進(jìn)行取HASH，然后用隨機(jī)字符串加密握手信息和握手信息的簽名HASH值疲牵，把結(jié)果發(fā)給服務(wù)端承二。這里之所以要帶上握手信息的HASH是因?yàn)椋乐剐畔⒈淮鄹母侔帧Ｈ绻畔⒈淮鄹暮ヰ敲捶?wù)端接收到信息進(jìn)行HASH時(shí)，就會(huì)發(fā)現(xiàn)HASH值和客戶(hù)端傳回來(lái)的不一樣识啦。這里就保證了信息不會(huì)被篡改负蚊。。

其他解釋?zhuān)?/p>

一颓哮、首先HTTP請(qǐng)求服務(wù)端生成證書(shū)家妆，客戶(hù)端對(duì)證書(shū)的有效期、合法性冕茅、域名是否與請(qǐng)求的域名一致伤极、證書(shū)的公鑰（RSA加密）等進(jìn)行校驗(yàn)蛹找；

二、客戶(hù)端如果校驗(yàn)通過(guò)后哨坪，就根據(jù)證書(shū)的公鑰的有效庸疾， 生成隨機(jī)數(shù)，隨機(jī)數(shù)使用公鑰進(jìn)行加密（RSA加密）当编；

三届慈、消息體產(chǎn)生的后，對(duì)它的摘要進(jìn)行MD5（或者SHA1）算法加密忿偷，此時(shí)就得到了RSA簽名金顿；

四、發(fā)送給服務(wù)端牵舱，此時(shí)只有服務(wù)端（RSA私鑰）能解密。

五缺虐、解密得到的隨機(jī)數(shù)芜壁，再用AES加密，作為密鑰（此時(shí)的密鑰只有客戶(hù)端和服務(wù)端知道）高氮。

證書(shū)驗(yàn)證階段：

瀏覽器發(fā)起 HTTPS 請(qǐng)求慧妄。

服務(wù)端返回 HTTPS 證書(shū)。

客戶(hù)端驗(yàn)證證書(shū)是否合法剪芍，如果不合法則提示告警塞淹。

數(shù)據(jù)傳輸階段：

當(dāng)證書(shū)驗(yàn)證合法后，在本地生成隨機(jī)數(shù)罪裹。

通過(guò)公鑰加密隨機(jī)數(shù)饱普，并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端。

服務(wù)端通過(guò)私鑰對(duì)隨機(jī)數(shù)進(jìn)行解密状共。

服務(wù)端通過(guò)客戶(hù)端傳入的隨機(jī)數(shù)構(gòu)造對(duì)稱(chēng)加密算法套耕，對(duì)返回結(jié)果內(nèi)容進(jìn)行加密后傳輸。

非對(duì)稱(chēng)加密

這種方法就是峡继，讓客戶(hù)端和服務(wù)器都擁有兩把鑰匙冯袍，一把鑰匙是公開(kāi)的(全世界知道都沒(méi)關(guān)系)，我們稱(chēng)之為公鑰碾牌；另一把鑰匙則是保密的(只有自己本人才知道)康愤，我們稱(chēng)之為私鑰。這且舶吗，用公鑰加密的數(shù)據(jù)征冷，只有對(duì)應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)誓琼，只有對(duì)應(yīng)的公鑰才能解密资盅。

非對(duì)稱(chēng)加密比較慢调榄，對(duì)稱(chēng)加密不安全

這樣，服務(wù)器在給客戶(hù)端傳輸數(shù)據(jù)的過(guò)程中呵扛，可以用客戶(hù)端明文給他的公鑰進(jìn)行加密每庆，然后客戶(hù)端收到后，再用自己的私鑰進(jìn)行解密今穿＄土椋客戶(hù)端給服務(wù)器發(fā)送數(shù)據(jù)的時(shí)候也一樣采取這樣的方式。這樣就能保持?jǐn)?shù)據(jù)的安全傳輸了蓝晒。畫(huà)個(gè)圖理解一下：

非對(duì)稱(chēng)加密也并非是安全的腮出，

服務(wù)器以明文的方式給客戶(hù)端傳輸公鑰的時(shí)候，中間人截取了這把屬于服務(wù)器的公鑰芝薇，并且把中間人自己的公鑰冒充服務(wù)器的公鑰傳輸給了客戶(hù)端胚嘲。

之后客戶(hù)端就會(huì)用中間人的公鑰來(lái)加密自己生成的密鑰。然后把被加密的密鑰傳輸給服務(wù)器洛二，這個(gè)時(shí)候中間人又把密鑰給截取了馋劈，中間人用自己的私鑰對(duì)這把被加密的密鑰進(jìn)行解密，解密后中間人就可以獲得這把密鑰了晾嘶。

最后中間人再對(duì)這把密鑰用剛才服務(wù)器的公鑰進(jìn)行加密妓雾，再發(fā)給服務(wù)器。如圖：

數(shù)字證書(shū)登場(chǎng)

服務(wù)器在給客戶(hù)端傳輸公鑰的過(guò)程中垒迂，會(huì)把公鑰以及服務(wù)器的個(gè)人信息通過(guò)Hash算法生成信息摘要械姻。如圖

為了防止信息摘要被人調(diào)換，服務(wù)器還會(huì)用CA提供的私鑰對(duì)信息摘要進(jìn)行加密來(lái)形成數(shù)字簽名机断。如圖:

并且楷拳，最后還會(huì)把原來(lái)沒(méi)Hash算法之前的個(gè)人信息以及公鑰 和 數(shù)字簽名合并在一起，形成數(shù)字證書(shū)吏奸。如圖

當(dāng)客戶(hù)端拿到這份數(shù)字證書(shū)之后唯竹，就會(huì)用CA提供的公鑰來(lái)對(duì)數(shù)字證書(shū)里面的數(shù)字簽名進(jìn)行解密來(lái)得到信息摘要，然后對(duì)數(shù)字證書(shū)里服務(wù)器的公鑰以及個(gè)人信息進(jìn)行Hash得到另外一份信息摘要苦丁。最后把兩份信息摘要進(jìn)行對(duì)比浸颓，如果一樣，則證明這個(gè)人是服務(wù)器旺拉，否則就不是产上。如圖：

這樣，就可以保證服務(wù)器的公鑰安全著交給客戶(hù)端了蛾狗。

3.證書(shū)的驗(yàn)證

對(duì)稱(chēng)加密：加密使用的秘鑰和解密使用的秘鑰是相同的晋涣，也就是說(shuō)加密和解密都使用同一個(gè)秘鑰，加密算法是公開(kāi)的沉桌，秘鑰是加密者和解密者絕對(duì)保密的

非對(duì)稱(chēng)加密：加密使用的秘鑰和解密使用的秘鑰是不相同的谢鹊，HTTPS在數(shù)字證書(shū)驗(yàn)證的時(shí)候算吩，采用的RSA密碼體制就是一種非對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密：指的是加、解密使用不同的密鑰佃扼，一把作為公開(kāi)的公鑰偎巢，另一把作為私鑰。公鑰加密的信息兼耀，只有私鑰才能解密压昼。反之，私鑰加密的信息瘤运，只有公鑰才能解密窍霞。

舉個(gè)例子，你向某公司服務(wù)器請(qǐng)求公鑰拯坟，服務(wù)器將公鑰發(fā)給你但金，你使用公鑰對(duì)消息加密，那么只有私鑰的持有人才能對(duì)你的消息解密郁季。與對(duì)稱(chēng)加密不同的是冷溃，公司服務(wù)器不需要將私鑰通過(guò)網(wǎng)絡(luò)發(fā)送出去伪冰，因此安全性大大提高脆丁。

RSA是一種公鑰密碼體制，現(xiàn)在使用非常廣泛，這個(gè)密碼體制分為三部分塞琼，公鑰、私鑰禁舷、加密算法彪杉，其中公鑰和加密算法是公布的，私鑰是自己保密的牵咙。這種機(jī)制最大的特點(diǎn)是派近，通過(guò)公鑰加密的密文只有對(duì)應(yīng)的私鑰才能解密，同樣通過(guò)私鑰加密的密文也只有對(duì)應(yīng)的公鑰才能解密洁桌。下面我們將會(huì)講到HTTPS是如何通過(guò)RSA這種密碼體制去驗(yàn)證身份的

1.瀏覽器要求基于數(shù)字證書(shū)對(duì)網(wǎng)站進(jìn)行在線身份鑒別（身份認(rèn)證）渴丸；

2.網(wǎng)站（Web服務(wù)器）將數(shù)字證書(shū)傳遞給用戶(hù)瀏覽器；

3. 瀏覽器驗(yàn)證網(wǎng)站數(shù)字證書(shū)的有效性和可信性另凌，包括驗(yàn)證網(wǎng)站證書(shū)是否由可信的電子認(rèn)證機(jī)構(gòu)簽發(fā)（用CA的公鑰驗(yàn)證簽名）谱轨，證書(shū)上的域名是否與用戶(hù)要訪問(wèn)的網(wǎng)站域名一致，證書(shū)是否在有效期內(nèi)等吠谢；

4.證書(shū)有效性和可信性驗(yàn)證通過(guò)后土童，瀏覽器將一串隨機(jī)生成的數(shù)據(jù)傳遞到網(wǎng)站，要求網(wǎng)站對(duì)此進(jìn)行數(shù)字簽名工坊；

5.網(wǎng)站用私鑰對(duì)接收到隨機(jī)數(shù)據(jù)進(jìn)行數(shù)字簽名献汗，然后將簽名后的數(shù)據(jù)傳送到到用戶(hù)瀏覽器敢订；

?6.用戶(hù)瀏覽器使用網(wǎng)站證書(shū)上的公鑰對(duì)數(shù)字簽名后的數(shù)據(jù)進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)則說(shuō)明用戶(hù)要訪問(wèn)的網(wǎng)站確實(shí)是證書(shū)上所標(biāo)識(shí)的網(wǎng)站罢吃。

4.從輸入U(xiǎn)RL到頁(yè)面展現(xiàn)的過(guò)程

1.輸入U(xiǎn)RL后楚午，會(huì)先進(jìn)行域名解析。優(yōu)先查找本地host文件有無(wú)對(duì)應(yīng)的IP地址刃麸，沒(méi)有的話去本地DNS服務(wù)器查找醒叁，還不行的話，本地DNS服務(wù)器會(huì)去找根DNS服務(wù)器要一個(gè)域服務(wù)器的地址進(jìn)行查詢(xún)泊业，域服務(wù)器將要查詢(xún)的域名的解析服務(wù)器地址返回給本地DNS把沼，本地DNS去這里查詢(xún)就OK了。

2.瀏覽器拿到服務(wù)器的IP地址后吁伺，會(huì)向它發(fā)送HTTP請(qǐng)求饮睬。HTTP請(qǐng)求經(jīng)由一層層的處理、封裝篮奄、發(fā)出之后捆愁，最終經(jīng)由網(wǎng)絡(luò)到達(dá)服務(wù)器，建立TCP/IP連接窟却，服務(wù)器接收到請(qǐng)求并開(kāi)始處理昼丑。

3.服務(wù)器構(gòu)建響應(yīng)，再經(jīng)由一層層的處理夸赫、封裝菩帝、發(fā)出后，到達(dá)客戶(hù)端茬腿，瀏覽器處理請(qǐng)求呼奢。

4.瀏覽器開(kāi)始渲染頁(yè)面，解析HTML切平，構(gòu)建render樹(shù)握础，根據(jù)render樹(shù)的節(jié)點(diǎn)和CSS的對(duì)應(yīng)關(guān)系，進(jìn)行布局悴品，繪制頁(yè)面禀综。

一個(gè)HTTP請(qǐng)求從源端發(fā)出到在終端接收的處理過(guò)程都是要經(jīng)過(guò)以下四層。其中每一層都有各自的協(xié)議苔严。

證書(shū)包含什么信息定枷？

頒發(fā)機(jī)構(gòu)信息，公鑰邦蜜，公司信息依鸥，域名，有效期悼沈，指紋贱迟，封裝和分用

3. 瀏覽器如何驗(yàn)證證書(shū)的合法性姐扮？

瀏覽器發(fā)起 HTTPS 請(qǐng)求時(shí)，服務(wù)器會(huì)返回網(wǎng)站的 SSL 證書(shū)衣吠，瀏覽器需要對(duì)證書(shū)做以下驗(yàn)證：

驗(yàn)證域名茶敏、有效期等信息是否正確。證書(shū)上都有包含這些信息缚俏，比較容易完成驗(yàn)證惊搏；

判斷證書(shū)來(lái)源是否合法。每份簽發(fā)證書(shū)都可以根據(jù)驗(yàn)證鏈查找到對(duì)應(yīng)的根證書(shū)忧换，操作系統(tǒng)恬惯、瀏覽器會(huì)在本地存儲(chǔ)權(quán)威機(jī)構(gòu)的根證書(shū)，利用本地根證書(shū)可以對(duì)對(duì)應(yīng)機(jī)構(gòu)簽發(fā)證書(shū)完成來(lái)源驗(yàn)證亚茬；

判斷證書(shū)是否被篡改酪耳。需要與 CA 服務(wù)器進(jìn)行校驗(yàn)；

判斷證書(shū)是否已吊銷(xiāo)刹缝。通過(guò)CRL（Certificate Revocation List 證書(shū)注銷(xiāo)列表）和 OCSP（Online Certificate Status Protocol 在線證書(shū)狀態(tài)協(xié)議）實(shí)現(xiàn)碗暗，其中 OCSP 可用于第3步中以減少與 CA 服務(wù)器的交互，提高驗(yàn)證效率

以上任意一步都滿(mǎn)足的情況下瀏覽器才認(rèn)為證書(shū)是合法的梢夯。

這里插一個(gè)我想了很久的但其實(shí)答案很簡(jiǎn)單的問(wèn)題：

既然證書(shū)是公開(kāi)的言疗，如果要發(fā)起中間人攻擊，我在官網(wǎng)上下載一份證書(shū)作為我的服務(wù)器證書(shū)颂砸，那客戶(hù)端肯定會(huì)認(rèn)同這個(gè)證書(shū)是合法的噪奄，如何避免這種證書(shū)冒用的情況？

其實(shí)這就是非加密對(duì)稱(chēng)中公私鑰的用處沾凄，雖然中間人可以得到證書(shū)梗醇，但私鑰是無(wú)法獲取的知允，一份公鑰是不可能推算出其對(duì)應(yīng)的私鑰撒蟀，中間人即使拿到證書(shū)也無(wú)法偽裝成合法服務(wù)端，因?yàn)闊o(wú)法對(duì)客戶(hù)端傳入的加密數(shù)據(jù)進(jìn)行解密温鸽。

數(shù)據(jù)在經(jīng)過(guò)每一層的時(shí)候都要被對(duì)應(yīng)的協(xié)議包裝保屯，到達(dá)終端的時(shí)候，要一層一層的解包涤垫。這兩個(gè)過(guò)程叫封裝和分用姑尺。

發(fā)送時(shí)，用戶(hù)數(shù)據(jù)被HTTP封裝為報(bào)文蝠猬，每一層會(huì)將上層傳過(guò)來(lái)的報(bào)文作為本層的數(shù)據(jù)塊切蟋，并添加自己的首部，其中包含了協(xié)議標(biāo)識(shí)榆芦，這一整體作為本層報(bào)文向下傳遞柄粹。

接收時(shí)喘鸟，數(shù)據(jù)自下而上流動(dòng)，經(jīng)過(guò)每一層時(shí)被去掉報(bào)文首部驻右，根據(jù)報(bào)文標(biāo)識(shí)確定正確的上層協(xié)議什黑，最終到應(yīng)用層被應(yīng)用程序處理。

HTTP

請(qǐng)求報(bào)文有4部分組成:

響應(yīng)行堪夭，響應(yīng)頭愕把，空行，響應(yīng)體

HTTP屬于應(yīng)用層森爽，用戶(hù)觸發(fā)交互所產(chǎn)生的行為數(shù)據(jù)和服務(wù)端對(duì)此的響應(yīng)都由它封裝成HTTP報(bào)文恨豁，再交由下層協(xié)議進(jìn)行處理。報(bào)文的作用是客戶(hù)端與服務(wù)端溝通的載體爬迟，雙方都要遵循統(tǒng)一規(guī)則對(duì)信息進(jìn)行處理圣絮，這一規(guī)則稱(chēng)為HTTP。

?請(qǐng)求首部：是放在請(qǐng)求報(bào)文中的首部雕旨，它被用來(lái)告訴服務(wù)端一些信息扮匠。?響應(yīng)首部：為客戶(hù)端提供一些可能用到的信息。?通用首部：請(qǐng)求與響應(yīng)報(bào)文都包含的首部凡涩，例如Date首部?實(shí)體首部：對(duì)于報(bào)文實(shí)體主體部分的描述棒搜，比如Content-Type，表明其數(shù)據(jù)類(lèi)型活箕。?擴(kuò)展首部：開(kāi)發(fā)者自己添加的首部字段力麸，用來(lái)滿(mǎn)足定制化需求。

實(shí)體部分是可選的育韩，它被用來(lái)運(yùn)送請(qǐng)求或者響應(yīng)的數(shù)據(jù)克蚂，實(shí)體由實(shí)體首部 + 實(shí)體主體組成，實(shí)體首部對(duì)實(shí)體主體做描述筋讨。HTTP/1.1定義了以下的基本實(shí)體首部字段：

?Content-Type: 實(shí)體主體中的數(shù)據(jù)類(lèi)型埃叭。?Content-Length: 實(shí)體主體的長(zhǎng)度或者大小。悉罕，Content-Language: 和傳輸?shù)臄?shù)據(jù)最匹配的語(yǔ)言赤屋。

Content-Encoding: 來(lái)標(biāo)識(shí)服務(wù)端編碼時(shí)所用的編碼方式。

Content-Location: 要返回的數(shù)據(jù)的地址壁袄。

Content-Range: 如果是部分實(shí)體类早，用來(lái)標(biāo)記它是實(shí)體的哪個(gè)部分。

Content-MD5: 實(shí)體主體內(nèi)容的校驗(yàn)和嗜逻。

Last-Modified: 所傳輸內(nèi)容在服務(wù)器上創(chuàng)建或者最后修改的日期時(shí)間涩僻。

Expires: 實(shí)體數(shù)據(jù)試下的日期時(shí)間。

Allow: 所請(qǐng)求資源允許的請(qǐng)求方法。

ETag: 資源的特定版本的標(biāo)識(shí)符逆日∧涨恚可以讓緩存更高效，并節(jié)省帶寬屏富。

Cache-Control: 控制緩存機(jī)制的指令晴竞。

HTTP可緩存性包括:

public：HTTP請(qǐng)求返回時(shí)，經(jīng)過(guò)的代理服務(wù)器以及客戶(hù)端都可以對(duì)內(nèi)容進(jìn)行緩存狠半。

private：只有發(fā)起請(qǐng)求的瀏覽器可以進(jìn)行緩存

no-cache：本地和代理服務(wù)器可以緩存噩死，但是每次使用緩存時(shí)都要到服務(wù)器驗(yàn)證一下，服務(wù)器返回可以使用緩存才能生效神年。

max-age ：可以設(shè)置緩存的有效期

s-maxage：代理服務(wù)器的緩存有效期已维。同時(shí)設(shè)置max-age和s-maxage，客戶(hù)端會(huì)使用max-age已日，代理服務(wù)器會(huì)使用s-maxage

max-stale：發(fā)起端設(shè)置垛耳，指明請(qǐng)求可以使用過(guò)期的緩存。（瀏覽器用不到）

驗(yàn)證方面：

must-revalidate：如果緩存過(guò)期飘千，必須到服務(wù)器發(fā)送請(qǐng)求重新獲取數(shù)據(jù)

proxy-revalidate：緩存服務(wù)器的must-revalidate

Last-Modified：服務(wù)器返回Response的上次修改時(shí)間堂鲜，配合客戶(hù)端發(fā)送Request的If-Modified-Since使用

Etag：通過(guò)數(shù)據(jù)簽名標(biāo)記這個(gè)資源，下次請(qǐng)求時(shí)配合Requesst的If-Match/If-Non-Match的對(duì)比緩存中的Etag判斷是否使用緩存（數(shù)據(jù)簽名：資源對(duì)它的內(nèi)容會(huì)產(chǎn)生唯一的簽名护奈，如果內(nèi)容修改缔莲，簽名會(huì)進(jìn)行修改，例如對(duì)內(nèi)容hash計(jì)算）

no-store：本地和代理服務(wù)器都不能存儲(chǔ)緩存霉旗，每次都到原服務(wù)器拿數(shù)據(jù)痴奏。

no-transform：不允許改動(dòng)返回的內(nèi)容（比如壓縮、格式轉(zhuǎn)換）

以上是HTTP報(bào)文包含的主要結(jié)構(gòu)厌秒，當(dāng)請(qǐng)求報(bào)文到達(dá)服務(wù)器時(shí)读拆，服務(wù)器會(huì)對(duì)報(bào)文中的內(nèi)容解析出來(lái)，根據(jù)方法鸵闪、資源路徑檐晕、首部、和主體來(lái)處理請(qǐng)求岛马，然后通過(guò)對(duì)請(qǐng)求資源的訪問(wèn)結(jié)果棉姐，來(lái)構(gòu)建響應(yīng)屠列，回送給客戶(hù)端啦逆。

5.一次完整的HTTP請(qǐng)求過(guò)程

當(dāng)我們?cè)趙eb瀏覽器的地址欄中輸入： www.baidu.com，然后回車(chē)笛洛，到底發(fā)生了什么

　　1.對(duì)www.baidu.com這個(gè)網(wǎng)址進(jìn)行DNS域名解析夏志，得到對(duì)應(yīng)的IP地址

　　2.根據(jù)這個(gè)IP，找到對(duì)應(yīng)的服務(wù)器，發(fā)起TCP的三次握手

　　3.建立TCP連接后發(fā)起HTTP請(qǐng)求

　　4.服務(wù)器響應(yīng)HTTP請(qǐng)求沟蔑，瀏覽器得到html代碼

　　5.瀏覽器解析html代碼湿诊，并請(qǐng)求html代碼中的資源（如js、css圖片等）（先得到html代碼瘦材，才能去找這些資源）

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

域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請(qǐng)求 --> 服務(wù)器響應(yīng)http請(qǐng)求厅须，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請(qǐng)求html代碼中的資源（如js食棕、css朗和、圖片等） --> 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶(hù)

先弄懂下面5個(gè)基本知識(shí)點(diǎn)：

封裝報(bào)文是從上層到下層(應(yīng)用層 --> 傳輸層 --> 網(wǎng)絡(luò)層 – > 數(shù)據(jù)鏈路層 --> 物理層)，解封裝報(bào)文是從下層到上層簿晓。

實(shí)際例子：從PC1遠(yuǎn)程登錄服務(wù)器(Server)眶拉。

數(shù)據(jù)包傳輸?shù)倪^(guò)程中，源IP和目標(biāo)IP不會(huì)變，除非遇到NAT（SNAT或DNAT)，源MAC和目標(biāo)MAC遇到網(wǎng)關(guān)會(huì)變锦针。

二層內(nèi)通過(guò)MAC尋址子檀，三層通過(guò)IP尋址。

當(dāng)一個(gè)數(shù)據(jù)包的目的地址不是本機(jī)当纱，所以需要查詢(xún)路由表，當(dāng)查到路由表中的網(wǎng)關(guān)之后，需要獲取網(wǎng)關(guān)的MAC地址坞古，并將數(shù)據(jù)包的MAC地址修改成網(wǎng)關(guān)地址，然后發(fā)送到對(duì)應(yīng)的網(wǎng)卡劫樟。

協(xié)議數(shù)據(jù)單元在應(yīng)用層痪枫、表示層和會(huì)話層被稱(chēng)做數(shù)據(jù)(Data)，在傳輸層被稱(chēng)做分段(Segment)叠艳，在網(wǎng)絡(luò)層被稱(chēng)做包(Packet)奶陈，在數(shù)據(jù)鏈路層被稱(chēng)做幀(Frame)，在物理層被稱(chēng)做比特(Bit)附较。

PC1或者Server上保留的arp表是：arp和ip的映射關(guān)系吃粒。而二層交換機(jī)是arp和端口的映射關(guān)系，也就是這個(gè)arp 應(yīng)該由哪個(gè)端口轉(zhuǎn)發(fā)拒课。三層交換機(jī)可以保留arp和ip的映射關(guān)系徐勃。

　1.域名解析

　　a）首先會(huì)搜索瀏覽器自身的DNS緩存（緩存時(shí)間比較短，大概只有1分鐘早像，且只能容納1000條緩存）

　　b）如果瀏覽器自身的緩存里面沒(méi)有找到僻肖，那么瀏覽器會(huì)搜索系統(tǒng)自身的DNS緩存

　　c）如果還沒(méi)有找到，那么嘗試從 hosts文件里面去找

　　d）在前面三個(gè)過(guò)程都沒(méi)獲取到的情況下卢鹦，就遞歸地去域名服務(wù)器去查找臀脏，具體過(guò)程如下

?2.TCP連接（三次握手）

　　拿到域名對(duì)應(yīng)的IP地址之后，User-Agent（一般指瀏覽器）會(huì)以一個(gè)隨機(jī)端口（1024<端口<65535）向服務(wù)器的WEB程序（常用的有httpd，nginx）等的80端口揉稚。這個(gè)連接請(qǐng)求（原始的http請(qǐng)求經(jīng)過(guò)TCP/IP4層模型的層層封包）到達(dá)服務(wù)器端后（這中間有各種路由設(shè)備秒啦，局域網(wǎng)內(nèi)除外），進(jìn)入到網(wǎng)卡搀玖，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧（用于識(shí)別連接請(qǐng)求余境，解封包，一層一層的剝開(kāi)）灌诅，還有可能要經(jīng)過(guò)Netfilter防火墻（屬于內(nèi)核的模塊）的過(guò)濾葛超，最終達(dá)到WEB程序，最終建立了TCP/IP的連接

3.建立TCP連接之后延塑，發(fā)起HTTP請(qǐng)求

HTTP請(qǐng)求報(bào)文由三部分組成：請(qǐng)求行绣张，請(qǐng)求頭和請(qǐng)求正文

請(qǐng)求行：用于描述客戶(hù)端的請(qǐng)求方式，請(qǐng)求的資源名稱(chēng)以及使用的HTTP協(xié)議的版本號(hào)（例：GET/books/java.html HTTP/1.1）

請(qǐng)求頭：用于描述客戶(hù)端請(qǐng)求哪臺(tái)主機(jī)关带，以及客戶(hù)端的一些環(huán)境信息等

4.服務(wù)器端響應(yīng)http請(qǐng)求侥涵，瀏覽器得到html代碼

HTTP響應(yīng)也由三部分組成：狀態(tài)碼，響應(yīng)頭和實(shí)體內(nèi)容

狀態(tài)碼：狀態(tài)碼用于表示服務(wù)器對(duì)請(qǐng)求的處理結(jié)果

列舉幾種常見(jiàn)的：200（沒(méi)有問(wèn)題） 302（要你去找別人） 304（要你去拿緩存） 307（要你去拿緩存） 403（有這個(gè)資源宋雏，但是沒(méi)有訪問(wèn)權(quán)限） 404（服務(wù)器沒(méi)有這個(gè)資源） 500（服務(wù)器這邊有問(wèn)題

5.瀏覽器解析html代碼芜飘，并請(qǐng)求html代碼中的資源

瀏覽器拿到html文件后，就開(kāi)始解析其中的html代碼磨总，遇到j(luò)s/css/image等靜態(tài)資源時(shí)嗦明，就向服務(wù)器端去請(qǐng)求下載（會(huì)使用多線程下載，每個(gè)瀏覽器的線程數(shù)不一樣）蚪燕，這是時(shí)候就用上 keep-alive特性了娶牌，建立一次HTTP連接，可以請(qǐng)求多個(gè)資源馆纳，下載資源的順序就是按照代碼里面的順序诗良，但是由于每個(gè)資源大小不一樣，而瀏覽器又是多線程請(qǐng)求請(qǐng)求資源鲁驶，所以這里顯示的順序并不一定是代碼里面的順序鉴裹。

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

最后，瀏覽器利用自己內(nèi)部的工作機(jī)制钥弯，把請(qǐng)求的靜態(tài)資源和html代碼進(jìn)行渲染径荔，渲染之后呈現(xiàn)給用戶(hù)

5.HTTP的長(zhǎng)連接與短連接

在HTTP/1.0中默認(rèn)使用短連接。也就是說(shuō)脆霎，客戶(hù)端和服務(wù)器每進(jìn)行一次HTTP操作总处，就建立一次連接，任務(wù)結(jié)束就中斷連接绪穆。當(dāng)客戶(hù)端瀏覽器訪問(wèn)的某個(gè)HTML或其他類(lèi)型的Web頁(yè)中包含有其他的Web資源（如JavaScript文件辨泳、圖像文件虱岂、CSS文件等）玖院，每遇到這樣一個(gè)Web資源菠红，瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。

而從HTTP/1.1起难菌，默認(rèn)使用長(zhǎng)連接试溯，用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議郊酒，會(huì)在響應(yīng)頭加入這行代碼：

Connection:keep-alive

長(zhǎng)連接短連接操作過(guò)程

短連接的操作步驟是：

建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接

長(zhǎng)連接的操作步驟是：

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

什么時(shí)候用長(zhǎng)連接遇绞，短連接？

長(zhǎng)連接多用于操作頻繁燎窘，點(diǎn)對(duì)點(diǎn)的通訊摹闽，而且連接數(shù)不能太多情況，褐健。每個(gè)TCP連接都需要三步握手付鹿，這需要時(shí)間，如果每個(gè)操作都是先連接蚜迅，再操作的話那么處理速度會(huì)降低很多舵匾，所以每個(gè)操作完后都不斷開(kāi)，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了谁不，不用建立TCP連接坐梯。例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接， 如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤刹帕，而且頻繁的socket 創(chuàng)建也是對(duì)資源的浪費(fèi)吵血。

而像WEB網(wǎng)站的http服務(wù)一般都用短鏈接，因?yàn)殚L(zhǎng)連接對(duì)于服務(wù)端來(lái)說(shuō)會(huì)耗費(fèi)一定的資源偷溺，而像WEB網(wǎng)站這么頻繁的成千上萬(wàn)甚至上億客戶(hù)端的連接用短連接會(huì)更省一些資源践瓷，如果用長(zhǎng)連接，而且同時(shí)有成千上萬(wàn)的用戶(hù)亡蓉，如果每個(gè)用戶(hù)都占用一個(gè)連接的話晕翠，那可想而知吧。所以并發(fā)量大砍濒，但每個(gè)用戶(hù)無(wú)需頻繁操作情況下需用短連好樊卓。

由上可以看出，長(zhǎng)連接可以省去較多的TCP建立和關(guān)閉的操作碌尔，減少浪費(fèi)，節(jié)約時(shí)間唾戚。對(duì)于頻繁請(qǐng)求資源的客戶(hù)來(lái)說(shuō)叹坦，較適用長(zhǎng)連接募书。不過(guò)這里存在一個(gè)問(wèn)題莹捡，存活功能的探測(cè)周期太長(zhǎng)齿椅，還有就是它只是探測(cè)TCP連接的存活媒咳，屬于比較斯文的做法，遇到惡意的連接時(shí)妙同，保活功能就不夠使了芒涡。在長(zhǎng)連接的應(yīng)用場(chǎng)景下费尽，client端一般不會(huì)主動(dòng)關(guān)閉它們之間的連接，Client與server之間的連接如果一直不關(guān)閉的話柏卤，會(huì)存在一個(gè)問(wèn)題勾笆，隨著客戶(hù)端連接越來(lái)越多钝侠，server早晚有扛不住的時(shí)候里初，這時(shí)候server端需要采取一些策略双妨，如關(guān)閉一些長(zhǎng)時(shí)間沒(méi)有讀寫(xiě)事件發(fā)生的連接，這樣可 以避免一些惡意連接導(dǎo)致server端服務(wù)受損；如果條件再允許就可以以客戶(hù)端機(jī)器為顆粒度兜挨，限制每個(gè)客戶(hù)端的最大長(zhǎng)連接數(shù)，這樣可以完全避免某個(gè)蛋疼的客戶(hù)端連累后端服務(wù)噪舀。

短連接對(duì)于服務(wù)器來(lái)說(shuō)管理較為簡(jiǎn)單，存在的連接都是有用的連接，不需要額外的控制手段比驻。但如果客戶(hù)請(qǐng)求頻繁狈茉，將在TCP的建立和關(guān)閉操作上浪費(fèi)時(shí)間和帶寬。

6. HTTP1,HTTP2,HTTP3區(qū)別

HTTP/1.x 有連接無(wú)法復(fù)用、隊(duì)頭阻塞实昨、協(xié)議開(kāi)銷(xiāo)大和安全因素等多個(gè)缺陷

HTTP/1.0 傳輸數(shù)據(jù)時(shí)，每次都需要重新建立連接志电，增加延遲。

HTTP/1.1 雖然加入 keep-alive 可以復(fù)用一部分連接，但域名分片等情況下仍然需要建立多個(gè) connection蚀乔，耗費(fèi)資源，給服務(wù)器帶來(lái)性能壓力。

HTTP/2 通過(guò)多路復(fù)用氯哮、二進(jìn)制流姆打、Header 壓縮等等技術(shù)，極大地提高了性能，但是還是存在著問(wèn)題的

同個(gè)域名只需要占用一個(gè) TCP 連接垒玲，使用一個(gè)連接并行發(fā)送多個(gè)請(qǐng)求和響應(yīng),消除了因多個(gè) TCP 連接而帶來(lái)的延時(shí)和內(nèi)存消耗氮惯。并行交錯(cuò)地發(fā)送多個(gè)請(qǐng)求帘不，請(qǐng)求之間互不影響。并行交錯(cuò)地發(fā)送多個(gè)響應(yīng)，響應(yīng)之間互不干擾。

在 HTTP/2 中娘扩，每個(gè)請(qǐng)求都可以帶一個(gè) 31bit 的優(yōu)先值，0 表示最高優(yōu)先級(jí)， 數(shù)值越大優(yōu)先級(jí)越低牺陶。有了這個(gè)優(yōu)先值减俏，客戶(hù)端和服務(wù)器就可以在處理不同的流時(shí)采取不同的策略怕篷，以最優(yōu)的方式發(fā)送流梳猪、消息和幀。

在 HTTP/2 中引入了多路復(fù)用的技術(shù)匿沛。多路復(fù)用很好的解決了瀏覽器限制同一個(gè)域名下的請(qǐng)求數(shù)量的問(wèn)題者娱，同時(shí)也接更容易實(shí)現(xiàn)全速傳輸推姻，畢竟新開(kāi)一個(gè) TCP 連接都需要慢慢提升傳輸速度。

QUIC 基于 UDP 實(shí)現(xiàn)校翔，是 HTTP/3 中的底層支撐協(xié)議，該協(xié)議基于 UDP饲嗽，又取了 TCP 中的精華，實(shí)現(xiàn)了即快又可靠的協(xié)議

HTTP1.1 的缺陷

高延遲 — 隊(duì)頭阻塞(Head-Of-Line Blocking),無(wú)狀態(tài)特性 — 阻礙交互, 明文傳輸 — 不安全性, 不支持服務(wù)端推送

HTTP2

新增特性：

二進(jìn)制分幀 - HTTP2 性能增強(qiáng)的核心,? 多路復(fù)用 - 解決串行的文件傳輸和連接數(shù)過(guò)多

二進(jìn)制分幀

首先，HTTP2 沒(méi)有改變 HTTP1 的語(yǔ)義，只是在應(yīng)用層使用二進(jìn)制分幀方式傳輸沉馆。因此接癌，也引入了新的通信單位：幀、消息、流有咨。

分幀有什么好處似忧？服務(wù)器單位時(shí)間接收到的請(qǐng)求數(shù)變多淳衙，可以提高并發(fā)數(shù)肠牲。最重要的是梢睛，為多路復(fù)用提供了底層支持竖独。

多路復(fù)用

一個(gè)域名對(duì)應(yīng)一個(gè)連接，一個(gè)流代表了一個(gè)完整的請(qǐng)求-響應(yīng)過(guò)程。幀是最小的數(shù)據(jù)單位，每個(gè)幀會(huì)標(biāo)識(shí)出該幀屬于哪個(gè)流锉走，流也就是多個(gè)幀組成的數(shù)據(jù)流休偶。多路復(fù)用词顾，就是在一個(gè) TCP 連接中可以存在多個(gè)流。

二進(jìn)制分幀

首先垮媒，HTTP2 沒(méi)有改變 HTTP1 的語(yǔ)義，只是在應(yīng)用層使用二進(jìn)制分幀方式傳輸秕豫。因此侮穿，也引入了新的通信單位：幀回铛、消息袭祟、流。分幀有什么好處紊婉？服務(wù)器單位時(shí)間接收到的請(qǐng)求數(shù)變多何缓，可以提高并發(fā)數(shù)剩盒。最重要的是纪挎，為多路復(fù)用提供了底層支持。

多路復(fù)用

一個(gè)域名對(duì)應(yīng)一個(gè)連接，一個(gè)流代表了一個(gè)完整的請(qǐng)求-響應(yīng)過(guò)程。幀是最小的數(shù)據(jù)單位膜蠢，每個(gè)幀會(huì)標(biāo)識(shí)出該幀屬于哪個(gè)流贮勃，流也就是多個(gè)幀組成的數(shù)據(jù)流。多路復(fù)用，就是在一個(gè) TCP 連接中可以存在多個(gè)流。

QUIC

簡(jiǎn)介

Google

在推 SPDY 的時(shí)候就已經(jīng)意識(shí)到了這些問(wèn)題句喷，于是就另起爐灶搞了一個(gè)基于 UDP 協(xié)議的 QUIC 協(xié)議镣典。而這個(gè)就是 HTTP3。它真正“完美”地解決了“隊(duì)頭阻塞”問(wèn)題唾琼。

主要特點(diǎn)

改進(jìn)的擁塞控制兄春、可靠傳輸

快速握手

集成了 TLS 1.3 加密

多路復(fù)用

連接遷移

7.常見(jiàn)HTTP代碼

2XX

200 OK?(RFC7231)

201 Created?(RFC7231)

請(qǐng)求成功锡溯，正在創(chuàng)建一個(gè)或更多新資源赶舆。Location?標(biāo)頭中應(yīng)存在新資源的位置哑姚，或由請(qǐng)求的 URI 提供舌厨。通常志鹃，有效負(fù)載將描述并引用新生成資源的鏈接。

205 Reset Content?(RFC7231)

源站服務(wù)器建議客戶(hù)端將視圖重置為請(qǐng)求之前的原始狀態(tài)纤垂。通常用于表單或其他輸入提交夕晓。在請(qǐng)求中發(fā)送了有效負(fù)載宛乃，源站服務(wù)器成功進(jìn)行了操作，現(xiàn)在通知瀏覽器允許進(jìn)行其他提交蒸辆。

206 Partial Content (RFC 7233)

請(qǐng)求的部分資源已成功征炼，并位于有效負(fù)載中。請(qǐng)求必須已通過(guò)以下方式之一注明了范圍：

單個(gè)部分請(qǐng)求帶有 HTTP 標(biāo)頭躬贡，包括 Content Range 后跟大小谆奥。（如果響應(yīng)標(biāo)頭中存在，則必須與有效負(fù)載中的八位字節(jié)完全相等）例如拂玻，Content Range:?bytes 21010-47021/47022

HTTP 標(biāo)頭中有多個(gè)與?Content-Type: multipart/byteranges?相關(guān)的塊酸些，包括為各個(gè)部分分別列出 Content-Range 字段，但不在響應(yīng)?HTTP 標(biāo)頭中檐蚜。也需要?RFC 7233 第 4.1 節(jié)中規(guī)定的分界線魄懂。例如

206 通常用于處理需要分割的較大文件的客戶(hù)端，或者具有多個(gè)同步流以改進(jìn)延遲的已中斷下載闯第。

301 Moved Permanently?(RFC7231)

所請(qǐng)求資源的永久 URL 重定向市栗。目標(biāo)資源已被分配了新的永久 URI，日后引用該資源時(shí)都應(yīng)使用所含的某一個(gè) URI

3咳短、301重定向與302重定向的區(qū)別

302重定向是暫時(shí)的重定向填帽，搜索引擎會(huì)抓取新的內(nèi)容而保留舊的網(wǎng)址。因?yàn)榉?wù)器返回302代碼咙好，搜索引擎認(rèn)為新的網(wǎng)址只是暫時(shí)的篡腌。

301重定向是永久的重定向，搜索引擎在抓取新內(nèi)容的同時(shí)也將舊的網(wǎng)址替換為重定向之后的網(wǎng)址勾效。

從網(wǎng)址A 做一個(gè)302 重定向到網(wǎng)址B 時(shí)嘹悼，主機(jī)服務(wù)器的隱含意思是網(wǎng)址A 隨時(shí)有可能改主意，重新顯示本身的內(nèi)容或轉(zhuǎn)向其他的地方层宫。大部分的搜索引擎在大部分情況下绘迁，當(dāng)收到302 重定向時(shí)，一般只要去抓取目標(biāo)網(wǎng)址就可以了卒密，也就是說(shuō)網(wǎng)址B。如果搜索引擎在遇到302 轉(zhuǎn)向時(shí)棠赛，百分之百的都抓取目標(biāo)網(wǎng)址B 的話哮奇，就不用擔(dān)心網(wǎng)址URL 劫持了膛腐。問(wèn)題就在于，有的時(shí)候搜索引擎鼎俘，尤其是Google哲身，并不能總是抓取目標(biāo)網(wǎng)址

304 Not Modified ?(RFC 7232)

提醒客戶(hù)端，請(qǐng)求的資源在緩存中可用并且有效贸伐。源站服務(wù)器未曾修改請(qǐng)求所查詢(xún)的資源勘天。客戶(hù)端可以接收指定資源的有效負(fù)載捉邢，無(wú)需再次連接源站服務(wù)器脯丝，因此它將重定向請(qǐng)求以使用存儲(chǔ)的資源。?[RFC7234] 第 4.3.4 節(jié)中定義了有關(guān)可接收 304 響應(yīng)的緩存的要求伏伐。

在這一響應(yīng)前宠进，客戶(hù)端發(fā)送了有條件?GET?或?HEAD?請(qǐng)求，以指定當(dāng)前已存儲(chǔ)了什么資源藐翎。服務(wù)器向客戶(hù)端發(fā)出“OK”信號(hào)材蹬，以將此資源用作最新的版本，從而減少客戶(hù)端和服務(wù)器之間的數(shù)據(jù)傳輸量吝镣。

4xx 客戶(hù)端錯(cuò)誤

400 Bad Request ?(RFC7231)

服務(wù)器無(wú)法處理請(qǐng)求堤器，由于某些內(nèi)容被認(rèn)為是客戶(hù)端錯(cuò)誤（例如，語(yǔ)法錯(cuò)誤末贾、無(wú)效的請(qǐng)求消息框架或異常的請(qǐng)求路徑）

403 Forbidden?(RFC7231)

出現(xiàn)此錯(cuò)誤的主要原因是：

1.您設(shè)置的權(quán)限配置闸溃，或者您設(shè)置的 .htaccess 文件中配置的規(guī)則

2.Mod_security 規(guī)則。

3.IP 拒絕訪問(wèn)限制

404 Not Found?(RFC7231)

源站服務(wù)器無(wú)法或不愿找到所請(qǐng)求的資源未舟。這通常意味著主機(jī)服務(wù)器無(wú)法找到資源圈暗。?要發(fā)送此問(wèn)題的永久錯(cuò)誤消息，應(yīng)使用 410 錯(cuò)誤代碼裕膀。

413 Payload Too Large ?(RFC7231)

服務(wù)器拒絕處理請(qǐng)求员串，因?yàn)閺目蛻?hù)端發(fā)送的負(fù)載大于服務(wù)器希望接受的有效負(fù)載。服務(wù)器可選擇關(guān)閉連接昼扛。

429 Too Many Requests (RFC6585)

客戶(hù)端在根據(jù)服務(wù)器指定的時(shí)間內(nèi)發(fā)送了太多請(qǐng)求寸齐。429通常會(huì)在觸發(fā)“Rate Limiting (速率限制)”時(shí)產(chǎn)生。服務(wù)器可以作出響應(yīng)并提供信息抄谐，使請(qǐng)求者在特定時(shí)間段之后重試渺鹦。

499 Client Close Request

Nginx 特定響應(yīng)代碼，表明當(dāng)服務(wù)器仍在處理請(qǐng)求時(shí)蛹含，客戶(hù)端主動(dòng)關(guān)閉連接毅厚，使服務(wù)器無(wú)法返回狀態(tài)代碼。

Error 500: internal server error

500 錯(cuò)誤通常表示您的源站 Web 服務(wù)器存在問(wèn)題浦箱。?Error establishing database?connection?是源站 Web 服務(wù)器生成的常見(jiàn) HTTP 500 錯(cuò)誤消息吸耿。?聯(lián)系您的主機(jī)提供商來(lái)解決祠锣。

Error 502 bad gateway 或 Error 504 gateway timeout

聯(lián)系您的主機(jī)提供商，在您的源站 Web 服務(wù)器上排查這些常見(jiàn)的原因：

確保在請(qǐng)求生成 生成 502 或 504 錯(cuò)誤的訪問(wèn)者 URL 中的主機(jī)名和域名時(shí)咽安，源站服務(wù)器能夠響應(yīng)請(qǐng)求伴网。

調(diào)查服務(wù)器過(guò)載、崩潰或網(wǎng)絡(luò)故障妆棒。

識(shí)別發(fā)生超時(shí)或被阻止的應(yīng)用程序或服務(wù)澡腾。

請(qǐng)檢查它們是否似乎正在使用基于DNS的負(fù)載均衡器（例如，他們擁有AWS ELB的CNAME） 記錄）糕珊。 您還可以詢(xún)問(wèn)客戶(hù)在Web服務(wù)器前是否還有其他基礎(chǔ)架構(gòu)动分。 沿原始路徑的任何支持HTTP的軟件都可以返回502，因此有必要檢查每個(gè)日志放接。

Error 520: web server returns an unknown error

當(dāng)源站服務(wù)器向返回空白刺啦、未知或意外響應(yīng)時(shí)，會(huì)發(fā)生 520 錯(cuò)誤

源站 Web 服務(wù)器應(yīng)用程序崩潰

您的源站上未列入白名單纠脾。

源站 Web 服務(wù)器 TCP 空閑超時(shí)短于 300 秒

標(biāo)頭超過(guò) 8 KB（通常因?yàn)?Cookie 數(shù)量過(guò)多）

源站 Web 服務(wù)器的空響應(yīng)中缺少 HTTP 狀態(tài)代碼或響應(yīng)正文

缺少響應(yīng)標(biāo)頭或源站 Web 服務(wù)器未返回正確的 HTTP 錯(cuò)誤響應(yīng)

520 錯(cuò)誤普遍發(fā)生于造成源站 Web 服務(wù)器崩潰的 PHP 應(yīng)用程序玛瘸。

標(biāo)準(zhǔn)回答：

Web服務(wù)器或網(wǎng)絡(luò)設(shè)備（防火墻，負(fù)載平衡器）在建立TCP連接后將其重置苟蹈。 有時(shí)糊渊，當(dāng)Web服務(wù)器崩潰時(shí)，它將重置連接慧脱。 檢查您的Web服務(wù)器訪問(wèn)/錯(cuò)誤日志渺绒，以了解發(fā)生錯(cuò)誤的時(shí)間范圍，并查找任何錯(cuò)誤消息菱鸥。

您的Web服務(wù)器返回的無(wú)效響應(yīng)超出了我們的限制宗兼。 如果您的Web服務(wù)器返回太多/太大的標(biāo)頭，通常會(huì)發(fā)生這種情況氮采。 例如殷绍，這通常是由返回過(guò)多cookie的失控腳本引起的。 Code Igniter PHP框架也與此有關(guān)鹊漠。

Error 503: service temporarily unavailable

HTTP 錯(cuò)誤 503 在源站 Web 服務(wù)器過(guò)載時(shí)發(fā)生主到。可能的原因有兩種躯概，可通過(guò)錯(cuò)誤消息來(lái)辨別

解決方案：聯(lián)系您的主機(jī)提供商登钥，以核實(shí)是否針對(duì)您的源站 Web 服務(wù)器的請(qǐng)求實(shí)施了速率限制。

503 Service Unavailable消息娶靡，表示您需要聯(lián)系托管服務(wù)提供商以尋求幫助或查看本地錯(cuò)誤日志牧牢。 上游503可以指示資源耗盡或失敗的進(jìn)程，并且應(yīng)從服務(wù)器或應(yīng)用程序日志中清除確切原因。

Error 521: web server is down

源站 Web 服務(wù)器拒絕來(lái)連接時(shí)结执，會(huì)發(fā)生 521 錯(cuò)誤度陆。源站上的安全解決方案可能阻止了來(lái)自某些 IP地址的合法連接。

521 錯(cuò)誤的兩個(gè)最常見(jiàn)原因：

源站 Web 服務(wù)器應(yīng)用程序離線献幔，CDN 請(qǐng)求被阻止

Error 522: connection timed out

聯(lián)系源站 Web 服務(wù)器時(shí)超時(shí)會(huì)發(fā)生 522 錯(cuò)誤。有兩種不同的錯(cuò)誤導(dǎo)致 HTTP 錯(cuò)誤 522趾诗，具體取決于CDN和源站 Web 服務(wù)器之間發(fā)生超時(shí)的時(shí)間：

在連接建立之前蜡感，源站 Web 服務(wù)器未在CDN發(fā)送 SYN 后 15 秒內(nèi)將 SYN + ACK 返回給 Cloudflare。

在連接建立之后恃泪，源站 Web 服務(wù)器未在 90 秒內(nèi)確認(rèn)（ACK） 的資源請(qǐng)求郑兴。

聯(lián)系您的主機(jī)提供商，從源站 Web 服務(wù)器上排查下列常見(jiàn)原因：

（最常見(jiàn)）.htaccess贝乎、iptables 或防火墻中阻止了 對(duì)CDN或?qū)ζ湓O(shè)置了速率限制情连。確認(rèn)您的主機(jī)提供商已將CDN的IP Range地址列入白名單。

源站 Web 服務(wù)器過(guò)載或離線览效，因而丟棄了傳入的請(qǐng)求却舀。

源站 Web 服務(wù)器上禁用了?Keepalives?功能。

從源站 Web 服務(wù)器到發(fā)生問(wèn)題前最常連接您的源站 Web 服務(wù)器的?的?MTR 或 traceroute?結(jié)果锤灿。在源站 Web 服務(wù)器日志記錄的 IP 中挽拔，找到一個(gè)可成功連接的 IP。

Error 523: origin is unreachable

當(dāng) 無(wú)法聯(lián)系您的源站 Web 服務(wù)器時(shí)但校，會(huì)發(fā)生 523 錯(cuò)誤螃诅。這通常在CDN和源站 Web 服務(wù)器之間的網(wǎng)絡(luò)設(shè)備沒(méi)有通向源站 IP 地址的路由時(shí)發(fā)生。

Error 524: a timeout occurred

524 錯(cuò)誤表明 成功連接了源服務(wù)器状囱，但源站 Web 服務(wù)器沒(méi)有在默認(rèn)的 100 秒連接超時(shí)結(jié)束前提供 HTTP 響應(yīng)术裸。

從您的源站 Web 服務(wù)器上排查下列常見(jiàn)原因：

源站 Web 服務(wù)器上長(zhǎng)時(shí)間運(yùn)行的進(jìn)程。發(fā)生過(guò)載的源站 Web 服務(wù)器亭枷。

源站 Web 服務(wù)器上記錄請(qǐng)求響應(yīng)時(shí)間有助于辨別資源速度緩慢的原因袭艺。聯(lián)系您的主機(jī)提供商或站點(diǎn)管理員，以協(xié)助調(diào)整日志格式奶栖，或者搜索適用于您的 Web 服務(wù)器品牌（如?Apache?或?Nginx）的日志文檔

當(dāng)我們能夠建立與您的原始Web服務(wù)器的TCP連接時(shí)匹表，就會(huì)發(fā)生[524錯(cuò)誤] 但您的網(wǎng)絡(luò)服務(wù)器在連接超時(shí)限制（大約100秒）之前沒(méi)有響應(yīng)。此錯(cuò)誤通常是由源服務(wù)器上的長(zhǎng)時(shí)間運(yùn)行過(guò)程引起的宣鄙，例如PHP應(yīng)用程序或數(shù)據(jù)庫(kù)查詢(xún)袍镀，Web服務(wù)器必須在響應(yīng)請(qǐng)求之前等待。

此錯(cuò)誤也可能是源服務(wù)器超載導(dǎo)致的-如果您看到此錯(cuò)誤冻晤，則最好檢查服務(wù)器的可用資源苇羡，包括CPU和RAM以及總流量水平。 如果您的服務(wù)器具有較高的CPU負(fù)載或內(nèi)存不足鼻弧，則可能表明資源有問(wèn)題设江。我繼續(xù)檢查了過(guò)去24小時(shí)的日志锦茁，發(fā)現(xiàn)在此期間沒(méi)有其他524錯(cuò)誤。

最有效方法是直接向其原始Web服務(wù)器使用以下cURL請(qǐng)求叉存，該請(qǐng)求計(jì)算TCP連接發(fā)生所需的時(shí)間以及從其Web服務(wù)器（TTFB）傳輸?shù)降谝粋€(gè)字節(jié)的時(shí)間码俩。

curl -sv -o /dev/null -w?"Connect: %{time_connect} \n TTFB: %{time_starttransfer} \n Total time: %{time_total} \n"?https://www.scott.cf/sleep.php --resolve www.scott.cf:443:[origin IP]

Error 525:SSL handshake failed

525 錯(cuò)誤通常由源站 Web 服務(wù)器中的配置問(wèn)題引起。滿(mǎn)足以下兩個(gè)條件時(shí)會(huì)發(fā)生 525 錯(cuò)誤：

1.原始Web服務(wù)器未安裝證書(shū)歼捏。

2.原始Web服務(wù)器未在端口443（或其他自定義安全端口）上偵聽(tīng)稿存。

3.原始Web服務(wù)器不支持SNI或配置不正確。

4.接受的密碼套件與原始服務(wù)器支持的密碼套件不匹配瞳秽。

方案1：原始Web服務(wù)器未安裝證書(shū)瓣履。

curl -s --resolve?hostname:443:serveripaddress https://example.com -vso?/dev/null?-k

openssl s_client -showcerts -connect serveripaddress:443 -servername?hostname<?/dev/null?| openssl x509 -noout -text

93/5000

方案2：原始Web服務(wù)器未在端口443（或其他自定義安全端口）上偵聽(tīng)。

nmap -p 443 ec2-52-72-30-86.compute-1.amazonaws.com

方案3：原始Web服務(wù)器不支持SNI或未正確配置SNI练俐。

wireshark

Error 526: invalid SSL certificate

請(qǐng)您服務(wù)器管理員或主機(jī)提供商核查源站 Web 服務(wù)器的 SSL 證書(shū)袖迎，并進(jìn)行以下驗(yàn)證：

證書(shū)沒(méi)有到期, 證書(shū)沒(méi)有撤銷(xiāo), 證書(shū)由證書(shū)頒發(fā)機(jī)構(gòu)簽名（而非自簽名）

所請(qǐng)求的域名和主機(jī)名列在證書(shū)的?Common Name?或?Subject Alternative Name?中

您的源站 Web 服務(wù)器接受通過(guò) SSL 端口 443 進(jìn)行連接

并訪問(wèn)?https://www.sslshopper.com/ssl-checker.html#hostname=www.example.com（將 www.example.com 替換為您的主機(jī)名和域名），以驗(yàn)源站 SSL 證書(shū)并無(wú)問(wèn)題：

檢查原始服務(wù)器上是否存在帶有有效主機(jī)名并由證書(shū)頒發(fā)機(jī)構(gòu)簽名的證書(shū)腺晾。

$ openssl s_client -connect $ORIGIN_IP:443 -servername $DOMAIN <?/dev/null?2>/dev/null?| openssl x509 -noout -text |grep?'DNS:\|Issuer:\|Subject:';

$?echo?| openssl s_client -servername $DOMAIN -connect $ORIGIN_SERVER_IP:443 2>/dev/null?| openssl x509 -noout -dates

8.curl是基于URL語(yǔ)法在命令行方式下工作的文件傳輸工具燕锥，它支持FTP，F(xiàn)TPS丘喻，HTTP脯宿，HTTPS，GOPHER泉粉，TELNET连霉，DICT，F(xiàn)ILE及LDAP等協(xié)議嗡靡。curl支持HTTPS認(rèn)證跺撼，并且支持HTTP的POST,PUT等方法，F(xiàn)TP上傳讨彼，kerberos認(rèn)證歉井，HTTP上傳，代理服務(wù)器哈误，cookies哩至，用戶(hù)名/密碼認(rèn)證，通過(guò)http代理服務(wù)器上傳文件到FTP服務(wù)器等等蜜自，功能十分強(qiáng)大菩貌。

這一系列標(biāo)志指定詳細(xì)的響應(yīng)，同時(shí)將頁(yè)面的輸出/正文轉(zhuǎn)儲(chǔ)到本地/ dev / null項(xiàng)重荠，該項(xiàng)立即丟棄該信息并且不保存箭阶。 這用于提供干凈的信息顯示，例如請(qǐng)求/響應(yīng)頭。 以下是這些選項(xiàng)的細(xì)分：

-s：靜默模式仇参。 刪除顯示進(jìn)度表或錯(cuò)誤消息嘹叫。

-v：?jiǎn)⒂迷敿?xì)輸出。

-o / dev / null：將輸出設(shè)置為文件诈乒。 在這種情況下罩扇，我們會(huì)將頁(yè)面正文發(fā)送到/ dev / null項(xiàng)目。

Debugging HTTP Errors

curl -svo /dev/null --header?"Host: example.com"?http://123.123.123.123/

上面的--header選項(xiàng)對(duì)于發(fā)送特定的請(qǐng)求標(biāo)頭非常有用抓谴，例如Host暮蹂，Set-Cookie甚至是在唯一的客戶(hù)應(yīng)用程序/平臺(tái)中使用的自定義標(biāo)頭。

在較新版本的curl還支持一個(gè)為例子顯示下：–resolve的選項(xiàng)癌压，可以直接用來(lái)指定對(duì)url的解析

curl -svo /dev/null --resolve example.com:80:123.123.123.123 http://example.com/

resolve選項(xiàng)為特定主機(jī)和端口設(shè)置自定義地址。 這提供了使用指定地址發(fā)送curl請(qǐng)求的功能荆陆，并防止使用其他通程步欤可以解析的地址（替代修改本地/ etc / hosts文件的命令行）。 該選項(xiàng)對(duì)于比較原始服務(wù)器與特定服務(wù)器之間的服務(wù)器響應(yīng)非常有用被啼。

這顯示了完成請(qǐng)求所花費(fèi)的總時(shí)間：

curl -svo /dev/null https://example.com/ -w "\nContent Type: %{content_type} \

\nHTTP Code: %{http_code} \

\nHTTP Connect:%{http_connect} \

\nNumber Connects: %{num_connects} \

\nNumber Redirects: %{num_redirects} \

\nRedirect URL: %{redirect_url} \

\nSize Download: %{size_download} \

\nSize Upload: %{size_upload} \

\nSSL Verify: %{ssl_verify_result} \

\nTime Handshake: %{time_appconnect} \

\nTime Connect: %{time_connect} \

\nName Lookup Time: %{time_namelookup} \

\nTime Pretransfer: %{time_pretransfer} \

\nTime Redirect: %{time_redirect} \

\nTime Start Transfer: %{time_starttransfer} \

\nTime Total: %{time_total} \

Debugging SSL/TLS

curl -svo /dev/null https://whiskytango.us/ 2>&1 | egrep -v "^{.*$|^}.*$|^\* http.*$"

字符串2>＆1 | egrep -v“ ^ {帜消。* $ | ^}。* $ | ^ \ * http浓体。* $”可用于清理和解析cURL輸出泡挺，以減少TLS握手/證書(shū)信息的干擾。

WebSocket的使用場(chǎng)景

社交聊天命浴、彈幕娄猫、多玩家游戲鸠儿、協(xié)同編輯幔睬、股票基金實(shí)時(shí)報(bào)價(jià)叠必、體育實(shí)況更新孩饼、視頻會(huì)議/聊天芹壕、基于位置的應(yīng)用啤它、在線教育载迄、智能家居等需要高實(shí)時(shí)的場(chǎng)景

WebSocket 的其他特點(diǎn)：

建立在 TCP 協(xié)議之上脑沿，服務(wù)器端的實(shí)現(xiàn)比較容易捉兴。

與 HTTP 協(xié)議有著良好的兼容性蝎困。默認(rèn)端口也是80和443，并且握手階段采用 HTTP 協(xié)議倍啥，因此握手時(shí)不容易屏蔽禾乘，能通過(guò)各種 HTTP 代理服務(wù)器。

數(shù)據(jù)格式比較輕量逗栽，性能開(kāi)銷(xiāo)小盖袭，通信高效。

可以發(fā)送文本，也可以發(fā)送二進(jìn)制數(shù)據(jù)鳄虱。

沒(méi)有同源限制弟塞，客戶(hù)端可以與任意服務(wù)器通信。

協(xié)議標(biāo)識(shí)符是ws（如果加密拙已，則為wss）决记，服務(wù)器網(wǎng)址就是 URL。

由輪詢(xún)到WebSocket

1 輪詢(xún)

客戶(hù)端和服務(wù)器之間會(huì)一直進(jìn)行連接倍踪，每隔一段時(shí)間就詢(xún)問(wèn)一次系宫。客戶(hù)端會(huì)輪詢(xún)建车，有沒(méi)有新消息扩借。這種方式連接數(shù)會(huì)很多，一個(gè)接受缤至，一個(gè)發(fā)送潮罪。而且每次發(fā)送請(qǐng)求都會(huì)有Http的Header，會(huì)很耗流量领斥，也會(huì)消耗CPU的利用率嫉到。

2 長(zhǎng)輪詢(xún)

長(zhǎng)輪詢(xún)是對(duì)輪詢(xún)的改進(jìn)版，客戶(hù)端發(fā)送HTTP給服務(wù)器之后月洛，有沒(méi)有新消息何恶，如果沒(méi)有新消息，就一直等待嚼黔。當(dāng)有新消息的時(shí)候细层，才會(huì)返回給客戶(hù)端。在某種程度上減小了網(wǎng)絡(luò)帶寬和CPU利用率等問(wèn)題隔崎。但是這種方式還是有一種弊端：例如假設(shè)服務(wù)器端的數(shù)據(jù)更新速度很快今艺，服務(wù)器在傳送一個(gè)數(shù)據(jù)包給客戶(hù)端后必須等待客戶(hù)端的下一個(gè)Get請(qǐng)求到來(lái)，才能傳遞第二個(gè)更新的數(shù)據(jù)包給客戶(hù)端爵卒，那么這樣的話虚缎，客戶(hù)端顯示實(shí)時(shí)數(shù)據(jù)最快的時(shí)間為2×RTT（往返時(shí)間），而且如果在網(wǎng)絡(luò)擁塞的情況下钓株，這個(gè)時(shí)間用戶(hù)是不能接受的实牡，比如在股市的的報(bào)價(jià)上。另外轴合，由于http數(shù)據(jù)包的頭部數(shù)據(jù)量往往很大（通常有400多個(gè)字節(jié)）创坞，但是真正被服務(wù)器需要的數(shù)據(jù)卻很少（有時(shí)只有10個(gè)字節(jié)左右），這樣的數(shù)據(jù)包在網(wǎng)絡(luò)上周期性的傳輸受葛，難免對(duì)網(wǎng)絡(luò)帶寬是一種浪費(fèi)题涨。

3? WebSocket

現(xiàn)在急需的需求是能支持客戶(hù)端和服務(wù)器端的雙向通信偎谁，而且協(xié)議的頭部又沒(méi)有HTTP的Header那么大，于是纲堵，Websocket就誕生了巡雨！流量消耗方面，相同的每秒客戶(hù)端輪詢(xún)的次數(shù)席函，當(dāng)次數(shù)高達(dá)數(shù)萬(wàn)每秒的高頻率次數(shù)的時(shí)候铐望，WebSocket消耗流量?jī)H為輪詢(xún)的幾百分之一

WebSocket協(xié)議原理

Websocket是應(yīng)用層第七層上的一個(gè)應(yīng)用層協(xié)議，它必須依賴(lài) HTTP 協(xié)議進(jìn)行一次握手 茂附，握手成功后正蛙，數(shù)據(jù)就直接從 TCP 通道傳輸，與 HTTP 無(wú)關(guān)了营曼。

Websocket的數(shù)據(jù)傳輸是frame形式傳輸?shù)钠寡椋热鐣?huì)將一條消息分為幾個(gè)frame，按照先后順序傳輸出去蒂阱。這樣做會(huì)有幾個(gè)好處：

1 大數(shù)據(jù)的傳輸可以分片傳輸徊件，不用考慮到數(shù)據(jù)大小導(dǎo)致的長(zhǎng)度標(biāo)志位不足夠的情況。

2 和http的chunk一樣蒜危，可以邊生成數(shù)據(jù)邊傳遞消息，即提高傳輸效率睹耐。

WebSocket和Socket的區(qū)別與聯(lián)系

首先辐赞，Socket 其實(shí)并不是一個(gè)協(xié)議。它工作在 OSI 模型會(huì)話層（第5層）硝训，是為了方便大家直接使用更底層協(xié)議（一般是 TCP 或 UDP ）而存在的一個(gè)抽象層响委。Socket是對(duì)TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議窖梁，而是一個(gè)調(diào)用接口(API)赘风。

Socket通常也稱(chēng)作”套接字”，用于描述IP地址和端口纵刘，是一個(gè)通信鏈的句柄邀窃。網(wǎng)絡(luò)上的兩個(gè)程序通過(guò)一個(gè)雙向的通訊連接實(shí)現(xiàn)數(shù)據(jù)的交換，這個(gè)雙向鏈路的一端稱(chēng)為一個(gè)Socket假哎，一個(gè)Socket由一個(gè)IP地址和一個(gè)端口號(hào)唯一確定瞬捕。應(yīng)用程序通常通過(guò)”套接字”向網(wǎng)絡(luò)發(fā)出請(qǐng)求或者應(yīng)答網(wǎng)絡(luò)請(qǐng)求。

Socket在通訊過(guò)程中舵抹，服務(wù)端監(jiān)聽(tīng)某個(gè)端口是否有連接請(qǐng)求肪虎，客戶(hù)端向服務(wù)端發(fā)送連接請(qǐng)求，服務(wù)端收到連接請(qǐng)求向客戶(hù)端發(fā)出接收消息惧蛹，這樣一個(gè)連接就建立起來(lái)了扇救⌒讨Γ客戶(hù)端和服務(wù)端也都可以相互發(fā)送消息與對(duì)方進(jìn)行通訊，直到雙方連接斷開(kāi)

forward 和 redirect 的區(qū)別迅腔？

Forward和Redirect代表了兩種請(qǐng)求轉(zhuǎn)發(fā)方式：直接轉(zhuǎn)發(fā)和間接轉(zhuǎn)發(fā)装畅。

直接轉(zhuǎn)發(fā)方式（Forward），客戶(hù)端和瀏覽器只發(fā)出一次請(qǐng)求钾挟，Servlet洁灵、HTML、JSP或其它信息資源掺出，由第二個(gè)信息資源響應(yīng)該請(qǐng)求徽千，在請(qǐng)求對(duì)象request中，保存的對(duì)象對(duì)于每個(gè)信息資源是共享的汤锨。

間接轉(zhuǎn)發(fā)方式（Redirect）實(shí)際是兩次HTTP請(qǐng)求双抽，服務(wù)器端在響應(yīng)第一次請(qǐng)求的時(shí)候，讓瀏覽器再向另外一個(gè)URL發(fā)出請(qǐng)求闲礼，從而達(dá)到轉(zhuǎn)發(fā)的目的牍汹。

密鑰套件

也稱(chēng)加密套件、密碼套件柬泽，是 SSL 中最核心的算法套件慎菲，稱(chēng)之為套件是因?yàn)槠渲邪嗣荑€交換算法、簽名算法锨并、加密算法和摘要算法露该，由兩個(gè)字節(jié)表示。以下是 TLS 密鑰套件的語(yǔ)法：

那服務(wù)端又是怎么選擇這個(gè)密鑰套件呢第煮？在 openssl 里面密鑰套件的選擇與幾個(gè)因素有關(guān)：

1.服務(wù)端配置的密鑰套件列表解幼。

2.客戶(hù)端支持的密鑰套件列表。

3.服務(wù)端密鑰套件列表優(yōu)先還是客戶(hù)端密鑰套件列表優(yōu)先包警。

4.已選擇的 SSL 協(xié)議版本撵摆。

5.證書(shū)所支持的算法。

Cipher Suite害晦，加密套件特铝，即密碼套件。是TLS/SSL網(wǎng)絡(luò)協(xié)議中的一個(gè)概念篱瞎。指在ssl通信中苟呐，服務(wù)器和客戶(hù)端所使用的加密算法的組合。

一個(gè)加密套件是一個(gè)四件套俐筋，包含四個(gè)功能：密鑰交換算法牵素、身份驗(yàn)證算法 、對(duì)稱(chēng)加密算法和信息摘要算法澄者。

密鑰交換算法

顧名思義笆呆，該算法用來(lái)交換秘鑰请琳。

SSL 通信過(guò)程（握手結(jié)束后）中，雙方使用的是對(duì)稱(chēng)加密的方式 赠幕。由于通信雙方以前并不知道彼此的存在俄精，它們也不可能預(yù)先存儲(chǔ)相同的加密秘鑰，那么應(yīng)當(dāng)怎么做呢榕堰？答案是在 SSL 通信的握手階段竖慧，使用秘鑰交換算法使雙方使用的秘鑰保持一致。

常用的密鑰交換算法有RSA逆屡、Diffie-Hellman密鑰交換圾旨、ECDH（Elliptic Curve Diffie-Hellman）、SRP（安全遠(yuǎn)程密碼）魏蔗、由TLS 1.2支持密鑰交換算法PSK（Pre Shared Key）砍的。

身份驗(yàn)證算法

身份驗(yàn)證又稱(chēng)“驗(yàn)證”、“鑒權(quán)”莺治，是指通過(guò)一定的手段廓鞠，完成對(duì)用戶(hù)身份的確認(rèn)。常用算法有 RSA谣旁、ECDSA床佳、DSS

對(duì)稱(chēng)加密算法

對(duì)稱(chēng)加密（也叫私鑰加密）指加密和解密使用相同密鑰的加密算法。常用算法有 AES榄审、DES夕土、3DES。

信息摘要算法

根據(jù)某種運(yùn)算規(guī)則對(duì)信息進(jìn)行提取某種形式的提取瘟判，提取出來(lái)的數(shù)據(jù)就是摘要。主要用于驗(yàn)證信息的完整性角溃。常用算法有 MD5拷获、SHA-1。

舉例說(shuō)明

比如加密套件為：TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA1

TLS：通信協(xié)議

ECDHE：秘鑰交換算法

ECDSA：身份驗(yàn)證算法

AES_128_CBC：通信時(shí)使用的對(duì)稱(chēng)加密算法

SHA1：信息摘要算法

網(wǎng)絡(luò)---關(guān)于HTTP 304狀態(tài)碼的理解

首先看一個(gè)關(guān)于304請(qǐng)求的響應(yīng)頭的信息减细，這里面有兩個(gè)比較重要的請(qǐng)求頭字段：If-Modified-Since?和?If-None-Match匆瓜，這兩個(gè)字段表示發(fā)送的是一個(gè)條件請(qǐng)求

當(dāng)客戶(hù)端緩存了目標(biāo)資源但不確定該緩存資源是否是最新版本的時(shí)候, 就會(huì)發(fā)送一個(gè)條件請(qǐng)求，這樣就可以辨別出一個(gè)請(qǐng)求是否是條件請(qǐng)求未蝌，在進(jìn)行條件請(qǐng)求時(shí),客戶(hù)端會(huì)提供給服務(wù)器一個(gè)If-Modified-Since請(qǐng)求頭,其值為服務(wù)器上次返回的Last-Modified響應(yīng)頭中的Date日期值,還會(huì)提供一個(gè)If-None-Match請(qǐng)求頭,值為服務(wù)器上次返回的ETag響應(yīng)頭的值驮吱。

服務(wù)器會(huì)讀取到這兩個(gè)請(qǐng)求頭中的值,判斷出客戶(hù)端緩存的資源是否是最新的,如果是的話,服務(wù)器就會(huì)返回HTTP/304 Not Modified響應(yīng)頭, 但沒(méi)有響應(yīng)體.客戶(hù)端收到304響應(yīng)后,就會(huì)從本地緩存中讀取對(duì)應(yīng)的資源.

所以：出現(xiàn)304訪問(wèn)的情況下其實(shí)就是先在本地緩存了訪問(wèn)的資源，然后請(qǐng)求的時(shí)候流量其實(shí)就是cdn返回的響應(yīng)頭的字節(jié)數(shù)的流量萧吠。

網(wǎng)站加載 Waiting (TTFB) 時(shí)間過(guò)長(zhǎng)的原因和解決辦法

TTFB 是 Time to First Byte 的縮寫(xiě)左冬，指的是瀏覽器開(kāi)始收到服務(wù)器響應(yīng)數(shù)據(jù)的時(shí)間（后臺(tái)處理時(shí)間+重定向時(shí)間），是反映服務(wù)端響應(yīng)速度的重要指標(biāo)纸型。就像你問(wèn)朋友了一個(gè)問(wèn)題拇砰，你的朋友思考了一會(huì)兒才給你答案梅忌，你朋友思考的時(shí)間就相當(dāng)于 TTFB。你朋友思考的時(shí)間越短除破，就說(shuō)明你朋友越聰明或者對(duì)你的問(wèn)題越熟悉牧氮。對(duì)服務(wù)器來(lái)說(shuō)，TTFB 時(shí)間越短瑰枫，就說(shuō)明服務(wù)器響應(yīng)越快踱葛。

大家可以上傳一些靜態(tài)的 HTML 頁(yè)面到服務(wù)器，然后打開(kāi)這些靜態(tài)頁(yè)面光坝，看一些這些頁(yè)面的 TTFB 時(shí)間尸诽，大多數(shù)服務(wù)器的 TTFB 時(shí)間都在 50 ms 以下，這個(gè)時(shí)間就是我們優(yōu)化時(shí)候可以追求的時(shí)間教馆。下面兩個(gè)圖中的 TTFB 時(shí)間分別是本站所在服務(wù)器的靜態(tài)和動(dòng)態(tài)網(wǎng)頁(yè) TTFB 等待時(shí)間逊谋。

靜態(tài)網(wǎng)頁(yè) Waiting （TTFB）時(shí)間

動(dòng)態(tài)網(wǎng)頁(yè) Waiting （TTFB）時(shí)間

根據(jù)我們的測(cè)試，TTFB 時(shí)間如果超過(guò)了 500 ms土铺，用戶(hù)在打開(kāi)網(wǎng)頁(yè)的時(shí)候就會(huì)感覺(jué)到明顯的等待胶滋。我么可以把 500 ms 以上認(rèn)為是?TTFB 時(shí)間過(guò)長(zhǎng)”螅可見(jiàn)究恤，WordPress 智庫(kù)的服務(wù)器還不算差。

TTFB 過(guò)長(zhǎng)的原因

我們知道后德，對(duì)于動(dòng)態(tài)網(wǎng)頁(yè)來(lái)說(shuō)部宿，服務(wù)器收到用戶(hù)打開(kāi)一個(gè)頁(yè)面的請(qǐng)求時(shí)，首先要從數(shù)據(jù)庫(kù)中讀取該頁(yè)面需要的數(shù)據(jù)瓢湃，然后把這些數(shù)據(jù)傳入到模版中理张，模版渲染后，再返回給用戶(hù)绵患。由于查詢(xún)數(shù)據(jù)和渲染模版需要需要一定的時(shí)間雾叭，在這個(gè)過(guò)程沒(méi)有完成之前，瀏覽器就一致處于等待接收服務(wù)器響應(yīng)的狀態(tài)落蝙。有些服務(wù)的性能比較低织狐，或者優(yōu)化沒(méi)做好，這個(gè)時(shí)間就會(huì)比較長(zhǎng)筏勒。

當(dāng)然移迫，如果服務(wù)器到用戶(hù)之間的網(wǎng)絡(luò)不好，（比如管行，服務(wù)器在歐洲厨埋，用戶(hù)在中國(guó)，用戶(hù)打開(kāi)網(wǎng)頁(yè)的時(shí)候捐顷，請(qǐng)求需要跨越千山萬(wàn)水才能達(dá)到服務(wù)器）揽咕，服務(wù)器接收到用戶(hù)請(qǐng)求的時(shí)間過(guò)長(zhǎng)悲酷，也是導(dǎo)致 TTFB 時(shí)間過(guò)長(zhǎng)的原因。

有時(shí)候亲善，頁(yè)面在用戶(hù)的瀏覽器中保存了過(guò)多的 Cookie设易，每次請(qǐng)求，這些 Cookie 都要發(fā)送到服務(wù)器蛹头，服務(wù)器都要處理這些 Cookie顿肺，這也是導(dǎo)致 TTFB 時(shí)間過(guò)長(zhǎng)的原因之一。

Waiting (TTFB) 時(shí)間過(guò)長(zhǎng)的解決辦法

知道了原因渣蜗，解決辦法就顯而易見(jiàn)了屠尊，那就是縮短服務(wù)器響應(yīng)時(shí)間，最簡(jiǎn)單直接并且有效的辦法就是使用緩存耕拷，把 PHP 和 MySQL 的執(zhí)行時(shí)間最小化讼昆，一些緩存插件可以把 SQL 查詢(xún)結(jié)果緩存起來(lái)，把幾十次查詢(xún)結(jié)果轉(zhuǎn)換為幾次骚烧；一些緩存插件可以直接把用戶(hù)所請(qǐng)求的頁(yè)面靜態(tài)化浸赫，用戶(hù)打開(kāi)網(wǎng)頁(yè)時(shí)，相當(dāng)于直接從服務(wù)器上下載了靜態(tài)頁(yè)面赃绊。

如果是網(wǎng)絡(luò)原因既峡，換一個(gè)服務(wù)器是比較直接的解決辦法。如果因?yàn)橐恍┰虿荒軗Q服務(wù)器碧查，可以使用一個(gè)?CDN运敢，把頁(yè)面同步到離用戶(hù)比較近的 CDN 節(jié)點(diǎn)上，也是一個(gè)不錯(cuò)的解決辦法忠售。

如果是 Cookie 的原因传惠，可以通過(guò)修改應(yīng)用程序稻扬，刪除一些不必要的 Cookie困后，或者精簡(jiǎn) Cookie 內(nèi)容汽绢，縮短 Cookie 的有效期等，都是解決辦法。

影響 TTFB 的主要因素有三個(gè)：

CDN

一般網(wǎng)站會(huì)將靜態(tài)內(nèi)容分發(fā)到 CDN哎迄，CDN 的內(nèi)容又會(huì)復(fù)制到其他地理位置的服務(wù)器渺氧，以便更接近用戶(hù)，從而減少 TTFB 的時(shí)間衬鱼。當(dāng)然動(dòng)態(tài)內(nèi)容也可以放到 CDN 上消别，只要及時(shí)清除 cache 就行。

后端服務(wù)器的性能，后端服務(wù)器軟件的和系統(tǒng)的設(shè)計(jì)

其實(shí) TTFB 作為一個(gè)單一指數(shù)很難去衡量一個(gè)網(wǎng)站的真實(shí)速度和用戶(hù)體驗(yàn)。主要就是講在某些情況下，雖然 TTFB 很快赴叹，但是因?yàn)閿?shù)據(jù)沒(méi)有壓縮姚炕，其實(shí)后面數(shù)據(jù)的傳輸反而慢些椒，用戶(hù)看到整個(gè)頁(yè)面需要等待更久忧侧。

但是作為被動(dòng)方，也就是用戶(hù)，不能控制 server肚逸，研究這個(gè)也還是有價(jià)值的主之。比如需要實(shí)時(shí)獲取一些數(shù)據(jù)的時(shí)候朱巨，如果要更快洪唐，你的服務(wù)器地址就有講究了，這個(gè) TTFB 指標(biāo)就有用。

一般來(lái)講度硝，CDN 不會(huì)影響 TTFB，因?yàn)槎际窍燃虞d html捌治，再是靜態(tài)文件森枪，例如圖片和 css式散、js 文件等。但是大的 CDN 服務(wù)提供商，例如 Cloudflare 這樣的琳骡，會(huì)從 DNS 層就開(kāi)始控制竖席，所以 DNS 和服務(wù)器的 會(huì)影響到 TTFB员寇。