老生常談-從輸入url到頁面展示到底發生了什麼

標籤：fat   收錄   網域服務器   rom   erro   redirect   .sh   介紹   str   

閱讀目錄

• 1、輸入地址
• 2、瀏覽器尋找網域名稱的 IP 位址　　
• 3、瀏覽器向 網頁伺服器發送一個 HTTP 要求
• 4、伺服器的永久重新導向響應
• 5、瀏覽器跟蹤重新導向地址
• 6、伺服器處理請求
• 7、伺服器返回一個 HTTP 響應　
• 8、瀏覽器顯示 HTML
• 9、瀏覽器發送請求擷取嵌入在 HTML 中的資源（片、音頻、視頻、CSS、JS等等）

     剛開始寫這篇文章還是挺糾結的，因為網上搜尋“從輸入url到頁面展示到底發生了什麼”，你可以搜到一大堆的資料。而且面試這道題基本是必考題，二月份面試的時候，雖然知道這個過程發生了什麼，不過當面試官一步步追問下去的，很多細節就不太清楚了。

　　最近剛好也在看http協議相關的東西，所以想對這個話題來個深入的總結，本文的目的是通過輸入url之後發生的事情來做知識的總結和擴充。所以文章可能會很雜。

    總的過程大概如下:

1、輸入地址

    當我們開始在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智能的匹配可能得 url 了，他會從記錄，書籤等地方，找到已經輸入的字串可能對應的 url，然後給出智能提示，讓你可以補全url地址。對於 google的chrome 的瀏覽器，他甚至會直接從緩衝中把網頁展示出來，就是說，你還沒有按下 enter，頁面就出來了。

2、瀏覽器尋找網域名稱的 IP 位址　　

　　1、請求一旦發起，瀏覽器首先要做的事情就是解析這個網域名稱，一般來說，瀏覽器會首先查看本地硬碟的 hosts 檔案，看看其中有沒有和這個網域名稱對應的規則，如果有的話就直接使用 hosts 檔案裡面的 ip 地址。

      2、如果在本地的 hosts 檔案沒有能夠找到對應的 ip 地址，瀏覽器會發出一個 DNS請求到本地DNS伺服器 。本地DNS伺服器一般都是你的網路接入伺服器商提供，比如中國電信，中國移動。

　   3、查詢你輸入的網址的DNS請求到達本地DNS伺服器之後，本地DNS伺服器會首先查詢它的緩衝記錄，如果緩衝中有此條記錄，就可以直接返回結果，此過程是遞迴的方式進行查詢。如果沒有，本地DNS伺服器還要向DNS根伺服器進行查詢。

　　4、根DNS伺服器沒有記錄具體的網域名稱和IP地址的對應關係，而是告訴本地DNS伺服器，你可以到網域服務器上去繼續查詢，並給出網域服務器的地址。這種過程是迭代的過程。

　　5、本地DNS伺服器繼續向網域服務器發出請求，在這個例子中，請求的對象是.com網域服務器。.com網域服務器收到請求之後，也不會直接返回網域名稱和IP地址的對應關係，而是告訴本地DNS伺服器，你的網域名稱的解析伺服器的地址。

　　6、最後，本地DNS伺服器向網域名稱的解析伺服器發出請求，這時就能收到一個網域名稱和IP地址對應關係，本地DNS伺服器不僅要把IP地址返回給使用者電腦，還要把這個對應關係儲存在緩衝中，以備下次別的使用者查詢時，可以直接返回結果，加快網路訪問。

 

下面這張圖很完美的解釋了這一過程：

知識擴充： 1)什麼是DNS？

　　DNS（Domain Name System，網域名稱系統），網際網路上作為網域名稱和IP地址相互映射的一個分散式資料庫，能夠使使用者更方便的訪問互連網，而不用去記住能夠被機器直接讀取的IP數串。通過主機名稱，最終得到該主機名稱對應的IP地址的過程叫做網域名稱解析（或主機名稱解析）。

