純前端解決跨域問題

【51CTO活動】8.26 帶你深度了解清華大學、搜狗基於演算法的IT運維實踐與探索

背景

跨域是由瀏覽器的同源策略引起的，是指頁面請求的url地址，必須與瀏覽器上的url地址處於同域上(即域名，埠，協議相同)。

這是為了防止某域名下的介面被其他域名下的網頁非法調用，是瀏覽器對JavaScript施加的安全限制。

這個措施的出發點是好的，但是程序頁面開發的過程中，卻常常給前端開發者帶來麻煩。

由於前端開發過程中，靜態資源是放在本地電腦上的，訪問這些資源通常通過IP方式(127.0.0.1)或者localhosts來訪問，與線上伺服器所在域名不符，不能順利調用服務的埠。

解決跨域問題常用的解決方案有這兩個：

JSONP：利用script標籤可跨域的特點，在跨域腳本中可以直接回調當前腳本的函數。 CORS：伺服器設置HTTP響應頭中Access-Control-Allow-Origin的值，解除跨域限制。

但是這兩個跨域方案都存在一個致命的缺陷，嚴重依賴後端的協助。

開發中遇到的每一個介面都需要提前找後端進行特殊的處理。而且即使後端願意幫忙，某些介面不是隨便就能開放的(譬如已經在上線正式環境的介面)。

無論如何，依賴後端協助的跨域解決方案都會在一定程度上限制前端開發的進度。

那麼有沒有前端獨立就能實現的跨域方案呢?有的，我們可以利用「代理」或「反向代理」技術來實現開發中的跨域問題。

代理與反向代理

代理

代理，也稱正向代理，意思是一個位於客戶端和目標伺服器(target server)之間的伺服器，為了從目標伺服器取得內容，客戶端向代理髮送一個請求並指定目標(目標伺服器)，然後代理向目標伺服器轉交請求並將獲得的內容返回給客戶端。

通俗地說：

「客戶端」可以看作一個黑社會大佬，「目標伺服器」可以看作一家飯店，「代理伺服器」可以看作小弟。 「老大」想吃飯店的醬排骨飯，就讓「小弟」去買，「小弟」跑到「飯店」要個醬排骨飯。 「飯店」醬排骨飯做好，送到「小弟」手上，「小弟」最後再把醬排骨飯拿給「大佬」。

說白了，小弟就是個跑腿的，代理大佬的需求。

數據流程：

數據請求過程：瀏覽器-》代理伺服器-》目標伺服器 數據返回過程：目標伺服器-》代理伺服器-》瀏覽器

應用:

最經典的應用就是科學上網：我是一個國內用戶，我訪問不了google，但是我能訪問一個香港的某個代理伺服器。

這個香港的代理伺服器可以訪問google，於是我先把請求發送到那個代理伺服器，告訴他我需要訪問google，代理伺服器去取內容，最後返回給我。

就好比，大佬被抓起來坐牢了，不能出去買醬排骨，只好拜託小弟去買回來。

反向代理

百度百科的解釋如下：

反向代理(Reverse Proxy)方式是指以代理伺服器來接受internet上的連接請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連接的客戶端，此時代理伺服器對外就表現為一個反向代理伺服器。

數據流程：

數據請求過程：瀏覽器-》【反向代理伺服器-》處理數據的伺服器】 數據返回過程：【處理數據的伺服器-》反向代理伺服器】-》瀏覽器

通俗地說：

「瀏覽器」可以看作食客，「【反向代理伺服器-》處理數據的伺服器】」這一個整體可以看作飯店，其中「反向代理服務」相當於點單的服務員。「處理數據的伺服器」可以理解為是廚師。

「食客」向來到「飯店」向「服務員」點菜，但服務員並不會真正去做菜，他是下達命令讓「廚師」去做菜。 「廚師」把菜做好了給「服務員」，「服務員」再把菜端給「食客」。

在外部看來，「代理伺服器」和「處理數據的伺服器」是一個整體。就好比，食客只會去飯店吃飯，而不是去找廚師吃飯(即對於瀏覽器來說，到達反向代理伺服器已經完成任務了，後面的操作則由反向代理伺服器負責)。

具體飯店怎麼操作，對食客是透明的。有可能某個服務員即當伺服器也當廚師(即反向代理伺服器和處理數據的伺服器是同一台PC機)。

補充一下，沒有反向代理，就好比沒有了服務員，食客直接向廚師要吃的。譬如，你餓了，直接叫媽媽做飯是一樣的(少了下訂單的步驟)

