前言本書(shū)從眾多技術(shù)專家日積月累的典型問(wèn)題中，經(jīng)過(guò)層層篩選，為大家提供了35個(gè)經(jīng)典問(wèn)題答疑實(shí)錄，內(nèi)容頗具深度，具有深厚的技術(shù)底蘊(yùn)，是理論和實(shí)踐的完美結(jié)合。通篇從“問(wèn)題描述”到“排查思路&過(guò)程”，再到“問(wèn)題原因”、“解決方案”、“適用產(chǎn)品”，層層探討和剖析，相信每個(gè)經(jīng)典問(wèn)題都能讓同學(xué)們從中挖掘到自己真正的信息需求，整合應(yīng)用并輸出，為后續(xù)處理類似疑難工單提升運(yùn)維效率，降低工單處理時(shí)長(zhǎng)。無(wú)論你是哪個(gè)年齡段、身處哪個(gè)職位，希望本書(shū)能夠讓所有對(duì)“對(duì)象存儲(chǔ)&視頻云”感興趣的朋友有所獲有所得，對(duì)大家的日常生活和工作需求都能有所幫助。書(shū)中難免有筆誤、差錯(cuò)或遺漏等問(wèn)題，希望大家一起溝通交流個(gè)人見(jiàn)解，共同進(jìn)步。CDN更改源站后生效慢CDN更改源站后生效慢作者：胡夫CDN更改源站后生效慢，還是存在回源老的源站的情況。概率性數(shù)據(jù)同步慢導(dǎo)致，一般是因?yàn)橛蛎脑L問(wèn)量級(jí)比較小有關(guān)，如果訪問(wèn)量大那么刷新速度會(huì)比較快。這種情況可以考慮增加一個(gè)回原頭強(qiáng)制更新dns。在CDN控制臺(tái)添加添加"自定義回源請(qǐng)求頭"，增加如下配置：Ali-Tproxy-Dns-Update:sync全站加速WebSocket偶發(fā)訪問(wèn)失敗-劫持行為作者：胡夫客戶使用DCDN的WebSocket業(yè)務(wù)，偶發(fā)出現(xiàn)無(wú)法訪問(wèn)的情況，線上有1%左右的失敗率。根據(jù)客戶溝通，該問(wèn)題并不是必現(xiàn)的，目前是其中一位同事家里的wifi網(wǎng)絡(luò)下能復(fù)現(xiàn)問(wèn)題，而且重啟家里的光貓以后能正常，但一段時(shí)間以后又會(huì)出現(xiàn)問(wèn)題。嘗試讓客戶復(fù)現(xiàn)問(wèn)題，提供客戶端的Netwrok信息和客戶端抓包信息。從抓包信息看，是源站響應(yīng)了500。進(jìn)一步跟客戶確認(rèn)源站邏輯，根據(jù)客戶的反饋是源站會(huì)先校驗(yàn)Upgrade:websocket這個(gè)請(qǐng)求頭，如果沒(méi)有這個(gè)請(qǐng)求頭就會(huì)返回500。但是奇怪的是，根據(jù)抓包文件看，客戶端明明是帶了Upgrade:websocket請(qǐng)求頭的，因此懷疑是DCDN節(jié)點(diǎn)轉(zhuǎn)發(fā)的問(wèn)題。根據(jù)WebSocket的RFC協(xié)議文檔可以知道：1.Websocket請(qǐng)求必須包含一個(gè)Upgradeheader字段，它的值必須包含"websocket"。2.WebSocket請(qǐng)求必須包含一個(gè)Connectionheader字段，它的值必須包含"Upgrade"。根據(jù)抓包信息，使用curl指定到對(duì)應(yīng)的DCDN請(qǐng)求模擬發(fā)WebSocket請(qǐng)求測(cè)試，發(fā)現(xiàn)在客戶側(cè)能穩(wěn)定復(fù)現(xiàn)的情況下，我們curl測(cè)試并不能復(fù)現(xiàn)，排查來(lái)看又跟節(jié)點(diǎn)沒(méi)有關(guān)系。嘗試讓客戶在源站側(cè)加一下打印，將收到的請(qǐng)求頭打印出來(lái)，從源站的打印來(lái)看，出問(wèn)題的時(shí)候的確是沒(méi)有收到Upgrade:websocket頭。而如果是正常的請(qǐng)求，源站是能打印出Upgrade:websocket頭的。如果嘗試在源站側(cè)去掉這個(gè)Upgrade的校驗(yàn)，雖然可以請(qǐng)求成功，但是無(wú)法進(jìn)行WebSocket通信，因?yàn)檎麠l鏈路并不是走的WebSocket。排查后臺(tái)CDN的日志，發(fā)現(xiàn)正常請(qǐng)求的hit_info字段顯示的是WS，也就是走的WebSocket請(qǐng)求。而異常請(qǐng)求的hit_info字段是dynamic，也就是走的動(dòng)態(tài)加速，并不是WebSocket。從現(xiàn)象分析來(lái)看，懷疑是L1收到的請(qǐng)求里就沒(méi)有Upgrade:websocket相關(guān)的頭，所以L1認(rèn)為這不是WebSocket請(qǐng)求，走的是普通的動(dòng)態(tài)加速，轉(zhuǎn)發(fā)回源站也不會(huì)帶Upgrade頭。由于日志里并沒(méi)有記錄收到的客戶端Upgrade字段，因此需要后臺(tái)加一下debug日志，打印下該字段。重新讓客戶復(fù)現(xiàn)了一次問(wèn)題，并提供客戶端抓包數(shù)據(jù)。從抓包數(shù)據(jù)看，客戶端請(qǐng)求確實(shí)帶了Upgrade頭，而從DCDN的日志來(lái)看，確實(shí)是沒(méi)有收到Upgrade頭的，因此走的也是普通動(dòng)態(tài)加速請(qǐng)求。同時(shí)從客戶端收到的來(lái)自DCDN的報(bào)文看，這個(gè)TTL是64，這明顯是不正常的。正常情況由于DCDN節(jié)點(diǎn)發(fā)出的報(bào)文TTL原始值是64，中間每經(jīng)過(guò)一個(gè)網(wǎng)絡(luò)路由節(jié)點(diǎn)，TTL減1，客戶端收到的報(bào)文TTL不應(yīng)該是64。因此判斷是客戶端存在劫持行為，走了代理，應(yīng)該是客戶端發(fā)出請(qǐng)求以后客戶端層面做了異常轉(zhuǎn)發(fā)，按照普通的HTTP請(qǐng)求轉(zhuǎn)發(fā)，沒(méi)有轉(zhuǎn)WebSocket相關(guān)頭導(dǎo)致的。配置HTTPS證書(shū)，客戶端走wss請(qǐng)求以后，客戶側(cè)能復(fù)現(xiàn)問(wèn)題的現(xiàn)場(chǎng)就正常了，無(wú)法再?gòu)?fù)現(xiàn)問(wèn)題，而且線上錯(cuò)誤率明顯改善。CDN頁(yè)面優(yōu)化不生效排查遇到的坑作者：胡夫阿里云CDN提供了頁(yè)面優(yōu)化功能，當(dāng)開(kāi)啟頁(yè)面優(yōu)化功能時(shí)，CDN可以自動(dòng)清除HTML頁(yè)面冗余的注釋和重復(fù)的空白符，縮小文件體積，提升頁(yè)面可閱讀性。本案例遇到的一個(gè)問(wèn)題是，按照文檔開(kāi)啟了CDN的頁(yè)面優(yōu)化功能，但是訪問(wèn)HTML頁(yè)面實(shí)際并沒(méi)有優(yōu)化效果。在排查測(cè)試的過(guò)程中，發(fā)現(xiàn)直接用curlURL的方式查看響應(yīng)結(jié)果，是已經(jīng)被頁(yè)面優(yōu)化了，但是直接在瀏覽器上訪問(wèn)HTML卻沒(méi)有被優(yōu)化。進(jìn)一步對(duì)比curl請(qǐng)求以及瀏覽器Network下的RequestHeader以及ResponseHeader，發(fā)現(xiàn)瀏覽器的RequestHeader帶了Accept-Encoding:gzip,deflate，ResponseHeader返回了Content-Encoding:gzip，如下圖所示：我們知道HTTP協(xié)議上的GZIP編碼是一種用來(lái)改進(jìn)WEB應(yīng)用程序性能的技術(shù)，大流量的WEB站點(diǎn)常常使用GZIP壓縮技術(shù)來(lái)讓用戶感受更快的速度。從測(cè)試來(lái)看，瀏覽器請(qǐng)求頭帶了Accept-Encoding:gzip表示瀏覽器支持解碼gzip壓縮后的文件，如果服務(wù)器支持gzip壓縮，那么在收到這個(gè)請(qǐng)求頭以后，就會(huì)返回gzip壓縮以后的文件，在ResponseHeader里以Content-Encoding:gzip的形式體現(xiàn)。直接用如下curl命令帶Accept-Encoding請(qǐng)求頭測(cè)試，發(fā)現(xiàn)返回結(jié)果也是帶了gzip的，且頁(yè)面也是沒(méi)有優(yōu)化的。綜上可以暫時(shí)得出結(jié)論，返回結(jié)果帶了Accept-Encoding:gzip以后，CDN的頁(yè)面壓縮不生效，返回結(jié)果不帶Accept-Encoding:gzip，CDN的頁(yè)面壓縮生效。由于請(qǐng)求的鏈路是：客戶端Client-->CDN-->源站這個(gè)Gzip壓縮，可能是CDN產(chǎn)生的，也可能是源站產(chǎn)生的。這個(gè)比較容易驗(yàn)證，直接用curl命令綁定到源站IP去測(cè)試即可得出結(jié)論:測(cè)試來(lái)看，返回結(jié)果果然帶了Accept-Encoding:gzip，說(shuō)明是源站gzip壓縮導(dǎo)致的。產(chǎn)生這個(gè)現(xiàn)象的原因逐漸浮出水面，整個(gè)過(guò)程如下：當(dāng)用戶在瀏覽器發(fā)起請(qǐng)求時(shí)，瀏覽器默認(rèn)帶了Accept-Encoding:gzip這個(gè)請(qǐng)求頭，CDN作為一個(gè)代理服務(wù)器，在回源請(qǐng)求源服務(wù)器的時(shí)候轉(zhuǎn)發(fā)了這個(gè)來(lái)自真實(shí)客戶端（瀏覽器）的請(qǐng)求頭，源服務(wù)器由于開(kāi)了Gzip壓縮，因此在收到這個(gè)請(qǐng)求頭以后返回了Gzip壓縮以后的內(nèi)容給CDN，由于CDN不具備Gunzip功能，因此無(wú)法對(duì)Gzip壓縮以后的內(nèi)容去做頁(yè)面優(yōu)化，因此導(dǎo)致了頁(yè)面優(yōu)化功能不生效。以上基本定位問(wèn)題，但是為了更明確，我搭建了一個(gè)基于Nginx的Web服務(wù)器用做CDN的源站，并在Nginx的配置文件nginx.conf里開(kāi)啟了Gzip壓縮，配置如下圖：但是測(cè)試發(fā)現(xiàn)，通過(guò)CDN訪問(wèn)，并且發(fā)了Accept-Encoding:gzip請(qǐng)求頭以后，CDN依然可以完成頁(yè)面壓縮，這就比較奇怪。為了定位問(wèn)題，直接在Web服務(wù)器上抓了包，看一下CDN和Web服務(wù)器的交互請(qǐng)求，發(fā)現(xiàn)一個(gè)很奇怪的現(xiàn)象：CDN請(qǐng)求Web服務(wù)器的時(shí)候轉(zhuǎn)發(fā)了Accept-Encoding:gzip，但是Web服務(wù)器并沒(méi)有響應(yīng)Content-Encoding:gzip，報(bào)文如下圖：根據(jù)這個(gè)現(xiàn)象，去查了一下Nginx官網(wǎng)對(duì)于ngx_http_gzip_module模塊的配置說(shuō)明，可以看到該模塊有如下配置參數(shù)：其中有一個(gè)gzip_proxied參數(shù)引起了注意。這個(gè)參數(shù)的含義，可以解釋如下：語(yǔ)法：gzip_proxied[off|expired|no-cache|no-store|private|no_last_modified|no_etag|auth|any]…默認(rèn)值：gzip_proxiedoff作用域：http,server,locationNginx作為反向代理的時(shí)候啟用，開(kāi)啟或者關(guān)閉后端服務(wù)器返回的結(jié)果，匹配的前提是后端服務(wù)器必須要返回包含”Via”的header頭。off–對(duì)于所有來(lái)自代理服務(wù)器的請(qǐng)求，都關(guān)閉壓縮expired–如果響應(yīng)header頭中包含“Expires”頭信息則啟用壓縮no-cache–如果響應(yīng)header頭中包含“Cache-Control:no-cache”頭信息則啟用壓縮no-store–如果響應(yīng)header頭中包含“Cache-Control:no-store”頭信息則啟用壓縮private–如果響應(yīng)header頭中包含“Cache-Control:private”頭信息則啟用壓縮no_last_modified–如果響應(yīng)header頭中不包含“Last-Modified”頭信息則啟用壓縮no_etag–如果響應(yīng)header頭中不包含“ETag”頭信息則啟用壓縮auth–如果響應(yīng)header頭中包含“Authorization”頭信息則啟用壓縮any–無(wú)條件啟用壓縮，也就是對(duì)任何來(lái)自代理服務(wù)器的請(qǐng)求，都返回壓縮的內(nèi)容由于Nginx配置里配置了gzip_proxiedexpiredno-cacheno-storeprivateauth因此相當(dāng)于啟用了gzip_proxied參數(shù)，當(dāng)Web服務(wù)器發(fā)現(xiàn)來(lái)自代理服務(wù)器的請(qǐng)求時(shí)（在這里就是來(lái)自CDN的請(qǐng)求），Web服務(wù)器會(huì)去校驗(yàn)gzip_proxied參數(shù)，當(dāng)發(fā)現(xiàn)服務(wù)器的ResponseHeader里沒(méi)有返回Expires、"Cache-Control:no-cache"等類似響應(yīng)頭時(shí)，服務(wù)器就返回了不帶Gzip壓縮的數(shù)據(jù)。如果Gzip配置模塊是按照如下配置的話，那么任何來(lái)自代理服務(wù)器的請(qǐng)求，服務(wù)器都會(huì)返回Gzip壓縮的內(nèi)容。那么問(wèn)題來(lái)了，服務(wù)器是如何判斷這個(gè)請(qǐng)求是來(lái)自代理服務(wù)器的，而不是真實(shí)客戶端呢。這里就涉及到Via這個(gè)HTTPHeader了。關(guān)于Via的介紹，可以參考HTTP協(xié)議關(guān)于Via的文檔。Via是一個(gè)通用首部，是由代理服務(wù)器添加的，適用于正向和反向代理，在請(qǐng)求和響應(yīng)首部中均可出現(xiàn)。這個(gè)消息首部可以用來(lái)追蹤消息轉(zhuǎn)發(fā)情況，防止循環(huán)請(qǐng)求，以及識(shí)別在請(qǐng)求或響應(yīng)傳遞鏈中消息發(fā)送者對(duì)于協(xié)議的支持能力。在這里，CDN作為代理服務(wù)器，去請(qǐng)求源服務(wù)器的時(shí)候，請(qǐng)求頭里會(huì)帶上Via頭（這點(diǎn)在上面的抓包截圖里也可以看到而服務(wù)器就是根據(jù)請(qǐng)求頭里的Via得知該請(qǐng)求是來(lái)自上游代理服務(wù)器的。HTTP服務(wù)器的問(wèn)題是知道代理本身是否能夠處理壓縮響應(yīng)。傳入請(qǐng)求中的接受編碼頭(也就是Accept-Encoding:gzip)很可能是由原始客戶機(jī)請(qǐng)求提供的，但這并不能表明它所經(jīng)過(guò)的代理或網(wǎng)關(guān)的能力，也就是說(shuō)，服務(wù)器并不知道上游代理服務(wù)器能否處理Gzip壓縮以后的內(nèi)容。因此，在此場(chǎng)景中，服務(wù)器采用最安全的選項(xiàng)，并選擇不壓縮它發(fā)回的響應(yīng)，這也是合理的。關(guān)于Via這個(gè)Header對(duì)于Gzip壓縮的影響，可以參考這篇Akamai的文章，有詳細(xì)的介紹。既然源站響應(yīng)了gzip內(nèi)容會(huì)導(dǎo)致CDN的頁(yè)面優(yōu)化不生效，那只能源站響應(yīng)未壓縮過(guò)的內(nèi)容，但是這樣的話，最終對(duì)于客戶端來(lái)說(shuō)，請(qǐng)求到的文件沒(méi)有經(jīng)過(guò)有效壓縮，還是會(huì)消耗客戶端帶寬，從而影響Web頁(yè)面的訪問(wèn)性能。而CDN除了提供頁(yè)面優(yōu)化的功能外，還提供了Gzip的功能，那能不能在CDN層面去做頁(yè)面優(yōu)化和Gzip壓縮呢？通過(guò)測(cè)試發(fā)現(xiàn)，在CDN開(kāi)啟頁(yè)面優(yōu)化的同時(shí)，無(wú)論是開(kāi)啟Gzip壓縮還是Br壓縮，只要請(qǐng)求頭帶了accept-encoding:gzip,deflate,br頭，則頁(yè)面優(yōu)化不生效。由此可見(jiàn)，在CDN層面，智能壓縮的優(yōu)先級(jí)比較高，壓縮以后的內(nèi)容無(wú)法頁(yè)面優(yōu)化，看來(lái)這個(gè)方案暫時(shí)也不可行。當(dāng)然，這部分的策略有待產(chǎn)品層面去改良。綜上，該問(wèn)題可以總結(jié)如下：（1）如果源站響應(yīng)了Gzip壓縮的內(nèi)容，CDN會(huì)因?yàn)闊o(wú)法Gunzip導(dǎo)致頁(yè)面優(yōu)化功能不生效（2）如果希望與CDN去智能壓縮和頁(yè)面優(yōu)化，因此CDN層面智能壓縮的優(yōu)先級(jí)比頁(yè)面優(yōu)化的優(yōu)先級(jí)高，也會(huì)導(dǎo)致頁(yè)面優(yōu)化不生效（3）如果期望使用CDN的頁(yè)面優(yōu)化，那么需要確保源站服務(wù)器關(guān)閉Gzip壓縮。如果源站服務(wù)器是Nginx，通過(guò)修改Nginx配置文件里ngx_http_gzip_module模塊的gzip_proxied參數(shù)，設(shè)定來(lái)自代理服務(wù)器的請(qǐng)求，不返回Gzip壓縮的內(nèi)容來(lái)實(shí)現(xiàn)。（4）另外還有一種比較實(shí)現(xiàn)方案，是可以在CDN層面配置刪除Accept-Encoding這個(gè)回源HTTP請(qǐng)求頭。證書(shū)鏈不完整導(dǎo)致SSL握手失敗作者：胡夫使用OSS的NodeJSSDK，開(kāi)啟CNAME的情況下，HTTPS請(qǐng)求自定義域名，報(bào)錯(cuò)SSL握手失敗。從報(bào)錯(cuò)信息來(lái)看，ssl3__read_bytes:sslv3alerthandshakefailure，基本上是可以判斷SSL握手失敗了。但是通過(guò)瀏覽器訪問(wèn)卻可以正常訪問(wèn)，查看證書(shū)狀態(tài)正常。抓包來(lái)看確實(shí)是在SSL握手的時(shí)候，客戶端發(fā)完ClientHello，服務(wù)端直接發(fā)了FIN包?；?和2的初步判斷，有可能會(huì)誤以為是SDK的問(wèn)題從而誤導(dǎo)排查，其實(shí)遇到這種情況很有可能就是證書(shū)鏈不完整導(dǎo)致的?？梢韵扔胦penssl工具檢查下證書(shū)或者用相關(guān)證書(shū)檢測(cè)平臺(tái)檢測(cè)下證書(shū)鏈，比如/或者/ssl_check/以下三個(gè)截圖是本案例中分別用上面這兩個(gè)網(wǎng)站以及用openssl檢查的結(jié)果，可以看到確實(shí)是證書(shū)鏈不完整導(dǎo)致的。補(bǔ)全證書(shū)鏈，可以參考這個(gè)文檔里介紹的補(bǔ)全證書(shū)鏈的方案。存儲(chǔ)OSS一次HTTPS訪問(wèn)慢的案例分析<.22.一次HTTPS訪問(wèn)慢的案例分析作者：胡夫用戶反饋一個(gè)通過(guò)CDN加速的CSS資源，訪問(wèn)速度很慢，測(cè)試在PC上訪問(wèn)超過(guò)了3秒。Chrome復(fù)現(xiàn)了一下問(wèn)題，通過(guò)Network下的Timing信息分析這一次慢請(qǐng)求主要耗時(shí)在哪個(gè)時(shí)間點(diǎn)。通過(guò)以下圖可以明顯看到，這一次請(qǐng)求總耗時(shí)3.05s，但是有3.02s是耗時(shí)在了SSL握手上。我們知道HTTPS請(qǐng)求，在完成TCP三次握手以后，需要通過(guò)TLS協(xié)議來(lái)完成SSL握手，那么這次SSL握手的時(shí)間為什么耗時(shí)這么久呢？于是抓了一個(gè)異常包，根據(jù)CDN節(jié)點(diǎn)IP過(guò)濾了一下交互報(bào)文，具體如下圖。通過(guò)這個(gè)報(bào)文可以看到#944號(hào)報(bào)文Server端響應(yīng)了ServerHelloDone，返回了證書(shū)信息給客戶端，客戶端響應(yīng)ACK以后在#947號(hào)報(bào)文更新TCPWindow滑動(dòng)窗口，然后在#1291報(bào)文才繼續(xù)發(fā)ClientKeyExchange給Server端。從#947號(hào)包到#1291包，時(shí)間也從20:02:39到了20:02:42，耗時(shí)了3秒左右。從現(xiàn)象來(lái)看，這個(gè)耗時(shí)主要是"卡"在客戶端這了，那么客戶端這個(gè)時(shí)間到底干啥去了呢？要解釋上面問(wèn)題，還需要知道證書(shū)校驗(yàn)的機(jī)制。對(duì)于一個(gè)可信任的CA機(jī)構(gòu)頒發(fā)的有效證書(shū)，在證書(shū)到期之前，只要CA沒(méi)有把其吊銷，那么這個(gè)證書(shū)就是有效可信任的。有時(shí)，由于某些特殊原因（比如私鑰泄漏，證書(shū)信息有誤，CA有漏洞被黑客利用，頒發(fā)了其他域名的證書(shū)等等需要吊銷某些證書(shū)。那瀏覽器或者客戶端如何知道當(dāng)前使用的證書(shū)已經(jīng)被吊銷了呢，通常有兩種方式：CRL（CertificateRevocationList，證書(shū)吊銷列表）和OCSP（OnlineCertificateStatusProtocol，在線證書(shū)狀態(tài)協(xié)議）。一次HTTPS訪問(wèn)慢的案例分析<24（1）CRL：CRL是由CA機(jī)構(gòu)維護(hù)的一個(gè)列表，列表中包含已經(jīng)被吊銷的證書(shū)序列號(hào)和吊銷時(shí)間。瀏覽器可以定期去下載這個(gè)列表用于校驗(yàn)證書(shū)是否已被吊銷。可以看出，CRL只會(huì)越來(lái)越大，而且當(dāng)一個(gè)證書(shū)剛被吊銷后，瀏覽器在更新CRL之前還是會(huì)信任這個(gè)證書(shū)的，實(shí)時(shí)性較差。在每個(gè)證書(shū)的詳細(xì)信息中，都可以找到對(duì)應(yīng)頒發(fā)機(jī)構(gòu)的CRL地址。（2）OCSP：OCSP是一個(gè)在線證書(shū)查詢接口，它建立一個(gè)可實(shí)時(shí)響應(yīng)的機(jī)制，讓瀏覽器可以實(shí)時(shí)查詢每一張證書(shū)的有效性，解決了CRL的實(shí)時(shí)性問(wèn)題，但是OCSP也引入了一個(gè)性能問(wèn)題，某些客戶端會(huì)在SSL握手時(shí)去實(shí)時(shí)查詢OCSP接口，并在得到結(jié)果前會(huì)阻塞后續(xù)流程，這對(duì)性能影響很大，嚴(yán)重影響用戶體驗(yàn)。（OCSP地址也在證書(shū)的詳細(xì)信息中）通過(guò)瀏覽器上點(diǎn)擊安全鎖的小圖標(biāo)，可以看到證書(shū)的詳細(xì)信息，如下圖，我們可以看到幾個(gè)關(guān)鍵信息。證書(shū)簽發(fā)者：Let'sEncryptAuthorityX3OCSP_ServerURL：通過(guò)了解證書(shū)校驗(yàn)機(jī)制以后可以得知，這個(gè)問(wèn)題有可能是慢在證書(shū)校驗(yàn)這一塊。過(guò)濾了一下DNS報(bào)文，可以看到客戶端確實(shí)有OCSPServer域名的DNS查詢請(qǐng)求，該域名CNAME解析到了，最終解析到的IP是過(guò)濾了客戶端跟OCSPServer端的交互包，發(fā)現(xiàn)客戶端發(fā)起TCP三次握手，發(fā)送SYN包以后Server端未響應(yīng)，客戶端超時(shí)1秒以后繼續(xù)發(fā)送SYN包，發(fā)送了三次均無(wú)響應(yīng)，客戶端證書(shū)校驗(yàn)失敗，這個(gè)3秒剛好跟目前的耗時(shí)情況吻合。一次HTTPS訪問(wèn)慢的案例分析<26通過(guò)一些探測(cè)網(wǎng)站，在國(guó)內(nèi)探測(cè)了一下這個(gè)OCSPServer的地址確實(shí)表現(xiàn)也不是很好，大部分地區(qū)均無(wú)法訪問(wèn)，看來(lái)這個(gè)問(wèn)題收到運(yùn)營(yíng)商鏈路問(wèn)題的影響。通過(guò)以上排查分析，總結(jié)一下這個(gè)問(wèn)題發(fā)生的完整過(guò)程：客戶端發(fā)起一次HTTPS請(qǐng)求，在SSL握手的過(guò)程中，CDN服務(wù)端將證書(shū)信息發(fā)給了客戶端，客戶端根據(jù)證書(shū)信息，發(fā)起在線證書(shū)查詢來(lái)校驗(yàn)證書(shū)合法性，但是由于證書(shū)校驗(yàn)服務(wù)地址不可達(dá)導(dǎo)致證書(shū)校驗(yàn)失敗，客戶端間隔一秒繼續(xù)重試2次均失敗，耗時(shí)3秒以后客戶端停止校驗(yàn)，繼續(xù)完成后續(xù)的SSL握手，造成最終訪問(wèn)慢的現(xiàn)象。OCSP的原理決定了其存在隱私和性能問(wèn)題：（1）瀏覽器直接去請(qǐng)求第三方CA(CertificateAuthority,數(shù)字證書(shū)認(rèn)證機(jī)構(gòu))，會(huì)暴露網(wǎng)站的訪客(CA機(jī)構(gòu)會(huì)知道哪些用戶在訪問(wèn)我們的網(wǎng)站)；（2）瀏覽器進(jìn)行OCSP查詢會(huì)降低HTTPS性能(訪問(wèn)網(wǎng)站會(huì)變慢)OCSP實(shí)時(shí)查詢會(huì)增加客戶端的性能開(kāi)銷,本案例就是這種情況。針對(duì)這種情況，OCSPStapling出現(xiàn)了。OCSPStapling可以將原本需要客戶端實(shí)時(shí)發(fā)起的OCSP請(qǐng)求轉(zhuǎn)嫁給服務(wù)端，Web端將主動(dòng)獲取OCSP查詢結(jié)果，并隨證書(shū)一起發(fā)送給客戶端，以此讓客戶端跳過(guò)自己去尋求驗(yàn)證的過(guò)程，提高TLS握手效率，從而提高HTTPS性能。阿里云CDN也支持OCSPStapling功能，可以由CDN服務(wù)器查詢OCSP信息，從而降低客戶端驗(yàn)證請(qǐng)求延遲，減少等待查詢結(jié)果的響應(yīng)時(shí)間。具體配置方法和原理介紹可以參考設(shè)置OCSPStapling。不過(guò)本案例中，驗(yàn)證過(guò)開(kāi)啟CDN的OCSPStapling功能也無(wú)法解決，主要的問(wèn)題是OCSPServer端在國(guó)內(nèi)訪問(wèn)整體質(zhì)量均不佳，主要是由于跨境鏈路和運(yùn)營(yíng)商的問(wèn)題造成的，因此導(dǎo)致CDN去請(qǐng)求OCSP一樣質(zhì)量不佳。對(duì)于這種情況，如果是直接訪問(wèn)的Nginx，可以通過(guò)一些方式生成OCSPStapling文件部署到Nginx中（這里不展開(kāi)介紹）。如果是通過(guò)CDN等代理服務(wù)器方式，由于不能單獨(dú)配置OCSPStapling文件，最好的方式還是更換證書(shū)來(lái)解決。使用阿里云CDN的情況下，可以直接使用阿里云CDN的免費(fèi)證書(shū)，或者到阿里云SSL證書(shū)服務(wù)里去申請(qǐng)免費(fèi)證書(shū)or購(gòu)買付費(fèi)證書(shū)，詳細(xì)請(qǐng)戳這里。.作者：胡夫用戶使用阿里云CDN加速服務(wù)以后出現(xiàn)508錯(cuò)誤。我們先來(lái)看一下，Http_code508的定義：也就是說(shuō)，服務(wù)器在處理請(qǐng)求時(shí)陷入死循環(huán)，此狀態(tài)表示整個(gè)操作失敗。從上面的CDN的508錯(cuò)誤里，可以看到CDN返回的ResponseHeaders里，x-alicdn-da-ups-status響應(yīng)了508，eagleid響應(yīng)了兩個(gè)值。通常情況下，一次通過(guò)CDN加速的請(qǐng)求，eagleid只會(huì)記錄一個(gè)值，用于唯一標(biāo)識(shí)這次請(qǐng)求，像這種情況，eagleid記錄了多個(gè)值，說(shuō)明這個(gè)請(qǐng)求在CDN里循環(huán)了。造成這個(gè)現(xiàn)象的可能原因一般有如下兩種情況：lCDN的源站也是在阿里CDN上加速的，比如CDN的源站域名也是用了一個(gè)阿里CDN域名。lCDN的源站有一些代理的邏輯，會(huì)將CDN加速域名的請(qǐng)求代理到另外一個(gè)走阿里CDN加速的域名上。這里請(qǐng)注意，因?yàn)閿?shù)據(jù)的走向是：客戶端-->CDN-->源站。如果源站也是走了CDN的話，就會(huì)變成:客戶端-->CDN-->源站-->CDN-->源站...以此循環(huán)，這種情況就可能導(dǎo)致回環(huán)的情況，出現(xiàn)508。CDN產(chǎn)品本身有限制，要求CDN的源站不能是走阿里CDN加速，這是一種非標(biāo)準(zhǔn)化的操作。另外還有一種定位方法，可以直接綁定Host到源站去測(cè)試，也就是不通過(guò)CDN訪問(wèn)，然后看返回的Responseheaders響應(yīng)頭，是否帶有CDN的特殊header頭，一般就是看Via頭就可以了（阿里云CDN返回的header里會(huì)帶有Via頭可以參考下圖。如果直接訪問(wèn)源站的時(shí)候，源站返回的header頭卻有CDN特有的header頭，那就說(shuō)明源站有請(qǐng)求CDN的邏輯。如果去查對(duì)應(yīng)508的sunwell日志，在xff字段里可以看到有多個(gè)cdn的ip，也可以說(shuō)明該請(qǐng)求在CDN系統(tǒng)里回環(huán)了。CDN添加域名的時(shí)候，CDN控制臺(tái)會(huì)做判斷，如果用戶填寫(xiě)的源站域名是阿里CDN加速域名的話，會(huì)直接報(bào)錯(cuò)。但是有兩種情況目前CDN層面還無(wú)法避免，需要用戶側(cè)去修改：l用戶配置加速域名A的源站域名是域名B，此時(shí)域名B未走CDN加速，因此域名A的源站可以配置成功。但是配置成功以后，用戶將域名B添加到CDN上做加速。l用戶配置的源站不走CDN，但是源站會(huì)做一些代理，例如方向代理，把CDN加速域名的請(qǐng)求代理到另外一個(gè)CDN加速域名，這種情況CDN也是無(wú)法提前監(jiān)測(cè)到的。CDN加速OSS后未響應(yīng)Content-MD5作者：胡夫使用CDN加速OSS以后發(fā)現(xiàn)返回的響應(yīng)頭里沒(méi)有帶Content-MD5頭了，而直接通過(guò)OSS域名訪問(wèn)是會(huì)返回Content-MD5頭的。刷新CDN緩存以后部分節(jié)點(diǎn)會(huì)返回Content-MD5，但是還是會(huì)有部分節(jié)點(diǎn)不返回Content-MD5。<雖然X-Cache是MISS，沒(méi)有命中緩存回源的，但是通過(guò)以下的Via信息可以看到是命中L2的緩存了，L2節(jié)點(diǎn)是l2cn3037。通過(guò)Ali-Swift-Global-Savetime:1623065639可以知道該文件緩存到CDN節(jié)點(diǎn)的時(shí)間，unix時(shí)間戳1623065639轉(zhuǎn)換成北京時(shí)間是2021-06-0719:33:59。于是查對(duì)應(yīng)時(shí)間段l2cn3037這個(gè)節(jié)點(diǎn)的日志信息，發(fā)現(xiàn)該L2上記錄的狀態(tài)碼都是206，同時(shí)帶了http_range字段，說(shuō)明L2是Range回源OSS的，因此OSS響應(yīng)了206。查對(duì)應(yīng)時(shí)間段OSS的實(shí)時(shí)日志，發(fā)現(xiàn)OSS日志字段記錄的content__md5為"-"，說(shuō)明OSS確實(shí)沒(méi)有響應(yīng)content_md5字段。測(cè)試發(fā)現(xiàn)直接range請(qǐng)求OSS，OSS也是不會(huì)響應(yīng)Content-MD5的，經(jīng)確認(rèn)OSS的策略的確如此。確認(rèn)CDN的range回源配置，發(fā)現(xiàn)配置的是on，也就是開(kāi)啟了range回源。整個(gè)過(guò)程是19:33:59有一個(gè)客戶端發(fā)起了range請(qǐng)求，由于CDN域名配置了range回源，因此CDN會(huì)按照512KB的大小range回源OSS，OSS接到range請(qǐng)求以后響應(yīng)狀態(tài)碼206并且不響應(yīng)Content-MD5，這份響應(yīng)被CDN緩存下來(lái)。后續(xù)客戶端請(qǐng)求到對(duì)應(yīng)的CDN節(jié)點(diǎn)，不管是否是range請(qǐng)求，由于CDN已經(jīng)有緩存，就會(huì)直接返回之前緩存的不帶Content-MD5的Response信息。PS：為什么當(dāng)時(shí)刷新緩存以后通過(guò)CDN去訪問(wèn)可以看到有Content-MD5？答：因?yàn)楫?dāng)時(shí)刷新緩存以后，重新去訪問(wèn)的時(shí)候，客戶端發(fā)起的不是range請(qǐng)求，而是普通的請(qǐng)求；與此同時(shí)，由于CDN上配置的range回源是"on",并不是"force"，也就是不是強(qiáng)制range回源，因此CDN這種情況下回源的時(shí)候并沒(méi)有發(fā)起range請(qǐng)求，OSS是會(huì)響應(yīng)Content-MD5的。.OSS會(huì)返回CRC，如果要做文件一致性校驗(yàn)的話可以通過(guò)x-oss-hash-crc64ecma字段獲取CRC來(lái)做校驗(yàn)。對(duì)象存儲(chǔ)OSS源站不支持range導(dǎo)致請(qǐng)求CDN異常斷開(kāi)作者：胡夫通過(guò)CDN訪問(wèn)資源異常斷開(kāi)，無(wú)法讀取完整的數(shù)據(jù)。L2的日志分析看，接入層access日志顯示后端主動(dòng)斷開(kāi)連接，由于接入層的后端是緩存模塊swift，即是swift斷開(kāi)了連接。而swift的后端回源模塊沒(méi)有斷開(kāi)連接，由此可見(jiàn)這個(gè)請(qǐng)求就是L2的swift斷開(kāi)的。這里還有一個(gè)奇怪的地方，access日志的狀態(tài)碼是206，而回源模塊的狀態(tài)碼是200。進(jìn)一步發(fā)現(xiàn)，實(shí)際這個(gè)請(qǐng)求發(fā)起的是一個(gè)range請(qǐng)求，范圍bytes=1572864-2097151，但是源站卻沒(méi)有按照標(biāo)準(zhǔn)響應(yīng)206狀態(tài)碼，而是響應(yīng)了200狀態(tài)碼，導(dǎo)致L2一直在向源站讀數(shù)據(jù)。由于用戶的需求是需要讀取整個(gè)文件，查詢L1的日志發(fā)現(xiàn)客戶端確實(shí)是沒(méi)有發(fā)起range請(qǐng)求的，但是L2回源確發(fā)起了range請(qǐng)求。查詢域名配置發(fā)現(xiàn)域名開(kāi)啟了強(qiáng)制range回源。整個(gè)過(guò)程如下：.1.客戶端發(fā)起一個(gè)完整讀取文件的請(qǐng)求，由于域名開(kāi)了強(qiáng)制分片回源，L2在回源的時(shí)候發(fā)起了2.L2發(fā)起range請(qǐng)求回源，但是源站響應(yīng)了200，而不是206，這就會(huì)導(dǎo)致L2會(huì)讀取完整的整個(gè)文件的數(shù)據(jù)，而不僅僅是range請(qǐng)求的數(shù)據(jù)。3.由于這個(gè)文件非常大，導(dǎo)致L2一直在讀數(shù)據(jù)中，L2的swift由于已經(jīng)讀完了range請(qǐng)求的數(shù)據(jù)，但是還在讀后面的數(shù)據(jù)，但發(fā)現(xiàn)來(lái)自L1的range請(qǐng)求數(shù)據(jù)已經(jīng)有緩存了，就直接返回了緩存數(shù)據(jù)，同時(shí)也斷開(kāi)了連接。源站優(yōu)化，針對(duì)range請(qǐng)求需要響應(yīng)206狀態(tài)碼，而不是200狀態(tài)碼。如果源站對(duì)range請(qǐng)求無(wú)法正確響應(yīng)，那么CDN只能關(guān)閉range請(qǐng)求，但是關(guān)閉range請(qǐng)求的情況下對(duì)于大文件的訪問(wèn)效果和命中效果不佳，容易造成比較大的回源流量。.CDN回源帶寬突增作者：胡夫CDN控制臺(tái)顯示05-24日CDN回源帶寬突增，同時(shí)訪問(wèn)有異常，有很多5xx錯(cuò)誤?？刂婆_(tái)查看監(jiān)控信息，發(fā)現(xiàn)一周內(nèi)同比對(duì)比，訪問(wèn)帶寬并沒(méi)有突增，跟周圍幾天的業(yè)務(wù)量保持一致，說(shuō)明業(yè)務(wù)側(cè)并沒(méi)有明顯的上量，但是回源帶寬在異常時(shí)間確實(shí)有一個(gè)突增，而且命中率突降。下載對(duì)應(yīng)時(shí)間段CDN的日志，發(fā)現(xiàn)有大量的httpcode為206的range日志，請(qǐng)求的是zip后綴的大文件。分析日志查詢前10的clientip，例如top1的clientIP在1小時(shí)日志里有上萬(wàn)條請(qǐng)求，都是range請(qǐng)求zip。查詢r(jià)ange配置，發(fā)現(xiàn)CDN上并沒(méi)有開(kāi)啟range回源。同時(shí)直接range請(qǐng)求源站，發(fā)現(xiàn)源站并不支持range請(qǐng)求。由此問(wèn)題基本明確是range原因產(chǎn)生。在5.24日上午的時(shí)候，07:00～11:00期間，有一些客戶端在請(qǐng)求一些大文件，比如類似日志里分析的zip。由于文件比較大，客戶端發(fā)的是range請(qǐng)求，range的形式分片去請(qǐng)求。而這個(gè)文件由于在CDN上沒(méi)有緩存，因此CDN需要去回源。另外由于CDN上沒(méi)有配置開(kāi)啟range回源，因此雖然客戶端請(qǐng)求的時(shí)候帶了range，但是CDN回源請(qǐng)求源站的時(shí)候是不帶range的，CDN是向源站請(qǐng)求完整的數(shù)據(jù)然后返回給客戶端。但是由于客戶端拿完他該拿的數(shù)據(jù)部分（range的部分）就斷開(kāi)了，客戶端的斷開(kāi)導(dǎo)致CDN跟源站的連接也斷開(kāi)了，這種情況下這個(gè)文件并沒(méi)有緩存到CDN上。然后客戶端繼續(xù)發(fā)range請(qǐng)求，CDN繼續(xù)做同樣的動(dòng)作，因?yàn)橐恢本彺娌蛔?，而客戶端又一直在range請(qǐng)求，CDN就會(huì)一直回源，造成回源帶寬增加，源站的壓力增大，產(chǎn)生了一些504。這種情況建議CDN上開(kāi)啟range回源，這樣CDN也會(huì)range的形式請(qǐng)求源站，并且把range到的部分緩存到CDN上，不過(guò)前提是需要源站支持range請(qǐng)求。不過(guò)現(xiàn)在直接測(cè)試源站，發(fā)range請(qǐng)求，源站返回的是完整部分，因此源站不支持range請(qǐng)求，這樣即使CDNrange回源也達(dá)不到效果，因此需要源站開(kāi)啟range功能，然后CDN開(kāi)啟range回源來(lái)優(yōu)化這個(gè)場(chǎng)景。全站加速.41>跨域問(wèn)題-The'Access-Control-Allow-Origin'headerhasavalue'xxx'thatisnotequaltothesuppliedorigin跨域問(wèn)題-The'Access-Control-Allow-Origin'thesuppliedorigin作者：胡夫請(qǐng)求CDN加速的URL出現(xiàn)跨域報(bào)錯(cuò)從問(wèn)題看，CDN響應(yīng)的跨域頭Access-Control-Allow-Origin的Value值，跟客戶端請(qǐng)求的Origin跨域頭不一致，因此瀏覽器Bolck這個(gè)請(qǐng)求了。例如，請(qǐng)求跨域頭為'Origin:http://域名A'，但是響應(yīng)跨域頭為'Access-Control-Allow-Origin:http://域名B'這個(gè)問(wèn)題有以下幾種情況：跨域問(wèn)題-The'Access-Control-Allow-Origin'headerhasavalue'xxx'thatisnotequaltothesuppliedorigin這種情況需要修改CDN的跨域頭配置，配置成和客戶端請(qǐng)求的Origin一致。但是目前CDN默認(rèn)只能配置一個(gè)跨域頭，如果實(shí)際業(yè)務(wù)里存在多個(gè)Origin的情況下，CDN的跨域Value可以配置成"*",或者通過(guò)后臺(tái)PE修改配置為按照客戶端請(qǐng)求的Origin去分發(fā)匹配的跨域頭。第一次客戶端請(qǐng)求的時(shí)候，請(qǐng)求跨域頭為'Origin:http://域名A'，CDN沒(méi)有命中緩存，按照規(guī)則回源，由于源站配置了跨域頭，響應(yīng)了'Access-Control-Allow-Origin:http://域名A'；第二次客戶端請(qǐng)求的時(shí)候，請(qǐng)求跨域頭為'Origin:http://域名B'，但是由于CDN之前已經(jīng)緩存了，直接返回了緩存數(shù)據(jù)，而緩存數(shù)據(jù)里跨域響應(yīng)頭為'Access-Control-Allow-Origin:http://域名A'，這就導(dǎo)致響應(yīng)的Value值和客戶端不匹配，導(dǎo)致被瀏覽器Block。針對(duì)這種情況有兩種解法：方案一源站不用配置跨域頭，直接在CDN上配置跨域頭即可。然后刷新下CDN的緩存，把歷史緩存都清除掉。方案二CDN上配置Access-Control-Allow-Origin的時(shí)候選擇"不允許重復(fù)",這種情況下當(dāng)源站響應(yīng)跨域頭時(shí)，CDN會(huì)去掉源站的響應(yīng)頭，按照CDN的跨域響應(yīng)頭規(guī)則響應(yīng)給客戶端。43>跨域問(wèn)題-The'Access-Control-Allow-Origin'headerhasavalue'xxx'thatisnotequaltothesuppliedorigin第一次客戶端請(qǐng)求的時(shí)候，請(qǐng)求跨域頭為'Origin:http://域名A'，CDN響應(yīng)了'Access-Control-Allow-Origin:http://域名A'；第二次客戶端請(qǐng)求的時(shí)候，請(qǐng)求跨域頭為'Origin:http://域名B'，但是由于瀏覽器緩存了上一次請(qǐng)求的結(jié)果，直接返回了緩存數(shù)據(jù)，而緩存數(shù)據(jù)里跨域響應(yīng)頭為'Access-Control-Allow-Origin:http://域名A'，這就導(dǎo)致響應(yīng)的Value值和客戶端不匹配，導(dǎo)致被瀏覽器Block。這種情況需要強(qiáng)制刷新瀏覽器的緩存，另外為了避免這種情況的發(fā)生，建議在CDN上配置Cache-Control為no-cache，強(qiáng)制瀏覽器不緩存。413-GET請(qǐng)求不支持?jǐn)y帶body作者：胡夫請(qǐng)求CDN圖片時(shí)返回httpcode=413的問(wèn)題，瀏覽器請(qǐng)求正常，但是App端GET請(qǐng)求會(huì)報(bào)錯(cuò)4測(cè)試發(fā)現(xiàn)客戶端發(fā)起的GET請(qǐng)求里是帶了body的，respheaders返回了x-swift-error:invalidrequest表示請(qǐng)求不合法。GET請(qǐng)求如果攜帶body會(huì)返回413情況，因?yàn)閟wift不支持這樣請(qǐng)求。解決方案修改App請(qǐng)求圖片的邏輯，GET請(qǐng)求的時(shí)候不要帶body體。通過(guò)阿里云CDN系列產(chǎn)品訪問(wèn)與直接訪問(wèn)源站得到的結(jié)果不一樣作者：胡夫用了CDN加速以后，請(qǐng)求資源得到的結(jié)果和不通過(guò)CDN加速直接訪問(wèn)源站得到的結(jié)果不一致。當(dāng)客戶端請(qǐng)求CDN節(jié)點(diǎn)以后，如果沒(méi)有命中緩存，CDN會(huì)回源請(qǐng)求源站。在請(qǐng)求源站的時(shí)候，CDN除了會(huì)透?jìng)骺蛻舳说恼?qǐng)求頭，還會(huì)加上一些CDN特有的一些請(qǐng)求頭去請(qǐng)求源站,比如類似如下的請(qǐng)求頭。其中某些頭是特定功能有關(guān)，比如Ali-Swift-Range-Cache是關(guān)于Range回源的，如果CDN上開(kāi)了Range回源，就會(huì)加上這個(gè)頭。還有一些頭是固定都會(huì)有的，比如Via頭是表示的代理服務(wù)器，記錄的字段主要表示這個(gè)請(qǐng)求經(jīng)過(guò)的CDN節(jié)點(diǎn)，Ali-Cdn-Real-Ip記錄的是客戶端真實(shí)IP，X-Forwarded-For字段就是標(biāo)準(zhǔn)的HTTPXFF字段。具體這些請(qǐng)求頭，在源站轉(zhuǎn)包分析就能看到來(lái)自CDN.的請(qǐng)求頭到底有哪些。某些情況下，源站對(duì)于這里的一些請(qǐng)求頭，有一些不一樣的表現(xiàn)，大部分請(qǐng)求下都是因?yàn)閂ia這個(gè)請(qǐng)求頭導(dǎo)致的。源站接受到一個(gè)請(qǐng)求的時(shí)候，對(duì)于請(qǐng)求頭是否帶了Via頭會(huì)有不一樣的表現(xiàn)，因?yàn)橛行┰凑镜呐渲脮?huì)判斷是否有Via頭以此來(lái)判斷該請(qǐng)求是否來(lái)自代理服務(wù)器，然后做出不一樣的響應(yīng)。如何驗(yàn)證這個(gè)問(wèn)題是跟CDN的Via請(qǐng)求頭有關(guān)，或者跟另外的請(qǐng)求頭有關(guān)，這個(gè)可以通過(guò)在客戶端構(gòu)造HTTP請(qǐng)求，帶上Via頭去請(qǐng)求源站，看源站的響應(yīng)表現(xiàn)。例如使用curl工具綁定源站，并帶Via請(qǐng)求頭的測(cè)試命令如下如果帶了Via和不帶Via的請(qǐng)求話，源站服務(wù)器的表現(xiàn)不一樣，即可定位是源站對(duì)于Via字段有不一樣的表現(xiàn)，因此就可以解釋為什么通過(guò)CDN以后會(huì)有不一樣的表現(xiàn)。當(dāng)然，如果不是Via字段引起的，也可以帶上其他CDN的特有請(qǐng)求頭繼續(xù)追蹤驗(yàn)證，看具體是因?yàn)槟膫€(gè)請(qǐng)求頭引起的。如果定位到是由于CDN的某一個(gè)特定的頭導(dǎo)致源站有不一樣的表現(xiàn)，可以參考以下兩種解決方案去處理：（1）源站去檢查服務(wù)器配置，更改源站配置。（2）目前CDN已經(jīng)支持刪除回源請(qǐng)求頭，可以直接到CDN控制臺(tái)去配置刪除相關(guān)的回源請(qǐng)求頭。通過(guò)阿里云CDN系列產(chǎn)品訪問(wèn)與直接訪問(wèn)源站得到的目前DCDN暫時(shí)還未支持用戶自定義配置回源HTTP請(qǐng)求頭，需要提交工單后臺(tái)去配置。CDN系列產(chǎn)品，包括CDN、DCDN、SCDNDNS劫持導(dǎo)致訪問(wèn)目標(biāo)地址失敗并且解析主機(jī)作者：胡夫用戶使用CDN下載資源失敗，并且通過(guò)DNS解析主機(jī)后得到的IP地址也不是CDN節(jié)點(diǎn)的IP地址。DNS劫持是網(wǎng)絡(luò)上一種干擾用戶正常訪問(wèn)服務(wù)的行為。一般情況下，DNS劫持的方式分為攻擊DNS服務(wù)器和偽造DNS服務(wù)器兩種。DNS劫持會(huì)導(dǎo)致以下兩種情況發(fā)生：l將目標(biāo)網(wǎng)站域名解析到錯(cuò)誤的IP地址從而實(shí)現(xiàn)用戶無(wú)法訪問(wèn)目標(biāo)網(wǎng)站。l蓄意或惡意要求用戶訪問(wèn)指定網(wǎng)站。當(dāng)使用CDN下載資源失敗時(shí)，可以參考以下內(nèi)容確認(rèn)是否發(fā)生了DNS劫持：1.使用基調(diào)聽(tīng)云工具進(jìn)行測(cè)撥，當(dāng)用戶側(cè)訪問(wèn)目標(biāo)網(wǎng)站后，發(fā)現(xiàn)部分通過(guò)DNS解析主機(jī)后的IP地址不是CDN節(jié)點(diǎn)的IP地址。2.在用戶側(cè)使用第三方探測(cè)工具，例如，dig工具測(cè)試用戶DNS的工作狀態(tài)，以下是dig測(cè)試訪問(wèn)目標(biāo)網(wǎng)站后的返回圖。可以發(fā)現(xiàn)在ANSWER區(qū)域中，本次解析僅有A解析，并沒(méi)有CNAME解析的相關(guān)信息，因此判斷發(fā)生了DNS劫持。收集下列信息并向運(yùn)營(yíng)商獲取協(xié)助處理：l具體的用戶信息lCDN域名l故障發(fā)生區(qū)域和運(yùn)營(yíng)商l客戶端出口IP和出口DNSl說(shuō)明：關(guān)于獲取客戶端出口IP和出口DNS，可參考更多信息。l被劫持的IP地址.關(guān)于如何獲取客戶端出口IP和出口DNS，可根據(jù)您的客戶端操作系統(tǒng)參考以下內(nèi)容。1.確認(rèn)已安裝curl工具，然后執(zhí)行以下命令，獲取出口IP地址。2.執(zhí)行以下命令，獲取出口DNS信息。系統(tǒng)返回類似如下。進(jìn)入網(wǎng)頁(yè)瀏覽器，在地址欄輸入以下內(nèi)容然后訪問(wèn)網(wǎng)頁(yè)。瀏覽器返回類似如下。劫持問(wèn)題導(dǎo)致通過(guò)CDN請(qǐng)求資源沒(méi)有返回實(shí)際資源文件作者：胡夫通過(guò)CDN請(qǐng)求網(wǎng)站資源，有時(shí)會(huì)沒(méi)有返回實(shí)際的資源文件，而是返回其他類型的資源，例如text/html類型的內(nèi)容。從問(wèn)題描述看，可以初步判斷是由于網(wǎng)站資源被劫持導(dǎo)致，您可以按照以下示例抓包進(jìn)行確認(rèn)：1.使用Wireshark抓取請(qǐng)求資源時(shí)的數(shù)據(jù)包，詳情請(qǐng)參見(jiàn)網(wǎng)絡(luò)異常時(shí)如何抓取數(shù)據(jù)包。2.2號(hào)包是TCP三次握手的第2次握手包，單擊第2次握手包，確認(rèn)Timetolive（TTL）值在正常的范圍。3.5號(hào)包是服務(wù)端響應(yīng)HTTP請(qǐng)求的報(bào)文，TTL變?yōu)?27，和上一步查看的TTL值不一樣，說(shuō)明為異常情況。說(shuō)明：正常情況下Linux系統(tǒng)實(shí)例的TTL都是小于64。在Wireshark的FollowHTTPStream中可以看到響應(yīng)的ResponseHeader明顯不正常，沒(méi)有CDN特有的響應(yīng)頭，例如Via、EagleId，說(shuō)明這個(gè)請(qǐng)求不是從CDN節(jié)點(diǎn)響應(yīng)的。.4.1到3號(hào)包顯示客戶端跟CDN節(jié)點(diǎn)是正常TCP握手報(bào)文，4號(hào)包顯示在客戶端握手以后正常發(fā)起HTTP請(qǐng)求，但是請(qǐng)求被劫持，由中間網(wǎng)絡(luò)的其他鏈路節(jié)點(diǎn)響應(yīng)了這個(gè)HTTP請(qǐng)求，6號(hào)包顯示客戶端以為收到了正常的響應(yīng)，7號(hào)包正常發(fā)起FIN包，實(shí)際這個(gè)FIN包到了CDN節(jié)點(diǎn)，8到10號(hào)包可以看到報(bào)文的TTL是正常的，說(shuō)明CDN節(jié)點(diǎn)響應(yīng)了RST包。整個(gè)過(guò)程中，CDN節(jié)點(diǎn)至始至終都沒(méi)有真正的收到來(lái)自客戶端的HTTP請(qǐng)求。l建議使用HTTPS訪問(wèn)資源，提高訪問(wèn)安全，可以有效防止此類內(nèi)容劫持。如何配置CDN的HTTPS訪問(wèn)資源，詳情請(qǐng)參見(jiàn)配置HTTPS證書(shū)。l如果無(wú)法解決問(wèn)題，可能是由以下兩個(gè)原因?qū)е拢藭r(shí)需要獲取運(yùn)營(yíng)商協(xié)助。。CDN節(jié)點(diǎn)被運(yùn)營(yíng)商封了，或者節(jié)點(diǎn)本身有問(wèn)題。。用戶域名被運(yùn)營(yíng)商封了。.TCP劫持導(dǎo)致某地移動(dòng)CDN節(jié)點(diǎn)HTTPS訪問(wèn)失敗作者：胡夫在使用阿里云CDN服務(wù)時(shí)，在業(yè)務(wù)側(cè)做的監(jiān)控報(bào)警顯示某地移動(dòng)業(yè)務(wù)不可用。根據(jù)提供的URL和CDN節(jié)點(diǎn)Vip測(cè)試發(fā)現(xiàn)，會(huì)出現(xiàn)SSL握手失敗。進(jìn)行問(wèn)題的基礎(chǔ)分析，發(fā)現(xiàn)以下幾個(gè)現(xiàn)象：l在節(jié)點(diǎn)系統(tǒng)中探測(cè)該URL，發(fā)現(xiàn)其他CDN節(jié)點(diǎn)均正常，只有探測(cè)到這個(gè)某地移動(dòng)的CDN節(jié)點(diǎn)時(shí)有異常。l如果用HTTP請(qǐng)求到這個(gè)CDN節(jié)點(diǎn)，則是正常的，只有HTTPS訪問(wèn)有問(wèn)題。l基于以上兩點(diǎn)分析，推測(cè)該CDN節(jié)點(diǎn)可能是歷史不支持SNI的老節(jié)點(diǎn)。于是找到其他的CDN域名綁定到該節(jié)點(diǎn)，用HTTPS訪問(wèn)，卻是正常的，因此SNI的問(wèn)題也可排除。由于綁定節(jié)點(diǎn)能直接復(fù)現(xiàn)問(wèn)題，因此直接在客戶端側(cè)進(jìn)行抓包，通過(guò)ip.addr過(guò)濾該Vip的報(bào)文如下：80、81、82報(bào)文客戶端和服務(wù)端完成了TCP三次握手，接下來(lái)83號(hào)報(bào)文，客戶端發(fā)起了SSL的握手請(qǐng)求，但是84號(hào)報(bào)文服務(wù)端直接發(fā)了RST。由于CDN在正常情況下不可能出現(xiàn)這種RST包，已經(jīng)可推斷是劫持問(wèn)題。進(jìn)一步查看這個(gè)RST報(bào)文（84發(fā)現(xiàn)TTL（Timetolive）的值為58，Identification的值為0；而查看TCP三次握手服務(wù)端的報(bào)文（81顯示TTL的值為49，Identification的值為0。通常情況下，鏈路劫持的判斷依據(jù)會(huì)從以下幾個(gè)方面進(jìn)行判斷分析：lTTL：表現(xiàn)為T(mén)CP報(bào)的TTL不一致甚至抖動(dòng)很大。。一種情況：是跟正常包的TTL相差明顯。。另一種情況：是通過(guò)TTL來(lái)判斷操作系統(tǒng)類型，進(jìn)而間接判斷數(shù)據(jù)包是否有異常。lIdentification：出現(xiàn)不符合RFC標(biāo)準(zhǔn)的情況。對(duì)于給定地址和協(xié)議的IP包，它的Identification應(yīng)該是公差為1的單調(diào)遞增數(shù)列。每一個(gè)IP封包都有一個(gè)16位的唯一識(shí)別碼?當(dāng)程序產(chǎn)生的數(shù)據(jù)要通過(guò)網(wǎng)絡(luò)傳送時(shí)，都會(huì)被拆散成封包形式發(fā)送，當(dāng)封包要進(jìn)行重組的時(shí)候，這個(gè)ID就是依據(jù)?標(biāo)識(shí)字段唯一地標(biāo)識(shí)主機(jī)發(fā)送的每一份數(shù)據(jù)報(bào)，通常每發(fā)送一份消息它的值就會(huì)加1?說(shuō)明：其中關(guān)于Identification的描述，可以參見(jiàn)RFC文檔。以下截圖是選自RFC文檔對(duì)于Identification的描述。lBanner信息：表現(xiàn)為ResponseHeader中響應(yīng)的Server字段不對(duì)，例如CDN是Tengine，如果顯示的響應(yīng)頭為T(mén)omcat或者其他，那么很明顯這個(gè)請(qǐng)求不是CDN響應(yīng)。根據(jù)抓包分析，可以發(fā)現(xiàn)以下幾個(gè)點(diǎn)：lTCP握手包、服務(wù)端響應(yīng)包的TTL為49，而RST包的TTL為58，這個(gè)抖動(dòng)很大。正常情況TCP握手成功以后，在TCP斷開(kāi)前，這條鏈路應(yīng)該是穩(wěn)定的，TTL基本會(huì)維持固定的值，不會(huì)馬上出現(xiàn)這么大的變動(dòng)。lIdentification明顯不符合RFC標(biāo)準(zhǔn)。如果81和84號(hào)包都是同一個(gè)CDN節(jié)點(diǎn)響應(yīng)的，那么84號(hào)包應(yīng)該有一個(gè)具體的IdentificationValue值，而不是和81號(hào)包保持一致，都是0。綜上所述，基本上可以判斷是運(yùn)營(yíng)商劫持行為，且是針對(duì)這個(gè)域名做的劫持，CDN作為一個(gè)服務(wù)端來(lái)說(shuō)確實(shí)無(wú)法處理該類問(wèn)題。因此，提供相關(guān)的抓包證明，給相關(guān)運(yùn)營(yíng)商報(bào)故障處理。整個(gè)HTTPS的請(qǐng)求過(guò)程如下：l客戶端發(fā)起一次HTTPS請(qǐng)求，首先客戶端和服務(wù)端完成了TCP握手，而這個(gè)TCP握手確實(shí)是和CDN節(jié)點(diǎn)握手的。說(shuō)明：一般情況下握手的包不會(huì)被劫持。l握手成功以后客戶端發(fā)起SSL握手請(qǐng)求，這個(gè)請(qǐng)求最終卻沒(méi)有到達(dá)真正的CDN節(jié)點(diǎn)，而是被劫持到中間某一個(gè)路由節(jié)點(diǎn)給直接RST。如果要確定一個(gè)請(qǐng)求到底是否被劫持，最好的方案是在客戶端發(fā)起請(qǐng)求以后，客戶端和服務(wù)端同時(shí)雙向抓包確認(rèn)。但是這往往需要有相關(guān)權(quán)限的工程師登錄CDN節(jié)點(diǎn)進(jìn)行抓包，操作起來(lái)有一定難度。有時(shí)候可以通過(guò)客戶端抓包，看到明顯的異常TTL、Identification信息進(jìn)行推斷，也能基本定位。預(yù)熱文件卡住-海外L2回源國(guó)內(nèi)源站跨境鏈路作者：蒼柏用戶2021-01-0916:40:48+0800CST提交了一個(gè)zip文件的預(yù)熱，完成時(shí)間是2021-01-0916:40:57+0800CST，用戶源站100M帶寬，18:11:31反饋卡在78.57%，一小時(shí)以后查看，進(jìn)度還是卡在78.57%。預(yù)熱卡住一般是因?yàn)槟骋粋€(gè)或者某幾個(gè)節(jié)點(diǎn)，從客戶源站下載數(shù)據(jù)時(shí)候速度較慢，或者超時(shí)等導(dǎo)致。查看用戶的源站是國(guó)內(nèi)的源站。海外的L2節(jié)點(diǎn)請(qǐng)求國(guó)內(nèi)的源站，走跨境鏈路，可能會(huì)受到跨境鏈路影響，這部分問(wèn)題CDN層面也很難處理。預(yù)熱可以支持國(guó)內(nèi)和海外的，建議分開(kāi)預(yù)熱，先預(yù)熱國(guó)內(nèi)節(jié)點(diǎn)，再預(yù)熱海外的?？刂婆_(tái)目前沒(méi)有開(kāi)放分區(qū)域預(yù)熱的功能，目前可以使用API或者腳本的方式預(yù)熱，參考官網(wǎng)API預(yù)熱接口PushObjectCache文檔。設(shè)置了緩存規(guī)則但每次訪問(wèn)還是MISS作者：蒼柏CDN上配置了緩存規(guī)則但每次訪問(wèn)還是MISS的原因說(shuō)明?？蛻粼贑DN上配置了緩存規(guī)則，且客戶源站并未響應(yīng)no-cache的cache-control，但每次訪問(wèn)之后仍然是MISS，無(wú)法實(shí)現(xiàn)HIT。需要排查具體原因。訪問(wèn)URL：/查看瀏覽器開(kāi)發(fā)者工具下的responseHeader，確認(rèn)到無(wú)論是L1還是L2都是MISS，且無(wú)論F5刷新多少次頁(yè)面，每次都還是MISS，但比較奇怪的是：x-swift-cachetime并非0，而是一個(gè)很長(zhǎng)的數(shù)字。檢查控制臺(tái)配置，發(fā)現(xiàn)客戶配置了針對(duì)根目錄下的7776000的緩存時(shí)長(zhǎng)配置，和x-swift-cachetime時(shí)長(zhǎng)一致，回源請(qǐng)求頭以及ER、ES等均不存在配置。綁定客戶源站，發(fā)現(xiàn)客戶的源站響應(yīng)頭如下，存在Vary:Accept-Encoding,Cookie。我們知道，如果想要訪問(wèn)通過(guò)CDN加速的站點(diǎn)，實(shí)現(xiàn)PC端訪問(wèn)展示PC端內(nèi)容，mobile端訪問(wèn)展示mobile內(nèi)容，則可以通過(guò)源站增加：vary:user-agent來(lái)說(shuō)實(shí)現(xiàn)此需求；即針對(duì)不同的UA緩存不同的源站內(nèi)容；同樣：vary:Accept-Encoding表示，針對(duì)客戶端不同的Accept-Encoding值，緩存并響應(yīng)不同的編碼內(nèi)容，常用于Gzip，Br等壓縮各響應(yīng)不同內(nèi)容的需求中。同理，對(duì)vary:cookie，則表示對(duì)請(qǐng)求頭中的cookie，不同的值，緩存并響應(yīng)不同的內(nèi)容。所以，本例中，因?yàn)檎?qǐng)求頭中包含cookie，且每次訪問(wèn)客戶端請(qǐng)求頭中的cookie的值均不相同，相當(dāng)于每次訪問(wèn)到CDN上都是一個(gè)全新的內(nèi)容，都是第一次訪問(wèn)，第一次緩存，所以每次都是MISS，但又因?yàn)镃DN上配置了全站緩存7776000秒，所以每一個(gè)的x-swift-cachetime都是7776000如此長(zhǎng)的時(shí)間。源站去掉vary:cookie的responseHeader之后，此問(wèn)題解決。抽絲剝繭定位一個(gè)CDN訪問(wèn)慢的案例作者：胡夫某客戶反饋使用CDN以后下載時(shí)間很慢，TTFB很長(zhǎng)，需要定位原因。根據(jù)Network下的信息后臺(tái)查到CDN的日志信息，發(fā)現(xiàn)訪問(wèn)慢是因?yàn)橹虚g有過(guò)504重試，具體過(guò)程如下：（1）客戶端請(qǐng)求到L1（cn2620L1回源到cache18.l2cn2635以后，cache18.l2cn2635回（2）cache18.l2cn2635響應(yīng)504以后，觸發(fā)L1重試到cache12.l2cn2641，回源成功，RT時(shí)所以雖然最終現(xiàn)象看起來(lái)是訪問(wèn)成功了，只是速度比較慢，實(shí)際的過(guò)程中是因?yàn)橛?04并發(fā)生了重試，耗時(shí)主要是第一次回源504的耗時(shí)。同時(shí)查看但是客戶端提供的Network下的響應(yīng)頭也可以進(jìn)一步確認(rèn)此問(wèn)題，當(dāng)時(shí)雖然響應(yīng)了httpcode200，但是響應(yīng)頭里響應(yīng)了x-swift-error：origresponse5xxerror日志服務(wù)SLS查看L2的錯(cuò)誤日志分析，504錯(cuò)誤基本就是聚焦在l2cn2635節(jié)點(diǎn)，且rt時(shí)間是5s左右。根據(jù)前面的分析，其他L2節(jié)點(diǎn)到源站首字節(jié)都正常，日志也正常，唯獨(dú)這個(gè)L2節(jié)點(diǎn)到源站會(huì)504，而且首字節(jié)時(shí)間是5kms，因此懷疑是源站做了相關(guān)安全策略，或者該節(jié)點(diǎn)到源站的網(wǎng)絡(luò)問(wèn)題。但是用戶的源站是阿里云的SLB，且用戶反饋SLB層面并沒(méi)有做安全策略。由于該L2是唐山的一個(gè)L2節(jié)點(diǎn)，因此想到用聽(tīng)云到唐山地區(qū)用三大運(yùn)營(yíng)商探測(cè)下源站，發(fā)現(xiàn)也一切正常。CDN回源源站的時(shí)候產(chǎn)生了504，但是客戶源站SLB的日志并沒(méi)有查到504的日志，看起來(lái)這個(gè)504日志不是源站響應(yīng)的，那么就有可能CDN回源超時(shí)導(dǎo)致的。但是根據(jù)rt時(shí)間看5s就504了，看起來(lái)并沒(méi)有達(dá)到默認(rèn)CDN約定的回源超時(shí)時(shí)間，默認(rèn)CDN回源的超時(shí)時(shí)間是：建聯(lián)超時(shí)10s（也就是說(shuō)tcp連接10s超時(shí)讀客戶端請(qǐng)求頭超時(shí)時(shí)間：30s（也就是說(shuō)應(yīng)用層30s超時(shí)）。至此，一共有如下幾個(gè)疑問(wèn)需要確認(rèn)：（1）看起來(lái)rt時(shí)間5s并沒(méi)有達(dá)到超時(shí)時(shí)間，看起來(lái)不是超時(shí)導(dǎo)致，那么有可能是源站直接響應(yīng)504。（2）回源504日志顯示的錯(cuò)誤碼是"0"，也就是CDN認(rèn)為是正常請(qǐng)求，并不認(rèn)為是連接不上或超時(shí)斷開(kāi)這種情況，這也進(jìn)一步印證了源站直接響應(yīng)504的情況。（3）但是現(xiàn)在的問(wèn)題是源站查不到504日志，那么有沒(méi)有可能是客戶反饋的源站日志排查的結(jié)果不可靠？為了驗(yàn)證到底是不是源站吐的504，因此考慮讓用戶在源站側(cè)抓包，然后客戶端去訪問(wèn)復(fù)現(xiàn)，出現(xiàn)問(wèn)題以后提供chrome的har文件和源站的抓包文件。根據(jù)日志分析，第一次是cache18.l2cn2635回源504，回源的IP是101.x.xx.xx；然后L1重試到cache12.l2cn2641回源成功，回源的IP是115.xx.xx.xx。從源站的抓包文件看，可以看到來(lái)自115.xx.xx.xx的報(bào)文，但是過(guò)濾不到來(lái)自101.xx.xx.xx的報(bào)文，看起來(lái)就是101.xx.xx.xx的請(qǐng)求沒(méi)有到源站。目前情況看起來(lái)有點(diǎn)復(fù)雜了，源站SLB上沒(méi)有抓到來(lái)自CDN回源IP的報(bào)文，且源站日志沒(méi)有記錄該504請(qǐng)求的CDN回源IP的日志，看現(xiàn)象就是CDN回源源站的回源鏈路有問(wèn)題。為了進(jìn)一步驗(yàn)證這個(gè)問(wèn)題，只能到發(fā)生504的cache18.l2cn2635這臺(tái)機(jī)器上去抓包。從抓包結(jié)果來(lái)看，的確是源站直接響應(yīng)了504，而且看響應(yīng)504的報(bào)文里，TTL和SYN握手報(bào)文的TTL一致，看起來(lái)也不是被劫持導(dǎo)致，也不像是網(wǎng)絡(luò)問(wèn)題。而且只有兩臺(tái)CDN機(jī)器回源有504問(wèn)題，其他機(jī)器回源一切正常。各種證據(jù)表明，越來(lái)越像是源站有安全策略攔截了，但是源站是SLB，看SLB的一些訪問(wèn)控制的策略，比如IP黑白名單，即使攔截了應(yīng)該也能查到403的日志，而不會(huì)是504。檢查配置發(fā)現(xiàn)SLB開(kāi)啟了"透明WAF"功能。進(jìn)一步了解該功能原理，SLB開(kāi)啟透明WAF功能以后不需要更改DNS解析，請(qǐng)求SLB的流量都先走TWAF（透明WAFTWAF在CDN和SLB之間充當(dāng)了一個(gè)透明代理。TWAF和client建連時(shí)借用了SLB的IP，TWAF和SLB建連時(shí)借用了client的IP。那么根據(jù)這個(gè)現(xiàn)象看，極有可能是CDN的請(qǐng)求被TWAF攔截了（在下圖中，CDN的回源IP就是client）。去查了TWAF的攔截記錄，發(fā)現(xiàn)果然有攔截記錄，CDN的tproxyIP（回源IP）被WAF識(shí)別成攻擊IP，被用戶的訪問(wèn)控制策略加入到了WAF的黑名單里。致此，終于可以結(jié)案！由于業(yè)務(wù)請(qǐng)求走了CDN，CDN又通過(guò)匯聚式的L2節(jié)點(diǎn)回源，而源站配置了透明WAF，WAF配置的安全規(guī)則認(rèn)為這些頻繁回源的CDN節(jié)點(diǎn)IP是攻擊IP，被訪問(wèn)控制策略加入到黑名單，而TWAF通過(guò)響應(yīng)504的形式拒絕了來(lái)自CDN的回源請(qǐng)求。根據(jù)上面的TWAF實(shí)現(xiàn)原理圖可以知道，這個(gè)504的請(qǐng)求對(duì)于SLB來(lái)說(shuō)完全是沒(méi)有感知的，所以SLB上肯定沒(méi)有日志，需要查WAF的攔截日志才能發(fā)現(xiàn)。從黑名單里移除該CDN的回源IP即可。但是由于目前配置的策略，很有可能還會(huì)繼續(xù)把CDN的回源IP當(dāng)成攻擊IP處理，因此需要調(diào)整WAF攔截策略，或者把CDN的回源IP加入到白名單。但是這也有風(fēng)險(xiǎn)，因?yàn)镃DN回源時(shí)會(huì)智能分配節(jié)點(diǎn)訪問(wèn)源站，回源的節(jié)點(diǎn)IP是不固定的，因此不建議將源站的回源策略白名單設(shè)置為固定的節(jié)點(diǎn)IP列表，這樣有可能因?yàn)镃DN回源IP變更，新增IP由于未在白名單導(dǎo)致被攔截繼而發(fā)生回源失敗的情況。如果有強(qiáng)訴求，也可以通過(guò)調(diào)用CDN的DescribeL2VipsByDomain接口獲取CDN回源的節(jié)點(diǎn)IP列表并添加到源站服務(wù)器的白名單中。該接口僅支持日峰值帶寬為1Gbps以上的用戶調(diào)用，如果符合該條件，可以提交工單，申請(qǐng)?jiān)摻涌诘恼{(diào)用權(quán)限。全站加速.長(zhǎng)連接訪問(wèn)的場(chǎng)景下偶發(fā)出現(xiàn)CDN主動(dòng)發(fā)FIN包作者：胡夫用戶在測(cè)試長(zhǎng)連接場(chǎng)景，發(fā)現(xiàn)頻率不高的情況下，服務(wù)端(CDN)也會(huì)主動(dòng)發(fā)FIN包，并且FIN包之前會(huì)先發(fā)一個(gè)encryptedalert。SSL通信在斷開(kāi)連接時(shí)均為發(fā)送EncryptedAlert信息給客戶端告知要關(guān)閉ssl會(huì)話了，同步會(huì)發(fā)生FIN,ACK報(bào)文從TCP層面斷開(kāi)鏈接:Sincewearealreadyinanencryptedconnection,theonlywaytoreallyknowwhatisbeingsentwithinpacketsistomakeWiresharkorsimilartoolsawareofthekeysusedinthetransmission.Eventhoughthisispossible,Ithinkforthepurposeofthisanalysisitisenoughtoknowthattheclientsendsanalertmessagewhentheconnectionisaskedtobeclosedactivelybytheclientorserver.ThetypeofthisAlertmessageshouldbeCloseNotify(type0),butwewon’tbeabletoseeitfromtherawdata.Inthiscase,theclientisthesenderofthefollowingAlertmessage:encryptedalert只是一個(gè)告警，“encryptedalert”是https連接斷開(kāi)時(shí)（即tengine的finalize）必會(huì)發(fā)出的，就是四層需要揮手，tls層需要encryptedalert，是應(yīng)用層finalize后的必須過(guò)程。因此這個(gè)問(wèn)題不在這里，根本的原因需要看下tengine為什么會(huì)finalize，也就是為什么會(huì)斷開(kāi)連接。排查CDN的日志，從日志側(cè)沒(méi)有發(fā)現(xiàn)異常。因?yàn)楸旧磉@是屬于tcp長(zhǎng)連接的斷開(kāi)，并不是屬于異常斷開(kāi)，不會(huì)記錄499或者其他相關(guān)錯(cuò)誤碼，日志的相關(guān)字段都是正常的。嘗試在CDN的回源節(jié)點(diǎn)上抓包，在復(fù)現(xiàn)問(wèn)題的時(shí)候，發(fā)現(xiàn)源站會(huì)返回connectionclose頭部，導(dǎo)致tengine斷開(kāi)。由于當(dāng)時(shí)用戶的請(qǐng)求是一個(gè)POST請(qǐng)求，因此可以寫(xiě)一個(gè)腳本，本地host指向源站，用腳本發(fā)起長(zhǎng)連接請(qǐng)求，再連續(xù)請(qǐng)求的過(guò)程中也會(huì)出現(xiàn)斷開(kāi)的情況，示例代碼如下：Q客戶端發(fā)起長(zhǎng)連接請(qǐng)求，請(qǐng)求頭Connection:keep-alive。剛開(kāi)始交互一直是Connection:keep-alive，一段時(shí)間之后源站會(huì)主動(dòng)響應(yīng)Connection:close頭，導(dǎo)致cdntengine主動(dòng)斷開(kāi)和客戶端的連接。源站修改響應(yīng)Connection:close頭的策略去優(yōu)化。開(kāi)啟ossftp以后端口不通導(dǎo)致連接失敗作者：胡夫通過(guò)ftp客戶端去連接ossftp連接失敗。首先需要確保服務(wù)器上已經(jīng)安裝ossftp工具并按照文檔啟動(dòng)ossftp服務(wù)。其次需要確保服務(wù)器上安全組已經(jīng)開(kāi)啟相關(guān)的服務(wù)端口。如果只是開(kāi)放了端口，但是ossftp服務(wù)并沒(méi)有啟動(dòng)，那么肯定是連接不通這個(gè)端口。啟動(dòng)ossftp以后直接telnet測(cè)試服務(wù)器的公網(wǎng)2048端口還是不通，如圖2-1。從服務(wù)器上看ossftp確實(shí)啟動(dòng)起來(lái)的，如圖2-2。通過(guò)netstat-anpt命