這幾天，閱讀RFC2616認真學習一遍HTTP/1.1協議，一直認為要做互聯網開發的話，一定要對於HTTP協議爛熟於胸，於是下定決心要將這個協議好好理解一遍。這兩天，工作之余，拿著RFC就在那裏讀，對於HTTP協議有了不錯的理解，對於其中的字段與機制有了一定的理解，於是靜下心來，好好總結一下這兩天的閱讀收獲，同時也是一個回顧復習。

HTTP協議描述的是發送方與接收方的通信協議，通過兩方的自覺遵守而存在，當然有不少的瀏覽器並沒有百分百遵守這份協議。HTTP是運行於應用層的協議，基於TCP協議而運作。基本上是客戶/服務器對答模式，其中也包括在傳輸過程中的代理，網關，通道，緩存等都需要遵守這份協議。

閱讀完RFC之後，較為難以理解的部分是關於連接機制與緩存機制，其他都基本上是字段與頭部格式的定義，在裏面就不一一列舉，提供一個快查的網址：Quick reference to HTTP headers;

主要有兩種比較重要的機制，在這裏總結一下：

一， 連接機制;

HTTP/1.1支持兩種連接機制，一種是非持久連接，第二種是持久連接。基本上默認是使用持久連接，因為這樣能夠減少建立連接時候的網絡延時與CPU消耗。其中服務器與客戶端都會假定連接沒有關閉，除非對方傳來的頭文件包含" Connection:close"，不然連接將繼續保持。客戶端，服務器與代理都可以隨時結束連接，而他們也應該有一套機制去重新搭建起連接，並保持正確性。每個客戶端也只能與一個服務器保持兩條連接。代理也只能保持2N條連接，N 為代理的活躍用戶數。對於連接的時候，由用戶向服務器端發送一個帶有"Expect"的信息到服務器端，服務器端如果連接正常則返回一個100 ( continue )的信息到客戶端，提示客戶端可以繼續發送。

HTTP對於傳輸道路上的元素也有一定的要求。也規定了不透明代理可以改變哪些字段，而不能改變哪些字段。

二．緩存機制;

HTTP中使用緩存主要有兩個作用，一個是在很多情況下可以減少發送包，減少網絡IO，使用“過期”機制來處理；第二個是可以減少發送整包的操作，減少帶寬需求，使用“驗證”機制來處理。

(1)“過期”機制(Expiration Model)，用於服務器端制定一個“過期時間”，主要有兩種計算方式，按優先級順序，第一種是年齡(Age)，第二種是過期時間(Expiration)。對於第一種，服務器會提供一個年齡字段（Age)與一個有效年齡(max-age)，而年齡的計算，則是采用服務器生成時的初始年齡再加上從服務器生成至緩存的時間。如果有Age 這個字段的存在，則說明這個消息不是第一手的，中間有緩存的存在。而要計算一個消息是否過期，則需要采用以下的方法：

if( max_age_value )

Freshness_lifetime = max_age_value ;

Else

Freshness_lifetime = expires_value - date_value ;

Response_is_fresh = ( freshness_lifetime > current_age ) ;

總體計算方法都比較直觀與簡單，而如果需要更新緩存的話，則可以加入以下字段：

Cache-Control : max-age = 0 ; OR Cache-Control : no-cache ;

(2)驗證機制(Validation Model ) ,采用這種機制的時候，緩存先向服務器驗證當前的緩存條目是否最新的，則收到304的提示表示 Not Modified，條目是最新的。否則則會收到服務器返回的新緩存條目。而進行驗證的時候，可以使用兩個標準，一個是使用服務器在原條目上的"Last-Modified"，使用條件GET(If-Modified-Since OR If-Not-Modified-Since)去查詢。第二個是使用服務器為每個條目生成的"Entity Tag"，這個Tag如何生成完成由服務器去決定，因此也衍生出兩種驗證策略，一種是強驗證，即如果一個條目發生了改變之後"Entity Tag"也馬上變化的，第二種是使用弱驗證，即條目變化了"Entity Tag"仍然保持不變，相對驗證條件更弱。而對於是使用強驗證還是弱驗證則是取決於服務器端了。

以前對於HTTP和FTP也是有所了解的，看了一遍英文版的RFC文檔，雖然很痛苦，但是感覺是有所不同的。