比較

從用途上來講：

正向代理的典型用途是為在防火牆內的區域網客戶端提供訪問Internet的途徑。正向代理還可以使用緩衝特性減少網路使用率。 反向代理的典型用途是為後端的多台伺服器提供負載平衡，或為後端較慢的伺服器提供緩衝服務。

從安全性來講：

正向代理允許客戶端通過它訪問任意網站並且隱藏客戶端自身，因此你必須採取安全措施以確保僅為經過授權的客戶端提供服務。 反向代理對外都是透明的，訪問者並不知道自己訪問的是一個代理。

從使用方來看：

正向代理是瀏覽器端進行配置的，與伺服器端無關，甚至可以對服務端隱藏。 反向代理是伺服器端配置的，對瀏覽器端是透明的。

利用代理實現跨域

實現原理

對正向代理伺服器進行配置，當獲取非介面數據時，讓代理伺服器指向開發者本機的資源。當訪問介面時，訪問後端介面數據。

相當於大佬讓小弟把醬排骨飯裡面的飯和醬排骨分開買，飯自己家煮，醬排骨才去飯店買。

程序運行過程

瀏覽器訪問頁面，假設訪問淘寶頁面：taobao.com/index.html(假設這個頁面中調用了taobao.com/api/getNew獲取最新商品的介面) taobao.com/index.html請求經過代理伺服器，根據配置，index.html頁面請求127.0.0.1:3000 127.0.0.1:3000返回index.html文件給瀏覽器。 瀏覽器運行index.html頁面，發起taobao.com/api/etNew請求。 taobao.com/api/getNew請求經過代理伺服器，但由於沒有對這個介面進行特殊配置，會正常訪問淘寶伺服器中的介面。 淘寶伺服器接受到taobao.com/api/getNew請求，檢查請求頭的hosts欄位，發現是taobao.com，沒有跨域，將結果返回給代理伺服器。 代理伺服器拿到結果，返回給瀏覽器，瀏覽器進行解析顯示。

代理配置(以mac下的charles為例)

打開charles的映射關係表【charles->tool->Map Remote】。

點擊add可以添加映射關係。

注意：

匹配taobao.com/api/ 的配置項要放在匹配taobao.com/ 的配置項前，讓匹配API的優先順序更高。否則將只匹配到taobao.com/*的配置。 如果介面請求中，有涉及到https協議的，需要提前在電腦上安裝charles的證書 。 chrome系瀏覽器的請求是不經過charles代理的，這時需要設置電腦上的網路設置，設置代理地址為charles。

微信開發者工具是不走系統代理的，需要額外設置。【微信開發者工具-》設置-》代理-》指向代理伺服器】

利用反向代理實現跨域

反向代理需要用到nginx，其詳細介紹請看 http://www.nginx.cn/doc/http://www.nginx.cn/doc/

實現原理

原理大體相同，但是處理的端不同，反向代理實在伺服器端進行處理。首先修改hosts文件，將域名指向開發者的電腦本身，

把自己偽裝成服務端，再通過nginx對不同的請求進行轉發，把靜態資源指向開發者本地電腦的資源，將介面指向實際的伺服器。

相當於把飯店設置在了黑社會的樓下，去樓下買醬排骨飯的時候，飯店飯自己做，醬排骨則偷偷跑去別的飯店買。

代理配置

設置hosts文件，將目標域名指向本機。

編輯nginx配置，對不同的資源請求，指向到對應地址。同樣的，將靜態資源指向本機服務，將介面指向真正的伺服器。

程序運行過程

瀏覽器訪問頁面，假設訪問淘寶頁面：taobao.com/index.html taobao.com域名解析先經過hosts文件配置，發現taobao.com域名指向127.0.0.1，則向本機發起請求。 nginx接收到taobao.com/index.html請求，根據nginx的配置，將把這個請求轉發給127.0.0.1:3000。 瀏覽器拿到index.html文件，發起taobao.com/api/getNew請求 nginx接收到taobao.com/api/getNew請求請求，根據nginx的配置，將把這個請求轉發給真正的淘寶伺服器中。 淘寶伺服器將數據返回給nginx，再返回給瀏覽器執行。

簡單的對比

使用charles等正向代理方式比較簡單，需要掌握的知識點也比較少。但同時其可配置性較弱，更適合小型項目使用。 使用nginx的反向代理則相對複雜一些，需要了解基本的nginx配置。但其可配置性較強，支持URL的正則匹配，設置優先順序等，適合複雜的項目使用

點贊 0

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！