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

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

在 Spring Boot / Spring Cloud 面世以前，它已經演進了 5 個大版本和無數小版本，功能和生態都變得愈來愈豐富。但對初涉 Spring 的小夥伴們來講，這就不太公平了，不像老兵哥能夠伴着它慢慢成長，如今這套技術棧已經很龐大了，短期內吃透這個巨無霸，有沒有捷徑可走呢？有，就像當年 DOS 操做系統一張軟盤就裝下了，總共才幾 MB，如今動不動就幾十上百 GB，但操做系統內核是很小的，其原理機制就是教科書上那些，一輩子2、二生3、三生萬物，惟有掌握這些穩定不變的「一二三」，即核心原理機制（例如：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、POP三、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】