1，HTTP所表達的控制以及描述性相關的信息都包含在了HTTP的起始行和首部之中。BNF的使用使得自己能夠清晰的梳理出起始行和首部中所有類別的元信息。對於每一類的元信息具體包含哪些內容也能夠有所了解。這一抽象的方法不僅HTTP協議定義的時候比較嚴謹之外，在實現HTTP解析器（瀏覽器）的時候參照BNF寫代碼是非常容易實現的。這也提醒了我們在編寫相關的系統設計方案的時候是可以借鑒類似的方法的。畢竟使用文字表述的設計方案存在這問題遺漏，表述不夠清晰，不同人理解有所差異等方面的問題。（我們會看到在FTP之中也有類似的方法，狀態圖）。HTTP被設計成為一種非常容易擴展的協議，因此協議時松散的。頭域可以加入需要的頭部名和指定的值，盡管有的頭部沒有加入RFC標準，但是可能成為約定成俗的標準(雖然這會給HTTP的安全性帶來了挑戰)，由此可以看出良好的設計方案在一開始的時候就考慮到其以擴展性，這也是HTTP能夠長期存在，不斷發展的原因。

2，FTP采用的是控制和數據相分離的模式實現文件的傳送。首先這一設計思想在程序的設計之中本身就很常見。FTP采用的是命令+響應碼的形式來控制文件傳輸的功能，若幹條命令+不同類別的響應碼會導致不同的結果，其組合方式多種多樣，但是FTP的RFC文檔給出了這些組合的狀態圖。六種類型的狀態圖覆蓋了FTP可能的所有情況。前面我們提到HTTP的BNF表示方法利於編寫程序，這裏的狀態圖同樣給出了編寫完備FTP軟件的指導性方法。當然狀態圖也可以看出有的命令是有先後順序的，但是大多數的命令是沒有此要求的。

3，RTSP可以說基本復用了HTTP的設計思路，從請求和響應的消息組成可以清晰的看出。但是其也借鑒了FTP中相關的優秀思想。比如數據和控制的分離，RTSP的數據傳輸就是由RTP/RTCP等協議去實現的。在HTTP中，請求響應模式采用的是CS的模式，即客戶端發起請求，服務器應答響應。FTP的就發生了變化，首先在FTP的架構之中存在這一個客戶端控制這兩個服務器的通信。兩個SERVER的通信以及在FTP中的Port模式下（數據連接是由服務器發起的），這兩種情況跟HTTP就很不相同。至於到了RTSP請求是雙向的。

總的來說三種協議都是基於文本的應用層協議，基於文本的協議在需要某些屬性、方法或者命令的時候能夠比較方便的添加。相對與傳輸層以及網絡層（雖然也有擴展）來說，固定的位置表達的含義是確定的，基於文本的協議比較靈活多變。當然協議最基本的分層原則也在HTTP，FTP以及RTSP中有所體現，即應用層協議應盡量減少其與下層之間的耦合性。雖然常見的HTTP都是基於TCP協議的，但是HTTP並不關心整個HTTP消息在傳輸層如何使用的。

一、概述

1.1 五層模型

互聯網的實現，分成好幾層。每一層都有自己的功能，就像建築物一樣，每一層都靠下一層支持。

用戶接觸到的，只是最上面的一層，根本沒有感覺到下面的層。要理解互聯網，必須從最下層開始，自下而上理解每一層的功能。

如何分層有不同的模型，有的模型分七層，有的分四層。我覺得，把互聯網分成五層，比較容易解釋。

如上圖所示，最底下的一層叫做"實體層"（Physical Layer），最上面的一層叫做"應用層"（Application Layer），中間的三層（自下而上）分別是"鏈接層"（Link Layer）、"網絡層"（Network Layer）和"傳輸層"（Transport Layer）。越下面的層，越靠近硬件；越上面的層，越靠近用戶。

它們叫什麽名字，其實並不重要。只需要知道，互聯網分成若幹層就可以了。

1.2 層與協議

每一層都是為了完成一種功能。為了實現這些功能，就需要大家都遵守共同的規則。

大家都遵守的規則，就叫做"協議"（protocol）。

互聯網的每一層，都定義了很多協議。這些協議的總稱，就叫做"互聯網協議"（Internet Protocol Suite）。它們是互聯網的核心，下面介紹每一層的功能，主要就是介紹每一層的主要協議。

二、實體層

我們從最底下的一層開始。

電腦要組網，第一件事要幹什麽？當然是先把電腦連起來，可以用光纜、電纜、雙絞線、無線電波等方式。

這就叫做"實體層"，它就是把電腦連接起來的物理手段。它主要規定了網絡的一些電氣特性，作用是負責傳送0和1的電信號。

