Http協議

Http協議

大三學習了《計算機網絡》的課程，可是老師只把幾層協議簡單的介紹了一下，就沒有深刻的去學習。這麼多年，一直在使用Http，在去年的時候纔開始使用到Https，回過頭來發現關於Http的細節性的東西遺漏了不少。欠過帳的早晚要還的！在我對Servlet進行研究時，發現不少底層上的參數搞不清楚究竟是協議上的仍是Servlet上的。因此，仍是從Http的協議開始入手，從新學習和總結一下。

一、Http簡介

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。

HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

HTTP默認端口號爲80，Https的默認端口爲443。

特色

一、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

二、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

3.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

五、支持B/S及C/S模式。

TCP & HTTP & UDP:

TCP/IP是個協議組，可分爲四個層次：網絡接口層、網絡層、傳輸層和應用層。

網絡層	所包含協議
網絡層	IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議
傳輸層	TCP協議、UDP協議
應用層	有FTP、HTTP、TELNET、SMTP、DNS等協議

所以，HTTP自己就是一個協議，是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

socket

socket是爲了實現通訊過程而創建成來的通訊管道，其真實的表明是客戶端和服務器端的一個通訊進程，雙方進程經過socket進行通訊，而通訊的規則採用指定的協議。

socket只是一種鏈接模式，不是協議，tcp、udp，簡單的說（雖然不許確）是兩個最基本的協議,不少其它協議都是基於這兩個協議如，http就是基於tcp的，.用socket能夠建立tcp鏈接，也能夠建立udp鏈接，這意味着，用socket能夠建立任何協議的鏈接，由於其它協議都是基於此的。

2.Http消息

HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）來傳輸數據和創建鏈接。

URL和URI區別

URI	URL
URI，是uniform resource identifier，統一資源標識符，用來惟一的標識一個資源。	URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL能夠用來標識一個資源，並且還指明瞭如何locate這個資源，URL是Internet上用來描述信息資源的字符串，主要用在各類WWW客戶程序和服務器程序上，。
Web上可用的每種資源如HTML文檔、圖像、視頻片斷、程序等都是一個來URI來定位的	採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄等
URI通常由三部組成：一、訪問資源的命名機制。 二、存放資源的主機名。三、資源自身的名稱，由路徑表示，着重強調於資源。	URL通常由三部組成：一、協議(或稱爲服務方式)。二、存有該資源的主機IP地址(有時也包括端口號)。三、主機資源的具體地址。如目錄和文件名等

例如：在瀏覽器地址欄鍵入URL，按下回車以後會經歷如下流程：

一、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;

二、解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器創建TCP鏈接;

三、瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文做爲 TCP 三次握手的第三個報文的數據發送給服務器;

四、服務器對瀏覽器請求做出響應，並把對應的 html 文本發送給瀏覽器;

五、釋放 TCP鏈接;

六、瀏覽器將該 html 文本並顯示內容; 　　

客戶端請求消息

客戶端發送一個HTTP請求到服務器的請求消息包括如下格式：請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成，下圖給出了請求報文的通常格式。

Get請求

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8

第一部分：請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本.

GET說明請求類型爲GET,[/562f25980001b1b106000338.jpg]爲要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。

第二部分：請求頭部，緊接着請求行（即第一行）以後的部分，用來講明服務器要使用的附加信息

從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,而且在每一個請求中自動發送等等

第三部分：空行，請求頭部後面的空行是必須的

即便第四部分的請求數據爲空，也必須有空行。

第四部分：請求數據也叫主體，能夠添加任意的其餘數據。

這個例子的請求數據爲空。

post請求

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求數據，第八行。

響應消息Response

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

三、請求方法和狀態碼

請求方法

根據HTTP標準，HTTP請求可使用多種請求方法。
HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

序號	方法	描述
1	GET	請求指定的頁面信息，並返回實體主體。
2	HEAD 類	似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
3	POST 向	指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。
4	PUT 從客	戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的頁面。
6	CONNECT	HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。
7	OPTION	S 容許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求，主要用於測試或診斷。

狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文爲HTTP Status Code。

分類	分類描述
1**	信息，服務器收到請求，須要請求者繼續執行操做
2**	成功，操做被成功接收並處理
3**	重定向，須要進一步的操做以完成請求
4**	客戶端錯誤，請求包含語法錯誤或沒法完成請求
5**	服務器錯誤，服務器在處理請求的過程當中發生了錯誤

常見的狀態碼

200 OK                        //客戶端請求成功
400 Bad Request               //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized              //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 
403 Forbidden                 //服務器收到請求，可是拒絕提供服務
404 Not Found                 //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error     //服務器發生不可預期的錯誤
503 Server Unavailable        //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

HTTP content-type

