診断キー一覧ファイル（ list.json ）の圧縮転送対応提案

[b-wind]

その機能リクエストは何らかの問題に関連しますか / Is your feature request related to a problem?

COCOA は一日数回程度、診断キーの一覧を取得し新たな診断キーが登録されていないかチェックしています。
主な利用状況がモバイル回線である事を考えると、この際の通信量を削減することが望ましいです。
list.json は毎回全部分をダウンロードした上での比較になっているため、それなりの効果が有るものと考えます。

解決策についてお書きください / Describe the solution you'd like

HTTP 通信路の圧縮機能を使うことで大幅な削減が期待出来ます。（一般的な gzip 圧縮で 1/10 程度 ）
必要な対応内容は以下の２点。

1. CDN 側で圧縮転送機能を有効にする
2. COCOA のHTTP通信で圧縮転送機能を有効にする

圧縮に使うアルゴリズムは可能で有れば Brotli が高効率。互換性の為に GZip / Deflate も有効にしておく事がお勧めです。

あなたが考える代替案についてご説明ください / Describe alternatives you've considered

毎回一括ダウンロードしか出来ない点も不要な通信を発生させているので課題としてあげられる。
差分ダウンロードが可能な形に変更すると言う手段も考慮するのが望ましい。

その他 / Additional context

• 別 Issue で検討していた物を単独の課題として切り出しました ETag による通信量削減 #199 (comment)
• .Net 標準ライブラリを使う限り、展開は透過的に行われるため機能追加のための改変は大きくないことが期待されます
• HTTP ヘッダーによって処理を分岐する為、過去バージョンとの互換性が期待されます

---

Internal IDs:

• NFR 6572

[b-wind]

サーバー側で確認すべき事。

1. 圧縮の有効化を行う。
   https://docs.microsoft.com/ja-jp/azure/cdn/cdn-improve-performance
2. list.json を更新した後も更新後のファイルが圧縮されていることを確認する。

Azure CDN を使って居る物と認識していますので対応は可能だという認識ですが、実際に運用したことは無いので確認が確認が必要です。

[b-wind]

クライアント実装。

HttpClient 生成時に Handler を指定する様に変更する。

cocoa/Covid19Radar/Covid19Radar/Services/HttpClientService.cs

Lines 19 to 22 in 2a72949

	public HttpClient Create()
	{
	return new HttpClient();
	}

Android 実装例

public HttpClient Create() 
 { 
    var handler = new AndroidClientHandler {
        AutomaticDecompression = DecompressionMethods.Brotli | DecompressionMethods.Deflate | DecompressionMethods.GZip,
    };
    return new HttpClient();
}

https://github.com/xamarin/xamarin-android/blob/f5ae4ca41caa7873443ebebe1d0a53595ff6495b/src/Mono.Android/Xamarin.Android.Net/AndroidClientHandler.cs#L34-L39

[b-wind]

iOS では NSUrlSessionHandler を指定している限り、デフォルトで有効になっている模様。（要確認）

[b-wind]

HTTP の通信上は以下の二点で確認出来ます。

1. Request Header に Accept-Encoding が指定されている
2. Responce Hedaer に Content-Encoding が指定されている

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Accept-Encoding

[keiji]

ありがとうございます。通信効率は上げていきたいですね。こちらサーバーやCDNも絡んでくる話なのでサーバーチームとも連携して実現可能性を探りたいと考えています。

直近、ぼくができるのはAndroid, iOSでAccept-Encodingを付けてリクエストして、サーバー（これは仮プログラムでも良いですね）が送出する圧縮データを透過的に取り扱えるかの確認です。スペック的には対応していることは確認して頂いていますが、ぼくの方でも手元で動かして「動くよ」ってレベルにしておきたいと思ってます。

[b-wind]

実装コードは取り込まれたようですが、サーバーサイドの変更は対応バージョンのリリース後とかでしょうか。
（手元で試す限りはサーバーからの応答は変わっていないようなので）

[keiji]

ぼくの知る限りlist.jsonはAzure CDNで配信していますね。
なので、個人的にはアプリ側でaccept-encodingを付けることでCDNがいい感じにしてくれることを期待していました。CDN側の設定が必要であれば、設定の予定について聞いておきます。

https://docs.microsoft.com/ja-jp/azure/cdn/cdn-troubleshoot-compression

ちなみに、今のままだと診断キーファイル（.zip）もさらに圧縮されることになりそうなので、無駄な圧縮をしないようにちゃんと手当しようねみたいな話を開発チームがしているのを聞きました（この件は後ほどIssueにする予定です）。

[b-wind]

ドキュメントを読む限り Azure CDN で圧縮転送を行うには事前に設定が必要の様です（ #938 (comment) ）

ちなみに、今のままだと診断キーファイル（.zip）もさらに圧縮されることになりそうなので、無駄な圧縮をしないようにちゃんと手当しようねみたいな話を開発チームがしているのを聞きました（この件は後ほどIssueにする予定です）。