三、鏈接層

3.1 定義

單純的0和1沒有任何意義，必須規定解讀方式：多少個電信號算一組？每個信號位有何意義？

這就是"鏈接層"的功能，它在"實體層"的上方，確定了0和1的分組方式。

3.2 以太網協議

早期的時候，每家公司都有自己的電信號分組方式。逐漸地，一種叫做"以太網"（Ethernet）的協議，占據了主導地位。

以太網規定，一組電信號構成一個數據包，叫做"幀"（Frame）。每一幀分成兩個部分：標頭（Head）和數據（Data）。

"標頭"包含數據包的一些說明項，比如發送者、接受者、數據類型等等；"數據"則是數據包的具體內容。

"標頭"的長度，固定為18字節。"數據"的長度，最短為46字節，最長為1500字節。因此，整個"幀"最短為64字節，最長為1518字節。如果數據很長，就必須分割成多個幀進行發送。

3.3 MAC地址

上面提到，以太網數據包的"標頭"，包含了發送者和接受者的信息。那麽，發送者和接受者是如何標識呢？

以太網規定，連入網絡的所有設備，都必須具有"網卡"接口。數據包必須是從一塊網卡，傳送到另一塊網卡。網卡的地址，就是數據包的發送地址和接收地址，這叫做MAC地址。

每塊網卡出廠的時候，都有一個全世界獨一無二的MAC地址，長度是48個二進制位，通常用12個十六進制數表示。

前6個十六進制數是廠商編號，後6個是該廠商的網卡流水號。有了MAC地址，就可以定位網卡和數據包的路徑了。

3.4 廣播

定義地址只是第一步，後面還有更多的步驟。

首先，一塊網卡怎麽會知道另一塊網卡的MAC地址？

回答是有一種ARP協議，可以解決這個問題。這個留到後面介紹，這裏只需要知道，以太網數據包必須知道接收方的MAC地址，然後才能發送。

其次，就算有了MAC地址，系統怎樣才能把數據包準確送到接收方？

回答是以太網采用了一種很"原始"的方式，它不是把數據包準確送到接收方，而是向本網絡內所有計算機發送，讓每臺計算機自己判斷，是否為接收方。

上圖中，1號計算機向2號計算機發送一個數據包，同一個子網絡的3號、4號、5號計算機都會收到這個包。它們讀取這個包的"標頭"，找到接收方的MAC地址，然後與自身的MAC地址相比較，如果兩者相同，就接受這個包，做進一步處理，否則就丟棄這個包。這種發送方式就叫做"廣播"（broadcasting）。

有了數據包的定義、網卡的MAC地址、廣播的發送方式，"鏈接層"就可以在多臺計算機之間傳送數據了。

四、網絡層

4.1 網絡層的由來

以太網協議，依靠MAC地址發送數據。理論上，單單依靠MAC地址，上海的網卡就可以找到洛杉磯的網卡了，技術上是可以實現的。

但是，這樣做有一個重大的缺點。以太網采用廣播方式發送數據包，所有成員人手一"包"，不僅效率低，而且局限在發送者所在的子網絡。也就是說，如果兩臺計算機不在同一個子網絡，廣播是傳不過去的。這種設計是合理的，否則互聯網上每一臺計算機都會收到所有包，那會引起災難。

互聯網是無數子網絡共同組成的一個巨型網絡，很像想象上海和洛杉磯的電腦會在同一個子網絡，這幾乎是不可能的。

因此，必須找到一種方法，能夠區分哪些MAC地址屬於同一個子網絡，哪些不是。如果是同一個子網絡，就采用廣播方式發送，否則就采用"路由"方式發送。（"路由"的意思，就是指如何向不同的子網絡分發數據包，這是一個很大的主題，本文不涉及。）遺憾的是，MAC地址本身無法做到這一點。它只與廠商有關，與所處網絡無關。

這就導致了"網絡層"的誕生。它的作用是引進一套新的地址，使得我們能夠區分不同的計算機是否屬於同一個子網絡。這套地址就叫做"網絡地址"，簡稱"網址"。

於是，"網絡層"出現以後，每臺計算機有了兩種地址，一種是MAC地址，另一種是網絡地址。兩種地址之間沒有任何聯系，MAC地址是綁定在網卡上的，網絡地址則是管理員分配的，它們只是隨機組合在一起。

網絡地址幫助我們確定計算機所在的子網絡，MAC地址則將數據包送到該子網絡中的目標網卡。因此，從邏輯上可以推斷，必定是先處理網絡地址，然後再處理MAC地址。

