web前端對http理解

1. 基礎概念篇

TCP/IP 通訊傳輸流

cookie

url和URI

get和post

cookie,session,webstorge區別

跨域

網絡安全

http緩存

1.1介紹

HTTP是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫。

HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可使瀏覽器更加高效，使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔，還肯定傳輸文檔中的哪一部分，以及哪部份內容首先顯示(如文本先於圖形)等。

HTTP是一個應用層協議，由請求和響應構成，是一個標準的客戶端服務器模型。HTTP是一個無狀態的協議。

1.2 在TCP/IP協議棧中的位置

HTTP協議一般承載於TCP協議之上，有時也承載於TLS或SSL協議層之上，這個時候，就成了咱們常說的HTTPS。以下圖所示：

首先，糾正一下我之前一直誤解的概念，我一直覺得Http和Tcp是兩種不一樣的，可是地位對等的協議，雖然知道TCP是傳輸層，而http是應用層。今天學習了下，知道了 http是要基於TCP鏈接基礎上的，簡單的說，TCP就是單純創建鏈接，不涉及任何咱們須要請求的實際數據，簡單的傳輸。http是用來收發數據，即實際應用上來的。

默認HTTP的端口號爲80，HTTPS的端口號爲443。

1.3 HTTP的請求響應模型

HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖：

這樣就限制了使用HTTP協議，沒法實如今客戶端沒有發起請求的時候，服務器將消息推送給客戶端。

HTTP協議是一個無狀態的協議，同一個客戶端的此次請求和上次請求是沒有對應關係。

注意：客戶端與服務器的角色不是固定的，一端充當客戶端，也可能在某次請求中充當服務器。這取決與請求的發起端。HTTP協議屬於應用層，創建在傳輸層協議TCP之上。客戶端經過與服務器創建TCP鏈接，以後發送HTTP請求與接收HTTP響應都是經過訪問Socket接口來調用TCP協議實現

1.4 工做流程

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：

1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。

2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。

3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。

4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。

若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

1.5http發展歷史

HTTP/1.0 標準於 1996 年 5 月做爲第一份標準被公佈，它被記載於 RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0

HTTP/1.1 標準於 1999 年 6 月被公佈，截止到目前它應該是最主流的 HTTP 協議版本，它被記載於 RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1

HTTP/2 標準於 2015 年 5 月被正式發佈，它被記載於 RFC7540 - Hypertext Transfer Protocol -- HTTP/2

它的特色是

① 採用二進制而非明文來打包，

② 多路複用，

③ 修復隊頭堵塞，

④ 容許設置設定請求優先級，

⑤ 服務器推送，

⑥ WebSocket 等等。

HTTP/2爲何是二進制？

比起像HTTP/1.x這樣的文本協議，二進制協議解析起來更高效、「線上」更緊湊，更重要的是錯誤更少。

爲何 HTTP/2 須要多路傳輸?

HTTP/1.x 有個問題叫線端阻塞(head-of-line blocking), 它是指一個鏈接(connection)一次只提交一個請求的效率比較高, 多了就會變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個問題, 可是效果並不理想(數據量較大或者速度較慢的響應, 會阻礙排在他後面的請求). 此外, 因爲網絡媒介(intermediary )和服務器不能很好的支持流水線, 致使部署起來困難重重。而多路傳輸(Multiplexing)能很好的解決這些問題, 由於它能同時處理多個消息的請求和響應; 甚至能夠在傳輸過程當中將一個消息跟另一個摻雜在一塊兒。因此客戶端只須要一個鏈接就能加載一個頁面。

消息頭爲何須要壓縮?

假定一個頁面有80個資源須要加載（這個數量對於今天的Web而言仍是挺保守的）, 而每一次請求都有1400字節的消息頭（着一樣也並很多見，由於Cookie和引用等東西的存在）, 至少要7到8個來回去「在線」得到這些消息頭。這還不包括響應時間——那只是從客戶端那裏獲取到它們所花的時間而已。這全都因爲TCP的慢啓動機制，它會基於對已知有多少個包，來肯定還要來回去獲取哪些包 – 這很明顯的限制了最初的幾個來回能夠發送的數據包的數量。相比之下，即便是頭部輕微的壓縮也能夠是讓那些請求只需一個來回就能搞定——有時候甚至一個包就能夠了。這種開銷是能夠被節省下來的，特別是當你考慮移動客戶端應用的時候，即便是良好條件下，通常也會看到幾百毫秒的來回延遲。

服務器推送的好處是什麼？

