圖解 Spring：HTTP 請求的處理流程與機制【1】

2003 年， 到中興通訊做研究生實習，Spring 就是那年誕生的，2004 年 3 月釋出了 1.0 版本，到現在已經超過 15 年了。從單體式分層架構到雲原生微服務架構，它穩坐在 JAVA 應用框架的頭把交椅上從未被撼動，它給我們帶來了巨大的價值，不僅可以降低開發難度，同時還可以提升開發效率。

在 Spring Boot / Spring Cloud 面世之前，它已經演進了 5 個大版本和無數小版本，功能和生態都變得越來越豐富。但對初涉 Spring 的小夥伴們來說，這就不太公平了，不像 可以伴著它慢慢成長，現在這套技術棧已經很龐大了，短時間內吃透這個巨無霸，有沒有捷徑可走呢？

有，就像當年 DOS 作業系統一張軟盤就裝下了，總共才幾 MB，現在動不動就幾十上百 GB，但作業系統核心是很小的，其原理機制就是教科書上那些，一生二、二生三、三生萬物，唯有掌握這些穩定不變的“一二三”，即核心原理機制（例如：IOC \ AOP \ ORM 等），那我們的學習就可以達到事半功倍了。

就像我們購買了毛坯房，入住前必須裝修一番，其中水、電、氣、網等管路的佈線必須先行，不同管路有不同的走法，有的走地板，有的走牆面，等管路都鋪設妥當了才能鋪地磚、吊天花、刷牆貼紙等。作為業主，如果你不知道這些管路的走線，當出現停電、斷網或漏水等問題時，你壓根不知道怎麼分析、定位和修復。

在公司內 經常接到的問題求助，由於小夥伴不知道這些原理機制，蠻簡單的問題分析定位了好些天還沒頭緒。如果循著原理機制，那我們就可以做到遊刃有餘了。其實，這些底層原理機制並不算複雜，僅僅是我們不知道，或者缺乏好資料，老兵哥準備透過圖解的方式把這些原理機制剖析給大傢伙聽。

本系列文章將聚焦 Spring 處理 HTTP 請求的全流程，幫助大家瞭解掌握 Spring 這座摩天大樓裡面的管路佈線，讓學習變得事半功倍，讓使用變得遊刃有餘，具體將包含下述幾個方面內容：

• HTTP 請求處理全流程，包括瀏覽器、Web 伺服器、應用 Spring 等；
• Web 伺服器與應用 Spring 之間的互動介面、協作機制和配置規則等；
• Spring 處理 HTTP 請求的機制，包括 Dispatcher、Controller、View、Model、Service、DAO 等；
• 不同應用架構場景下 HTTP 請求處理的子流程，包括 JSP、前後端分離等；
• HTTP 請求處理相關配置檔案說明，包括 Web、Bootstrap、Spring MVC、Application Context 等；
• HTTP 請求處理常見問題說明等。

適合讀者：開發、測試、架構等

1. HTTP 請求處理流程概覽

由計算機構建起來的網路空間是一個虛擬的世界，它是我們人類腦力的延伸。雖然虛擬世界既抽象又幻化，但它終究是根據我們建設物理世界的經驗構建出來的。混跡 IT 江湖的時間也不短了， 找到了一種理解虛擬世界的方法，就是在現實世界找到原型，原型更加形象生動，我們對它也非常熟悉，透過原型就能更加準確地瞭解計算機技術背後的機制原理。

客戶端（或瀏覽器）、Web 容器、Web 應用、Spring 框架等處理 HTTP 請求的過程，我們可以用現實世界中的什麼原型來跟它對應呢？我們可以將其類比為物流快遞投送檔案包裹的過程。

