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

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

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

http/0.9
1991年發(fā)布，只有一個(gè)命令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)不僅可以傳輸文字，還能傳輸圖像、視頻、二進(jìn)制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)。除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動(dòng)手段。

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

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

**缺點(diǎn)：**

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

為了解決這個(gè)問題，有些瀏覽器在請(qǐng)求時(shí)，用

列表項(xiàng)目

了一個(gè)非標(biāo)準(zhǔn)的Connection字段。

Connection: keep-alive

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

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

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

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

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

**缺點(diǎn)**

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

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

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

HTTP/2
2015年，HTTP/2 發(fā)布。它不叫 HTTP/2.0，是因?yàn)闃?biāo)準(zhǔn)委員會(huì)不打算再發(fā)布子版本了，下一個(gè)新版本將是 HTTP/3。

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

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

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

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

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

無連接的——每次請(qǐng)求完成之后立即斷開連接

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

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

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

請(qǐng)求行

url —— Request URL

請(qǐng)求方法 —— Request Method

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

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

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

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


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

通用首部字段

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

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

Cookie主要用于以下三個(gè)方面：

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

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

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

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

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

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

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

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

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

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

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

同一個(gè)一級(jí)域名下的兩個(gè)二級(jí)域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不能交互使用Cookie，因?yàn)槎叩挠蛎⒉粐?yán)格相同。如果想所有helloweenvsfei.com名下的二級(jí)域名都可以使用該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會(huì)在maxAge秒之后自動(dòng)失效。瀏覽器會(huì)將maxAge為正數(shù)的Cookie持久化，即寫到對(duì)應(yīng)的Cookie文件中。無論客戶關(guān)閉了瀏覽器還是電腦，只要還在maxAge秒之前，登錄網(wǎng)站時(shí)該Cookie仍然有效。

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

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

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

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

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

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

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

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

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