图解HTTP-HTTP
文章目錄
- HTTP
- HTTP是不保存狀態的協議(對請求和響應不做持久化處理)
- 請求URI定位資源
- HTTP中的方法
- 1、GET(獲取資源)
- 2、POST( 傳輸實體主體)
- 3、PUT(傳輸文件)
- 4、HEAD(獲取報文首部)
- 5、DELETE：刪除文件
- 6、OPTIONS
- 7、TRACE(追蹤路徑)
- 例子
- 8、CONNECT(要求用隧道協議連接代理，使用SSL或者TLS協議將通信內容加密后經網絡隧道傳輸)
- 例子
- 總結
- 持久連接節省通信量
- 建立連接
- 斷開TCP連接
- 持久連接(HTTP1.1所有的連接都是持久連接)
- 管線化(不需要等待響應即可直接發送下一個請求)
- 使用Cookie管理狀態
- 例子
- HTTP報文內的HTTP信息
- 1、請求報文結構
- 首部字段分類
- 提升傳輸速率
- 編碼提升傳輸速率（客戶端收到后需要解碼）
- 分割發送的分塊傳輸編碼
- 發送多種數據的多部分對象集合
- MIME類型
- multipart/form-data
- multipart/byteranges
- multipart/byteranges
- 獲取部分內容的范圍請求(Range首部來指定資源的byte范圍)
- 內容協商返回合適內容
- 內容協商分類
- 返回結果的HTTP狀態碼
- 狀態碼告知從服務端返回的請求結果
- 2XX成功
- 200(表示請求被正常處理)
- 204(No Content)
- 206(Partial Content)
- 3XX重定向
- 1、301Moved Permanently(永久性重定向)
- 2、302 Found
- 303(略)
- 304(略)
- 307(略)
- 4XX客戶端錯誤
- 400 Bad Request(請求報文存在語法錯誤)
- 401 Unauthorized
- 403Forbidden
- 404 Not Found
- 5XX服務器錯誤
- 500 Internal Server Error(執行請求時發生錯誤)
- 503 Service Unavailable(服務器處于超負載或正在進行停機維護)
- 與HTTP協作的Web服務器
- 1、用單個虛擬主機實現多域名(借助Host首部實現)
- 2、通信數據轉發程序：代理、網關、隧道
- 代理(不會改變請求URI)
- 緩存代理
- 透明代理
- 網關
- 隧道(保證服務端和客戶端可以安全通信)
- 保存資源的緩存
- HTTP首部(請求頭、響應頭部分)
- 首部傳遞重要信息
- 首部結構
- 4種首部字段類型
- 通用首部字段
- 請求首部字段
- 響應首部字段
- 實體首部字段
- 首部具體信息(略)
HTTP
在兩臺計算機之間使用HTTP協議進行通信的時候，在一條鏈路上必定有一端是客戶端，另外一端則是服務端(但是角色可能會互換)。
就僅一條通信鏈路而言，服務端和客戶端的角色是固定的，而用HTTP協議能夠區分哪個是客戶端，哪個是服務端。
HTTP協議規定，請求從客戶端發出，最后服務器端響應請求并返回。也就是說服務端在沒有接收到請求之前不會發送響應。
HTTP是不保存狀態的協議(對請求和響應不做持久化處理)
HTTP協議是無狀態的協議，HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在HTTP這個級別，協議對于發送過的請求或者響應都不做持久化處理。
但是無狀態可能會導致業務處理變得棘手的情況增多，比如登陸到一家購物網站，即使跳轉到該網站的其他頁面，也需要能繼續保持登陸狀態。為了實現這個功能，于是引入了Cookie技術
請求URI定位資源
-
1、URI為完整的請求URI
GET http://hackr.jp/index.htm HTTP/1.1
URI在請求頭中 -
2、在首部字段HOST中寫明網絡域名或IP地址
GET /index.htm HTTP/1.1
Host:hackr.jp
在Host中寫明域名或者IP
HTTP中的方法
1、GET(獲取資源)
GET方法用來請求訪問已被URI識別的資源。指定的資源經服務端解析后返回內容。
也就是說，如果是文本，那么就直接原樣返回，如果是像CGI那樣的程序，那么返回經過執行后的輸出結果
2、POST( 傳輸實體主體)
實體主體可以理解成請求體
雖然用GET也可以傳輸實體的主體，但是一般不用get，雖然POST和GET相似，但是POST的主要目的不是獲取響應的主體內容。
3、PUT(傳輸文件)
要求在請求報文的主體中包含文件內容。然后保存到請求URI的指定的位置。
4、HEAD(獲取報文首部)
HEAD和GET方法一樣，只是不返回報文主體部分，用于確認URI的有效性即資源更新日期時間等。
5、DELETE：刪除文件
DELETE方法用來刪除文件，是與PUT相反的方法，用于按請求URI刪除指定的資源。
6、OPTIONS
OPTIONS方法用來查詢針對請求URI指定的資源支持的方法。
7、TRACE(追蹤路徑)
TRACE方法是讓WEB服務器端將之前的請求通信返回給客戶端。
發送請求的時候，在Max-Forwards首部字段中填入數值，每經過一個服務器端就將數字減去1，當數值剛好減到0的時候，就停止傳輸，最后接收到請求的服務器端返回狀態碼200 OK的響應。
客戶端可以通過TRACE方法查詢發送出去的請求是怎么樣被加工修改的。這是因為連接到目標服務器可能會通過代理中轉。
中間可能會經過多個代理服務器，返回當Max-Forwards為0的時候，此時那個服務器或者代理服務器收到的請求。
例子
請求：
TRACE /HTTP/1.1 Host:hackr.jp Max-Forwards:2響應：
HTTP/1.1 200 OK Content-Type:message/http Content-Length:1024TRACE /HTTP/1.1 Host:hackr.jp Max-Forwards:2在上面的響應體中，返回響應包含的請求內容
8、CONNECT(要求用隧道協議連接代理，使用SSL或者TLS協議將通信內容加密后經網絡隧道傳輸)
CONNECT方法要求在代理服務器通信時候建立隧道，實現用隧道協議進行TCP通信。主要使用SSL(Secure Sockets Layer，安全套接字)和TLS(Transport Layer Security，傳輸層安全)協議把內容加密后經網絡隧道傳輸。
CONNECT方法的格式如下所示：
- CONNECT 代理服務器名：端口號 HTTP版本
例子
使用CONNECT方法的請求-響應的例子：
-
請求
CONNECT proxy.hackr.jp:8080 HTTP/1.1
HOST:proxy.hackr.jp -
響應
HTTP/1.1 200 OK（之后進入網絡隧道）
總結
| GET | 獲取資源 | 1.0、1.1 |
| POST | 傳輸實體實體 | 1.0、1.1 |
| PUT | 傳輸文件 | 1.0、1.1 |
| HEAD | 獲取報文首部 | 1.0、1.1 |
| DELETE | 刪除文件 | 1.0、1.1 |
| OPTIONS | 詢問支持的方法 | 1.1 |
| TRACE | 追蹤路徑 | 1.1 |
| CONNECT | 要求用隧道協議連接代理 | 1.1 |
| LINK | 建立和資源之間的聯系 | 1.0 |
| UNLINK | 斷開連接關系 | 1.0 |
在這里列舉了中多方法，LINK和UNLINK已經被HTTP/1.1廢棄，不再支持。
持久連接節省通信量
HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接。
下面的建立連接和斷開連接可以以左邊為客戶端右邊為服務端為例子看
建立連接
- -----SYN—》
- 《----SYN/ACK-----
- -----ACK----》
斷開TCP連接
- 《----FIN----
- ------ACK—》
- -----FIN—》
- 《-----ACK-----
如果不支持持久連接，在很多HTML頁面中，可能要加載或者很多圖片等，那么就需要多次TCP的連接和斷開。
持久連接(HTTP1.1所有的連接都是持久連接)
為了解決TCP連接的問題，HTTP/1.1和一部分HTTP/1.0想出了持久連接的方法，持久連接的特點是，只要任意一端沒有明確斷開連接，則保持TCP連接狀態。
在HTTP/1.1中，所有的連接默認都是持久連接，但是在1.0的時候還沒有標準化。
管線化(不需要等待響應即可直接發送下一個請求)
持久連接使得多數請求以管線化(Pipeling)方式發送成為可能。從前發送請求需要等待并收到響應，才能發送下一個請求，管線化技術出現后，不用等待響應即可直接發送下一個請求。
使用Cookie管理狀態
因為HTTP是無狀態的，不對之前的請求和響應的狀態進行管理。也就是說，無法根據之前的狀態進行本次的請求處理。
無狀態好處：
- 不必保存狀態，自然可減少服務器的CPU以及內存的消耗。
Cookie技術通過在請求和響應的報文中寫入Cookie信息來控制客戶端的狀態。
- 1、Cookie會根據從服務器發送的響應報文內的一個叫做Set-Cookie的首部字段信息，通知客戶端保存Cookie。當下次客戶端再往服務器發送請求的時候，客戶端會自動在請求報文中加入Cookie值后發送出去。
- 2、服務器端發現客戶端發送來的Cookie之后，會去檢查究竟是從哪一個客戶端發來的連接請求，然后對比服務器上的記錄，得到之前的狀態信息。
例子
- 1、請求報文(沒有Cookie信息的狀態)
- 2、響應報文(服務器端生成Cookie信息)
- 3、請求報文(自動發送保存著的Cookie信息)
HTTP報文內的HTTP信息
1、請求報文結構
請求報文結構
- 請求行
- 請求頭(報文首部)
- 請求空行
- 請求體(報文主體)
響應報文結構：
- 響應行(狀態行)
- 響應頭
- 響應空行
- 響應體
首部字段分類
- 通用首部
- 請求首部
- 響應首部
- 實體首部
提升傳輸速率
編碼提升傳輸速率（客戶端收到后需要解碼）
編碼的操作需要計算機完成，因此會消耗更多的CPU資源。
常見的壓縮編碼有下面幾種：
- gzip(GNU zip)
- compress(UNIX 系統的標準壓縮)
- deflate(zlib)
- identity(不進行編碼)
分割發送的分塊傳輸編碼
在HTTP通信過程中，請求的編碼實體資源尚未傳輸完成之前是無法顯示請求頁面的，在傳輸大容量時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。
這種把實體主體分塊的功能稱為分塊傳輸編碼。
發送多種數據的多部分對象集合
MIME類型
MIME(Multipurpose Internet Mail Extensions)：多用途因特網郵件擴展
在把輸出結果傳送到瀏覽器上的時候，瀏覽器必須啟動適當的應用程序來處理這個傳輸文檔，這就可以通過MIME來完成。在HTTP中，MIME類型被定義在Content-Type Head中。
multipart/form-data
在web表單文件上傳時使用
multipart/byteranges
狀態碼206響應報文包含了多個范圍的內容時使用
multipart/byteranges
在HTTP報文中使用多部分對象集合時，需要在首部里加上Content-type。
獲取部分內容的范圍請求(Range首部來指定資源的byte范圍)
要實現該功能需要指定下載的實體范圍，像這樣，指定范圍發送的請求叫做范圍請求。
5001-10000字節：
- Range:bytes=5001-10000
從5001字節之后全部：
- Range:bytes=5001-
從一開始到3000字節和5000-7000字節的多重范圍：
- Range:bytes=0-3000,5000-7000
內容協商返回合適內容
在一個Web網站可能存在多份相同內容的頁面，比如英語版本、中文版本的web頁面，雖然內容上相同，但是使用的語言不同。
當瀏覽器的默認語言為英語或者中文，訪問相同的URI的WEB頁面的時候，則會顯示對應的英語版或者中文版本的頁面。這樣的機制稱為內容協商。
內容協商會以語言、字符集、編碼方式等為基準判斷響應的資源：
- ACCEPT
- ACCEPT-Charset
- Accept-Encoding
- Accept-Language
- Content-Language
內容協商分類
- 服務器驅動協商
以請求的首部為參考，在服務端自動處理。 - 客戶端驅動協商
用戶從瀏覽器顯示的可選選項中進行手動選擇 - 透明協商
這是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。
返回結果的HTTP狀態碼
狀態碼告知從服務端返回的請求結果
| 1XX | 信息性狀態碼 | 接收的請求正在處理 |
| 2XX | 成功狀態碼 | 請求正常處理完畢 |
| 3XX | 重定向狀態碼 | 需要進行附加操作以完成請求 |
| 4XX | 客戶端錯誤狀態碼 | 服務器無法處理請求 |
| 5XX | 服務器錯誤狀態碼 | 服務器處理請求錯誤 |
只要遵守狀態碼類別的定義，即使改變RFC2616中定義的狀態碼或服務器端自行創建狀態碼都沒問題。
2XX成功
200(表示請求被正常處理)
表示從客戶端發來的請求在服務器端被正常處理了。
204(No Content)
表示服務器接收的請求已成功處理，但是在返回的響應報文中不含實體的主體部分，也不允許返回任何實體的主體。
當瀏覽器發出請求處理之后，返回204響應，那么瀏覽器顯示的頁面不發生更新。
206(Partial Content)
該狀態碼表示客戶端進行了范圍請求，而服務器成功執行了這部分的get請求。
響應報文中包含有Content-Range指定范圍的實體內容。
3XX重定向
1、301Moved Permanently(永久性重定向)
永久性重定向.
這個狀態碼表示請求的資源已經被分配了新的URI。以后應該使用資源現在所指的URI。
2、302 Found
臨時性重定向
該狀態碼表示請求的資源被分配了新的URI。希望用戶(本次)能使用新的URI訪問。
和301不同的是，302資源不是被永久移動。
303(略)
304(略)
307(略)
4XX客戶端錯誤
400 Bad Request(請求報文存在語法錯誤)
該狀態碼表示請求報文中存在語法錯誤。
401 Unauthorized
表示發送的請求需要有HTTP認證(BASIC、DIGEST認證)的認證信息。如果之前以及進行過一次請求，那么表示用戶認證失敗。
403Forbidden
表示對請求資源的訪問被服務器拒絕了。
服務器沒有必要給出拒絕的理由，但是如果要給出拒絕理由的話，可以在實體的主體部分對原因進行描述。這樣用戶就能看到。
404 Not Found
表示服務器上無法找到請求的資源
5XX服務器錯誤
500 Internal Server Error(執行請求時發生錯誤)
表示服務器端在執行請求時發生錯誤
503 Service Unavailable(服務器處于超負載或正在進行停機維護)
表示服務器暫時處于超負載或者正在進行停機維護。
與HTTP協作的Web服務器
1、用單個虛擬主機實現多域名(借助Host首部實現)
在互聯網上，域名通過DNS解析映射到IP地址，可見，當請求發送到服務器的時候，已經上以IP地址形式訪問了。
所以如果多域名的話，當接收到請求的時候就要弄清楚究竟要訪問哪個域名。
在相同的IP地址下，虛擬主機可以寄存多個不同主機名和域名的web網站，因此在發送HTTP請求的時候，必須在Host首部內完整指定主機名或域名的URI
2、通信數據轉發程序：代理、網關、隧道
在HTTP通信的時候，還有一些用于轉發通信數據的應用程序，如：代理、網關和隧道。
這些應用程序和服務器可以將請求轉發給通信線路上的下一站服務器，并且能接收從那臺服務器發送的響應再轉發給客戶端。
代理(不會改變請求URI)
代理是一種有轉發功能的應用程序，位于服務器和客戶端之間，接收由客戶端發送來的請求再轉發給服務器，同時也接收服務器返回的響應并轉發給客戶端。
代理的好處：利用緩存減少網絡帶寬的流量。
緩存代理
預先將資源的副本保存在代理服務器
當對相同資源請求的時候，可以不從原服務器取數據，而是將之前緩存的資源作為響應返回。
透明代理
不對報文做任何加工的代理。
網關
網關是其他服務器通信數據的服務器，接收從客戶端發來的請求，它就像自己擁有資源的服務器一樣對請求進行處理，有時客戶都不會察覺自己的通信目標是一個網關。
網關和代理類似，但是網關能使通信線路上的服務器提供非HTTP協議服務。
隧道(保證服務端和客戶端可以安全通信)
隧道可以按照要求建立起一條與其他服務器的通信線路，屆時可以使用SSL等加密方式進行通信。隧道目的是為了保證服務端和客戶端之間可以安全通信。
保存資源的緩存
緩存服務器好處在于利用緩存可以避免多次從原服務器轉發資源，因此客戶端就近從服務器上獲取資源，而原服務器也不必多次處理相同請求。
HTTP首部(請求頭、響應頭部分)
首部傳遞重要信息
HTTP首部是構成HTTP報文的重要要素之一。無論是請求和響應都會使用首部字段，它能起到傳遞額外重要信息的作用。
首部是為了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證等內容
首部結構
首部字段名：字段值
例如：
- Content-Type來表示報文主體的對象類型
Content-Type：text/html
4種首部字段類型
通用首部字段
在請求和響應兩方都有的首部。
請求首部字段
從客戶端向服務端發送請求報文時使用的首部，補充了請求的附加內容、客戶端信息、響應內容相關內容優先級等信息
響應首部字段
從服務器端向客戶端返回響應報文時使用的首部，補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段
補充了資源內容更新時間等與實體有關的信息。
首部具體信息(略)
總結
以上是生活随笔為你收集整理的图解HTTP-HTTP的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 文昌京东配送小哥的那些骄傲事
- 下一篇： IT视频课程集(包含各类Oracle、D