Android 浏览器发送“Dalvik”作为用户代理
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/23804278/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Browser sending "Dalvik" as user agent
提问by Austin N
Android Browsersis sending Dalvik as the user agents in the request headers.
Android 浏览器将 Dalvik 作为请求标头中的用户代理发送。
I am currently working on a mobile site having a simple login page that validates username and password then authorizes users profile.
我目前正在一个移动网站上工作，它有一个简单的登录页面，可以验证用户名和密码，然后授权用户配置文件。
But when i checked the request headers i saw something unusual, there were two user agents from the same device.
但是当我检查请求标头时，我看到了一些不寻常的东西，有两个来自同一设备的用户代理。
Following are the user-agents from the same device:
以下是来自同一设备的用户代理：
"Mozilla/5.0 (Linux; Android 4.1.2; C5303 Build/12.0.A.1.257) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.114 Mobile Safari/537.36"
"Dalvik/1.6.0 (Linux; U; Android 4.2.2; C2004 Build/15.2.A.2.5)"
Even something strange the cookies that were initialed we either reset or dropped.
甚至一些奇怪的 cookie 被我们要么重置要么丢弃。
Is there any way i can debug this further for more information and get a better view on this issue??
有什么方法可以进一步调试它以获取更多信息并更好地了解这个问题？
This issue is not seen in old android phones or ios or windows phones.
此问题在旧的 android 手机或 ios 或 windows 手机中看不到。
**Issue noticed in high end android mobile handsets having KitKat/JellyBean OS
**在具有 KitKat/JellyBean 操作系统的高端安卓手机中注意到的问题
回答by Michael Levy
I just noticed a similar pattern of User-agents for back to back requests. In my case, the first request (with the Mozilla User agent) was from an embedded webview. The requested URL was to download a PDF file. What I've found is that the Android webview cannot handle the PDF content type, so it launches a PDF viewer through an intent. However, before this viewer is launched Android makes a second request for the same URL. In the second request, the Dalvik user agent is presented.
我刚刚注意到一种类似的用户代理模式用于背靠背请求。就我而言，第一个请求（使用 Mozilla 用户代理）来自嵌入式 web 视图。请求的 URL 是下载 PDF 文件。我发现 Android webview 无法处理 PDF 内容类型，因此它通过意图启动 PDF 查看器。但是，在此查看器启动之前，Android 会针对同一 URL 发出第二次请求。在第二个请求中，显示了 Dalvik 用户代理。
The two request strangeness has been discuss before, see Is setDownloadListener onDownloadStart called after the webview already Gets the file?and WebView - can't download file without requesting it twice?.
这两个请求的怪异之前已经讨论过了，见webview已经获取文件后调用setDownloadListener onDownloadStart吗？和WebView - 不能在没有请求两次的情况下下载文件？.
In my first request, from the webview, I see the user agent:
在我的第一个请求中，从 webview 中，我看到了用户代理：
Mozilla/5.0 (Linux; U; Android 4.2.2; en-us; Galaxy Nexus Build/JDQ39) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Mozilla/5.0 (Linux; U; Android 4.2.2; en-us; Galaxy Nexus Build/JDQ39) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
The second request (which I assume is from the Android OS, and not the webview) shows the user agent:
第二个请求（我假设来自 Android 操作系统，而不是 webview）显示了用户代理：
Dalvik/1.6.0 (Linux; U; Android 4.2.2; Galaxy Nexus Build/JDQ39)
Dalvik/1.6.0（Linux；U；Android 4.2.2；Galaxy Nexus Build/JDQ39）
回答by Chris Halcrow
- Dalvik is the Android VM in which individual apps run.
- What you're seeing is the request header from a browser running in Android (which runs within Dalvik).
- Hence the two UA (User Agent) strings, one for the browser, one for the VM in which it's running.
- Dalvik 是运行单个应用程序的 Android VM。
- 您看到的是来自在 Android 中运行的浏览器（在 Dalvik 中运行）的请求标头。
- 因此有两个 UA（用户代理）字符串，一个用于浏览器，一个用于运行它的 VM。
回答by Hugh Buntu
I've been seeing a rapidly increasing incidence of simultaneous GET requests with this profile on streaming servers in the past 6 months, but going back a few years with much lesser volume. It was easy to ignore them at first. The client pumps many simultaneous requests (I see 60-80 typically), and then it appears the client runs out of bandwidth; requests stall, subside, and then re-emerge. This goes on for several minutes. If multiple attacks of this sort were launched from different IPs on different Eyeball networks, it would start to qualify as a DDoS attack in my book.
在过去的 6 个月里，我看到在流服务器上使用此配置文件同时 GET 请求的发生率迅速增加，但几年前的数量要少得多。一开始很容易忽略它们。客户端同时发送许多请求（我通常看到 60-80），然后客户端似乎用完了带宽；请求停止，消退，然后重新出现。这会持续几分钟。如果这种类型的多次攻击是从不同 Eyeball 网络上的不同 IP 发起的，那么在我的书中，它就会开始被视为 DDoS 攻击。
Because the sources are on eyeball networks with ever changing IP's (over time, but not during an attack), using IP blocking is of limited effectiveness, and blocks need to be aged-out so they don't affect legitimate users.
由于来源位于 IP 不断变化的眼球网络上（随着时间的推移，而不是在攻击期间），使用 IP 阻止的效果有限，并且阻止需要老化，以免影响合法用户。
Your observation that cookies are not observed in any way would seem to lend weight to the possibility that these are malicious requests.
您对 cookie 未以任何方式观察到的观察似乎加重了这些是恶意请求的可能性。
In conclusion, to answer your question simply, yes, you can block these requests, especially since you have evidence that these may be malicious requests (that have been rising steadily since your post in my experience). You may, of course, be blocking legitimate requests. That's your call. You'll also have to deal with howto block them, since in my experience they originate mostly from DHCP leased addresses on eyeball networks.
总之，简单地回答您的问题，是的，您可以阻止这些请求，特别是因为您有证据表明这些请求可能是恶意请求（根据我的经验，自您的帖子以来一直在稳步上升）。当然，您可能会阻止合法请求。那是你的电话。您还必须处理如何阻止它们，因为根据我的经验，它们主要来自眼球网络上的 DHCP 租用地址。
