1.Http協議概述
超文本傳輸協議（HyperText Transfer Tansfer Protocol），是一種基于TCP的應用層協議，也是目前為止最為流行的應用層協議之一，可以說HTTP協議是萬維網的基石。
HTTP是一種客戶端請求、服務器應答式的模式，服務器端一般是不可能主動向客戶端發送數據的，在網絡正常的情況下請求和響應的相互對應性的。
所以我們上網的時候只能去找度娘，度娘不會主動來找我們。
2.TCP/IP協議
TCP/IP協議：鏈路層（網絡接口層）、網絡層、傳輸層和應用層。
鏈路層：驅動程序、網卡
網絡層：IP協議、ICMP協議、ARP協議、RARP協議等。
傳輸層：TCP協議、UDP協議。
應用層：FTP、HTTP、TELNET、SMTP、DNS等協議。
協議之間的關系如下圖：
注意：網絡層IP提供的是一種不可靠的服務。它只是盡可能快地把分組從源節點送到目的節點，但不提供任何可靠性的保證。
而Tcp在不可靠的ip層上，提供了一個可靠的運輸層，采用了超時重傳、發送和接受端到端的確認分組等機制。
3.工作原理
* HTTP協議采用請求/響應模式，客戶端向服務器發送一個請求報文，然后服務器響應請求。
* 在瀏覽器中輸入URL，并按下回車鍵
* 瀏覽器向DNS服務器請求解析該URL中的域名對應的IP地址(如果是IP請求，則不需要該步驟)
* 解析出IP后，根據IP和端口號，和服務器建立TCP連接
* 瀏覽器向服務器發送請求
* 服務器做出響應，把數據發送給瀏覽器
* 通信完成，斷開TCP連接
* 瀏覽器解析收到的數據并顯示
4.Http報文在各層的封裝過程
二、HTTP報文格式詳解
1. 請求方式Method：
（1）GET：請求指定的頁面信息，并返回實體主體。
（2）POST?：請求服務器接受所指定的文檔作為對所標識的URI的新的從屬實體。一般用提交信息或數據，請求服務器進行處理（例如提交表單或者上傳文件）。
（3）HEAD?：與GET用法相同，但只請求資源首部。下載前可使用HEAD發送請求，通過ContentLength響應字段，來了解網絡資源的大小、可用來測試超鏈接的有效性，可用性和最近修改、用于判斷本地緩存資源是否要更新。?
HTTP 1.1新增：
（4）OPTIONS：允許客戶端查看服務器的性能，可以說這是一個探測性的方法，客戶端通過該方法可以在不訪問服務器上實際資源的情況下就知道處理該資源的最優方式。
（5）PUT：用冪等的方式向指定資源位置上傳其最新內容(原來沒有就上傳，有就上傳并覆蓋原來的內容)?
（6）DELETE：請求服務器刪除Request-URI所標識的資源。?
（7）TRACE：回顯服務器收到的請求，主要用于測試或診斷。
（8）CONNECT：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的鏈接（經由非加密的HTTP代理服務器）。?
GET VS POST：
GET和POST本質上都是TCP連接，由于HTTP的規定和瀏覽器/服務器的限制才導致它們在應用過程中體現出一些不同：
GET：
優點：簡單方便，一步發送
缺點：HTTP協議規范沒有對URL長度進行限制，瀏覽器及服務器對長度有限制，URL最好不要超過IE的最大長度限制(2083個字符）、只接受ASCII字符、隱私相關的信息也直接暴露在URI中（www.baidu.com?username=tanggang02&character=Robust）且會被cache
POST:
優點：沒有長度限制；參數放在Request Body中傳遞、默認不會被瀏覽器緩存，相對于更安全；支持的參數類型多樣。
缺點：多數瀏覽器對于POST采用兩階段發送數據的，先發送請求頭（Header），再發送請求體(Body)，即使參數再少再短，也會被分成兩個步驟來發送。也就是說GET產生一個TCP數據報，POST產生兩個TCP數據包報。
對于GET方式的請求，瀏覽器會把http header和data一并發送出去，服務器響應200（返回數據）；
而對于POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。
存在問題：當網絡狀態不好的時候且connect：close時，在傳輸層TCP會出現兩次連接的過程，通信次數越多反而可靠性越低。
建議：對數據請求頻繁，數據不敏感且數據量在普通瀏覽器最小限定的2k范圍內，這樣的情況使用GET。
PUT VS POST（協議語義上的約定）
冪等性概念：
單目運算, x為某集合內的任意數, f為運算子如果滿足f(x)=f(f(x)), 那么我們稱f運算為具有冪等性(idempotent)，比如在實數集中,絕對值運算就是一個例子: abs(a)=abs(abs(a))
雙目運算，x為某集合內的任意數, f為運算子如果滿足f(x,x)=x, f運算的前提是兩個參數都同為x, 那么我們也稱f運算為具有冪等性，比如在實數集中,求兩個數的最大值的函數: max(x,x) = x,?還有布爾代數中,邏輯運算 "與", "或" 也都是冪等運算, 因為他們符合AND(0,0) = 0, AND(1,1) = 1, OR(0,0) = 0, OR(1,1) = 1
PUT請求具有冪等性。將A修改為B，它第一次請求值變為了B，再進行多次此操作，最終的結果還是B，與一次執行的結果是一樣的。?
POST不是冪等操作，因為一次請求添加一份新資源，二次請求則添加了兩份新資源，多次請求會產生不同的結果。
比如：在我們的支付系統中，一個api的功能是創建收款金額二維碼，它和金額相關，每個用戶可以有多個二維碼，如果連續調用則會創建新的二維碼，這個時候就用POST
用戶的賬戶二維碼只和用戶關聯，而且是一一對應的關系，此時這個api就可以用PUT
性能優化：https://segmentfault.com/a/1190000000353790
2.Request-URI
常見形式：
scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
#fragment 片段ID：錨點，應用于客戶端，不會傳給服務器
相對路徑形式：
GET /yongche.php HTTP/1.1
...
...
在請求頭信息中一般有Host值來指定服務器主機
URL 保留字符的百分號編碼（% + ascii碼十六進制表示）
3.Http-Version
隊頭阻塞：下一個請求必須在前一個請求響應到達之前才能發送。假設前一個請求響應一直不到達，那么下一個請求就不發送，同樣的后面的請求也給阻塞了
HTTP 0.9 date-1991
已過時淘汰、只允許發GET請求，且不支持請求頭。
HTTP 1.0 date-1996年5月
支持請求響應頭、支持GET、POST、HEAD方法
長連接（默認Connection: close）、緩存機制（?Expires 過期時間）
支持任何格式的內容、使得互聯網不僅可以傳輸文字，還能傳輸圖像、視頻、二進制文件。這為互聯網的大發展奠定了基礎。
HTTP 1.1 date-1997年1月
長連接（默認Connection: Keep-Alive）
請求管道化? （優化了隊頭阻塞問題）
增加緩存處理（強緩存和協商緩存[傳送門]，針對緩存新增字段：cache-control）
增加Host字段(HTTP 1.0 默認認為每臺服務器都綁定一個唯一的IP地址)
SPDY 協議 date-2009
SPDY強制使用SSL傳輸協議，全部請求由SSL加密，信息傳輸更安全
HTTP 2.0 date-2015 (基于SPDY)
二進制分幀 頭信息和數據體都是二進制，統稱為幀
雙工復用（或連接共享） 數據流：幀亂序發送，根據幀首部的流標識符重新組裝
頭部信息壓縮 - 把Cookie、User Agent 客戶端、服務端同時維護一張頭信息表，所有字段存入并生成索引號，后續只發索引號
服務器推送 （Server Push） 服務端預期客戶端需要其他的資源，主動發送
4.HTTP頭信息
常見請求頭
1）、Host
Host用于指定請求資源的主機名和端口號(可選，默認80)。
Host:www.baidu.com
2）、User-Agent
用戶請求的代理軟件，包括用戶的操作系統，瀏覽器等相關屬性。
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36
3）、Referer
代表當前訪問的URL的上一個URL，也就是用戶是從什么地方轉到本頁面的。
Referer:https://www.baidu.com/
4）、Cookie
Cookie是個非常重要的請求頭，常用來表示請求者的身份。比如有些會話信息(SesssionId)會存在Cookie中。
Cookie:BAIDUID=AAABBBCCCDDDEEEFFFGGG;BIDUPSID=ZYXWVUOPQRST;PSTM=1494145048;__cfduid=d9a1edfb6fa7a6a21167d12a07558b2551494568096;BD_CK_SAM=1;PSINO=1;BD_HOME=1;H_PS_PSSID=1421_21079_21672_20927;BD_UPN=12314353;sugstore=1
5）、Cache-Control
指定請求和響應遵循的緩存機制，Cache-Control: no-cache
6）、Accept
客戶端接受什么類型的信息。類型用MIME表示。
比如：
Accept: text/html,application/xhtml+xml,application/json
7）、Accept-Charset
客戶端接受什么字符集的文本內容。如UTF-8，GBK等。
8）、Connection
表示是否需要持久連接。（HTTP 1.1默認進行持久連接） keep-alive、close
9）、Accept-Encoding
客戶端接受什么壓縮格式的內容。如gzip壓縮格式，deflate壓縮，sdch壓縮。
10）、Range
只請求實體的一部分，指定范圍，Range: bytes=500-999
實例：
Accept:
application/json
Accept-Encoding:
gzip, deflate
Accept-Language:
zh-CN,zh;q=0.9
Cache-Control:
no-cache
Connection:
keep-alive
Content-Length:
201
Content-Type:
application/x-www-form-urlencoded
Cookie:
BAIDUIDB=68591AE3191431C1F6BCFE9874:FG=1; BIDUPSID=A1FB6-AE7QpNY5V3r57dNX-uup; RCVIDAAAAAAEAAAAifplryMvJ-sjrz7cyMTYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIGjYluBo2kUmQAm;
BDRCVFR[4r8LXJfwh-6]=I67x6TjHwwYf0; H_PS_PSSID=
Host:
Origin:
http://cp01-carpool-4.epc.baidu.com:8889
Pragma:
no-cache
Referer:
http://cp.epc.baidu.com:8889/main/webapp?page=unionInvoiceInfo
User-Agent:
Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1
X-Requested-With:
XMLHttpRequest
常見響應頭
1）、Server
服務器所使用的Web服務器名稱。攻擊者可以通過查看該頭信息，來探測Web服務器名稱。所以一般服務器端會對該頭信息進行修改。
Server: Apache/2.4.6 (CentOS)
2）、Set-Cookie
向客戶端設置Cookie。與Cookie請求頭相互對應。Set-Cookie頭是服務器向客戶端設置Cookie，Cookie頭是客戶端向服務器傳客戶端已經保存的Cookie信息。
Set-Cookie: __bsi=12777267876439010180_00_68_R_N_70_0303_C027_N_I_I_0; expires=Thu, 18-May-17 16:32:52 GMT; domain=www.baidu.com;path=/
3）、Last-Modified
服務器通過該頭信息告訴瀏覽器，資源最后的修改時間。從而讓客戶端及時地更新緩存內容。
4）、Location
服務器通過該頭信息告訴瀏覽器去訪問那個頁面，瀏覽器接收到這樣的響應信息后，通常會立刻訪問Location頭所指向的頁面。這個頭通常配合302重定向狀態碼使用。
5）、Refresh
服務器通過Refresh頭信息讓瀏覽器定時刷新。
比如下面這個頭信息定時三秒后，刷新到百度頁面。
Refresh: 3;url="http://www.baidu.com"
6）、Cache-Control
指定客戶端對頁面的緩存策略。
比如下面的頭信息表示指定客戶端不緩存該頁面內容。
Cache-Control: no-cache
7）、Content-Type
響應實體的內容類型。
Content-Type: text/html;charset=utf-8
8）、Content-Encoding
響應實體的編碼方式
Content-Encoding: gzip
9）、Content-Length
響應實體的內容長度
5.Http響應碼
HTTP/1.0200OK
客戶端發出HTTP請求，服務端接收后，會向客戶端發送響應信息。
1XX：信息提示。表示請求已被服務器接受，但需要繼續處理，范圍為100~101。
2XX：請求成功。服務器成功處理了請求。范圍為200~206。
3XX：客戶端重定向。重定向狀態碼用于告訴客戶端瀏覽器，它們訪問的資源已被移動，并告訴客戶端新的資源位置。客戶端收到重定向會重新對新資源發起請求。范圍為300~305。
4XX：客戶端信息錯誤。客戶端可能發送了服務器無法處理的東西，比如請求的格式錯誤，或者請求了一個不存在的資源。范圍為400~415。
5XX：服務器出錯。客戶端發送了有效的請求，但是服務器自身出現錯誤，比如Web程序運行出錯。范圍是500~505。
圖片參考：http://blog.jobbole.com/88450/
三、HTTPS （http over ssl）
HTTPS是在HTTP的基礎上和ssl/tls證書結合起來的一種協議,保證了傳輸過程中的安全性,減少了被惡意劫持的可能。
過程：
* 客戶端發送請求到服務端，要求與Web服務器建立SSL連接。
* 服務端會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
* 客戶端接收后會驗證證書的安全性,如果通過則會隨機生成一個隨機數,用公鑰對其加密,發送到服務端
* 服務端接受到這個加密后的隨機數后會用私鑰對其解密得到真正的隨機數,隨后用這個隨機數當做會話密鑰對需要發送的數據進行對稱加密
* 客戶端在接收到加密后的數據使用會話密鑰(即生成的隨機值)對數據進行解密并且解析數據呈現結果給客戶
* SSL加密建立
HTTPS使用的加密方式結合了對稱加密和不對稱加密的特點，在保證安全的情況下，又提高了傳輸效率。HTTP和HTTPS的區別如下：
https協議需要到ca申請證書，一般免費證書很少，需要交費。
http的信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。
http和https用的端口不一樣，前者是80，后者是443。
http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全
優點：
使用HTTPS協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，要比http協議安全，可防止數據在傳輸過程中不被竊取、改變，確保數據的完整性。
HTTPS是現行架構下比較安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
谷歌曾在2014年8月份調整搜索引擎算法，并稱“比起同等HTTP網站，采用HTTPS加密的網站在搜索結果中的排名將會更高”。
缺點：
SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
HTTPS協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。最關鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
