在瀏覽器中輸入URL並回車後都發生了什麼？

時間  2019-11-13
標籤 瀏覽器 輸入 url 回車 發生了 什麼 欄目 瀏覽器 简体版
原文   原文鏈接

1.解析URL

________________________________________________________________________php

關於URL：css

URL（Universal Resource Locator）：統一資源定位符。俗稱網頁地址或者網址。html

URL用來表示某個資源的地址。（經過俗稱就能看出來）前端

URL主要由如下幾個部分組成：web

a.傳輸協議ajax

b.服務器算法

c.域名數據庫

d.端口編程

e.虛擬目錄json

f.文件名

g.錨

h.參數

也就是說，一般一個URL是像下面這樣

連起來就是：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

上面的連接有幾個要注意的地方：「;」 和「/」的使用，80端口默認不顯示，「?」 到「#」之間跟着參數，多個參數使用「&」鏈接，「#」後面跟着錨。 

 ___________________________________________________________________________________________________________________________________________________________________

如今來討論URL解析，當在瀏覽器中輸入URL後，瀏覽器首先對拿到的URL進行識別，抽取出域名字段。

2. DNS解析

DNS解析（域名解析），DNS其實是一個域名和IP對應的數據庫。

IP地址往都難以記住，但機器間互相只認IP地址，因而人們發明了域名，讓域名與IP地址之間一一對應，它們之間的轉換工做稱爲域名解析，域名解析須要由專門的域名解析服務器來完成，整個過程是自動進行的。

能夠在瀏覽器中輸入IP地址瀏覽網站，也能夠輸入域名查詢網站，雖然得出的內容是同樣的可是調用的過程不同，輸入IP地址是直接從主機上調用內容，輸入域名是經過域名解析服務器指向對應的主機的IP地址，再從主機調用網站的內容。

在進行DNS解析時，會經歷如下步驟：

查詢瀏覽器緩存（瀏覽器會緩存以前拿到的DNS 2-30分鐘時間），若是沒有找到，

檢查系統緩存，檢查hosts文件，這個文件保存了一些之前訪問過的網站的域名和IP的數據。它就像是一個本地的數據庫。若是找到就能夠直接獲取目標主機的IP地址了。沒有找到的話，須要

檢查路由器緩存，路由器有本身的DNS緩存，可能就包括了這在查詢的內容；若是沒有，要

查詢ISP DNS 緩存：ISP服務商DNS緩存（本地服務器緩存）那裏可能有相關的內容，若是還不行的話，須要，

遞歸查詢：從根域名服務器到頂級域名服務器再到極限域名服務器依次搜索哦對應目標域名的IP。

經過以上的查找，就能夠獲取到域名對應的IP了。接下來就是向該IP地址定位的HTTP服務器發起TCP鏈接。

3. 瀏覽器與網站創建TCP鏈接（三次握手）

第一次握手：客戶端向服務器端發送請求（SYN=1） 等待服務器確認；

第二次握手：服務器收到請求並確認，回覆一個指令（SYN=1，ACK=1）；

第三次握手：客戶端收到服務器的回覆指令並返回確認（ACK=1）。

經過三次握手，創建了客戶端和服務器之間的鏈接，如今能夠請求和傳輸數據了。

4.請求和傳輸數據

好比要經過get請求訪問「http://www.dydh.org/」，經過抓包能夠看到：

請求網址（url）：http://www.dydh.org/

請求方法：GET

遠程地址：IP

狀態碼：200 OK

Http版本： HTTP/1.1

請求頭： ...

響應頭： ...

注意響應頭中有一個：Set-Cookie:"PHPSESSID=c882giens9f7d3oglcakhrl994; path=/"，說明瀏覽器中沒有關於這個網站的cookie信息。

當咱們下一次訪問相同的網站時：

能夠看到，請求頭中包含了這個cookie信息，

Cookie:"PHPSESSID=c882giens9f7d3oglcakhrl994; CNZZDATA1253283365=1870471808-1473694656-%7C1473694656"

cookie能夠用來保存一些有用的信息：Cookies若是是首次訪問，會提示服務器創建用戶緩存信息，若是不是，能夠利用Cookies對應鍵值，找到相應緩存，緩存裏面存放着用戶名，密碼和一些用戶設置項。

經過這種GET請求，和服務器的響應。能夠將服務器上的目標文件傳輸到瀏覽器進行渲染。

