原文作者：Tison
原文鏈接：https://tisonkong.github.io/github.io/2018/10/12/java web基礎篇——Http協(xié)議/
版權聲明：?如有侵權，請聯(lián)系刪除！
一、Http協(xié)議
HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是用于從3W服務器傳輸超文本到本地瀏覽器的傳送協(xié)議。它可以使瀏覽器更加高效，使網(wǎng)絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示(如文本先于圖形)等。
HTTP是一個應用層協(xié)議，基于請求與響應模式的、無狀態(tài)的、應用層的協(xié)議，常基于TCP的連接方式。HTTP使用統(tǒng)一資源標識符（Uniform Resource Identifiers, URI）來傳輸數(shù)據(jù)和建立連接。URL是一種特殊類型的URI，包含了用于查找某個資源的足夠的信息URL，全稱是UniformResourceLocator, 中文叫統(tǒng)一資源定位符,是互聯(lián)網(wǎng)上用來標識某一處資源的地址。
HTTP協(xié)議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請求/響應模型。客戶端向服務器發(fā)送一個請求報文，請求報文包含請求的方法、URL、協(xié)議版本、請求頭部和請求數(shù)據(jù)。服務器以一個狀態(tài)行作為響應，響應的內(nèi)容包括協(xié)議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數(shù)據(jù)。以下是 HTTP 請求/響應的步驟：
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.lxweimin.com/yitaicloud。
通過TCP套接字，客戶端向Web服務器發(fā)送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數(shù)據(jù)4部分組成。
Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態(tài)行、響應頭部、空行和響應數(shù)據(jù)4部分組成。
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內(nèi)可以繼續(xù)接收請求;
客戶端瀏覽器首先解析狀態(tài)行，查看表明請求是否成功的狀態(tài)代碼。然后解析每一個響應頭，響應頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數(shù)據(jù)HTML，根據(jù)HTML的語法對其進行格式化，并在瀏覽器窗口中顯示。
例如：在瀏覽器地址欄鍵入URL，按下回車之后會經(jīng)歷以下流程：
1、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
2、解析出 IP 地址后，根據(jù)該 IP 地址和默認端口 80，和服務器建立TCP連接;
3、瀏覽器發(fā)出讀取文件(URL 中域名后面部分對應的文件)的HTTP 請求，該請求報文作為?TCP 三次握手的第三個報文的數(shù)據(jù)發(fā)送給服務器;
4、服務器對瀏覽器請求作出響應，并把對應的 html 文本發(fā)送給瀏覽器;
5、釋放?TCP連接;
6、瀏覽器將該 html 文本并顯示內(nèi)容;
GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標識符）識別的資源，可以通過URL傳參給服務器。
POST：用于傳輸信息給服務器，主要功能與GET方法類似，但一般推薦使用POST方式。
PUT： 傳輸文件，報文主體中包含文件內(nèi)容，保存到對應URI位置。
DELETE：刪除文件，與PUT方法相反，刪除對應URI位置的文件。
HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用于驗證URI是否有效。
OPTIONS：查詢相應URI支持的HTTP方法。
區(qū)別一：
get重點在從服務器上獲取資源，post重點在向服務器發(fā)送數(shù)據(jù)；
區(qū)別二：
get傳輸數(shù)據(jù)是通過URL請求，以field（字段）= value的形式，置于URL后，并用”?”連接，多個請求數(shù)據(jù)間用”&”連接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的；
post傳輸數(shù)據(jù)通過Http的post機制，將字段與對應值封存在請求實體中發(fā)送給服務器，這個過程對用戶是不可見的；
區(qū)別三：
Get傳輸?shù)臄?shù)據(jù)量小，因為受URL長度限制，但效率較高；
Post可以傳輸大量數(shù)據(jù)，所以上傳文件時只能用Post方式；
區(qū)別四：
get是不安全的，因為URL是可見的，可能會泄露私密信息，如密碼等(頁面可以被緩存，或者獲得歷史訪問記錄)；
post較get安全性較高；
區(qū)別五：
get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。
post支持標準字符集，可以正確傳遞中文字符。
請求報文包含三部分：
a、請求行：包含請求方法、URI、HTTP版本信息
b、請求首部字段
c、請求內(nèi)容實體
響應報文包含三部分：
a、狀態(tài)行：包含HTTP版本、狀態(tài)碼、狀態(tài)碼的原因短語
b、響應首部字段
c、響應內(nèi)容實體
返回的狀態(tài)
1xx：指示信息–表示請求已接收，繼續(xù)處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操作
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現(xiàn)
5xx：服務器端錯誤–服務器未能實現(xiàn)合法的請求
200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執(zhí)行GET方法，相應報文中通過Content-Range指定范圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器無法識別
401：請求需要認證
403：請求的對應資源禁止被訪問
404：服務器無法找到對應資源
500：服務器內(nèi)部錯誤
503：服務器正忙
a、通用首部字段（請求報文與響應報文都會使用的首部字段）
Date：創(chuàng)建報文時間
Connection：連接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式
b、請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內(nèi)容編碼
Accept-Language：可接受的自然語言
c、響應首部字段（響應報文會使用的首部字段）
Accept-Ranges：可接受的字節(jié)范圍
Location：令客戶端重新定向到的URI
Server：HTTP服務器的安裝信息
d、實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
Allow：資源可支持的HTTP方法
Content-Type：實體主類的類型
Content-Encoding：實體主體適用的編碼方式
Content-Language：實體主體的自然語言
Content-Length：實體主體的的字節(jié)數(shù)
Content-Range：實體主體的位置范圍，一般用于發(fā)出部分請求時使用
先上答案，然后再后面詳細解釋：
a、默認持久連接，節(jié)省通信量，只要客戶端服務端任意一端沒有明確提出斷開TCP連接，就一直保持連接，可以發(fā)送多次HTTP請求
b、管線化，客戶端可以同時發(fā)出多個HTTP請求，而不用一個個等待響應
c、斷點續(xù)傳原理
HTTP 1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲。一個包含有許多圖像的網(wǎng)頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網(wǎng)頁文件的請求和應答仍然需要使用各自的連接。HTTP 1.1還允許客戶端不用等待上一次請求結果返回，就可以發(fā)出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果，以保證客戶端能夠區(qū)分出每次請求的響應內(nèi)容，這樣也顯著地減少了整個下載過程所需要的時間。基于HTTP 1.1協(xié)議的客戶機與服務器的信息交換過程。
【HTTP 1.1與HTTP 1.0的比較HTTP 1.1與HTTP 1.0的比較】
a、通信使用明文不加密，內(nèi)容可能被竊聽
b、不驗證通信方身份，可能遭到偽裝
c、無法驗證報文完整性，可能被篡改
HTTPS就是HTTP加上加密處理（一般是SSL安全通信線路）+認證+完整性保護
利用負載均衡優(yōu)化和加速HTTP應用
利用HTTP Cache來優(yōu)化網(wǎng)站
補充一點Cache的細節(jié)：
緩存是一個到處都存在的用空間換時間的例子。通過使用多余的空間，我們能夠獲取更快的速度。用戶在瀏覽網(wǎng)站的時候，瀏覽器能夠在本地保存網(wǎng)站中的圖片或者其他文件的副本，這樣用戶再次訪問該網(wǎng)站的時候，瀏覽器就不用再下載全部的文件，減少了下載量意味著提高了頁面加載的速度。
緩存非常有用，但是也帶來了一定的缺陷。當我們的網(wǎng)站發(fā)生了更新的時候，比如說Logo換了，瀏覽器本地仍保存著舊版本的Logo，那么瀏覽器如何來確定使用本地文件還是使用服務器上的新文件？下面來介紹幾種判斷的方法。
Caching Method 1：Last-Modified
服務器為了通知瀏覽器當前文件的版本，會發(fā)送一個上次修改時間的標簽，例如：
Last-modified: Fri, 16 Mar 2007 04:00:25 GMT
Caching Method 2: ETag
通常情況下，通過修改時間來比較文件是可行的。但是在一些特殊情況，例如服務器的時鐘發(fā)生了錯誤，服務器時鐘進行修改，夏時制DST到來后服務器時間沒有及時更新，這些都會引起通過修改時間比較文件版本的問題。
ETag可以用來解決這種問題。ETag是一個文件的唯一標志符。就像一個哈希或者指紋，每個文件都有一個單獨的標志，只要這個文件發(fā)生了改變，這個標志就會發(fā)生變化。如同 Last-modified 一樣，ETag 解決了文件版本比較的問題。只不過 ETag 的級別比 Last-Modified 高一些。
Caching Method 3：Expires
緩存一個文件，并且與服務器確認版本的方式非常好，但是仍有一個缺點，我們必須連接服務器。每次使用前都進行一次比較，這種方法很安全，但還不是最好的。我們可以使用 Expiration Date 來減少這種請求。
Caching Method 4：Max-age
Expires的方法很好，但是我們每次都得算一個精確的時間。max-age 標簽可以讓我們更加容易的處理過期時間。我們只需要說，這份資料你只能用一個星期就可以了。
【利用HTTP Cache來優(yōu)化網(wǎng)站】
瀏覽器的同源策略會導致跨域，這里同源策略又分為以下兩種
DOM同源策略：禁止對不同源頁面DOM進行操作。這里主要場景是iframe跨域的情況，不同域名的iframe是限制互相訪問的。
XmlHttpRequest同源策略：禁止使用XHR對象向不同源的服務器地址發(fā)起HTTP請求。
只要協(xié)議、域名、端口有任何一個不同，都被當作是不同的域，之間的請求就是跨域操作。
要解決跨域問題可以參考以下文章：
《跨域資源共享 CORS 詳解》?阮一峰大神的精品
另外玉剛寫了一篇不錯的，角度是站在前端來看的
