Есть несколько причин, по которым я могу предположить, что Google, возможно, решил использовать 5228 вместо 80 или 443.
Во-первых, в большинстве (но определенно не во всех) случаях 5228 не должно быть проблемой (т. Е. Заблокировано), поскольку push-уведомления широко используются, когда устройства находятся в движении. Это означает, что они используют соединения для передачи данных сотового телефона, которые не блокируют этот порт и не защищены брандмауэром.
Во-вторых, в случае сред, в которых может существовать брандмауэр (то есть с WiFi внутри корпорации), также вероятно, что трафик http проксируется или контролируется каким-либо образом. C2DM не полагается на стандартный протокол HTTP и, как ожидается, будет долгоживущим соединением. Это означает, что запуск его на 80/443 может вызвать проблемы в этих средах.
В-третьих, эти службы, вероятно, использовали 5228 до выхода C2DM, и не было никаких явных оснований для его изменения.
Исходя из моего опыта, я думаю, что было бы идеально, если бы они использовали 5228 по умолчанию и попытались откатиться до 443 в других случаях (поскольку, безусловно, существует множество сценариев, в которых 443 будет работать, когда 5228 не будет работать ). По крайней мере, в случае 443, изменение данных менее вероятно, чем в случае порта 80, поскольку протокол обычно шифруется. Тем не менее, все еще возможно, что соединение будет преждевременно прервано на 443. Однако этот риск существует в любой сетевой среде, и при попытке его использования не будет никаких ошибок.
И, с другой стороны, вполне вероятно, что включить C2DM на 443 было бы сложнее, чем кажется для Google, потому что их распределенные интерфейсные серверы, вероятно, знают, как конкретно обрабатывать трафик 80/443 как HTTP, и потребовали бы значительных -обработка для обработки C2DM.