http協議概覽

這裏我只是對一些知識進行簡單的整理，方便本身理解記憶，還有不少不完善的地方，更多細節，須要查看書籍或者其餘文章

http協議的發展過程

HTTP 是基於 TCP/IP 協議的應用層協議。它不涉及數據包（packet）傳輸，主要規定了客戶端和服務器之間的通訊格式，默認使用80端口。

http/0.9
1991年發佈，只有一個命令GET，協議規定，服務器只能迴應HTML格式的字符串，不能迴應別的格式。

---

http/1.0
1996年5月發佈，HTTP/1.0 版本發佈，內容大大增長，首先，任何格式的內容均可以發送。這使得互聯網不只能夠傳輸文字，還能傳輸圖像、視頻、二進制文件。這爲互聯網的大發展奠基了基礎。除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務器的互動手段。

HTTP請求和迴應的格式也變了。除了數據部分，每次通訊都必須包括頭信息（HTTP header），用來描述一些元數據。

其餘的新增功能還包括狀態碼（status code）、多字符集支持、多部分發送（multi-part type）、權限（authorization）、緩存（cache）、內容編碼（content encoding）等。

**缺點：**

1. 每一個TCP鏈接只能發送一個請求。發送數據完畢，鏈接就關閉，若是還要請求其餘資源，就必須再新建一個鏈接。
   TCP鏈接的新建成本很高，由於須要客戶端和服務器三次握手，而且開始時發送速率較慢（slow start）。因此，HTTP 1.0版本的性能比較差。隨着網頁加載的外部資源愈來愈多，這個問題就愈發突出了。

   爲了解決這個問題，有些瀏覽器在請求時，用

2. 列表項目

了一個非標準的Connection字段。

Connection: keep-alive

一個能夠複用的TCP鏈接就創建了，直到客戶端或服務器主動關閉鏈接。可是，這不是標準字段，不一樣實現的行爲可能不一致，所以不是根本的解決辦法。

---

http/1.1
1997年1月發佈，HTTP/1.1 版本發佈，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協議，一直用到了20年後的今天，直到如今仍是最流行的版本。

1.1 版的最大變化，就是引入了持久鏈接（persistent connection），即TCP鏈接默認不關閉，能夠被多個請求複用，不用聲明Connection: keep-alive。

客戶端和服務器發現對方一段時間沒有活動，就能夠主動關閉鏈接。不過，規範的作法是，客戶端在最後一個請求時，發送Connection: close，明確要求服務器關閉TCP鏈接。

1.1版還新增了許多動詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

**缺點**

• 雖然1.1版容許複用TCP鏈接，可是同一個TCP鏈接裏面，全部的數據通訊是按次序進行的。服務器只有處理完一個迴應，纔會進行下一個迴應。要是前面的迴應特別慢，後面就會有許多請求排隊等着。這稱爲"隊頭堵塞"（Head-of-line blocking）。

  爲了不這個問題，只有兩種方法：
  一是減小請求數；
  二是同時多開持久鏈接。這致使了不少的網頁優化技巧，好比合並腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。若是HTTP協議設計得更好一些，這些額外的工做是能夠避免的。

---

SPDY
2009年，谷歌公開了自行研發的 SPDY 協議，主要解決 HTTP/1.1 效率不高的問題。這個協議在Chrome瀏覽器上證實可行之後，就被看成 HTTP/2 的基礎，主要特性都在 HTTP/2 之中獲得繼承。

---

HTTP/2
2015年，HTTP/2 發佈。它不叫 HTTP/2.0，是由於標準委員會不打算再發布子版本了，下一個新版本將是 HTTP/3。

HTTP/1.1 版的頭信息確定是文本（ASCII編碼），數據體能夠是文本，也能夠是二進制。HTTP/2 則是一個完全的二進制協議。

二進制協議的一個好處是，能夠定義額外的幀。HTTP/2 定義了近十種幀，爲未來的高級應用打好了基礎。若是使用文本實現這種功能，解析數據將會變得很是麻煩，二進制解析則方便得多。

HTTP/2 複用TCP鏈接，在一個鏈接裏，客戶端和瀏覽器均可以同時發送多個請求或迴應，並且不用按照順序一一對應，這樣就避免了"隊頭堵塞"。

HTTPS
HTTPS是HTTP協議的安全版本，HTTP協議的數據傳輸是明文的，是不安全的，HTTPS使用了SSL/TLS協議進行了加密處理。

http協議的特色

