準備階段
當你在瀏覽器中輸入網址（例如www.coder.com）並且敲了回車以後， 瀏覽器首先要做的事情就是獲得coder.com的IP地址，具體的做法就是發送一個UDP的包給DNS服務器，DNS服務器會返回coder.com的IP, 這時候瀏覽器通常會把IP地址給緩存起來，這樣下次訪問就會加快。比如Chrome， 你可以通過chrome://net-internals/#dns來查看。
有了服務器的IP， 瀏覽器就要可以發起HTTP請求了，但是HTTP Request/Response必須在TCP這個“虛擬的連接”上來發送和接收。想要建立“虛擬的”TCP連接，TCP郵差需要知道4個東西：（本機IP, 本機端口，服務器IP, 服務器端口），現在只知道了本機IP,服務器IP， 兩個端口怎麼辦？
本機端口很簡單，操作系統可以給瀏覽器隨機分配一個， 服務器端口更簡單，用的是一個“衆所周知”的端口，HTTP服務就是80， 我們直接告訴TCP郵差就行。經過三次握手以後，客戶端和服務器端的TCP連接就建立起來了！ 終於可以發送HTTP請求了。
web服務器
一個HTTP GET請求經過千山萬水，歷經多個路由器的轉發，終於到達服務器端（HTTP數據包可能被下層進行分片傳輸，略去不表）。Web服務器需要着手處理了，它有三種方式來處理：
- 可以用一個線程來處理所有請求，同一時刻只能處理一個，這種結構易於實現，但是這樣會造成嚴重的性能問題。
- 可以爲每個請求分配一個進程/線程，但是當連接太多的時候，服務器端的進程/線程會耗費大量內存資源，進程/線程的切換也會讓CPU不堪重負。
- 複用I/O的方式，很多Web服務器都採用了複用結構，例如通過epoll的方式監視所有的連接，當連接的狀態發生變化（如有數據可讀）， 才用一個進程/線程對那個連接進行處理，處理完以後繼續監視，等待下次狀態變化。 用這種方式可以用少量的進程/線程應對成千上萬的連接請求。
我們使用Nginx這個非常流行的Web服務器來繼續下面的故事。對於HTTP GET請求，Nginx利用epoll的方式給讀取了出來， Nginx接下來要判斷，這是個靜態的請求還是個動態的請求？
- 如果是靜態的請求（HTML文件，Java文件，CSS文件，圖片等），也許自己就能搞定了（當然依賴於Nginx配置，可能轉發到別的緩存服務器去），讀取本機硬盤上的相關文件，直接返回。
- 如果是動態的請求，需要後端服務器（如Tomcat)處理以後才能返回，那就需要向Tomcat轉發，如果後端的Tomcat還不止一個，那就需要按照某種策略選取一個。
Ngnix支持這麼幾種：
- 輪詢：按照次序挨個向後端服務器轉發
- 權重：給每個後端服務器指定一個權重，相當於向後端服務器轉發的機率。
- ip_hash： 根據ip做一個hash操作，然後找個服務器轉發，這樣的話同一個客戶端ip總是會轉發到同一個後端服務器。
- fair：根據後端服務器的響應時間來分配請求，響應時間段的優先分配。
不管用哪種算法，某個後端服務器最終被選中，然後Nginx需要把HTTP Request轉發給後端的Tomcat，並且把Tomcat輸出的HttpResponse再轉發給瀏覽器。由此可見，Nginx在這種場景下，是一個代理人的角色。
應用服務器
Http Request終於來到了Tomcat，這是一個由Java寫的、可以處理Servlet/JSP的容器，我們的代碼就運行在這個容器之中。如同Web服務器一樣， Tomcat也可能爲每個請求分配一個線程去處理，即通常所說的BIO模式（Blocking I/O 模式）。也可能使用I/O多路複用技術，僅僅使用若干線程來處理所有請求，即NIO模式。
不管用哪種方式，Http Request 都會被交給某個Servlet處理，這個Servlet又會把Http Request做轉換，變成框架所使用的參數格式，然後分發給某個Controller(如果你是在用Spring)或者Action(如果你是在Struts)。
剩下的故事就比較簡單了（不，對碼農來說，其實是最複雜的部分），就是執行碼農經常寫的增刪改查邏輯，在這個過程中很有可能和緩存、數據庫等後端組件打交道，最終返回HTTP Response，由於細節依賴業務邏輯，略去不表。
根據我們的例子，這個HTTP Response應該是一個HTML頁面。
歸途
Tomcat很高興地把Http Response發給了Ngnix 。Ngnix也很高興地把Http Response 發給了瀏覽器。
發完以後TCP連接能關閉嗎？如果使用的是HTTP1.1， 這個連接默認是keep-alive，也就是說不能關閉；如果是HTTP1.0，要看看之前的HTTP Request Header中有沒有Connetion:keep-alive，如果有，那也不能關閉。
瀏覽器再次工作
瀏覽器收到了Http Response，從其中讀取了HTML頁面，開始準備顯示這個頁面。但是這個HTML頁面中可能引用了大量其他資源，例如js文件，CSS文件，圖片等，這些資源也位於服務器端，並且可能位於另外一個域名下面，例如static.coder.com。
瀏覽器沒有辦法，只好一個個地下載，從使用DNS獲取IP開始，之前做過的事情還要再來一遍。不同之處在於不會再有應用服務器如Tomcat的介入了。如果需要下載的外部資源太多，瀏覽器會創建多個TCP連接，並行地去下載。
但是同一時間對同一域名下的請求數量也不能太多，要不然服務器訪問量太大，受不了。所以瀏覽器要限制一下， 例如Chrome在Http1.1下只能並行地下載6個資源。
當服務器給瀏覽器發送JS,CSS這些文件時，會告訴瀏覽器這些文件什麼時候過期（使用Cache-Control或者Expire），瀏覽器可以把文件緩存到本地，當第二次請求同樣的文件時，如果不過期，直接從本地取就可以了；如果過期了，瀏覽器就可以詢問服務器端，文件有沒有修改過？（依據是上一次服務器發送的Last-Modified和ETag），如果沒有修改過（304 Not Modified），還可以使用緩存。否則的話服務器就會被最新的文件發回到瀏覽器。當然如果你按了Ctrl+F5，會強制地發出GET請求，完全無視緩存。
現在瀏覽器得到了三個重要的東西：
- HTML ，瀏覽器把它變成DOM Tree
- CSS, 瀏覽器把它變成CSS Rule Tree
- Java， 它可以修改DOM Tree
瀏覽器會通過DOM Tree和CSS Rule Tree生成所謂“Render Tree”，計算每個元素的位置/大小，進行佈局，然後調用操作系統的API進行繪製，這是一個非常複雜的過程，略去不表。到目前爲止，我們終於在瀏覽器中看到了www.coder.com的內容。