　　通俗的講，我們更習慣於記住一個網站的名字，比如www.baidu.com,而不是記住它的ip地址，比如：167.23.10.2。而電腦更擅長記住網站的ip地址，而不是像www.baidu.com等連結。因為，DNS就相當於一個電話本，比如你要找www.baidu.com這個網域名稱，那我翻一翻我的電話本，我就知道，哦，它的電話（ip）是167.23.10.2。

 

2)DNS查詢的兩種方式：遞迴查詢和迭代查詢

1、遞迴解析

    當局部DNS伺服器自己不能回答客戶機的DNS查詢時，它就需要向其他DNS伺服器進行查詢。此時有兩種方式，所示的是遞迴方式。局部DNS伺服器自己負責向其他DNS伺服器進行查詢，一般是先向該網域名稱的根網域服務器查詢，再由根網域名稱伺服器一級級向下查詢。最後得到的查詢結果返回給局部DNS伺服器，再由局部DNS伺服器返回給用戶端。

2、迭代解析

　　當局部DNS伺服器自己不能回答客戶機的DNS查詢時，也可以通過迭代查詢的方式進行解析，所示。局部DNS伺服器不是自己向其他DNS伺服器進行查詢，而是把能解析該網域名稱的其他DNS伺服器的IP地址返回給用戶端DNS程式，用戶端DNS程式再繼續向這些DNS伺服器進行查詢，直到得到查詢結果為止。也就是說，迭代解析只是幫你找到相關的伺服器而已，而不會幫你去查。比如說：baidu.com的伺服器ip地址在192.168.4.5這裡，你自己去查吧，本人比較忙，只能幫你到這裡了。

 

3)DNS網域名稱稱空間的組織方式

 我們在前面有說到根DNS伺服器，域DNS伺服器，這些都是DNS網域名稱稱空間的組織方式。按其功能命名空間中用來描述 DNS 網域名稱稱的五個類別的介紹詳見下表中，以及與每個名稱類型的樣本

（盜圖）

 

4)DNS負載平衡

　　當一個網站有足夠多的使用者的時候，假如每次請求的資源都位於同一台機器上面，那麼這台機器隨時可能會蹦掉。處理辦法就是用DNS負載平衡技術，它的原理是在DNS伺服器中為同一個主機名稱配置多個IP地址,在應答DNS查詢時,DNS伺服器對每個查詢將以DNS檔案中主機記錄的IP地址按順序返回不同的解析結果,將用戶端的訪問引導到不同的機器上去,使得不同的用戶端訪問不同的伺服器,從而達到負載平衡的目的?例如可以根據每台機器的負載量，該機器離使用者地理位置的距離等等。

 

3、瀏覽器向 網頁伺服器發送一個 HTTP 要求

　　拿到網域名稱對應的IP地址之後，瀏覽器會以一個隨機連接埠（1024<連接埠<65535）向伺服器的WEB程式（常用的有httpd,nginx等）80連接埠發起TCP的串連請求。這個串連請求到達伺服器端後（這中間通過各種路由裝置，區域網路內除外），進入到網卡，然後是進入到核心的TCP/IP協議棧（用於識別該串連請求，解鎖包，一層一層的剝開），還有可能要經過Netfilter防火牆（屬於核心的模組）的過濾，最終到達WEB程式，最終建立了TCP/IP的串連。

TCP串連:

　　建立了TCP串連之後，發起一個http請求。一個典型的 http request header 一般需要包括請求的方法，例如 GET 或者 POST 等，不常用的還有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法，一般的瀏覽器只能發起 GET 或者 POST 請求。

　　用戶端向伺服器發起http請求的時候，會有一些請求資訊，請求資訊包含三個部分：

　　| 要求方法URI協議/版本

      | 要求標頭(Request Header)

　　| 請求本文：

下面是一個完整的HTTP請求例子：

