當你輸入一個網址,實際會發生什麼?

来源:http://www.cnblogs.com/chenpingzhao/archive/2016/01/05/5102462.html
-Advertisement-
Play Games

英文原文:What really happens when you navigate to a URL,編譯:寒冬星空作為一個軟體開發者,你一定會對網路應用如何工作有一個完整的層次化的認知,同樣這裡也包括這些應用所用到的技術:像瀏覽器,HTTP,HTML,網路伺服器,需求處理等等。本文將更深入的研究...


英文原文:What really happens when you navigate to a URL

作為一個軟體開發者,你一定會對網路應用如何工作有一個完整的層次化的認知,同樣這裡也包括這些應用所用到的技術:像瀏覽器,HTTP,HTML,網路伺服器,需求處理等等。

1. 首先嘛,你得在瀏覽器里輸入要網址

當你輸入一個網址的時候,實際會發生什麼?

2. 瀏覽器查找功能變數名稱的IP地址

當你輸入一個網址的時候,實際會發生什麼?

導航的第一步是通過訪問的功能變數名稱找出其IP地址。DNS查找過程如下:

  • 瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是,操作系統沒有告訴瀏覽器儲存DNS記錄的時間,這樣不同瀏覽器會儲存個自固定的一個時間(2分鐘到30分鐘不等)。
  • 系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄,瀏覽器會做一個系統調用(windows里是gethostbyname)。這樣便可獲得系統緩存中的記錄。
  • 路由器緩存 – 接著,前面的查詢請求發向路由器,它一般會有自己的DNS緩存。
  • ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
  • 遞歸搜索 – 你的ISP的DNS伺服器從跟功能變數名稱伺服器開始進行遞歸搜索,從.com頂級功能變數名稱伺服器到Facebook的功能變數名稱伺服器。一般DNS伺服器的緩存中會有.com功能變數名稱伺服器中的功能變數名稱,所以到頂級伺服器的匹配過程不是那麼必要了。

DNS遞歸查找如下圖所示:

當你輸入一個網址的時候,實際會發生什麼?

DNS有一點令人擔憂,這就是像wikipedia.org 或者 facebook.com這樣的整個功能變數名稱看上去只是對應一個單獨的IP地址。還好,有幾種方法可以消除這個瓶頸:

  • 迴圈 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說,Facebook.com實際上就對應了四個IP地址。
  • 負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
  • 地理 DNS 根據用戶所處的地理位置,通過把功能變數名稱映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態,但映射靜態內容的話非常好。
  • Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足,Anycast與TCP協議適應的不是很好,所以很少應用在那些方案中。

大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。

3. 瀏覽器給web伺服器發送一個HTTP請求

當你輸入一個網址的時候,實際會發生什麼?

因為像Facebook主頁這樣的動態頁面,打開後在瀏覽器緩存中很快甚至馬上就會過期,毫無疑問他們不能從中讀取。

所以,瀏覽器將把一下請求發送到Facebook所在的伺服器:

GET http://facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Host: facebook.com
 Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

GET 這個請求定義了要讀取的URL: “http://facebook.com/”。 瀏覽器自身定義 (User-Agent 頭), 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求伺服器為了後邊的請求不要關閉TCP連接。

請求中也包含瀏覽器存儲的該功能變數名稱的cookies。可能你已經知道,在不同頁面請求當中,cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名,伺服器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機里,每次請求時發送給伺服器。

用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler,當然也有像FireBug這樣其他的工具。這些軟體在網站優化時會幫上很大忙。

除了獲取請求,還有一種是發送請求,它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發送請求在請求正文頭之後發送其參數。

像“http://facebook.com/”中的斜杠是至關重要的。這種情況下,瀏覽器能安全的添加斜杠。而像“http: //example.com/folderOrFile”這樣的地址,因為瀏覽器不清楚folderOrFile到底是文件夾還是文件,所以不能自動添加 斜杠。這時,瀏覽器就不加斜杠直接訪問地址,伺服器會響應一個重定向,結果造成一次不必要的握手。

4. facebook服務的永久重定向響應

當你輸入一個網址的時候,實際會發生什麼?

圖中所示為Facebook伺服器發回給瀏覽器的響應:

