為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

#0 系列目錄#

• WEB請求處理
• WEB請求處理一：瀏覽器請求發(fā)起處理
• WEB請求處理二：Nginx請求反向代理
• WEB請求處理三：Servlet容器請求處理
• WEB請求處理四：Tomcat配置實(shí)踐
• WEB請求處理五：MVC框架請求處理

#1 HTTP報(bào)文# HTTP報(bào)文是面向文本的，報(bào)文中的每一個(gè)字段都是一些ASCII碼串，各個(gè)字段的長度是不確定的。HTTP有兩類報(bào)文：請求報(bào)文和響應(yīng)報(bào)文。 ##1.1 HTTP請求報(bào)文解剖## ###1.1.1 請求報(bào)文結(jié)構(gòu)### HTTP請求報(bào)文由3部分組成（請求行+請求頭+請求體）：

下面是一個(gè)實(shí)際的請求報(bào)文：

①為請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當(dāng)前的大多數(shù)瀏覽器只支持GET和POST，Spring 3.0提供了一個(gè)HiddenHttpMethodFilter，允許你通過“_method”的表單參數(shù)指定這些特殊的HTTP方法（實(shí)際上還是通過POST提交表單）。服務(wù)端配置了HiddenHttpMethodFilter后，Spring會(huì)根據(jù)_method參數(shù)指定的值模擬出相應(yīng)的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進(jìn)行映射了。?

GET：最常見的一種請求方式，服務(wù)器將URL定位的資源放在響應(yīng)報(bào)文的數(shù)據(jù)部分，回送給客戶端。地址中”?”之后的部分就是通過GET發(fā)送的請求數(shù)據(jù)，各個(gè)數(shù)據(jù)之間用”&”符號(hào)隔開。顯然，這種方式不適合傳送私密數(shù)據(jù)。另外，由于不同的瀏覽器對地址的字符限制也有所不同，一般最多只能識(shí)別1024個(gè)字符，所以如果需要傳送大量數(shù)據(jù)的時(shí)候，也不適合使用GET方式。

POST：對于上面提到的不適合使用GET方式的情況，可以考慮使用POST方式，因?yàn)槭褂肞OST方法可以允許客戶端給服務(wù)器提供信息較多。POST方法將請求參數(shù)封裝在HTTP請求數(shù)據(jù)中，以名稱/值的形式出現(xiàn)，可以傳輸大量數(shù)據(jù)，這樣POST方式對傳送的數(shù)據(jù)大小沒有限制，而且也不會(huì)顯示在URL中。

關(guān)于HTTP請求GET和POST的區(qū)別：

GET提交：請求的數(shù)據(jù)會(huì)附在URL之后（就是把數(shù)據(jù)放置在HTTP協(xié)議頭＜request-line＞中），以?分割URL和傳輸數(shù)據(jù)，多個(gè)參數(shù)用&連接。如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送，如果是空格，轉(zhuǎn)換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號(hào)以16進(jìn)制表示的ASCII。 ? POST提交：把提交的數(shù)據(jù)放置在是HTTP的報(bào)文體＜request-body＞中。 因此，GET提交的數(shù)據(jù)會(huì)在地址欄中顯示出來，而POST提交，地址欄不會(huì)改變。

傳輸數(shù)據(jù)的大小： 首先聲明，HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進(jìn)行限制。 而在實(shí)際開發(fā)中存在的限制主要有： ?GET：特定瀏覽器和服務(wù)器對URL長度有限制，例如IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持。 因此對于GET提交時(shí)，傳輸數(shù)據(jù)就會(huì)受到URL長度的限制。 POST：由于不是通過URL傳值，理論上數(shù)據(jù)不受限。但實(shí)際各個(gè)WEB服務(wù)器會(huì)規(guī)定對post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。 ?3. 安全性： POST的安全性要比GET的安全性高。注意：這里所說的安全性和上面GET提到的“安全”不是同個(gè)概念。上面“安全”的含義僅僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的Security的含義，比如：通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)?1)登錄頁面有可能被瀏覽器緩存，(2)其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號(hào)和密碼了，

②為請求對應(yīng)的URL地址，它和報(bào)文頭的Host屬性組成完整的請求URL。

③為協(xié)議名稱及版本號(hào)。

④為HTTP的報(bào)文頭，報(bào)文頭包含若干個(gè)屬性，格式為“屬性名:屬性值”，服務(wù)端據(jù)此獲取客戶端的信息。