5.瀏覽器渲染頁面

客戶端拿到服務器端傳輸來的文件，找到HTML和MIME文件，經過MIME文件，瀏覽器知道要用頁面渲染引擎來處理HTML文件。

ａ.瀏覽器會解析html源碼，而後建立一個 DOM樹。

在DOM樹中，每個HTML標籤都有一個對應的節點，而且每個文本也都會有一個對應的文本節點。

b.瀏覽器解析CSS代碼，計算出最終的樣式數據，造成css對象模型CSSOM。

首先會忽略非法的CSS代碼，以後按照瀏覽器默認設置——用戶設置——外鏈樣式——內聯樣式——HTML中的style樣式順序進行渲染。

c.利用DOM和CSSOM構建一個渲染樹（rendering tree）。
渲染樹和DOM樹有點像，可是是有區別的。

DOM樹徹底和html標籤一一對應，可是渲染樹會忽略掉不須要渲染的元素，好比head、display:none的元素等。

並且一大段文本中的每個行在渲染樹中都是獨立的一個節點。
渲染樹中的每個節點都存儲有對應的css屬性。

ｄ.瀏覽器就根據渲染樹直接把頁面繪製到屏幕上。

———————————————————————————————————————————————————

 

參考連接：

https://www.zhihu.com/question/34873227

http://blog.csdn.net/qq991029781/article/details/50938475

http://blog.csdn.net/lihongxun945/article/details/37830667

http://www.myexception.cn/go/1860953.html

http://www.nowcoder.com/discuss/3853?pos=264&type=1&order=0

http://www.cnblogs.com/xiaohuochai/p/4750444.html

http://baike.so.com/doc/1578352-1668460.html

http://www.cnblogs.com/simonbaker/p/4253832.html

 

https://www.cnblogs.com/tisikcci/p/5866753.html

 

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

做爲一個軟件開發者，你必定會對網絡應用如何工做有一個完整的層次化的認知，一樣這裏也包括這些應用所用到的技術：像瀏覽器，HTTP，HTML，網絡服務器，需求處理等等。

本文將更深刻的研究當你輸入一個網址的時候，後臺到底發生了一件件什麼樣的事～

1. 首先嘛，你得在瀏覽器裏輸入要網址:

image

 

2. 瀏覽器查找域名的IP地址

image

導航的第一步是經過訪問的域名找出其IP地址。DNS查找過程以下：

  • 瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是，操做系統沒有告訴瀏覽器儲存DNS記錄的時間，這樣不一樣瀏覽器會儲存個自固定的一個時間（2分鐘到30分鐘不等）。
  • 系統緩存 – 若是在瀏覽器緩存裏沒有找到須要的記錄，瀏覽器會作一個系統調用（windows裏是gethostbyname）。這樣即可得到系統緩存中的記錄。
  • 路由器緩存 – 接着，前面的查詢請求發向路由器，它通常會有本身的DNS緩存。
  • ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的服務器。在這通常都能找到相應的緩存記錄。
  • 遞歸搜索 – 你的ISP的DNS服務器從跟域名服務器開始進行遞歸搜索，從.com頂級域名服務器到Facebook的域名服務器。通常DNS服務器的緩存中會有.com域名服務器中的域名，因此到頂級服務器的匹配過程不是那麼必要了。

DNS遞歸查找以下圖所示：

500px-An_example_of_theoretical_DNS_recursion_svg

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請求

image

由於像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 andAccept-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服務的永久重定向響應

image

圖中所示爲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. 瀏覽器跟蹤重定向地址

image

如今，瀏覽器知道了「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. 服務器「處理」請求

image

服務器接收到獲取請求，而後處理並返回一個響應。

這表面上看起來是一個順向的任務，但其實這中間發生了不少有意思的東西- 就像做者博客這樣簡單的網站，況且像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響應

image

圖中爲服務器生成並返回的響應：

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" class=" no_js">
 <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文檔時，它就已經開始顯示這個頁面了：

image

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

image

在瀏覽器顯示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）請求

image

在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是一個請求-響應協議，因此聊天服務器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務器端看本身有沒有新消息。

這些狀況發生時長輪詢是個減輕服務器負載挺有趣的技術。若是當被輪詢時服務器沒有新消息，它就不理這個客戶端。而當還沒有超時的狀況下收到了該客戶的新消息，服務器就會找到未完成的請求，把新消息作爲響應返回給客戶端。

總結一下

