2 相同的 HTTP 請求給出不同的結果？

Question

這兩個請求有什么區別，導致它們從服務器獲得不同的結果/響應，盡管它們應該是相同的？

1. 簡單點擊/導航后由 Chrome 發起的請求（成功，響應碼為 302）
2. 我只是將該請求復制為 curl 並將其導入 Postman 然后 postman 掛起

我對 Java - HttpUrlConnection（模仿所有請求標頭和 cookies 就像 Chrome 發送一樣）做了同樣的事情，但它掛起並永遠等待。 這僅僅是因為服務器邏輯不接受非瀏覽器客戶端嗎？

以下是我嘗試的步驟：

1. Visited this link: https://www.tokopedia.com/p/handphone-tablet/handphone
2. I opened the inspector and opened the Network - All tab
3. I clicked one of the products
4. I clicked the top request from the Network - All tab
5. I copied it as cURL bash
6. I imported it to Postman
7. I ran that request
8. Postman hanged

Answer 1

確保發送完全相同的數據的唯一方法是自己通過 telnet 之類的方式手動發送。 我曾經遇到過類似的問題 - 結果是瀏覽器正在發送一大塊數據，而我的代碼是逐行發送數據。 沒有網站應該有這個問題，但它可能存在。

Answer 2

服務器可能正在檢查用戶代理請求 header並將阻止不是來自瀏覽器的流量。 嘗試將 header 中的curl或您的 Java 代碼設置為對應於（任何）瀏覽器的值。 我在一些電子商店和商業網站上遇到過這種行為。

Answer 3

實際上，問題甚至可能比其他答案所說的更深。

因此，用戶代理請求 header 和 telnet 都不能解決該問題（除非您也使用 telnet 手動初始化 TLS 握手，但這幾乎不可能完成）。

TLS 指紋識別

如果連接是 SSL/TLS 連接，服務器可以檢測使用哪種算法生成密鑰，並且大多數應用程序都有其特定的簽名/密碼。

因此，僅通過 TLS 握手，您就可以從 Postman 或 FireFox 或 Java 中分辨出 Chrome。 Java 通常 - 除非 JVM 實現真的想要 go 越野 - 在所有平台上具有相同的簽名，在所有平台上使用相同的密碼/算法。

很抱歉，我無法正確回憶這種技術的名稱。 我知道發布的第一個項目稱為“A3”或“S3”。 Salesforce發表了一篇關於JA3分析的文章。 他們描述了該技術並顯示了簽名和應用程序列表，因此您可以猜測您正在與之交談的應用程序，甚至無需解密數據： https://engineering.salesforce.com/tls-fingerprinting-with-ja3 -and-ja3s-247362855967

我的解決方案

我也有同樣的問題，想掃描 NVidia 或 AMD 服務器的顯卡可用性。 從 Java 沒有工作，所以經過大量研究，找到上面提到的項目，我只是使用 Selenium 來控制 FireFox 並以這種方式得到了我的目標服務器響應。