4.2 IP協議

規定網絡地址的協議，叫做IP協議。它所定義的地址，就被稱為IP地址。

目前，廣泛采用的是IP協議第四版，簡稱IPv4。這個版本規定，網絡地址由32個二進制位組成。

習慣上，我們用分成四段的十進制數表示IP地址，從0.0.0.0一直到255.255.255.255。

互聯網上的每一臺計算機，都會分配到一個IP地址。這個地址分成兩個部分，前一部分代表網絡，後一部分代表主機。比如，IP地址172.16.254.1，這是一個32位的地址，假定它的網絡部分是前24位（172.16.254），那麽主機部分就是後8位（最後的那個1）。處於同一個子網絡的電腦，它們IP地址的網絡部分必定是相同的，也就是說172.16.254.2應該與172.16.254.1處在同一個子網絡。

但是，問題在於單單從IP地址，我們無法判斷網絡部分。還是以172.16.254.1為例，它的網絡部分，到底是前24位，還是前16位，甚至前28位，從IP地址上是看不出來的。

那麽，怎樣才能從IP地址，判斷兩臺計算機是否屬於同一個子網絡呢？這就要用到另一個參數"子網掩碼"（subnet mask）。

所謂"子網掩碼"，就是表示子網絡特征的一個參數。它在形式上等同於IP地址，也是一個32位二進制數字，它的網絡部分全部為1，主機部分全部為0。比如，IP地址172.16.254.1，如果已知網絡部分是前24位，主機部分是後8位，那麽子網絡掩碼就是11111111.11111111.11111111.00000000，寫成十進制就是255.255.255.0。

知道"子網掩碼"，我們就能判斷，任意兩個IP地址是否處在同一個子網絡。方法是將兩個IP地址與子網掩碼分別進行AND運算（兩個數位都為1，運算結果為1，否則為0），然後比較結果是否相同，如果是的話，就表明它們在同一個子網絡中，否則就不是。

比如，已知IP地址172.16.254.1和172.16.254.233的子網掩碼都是255.255.255.0，請問它們是否在同一個子網絡？兩者與子網掩碼分別進行AND運算，結果都是172.16.254.0，因此它們在同一個子網絡。

總結一下，IP協議的作用主要有兩個，一個是為每一臺計算機分配IP地址，另一個是確定哪些地址在同一個子網絡。

4.3 IP數據包

根據IP協議發送的數據，就叫做IP數據包。不難想象，其中必定包括IP地址信息。

但是前面說過，以太網數據包只包含MAC地址，並沒有IP地址的欄位。那麽是否需要修改數據定義，再添加一個欄位呢？

回答是不需要，我們可以把IP數據包直接放進以太網數據包的"數據"部分，因此完全不用修改以太網的規格。這就是互聯網分層結構的好處：上層的變動完全不涉及下層的結構。

具體來說，IP數據包也分為"標頭"和"數據"兩個部分。

"標頭"部分主要包括版本、長度、IP地址等信息，"數據"部分則是IP數據包的具體內容。它放進以太網數據包後，以太網數據包就變成了下面這樣。

IP數據包的"標頭"部分的長度為20到60字節，整個數據包的總長度最大為65,535字節。因此，理論上，一個IP數據包的"數據"部分，最長為65,515字節。前面說過，以太網數據包的"數據"部分，最長只有1500字節。因此，如果IP數據包超過了1500字節，它就需要分割成幾個以太網數據包，分開發送了。

4.4 ARP協議

關於"網絡層"，還有最後一點需要說明。

因為IP數據包是放在以太網數據包裏發送的，所以我們必須同時知道兩個地址，一個是對方的MAC地址，另一個是對方的IP地址。通常情況下，對方的IP地址是已知的（後文會解釋），但是我們不知道它的MAC地址。

所以，我們需要一種機制，能夠從IP地址得到MAC地址。

這裏又可以分成兩種情況。第一種情況，如果兩臺主機不在同一個子網絡，那麽事實上沒有辦法得到對方的MAC地址，只能把數據包傳送到兩個子網絡連接處的"網關"（gateway），讓網關去處理。

第二種情況，如果兩臺主機在同一個子網絡，那麽我們可以用ARP協議，得到對方的MAC地址。ARP協議也是發出一個數據包（包含在以太網數據包中），其中包含它所要查詢主機的IP地址，在對方的MAC地址這一欄，填的是FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。它所在子網絡的每一臺主機，都會收到這個數據包，從中取出IP地址，與自身的IP地址進行比較。如果兩者相同，都做出回復，向對方報告自己的MAC地址，否則就丟棄這個包。

