這里我只是對一些知識進行簡單的整理，方便自己理解記憶，還有很多不完善的地方，更多細節，需要查看書籍或者其他文章
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）等。
**缺點：**
每個TCP連接只能發送一個請求。發送數據完畢，連接就關閉，如果還要請求其他資源，就必須再新建一個連接。
TCP連接的新建成本很高，因為需要客戶端和服務器三次握手，并且開始時發送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨著網頁加載的外部資源越來越多，這個問題就愈發突出了。
為了解決這個問題，有些瀏覽器在請求時，用
列表項目
了一個非標準的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請求都是獨立的，任何兩個請求之間沒有什么必然的聯系。但是在實際應用當中并不是完全這樣的，引入了html' target='_blank'>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種方法.
通用首部字段
本質上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 // 新建Cookiecookie.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 // 新建Cookiecookie.setSecure(true); // 設置安全屬性response.addCookie(cookie); // 輸出到客戶端
提示：secure屬性并不能對Cookie內容加密，因而不能保證絕對的安全性。如果需要高安全性，需要在程序中對Cookie內容加密、解密，以防泄密。
http sessionsession和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。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
新聞熱點
疑難解答
