『壹』 WEB請求處理之瀏覽器響應
當我們使用瀏覽器進行瀏覽操作的時候，會產生一系列的數據請求。現在瀏覽器和伺服器之間的數據交互是基於B/S架構的，而這種架構是建立在HTTP請求的基礎上的，當我們在瀏覽器的地址欄中輸入一個網頁的地址後，會觸發一些列事件，如下圖所示:
以上就是我們訪問網頁時會觸發的一系列事件,也是web請求處理的基本流程，接下來對幾個概念詳細介紹.
TCP協議是OSI七層協議中傳輸層的一項協議,它是一種面向連接的可靠交付的數據傳輸協議，和UDP用戶數據報協議不同的是，它需要建立連接，並且需要無差錯和可靠地交付數據。通過TCP建立連接，需要經過三次握手，關閉TCP連接需要四次揮手。
OSI七層模型中TCP處於的層級位置如圖所示
TCP建立連接是為了可靠地傳輸數據，因此建立過程比較復雜，以確保可靠地傳輸數據。具體流程如下圖所示:
TCP四次揮手
當數據傳輸成功後需要關閉連接，這就是TCP四次揮手。四次揮手比握手還要復雜，具體流程如下圖所示:
在這個過程中，為什麼會涉及到四次揮手呢，這是因為在客戶端發送主動關閉連接請求時，伺服器端收到關閉請求並返回確認收到請求報文，但是伺服器不會立即關閉，因為在這個時間段內可能還會有數據傳送，伺服器端會繼續傳送數據給客戶端，當沒有數據傳送時，伺服器端會主動發送報文給客戶端請求關閉,等待客戶端返回確認時伺服器端就進入了close狀態。
從上面的OSI七層模型中我們可以看到HTTP處於七層協議中的應用層，也就是最接近用戶的一層。它主要是處理WEB數據請求，它是無狀態無連接的協議。無狀態是指上一次傳送的數據是沒有存儲下來的，下一次操作獲取不到上次的數據。無連接是指需要請求數據時才會建立連接，否則處於無連接狀態。在WtEB請求處理過程中，我們主要是關心HTTP請求頭和響應頭還有就是狀態碼.
下面是使用FIDDLER抓包工具抓取的請求包
CONNECT www..com:443 HTTP/1.1
Host: www..com:443
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36
人們習慣記憶域名，但機器間互相只認IP地址，域名與IP地址之間是多對多的關系，一個ip地址不一定只對應一個域名，且一個域名可以對應多個ip地址，它們之間的轉換工作稱為域名解析，域名解析需要由專門的域名解析伺服器來完成，整個過程是自動進行的。
由於DNS域名解析有些復雜，本文章就不就過多的講解。
總結：以上就是web請求處理中瀏覽器響應的相關知識，由於涉及到的 知識太多因此沒喲很詳細的將解，只將解了部分的重要內容，待到以後學習加深，進一步完善。
『貳』 Web響應時間很長
錯別字太多
Web響應時間很長無非幾個方面的問題：
1.主機硬體低配而裝了高配操作系統，比如win7,小馬拉大車嘍
一般屬這種情況的話，運行大多軟體都會慢，如果運行別的軟體不慢，僅是web慢，skip這一條，看第三條.（新買的東芝筆記本電腦，估計配置應該還不錯吧，可以看下一條了）
2.主機內軟體安裝的不合適，比如中病毒了、或者是安了幾套殺毒軟體（同時安裝)等等原因，系統CPU被這些軟體過度佔用，如果這樣，殺毒、卸載不必要的軟體。
比如360，就建議停用一下，看看是否響應速度會變快。
3.如果前兩條都不符合，則問題集中在web方面，
3.1所訪問的具體某個網站慢，判斷很容易，看看訪問別的web速度快不快，如果有快有慢，那問題可以結題了。如果都慢，請看下一條。
3.2檢查下DNS設置的是否合適，建議選用與你上網線路較近的DNS
『叄』 http請求和響應
當瀏覽器向Web伺服器發出請求時，它向伺服器傳遞了一個數據塊，也就是請求信息，HTTP請求信息由3部分組成：
l 請求方法URI協議/版本
l 請求頭(Request Header)
l 請求正文
下面是一個HTTP請求的例子：
GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate
username=jinqiao&password=1234
（1）請求方法URI協議/版本
請求的第一行是「方法URL議/版本」：GET/sample.jsp HTTP/1.1
以上代碼中「GET」代表請求方法，「/sample.jsp」表示URI，「HTTP/1.1代表協議和協議的版本。
根據HTTP標准，HTTP請求可以使用多種請求方法。例如：HTTP1.1目前支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。
GET 請求獲取由Request-URI所標識的資源。
POST 在Request-URI所標識的資源後附加新的數據。
HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭。
OPTIONS 請求查詢伺服器的性能，或查詢與資源相關的選項和需求。
PUT 請求伺服器存儲一個資源，並用Request-URI作為其標識。
DELETE 請求伺服器刪除由Request-URI所標識的資源。
TRACE 請求伺服器回送收到的請求信息，主要用語測試或診斷。
在Internet應用中，最常用的方法是GET和POST。
URI完整地指定了要訪問的網路資源，通常只要給出相對於伺服器的根目錄的相對目錄即可，因此總是以「/」開頭，最後，協議版本聲明了通信過程中使用HTTP的版本。
『肆』 如何定位Web應用響應慢原因
運用聽雲Server解決Web應用過程響應慢，並且定位到具體代碼，我們首先登陸聽雲Server控制台，點擊需要查看的應用，進入Web應用過程模塊。（聽雲Server中Web應用過程指：應用程序中處理一次獨立的Web訪問請求的過程，完整的web應用過程是從應用程序收到請求到響應的整個過程）
Web應用過程功能模塊是將當前應用以Web應用過程的維度來展示詳細的應用性能數據，包括以下幾個功能：
「Web應用過程一覽」列出當前應用所有的Web應用過程，並且可以按照耗時百分比、響應時間、吞吐率、Apdex、錯誤率進行排序。
「TOP5最耗時Web應用過程堆疊圖」展示了耗時百分比最大的前5個Web應用過程其牆鍾時間比在選定時間內的變化趨勢。（牆鍾時間比指的是Web應用過程在圖表橫坐標粒時間度下的總耗時時間/圖表橫坐標粒度時間）
「Web應用過程響應時間與吞吐率圖」展示了應用的平均響應時間和每分鍾請求次數在選定時間內的變化趨勢。當請求的響應時間大於設定的閾值時會被顯示在慢應用追蹤列表中。（可在設置中對Web過程跟蹤閾值進行設定，例如設置為500毫秒，那麼所有響應時間大於500毫秒的請求都會被顯示在慢應用過程追蹤列表中，具體值根據自己的需求設置即可）
對於Web應用過程響應慢，我們選擇按照「響應時間」進行排序，響應時間由長到短排列，選擇時間較長的優先進行解決。
點擊該Web應用過程進行數據鑽取，查看其詳細的性能分解。可以看到Web應用過程性能分解堆疊圖，顯示了這個Web應用過程中各個組件在選定時間內的平均響應時間的變化趨勢。
「性能分解表格」展示了其中各個組件的詳細性能信息，包括的信息有代碼段、性能分類、耗時百分比、調用次數、平均響應時間，排列順序是按照平均響應時間由長到短進行排序的。
「響應時間和吞吐率圖」展示了該Web應用過程在選定時間內平均響應時間和每分鍾請求次數的變化趨勢。
「慢應用追蹤列表」顯示了該應用下響應時間大於設定閾值的請求，同樣還是按照響應時間由長到短進行排序。
點擊其中響應時間較長的請求進行慢應用追蹤，跳轉至應用過程慢追蹤頁面。
摘要中可以看到各個組件的響應耗時百分比圖，下面還列出了各個最慢組件詳細的調用次數、持續時間、響應耗時佔比數據。
接下來重點查看追蹤詳情，可以看到各個代碼段的持續時間、時間佔比和時間偏移量，其中持續時間長時間佔比高的就是響應時間長的代碼段，則需要對該代碼段進行重點的優化和修改，從而解決Web應用過程響應慢的問題。
後面的相關SQL展示了其中的SQL操作以及其調用次數和總耗時。
拓補圖展示了相關的調用關系方便更加全面的分析問題，特別說明的是只有發生跨應用調用的應用過程慢追蹤才會展示拓補圖。