⑤為報(bào)文體，它將一個(gè)頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個(gè)格式化串，它承載多個(gè)請求參數(shù)的數(shù)據(jù)。不但報(bào)文體可以傳遞請求參數(shù)，請求URL也可以通過類似于“/chapter15/user.html?param1=value1&param2=value2”的方式傳遞請求參數(shù)。

**對照上面的請求報(bào)文，我們把它進(jìn)一步分解，你可以看到一幅更詳細(xì)的結(jié)構(gòu)圖：?**

###1.1.2 HTTP請求報(bào)文頭屬性### 報(bào)文頭屬性是什么東西呢？我們不妨以一個(gè)小故事來說明吧。

快到中午了，張三豐不想去食堂吃飯，于是打電話叫外賣：老板，我要一份[魚香肉絲]，要12：30之前給我送過來哦，我在江湖湖公司研發(fā)部，叫張三豐。

這里，你要[魚香肉絲]相當(dāng)于HTTP報(bào)文體，而“12：30之前送過來”，你叫“張三豐”等信息就相當(dāng)于HTTP的報(bào)文頭。它們是一些附屬信息，幫忙你和飯店老板順利完成這次交易。?

請求HTTP報(bào)文和響應(yīng)HTTP報(bào)文都擁有若干個(gè)報(bào)文關(guān)屬性，它們是為協(xié)助客戶端及服務(wù)端交易的一些附屬信息。

Accept：

請求報(bào)文可通過一個(gè)“Accept”報(bào)文頭屬性告訴服務(wù)端 客戶端接受什么類型的響應(yīng)。

如下報(bào)文頭相當(dāng)于告訴服務(wù)端，俺客戶端能夠接受的響應(yīng)類型僅為純文本數(shù)據(jù)啊，你丫別發(fā)其它什么圖片啊，視頻啊過來，那樣我會(huì)歇菜的~~~：?

Accept:text/plain

Accept屬性的值可以為一個(gè)或多個(gè)MIME類型的值，關(guān)于MIME類型，大家請參考：http://en.wikipedia.org/wiki/MIME_type

Cookie：

客戶端的Cookie就是通過這個(gè)報(bào)文頭屬性傳給服務(wù)端的哦！如下所示：

Cookie:?$Version=1;?Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C

服務(wù)端是怎么知道客戶端的多個(gè)請求是隸屬于一個(gè)Session呢？注意到后臺(tái)的那個(gè)jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原來就是通過HTTP請求報(bào)文頭的Cookie屬性的jsessionid的值關(guān)聯(lián)起來的！（當(dāng)然也可以通過重寫URL的方式將會(huì)話ID附帶在每個(gè)URL的后面哦）。

Referer：

表示這個(gè)請求是從哪個(gè)URL過來的，假如你通過google搜索出一個(gè)商家的廣告頁面，你對這個(gè)廣告頁面感興趣，鼠標(biāo)一點(diǎn)發(fā)送一個(gè)請求報(bào)文到商家的網(wǎng)站，這個(gè)請求報(bào)文的Referer報(bào)文頭屬性值就是http://www.google.com。?

唐僧到了西天. 如來問：儂是不是從東土大唐來啊？ 唐僧：厲害！你咋知道的！ 如來：呵呵，我偷看了你的Referer...

很多貌似神奇的網(wǎng)頁監(jiān)控軟件（如著名的?我要啦），只要在你的網(wǎng)頁上放上一段JavaScript，就可以幫你監(jiān)控流量，全國訪問客戶的分布情況等報(bào)表和圖表，其原理就是通過這個(gè)Referer及其它一些HTTP報(bào)文頭工作的。

Cache-Control：

對緩存進(jìn)行控制，如一個(gè)請求希望響應(yīng)返回的內(nèi)容在客戶端要被緩存一年，或不希望被緩存就可以通過這個(gè)報(bào)文頭達(dá)到目的。?

如以下設(shè)置，相當(dāng)于讓服務(wù)端將對應(yīng)請求返回的響應(yīng)內(nèi)容不要在客戶端緩存：

