成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

再也不學(xué)AJAX了?。ㄈ┛缬颢@取資源 ③ - WebSocket & postMessag

liangzai_cool / 2698人閱讀

摘要:一基于維基百科的定義,是一種在單個(gè)連接上進(jìn)行全雙工通訊的協(xié)議。讓我們看看這個(gè)模型的具體實(shí)現(xiàn)下面是客戶端告知服務(wù)端要升級(jí)為協(xié)議的報(bào)頭下面是服務(wù)端向客戶端返回的響應(yīng)報(bào)頭想知道這些報(bào)頭中的字段中代表什么可以參考維基百科下的說明。

讓我們先簡(jiǎn)單回顧一下之前談到的內(nèi)容,AJAX是一種無頁面刷新的獲取服務(wù)器資源的混合技術(shù)。而基于瀏覽器的“同源策略”,不同“域”之間不可以發(fā)送AJAX請(qǐng)求。但是在某些情境下,我們需要“跨域獲取資源”,為了滿足這一需求,我們可以使用“JSONP”與“CORS”兩種技術(shù)。

現(xiàn)在,我們將要簡(jiǎn)要了解“跨域共享資源”的另外兩種方式:WebSocket 和 postMessage。讓我們先大概看看他們是什么,以及究竟是基于怎樣的原理,滿足了我們的需求 - “跨域獲取資源”。

一、WebSocket

基于維基百科的定義,WebSocket是一種在單個(gè)TCP連接上進(jìn)行全雙工通訊的協(xié)議。在這里我并不打算解釋“TCP連接”和“全雙工通訊”這兩個(gè)專業(yè)術(shù)語(這樣做會(huì)讓這篇文章變得很長(zhǎng),而且也偏離了我們的主題),讓我們聚焦這段定義的最后兩個(gè)字協(xié)議。

說到協(xié)議,你是否聯(lián)想到“HTTP協(xié)議”?沒錯(cuò),HTML5標(biāo)準(zhǔn)之所以提出了一種新的互聯(lián)網(wǎng)通信協(xié)議 - WebSocket,就是為了彌補(bǔ)在某些情景下使用HTTP協(xié)議通信的一些不足。但是注意,這并不意味WebSocket協(xié)議就可以完全取代HTTP協(xié)議了,其實(shí)兩者的關(guān)系更像是兩兄弟,各自有著各自擅長(zhǎng)的領(lǐng)域,而且時(shí)不時(shí)還一同協(xié)作解決難題。

那么上面提到的某些情景具體是指什么呢?答案是“服務(wù)端與客戶端的雙向通信”。我們知道,當(dāng)我們使用HTTP協(xié)議時(shí),客戶端與服務(wù)端的通信模式始終是由客戶端向服務(wù)端發(fā)送請(qǐng)求,服務(wù)端只負(fù)責(zé)驗(yàn)證請(qǐng)求并返回響應(yīng)。

我們可以這樣想象,在HTTP協(xié)議下,服務(wù)端扮演著“守門人”的角色,而客戶端則是一個(gè)郵局,它每發(fā)送一個(gè)請(qǐng)求就像是委托一個(gè)信使攜帶一封信(信里注明自己的身份和需要獲取資源的名稱)到服務(wù)端,當(dāng)信使到達(dá)時(shí),“守門人”會(huì)拆開信封,檢查里面的身份信息,如果身份合法則打開資源寶庫的大門,將相應(yīng)的資源交給信使,令其返回給客戶端。

在這個(gè)故事里,服務(wù)端的角色有些枯燥呆板對(duì)吧?不僅如此,故事中服務(wù)端扮演的“守門人”角色還患有嚴(yán)重的臉盲癥,在工作中他只“認(rèn)信不認(rèn)人”,也就是說客戶端發(fā)送的每一個(gè)請(qǐng)求,對(duì)于服務(wù)而言都是全新的,守門人不會(huì)因?yàn)樾攀股洗蝸磉^,或是收到兩次相同的信而覺得眼熟,對(duì)信使有額外的寒暄。這也就是為什么我們說HTTP協(xié)議是“無狀態(tài)的”。乍看起來,這似乎有些不合理,但是這種設(shè)計(jì)卻使服務(wù)器的工作變得簡(jiǎn)單可控,提升了服務(wù)器的工作效率。