但願看了本文，你能明白不一樣的網絡模塊是如何協同工做的

https://www.cnblogs.com/qxzy/p/5493012.html

 

當你訪問淘寶的時候，發生了什麼？

 

導讀

 

當你在瀏覽器上，指尖輕輕輸入  www.taobao.com  之後發生了什麼？本文從你按下瀏覽器的肯定鍵開始分析，一直到你如何找到商品結束。適合各種讀者瞭解你僅僅訪問一次淘寶的首頁，所涉及到的技術和系統規模，本文做者名叫孫放，著於他在淘寶實習期間。

 

你發現快要過節了，因而想給你的男/女友買點兒禮物，你打開了淘寶。下面來看看，當你在瀏覽器輕輕www.taobao.com 之後發生了什麼？

 

首先你的瀏覽器查詢了DNS服務器（注：可以令人更方便的訪問互聯網，而不用去記住可以被機器直接讀取的IP地址，例如192.168.1.1），如今DNS服務器將www.taobao.com轉換成IP地址，機器能直接讀取了。

 

不過瀏覽器發現，在不一樣的地區或者不一樣的網絡（電信、聯通、移動）的狀況下，轉換後的IP地址極可能是不同的，這首先涉及到負載均衡（注：至關於幾萬人的大學，一個食堂不夠用，因而學校弄了五個食堂來服務全部的同窗，這就叫負載均衡）。第一步，經過DNS解析域名時將你的訪問分配到不一樣的入口，同時儘量保證你所訪問的入口是全部入口中可能較快的一個。

 

好了，如今你經過這個入口成功的訪問了www.taobao.com的實際的入口IP地址。這時你產生了一個PV（注： Page View，一次頁面訪問），每日每一個網站的總PV量是形容一個網站規模的重要指標。淘寶網全網在平日非促銷期間的PV大概是16-25億之間。同時做爲一個獨立的用戶，你此次訪問淘寶網的全部頁面，均算做一個UV（注：Unique Visitor用戶訪問）。賣火車票的12306.cn的日PV量最高峯在10億左右，而UV量卻遠小於淘寶網十餘倍，這其中的緣由我相信你們都會知道。（注：由於頻繁刷新）

 

由於同一時刻訪問www.taobao.com的人數過於巨大，因此即使是淘寶首頁頁面的服務器，也不可能僅有一臺。僅用於生成www.taobao.com首頁的服務器就可能有成百上千臺，那麼你的一次訪問時生成頁面給你看的任務便會被分配給其中一臺服務器完成。（注：至關於學校有5個食堂，二食堂3窗口總是爆滿，由於打菜的是個萌妹子。）

 

這個過程要保證公正、公平、平均（注：這成百上千臺服務器每臺負擔的用戶數要差很少，就像食堂不能顛勺），這一很複雜的過程是由幾個系統配合完成，其中最關鍵的即是LVS(Linux Virtual Server)，世界上最流行的負載均衡系統之一，正是由目前在淘寶網供職的章文嵩博士開發的。

 

通過一系列複雜的邏輯運算和數據處理，用於此次給你看的淘寶網首頁的內容便生成成功了。

 

據消息稱，在雙十一當天高峯，淘寶的訪問流量最巔峯達到871GB/S（注：一秒鐘871GB，若是你電腦硬盤是500G的話，至關於一秒鐘，你的磁盤就被塞滿了）。這個數字意味着須要178萬個4Mb帶寬的家庭寬帶才能負擔的起，也徹底有能力拖垮一箇中小城市的所有互聯網帶寬。那麼顯然，這些訪問流量不可能集中在一塊兒。而且你們都知道，不一樣地區不一樣網絡（注：電信、聯通、教育網等）之間互訪會很是緩慢，可是你卻發現不多發現淘寶網訪問緩慢。這即是CDN(Content Delivery Network)，即內容分發網絡的做用。淘寶在全國各地創建了數十上百個CDN節點，利用一些手段保證你訪問的地方是離你最近的CDN節點，這樣便保證了大流量分散在各地訪問的加速節點上，指不定大家家這塊就有一個。

 

這便出現了一個問題，那就是假如一個賣家發佈了一個新的寶貝，上傳了幾張新的寶貝圖片，那麼淘寶網如何保證全國各地的CDN節點中都會同步的存在這幾張圖片供用戶使用呢？這裏邊就涉及到了大量的內容分發與同步的相關技術。淘寶開發了分佈式文件系統TFS(Taobao FileSystem)來處理這類問題。

 