Cache-Control:?no-cache ```?5. **User-Agent：**產(chǎn)生請求的瀏覽器類型。6. **Host：**請求的主機(jī)名，允許多個(gè)域名同處一個(gè)IP地址，即虛擬主機(jī)。###1.1.3 如何訪問請求報(bào)文頭### 由于請求報(bào)文頭是客戶端發(fā)過來的，服務(wù)端當(dāng)然只能讀取了，以下是HttpServletRequest一些用于讀取請求報(bào)文頭的API：

// 獲取請求報(bào)文中的屬性名稱?? java.util.Enumeration<java.lang.String>???getHeaderNames();?? ?? // 獲取指定名稱的報(bào)文頭屬性的值?? java.lang.String?getHeader(java.lang.String?name);

由于一些請求報(bào)文頭屬性“太著名”了，因此HttpServletRequest為它們提供了VIP的API：?

// 獲取報(bào)文頭中的Cookie（讀取Cookie的報(bào)文頭屬性）? Cookie[]???getCookies()?;?? ?? // 獲取客戶端本地化信息（讀取?Accept-Language?的報(bào)文頭屬性）?? java.util.Locale????getLocale()??? ?? // 獲取請求報(bào)文體的長度（讀取Content-Length的報(bào)文頭屬性）?? int?getContentLength();??

// 獲取請求所關(guān)聯(lián)的HttpSession，其內(nèi)部的機(jī)理是通過讀取請求報(bào)文頭中Cookie屬性的JSESSIONID的值， // 在服務(wù)端的一個(gè)會(huì)話Map中，根據(jù)這個(gè)JSESSIONID獲取對應(yīng)的HttpSession的對象 HttpSession?getSession()

##1.2 HTTP響應(yīng)報(bào)文解剖## ###1.2.1 響應(yīng)報(bào)文結(jié)構(gòu)### HTTP的響應(yīng)報(bào)文也由三部分組成（**響應(yīng)行+響應(yīng)頭+響應(yīng)體**）：?以下是一個(gè)實(shí)際的HTTP響應(yīng)報(bào)文：?①報(bào)文協(xié)議及版本；?②狀態(tài)碼及狀態(tài)描述；?③響應(yīng)報(bào)文頭，也是由多個(gè)屬性組成；?④響應(yīng)報(bào)文體，即我們真正要的“干貨”；###1.2.2 響應(yīng)狀態(tài)碼### 和請求報(bào)文相比，響應(yīng)報(bào)文多了一個(gè)“響應(yīng)狀態(tài)碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結(jié)果。**HTTP的響應(yīng)狀態(tài)碼由5段組成：** > 1xx 消息，**一般是告訴客戶端，請求已經(jīng)收到了，正在處理**，別急...。 > > 2xx **處理成功**，一般表示：請求收悉、我明白你要的、請求已受理、已經(jīng)處理完成等信息。 > > 3xx **重定向到其它地方**。它讓客戶端再發(fā)起一個(gè)請求以完成整個(gè)處理。 > > 4xx **處理發(fā)生錯(cuò)誤，責(zé)任在客戶端**，如客戶端的請求一個(gè)不存在的資源，客戶端未被授權(quán)，禁止訪問等。 > > 5xx **處理發(fā)生錯(cuò)誤，責(zé)任在服務(wù)端**，如服務(wù)端拋出異常，路由出錯(cuò)，HTTP版本不支持等。**以下是幾個(gè)常見的狀態(tài)碼：** > **200 OK** 你最希望看到的，即處理成功！ > > **301 永久重定向** Location響應(yīng)首部的值仍為當(dāng)前URL，因此為隱藏重定向; > > **302 臨時(shí)重定向** 顯式重定向, Location響應(yīng)首部的值為新的URL。 > > **303 See Other**?redirect到其它的頁面，目標(biāo)的URL通過響應(yīng)報(bào)文頭的Location告訴你。 > > **304 Not Modified** 告訴客戶端，你請求的這個(gè)資源至你上次取得后，并沒有更改，你直接用你本地的緩存吧，我很忙哦，你能不能少來煩我啊！ > > **400 Bad Request** 客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解。 > > **401 Unauthorized** 請求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用。 > > **403 Forbidden** 服務(wù)器收到請求，但是拒絕提供服務(wù)。 > > **404 Not Found** 你最不希望看到的，即找不到頁面。如你在google上找到一個(gè)頁面，點(diǎn)擊這個(gè)鏈接返回404，表示這個(gè)頁面已經(jīng)被網(wǎng)站刪除了，google那邊的記錄只是美好的回憶。 > > **500 Internal Server Error** 看到這個(gè)錯(cuò)誤，你就應(yīng)該查查服務(wù)端的日志了，肯定拋出了一堆異常，別睡了，起來改BUG去吧！ > > **503 Server Unavailable** 服務(wù)器當(dāng)前不能處理客戶端的請求，一段時(shí)間后可能恢復(fù)正常，舉個(gè)例子：HTTP/1.1 200 OK（CRLF）。其它的狀態(tài)碼參見：[http://en.wikipedia.org/wiki/List_of_HTTP_status_codes](http://en.wikipedia.org/wiki/List_of_HTTP_status_codes)有些響應(yīng)碼，Web應(yīng)用服務(wù)器會(huì)自動(dòng)給生成。你可以通過HttpServletResponse的API設(shè)置狀態(tài)碼：?

// 設(shè)置狀態(tài)碼，狀態(tài)碼在HttpServletResponse中通過一系列的常量預(yù)定義了，如SC_ACCEPTED，SC_OK?? void?setStatus(int?sc)

###1.2.3 HTTP響應(yīng)報(bào)文頭屬性### **Cache-Control：**響應(yīng)輸出到客戶端后，服務(wù)端通過該報(bào)文頭屬告訴客戶端如何控制響應(yīng)內(nèi)容的緩存。下面的設(shè)置讓客戶端對響應(yīng)內(nèi)容緩存3600秒，也即在3600秒內(nèi)，如果客戶再次訪問該資源，直接從客戶端的緩存中返回內(nèi)容給客戶，不要再從服務(wù)端獲取（當(dāng)然，這個(gè)功能是靠客戶端實(shí)現(xiàn)的，服務(wù)端只是通過這個(gè)屬性提示客戶端“應(yīng)該這么做”，做不做，還是決定于客戶端，如果是自己宣稱支持HTTP的客戶端，則就應(yīng)該這樣實(shí)現(xiàn)）。?

Cache-Control:?max-age=3600

**ETag：**一個(gè)代表響應(yīng)服務(wù)端資源（如頁面）版本的報(bào)文頭屬性，如果某個(gè)服務(wù)端資源發(fā)生變化了，這個(gè)ETag就會(huì)相應(yīng)發(fā)生變化。它是Cache-Control的有益補(bǔ)充，可以讓客戶端“更智能”地處理什么時(shí)候要從服務(wù)端取資源，什么時(shí)候可以直接從緩存中返回響應(yīng)。?關(guān)于ETag的說明，你可以參見：[http://en.wikipedia.org/wiki/HTTP_ETag](http://en.wikipedia.org/wiki/HTTP_ETag)。?Spring 3.0還專門為此提供了一個(gè)`org.springframework.web.filter.ShallowEtagHeaderFilter`（實(shí)現(xiàn)原理很簡單，對JSP輸出的內(nèi)容MD5，這樣內(nèi)容有變化ETag就相應(yīng)變化了），用于生成響應(yīng)的ETag，**因?yàn)檫@東東確實(shí)可以幫助減少請求和響應(yīng)的交互**。下面是一個(gè)ETag：

ETag:?"737060cd8c284d8af7ad3082f209582d"

**Location：**在JSP中讓頁面Redirect到一個(gè)某個(gè)A頁面中，其實(shí)是讓客戶端再發(fā)一個(gè)請求到A頁面，這個(gè)需要Redirect到的A頁面的URL，其實(shí)就是通過響應(yīng)報(bào)文頭的Location屬性告知客戶端的，如下的報(bào)文頭屬性，將使客戶端redirect到iteye的首頁中。

Location:?http://www.iteye.com

**Set-Cookie：**服務(wù)端可以設(shè)置客戶端的Cookie，其原理就是通過這個(gè)響應(yīng)報(bào)文頭屬性實(shí)現(xiàn)的。

Set-Cookie:?UserID=JohnDoe;?Max-Age=3600;?Version=1

Connection 使用keep-alive特性； Content-Encoding 使用gzip方式對資源壓縮； Content-type MIME類型為html類型，字符集是 UTF-8； Date 響應(yīng)的日期； Server 使用的WEB服務(wù)器； Transfer-Encoding:chunked 分塊傳輸編碼 是http中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用（通常是網(wǎng)頁瀏覽器）的數(shù)據(jù)可以分成多個(gè)部分，分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供；

更多其它的HTTP響應(yīng)頭報(bào)文，參見：[http://en.wikipedia.org/wiki/List_of_HTTP_header_fields](http://en.wikipedia.org/wiki/List_of_HTTP_header_fields)###1.2.4 如何寫HTTP請求報(bào)文頭### 在服務(wù)端可以通過HttpServletResponse的API寫響應(yīng)報(bào)文頭的屬性：?

// 添加一個(gè)響應(yīng)報(bào)文頭屬性?? void?setHeader(String?name,?String?value)?

像Cookie，Location這些響應(yīng)都是有福之人，HttpServletResponse為它們都提供了VIP版的API：?

// 添加Cookie報(bào)文頭屬性?? void?addCookie(Cookie?cookie)??? ?? // 不但會(huì)設(shè)置Location的響應(yīng)報(bào)文頭，還會(huì)生成303的狀態(tài)碼呢，兩者天仙配呢?? void?sendRedirect(String?location)???

#2 HTTP傳輸處理# **在一個(gè)網(wǎng)絡(luò)中。傳輸數(shù)據(jù)需要面臨三個(gè)問題：**> 1. 客戶端**如何知道所請求內(nèi)容的位置**？ > 2. 當(dāng)客戶端知道所請求內(nèi)容的位置后，**如何獲取所請求的內(nèi)容**？ > 3. 所請求內(nèi)容以**何種形式組織以便被客戶端所識(shí)別**？對于WEB來說，回答上面三種問題分別采用三種不同的技術(shù)，分別為：**統(tǒng)一資源定位符(URI)，超文本傳輸協(xié)議(HTTP)和超文本標(biāo)記語言(HTML)**。對于大多數(shù)WEB開發(fā)人員來說URI和HTML都是非常的熟悉。而HTTP協(xié)議在很多WEB技術(shù)中都被封裝的過多使得HTTP反而最不被熟悉。HTTP作為一種傳輸協(xié)議，也是像HTML一樣隨著時(shí)間不斷演進(jìn)的，目前流行的HTTP1.1是HTTP協(xié)議的第三個(gè)版本。在Internet中所有的傳輸都是通過TCP/IP進(jìn)行的。**HTTP協(xié)議作為TCP/IP模型中應(yīng)用層的協(xié)議也不例外**。HTTP在網(wǎng)絡(luò)中的層次如圖所示：可以看出，**HTTP是基于傳輸層TCP協(xié)議的**，而TCP是一個(gè)端到端的面向連接的協(xié)議。**所謂的端到端可以理解為進(jìn)程到進(jìn)程之間的通信**。所以HTTP在開始傳輸之前，首先需要建立TCP連接，而TCP連接的過程需要所謂的“三次握手”。概念如圖所示。在TCP三次握手之后，建立了TCP連接，此時(shí)HTTP就可以進(jìn)行傳輸了。一個(gè)重要的概念是面向連接，**即HTTP在傳輸完成之前并不斷開TCP連接**。在HTTP1.1中(通過Connection頭設(shè)置)這是默認(rèn)行為。所謂的HTTP傳輸完成，我們通過一個(gè)具體的例子來看。比如訪問我的博客，使用Fiddler來截取對應(yīng)的請求和響應(yīng)。如圖所示：可以看出，雖然僅僅訪問了我的博客，但所獲取的不僅僅是一個(gè)HTML，而是瀏覽器對HTML解析的過程中，如果發(fā)現(xiàn)需要獲取的內(nèi)容，會(huì)再次發(fā)起HTTP請求去服務(wù)器獲取，比如上圖中的那個(gè)common2.css。**這上面19個(gè)HTTP請求，只依靠一個(gè)TCP連接就夠了，這就是所謂的持久連接。**也是所謂的一次HTTP請求完成。#3 瀏覽器解析html代碼，并請求html代碼中的資源# 瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時(shí)，就向服務(wù)器端去請求下載（會(huì)使用多線程下載，每個(gè)瀏覽器的線程數(shù)不一樣），**這個(gè)時(shí)候就用上keep-alive特性了，建立一次HTTP連接，可以請求多個(gè)資源，下載資源的順序就是按照代碼里的順序**，但是由于每個(gè)資源大小不一樣，而瀏覽器又多線程請求請求資源，所以從下圖看出，這里顯示的順序并不一定是代碼里面的順序。瀏覽器在請求靜態(tài)資源時(shí)（在未過期的情況下），向服務(wù)器端發(fā)起一個(gè)http請求（詢問自從上一次修改時(shí)間到現(xiàn)在有沒有對資源進(jìn)行修改），如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒有修改），那么瀏覽器會(huì)直接讀取本地的該資源的緩存文件。**瀏覽器具體渲染頁面，內(nèi)部工作原理，請參考：[《前端必讀：瀏覽器內(nèi)部工作原理》](http://kb.cnblogs.com/page/129756/)**。

轉(zhuǎn)載于:https://my.oschina.net/xianggao/blog/715041

總結(jié)

以上是生活随笔為你收集整理的WEB请求处理六：浏览器HTTP协议漫谈的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。