計算機網絡相關知識

1、常見狀態碼

1. 消息

100 Continue：客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。

2. 成功

200 OK：請求已成功，請求所但願的響應頭或數據體將隨此響應返回。出現此狀態碼是表示正常狀態。201 Created：請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其 URI 已經隨Location 頭信息返回。假如須要的資源沒法及時創建的話，應當返回 '202 Accepted'。

202 Accepted：服務器已接受請求，但還沒有處理。正如它可能被拒絕同樣，最終該請求可能會也可能不會被執行。在異步操做的場合下，沒有比發送這個狀態碼更方便的作法了。

3. 重定向

301 Moved Permanently：被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。

新的永久性的URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。

若是這不是一個 GET 或者 HEAD 請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求獲得了一個301響應的話，接下來的重定向請求將會變成 GET 方式。

302 Move Temporarily：請求的資源臨時從不一樣的 URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。上文有說起。

若是這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。

注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。

303 See Other：對應當前請求的響應能夠在另外一個 URL 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。

注意：許多 HTTP/1.1 版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。

304 Not Modified：若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。

該響應必須包含如下的頭信息：

Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。

ETag 和/或 Content-Location，假如一樣的請求本應返回200響應。

Expires, Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。

假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。

假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。

假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。

4. 請求錯誤

400 Bad Request：語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。請求參數有誤。

401 Unauthorized：當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。參見RFC 2617。

403 Forbidden：服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個 HEAD 請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。

404 Not Found：請求失敗，請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。出現這個錯誤的最有可能的緣由是服務器端沒有這個頁面。

405 Method Not Allowed：請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。

鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。

406 Not Acceptable：請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。

5. 服務器錯誤

500 Internal Server Error：服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器端的源代碼出現錯誤時出現。

501 Not Implemented：服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。

502 Bad Gateway：做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

503 Service Unavailable：因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理500響應的方式處理它。

注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是但願拒絕客戶端的鏈接。

504 Gateway Timeout：做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。

注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤

505 HTTP Version Not Supported：服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。

2、緩存

1. 瀏覽器緩存

· 200 OK (from cache) ——強制緩存，指的是瀏覽器沒有跟服務器確認，直接用了瀏覽器緩存。經過設置 expires/cache-control 來實現的。雖然是強緩存，但用戶主動觸發的刷新行爲，仍是會採用緩存協商的策略，主動觸發的刷新行爲包括點擊刷新按鈕、右鍵刷新、f5刷新、ctrl+f5刷新等。
· 304 Not Modified——協商緩存，比 200 OK (from cache) 慢，指的是瀏覽器還向服務器確認了下 "If-Not-Modified"，才用的緩存。

（1）Last-Modified：表示文檔的最後修改時間，當去服務器驗證時會拿這個時間去；
（2）Expires：http/1.0規範定義，表示文檔在瀏覽器中的過時時間，當緩存的內容超過這個時間則須要從新去服務器獲取最新的內容；
（3）Cache-Control：http/1.1規範定義，表示瀏覽器緩存控制，max-age=3153600表示文檔能夠在瀏覽器中緩存一年。

Last-Modified：在瀏覽器第一次請求某一個URL時，服務器端的返回狀態會是200，資源響應頭有一個Last-Modified的屬性標記此文件在服務期端最後被修改的時間，另一半也有個Etag。

HTTP中，經過Cache-Control首部和Expires首部爲文檔指定了過時時間，經過對過時時間的判斷，緩存就能夠知道文檔是否是在保質期內。

Last-Modified（Etag）
（1）Last-Modified ： http1.0時期屬性， 如今仍在使用。
（2）ETag（Entity Tag） http1.1時期新加屬性 。由於如下幾個緣由增長此屬性：

• 某些服務器不能精確獲得文件的最後修改時間， 這樣就沒法經過最後修改時間來判斷文件是否更新了。
• 某些文件的修改很是頻繁，在秒如下的時間內進行修改. Last-Modified只能精確到秒。
• 一些文件的最後修改時間改變了，可是內容並未改變。 咱們不但願客戶端認爲這個文件修改了。

Last-Modified與ETag同時使用時，瀏覽器在驗證時會同時發送If-Modified-Since和If-None-Match，按照http/1.1規範，若是同時使用If-Modified-Since和If-None-Match則服務端必須兩個都驗證經過後才能返回304；且nginx就是這樣作的。所以實際使用時應該根據實際狀況選擇。
分佈式的Web系統中，當訪問落在不一樣的物理機上時會返回不一樣的ETag，進而致使304失效，降級爲200請求,因此常常在使用中會關閉ETag。

Cache-Control(expires)
（1）Pragma : no-cache http1.0時期的屬性 爲了兼容會使用
（2）expires：0 http1.0時期的屬性 ，如今默認瀏覽器均默認使用HTTP 1.1，因此它的做用基本忽略。expires 的一個缺點就是，返回的到期時間是服務器端的時間，這樣存在一個問題，若是客戶端的時間與服務器的時間相差很大（好比時鐘不一樣步，或者跨時區），那麼偏差就很大，因此在HTTP 1.1版開始，使用Cache-Control: max-age=秒替代。
（3）Cache-Control http1.1 中加入的新屬性，它有如下經常使用參數：

• Public/Private 私有緩存/共有緩存
• no-cache：不建議使用本地緩存，但仍然會緩存到本地。雖然不使用本地緩存。須要使用緩存協商，先與服務器確認返回的響應是否被更改，若是以前的響應中存在ETag，那麼請求的時候會與服務端驗證，若是資源未被更改，則能夠避免從新下載。
• no-store：不會在客戶端緩存任何數據
• max-age：比較特殊，是一個混合屬性，替代了Expires的過時時間

2. 301,302重定向

2.1 共同點和不一樣點

• 301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址能夠從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另外一個地址B）

• 301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換爲重定向以後的網址；
• 302表示舊地址A的資源還在（仍然能夠訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址

2.2 應用場景

• 場景一 想換個域名，舊的域名不用啦，這樣用戶訪問舊域名時用301就重定向到新的域名。其實也是告訴搜索引擎收錄的域名須要對新的域名進行收錄。

• 場景二 登陸後重定向到指定的頁面，這種場景比較常見就是登陸成功跳轉到具體的系統頁面。

• 場景三 有時候須要自動刷新頁面，好比5秒後回到訂單詳細頁面之類。

• 場景四 有時系統進行升級或者切換某些功能時，須要臨時更換地址。

• 場景五 像微博之類的使用短域名，用戶瀏覽後須要重定向到真實的地址之類。

2.3 301與302在選擇上注意的問題——302 重定向和網址劫持（URL hijacking）

從網址A 作一個302 重定向到網址B 時，主機服務器的隱含意思是網址A 隨時有可能改主意，從新顯示自己的內容或轉向其餘的地方。大部分的搜索引擎在大部分狀況下，當收到302重定向時，通常只要去抓取目標網址就能夠了，也就是說網址B。若是搜索引擎在遇到302 轉向時，百分之百的都抓取目標網址B 的話，就不用擔憂網址URL 劫持了。問題就在於，有的時候搜索引擎，尤爲是Google，並不能老是抓取目標網址。好比說，有的時候A 網址很短，可是它作了一個302重定向到B網址，而B網址是一個很長的亂七八糟的URL網址，甚至還有可能包含一些問號之類的參數。很天然的，A網址更加用戶友好，而B網址既難看，又不用戶友好。這時Google頗有可能會仍然顯示網址A。因爲搜索引擎排名算法只是程序而不是人，在遇到302重定向的時候，並不能像人同樣的去準確斷定哪個網址更適當，這就形成了網址URL劫持的可能性。也就是說，一個不道德的人在他本身的網址A作一個302重定向到你的網址B，出於某種緣由， Google搜索結果所顯示的仍然是網址A，可是所用的網頁內容倒是你的網址B上的內容，這種狀況就叫作網址URL 劫持。你辛辛苦苦所寫的內容就這樣被別人偷走了。302重定向所形成的網址URL劫持現象，已經存在一段時間了。不過到目前爲止，彷佛也沒有什麼更好的解決方法。

