Google.com 和 clients1.google.com/generate_204

Question

我正在查看 google.com 在 firebug 中的網絡活動，只是因為我很好奇並注意到請求返回“204 No Content”。

事實證明，“204 No Content”主要是為了允許在不改變用戶代理的活動文檔視圖的情況下進行操作的輸入，盡管任何新的或更新的元信息都應該應用於當前在用戶代理的活動文檔中的文檔。看法。” 任何。

我查看了 JS 源代碼，看到“generate_204”是這樣請求的：

(new Image).src="http://clients1.google.com/generate_204"

根本沒有變量聲明/賦值。

我的第一個想法是它被用來跟蹤是否啟用了 Javascript。 但是無論如何，“(new Image).src='...'”調用是從動態加載的外部 JS 文件中調用的，因此這毫無意義。

任何人對這點可能有什么想法？

更新

“/generate_204”似乎在許多谷歌服務/服務器上可用（例如，maps.google.com/generate_204、maps.gstatic.com/generate_204 等...）。

您可以通過為您的網絡應用程序可能使用的每個谷歌擁有的服務預取 generate_204 頁面來利用這一點。 像這樣：

window.onload = function(){
    var two_o_fours = [
        // google maps domain ...
        "http://maps.google.com/generate_204",

        // google maps images domains ... 
        "http://mt0.google.com/generate_204",
        "http://mt1.google.com/generate_204",
        "http://mt2.google.com/generate_204",
        "http://mt3.google.com/generate_204",

        // you can add your own 204 page for your subdomains too!
        "http://sub.domain.com/generate_204"
    ];
    for(var i = 0, l = two_o_fours.length; i < l; ++i){
        (new Image).src = two_o_fours[i];
    }
};

Answer 1

我在谷歌搜索 generate_204 時發現了這個舊線程，因為 Android 似乎使用它來確定 wlan 是打開（收到響應 204）關閉（根本沒有響應）還是被阻止（重定向到強制門戶）。 在這種情況下，會顯示需要登錄 WiFi 的通知...

Answer 2

就像 Snukker 所說，clients1.google.com 是搜索建議的來源。 我的猜測是，他們會在您需要之前請求強制 clients1.google.com 進入您的 DNS 緩存，因此您在第一個“真實”請求上的延遲會更少。

谷歌瀏覽器已經對頁面上的任何鏈接執行了此操作，並且（我認為）當您在地址欄中鍵入地址時。 這似乎是讓所有瀏覽器都做同樣事情的一種方式。

Answer 3

如果 Chrome 檢測到 SSL 連接超時、證書錯誤或其他可能由強制門戶（例如酒店的 WiFi 網絡）引起的網絡問題，Chrome 將向http://www.gstatic發出無 cookie 請求。 com/generate_204並檢查響應代碼。 如果該請求被重定向，Chrome 將假設它是一個登錄頁面，在新選項卡中打開重定向目標。 不會記錄對強制門戶檢測頁面的請求。

來源：Google Chrome 隱私白皮書

Answer 4

谷歌正在使用它來檢測設備是在線還是在強制門戶中。

Chromium OS 的連接管理器 Shill 嘗試在服務轉換到就緒狀態時檢測強制門戶內的服務。 通過嘗試檢索網頁http://clients3.google.com/generate_204來確定是否處於強制門戶中或在線。 眾所周知，這個眾所周知的 URL 會返回一個帶有 HTTP 狀態 204 的空頁面。如果由於任何原因沒有返回網頁，或者收到了 204 以外的 HTTP 響應，則 shill 將服務標記為處於門戶狀態。

以下是Google Chrome 隱私白皮書中的相關解釋：

如果 Chrome 檢測到 SSL 連接超時、證書錯誤或其他可能由強制門戶（例如酒店的 WiFi 網絡）引起的網絡問題，Chrome 將向http://www.gstatic發出無 cookie 請求。 com/generate_204並檢查響應代碼。 如果該請求被重定向，Chrome 將假設它是一個登錄頁面，在新選項卡中打開重定向目標。 不會記錄對強制門戶檢測頁面的請求。

更多信息： http : //www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

Answer 5

有時在 AJAX 中使用 204 響應來跟蹤點擊和頁面活動。 在這種情況下，在 get 請求中傳遞給服務器的唯一信息是 cookie 而不是請求參數中的特定信息，所以這里似乎不是這種情況。

