關於跨域的總結

關於跨域，我的總結了如下幾種方法

• JSONP
• CORS
• WebSocket
• document.domain
• window.name
• location.hash
• postMessage

其中：CORS、jsonp等方法經常使用，window.name的方法既不復雜，也能兼容到幾乎全部瀏覽器，這真是極好的一種跨域方法。

---

webSocket

WebSocket是一種在單個TCP鏈接上進行全雙工通信的協議。WebSocket與HTTP協議其實二者的關係像是兩兄弟，各自有着各自擅長的領域，並且時不時還一同協做解決難題。
WebSocket要解決的問題：當服務器資源到位時，可以主動通知瀏覽器並返回相應資源。HTML5標準推出了WebSocket協議。
自己就不受瀏覽器「同源策略」的限制，WebSocket協議下的通信機制，客戶端和服務端一旦創建鏈接，就能夠順暢的互發數據，所以WebSocket協議自己就是「有狀態的」，不須要Cookie的幫忙，既然沒有Cookie，天然也不須要「同源策略」去保護。
下面來講說webSocket的具體實現：
像發起AJAX請求同樣，發起WebSocket請求須要藉助瀏覽器提供的WebSocket對象，該對象提供了用於建立和管理WebSocket鏈接，以及經過該鏈接收發數據的API。全部的瀏覽器都默認提供了WebSocket對象。讓咱們看看該對象的用法：

和使用XHRHttpRequest對象同樣，咱們首先要實例化一個WebSocket對象：

傳入的參數爲響應WebSocket請求的地址。

一樣相似AJAX的是，WebSocket對象也有一個readyState屬性，用來表示對象實例當前所處的連接狀態，有四個值：

0：表示正在鏈接中（CONNECTING）；
1：表示鏈接成功，能夠通訊（OPEN）；
2：表示鏈接正在關閉（CLOSING）；
3：表示鏈接已經關閉或打開鏈接失敗（CLOSED）；
咱們能夠經過判斷這個值來執行咱們相應的代碼。

除此以外，WebSocket對象還提供給咱們一系列事件屬性，使咱們控制鏈接過程當中的通訊行爲：

onopen：用於指定鏈接成功後的回調函數；
onclose：用於指定鏈接關閉後的回調函數；
onmessage：用於指定收到服務器數據後的回調函數；
onerror：用於指定報錯時的回調函數；
經過.send()方法，咱們擁有了向服務器發送數據的能力（WebSocket還容許咱們發送二進制數據）。

如何知道什麼時候咱們的數據發送完畢呢？咱們須要使用WebSocket對象的bufferedAmount屬性，該屬性的返回值表示了還有多少字節的二進制數據沒有發送出去，因此咱們能夠經過判斷該值是否爲0而肯定數據是否發送結束。

---

CORS

阮一峯博客http://www.ruanyifeng.com/blo...
在http header中寫入容許訪問的域名。
Access-Control-Allow-Origin，該字段是必須的。它的值要麼是請求時Origin字段的值，要麼是一個*，表示接受任意域名的請求。
須要注意的是：CORS請求默認狀況下是不會發送cookie的，因此須要在服務器的響應中設置：
Access-Control-Allow-Credentials: true
除此以外，還須要在AJAX請求中設置：
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
CORS請求分爲簡單請求和非簡單請求：
簡單請求：須要AJAX裏的onerrer回調函數進行捕獲，由於也可能會返回200。
非簡單請求：瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可使用哪些HTTP動詞和頭信息字段。只有獲得確定答覆，瀏覽器纔會發出正式的XMLHttpRequest請求，不然就報錯。
會首先發送一個預檢請求，請求方法爲：options，而且在請求頭中會包含相應字段：
Access-Control-Request-Method
Access-Control-Request-Headers
若是響應頭中有CORS相關字段：
Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
瀏覽器檢查響應頭中包含這三個字段，則預檢請求成功；不然，則會拋出錯誤。一旦服務器經過了"預檢"請求，之後每次瀏覽器正常的CORS請求，就都跟簡單請求同樣，會有一個Origin頭信息字段。服務器的迴應，也都會有一個Access-Control-Allow-Origin頭信息字段。

---

JSONP

1. 咱們發現，Web頁面上調用js文件時則不受是否跨域的影響（不只如此，咱們還發現凡是擁有」src」這個屬性的標籤都擁有跨域的能力，好比<script>、<img>、<iframe>）；
2. 因而能夠判斷，當前階段若是想經過純web端（ActiveX控件、服務端代理、屬於將來的HTML5之Websocket等方式不算）跨域訪問數據就只有一種可能，那就是在遠程服務器上設法把數據裝進js格式的文件裏，供客戶端調用和進一步處理；
3. 恰巧咱們已經知道有一種叫作JSON的純字符數據格式能夠簡潔的描述複雜數據，更妙的是JSON還被js原生支持，因此在客戶端幾乎能夠爲所欲爲的處理這種格式的數據；
4. 這樣子解決方案就呼之欲出了，web客戶端經過與調用腳本如出一轍的方式，來調用跨域服務器上動態生成的js格式文件（通常以JSON爲後綴），顯而易見，服務器之因此要動態生成JSON文件，目的就在於把客戶端須要的數據裝入進去。
5. 、客戶端在對JSON文件調用成功以後，也就得到了本身所需的數據，剩下的就是按照本身需求進行處理和展示了，這種獲取遠程數據的方式看起來很是像AJAX，但其實並不同。
6. 爲了便於客戶端使用數據，逐漸造成了一種非正式傳輸協議，人們把它稱做JSONP，該協議的一個要點就是容許用戶傳遞一個callback參數給服務端，而後服務端返回數據時會將這個callback參數做爲函數名來包裹住JSON數據，這樣客戶端就能夠隨意定製本身的函數來自動處理返回數據了。

document.domain

這個主要針對跨域訪問cookie的狀況
兩個網頁一級域名相同，只是二級域名不一樣，瀏覽器容許經過設置document.domain共享 Cookie。
舉例來講，A網頁是http://w1.example.com/a.html，B網頁是http://w2.example.com/b.html，那麼只要設置相同的document.domain，兩個網頁就能夠共享Cookie。其實也能夠在服務器端進行設置：指定Cookie的所屬域名爲一級域名，好比.example.com。Set-Cookie: key=value; domain=.example.com; path=/這樣二級域名和三級域名不用作任何設置均可以共享這個cookie。未完待續。。。