原文作者：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)絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔销斟，還確定傳輸文檔中的哪一部分庐椒，以及哪部分內容首先顯示(如文本先于圖形)等。
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)行作為響應笨腥，響應的內容包括協(xié)議的版本拓哺、成功或者錯誤代碼、服務器信息脖母、響應頭部和響應數(shù)據(jù)士鸥。以下是 HTTP 請求/響應的步驟：
一個HTTP客戶端谆级，通常是瀏覽器烤礁，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如肥照，http://www.reibang.com/yitaicloud脚仔。
通過TCP套接字舆绎，客戶端向Web服務器發(fā)送一個文本的請求報文鲤脏，一個請求報文由請求行、請求頭部吕朵、空行和請求數(shù)據(jù)4部分組成猎醇。
Web服務器解析請求边锁，定位請求資源姑食。服務器將資源復本寫到TCP套接字，由客戶端讀取茅坛。一個響應由狀態(tài)行音半、響應頭部则拷、空行和響應數(shù)據(jù)4部分組成。
若connection 模式為close煌茬，則服務器主動關閉TCP連接，客戶端被動關閉連接彻桃，釋放TCP連接;若connection 模式為keepalive坛善，則該連接會保持一段時間，在該時間內可以繼續(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 文本并顯示內容;
GET： 用于請求訪問已經(jīng)被URI（統(tǒng)一資源標識符）識別的資源舔亭，可以通過URL傳參給服務器些膨。
POST：用于傳輸信息給服務器，主要功能與GET方法類似钦铺，但一般推薦使用POST方式订雾。
PUT： 傳輸文件，報文主體中包含文件內容矛洞，保存到對應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劫笙、請求內容實體
響應報文包含三部分：
a芙扎、狀態(tài)行：包含HTTP版本、狀態(tài)碼邀摆、狀態(tài)碼的原因短語
b纵顾、響應首部字段
c、響應內容實體
返回的狀態(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：服務器內部錯誤
503：服務器正忙
a虫埂、通用首部字段（請求報文與響應報文都會使用的首部字段）
Date：創(chuàng)建報文時間
Connection：連接的管理
Cache-Control：緩存的控制
Transfer-Encoding：報文主體的傳輸編碼方式
b、請求首部字段（請求報文會使用的首部字段）
Host：請求資源所在服務器
Accept：可處理的媒體類型
Accept-Charset：可接收的字符集
Accept-Encoding：可接受的內容編碼
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ū)分出每次請求的響應內容姑隅，這樣也顯著地減少了整個下載過程所需要的時間写隶。基于HTTP 1.1協(xié)議的客戶機與服務器的信息交換過程讲仰。
【HTTP 1.1與HTTP 1.0的比較HTTP 1.1與HTTP 1.0的比較】
a慕趴、通信使用明文不加密，內容可能被竊聽
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 詳解》?阮一峰大神的精品
另外玉剛寫了一篇不錯的匣缘，角度是站在前端來看的