好了，這時你終於加載完了淘寶首頁，那麼你習慣性的在首頁搜索框中輸入了 ’月餅’ 二字並敲回車，這時你又產生了一個PV，而後，淘寶網的主搜索系統便開始爲你服務了。它首先對你輸入的內容基於一個分詞庫進行分詞操做。衆所周知，英文是以詞爲單位的，詞和詞之間是靠空格隔開，而中文是以字爲單位，句子中全部的字連起來才能描述一個意思。例如，英文句子I am a student，用中文則爲：「我是一個學生」。計算機能夠很簡單經過空格知道student是一個單詞，可是不能很容易明白「學」、「生」兩個字合起來才表示一個詞。把中文的漢字序列切分紅有意義的詞，就是中文分詞，有些人也稱爲切詞。我是一個學生，分詞的結果是：我是一個學生。

 

進行分詞以後，還須要根據你輸入的搜索詞進行你的購物意圖分析。用戶進行搜索時經常有以下幾類意圖：

 

（1）瀏覽型：沒有明確的購物對象和意圖，邊看邊買，用戶比較隨意和感性。查詢例如：」2013年10大香水排行」，」2013年流行雪紡衫」， 「iPhone有哪一個牌子好？」；

 

（2）查詢型：有必定的購物意圖，體如今對屬性的要求上。查詢例如：」適合老人用的手機」，」500元手錶」；

 

（3）對比型：已經縮小了購物意圖，具體到了某幾個產品。查詢例如：」iPhone 5 三星蓋世三″，」三星 i9300 i9400″；

 

（4）肯定型：已經作了基本決定，重點考察某個對象。查詢例如：」iPhone5″，」蓋世三″。經過對你的購物意圖的分析，主搜索會呈現出徹底不一樣的結果來。

 

以後的數個步驟後，主搜索系統便根據上述以及更多複雜的條件列出了搜索結果，這一切是由一千多臺搜索服務器完成。而後你開始逐一點擊瀏覽搜索出的寶貝。你開始查看寶貝詳情頁面。常常網購的親們會發現，當你買過了一個寶貝以後，即使是商家屢次修改了寶貝詳情頁，你仍然可以經過‘已買到的寶貝’查看當時的快照。那麼顯然，對於每一年數十上百億比交易的商品詳情快照進行保存和快速調用不是一個簡單的事情。這其中又涉及到數套系統的共同協做，其中較爲重要的是Tair(注：淘寶自行研發的分佈式KV存儲方案)。

 

而後不管你是否真正進行了交易，你的這些訪問行爲便忠實的被系統記錄下來，用於後續的業務邏輯和數據分析。這些記錄中訪問日誌記錄即是最重要的記錄之一，可是前邊咱們得知，這些訪問是分佈在各個地區不少不一樣的服務器上的，而且因爲用戶衆多，這些日誌記錄都很是龐大，達到TB（注：1TB=1024GB）級別很是正常。那麼爲了快速及時傳輸同步這些日誌數據，淘寶研發了TimeTunnel，用於進行實時的數據傳輸，交給後端系統進行計算報表等操做。

 

你的瀏覽數據、交易數據以及其它不少不少的數據記錄均會被保留下來。使得淘寶存儲的歷史數據垂手可得的便達到了十數甚至更多個 PB(注：1PB=1024TB=1048576GB)。如此巨大的數據量通過淘寶系統1:120的極限壓縮存儲在淘寶的數據倉庫中。而且經過一個叫作雲梯的，由數萬臺服務器組成的超大規模數據系統不斷的進行分析和挖掘。

 

從這些數據中淘寶可以知道小到你是誰，你喜歡什麼，你的孩子幾歲了，你是否在談戀愛，喜歡玩魔獸世界的人喜歡什麼樣的飲料等，大到各行各業的零售狀況、各種商品的興衰消亡等等海量的信息。

 

你剛訪問了淘寶首頁，而淘寶卻作了這麼多事情。

 

說了這麼多，其實也只是敘述了淘寶上正在運行的成千上萬個系統中的寥寥幾個。即使是你僅僅訪問一次淘寶的首頁，所涉及到的技術和系統規模都是你徹底沒法想象的，是淘寶3000多名頂級的工程師們的心血結晶，其中甚至包括長江學者、國家科學技術最高獎得主等衆多大牛。一樣，百度、騰訊等的業務系統也毫不比淘寶簡單。你須要知道的是，你天天使用的互聯網產品，看似簡單易用，背後卻凝聚着不可思議的智慧與勞動。

 