MIME type 毎の圧縮・非圧縮の設定は可能だという認識です。
さし当たり json ファイルは事前に圧縮設定。zip ファイルは無圧縮（特に設定しない）というのが妥当かなと。

圧縮設定に関する Issue を建てられるのであれば、list.json の対応も含めた内容にして頂けると纏まりが良さそうですね。

[keiji]

サーバー側のリリースも完了して、ぼくの手元では圧縮されて配信されてくるのが確認できました。

$ curl -H 'Accept-Encoding: gzip,deflate' [list.jsonのURL] --output list.json.zip

診断キー.zipもそのまま（圧縮されたバイナリとして）ダウンロードしてみましたが、得られたzipファイルを展開するとそのままexport.binなどが得られるので、サーバー側がMIMEを見て圧縮対象から外している可能性がありますね。 こちら確認します。

こちらぼくの間違いでした。mac標準のArchive Utilityを使ったので、2重圧縮がかかっていても一気に展開してしまっていました。
別のアーカイバを使ったらgzipからzipが出てきた。

[b-wind]

今手元で見る限り変わっていない様にも見えます。
お手数ですが、curl の -I オプションを付加してレスポンスヘッダを確認頂いても良いでしょうか。

$ curl -H 'Accept-Encoding: gzip,deflate' -I [list.jsonのURL]

[b-wind]

実機で確認した所対応が確認出来ました。

余談ですが、.NET での指定にかかわらず、 iPhone 環境では Brotli も対応している様子。

[keiji]

iOSいいなぁ。
Androidの方は、まだHTTP 2でなくHTTP 1.1で通信しているはず。

[b-wind]

手元の環境でも確認出来ました。

 $ curl --compressed -I URL
HTTP/2 200
content-encoding: gzip
accept-ranges: bytes
age: 2237
cache-control: max-age=3600
content-md5: j18R/TuySFxxJQzQOHUmVw==
content-type: application/octet-stream
date: Thu, 09 Jun 2022 13:33:59 GMT
etag: 0x8DA4A075932F388
expires: Thu, 09 Jun 2022 14:33:59 GMT
last-modified: Thu, 09 Jun 2022 11:01:04 GMT
server: ECAcc (osa/2B63)
x-cache: HIT
x-ms-blob-type: BlockBlob
x-ms-lease-status: unlocked
x-ms-request-id: 343f26f2-301e-005d-1000-7c1cb8000000
x-ms-version: 2009-09-19
content-length: 2424

[b-wind]

あれ、 COCOA v2.0.1 (iOS) で対応が確認出来てしまったと言う事は iOS 環境では過去バージョンも含めて対応してる…… かも知れない。

[b-wind]

なお、 zip ファイルへのアクセス時も content-encoding: gzip が設定されているので不要な圧縮が行われてしまっているように見えます。
さほど実害は無いですが。

$ curl --compressed -I {ZIP_URL}
HTTP/2 200
content-encoding: gzip
accept-ranges: bytes
age: 3078
cache-control: max-age=3600
content-md5: o7bSstkhOPwbwUOlHqTBfQ==
content-type: application/octet-stream
date: Thu, 09 Jun 2022 16:06:36 GMT
etag: 0x8DA4A28C7CAED70
expires: Thu, 09 Jun 2022 17:06:36 GMT
last-modified: Thu, 09 Jun 2022 15:00:23 GMT
server: ECAcc (osa/2B2D)
x-cache: HIT
x-ms-blob-type: BlockBlob
x-ms-lease-status: unlocked
x-ms-meta-batch_number: 10994
x-ms-meta-batch_region: 440
x-ms-request-id: c21288dd-901e-0054-1913-7c596b000000
x-ms-version: 2009-09-19
content-length: 359

[b-wind]

こんな感じに。

$ curl --compressed --raw {ZIP_URL} --output output.zip.gz
$ file output.zip.gz
output.zip.gz: gzip compressed data
$ gzip -dc output.zip.gz > output.zip
$ file output.zip
output.zip Zip archive data

[keiji]

zip ファイルへのアクセス時も content-encoding: gzip が設定されているので不要な圧縮が行われてしまっているように見えます。

はい。そこは認識していて開発チーム側で改善（設定変更）を予定しています。
（明日にでもIssueを作ろうかと

[b-wind]

Zip ファイルの再圧縮には #1036 で対応されるのかな。よく分かってないですが。

[keiji]

一応明日、開発チームの方に確認しますが、#1036 のDescription 「blob storage 書き込み時にcontent typeを指定する」 を見るに、現在list.json/診断キー.zipを生成してblobに書き込む時にContentTypeを設定していない。

なので、Azure CDN側ではMIMEに応じた圧縮を設定済でも、MIME自体が application/octet-stream になって判別できていない（全部圧縮）。を、修正したようですね。