WS-Security 提供了一些強大的特性來保障 Web 服務應用程序的安全，並且它們是許多應用程序的基本特性。但是，這些特性是以高昂的性能和消息開銷為代價的。Dennis Sosnoski 將繼續在他的 Java Web 服務 專欄系列中討論 WS-Security 或 WS-SecureConversation 的使用對 Axis2 性能造成的影響，並且他將論述何時更合適使用較為簡單的（以及性能較好的）HTTPS-secured 連接。
WS-Security 以現有的密碼學以及 XML 加密和簽名行業標準為基礎，為 Web 服務應用程序提供了一組全面的安全特性，您可以通過 WS-Policy 和 WS-SecurityPolicy 來指定特定應用程序可以使用哪些特性，從而允許服務客戶機自行配置以訪問服務。通過跨多個平台和 Web 服務框架對這些標準的廣泛支持，可以實現出色的互操作性（並且會不斷改善）。
儘管能帶來這麼多好處，但 WS-Security 也存在一些缺點。在本 系列 的前兩篇文章中，您已經知道 WS-Security 的配置有時會非常複雜，並且有時會在交換的消息中添加許多塊（bulk）。那麼，WS-Security 帶來的收益在什麼情況下才物有所值呢？在本文中，我們將深入探討 WS-Security 以及相關 WS-SecureConversation 的運行時成本（在處理開銷和添加塊方面），並引申到如何應用 WS-Security 才能讓應用程序受益的話題。
觀察性能
為了測量應用程序在不同配置下的性能，本文將測定當客戶機和伺服器運行於同一系統中特定請求序列的執行時間。這種方法存在一些缺點 — 最顯著的是，它將客戶機和伺服器處理開銷結合在一起，因此不能單獨測算它們 — 但它比在網路上運行測試能生成更加一致的結果。您還可以輕鬆地在自己的硬體和 JVM 上試運行這些測試，相關的實現代碼請參見 下載。
性能測試應用程序
用於測試的應用程序是一個地震數據檢索服務。它基於一個地震資料庫，其中包含一段時間內世界各地發生的 93,000 多次地震的實際數據。對服務的請求將指定經度、緯度、日期或震級的範圍，並且服務將按地區和時間順序分組返回所有匹配的地震。整個資料庫按索引保存在內存中，以便於快速處理請求，因此每條請求幾乎所有的處理時間都花在實際的 Web 服務處理代碼上（包括將轉換為 XML 或從 XML 轉換而來的數據綁定代碼）。
清單 1 展示了一個對服務的示例請求，以及隨後的響應（為適應頁面寬度重新調整了格式）：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types"> <ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date> <ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date> <ns1:min-long>160.4685</ns1:min-long> <ns1:max-long>178.19693</ns1:max-long> <ns1:min-lat>-42.423557</ns1:min-lat> <ns1:max-lat>-30.44976</ns1:max-lat> </ns1:matchQuakes> </soapenv:Body> </soapenv:Envelope> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9"> <ns1:result-set> <ns1:area-name>New Zealand Region</ns1:area-name> <ns1:regions count="0"> <ns1:region ident="rgn159" index="159">NORTH ISLAND, NEW ZEALAND</ns1:region> <ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND, N.Z.</ns1:region> </ns1:regions> <ns1:quakes count="9"> <ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000" latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4" method="ML" region="rgn160"/> <ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0" latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5" method="ML" region="rgn160"/> <ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600" latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6" method="ML" region="rgn159"/> <ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000" latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3" method="MB" region="rgn159"/> <ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600" latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0" method="ML" region="rgn159"/> <ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700" latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0" method="ML" region="rgn159"/> <ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300" latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3" method="ML" region="rgn159"/> <ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900" latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5" method="ML" region="rgn159"/> <ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400" latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5" method="ML" region="rgn159"/> </ns1:quakes> </ns1:result-set> </ns1:results> </soapenv:Body> </soapenv:Envelope> |
在測試中，客戶機將查詢範圍調整為整體地震數據集的一部分，並生成一系列偽隨機請求。每次使用相同輸入參數運行客戶機所生成的請求序列都是相同的，這允許我們測試不同的 Web 服務配置。通過更改客戶機的輸入參數（用於更改請求所使用的查詢範圍），可以輕鬆地測試不同的結果消息大小。
WS-Security 性能
本文所示的測試結果基於兩個請求序列。第一個序列使用 1,000 條請求，查詢參數經過調整以便各查詢只匹配整個地震資料庫的一小部分（1,000 條請求僅返回 826 次匹配的地震）。第二個序列使用 100 條請求，同時調整以匹配更大的資料庫部分（100 條請求返回 176,745 次匹配的地震）。每個請求序列都在不同的安全性配置下運行了多次，每種配置只取最好的測試結果。
運行測試的環境是 Mandriva 2009.1 64-bit Linux® 系統、Athlon X2 5400+ 處理器、4GB 內存和 Sun Java 1.6.0_13 32 位 JVM。伺服器代碼在 Tomcat 6.0.20 上運行，配置為使用 1,024MB 大小的堆，客戶機代碼使用 512MB 大小的堆。我們使用 1.5 版本的 Axis2，並使用最新版本的 Rampart 代碼。（在本文測試時，還沒有與 Axis2 1.5 代碼相匹配的 Rampart 發行版可用。要運行完整的測試集，為 Tomcat 配置 1,024MB 大小的堆是非常必要的（為各安全性配置使用單獨的 Web 服務應用程序）；剛開始使用 256MB 大小的堆執行測試時，WS-Security 測試有時會因為各種奇怪的錯誤（舉例來說，未提供 DTD 時出現的 “SOAP message MUST NOT contain a Document Type Declaration(DTD)” 錯誤）或者 java.lang.OutOfMemoryError 而失敗。
我們使用以下安全性配置運行各測試：
實際測試時間從 plain 配置的 4 秒到 signencr 配置的 55 秒。圖 1 顯示了相對測試時間，為便於比較使用了相對 plain 配置時間的倍數：
從 圖 1 中可以看出，Secure Sockets Layer (SSL) — 從技術上說，現在應該稱作 Transport Layer Security (TLS)，但本文仍然使用為人所熟知的舊錶示方法 — 加密所提供的性能接近無保護措施時的性能水平（但其處理大消息比處理小消息的性能要好，處理小消息所花的時間要長 80％，處理大消息所花的時間要長 20％）。另一方面，使用 WS-Security 會造成性能顯著降低。僅在請求消息上添加簡單的 UsernameToken 報頭會造成性能降低到 SSL 處理小消息時的性能水平，但比使用 SLL 處理大消息時的性能慢 幾倍。在簽名與加密相結合的情況下，測試時間比無保護措施下要長 2,100％。
從一定程序上說，WS-Security 帶來的這種性能上的影響歸因於 Rampart 處理程序實現的缺陷，這會造成每次有 Rampart 參與時都將各請求和響應消息轉換成 Document Object Model (DOM) 格式（即使未對消息執行任何安全性處理）。應該在 Rampart 1.5 發行版中修復此問題以便它可以兼容 Axis2 1.5。根據修復的實現方式，它可以顯著改善 UsernameToken 測試的運行時間。但是，即使修復了此問題可能也不會影響其他的 WS-Security 運行時間。
與 WS-Security 相結合的 XML Signature 和 XML Encryption 的運行方式，以及 WS-Security 和這些 XML 標準的實現所使用的庫也是影響性能的因素之一。還記得 “Java Web 服務：Axis2 WS-Security 簽名和加密” 這篇文章說過，簽名 XML 消息需要一個叫做規範化 的步驟，用於在捕獲簽名值之前將 XML 轉換為特定的規範格式。標準需要這一步驟是因為已經確定即使在解析器分解 XML 並重新生成它之後也需要保留簽名。雖然這毫無疑問是 XML Signature 的一個實用的特性，但它為處理增加了大量的開銷。在一定程度上，由於使用 DOM 模型是實現規範化最簡單的一種方法，因此 XML 安全性庫都被設計為操作 XML 的 DOM 表示。（這是為何 Rampart 處理程序即使在參與服務或客戶機任務時也要生成 DOM 的原因，但前提是 DOM 有必要的作用）。僅將數據轉換成 DOM 表示的步驟就會造成大量的 WS-Security 開銷，這可以從 UsernameToken 時間看出。在大響應消息的情況中，這種開銷看上去與實際的簽名或加密處理相當（如 圖 1 所示，比較 username 測試的紅柱 — 其中，唯一的主要開銷是 DOM 的創建 — 與 sign 和 encr 測試的紅柱，其中，實際的加密處理是在創建 DOM 之後完成的）。
[火星人 ] Java Web 服務: WS-Security 的大開銷已經有689次圍觀