大致意思是會引發搜索引擎的排名，並且302重定向很容易被搜索引擎誤認爲是利用多個域名指向同一網站，那麼你的網站就會被封掉。總之，除非真是臨時重定向使用302，其餘的狀況最好仍是使用301.

3、cookie, session, token

Cookie

cookie 是一個很是具體的東西，指的就是瀏覽器裏面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。

cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。因爲cookie是存在客戶端上的，因此瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁盤空間，因此每一個域的cookie數量是有限的。服務端能夠設置httpOnly，使得前端沒法操做cookie

Session

session 從字面上講，就是會話。這個就相似於你和一我的交談，你怎麼知道當前和你交談的是張三而不是李四呢？對方確定有某種特徵（長相等）代表他就是張三。

session 也是相似的道理，服務器要知道當前發請求給本身的是誰。爲了作這種區分，服務器就要給每一個客戶端分配不一樣的「身份標識」，而後客戶端每次向服務器發請求的時候，都帶上這個「身份標識」，服務器就知道這個請求來自於誰了。至於客戶端怎麼保存這個「身份標識」，能夠有不少種方式，對於瀏覽器客戶端，你們都默認採用 cookie 的方式。

服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站後session會被銷燬。這種用戶信息存儲方式相對cookie來講更安全，但是session有一個缺陷：若是web服務器作了負載均衡，那麼下一個操做請求到了另外一臺服務器的時候session會丟失。

Token

在Web領域基於Token的身份驗證隨處可見。在大多數使用Web API的互聯網公司中，tokens 是多用戶下處理認證的最佳方式。

如下幾點特性會讓你在程序中使用基於Token的身份驗證

1.無狀態、可擴展

 2.支持移動設備

 3.跨程序調用

 4.安全

基於服務器驗證方式暴露的一些問題

1.Seesion：每次認證用戶發起請求時，服務器須要去建立一個記錄來存儲信息。當愈來愈多的用戶發請求時，內存的開銷也會不斷增長。

2.可擴展性：在服務端的內存中使用Seesion存儲登陸信息，伴隨而來的是可擴展性問題。

3.CORS(跨域資源共享)：當咱們須要讓數據跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另外一個域的資源，就能夠會出現禁止請求的狀況。

4.CSRF(跨站請求僞造)：用戶在訪問銀行網站時，他們很容易受到跨站請求僞造的攻擊，而且可以被利用其訪問其餘的網站。

在這些問題中，可擴展行是最突出的。所以咱們有必要去尋求一種更有行之有效的方法。

基於Token的驗證原理

基於Token的身份驗證是無狀態的，咱們不將用戶信息存在服務器或Session中。這種概念解決了在服務端存儲信息時的許多問題,NoSession意味着你的程序能夠根據須要去增減機器，而不用去擔憂用戶是否登陸。

基於Token的身份驗證的過程以下:

1.用戶經過用戶名和密碼發送請求。

2.程序驗證。

3.程序返回一個簽名的token 給客戶端。

4.客戶端儲存token,而且每次用於每次發送請求。

5.服務端驗證token並返回數據。

本部分摘自：http://www.javashuo.com/article/p-pmqrabgg-cs.html

4、前端持久化的方式、區別

1.使用前端cookie技術來保存本地化數據，如jquery.cookie.js；

2.使用html5提供的localStorage技術來提供解決方案；

html5中的Web Storage包括了兩種存儲方式：sessionStorage和localStorage。
sessionStorage用於本地存儲一個會話(session)中的數據,這些數據只有在同一個會話中的頁面才能訪問而且當會話結束後數據也隨之銷燬。所以sessionStorage不是一種持久化的本地存儲,僅僅是會話級別的存儲。而localStorage用於持久化的本地存儲,除非主動刪除數據,不然數據是永遠不會過時的。若是是要永久保存的,那麼就請使用localStorage方法存取值,若是是要瀏覽關閉會話結束就清除緩存的,固然就得選擇sessionStorage方法了;

5、DNS是怎麼解析的

網絡通信大部分是基於TCP/IP的，而TCP/IP是基於IP地址的，因此計算機在網絡上進行通信時只能識別如「202.96.134.133」之類的IP地址，而不能認識域名。咱們沒法記住10個以上IP地址的網站，因此咱們訪問網站時，更多的是在瀏覽器地址欄中輸入域名，就能看到所須要的頁面，這是由於有一個叫「DNS服務器」的計算機自動把咱們的域名「翻譯」成了相應的IP地址，而後調出IP地址所對應的網頁。它所提供的服務是用來將主機名和域名轉換爲IP地址.

一、在瀏覽器中輸入www . qq .com 域名，操做系統會先檢查本身本地的hosts文件是否有這個網址映射關係，若是有，就先調用這個IP地址映射，完成域名解析。

二、若是hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，若是有，直接返回，完成域名解析。

三、若是hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/ip參數中設置的首選DNS服務器，在此咱們叫它本地DNS服務器，此服務器收到查詢時，若是要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具備權威性。

四、若是要查詢的域名，不禁本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具備權威性。