HTTP/1.1 301 Moved Permanently
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 Location: http://www.facebook.com/
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
 path=/; domain=.facebook.com; httponly
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Date: Fri, 12 Feb 2010 05:09:51 GMT
 Content-Length: 0

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

為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢?這個問題有好多有意思的答案。

其中一個原因跟搜索引擎排名有 關。你看,如果一個頁面有兩個地址,就像http://www.igoro.com/ 和http://igoro.com/,搜索引擎會認為它們是兩個網站,結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思,這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。

還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時,它可能會在緩存里出現好幾次。

5. 瀏覽器跟蹤重定向地址

當你輸入一個網址的時候,實際會發生什麼?

現在,瀏覽器知道了“http://www.facebook.com/”才是要訪問的正確地址,所以它會發送另一個獲取請求:

GET http://www.facebook.com/ HTTP/1.1
 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
 Accept-Language: en-US
 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
 Accept-Encoding: gzip, deflate
 Connection: Keep-Alive
 Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
 Host: www.facebook.com

頭信息以之前請求中的意義相同。

6. 伺服器“處理”請求

當你輸入一個網址的時候,實際會發生什麼?

伺服器接收到獲取請求,然後處理並返回一個響應。

這錶面上看起來是一個順向的任務,但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站,何況像facebook那樣訪問量大的網站呢!

  • Web 伺服器軟體
    web伺服器軟體(像IIS和阿帕奇)接收到HTTP請求,然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行響應的程式(像ASP.NET,PHP,RUBY…)。舉 個最簡單的例子,需求處理可以以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web伺服器軟體可以設置成為地址人工的對應請求處理,這樣 page1.aspx的發佈地址就可以是http://example.com/folder1/page1。
  • 請求處理
    請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些數據,並講數據存儲在伺服器上。然後,需求處理會生成一個HTML響應。

所 有動態網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL資料庫來存儲數據,存儲大量數據和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案 有:sharding (基於主鍵值講數據表分散到多個資料庫中),複製,利用弱語義一致性的簡化資料庫。

委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講,Fackbook得及時更新新聞feed,但數據支持下的“你可能認識的人”功能只需要每晚更新 (作者猜測是這樣的,改功能如何完善不得而知)。批處理作業更新會導致一些不太重要的數據陳舊,但能使數據更新耕作更快更簡潔。

7. 伺服器發回一個HTML響應

當你輸入一個網址的時候,實際會發生什麼?

圖中為伺服器生成並返回的響應:

HTTP/1.1 200 OK
 Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
 pre-check=0
 Expires: Sat, 01 Jan 2000 00:00:00 GMT
 P3P: CP="DSP LAW"
 Pragma: no-cache
 Content-Encoding: gzip
 Content-Type: text/html; charset=utf-8
 X-Cnection: close
 Transfer-Encoding: chunked
 Date: Fri, 12 Feb 2010 09:05:55 GMT

 2b3Tn@[...]

整個響應大小為35kB,其中大部分在整理後以blob類型傳輸。

內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後,你可以看到如下期望的HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"    
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
 lang="en" id="facebook">
 <head>
 <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
 <meta http-equiv="Content-language" content="en" />
 ...

關於壓縮,頭信息說明瞭是否緩存這個頁面,如果緩存的話如何去做,有什麼cookies要去設置(前面這個響應里沒有這點)和隱私信息等等。

請註意報頭中把Content-type設置為“text/html”。報頭讓瀏覽器將該響應內容以HTML形式呈現,而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應,不過同時也會考慮像URL擴展內容等其他因素。

8. 瀏覽器開始顯示HTML

在瀏覽器沒有完整接受全部HTML文檔時,它就已經開始顯示這個頁面了:

當你輸入一個網址的時候,實際會發生什麼?

9. 瀏覽器發送獲取嵌入在HTML中的對象

當你輸入一個網址的時候,實際會發生什麼?

在瀏覽器顯示HTML時,它會註意到需要獲取其他地址內容的標簽。這時,瀏覽器會發送一個獲取請求來重新獲得這些文件。

下麵是幾個我們訪問facebook.com時需要重獲取的幾個URL:

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

     

    http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif

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

     

    http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css

  • JavaScript 文件

    http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

    http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js

這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些功能變數名稱,發送請求,重定向等等…

