# Week5 —— HTTP(+S, on SSL/TLS)
- ## 什麼是通訊協定？<br>為什麼要有通訊協定的存在？
定義：通訊協定在網路規範數據在網路節點之間，該如何進行傳輸和交換的一套標準。
它們描述了傳送與接收訊息、處理以及回應的格式和程序 (process)。
存在原因有
**- 規格化： *不同* 製造商、*不同* 系統與軟體、*不同* 地理位置的節點能夠通過遵守同一套通訊協定來進行溝通。**
**- 效率：定義了數據傳輸的標準格式和程序，可以提高數據傳輸的效率。**
**- 可靠性：包含錯誤檢測、校正機制，提高數據傳輸的可靠性。**
**- 兼容性：確保新舊技術之間彼此兼容性。**
**- 🌟安全性：部分通訊協定，甚至還提供數據加密、驗證，來保證數據傳輸的安全。** |
| |TCP / IP| HTTP|FTP|SMTP|
|-|-|-|-|-|
| 定義 | 網路通訊規則 | 分配網路資源協定 | 文件傳輸 | 電子郵件傳輸 |
| 層級 | OSI 模型<br>傳輸層 (TCP)與網路層 (IP) | 應用層 | 應用層 | 應用層 |
| 傳輸方式 | 連接導向 (TCP)<br>非連接導向 (IP) | 請求—回應 | 控制和資料連接 | 請求—回應 |
| 用途 | 網路通訊 | 網頁資料傳輸 | 文件傳輸 | 電子郵件傳輸 |
| 安全性 | 無 | 要 HTTPS | 要 SSL / TLS | 要 SSL / TLS |
| 實例 | 瀏覽器與伺服器 | 瀏覽網頁 | 上傳下載文件| 發送接收郵件 |
## HTTP 通訊協定有哪些重要的特性？
- 無狀態性：HTTP協定是無狀態的，意味著伺服器不會保存客戶端的任何資料。每次客戶端發送請求到伺服器時，伺服器就會處理該請求並回應，然後忘記請求。無狀態性讓 HTTP 協定更簡單，但也意味著無法直接實現像登錄狀態或購物車這類需要狀態的功能，這需要使用到如 Cookie 的其他技術。
- 簡單快速：客戶端向伺服器請求服務時，只需要傳送方法和路徑。由於 HTTP 協定的設計簡單，所以通訊速度很快。
- 靈活：HTTP 允許傳輸任何類型的數據，只需要在 HTTP Header 中的 Content-Type 欄位中標明資料類型即可。
- 無連接：意味著一次 HTTP 通信只能處理一個請求。伺服器處理完客戶的請求並收到客戶的應答後，即切斷連接。這可以 **節省傳輸時間**。
- 支援 BLOB：支援 BLOB（Binary Large Object），這表示它可以傳輸如圖片或其他多媒體檔案等大型二進位對象。
- 可擴展性：允許自定義方法和 Header 欄位，使協定具有高度擴展性。
請注意，HTTP是一種明文傳輸協定，這意味著其在傳輸數據時並不具備安全性。然而，透過**HTTPS（HTTP Secure）**，
可以為 HTTP 協定提供加密的連接，以保護數據的安全。
## HTTP Request 包含哪些重要的資訊欄位？
HTTP Request 主要由三部分組成：起始行 (Start line)，請求頭 (Header)，以及請求主體 (Body)。以下是這三個部分中的一些重要的欄位：
### 起始行 (Start line)
| | |
|-|-|
| **Method** | HTTP 方法，如 GET、POST、PUT、DELETE |
| **URL** | 請求的 URL，包含了所要訪問的資源的路徑 |
| **HTTP Version** | 使用的 HTTP 版本，如 HTTP / 1.1 或 HTTP / 2 |
### 請求頭 (Header)
| | |
|-|-|
|**Host**| 要訪問的伺服器的地址和端口號 (port)|
|**User-Agent**| 客戶端（例如瀏覽器）的識別資訊 |
|**Accept**| 客戶端接受的媒體類型|
|**Content-Type**| 請求有主體時，會指定主體的媒體類型 |
|**Content-Length**| 請求有主體時，會指定主體的長度（以字節為單位）|
|**Authorization**| 當需要認證時，會包含認證憑據 |
|**Cookie**| 與請求的 URL 相關的所有 Cookie |
### 請求主體 (Body)
包含實際的請求資料，並不是所有的請求都有主體。
如：GET 請求沒有主體，POST, PUT 請求通常有主體。
請注意，以上只是一些常見的重要欄位，還有許多其他的 header 欄位可以用於各種目的。
## HTTP Response 包含哪些重要的資訊欄位？
HTTP Response 主要由三部分組成：
- 狀態行 (Status line)
- 響應頭 (Header)
- 響應主體 (Body)。
以下是這三個部分中的一些重要的欄位：
### 狀態行 (Status line)
| | |
|-|-|
|**HTTP Version**|*使用的 HTTP 版本*|
|**Status Code**|HTTP 狀態碼，表明了請求的處理結果。|
|**Status Text**|與狀態碼相對應的文字描述|
### 響應頭 (Header)
| | |
|-|-|
|**Content-Type**|*指定了主體的媒體類型*|
|**Content-Length**|*指定了主體的長度（以字節為單位）*|
|**Server**|處理該請求的伺服器的訊息|
|**Set-Cookie**|伺服器設置的cookie|
|**Date**|響應生成的日期和時間|
### 響應主體 (Body)
這部分包含實際的響應數據，這可以是 HTML、圖片、JSON 對象等等。
請注意，以上只是一些常見和重要的欄位，還有許多其他的 HTTP Header 欄位可以用於各種目的。
## 哪些前端程式、瀏覽器操作會預設使用 HTTP GET 方法？
以下是一些前端程式或瀏覽器操作會預設使用 HTTP GET 方法的例子：
1. **在瀏覽器網址列輸入網址**：輸入網址並按下 Enter 時，瀏覽器會使用 GET 方法向該網址發送請求。
2. **點擊超連結**：點擊一個超連結時。
3. **重新載入頁面**：點擊按鈕或使用快速鍵（如 Ctrl+R 或 F5）時，瀏覽器會重新請求當前的頁面。
4. **透過 JavaScript 發送 AJAX 請求**：當使用 `fetch` 或 `XMLHttpRequest` 物件發送 AJAX 請求時，如果沒有明確指定請求方法，則預設會使用 GET 方法。
5. **HTML 表單的預設提交方式**：當 HTML 表單（`<form>`）的 `method` 屬性沒有指定或者設定為 `"GET"` 時，提交表單會以 GET 方法發送請求。
請注意，**GET** 方法應該只用於 **獲取資訊**
不應該用來進行會改變伺服器狀態的操作（例如 **建立、更新或刪除資源** ）
這些操作應該使用其他的 **HTTP** 方法，例如 **POST**、**PUT** 或 **DELETE**。
## 詳細描述後端程式 redirect() 導向操作，實際上是如何透過前後端的互動完成？
### 絕對不會主動發訊息給客戶端
當後端程式執行 `redirect()` 方法時，它通常會向客戶端（Client side, 通常是網頁瀏覽器）發送一個特殊的 HTTP 響應。
這個響應的狀態碼通常是 **301(永久重定向)** 或 **302(臨時重定向)**，並且包含一個 `Location` 頭，其值為新的 URL。以下是這個過程的詳細步驟：
- **客戶端向伺服器發送請求**：使用者在網址列輸入網址、點擊連結、提交表單或者 JavaScript 發送 AJAX 請求而產生。
- **伺服器接收到請求並處理**：伺服器的後端程式會根據請求的 URL 和其他信息來決定如何處理這個請求。如果決定需要重定向，它就會執行 `redirect()` 方法。
- **伺服器發送重定向響應**：後端程式會創建一個狀態碼為 301 或 302 的 HTTP 響應，並且在這個響應的頭部加上一個 `Location` 頭，其值為新的 URL。然後，這個響應會被送回到客戶端。
- **客戶端接收到重定向響應**：當網頁瀏覽器（或其他客戶端）接收到這個響應時，它會解析這個響應，並且讀取 `Location` 頭的值。
- **客戶端發送新的請求**：瀏覽器會使用從 `Location` 頭獲取的新 URL，再次發送一個 HTTP 請求到伺服器。
- **伺服器處理新的請求**：當伺服器接收到新的請求時，它會像處理其他請求一樣處理這個請求，例如返回一個網頁或者其他資源。
## Redirect 重新導向流程
```sequence
客戶端->伺服器: 網址列輸入網址、點擊連結、提交表單、AJAX
Note right of 伺服器: 根據 URL 處理
伺服器-->客戶端: 狀態碼 301/302 響應+`Location` 頭，值為新 URL
Note left of 客戶端: 解析響應
客戶端->伺服器: 獲取新 URL 後再次發請求
Note right of 伺服器: 繼續處理...
伺服器-->客戶端: 繼續...
```
透過這種方式，`redirect()` 方法可以引導瀏覽器從一個 URL 導向到另一個。
這種重定向是在伺服器端完成的，而客戶端的行為（例如瀏覽器）是透明的。
換句話說，使用者通常會看到他們的瀏覽器突然從一個頁面跳轉到另一個頁面，而且網址列中的 URL 也會改變。
## What is a 301 Redirect, and When Should You Use One?
https://blog.hubspot.com/blog/tabid/6307/bid/7430/what-is-a-301-redirect-and-why-should-you-care.aspx
以下是一個用來比較 HTTP, HTTPS 和 SSL 的 Markdown 表格：
## HTTPS
**Hyper Text Transfer Protocol**
| 功能 | HTTP | HTTPS | SSL |
| ---- | ---- | ----- | --- |
| 定義 | 用於傳輸超文本的協議 | HTTP Secure，傳輸加密的網頁資料，透過 SSL / TLS 協議加密，保護資料的完整安全。 | Secure Sockets Layer，為網路通訊提供安全與資料完整性的加密協議。 |
| 安全性 | 不具備加密功能，資料傳輸過程會被竊取或篡改。 | 透過 SSL / TLS 提供加密連線，防止資料在傳輸過程被竊取篡改| SSL 是一種安全協議，用來確保在網際網路上資料的安全傳輸。|
| 預設端口號 | 80 | 443 | 依賴於使用該協議的應用。 |
| 效能 | 比 HTTPS 快 | 比 HTTP 慢，需要加密解密，但差異在現代硬體可忽略不計 | 效能取決於如何實施以及它被用在哪個網路應用中 |
| 隱私保護 | 低，傳輸過程可能會被竊取或篡改。 | 高，即使被攔截也無法輕易閱讀 | 高，因為 SSL 提供了數據加密、身份驗證以及訊息完整性檢查。 |
### 在實際應用中選擇使用哪種協議的一些考慮因素包括：
- SEO 必要性（搜索引擎優化）：Google 已明確表示 HTTPS 是他們排名算法，不用的話搜尋結果排名會非常災難
- 資料安全必要性：信用卡資訊，個人身份資訊，登入憑證等，
HTTPS 通過 SSL / TLS 協議提供的加密連線能提供必要的安全性。
- 使用者信任和網站聲譽：使用者在瀏覽器上看到 `https` 或鎖定的 `🔒` 圖標，可以知道他們的資訊是安全的，增強他們對網站的信任。
- 效能和可用資源：儘管在現代硬體上 HTTPS 的加密和解密操作帶來的效能下降通常可以忽略不計，但在有限的資源或高負載的情況下，這可能仍是一個需要考慮的因素。
- Web 功能需求：某些新的 Web 功能，如 `HTTP/2` 和 Service Workers，要求網站必須運行在 HTTPS 上。
- 成本與管理：雖然現在有許多組織如 `Let's Encrypt` 提供免費的 SSL 憑證，但在某些情況下，購買和管理 SSL 憑證可能仍需要時間和資源。
| OSI Model | Layer Function |
|---|---|
| **Layer 7**: 💁Application 應用層 | 為應用程式提供網路服務的端點/接口。例如 **HTTP(S)**、SMTP、FTP 等。|
| **Layer 6**: 🧑💻Presentation 表示層 | 負責資料的轉換和編碼，以便其能夠在資料上進行傳輸，例如 **ASCII**、**Unicode**、JPEG|
| **Layer 5**: 💬Session 會話層 | 建立、管理和終止兩個網路節點之間的連結（會話），例如 NFS、**SQL**、**RPC**|
| **SSL 🔐 (Secure Sockets Layer)<br>TLS (Transport Layer Security)** | 保證資料安全和完整性，使用了 TCP (第4層) |
| **Layer 4**: ➡️ Transport 傳輸層| 提供了點對點的資料傳輸與控制。例如 **TCP** 和 UDP 協議。|
| **Layer 3**: 🛜 Network 網路層| 負責數據包的路由和傳輸，例如 **IP** 協議、ICMP、IGMP。|
| **Layer 2**: 🧵Data Link 資料連結層 | 連接網路軟體和硬體的部分。例如 Ethernet 和 PPP。|
| **Layer 1** ⚡️Physical 實體層| 處理硬體方面的細節，例如電壓、時鐘、物理數據速率等。Ethernet（硬體實現）。|
SSL (Secure Sockets Layer) 和它的繼任者 TLS (Transport Layer Security) 主要運作在 OSI 模型的第五層（會話層）和第四層（傳輸層）之間。它們為網路通信提供了安全和數據完整性保證。
SSL / TLS 協議使用了傳輸層的服務（如 TCP），並為應用層（如 HTTP）提供了一個安全的通道。因此，當我們說 HTTPS（HTTP over SSL / TLS）時，實際上是指 HTTP 在 SSL / TLS 的保護下運行。
總的來說，雖然 SSL / TLS 在 OSI 模型中並沒有明確的一層，但它們主要在會話層和傳輸層之間運作，為上層應用提供安全性保證。
```mermaid
graph TD;
A-->P;
P-->S;
S-->T;
T-->N;
N-->D;
D-->PHY;
A(應用層 HTTP, HTTPS, SMTP, FTP);
P(表示層 ASCII, Unicode, JPEG);
S(會話層 NFS, SQL, RPC);
T(傳輸層 TCP, UDP);
N(網路層 IP, ICMP, IGMP);
D(資料連結層 Ethernet, PPP);
PHY(實體層 Ethernet（硬體實現）);
```
```
### 5-NFS (Network File System):
在許多 Unix 和 Linux 系統中，NFS 仍然是共享文件的主要方式。它也被用在一些企業級的存儲解決方案中。
NFS 是一種分佈式文件系統協議，由 Sun Microsystems 在 1980 年代開發，允許一個系統在網路上分享其文件系統給其他系統使用，就像本地存儲一樣。
### 4-UDP (User Datagram Protocol 使用者資料圖表協議):
UDP 是一種無連接的網路通信協議，它不保證消息的順序或可靠性，但傳輸速度快、低延遲，在許多即時應用中仍然被廣泛使用，常用於影片串流、VoIP（網路語音）、遊戲等對即時性要求高的應用。
```
### 4-TCP (Transmission Control Protocol):
TCP 是一種連接導向的協議，它確保數據包按照發送的順序到達，並重傳丟失的數據包，常用於需要可靠的傳輸的應用，如：網頁瀏覽、郵件傳輸等。
TCP 和 IP 的主要區別在於， IP (3層) 負責將數據包路由到目的地，TCP (4層) 接著負責數據的傳輸和控制。
### 3-ICMP (Internet Control Message Protocol):
用於 **IP** 網路診斷和報告錯誤的協議，例如 **"ping"** 命令
### 3-IGMP (Internet Group Management Protocol): 網際網路群組管理協議
主要用於支援多播和 IP 電視（IPTV）等應用。多播允許一個來源節點向多個目標節點同時傳送資料，而不需要重複傳送。
### （少用）2-PPP (Point-to-Point Protocol 點對點協議):
一種數據鏈路協議，用於在直接連接的兩個節點之間建立網路連接，例如撥號和數據機連接。
雖然 PPP 在撥號上網中的使用已經大大減少（因為寬頻和行動網路的普及），但它仍然在某些場合下被使用，例如在某些 DSL（數位用戶線）和 VPN（虛擬私人網路）連接中。
### Ethernet:
一種用於構建區域網路（LAN）的技術標準。
它定義了如何進行數據包的傳輸，包括如何格式化數據、如何檢測和糾正錯誤等。
Ethernet 可以用於有線（例如，使用雙絞線或光纖）和無線（例如，Wi-Fi）網路。
### LAN
Sign in with Wallet
Connect another wallet