但是這樣的設(shè)計(jì)仍然存在兩個(gè)問題:

每一個(gè)請(qǐng)求都需要身份驗(yàn)證,這對(duì)于用戶而言意味著需要在每一次發(fā)送請(qǐng)求時(shí)輸入身份信息;

當(dāng)客戶端所請(qǐng)求的資源是動(dòng)態(tài)生成的時(shí),客戶端無法在資源生成時(shí)得到通知(還記得吧,服務(wù)器只是一個(gè)原地不動(dòng)的“守門人”);

如何解決這兩個(gè)問題呢?對(duì)于前者,答案是使用“Cookie”,而對(duì)于后者,則輪到我們今天的主角“WebSocket”大顯身手。

在討論WebSocket之前,讓我們先稍微繞點(diǎn)路,談?wù)劇癈ookie”是如何解決“每一個(gè)請(qǐng)求都需要身份驗(yàn)證”的問題的。

(一)為HTTP協(xié)議添加狀態(tài) - Cookie

我們之前提到,HTTP協(xié)議下,客戶端與服務(wù)端的通信是“無狀態(tài)”的,也就是說,如果服務(wù)器中的某部分資源是由某個(gè)客戶專屬的,那么每當(dāng)這個(gè)客戶想要獲取資源時(shí),都需要首先在瀏覽器中輸入賬號(hào)密碼,然后再發(fā)送請(qǐng)求,并在被服務(wù)器識(shí)別身份信息成功后獲取請(qǐng)求的資源。我們當(dāng)然不想每次發(fā)送一個(gè)請(qǐng)求都要輸入一遍賬號(hào)密碼,因此我們需要Cookie,這個(gè)既可以存儲(chǔ)在瀏覽器,又會(huì)被瀏覽器發(fā)送HTTP請(qǐng)求時(shí)默認(rèn)發(fā)送至服務(wù)端,并且還受瀏覽器“同源策略”保護(hù)的東西幫助我們提高發(fā)起一次請(qǐng)求的效率。

在有了Cookie之后,我們可以在一次會(huì)話中(從用戶登錄到瀏覽器關(guān)閉)只輸入一次賬號(hào)密碼,然后將其保存在Cookie中,在整個(gè)會(huì)話期間,Cookie都會(huì)伴隨著HTTP請(qǐng)求的發(fā)送被服務(wù)器識(shí)別,從而避免了我們重復(fù)的輸入身份信息。

不僅如此,基于Cookie的特性:可以保存在瀏覽器內(nèi),還會(huì)在瀏覽器發(fā)送HTTP請(qǐng)求時(shí)默認(rèn)攜帶,服務(wù)端也可以操作Cookie。Cookie還可以幫助我們節(jié)省網(wǎng)絡(luò)請(qǐng)求的發(fā)起數(shù)量。例如,當(dāng)我們?cè)谥谱饕粋€(gè)購(gòu)物網(wǎng)站時(shí),我們當(dāng)然不希望用戶在每添加一個(gè)商品到購(gòu)物車就向服務(wù)器發(fā)送一個(gè)請(qǐng)求(請(qǐng)求數(shù)量越少,服務(wù)器壓力就越小),此時(shí),我們就可以將添加商品所導(dǎo)致的數(shù)據(jù)變動(dòng)存儲(chǔ)在Cookie內(nèi),然后等待下次發(fā)送請(qǐng)求時(shí),一并發(fā)送給服務(wù)器處理。

現(xiàn)在我們可以說,Cookie的出現(xiàn),為無狀態(tài)的HTTP協(xié)議通信添加了狀態(tài)。

最后需要注意,Cookie大多數(shù)情況下,都保存著用戶的身份信息,因此各種惡意攻擊者對(duì)于Cookie的攻擊便花樣百出,層出不窮。其本質(zhì)上就是想要獲得用戶的Cookie,再利用其中的身份信息偽裝成用戶獲取相應(yīng)資源,而瀏覽器的“同源策略”本質(zhì)上就是保護(hù)用戶的Cookie信息不會(huì)泄露。

(二)讓服務(wù)器也動(dòng)起來 - WebSocket

