摘要：如何解決跨域問題跨域原因由于瀏覽器的同源策略限制，只允許請(qǐng)求當(dāng)前源域名協(xié)議端口的資源。同源策略同源策略是客戶端腳本尤其是的重要的安全度量標(biāo)準(zhǔn)。同源策略指的是協(xié)議，域名，端口相同，同源策略是一種安全協(xié)議。狀態(tài)表示客戶端已發(fā)送報(bào)文。

跨域原因：由于瀏覽器的同源策略限制，XmlHttpRequest只允許請(qǐng)求當(dāng)前源（域名、協(xié)議、端口）的資源。在腳本中發(fā)起HTTP請(qǐng)求，出于安全考慮，會(huì)被瀏覽器限制，html中通過標(biāo)簽請(qǐng)求不存跨域：img，video，script文件，css文件等。
同源策略：同源策略是客戶端腳本（尤其是Javascript）的重要的安全度量標(biāo)準(zhǔn)。它最早出自Netscape Navigator2.0，其目的是防止某個(gè)文檔或腳本從多個(gè)不同源裝載。同源策略指的是：協(xié)議，域名，端口相同，同源策略是一種安全協(xié)議。一段腳本只能讀取來自同一來源的窗口和文檔的屬性。
為什么要有同源限制？
我們舉例說明：比如一個(gè)黑客程序，他利用Iframe把真正的銀行登錄頁面嵌到他的頁面上，當(dāng)你使用真實(shí)的用戶名，密碼登錄時(shí)，他的頁面就可以通過Javascript讀取到你的表單中input中的內(nèi)容，這樣用戶名，密碼就輕松到手了。

跨域的幾種方式：

1>、JSONP:json+padding（內(nèi)填充），顧名思義，就是把JSON填充到一個(gè)盒子里。
原理：利用HTML的 /** jQuery獲取jsonp **/ $("#getJsonpByJquery").click(function () { $.ajax({ url: "http://localhost:2701/home/somejsonp", dataType: "jsonp", jsonp: "callback", success: function (data) { console.log(data) } }) })

進(jìn)階問題：
1，JSONP需要?jiǎng)討B(tài)創(chuàng)建script標(biāo)簽，需不需要處理這些script元素？怎么處理？
需要，可以監(jiān)聽script標(biāo)簽的加載狀態(tài)，當(dāng)失敗或加載完成后移除script標(biāo)簽并移除標(biāo)簽上的監(jiān)聽事件，以及掛載在window上的回調(diào)函數(shù)。

2，JSONP請(qǐng)求的時(shí)候，服務(wù)器發(fā)生錯(cuò)誤該怎么辦，前端怎么處理這個(gè)錯(cuò)誤？
一般前端框架都會(huì)對(duì)跨域請(qǐng)求失敗是進(jìn)行處理，比如JQuery中，當(dāng)使用ajax或getJSON發(fā)送請(qǐng)求后會(huì)返回一個(gè)jqXHR對(duì)象。該對(duì)象實(shí)現(xiàn)了Promise協(xié)議，所以我們可以使用它的done、fail、always等接口來處理回調(diào)。例如我們可以用在它的fail回調(diào)中進(jìn)行請(qǐng)求失敗時(shí)的錯(cuò)誤處理：

var xhr = $.getJSON(...);
xhr.fail(function(jqXHR, textStatus, ex) {
    alert("request failed, cause: " + ex.message);
});

當(dāng)遇到“非正常錯(cuò)誤”時(shí)，除了IE7、8以外，JQuery的JSONP在較新的瀏覽器中全部會(huì)“靜默失敗”。但很多時(shí)候我們希望能夠捕獲和處理這種錯(cuò)誤。實(shí)際上在這些瀏覽器中，

3>、通過修改document.domain來跨子域：將子域和主域的document.domain設(shè)為同一個(gè)主域.前提條件：這兩個(gè)域名必須屬于同一個(gè)基礎(chǔ)域名!而且所用的協(xié)議，端口都要一致，否則無法利用document.domain進(jìn)行跨域。

4>、window.name實(shí)現(xiàn)跨域：window.name 的美妙之處：name 值在不同的頁面（甚至不同域名）加載后依舊存在，并且可以支持非常長的 name 值（2MB）。
原理：當(dāng)在瀏覽器中打開一個(gè)頁面，或者在頁面中添加一個(gè)iframe時(shí)即會(huì)創(chuàng)建一個(gè)對(duì)應(yīng)的window對(duì)象，當(dāng)頁面加載另一個(gè)新的頁面時(shí)，window的name屬性是不會(huì)變的。這樣就可以利用在頁面動(dòng)態(tài)添加一個(gè)iframe然后src加載數(shù)據(jù)頁面，在數(shù)據(jù)頁面將需要的數(shù)據(jù)賦值給window.name。然而此時(shí)承載iframe的parent頁面還是不能直接訪問，不在同一域下iframe的name屬性，這時(shí)只需要將iframe再加載一個(gè)與承載頁面同域的空白頁面，即可對(duì)window.name進(jìn)行數(shù)據(jù)讀取。
www.test.com下a.html頁：

www.domain.com下b.html頁：

5>、window.postMessage方法來跨域：
www.test.com下a.html頁：

點(diǎn)擊我通過iframe框架向http://www.lamport.me/data2.html頁面發(fā)送并返回?cái)?shù)據(jù)

www.domain.com下b.html頁：

6>、另可通過filder工具，或者本地起node來實(shí)現(xiàn)跨域。