Content-Type，內容類型，通常是指網頁中存在的Content-Type，用於定義網絡文件的類型和網頁的編碼，決定瀏覽器將以什麼形式、什麼編碼讀取這個文件，這就是常常看到一些Asp網頁點擊的結果倒是下載到的一個文件或一張圖片的緣由。

HTTP 響應頭信息

HTTP請求頭提供了關於請求，響應或者其餘的發送實體的信息。

應答頭	說明
Allow	服務器支持哪些請求方法（如GET、POST等）。
Content-Encoding	文檔的編碼（Encode）方法。只有在解碼以後才能夠獲得Content-Type頭指定的內容類型。利用gzip壓縮文檔可以顯著地減小HTML文檔的下載時間。Java的GZIPOutputStream能夠很方便地進行gzip壓縮，但只有Unix上的Netscape和Windows上的IE 四、IE 5才支持它。所以，Servlet應該經過查看Accept-Encoding頭（即request.getHeader("Accept-Encoding")）檢查瀏覽器是否支持gzip，爲支持gzip的瀏覽器返回經gzip壓縮的HTML頁面，爲其餘瀏覽器返回普通頁面。
Content-Length	表示內容長度。只有當瀏覽器使用持久HTTP鏈接時才須要這個數據。若是你想要利用持久鏈接的優點，能夠把輸出文檔寫入 ByteArrayOutputStream，完成後查看其大小，而後把該值放入Content-Length頭，最後經過byteArrayStream.writeTo(response.getOutputStream()發送內容。
Content-Type	表示後面的文檔屬於什麼MIME類型。Servlet默認爲text/plain，但一般須要顯式地指定爲text/html。因爲常常要設置Content-Type，所以HttpServletResponse提供了一個專用的方法setContentType。
Date	當前的GMT時間。你能夠用setDateHeader來設置這個頭以免轉換時間格式的麻煩。
Expires	應該在何時認爲文檔已通過期，從而再也不緩存它？
Last-Modified	文檔的最後改動時間。客戶能夠經過If-Modified-Since請求頭提供一個日期，該請求將被視爲一個條件GET，只有改動時間遲於指定時間的文檔纔會返回，不然返回一個304（Not Modified）狀態。Last-Modified也可用setDateHeader方法來設置。
Location	表示客戶應當到哪裏去提取文檔。Location一般不是直接設置的，而是經過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。
Refresh	表示瀏覽器應該在多少時間以後刷新文檔，以秒計。除了刷新當前文檔以外，你還能夠經過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。
Server	服務器名字。Servlet通常不設置這個值，而是由Web服務器本身設置。
Set-Cookie	設置和頁面關聯的Cookie。Servlet不該使用response.setHeader("Set-Cookie", ...)，而是應使用HttpServletResponse提供的專用方法addCookie。參見下文有關Cookie設置的討論。
WWW-Authenticate	客戶應該在Authorization頭中提供什麼類型的受權信息？在包含401（Unauthorized）狀態行的應答中這個頭是必需的。例如，response.setHeader("WWW-Authenticate", "BASIC realm=＼"executives＼"")。

四、補充

get和post區別

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。

• GET產生的URL地址能夠被Bookmark，而POST不能夠。

• GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。

• GET請求只能進行url編碼，而POST支持多種編碼方式。

• GET請求參數會被完整保留在瀏覽器歷史記錄裏，而POST中的參數不會被保留。

• GET請求在URL中傳送的參數是有長度限制的，而POST麼有。

• 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。

• GET比POST更不安全，由於參數直接暴露在URL上，因此不能用來傳遞敏感信息。

• GET參數經過URL傳遞，POST放在Request body中。

GET和POST還有一個重大區別：

GET產生一個TCP數據包；POST產生兩個TCP數據包。

對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。

由於POST須要兩步，時間上消耗的要多一點，看起來GET比POST更有效。所以Yahoo團隊有推薦用GET替換POST來優化網站性能。但這是一個坑！跳入需謹慎。爲何？

1. GET與POST都有本身的語義，不能隨便混用。

2. 據研究，在網絡環境好的狀況下，發一次包的時間和發兩次包的時間差異基本能夠無視。而在網絡環境差的狀況下，兩次包的TCP在驗證數據包完整性上，有很是大的優勢。

3. 並非全部瀏覽器都會在POST中發送兩次包，Firefox就只發送一次。

Https

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容請看SSL。

不使用SSL/TLS的HTTP通訊，就是不加密的通訊。全部信息明文傳播，帶來了三大風險。

（1） 竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。
（2） 篡改風險（tampering）：第三方能夠修改通訊內容。
（3） 冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

SSL/TLS協議是爲了解決這三大風險而設計的，但願達到：

（1） 全部信息都是加密傳播，第三方沒法竊聽。
（2） 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。
（3） 配備身份證書，防止身份被冒充。

參考文章
一、HTTP 協議入門
二、HTTP 教程
三、看完還不懂HTTPS我直播吃翔