繞了一個(gè)小彎,現(xiàn)在可以回過頭來繼續(xù)談?wù)勎覀兊闹鹘荳ebSocket了。再讓我們回憶一下WebSocket要解決的問題:

客戶端無法獲知請(qǐng)求的動(dòng)態(tài)資源何時(shí)到位“,讓我們描述的更詳細(xì)一點(diǎn),有時(shí)候客戶端想要請(qǐng)求的資源,服務(wù)器需要一定時(shí)間后才能返回(比如該資源依賴于其他服務(wù)器的計(jì)算返回結(jié)果),由于在HTTP協(xié)議下,網(wǎng)絡(luò)通信是單向的,因此服務(wù)器并不具備當(dāng)資源準(zhǔn)備就緒時(shí),通知瀏覽器的功能(因?yàn)槲覀円U戏?wù)器的工作效率)。因此,基于HTTP協(xié)議通常的做法是,設(shè)置一個(gè)定時(shí)器,每隔一定時(shí)間由瀏覽器向服務(wù)器發(fā)送一次請(qǐng)求以探測(cè)資源是否到位。

這種做法顯然浪費(fèi)了很多請(qǐng)求,換句話說,浪費(fèi)了很多帶寬(我們每個(gè)請(qǐng)求都要攜帶Cookie和報(bào)頭,這些都會(huì)占用帶寬傳輸),不僅低效率,而且也不夠優(yōu)雅。

理所當(dāng)然的,在這種情況下,我們希望當(dāng)服務(wù)器資源到位時(shí),能夠主動(dòng)通知瀏覽器并返回相應(yīng)資源。而為了實(shí)現(xiàn)這一點(diǎn),HTML5標(biāo)準(zhǔn)推出了WebSocket協(xié)議,使瀏覽器和服務(wù)器實(shí)現(xiàn)了雙向通信,更妙的是,除了IE9及以下的IE瀏覽器,所有的瀏覽器都支持WebSocket協(xié)議。

讓我們也同樣構(gòu)建一個(gè)基于WebSocket協(xié)議的心智模型,在這個(gè)心智模型中,服務(wù)端扮演的角色發(fā)生了一些改變,服務(wù)端不再只是一個(gè)“守門人”,同時(shí)它也運(yùn)營(yíng)著一個(gè)和客戶端一樣的“郵局”,也就是說,他也擁有了可以向客戶端發(fā)送數(shù)據(jù)的能力。至此一個(gè)完整的基于WebSocket協(xié)議的通信流程為:

客戶端派發(fā)一個(gè)信使向服務(wù)器送信,服務(wù)器扮演的“守門人”檢查信件,發(fā)現(xiàn)信件中寫到“讓我們用更加潮流的WebSocket方式交流吧”,服務(wù)器在在信件末尾添加上一句“沒問題,瀏覽器伙計(jì)”,讓信使原路返回告知瀏覽器。當(dāng)瀏覽器再次向服務(wù)器告知收到消息時(shí)(第三次握手),服務(wù)器就開始運(yùn)轉(zhuǎn)“郵局”,向客戶端派發(fā)信使與瀏覽器互發(fā)信息,轉(zhuǎn)發(fā)資源。

讓我們看看這個(gè)模型的具體實(shí)現(xiàn):

下面是客戶端告知服務(wù)端要升級(jí)為WebSocket協(xié)議的報(bào)頭:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

下面是服務(wù)端向客戶端返回的響應(yīng)報(bào)頭:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

想知道這些報(bào)頭中的字段中代表什么?可以參考維基百科下的說明。

(三)客戶端發(fā)起WebSocket請(qǐng)求

既然我們已經(jīng)為了解釋“什么是WebSocket”,“WebSocket的意義”花了那么多篇幅,那么不妨添加上最后一個(gè)環(huán)節(jié),讓這個(gè)主題變得更加完整,接下來我們將要簡(jiǎn)單講解一下客戶端如何發(fā)起一個(gè)WebSocket請(qǐng)求。

像發(fā)起AJAX請(qǐng)求一樣,發(fā)起WebSocket請(qǐng)求需要借助瀏覽器提供的WebSocket對(duì)象,該對(duì)象提供了用于創(chuàng)建和管理WebSocket連接,以及通過該連接收發(fā)數(shù)據(jù)的API。所有的瀏覽器都默認(rèn)提供了WebSocket對(duì)象。讓我們看看該對(duì)象的用法:

和使用XHRHttpRequest對(duì)象一樣,我們首先要實(shí)例化一個(gè)WebSocket對(duì)象:

var ws = new WebSocket("wss://echo.websocket.org")

傳入的參數(shù)為響應(yīng)WebSocket請(qǐng)求的地址。

同樣類似AJAX的是,WebSocket對(duì)象也有一個(gè)readyState屬性,用來表示對(duì)象實(shí)例當(dāng)前所處的鏈接狀態(tài),有四個(gè)值:

0:表示正在連接中(CONNECTING);

1:表示連接成功,可以通信(OPEN);

2:表示連接正在關(guān)閉(CLOSING);

3:表示連接已經(jīng)關(guān)閉或打開連接失?。–LOSED);

我們可以通過判斷這個(gè)值來執(zhí)行我們相應(yīng)的代碼。

除此之外,WebSocket對(duì)象還提供給我們一系列事件屬性,使我們控制連接過程中的通信行為:

onopen:用于指定連接成功后的回調(diào)函數(shù);

onclose:用于指定連接關(guān)閉后的回調(diào)函數(shù);

onmessage:用于指定收到服務(wù)器數(shù)據(jù)后的回調(diào)函數(shù);

onerror:用于指定報(bào)錯(cuò)時(shí)的回調(diào)函數(shù);

通過.send()方法,我們擁有了向服務(wù)器發(fā)送數(shù)據(jù)的能力(WebSocket還允許我們發(fā)送二進(jìn)制數(shù)據(jù)):

ws.send("Hi, server!")

如何知道何時(shí)我們的數(shù)據(jù)發(fā)送完畢呢?我們需要使用WebSocket對(duì)象的bufferedAmount屬性,該屬性的返回值表示了還有多少字節(jié)的二進(jìn)制數(shù)據(jù)沒有發(fā)送出去,所以我們可以通過判斷該值是否為0而確定數(shù)據(jù)是否發(fā)送結(jié)束。

var data = new ArrayBuffer(1000000)
ws.send(data)

if (socket.bufferedAmount === 0) {
    // 發(fā)送完畢
} else {
    // 還在發(fā)送
}

OK,目前為止我們花了大量篇幅解釋了WebSocket協(xié)議是什么,它能夠幫助我們做什么,以及客戶端發(fā)送WebSocket請(qǐng)求的方式。但是目前為止,我們還是沒有談?wù)撘欢↑c(diǎn)關(guān)于WebSocket是如何幫助我們繞過瀏覽器的“同源策略”讓我們實(shí)現(xiàn)“跨域資源共享”,你是否已經(jīng)有點(diǎn)等的不耐煩了?

但是別急,當(dāng)你清楚的了解到WebSocket是什么之后,答案就呼之欲出了,那就是當(dāng)客戶端與服務(wù)端創(chuàng)建WebSocket連接后,本身就可以天然的實(shí)現(xiàn)跨域資源共享,WebSocket協(xié)議本身就不受瀏覽器“同源策略”的限制(還記得吧,同源策略只是限制了跨域的AJAX請(qǐng)求?),所以問題本身就不成立(有點(diǎn)賴皮是吧?)。

但是你可能又會(huì)問,如果沒有瀏覽器“同源策略”的限制,那么用戶的Cookie安全又由誰來保護(hù)呢?問得好,看來你有認(rèn)真閱讀上面的文字,為了解答這個(gè)問題,讓我們換一種角度思考,我們說過Cookie的存在就是為了給無狀態(tài)的HTTP協(xié)議通訊添加狀態(tài),因?yàn)镃ookie是明文傳輸?shù)?,且通常包含用戶的身份信息,所以非常受到網(wǎng)絡(luò)攻擊者的“關(guān)注”。但是想想WebSocket協(xié)議下的通訊機(jī)制,客戶端和服務(wù)端一旦建立連接,就可以順暢的互發(fā)數(shù)據(jù),因此WebSocket協(xié)議本身就是“有狀態(tài)的”,不需要Cookie的幫忙,既然沒有Cookie,自然也不需要“同源策略”去保護(hù),因此其實(shí)這個(gè)問題也不成立。