XML:擴(kuò)展標(biāo)記語言，使用DTD文檔類型定義來組織數(shù)據(jù)，格式統(tǒng)一，適合Web傳輸。
優(yōu)點(diǎn)：
1.格式統(tǒng)一，符合標(biāo)準(zhǔn)；
2.容易與其他系統(tǒng)進(jìn)行遠(yuǎn)程交互，數(shù)據(jù)共享方便；
3.擴(kuò)展性好；
4.描述性比JSON好；
缺點(diǎn)：
1.文件龐大，格式復(fù)雜，傳輸數(shù)據(jù)量大；
2.客戶端不同瀏覽器解析XML方式不一致，需要重復(fù)編寫很多代碼；
3.服務(wù)器端和客戶端解析XML花費(fèi)較多的資源和時(shí)間。
JSON：一種輕量級(jí)的數(shù)據(jù)交換格式，具有良好的可讀和便于快速編寫的特性。可在不同平臺(tái)之間進(jìn)行數(shù)據(jù)交換。JSON采用兼容性很高的、完全獨(dú)立于語言文本格式。
優(yōu)點(diǎn)：
1，數(shù)據(jù)格式簡單，易于讀寫，傳輸數(shù)據(jù)量較??；
2.易于解析，客戶端可以簡單通過eval()進(jìn)行JSON數(shù)據(jù)的讀??；
3.支持多種語言，便于服務(wù)端的解析；
缺點(diǎn)：
JSON只提供整體解析方案，而這種方法只在解析較少的數(shù)據(jù)時(shí)才能起到良好的效果；
XML通過SAX解析，可以不需要整個(gè)讀入文檔，就可以對(duì)解析出的內(nèi)容進(jìn)行處理，是一種逐步解析的方法，也可以隨時(shí)終止，這種方案很適合于對(duì)大量數(shù)據(jù)的處理。
數(shù)據(jù)展示比較：

/** XML **/


  中國
  
    黑龍江
    
      哈爾濱
      大慶
      　　
  
  
    廣東
    
      廣州
      深圳
      珠海
     　　
  
  
    臺(tái)灣
    
      　臺(tái)北
      　高雄
    　
  
  
    新疆
    
      烏魯木齊
    
  


 /** JSON **/
 var country =
    {
        name: "中國",
        provinces: [
        { name: "黑龍江", citys: { city: ["哈爾濱", "大慶"]} },
        { name: "廣東", citys: { city: ["廣州", "深圳", "珠海"]} },
        { name: "臺(tái)灣", citys: { city: ["臺(tái)北", "高雄"]} },
        { name: "新疆", citys: { city: ["烏魯木齊"]} }
        ]
    }

ACK:TCP協(xié)議規(guī)定，只有ACK=1時(shí)有效，也規(guī)定連接建立后所有發(fā)送的報(bào)文的ACK必須為1;
SYN: 在連接建立時(shí)用來同步序號(hào)。當(dāng)SYN=1而ACK=0時(shí)，表明這是一個(gè)連接請(qǐng)求報(bào)文。對(duì)方若同意建立連接，則應(yīng)在響應(yīng)報(bào)文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個(gè)連接請(qǐng)求或連接接受報(bào)文。
FIN:即完，終結(jié)的意思， 用來釋放一個(gè)連接。當(dāng) FIN = 1 時(shí)，表明此報(bào)文段的發(fā)送方的數(shù)據(jù)已經(jīng)發(fā)送完畢，并要求釋放連接。