五、若是本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，若是未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來受權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，若是本身沒法解析，它就會找一個管理.com域的下一級DNS服務器地址(http://qq.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找http://qq.com域服務器，重複上面的動做，進行查詢，直至找到www . qq .com主機。

六、若是用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器若是不能解析，或找根DNS或把轉請求轉至上上級，以此循環。無論是本地DNS服務器用是是轉發，仍是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。 
從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。

1） 瀏覽器緩存

當用戶經過瀏覽器訪問某域名時，瀏覽器首先會在本身的緩存中查找是否有該域名對應的IP地址（若曾經訪問過該域名且沒有清空緩存便存在）；

2） 系統緩存

當瀏覽器緩存中無域名對應IP則會自動檢查用戶計算機系統Hosts文件DNS緩存是否有該域名對應IP；

3） 路由器緩存

當瀏覽器及系統緩存中均無域名對應IP則進入路由器緩存中檢查，以上三步均爲客服端的DNS緩存；

4） ISP（互聯網服務提供商）DNS緩存

當在用戶客服端查找不到域名對應IP地址，則將進入ISP DNS緩存中進行查詢。好比你用的是電信的網絡，則會進入電信的DNS緩存服務器中進行查找；

5） 根域名服務器

當以上均未完成，則進入根服務器進行查詢。全球僅有13臺根域名服務器，1個主根域名服務器，其他12爲輔根域名服務器。根域名收到請求後會查看區域文件記錄，若無則將其管轄範圍內頂級域名（如.com）服務器IP告訴本地DNS服務器；

6） 頂級域名服務器

頂級域名服務器收到請求後查看區域文件記錄，若無則將其管轄範圍內主域名服務器的IP地址告訴本地DNS服務器；

7） 主域名服務器

主域名服務器接受到請求後查詢本身的緩存，若是沒有則進入下一級域名服務器進行查找，並重復該步驟直至找到正確紀錄；

8）保存結果至緩存

本地域名服務器把返回的結果保存到緩存，以備下一次使用，同時將該結果反饋給客戶端，客戶端經過這個IP地址與web服務器創建連接。

6、cdn

CDN的全稱是Content Delivery Network，即內容分發網絡。CDN是構建在現有網絡基礎之上的智能虛擬網絡，依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。

CDN的基本原理是普遍採用各類緩存服務器，將這些緩存服務器分佈到用戶訪問相對集中的地區或網絡中，在用戶訪問網站時，利用全局負載技術將用戶的訪問指向距離最近的工做正常的緩存服務器上，由緩存服務器直接響應用戶請求。  

CDN的基本思路是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。經過在網絡各處放置 節點服務器所構成的在現有的互聯網基礎之上的一層智能 虛擬網絡，CDN系統可以實時地根據 網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。

主要功能：

(1)節省骨幹網帶寬，減小帶寬需求量;

(2)提供服務器端加速，解決因爲用戶訪問量大形成的服務器過載問題;

(3)服務商能使用Web Cache技術在本地緩存用戶訪問過的Web頁面和對象，實現相同對象的訪問無須佔用主幹的出口帶寬，並提升用戶訪問因特網頁面的相應時間的需求；

(4)能克服網站分佈不均的問題，而且能下降網站自身建設和維護成本；

(5)下降「通訊風暴」的影響，提升網絡訪問的穩定性。  

7、計算機網絡的相關協議

協議數據單元PDU（Protocol Data Unit）是指對等層次之間傳遞的數據單位

物理層的 PDU是數據位（bit）

數據鏈路層的 PDU是數據幀（frame）

網絡層的PDU是數據報（packet）

傳輸層的 PDU是數據段（segment）

其餘更高層次的PDU是報文（message）

應用層: (典型設備:應用程序，如FTP，SMTP ，HTTP)

DHCP(Dynamic Host Configuration Protocol)動態主機分配協議，使用 UDP 協議工做，主要有兩個用途：給內部網絡或網絡服務供應商自動分配 IP 地址，給用戶或者內部網絡管理員做爲對全部計算機做中央管理的手段。實現即插即用連網。

DNS （Domain Name System ）域名解析<端口號53>

FTP （File Transfer Protocol ）文件傳輸協議<端口號21>減小或消除不一樣操做系統下處理文件的不兼容性。

HTTP （Hypertext Transfer Protocol ）超文本傳輸協議 <端口號 80>， 面向事務的應用層協議。

POP3 (Post Office Protocol 3) 即郵局協議的第3 個版本，用於接受郵件。

SMTP （Simple Mail Transfer Protocol ）簡單郵件傳輸協議 <端口號25> 用於發送郵件。

SSH （Secure Shell ）安全外殼協議

TELNET 遠程登陸協議 <端口號23>

傳輸層: (典型設備: 進程和端口) 數據單元：數據段 （Segment）

TCP （Transmission Control Protocol ）傳輸控制協議提供可靠的面向鏈接的服務，傳輸數據前須先創建鏈接，結束後釋放。可靠的全雙工信道。可靠、有序、無丟失、不重複。

UDP (User Datagram Protocol ）用戶數據報協議發送數據前無需創建鏈接，不使用擁塞控制，不保證可靠交付，最大努力交付。

網絡層: (典型設備:路由器，防火牆、多層交換機) 數據單元：數據包（Packet ）

IP (IPv4 · IPv6) (Internet Protocol) 網絡之間互連的協議

ARP (Address Resolution Protocol) 即地址解析協議，實現經過IP 地址得 知其物理地址。

RARP (Reverse Address Resolution Protocol)反向地址轉換協議容許局域 網的物理機器從網關服務器的 ARP 表或者緩存上請求其 IP地址。

ICMP (Internet Control Message Protocol ）Internet 控制報文協議。它是TCP/IP 協議族的一個子協議，用於在IP 主機、路由器之間傳遞控制消息。

ICMPv6 :
IGMP (Internet Group Management Protocol) Internet 組管理協議,是因特 網協議家族中的一個組播協議，用於 IP 主機向任一個直接相鄰的路由器報 告他們的組成員狀況。

RIP (Router information protocol) 路由信息協議是一種在網關與主機之間交換路由選擇信息的標準。

OSPF (Open Shortest Path Firs)開放式最短路徑優先,分佈式鏈路狀態協議。

BGP（Border Gateway Protocol ）邊界網關協議，用來鏈接Internet 上獨立系統的路由選擇協議.採用路徑向量路由選擇協議。

數據鏈路層: (典型設備: 網卡，網橋，交換機) 數據單元：幀 （Frame）

ARQ（Automatic Repeat-reQuest ）自動重傳請求協議，錯誤糾正協議之一，包括中止等待ARQ 協議和連續ARQ 協議，錯誤偵測、正面確認、逾時重傳與負面確認繼以重傳等機制。

中止等待協議：
CSMA/CD(Carrrier Sense Multiple Access with Collision Detection)載波監聽多點接入/碰撞檢測協議。總線型網絡，協議的實質是載波監聽和碰撞檢測。載波監聽即發數據前先檢測總線上是否有其餘計算機在發送數據，如暫時不發數據，避免碰撞。碰撞檢測爲計算機邊發送數據邊檢測信道上的信號電壓大小。

PPP(Point-to-Ponit Protocol)點對點協議面向字節，由三部分組成：
一個將IP 數據報封裝到串行鏈路的方法
一個用於創建、配置和測試數據鏈路鏈接的鏈路控制協議LCP
一套網絡控制協議NCP

HDLC （High-Level Data Link Control ）高級數據鏈路控制同步網上傳輸數據、面向比特的數據鏈路層協議。

ATM （Asynchronous Transfer Mode ）異步傳遞方式，創建在電路交換和分組交換的基礎上的一種面向鏈接的快速分組交換技術。 「異步」是指將ATM 信元「異步插入」到同步的 SDH 比特流中。如同步插入則用戶在每幀中所佔的時隙相對位置固定不變。「同步」是指網絡中各鏈路上的比特流都是受同一很是精確的主時鐘的控制。Wi-Fi 、WiMAX 、DTM 、令牌環、以太網、FDDI 、幀中繼、 GPRS 、 EVDO 、HSPA 、L2TP 、ISDN

物理層:(典型設備：中繼器，集線器) 數據單元：比特 （Bit）

光纖、 同軸電纜、雙絞線…

TCP/IP

Transmission Control Protocol/Internet Protocol的簡寫，中譯名爲傳輸控制協議/因特網互聯協議，又名網絡通信協議，是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議等組成（固然還有其餘後來發展起來的網絡協議，還包括 ARP，ICMP，IGMP，UDP，以及讓域名訪問成爲可能的DNS，以及電腦/手機能夠自動獲取IP地址的DHCP。固然還有形形色色的應用層的協議如 HTTP / SMTP / FTP 等。）。TCP/IP 定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標準。協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的協議來完成本身的需求。通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求從新傳輸，直到全部數據安全正確地傳輸到目的地。而IP是給因特網的每一臺聯網設備規定一個地址。

IP協議（Internet Protocol）是將多個包交換網絡鏈接起來，它在源地址和目的地址之間傳送一種稱之爲數據包的東西，它還提供對數據大小的從新組裝功能，以適應不一樣網絡對包大小的要求。IP協議在OSI參考模型中應用於網絡層，以「數據包（Package）」爲單位。其中，IP地址的定義是確認惟一端口號和路由選擇的關鍵，IP地址至關於每臺電話的電話號碼，惟一且是咱們互相聯繫的關鍵，所以IP協議也是網絡互連的關鍵。

IP協議特色

• ①IP協議是一種無鏈接、不可靠的分組傳送服務的協議。
• ②IP協議是點-點線路的網絡層通訊協議。IP協議是針對原主機-路由器、路由器-路由器、路由器-目的主機之間的數據傳輸的點-點線路的網絡層通訊協議。
• ③IP協議屏蔽了網絡在數據鏈路層、物理層協議與實現技術上的差別。：經過IP協議，網絡層向傳輸層提供的是統一的IP分組，傳輸層不須要考慮互聯網在數據鏈路層、物理層協議與實現技術上的差別，IP協議使得異構網絡的互聯變得容易了。

TCP(Transmission Control Protocol 傳輸控制協議)是一種面向鏈接的、可靠的， 基於IP的傳輸層協議。TCP在IP報文的協議號是6。TCP是一個超級麻煩的協議，而它又是互聯網的基礎。

TCP工做在網絡OSI的七層模型中的第四層——Transport層（傳輸層），IP在第三層——Network層，ARP 在第二層——Data Link層。在第二層的數據，咱們把它叫Frame（數據幀），在第三層的數據叫Packet（數據包），第四層的數據叫Segment（數據段）。 同時，咱們須要簡單的知道，數據從應用層發下來，會在每一層都會加上頭部信息，進行封裝，而後再發送到數據接收端。因此數據的發送和接收其實就是數據的封裝和解封裝的過程。

UDP 是User Datagram Protocol的簡稱， 中文名是用戶數據報協議，是OSI（Open System Interconnection，開放式系統互聯） 參考模型中一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務，IETF RFC 768是UDP的正式規範。UDP在IP報文的協議號是17。與所熟知的TCP（傳輸控制協議）協議同樣，UDP協議直接位於IP（網際協議）協議的頂層。根據OSI（開放系統互連）參考模型，UDP和TCP都屬於傳輸層協議。UDP協議的主要做用是將網絡數據流量壓縮成數據包的形式。一個典型的數據包就是一個二進制數據的傳輸單位。每個數據包的前8個字節（16*4位）用來包含報頭信息，剩餘字節則用來包含具體的傳輸數據。

• UDP是一個無鏈接協議，傳輸數據以前源端和終端不創建鏈接，當 UDP想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
• 因爲傳輸數據不創建鏈接，所以也就不須要維護鏈接狀態，包括收發狀態等，所以一臺服務機可同時向多個客戶機傳輸相同的消息。
• UDP信息包的標題很短，只有8個字節，相對於TCP的20個字節信息包的額外開銷很小。
• 吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。
• UDP使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態表（這裏面有許多參數）。
• UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，所以，應用程序須要選擇合適的報文大小。 雖然UDP是一個不可靠的協議，但它是分發信息的一個理想協議。例如，在屏幕上報告股票市場、在屏幕上顯示航空信息等等。UDP也用在路由信息協議RIP（Routing Information Protocol）中修改路由表。在這些應用場合下，若是有一個消息丟失，在幾秒以後另外一個新的消息就會替換它。UDP普遍用在多媒體應用中，例如，Progressive Networks公司開發的RealAudio軟件，它是在因特網上把預先錄製的或者現場音樂實時傳送給客戶機的一種軟件，該軟件使用的RealAudio audio-on-demand protocol協議就是運行在UDP之上的協議，大多數因特網電話軟件產品也都運行在UDP之上。

TCP擁塞控制原理

• 擁塞控制：
  當網絡中某一資源的需求超出了該資源所能提供的可用部分，這時網絡的性能就要開始變壞，這種狀況就叫作擁塞。而擁塞控制就是爲了減小或者避免擁塞對網絡性能的影響而作出的一種控制手段。

• 擁塞控制思路：發送方維持一個叫作擁塞窗口的狀態變量，擁塞窗口的大小取決於網絡的擁塞程度，而且在動態的變化。發送方讓本身的發送窗口等於擁塞窗口，若是在考慮接收方的接收能力，通常發送窗口還要小於擁塞窗口。

• 慢開始：當主機開始發送數據的時候，由小到大的增大發送窗口，也就是由小到大的增大擁塞窗口。接收方接收到一個報文以後就回傳一個確認報文，發送方每接收到一個確認報文，就將擁塞窗口加1，這樣每通過一個傳輸輪次以後，擁塞窗口就增大一倍。

• 擁塞避免：思路是讓擁塞窗口緩慢的增大，即每通過一個往返時間RTT就把發送方的擁塞窗口加1，而不是加倍，這樣擁塞窗口就是線性緩慢增長，比慢開始的增加速率緩慢的多。

• 慢開始門限：爲了防止擁塞窗口增加過大引發網絡擁塞，還須要設置一個慢開始門限

  • 擁塞窗口<慢開始門限時，使用慢開始算法
  • 擁塞窗口>慢開始門限時，使用擁塞避免算法
  • 擁塞窗口=慢開始門限時，兩種算法均可以

TCP/UDP區別

1. 通常區別

• TCP是面向鏈接的，傳輸數據保證可靠性和安全性；TCP協議是非面向鏈接的，是不可靠但高效率的協議。
• TCP佔用資源多而UDP佔用少。
• TCP是流模式而TCP是數據報模式。（能夠這樣理解：TCP是面向鏈接的，用打電話的過程來類比，就是通訊雙方是互相明確的，因此進行的是「你一句我一句」的交流，TCP整個通訊過程間有一個緩存區，因爲通訊主體明確，所以能夠斷斷續續地進行交流，數據比如水流，知道源頭和目的地，所以稱爲流模式。反過來，UDP是非面向鏈接的，比如寫信的過程，假設咱們只要知道佩奇的地址，咱們就能寫信給佩奇，而佩奇卻不認識咱們。這樣發起通訊方的身份是不明確的，每一個發送端的信息都不能和別的發送端混淆，否則會形成數據失效，因此UDP要對數據進行「打包」發送，是面向報文的，就像寫信須要用信封套起來，否則只發送數據甚至數據混合會變得毫無心義，就像qq羣的匿名聊天，這不扯皮嗎？）
• TCP和UDP的應用場景和編程方式也有很大差異，此處再也不贅述。

2. TCP的粘包和UDP的丟包

 　　TCP粘包現象：TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩衝區看，後一包數據的頭緊接着前一包數據的尾。

　　粘包緣由：

• 發送端：TCP默認會使用Nagle算法。而Nagle算法主要作兩件事：1）只有上一個分組獲得確認，纔會發送下一個分組；2）收集多個小分組，在一個確認到來時一塊兒發送。因此，正是Nagle算法形成了發送方有可能形成粘包現象。
• 接收端：TCP接收到分組時，並不會馬上送至應用層處理，或者說，應用層並不必定會當即處理；實際上，TCP將收到的分組保存至接收緩存裏，而後應用程序主動從緩存裏讀收到的分組。這樣一來，若是TCP接收分組的速度大於應用程序讀分組的速度，多個包就會被存至緩存，應用程序讀時，就會讀到多個首尾相接粘到一塊兒的包。

　　粘包處理：若是黏在一塊兒的包是同一個總體，即贊成部分數據分割而來的，那麼就不用進行處理。若是是不一樣部分的數據粘到一塊兒，就須要進行粘包解決：

• 發送端致使：使用TCP_NODELAY選項來關閉Nagle算法。
• 接收端致使：暫無。
• 統一解決（應用層）：能夠解決接收方形成的粘包問題，還能解決發送方形成的粘包問題。
  解決方法就是循環處理：應用程序在處理從緩存讀來的分組時，讀完一條數據時，就應該循環讀下一條數據，直到全部的數據都被處理；可是如何判斷每條數據的長度呢？
  兩種途徑：
  　　1）格式化數據：每條數據有固定的格式（開始符、結束符），這種方法簡單易行，但選擇開始符和結束符的時候必定要注意每條數據的內部必定不能出現開始符或結束符；
         2）發送長度（推薦）：發送每條數據的時候，將數據的長度一併發送，好比能夠選擇每條數據的前4位是數據的長度，應用層處理時能夠根據長度來判斷每條數據的開始和結束。

　　UDP丟包現象：丟包現象即便用UDP發送時，因爲不可靠鏈接方式，收到各類因素影響，數據包可能會在接受過程當中丟失一部分，從而致使數據不完整。

　　UDP丟包緣由：

• 發送端：發送的包太大致使send方法沒法正常切割爲小包致使丟包、發送的包太大超過緩存設置也會出現對包、發送頻率太快致使接收端未接受或溢出緩衝區而丟包。
• 接收端：處理時間過長致使丟包。
• 其餘：網絡等問題。

　　UDP丟包處理：

• UDP的缺陷在於丟包和亂序問題，通常視狀況進行處理，而發送的時候也須要注意上述致使丟包的問題。

HTTP是一個客戶端和服務器端請求和應答的標準，一般，由HTTP客戶端發起一個請求，創建一個到服務器指定端口（默認是80端口）的TCP鏈接。HTTP服務器則在那個端口監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行。 HTTP協議的網頁 HTTP協議的網頁 HTTP使用TCP而不是UDP的緣由在於（打開）一個網頁必須傳送不少數據，而TCP協議提供傳輸控制，按順序組織數據，和錯誤糾正。

　　經過HTTP或者HTTPS協議（HTTP協議+SSL協議）請求的資源由統一資源標示符（Uniform Resource Identifiers）（或者，更準確一些，URLs）來標識。HTTP有如下特色：

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

• 靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
• 支持B/S及C/S模式。

URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息，URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。如下面這個URL爲例，介紹下普通URL的各部分組成：

　　http://www.cnblogs.com：8080/fzz9/index.jsp？id=30303&page=2#name

• 協議部分：通常爲HTTP或Https，後接//做爲分隔符。
• 域名部分：www.cnblogs.com爲網站域名。

• 端口號部分：此網址爲8080。跟在域名後面的是端口號，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口。

• 虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。
• 參數部分：從「？」開始到「#」爲止之間的部分爲參數部分。本例中的參數部分爲「id=30303&page=2」。不是必要部分。
• 文件名部分：從域名後的最後一個「/」開始到後面一個「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，都是文件名部分。本例中的文件名是「index.jsp」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名。
• 錨部分(Fragment)：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分。#是用來指導瀏覽器動做的，對服務器端徹底無用。window.location.hash讀取#值

本部分摘自：http://www.javashuo.com/article/p-ewsekudn-dm.html    http://www.javashuo.com/article/p-fvcfqfjo-cv.html

8、http/https/http2.0

1. http

超文本傳輸協議

http請求頭部字段：http://www.javashuo.com/article/p-qrnsonao-cy.html

2. https

HTTPS 是以安全爲目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL。

HTTPS 協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。 HTTPS 和 HTTP 的區別主要以下：

• HTTPS 協議使用 ca 申請證書，因爲免費證書較少，須要必定費用。
• HTTP 是明文傳輸，HTTPS 則是具備安全性的 SSL 加密傳輸協議。
• HTTP 和 HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是 80，後者是 443。

3. http1.0

• 請求與響應支持 HTTP 頭，增長了狀態碼，響應對象的一開始是一個響應狀態行
• 協議版本信息須要隨着請求一塊兒發送，支持 HEAD，POST 方法
• 支持傳輸 HTML 文件之外其餘類型的內容 

• 簡單快速：當客戶端向服務器端發送請求時，只是簡單的填寫請求路徑和請求方法便可，而後就能夠經過瀏覽器或其餘方式將該請求發送就好了 。
• 靈活： HTTP 協議容許客戶端和服務器端傳輸任意類型任意格式的數據對象
• 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接，採用這種方式能夠節省傳輸時間。(當今多數服務器支持Keep-Alive功能，使用服務器支持長鏈接，解決無鏈接的問題)
• 無狀態：無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。即客戶端發送HTTP請求後，服務器根據請求，會給咱們發送數據，發送完後，不會記錄信息。(使用 cookie 機制能夠保持 session，解決無狀態的問題)

4. http1.1

• 能夠複用鏈接
• 增長 pipeline：HTTP 管線化是將多個 HTTP 請求整批提交的技術，而在傳送過程當中不需先等待服務端的迴應。管線化機制須經過永久鏈接（persistent connection）完成。瀏覽器將HTTP請求大批提交可大幅縮短頁面的加載時間，特別是在傳輸延遲（lag/latency）較高的狀況下。有一點須要注意的是，只有冪等的請求能夠使用 pipeline，如 GET，HEAD 方法。
• chunked 編碼傳輸：該編碼將實體分塊傳送並逐塊標明長度,直到長度爲 0 塊表示傳輸結束, 這在實體長度未知時特別有用(好比由數據庫動態產生的數據)
• 引入更多緩存控制機制：如 etag，cache-control
• 引入內容協商機制，包括語言，編碼，類型等，並容許客戶端和服務器之間約定以最合適的內容進行交換
• 請求消息和響應消息都支持 Host 頭域：在 HTTP1.0 中認爲每臺服務器都綁定一個惟一的 IP 地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個 IP 地址。所以，Host 頭的引入就頗有必要了。
• 新增了 OPTIONS,PUT, DELETE, TRACE, CONNECT 方法 雖然 HTTP/1.1 已經優化了不少點，做爲一個目前使用最普遍的協議版本，已經可以知足不少網絡需求，可是隨着網頁變得愈來愈複雜，甚至演變成爲獨立的應用，HTTP/1.1 逐漸暴露出了一些問題：
• 在傳輸數據時，每次都要從新創建鏈接，對移動端特別不友好
• 傳輸內容是明文，不夠安全
• header 內容過大，每次請求 header 變化不大，形成浪費
• keep-alive 給服務端帶來性能壓力 爲了解決這些問題，HTTPS 和 SPDY 應運而生。

5. http2.0

• 使用二進制分幀層：在應用層與傳輸層之間增長一個二進制分幀層，以此達到在不改動 HTTP 的語義，HTTP 方法、狀態碼、URI 及首部字段的狀況下，突破HTTP1.1 的性能限制，改進傳輸性能，實現低延遲和高吞吐量。在二進制分幀層上，HTTP2.0 會將全部傳輸的信息分割爲更小的消息和幀，並對它們採用二進制格式的編碼，其中 HTTP1.x 的首部信息會被封裝到 Headers 幀，而咱們的 request body 則封裝到 Data 幀裏面。
• 多路複用：對於 HTTP/1.x，即便開啓了長鏈接，請求的發送也是串行發送的，在帶寬足夠的狀況下，對帶寬的利用率不夠，HTTP/2.0 採用了多路複用的方式，能夠並行發送多個請求，提升對帶寬的利用率。
• 數據流優先級：因爲請求能夠併發發送了，那麼若是出現了瀏覽器在等待關鍵的 CSS 或者 JS 文件完成對頁面的渲染時，服務器卻在專一的發送圖片資源的狀況怎麼辦呢？HTTP/2.0 對數據流能夠設置優先值，這個優先值決定了客戶端和服務端處理不一樣的流採用不一樣的優先級策略。
• 服務端推送：在 HTTP/2.0 中，服務器能夠向客戶發送請求以外的內容，好比正在請求一個頁面時，服務器會把頁面相關的 logo，CSS 等文件直接推送到客戶端，而不會等到請求來的時候再發送，由於服務器認爲客戶端會用到這些東西。這至關於在一個 HTML 文檔內集合了全部的資源。
• 頭部壓縮：使用首部表來跟蹤和存儲以前發送的鍵值對，對於相同的內容，不會再每次請求和響應時發送。

SSL加密過程：

• 第一步：A給出支持SSL協議版本號，一個客戶端隨機數(Client random，請注意這是第一個隨機數)，客戶端支持的加密方法等信息；
• 第二步：B收到信息後，確認雙方使用的加密方法，並返回數字證書，一個服務器生成的隨機數(Server random，注意這是第二個隨機數)等信息；
• 第三步：A確認數字證書的有效性，而後生成一個新的隨機數(Premaster secret)，而後使用數字證書中的公鑰，加密這個隨機數，發給B。
• 第四步：B使用本身的私鑰，獲取A發來的隨機數(即Premaster secret)；(第3、四步就是非對稱加密的過程了)
• 第五步：A和B經過約定的加密方法(一般是AES算法)，使用前面三個隨機數，生成對話密鑰，用來加密接下來的通訊內容；

本部分摘自：http://www.javashuo.com/article/p-axrsxogg-dh.html     http://www.javashuo.com/article/p-vurbdisw-cr.html（寫的很好呦~）

9、get post區別

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。
• GET產生的URL地址能夠被Bookmark，而POST不能夠。
• GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
• GET請求只能進行url編碼，而POST支持多種編碼方式。
• GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。
• GET請求在URL中傳送的參數是有長度限制的，而POST麼有。（瀏覽器限制）
• 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
• GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。（從傳輸的角度來講，他們都是不安全的，由於 HTTP 在網絡上是明文傳輸的，只要在網絡節點上捉包，就能完整地獲取數據報文。要想安全傳輸，就只有加密，也就是 HTTPS）
• GET參數經過URL傳遞，POST放在Request body中。
• GET產生一個TCP數據包；POST產生兩個TCP數據包。（部分瀏覽器的行爲，而不是post 必然行爲）

  對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；

  而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）

GET和POST是什麼？HTTP協議中的兩種發送請求的方法。

HTTP是什麼？HTTP是基於TCP/IP的關於數據如何在萬維網中如何通訊的協議。

HTTP的底層是TCP/IP。因此GET和POST的底層也是TCP/IP，也就是說，GET/POST都是TCP連接。GET和POST能作的事情是同樣同樣的。你要給GET加上request body，給POST帶上url參數，技術上是徹底行的通的，只要後端支持就好。

實際上，沒有本質區別，可是因爲HTTP的規定和瀏覽器/服務器的限制，致使他們在應用過程當中體現出一些不一樣。（大多數）瀏覽器一般都會限制url長度在2K個字節，而（大多數）服務器最多處理64K大小的url。超過的部分，恕不處理。若是你用GET服務，在request body偷偷藏了數據，不一樣服務器的處理方式也是不一樣的，有些服務器會幫你卸貨，讀出數據，有些服務器直接忽略，因此，雖然GET能夠帶request body，也不能保證必定能被接收到哦。

本部分摘自：https://blog.51cto.com/13961945/2287553

10、ajax、 axios庫

Axios 是一個基於 promise 的 HTTP 庫，能夠用在瀏覽器和 node.js 中。

它的特性是：

• 從瀏覽器中建立 XMLHttpRequests
• 從 node.js 建立 http 請求
• 支持 Promise API
• 攔截請求和響應
• 轉換請求數據和響應數據
• 取消請求
• 自動轉換 JSON 數據
• 客戶端支持防護 XSRF

axios包含全部請求方式函數的封裝、

axios.get（url [，config]）
axios.delete（url [，config]）
axios.head（url [，config]）
axios.post（url [，data [，config]]）
axios.put（url [，data [，config]]）
axios.patch（url [，data [，config]]）

本部分摘自：https://www.jianshu.com/p/ae8e9edf4460

11、tcp三次握手，四次揮手流程

SYN(synchronous創建聯機)

ACK(acknowledgement 確認)

PSH(push傳送)

FIN(finish結束)

RST(reset重置)

URG(urgent緊急)

1. 三次握手——創建TCP鏈接

第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。

第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack (number )=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認鏈接請求，Server進入SYN_RCVD狀態。

第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間能夠開始傳輸數據了。

爲何三次握手？

• 防止已失效的鏈接請求又傳送到服務器端，於是產生錯誤。
• 爲了實現可靠數據傳輸， TCP 協議的通訊雙方， 都必須維護一個序列號， 以標識發送出去的數據包中， 哪些是已經被對方收到的。 三次握手的過程便是通訊雙方相互告知序列號起始值， 並確認對方已經收到了序列號起始值的必經步驟
• 若是隻是兩次握手， 至多隻有鏈接發起方的起始序列號能被確認， 另外一方選擇的序列號則得不到確認

有這樣一種狀況，當A發送一個消息給B，可是因爲網絡緣由，消息被阻塞在了某個節點，而後阻塞的時間超出設定的時間，A會認爲這個消息丟失了，而後從新發送消息。

當A和B通訊完成後，這個被A認爲失效的消息，到達了B
對於B而言，覺得這是一個新的請求連接消息，就向A發送確認，
對於A而言，它認爲沒有給B再次發送消息（由於上次的通話已經結束）全部A不會理睬B的這個確認，可是B則會一直等待A的消息

這就致使了B的時間被浪費（對於服務器而言，CPU等資源是一種浪費），這樣是不可行的，這就是爲何不能兩次握手的緣由了。

2. 四次揮手——斷開TCP鏈接

先由客戶端向服務器端發送一個FIN，請求關閉數據傳輸。

當服務器接收到客戶端的FIN時，向客戶端發送一個ACK，其中ack的值等於FIN+SEQ

而後服務器向客戶端發送一個FIN，告訴客戶端應用程序關閉。

當客戶端收到服務器端的FIN是，回覆一個ACK給服務器端。其中ack的值等於FIN+SEQ

爲何要4次揮手？

• 確保數據可以完整傳輸。
• 當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方了。
• 但未必被動方全部的數據都完整的發送給了主動方，因此被動方不會立刻關閉SOCKET,它可能還須要發送一些數據給主動方後，
• 再發送FIN報文給主動方，告訴主動方贊成關閉鏈接，因此這裏的ACK報文和FIN報文多數狀況下都是分開發送的。

爲何須要TIME_WAIT狀態 

• 可靠的終止TCP鏈接 
• 保證讓遲來的TCP報文段有足夠的時間被識別並丟棄

SYN攻擊：

在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了。

本部分摘自：http://www.javashuo.com/article/p-gdgxchwo-cd.html

12、跨域

瀏覽器的同源策略致使了跨域：同源策略限制了從同一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。

- 不一樣的域名 （好比在網站 example.com 請求 api.com)

- 不一樣的子域名 （好比在網站 example.com 請求 api.example.com)

- 不一樣的端口 （好比在網站 example.com 請求 example.com:3001)