GET/sample.jspHTTP/1.1Accept:image/gif.image/jpeg,*/*Accept-Language:zh-cnConnection:Keep-AliveHost:localhostUser-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)Accept-Encoding:gzip,deflate
username=jinqiao&password=1234

 注意：最後一個要求標頭之後是一個空行，發送斷行符號符和分行符號，通知伺服器以下不再有要求標頭。

（1）請求的第一行是“方法URL議/版本”：GET/sample.jsp HTTP/1.1
（2）要求標頭(Request Header)
　　 要求標頭包含許多有關的用戶端環境和請求本文的有用資訊。例如，要求標頭可以聲明瀏覽器所用的語言，請求本文的長度等。

Accept:image/gif.image/jpeg.*/*Accept-Language:zh-cnConnection:Keep-AliveHost:localhostUser-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)Accept-Encoding:gzip,deflate.

（3）請求本文
    要求標頭和請求本文之間是一個空行，這個行非常重要，它表示要求標頭已經結束，接下來的是請求本文。請求本文中可以包含客戶提交的查詢字串資訊：

username=jinqiao&password=1234

 知識擴充：1）TCP三向交握

第一次握手：用戶端A將標誌位SYN置為1,隨機產生一個值為seq=J（J的取值範圍為=1234567）的資料包到伺服器，用戶端A進入SYN_SENT狀態，等待服務端B確認；

第二次握手：服務端B收到資料包後由標誌位SYN=1知道用戶端A請求建立串連，服務端B將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包發送給用戶端A以確認串連請求，服務端B進入SYN_RCVD狀態。

第三向交握：用戶端A收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包發送給服務端B，服務端B檢查ack是否為K+1，ACK是否為1，如果正確則串連建立成功，用戶端A和服務端B進入ESTABLISHED狀態，完成三向交握，隨後用戶端A與服務端B之間可以開始傳輸資料了。

：

 

  2）為什需要三向交握？

  《電腦網路》第四版中講“三向交握”的目的是“為了防止已失效的串連請求報文段突然又傳送到了服務端，因而產生錯誤”

   書中的例子是這樣的，“已失效的串連請求報文段”的產生在這樣一種情況下：client發出的第一個串連請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到串連釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的串連請求報文段後，就誤認為是client再次發出的一個新的串連請求。於是就向client發出確認報文段，同意建立串連。

　　假設不採用“三向交握”，那麼只要server發出確認，新的串連就建立了。由於現在client並沒有發出建立串連的請求，因此不會理睬server的確認，也不會向server發送資料。但server卻以為新的運輸串連已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三向交握”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立串連。”。主要目的防止server端一直等待，浪費資源。

 3）TCP四次揮手

第一次揮手：Client發送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：Server發送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

 4）為什麼建立串連是三向交握，而關閉串連卻是四次揮手呢？

　　這是因為服務端在LISTEN狀態下，收到建立串連請求的SYN報文後，把ACK和SYN放在一個報文裡發送給用戶端。而關閉串連時，當收到對方的FIN報文時，僅僅表示對方不再發送資料了但是還能接收資料，己方也未必全部資料都發送給對方了，所以己方可以立即close，也可以發送一些資料給對方後，再發送FIN報文給對方來表示同意現在關閉串連，因此，己方ACK和FIN一般都會分開發送。

 

4、伺服器的永久重新導向響應

 　　伺服器給瀏覽器響應一個301永久重新導向響應，這樣瀏覽器就會訪問“http://www.google.com/” 而非“http://google.com/”。

　　為什麼伺服器一定要重新導向而不是直接發送使用者想看的網頁內容呢？其中一個原因跟搜尋引擎排名有關。如果一個頁面有兩個地址，就像http://www.yy.com/和http://yy.com/，搜尋引擎會認為它們是兩個網站，結果造成每個搜尋連結都減少從而降低排名。而搜尋引擎知道301永久重新導向是什麼意思，這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成緩衝友好性變差，當一個頁面有好幾個名字時，它可能會在緩衝裡出現好幾次。

擴充知識1）301和302的區別。

