WebSurfer's Home

Filter by APML

IIS ログの time-taken

by WebSurfer 1. July 2016 14:39

IIS のログの中に time-taken という項目があります。具体的にいつからいつまでの時間かについて調べたのですが、その過程でいくつか発見があったので備忘録として書いておきます。(そもそもの話は MSDN Forum のスレッド「IIS 8.5のログの"time-taken"の値について」が発端です)

リクエスト処理の流れ

(出典: Microsoft 公式解説書 一目でわかる IIS 7.0)

上の図は IIS がブラウザから要求を受けて応答を返すまでの流れを示しています。この図で time-taken はいつからいつまでになるかを簡単に書くと、上の図の ② で HTTP.sys が要求の最初のバイトを受け取ってから、⑨ で要求に対する最後の応答を返すまでとなります。

それに加えて、IIS6 以降は最後のパケットに対するクライアントからの ACK を受け取るまでが time-taken に含まれるようになったとのことです。

詳しくは以下の Microsoft の記事を見てください。

Description of the time-taken field in IIS 7 HTTP logging

タイトルが "IIS 7.0" となっていますが、IIS7.5 以降も同じだと思います。記事の Note の "TCP buffering is used" は ASP.NET Web アプリには関係なさそうです(公式文書などで裏は取れていませんが、この記事の下の方に書いた報告などからも ASP.NET でバッファを有効にしているとは考えにくいです)。

Microsoft の別の記事、例えば、Default Log File Settings for Web Sites とか W3C Logging)に "Time taken does not reflect time across the network" と書いてあるものもありますが、古い記述のままで修正がされてないものと思われます。

というわけで、今回分かったことを箇条書きにすると以下の通りです:

  1. time-taken は上の図で ② から ⑨ までの時間。
  2. 通常、一番最初の要求を受けてワーカープロセスを起動・初期化しログファイルを開くという操作が行われる。なので、一番最初の要求では time-taken はその分長くなる。
  3. IIS6 以降では上に紹介した Microsoft の記事に書いてあるように network time も time-taken に含まれる。それゆえ、サイズの大きなファイルを遅いネットワークでダウンロードしたりすると time-taken の値は予想よりかなり大きくなることがある。
  4. トレース情報で調べられる時間やプログラムで Stopwatch などを使って調べられる時間は上の図の ⑦ から ⑧ までの範囲内なので、当然 time-Taken の方が長くなる。

上記 3 すなわち「network time も time-taken に含まれる」を裏付けるような、time-taken の値が executionTimeout を越えているとか、プログラムのコードで実際に計った時間よりはるかに長いという報告を stackoverflow に見つけましたので、参考にリンクを張っておきます。

In our IIS logs, why do requests last 5 min and longer when executionTimeout is 110 seconds?

Difference in time-taken in IIS and ASP.NET

Tags: , ,

Windows Server

二重スラッシュを含む URL 書換

by WebSurfer 23. January 2015 14:10

IIS の URL Rewrite モジュールを使用して aaaa/1/2/3 という URL を test.aspx?x=1&y=2&z=3 というように書き換えることを考えます。

URL の書き換え

この時、たとえば上の画像のように 2 つ目の値をスキップした aaaa/1//3 という URL を test.aspx?x=1&y=&z=3(y に値がないところに注目)に書き換えたい場合はどうすればいいでしょうか?

IIS7 の URL Rewrite モジュールを使って、普通に(というか、あまり深く考えずに)書換ルールを作ると以下のようにすると思います。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="aaaa/(.*)/(.*)/(.*)" />
      <action 
        type="Rewrite" 
        url="test.aspx?x={R:1}&y={R:2}&z={R:3}" />
    </rule>
  </rules>
</rewrite> 

IIS マネージャーの「テストパターン」ダイアログ上で、[テスト対象データの入力(D):]テキストボックスに aaaa/1/2/3 とか aaaa/1//3 などのテストパターンを入力してテストすると、 {R:1}, {R:2}, {R:3} には期待通りの結果が得られます。

なので、ブラウザから aaaa/1/2/3 とか aaaa/1//3 などで呼んでも同様に aaaa/(.*)/(.*)/(.*) にマッチして、test.aspx?x=1&y=2&z=3 とか test.aspx?x=1&y=&z=3 に書き換えられると期待すると思います。

