http學習筆記——章節02_初步瞭解http

知識點:

  • http通信初識
  • 無狀態和資源定位
  • http相關方法
  • 持久連接和管線化
  • 使用cookie進行狀態管理

1. http通信初識

兩臺計算機使用http進行通信時吧,在一條通信路上必定有一端爲客戶端,另一端爲服務器端

通信方式爲:客戶端發出請求信息,服務器接收請求並返回響應信息
在這裏插入圖片描述

1.1 先來看請求信息

GET /index.htm HTTP/1.1 Host: hackr.jp

  • 起始行開頭的GET表示請求訪問服務器的類 型,稱爲方法 method)。
  • 隨後的字符串 /index.htm 指明瞭請求訪問的資源對象,也叫做請求 URI( request-URI)。
  • 最後的 HTTP/1.1,即HTTP的版本號,用來提示客戶端使用的HTTP協議功能

綜上: 請求報文是由請求方法、 請求 URI、協議版本、可選的請求首部字段和內容實體構成的
在這裏插入圖片描述

1.2 再來看響應信息

HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
<html>
......
  • 開頭的HTTP/1.1 表示服務器端對應的HTTP版本。 200 OK 表示請求的處理結果的狀態碼( status code)和原因短語( reason-phrase)
  • 第二行顯示了創建響應的日期時間,它是首部字段中的一個屬性
  • 下面倆個同爲首部字段的屬性,它反映了主體的信息
  • 最後的html片段則就是資源主體的實體

綜上:響應報文基本上由協議版本、 狀態碼(表示請求成功或失敗的數字代碼)、用以解釋狀態碼的原因短語、 可選的響應首部字段以及實體主體構成
在這裏插入圖片描述

2. 無狀態和資源定位

2.1 無狀態

http是一個不保存狀態的協議,即它不會對請求和響應之間的通信狀態進行保存。也就是說都是轉眼不認人的那種。

爲什麼這麼設計?

要保存相應的狀態信息,就肯定需要cpu和內存空間。爲了使它能夠更快速的處理大量事務,確保協議的可伸縮性。特意把它設計成這麼簡單的。

2.2 請求 URI 定位資源

http使用URI進行資源的定位,使得客戶端可以通過它獲取或訪問資源

客戶端因請求訪問資源而發送請求信息時,要將URI放到請求報文中。來看幾種指定請求URI的方式

  • URI爲完整的請求URIGET http://hackr.jp/index.htm HTTP/1.1
  • 在首部字段Host中寫明網絡域名或IP地址 GET /index.htm HTTP/1.1 Host: hackr.jp

如果不是對某個特定的資源進行請求或訪問,而是本事就是想對這個服務器本身發起請求,可以使用*來替代請求URI
栗子:
OPTIONS * HTTP/1.1

3. http相關方法

3.1 get

GET 方法用來請求訪問資源,指定的資源經過服務器端解析之後返回響應內容。即如果是文本就原樣返回;如果是程序,則返回執行結果

3.2 post

POST用來傳輸實體的主體,雖然GET也能傳輸實體(如地址欄傳參)但是一般實體的傳輸都是用POST,GET的主要目的是獲取資源POST則不然

3.3 put

PUT方法用來傳輸文件,如同FTP協議的文件上傳。要求在請求報文的主體中包含文件內容信息,然後根據URI保存到它其指定的位置上
但是HTTP/1.1 的 PUT 方法自身不帶驗證機制,即任何人都可以向該服務端上傳文件存在安全問題,故一般的web網站不會使用這個方法。若是配合web應用程序的驗證機制,或者架構設計採用REST標準的同類web網站,就可能會開發put方法

3.4 HEAD

與get方法一樣,只不過它所返回的響應報文不包含主體部分。只是爲了確認URI的有效性及資源更新的日期

3.5 DELETE

DELETE用來刪除上傳的文件與PUT正好相反

3.6 OPTIONS

這個方法用來查詢要請求URI資源所支持的方法,比如對方資源可能只支持get、post等

3.7 TRACE

路徑追蹤,這個辦法是讓web服務器端將之前的請求通信環回返給客戶端

如:在客戶端發送一個請求時,會在請求報文首部字段一個叫Max-Forwards的屬性中填入一個數值,這個請求每經過一箇中轉服務器Max-Forwards裏面的值便會減一,當它數值減到0時便會停止繼續傳輸此時便正好到達了URI所定位的資源服務器端

這個方法容易引起XST(跨站追蹤攻擊)一般不會使用

3.8 CONNECT

這個方法要求在與代理服務器通信時建立隧道,實現用隧道協議進行TCP通信。主要使用SSL和TLS協議把通信內容加密之後經過網絡隧道傳輸

4. 持久連接和管線化

4.1 持久連接

爲什麼會用持久連接?
在http的初始版本中每進行一次HTTP通信便要斷開一次TCP連接,這種設計可能適合當時的web環境。可是到如今一個好點頁面幾十張上百張大圖片小圖片。還有各種靜態資源,如果還是每通信一次斷開一次連接那不說cpu和內存的消耗。但用戶體驗便差到極點了吧(每次重複上百次三次握手四次揮手瘋了)
爲了解除這個問題,便出現了持久連接。持久連接的特點是隻要任意一端沒有明確提出斷開連接,則保持TCP連接的狀態

4.2 管線化

管線化是繼持久連接的進一步優化,持久連接的實現使多數請求以管線化方式發送成爲可能。
以前客戶端發送了一個請求,只有收到了服務器端給額響應才能進行發送下一個請求,管線化的出現打破了這一規律。使得客戶端不用等到響應信息直接可發送下一個請求

5. 使用cookie進行狀態管理

我們已經知道爲了儘可能的減少cpu和內存的消耗,http是無狀態的。但是現實應用中我們又需要它保存狀態。於是引進了cookie技術
cookie是通過在請求和響應報文中寫入cookie信息的方式來控制它們狀態的
流程

  1. 首先客戶端向服務器端發送請求,服務器端在會響應報文中加一個Set-Cookie的首部字段信息來通知客戶端保存cookie。並做下記錄
  2. 當下次客戶端再向該服務器發送請求時會自動給自己的請求報文加入保存的cookie
  3. 服務器端收到此cookie時會對比服務器端的記錄檢查它是哪個客戶端(畢竟服務器端授予cookie的客戶端不止),從而得到之前的狀態信息
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章