　　301和302狀態代碼都表示重新導向，就是說瀏覽器在拿到伺服器返回的這個狀態代碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中擷取（使用者看到的效果就是他輸入的地址A瞬間變成了另一個地址B）——這是它們的共同點。

　　他們的不同在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜尋引擎在抓取新內容的同時也將舊的網址交換為重新導向之後的網址；

　　302表示舊地址A的資源還在（仍然可以訪問），這個重新導向只是臨時地從舊地址A跳轉到地址B，搜尋引擎會抓取新的內容而儲存舊的網址。 SEO302好於301

 

2）重新導向原因：

（1）網站調整（如改變網頁目錄結構）；（2）網頁被移到一個新地址；（3）網頁副檔名改變(如應用需要把.php改成.Html或.shtml)。        這種情況下，如果不做重新導向，則使用者收藏夾或搜尋引擎資料庫中舊地址只能讓訪問客戶得到一個404分頁錯誤資訊，訪問流量白白喪失；再者某些註冊了多個網域名稱的網站，也需要通過重新導向讓訪問這些網域名稱的使用者自動跳轉到主要站台等。 3）什麼時候進行301或者302跳轉呢？        當一個網站或者網頁24—48小時內臨時移動到一個新的位置，這時候就要進行302跳轉，而使用301跳轉的情境就是之前的網站因為某種原因需要移除掉，然後要到新的地址訪問，是永久性的。清晰明確而言：使用301跳轉的大概情境如下：1、網域名稱到期不想續約（或者發現了更適合網站的網域名稱），想換個網域名稱。2、在搜尋引擎的搜尋結果中出現了不帶www的網域名稱，而帶www的網域名稱卻沒有收錄，這個時候可以用301重新導向來告訴搜尋引擎我們目標的網域名稱是哪一個。3、空間伺服器不穩定，換空間的時候。 5、瀏覽器跟蹤重新導向地址

   現在瀏覽器知道了 "http://www.google.com/"才是要訪問的正確地址，所以它會發送另一個http請求。這裡沒有啥好說的

 

6、伺服器處理請求

　　經過前面的重重步驟，我們終於將我們的http請求發送到了伺服器這裡，其實前面的重新導向已經是到達伺服器了，那麼，伺服器是如何處理我們的請求的呢？

　　後端從在固定的連接埠接收到TCP報文開始，它會對TCP串連進行處理，對HTTP協議進行解析，並按照報文格式進一步封裝成HTTP Request對象，供上層使用。

　　一些大一點的網站會將你的請求到反向 Proxy伺服器中，因為當網站訪問量非常大，網站越來越慢，一台伺服器已經不夠用了。於是將同一個應用部署在多台伺服器上，將大量使用者的請求分配給多台機器處理。此時，用戶端不是直接通過HTTP協議訪問某網站應用程式伺服器，而是先請求到Nginx，Nginx再請求應用伺服器，然後將結果返回給用戶端，這裡Nginx的作用是反向 Proxy伺服器。同時也帶來了一個好處，其中一台伺服器萬一掛了，只要還有其他伺服器正常運行，就不會影響使用者使用。

：

通過Nginx的反向 Proxy，我們到達了web伺服器，服務端指令碼處理我們的請求，訪問我們的資料庫，擷取需要擷取的內容等等，當然，這個過程涉及很多後端指令碼的複雜操作。由於對這一塊不熟，所以這一塊只能介紹這麼多了。

 

擴充閱讀：1）什麼是反向 Proxy？

用戶端本來可以直接通過HTTP協議訪問某網站應用程式伺服器，網站管理員可以在中間加上一個Nginx，用戶端請求Nginx，Nginx請求應用伺服器，然後將結果返回給用戶端，此時Nginx就是反向 Proxy伺服器。

 

7、伺服器返回一個 HTTP 響應　

　　經過前面的6個步驟，伺服器收到了我們的請求，也處理我們的請求，到這一步，它會把它的處理結果返回，也就是返回一個HTPP響應。

