摘要：常見的有等協(xié)議如，其中是頂級(jí)域名，是主域名，是子域名。就是利用標(biāo)簽的跨域功能來實(shí)現(xiàn)跨域拉取數(shù)據(jù)的。子框架加載的是你自己可控的頁面，這時(shí)候可以分兩種情況主域相同，子域不同可以通過在和父頁面里都設(shè)置主域名來實(shí)現(xiàn)跨域通信。

http: //zt.jd.com:80/cgi-bin/popuser_menu?tag=4#eduTop
這是一個(gè)普通的URL，格式：protocol :// hostname[:port] / path / [?query]#fragment
關(guān)系對(duì)應(yīng)如下圖：

在瀏覽器里有一個(gè)策略--同源策略--即只有同源的文件之間才能互相通信，否則就會(huì)被瀏覽器拒絕。如下圖，在www.jd.com下面的頁面想請(qǐng)求zt.jd.com頁面時(shí)是被拒絕的。

那什么是同源，同源就是相同的來源，只有這些資源都來自相同的地方，它們之間才能通信，否則就可能存在安全和隱私問題。通常情況下，同源也叫同域，因?yàn)榕袛嗤吹姆绞骄褪潜葘?duì)“協(xié)議+域名+端口“是否一致。

protocol： 常見的有http, https, ftp等協(xié)議

host: 如zt.jd.com,，其中com是頂級(jí)域名，jd是主域名，zt是子域名。因此zt.jd.com和www.jd.com是不同源的，m.zt.jd.com和zt.jd.com也是不同源的。

port: 80, 8080等，url不加端口號(hào)時(shí)默認(rèn)為80端口，因此對(duì)于http ://zt.jd.com和http ://zt.jd.com:80是同源的，而很明顯http ://zt.jd.com和http ://zt.jd.com:8080則是不同源。

對(duì)于http ://store.company.com/dir/page.html這個(gè)URL來說，MDN上有這樣的描述，基本可以很清晰的說明什么是同源了：

對(duì)于XMLHttpRequest對(duì)象，是不支持跨域操作的，你沒辦法在www.jd.com下通過ajax去調(diào)用zt.jd.com下的接口，瀏覽器會(huì)把請(qǐng)求給拒絕掉。
那瀏覽器到底是拒絕發(fā)請(qǐng)求呢？還是拒絕接受響應(yīng)呢？我們看一下network：

很明顯請(qǐng)求是發(fā)出去的，而且響應(yīng)了200 ok。只是響應(yīng)內(nèi)容被瀏覽器屏蔽了，js也無法讀取到。fiddler里面可以看到響應(yīng)的內(nèi)容：

那為什么瀏覽器不直接把請(qǐng)求丟掉，而是在響應(yīng)的時(shí)候屏蔽掉呢？因?yàn)樵瓌t上來講如果服務(wù)器允許，客戶端沒理由阻止跨域，因此客戶端必須確認(rèn)服務(wù)器并沒有允許當(dāng)前域的跨域訪問時(shí)才能丟掉這個(gè)請(qǐng)求，這就涉及到CORS。
在XMLHttpRequest2里，可以通過服務(wù)器設(shè)置Access-control-allow-origin響應(yīng)頭部字段來告訴瀏覽器允許ajax跨域。如下圖，在zt.jd.com下用ajax調(diào)用xoa.pp.jd.com下的接口，成功跨域調(diào)用。

但畢竟是HTML5的新特性，瀏覽器端的兼容性并不好，因此，目前很少使用這種方式。更多的使用JSONP。

我們知道在HTML標(biāo)簽里，有一些特殊的標(biāo)簽是可以跨域的，比如script, link, img之類的，這些標(biāo)簽可以提供給我們主動(dòng)調(diào)用第三方資源的能力，方便web開發(fā)。由于調(diào)用資源的主動(dòng)權(quán)在你自己手里，因此只要你調(diào)用自己可信任的資源，不會(huì)有什么安全性問題。JSONP就是利用script標(biāo)簽的跨域功能來實(shí)現(xiàn)跨域拉取數(shù)據(jù)的。 我們來看script標(biāo)簽的特殊之處在哪里。 通常情況下，script標(biāo)簽是這樣用的：

還有這樣用的：

