2016年度Accessログのまとめ

ありがち企画ではあるのですが、当サイトの2016年のログ統計を振り返ってみたいと思います。

具体的には、HTTPプロトコルのバージョンの比較、サーバの処理時間の比較、TLS暗号スイートのシェアについて見てみます。

ここから、2017年度のチューニングの「傾向と対策」を考えるヒントとしたいと思います。

なお、「アクセスログの取り方」の設定で取った情報を元に集計しています。

HTTPプロトコルバージョン

まずは、2016年度の各月のHTTPプロトコルのバージョンをまとめたのが下の表になります。

HTMLファイルのアクセスログに絞って集計しています。付随する画像・CSSは集計から外しています。

言ってしまえば、ほぼ、当サイトのPVです。

あまりに貧弱な数値なので、2016年5月を基準とした比較としています。ご容赦ください。

それから、UserAgentから、明らかにロボットと思われるアクセスは除外しています。

HTTP/1.0はおそらくロボットだと思うのですが、UserAgentからロボットと確認できないものは、あえて集計に加えました。

2016年5月の段階で、75%のPVがHTTP/2となっています。

これは、2017年4月まで多少の増減はありますが、ほぼ似たような数値となっています。

企業が利用するセキュリティー系Proxyなどが、HTTP/1.1のままなのでしょう。

当面は、HTTP/1.1が25%、HTTP/2が75%で来る想定で良いと思われます。

案外、HTTP/1.0のアクセスがしぶといですが、2017年に入ってからは、さすがに減少傾向です。

（2017年に入って、当サイトのPVが増えてきたため、割合が相対的に減ったとも取れますが…）

HTTP/2においてPUSHを使う割合は、2016年6月に増えています。

後述しますが、2016年6月は、TLSの暗号スイートのシェアのトップが、ECDHE-ECDSA-AES128-GCM-SHA256から、ECDHE-ECDSA-AES256-GCM-SHA384に変わった月でもあります。おそらくChrome 51.0.2704のリリースに伴う事象と考えています。

2016年4月にリリースの、Apache2.4.20から、H2PushDiarySizeが利用できるようになったのと前後して、一気にPush対応のブラウザが増えた感じです。

当サイトは、共通のCSSファイルを１つと、あれば一部SVG画像をプッシュしているので、なんとなく滞在ページ数が見え隠れするデータです。,

1ファイルあたりのサーバ側処理時間

続いて、サーバログに記載の処理時間を確認します。

2017年2月にサーバのプロバイダ回線を変えたので、2016年5月～2017年１月までを見てみます。

この中には、TLS接続にかかる時間は含まれていません。純粋にTLSより先のHTTP処理のみです。

先ほどの分類ごとに、1ファイル辺りのサーバ側処理時間をまとめてみました。

HTTP/1.xとHTTP/2はそれぞれ、HTMLファイルの処理時間です。

PUSHEDは、プッシュ処理の時間です。

それぞれ、処理時間を昇順に並べ、極端に早い、もしくは遅い上位5%、下位5%を除いた平均値です。

昨年11月までは、HTTP/2のほうが、処理時間が短くなっています。

12月に、Apache HTTPD 2.4.25に変わって、H2PushResourceディレクティブが追加された影響も考えられます。

とはいえ、それほど大差はありません。ほぼ一緒です。

一方、時が進むにつれて、PUSHにかかる時間が長くなってきています。

これは昨年5月頃は、PUSH対象がCSSファイル一つくらいだったのですが、次第にSVG画像のPUSHを増やしているため時間がかかっているようです。

と書いたは良いが、気になってログを見てみると、特に、CSSファイルと、SVG画像の２つを同時にプッシュすると、２つとも同じような時間がかかっています。

で、原因に気付く。

H2PushPriorityの設定を、interleavedとしてるから当たり前です。

インターリーブ（interleaved）で複数のファイルをプッシュすると、同時に転送が終わるように間欠的にデータを送ります。

そのため、小さいファイルの処理時間は、大きいファイルのプッシュ処理時間に支配されます。

ってことを、わかりにくく以下で書いてました。

参考>>　HTTP/2プッシュの優先順位

2016年5月～6月は、CSSファイルしかPUSH対象としていないので、CSSファイルのプッシュ処理時間は、HTMLファイルのダウンロードに支配されています。

2016年7月以降は、同時にプッシュされるSVG画像のプッシュ処理時間に支配されていると言うことです。

このようにログ上、プッシュ処理の時間は大きく見えますが、インターリーブ転送の関係で、コンテンツを構成するファイル群の処理に要した時間といえます。

もともと、サーバ側では、クライアント側のリクエスト処理に関する部分を除いた処理のログしか取れません。

HTTP/1.1のログでは、クライアント側のリクエスト処理が複数回あります。そのため、クライアント側のリクエスト処理が支配的になりがちで、それぞれの個別の転送の合計でしか、評価できませんでした。

H2プッシュでは、クライアント側のリクエスト処理が1回で、複数ファイルの転送を行えます。コンテンツの一定部分の転送がまとまるため、よりユーザの体感に近いデータといえます。

暗号スイートのシェア

当サイトでは、ECDSAとRSAの2種類の証明書を用意していますが、使われた暗号スイートは、ECDSA系が圧倒的です。

割合で言えば、5%程度がRSA系、残りがECDSA系です。

ブラウザは、積極的にECDSAの証明書を使ってくることがわかります。

また、AESでは、GCMによるブロック暗号が主流です。

あとは、AESで128ビットを使うか、256ビットを使うかといったあたりですが、2016年6月を境に、AES256の利用が増えています。

おそらくChrome 51.0.2704のリリースに伴う事象と考えています。

当サイトの扱う情報はたかがしれているので、AES128に抑えてもいい気もします。

夢のまた夢ですが、アクセス集中があった場合は、AES128に抑えようと思います。

一方、鍵交換は、3%程度がDHE、のこりがECDHEです。

DHEは、実用的な衝突方法が見つかりつつあるSHA-1との組み合わせが多いため、当サイトのポリシー変更に伴い、今年３月以降激減しております。

2017年中に無くなる気がします。

さらに、2017年度は、TLS1.3による変化が見られると思いますが、どうなるでしょう？

まとめ

なんだかんだ言って、今回のこの企画は、予想外のチューニング反省会になりました。

年に1回くらいは、ログをみてチューニングしようと思いました。