摘要：如何解決跨域問題跨域原因由于瀏覽器的同源策略限制，只允許請求當前源域名協議端口的資源。同源策略同源策略是客戶端腳本尤其是的重要的安全度量標準。同源策略指的是協議，域名，端口相同，同源策略是一種安全協議。狀態表示客戶端已發送報文。

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

跨域的幾種方式：

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

進階問題：
1，JSONP需要動態創建script標簽，需不需要處理這些script元素？怎么處理？
需要，可以監聽script標簽的加載狀態，當失敗或加載完成后移除script標簽并移除標簽上的監聽事件，以及掛載在window上的回調函數。

2，JSONP請求的時候，服務器發生錯誤該怎么辦，前端怎么處理這個錯誤？
一般前端框架都會對跨域請求失敗是進行處理，比如JQuery中，當使用ajax或getJSON發送請求后會返回一個jqXHR對象。該對象實現了Promise協議，所以我們可以使用它的done、fail、always等接口來處理回調。例如我們可以用在它的fail回調中進行請求失敗時的錯誤處理：

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

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

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

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

www.domain.com下b.html頁：

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

點擊我通過iframe框架向http://www.lamport.me/data2.html頁面發送并返回數據

www.domain.com下b.html頁：

6>、另可通過filder工具，或者本地起node來實現跨域。

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

/** XML **/


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


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

ACK:TCP協議規定，只有ACK=1時有效，也規定連接建立后所有發送的報文的ACK必須為1;
SYN: 在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文。對方若同意建立連接，則應在響應報文中使SYN=1和ACK=1. 因此, SYN置1就表示這是一個連接請求或連接接受報文。
FIN:即完，終結的意思， 用來釋放一個連接。當 FIN = 1 時，表明此報文段的發送方的數據已經發送完畢，并要求釋放連接。

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

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

一個完整的三次握手就是：請求---應答----再次確認----服務端收到確認建立連接

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

若在握手過程中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包。

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

1、為什么建立連接時三次握手，關閉連接是4次握手？

1.這是因為服務端的LISTEN狀態下的SOCKET當收到SYN報文的建連請求后，它可以把ACK和SYN（ACK起應答作用，而SYN起同步作用）放在一個報文里來發送。
2.但關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方沒有數據發送給你了；但未必你所有的數據都全部發送給對方了，所以你未必會馬上會關閉SOCKET,也即你可能還需要發送一些數據給對方之后，再發送FIN報文給對方來表示你同意現在可以關閉連接了，所以它這里的ACK報文和FIN報文多數情況下都是分開發送的.

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

1.這是因為雖然雙方都同意關閉連接了，而且握手的4個報文也都協調和發送完畢，按理可以直接回到CLOSED狀態（就好比從SYN_SEND狀態到ESTABLISH狀態那樣）；
2.但是因為我們必須要假想網絡是不可靠的，你無法保證你最后發送的ACK報文會一定被對方收到，因此對方處于LAST_ACK狀態下的SOCKET可能會因為超時未收到ACK報文，而重發FIN報文，所以這個TIME_WAIT狀態的作用就是用來重發可能丟失的ACK報文。

TCP（Transmission Control Protocol，傳輸控制協議）是基于連接的協議，也就是說，在正式收發數據前，必須和對方建立可靠的連接。一個TCP連接必須要經過三次“對話”才能建立起來

UDP（User Data Protocol，用戶數據報協議）是與TCP相對應的協議。它是面向非連接的協議，它不與對方建立連接，而是直接就把數據包發送過去！
UDP適用于一次只傳送少量數據、對可靠性要求不高的應用環境。

1.創建XMLHttpRequest對象,也就是創建一個異步調用對象；
2.通過XMLHttpRequest對象創建一個新的HTTP請求,并指定該HTTP請求的方法、URL及驗證信息；
3.設置響應HTTP請求狀態變化的函數；
4.發送HTTP請求；
5.獲取異步調用返回的數據；
6.使用JavaScript和DOM實現局部刷新.

1、var xhr = new XMLHttpRequest(); // 創建xhr對象
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 - 用于表示請求的五種狀態：

具體有關XMLHttpRequest內容可查看文章你不知道的 XMLHttpRequest、HTTP 最強資料大全

ajax的缺點和在IE下的問題：

ajax不支持瀏覽器back按鈕。

安全問題 AJAX暴露了與服務器交互的細節。

對搜索引擎的支持比較弱。

破壞了程序的異常機制。

不容易調試。

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

Web Worker無法訪問DOM節點；

Web Worker無法訪問全局變量或是全局函數；

Web Worker無法調用alert()或者confirm之類的函數；

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

專用線程示例：

主線程代碼

/** 1. 創建專用線程 **/
var worker = new Worker("dedicated.js");
/** 2. 接收來至工作線程 **/
worker.onmessage = function (event) { ... };
/** 3.發送 ArrayBuffer 數據代碼 **/
worker.postMessage(10000);
/** 4.終止一個worker的執行 **/
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. 創建共享線程 **/
var worker = new SharedWorker("sharedworker.js", ’ mysharedworker ’ );
/** 2. 從端口接收數據 , 包括文本數據以及結構化數據 **/
worker.port.onmessage = function (event) { define your logic here... }; 
/** 3. 向端口發送普通文本數據 **/
 worker.port.postMessage("put your message here … "); 
