數據包嗅探器 - 追溯到內容的起源地

Question

我使用sniffex.c作爲我的出發點，並且我花了幾個月的時間努力讓數據包嗅探器以我想要的方式工作。這是一個很好的工具，用於提供網絡中每臺計算機的流量彙總概要，但是我發現自己希望獲得有關入站流量來源的更多信息。如果我在樣本入站數據包的src_ip上執行whois，大多數情況下我會收到Qwest Communications Company，LLC或AKAMAI TECHNOLOGIES INC擁有的主機的信息，這些主機並不真正向我提供我感興趣的信息。

在這一點上，我有興趣跟蹤數據來自哪裏，如youtube或espn ......如何做到這一點？

反向dns查找聽起來像我正在尋找的，但如果我採取src_ip，我收到了一個體面的數據塊，並把它放在一個在線反向dns搜索表單，我所得到的是，它是由qwest擁有。

編輯＃1：

OK，我現在有怎麼問這個問題的一個更好的主意，這要歸功於以下蓋伊·哈里斯的回答。正如他所說，每個數據包中的ASCII數據應該有一個「主機：」行，這應該能夠提供更直接的信息，說明這些數據的來源在更高層次上。現在我該如何獲得這些數據？解析ascii文本是最好的方法，還是有現有的函數來獲取這些數據？

編輯＃2：

好，解析無論是有效載荷或頭ASCII似乎是一個死衚衕。我找到了非常有用的libpcap應用程序here的來源。該程序將以上所有內容打印到日誌文件中。仔細查看這些數據，我發現很少數據包有「主機：」字段。顯然只有TCP端口80的數據包，然後纔是該系列中的第一個數據包。即使那樣，我發現只有這個主機領域的人才能在我的網絡上的一個盒子上由網絡服務器提供服務。

因此，我現在要求完全不可能弄清楚許多不同網站的內容可能會緩存在單個主機上？

Answer 1

奎斯特（誰被CenturyLink購買）是一個ISP（和CenturyLink仍然是）。例如，有些公司可能會將它們用作託管ISP，因此諸如對www.example.com的HTTP請求等請求實際上由Qwest的/ CenturyLink的服務器之一處理，所以如果您從www.example下載的話。您實際上是從Qwest/CenturyLink擁有的服務器下載的，其IP地址也屬於Qwest/CenturyLink。

Akamai是一家爲組織提供基礎設施的公司，該組織希望爲人們提供批次下載材料;該組織將arrange that the domain name for their server will actually resolve to an IP address for Akamai，所以如果你認爲你從www.example.com下載，你實際上是從Akamai的一臺服務器上下載的，其IP地址也屬於Akamai。

因此，來自www.example.com的回覆下載請求（例如HTTP GET請求）的入站數據包的源IP地址可能是屬於Qwest或Akamai的主機的IP地址 - 那真的是是真正開始流量的主機！

如果它屬於Qwest，則Example Inc.的Web服務器實際上可能存儲在Qwest IP地址的Qwest機器上，而不是Example Inc.所擁有的機器上。並使用Example Inc.所擁有的範圍內的IP地址（Example Inc.可能比管理服務器和專用IP地址的範圍更適合其資源）。

如果它屬於Akamai的，它具有下載的材料，通過實例公司，誰與Akamai簽約，提供內容緩存提供的副本。

關於您可以做的確定哪些材料實際上正在下載的內容，例如，請查看客戶端爲確定IP地址所做的DNS請求（以便您看到「www.example.com」在DNS請求中，而不是僅僅看到Qwest/Akamai /爲DNS請求返回的任何IP地址）和/或至少對於HTTP而言，HTTP 1.1請求中的「主機：」頭（其還將包含域名稱）。

而且，在一般情況下，在下載過程中的某個任意點開始捕獲的情況下，始終可以找出而不是，以便找出正在下載的內容的「原始」來源。

的Host：頭只會出現在最初的HTTP請求，所以如果你沒有在時間捕捉交通初始HTTP請求提出，或者如果下載的是不是一個HTTP請求的結果，你運氣不好。

DNS請求將在下載開始之前完成 - 並且，由於DNS解析器可以緩存DNS請求的結果，所以在下載開始之前它可能已經花費了相當長的時間 - 因此，如果您不是「在獲得DNS請求時捕獲，你的運氣不好。