Как службы облачных сообщений достигают устройств за NAT / межсетевым экраном?

8

Получение push-уведомлений на устройствах с локальным IP-адресом работает нормально. Мне просто интересно, как это работает. Это просто uPnP? Устройство начинает связь с облачным сервисом обмена сообщениями, а затем включается IGD? Таким образом, сопоставление сохраняется. Поддерживает ли клиент push-уведомлений постоянное соединение с облачным сервером? Я хотел бы думать, что это не так.

Меня особенно интересует, как push-уведомление знает, как связаться с устройством, если оно находится за NAT или межсетевым экраном. Существует ли сценарий, при котором push-уведомления Google не смогут получить доступ к устройству?

cloudraven
источник

Ответы:

6

Как вы можете себе представить, Google довольно тихо относится к деталям своей реализации. Поэтому я просто опишу это в общем случае и в очень простой форме.

Толчок заключается в том, что клиент (т.е. телефон) открывает TCP-соединение с сервером обмена сообщениями (например, Google). Это соединение должно оставаться открытым до тех пор, пока телефон включен. К счастью, TCP-соединение не использует абсолютно никакой полосы пропускания, когда ничего не передает, поэтому не тратит много данных, радиопередатчик может отключиться и т. Д.

Соединение может оставаться открытым неограниченно долго, однако за NAT инфраструктура NAT хранит таблицу открытых соединений, которые она обрабатывает, и отбрасывает соединения, которые простаивали в течение некоторого времени, обычно 10-15 минут. Ни один конец не получает уведомление об этом. Таким образом, это выполняется путем отправки пакета поддержки TCP, который обновляет запись в таблице соединений NAT оператора. Это стоит всего около 50 байтов или около того, и это нужно делать каждые несколько минут.

Майкл Хэмптон
источник