整體分爲這麼幾個過程：

  • DNS解析
  • TCP鏈接
  • 發送HTTp請求
  • 服務器處理並返回HTTP報文
  • 瀏覽器解析渲染頁面
  • 鏈接結束

具體過程
一、DNS解析
DNS解析的過程就是尋找哪臺機器上有你須要資源的過程。當輸入www.baidu.com的時候，實際上是要找對應的ip地址，DNS充當了翻譯的角色，實現了網址到IP地址的轉換。由於互聯網上的每一臺計算機的惟一標識是它的IP地址。

解析過程:

DNS解析是一個遞歸查詢的過程。
圖片描述

圖片描述

首先在本地域名服務器中查詢IP地址，若是沒有找到的狀況下，本地域名服務器會向根域名服務器發送一個請求，若是根域名服務器也不存在該域名時，本地域名會向com頂級域名服務器發送一個請求，依次類推下去。直到最後本地域名服務器獲得baidu的IP地址並把它緩存到本地，供下次查詢使用。從上述過程當中，能夠看出網址的解析是一個從右向左的過程: com -> baidu.com -> www.baidu.com。可是你是否發現少了點什麼，根域名服務器的解析過程呢？事實上，真正的網址是www.baidu.com.，並非我多打了一個.，這個.對應的就是根域名服務器，默認狀況下全部的網址的最後一位都是.，既然是默認狀況下，爲了方便用戶，一般都會省略，瀏覽器在請求DNS的時候會自動加上，全部網址真正的解析過程爲: . -> .com -> baidu.com. -> www.baidu.com.。

二、TCP鏈接
三、 HTTP請求
其實這部分又能夠稱爲前端工程師眼中的HTTP，它主要發生在客戶端。發送HTTP請求的過程就是構建HTTP請求報文並經過TCP協議中發送到服務器指定端口(HTTP協議80/8080, HTTPS協議443)。HTTP請求報文是由三部分組成: 請求行, 請求報頭和請求正文。
請求行

格式以下:

Method Request-URL HTTP-Version CRLF

eg: GET index.html HTTP/1.1
經常使用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

TODO：

GET和POST有什麼區別？
請求報頭

請求報頭容許客戶端向服務器傳遞請求的附加信息和客戶端自身的信息。
PS: 客戶端不必定特指瀏覽器，有時候也可以使用Linux下的CURL命令以及HTTP客戶端測試工具等。
常見的請求報頭有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

請求正文

當使用POST, PUT等方法時，一般須要客戶端向服務器傳遞數據。這些數據就儲存在請求正文中。在請求包頭中有一些與請求正文相關的信息，例如: 如今的Web應用一般採用Rest架構，請求的數據格式通常爲json。這時就須要設置Content-Type: application/json。

四、服務器處理並返回HTTP報文
天然而然這部分對應的就是後端工程師眼中的HTTP。後端從在固定的端口接收到TCP報文開始，這一部分對應於編程語言中的socket。它會對TCP鏈接進行處理，對HTTP協議進行解析，並按照報文格式進一步封裝成HTTP Request對象，供上層使用。這一部分工做通常是由Web服務器去進行，我使用過的Web服務器有Tomcat, Jetty和Netty等等。

HTTP響應報文也是由三部分組成: 狀態碼, 響應報頭和響應報文。

狀態碼

狀態碼是由3位數組成，第一個數字定義了響應的類別，且有五種可能取值:

1xx：指示信息–表示請求已接收，繼續處理。
2xx：成功–表示請求已被成功接收、理解、接受。
3xx：重定向–要完成請求必須進行更進一步的操做。
4xx：客戶端錯誤–請求有語法錯誤或請求沒法實現。
5xx：服務器端錯誤–服務器未能實現合法的請求。平時遇到比較常見的狀態碼有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500(分別表示什麼請自行查找)。
TODO:

301和302有什麼區別？
HTTP緩存
響應報頭

常見的響應報頭字段有: Server, Connection...。

響應報文

服務器返回給瀏覽器的文本信息，一般HTML, CSS, JS, 圖片等文件就放在這一部分。

五、瀏覽器解析渲染頁面

https://segmentfault.com/a/1190000011564089

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程