- 不一樣協議 （好比在網站 https://example.com 請求 http://example.com)

1. JSONP

瀏覽器只對XHR(XMLHttpRequest)請求有同源請求限制，而對script標籤src屬性、link標籤ref屬性和img標籤src屬性沒有這這種限制，利用這個「漏洞」就能夠很好的解決跨域請求。JSONP就是利用了script標籤無同源限制的特色來實現的，當向第三方站點請求時，咱們能夠將此請求放在<script>標籤的src屬性裏，這就如同咱們請求一個普通的JS腳本，能夠自由的向不一樣的站點請求：

<script src="http://www.b.com/request?para1=1"></script>

• script標籤設置src屬性爲請求的地址，並判斷回調函數做爲參數
• 服務端構建JS腳本，傳遞返回給客戶端的數據
• 客戶端在回調函數中解析服務器生成的數據

只支持GET，不支持POST請求

/**
 * JSONP請求工具
 * @param url 請求的地址
 * @param data 請求的參數
 * @returns {Promise<any>}
 */
const request = ({url, data}) => {
  return new Promise((resolve, reject) => {
    // 處理傳參成xx=yy&aa=bb的形式
    const handleData = (data) => {
      const keys = Object.keys(data)
      const keysLen = keys.length
      return keys.reduce((pre, cur, index) => {
        const value = data[cur]
        const flag = index !== keysLen - 1 ? '&' : ''
        return `${pre}${cur}=${value}${flag}`
      }, '')
    }
    // 動態建立script標籤
    const script = document.createElement('script')
    // 接口返回的數據獲取
    window.jsonpCb = (res) => {
      document.body.removeChild(script)
      delete window.jsonpCb
      resolve(res)
    }
    script.src = `${url}?${handleData(data)}&cb=jsonpCb`
    document.body.appendChild(script)
  })
}
// 使用方式
request({
  url: 'http://localhost:9871/api/jsonp',
  data: {
    // 傳參
    msg: 'helloJsonp'
  }
}).then(res => {
  console.log(res)
})