tcp標(biāo)志位,有6種標(biāo)示：
1.SYN(synchronous建立聯(lián)機(jī)) 
2.ACK(acknowledgement 確認(rèn)) 
3.PSH(push傳送) 
4.FIN(finish結(jié)束) 
5.RST(reset重置) 
6.URG(urgent緊急) Sequence number(順序號(hào)碼) Acknowledge number(確認(rèn)號(hào)碼)
狀態(tài)詳解：
1.CLOSED： 表示初始狀態(tài)。
2.LISTEN： 這個(gè)也是非常容易理解的一個(gè)狀態(tài)，表示服務(wù)器端的某個(gè)SOCKET處于監(jiān)聽狀態(tài)，可以接受連接了。
3.SYN_RCVD： 這個(gè)狀態(tài)表示接受到了SYN報(bào)文，在正常情況下，這個(gè)狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時(shí)的三次握手會(huì)話過程中的一個(gè)中間狀態(tài)，很短暫，基本
上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個(gè)客戶端測試程序，故意將三次TCP握手過程中最后一個(gè)ACK報(bào)文不予發(fā)送。因此這種狀態(tài)
時(shí)，當(dāng)收到客戶端的ACK報(bào)文后，它會(huì)進(jìn)入到ESTABLISHED狀態(tài)。
4.SYN_SENT： 這個(gè)狀態(tài)與SYN_RCVD遙想呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時(shí)，它首先發(fā)送SYN報(bào)文，因此也隨即它會(huì)進(jìn)入到了SYN_SENT狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個(gè)報(bào)文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報(bào)文。
5.ESTABLISHED：這個(gè)容易理解了，表示連接已經(jīng)建立了。
6.FIN_WAIT_1： 這個(gè)狀態(tài)要好好解釋一下，其實(shí)FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對(duì)方的FIN報(bào)文。而這兩種狀態(tài)的區(qū)別
是：FIN_WAIT_1狀態(tài)實(shí)際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時(shí)，它想主動(dòng)關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報(bào)文，此時(shí)該SOCKET即
進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對(duì)方回應(yīng)ACK報(bào)文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實(shí)際的正常情況下，無論對(duì)方何種情況下，都應(yīng)該馬
上回應(yīng)ACK報(bào)文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時(shí)常?？梢杂胣etstat看到。
7.FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實(shí)際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對(duì)方，我暫時(shí)還有點(diǎn)數(shù)據(jù)需要傳送給你，稍后再關(guān)閉連接。
8.TIME_WAIT： 表示收到了對(duì)方的FIN報(bào)文，并發(fā)送出了ACK報(bào)文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對(duì)方同時(shí)帶FIN標(biāo)志和ACK標(biāo)志的報(bào)文時(shí)，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。
9.CLOSING： 這種狀態(tài)比較特殊，實(shí)際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)你發(fā)送FIN報(bào)文后，按理來說是應(yīng)該先收到（或同時(shí)收到）對(duì)方的
ACK報(bào)文，再收到對(duì)方的FIN報(bào)文。但是CLOSING狀態(tài)表示你發(fā)送FIN報(bào)文后，并沒有收到對(duì)方的ACK報(bào)文，反而卻也收到了對(duì)方的FIN報(bào)文。什
么情況下會(huì)出現(xiàn)此種情況呢？其實(shí)細(xì)想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時(shí)close一個(gè)SOCKET的話，那么就出現(xiàn)了雙方同時(shí)發(fā)送FIN報(bào)
文的情況，也即會(huì)出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。
10.CLOSE_WAIT： 這種狀態(tài)的含義其實(shí)是表示在等待關(guān)閉。怎么理解呢？當(dāng)對(duì)方close一個(gè)SOCKET后發(fā)送FIN報(bào)文給自己，你系統(tǒng)毫無疑問地會(huì)回應(yīng)一個(gè)ACK報(bào)文給對(duì)
方，此時(shí)則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢，實(shí)際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對(duì)方，如果沒有的話，那么你也就可以
close這個(gè)SOCKET，發(fā)送FIN報(bào)文給對(duì)方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。
11.LAST_ACK： 這個(gè)狀態(tài)還是比較容易好理解的，它是被動(dòng)關(guān)閉一方在發(fā)送FIN報(bào)文后，最后等待對(duì)方的ACK報(bào)文。當(dāng)收到ACK報(bào)文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。

三次握手：
1、客戶端（Client）向服務(wù)端發(fā)送SYN包，即SYN=1,ACK=0，隨機(jī)產(chǎn)生seq number=3626544836，服務(wù)端（Serve）接收到SYN包，通過SYN=1，ACK=0 知道要求建立聯(lián)機(jī)；（第一次握手）
2、服務(wù)端收到請(qǐng)求后要確認(rèn)聯(lián)機(jī)信息，向客戶端發(fā)送SYN包（syn=k），即ack number=3626544837,syn=1,ack=1,隨機(jī)產(chǎn)生seq=1739326486的包，服務(wù)端進(jìn)入SYN_RECV狀態(tài)；（第二次握手）
3、客戶端接收到服務(wù)發(fā)回的SYN+ACK包后，檢查ack number是否正確，即第一次發(fā)送的seq number+1,以及位碼ack是否為1，若正確，再次向服務(wù)端發(fā)送確認(rèn)包ACK，即ack number=1739326487,ack=1，此包發(fā)送完畢后，服務(wù)端接收到后確認(rèn)seq = seq + 1，ack = 1，則連接建立成功，雙方進(jìn)入ESTABLISHED狀態(tài)。（第三次握手）

一個(gè)完整的三次握手就是：請(qǐng)求---應(yīng)答----再次確認(rèn)----服務(wù)端收到確認(rèn)建立連接

建立連接為什么要三次握手(兩次確認(rèn))？
兩次確認(rèn)主要是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送給了服務(wù)端，因而產(chǎn)生錯(cuò)誤連接。
已失效的連接請(qǐng)求報(bào)文段發(fā)生情況：
1.假設(shè)客戶端向服務(wù)端發(fā)送一個(gè)建立連接的請(qǐng)求，請(qǐng)求報(bào)文由于網(wǎng)絡(luò)原因在某個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)滯留了，客戶端長時(shí)間沒有收到服務(wù)端的確認(rèn)，于是以為請(qǐng)求報(bào)文丟失，于是又再一次發(fā)送連接請(qǐng)求，然后這次收到確認(rèn)并成功建立了連接，數(shù)據(jù)輸出完后，釋放了連接。
2.在釋放連接之后，結(jié)果第一次的連接請(qǐng)求到達(dá)了服務(wù)端，這時(shí)服務(wù)端會(huì)誤以為這是客戶端又重新發(fā)出了一次新的請(qǐng)求，于是向客戶端發(fā)送確認(rèn)報(bào)文段，同意建立連接。
3.假如沒有采用三次握手，服務(wù)端這次發(fā)送確認(rèn)后就建立了新的連接，并等待客戶端發(fā)來請(qǐng)求，可是客戶端實(shí)際情況并沒有發(fā)出請(qǐng)求，于是服務(wù)端很多資源就這樣浪費(fèi)了。
4.如果采用三次握手，當(dāng)服務(wù)端向客戶端發(fā)送確認(rèn)報(bào)文段后，客戶端并不會(huì)再向服務(wù)端發(fā)送確認(rèn)，于是服務(wù)端就知道客戶端并沒有要求建立連接。

