Временные ошибки 401 Google c2dm на некоторых экземплярах AWS

Как понять, почему мы получаем случайную ошибку 401 из Google c2dm подтолкнуть службу на некоторых AWS когда просят c2dm доставить уведомление?

Это временная проблема. Все экземпляры AWS в большинстве случаев успешно отправляют HTTPS-запрос в Google c2dm, некоторые экземпляры успешны в 100% случаев, а некоторые иногда получают 401-е сообщение. Поэтому мы не считаем, что это проблема с нашей регистрацией на c2dm или нашим кодом уведомления (python), который находится в производстве более года. Ошибка 401 началась 16 мая 2012 г.

Вместо этого мы думаем, что что-то в инфраструктуре Amazon, включая кеширование DNS, может быть каким-то образом связано с проблемой. Google любезно ответил на наш запрос:

Я искал что-нибудь, что могло бы вызвать нестабильную связь. Попробуйте проверить, не появляется ли у вас необычное количество поврежденных или отброшенных пакетов на сетевом адаптере этой машины.

Однако мы не видим никаких свидетельств «ненадежной связи». Когда возникают проблемы, нагрузка на ЦП на экземплярах почти равна нулю, а количество Ethernet-соединений на проблемных машинах в среднем ниже, чем на экземплярах, у которых нет проблем.

Одна из подсказок заключается в том, что ошибка 401, кажется, возникает в группе (несколько из них происходят примерно в 4 минуты друг от друга), и что группы часто расположены на расстоянии от 10 до 60 минут (хотя без ошибок может быть много часов). Мы не видим ошибок ввода-вывода или «нестабильных коммуникаций», только 401 ошибка от Google c2dm.

А сообщение serverfault заставили нас задуматься о кэшировании DNS на AWS, поскольку оно связано с SSL-проверкой имени хоста в сертификате, предлагаемом службой Google c2dm, но похоже, что используемый нами python 2.7 urllib2 не проверяет хост по умолчанию.

Еще одна подсказка заключается в том, что мы изменили IP-адрес первого веб-экземпляра, который выявил проблему, с помощью функции «эластичного IP-адреса»: тот же, постоянно работающий экземпляр, только с новым IP. Этот экземпляр стал 100% успешным в течение 4 дней, но с тех пор вернулся к периодическим 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

Примеры заголовков HTTP, возвращенных в ответе 401:

'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. Google любезно ответил, что они усилят проблему.