//它的基本思想是，網頁經過添加一個<script>元素，向服務器請求JSON數據，這種作法不受同源政策限制；服務器收到請求後，將數據放在一個指定名字的回調函數裏傳回來。
//首先，網頁動態插入<script>元素，由它向跨源網址發出請求。
function addScriptTag(src) {
  var script = document.createElement('script');
  script.setAttribute("type","text/javascript");
  script.src = src;
  document.body.appendChild(script);
}

window.onload = function () {
  addScriptTag('http://example.com/ip?callback=foo');
}

function foo(data) {
  console.log('Your public IP address is: ' + data.ip);
};
//上面代碼經過動態添加<script>元素，向服務器example.com發出請求。注意，該請求的查詢字符串有一個callback參數，用來指定回調函數的名字，這對於JSONP是必需的。
//服務器收到這個請求之後，會將數據放在回調函數的參數位置返回。

2. CORS（HTML5支持）

CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）

瀏覽器將CORS請求分紅兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。

只要同時知足如下兩大條件，就屬於簡單請求。
（1) 請求方法是如下三種方法之一：

• HEAD
• GET
• POST

（2）HTTP的頭信息不超出如下幾種字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

Access-Control-Allow-Origin

這個頭部信息由服務器返回，用來明確指定那些客戶端的域名容許訪問這個資源

