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

2003 年，老兵哥初到中興開始研究生實習，Spring 就是那年誕生的，2004 年 3 月發布了 1.0 版本，到現在已經超過 15 年了。從單體式分層架構到云原生微服務架構，它穩坐在 JAVA 應用框架的頭把交椅上從未被撼動，它給我們帶來了巨大的價值，不僅可以降低開發難度，同時還可以提升開發效率。但時間這把殺豬刀不僅改變了老兵哥，也同樣沒放過 Spring，我們都變得越來越強大了。

在 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://201.187.10.21:8080/spring-demo/user/register

上述格式是供我們閱讀的，最終這些信息要填寫至 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

name=itlaobingge&password=123456&sex=male&age=30

接下來，我們一起逐段解析一下這個 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 框架的過程示意。

本文主要價值是幫助大家梳理出端到端的全流程框架，也就是我們常說的全局視角或者上帝視角。有了這個框架之后，我們可以根據自己的需要按圖索驥找相關節點的資料來研究學習，不至于陷入細節找不到方向。當然，考慮到我們每個人的工作學習情況不同，平時遇到的問題也不同，本文內容無法覆蓋所有人遇到的問題，歡迎大家留言提問，也歡迎關注我的博客或公號“IT老兵哥”交流互動，我會盡力盡快解答大家提出的問題，謝謝！

本系列其他文章索引如下：

• 圖解 Spring：HTTP 請求的處理流程與機制【2】
• 圖解 Spring：HTTP 請求的處理流程與機制【3】
• 圖解 Spring：HTTP 請求的處理流程與機制【4】
• 圖解 Spring：HTTP 請求的處理流程與機制【5】