至此,已經(jīng)將關(guān)于WebSocket的所有內(nèi)容都大致講述了一遍,真沒想到是如此巨大的工作量。看來本篇文章不應(yīng)該叫做“再也不學(xué)AJAX了”,而是“再也不學(xué)AJAX,JSONP,CORS,WebSocket..”。

真是了不起。

二、postMessage

回頭一看,我們已經(jīng)在“跨域”這個(gè)主題上整整停留了三篇文章,涉及的技術(shù)包括JSONP,CORS與WebSocket。需要注意的是,以上這些跨域技術(shù)都只適用于客戶端請(qǐng)求異域服務(wù)端資源的情景。而除此之外,有時(shí)候我們還需要在異域的兩個(gè)客戶端之間共享數(shù)據(jù),例如頁面與內(nèi)嵌iframe窗口通訊,頁面與新打開異域頁面通訊。

這就是使用HTML5提供的新API -- postMessage的時(shí)候了。

使用postMessage技術(shù)實(shí)現(xiàn)跨域的原理非常簡(jiǎn)單,一方面,主窗口通過postMessageAPI向異域的窗口發(fā)送數(shù)據(jù),另一方面我們?cè)诋愑虻捻撁婺_本中始終監(jiān)聽message事件,當(dāng)獲取主窗口數(shù)據(jù)時(shí)處理數(shù)據(jù)或者以同樣的方式返回?cái)?shù)據(jù)從而實(shí)現(xiàn)跨窗口的異域通訊。

讓我們用具體的業(yè)務(wù)場(chǎng)景與代碼進(jìn)一步說明,假如我們的頁面現(xiàn)在有兩個(gè)窗口,窗口1命名為“window_1”, 窗口2命名為“window_2”,當(dāng)然,窗口1與窗口2的“域”是不同的,我們的需求是由窗口1向窗口2發(fā)送數(shù)據(jù),而當(dāng)窗口2接收到數(shù)據(jù)時(shí),將數(shù)據(jù)再返回給窗口1。先讓我們看看窗口1script標(biāo)簽內(nèi)的代碼:

// window_1 域名為 http://winodow1.com:8080
window.postMessage("Hi, How are you!", "http://window2.com:8080")

可以看到,postMessage函數(shù)接收兩個(gè)參數(shù),第一個(gè)為要發(fā)送的信息(可以是任何JavaScript類型數(shù)據(jù),但部分瀏覽器只支持字符串格式),第二個(gè)為信息發(fā)送的目標(biāo)地址。讓我們?cè)倏纯创翱?script標(biāo)簽內(nèi)的代碼:

// window_2 域名為 http://window2.com:8080
window.addEventListener("message", receiveMessage, false)

function receiveMessage(event) {
    // 對(duì)于Chorme,origin屬性為originalEvent.origin屬性
    var origin = event.origin || event.originalEvent.origin
    if (origin !== "http://window1.com:8080") {
        return 
    }
    window.postMessage("I"m ok", "http://window1.com:8080")
}

看到了嗎,我們?cè)趙indow上綁定了一個(gè)事件監(jiān)聽函數(shù),監(jiān)聽message事件。一旦我們接收到其他域通過postMessage發(fā)送的信息,就會(huì)觸發(fā)我們的receiveMessage回調(diào)函數(shù)。該函數(shù)會(huì)首先檢查發(fā)送信息的域是否是我們想要的(之后我們會(huì)對(duì)此詳細(xì)說明),如果驗(yàn)證成功則會(huì)像窗口1發(fā)送一條消息。

看起來很好懂不是嗎,一方發(fā)送信息,一方捕捉信息。但是,我需要格外提醒你的是所有“跨域”技術(shù)都需要關(guān)注的“安全問題”。讓我們想想postMessage技術(shù)之所以能實(shí)現(xiàn)跨域資源共享,本質(zhì)上是要依賴于客戶端腳本設(shè)置了相應(yīng)的message監(jiān)聽事件。因此只要有消息通過postMessage發(fā)送過來,我們的腳本都會(huì)接收并進(jìn)行處理。由于任何域都可以通過postMessage發(fā)送跨域信息,因此對(duì)于設(shè)置了事件監(jiān)聽器的頁面來說,判斷到達(dá)頁面的信息是否是安全的是非常重要的事,因?yàn)槲覀儾⒉幌胍獔?zhí)行有危險(xiǎn)的數(shù)據(jù)。

