摘要：如果想所有名下的二級域名都可以使用該，需要設(shè)置的參數(shù)，例如新建設(shè)置域名設(shè)置路徑設(shè)置有效期輸出到客戶端的有效期的決定著的有效期，單位為秒。的安全屬性協(xié)議不僅是無狀態(tài)的，而且是不安全的。

這里我只是對一些知識進行簡單的整理，方便自己理解記憶，還有很多不完善的地方，更多細節(jié)，需要查看書籍或者其他文章

HTTP 是基于 TCP/IP 協(xié)議的應(yīng)用層協(xié)議。它不涉及數(shù)據(jù)包（packet）傳輸，主要規(guī)定了客戶端和服務(wù)器之間的通信格式，默認使用80端口。

http/0.9
1991年發(fā)布，只有一個命令GET，協(xié)議規(guī)定，服務(wù)器只能回應(yīng)HTML格式的字符串，不能回應(yīng)別的格式。

http/1.0
1996年5月發(fā)布，HTTP/1.0 版本發(fā)布，內(nèi)容大大增加，首先，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像、視頻、二進制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)。除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動手段。

HTTP請求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。

其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等。

**缺點：**

每個TCP連接只能發(fā)送一個請求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請求其他資源，就必須再新建一個連接。
TCP連接的新建成本很高，因為需要客戶端和服務(wù)器三次握手，并且開始時發(fā)送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁加載的外部資源越來越多，這個問題就愈發(fā)突出了。

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

列表項目

了一個非標準的Connection字段。

Connection: keep-alive

一個可以復(fù)用的TCP連接就建立了，直到客戶端或服務(wù)器主動關(guān)閉連接。但是，這不是標準字段，不同實現(xiàn)的行為可能不一致，因此不是根本的解決辦法。

http/1.1
1997年1月發(fā)布，HTTP/1.1 版本發(fā)布，只比 1.0 版本晚了半年。它進一步完善了 HTTP 協(xié)議，一直用到了20年后的今天，直到現(xiàn)在還是最流行的版本。

1.1 版的最大變化，就是引入了持久連接（persistent connection），即TCP連接默認不關(guān)閉，可以被多個請求復(fù)用，不用聲明Connection: keep-alive。

客戶端和服務(wù)器發(fā)現(xiàn)對方一段時間沒有活動，就可以主動關(guān)閉連接。不過，規(guī)范的做法是，客戶端在最后一個請求時，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接。

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

**缺點**

雖然1.1版允許復(fù)用TCP連接，但是同一個TCP連接里面，所有的數(shù)據(jù)通信是按次序進行的。服務(wù)器只有處理完一個回應(yīng)，才會進行下一個回應(yīng)。要是前面的回應(yīng)特別慢，后面就會有許多請求排隊等著。這稱為"隊頭堵塞"（Head-of-line blocking）。

為了避免這個問題，只有兩種方法：
一是減少請求數(shù)；
二是同時多開持久連接。這導(dǎo)致了很多的網(wǎng)頁優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計得更好一些，這些額外的工作是可以避免的。

SPDY
2009年，谷歌公開了自行研發(fā)的 SPDY 協(xié)議，主要解決 HTTP/1.1 效率不高的問題。這個協(xié)議在Chrome瀏覽器上證明可行以后，就被當作 HTTP/2 的基礎(chǔ)，主要特性都在 HTTP/2 之中得到繼承。

HTTP/2
2015年，HTTP/2 發(fā)布。它不叫 HTTP/2.0，是因為標準委員會不打算再發(fā)布子版本了，下一個新版本將是 HTTP/3。

HTTP/1.1 版的頭信息肯定是文本（ASCII編碼），數(shù)據(jù)體可以是文本，也可以是二進制。HTTP/2 則是一個徹底的二進制協(xié)議。

二進制協(xié)議的一個好處是，可以定義額外的幀。HTTP/2 定義了近十種幀，為將來的高級應(yīng)用打好了基礎(chǔ)。如果使用文本實現(xiàn)這種功能，解析數(shù)據(jù)將會變得非常麻煩，二進制解析則方便得多。

HTTP/2 復(fù)用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應(yīng)，而且不用按照順序一一對應(yīng)，這樣就避免了"隊頭堵塞"。

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

