前言
想必有些朋友和我一樣，想要弄清楚當使用瀏覽器訪問一個站點時，究竟向那些站點發起了 HTTP 請求；站點的 HTTP 響應；這些站點的域名是否和 shell 終端輸出的 socket 套接字IP地址對應得上；這些站點使用的域名，IP地址，物理地址，域名擁有者和IP地址擁有者之間的聯繫；系統當前是否存在惡意或非法的網絡連接。。。等等。
本博文就是要以隨手取得的開源工具，並且用一種可實際操作的標準化流程，來達到上述種種分析任務的目標。
這套工具集與流程，以及思路，適用於你想分析的任何對象（這裏指站點），並且這裏提出的方法僅作爲拋磚引玉，最終目的是激發大家對相關技術的思考，研究出更好的調試，分析方法，從而徹底明白訪問站點時發生的事情。
準備工具
firefox 或其它瀏覽器內建的 web開發者工具
（這裏使用 firefox 的開發者工具，不使用 firebug 插件的原因是它的“網絡”分析模塊沒有 firefox 內建的開發者工具來得“強大”）
我們主要通過它的“網絡”模塊，查看當訪問一個站點時，瀏覽器向哪些 URL 併發的 HTTP 請求內容，以及站點的 HTTP 響應內容，然後在它的“查看器”模塊中，定位引發瀏覽器請求其它 URL 的相應 HTML 標籤
firefox 的 noscript 插件
需要額外安裝，詳見後文；
用於禁止或允許站點的腳本以及跨域腳本，可以阻止，攔截，以及淨化惡意站點存在的各種類型跨站腳本；我們用它來分析加載一個站點的腳本前後的 socket 套接字 IP 地址列表，對比前後的差異
shell 命令行工具 dig
CentOS6.5 默認安裝，可以通過 yum 或者 rpm ，或者官方網站更新到最新版；
作爲 DNS 解析的本地客戶端，向因特網上的 DNS 服務器發送解析請求；
我們利用它來將開發者工具“網絡”模塊列出的域名，與 shell 終端執行 netstat 輸出的 socket 套接字的 IP 地址，對應起來；當然你也可以使用 nslookup ，甚至 windows 平臺的 nslookup，不過它沒有 dig 強大
APNIC（Asia-Pacific Network Information Centre，亞太互聯網絡信息中心） 的 whois 數據庫查詢頁面
CNNIC（China Internet Network Information Center，中國互聯網絡信息中心） 的 whois 數據庫查詢頁面
其它提供 whois 查詢以及站點相關信息查詢服務的站點
http://www.wmtips.com/tools/info/
上述這些站點用於查詢對象的域名註冊信息，IP地址註冊信息，網絡範圍，網絡塊大小，物理地址，AS自治域號碼（如果有申請）等等，對於深入理解站點的背景信息甚至網絡拓撲至關重要。
接着，以我個人的博客首頁 URL 地址爲測試用例來介紹標準化的分析流程；在這之前，需要下載，安裝 firefox 的 noscript 插件，官方下載地址：
參考如下截圖：
確認已經安裝並啓用 noscript，以 firefox 訪問
http://shayi1983.blog.51cto.com/
注意底部 noscript 的狀態欄，左側是當前頁面允許或禁止的腳本和所有用於引入腳本的 HTML 標籤數量統計；單擊右側選項可以單獨允許或禁止當前頁面引入的某個同域或跨域的腳本，
爲了測試方便，我們將包括 shayi1983.blog.51cto.com 站點在內的所有站點引入的腳本全部攔截，然後刷新頁面，並且打開一個 shell 終端，執行
netstat -antupeo 命令，查看打開的網絡連接：
各位大牛可能都已經猜到接下來的流程了：使用 dig 工具，對上面9個廣域網 IP 進行反向 DNS 解析，查詢其對應的域名，並且結合 APNIC 與 CNNIC 的 whois 數據庫查詢，闡明這些域名與 shayi1983.blog.51cto.com 站點的（利益）關係；
先彆着急，我們還沒用到 firefox 開發者工具的“網絡”模塊，分析在訪問
shayi1983.blog.51cto.com 站點時，瀏覽器都向哪些 URL 發起了 HTTP 請求，記下這些 URL 的“主機名”部分，利用 dig 對這些主機名進行正向 DNS 解析，將結果的 IP 地址與上面 9 個廣域網 IP 進行驗證，如果要進一步獲取信息，再使用
whois 數據庫。這就是整個分析調試的流程。
回到主題，我們整理彙總了在訪問 shayi1983.blog.51cto.com 站點時，瀏覽器請求的所有站點列表，用 dig 對這個列表中的每個主機名進行 DNS 解析，將結果與 shell 的輸出比對；對於你想分析的任何其它站點，這個方法都是適用的，注意， noscript 可以讓你挖掘到更多的站點引用信息：
shayi1983.blog.51cto.com blog.51cto.com home.51cto.com p_w_picpaths.51cto.com img1.51cto.com ucenter.51cto.com log.51cto.com ad.doubleclick.net new.51cto.com s3.51cto.com d.agkn.com v.admaster.com.cn
這裏要解釋一下 ad.doubleclick.com , d.agkn.com , v.admaster.com.cn
這三個站點。根據開發者工具的網絡模塊顯示，在訪問 shayi1983.blog.51cto.com
的時候，瀏覽器都向這3個站點發起了 HTTP 請求，爲什麼我們用 noscript 禁用了所有腳本，竟然還有跨域請求？
問題出在前述的 noscript <iframe> 過濾漏洞（暫且這麼稱呼）；因爲某種未知原因， noscript 沒能過濾掉 <iframe> 引入的內容，導致瀏覽器向引入的目標站點，即 log.51cto.com ，發起 HTTP 請求；
而在開發工具中查看瀏覽器向這3個第三方站點發起的 HTTP 請求信息，其 “Referer”請求頭的值，剛好就是 log.51cto.com ，意味着當 firefox 請求 log.51cto.com 的 pageview.php web 應用程序時，返回的 HTML 頁面中，又引入了這3個站點的內容，並且 noscript 沒能及時阻止，導致 firefox 訪問這3個站點，對應的套接字 IP 地址可以在 shell 中驗證；
同時這也驗證了“木桶原理”這條安全業界準則，試想一下，如果這些第三方域，繼續引入其它站點的內容，形成龐大的站點引用樹，最終不可避免的將會引入惡意站點的 javascript 腳本，導致用戶 cookie 劫持，個人信息被竊，下載網頁***等嚴重後果。
在這個場景中，noscript 安全功能強大，但是其 <iframe> 過濾漏洞，恰恰成了最短的那塊木板。
下面就是整個 DNS 查詢的結果，過程比較枯燥，但是對於一些知識點和需要重視的地方，還是會在截圖中註明：
看到這裏，如果你已經覺得頭暈了，那麼我們把這個前因後果，三方之間（ 51cto，帝聯，光環新網）的關係整理總結如下：（ 全部依賴個人的推測，如果有錯誤之處還懇請同行指正 ）
一，上海帝聯科技股份有限公司，是一家提供IDC機房服務器託管，以及 CDN （內容分發網絡）加速的運營商，它首先向 APNIC 申請租用 IP 地址，前者被分配到的地址塊是119.254.112.0/20( IP 子網劃分後的結果爲119.254.112.0-119.254.127.255)，實際的分配動作，可能是APNIC，也可能是 CNNIC，
二，帝聯通過（租用） 北京光環新網科技股份有限公司這家 ISP 的服務 ，接入互聯網，光環新網將這個網段與它被分配到的 AS 自治域號碼 AS23844（這個AS號碼可能是光環新網向 CNNIC 申請的） ，關聯起來，用於 BGP互聯，實現將該網段路由至 CSTNET（中國科技網）這個國內的骨幹網上，再通過這個骨幹網與國內其它骨幹網，以及 Internet 互通互連。
這樣就實現了向帝聯提供接入服務。
三，51cto 向帝聯租用 CDN 加速服務，後者向前者提供一臺 IP 爲 119.254.116.18 的服務器，用於圖片緩存，從表面上看，只有這一臺服務器，但實際上，即便是用於加速圖片下載的服務器，後端也有大量的內網服務器集羣來實現負載均衡；
光這樣還不行，既然我們可以通過 CNAME 域名訪問到這臺服務器和它的內網集羣，說明帝聯有向其它提供域名申請的廠商，將這個 IP 與 51cto.ghcdn.cn 關聯起來，後者負責將這條資源記錄寫入其自身維護的區數據文件，簡單的講，
負責 ghcdn.cn 域的權威名字服務器，其區數據文件中，應該就保存着這一條映射記錄，
最後，51cto 的開發人員，將這個 CNAME 域名通過 HTML <img> 標籤的 src 屬性，引入到頁面 HTML 源碼中，這個過程也有可能是和發佈博客相關的 web 應用程序在用戶提交博文時，自動完成的，具體可能是由判斷用戶是否勾選“置頂”複選框的代碼邏輯執行，當然相關代碼是由開發人員編寫的。
這樣，當其它用戶訪問該頁面時，例如我這裏的 firefox 先向谷歌的 DNS 服務器 8.8.8.8 請求解析 img1.51cto.com 的 IP 地址，如果 8.8.8.8 在它的本地緩存中有這條記錄，而且記錄沒有過期，那它就直接發給客戶端；假設 8.8.8.8 不知道這個域名的 IP ，它總知道“根名字服務器”的 IP 吧 ？
（A）8.8.8.8 可能親自向分佈在全世界各地的 13臺“根名字服務器”其中一臺，請求解析 img1.51cto.com 的 IP 地址，或者
（B）8.8.8.8 向客戶端返回其中一臺的 IP，要客戶端自己向這個根名字服務器請求解析 img1.51cto.com
(A)叫做 DNS 遞歸解析；(B)叫做 DNS 迭代解析
不管是遞歸還是迭代，任何一臺根名字服務器，肯定知道負責 com. 這個 gTLD（通用頂級域）的權威名字服務器的其中一臺的 IP ，對於遞歸解析，它親自向其中一臺發起查詢；對於迭代解析，它將其中一臺的 IP 通過 DNS 應答，發給客戶端，叫客戶端自己去查；
因爲 com. 是 . 的子域；而 51cto.com. 是 com. 的子域，因此負責 com. 域的任何一臺權威名字服務器，應該都知道負責 51cto.com. 域的權威名字服務器的 IP ，所以，負責 com. 域的權威名字服務器，可能親自去查（遞歸），也可能向本地客戶端，返回負責 51cto.com. 域的名字服務器 IP ，要其自己去查（迭代），
需要注意的是，對於遞歸解析，查詢結果會從負責 51cto.com. 域的名字服務器（到這裏纔會產生實際的查詢結果）逐級返回至根名字服務器，然後再返回到遞歸解析請求的起始點，即 8.8.8.8，最後，由它將查詢結果交給客戶端。
不管是那種方式，51cto.com. 域的權威名字服務器，肯定知道 img1.51cto.com 的 IP ，只要得到這條資源記錄，那麼本地客戶端就可以向該 IP 發起 HTTP 請求，而 img1.51cto.com 與 51cto.ghcdn.cn 指向同樣的 IP ，因此也可以直接請求解析 51cto.ghcdn.cn，只是它的整個解析流程會涉及到負責 cn. 這個國家頂級域的權威名字服務器；
關於這一點，下面通過 dig 的一個追蹤 DNS 解析過程的參數：trace 就可以非常直觀的展現，有興趣的朋友也可以自行研究搜索介紹 dig 使用的文章:
看完上面這張圖後，你發現存在問題了嗎？
如果 dig 的追蹤和輸出結果無誤，那麼上面的截圖表示，最終由 180.153.162.151 這臺名字服務器返回查詢結果，但結果僅僅是一個 CNAME 域名，我們知道，因特網上的主機，最終是要依賴 IP 地址進行路由訪問的，因此必須知道 51cto.ghcdn.cn 的 IP 地址，
如果是 dig ，那也就算了，因爲它已經完成交給它的任務：追蹤解析 img1.51cto.com 的過程，即便最後結果是 CNAME，它也不在意；
但是對於瀏覽器而言，那就不一樣了，它被賦予的任務是從這臺主機下載圖片，並展現給用戶，這需要知道實際的 IP 地址才行（排除本地緩存的例外情況）；
因此，我個人推測：瀏覽器需要向 8.8.8.8 ，請求解析 51cto.ghcdn.cn 的 IP 地址，因此除了經歷類似上面 dig 的解析過程外，還涉及和 cn. 這個國家頂級域相關的解析鏈（當然可以用 wireshark 驗證是否正確，留給各位課後練習）
下面，給出一張用 dig 追蹤解析 51cto.ghcdn.cn IP 地址的過程，來模擬瀏覽器可能的相同行爲：
下面給出一張查詢“負責 ghcdn.cn. 域的權威名字服務器”與“負責 51cto.com.域的權威名字服務器”結果的截圖，
提醒一下，這裏只是爲了交流技術，嚴格禁止，並且對用截圖中給出的信息，向目標進行 DNS 區域數據文件傳送，DNS 緩存下毒，僞造源IP的查詢反射 DDOS，等***行爲帶來的後果不承擔任何法律責任：
*****補充知識點：關於 SOA（起始授權記錄），權威回答與非權威回答
用最通俗的解釋，SOA 就是負責某個域的名字服務器的記錄；通常，一個域可能會有多個名字服務器來負責，但是其中只有一個名字服務器的優先級別最高，SOA 就記錄了這個至高無上的名字服務器的信息；
如果我們（客戶端 DNS 解析程序）直接向負責某個域的名字服務器其中之一，查詢該域的任何信息，那麼得到的響應會表明是權威回答，因爲它就負責維護這個域中所有主機-域名到 IP 地址的映射關係；這每一條映射稱爲“資源記錄”；包含該區所有資源記錄的文件稱爲“正向解析的區數據文件”；
如果我們向任何其它不屬於這個域的名字服務器，查詢該域的信息，得到的響應會表明是非權威回答，因爲這些第三方名字服務器可能返回它們本地緩存的記錄；
下面用截圖來說明這些概念：
爲了更深入理解，我們再舉個例子，如下：
好了，經過上面一連串的努力，總算對 img1.51cto.com 這個域名的前世今生有了稍微清晰一點的認識，我們繼續把前面 netstat 命令輸出中，剩餘的5條 IP 地址記錄，解釋清楚，作爲本篇博文的結束：