/** 向端口發送結構化數據 **/
worker.port.postMessage({ username: "usertext"; live_city: 
["data-one", "data-two", "data-three","data-four"]});

socket:Websocket 其實是基于 HTML5 規范的一個新協議，它實現了瀏覽器與服務器全雙工通信，能更好的節省服務器資源和帶寬并達到實時通訊，它建立在 TCP 之上，同 HTTP 一樣通過 TCP 來傳輸數據。

WebSocket 是一種雙向通信協議，在建立連接后，WebSocket 服務器和 Browser/Client Agent 都能主動的向對方發送或接收數據，就像 Socket 一樣；

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

HTTP請求與響應交互圖：

WebSocket請求與響應交互圖：

相對于傳統 HTTP 每次請求-應答都需要客戶端與服務端建立連接的模式，WebSocket 是類似 Socket 的 TCP 長連接的通訊模式，一旦 WebSocket 連接建立后，后續數據都以幀序列的形式傳輸。在客戶端斷開 WebSocket 連接或 Server 端斷掉連接前，不需要客戶端和服務端重新發起連接請求。在海量并發及客戶端與服務器交互負載流量大的情況下，極大的節省了網絡帶寬資源的消耗，有明顯的性能優勢，且客戶端發送和接受消息是在同一個持久連接上發起，實時性優勢明顯。

WebSocket 通訊請求響應報文：
客戶端連接報文：

可以看到，客戶端發起的 WebSocket 連接報文類似傳統 HTTP 報文，"Upgrade：websocket"參數值表明這是 WebSocket 類型請求，“Sec-WebSocket-Key”是 WebSocket 客戶端發送的一個 base64 編碼的密文，要求服務端必須返回一個對應加密的“Sec-WebSocket-Accept”應答，否則客戶端會拋出“Error during WebSocket handshake”錯誤，并關閉連接。

服務端響應報文：

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

WebSocket 實現：
支持瀏覽器：

實現代碼：

/** 申請一個WebSocket對象，參數為需要連接的服務端地址，協議的URL使用ws://開頭，安全的WebSocket協議使用wss://開頭 **/
var ws = new WebSocket("ws://...");

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

/** 如果連接失敗，發送、接收數據失敗或者處理數據出現錯誤，browser 會觸發 onerror 消息 **/
ws.onerror = function(evt){console.log("error")};

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

/** 當 Browser 接收到 WebSocketServer 端發送的關閉連接請求時，就會觸發 onclose 消息 **/
 ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; 

所有的操作都是采用異步回調的方式觸發，這樣不會阻塞 UI，可以獲得更快的響應時間，更好的用戶體驗。

http中文叫超文本傳輸協議，是客戶端與服務端之間傳輸數據規定的一種協議，通常承載與TCP協議之上，基于請求與響應模式的、無狀態的、應用層的協議，常基于TCP的連接方式。
特點：

支持客戶/服務器模式；

簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快；

靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記；

無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。

無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。在實際應用當中并不是完全這樣的，引入了Cookie和Session機制來關聯請求。

HTTP報文：
請求報文：由請求行、請求頭、請求體構成，每一行的末尾都有回車和換行，在請求頭和請求體之間還有一個空行。

請求行指定由請求方法、請求URL、協議版本組成；

請求頭是由鍵值對形式存在的，例如content-type:application/json;

空行；

請求體就是要傳輸的數據；

響應報文：由狀態行、響應頭、響應體組成。

狀態行由協議版本、狀態碼、狀態短語組成；

響應頭也是由鍵值對形式存在，例如：
Content-Length: 563
Content-Type: text/html

空行；

響應體即要傳輸的數據；

HTTP請求方法：

GET：獲取資源；

POST：傳輸實體主體； POST方法用來傳輸實體主體。POST與GET的區別之一就是目的不同，二者之間的區別會在文章的最后詳細說明。雖然GET方法也可以傳輸，但是一般不用，因為GET的目的是獲取，POST的目的是傳輸。

PUT：傳輸文件； PUT方法用來傳輸文件。類似FTP協議，文件內容包含在請求報文的實體中，然后請求保存到URL指定的服務器位置。

HEAD：獲得報文首部； HEAD方法類似GET方法，但是不同的是HEAD方法不要求返回數據。用于確認URI的有效性及資源更新時間等。

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

OPTIONS：詢問支持的方法； 因為并不是所有的服務器都支持規定的方法，為了安全有些服務器可能會禁止掉一些方法例如DELETE、PUT等。那么OPTIONS就是用來詢問服務器支持的方法。

TRACE：追蹤路徑； TRACE方法是讓Web服務器將之前的請求通信還回給客戶端的方法。這個方法并不常用。

CONNECT：要求用隧道協議連接代理； CONNECT方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行TCP通信。主要使用SSL/TLS協議對通信內容加密后傳輸。

HTTP的響應狀態碼：

get和post區別：

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