那么接下來的問題便是,如何鑒別發(fā)送至頁面的信息呢?答案是通過 message事件監(jiān)聽函數(shù)的事件對(duì)象,我們稱它為event,該對(duì)象有三個(gè)屬性:

data:值為其他window傳遞過來的對(duì)象;

origin:值為消息發(fā)送方窗口的域名;

source:值為對(duì)發(fā)送消息的窗口對(duì)象的引用;

很顯然的,我們應(yīng)該著重檢測(cè)event對(duì)象的origin屬性,建立一個(gè)白名單對(duì)origin屬性進(jìn)行檢測(cè)通常是一個(gè)明智的做法。

最后,再讓我們談?wù)?b>postMessage對(duì)象的瀏覽器兼容性,這方面到是很幸運(yùn),除了IE8以下的IE瀏覽器,所有的瀏覽器都支持postMessage方法!

至此,我們終于完全講完了“跨域共享資源”這一主題?;瞬簧倭馐前桑肯M@是值得的。







? Hey!到這里《再也不學(xué)AJAX了!》這個(gè)專題系列就完全結(jié)束了,還記得我們的初心嗎?我希望你能通過閱讀這個(gè)系列的文章,以較為輕松的方式,系統(tǒng)完整地掌握AJAX技術(shù),從此再也不用刻意學(xué)習(xí)零散的AJAX知識(shí)。希望我達(dá)成了我的目標(biāo),也希望你在閱讀學(xué)習(xí)的過程中感到愉快。

關(guān)于AJAX技術(shù)這個(gè)專題,其實(shí)我還想講述的兩個(gè)話題是:更優(yōu)雅的資源獲取方式:fetch API 以及 深入jQuery:AJAX的實(shí)現(xiàn),但是鑒于我個(gè)人時(shí)間精力有限(完成一個(gè)系列文章真的比我想的要付出更多時(shí)間?。?,就決定暫時(shí)先放下,等將來有機(jī)會(huì)再以這個(gè)系列的番外篇的形式補(bǔ)充上去,希望你們可以理解和接受:)。

這是我第一次在技術(shù)平臺(tái)中以“系列”的方式發(fā)表技術(shù)文章,我個(gè)人覺得這樣的方式更容易令人在整體上把握和理解一個(gè)技術(shù),從而做到更靈活熟練的使用。希望你們也認(rèn)同這一點(diǎn)并在閱讀過程中感到愉快。之后,我也會(huì)繼續(xù)在專欄中發(fā)表關(guān)于Web開發(fā)技術(shù)的系列文章,希望得到你們的認(rèn)可和支持。

最后,再談?wù)勎以诩夹g(shù)平臺(tái)發(fā)表文章的初心:之所以開始在各平臺(tái)(目前為稀土掘金和segmentfault)發(fā)表技術(shù)文章,主要是為了幫助我消化知識(shí),鍛煉寫作的文筆,驗(yàn)證我對(duì)某個(gè)技術(shù)的理解是否正確,以及積攢人氣滿足虛榮心。在這個(gè)過程中,也希望讀者能夠通過閱讀我的文章,加深對(duì)某一技術(shù)的理解。我認(rèn)為這是一件雙贏的事情,因此我十分歡迎,甚至是期待你在閱讀我任何文章的過程中都能夠:

如果覺得有所收獲,毫不猶豫的點(diǎn)擊贊賞按鈕(我真的真的會(huì)很開心?);

如果想到了其他相關(guān)知識(shí),或發(fā)現(xiàn)我對(duì)某個(gè)技術(shù)的理解不正確,毫不猶豫的在評(píng)論區(qū)留言與我交流

如果對(duì)于我講述中的某個(gè)概念還是不懂,毫不猶豫的在留言區(qū)告知我你的困惑,我會(huì)思考怎么樣把這個(gè)概念講述的更加清楚明白;

如果覺得我的文章不錯(cuò),毫不猶豫的將我的文章推薦給他人,邀請(qǐng)他們成為我的讀者;