簡單請求

瀏覽器會在在header信息裏面多加一個字段：
key：origin 
value：協議+域名+端口（如https://localhost:8080）

服務器根據對象裏的origin值來決定是否贊成此次請求

若是請求經過
請求經過後，服務器會在header裏多增長几個字段：

Access-Control-Allow-Origin: https://localhost:8080
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Token

非簡單請求

非簡單請求的方法就是Put，Delete，或者Content-Type是application/json

非簡單請求在發出CORS請求以前，會增長一次HTTP查詢請求，也叫預檢請求
預檢請求成功了，瀏覽器才能發出XMLHttpRequest，不然報錯

若是瀏覽器發現這是一個非簡單請求
就會先發送一個預檢請求：

OPTIONS /cors HTTP/1.1
Origin: http://localhost:8088
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: token

預測請求的方法名叫OPTIONS
Origin和簡單請求同樣
Access-Control-Request-Method是請求方法
Access-Control-Request-Headers是額外發送的頭信息字段
（tip：預檢請求通常緩存下來，以便不須要在每次請求都發送）

若是預檢請求經過
咱們來看下服務器發出的迴應

HTTP/1.1 200 OK
Date: Nov, 01 Dec 2017 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://localhost：8088
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: token
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

若是預檢請求失敗
服務器會返回一個HTTP迴應（沒有CORS的頭信息字段）
並在console打出not allowed by Access-Control-Allow-Origin異常