無狀態(tài)——每次HTTP請求都是獨立的，任何兩個請求之間沒有什么必然的聯(lián)系。但是在實際應(yīng)用當中并不是完全這樣的，引入了Cookie和Session機制來關(guān)聯(lián)請求。

無連接的——每次請求完成之后立即斷開連接

單向的應(yīng)用層協(xié)議——通信請求只能由客戶端發(fā)起，服務(wù)端對請求做出應(yīng)答處理。

多次請求——　在客戶端請求網(wǎng)頁時多數(shù)情況下并不是一次請求就能成功的，服務(wù)端首先是響應(yīng)HTML頁面，然后瀏覽器收到響應(yīng)之后發(fā)現(xiàn)HTML頁面還引用了其他的資源，例如，CSS，JS文件，圖片等等，還會自動發(fā)送HTTP請求這些需要的資源。

現(xiàn)在的HTTP版本支持管道機制（即在同一個TCP連接里面，客戶端可以同時發(fā)送多個請求），可以同時請求和響應(yīng)多個請求，大大提高了效率。

請求行

url —— Request URL

請求方法 —— Request Method

狀態(tài)碼 —— Status Code

服務(wù)器地址 —— Remote Address

在跨域拒絕時，可能是method為options，狀態(tài)碼為404/405等（當然，實際上可能的組合有很多）的

**常用狀態(tài)碼：**
200——表明該請求被成功地完成，所請求的資源發(fā)送回客戶端
304——自從上次請求后，請求的網(wǎng)頁未修改過，請客戶端使用本地緩存
400——客戶端請求有錯（譬如可以是安全模塊攔截）
401——請求未經(jīng)授權(quán)
403——禁止訪問（譬如可以是未登錄時禁止）
404——資源未找到
500——服務(wù)器內(nèi)部錯誤
503——服務(wù)不可用
...


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

通用首部字段

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

HTTP Cookie（也叫Web Cookie或瀏覽器Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會在瀏覽器下次向同一服務(wù)器再發(fā)起請求時被攜帶并發(fā)送到服務(wù)器上。通常，它用于告知服務(wù)端兩個請求是否來自同一瀏覽器，如保持用戶的登錄狀態(tài)。Cookie使基于無狀態(tài)的HTTP協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。

Cookie主要用于以下三個方面：

會話狀態(tài)管理（如用戶登錄狀態(tài)、購物車、游戲分數(shù)或其它需要記錄的信息）

個性化設(shè)置（如用戶自定義設(shè)置、主題等）

瀏覽器行為跟蹤（如跟蹤分析用戶行為等）

Cookie曾一度用于客戶端數(shù)據(jù)的存儲，因當時并沒有其它合適的存儲辦法而作為唯一的存儲手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲方式，Cookie漸漸被淘汰。由于服務(wù)器指定Cookie后，瀏覽器的每次請求都會攜帶Cookie數(shù)據(jù)，會帶來額外的性能開銷（尤其是在移動環(huán)境下）。新的瀏覽器API已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲到本地，如使用 Web storage API （本地存儲和會話存儲）或 IndexedDB 。

創(chuàng)建cookie
服務(wù)器收到HTTP請求時，服務(wù)器可以在響應(yīng)頭里面添加一個Set-Cookie選項。瀏覽器收到響應(yīng)后通常會保存下Cookie，之后對該服務(wù)器每一次請求中都通過Cookie請求頭部將Cookie信息發(fā)送給服務(wù)器。另外，Cookie的過期時間、域、路徑、有效期、適用站點都可以根據(jù)需要來指定。

nodejs中服務(wù)端設(shè)置cookie的方法

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

cookie是保存在客戶端中，按照客戶端中存儲的位置，可分為內(nèi)存cookie和硬盤cookie。

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

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

