1. 前言

貴金屬wap版直播間上線后，偶爾有用戶反饋，在進(jìn)入wap直播間的時(shí)候，出現(xiàn)空白頁(yè)面，但是重新刷新又可以正常顯示了。我們?cè)欢日J(rèn)為是網(wǎng)絡(luò)請(qǐng)求異常或兼容問題，直到開發(fā)PC版直播間，在進(jìn)行調(diào)試中，同樣遇到了“白屏”問題，才引起了足夠重視，并進(jìn)行了問題跟蹤與分析?，F(xiàn)在跟大家分享一下，這種偶然現(xiàn)象出現(xiàn)的原因。

我們的直播間落地頁(yè)在fa.163.com 系統(tǒng)，而直播間內(nèi)容，是通過 向直播間系統(tǒng) qz.fa.163.com 發(fā)起Ajax請(qǐng)求獲取的。在出現(xiàn)“白屏”的時(shí)候，可以通過瀏覽器的調(diào)試窗口，可以看到出現(xiàn)下面的報(bào)錯(cuò)

2. 問題分析

從上述錯(cuò)誤提示文案中可以看到，問題首先和 跨域 有關(guān)。

何為跨域

從字面上理解為“跨域名”，瀏覽器不能執(zhí)行其他網(wǎng)站的腳本，然而，跨域不僅僅局限于域名這一項(xiàng)。只要協(xié)議、域名、端口有任何一個(gè)不同，都被當(dāng)作是不同的域。 這是由于>同源策略的限制，從一個(gè)域上加載的腳本不允許訪問另外一個(gè)域的文檔屬性。雖然在瀏覽器中，<script>、<img>、<iframe>、<link>等標(biāo)簽都>可>以加載跨域資源，而不受同源限制，但瀏覽器會(huì)限制腳本中發(fā)起的跨域請(qǐng)求。比如，使用 XMLHttpRequest 對(duì)象和Fetch發(fā)起 HTTP 請(qǐng)求就必須遵守同源策略。

同源策略/SOP(Same origin policy)是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，瀏覽器很容易受到XSS、CSFR等攻擊。SOP要求兩個(gè)通訊地址的協(xié)議、域名、端口號(hào)必須相同，否則兩個(gè)地址的通訊將被瀏覽器視為不安全的，并被block下來。

舉個(gè)例子：從貴金屬主站 http://fa.163.com 發(fā)起請(qǐng)求訪問以下url：

解決跨域

在實(shí)際應(yīng)用中有多種方式來解決跨域問題，相信在實(shí)踐中都會(huì)用到其中的某些方案：

(1).JSONP (無狀態(tài)連接，不能獲悉連接狀態(tài)和錯(cuò)誤事件，而且只能走GET的形式)

(2).iframe形式

(3).服務(wù)器代理

頁(yè)面直接向同域的服務(wù)端發(fā)請(qǐng)求，服務(wù)端進(jìn)行跨域處理或爬蟲后，再把數(shù)據(jù)返回給客戶端頁(yè)。

(4).CORS

CORS(Cross-Origin Resource Sharing)跨域資源共享，定義了必須在訪問跨域資源時(shí)，瀏覽器與服務(wù)器應(yīng)該如何溝通。CORS背后的基本思想就>是使用自定義的HTTP頭部讓瀏覽器與服務(wù)器進(jìn)行溝通，從而決定請(qǐng)求或響應(yīng)是應(yīng)該成功還是失敗。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低>于IE10。整個(gè)CORS通信過程，都是瀏覽器自動(dòng)完成，不需要用戶參與。對(duì)于開發(fā)者來說，CORS通信與同源的AJAX通信沒有差別，代碼完全一樣。瀏>覽器一旦發(fā)現(xiàn)AJAX請(qǐng)求跨源，就會(huì)自動(dòng)添加一些附加的頭信息，有時(shí)還會(huì)多出一次附加的請(qǐng)求，但用戶不會(huì)有感覺。

CORS方式實(shí)現(xiàn)：

瀏覽器在發(fā)出CORS請(qǐng)求時(shí)會(huì)在頭信息之中增加一個(gè)Origin字段;后端返回代碼中增加三個(gè)字段

header(“Access-Control-Allow-Origin”:“”);           // 必選 允許所有來源訪問 
 
header(“Access-Control-Allow-Credentials”:“true”);  //可選 是否允許發(fā)送cookie 
 
header(“Access-Control-Allow-Method”:“POST,GET”);   //可選 允許訪問的方式  