預檢請求經過之後
瀏覽器發每次出的CORS請求就和簡單請求同樣
會有一個origin字段
服務器每次迴應都會有Access-Control-Allow-Origin頭信息字段

三、 document.domain + iframe跨域

此方案僅限主域相同，子域不一樣的跨域應用場景。

實現原理：兩個頁面都經過js強制設置document.domain爲基礎主域，就實現了同域。

父窗口(http://www.demo.com/a.html)
<iframe id="iframe" src="http://child.demo.com/b.html"></iframe>
<script>
    document.domain = 'demo.com';
    var user = 'admin';
</script>
子窗口：(http://child.demo.com/b.html)
<script>
    document.domain = 'demo.com';
    // 獲取父窗口中變量
    alert('get js data from parent ---> ' + window.parent.user);
</script>

四、 location.hash + iframe

實現原理： a欲與b跨域相互通訊，經過中間頁c來實現。 三個頁面，不一樣域之間利用iframe的location.hash傳值，相同域之間直接js訪問來通訊。

具體實現：A域：a.html -> B域：b.html -> A域：c.html，a與b不一樣域只能經過hash值單向通訊，b與c也不一樣域也只能單向通訊，但c與a同域，因此c可經過parent.parent訪問a頁面全部對象。

實現原理： a欲與b跨域相互通訊，經過中間頁c來實現。 三個頁面，不一樣域之間利用iframe的location.hash傳值，相同域之間直接js訪問來通訊。

具體實現：A域：a.html -> B域：b.html -> A域：c.html，a與b不一樣域只能經過hash值單向通訊，b與c也不一樣域也只能單向通訊，但c與a同域，因此c可經過parent.parent訪問a頁面全部對象。

五、 window.name + iframe跨域

window.name屬性的獨特之處：name值在不一樣的頁面（甚至不一樣域名）加載後依舊存在，而且能夠支持很是長的 name 值（2MB）。

六、 postMessage跨域

postMessage是HTML5 XMLHttpRequest Level 2中的API，且是爲數很少能夠跨域操做的window屬性之一，它可用於解決如下方面的問題：
a.） 頁面和其打開的新窗口的數據傳遞
b.） 多窗口之間消息傳遞
c.） 頁面與嵌套的iframe消息傳遞
d.） 上面三個場景的跨域數據傳遞

用法：postMessage(data,origin)方法接受兩個參數
data： html5規範支持任意基本類型或可複製的對象，但部分瀏覽器只支持字符串，因此傳參時最好用JSON.stringify()序列化。
origin： 協議+主機+端口號，也能夠設置爲"*"，表示能夠傳遞給任意窗口，若是要指定和當前窗口同源的話設置爲"/"。

<iframe id="iframe" src="http://www.demo2.com/b.html" style="display:none;"></iframe>
<script>       
    var iframe = document.getElementById('iframe');
    iframe.onload = function() {
        var data = {
            name: 'aym'
        };
        // 向domain2傳送跨域數據
        iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.demo2.com');
    };

    // 接受domain2返回數據
    window.addEventListener('message', function(e) {
        alert('data from demo2 ---> ' + e.data);
    }, false);
</script>

<script>
    // 接收domain1的數據
    window.addEventListener('message', function(e) {
        alert('data from demo1 ---> ' + e.data);

        var data = JSON.parse(e.data);
        if (data) {
            data.number = 16;

            // 處理後再發回domain1
            window.parent.postMessage(JSON.stringify(data), 'http://www.demo1.com');
        }
    }, false);
</script>

七、 nginx代理跨域
八、 nodejs中間件代理跨域
九、 WebSocket協議跨域

本部分摘自：https://segmentfault.com/a/1190000015597029?utm_source=tag-newest 

                     https://segmentfault.com/a/1190000017867312?utm_source=tag-newest   

                     http://www.javashuo.com/article/p-vwlsbjnn-br.html

十3、前端安全XSS、CSRF

1. XSS——跨站腳本攻擊

其原理是攻擊者向有 XSS漏洞的網站中輸入(傳入)惡意的HTML代碼，當其它用戶瀏覽該網站時，這段HTML代碼會自動執行，從而達到攻擊的目的。如，盜取用戶 Cookie、破壞頁面的正常結構，插入廣告等惡意內容、重定向到其它網站，D-doss攻擊等；XSS攻擊相似於SQL注入攻擊，攻擊以前，咱們先找到一個存在XSS漏洞的網站。理論上，全部可輸入的地方沒有對輸入數據進行處理的話，都會存在XSS漏洞，漏洞的危害取決於攻擊代碼的威力。

反射型
發出請求時，XSS代碼出如今url中，做爲輸入提交到服務器端，服務器端解析後響應，XSS代碼隨響應內容一塊兒傳回給瀏覽器，最後瀏覽器解析執行XSS代碼。這個過程像一次反射，因此叫反射型XSS。
存儲型
存儲型XSS和反射型XSS的差異在於，提交的代碼會存儲在服務器端（數據庫、內存、文件系統等），下次請求時目標頁面時不用再提交XSS代碼。
防範措施

設置httponly，對cookie進行保護

編碼：對用戶輸入的數據進行 HTML Entity 編碼。Encode的做用是將等一些字符進行轉化，使得瀏覽器在最終輸出結果上是同樣的。

過濾：移除用戶輸入的和事件相關的屬性。如onerror能夠自動觸發攻擊，還有onclick等。移除用戶輸入的Style節點、Script節點、Iframe節點。（尤爲是Script節點，它但是支持跨域的呀，必定要移除）。

校訂：避免直接對HTML Entity進行解碼。使用DOM Parse轉換，校訂不配對的DOM標籤。

2. CSRF——跨站點僞造請求

該攻擊能夠在受害者絕不知情的狀況下以受害者名義僞造請求發送給受攻擊站點，從而在未受權的狀況下執行在權限保護之下的操做，具備很大的危害性。具體來說，能夠這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來講這個請求是徹底合法的，可是卻完成了攻擊者所指望的一個操做，好比以你的名義發送郵件、發消息，盜取你的帳號，添加系統管理員，甚至於購買商品、虛擬貨幣轉帳等。

• 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登陸網站A；
• 在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A；
• 用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B；
• 網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問第三方站點A；
• 瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

防範措施

方法1、Token 驗證：（用的最多）

服務器發送給客戶端一個token；
客戶端提交的表單中帶着這個token。
若是這個 token 不合法，那麼服務器拒絕這個請求。
方法二：隱藏令牌：

把 token 隱藏在 http 的 head頭中。

方法二和方法一有點像，本質上沒有太大區別，只是使用方式上有區別。

方法3、Referer 驗證：

Referer 指的是頁面請求來源。意思是，只接受本站的請求，服務器才作響應；若是不是，就攔截。

CSRF 和 XSS 的區別
區別一：
CSRF：須要用戶先登陸網站A，獲取 cookie。

XSS：不須要登陸。

區別二：（原理的區別）
CSRF：是利用網站A自己的漏洞，去請求網站A的api。

XSS：是向網站 A 注入 JS代碼，而後執行 JS 裏的代碼，篡改網站A的內容

本部分摘自：https://blog.csdn.net/m0_37686205/article/details/90030588

十4、websocket

 websocket是HTML5的一個新協議，它容許服務端向客戶端傳遞信息，實現瀏覽器和客戶端雙工通訊。

服務器能夠主動向客戶端推送信息，客戶端也能夠主動向服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。

• 與 HTTP 協議有着良好的兼容性。默認端口也是 80 和 443 ，而且握手階段採用 HTTP 協議，所以握手時不容易屏蔽，能經過各類 HTTP 代理服務器。 
• 創建在TCP協議基礎之上，和http協議同屬於應用層
• 數據格式比較輕量，性能開銷小，通訊高效。 
• 能夠發送文本，也能夠發送二進制數據。 
• 沒有同源限制，客戶端能夠與任意服務器通訊
• 協議標識符是ws（若是加密，則爲wss），服務器網址就是 URL,如ws://localhost:8023

本部分摘自：http://www.javashuo.com/article/p-qqicfccz-ec.html

十5、Http請求中的keep-alive

傳統的Http應用裏都是一次TCP鏈接一次request。

這種狀況下效率有點低：

• 服務端負載增長，每一個請求過來都得佔用端口
• 客戶端或服務端對客戶端鏈接數的限制（chrome 限制是6個）
  這種狀況不少，好比網頁加載對於這個case的處理就是使用將靜態資源放置到不一樣Domain或者壓縮打包減小數量來提升效率

• 短鏈接

  所謂短鏈接，就是每次請求一個資源就創建鏈接，請求完成後鏈接立馬關閉。每次請求都通過「建立tcp鏈接->請求資源->響應資源->釋放鏈接」這樣的過程

• 長鏈接

  所謂長鏈接(persistent connection)，就是隻創建一次鏈接，屢次資源請求都複用該鏈接，完成後關閉。要請求一個頁面上的十張圖，只須要創建一次tcp鏈接，而後依次請求十張圖，等待資源響應，釋放鏈接。

• 並行鏈接

  所謂並行鏈接(multiple connections)，其實就是併發的短鏈接。

(1) client發出的HTTP請求頭須要增長Connection:keep-alive字段

(2) Web-Server端要能識別Connection:keep-alive字段，而且在http的response裏指定Connection:keep-alive字段，告訴client，我能提供keep-alive服務，而且"應允"client我暫時不會關閉socket鏈接

在HTTP/1.0裏，爲了實現client到web-server能支持長鏈接，必須在HTTP請求頭裏顯示指定

Connection:keep-alive 

在HTTP/1.1裏，就默認是開啓了keep-alive，要關閉keep-alive須要在HTTP請求頭裏顯示指定

Connection:close 

如今大多數瀏覽器都默認是使用HTTP/1.1，因此keep-alive都是默認打開的。一旦client和server達成協議，那麼長鏈接就創建好了。

客戶端和服務端在創建鏈接並完成request後並不會當即斷開TCP鏈接，而是在下次request來臨時複用此次TCP鏈接。可是這裏也必需要有TCP鏈接的timeout時間限制。否則會形成服務端端口被長期佔用釋放不了。

對於不適用keepalive的request來講，無論是客戶端仍是服務端都是經過TCP的連接的斷開知道request的結束（TCP 揮手時會check 數據包的 seq， 保證數據完整性）。
支持keepalive後，如何知道request結束了呢？
在Http1.1的版本里， 解決方案是request 和reponse裏使用contentLength來幫助確認是否收到所有數據。

另外一個問題就是在使用keepalive的狀況，客戶端依然有同時發送多個請求的狀況，好比網頁加載是須要同時load多個靜態資源。好比 瀏覽器默認最大鏈接數是6，如今有十個資源同時加載，那麼這十個裏會有6個並行，4個與前6個串行。

在keepalive裏有個問題就是若是能知道每一個repose與其對應的request的話，併發的請求能夠只須要一次TCP鏈接，這也就是http2.0實現的多路複用

十6、網絡分層

 

本部分摘自（圖是別人的，畫的巨好，可是沒找到原做者）：http://www.javashuo.com/article/p-rhbsanol-bo.html

十7、即時通訊，除了Ajax和websocket

長輪詢

十8、模塊化，commonJS，es6，cmd，amd

AMD、CMD、CommonJs是ES5中提供的模塊化編程的方案，import/export是ES6中新增的。

1. AMD-異步模塊定義

AMD是RequireJS在推廣過程當中對模塊定義的規範化產出，它是一個概念，RequireJS是對這個概念的實現，就比如JavaScript語言是對ECMAScript規範的實現。AMD是一個組織，RequireJS是在這個組織下自定義的一套腳本語言。RequireJS：是一個AMD框架，能夠異步加載JS文件，按照模塊加載方法，經過define()函數定義，第一個參數是一個數組，裏面定義一些須要依賴的包，第二個參數是一個回調函數，經過變量來引用模塊裏面的方法，最後經過return來輸出。

2. CMD---是SeaJS在推廣過程當中對模塊定義的規範化產出，是一個同步模塊定義，是SeaJS的一個標準，SeaJS是CMD概念的一個實現，SeaJS是淘寶團隊提供的一個模塊開發的js框架.

3. CommonJS規範---是經過module.exports定義的，在前端瀏覽器裏面並不支持module.exports,經過node.js後端使用的。Nodejs端是使用CommonJS規範的，前端瀏覽器通常使用AMD、CMD、ES6等定義模塊化開發的。

3. ES6特性，模塊化---export/import對模塊進行導出導入的。

AMD推崇依賴前置，在定義模塊的時候就要聲明其依賴的模塊 
CMD推崇就近依賴，只有在用到某個模塊的時候再去require 

不少人說requireJS是異步加載模塊，SeaJS是同步加載模塊，這麼理解其實是不許確的，其實加載模塊都是異步的，只不過AMD依賴前置，js能夠方便知道依賴模塊是誰，當即加載，而CMD就近依賴，須要使用把模塊變爲字符串解析一遍才知道依賴了那些模塊，這也是不少人詬病CMD的一點，犧牲性能來帶來開發的便利性，實際上解析模塊用的時間短到能夠忽略