瀏覽器的“同源策略”固然保障了互聯網世界的數據隱私與數據安全，但是如果當我們需要使用AJAX跨域請求資源時，“同源策略”又會成為開發者的阻礙。在本文中，我們會簡單介紹需要跨域請求資源的兩種情景，然后，詳細解釋目前主流的四種跨域請求資源方案。
讓我們開始吧！
一、何時需要跨域
試想，當我們擁有多個站點，並且這些站點又經常共享相同的數據，那么為每個站點存儲一份數據看起來就蠢透了。更好的方案是，我們建設一台靜態資源存儲服務器，然后讓我們的所有站點都從這一台服務器上獲取資源。很理想的方案，但是現實中，我們首要解決的問題便是瀏覽器的“同源策略”，別忘了，不同域之間無法通過AJAX技術獲取資源。這是需要跨域獲取資源的主要情景。
另外，站在互聯網“開放，平等，自由”精神的角度上講，如果所有人的數據都被設置為只有同域才能訪問，那么互聯網世界未免也太無聊了，如果我就是想要與更多的人分享我的數據，難道不應該有辦法讓我做到這一點嗎？
當然有辦法，下面我們就將一一解釋當下主流的跨域請求資源方式。
二、跨域請求資源方案
我們將主要介紹以下四種跨域請求資源的方案，並逐一解釋他們的原理，實用方式以及優缺點，希望你和我一樣有耐心，耐心總是能帶來回報：
- 野路子出身卻好用的方式：JSONP；
- 官方推薦的跨域資源共享方案：CORS；
- 使用HTML5 API：postMessage；
- 拋棄HTTP，使用：Web Sockets；
在開始下面的內容之前，我們首先需要強調一點，無論是怎樣的跨域資源獲取方案，本質上都需要服務器端的支持。跨域獲取資源之所以能夠成功，本質是服務器默許了你有權限獲取相應資源。下面我們所運用的種種方式，實際上是客戶端和服務端互相配合，繞過同源策略進行數據交互的工作，千萬不要誤以為掌握了下述技術后，我們就能成為一個黑客 🤷🏿♂️。
（一）野路子出身卻異常好用的方式：JSONP
正如標題所描述的那樣，JSONP技術是早期某個(些?)聰明的程序員發明的跨域資源獲取方式，由於該技術的簡單易用，逐漸變得越來越流行，最終成為經典的跨域獲取資源方案。
JSONP是“JSON with padding”的簡寫，我將其翻譯為“被包裹的JSON”，當你看完這個章節，你一定會覺得這個名字相當貼切。
讓我們模擬一下當初想到JSONP技術的高手程序員是如何推理的：
首先，我們應該清楚的認識到，瀏覽器的“同源策略”只是阻止了通過AJAX技術跨域獲取資源，而並沒有禁止跨域獲取資源這件事本身，正因如此，我們可以通過<link>標簽，<img>標簽以及<script>標簽中的href屬性或src屬性獲取異域的CSS，JS資源和圖片（雖然我們其實並不能讀取這些資源的內容）。
其次，我們知道（也許你不知道，但是，還記得嗎，我在模擬那個高手程序員？）<script>標簽通過src屬性加載的JS資源，實際上只是將JS文件內容原封不動的放置在<scritp>的標簽內，並沒有什么神奇之處！
也就是說，如果我們的sayHi.js文件只有這樣一段代碼:
// sayHi.js
alert('Hi')
當我們在HTML文件中，成功加載sayHi.js文件時，瀏覽器只不過是做了如下操作：
<!-- 加載前 -->
<script src="sayHi.js"></script>
<!-- 加載后 （為了方便閱讀，我格式化了代碼）-->
<script src="sayHi.js">
alert('Hi')
</script>
這意味着什么呢？這意味着被加載的文件與HTML文件下的其他JS文件共享一個全局作用域。也就是說，<scritp>標簽加載到的資源是可以被全局作用域下的函數所使用的！
但是慢着！如果<script>標簽加載到的一些數據並不符合JavaScript語法規定的數據類型，JavaScript就無法處理這些錯誤不是嗎？而且就算數據類型正常了，我們還應該將數據存儲於一個變量內，然后調用這個變量...
說的沒錯！不過我們其實已經離正確答案很近了。
還記的我們這一方案的名稱嗎？JSONP！，也就是說我們已經約定好了數據的格式為JSON，這是JavaScript可以處理的數據類型，並且JSON格式的數據可以承載大量信息。那么有關變量的問題呢？這個回答則更巧妙些，因為我們會通過向服務器傳入一個函數的方式，將數據變為函數的參數，讓我們直接看看JSONP的使用方式：
1. function handleResponse(response) {
2. alert(`You get the data : ${response}`)
3. }
4. const script = document.createElement('script')
5. script.src = 'http://somesite.com/json/?callback=handleResponse'
6. document.body.insertBefore(script, document.body.firstChild)
很容易看到，我們在1-3行中創建了一個函數，該函數用來處理我們將要獲得的數據，該函數的參數response即是服務器響應的數據。在4-6行中我們所做的是利用JavaScript動態生成一個script標簽，並將其插入HTML文檔。但是注意第5行我們制定的src值，在URL末尾，我們有這樣一段查詢參數callback=handleResponse，callback的值正是我們先前創建的函數。
事情開始變得有些令人困惑了，究竟發生了什么呢？我們如何通過上述代碼最終實現跨域獲取資源？
答案就藏在服務端的代碼中，當服務端支持JSONP技術時，會做如下一些設置：
- 識別請求的URL，提取callback參數的值，並動態生成一個執行該參數值（一個函數）的JavaScript語句；
- 將需要返回的數據放入動態生成的函數中，等待其加在到頁面時被執行；
此時該文件內容看起來就像這樣：
handleResponse(response) // response為被請求的JSON格式的數據
因此，當資源加載到位，內容顯示在script標簽內時，瀏覽器引擎會執行這條語句，我們想要的數據就可以被我們以任何想要的方式處理了。真不可思議！
你現在知道為什么這項技術被命名為JSONP了吧？那個“padding”指的就是我們的“callback”函數，真是恰如其名。
最后，我們還要對JSONP技術再強調兩點：
- JSONP技術與AJAX技術無關：雖然同樣牽扯到跨域獲取資源這個主題，但我們應該已經清楚的看到，JSONP的本質是繞過AJAX獲取資源的機制，使用原始的
src屬性獲取異域資源； - JSONP技術存在一下三點缺陷：
- 無法發送POST請求，也就是說JSONP技術只能用於請求異域資源，無法上傳數據或修改異域數據；
- 無法監測JSONP請求是否失敗；
- 可能存在安全隱患：別忘了，JSONP之所以能成功獲取異域服務器資源，靠的是服務器動態生成了回調函數，並在頁面中執行，那么如果服務器在原有的回調函數下再添加些別的惡意JavaScript代碼會怎樣？當然也會被執行！所以在使用JSONP技術時，一定要確保請求資源的服務器是值得信賴的；
雖然存在一些缺陷，但JSONP的瀏覽器兼容性卻是非常好的，可以說是一種非常小巧高效的跨域資源獲取技術。
（二）官方推薦的跨域資源共享方案：CORS
CORS是W3C頒布的一個瀏覽器技術規范，其全稱為“跨域資源共享”（Cross-origin resource sharing），它的意義在於，它是由W3C官方推廣的允許通過AJAX技術跨域獲取資源的規范，因此相較於JSONP而言，功能更加強大，使用起來也沒有了hack的味道。
關於CORS的具體細節，我建議你可以移步阮一峰的同主題博客閱讀，我認為該文章已經將這個主題講解的十分透徹了。
你當然也可以選擇繼續向下閱讀，看看我是怎樣理解CORS技術並重新梳理CORS技術相關知識的，希望也能給你帶來幫助。
我們之前提到過，如果想要繞過瀏覽器“同源策略”，實現使用AJAX技術跨域獲取資源，需要服務端和客戶端的協同合作。而對於CORS標准而言，實現AJAX跨域獲取資源，重點還在於服務器端返回的響應是否清楚的告知了瀏覽器此次跨域AJAX請求的合法性。
那么？服務器端該如何向瀏覽器傳達這一信息呢？答案是要看AJAX請求的復雜程度，也就是說，對於簡單的AJAX請求，服務器要向瀏覽器做出的“說明”就少，而如果是復雜的AJAX，服務器則要向瀏覽器多“解釋”幾句。
那么，如何區分AJAX請求的復雜度呢，標准在於簡單的AJAX請求只符合下面兩個條件：
- 請求方法只屬於HEAD，GET，POST請求的其中一種；
- HTTP的頭信息只限於以下字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type（只能為
application/x-www-form-urlencoded，multipart/form-data和text/plain其中一種）
而當瀏覽器檢測到一個簡單的跨域AJAX請求，瀏覽器會首先為我們添加一個頭部信息：Origin它的值為請求發送代碼所在的源（希望你還記得，一個源由“協議”，“域名和端口”組成）。類似這樣：
GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0 ...
而當這樣的一條HTTP請求發送到服務端時，服務端會檢測該請求報頭中的Origin字段的值是否在許可范圍內，如果的確是服務端認可的域，那么服務端會在響應報文中添加如下字段：
Access-Control-Allow-Origin（必須）：該字段用來告知瀏覽器服務端接受的能夠發送跨域AJAX請求的域，它的值要么是該次AJAX請求報頭中由瀏覽器自動添加的Origin值，要么還可以是一個*號，表示可以接受任意的域名請求；Access-Control-Allow-Credentials（可選）：該字段用來告知瀏覽器是否允許客戶端向服務端發送Cookie。默認情況下，CORS規范會阻止跨域AJAX向服務端發送Cookie，因此該字段默認值為false，當你顯式的將該字段值設置為true時，則表示允許此次跨域AJAX向服務端發送Cookie。Access-Control-Expose-Headers（可選）：該字段用來向客戶端暴露可獲取的響應頭；
CORS規范規定，客戶端XMLHttpRequest對象的getResponseHeader()方法只能拿到6個基本的字段：
* Cache-Control：表示響應遵循的緩存機制；
* Content-Language：表示響應體的語言；
* Content-Type：表示響應體的MIME類型；
* Expires：表示文檔的過期時間，到期不再緩存；
* Last-Modified：表示文檔的最后改動時間；
* Pragma：用來包含特定的指令；
但是當客戶端想要獲取額外的響應頭字段時，就需要服務端通過在該字段后定義相應的客戶端可獲取的響應頭字段名稱。
以上就是簡單跨域AJAX請求，客戶端與服務端的交互，在繼續介紹復雜的跨域AJAX請求前，讓我們先停一停，回過頭來看看響應報頭的Access-Control-Allow-Origin字段，談一談CORS規范中為什么默認不允許跨域AJAX請求攜帶Cookie，以及如果客戶端需要傳送Cookie時，客戶端與服務端又該如何交互的問題。
首先，我們要知道，在客戶端與服務端數據傳輸的過程中，Cookie一直是以明文的形式伴隨着數據的傳輸，只要客戶端發送了Cookie至服務端，服務端就會至少返回該段Cookie。而我們又提到過，大多數網站都使用Cookie短暫存儲用戶會話中的身份信息，因此將Cookie暴露在外是存在安全隱患的，CSRF攻擊的目的便是獲取用戶的Cookie信息，因此在跨域AJAX請求中，為了減少Cookie泄露的風險，CORS規范默認禁止跨域AJAX請求攜帶Cookie。
那么如果客戶端實在需要攜帶Cookie信息怎么辦呢？正如上文提到過的，需要客戶端與服務端一起配合，讓我們看看具體細節：
- 首先是客戶端：
開發者需要在創建XMLHttpRequest對象實例時，手動配置withCredentials屬性，將其值設置為true：
var xhr = new XMLHttpRequest()
xhr.withCredentials = true
某些瀏覽器會默認允許在跨域AJAX請求中發送Cookie，此時如果不想要發送Cookie，你只需要將其值設置為false。
- 其次是服務端：
對於服務端而言，除了像之前提到的要在響應報頭設置Access-Control-Allow-Credential字段的值為true之外，還需要為Access-Control-Allow-Origin字段設置一個明確的域，不可以再使用*號。
相信你也能明白，這一切都是為了保護客戶端與服務端Cookie的隱私和安全。
現在我們可以繼續我們的主題，一起看一看如果我們的跨域AJAX請求超出了“簡單”的標准，客戶端與服務端又應該如何相互配合，實現跨域的資源共享。
與簡單AJAX跨域請求不同，“復雜“的AJAX跨域請求一共會發送兩次HTTP請求，其中第一次為”查詢請求“，第二次才是我們正式的”AJAX跨域請求“。為什么多出了一次”查詢請求“呢？道理其實很簡單，我們想象一下當發送”復雜“的AJAX跨域請求時，瀏覽器最先拿到請求開始識別，然后發現這個請求並不“單純”（不滿足簡單跨域AJAX請求標准），於是感到十分疑惑的瀏覽器會試探的沿着請求的地址向服務端發問，詢問服務端是否允許異域的客戶端向它發送額外的請求信息，這一次“發問”，即是第一次HTTP請求，即“查詢請求”。而服務端當然也會這次“發問”給出相應的回答，然后瀏覽器就會根據回答的結果決定是否繼續發送該跨域AJAX請求。
讓我們看看具體的實現細節：
首先，讓我們創造出一個“復雜”的AJAX跨域請求：
var url = 'http://another.com/cors'
var xhr = new XMLHttpRequest()
xhr.open('put', url, true) // 這里我們設置請求的方式為'put'
xhr.setRequestHeader('X-Custom-Header', 'Value') // 這里我們自定義了一個請求頭字段
xhr.send()
當瀏覽器識別到該請求“並不簡單”時，就會自動向服務其發送一個“查詢請求”，其報頭信息大致如下：
OPTIONS /cors HTTP/1.1
Origin: http://thisOne.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: another.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
注意這次“查詢請求”使用了“OPTIONS”的請求方法，表明了這是一個查詢請求。請求頭部的信息說明了請求來源的域，請求使用的HTTP方法以及請求額外發送的頭部字段。
讓我們再轉換至服務器視角，當服務端接收到瀏覽器發來的這樣一個查詢請求后，就可以判斷出是否應該接收該請求。如果想要向瀏覽器表示允許該請求，則會返回這樣的響應報文：
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61（Unix）
Access-Control-Allow-Origin: http://thisOne.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header // 該字段值為以“,”號分割的字符串
Content-type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
讀到這里我們已經大概猜的出服務端向瀏覽器傳遞的信息了：
- 首先，
Access-Control-Allow-Origin字段向瀏覽器說明了發起AJAX請求的域是被服務器認可的（注意這個字段的值也可以為一個“*”號）； - 其次，
Access-Control-Allow-Methods字段向瀏覽器說明了服務器接收跨域AJAX的請求方式； - 最后，
Access-Control-Allow-Headers字段向瀏覽器說明了服務器允許跨域AJAX額外發送的報頭信息；
當瀏覽器收到服務端這樣的表示同意請求的響應后，就會正常發送接下來的跨域AJAX請求，而服務器也會正常的回應。值的一提的是，在服務端與客戶端整個跨域AJAX請求的交互中，Access-Control-Allow-Origin頭信息自始至終都是必須攜帶的。
而當服務器在檢查“查詢請求”后，如果不同該請求，則會返回一個正常的HTTP響應，報文中包含任何與CORS規范有關的報頭字段，此時，瀏覽器就會心領神會的明白服務器拒絕接收發出的跨域AJAX請求，因此會返回一個錯誤狀態（可以被XML對象實例使用onerror回調函數捕獲）並在控制台打印一條錯誤信息：
XMLHttpRequest cannot load http://another.com
Origin http://thisOne.com is not allowed by Access-Control-Allow-Origin
至此，無論是“簡單”的跨域AJAX請求還是“復雜”的跨域AJAX請求，我們都已經清楚的知曉了他們的運作原理，這真是件了不起的事情。但是先別着急慶祝，我們剛才還遺漏了一個話題沒有談到：“節約復雜AJAX跨域請求的HTTP請求數”。
相信你還記的，對於“復雜”的跨域AJAX請求，瀏覽器會向服務器發送兩次HTTP請求，雖然實際上兩次HTTP請求與一次HTTP請求所耗費的時間幾乎難以感知，但是如果我們有辦法一次搞定，又為什么還要重復做兩次呢？
對於服務器而言，“一次搞定”的方法就在於，在瀏覽器第一次發送復雜的跨域AJAX查詢請求時，在響應報頭中添加Access-Control-Max-Age字段，這是一個可選的字段，它用來指定本次查詢請求的有效期，單位為秒。也就是說，通過該字段，服務器擁有了告知瀏覽器“這個請求我批准了，X秒以內不需要再向我確認”的能力。至此，我們成功的將接下來的跨域請求數由兩次節約為一次！
三、小結
一口氣看到這里？真不容易！ 希望這是值得的，讓我們總結一下我們在本文中都談到了些什么。首先，我們談到了我們何時需要發起跨域AJAX請求的問題，做到了“知其然”。其次，我們深入探討了使用JSONP技術和CORS規范實現發送跨域AJAX請求的細節，成功達到了我們“知其所以然”的目標。相信現在的你已經對向他人談論“跨域”這個主題充滿自信。真的很棒對吧？
如果你依然覺得意猶未盡，不妨接着和我繼續深入這個主題，看看實現跨域共享資源的另外兩種“時髦”的方式：使用 postMessage 和 webSocket。
感興趣嗎？休息一下，然后再回來，目前為止你表現的都非常出色！🙌。