HTTP 介紹
HTTP 基礎
前情提要:
認識HTTP的細節
HTTP 介紹
定義: 定義了客戶端跟伺服器端之間的溝通格式
無狀態協議 Stateless Protocol : 每一次的 HTTP 請求及 HTTP 回應都不相關
重大影響:你是誰?該怎麼保持每次連接的狀態
客戶端的 cookie & 伺服器端的 Session Data
客戶端 = 消費者、伺服器端 = 餐廳
Cookie = 集點卡、Session Data = 會員卡(Session ID = 會員卡號)
HTTP 訊息格式
客戶端發出請求,伺服器端回應,那中間的傳輸是什麼呢?是一段「訊息」
訊息格式:
- HTTP start line + CRLF
- 請求:請求方法、空白、請求目標、空白、HTTP 版本、CRLF
- 回應:HTTP 版本、空白、狀態碼、空白、原因短語、CRLF
- HTTP Header fields + CRLF
- CRLF
- HTTP Message Body (optional)
CRLF 是回車鍵(enter鍵) + 下一行的意思
HTTP 請求訊息格式
要求網址: https://www.kollos.com.tw/ 要求方法: GET 狀態碼: 200 OK 遠端位址: 35.234.58.227:443 參照網址政策: strict-origin-when-cross-origin
response header
HTTP/1.1 200 OK Server: nginx/1.20.1 Date: Fri, 19 May 2023 06:08:17 GMT Content-Type: text/html; charset=utf8 Content-Length: 190465 Connection: keep-alive Access-Control-Allow-Origin: *
request header
GET / HTTP/1.1 Accept: image/avif,image/webp,image/apng,image/svg+xml,image/,/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6 Connection: keep-alive Cookie: session=511c04fe835f79835d453aa86de510945cd14773gAWVRAAAAAAAAACMQDkzMDhjYTcxY2NiNzFkZmQwZWQzY2Y3ZWZmMjAzMTNmMGE4ZmFiZDEzMThmYWFjOGM4ODVjYWQyNjExYjZkZDmULg==; _gcl_au=1.1.1091339816.1684468685; _gid=GA1.3.644000670.1684468685; G_ENABLED_IDPS=google; _fbp=fb.2.1684468685257.786296447; _clck=6o0wa6|2|fbq|0|1234; _ttd_sync=1; _ga_G5MMRRR9VT=GS1.1.1684468687.1.1.1684472304.0.0.0; _ga_K42VZSC5VR=GS1.1.1684468687.1.1.1684472304.49.0.0; _ga=GA1.3.1068882697.1684468685; _uetsid=5deb2580f5f911edb839e15aa2b798f2; _uetvid=5deb8600f5f911ed8ceff95ca454cee8; _clsk=165dy0k|1684472306556|14|1|w.clarity.ms/collect Host: www.kollos.com.tw Referer: https://www.kollos.com.tw/backend/frontend/css/common.css Sec-Fetch-Dest: image Sec-Fetch-Mode: no-cors Sec-Fetch-Site: same-origin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36 sec-ch-ua: “Google Chrome”;v=”113”, “Chromium”;v=”113”, “Not-A.Brand”;v=”24” sec-ch-ua-mobile: ?0 sec-ch-ua-platform: “macOS”
HTTP 訊息格式
手動發出一個 HTTP 請求 – 使用 telnet 來建立一個 TCP 連線到伺服器端,並請求一個資源
HTTP 請求方法
目前共有 9 種方法,這裡介紹3種:
GET 方法
- 用於從伺服器端獲取指定的資源(文件、圖片、影片)
- http://api.tagtoo.com.tw/v3/feed/facebook/special/1843?currency=TWD
POST 方法
送資料給伺服器端,而伺服器端會針對這些資料做資源上的新增/修改,如提交表單
HEAD 方法
幾乎跟 GET 方法一樣,但不要求 HTTP 回應的 Message Body,只有 Meta Data
HTTP HEADER
-
提供 HTTP 請求/回應的額外資料,給客戶端或伺服端判別或操作
- Host: www.kollos.com.tw:80
- 伺服器的域名:伺服器所監聽的埠號
- HTTP/1.1 後的必填欄位
- Referer: https://www.kollos.com.tw/backend/frontend/css/common.css
- 其實是 “Referrer”
- 從這個欄位的網站,連到你的網站
- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36
- 標明身份
HTTP 回應狀態碼
- 伺服器端回傳HTTP回應給客戶端時,用來表示這次HTTP的請求結果
- 分五大類
- 訊息 1XX: 表明HTTP請求已經收到,將有後續動作
- 成功 2XX: 表明HTTP請求已經收到,能辨別,且處理完成
- 轉址 3XX: 客戶端需要進一步操作,搭配 Location Header
- 客戶端錯誤 4XX: HTTP請求語法錯誤,或無法完成HTTP請求
- 伺服器錯誤 5XX
Content Security Policy (CSP)
CSP代表內容安全策略(Content Security Policy)。它是一種安全機制,用於幫助保護網站免受跨站腳本攻擊(XSS)、數據注入和點擊劫持等常見的網絡安全威脅。
語法:
- self - 允許同網域
- unsafe-inline - 允許 HTML 內的執行
response header 中每一行的意思
> Access-Control-Allow-Origin: https://www.kollos.com.tw
> Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
> Content-Length: 2
> Content-Type: application/json
> Date: Fri, 19 May 2023 06:08:19 GMT
> Server: uvicorn
> Via: 1.1 google
Access-Control-Allow-Origin
> 這個響應頭表示允許訪問該資源的源(來源)是"https://www.kollos.com.tw"。在跨域請求中,該頭部可以用於指定允許訪問資源的來源域名。
> Access-Control-Allow-Origin: https://www.kollos.com.tw
Alt-Svc
> 這個響應頭是備用服務的聲明。它指示客戶端可以使用HTTP/3 (h3)協議和HTTP/2 (h3-29)協議訪問資源。該頭部中的 "ma" 參數表示備用服務的最大期限(以秒為單位)
> Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
PS. 這個後面有更詳細的解釋
Content-Length
> 這個響應頭表示響應主體的長度為2個字節。它指示了服務器發送的實際數據的大小。
> Content-Length: 2
Content-Type
> 這個響應頭表示響應的內容類型為"application/json",即服務器返回的數據是以 JSON 格式進行編碼的。
> Content-Type: application/json
Date
> 這個響應頭表示響應生成的日期和時間。它指示響應生成的準確時間,以協調世界時 (UTC) 格式表示。
> Date: Fri, 19 May 2023 06:08:19 GMT
Server
> 這個響應頭指示響應的服務器軟體名稱。在這種情況下,服務器使用的是名為 "uvicorn" 的軟件。
> Server: uvicorn
Via
> 這個響應頭指示響應通過了一個或多個中間代理(例如代理服務器或網關)。 "Via" 頭部提供了關於經過的代理的信息,包括代理的協議版本和名稱。在這裡,響應經過了一個名為 "google" 的代理。
> Via: 1.1 google
request header 中每一行的意思
> :Authority: event.tagtoo.co
> :Method: POST
> :Path: /event/v1
> :Scheme: https
> Accept: */*
> Accept-Encoding: gzip, deflate, br
> Accept-Language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6
> Content-Length: 613
> Content-Type: text/plain;charset=UTF-8
> Cookie: permanent=a+z4sn5k9m7p5956wp; session=b+r60ipq78orlffaie
> Origin: https://www.kollos.com.tw
> Referer: https://www.kollos.com.tw/
> Sec-Ch-Ua: "Google Chrome";v="113", "Chromium";v="113", "Not-A.Brand";v="24"
> Sec-Ch-Ua-Mobile: ?0
> Sec-Ch-Ua-Platform: "macOS"
> Sec-Fetch-Dest: empty
> Sec-Fetch-Mode: no-cors
> Sec-Fetch-Site: cross-site
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Authority
> 這是請求的目標服務器的主機名(域名),即請求將發送到 event.tagtoo.co。
> :Authority: event.tagtoo.co
Method
> 這是HTTP請求的方法,表示此請求將使用POST方法發送到服務器。
> :Method: POST
Path
> 這是請求的路徑,表示要訪問的資源在服務器上的位置。在這種情況下,請求將訪問位於/event/v1的資源。
> :Path: /event/v1
Scheme
> 這是請求使用的協議,表示請求將通過HTTPS協議進行安全通信。
> > :Scheme: https
Accept
> 這是指示客戶端可以接受任何類型的響應內容。通配符 * 表示可以接受任何類型。
> Accept: */*
Accept-Encoding
> 這是指示客戶端可以接受的響應內容編碼方式。 gzip、deflate和br分別表示支持Gzip壓縮、Deflate壓縮和Brotli壓縮。
> Accept-Encoding: gzip, deflate, br
Accept-Language
> 這是指示客戶端可以接受的語言偏好設置。在這裡,zh-TW表示中文(台灣),zh表示中文,en-US表示英文(美國),en表示英文,zh-CN表示中文(中國),q=0.9、q=0.8、q=0.7和q=0.6是用於指定每種語言的優先級。
> Accept-Language: zh-TW,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-CN;q=0.6
Content-Length
> 這是請求主體的長度,表示請求主體包含的數據的字節數。
> Content-Length: 613
Content-Type
> 這是請求主體的內容類型,表示請求主體中的數據是純文本,並使用UTF-8編碼。
> Content-Type: text/plain;charset=UTF-8
Cookie
> 這是包含在請求中的Cookie頭部,其中包含了一些鍵值對,用於在客戶端和服務器之間傳遞狀態信息。
> Cookie: permanent=a+z4sn5k9m7p5956wp; session=b+r60ipq78orlffaie
Origin
> 這是指示請求的來源頁面的URL。在這裡,請求來自 https://www.kollos.com.tw。
> Origin: https://www.kollos.com.tw
Referer
> 這是指示引用來源頁面的URL。在這裡,請求中的數據是從 https://www.kollos.com.tw/ 頁面發送的。
> Referer: https://www.kollos.com.tw/
Sec-Ch-Ua
> 這是指示客戶端的用戶代理(瀏覽器)和版本信息。
> Sec-Ch-Ua: "Google Chrome";v="113", "Chromium";v="113", "Not-A.Brand";v="24"
Sec-Ch-Ua-Mobile
> 這是指示客戶端的用戶代理是否為移動設備的標誌。
> Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform
> 這是指示客戶端的操作系統平台信息。
> Sec-Ch-Ua-Platform: "macOS"
Sec-Fetch-Dest
> 這是指示在發起請求時,不需要特定的目標資源類型。 "empty"表示不指定具體的目標資源類型。
> Sec-Fetch-Dest: empty
Sec-Fetch-Mode
> 這是指示在發起請求時,使用的是 "no-cors" 模式。在 "no-cors" 模式下,瀏覽器會發起跨域請求,但不會在請求中包含對於跨域響應的訪問權限檢查。
> Sec-Fetch-Mode: no-cors
Sec-Fetch-Site
> 這是指示在發起請求時,請求的資源位於不同的站點(跨站點)。這個頭部告訴服務器請求的資源是跨域的。
> Sec-Fetch-Site: cross-site
User-Agent
> 這是指示發起請求的用戶代理(瀏覽器)的信息。在這裡,用戶代理是基於WebKit引擎的Mozilla瀏覽器,版本號為113.0.0.0,運行在Macintosh操作系統的Intel Mac OS X 10.15.7版本上。
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
Alt-Svc 意思 (alternative service)
它是為了讓伺服器端能告訴客戶端 “看,我在這個主機的這個端口用此協定提供相同的服務”。
> Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
收到這樣的 Alt-svc 回應後,如果客戶端支援並希望使用其他協定,則它將在後台使用指定的協定與主機進行並行連接,並且連接成功。 如果是這樣,它將切換到該協定,而不是使用第一個連接。
Alt-svc 回應中有一個到期計時器,讓客戶端可以在指定的時間內使用建議的替代協定後將後續連接和請求直接發送給替代主機。
> 就是這個,這代表2592000秒(即30天),客戶端在此期限內可以使用備用服務來獲取資源。
> ma=2592000
詳細解釋 : https://http3-explained.haxx.se/zh-tw/h3/h3-altsvc
OSI 模型 (Open System Interconnection Model)
是一種概念模型,由國際標準化組織(ISO)
提出,一個試圖使各種電腦在世界範圍內互連為網路的標準框架。定義於 ISO/IEC 7498-1
。
該模型將通訊系統中的資料規劃分為 七個層
,從 分散式應用程式資料的最高層表示
到 跨通訊媒介傳輸資料的物理實現
,每個中間層為其上一層提供功能,其自身功能則由其下一層提供,功能的類別通過標準的通訊協定在軟體中實現。
根據建議X.200,OSI將電腦網路體系架構劃分為以下七層,標有 1~7,第一層在底部。
第七層 - 應用層
應用層(Application Layer) 提供為應用軟體而設計的介面,以設定與另一個軟體之間的通訊。例如:HTTP、HTTPS、FTP、Telnet、SSH、SMTP、POP3等。
第六層 - 表現層(表示層)
表現層(Presentation Layer) 把數據轉換為能與接收者的系統格式相容並適合傳輸的格式。
第五層 - 會議層(對談層)
會議層(Session Layer) 負責在數據傳輸中設定和維護電腦網路中兩台電腦之間的通訊連接。
第四層 - 傳輸層
傳輸層(Transport Layer) 把傳輸表頭(TH) 加至資料以形成封包。傳輸表頭包含了所使用的協定等傳送資訊。例如:傳輸控制協定(TCP)等。
第三層 - 網路層
網路層(Network Layer) 決定數據的路徑選擇和轉寄,將網路表頭(NH) 加至數據包,以形成封包。網路表頭包含了網路資料。例如:網際網路協定(IP)等。
第二層 - 資料連接層
資料連結層(Data Link Layer) 負責網路尋址、錯誤偵測和改錯。當表頭和表尾被加至數據包時,會形成資訊框(Info Box)。數據連結串列頭(DLH)是包含了實體位址和錯誤偵測及改錯的方法。數據連結串列尾(DLT)是一串指示數據包末端的字串。例如以太網、無線區域網路(Wi-Fi)和通用分組無線服務(GPRS)等。
分為兩個子層:邏輯鏈路控制(logical link control,LLC)子層和媒介存取控制(Media access control,MAC)子層。
第一層 - 實體層
實體層(Physical Layer) 在區域網路上傳送資料框(Data Frame),它負責管理電腦通訊裝置和網路媒體之間的互通。包括了針腳、電壓、線纜規範、集線器、中繼器、網卡、主機介面卡、路由器等。
OSI 影響
OSI是一個定義良好的協定規範集,並有許多可選部分完成類似的任務。它定義了開放系統的階層、層次之間的相互關係以及各層所包括的可能的任務,作為一個框架來協調和組織各層所提供的服務。
OSI參考模型並沒有提供一個可以實現的方法,而是描述了一些概念,用來協調行程間通訊標準的制定。即OSI參考模型並不是一個標準,而是一個在制定標準時所使用的概念性框架。
TCP/IP 網際網路協議套組
前面為什麼會提到 OSI 呢?原因就是現在要來講網際網路最重要的協議了,就是被稱為 TCP/IP 的協定。
TCP/IP 提供了點對點連結的機制,將資料應該如何封裝、定址、傳輸、路由,以及在目的地如何接收,都加以標準化,他將軟體通訊過程抽象化為 四個抽象層
,採取 協定堆疊
的方式,分別時做出不同的通訊協定。
協定套組下的各種協定,依其功能不同,分別歸屬到這四個階層之中,常規為是簡化的 七層OSI模型
。
Ps. 懶人包就是,TCP/IP協議,就是簡化版的OSI模型
tcp/ip 協定棧組成
整個通訊網路的任務,,可以劃分不同的功能區塊,即所謂的 層級(layer)
,用於網際網路的協定可以比照 TCP/IP參考模型
進行分類,tcp/ip 協定棧起始於第三層協定IP。
必須協定
所有的TCP/IP應用都必須實現IP和ICMP。對於一個路由器(router)而言,有這兩個協定就可以運作,雖然從應用的角度來看,這樣一個路由器意義不大。
實際的路由器一般還需要執行許多「推薦」使用的協定,以及一些其他的協定。 幾乎所有連接到網際網路上的電腦上都存在的IPv4協定出生在1981年,今天的版本和最早的版本並沒有多少改變。
升級版IPv6的工作始於1995年,目的在於取代IPv4。ICMP協定主要用於收集有關網路的資訊尋找錯誤等工作。
網際網路控制訊息協定(ICMP)
是網際網路協定套組的核心協定之一。它用於網際網路協定(IP)中傳送控制訊息,提供可能發生在通訊環境中的各種問題回饋。通過這些資訊,使管理者可以對所發生的問題作出診斷,然後採取適當的措施解決。
網際網路協定疊中的層
通常人們認為OSI模型的上面三層(應用、表現、會議層),在TCP/IP中會濃縮成一個應用層,由於TCP/IP有一個比較弱的會議層,由TCP和RTP下的打開和關閉連接組成,並且在TCP和UDP下的各種應用提供不同的埠號,這些功能能夠由單個的應用程式(或者那些應用程式所使用的庫)增加。
> TCP/IP 的四個抽象層
> | - - - - - - - - - - - |
> | |
> | 應用層 | 例如HTTP、FTP、DNS
> | (application layer) | (如BGP和RIP這樣的路由協定,儘管由於各種各樣的原因它們分別執行在TCP和UDP上,仍然可以將它們看作網路層的一部分)
> | |
> | - - - - - - - - - - - |
>
> | - - - - - - - - - - - |
> | |
> | 傳輸層 | 例如TCP、UDP、RTP、SCTP
> | (transport layer) | (如OSPF這樣的路由協定,儘管執行在IP上也可以看作是網路層的一部分)
> | |
> | - - - - - - - - - - - |
>
> | - - - - - - - - - - - |
> | |
> | 網路互連層 | 對於TCP/IP來說這是網際網路協定(IP)
> | (transport layer) | (如ICMP和IGMP這樣的必須協定儘管執行在IP上,也仍然可以看作是網路互連層的一部分;ARP不執行在IP上)
> | |
> | - - - - - - - - - - - |
>
> | - - - - - - - - - - - |
> | |
> | 網路存取(連結)層 | 例如乙太網路、Wi-Fi、MPLS等。
> | (Network Access layer)|
> | |
> | - - - - - - - - - - - |
應用層
該層包括所有和應用程式協同工作,利用基礎網路交換應用程式專用的資料的協定。
應用層是大多數普通與網路相關的程式,為了通過網路與其他通訊所使用的層,這個層的處理過程是應用特有的資料從網路相關的程式,以這種內部使用的格式進行傳送,然後編碼成標準協定的格式。
一些特定的程式視為在此層運行,他們提供服務直接支援使用者應用,這些程式和他們對應的協定,包括 HTTP(全球資訊網服務)、FTP(檔案傳輸)、SMTP(電子郵件)、SSH(安全遠端登入)、DNS(名稱⇔IP位址尋找)…等等多項協定。
一旦從應用程式來的資料編碼成一個標準的應用層協定,他將傳送到IP棧的下一層。
在傳輸層,應用程式最常用的是TCP或UDP,並且伺服器應用程式經常與一個 公開的埠號
相聯絡,伺服器應用程式的埠由 網際網路號分碼配局(IANA)
正式分配,但是現今一些新協定的開發者經常選擇它們自己的埠號。
連結外部的客戶端程式通常使用系統分配的一個隨機埠號。監聽一個埠並且通過伺服器將那個埠傳送到應用的另外一個副本,以建立對等連結的應用也可以使用一個隨機埠,但是應用程式通常允許定義一個特定的埠範圍的規範,以允許埠能夠通過實現網路位址轉換(NAT)的路由器對映到內部。
每一個應用層協定一般都會使用到兩個傳輸層協定之一:
(1) 面向連接的TCP傳輸控制協定
(2) 無連接的包傳輸的UDP使用者資料報協定
常用的應用層協定有:
執行在TCP協定上的協定:
- HTTP(Hypertext Transfer Protocol,超文字傳輸協定),主要用於普通瀏覽。
- HTTPS(Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL,安全超文字傳輸協定),HTTP協定的安全版本。
- FTP(File Transfer Protocol,檔案傳輸協定),由名知義,用於檔案傳輸。
- POP3(Post Office Protocol, version 3,郵局協定),收郵件用。
- SMTP(Simple Mail Transfer Protocol,簡單郵件傳輸協定),用來傳送電子郵件。
- TELNET(Teletype over the Network,網路電傳),通過一個終端(terminal)登陸到網路。
- SSH(Secure Shell,用於替代安全性差的TELNET),用於加密安全登陸用。
執行在UDP協定上的協定:
- BOOTP(Boot Protocol,啟動協定),應用於無盤裝置。
- NTP(Network Time Protocol,網路時間協定),用於網路同步。
- DHCP(Dynamic Host Configuration Protocol,動態主機組態協定),動態組態IP位址。
其他:
- DNS(Domain Name Service,域名服務),用於完成位址尋找,郵件轉發等工作(執行在TCP和UDP協定上)。
- ECHO(Echo Protocol,迴繞協定),用於查錯及測量應答時間(執行在TCP和UDP協定上)。
- SNMP(Simple Network Management Protocol,簡單網路管理協定),用於網路資訊的收集和網路管理。
- ARP(Address Resolution Protocol,位址解析協定),用於動態解析乙太網路硬體的位址。
傳輸層
主要提供系統間資料的傳輸更高階的控制,為了確保本層保證所有的資料都是以正確的順序送達,因此紀錄來源/目的Port位置,此外亦會給每一個封包追蹤號碼,並在目的地進行檢查。
網路互連層
主要是負責處理將封包由來源電腦傳給目的電腦之間的路徑選擇問題,因此會在此定義該封包需要送往哪一個IP位置。
網路存取(連結)層
主要是用來定義來源/目的的MAC地址,以及所使用的協定為何(IPV4/IPV6)