Skip to main content

Command Palette

Search for a command to run...

Lesson 7: 網路共通語-HTTP 協定核心

Updated
2 min read

前面介紹了比較多實務上的內容,內容也相對扎實,接下來我們就進到比較輕鬆的環節,這篇文章主要探討HTTP以及相關延伸的概念。

什麼是Http

HTTP(超文字傳輸協定,HyperText Transfer Protocol)是全球資訊網 (World Wide Web) 的基礎,它是一種應用層協定,用於在用戶端和伺服器之間傳輸超媒體文件(例如 HTML 頁面)。HTTP 是網路上的共通語言。

HTTP (HyperText Transfer Protocol,超文字傳輸協定) 是全球資訊網 (World Wide Web) 的資料通訊基礎。

它位於 OSI 模型的應用層,是電腦之間交換資訊時遵循的一套規則。如果說 TCP/IP 像是網路世界的郵局和道路,那麼 HTTP 就是與伺服器之間溝通的「語言」。

OSI模型是什麼

相信離開資訊相關科系後,這些學術內容(計算機概論)大家跟我一樣都拋在腦後了,所以我們來簡單複習一下。

OSI模型分成七層:應用層、表示層、工作層、傳輸層、網路層、資料連結層、實體層

基本上工作後大多只會碰到應用層

應用層就是大家耳熟能詳的:Http,Https,FTP,SMTP之類的

Http的應用

HTTP 採用經典的客戶端-伺服器端 (Client-Server) 模式,整個過程就是一個不斷循環的請求-回應 (Request-Response) 循環。

  1. 用戶端 (Client, 通常是瀏覽器):發起請求,要求存取特定資源(如 HTML 文件、圖片、API 資料)。

  2. 伺服器端 (Server, 網站主機):接收請求,處理資料,並回傳回應。

Request

作為後端工程師,我們每天都在接受請求後進行回應,一個完整的請求包含以下

請求行

請求行由:請求方法(Method)、請求目標(path/路由)、請求版本 組合而成。

請求版本

其實回應速度也會跟Http版本有關,以下提供Http1.1/2/3之間的比較

常見 HTTP 方法 (Method)

這是實現 RESTful API 的基礎。

請求標頭 (Request Headers)

包含額外的元數據,以 Key-Value 形式呈現,是控制請求行為的關鍵,以下我挑幾個重點介紹:

  1. User-Agent:Client端的類型(如OS , 瀏覽器版本)

  2. Accept:Client端接受的回應類型 (例如:application/json, text/html , / )

  3. Content-Type:主體中發送的數據格式 (例如:application/json, application/x-www-form-urlencoded)

  4. Cookie:瀏覽器發送給伺服器的 Cookie 資料,用於身份識別

  5. Authorization:身份驗證資訊 (例如:Bearer Token)

請求主體 (Request Body)

僅在 POSTPUTPATCH 等方法中出現。它攜帶了實際要提交給伺服器處理的數據,例如表單數據、JSON 物件等。

Response

Response就是 server 端接受到request後,結束處理丟回去給client端的回應

基本上跟Request沒差多少,比較不一樣的是:status code

Status Code

這裡就針對常見的status code進行介紹。

但實際上大家都很懶,我還真沒看過真的哪家公司完全照status code的定義回傳的

成功類

  • 200 - 請求成功,回傳資源

  • 201 - created,資源新增成功

  • 204 - No Content ,請求成功,但不回傳資源

重定向

  • 301 - 永久轉址

  • 302 - 暫時轉址

Client的問題

  • 400 - 請求格式有誤

  • 401 - Unauthorized,沒有身份驗證(沒有登入)

  • 403 - Forbidden,沒權限

  • 404 - 找不到資源

  • 413 - 請求過大

  • 429 - 請求頻率過高

Server的問題

  • 500 - Internal Server Error ,程式碼發生未預期的錯誤

  • 503 - Service Unavailable ,伺服器臨時超載或維護

HTTP 的核心特性

無狀態性

HTTP 協定本身不保留任何用戶端的連線狀態或歷史資訊。每個請求和回應都被視為一次獨立的事件。為了維持使用者體驗(例如登入狀態),通常會透過 CookiesSession 等技術來彌補無狀態的限制。

補充:傳統登入做法就是session id存在前端cookie,因為前端請求會攜帶cookie到後端,後端就拿cookie中的session id 找 session就知道是哪個User了。

一次性

在 HTTP/1.0 中,每次請求發送完畢並收到回應後,TCP 連線就會被關閉。雖然 HTTP/1.1 及後續版本引入了持久連線 (Persistent Connection) 來重複使用連線以提高效率,但 HTTP 協定本身仍是基於請求/回應的模式。

補充:實務上如果需要保持連線,多半會使用websocket(一樣是 應用層的協議)

HTTP 與 HTTPS 的差異

差一個S,差在哪?

Https就是Http多一個secure,簡單來說就是比較安全,那安全在哪?

在 HTTP 之下加入了 安全通層協定/傳輸層安全,將所有傳輸的資料進行加密,提供資料機密性和完整性,以及伺服器身份驗證。這對於處理信用卡號碼、密碼等敏感資訊的網站至關重要。HTTPS 預設使用443 port,而 HTTP 預設使用80 port。