也就是說script既可以拉取數(shù)據(jù)，也可以執(zhí)行代碼。那假如，我們用它來拉取一個(gè)跨域的接口，我們?cè)鯓硬拍馨呀涌诜祷氐臄?shù)據(jù)拿來用呢？很明顯，那就是讓接口在返回?cái)?shù)據(jù)的同時(shí)，還要返回操作這些數(shù)據(jù)的js代碼。比如：

但是這種方式存在兩個(gè)弊端：依賴問題和阻塞問題。你必須確保那個(gè)拉取數(shù)據(jù)的script標(biāo)簽是先執(zhí)行了，而后面的代碼必須等它執(zhí)行完才能執(zhí)行。那么，就使用異步回調(diào)唄。如下：

先定義一個(gè)回調(diào)函數(shù)，然后把拉取數(shù)據(jù)的script標(biāo)簽改為異步拉取。這樣拉取成功后會(huì)調(diào)用定義好的回調(diào)函數(shù)來進(jìn)行數(shù)據(jù)處理。這樣就不用理會(huì)依賴問題，script標(biāo)簽可以不考慮先后順序，因?yàn)楫惒奖仨氃谕酱a完成后才執(zhí)行。但是，這樣還存在一個(gè)問題，那就是接口通用性受到了限制，因?yàn)楸仨毞祷匾痪鋵懰赖膔enderData(data)代碼，拉取這個(gè)接口的頁面總是必須定義一個(gè)叫做renderData的函數(shù)。于是，聰明的人又想到了解決辦法，那就是用傳參的方式告訴接口給我返回什么回調(diào)函數(shù)，這樣我想定義一個(gè)renderData1也行，renderData2也行，接口的通用性就大大提高了。如下：

接口讀出參數(shù)callback，并把它返回即可。這樣我傳給接口render1它就返回render1，render2就返回render2。

這就是JSONP，一般會(huì)封裝成一個(gè)類似于ajax的函數(shù)，直接傳參即可動(dòng)態(tài)創(chuàng)建script標(biāo)簽實(shí)現(xiàn)跨域請(qǐng)求。但是，這里有必要說明一點(diǎn)，JSONP接口通過CSRF很容易被惡意拉取到敏感信息，你可以構(gòu)造頁面讓目標(biāo)用戶打開，因?yàn)閏allback的存在，你能將拉取到的用戶信息上傳到自己的服務(wù)器，因此需做好防范。

iframe是一個(gè)特殊的標(biāo)簽，可以在頁面里面加載別的頁面。
既然有加載別的頁面的能力，那在非同源下必定是要受到同源策略限制的，否則，我們就能隨便讀取任意網(wǎng)站的cookie了。

非同源情況下，默認(rèn)是阻止父框架與子框架之間的通信的，但可以分為兩種情況：

子框架加載的URL是一個(gè)第三方頁面時(shí)：你能做的僅僅就是把它展現(xiàn)出來，而沒有任何能力去訪問它。

子框架加載的URL是你自己可控的頁面，這時(shí)候可以分兩種情況：

主域相同，子域不同：可以通過在iframe和父頁面里都設(shè)置document.domain=主域名來實(shí)現(xiàn)跨域通信。

主域不同：這種情況只能通過一些奇淫異巧來實(shí)現(xiàn)簡(jiǎn)單的通信。有兩種情況：

父框架向子框架通信：父框架通過改變iframe的src的hash值，iframe監(jiān)聽自身location.hash即可獲取到父框架設(shè)置的參數(shù)，從而實(shí)現(xiàn)信息的傳遞。但數(shù)據(jù)量收到url長度的限制。

子框架向父框架通信：大家或許會(huì)想那直接逆向一下設(shè)置location.hash不就行了嗎。事實(shí)上是不行的，在iframe里設(shè)置location.hash是無法更新到iframe的src值的。因此，還得再嵌入一個(gè)跟父框架同源的iframe到子框架里，然后通過“父框架向子框架通信”的方式讓子框架傳遞信息給“孫框架"，然后父框架再去讀”孫框架“就行了。

同源情況下，無需設(shè)置即可雙向通信。但是，假如父頁面和子頁面任何一方設(shè)置了document.domain，都會(huì)導(dǎo)致瀏覽器的跨域攔截，即使document.domain就是當(dāng)前的domain也不行。也就是說，要么都不設(shè)置，要么都設(shè)置。