簡介
本檔案介紹媒體檔案的語音可延伸標籤語言(VXML)/客戶語音入口網站(CVP)超文字傳輸通訊協定(HTTP)快取。
必要條件
需求
思科建議您瞭解以下主題：
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
背景資訊
在HTTP客戶端快取中，儲存媒體檔案涉及兩種型別的快取：
- IVR媒體播放器快取和
- HTTP客戶端快取
伺服器快取設定覆蓋HTTP客戶端設定，這些引數通過http消息標頭或通過vxml應用程式指令碼從伺服器傳送。
網關提示快取注意事項
步驟1.在HTTP媒體伺服器上儲存音訊提示時，需要正確的網關提示快取方法，以最佳化網關效能和網路頻寬消耗。如果完全禁用快取，網關效能將降低大約35-40%。
若要在閘道上設定快取，請在閘道上設定以下專案：
..ivr prompt memory 15000
..http client cache memory file 500
..http client cache memory pool 15000
附註：http client cache memory file表示可以快取的最大大小提示檔案(KB)。通常，必須將大於500K（大約一分鐘）的客戶提示拆分為更小、更易於管理的片段，以便載入和快取。例如，隊列音樂可能是30秒提示的重複循環。另請注意，由於提示是流式傳輸的，因此除非播放整個提示，否則提示不會快取。因此，建議將提示符設定為可管理的大小。
步驟2.同步網關和HTTP媒體伺服器之間的日期時間。
附註：同步不必精確，但至少在一兩分鐘內。未同步的時間可能導致提示從不刷新，或每次呼叫都會刷新，這兩種情況都是不想要的行為。
步驟3.在媒體伺服器上，設定內容過期時間（例如15分鐘）。
附註：在IIS中，此操作在HTTP標頭頁籤下完成。網關提示在此時間段後刷新。所選時段必須反映重新記錄提示的頻率以及修改後等待載入新提示所花費的時間。
步驟4.導航到程式>管理工具> IIS管理器。
步驟5.導覽至您要修改的.wav檔案。
步驟6.然後,按一下右鍵>屬性> HTTP標頭
步驟7.啟用內容過期。
如何確定網關是否正確快取
若要判斷是否已正確設定閘道快取，請執行以下操作：
每次客戶端請求提示時，媒體伺服器上的IIS日誌都會記錄。如果快取設定正確，則對於任何特定提示，這些請求大約每X分鐘出現一次（X是步驟3中定義的任何刷新間隔。）。日誌位於：C:\WINNT\system32\LogFiles\W3SVC1\ex*
或,
在網關上運行show http client cache。Fresh Time列必須等於HTTP介質伺服器上設定的刷新時間段。
例如，如果刷新期間設定為15分鐘，則必須是900秒。Age列顯示自上次刷新提示以來經過的秒數。通常，此數字小於新鮮時間。但是，如果最近沒有呼叫訪問過提示符，則此數字可能大於新時間。僅當呼叫觸發提示且提示「刷新時間」已過期時，才會刷新提示。如果Fresh Time是一個非常高的值，則從快取中刪除提示（隱藏命令除外）的唯一方法就是重新載入網關。
通過IIS將報頭新增為實際HTTP報頭會容易得多。
這可以通過IIS 6或7完成。
http://weblogs.asp.net/joelvarty/archive/2009/03/23/force-ie7-compatibility-mode-in-ie8-with-iis-settings.aspx
計算FreshTime
有幾個變數可以影響檔案的FreshTime，例如：來自伺服器的http消息標頭，以及通過CLI配置的快取刷新值等。
那麼，您如何知道檔案在其FreshTime中使用了哪個值？檔案的FreshTime按以下優先順序確定：
1.從http伺服器下載檔案時，如果其中一個http消息標頭包含以下內容：
Cache-Control: max-age = <value in seconds>
然後將<value in seconds>用作此檔案的FreshTime。
2.如果(1)不存在，但http消息中包含這兩個標頭：
Expires: <expiration date time>
Date: <Current date time>
然後，將差異<expiration date time> - <Current date time>用作此檔案的FreshTime。
3. HTTP/1.1規範RFC 2616(HTTP)建議存在(1)或(2)中所述的http消息標頭。 如果伺服器在其http響應中未能同時傳送(1)或(2)，則可以從消息標頭獲取Date和Last-Modified之間差值的10%:
Last-Modified: <last-modified date time>
Date: <Current date time>
因此，此檔案的FreshTime計算為：
FreshTime = 10% x ((Last-Modified) - (Date))
4.最後，當快取刷新配置CLI開始發揮作用時。如果上述(1)-(3)個消息標頭都不存在，CLI允許使用者將啟發式FreshTime值作為臨時值分配給檔案。
c5400-02(config)#http client cache refresh ?
<1-864000> Time value in seconds
預設刷新值為86400秒（24小時）。
附註：當存在任何消息標頭(1)-(3)時，配置的http客戶端快取刷新對檔案沒有影響。
附註：如果該CLI有效，則不會回溯。也就是說，新配置的刷新值僅適用於新的傳入檔案。對快取中已存在的條目沒有影響。
刪除過期的快取條目
附註：路由器不會自行刷新任何過時檔案。
過時檔案僅在需要時刷新。為什麼路由器會花費寶貴的CPU週期來更新快取中的檔案，而不知道這些檔案是否或何時會被使用，而其它緊急服務卻需要CPU?
這意味著過時的快取項可以在快取中保留很長時間，直到將其刪除為同一檔案的全新副本或僅需要其快取記憶體空間的另一個檔案騰出空間。有時，如果過時快取條目的使用期限沒有超過應用程式指定的MaxStale值，則它仍然可用。
簡而言之，無論快取條目是過時還是仍然可用，都可以通過以下簡單比較來計算：
- file is fresh if FreshTime > Age
- file is stale but still usable if (FreshTime + MaxStale) > Age
- file is stale and not usable if (FreshTime + MaxStale) <= Age
MaxStale
表示客戶端願意接受已超過其到期時間的響應。如果為max-stale分配了一個值，則客戶端願意接受超出其過期時間不超過指定秒數的響應。如果沒有為max-stale分配值，則客戶端願意接受任何年齡的過時響應。
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
如前所述，當出現以下情況時，其所有者會根據需要刪除過時的快取條目：
快取條目變為陳舊；和
其ref計數為零(0)，即沒有人使用此快取條目；和
需要它的儲存空間為其他條目騰出空間
這意味著http客戶端和IVR Media Player必須分別以非流模式和流模式管理和控制其快取條目。如果http客戶端需要清理一些過時條目以重新獲得快取記憶體池中的空間，但並非這些檔案的所有者，該怎麼辦？ 這將成為http客戶端快取後台管理程式的責任。
http客戶端快取後台管理器每5分鐘喚醒一次。如果用於快取條目的總記憶體超過了配置的快取池大小的70%閾值，則老化器將遍歷每個快取條目。如果輸入內容仍舊新鮮，它將不作任何處理。如果條目過時且沒有引用它，即ref count = 0，則http客戶端會自行刪除該條目，因為它是該條目的合法所有者。如果過時條目的引用計數為1，並且沒有與其連結的父項或子項（這意味著檔案不在刷新下載過程中），則http客戶端將回撥以通知Media Player釋放此過時條目。
Audio-Prompt Load命令
有時，可能需要或必需手動將音訊檔案下載到路由器中。現在，我們已被告知路由器不會自動轉到http伺服器來刷新陳舊的快取條目。這些條目僅在需要時才刷新。 手動下載可以解決此問題。
手動下載的另一種情形可能很有用，那就是在非流模式下預載入大型音訊提示。這可以在收到第一個呼叫之前完成，以便呼叫者不會遇到提示載入的任何延遲。
若要手動下載特定音訊檔案，請執行以下CLI命令：
audio-prompt load <url>
<url>是音訊檔案在伺服器上的位置。當然，應正確配置http客戶端快取以將此檔案儲存在快取中。
附註：如果<url>是活動提示（即當前正在播放），則此CLI無效。
日期時間
此外，請確保網關和HTTP媒體伺服器之間的日期時間同步。這是必須的。
警告：請勿在VXML GW中使用clear http client cache。如果在非常載入/活動的VXML GW上呼叫此命令，則已知會導致問題、記憶體損壞和崩潰。基本上，不建議使用clear ip http client cache all。它會刷新快取中的所有條目，然後建立節點並從快取連結清單中刪除節點，這會導致一些問題。此命令正在從Cisco IOS®中刪除。建議的命令是set http client cache stale，此命令的作用是隻刷新快取中新更改的部分。
意見