但 不像動態頁面那樣,靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊,而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息,所以瀏覽器知道要把它們緩存多長時間。還有,每個響應都可能包含像版本號一樣工作的ETag頭(被請求變數的實體值),如果瀏覽器觀察到文件的版本 ETag信息已經存在,就馬上停止這個文件的傳輸。

試著猜猜看“fbcdn.net”在地址中代表什麼?聰明的答案是”Facebook內容分髮網絡”。Facebook利用內容分髮網絡(CDN)分發像圖片,CSS表和JavaScript文件這些靜態文件。所以,這些文件會在全球很多CDN的數據中心中留下備份。

靜態內容往往代表站點的帶寬大小,也能通過CDN輕鬆的複製。通常網站會使用第三方的CDN。例如,Facebook的靜態文件由最大的CDN提供商Akamai來托管。

舉例來講,當你試著ping static.ak.fbcdn.net的時候,可能會從某個akamai.net伺服器上獲得響應。有意思的是,當你同樣再ping一次的時候,響應的伺服器可能就不一樣,這說明幕後的負載平衡開始起作用了。

10. 瀏覽器發送非同步(AJAX)請求

當你輸入一個網址的時候,實際會發生什麼?

在Web 2.0偉大精神的指引下,頁面顯示完成後客戶端仍與伺服器端保持著聯繫。

以 Facebook聊天功能為例,它會持續與伺服器保持聯繫來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態,在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址,它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中,客戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發佈請求來獲取你好友里哪個 線上的狀態信息。

提起這個模式,就必須要講講”AJAX”– “非同步JavaScript 和 XML”,雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧,對於非同步請求,Facebook會返回一些JavaScript的代碼片段。

除了其他,fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上,你不僅可以被動的做為這些請求的看客,還能主動出擊修改和重新發送它們。AJAX請求這麼容易被蒙,可著實讓那些計分的線上游戲開發者們鬱悶的了。(當然,可別那樣騙人家~)

Facebook聊天功能提供了關於AJAX一個有意思的問題案例:把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議,所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。

這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息,它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息,伺服器就會找到未完成的請求,把新消息做為響應返回給客戶端。

總結一下

希望看了本文,你能明白不同的網路模塊是如何協同工作的


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 之前我在一篇blog中寫過如何使用多語言工具包,見http://www.cnblogs.com/yanxiaodi/p/3800767.html在WinEcos社區也發佈過一篇詳細的文章介紹多語言工具包的使用,但因社區改版那篇文章已經找不到了。當時寫的時候還沒有出Win10的SDK,都是基於UAP框...
  • 當HttpContext對象創建之後,HttpRuntime將隨後創建一個用於處理請求的對象,這個對象的類型為HttpApplication. 在ASP.NET內部,HttpRuntime管理一個定義在System.Web命名空間下的HttpApplicationFactory類的實例...
  • 在mac上截屏的幾種方式
  • 1、圖像的延遲一幀的問題,主要原因如代碼中所說,只有隊列多餘兩幀的時候才會出隊一幀。該問題對於連續的圖像幀基本無影響,只是對於非連續的情況下,進來的第一幀會延後,先出來的是上一次圖像序列中最後一幀。而當次圖像序列的最後一幀將會被刷到隊列中。 如果將其中的2改寫為1,則會出現圖像上下分層現象,上層是....
  • - check-rpaths的問題 今天在編譯varnish的時候,遇到幾個問題,其中一個就是出現如下錯誤:...+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot************************************....
  • 安裝參見: https://github.com/oetiker/SmokePing/blob/master/doc/smokeping_install.pod 1 Smokeping 2 3 *** General *** 4 5 owner = Ctry 6 contact...
  • 發現伺服器的cpu使用率特別高排查思路:-使用top或者mpstat查看cpu的使用情況# mpstat -P ALL 2 1Linux 2.6.32-358.el6.x86_64 (linux—host) 01/05/2016 _x86_64_ (24 CPU)04:41:13 PM CPU...
  • USB 設備驅動:一、USB 描述符:(存在於USB 的E2PROM裡面)1、 設備描述符:struct usb_device_descriptor2、 配置描述符:struct usb_config_descriptor3、 介面描述符:struct usb_interface_descripto...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...