post請求會把數據放在請求實體中，這樣理論上是沒有大小限制，并且POST可能會修改服務器上的資源的請求。

常用狀態碼：

200：OK；
代表請求被正常的處理成功了。

204：No Content；
請求處理成功，但是沒有數據實體返回，也不允許有實體返回。比如說HEAD請求，可能就會返回204 No Content，因為HEAD就是只獲取頭信息。

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

206：Partial Content；
這是客戶端使用Content-Range指定了需要的實體數據的范圍，然后服務端處理請求成功之后返回用戶需要的這一部分數據而不是全部，執行的請求就是GET。

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

302：Found；
代表臨時重定向。該狀態碼表示請求的資源已經被分配了新的URL，但是和301的區別是302代表的不是永久性的移動，只是臨時的。就是說這個URL還可能會發生改變。如果保存成書簽了也不會更新。

303：See Other；
和302的區別是303明確規定客戶端應當使用GET方法。

304：Not Modified；
該狀態碼表示客戶端發送附帶條件請求時，服務器端允許請求訪問資源，但是沒有滿足條件,瀏覽器在接收到個狀態碼后，會使用瀏覽器已緩存的文件。304狀態碼返回時不包含任何數據實體。304雖然被劃分在3XX中但是和重定向沒有關系。

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

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

400：Bad Request；
400表示請求報文中存在語法錯誤。需要修改后再次發送。

401：Unauthorized；
該狀態碼表示未授權，請求要求身份驗證。對于登錄后請求的網頁，服務器可能返回此響應。

403：Forbidden；
表明請求訪問的資源被拒絕了。沒有獲得服務器的訪問權限，IP被禁止等。

404：Not Found；
表明請求的資源在服務器上找不到。當然也可以在服務器拒絕請求且不想說明理由時使用。

408：Request Timeout；
表示客戶端請求超時，就是在客戶端和服務器建立連接后服務器在一定時間內沒有收到客戶端的請求。

500：Internal Server Error；
表明服務器端在執行請求時發生了錯誤，很有可能是服務端程序的Bug或者臨時故障。

503：Service Unavailable；
表明服務器暫時處于超負載或正在進行停機維護，現在無法處理請求。如果事先得知解除以上狀況需要的時間，最好寫入Retry-After字段再返回給客戶端。

504：Getaway Timeout；
網關超時，是代理服務器等待應用服務器響應時的超時，和408 Request Timeout的卻別就是504是服務器的原因而不是客戶端的原因。

HTTP協議通常承載于TCP協議之上，在HTTP和TCP之間添加一個安全協議層（SSL或TSL），這個時候，就成了我們常說的HTTPS。
默認HTTP的端口號為80，HTTPS的端口號為443。

為什么HTTPS安全？
因為網絡請求需要中間有很多的服務器路由器的轉發。中間的節點都可能篡改信息，而如果使用HTTPS，密鑰在你和終點站才有。https之所以比http安全，是因為他利用ssl/tls協議傳輸。它包含證書，卸載，流量轉發，負載均衡，頁面適配，瀏覽器適配，refer傳遞等，保障了傳輸過程的安全性。

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

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

瀏覽器發送http請求報文；

服務器返回http響應報文；

斷開TCP連接；

瀏覽器解析HTML/SVG/XHTML，解析這三種文件產生一個 DOM Tree；

在瀏覽器顯示HTML時，它會注意到需要獲取其他地址內容的標簽。這時，瀏覽器會發送一個獲取請求來重新獲得這些文件。這些文件就包括CSS/JS/圖片等資源，這些資源的地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名，發送請求，重定向等等…；

瀏覽器解析 CSS 會產生 CSS 規則樹；

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

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

Reflow（回流）：瀏覽器要花時間去渲染，當它發現了某個部分發生了變化影響了布局，那就需要倒回去重新渲染。

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

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

dom深度盡量淺；

減少inline javascript、css的數量；

使用現代合法的css屬性；

不要為id選擇器指定類名或是標簽，因為id可以唯一確定一個元素；

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

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

script標簽為什么要放在body結束標簽之前？

因為js的下載和執行會阻塞Dom樹的構建。

載入后馬上執行；

執行時會阻塞頁面后續的內容（包括頁面的渲染、其它資源的下載）。原因：因為瀏覽器需要一個穩定的DOM樹結構，而JS中很有可能有 代碼直接改變了DOM樹結構，比如使用 document.write 或appendChild,甚至是直接使用的location.href進行跳轉，瀏覽器為了防止出現JS修改DOM樹，需要重新構建DOM樹的情況，所以 就會阻塞其他的下載和呈現。

減少 JavaScript 對性能的影響的方法：

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

盡可能地合并腳本。頁面中的script標簽越少，加載也就越快，響應也越迅速。無論是外鏈腳本還是內嵌腳本都是如此。

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

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

不同：

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

cookie數據有路徑概念，可以限制cookie只能在某路徑下；

cookie：4k Storage：5M；

sessionStorage： 僅在當前瀏覽器關閉前有效，localStorage：始終有效，cookie：過期之前有效；

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

待續.....2017.5.31