cookie不可跨域
很多網(wǎng)站都會使用Cookie。例如：Google會向客戶端頒發(fā)Cookie，Baidu也會向客戶端頒發(fā)Cookie。那瀏覽器訪問Google會不會也攜帶上Baidu頒發(fā)的Cookie呢？或者Google能不能修改Baidu頒發(fā)的Cookie呢？
案是否定的。Cookie具有不可跨域名性。根據(jù)Cookie規(guī)范，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作百度的Cookie。
Cookie在客戶端是由瀏覽器來管理的。瀏覽器能夠保證Google只會操作Google的Cookie而不會操作Baidu的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網(wǎng)站是否能操作另一個網(wǎng)站Cookie的依據(jù)是域名。Google與Baidu的域名不一樣，因此Google不能操作Baidu的Cookie。

同一個一級域名下的兩個二級域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不能交互使用Cookie，因為二者的域名并不嚴格相同。如果想所有helloweenvsfei.com名下的二級域名都可以使用該Cookie，需要設(shè)置Cookie的domain參數(shù)，例如：

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

cookie的有效期
Cookie的maxAge決定著Cookie的有效期，單位為秒（Second）。Cookie中通過getMaxAge()方法與setMaxAge(int maxAge)方法來讀寫maxAge屬性。 如果maxAge屬性為正數(shù)，則表示該Cookie會在maxAge秒之后自動失效。瀏覽器會將maxAge為正數(shù)的Cookie持久化，即寫到對應(yīng)的Cookie文件中。無論客戶關(guān)閉了瀏覽器還是電腦，只要還在maxAge秒之前，登錄網(wǎng)站時該Cookie仍然有效。

如果maxAge為負數(shù)，則表示該Cookie僅在本瀏覽器窗口以及本窗口打開的子窗口內(nèi)有效，關(guān)閉窗口后該Cookie即失效。maxAge為負數(shù)的Cookie，為臨時性Cookie，不會被持久化，不會被寫到Cookie文件中。Cookie信息保存在瀏覽器內(nèi)存中，因此關(guān)閉瀏覽器該Cookie就消失了。

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

Cookie的安全屬性
HTTP協(xié)議不僅是無狀態(tài)的，而且是不安全的。使用HTTP協(xié)議的數(shù)據(jù)不經(jīng)過任何加密就直接在網(wǎng)絡(luò)上傳播，有被截獲的可能。使用HTTP協(xié)議傳輸很機密的內(nèi)容是一種隱患。如果不希望Cookie在HTTP等非安全協(xié)議中傳輸，可以設(shè)置Cookie的secure屬性為true。瀏覽器只會在HTTPS和SSL等安全協(xié)議中傳輸此類Cookie。下面的代碼設(shè)置secure屬性為true：

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

提示：secure屬性并不能對Cookie內(nèi)容加密，因而不能保證絕對的安全性。如果需要高安全性，需要在程序中對Cookie內(nèi)容加密、解密，以防泄密。

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

當程序需要為某個客戶端的請求創(chuàng)建一個session的時候，服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標識- 稱為session id，如果已包含一個session id則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照session id把這個session檢索出來使用（如果檢索不到，可能會新建一個），如果客戶端請求不包含session id，則為此客戶端創(chuàng)建一個session并且生成一個與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個既不會重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個session id將被在本次響應(yīng)中返回給客戶端保存。 保存這個session id的方式可以采用cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)揮給服務(wù)器。一般這個cookie的名字都是類似于SEEESIONID。

通常session的創(chuàng)建需要依賴cookie，但cookie可以被人為的禁止，需要有其他的機制以便在cookie被禁止的時候能夠把session id 傳遞回服務(wù)器，可以把session id直接附加在URL路徑的后面

注意：在談?wù)搒ession機制的時候，常常聽到這樣一種誤解“只要關(guān)閉瀏覽器，session就消失了”。其實可以想象一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的，除非程序通知服務(wù)器刪除一個session，否則服務(wù)器會一直保留，程序一般都是在用戶做log off的時候發(fā)個指令去刪除session。
然而瀏覽器從來不會主動在關(guān)閉之前通知服務(wù)器它將要關(guān)閉，因此服務(wù)器根本不會有機會知道瀏覽器已經(jīng)關(guān)閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關(guān)閉瀏覽器后這個session id就消失了，再次連接服務(wù)器時也就無法找到原來的session。
如果服務(wù)器設(shè)置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發(fā)出的HTTP請求頭，把原來的session id發(fā)送給服務(wù)器，則再次打開瀏覽器仍然能夠找到原來的session。

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