計算機網路就像現實世界的交通路網，四通八達的網路主要職責就是承載貨物的運輸。在 OSI 七層或 TCP/IP 四層網路協議模型中，HTTP （Hyper Text Transfer Protocol）和 FTP（File Transfer Protocol）、SMTP（Simple Mail Transfer Protocol）、POP3（Post Office Protocol 3）、IMAP4（Internet Mail Access Protocol）等協議都隸屬於應用層協議，這些協議就好比運送不同型別貨物的物流快遞公司，FTP 這套體系是專門運送檔案的，SMTP、POP3、IMAP4 是專門投遞郵件的，而 HTTP 協議最初是用於超文字的。

但隨著全球資訊網（WWW）的蓬勃發展，HTTP 這套協議體系得到了最為廣泛的發展，它的設計非常優良，帶來了靈活性、擴充套件性和易用性，可以承載各種型別資訊的傳輸，就像現在網際網路物流公司越做越大，可以覆蓋越來越多的業務了。

HTTP 請求或應答就像一個郵包，這個郵包分成報文頭和報文體，其中報文體就是被承運的資訊載荷，而報文頭就像我們平時郵寄東西時填寫的快遞單，包括收（發）件人地址、服務等級要求、郵寄物品描述等。

針對本文的主題，我們就只重點剖析一下收件人地址。一個符合 RESTful 風格的服務介面 API 的 HTTP URL 如下所示：

http:// {ip} : {port} / {context-path} / {service-name} / {method-name}

舉個具體的例子，就像我們要往下面這個地址投遞一份檔案來完成使用者註冊：

上述格式是供我們閱讀的，最終這些資訊要填寫至 HTTP 報文當中，真實效果如下所示：

POST /spring-demo/user/register HTTP/1.1 Accept: application/json Accept-Language: zh-cn User-Agent: Mozilla/5.0 Host: 201.187.10.21:8080 Content-Length: 112 Connection: Keep-Alive Cache-Control: no-cache Cookie: JSESSIONID=12DII6898EFY998APBE17B

接下來，我們一起逐段解析一下這個 HTTP URL，看看每段資訊存在的意義：

• ip：IP 地址資訊，用於特定網路中不同計算機的定址。
• port：埠資訊，用於同一臺計算機上不同 Web 容器的定址，一臺計算機可以執行多個 Web 容器例項。
• context-path：上下文路徑，用於同個 Web 容器內不同應用的定址，一個 Web 容器例項可以部署多款應用。
• service-name：服務名稱，用於同個應用內部不同服務的定址，一個應用內部通常會有多個服務。
• method-name：方法名稱，用於同個服務內部不同方法的定址，一個服務通常都會包含多個方法。

上述收件人地址是由客戶端（或瀏覽器）填寫的，HTTP 傳輸體系將根據收件人地址資訊對郵包進行投送，基於 IP 地址或域名資訊找到了特定的計算機，而計算機會根據埠資訊將郵包交給具體的 Web 容器例項。

接下來，Web 容器會接管郵包投送任務，它將根據上下文路徑找到具體的應用。如果當前這款應用是採用 Spring 框架構建的，那麼Spring 將接管郵包投送任務，它將根據服務名稱和方法名稱找到真正可以處理郵包當中載荷資訊的服務方法。

該服務方法會及時處理郵包內的資訊，待處理完成後再將結果資訊裝進新的郵包快，遞迴客戶端（或瀏覽器）。 如下圖所示，這就是 HTTP 請求穿越網路、計算機、Web 容器、Web 應用、Spring 框架的過程示意。

本文主要價值是幫助大家梳理出端到端的全流程框架，也就是我們常說的全域性視角或者上帝視角。有了這個框架之後，我們可以根據自己的需要按圖索驥找相關節點的資料來研究學習，不至於陷入細節找不到方向。

當然，考慮到我們每個人的工作學習情況不同，平時遇到的問題也不同，本文內容無法覆蓋所有人遇到的問題，歡迎大家留言提問。如果想收穫更多職業規劃、軟體開發、公眾表達、自由職業相關的經驗，請點選訪問「 」！