若在握手過程中某個(gè)階段莫名中斷，TCP協(xié)議會(huì)再次以相同的順序發(fā)送相同的數(shù)據(jù)包。

四次揮手：
由于TCP連接是全雙工的，因此每個(gè)方向都必須多帶帶進(jìn)行關(guān)閉。這個(gè)原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。
1、客戶端向服務(wù)端發(fā)送一個(gè)FIN，表示自己這方的數(shù)據(jù)已經(jīng)發(fā)送完畢，可以釋放連接。
2、服務(wù)端收到FIN后，發(fā)回一個(gè)ASK，確認(rèn)已收到釋放連接通知，確認(rèn)序號(hào)為收到的序號(hào)加1。
3、服務(wù)端確認(rèn)自己這方的數(shù)據(jù)已經(jīng)發(fā)送完畢后，向客戶端發(fā)送一個(gè)FIN,表示要釋放連接。
4、客戶端收到FIN后，發(fā)回一個(gè)ASK報(bào)文確認(rèn)，確認(rèn)序號(hào)為收到的序號(hào)加1。

1、為什么建立連接時(shí)三次握手，關(guān)閉連接是4次握手？

1.這是因?yàn)榉?wù)端的LISTEN狀態(tài)下的SOCKET當(dāng)收到SYN報(bào)文的建連請(qǐng)求后，它可以把ACK和SYN（ACK起應(yīng)答作用，而SYN起同步作用）放在一個(gè)報(bào)文里來發(fā)送。
2.但關(guān)閉連接時(shí)，當(dāng)收到對(duì)方的FIN報(bào)文通知時(shí)，它僅僅表示對(duì)方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對(duì)方了，所以你未必會(huì)馬上會(huì)關(guān)閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對(duì)方之后，再發(fā)送FIN報(bào)文給對(duì)方來表示你同意現(xiàn)在可以關(guān)閉連接了，所以它這里的ACK報(bào)文和FIN報(bào)文多數(shù)情況下都是分開發(fā)送的.

2．為什么TIME_WAIT狀態(tài)還需要等2MSL后才能返回到CLOSED狀態(tài)？

1.這是因?yàn)殡m然雙方都同意關(guān)閉連接了，而且握手的4個(gè)報(bào)文也都協(xié)調(diào)和發(fā)送完畢，按理可以直接回到CLOSED狀態(tài)（就好比從SYN_SEND狀態(tài)到ESTABLISH狀態(tài)那樣）；
2.但是因?yàn)槲覀儽仨氁傧刖W(wǎng)絡(luò)是不可靠的，你無法保證你最后發(fā)送的ACK報(bào)文會(huì)一定被對(duì)方收到，因此對(duì)方處于LAST_ACK狀態(tài)下的SOCKET可能會(huì)因?yàn)槌瑫r(shí)未收到ACK報(bào)文，而重發(fā)FIN報(bào)文，所以這個(gè)TIME_WAIT狀態(tài)的作用就是用來重發(fā)可能丟失的ACK報(bào)文。

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是基于連接的協(xié)議，也就是說，在正式收發(fā)數(shù)據(jù)前，必須和對(duì)方建立可靠的連接。一個(gè)TCP連接必須要經(jīng)過三次“對(duì)話”才能建立起來

UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）是與TCP相對(duì)應(yīng)的協(xié)議。它是面向非連接的協(xié)議，它不與對(duì)方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過去！
UDP適用于一次只傳送少量數(shù)據(jù)、對(duì)可靠性要求不高的應(yīng)用環(huán)境。

1.創(chuàng)建XMLHttpRequest對(duì)象,也就是創(chuàng)建一個(gè)異步調(diào)用對(duì)象；
2.通過XMLHttpRequest對(duì)象創(chuàng)建一個(gè)新的HTTP請(qǐng)求,并指定該HTTP請(qǐng)求的方法、URL及驗(yàn)證信息；
3.設(shè)置響應(yīng)HTTP請(qǐng)求狀態(tài)變化的函數(shù)；
4.發(fā)送HTTP請(qǐng)求；
5.獲取異步調(diào)用返回的數(shù)據(jù)；
6.使用JavaScript和DOM實(shí)現(xiàn)局部刷新.

1、var xhr = new XMLHttpRequest(); // 創(chuàng)建xhr對(duì)象
2、xhr.open("GET", "example.php");
3、xhr.onreadystatechange = function(){
　　if ( xhr.readyState == 4 && xhr.status == 200 ) {
　　　　　alert( xhr.responseText );
　　} else {
　　　　　alert( xhr.statusText );
　　}
};
xhr.setRequestHeader( ..., ... );
4、xhr.send();

readyState: unsigned short - 用于表示請(qǐng)求的五種狀態(tài)：

具體有關(guān)XMLHttpRequest內(nèi)容可查看文章你不知道的 XMLHttpRequest、HTTP 最強(qiáng)資料大全

ajax的缺點(diǎn)和在IE下的問題：

ajax不支持瀏覽器back按鈕。

安全問題 AJAX暴露了與服務(wù)器交互的細(xì)節(jié)。

對(duì)搜索引擎的支持比較弱。

破壞了程序的異常機(jī)制。

不容易調(diào)試。

worker主線程:Web Worker可以分為兩種不同線程類型，一個(gè)是專用線程，一個(gè)是共享線程。
使用限制：

Web Worker無法訪問DOM節(jié)點(diǎn)；

Web Worker無法訪問全局變量或是全局函數(shù)；

