首先對上篇blog
進行乙個補充：
以我做的「基於執行緒池和資料庫連線池的web
伺服器」為例，說說http
通訊的流程，大體分為三個階段：
a．連線
伺服器通過乙個serversocket
類物件對8000
埠進行監聽，監聽到之後建立
連線，開啟乙個socket
虛擬檔案。
b．請求
建立與建立socket
連線相關的流物件後，瀏覽器獲取請求，為get
請求，則
從請求資訊中獲取所訪問的html
檔名，向伺服器傳送請求。
c．應答
服務收到請求後，搜尋相關目錄檔案，若不存在，返回錯誤資訊。若存在，
則想html
檔案，進行加http
頭等處理後響應給瀏覽器，瀏覽器解析html
伺服器，異
ok！言歸正傳!
寫上篇blog
時，留下了乙個問題，就是瀏覽器的工作原理，在我們輸入乙個**就獲得如此豐富多彩的網路世界的背後究竟發生了什麼事請，作為乙個軟體工程的學生很有必要研究一下！上網查了查，想總結如下：
s1：瀏覽器根據你輸入的**查詢ip
位址。這裡涉及到乙個叫dns
（網域名稱解析系統）的東西，專門用於查詢網域名稱對應的ip
位址的。當然，處於效能的考慮，不是每一次都需要到這個系統中進行查詢的，這裡邊會有很多的快取對一些對應資訊進行快取。會依次查詢：瀏覽器快取，系統快取，路由器快取，isp dns
快取，isp dns
對root
網域名稱伺服器到自己的網域名稱伺服器進行遞迴搜尋。
這裡產生乙個問題：負載平衡器；
s2：瀏覽器向伺服器傳送請求。（當然，有時候瀏覽器中有快取另當別論）。這裡就是上篇blog
中提到的過程了。
當然這裡可以有乙個小插曲，重定向響應。當輸入
時，當伺服器回給瀏覽器響應乙個301永久重定向響應。
瀏覽器接到重定向後就會跟蹤重定向，進而瀏覽器就會訪問「 而非「」。
這裡也產生乙個問題：cookies s3
：伺服器處理請求。伺服器接受請求，並進行處理。
裡面至少包括下列知識：
web伺服器（iis
，阿帕奇等），cgi
，servlet
，asp
，jsp
，以及我們現在所學的web
開發（hss
框架，設計模式等等）大都是在做這個事情。
s4：伺服器發回乙個html
響應s5
：瀏覽器開始顯示html。s6
：瀏覽器傳送嵌在html
，js等。這些資源同樣需要經歷想訪問html
檔案的流程。
這裡同樣有很多東西可以研究的啦！像這些靜態資源如何存放，有個叫內容分發器的東西（將這些資源分發到不同的資料中心備份），負責平衡器等在這裡就有用處了。 s7
：補充瀏覽器傳送乙個ajax
請求。對這個還不是太明白，同樣產生乙個問題：ajax。
查資料了解到：
facebook聊天功能提供了關於ajax乙個有意思的問題案例：把資料從伺服器端推送到客戶端。因為http是乙個請求-響應協議，所以聊天伺服器不能把新訊息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新訊息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新訊息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新訊息，伺服器就會找到未完成的請求，把新訊息做為響應返回給客戶端。
寫本blog
遇到的問題如下：
1.
負載平衡器是以乙個特定ip位址進行偵聽並將網路請求**到集群伺服器上的硬體裝置。 一些大型的站點一般都會使用這種昂貴的高效能負載平衡器。 ？？？多次接觸到這個詞了~~~~ 先放這下次解決！
2.
cookies
3.
ajax
瀏覽器工作原理
介紹 渲染引擎又叫排版引擎或者瀏覽器核心 主流的渲染引擎有 解析html構造dom樹 document object model，文件物件模型 dom是w3c組織推薦的處理可擴充套件置標語言的標準程式設計介面。構建渲染數，渲染數並不等同於dom數，因為像head標籤或者display none這樣的...
瀏覽器工作原理
輸入網域名稱，瀏覽器做簡單的篩選判斷 預設為http協議，https的話需要手動輸入 dns查詢，獲取ip位址 先查自己記憶體裡的dns cache 再查本地硬碟裡的host檔案 查詢dns服務 建立tcp ip連線 傳送http請求 伺服器處理 瀏覽器收到返回，解析展示 我們在瀏覽器輸入 其實就是...
瀏覽器工作原理
關於渲染是否被loadrunner計入到響應時間 瀏覽器的主要元件包括 1.使用者介面 包括位址列 後退 前進按鈕 書籤目錄等，也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分 2.瀏覽器引擎 用來查詢及操作渲染引擎的介面 3.渲染引擎 用來顯示請求的內容，例如，如果請求內容為html...