總之，有了ARP協議之後，我們就可以得到同一個子網絡內的主機MAC地址，可以把數據包發送到任意一臺主機之上了。

五、傳輸層

5.1 傳輸層的由來

有了MAC地址和IP地址，我們已經可以在互聯網上任意兩臺主機上建立通信。

接下來的問題是，同一臺主機上有許多程序都需要用到網絡，比如，你一邊瀏覽網頁，一邊與朋友在線聊天。當一個數據包從互聯網上發來的時候，你怎麽知道，它是表示網頁的內容，還是表示在線聊天的內容？

也就是說，我們還需要一個參數，表示這個數據包到底供哪個程序（進程）使用。這個參數就叫做"端口"（port），它其實是每一個使用網卡的程序的編號。每個數據包都發到主機的特定端口，所以不同的程序就能取到自己所需要的數據。

"端口"是0到65535之間的一個整數，正好16個二進制位。0到1023的端口被系統占用，用戶只能選用大於1023的端口。不管是瀏覽網頁還是在線聊天，應用程序會隨機選用一個端口，然後與服務器的相應端口聯系。

"傳輸層"的功能，就是建立"端口到端口"的通信。相比之下，"網絡層"的功能是建立"主機到主機"的通信。只要確定主機和端口，我們就能實現程序之間的交流。因此，Unix系統就把主機+端口，叫做"套接字"（socket）。有了它，就可以進行網絡應用程序開發了。

5.2 UDP協議

現在，我們必須在數據包中加入端口信息，這就需要新的協議。最簡單的實現叫做UDP協議，它的格式幾乎就是在數據前面，加上端口號。

UDP數據包，也是由"標頭"和"數據"兩部分組成。

"標頭"部分主要定義了發出端口和接收端口，"數據"部分就是具體的內容。然後，把整個UDP數據包放入IP數據包的"數據"部分，而前面說過，IP數據包又是放在以太網數據包之中的，所以整個以太網數據包現在變成了下面這樣：

UDP數據包非常簡單，"標頭"部分一共只有8個字節，總長度不超過65,535字節，正好放進一個IP數據包。

5.3 TCP協議

UDP協議的優點是比較簡單，容易實現，但是缺點是可靠性較差，一旦數據包發出，無法知道對方是否收到。

為了解決這個問題，提高網絡可靠性，TCP協議就誕生了。這個協議非常復雜，但可以近似認為，它就是有確認機制的UDP協議，每發出一個數據包都要求確認。如果有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。

因此，TCP協議能夠確保數據不會遺失。它的缺點是過程復雜、實現困難、消耗較多的資源。

TCP數據包和UDP數據包一樣，都是內嵌在IP數據包的"數據"部分。TCP數據包沒有長度限制，理論上可以無限長，但是為了保證網絡的效率，通常TCP數據包的長度不會超過IP數據包的長度，以確保單個TCP數據包不必再分割。

六、應用層

應用程序收到"傳輸層"的數據，接下來就要進行解讀。由於互聯網是開放架構，數據來源五花八門，必須事先規定好格式，否則根本無法解讀。

"應用層"的作用，就是規定應用程序的數據格式。

舉例來說，TCP協議可以為各種各樣的程序傳遞數據，比如Email、WWW、FTP等等。那麽，必須有不同協議規定電子郵件、網頁、FTP數據的格式，這些應用程序協議就構成了"應用層"。

這是最高的一層，直接面對用戶。它的數據就放在TCP數據包的"數據"部分。因此，現在的以太網的數據包就變成下面這樣。

至此，整個互聯網的五層結構，自下而上全部講完了。這是從系統的角度，解釋互聯網是如何構成的。下一篇，我反過來，從用戶的角度，自上而下看看這個結構是如何發揮作用，完成一次網絡數據交換的。

本文介紹如何將一個 HTTP 網站升級到 HTTPS 。

一、獲取證書

升級到 HTTPS 協議的第一步，就是要獲得一張證書。

證書是一個二進制文件，裏面包含經過認證的網站公鑰和一些元數據，要從經銷商購買。

• GoGetSSL
• SSLs.com
• SSLmate.com

證書有很多類型，首先分為三種認證級別。

• 域名認證（Domain Validation）：最低級別認證，可以確認申請人擁有這個域名。對於這種證書，瀏覽器會在地址欄顯示一把鎖。
• 公司認證（Company Validation）：確認域名所有人是哪一家公司，證書裏面會包含公司信息。
• 擴展認證（Extended Validation）：最高級別的認證，瀏覽器地址欄會顯示公司名。