Web Worker無法調(diào)用alert()或者confirm之類的函數(shù)；

Web Worker無法訪問window、document之類的瀏覽器全局變量；

專用線程示例：

主線程代碼

/** 1. 創(chuàng)建專用線程 **/
var worker = new Worker("dedicated.js");
/** 2. 接收來至工作線程 **/
worker.onmessage = function (event) { ... };
/** 3.發(fā)送 ArrayBuffer 數(shù)據(jù)代碼 **/
worker.postMessage(10000);
/** 4.終止一個(gè)worker的執(zhí)行 **/
worker.terminate()；

------------------------------------------------

worker線程代碼

addEventListener("message", function(evt){  
var date = new Date();  
var currentDate = null;  
do {  
    currentDate = new Date();  
}while(currentDate - date < evt.data);  
    postMessage(currentDate);  
}, false);  

共享線程示例：

/** 1. 創(chuàng)建共享線程 **/
var worker = new SharedWorker("sharedworker.js", ’ mysharedworker ’ );
/** 2. 從端口接收數(shù)據(jù) , 包括文本數(shù)據(jù)以及結(jié)構(gòu)化數(shù)據(jù) **/
worker.port.onmessage = function (event) { define your logic here... }; 
/** 3. 向端口發(fā)送普通文本數(shù)據(jù) **/
 worker.port.postMessage("put your message here … "); 
/** 向端口發(fā)送結(jié)構(gòu)化數(shù)據(jù) **/
worker.port.postMessage({ username: "usertext"; live_city: 
["data-one", "data-two", "data-three","data-four"]});

socket:Websocket 其實(shí)是基于 HTML5 規(guī)范的一個(gè)新協(xié)議，它實(shí)現(xiàn)了瀏覽器與服務(wù)器全雙工通信，能更好的節(jié)省服務(wù)器資源和帶寬并達(dá)到實(shí)時(shí)通訊，它建立在 TCP 之上，同 HTTP 一樣通過 TCP 來傳輸數(shù)據(jù)。

WebSocket 是一種雙向通信協(xié)議，在建立連接后，WebSocket 服務(wù)器和 Browser/Client Agent 都能主動(dòng)的向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)，就像 Socket 一樣；

WebSocket 需要類似 TCP 的客戶端和服務(wù)器端通過握手連接，連接成功后才能相互通信。

HTTP請(qǐng)求與響應(yīng)交互圖：

WebSocket請(qǐng)求與響應(yīng)交互圖：

相對(duì)于傳統(tǒng) HTTP 每次請(qǐng)求-應(yīng)答都需要客戶端與服務(wù)端建立連接的模式，WebSocket 是類似 Socket 的 TCP 長連接的通訊模式，一旦 WebSocket 連接建立后，后續(xù)數(shù)據(jù)都以幀序列的形式傳輸。在客戶端斷開 WebSocket 連接或 Server 端斷掉連接前，不需要客戶端和服務(wù)端重新發(fā)起連接請(qǐng)求。在海量并發(fā)及客戶端與服務(wù)器交互負(fù)載流量大的情況下，極大的節(jié)省了網(wǎng)絡(luò)帶寬資源的消耗，有明顯的性能優(yōu)勢，且客戶端發(fā)送和接受消息是在同一個(gè)持久連接上發(fā)起，實(shí)時(shí)性優(yōu)勢明顯。

WebSocket 通訊請(qǐng)求響應(yīng)報(bào)文：
客戶端連接報(bào)文：

可以看到，客戶端發(fā)起的 WebSocket 連接報(bào)文類似傳統(tǒng) HTTP 報(bào)文，"Upgrade：websocket"參數(shù)值表明這是 WebSocket 類型請(qǐng)求，“Sec-WebSocket-Key”是 WebSocket 客戶端發(fā)送的一個(gè) base64 編碼的密文，要求服務(wù)端必須返回一個(gè)對(duì)應(yīng)加密的“Sec-WebSocket-Accept”應(yīng)答，否則客戶端會(huì)拋出“Error during WebSocket handshake”錯(cuò)誤，并關(guān)閉連接。

服務(wù)端響應(yīng)報(bào)文：

“Sec-WebSocket-Accept”的值是服務(wù)端采用與客戶端一致的密鑰計(jì)算出來后返回客戶端的。,“HTTP/1.1 101 Switching Protocols”表示服務(wù)端接受 WebSocket 協(xié)議的客戶端連接，經(jīng)過這樣的請(qǐng)求-響應(yīng)處理后，客戶端服務(wù)端的 WebSocket 連接握手成功, 后續(xù)就可以進(jìn)行 TCP 通訊了。

WebSocket 實(shí)現(xiàn)：
支持瀏覽器：

實(shí)現(xiàn)代碼：

/** 申請(qǐng)一個(gè)WebSocket對(duì)象，參數(shù)為需要連接的服務(wù)端地址，協(xié)議的URL使用ws://開頭，安全的WebSocket協(xié)議使用wss://開頭 **/
var ws = new WebSocket("ws://...");

/** 當(dāng) Browser 和 WebSocketServer 連接成功后，會(huì)觸發(fā) onopen 消息 **/
ws.onopen = function(){ws.send(“Test!”);};

/** 如果連接失敗，發(fā)送、接收數(shù)據(jù)失敗或者處理數(shù)據(jù)出現(xiàn)錯(cuò)誤，browser 會(huì)觸發(fā) onerror 消息 **/
ws.onerror = function(evt){console.log("error")};

