> For the complete documentation index, see [llms.txt](https://jen-hsuan-hsieh.gitbook.io/protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jen-hsuan-hsieh.gitbook.io/protocol/chapter3-protocol-for-wireless-network/32http/321session-and-cookie.md).

# 3.2.1.Basic concept

## 1.Overview (參考自[wiki](https://zh.wikipedia.org/wiki/%E8%B6%85%E6%96%87%E6%9C%AC%E4%BC%A0%E8%BE%93%E5%8D%8F%E8%AE%AE#.E8.AF.B7.E6.B1.82.E6.96.B9.E6.B3.95))

* HTTP是一個用戶端終端（用戶）和伺服器端（網站）請求和應答的標準（TCP）。通過使用網頁瀏覽器、網路爬蟲或者其它的工具，用戶端發起一個HTTP請求到伺服器上指定埠（預設埠為80）。我們稱這個用戶端為用戶代理程式（user agent）。
* 應答的伺服器上儲存著一些資源，比如HTML檔案和圖像。我們稱這個應答伺服器為源伺服器（origin server）。在用戶代理和源伺服器中間可能存在多個「中間層」，比如代理伺服器、閘道器或者隧道（tunnel）。

## 2.HTTP Request

![](https://3840825399-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M4M0G8PXRnA3yHgZCAL%2F-M4M0Gn8DmjJ2aT88bjY%2F-M4M0HcJ-71B3JDd29vr%2F%E8%9E%A2%E5%B9%95%E5%BF%AB%E7%85%A7%202017-05-03%20%E4%B8%8B%E5%8D%882.07.49.png?generation=1586302892391078\&alt=media)

* HTTP請求可分為三個部分
  * 請求方法URI協議/版本
    * 如上圖, GET代表請求方法, /blo/pos...代表URI, HTTP 1.1是協議的版本
  * 請求頭(Request Header)
  * 請求正文
    * 請求頭和請求正文之間是一个空行, 這個行非常重要, 它表示請求頭已經結束, 接下来的是請求正文

## 3.Request Method

* [HTTP 1.1](https://www.w3.org/Protocols/rfc2616/rfc2616.html)協定中共定義了八種方法
  * 1.GET：向指定的資源發出顯示請求,使用GET方法應該只用在讀取資料
    * 2.POST: 向指定資源提交資料, 請求伺服器進行處理（例如提交表單或者上傳檔案. 資料被包含在請求本文中.這個請求可能會建立新的資源或修改現有資源, 或二者皆有。
  * 3.PUT：向指定資源位置上傳其最新內容
  * 4.DELETE：請求伺服器刪除Request-URI所標識的資源
  * 5.TRACE：回顯伺服器收到的請求, 主要用於測試或診斷
  * 6.HEAD：與GET方法一樣, 都是向伺服器發出指定資源的請求. 只不過伺服器將不傳回資源的本文部份
  * 7.OPTIONS：這個方法可使伺服器傳回該資源所支援的所有HTTP請求方法
  * 8.CONNECT：HTTP/1.1協定中預留給能夠將連線改為管道方式的代理伺服器. 通常用於SSL加密伺服器的連結（經由非加密的HTTP代理伺服器）

## 4.HTTP Response

* HTTP響應可分為三個部分
  * 狀態行
    * status code
    * 響應頭(Response Header)
    * Location
      * Server
        * WWW-Authenticate
          * Content-Encoding
          * Content-Language
          * Content-Length
          * Content-Type
          * Last-Modified
          * Expires
    * 響應正文

## 5.Status code

* **200 : OK** (客户端請求成功)
* **400 : Bad Request** (由於客户端請求有語法錯誤，不能被服務器所理解)
* **401 : Unauthorized** (請求未經授權, 這個狀態代碼必須和WWW-Authenticate一起使用)
* **403 : Forbidden** (服务器收到請求, 但是拒絕提供服務. 服務器通常會在響應正文中给出不提供服務的原因)
* **404 : Not Found** (請求的資源不存在, 例如輸入了錯誤的URL)
* **500 : Internal Server Error** (服務器發生不可預期的錯誤，導致無法完成客户端的請求)
* **503 : Service Unavailable** (服務器當前不能夠處理客户端的請求, 在一段時間之後, 服務器可能会恢復正常)

## 6.HTTP/2 v.s HTTP/1.1 (參考自[Joomla](https://simular.co/knowledge/site-build/68-about-http2-and-http11.html))

* 1.API 不用修改: HTTP/2多數的header與HTTP/1.1相同, 因此可以向下相容HTTP/1.1
* 2.建立在 SPDY 的基礎上
* 3.伺服器推送: 例如可以在瀏覽器尚未發出請求前, 預先推送 CSS 或頁面 Layout 到瀏覽器上, 增加之後的頁面載入速度
* 4.標頭壓縮與編碼
* 5.流程下載控制與優先級
* 6.不強制採用加密傳輸

## 7.HTTP v.s HTTPS

* https 是 http over SSL 的縮寫(SSL: Secure Sockets Layer), 也就是將常見的 http 協定經過加密後的版本, 目前已是網路上進行加密通訊之全球化標準
* https 的功用
  * 1.讓使用者確認伺服器的身份:
    * 伺服器若需啟用 https 的加密協定, 必需安裝 SSL 憑證於伺服器中, 且此 SSL 憑證中會記載伺服器的相關資訊, 如憑證發放單位、憑證有效日期及網站的網址等資訊。當使用者透過 IE 或其他網頁瀏覽器瀏覽加密網頁時, 瀏覽器會自動檢查伺服器的憑證中上述的三種資訊是否正確, 只要其中一項不通過檢查, 瀏覽器就會跳出警告, 告知使用者這個網站可能是不安全, 甚至是惡意人士偽造的
  * 2.內容加密
    * 當伺服器使用 https 協定時, 所有在使用者端(瀏覽器)和伺服器之間傳遞的資料, 都會經過加密, 所以就算使用者的密碼或信用卡號碼在網路上被攔截, 也必需花費相當功夫的解碼後才可以被讀出解讀
  * 3.資料完整性確認
    * SSL 會自動偵測資料於傳遞途中是否有遭到修改, 使用者便可以安心地將個人私密資料(如信用卡資訊)透過網際網路進行傳輸, 並信任 SSL 機制會保護這些資訊的隱私及安全性