還分為三種覆蓋範圍。

• 單域名證書：只能用於單一域名，foo.com的證書不能用於www.foo.com
• 通配符證書：可以用於某個域名及其所有一級子域名，比如*.foo.com的證書可以用於foo.com，也可以用於www.foo.com
• 多域名證書：可以用於多個域名，比如foo.com和bar.com

認證級別越高、覆蓋範圍越廣的證書，價格越貴。

還有一個免費證書的選擇。為了推廣HTTPS協議，電子前哨基金會EFF成立了 Let‘s Encrypt，提供免費證書（教程和工具）。

拿到證書以後，可以用 SSL Certificate Check 檢查一下，信息是否正確。

二、安裝證書

證書可以放在/etc/ssl目錄（Linux 系統），然後根據你使用的Web服務器進行配置。

• 證書配置文件生成器，by Mozilla
• 配置文件模板，by SSLMate

如果使用 Let‘s Encrypt 證書，請使用自動安裝工具 Certbot。

安裝成功後，使用 SSL Labs Server Test 檢查一下證書是否生效。

三、修改鏈接

下一步，網頁加載的 HTTP 資源，要全部改成 HTTPS 鏈接。因為加密網頁內如果有非加密的資源，瀏覽器是不會加載那些資源的。

<script src="http://foo.com/jquery.js"></script>

上面這行加載命令，有兩種改法。

<!-- 改法一 -->
<script src="https://foo.com/jquery.js"></script>

<!-- 改法二 -->
<script src="//foo.com/jquery.js"></script>

其中，改法二會根據當前網頁的協議，加載相同協議的外部資源，更靈活一些。

另外，如果頁面頭部用到了rel="canonical"，也要改成HTTPS網址。

<link rel="canonical" href="https://foo.com/bar.html" />

四、301重定向

下一步，修改 Web 服務器的配置文件，使用 301 重定向，將 HTTP 協議的訪問導向 HTTPS 協議。

Nginx 的寫法。

server {
  listen 80;
  server_name domain.com www.domain.com;
  return 301 https://domain.com$request_uri;
}

Apache 的寫法（.htaccess文件）。

2. RewriteEngine On
3. RewriteCond %{HTTPS} off
4. RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

五、安全措施

以下措施可以進一步保證通信安全。

5.1 HTTP Strict Transport Security (HSTS)

訪問網站時，用戶很少直接在地址欄輸入https://，總是通過點擊鏈接，或者3xx重定向，從HTTP頁面進入HTTPS頁面。攻擊者完全可以在用戶發出HTTP請求時，劫持並篡改該請求。

另一種情況是惡意網站使用自簽名證書，冒充另一個網站，這時瀏覽器會給出警告，但是許多用戶會忽略警告繼續訪問。

"HTTP嚴格傳輸安全"（簡稱 HSTS）的作用，就是強制瀏覽器只能發出HTTPS請求，並阻止用戶接受不安全的證書。

它在網站的響應頭裏面，加入一個強制性聲明。以下例子摘自維基百科。

Strict-Transport-Security: max-age=31536000; includeSubDomains

上面這段頭信息有兩個作用。

（1）在接下來的一年（即31536000秒）中，瀏覽器只要向example.com或其子域名發送HTTP請求時，必須采用HTTPS來發起連接。用戶點擊超鏈接或在地址欄輸入http://www.example.com/，瀏覽器應當自動將http轉寫成https，然後直接向https://www.example.com/發送請求。

（2）在接下來的一年中，如果example.com服務器發送的證書無效，用戶不能忽略瀏覽器警告，將無法繼續訪問該網站。

HSTS 很大程度上解決了 SSL 剝離攻擊。只要瀏覽器曾經與服務器建立過一次安全連接，之後瀏覽器會強制使用HTTPS，即使鏈接被換成了HTTP。

該方法的主要不足是，用戶首次訪問網站發出HTTP請求時，是不受HSTS保護的。

如果想要全面分析網站的安全程度，可以使用 Mozilla 的 Observatory。

5.2 Cookie

另一個需要註意的地方是，確保瀏覽器只在使用 HTTPS 時，才發送Cookie。

網站響應頭裏面，Set-Cookie字段加上Secure標誌即可。

Set-Cookie: LSID=DQAAAK...Eaem_vYg; Secure

什麽是http及RFC?