某些 AWS 实例上的 Google c2dm 瞬态 401 错误

Question

当要求 c2dm 发送通知时，我们如何弄清楚为什么我们会在某些AWS实例上从Google c2dm推送服务中偶尔收到 401 错误？

这是一个暂时性的问题。所有 AWS 实例在向 Google c2dm 发送 HTTPS 请求时大多成功，有些实例 100% 的时间成功，有些实例偶尔会收到 401。因此，我们不认为这是我们的 c2dm 注册或我们已投入生产一年多的通知代码 (python) 的问题。401 错误始于 2012 年 5 月 16 日。

相反，我们认为 Amazon 基础设施中的某些东西，包括 DNS 缓存，可能以某种方式参与了这个问题。谷歌亲切地回复了我们的询问：

我会寻找可能导致不稳定通信的东西。尝试看看您是否在该机器的网络适配器上收到异常数量的损坏或丢失的数据包。

但是，我们没有看到任何“片状通信”的证据。出现问题时实例上的cpu负载接近于0，并且出现问题的机器上的以太网连接数平均低于没有问题的实例。

一个线索是 401 错误似乎是在一个块中发生的（几个发生在大约 4 分钟内），并且这些块通常相隔 10 到 60 分钟（尽管可能有很多小时没有错误）。我们没有看到 I/O 错误或“不稳定的通信”错误，只有来自 Google c2dm 的 401 错误。

服务器故障帖子让我们考虑在 AWS 上进行 DNS 缓存，因为它与 Google c2dm 服务提供的证书中主机名的 SSL 验证有关，但我们使用的 python 2.7 urllib2 似乎没有通过以下方式验证主机默认。

另一个线索是，我们使用“弹性 IP”功能更改了第一个出现问题的 Web 实例的 IP 地址：相同的、持续运行的实例，只是使用了一个新 IP。该实例在 4 天内 100% 成功，但此后又恢复为偶尔出现 401。

我们能做些什么来阐明这一点？

堆栈跟踪示例：

c2dm push error: HTTP Error 401: Unauthorized 
Traceback (most recent call last):
   File "/home/django/base/src/mmsite/push/models.py", 
line 262, in send_c2dm_message     
   response = urllib2.urlopen(request) # third try
   File "/usr/local/lib/python2.7/urllib2.py",
 line 126, in urlopen     
    return _opener.open(url, data, timeout)
   File "/usr/local/lib/python2.7/urllib2.py",
 line 400, in open     
    response = meth(req, response)
   File "/usr/local/lib/python2.7/urllib2.py",
 line 513, in http_response     'http', request, response, code, msg, hdrs)   
   File "/usr/local/lib/python2.7/urllib2.py",
 line 438, in error
     return self._call_chain(*args)   
     File "/usr/local/lib/python2.7/urllib2.py", 
line 372, in _call_chain
     result = func(*args)
   File "/usr/local/lib/python2.7/urllib2.py", 
   line 521, in http_error_default
     raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
 HTTPError: HTTP Error 401: Unauthorized

401 回复中返回的示例 HTTP 标头：

'headers': [
    'Content-Type: text/html; charset=UTF-8\r\n', 'Date: Fri, 25 May 2012 00:24:25 GMT\r\n', 
    'Expires: Fri, 25 May 2012 00:24:25 GMT\r\n', 'Cache-Control: private, max-age=0\r\n', 
    'X-Content-Type-Options: nosniff\r\n', 'X-Frame-Options: SAMEORIGIN\r\n', 
    'X-XSS-Protection: 1; mode=block\r\n', 'Server: GSE\r\n', 'Connection: close\r\n']

编辑其他测试信息：

我们能够在开发网络上重现这个短暂的 401。有时它有效，有时它得到 401。由于开发网络与 AWS 完全分开，这消除了我们正在考虑的有关 AWS 的所有变量，并强调了问题出在 Google 方面的理论。谷歌友好地回复说他们会升级这个问题。

Answer 1

通过更改 auth 密钥（通过向 c2dm 服务发出 URL 请求来获取新密钥的自动化过程，然后将其立即放入我们的服务器端推送代码中）可以解决此问题。虽然密钥对于大多数 c2dm 推送都工作正常，但我们不愿意这样做，但看起来一些 Google 服务器对该密钥不满意，导致我们出现间歇性错误。自从一周前更改以来，我们一直没有错误。