相信大家很常聽到Https的S就是SSL,但其實在現代化的網路中SSL已經全面改成TLS了。

從前 (1990s): HTTPS = HTTP + SSL

現在 (實際標準): HTTPS = HTTP + TLS

SSL 3.0 之後就被廢棄,所有現代瀏覽器與伺服器都使用 TLS 1.2 或 TLS 1.3。

ps.前陣子忘記在哪裡看到有人在吵Https的S到底是不是TLS,甚至有人去截圖維基百科說S明明是指Secure,但人家百科後面明明還有寫:常稱為HTTP over TLS、HTTP over SSL或HTTP Secure。

不管S指的是TLS還是Secure,就是因為用TLS加密封包才會比較Secure。

從Rookie到Junior,一個後端成長的30堂課

Part 22 of 31

“從 Rookie 到 Junior:一個後端成長的 30 堂課” 是一套專為後端新手所設計的成長型技術系列文章。內容以實務為導向,逐步拆解後端工程的核心能力,包括程式語言基礎、架構思維、框架運作原理、業務邏輯設計、資料庫操作、以及常見的開發模式。 本系列的目標是協助讀者從零散的學習堆疊,建立成體系的後端知識框架。讀者能夠理解各語言背後不變的工程思維與設計原則。這套內容旨在讓學習者從「會寫程式」進入「能理解系統設計」的階段,逐步具備勝任 Junior Backend Engineer 的能力。

Up next

Module 2 現代化 API 設計與通訊

序 現在,我們要將目光轉向「對外」的窗口。如果說資料庫是內功,那麼 API (Application Programming Interface) 就是招式與門面。一個優秀的後端工程師,必須懂得如何設計出優雅、易用且安全的 API,讓前端、App 或第三方服務能夠順暢地與你的核心系統對話。 在 Module 2中,從網路世界的共通語言——HTTP 協定與 RESTful 風格開始,學習如何讓 API 說一口標準的「國際語言」。 但網路世界充滿了惡意,因此我們也會有部分篇幅聚焦於「安全性」與「防禦...

More from this blog

Lesson 26 : 系統韌性的守護者-限流、熔斷與背壓的設計模式

當這幾個名詞出現後,代表我們進到了一個高併發/大流量的系統了。在這個章節中,我們一起來看看如何透過一些方式來避免高併發導致我們的系統crash掉。 限流(Rate Limiting) 相信大家對這個名詞並不陌生,限流其實就是字面上的含意,限制流量。 限流的目的是保護「接收方」,確保系統不會因為瞬間的高併發請求而癱瘓。 限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全

Mar 26, 20262 min read

Lesson 25: 淺談 單體架構、微服務架構與單/多租戶架構

過去我們討論了 要把程式寫在哪、程式要怎麼拆的題目,接下來我們來看看「如何服務不同客戶」,這些架構反映了軟體開發在擴充性與複雜度之間的權衡。 軟體架構深度解析:從系統拆分到商業規模化 在軟體工程的演進中,架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構:系統如何運行(單體 vs. 分散式) 以及 如何服務客戶(單租戶 vs. 多租戶)。

Mar 26, 20262 min read

Lesson 24: 資料庫擴展術-讀寫分離、複寫機制與快取一致性挑戰

為什麼要讀寫分離? 大多數的 Web 應用都是 「讀多寫少」(例如:看文的人多,發文的人少,Heavy Read System)。當所有的請求都塞給同一台資料庫時,磁碟 I/O 和連線數會成為瓶頸。 Master (主庫): 負責寫入 (Insert/Update/Delete),確保數據一致性。 Slave (從庫): 負責讀取 (Select),可以有多個從庫來分擔讀取壓力。 為什麼讀

Mar 25, 20262 min read

面試經驗談 2025-2026

從2025年3月開始,我陸陸續續參與了從新創到上市櫃公司的Senior - Tech Lead的相關面試,其中有不乏 尊重面試者、展現高度專業的企業(公司),當然也有遇到幾場面試鬼故事,這篇文章主要分享我對於軟體工程師面試的方向分享,以及部分鬼故事,以此警惕自己不要成為這樣的面試官。 AI的洪流,改變了SWE的生態 LLM的發展確確實實的影響到了軟體工程師的生態。 過去受限於算力與資料規模,深度學

Mar 23, 20262 min read

Lesson 23: 系統的緩衝區-Queue 佇列與非同步處理 (Asynchronous)

佇列 佇列的實作工具非常多,舉凡AWS SQS、RabbitMQ、Kafka…等。 佇列的特性,其實是一個非常強大的系統緩衝區,應用層面非常廣。 什麼是佇列? 佇列可以想像成,在既有流程中外,有另一個”水管”,來連接原有的資料流(或邏輯過程),其中 呼叫方將資料 推(Push)到水管中,接受方(監聽) 從水管中將資料拉(Pull)出處理 為什麼佇列是「強大的緩衝區」? 在同步處理中,系統像是一

Mar 23, 20262 min read

Bennett's Tech Blog | 後端架構、系統設計

32 posts

來自台灣的軟體工程師,相信軟體可以改變世界