【http協議】淺談
【http協議】淺談
一、 概述
http，超文本傳輸協議(HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議。
- 請求與響應： 客戶端發送請求，服務器端響應數據
- 無狀態的： 無狀態是指協議對於事務處理沒有記憶功能。缺少狀態意味著，假如後面的處理需要前面的信息，則前面的信息必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要前面信息時，應答就較快。直觀地說，就是每個請求都是獨立的，與前面的請求和後面的請求都是沒有直接聯系的。
- 應用層：Http是屬於應用層的協議，配合TCP/IP使用。
- TCP/IP：Http使用TCP作為它的支撐運輸協議。HTTP客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器（客戶機）和服務器進程就可以通過套接字接口訪問TCP
二、HTTP請求
1.請求報文
HTTP請求是客戶端往服務端發送請求動作，告知服務器自己的要求。
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成
（1）請求行
請求行分為三個部分：請求方法、請求地址和協議版本
請求方法
HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常的兩種GET和POST，如果是RESTful接口的話一般會用到GET、POST、DELETE、PUT。（什麽是RESTFul？）
GET --- 訪問服務器的資源
POST --- 向服務器發送要修改的數據 HEAD --- 獲取服務器文檔的首部 PUT --- 向服務器上傳資源 DELETE--- 刪除服務器的資源
請求地址
URL：統一資源定位符，是一種自願位置的抽象唯一識別方法。
組成：<協議>：//<主機>：<端口>/<路徑>
端口和路徑有時可以省略（HTTP默認端口號是80）
如下例：
有時會帶參數，GET請求
協議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1
（2）請求頭部
請求頭部為請求報文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。
常見請求頭如下：
請求頭部的最後會有一個空行，表示請求頭部結束，接下來為請求數據，這一行非常重要，必不可少。
（3）請求數據
可選部分，比如GET請求就沒有請求數據。
下面是一個POST方法的請求報文：
POST /index.php HTTP/1.1 請求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 請求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer:http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
空行
username=aa&password=1234 請求數據
三、HTTP響應報文
HTTP響應報文主要由狀態行、響應頭部、空行以及響應數據組成。
1.狀態行
由3部分組成，分別為：協議版本，狀態碼，狀態碼描述。
其中協議版本與請求報文一致，狀態碼描述是對狀態碼的簡單描述，所以這裏就只介紹狀態碼。
狀態碼
狀態代碼為3位數字。
1xx：指示信息——表示請求已接收，繼續處理。
2xx：成功——表示請求已被成功接收、理解、接受。
3xx：重定向——要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤——請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤——服務器未能實現合法的請求。
下面列舉幾個常見的：
200---OK/請求已經正常處理完畢
301---/請求永久重定向
302---/請求臨時重定向
304---/請求被重定向到客戶端本地緩存
400---/客戶端請求存在語法錯誤
401---/客戶端請求沒有經過授權
403---/客戶端的請求被服務器拒絕，一般為客戶端沒有訪問權限
404---/客戶端請求的URL在服務端不存在
500---/服務端永久錯誤
503---/服務端發生臨時錯誤2.響應頭部
與請求頭部類似，為響應報文添加了一些附加信息
常見響應頭部如下：
3.響應數據
用於存放需要返回給客戶端的數據信息。
下面是一個響應報文的實例：
HTTP/1.1 200 OK 狀態行
Date: Sun, 17 Mar 2013 08:12:54 GMT 響應頭部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
空行
<html> 響應數據
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>關於請求頭部和響應頭部的知識點很多，這裏只是簡單介紹。
通過以上步驟，數據已經傳遞完畢，HTTP/1.1會維持持久連接，但持續一段時間總會有關閉連接的時候，這時候據需要斷開TCP連接。
四、HTTP版本
HTTP/0.9
HTTP協議的最初版本，功能簡陋，僅支持請求方式GET，並且僅能請求訪問HTML格式的資源。
HTTP/1.0
在0.9版本上做了進步，增加了請求方式POST和HEAD；不再局限於0.9版本的HTML格式，根據Content-Type可以支持多種數據格式，即MIME多用途互聯網郵件擴展，例如text/html、image/jpeg等；同時也開始支持cache，就是當客戶端在規定時間內訪問統一網站，直接訪問cache即可。
但是1.0版本的工作方式是每次TCP連接只能發送一個請求，當服務器響應後就會關閉這次連接，下一個請求需要再次建立TCP連接，就是不支持keepalive。
HTTP/1.1
解決了1.0版本的keepalive問題，1.1版本加入了持久連接，一個TCP連接可以允許多個HTTP請求； 加入了管道機制，一個TCP連接同時允許多個請求同時發送，增加了並發性；新增了請求方式PUT、PATCH、DELETE等。
但是還存在一些問題，服務端是按隊列順序處理請求的，假如一個請求處理時間很長，則會導致後邊的請求無法處理，這樣就造成了隊頭阻塞的問題；同時HTTP是無狀態的連接，因此每次請求都需要添加重復的字段，降低了帶寬的利用率。
HTTP/2.0
為了解決1.1版本利用率不高的問題，提出了HTTP/2.0版本。增加雙工模式，即不僅客戶端能夠同時發送多個請求，服務端也能同時處理多個請求，解決了隊頭堵塞的問題；HTTP請求和響應中，狀態行和請求/響應頭都是些信息字段，並沒有真正的數據，因此在2.0版本中將所有的信息字段建立一張表，為表中的每個字段建立索引，客戶端和服務端共同使用這個表，他們之間就以索引號來表示信息字段，這樣就避免了1.0舊版本的重復繁瑣的字段，並以壓縮的方式傳輸，提高利用率。
另外也增加服務器推送的功能，即不經請求服務端主動向客戶端發送數據。
當前主流的協議版本還是HTTP/1.1版本。
網站訪問量
IP IP訪問量
相同的公網IP計算一次，就是同一個局域網內的所有用戶訪問一個網站，但是他們都是借助一個公網IP去訪問那個網站的（NAT），因此這也只能算作一個IP訪問量。換一次公網IP則會加1。
PV 網頁訪問量
用戶訪問的頁面數就是PV訪問量，同一個局域網的不同用戶，而且就算是同一個用戶，只要刷新一次網站頁面，PV訪問量就加1，三個訪問量的值往往數PV的值最大。
UV 訪客訪問量
這裏的訪客不是用戶，而是電腦，一臺電腦算一個訪客，即使是同一臺電腦的不同用戶，訪問同一個網站UV也只能加1，只有更換電腦才會使UV加1，因為服務端會記錄客戶端電腦的信息。
五、怎麽理解無狀態
http無狀態：
是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。其次隨著客戶端與服務器進行動態交互的Web應用程序的出現，如購物車程序需要知道用戶到底在之前選擇了什麽商品，則需要解決無狀態的問題。為支持客戶端與服務器之間的交互，需要通過不同的技術為交互存儲狀態，而這些不同的技術就是Cookie和Session了。
Cookie解決方案：
通過客戶端保持狀態，該方式將服務器發給客戶端的特殊信息，以文本文件的方式存放在客戶端，然後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息。當用戶連接到支持cookie的網站時，用戶會提供包括用戶名在內的個人信息並且提交至服務器；接著，服務器在向客戶端回傳相應的超文本的同時也會發回這些個人信息。如登陸購物添加到購物車以及登陸時是否保存密碼等都是通過將信息保存到Cookie是產生的作用。
Session解決方案：
當客戶端訪問服務器時，服務器根據需求設置Session，將會話信息保存在服務器上，同時將標示Session的SessionId傳遞給客戶端瀏覽器。瀏覽器將這個 SessionId 保存在內存中，我們稱之為無過期時間的 Cookie。瀏覽器關閉後，這個 Cookie 就會被清掉，它不會存在於用戶的 Cookie 臨時文件。以後瀏覽器每次請求都會額外加上這個參數值，服務器會根據這個 SessionId，就能取得客戶端的數據信息。如果客戶端瀏覽器意外關閉，服務器保存的 Session 數據不是立即釋放，此時數據還會存在，只要我們知道那個SessionId，就可以繼續通過請求獲得此Session 的信息。因為此時後臺的 Session 還存在，當然我們可以設置一個 Session 超時時間，一旦超過規定時間沒有客戶端請求時，服務器就會清除對應 SessionId 的 Session 信息。
六、http和https
HTTP特點：
無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作
無連接：HTTP/1.1之前，由於無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
基於請求和響應：基本的特性，由客戶端發起請求，服務端響應
簡單快速、靈活
通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性
HTTPS特點：
基於HTTP協議，通過SSL或TLS提供加密處理數據、驗證對方身份以及數據完整性保護
內容加密：采用混合加密技術，中間者無法直接查看明文內容
驗證身份：通過證書認證客戶端訪問的是自己的服務器
保護數據完整性：防止傳輸的內容被中間人冒充或者篡改
安全性考慮：
HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麽作用
SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行
中間人攻擊（MITM攻擊）是指，黑客攔截並篡改網絡中的通信數據。又分為被動MITM和主動MITM，被動MITM只竊取通信數據而不修改，而主動MITM不但能竊取數據，還會篡改通信數據。最常見的中間人攻擊常常發生在公共wifi或者公共路由上。
成本考慮：
SSL證書需要購買申請，功能越強大的證書費用越高
SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電。
HTTPS連接緩存不如HTTP高效，流量成本高。
HTTPS連接服務器端資源占用高很多，支持訪客多的網站需要投入更大的成本。
HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是采用分而治之，類似12306網站的主頁使用HTTP協議，有關於用戶信息等方面使用HTTPS。
暫時不做更深理解。
參考：https://blog.csdn.net/leshami/article/details/49834777 https://github.com/LRH1993/android_interview/blob/master/computer-networks/http.md#2%E5%93%8D%E5%BA%94%E5%A4%B4%E9%83%A8
【http協議】淺談