しかし、ブラウザから aaaa/1//3 で呼ぶとダメです。ダメな理由は、IIS が aaaa/1//3 を aaaa/1/3 に書き換えてしまうからです。詳しく書くと以下の通りです。

  1. ブラウザからは aaaa/1//3 で要求が出る。
  2. それを受けた IIS は aaaa/1//3 を aaaa/1/3 に書き換えてしまう。
  3. aaaa/1/3 が URL Rewrite モジュールに渡される。
  4. aaaa/1/3 は aaaa/(.*)/(.*)/(.*) にはマッチしない。マッチしないので書き換えは行われない。
  5. 書き換えが行われないので、IIS は aaaa/1/3 で指定されるリソースを探す。
  6. そのようなリソースは存在しないので HTTP エラー 404.0 - Not Found となる。

ちなみに、aaaa/1/2/3 であれば期待通り test.aspx?x=1&y=2&z=3 に書き換えられ、test.aspx ページ内でクエリ文字列は正しく取得できます。

上記 2 がどうして分かったかと言うと、6 で表示されるエラー画面で「要求された URL http://aspnet4site:80/aaaa/1/3」となっていたからです。(aspnet4site は自分の開発マシンで使っているホスト名です)

というわけで、上記 2 を何とかしないと URL Rewrite モジュールでは対処できないということになります。

それを何とかする手段が IIS Server Variables の UNENCODED_URL を使用して IIS が処理する前の URL を取得して、それに書換ルールを適用することです。

詳しい手順は Microsoft IIS.net の記事 URL Rewrite Module Configuration Reference の中の「Using server variables in rewrite rules」および「Using back-references in rewrite rules」というセクションが参考になると思います。

具体的な書換ルールのコードは、今回のケースでは以下のようになります。

<rewrite>
  <rules>
    <rule name="DoubleSlash">
      <match url="^aaaa/" />
      <action 
        type="Rewrite"
        url="test.aspx?x={C:1}&y={C:2}&z={C:3}" />
      <conditions>
        <add 
          input="{UNENCODED_URL}" 
          pattern="^/aaaa/(.*)/(.*)/(.*)" />
      </conditions>
    </rule>
  </rules>
</rewrite>

上記のルールで、aaaa/1/2/3 でも、aaaa/1//3 でも、aaaa//2/3 でも、 aaaa/// でも、その他全てのパターンで期待通り書き換え��れるのを確認できました。

Tags: ,

Windows Server

CA 証明書の有効期限

by WebSurfer 17. January 2015 18:51

先の記事 Active Directory 証明書サービス (AD CS) で紹介しました CA 証明書ですが、それには有効期限があって、手動で書き換える必要があります。

CA 証明書の書き換え

CA 証明書は AD CS の初回インストール時には自動的に発行されインストールされますが、有効期限はデフォルトで 5 年(AD CS のインストール時に変更できます)なので忘れたころに期限切れになります。

期限切れになっても自動的には更新されないので注意が必要なようです。(実は、自分は気がつかなかったです。(汗))

ブラウザで Web を通して http://localhost/certsrv から CA 証明書をダウンロードしても、古いものがダウンロードされるだけです。(実は、それで更新されるのではないかと思ってやってみたのですが、ダメでした。まぁ、考えてみれば当たり前ですね。(笑))

更新(書き換え)するには以下の操作が必要です。

  1. [管理ツール] から [証明機関] を開く。
  2. 証明機関管理コンソールの左のコンソール ツリーより CA 名(上の画像の例では bglb-SVR2K8-CA)を右クリックし、 [すべてのタスク] ⇒ [CA 証明書の書き換え] を選択。
  3. 証明書サービスを停止するか聞かれるので [はい] をクリック。
  4. 証明するキー (秘密鍵) を書き換えるか聞かれるので、 [いいえ] を選択し、 [OK] をクリック。

なお、有効期限を変更することは可能だそうです。具体的には Microsoft TechNet ブログの記事 CA 証明書の有効期限 を参照してください。

Tags:

Windows Server

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  December 2025  >>
MoTuWeThFrSaSu
24252627282930
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar