DSAS開発者の部屋:Android のプッシュ通知用コネクションに関するメモ

2012年08月07日

Android のプッシュ通知用コネクションに関するメモ

Android のプッシュ通知機構（GCM, 旧 C2DM）は有用なしくみですが、オープンソースではないソフトウェア要素が関わっているためか内部仕様に近い情報をあまり見かけないのが残念です。手元での観察結果をもとにプッシュ通知で使用されるネットワークコネクションまわりの情報をいくつかまとめてみました。

まとめ

Android 端末上の com.google.process.gapps プロセスは mtalk.google.com:5228 へ TCP コネクション [A] を張る
（通常は 5228 番ポートだが 5229, 5230 番ポートが使用される場合もある）

com.google.process.gapps プロセスは基本的に [A] をずっと張りっ放しにしており接続維持のため無応酬 15分ごとに Keep-Alive パケットを流す

GCM, C2DM のプッシュ通知はいずれも [A] 経由で端末へ送られる

※[A] はプッシュ通知以外の用途にも利用されている様子でありそちらもおって調査したい

端末－ Google サーバ間のコネクションについて

コネクションの存在確認

GCM に関する開発者向け情報へアクセスすると次の記述が見つかります。

[GCM Architectural Overview | Android Developers] より

Note: If your organization has a firewall that restricts the traffic to or from the Internet, you'll need to configure it to allow connectivity with GCM. The ports to open are: 5228, 5229, and 5230. GCM typically only uses 5228, but it sometimes uses 5229 and 5230.

GCM では端末と所定の外部サーバとの接続に通常 5228 番ポートを使うということですね。さっそく Android 端末実機上で netstat コマンドを実行してみます。

※ここで使用しているのは root 化ずみの実験用端末であり、
各コマンドは Android オリジナルのものではなくBusyBox 版を利用しています。

pid=3547 のプロセスが「173.194.72.188:5228」との間に TCP コネクションを張っていることがわかります。

# netstat -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 10.10.0.10:60272        74.125.235.111:80       ESTABLISHED 6337/berserker.andr
tcp        1      0 ::ffff:10.10.0.10:33375 ::ffff:74.125.235.145:443 CLOSE_WAIT  3547/com.google.pro
tcp        0      0 ::ffff:10.10.0.10:22    ::ffff:10.10.0.6:3667   ESTABLISHED 6385/dropbear
tcp        1      0 ::ffff:10.10.0.10:52412 ::ffff:74.125.235.180:443 CLOSE_WAIT  7318/com.google.and
tcp        0      0 ::ffff:10.10.0.10:22    ::ffff:10.10.0.6:3911   ESTABLISHED 6879/dropbear
tcp        0      0 ::ffff:10.10.0.10:44984 ::ffff:173.194.72.188:5228 ESTABLISHED 3547/com.google.pro
tcp        0      0 ::ffff:10.10.0.10:36091 ::ffff:74.125.235.122:80 ESTABLISHED 6337/berserker.andr
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  2      [ ]         DGRAM                     10725 3445/system_server  /data/misc/wifi/sockets/wpa_ctrl_3445-307
unix  2      [ ]         DGRAM                     10727 3445/system_server  /data/misc/wifi/sockets/wpa_ctrl_3445-308
unix  2      [ ]         STREAM                     1293 103/rild            /dev/socket/rild-debug
unix  2      [ ]         STREAM                     1295 103/rild            /dev/socket/rild
unix  4      [ ]         DGRAM                     10722 3762/wpa_supplicant /dev/socket/wpa_wlan0
unix  3      [ ]         STREAM     CONNECTED      17159 108/adbd
unix  3      [ ]         STREAM     CONNECTED      17158 108/adbd
                           :

当該コネクションを保持するプロセスについて

pid=3547 は「com.google.process.gapps」というプロセス。

# ps | grep 3547
  3547 app_1      0:05 com.google.process.gapps

「com.google.process.gapps」は「Google Services Framework」のプロセス名。
（関連記事）
"Fix for Google services Framework (process com.google.process.gapps) has stopped unexpectedly"

「Google services Framework」の実体は以下のシステムパッケージ。（※ソース未公開）

 # ls -l /system/app/GoogleServicesFramework.apk
-rw-r--r--    1 root     root       2867063 Feb  6  2012 /system/app/GoogleServicesFramework.apk

接続先サーバについて

「173.194.72.188」に該当するホスト名は「mtalk.google.com」。

$ host -v mtalk.google.com
Trying "mtalk.google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30177
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mtalk.google.com.              IN      A

;; ANSWER SECTION:
mtalk.google.com.       85662   IN      CNAME   mobile-gtalk.l.google.com.
mobile-gtalk.l.google.com. 66   IN      A       173.194.72.188

Received 79 bytes from 10.10.0.18#53 in 0 ms

※2012 年 8 月現在、「mtalk.google.com」の分散先として「173.194.72.188」「74.125.31.188」の 2 サーバの存在を確認

接続維持用の Keep-Alive パケットについて

tcpdump を走らせ 5228 ポートをめぐる応酬を監視。沈黙状態の 15 分ごとに端末から Keep-Alive パケットが送出される様子が見てとれます。

# tcpdump  -nl -s 256 port 5228
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 256 bytes
13:16:23.504179 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 78:103(25) ack 541win 11236 <nop,nop,timestamp 9585688 3638038533>
13:16:23.560095 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 541:566(25) ack 103 win 274 <nop,nop,timestamp 3638938605 9585688>
13:16:23.560168 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 566 win 11236 <nop,nop,timestamp 9585694 3638938605>
13:31:23.568391 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 103:128(25) ack 566 win 11236 <nop,nop,timestamp 9675694 3638938605>
13:31:23.624242 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 566:591(25) ack 128 win 274 <nop,nop,timestamp 3639838674 9675694>
13:31:23.624371 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 591 win 11236 <nop,nop,timestamp 9675700 3639838674>
13:46:23.637744 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 128:153(25) ack 591 win 11236 <nop,nop,timestamp 9765701 3639838674>
13:46:23.696340 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 591:616(25) ack 153 win 274 <nop,nop,timestamp 3640738749 9765701>
13:46:23.696469 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 616 win 11236 <nop,nop,timestamp 9765707 3640738749>
14:01:23.712443 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 153:178(25) ack 616 win 11236 <nop,nop,timestamp 9855709 3640738749>
14:01:23.770009 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 616:641(25) ack 178 win 274 <nop,nop,timestamp 3641638829 9855709>
14:01:23.770164 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 641 win 11236 <nop,nop,timestamp 9855715 3641638829>
14:16:23.783100 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 178:203(25) ack 641 win 11236 <nop,nop,timestamp 9945716 3641638829>
14:16:23.841258 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 641:666(25) ack 203 win 274 <nop,nop,timestamp 3642538904 9945716>
14:16:23.841349 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 666 win 11236 <nop,nop,timestamp 9945722 3642538904>
14:31:23.853398 IP 10.10.0.10.48304 > 173.194.72.188.5228: P 203:228(25) ack 666 win 11236 <nop,nop,timestamp 10035723 3642538904>
14:31:23.912470 IP 173.194.72.188.5228 > 10.10.0.10.48304: P 666:691(25) ack 228 win 274 <nop,nop,timestamp 3643438980 10035723>
14:31:23.912555 IP 10.10.0.10.48304 > 173.194.72.188.5228: . ack 691 win 11236 <nop,nop,timestamp 10035729 3643438980>

GCM, C2DM で通知を送ってみる

以下は自作アプリから C2DM, GCM の順に端末へプッシュ通知を送った時の様子です。いずれも「173.194.72.188:5228」経由で通知が端末へ配信されていることがわかります。

11:49:49.268419 IP 173.194.72.188.5228 > 10.10.0.10.44984: P 974497881:974498015(134) ack 436376500 win 272 <nop,nop,timestamp 1641184578 3415344>
11:49:49.269687 IP 10.10.0.10.44984 > 173.194.72.188.5228: . ack 134 win 11236 <nop,nop,timestamp 3483319 1641184578>

11:49:59.146970 IP 173.194.72.188.5228 > 10.10.0.10.44984: P 134:262(128) ack 1 win 272 <nop,nop,timestamp 1641194459 3483319>
11:49:59.147103 IP 10.10.0.10.44984 > 173.194.72.188.5228: . ack 262 win 11236 <nop,nop,timestamp 3484307 1641194459>

(tanabe)

klab_gijutsu2 at 17:20│Comments(4)│TrackBack(0)│Android | win

トラックバックURL

この記事へのコメント

1. Posted by しまりす 2013年11月19日 14:08

はじめまして
heartbeetが15分毎というのは、Wifi上の話でしょうか？
資料によっては3g/2gは28分毎ってのがありましたので。

何にし、MVNOによってはheartbeetが掛かる前に、NAT切断しちゃうようで、
PUSH受けれないんですよね…

少ないサンプルでは、
・FREEBIT系は28分以上もつ？
・InfoSphere系は即断？
のような感じです。

2. Posted by tanabe 2013年11月19日 14:15

こんにちは。ご指摘のとおり、この記事はWiFi環境での観察結果に基づくものです。

3. Posted by しまりす 2013年11月19日 15:00

ご返答ありがとうございます。
すみません、beetじゃなくてbeatですね…

この記事のおかげで、push着信できない原因を突き止めることができました。
ありがとうございます。

デバイス側heartbeatを5分に変更してコネクションkeepすることで、
常時push着信できるようになりました！

4. Posted by tanabe 2013年11月19日 15:02

記事がお役に立ち幸いでした。今後とも当ブログを宜しくお願い致します。

この記事にコメントする

名前:
メール:
URL:
	情報を記憶:	評価:	顔星