HTTP響應與HTTP請求相似，HTTP響應也由3個部分構成，分別是：

l 　狀態行

l 　回應標頭(Response Header)

l 　響應本文

HTTP/1.1 200 OKDate: Sat, 31 Dec 2005 23:59:59 GMTContent-Type: text/html;charset=ISO-8859-1Content-Length: 122＜html＞＜head＞＜title＞http＜/title＞＜/head＞＜body＞＜!-- body goes here --＞＜/body＞＜/html＞

狀態行：

狀態行由協議版本、數字形式的狀態碼、及相應的狀態原因，各元素之間以空格分隔。

格式:    HTTP-Version Status-Code Reason-Phrase CRLF

例如:    HTTP/1.1 200 OK \r\n

-- 協議版本：是用http1.0還是其他版本

-- 狀態原因：狀態原因給出了關於狀態碼的簡短的文字描述。比如狀態碼為200時的描述為 ok

-- 狀態碼：狀態碼由三位元字組成，第一個數字定義了響應的類別，且有五種可能取值。如下

 

1xx：資訊性狀態代碼，表示伺服器已接收了用戶端請求，用戶端可繼續發送請求。

    100 Continue

    101 Switching Protocols

 2xx：成功狀態代碼，表示伺服器已成功接收到請求並進行處理。

    200 OK 表示用戶端請求成功

    204 No Content 成功，但不返回任何實體的主體部分

    206 Partial Content 成功執行了一個範圍（Range）請求

3xx：重新導向狀態代碼，表示伺服器要求用戶端重新導向。

    301 Moved Permanently 永久性重新導向，響應報文的Location首部應該有該資源的新URL

    302 Found 臨時性重新導向，響應報文的Location首部給出的URL用來臨時定位資源

    303 See Other 請求的資源存在著另一個URI，用戶端應使用GET方法定向擷取請求的資源

    304 Not Modified 伺服器內容沒有更新，可以直接讀取瀏覽器緩衝

     307 Temporary Redirect 臨時重新導向。與302 Found含義一樣。302禁止POST變換為GET，但實際使用時並不一定，307則更多瀏覽器可能會遵循這一標準，但也依賴於瀏覽器具體實現

 4xx：用戶端錯誤狀態代碼，表示用戶端的請求有非法內容。

       400 Bad Request 表示用戶端請求有語法錯誤，不能被伺服器所理解

       401 Unauthonzed 表示請求未經授權，該狀態碼必須與 WWW-Authenticate 前序域一起使用

       403 Forbidden 表示伺服器收到請求，但是拒絕提供服務，通常會在響應本文中給出不提供服務的原因

       404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL

5xx：伺服器錯誤狀態代碼，表示伺服器未能正常處理用戶端的請求而出現意外錯誤。

        500 Internel Server Error 表示伺服器發生不可預期的錯誤，導致無法完成用戶端的請求

        503 Service Unavailable 表示伺服器當前不能夠處理用戶端的請求，在一段時間之後，伺服器可能會恢複正常

 

回應標頭：

　　回應標頭部：由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號":"分隔，典型的回應標頭有：

 

響應本文

包含著我們需要的一些具體資訊，比如cookie，html,image，後端返回的請求資料等等。這裡需要注意，響應本文和回應標頭之間有一行空格，表示回應標頭的資訊到空格為止，是fiddler抓到的請求本文，紅色框中的：響應本文：

 

8、瀏覽器顯示 HTML

　　在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了，瀏覽器是如何把頁面呈現在螢幕上的呢？不同瀏覽器可能解析的過程不太一樣，這裡我們只介紹webkit的渲染過程，對應的就是WebKit渲染的過程，這個過程包括：

解析html以構建dom樹 -> 構建render樹 -> 布局render樹 -> 繪製render樹

　　瀏覽器在解析html檔案時，會”自上而下“載入，並在載入過程中進行解析渲染。在解析過程中，如果遇到請求外部資源時，片、外鏈的CSS、iconfont等，請求過程是非同步，並不會影響html文檔進行載入。