• 無狀態——每次HTTP請求都是獨立的，任何兩個請求之間沒有什麼必然的聯繫。可是在實際應用當中並非徹底這樣的，引入了Cookie和Session機制來關聯請求。
• 無鏈接的——每次請求完成以後當即斷開鏈接
• 單向的應用層協議——通訊請求只能由客戶端發起，服務端對請求作出應答處理。
• 屢次請求——　在客戶端請求網頁時多數狀況下並非一次請求就能成功的，服務端首先是響應HTML頁面，而後瀏覽器收到響應以後發現HTML頁面還引用了其餘的資源，例如，CSS，JS文件，圖片等等，還會自動發送HTTP請求這些須要的資源。

如今的HTTP版本支持管道機制（即在同一個TCP鏈接裏面，客戶端能夠同時發送多個請求），能夠同時請求和響應多個請求，大大提升了效率。

http報文結構

請求行

• url —— Request URL
• 請求方法 —— Request Method
• 狀態碼 —— Status Code
• 服務器地址 —— Remote Address

  在跨域拒絕時，多是method爲options，狀態碼爲404/405等（固然，實際上可能的組合有不少）的

---

**經常使用狀態碼：**
200——代表該請求被成功地完成，所請求的資源發送回客戶端
304——自從上次請求後，請求的網頁未修改過，請客戶端使用本地緩存
400——客戶端請求有錯（譬如能夠是安全模塊攔截）
401——請求未經受權
403——禁止訪問（譬如能夠是未登陸時禁止）
404——資源未找到
500——服務器內部錯誤
503——服務不可用
...


**HTTP請求方法**
在HTTP1.1版本中支持GET、POST等近10種方法.

---

通用首部字段

HTTP Cookie

本質上cookies就是http的一個擴展。有兩個http頭部是專門負責設置以及發送cookie的,它們分別是Set-Cookie以及Cookie。

HTTP Cookie（也叫Web Cookie或瀏覽器Cookie）是服務器發送到用戶瀏覽器並保存在本地的一小塊數據，它會在瀏覽器下次向同一服務器再發起請求時被攜帶併發送到服務器上。一般，它用於告知服務端兩個請求是否來自同一瀏覽器，如保持用戶的登陸狀態。Cookie使基於無狀態的HTTP協議記錄穩定的狀態信息成爲了可能。

Cookie主要用於如下三個方面：

• 會話狀態管理（如用戶登陸狀態、購物車、遊戲分數或其它須要記錄的信息）
• 個性化設置（如用戶自定義設置、主題等）
• 瀏覽器行爲跟蹤（如跟蹤分析用戶行爲等）

Cookie曾一度用於客戶端數據的存儲，因當時並無其它合適的存儲辦法而做爲惟一的存儲手段，但如今隨着現代瀏覽器開始支持各類各樣的存儲方式，Cookie漸漸被淘汰。因爲服務器指定Cookie後，瀏覽器的每次請求都會攜帶Cookie數據，會帶來額外的性能開銷（尤爲是在移動環境下）。新的瀏覽器API已經容許開發者直接將數據存儲到本地，如使用 Web storage API （本地存儲和會話存儲）或 IndexedDB 。

建立cookie
服務器收到HTTP請求時，服務器能夠在響應頭裏面添加一個Set-Cookie選項。瀏覽器收到響應後一般會保存下Cookie，以後對該服務器每一次請求中都經過Cookie請求頭部將Cookie信息發送給服務器。另外，Cookie的過時時間、域、路徑、有效期、適用站點均可以根據須要來指定。

nodejs中服務端設置cookie的方法

request.setHeader('Set-Cookie', ['type=ninja', 'language=javascript']);

cookie是保存在客戶端中，按照客戶端中存儲的位置，可分爲內存cookie和硬盤cookie。

內存cookie
cookie的生存時間是整個會話期間的話，瀏覽器會將cookie保存在內存中，瀏覽器關閉時就會自動清除這個cookie

硬盤cookie
就是cookie保存在客戶端的硬盤中，瀏覽器關閉的話，該cookie也不會被清除，下次打開瀏覽器訪問對應網站時，這個cookie就會自動再次發送到服務器端。

cookie不可跨域
不少網站都會使用Cookie。例如：Google會向客戶端頒發Cookie，Baidu也會向客戶端頒發Cookie。那瀏覽器訪問Google會不會也攜帶上Baidu頒發的Cookie呢？或者Google能不能修改Baidu頒發的Cookie呢？
案是否認的。Cookie具備不可跨域名性。根據Cookie規範，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操做Google的Cookie，而不能操做百度的Cookie。
Cookie在客戶端是由瀏覽器來管理的。瀏覽器可以保證Google只會操做Google的Cookie而不會操做Baidu的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網站是否能操做另外一個網站Cookie的依據是域名。Google與Baidu的域名不同，所以Google不能操做Baidu的Cookie。

