HTTP總有你感興趣的

柴碼發表於2018-01-07

HTTP總有你感興趣的

前言

一週或兩週一更美好的計劃是用來打破的,由於前段眼疾的情況已經有三週沒跟大家分享些乾貨。身體是革命的本錢,還望老碼猿們在加班的時候也要注意身體健康。

作為一位稱職的碼農,在這三週養眼的時間裡也不忘學習,系統的去了解了下我們大家都熟悉而有陌生的HTTP協議

我相信在我們碼農當中還有很大一部分Web應用程式開發者並不瞭解支撐Web基礎的HTTP協議。接下來我們從以下幾點去熟悉瞭解HTTP協議

  • HTTP的誕生
  • HTTP如何作用於客戶端與伺服器端的通訊
  • HTTP請求結果狀態碼
  • 安全的HTTPS

HTTP的誕生

HTTP全稱為HyperText Transfer Protocol超文字傳輸協議(超文字轉移協議)。

80年代HTTP的最初是致力於全世界的研究者們進行知識共享。隨後的一段時間的發展,一級網景通訊公司與微軟的瀏覽器大戰是得HTTP標準協議逐步被確立。目前主流的HTTP協議版本是1997年1月公佈的HTTP/1.1 版本。為了讓大家深刻回憶下HTTP/1.1 在我們web程式中的存在請看上期Spring Boot 啟動原理解析(二) Tomcat 啟動詳解中的一圖

HTTP總有你感興趣的

HTTP如何作用於客戶端與伺服器端的通訊

在瞭解HTTP如何進行通訊時有幾個TCP/IPD協議族是需要進行了解的:

1. 應用層:決定了向使用者提供應用服務時通訊的活動
2. 傳輸層:對上層應用層提供出於網路連線中的兩臺計算機之間的資料傳輸
3. 網路層:處理在網路上流動的資料包
4. 資料鏈路層:處理連線網路的硬體部分
複製程式碼

HTTP協議是利用TCP/IP協議族進行網路通訊,會通過分層順序與對方進行通訊。

我們以一個網路請求為例子,首先作為傳送端的客戶端在應用層(HTTP協議)發起了一個WEB頁面的HTTP請求。接著傳輸層(TCP協議)把應用層接收到的資料(HTTP請求報文)進行分割,並在各個報文上打上標記序號及埠號後轉發給網路層。網路層(IP協議)增加接收目的地的MAC地址後轉發給鏈路層,最後有鏈路層對外部網路傳送請求報文。接收端的伺服器在鏈路層收到資料,按序向上層傳送,一直到應用層。請求的響應過程則以伺服器端為起點傳送資料一直到客戶端接收到傳輸的資料。這樣一個完整的HTTP請求就完成了。

HTTP總有你感興趣的
傳送端在層與層之間的資料傳輸時,每經過一層時必定會被打上一個該層所屬的首部資訊。反之,接收端在層與層之間傳輸資料時,沒經過一層時都會把對應的首部資訊刪了。

從上文的HTTP通訊解讀過程我們知道沒有任環節進行通訊狀態的儲存,故此HTTP是一種無狀態協議。為實現儲存通訊狀態功能則需引入Cookie技術。

HTTP請求結果狀態碼

狀態碼描述的是伺服器返回的請求結果。狀態碼的類別有

  • 1xx Infomational(資訊性狀態碼) 接收的請求正在處理
  • 2xx Success(成功狀態碼) 請求正常處理完畢
  • 3xx Redirection(重定向狀態碼)
  • 4xx Client Error(客戶端錯誤狀態碼)
  • 5xx Seriver Error(伺服器錯誤狀態碼)

2xx的響應結果表明請求被正常處理了。

3xx重定向 響應結果表明瀏覽器需要執行某些特殊的處理以正確處理請求。301 Moved Permannetly 永久性重定向,請求的資源已被分配了新的URI;302 Found 臨時性重定向,請求的資源已被分配了新的URI;

4xx客戶端錯誤 表明客戶端是發生錯誤原因所在。400 Bad Request 請求報文中存在錯誤;403 Forbidden 伺服器拒絕請求資源的訪問;404伺服器上未找到請求資源。

5xx伺服器錯誤 表明伺服器本身發生錯誤

安全的HTTPS

HTTP + 加密 + 認證 + 完整性保護 = HTTPS 事物皆具兩面性,HTTP本身也有不足之處

  • 通訊使用明文傳輸,內容會有被竊聽的風險
  • 不驗證通訊方的身份,有可能遭遇偽裝
  • 無法證明報文的完整性,所以報文有可能已被篡改

如果在HTTP協議通訊過程中使用未加密的明文,比如WEB頁面進行登入操作時就會面臨被竊聽以及私密資訊暴露的風險;對於HTTP來說,伺服器跟客戶端都無法確認通訊方,因此很有可能並不是和原本預想的通訊方在實際的通訊。

為了統一的解決上述問題,需要在HTTP上再加入加密處理和認證等機制。通常的將加了加密及認證機制的HTTP稱為HTTP(HTTP secret)

The last

三人行,必有我師。在給大家分享乾貨的同時,才疏學淺還望大家大刀予以斧正。也歡迎關注我的掘金或簡書,名稱為柴碼

相關文章