/** 當(dāng) Browser 接收到 WebSocketServer 發(fā)送過來的數(shù)據(jù)時(shí)，就會(huì)觸發(fā) onmessage 消息，參數(shù) evt 中包含 Server 傳輸過來的數(shù)據(jù) **/
ws.onmessage = function(evt){console.log(evt.data);ws.close();}; 

/** 當(dāng) Browser 接收到 WebSocketServer 端發(fā)送的關(guān)閉連接請(qǐng)求時(shí)，就會(huì)觸發(fā) onclose 消息 **/
 ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; 

所有的操作都是采用異步回調(diào)的方式觸發(fā)，這樣不會(huì)阻塞 UI，可以獲得更快的響應(yīng)時(shí)間，更好的用戶體驗(yàn)。

http中文叫超文本傳輸協(xié)議，是客戶端與服務(wù)端之間傳輸數(shù)據(jù)規(guī)定的一種協(xié)議，通常承載與TCP協(xié)議之上，基于請(qǐng)求與響應(yīng)模式的、無狀態(tài)的、應(yīng)用層的協(xié)議，?；赥CP的連接方式。
特點(diǎn)：

支持客戶/服務(wù)器模式；

簡單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快；

靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記；

無連接：無連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。

無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。在實(shí)際應(yīng)用當(dāng)中并不是完全這樣的，引入了Cookie和Session機(jī)制來關(guān)聯(lián)請(qǐng)求。

HTTP報(bào)文：
請(qǐng)求報(bào)文：由請(qǐng)求行、請(qǐng)求頭、請(qǐng)求體構(gòu)成，每一行的末尾都有回車和換行，在請(qǐng)求頭和請(qǐng)求體之間還有一個(gè)空行。

請(qǐng)求行指定由請(qǐng)求方法、請(qǐng)求URL、協(xié)議版本組成；

請(qǐng)求頭是由鍵值對(duì)形式存在的，例如content-type:application/json;

空行；

請(qǐng)求體就是要傳輸?shù)臄?shù)據(jù)；

響應(yīng)報(bào)文：由狀態(tài)行、響應(yīng)頭、響應(yīng)體組成。

狀態(tài)行由協(xié)議版本、狀態(tài)碼、狀態(tài)短語組成；

響應(yīng)頭也是由鍵值對(duì)形式存在，例如：
Content-Length: 563
Content-Type: text/html

空行；

響應(yīng)體即要傳輸?shù)臄?shù)據(jù)；

HTTP請(qǐng)求方法：

GET：獲取資源；

POST：傳輸實(shí)體主體； POST方法用來傳輸實(shí)體主體。POST與GET的區(qū)別之一就是目的不同，二者之間的區(qū)別會(huì)在文章的最后詳細(xì)說明。雖然GET方法也可以傳輸，但是一般不用，因?yàn)镚ET的目的是獲取，POST的目的是傳輸。

PUT：傳輸文件； PUT方法用來傳輸文件。類似FTP協(xié)議，文件內(nèi)容包含在請(qǐng)求報(bào)文的實(shí)體中，然后請(qǐng)求保存到URL指定的服務(wù)器位置。

HEAD：獲得報(bào)文首部； HEAD方法類似GET方法，但是不同的是HEAD方法不要求返回?cái)?shù)據(jù)。用于確認(rèn)URI的有效性及資源更新時(shí)間等。

DELETE：刪除文件； DELETE方法用來刪除文件，是與PUT相反的方法。DELETE是要求返回URL指定的資源。

OPTIONS：詢問支持的方法； 因?yàn)椴⒉皇撬械姆?wù)器都支持規(guī)定的方法，為了安全有些服務(wù)器可能會(huì)禁止掉一些方法例如DELETE、PUT等。那么OPTIONS就是用來詢問服務(wù)器支持的方法。

TRACE：追蹤路徑； TRACE方法是讓W(xué)eb服務(wù)器將之前的請(qǐng)求通信還回給客戶端的方法。這個(gè)方法并不常用。

CONNECT：要求用隧道協(xié)議連接代理； CONNECT方法要求在與代理服務(wù)器通信時(shí)建立隧道，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行TCP通信。主要使用SSL/TLS協(xié)議對(duì)通信內(nèi)容加密后傳輸。

HTTP的響應(yīng)狀態(tài)碼：

get和post區(qū)別：

get請(qǐng)求數(shù)據(jù)會(huì)附加在url之后，以？分割url地址和傳輸數(shù)據(jù)，多個(gè)參數(shù)用&鏈接。傳輸數(shù)據(jù)會(huì)受到url長度的限制。并且get請(qǐng)求由于把請(qǐng)求數(shù)據(jù)都放在URL上，這樣很容易被他人拿到數(shù)據(jù)。比如登錄頁面，用戶名和密碼都會(huì)暴露在URL上。

post請(qǐng)求會(huì)把數(shù)據(jù)放在請(qǐng)求實(shí)體中，這樣理論上是沒有大小限制，并且POST可能會(huì)修改服務(wù)器上的資源的請(qǐng)求。

常用狀態(tài)碼：

200：OK；
代表請(qǐng)求被正常的處理成功了。

204：No Content；
請(qǐng)求處理成功，但是沒有數(shù)據(jù)實(shí)體返回，也不允許有實(shí)體返回。比如說HEAD請(qǐng)求，可能就會(huì)返回204 No Content，因?yàn)镠EAD就是只獲取頭信息。