同一個一級域名下的兩個二級域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不能交互使用Cookie，由於兩者的域名並不嚴格相同。若是想全部helloweenvsfei.com名下的二級域名均可以使用該Cookie，須要設置Cookie的domain參數，例如：

Cookie cookie = new Cookie("time","20080808"); // 新建Cookie
cookie.setDomain(".helloweenvsfei.com"); // 設置域名
cookie.setPath("/"); // 設置路徑
cookie.setMaxAge(Integer.MAX_VALUE); // 設置有效期
response.addCookie(cookie); // 輸出到客戶端

cookie的有效期
Cookie的maxAge決定着Cookie的有效期，單位爲秒（Second）。Cookie中經過getMaxAge()方法與setMaxAge(int maxAge)方法來讀寫maxAge屬性。 若是maxAge屬性爲正數，則表示該Cookie會在maxAge秒以後自動失效。瀏覽器會將maxAge爲正數的Cookie持久化，即寫到對應的Cookie文件中。不管客戶關閉了瀏覽器仍是電腦，只要還在maxAge秒以前，登陸網站時該Cookie仍然有效。

若是maxAge爲負數，則表示該Cookie僅在本瀏覽器窗口以及本窗口打開的子窗口內有效，關閉窗口後該Cookie即失效。maxAge爲負數的Cookie，爲臨時性Cookie，不會被持久化，不會被寫到Cookie文件中。Cookie信息保存在瀏覽器內存中，所以關閉瀏覽器該Cookie就消失了。

注意：從客戶端讀取Cookie時，包括maxAge在內的其餘屬性都是不可讀的，也不會被提交。瀏覽器提交Cookie時只會提交name與value屬性。maxAge屬性只被瀏覽器用來判斷Cookie是否過時。

Cookie的安全屬性
HTTP協議不只是無狀態的，並且是不安全的。使用HTTP協議的數據不通過任何加密就直接在網絡上傳播，有被截獲的可能。使用HTTP協議傳輸很機密的內容是一種隱患。若是不但願Cookie在HTTP等非安全協議中傳輸，能夠設置Cookie的secure屬性爲true。瀏覽器只會在HTTPS和SSL等安全協議中傳輸此類Cookie。下面的代碼設置secure屬性爲true：

Cookie cookie = new Cookie("time", "20080808"); // 新建Cookie
cookie.setSecure(true); // 設置安全屬性
response.addCookie(cookie); // 輸出到客戶端

提示：secure屬性並不能對Cookie內容加密，於是不能保證絕對的安全性。若是須要高安全性，須要在程序中對Cookie內容加密、解密，以防泄密。

http session

session和cookie同樣，都是用來記錄http狀態的一種機制，但不一樣的是cookie存在於客戶端，所攜帶的大小收到限制，而session則存在於服務端，存儲的大小不受限制。

當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識- 稱爲session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。 保存這個session id的方式能夠採用cookie，這樣在交互過程當中瀏覽器能夠自動的按照規則把這個標識發揮給服務器。通常這個cookie的名字都是相似於SEEESIONID。

一般session的建立須要依賴cookie，但cookie能夠被人爲的禁止，須要有其餘的機制以便在cookie被禁止的時候可以把session id 傳遞迴服務器，能夠把session id直接附加在URL路徑的後面

注意：在談論session機制的時候，經常聽到這樣一種誤解「只要關閉瀏覽器，session就消失了」。其實能夠想象一下會員卡的例子，除非顧客主動對店家提出銷卡，不然店家絕對不會輕易刪除顧客的資料。對session來講也是同樣的，除非程序通知服務器刪除一個session，不然服務器會一直保留，程序通常都是在用戶作log off的時候發個指令去刪除session。
然而瀏覽器歷來不會主動在關閉以前通知服務器它將要關閉，所以服務器根本不會有機會知道瀏覽器已經關閉，之因此會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個session id就消失了，再次鏈接服務器時也就沒法找到原來的session。
若是服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然可以找到原來的session。

參考文章：
http://www.ruanyifeng.com/blo...
https://www.cnblogs.com/wxism...
https://developer.mozilla.org...
https://www.2cto.com/kf/20120...