　　解析過程中，瀏覽器首先會解析HTML檔案構建DOM樹，然後解析CSS檔案構建渲染樹，等到渲染樹構建完成後，瀏覽器開始布局渲染樹並將其繪製到螢幕上。這個過程比較複雜，涉及到兩個概念: reflow(迴流)和repain(重繪)。

　　DOM節點中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顏色,字型,等確定下來之後，瀏覽器便開始繪製內容，這個過程稱為repain。

　　頁面在首次載入時必然會經曆reflow和repain。reflow和repain過程是非常消耗效能的，尤其是在行動裝置上，它會破壞使用者體驗，有時會造成頁面卡頓。所以我們應該儘可能少的減少reflow和repain。

　　

　　當文檔載入過程中遇到js檔案，html文檔會掛起渲染（載入解析渲染同步）的線程，不僅要等待文檔中js檔案載入完畢，還要等待解析執行完畢，才可以恢複html文檔的渲染線程。因為JS有可能會修改DOM，最為經典的document.write，這意味著，在JS執行完成前，後續所有資源的下載可能是沒有必要的，這是js阻塞後續資源下載的根本原因。所以我明平時的代碼中，js是放在html文檔末尾的。

　　JS的解析是由瀏覽器中的JS解析引擎完成的，比如Google的是V8。JS是單線程運行，也就是說，在同一個時間內只能做一件事，所有的任務都需要排隊，前一個任務結束，後一個任務才能開始。但是又存在某些任務比較耗時，如IO讀寫等，所以需要一種機制可以先執行排在後面的任務，這就是：同步任務(synchronous)和非同步任務(asynchronous)。

　　JS的執行機制就可以看做是一個主線程加上一個任務隊列(task queue)。同步任務就是放在主線程上執行的任務，非同步任務是放在任務隊列中的任務。所有的同步任務在主線程上執行，形成一個執行棧;非同步任務有了運行結果就會在任務隊列中放置一個事件；指令碼運行時先依次運行執行棧，然後會從任務隊列裡提取事件，運行任務隊列中的任務，這個過程是不斷重複的，所以又叫做事件迴圈(Event loop)。具體的過程可以看我這篇文章：點擊這裡

 

9、瀏覽器發送請求擷取嵌入在 HTML 中的資源（片、音頻、視頻、CSS、JS等等）

　　其實這個步驟可以並列在步驟8中，在瀏覽器顯示HTML時，它會注意到需要擷取其他地址內容的標籤。這時，瀏覽器會發送一個擷取請求來重新獲得這些檔案。比如我要擷取外圖片，CSS，JS檔案等，類似於下面的連結：

圖片：http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

CSS式樣表：http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

JavaScript 檔案：http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

　　這些地址都要經曆一個和HTML讀取類似的過程。所以瀏覽器會在DNS中尋找這些網域名稱，發送請求，重新導向等等...

不像動態網頁面，靜態檔案會允許瀏覽器對其進行緩衝。有的檔案可能會不需要與伺服器通訊，而從緩衝中直接讀取，或者可以放到CDN中

 

 -------------------------------------------------分割線-----------------------------------------------------

 

　　至此，從輸入url到頁面展示的過程終於整理完了。本文前前後後整理了差不多一個星期，當然，網上有很多文章的順序可能跟本文不太一樣，也是可以的。

如今已離開呆了一年的大YY，進入了另一家公司，有很多東西在後面等著學習，有點小壓力的同時也有很強烈的興奮，哈哈。願你在金三銀四裡找到滿意的工作，乾巴爹。

　　當然，文筆有限，有誤之處，歡迎指出，本文參考了很多的文章，不過很多文章的連結不記得了，所以只列出了下面三個參考連結。

 

 

參考文獻：

1190000006879700  

http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/

http://zrj.me/archives/589  

 

老生常談-從輸入url到頁面展示到底發生了什麼