205：Reset Content；
不但沒有數(shù)據(jù)實(shí)體返回，而且還需要重置表單，方便用戶再次輸入。

206：Partial Content；
這是客戶端使用Content-Range指定了需要的實(shí)體數(shù)據(jù)的范圍，然后服務(wù)端處理請(qǐng)求成功之后返回用戶需要的這一部分?jǐn)?shù)據(jù)而不是全部，執(zhí)行的請(qǐng)求就是GET。

301：Moved Permanently；
代表永久性定向。該狀態(tài)碼表示請(qǐng)求的資源已經(jīng)被分配了新的URL，以后應(yīng)該使用資源現(xiàn)在指定的URL。也就是說如果已經(jīng)把資源對(duì)應(yīng)的URL保存為書簽了，這是應(yīng)該按照Location首部字段提示的URL重新保存。

302：Found；
代表臨時(shí)重定向。該狀態(tài)碼表示請(qǐng)求的資源已經(jīng)被分配了新的URL，但是和301的區(qū)別是302代表的不是永久性的移動(dòng)，只是臨時(shí)的。就是說這個(gè)URL還可能會(huì)發(fā)生改變。如果保存成書簽了也不會(huì)更新。

303：See Other；
和302的區(qū)別是303明確規(guī)定客戶端應(yīng)當(dāng)使用GET方法。

304：Not Modified；
該狀態(tài)碼表示客戶端發(fā)送附帶條件請(qǐng)求時(shí)，服務(wù)器端允許請(qǐng)求訪問資源，但是沒有滿足條件,瀏覽器在接收到個(gè)狀態(tài)碼后，會(huì)使用瀏覽器已緩存的文件。304狀態(tài)碼返回時(shí)不包含任何數(shù)據(jù)實(shí)體。304雖然被劃分在3XX中但是和重定向沒有關(guān)系。

客戶端請(qǐng)求一個(gè)頁面（A）。 服務(wù)器返回頁面A，并在給A加上一個(gè)ETag。 客戶端展現(xiàn)該頁面，并將頁面連同ETag一起緩存。
客戶再次請(qǐng)求頁面A，并將上次請(qǐng)求時(shí)服務(wù)器返回的ETag一起傳遞給服務(wù)器。
服務(wù)器檢查該ETag，并判斷出該頁面自上次客戶端請(qǐng)求之后還未被修改，直接返回響應(yīng)304（未修改——Not
Modified）和一個(gè)空的響應(yīng)體。

307：Temporary Redirect；
臨時(shí)重定向，與302 Found相同，但是302會(huì)把POST改成GET，而307就不會(huì)。

400：Bad Request；
400表示請(qǐng)求報(bào)文中存在語法錯(cuò)誤。需要修改后再次發(fā)送。

401：Unauthorized；
該狀態(tài)碼表示未授權(quán)，請(qǐng)求要求身份驗(yàn)證。對(duì)于登錄后請(qǐng)求的網(wǎng)頁，服務(wù)器可能返回此響應(yīng)。

403：Forbidden；
表明請(qǐng)求訪問的資源被拒絕了。沒有獲得服務(wù)器的訪問權(quán)限，IP被禁止等。

404：Not Found；
表明請(qǐng)求的資源在服務(wù)器上找不到。當(dāng)然也可以在服務(wù)器拒絕請(qǐng)求且不想說明理由時(shí)使用。

408：Request Timeout；
表示客戶端請(qǐng)求超時(shí)，就是在客戶端和服務(wù)器建立連接后服務(wù)器在一定時(shí)間內(nèi)沒有收到客戶端的請(qǐng)求。

500：Internal Server Error；
表明服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤，很有可能是服務(wù)端程序的Bug或者臨時(shí)故障。

503：Service Unavailable；
表明服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無法處理請(qǐng)求。如果事先得知解除以上狀況需要的時(shí)間，最好寫入Retry-After字段再返回給客戶端。

504：Getaway Timeout；
網(wǎng)關(guān)超時(shí)，是代理服務(wù)器等待應(yīng)用服務(wù)器響應(yīng)時(shí)的超時(shí)，和408 Request Timeout的卻別就是504是服務(wù)器的原因而不是客戶端的原因。

HTTP協(xié)議通常承載于TCP協(xié)議之上，在HTTP和TCP之間添加一個(gè)安全協(xié)議層（SSL或TSL），這個(gè)時(shí)候，就成了我們常說的HTTPS。
默認(rèn)HTTP的端口號(hào)為80，HTTPS的端口號(hào)為443。

為什么HTTPS安全？
因?yàn)榫W(wǎng)絡(luò)請(qǐng)求需要中間有很多的服務(wù)器路由器的轉(zhuǎn)發(fā)。中間的節(jié)點(diǎn)都可能篡改信息，而如果使用HTTPS，密鑰在你和終點(diǎn)站才有。https之所以比http安全，是因?yàn)樗胹sl/tls協(xié)議傳輸。它包含證書，卸載，流量轉(zhuǎn)發(fā)，負(fù)載均衡，頁面適配，瀏覽器適配，refer傳遞等，保障了傳輸過程的安全性。

瀏覽器通過DNS查詢查找出域名的IP地址：瀏覽器緩存 >> 系統(tǒng)緩存 >> 路由器緩存 >> ISP DNS 緩存 >> 遞歸搜索

通過TCP三次握手與服務(wù)器建立連接；

瀏覽器發(fā)送http請(qǐng)求報(bào)文；