nginx是一個(gè)高性能的web服務(wù)器，常用作反向代理服務(wù)器。nginx作為反向代理服務(wù)器，就是把http請(qǐng)求轉(zhuǎn)發(fā)到另一個(gè)或者一些服務(wù)器上。通過把本地一個(gè)url前綴映射到要跨域訪問的web服務(wù)器上，就可以。

為了解決跨域問題，我們選擇方案d ， 在直播間的過濾器中，統(tǒng)一添加了如下代碼：

<a href='http://www.jobbole.com/members/wx610506454'>@Override</a> 
 
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { 
 
 // 加入響應(yīng)頭 
 
 String origin = request.getHeader("Origin"); 
 
 if("http://fa.163.com".equals(origin) || "https://fa.163.com".equals(origin) ) { 
 
     response.addHeader("Access-Control-Allow-Origin", origin); 
 
     response.addHeader("Access-Control-Allow-Credentials", "true"); 
 
 } 
 
 return true;  

從錯(cuò)誤提示文案中，我們還可以看到錯(cuò)誤提示的關(guān)鍵點(diǎn) “http://fa.163.com” that is not equal to the supplied origin. Origin ‘https://fa.163.com‘ is therefore not allowed access.

目前我們的系統(tǒng)同時(shí)支持http訪問和https訪問，但是為什么使用 http訪問 ，返回的header中卻是 https 協(xié)議呢?

通過多次模擬，確認(rèn)出現(xiàn)問題的請(qǐng)求中，Request URL使用的協(xié)議和 response返回的headers中的 Access-Control-Allow-Origin 中的 協(xié)議確實(shí)不一致，且還有一個(gè)特性，X-Cached 為 HIT，如下圖：

命中了緩存的請(qǐng)求，出現(xiàn)了協(xié)議不一致?

突然想到，這個(gè)接口，我們配置了nginx 緩存，那必然和nginx緩存有關(guān)了。

Nginx 緩存

Nginx (engine x) 是一個(gè)高性能的HTTP和反向代理服務(wù)器。

首先從源服務(wù)器(內(nèi)部網(wǎng)絡(luò)上的web服務(wù)器)上獲取內(nèi)容，然后把內(nèi)容返回給用戶，同時(shí)，也會(huì)把內(nèi)容保存到代理服務(wù)器上一份，這樣日后再接收同樣的信息請(qǐng)求時(shí)，他會(huì)把本地緩存里的內(nèi)容直接發(fā)給用戶，以此減少后端web服務(wù)器的壓力，提高響應(yīng)速度。這其實(shí)就是緩存服務(wù)器所實(shí)現(xiàn)的功能。如下圖所示。

進(jìn)入直播間后，首先需要查詢直播內(nèi)容是否有更新，而這個(gè)接口客戶端會(huì)以5s間隔輪詢，為了減少tomcat的壓力，我們配置了nginx緩存。配置如下

其中：

proxy_cache_methods： 用來設(shè)置HTTP哪些方法會(huì)被緩存，直播間接口配置了GET、HEAD、POST;

proxy_cache_valid: 用來設(shè)置對(duì)不同HTTP狀態(tài)碼的不同緩存時(shí)間。直播間接口配置了對(duì)于 返回值為200的狀態(tài)碼，緩存5秒;

proxy_cache_min_uses: 用來設(shè)置多少次訪問后，應(yīng)答值會(huì)被緩存，配置為3次;

proxy_cache_key: 設(shè)置Web緩存的key

proxy_cache: 用來設(shè)置哪個(gè)緩存區(qū)將被使用，并定義緩存區(qū)的名稱

通過上述配置，我們可以看到 proxy_cache_key 配置中，只配置了host + uri + 參數(shù)，但沒有配置協(xié)議，所以無論用http訪問，還是https訪問，只要被緩存后，返回的內(nèi)容都是一樣的，而不會(huì)區(qū)分http或https。從而引起了跨域問題。

至此，問題分析完畢。

3. 問題解決

跟運(yùn)維同學(xué)溝通后，通過修改nginx配置，將協(xié)議類型scheme加入到緩存查找的判斷參數(shù)中，配置如下。

問題得到了解決。

4. 總結(jié)

上述“慘案” ，是 跨域、nginx緩存、http/https協(xié)議 這三種條件同時(shí)出現(xiàn)引發(fā)的。

如果不涉及跨域，混用 http/https協(xié)議 + nginx緩存，其實(shí)也是沒有問題的。但是一旦出現(xiàn)了跨域使用，必須 在nginx 緩存配置中，配置 scheme + host + uri +　參數(shù)。