當瀏覽器請求一個網頁時，服務器將會發回HTML，在服務器開始發送JavaScript、圖片和CSS前，服務器須要等待瀏覽器解析HTML和發送全部內嵌資源的請求。服務器推送服務經過「推送」那些它認爲客戶端將會須要的內容到客戶端的緩存中，以此來避免往返的延遲。

2. http請求

下圖是在網上找的一張圖，以爲能很好的表達HTTP請求的所發送的數據格式。

由上圖能夠看到，http請求由請求行，消息報頭，請求正文三部分構成。

HTTP請求狀態行

請求行由請求Method, URL 字段和HTTP Version三部分構成, 總的來講請求行就是定義了本次請求的請求方式, 請求的地址, 以及所遵循的HTTP協議版本例如：

GET /example.html HTTP/1.1 (CRLF)
複製代碼

未完待續。。。

3.HTTP的五大特色

• 支持客戶/服務器模式。
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。
• 靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。早期這麼作的緣由是請求資源少，追求快。後來經過Connection: Keep-Alive實現長鏈接
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

非持久鏈接和持久鏈接

在實際的應用中，客戶端每每會發出一系列請求，接着服務器端對每一個請求進行響應。對於這些請求|響應，若是每次都通過一個單獨的TCP鏈接發送，稱爲非持久鏈接。反之，若是每次都通過相同的TCP鏈接進行發送，稱爲持久鏈接

非持久鏈接在每次請求|響應以後都要斷開鏈接，下次再創建新的TCP鏈接，這樣就形成了大量的通訊開銷。例如前面提到的往返時間(RTT) 就是在創建TCP鏈接的過程當中的代價。

非持久鏈接給服務器帶來了沉重的負擔，每臺服務器可能同時面對數以百計甚至更多的請求。持久鏈接就是爲了解決這些問題，其特色是一直保持TCP鏈接狀態，直到遇到明確的中斷要求以後再中斷鏈接。持久鏈接減小了通訊開銷，節省了通訊量。

HTTP優化方案

• TCP複用，TCP鏈接複用是將多個客戶端的HTTP請求複用到一個服務器端的TCP鏈接上，HTTP複用是指一個一個客戶端的多個HTTP請求經過一個TCP鏈接進行處理。
• 內容緩存。將常常用到的內容進行緩存起來，那麼客戶端就能夠直接在內存中獲取相應的數據了。
• 壓縮，將文本數據進行壓縮，減小寬帶
• SSL加速。使用SSL協議對HTTP協議進行加密，在通道內加密並加速
• TCP緩衝：經過TCP緩衝技術，能夠提升服務器端響應事件和處理效率，減小因爲通訊鏈路問題給服務器形成鏈接負擔.

4.HTTP和HTTPS

HTTP的不足

• 通訊使用明文(不加密),內容可能會被竊聽
• 不驗證通訊方的身份,所以有可能遭遇假裝
• 沒法證實報文的完整性,因此有可能已遭篡改

HTTPS介紹

HTTP 協議中沒有加密機制,但能夠經過SSL(Secure Socket Layer, 安全套接層 )或 TLS(Transport Layer Security, 安全層傳輸協議)的組合使用,加密 HTTP 的通訊內容。屬於通訊加密，即在整個通訊線路中加密。

HTTP + 加密 + 認證 + 完整性保護 = HTTPS（HTTP Secure ）

複製代碼

HTTPS 採用共享密鑰加密（對稱）和公開密鑰加密（非對稱）二者並用的混合加密機制。若密鑰可以實現安全交換,那麼有可能會考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密與共享密鑰加密相比,其處理速度要慢。

因此應充分利用二者各自的優點, 將多種方法組合起來用於通訊。 在交換密鑰階段使用公開密鑰加密方式,以後的創建通訊交換報文階段 則使用共享密鑰加密方式。

HTTPS握手過程的簡單描述以下：

1，瀏覽器將本身支持的一套加密規則發送給網站。

服務器得到瀏覽器公鑰

2，網站從中選出一組加密算法與HASH算法，並將本身的身份信息以證書的形式發回給瀏覽器。證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。

瀏覽器得到服務器公鑰

3，得到網站證書以後瀏覽器要作如下工做：

• 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），若是證書受信任，則瀏覽器欄裏面會顯示一個小鎖頭，不然會給出證書不受信的提示。
• 若是證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼（接下來通訊的密鑰），並用證書中提供的公鑰加密（共享密鑰加密）。
• 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將以前生成的全部信息發送給網站。

4，網站接收瀏覽器發來的數據以後要作如下的操做：

• 使用本身的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。
• 使用密碼加密一段握手消息，發送給瀏覽器。

HTTPS的不足

加密解密過程複雜，致使訪問速度慢

加密須要認向證機構付費

整個頁面的請求都要使用HTTPS