服務(wù)器返回http響應(yīng)報(bào)文；

斷開TCP連接；

瀏覽器解析HTML/SVG/XHTML，解析這三種文件產(chǎn)生一個(gè) DOM Tree；

在瀏覽器顯示HTML時(shí)，它會(huì)注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí)，瀏覽器會(huì)發(fā)送一個(gè)獲取請(qǐng)求來重新獲得這些文件。這些文件就包括CSS/JS/圖片等資源，這些資源的地址都要經(jīng)歷一個(gè)和HTML讀取類似的過程。所以瀏覽器會(huì)在DNS中查找這些域名，發(fā)送請(qǐng)求，重定向等等…；

瀏覽器解析 CSS 會(huì)產(chǎn)生 CSS 規(guī)則樹；

解析JavaScript腳本，主要是通過 DOM API 和 CSSOM API 來操作 DOM Tree 和 CSS Rule Tree

瀏覽器解析渲染過程是逐步完成的，為了更好的用戶體驗(yàn)，渲染引擎將會(huì)盡可能早的將內(nèi)容呈現(xiàn)到屏幕上，并不會(huì)等到所有的html都解析完成之后再去構(gòu)建和布局render樹。它是解析完一部分內(nèi)容就顯示一部分內(nèi)容，同時(shí)，可能還在通過網(wǎng)絡(luò)下載其余內(nèi)容。

Reflow（回流）：瀏覽器要花時(shí)間去渲染，當(dāng)它發(fā)現(xiàn)了某個(gè)部分發(fā)生了變化影響了布局，那就需要倒回去重新渲染。

Repaint（重繪）：如果只是改變了某個(gè)元素的背景顏色，文字顏色等，不影響元素周圍或內(nèi)部布局的屬性，將只會(huì)引起瀏覽器的repaint，重畫某一部分。

編寫CSS注意事項(xiàng)：
CSS選擇符是從右到左進(jìn)行匹配的。#nav li 會(huì)去找所有的li，然后再去確定它的父元素是不是#nav。

dom深度盡量淺；

減少inline javascript、css的數(shù)量；

使用現(xiàn)代合法的css屬性；

不要為id選擇器指定類名或是標(biāo)簽，因?yàn)閕d可以唯一確定一個(gè)元素；

避免后代選擇符，盡量使用子選擇符。原因：子元素匹配符的概率要大于后代元素匹配符。后代選擇符;#tp p{} 子選擇符：#tp>p{}；

避免使用通配符，舉一個(gè)例子，.mod .hd *{font-size:14px;} 根據(jù)匹配順序,將首先匹配通配符,也就是說先匹配出通配符,然后匹配.hd（就是要對(duì)dom樹上的所有節(jié)點(diǎn)進(jìn)行遍歷他的父級(jí)元素）,然后匹配.mod,這樣的性能耗費(fèi)可想而知.

script標(biāo)簽為什么要放在body結(jié)束標(biāo)簽之前？

因?yàn)閖s的下載和執(zhí)行會(huì)阻塞Dom樹的構(gòu)建。

載入后馬上執(zhí)行；

執(zhí)行時(shí)會(huì)阻塞頁面后續(xù)的內(nèi)容（包括頁面的渲染、其它資源的下載）。原因：因?yàn)闉g覽器需要一個(gè)穩(wěn)定的DOM樹結(jié)構(gòu)，而JS中很有可能有 代碼直接改變了DOM樹結(jié)構(gòu)，比如使用 document.write 或appendChild,甚至是直接使用的location.href進(jìn)行跳轉(zhuǎn)，瀏覽器為了防止出現(xiàn)JS修改DOM樹，需要重新構(gòu)建DOM樹的情況，所以 就會(huì)阻塞其他的下載和呈現(xiàn)。

減少 JavaScript 對(duì)性能的影響的方法：

將所有的script標(biāo)簽放到頁面底部，也就是body閉合標(biāo)簽之前，這能確保在腳本執(zhí)行前頁面已經(jīng)完成了DOM樹渲染。

盡可能地合并腳本。頁面中的script標(biāo)簽越少，加載也就越快，響應(yīng)也越迅速。無論是外鏈腳本還是內(nèi)嵌腳本都是如此。

采用無阻塞下載 JavaScript 腳本的方法：
(1)、使用script標(biāo)簽的 defer 屬性（僅適用于 IE 和 Firefox 3.5 以上版本）；
(2)、使用動(dòng)態(tài)創(chuàng)建的script元素來下載并執(zhí)行代碼；
(3)、按需異步載入js;

SessionStorage 和 localStorage 是HTML5 storage API 提供的， 可以把數(shù)據(jù)保存在本地，避免了數(shù)據(jù)在瀏覽器和服務(wù)器之間不必要的通信。sessionStorage，localStorage， cookie 都是在瀏覽器存儲(chǔ)的數(shù)據(jù)。

不同：

cookie數(shù)據(jù)始終在同源http中攜帶，即使不需要，也會(huì)在瀏覽器和服務(wù)器間來回傳遞。Storage只存在本地；

cookie數(shù)據(jù)有路徑概念，可以限制cookie只能在某路徑下；

cookie：4k Storage：5M；

sessionStorage： 僅在當(dāng)前瀏覽器關(guān)閉前有效，localStorage：始終有效，cookie：過期之前有效；

sessionStorage：在打開的不同瀏覽器窗口不共享，即使同一頁面，localStorage：在同源頁面共享，cookie：同源頁面共享

待續(xù).....2017.5.31