似乎clients1.google.com 是谷歌搜索建議背后的服務器。 當您訪問http://www.google.com 時，cookie 會傳遞到http://clients1.google.com/generate_204 。 也許這是在服務器上啟動某種會話？ 不管有什么用途，我懷疑這是一個非常標准的用途。

Answer 6

谷歌為阻止垃圾郵件和搜索數據庫的抓取做出了大量的努力，我相信這是跟蹤機器人等工作的一部分。

一些簡單的反機器人偽代碼可能會像這樣。

On GET (google.*) Save RemoteEndPoint
{
    If RemoteEndPoint GETs (clients1.google.com/generate_204) Then
        Set botAlert_stage1 = false;
    Else
        Set botAlert_stage1 = true;
    End If
}

我也相信最新的谷歌首頁“主題”也是一個幫助反垃圾郵件/機器人活動的新工具。

** 注意** ipv6.google.com 也包括此措施。

只是我毫無根據的未經證明的兩個2p。

Answer 7

許多應用程序訪問此 URL 以確定它們是否具有僅指向強制門戶的連接。

這個想法是任何強制門戶都認為這是一個“正常”的網站，然后將您重定向到其門戶站點，該站點返回狀態 200。如果應用程序嘗試訪問任何正常網站，它會遇到完全意想不到的響應，並且可能無法找出問題所在。 但是，使用此 URL 很容易：如果您獲得狀態 200，則您處於強制門戶內，您可以告訴您的用戶對其進行處理（通常使用瀏覽器登錄門戶，或關閉 WiFi 並依賴在 3G 上，如果他們使用的是電話）。 如果您獲得狀態 204，則您已連接到 Google，因此您的應用程序實際上已連接到 Internet。

微軟和蘋果使用的方法略有不同； 它們都有一些返回狀態為 200 的非常具體的短文本消息的 URL，因此您可以訪問“captive.apple.com”並檢查狀態為 200 的數據為“成功”和沒有其他的。 如果您獲得狀態 200 而不是該數據，那么您將再次處於強制門戶中。

Answer 8

該文件說明：

http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1417&context=ecetr&sei-redir=1

（搜索 generate204 ）

相關欄目：

在不同的對象中，一個 javascript 函數觸發一個generate204請求，該請求發送到應該提供視頻的視頻服務器。 這將啟動視頻預取，它有兩個主要目標：首先，它強制客戶端執行視頻服務器名稱的 DNS 解析。 其次，它強制客戶端打開一個到視頻服務器的 TCP 連接。 兩者都有助於加快視頻下載階段。

此外， generate204請求與真實視頻下載請求具有完全相同的格式和選項，因此最終會警告視頻服務器客戶端可能很快就會下載該視頻。 請注意，視頻服務器回復204 No Content響應，正如命令所暗示的那樣，到目前為止還沒有下載任何視頻內容。

Answer 9

我發現這篇博文解釋了它用於記錄點擊次數。 沒有來自谷歌的官方消息，它可以用於任何數量的東西。

http://mark.koli.ch/2009/03/howto-configure-apache-to-return-a-http-204-no-content-for-ajax.html

Answer 10

生成器204可能正在動態加載搜索標准的建議。 正如我從我的負載測試腳本中看到的那樣，這似乎負責每次用戶在文本框中鍵入時的每個服務器調用

Answer 11

好吧，我已經看了好幾次了，結果谷歌記錄了他們第一次訪問 google.com 的來源； 使用 Google Chrome 跟蹤我有 90% 的猜測是用於Logging Referers ，也許當 Google 發布其瀏覽器使用標准列表時，用戶代理統計數據是眾所周知的：

• 請求網址： http : //clients1.google.se/generate_204

• 請求方式： GET

• 狀態碼： 204 無內容

響應頭

• 內容長度：0
• 內容類型：文本/html
• 日期：2010 年 5 月 21 日星期五 17:06:24 GMT
• 服務器：GFE/2.0

這里“ ^Request Headers ”下的“ Referer ”顯示了許多人來自Microsoft.com 的Google 統計數據，還解析出“ Windows 7 ”一詞以幫助我在該會話的后續搜索中專注於 Windows 7

//史蒂文