如果你覺得閱讀我的文章所花費(fèi)的時(shí)間很值得,對(duì)你有很大幫助并且也認(rèn)可我的勞動(dòng)成果,你大可以點(diǎn)擊下方紅色的“贊賞支持”按鈕為這篇文章付費(fèi),同時(shí)表達(dá)你對(duì)我創(chuàng)作的認(rèn)可與支持。寫作能夠?qū)θ擞幸嬗帜塬@得報(bào)酬,這著實(shí)令人倍感欣慰。

我的創(chuàng)作和成長(zhǎng)需要你們的幫助和支持,作為報(bào)答,我會(huì)持續(xù)發(fā)布優(yōu)質(zhì)的文章,陪同你們一起成長(zhǎng)。關(guān)注我,一起加油吧! ?

文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/92392.html

相關(guān)文章

  • 再也不學(xué)AJAX?。?em>三)跨域獲取資源 ② - JSONP & CORS

    摘要:瀏覽器的同源策略固然保障了互聯(lián)網(wǎng)世界的數(shù)據(jù)隱私與數(shù)據(jù)安全,但是如果當(dāng)我們需要使用跨域請(qǐng)求資源時(shí),同源策略又會(huì)成為開發(fā)者的阻礙。我們之前提到過,如果想要繞過瀏覽器同源策略,實(shí)現(xiàn)使用技術(shù)跨域獲取資源,需要服務(wù)端和客戶端的協(xié)同合作。 瀏覽器的同源策略固然保障了互聯(lián)網(wǎng)世界的數(shù)據(jù)隱私與數(shù)據(jù)安全,但是如果當(dāng)我們需要使用AJAX跨域請(qǐng)求資源時(shí),同源策略又會(huì)成為開發(fā)者的阻礙。在本文中,我們會(huì)簡(jiǎn)單介紹需...

    enda 評(píng)論0 收藏0
  • 再也不學(xué)AJAX?。ㄒ唬?em>AJAX概述

    摘要:需要注意的是,并不是的替代品,兩者各自有其適應(yīng)的場(chǎng)景。但為了方便交流,我們通常將獲取資源的一方稱為客戶端主要的工具是瀏覽器,而將派發(fā)資源的一方稱為服務(wù)端又稱為服務(wù)器。它可以幫助我們?yōu)橹蟾拍罴?xì)節(jié)的學(xué)習(xí)打下良好基礎(chǔ)。 再也不學(xué)AJAX了是一個(gè)與AJAX主題相關(guān)的文章系列,包含以下三個(gè)部分的內(nèi)容: AJAX概述:主要回答AJAX是什么這個(gè)問題; 使用AJAX:介紹如何通過JavaSc...

    neu 評(píng)論0 收藏0
  • 再也不學(xué)AJAX!(跨域獲取資源 ① - 同源策略

    摘要:瀏覽器的同源策略瀏覽器所遵守的同源策略是指限制不同源之間執(zhí)行特定操作。這正是同源策略想要規(guī)避的安全隱患。目前為止,你已經(jīng)充分了解同源策略這個(gè)主題。 我們之前提到過,AJAX技術(shù)使開發(fā)者能夠?qū)W⒂诨ヂ?lián)網(wǎng)中數(shù)據(jù)的傳輸,而不再拘泥于數(shù)據(jù)傳輸?shù)妮d體。通過AJAX技術(shù),我們獲取數(shù)據(jù)的方式變得更加靈活,可控和優(yōu)雅。 但是AJAX技術(shù)并不是一把萬能鑰匙,互聯(lián)網(wǎng)中的數(shù)據(jù)隱私和數(shù)據(jù)安全(例如你的銀行賬號(hào)...

    godlong_X 評(píng)論0 收藏0
  • 雜談:前端Web通信

    摘要:作為開發(fā)同學(xué)的小伙伴客戶端的瀏覽器,有點(diǎn)小調(diào)皮還做了一個(gè)同源策略的限制,當(dāng)我們的數(shù)據(jù)請(qǐng)求遇到不同源的情況下跨域,我們就得嘗試其它的通信方法,不能一條道走到黑。 showImg(https://segmentfault.com/img/bVburZO?w=600&h=450); Web2.0以來,Ajax的出世,解決了傳統(tǒng)表單提交頁面跳轉(zhuǎn),閃爍白屏等問題。使得Web頁面可以實(shí)現(xiàn)局部更新,...

    Betta 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<