㈠ 如何正確防禦xss攻擊
傳統防禦技術
2.1.1基於特徵的防禦
傳統XSS防禦多採用特徵匹配方式，在所有提交的信息中都進行匹配檢查。對於這種類型的XSS攻擊，採用的模式匹配方法一般會需要對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定為XSS攻擊。
2.1.2 基於代碼修改的防禦
和SQL注入防禦一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應用開發的角度來避免：
1、對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度范圍內、採用適當格式、採用所預期的字元的內容提交，對其他的一律過濾。
2、實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。
3、確認接收的的內容被妥善的規范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
當然，如上方法將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字元，人與系統間的交互被降到極致，僅適用於信息發布型站點。
並且考慮到很少有Web編碼人員受過正規的安全培訓，很難做到完全避免頁面中的XSS漏洞。
(1)javaweb安全策略擴展閱讀：
XSS攻擊的危害包括
1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
2、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
3、盜竊企業重要的具有商業價值的資料
4、非法轉賬
5、強制發送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發起攻擊
受攻擊事件
新浪微博XSS受攻擊事件
2011年6月28日晚，新浪微博出現了一次比較大的XSS攻擊事件。
大量用戶自動發送諸如：
「郭美美事件的一些未注意到的細節」，「建黨大業中穿幫地方」，「讓女人心動的100句詩歌」，「這是傳說中的神仙眷侶啊」等等微博和私信，並自動關注一位名為hellosamy的用戶。
事件的經過線索如下：
20:14，開始有大量帶V的認證用戶中招轉發蠕蟲
20:30，某網站中的病毒頁面無法訪問
20:32，新浪微博中hellosamy用戶無法訪問
21:02，新浪漏洞修補完畢
網路貼吧xss攻擊事件
2014年3月9晚，六安吧等幾十個貼吧出現點擊推廣貼會自動轉發等。並且吧友所關注的每個關注的貼吧都會轉一遍，病毒循環發帖。並且導致吧務人員，和吧友被封禁。
㈡ java.lang.NullPointerException問題.
NullPointerException顧名思義就是空指針啦~~
比如獲取一個String放到一個變數里的時候，有沒有可能沒取到，然後調用那些字元串的方法的時候就樣啦~~
再比如rs已經指到空行了，還要讓它getInt()或getString()~~~
這個問題是相當常見的，需要你比較細心地一行一行地看代碼，看看有沒有什麼邊界條件沒有考慮到的
你這里沒給出具體的程序，我也就只能給你分析這么多了，不知道有沒幫到你呢？
後面那個應該是路徑錯了吧，你有沒有把相應的類放在那個指定目錄下面？
㈢ javaweb開發怎麼防止機器攻擊一直刷簡訊驗證碼
一般現在系統群發的驗證碼都是由專門的簡訊群發平台發送的，號段一般是106，如果有收不到的情況，可能是被運營商攔截了或者是系統延遲了
㈣ 安全開發運維必備的Nginx代理Web伺服器性能優化與安全加固配置
為了更好的指導部署與測試藝術升系統nginx網站伺服器高性能同時下安全穩定運行,需要對nginx服務進行調優與加固;
本次進行Nginx服務調優加固主要從以下幾個部分：
本文檔僅供內部使用，禁止外傳，幫助研發人員，運維人員對系統長期穩定的運行提供技術文檔參考。
Nginx是一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP伺服器。Nginx作為負載均衡伺服器, Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務，也可以支持作為 HTTP代理伺服器對外進行服務。
Nginx版本選擇:
項目結構:
Nginx文檔幫助: http://nginx.org/en/docs/
Nginx首頁地址目錄: /usr/share/nginx/html
Nginx配置文件:
localtion 請求匹配的url實是一個正則表達式:
Nginx 匹配判斷表達式:
例如,匹配末尾為如下後綴的靜態並判斷是否存在該文件, 如不存在則404。
查看可用模塊編譯參數：http://nginx.org/en/docs/configure.html
http_gzip模塊
開啟gzip壓縮輸出(常常是大於1kb的靜態文件)，減少網路傳輸;
http_fastcgi_mole模塊
nginx可以用來請求路由到FastCGI伺服器運行應用程序由各種框架和PHP編程語言等。可以開啟FastCGI的緩存功能以及將靜態資源進行剝離，從而提高性能。
keepalive模塊
長連接對性能有很大的影響，通過減少CPU和網路開銷需要開啟或關閉連接;
http_ssl_mole模塊
Nginx開啟支持Https協議的SSL模塊
Linux內核參數部分默認值不適合高並發,Linux內核調優，主要涉及到網路和文件系統、內存等的優化，
下面是我常用的內核調優配置：
文件描述符
文件描述符是操作系統資源，用於表示連接、打開的文件，以及其他信息。NGINX 每個連接可以使用兩個文件描述符。
例如如果NGINX充當代理時，通常一個文件描述符表示客戶端連接，另一個連接到代理伺服器，如果開啟了HTTP 保持連接，這個比例會更低（譯註：為什麼更低呢）。
對於有大量連接服務的系統，下面的設置可能需要調整一下：
精簡模塊:Nginx由於不斷添加新的功能，附帶的模塊也越來越多,建議一般常用的伺服器軟體使用源碼編譯安裝管理;
(1) 減小Nginx編譯後的文件大小
(2) 指定GCC編譯參數
修改GCC編譯參數提高編譯優化級別穩妥起見採用 -O2 這也是大多數軟體編譯推薦的優化級別。
GCC編譯參數優化 [可選項] 總共提供了5級編譯優化級別：
常用編譯參數:
緩存和壓縮與限制可以提高性能
NGINX的一些額外功能可用於提高Web應用的性能，調優的時候web應用不需要關掉但值得一提，因為它們的影響可能很重要。
簡單示例:
1) 永久重定向
例如，配置 http 向 https 跳轉 (永久)
nginx配置文件指令優化一覽表
描述:Nginx因為安全配置不合適導致的安全問題,Nginx的默認配置中存在一些安全問題,例如版本號信息泄露、未配置使用SSL協議等。
對Nginx進行安全配置可以有效的防範一些常見安全問題，按照基線標准做好安全配置能夠減少安全事件的發生,保證採用Nginx伺服器系統應用安全運行;
Nginx安全配置項：
溫馨提示: 在修改相應的源代碼文件後需重新編譯。
設置成功後驗證:
應配置非root低許可權用戶來運行nginx服務,設置如下建立Nginx用戶組和用戶，採用user指令指運行用戶
加固方法:
我們應該為提供的站點配置Secure Sockets Layer Protocol (SSL協議)，配置其是為了數據傳輸的安全，SSL依靠證書來驗證伺服器的身份，並為瀏覽器和伺服器之間的通信加密。
不應使用不安全SSLv2、SSLv3協議即以下和存在脆弱性的加密套件(ciphers), 我們應該使用較新的TLS協議也應該優於舊的,並使用安全的加密套件。
HTTP Referrer Spam是垃圾信息發送者用來提高他們正在嘗試推廣的網站的互聯網搜索引擎排名一種技術，如果他們的垃圾信息鏈接顯示在訪問日誌中，並且這些日誌被搜索引擎掃描，則會對網站排名產生不利影響
加固方法:
當惡意攻擊者採用掃描器進行掃描時候利用use-agent判斷是否是常用的工具掃描以及特定的版本,是則返回錯誤或者重定向;
Nginx支持webdav，雖然默認情況下不會編譯。如果使用webdav，則應該在Nginx策略中禁用此規則。
加固方法: dav_methods 應設置為off
當訪問一個特製的URL時，如"../nginx.status"，stub_status模塊提供一個簡短的Nginx伺服器狀態摘要,大多數情況下不應啟用此模塊。
加固方法：nginx.conf文件中stub_status不應設置為：on
如果在瀏覽器中出現Nginx自動生成的錯誤消息，默認情況下會包含Nginx的版本號,這些信息可以被攻擊者用來幫助他們發現伺服器的潛在漏洞
加固方法: 關閉"Server"響應頭中輸出的Nginx版本號將server_tokens應設置為：off
client_body_timeout設置請求體（request body）的讀超時時間。僅當在一次readstep中，沒有得到請求體，就會設為超時。超時後Nginx返回HTTP狀態碼408(Request timed out)。
加固方法：nginx.conf文件中client_body_timeout應設置為：10
client_header_timeout設置等待client發送一個請求頭的超時時間（例如：GET / HTTP/1.1）。僅當在一次read中沒有收到請求頭，才會設為超時。超時後Nginx返回HTTP狀態碼408(Request timed out)。
加固方法：nginx.conf文件中client_header_timeout應設置為：10
keepalive_timeout設置與client的keep-alive連接超時時間。伺服器將會在這個時間後關閉連接。
加固方法：nginx.conf文件中keepalive_timeout應設置為：55
send_timeout設置客戶端的響應超時時間。這個設置不會用於整個轉發器，而是在兩次客戶端讀取操作之間。如果在這段時間內，客戶端沒有讀取任何數據，Nginx就會關閉連接。
加固方法：nginx.conf文件中send_timeout應設置為：10
GET和POST是Internet上最常用的方法。Web伺服器方法在RFC 2616中定義禁用不需要實現的可用方法。
加固方法:
limit_zone 配置項限制來自客戶端的同時連接數。通過此模塊可以從一個地址限制分配會話的同時連接數量或特殊情況。
加固方法：nginx.conf文件中limit_zone應設置為：slimits $binary_remote_addr 5m
該配置項控制一個會話同時連接的最大數量，即限制來自單個IP地址的連接數量。
加固方法：nginx.conf 文件中 limit_conn 應設置為: slimits 5
加固方法：
加固方法:
解決辦法:
描述後端獲取Proxy後的真實Client的IP獲取需要安裝--with-http_realip_mole，然後後端程序採用JAVA(request.getAttribute("X-Real-IP"))進行獲取;
描述: 如果要使用geoip地區選擇,我們需要再nginx編譯時加入 --with-http_geoip_mole 編譯參數。
描述: 為了防止外部站點引用我們的靜態資源，我們需要設置那些域名可以訪問我們的靜態資源。
描述: 下面收集了Web服務中常規的安全響應頭, 它可以保證不受到某些攻擊,建議在指定的 server{} 代碼塊進行配置。
描述: 為了防止某些未備案的域名或者惡意鏡像站域名綁定到我們伺服器上, 導致伺服器被警告關停，將會對業務或者SEO排名以及企業形象造成影響，我們可以通過如下方式進行防範。
執行結果:
描述: 有時你的網站可能只需要被某一IP或者IP段的地址請求訪問，那麼非白名單中的地址訪問將被阻止訪問, 我們可以如下配置;
常用nginx配置文件解釋：
(1) 阿里巴巴提供的Concat或者Google的PageSpeed模塊實現這個合並文件的功能。
(2) PHP-FPM的優化
如果您高負載網站使用PHP-FPM管理FastCGI對於PHP-FPM的優化非常重要
(3) 配置Resin on Linux或者Windows為我們可以打開 resin-3.1.9/bin/httpd.sh 在不影響其他代碼的地方加入:-Dhttps.protocols=TLSv1.2, 例如
原文地址: https://blog.weiyigeek.top/2019/9-2-122.html
㈤ java web 開發 購物網站 怎麼做訂單結算部分
我寫過兩次訂單結算,不過都是asp.net下的,但是應該差不多吧.訂單結算是最後的步驟,提交訂單之後需要做結算,實際上就是收錢嘛.
傳統來講此時需要一個支付介面,比如說支付寶財付通快錢 網銀在線之類的,他們提供介面,我們按照他們說明文檔來實現就好.重要的是交易記錄哦！！提交訂單後需要交易日誌(不能從字面意義上來理解"交易",實際上跟別人討價還價也是交易的一種不是嘛.)轉到介面前需要日誌,介面返回信息需要日誌(表結構差不多啦)這些日誌,方便以後退款或者查看狀態使用;
不傳統來講除支付介面外,要考慮購物網站個人錢包支付或者線下匯款之類的 建議使用策略模式
額 不知道說啥了.縷一縷在紙上構思下就差不多 但一定要考慮好安全性
㈥ 深入分析Java Web技術內幕的圖書目錄
第1章 深入Web請求過程 1
1.1 B/S網路架構概述 2
1.2 如何發起一個請求 4
1.3 HTTP協議解析 6
1.3.1 查看HTTP信息的工具 8
1.3.2 瀏覽器緩存機制 9
1.4 DNS域名解析 12
1.4.1 DNS域名解析過程 12
1.4.2 跟蹤域名解析過程 15
1.4.3 清除緩存的域名 18
1.4.4 幾種域名解析方式 19
1.5 CDN工作機制 20
1.5.1 CDN架構 20
1.5.2 負載均衡 21
1.6 總結 24
第2章 深入分析Java I/O的工作機制 25
2.1 Java的I/O類庫的基本架構 25
2.1.1 基於位元組的I/O操作介面 26
2.1.2 基於字元的I/O操作介面 27
2.1.3 位元組與字元的轉化介面 28
2.2 磁碟I/O工作機制 29
2.2.1 幾種訪問文件的方式 29
2.2.2 Java訪問磁碟文件 33
2.2.3 Java序列化技術 34
2.3 網路I/O工作機制 36
2.3.1 TCP狀態轉化 37
2.3.2 影響網路傳輸的因素 39
2.3.3 Java Socket的工作機制 39
2.3.4 建立通信鏈路 40
2.3.5 數據傳輸 41
2.4 NIO的工作方式 41
2.4.1 BIO帶來的挑戰 41
2.4.2 NIO的工作機制 42
2.4.3 Buffer的工作方式 45
2.4.4 NIO的數據訪問方式 47
2.5 I/O調優 49
2.5.1 磁碟I/O優化 49
2.5.2 TCP網路參數調優 50
2.5.3 網路I/O優化 52
2.6 設計模式解析之適配器模式 56
2.6.1 適配器模式的結構 56
2.6.2 Java I/O中的適配器模式 57
2.7 設計模式解析之裝飾器模式 57
2.7.1 裝飾器模式的結構 58
2.7.2 Java I/O中的裝飾器模式 58
2.8 適配器模式與裝飾器模式的區別 59
2.9 總結 59
第3章 深入分析Java Web中的中文編碼問題 60
3.1 幾種常見的編碼格式 60
3.1.1 為什麼要編碼 60
3.1.2 如何「翻譯」 61
3.2 Java中需要編碼的場景 63
3.2.1 I/O操作中存在的編碼 63
3.2.2 內存操作中的編碼 65
3.3 Java中如何編解碼 66
3.3.1 按照ISO-8859-1編碼 68
3.3.2 按照GB2312編碼 69
3.3.3 按照GBK編碼 70
3.3.4 按照UTF-16編碼 70
3.3.5 按照UTF-8編碼 71
3.3.6 UTF-8編碼代碼片段 71
3.3.7 幾種編碼格式的比較 73
3.4 Java Web中涉及的編解碼 73
3.4.1 URL的編解碼 75
3.4.2 HTTP Header的編解碼 78
3.4.3 POST表單的編解碼 78
3.4.4 HTTP BODY的編解碼 79
3.5 JS中的編碼問題 80
3.5.1 外部引入JS文件 80
3.5.2 JS的URL編碼 81
3.5.3 其他需要編碼的地方 83
3.6 常見問題分析 83
3.6.1 中文變成了看不懂的字元 83
3.6.2 一個漢字變成一個問號 84
3.6.3 一個漢字變成兩個問號 84
3.6.4 一種不正常的正確編碼 85
3.7 總結 86
第4章 Javac編譯原理 87
4.1 Javac是什麼 88
4.2 Javac編譯器的基本結構 88
4.3 Javac工作原理分析 90
4.3.1 詞法分析器 91
4.3.2 語法分析器 98
4.3.3 語義分析器 103
4.3.4 代碼生成器 113
4.4 設計模式解析之訪問者模式 116
4.4.1 訪問者模式的結構 117
4.4.2 Javac中訪問者模式的實現 118
4.5 總結 119
第5章 深入class文件結構 120
5.1 JVM指令集簡介 120
5.1.1 類相關的指令 122
5.1.2 方法的定義 123
5.1.3 屬性的定義 124
5.1.4 其他指令集 125
5.2 class文件頭的表示形式 133
5.3 常量池 137
5.3.1 UTF8常量類型 140
5.3.2 Fieldref、Methodref常量類型 141
5.3.3 Class常量類型 141
5.3.4 NameAndType常量類型 142
5.4 類信息 142
5.5 Fields和Methods定義 143
5.6 類屬性描述 147
5.7 Javap生成的class文件結構 148
5.7.1 LineNumberTable 150
5.7.2 LocalVariableTable 151
5.8 總結 153
第6章 深入分析ClassLoader 工作機制 154
6.1 ClassLoader類結構分析 155
6.2 ClassLoader的等級載入機制 156
6.3 如何載入class文件 159
6.3.1 載入位元組碼到內存 159
6.3.2 驗證與解析 161
6.3.3 初始化Class對象 161
6.4 常見載入類錯誤分析 161
6.4.1 ClassNotFoundException 161
6.4.2 NoClassDefFoundError 162
6.4.3 UnsatisfiedLinkError 163
6.4.4 ClassCastException 164
6.4.5 ExceptionInInitializerError 165
6.5 常用的ClassLoader分析 166
6.6 如何實現自己的ClassLoader 170
6.6.1 載入自定義路徑下的class文件 170
6.6.2 載入自定義格式的class文件 172
6.7 實現類的熱部署 174
6.8 Java應不應該動態載入類 176
6.9 總結 177
第7章 JVM體系結構與工作方式 178
7.1 JVM體系結構 178
7.1.1 何謂JVM 178
7.1.2 JVM體系結構詳解 181
7.2 JVM工作機制 183
7.2.1 機器如何執行代碼 183
7.2.2 JVM為何選擇基於棧的架構 184
7.2.3 執行引擎的架構設計 185
7.2.4 執行引擎的執行過程 186
7.2.5 JVM方法調用棧 191
7.3 總結 195
第8章 JVM內存管理 196
8.1 物理內存與虛擬內存 197
8.2 內核空間與用戶空間 198
8.3 Java中哪些組件需要使用內存 199
8.3.1 Java堆 199
8.3.2 線程 199
8.3.3 類和類載入器 200
8.3.4 NIO 200
8.3.5 JNI 201
8.4 JVM內存結構 201
8.4.1 PC寄存器 202
8.4.2 Java棧 202
8.4.3 堆 203
8.4.4 方法區 203
8.4.5 運行時常量池 204
8.4.6 本地方法棧 204
8.5 JVM內存分配策略 204
8.5.1 通常的內存分配策略 205
8.5.2 Java中內存分配詳解 205
8.6 JVM內存回收策略 210
8.6.1 靜態內存分配和回收 210
8.6.2 動態內存分配和回收 211
8.6.3 如何檢測垃圾 211
8.6.4 基於分代的垃圾收集演算法 213
8.7 內存問題分析 222
8.7.1 GC日誌分析 222
8.7.2 堆快照文件分析 225
8.7.3 JVM Crash日誌分析 225
8.8 實例1 231
8.9 實例2 233
8.10 實例3 235
8.11 總結 240
第9章 Servlet工作原理解析 241
9.1 從Servlet容器說起 241
9.1.1 Servlet容器的啟動過程 242
9.1.2 Web應用的初始化工作 245
9.2 創建Servlet實例 247
9.2.1 創建Servlet對象 248
9.2.2 初始化Servlet 248
9.3 Servlet體系結構 250
9.4 Servlet如何工作 253
9.5 Servlet中的Listener 255
9.6 Filter如何工作 257
9.7 Servlet中的url-pattern 259
9.8 總結 260
第10章 深入理解Session與Cookie 261
10.1 理解Cookie 262
10.1.1 Cookie屬性項 262
10.1.2 Cookie如何工作 263
10.1.3 使用Cookie的限制 266
10.2 理解Session 267
10.2.1 Session與Cookie 267
10.2.2 Session如何工作 268
10.3 Cookie安全問題 271
10.4 分布式Session框架 272
10.4.1 存在哪些問題 272
10.4.2 可以解決哪些問題 273
10.4.3 總體實現思路 273
10.5 Cookie壓縮 278
10.6 表單重復提交問題 280
10.7 總結 281
第11章 Tomcat的系統架構與 設計模式 282
11.1 Tomcat總體設計 282
11.1.1 Tomcat總體結構 283
11.1.2 Connector組件 289
11.1.3 Servlet容器Container 294
11.1.4 Tomcat中的其他組件 305
11.2 Tomcat中的設計模式 305
11.2.1 門面設計模式 305
11.2.2 觀察者設計模式 307
11.2.3 命令設計模式 309
11.2.4 責任鏈設計模式 310
11.3 總結 312
第12章 Jetty的工作原理解析 313
12.1 Jetty的基本架構 313
12.1.1 Jetty的基本架構簡介 313
12.1.2 Handler的體系結構 315
12.2 Jetty的啟動過程 316
12.3 接受請求 317
12.3.1 基於HTTP協議工作 317
12.3.2 基於AJP工作 319
12.3.3 基於NIO方式工作 322
12.4 處理請求 323
12.5 與Jboss集成 326
12.6 與Tomcat的比較 327
12.6.1 架構比較 327
12.6.2 性能比較 328
12.6.3 特性比較 328
12.7 總結 329
第13章 Spring框架的設計理念與 設計模式分析 330
13.1 Spring的骨骼架構 330
13.1.1 Spring的設計理念 331
13.1.2 核心組件如何協同工作 332
13.2 核心組件詳解 333
13.2.1 Bean組件 333
13.2.2 Context組件 335
13.2.3 Core組件 336
13.2.4 Ioc容器如何工作 338
13.3 Spring中AOP特性詳解 348
13.3.1 動態代理的實現原理 348
13.3.2 Spring AOP如何實現 351
13.4 設計模式解析之代理模式 354
13.4.1 代理模式原理 354
13.4.2 Spring中代理模式的實現 354
13.5 設計模式解析之策略模式 357
13.5.1 策略模式原理 357
13.5.2 Spring中策略模式的實現 358
13.6 總結 358
第14章 Spring MVC工作機制與 設計模式 360
14.1 Spring MVC的總體設計 360
14.2 Control設計 365
14.2.1 HandlerMapping初始化 366
14.2.2 HandlerAdapter初始化 368
14.2.3 Control的調用邏輯 369
14.3 Model設計 370
14.4 View設計 371
14.5 框架設計的思考 373
14.5.1 為什麼需要框架 373
14.5.2 需要什麼樣的框架 373
14.5.3 框架設計的原則 374
14.5.4 「指航燈」 374
14.5.5 最基本的原則 374
14.6 設計模式解析之模板模式 375
14.6.1 模板模式的結構 375
14.6.2 Spring MVC中的模板模式示例 376
14.7 總結 377
第15章 深入分析Ibatis框架之系統 架構與映射原理 378
15.1 Ibatis框架主要的類層次結構 378
15.2 Ibatis框架的設計策略 379
15.3 Ibatis框架的運行原理 381
15.4 示例 383
15.5 Ibatis對SQL語句的解析 385
15.6 資料庫欄位映射到Java對象 386
15.7 示例運行的結果 388
15.8 設計模式解析之簡單工廠模式 388
15.8.1 簡單工廠模式的實現原理 388
15.8.2 Ibatis中的簡單工廠模式示例 389
15.9 設計模式解析之工廠模式 390
15.9.1 工廠模式的實現原理 390
15.9.2 Ibatis中的工廠模式示例 391
15.10 總結 392
第16章 Velocity工作原理解析 394
16.1 Velocity總體架構 395
16.2 JJTree渲染過程解析 398
16.2.1 #set語法 402
16.2.2 Velocity的方法調用 403
16.2.3 #if、#elseif和#else語法 406
16.2.4 #foreach語法 407
16.2.5 #parse語法 409
16.3 事件處理機制 410
16.4 常用優化技巧 413
16.4.1 減少樹的總節點數量 413
16.4.2 減少渲染耗時的節點數量 413
16.5 與JSP比較 414
16.5.1 JSP渲染機制 414
16.5.2 Velocity與JSP 420
16.6 設計模式解析之合成模式 420
16.6.1 合成模式的結構 420
16.6.2 Velocity中合成模式的實現 421
16.7 設計模式解析之解釋器模式 422
16.7.1 解釋器模式的結構 422
16.7.2 Velocity中解釋器模式的實現 423
16.8 總結 423
第17章 Velocity優化實踐 424
17.1 現實存在的問題 424
17.2 優化的理論基礎 425
17.2.1 程序語言的三角形結構 425
17.2.2 數據結構減少抽象化 426
17.2.3 簡單的程序復雜化 426
17.2.4 減少翻譯的代價 427
17.2.5 變的轉化為不變 427
17.3 一個高效的模板引擎的實現思路 427
17.3.1 vm模板如何被編譯 429
17.3.2 方法調用的無反射優化 436
17.3.3 字元輸出改成位元組輸出 439
17.4 優化的成果 440
17.4.1 char轉成byte 440
17.4.2 無反射執行 441
17.5 其他優化手段 442
17.6 總結 442
㈦ 編寫java web的類，該類能不能有成員變數
以前我也和你有過同樣的困惑，仔細分析一下，什麼時候會有線程安全問題呢？當多個線程並發修改和讀取某個變數時就會發生。
一般的類，被容器或框架實現成了一個單例，而web程序明顯是多線程的，所以在沒有任何防範措施的情況下給聲明屬性變數，可能會造成線程安全問題，同理，service層也存在這樣的問題。
如何才能讓擁有屬性變數，又不會造成線程安全問題呢？我所了解的有幾種策略，但都存在各自的問題：
1. 最省心的辦法是使用ThreadLocal類，但是在線程池環境下需要小心地設置和刪除ThreadLocal線程局部變數，以保證不同用戶線程之間數據的正確性和隱私；
2. 可以對每個涉及到的方法加鎖，線程同步等待獲得鎖會帶來大把的性能損失；
3. 也可以將屬性聲明成volatile的，不過在某些情況下並不總是線程安全的。
順便說一句，spring代理的DataSource實際上也是通過ThreadLocal來存取Connection的，這樣即保證了每個請求的數據獨立性，又實現了在一次請求中跨類跨方法的進行事務管理。
綜上所述，線程問題會給你帶來無窮無盡的煩惱，所以能不在里做這樣的事最好，方法內部的局部變數是最安全的，或者每次使用都重新new一個對象出來，單例對象是邪惡的，我們沒必要為了節省那一點點可憐的內存被搞得焦頭爛額的。
㈧ 網路安全的主要類型
計算機網路安全技術簡稱網路安全技術，指致力於解決諸如如何有效進行介入控制，以及如何保證數據傳輸的安全性的技術手段，主要包括物理安全分析技術，網路結構安全分析技術，系統安全分析技術，管理安全分析技術，及其它的安全服務和安全機制策略。
技術分類虛擬網技術
虛擬網技術主要基於近年發展的區域網交換技術(ATM和乙太網交換）。交換技術將傳統的基於廣播的區域網技術發展為面向連接的技術。因此，網管系統有能力限制區域網通訊的范圍而無需通過開銷很大的路由器。防火牆技術網路防火牆技術是一種用來加強網路之間訪問控制,防止外部網路用戶以非法手段通過外部網路進入內部網路,訪問內部網路資源,保護內部網路操作環境的特殊網路互聯設備.它對兩個或多個網路之間傳輸的數據包如鏈接方式按照一定的安全策略來實施檢查,以決定網路之間的通信是否被允許,並監視網路運行狀態.
防火牆產品主要有堡壘主機,包過濾路由器,應用層網關(代理伺服器)以及電路層網關,屏蔽主機防火牆,雙宿主機等類型.
病毒防護技術
病毒歷來是信息系統安全的主要問題之一。由於網路的廣泛互聯，病毒的傳播途徑和速度大大加快。
將病毒的途徑分為：
(1 ) 通過FTP，電子郵件傳播。
(2) 通過軟盤、光碟、磁帶傳播。
(3) 通過Web游覽傳播，主要是惡意的Java控制項網站。
(4) 通過群件系統傳播。
病毒防護的主要技術如下：
(1) 阻止病毒的傳播。
在防火牆、代理伺服器、SMTP伺服器、網路伺服器、群件伺服器上安裝病毒過濾軟體。在桌面PC安裝病毒監控軟體。
(2) 檢查和清除病毒。
使用防病毒軟體檢查和清除病毒。
(3) 病毒資料庫的升級。
病毒資料庫應不斷更新，並下發到桌面系統。
(4) 在防火牆、代理伺服器及PC上安裝Java及ActiveX控制掃描軟體，禁止未經許可的控制項下載和安裝。入侵檢測技術利用防火牆技術，經過仔細的配置，通常能夠在內外網之間提供安全的網路保護，降低了網路安全風險。但是，僅僅使用防火牆、網路安全還遠遠不夠：
(1) 入侵者可尋找防火牆背後可能敞開的後門。
(2) 入侵者可能就在防火牆內。
(3) 由於性能的限制，防火牆通常不能提供實時的入侵檢測能力。入侵檢測系統是近年出現的新型網路安全技術，目的是提供實時的入侵檢測及採取相應的防護手段，如記錄證據用於跟蹤和恢復、斷開網路連接等。
實時入侵檢測能力之所以重要首先它能夠對付來自內部網路的攻擊，其次它能夠縮短hacker入侵的時間。
入侵檢測系統可分為兩類：基於主機和基於網路的入侵檢測系統。安全掃描技術
網路安全技術中，另一類重要技術為安全掃描技術。安全掃描技術與防火牆、安全監控系統互相配合能夠提供很高安全性的網路。
安全掃描工具通常也分為基於伺服器和基於網路的掃描器。
認證和數字簽名技術
認證技術主要解決網路通訊過程中通訊雙方的身份認可，數字簽名作為身份認證技術中的一種具體技術，同時數字簽名還可用於通信過程中的不可抵賴要求的實現。VPN技術1、企業對VPN 技術的需求
企業總部和各分支機構之間採用internet網路進行連接，由於internet是公用網路，因此，必須保證其安全性。我們將利用公共網路實現的私用網路稱為虛擬私用網(VPN)。
2、數字簽名
數字簽名作為驗證發送者身份和消息完整性的根據。公共密鑰系統(如RSA)基於私有/公共密鑰對，作為驗證發送者身份和消息完整性的根據。CA使用私有密鑰計算其數字簽名，利用CA提供的公共密鑰，任何人均可驗證簽名的真實性。偽造數字簽名從計算能力上是不可行的。
3、IPSEC
IPSec作為在IP v4及IP v6上的加密通訊框架，已為大多數廠商所支持，預計在1998年將確定為IETF標准，是VPN實現的Internet標准。
IPSec主要提供IP網路層上的加密通訊能力。該標准為每個IP包增加了新的包頭格式，Authentication Header(AH)及encapsualting security payload(ESP)。IPsec使用ISAKMP/Oakley及SKIP進行密鑰交換、管理及加密通訊協商(Security Association)。
㈨ 為什麼我的電腦不能運行java web start
Java Web Start 是幫助客戶機端應用程序開發的一個新技術，它的獨特之處在於將您從關心客戶機是如何啟動的（從 Web 瀏覽器或是桌面）中解放出來。另外，該技術提供了一個使 Web 伺服器能獨立的分發和更新客戶機代碼的集合部署方案。軟體工程師 Steve Kim 介紹了該新技術（該技術預定將集成進Java 1.4 的最終發行版），並從開發者和用戶的角度進行了描述。您可以在 討論論壇與作者和其他讀者分享您對這篇文章的看法。
在現今的不斷發展的軟體業市場，用戶強烈要求客戶機應用程序不但能運行在台式機環境，還能運行在網際網路。用戶希望他們從基於 Web 的應用程序獲得與從台式機獲得的相同的功能和支持，而且最好是用瘦客戶機介面打包。目前，最通用的解決方案是開發兩個獨立的 Java 應用程序：一個作為台式機應用程序執行，另一個模仿台式機應用程序的多數功能，但是通過 Web 訪問。這對開發者是個負擔，開發者要寫兩個獨立的在不同的執行環境執行相同的功能的應用程序，然而對軟體公司也是個財政負擔，軟體公司被迫為兩個獨立的應用程序提供支持。為緩解該問題，Sun Microsystems 引進了 Java Web Start，它是個使 Java 應用程序可以從台式機或 Web 頁面啟動的客戶機端技術。這消除了為 Web 應用程序開發 Java 支持的需要，而且還提供了一個有效方式來升級、維護和管理任何通用的 Web 伺服器都支持的客戶端的 Java 應用程序。
什麼是 Java Web Start？
Java Web Start 是一個軟體技術，它包含了 applet 的可移植性、Servlet 和 JavaServer Pages （JSP）的可維護性以及象 XML 和 HTML 這樣的標記語言的簡易性。它是基於 Java 的應用程序，允許從標準的 Web 伺服器啟動、部署和更新功能完全的 Java 2 客戶機應用程序。在第一次啟動 Java Web Start 時，用戶可以從 Web 下載新的客戶機應用程序；之後這些應用程序可以通過 Web 頁面的鏈接或（Windows 中的）桌面圖標或「開始」菜單初始化。應用程序在 Java Web Start 下快速初始化，被高速緩存在客戶機，並且可以遠程的離線啟動。另外，因為 Java Web Start 是從 Java 2 技術建立起來的，所以它繼承了 Java 平台的完整的安全性體系結構。
由於 Java Web Start 自身是一個 Java 應用程序，所以該軟體是平台獨立的，並且支持 Java 2 平台的任何客戶機系統都支持該軟體。當客戶機應用程序啟動時，Java Web Start 自動執行更新，在從原來的高速緩存（倘若存在高速緩存）裝入應用程序的同時，從 Web 下載最新的代碼。Java Web Start 還提供了一個 Java 應用程序管理器（Java Application Manager）實用程序，既提供了多種選項，如清除下載的應用程序的高速緩存、指定多種 JRE 的使用、設置 HTTP 代理，還允許最終用戶組織他們的 Java 應用程序。
回頁首
Java Web Start 對 Java 插件
Java Web Start 和 Java 插件的一個共同作用是：允許 Java 程序從任何地方、在任何平台安全運行。兩種 Java 技術都提供了可以啟動和執行 Java 程序的「沙箱（sandbox）」安全環境，還具有高速緩存應用程序和指定使用的 JRE 的能力。Java Web Start 和 Java 插件的根本不同是 Java 插件限於在 Web 瀏覽器環境中運行的 Java applet。Java 插件嚴重的依賴於 Web 瀏覽器的 JRE，並且如果沒有瀏覽器就不能運行。另一方面，Java Web Start 可以在 Web 頁面單擊鏈接或是單擊 Java 應用程序管理器來啟動 Java 應用程序。在 Windows 操作系統中，用戶可以從開始菜單或是只要雙擊桌面圖標來啟動應用程序。如果瀏覽器窗口被關閉，從 Web 瀏覽器啟動的客戶機應用程序不會受到影響。
盡管 Java Web Start 確實支持 Java applet，而且確實包含內置的 Appletviewer，但這個技術的最初目的是啟動和部署 Java 客戶機應用程序。某些約束，如 applet 的策略文件不受支持。
回頁首
用戶觀點的 Java Web Start
Java Web Start 不僅允許開發者開發可從 Web 頁面啟動和執行的應用程序（不只是 applet），還強調了無需任何用戶交互就可以為現存的客戶機代碼提供透明更新的部署方案。為幫助您理解這個過程、幫助您決定是否為與 Java Web Start 的兼容性而開發自己的應用程序，我們將從用戶的觀點來看這個產品。我將從兩個基本的用戶場景（安裝 Java Web Start 和從使用 Java Web Start 的 Web 下載和啟動應用程序）的基本解釋開始。
首次安裝 Java Web Start
Java 插件無需用戶在客戶機安裝任何的應用程序，與 Java 插件不同，Java Web Start 必須要安裝在每台用於從 Web 來啟動 Java 應用程序的客戶機。當用戶試圖用 Java Web Start 啟動一個基於 Web 的應用程序時，Web 瀏覽器將啟動 Java Web Start 從而開始下載適當的文件。
如果 Java Web Start 安裝在本地機的話，那麼需要的應用程序將正常的啟動和進行。另一方面，如果 Java Web Start 還沒安裝，用戶將被提示要下載該程序。一旦用戶同意下載 Java Web Start 並且已經下載了該文件，用戶就必須運行程序來安裝 Java Web Start，如圖 1 所示。
圖 1. 安裝 Java Web Start
在安裝過程中，Java Web Start 安裝程序將判斷在客戶機上是否安裝了 Java 2 環境。如果未安裝，將出現一個安裝對話框，如圖 2 所示。
圖 2. Java Web Start 搜索 Java 2 環境
一旦裝好了 Java Web Start，就必須關閉所有的打開的 Web 瀏覽器。新的 MIME 標記（帶有 jnlp 擴展名）是為 Web 瀏覽器定義的，用於 Web 瀏覽器啟動自身（Web 伺服器）和 Java Web Start 之間的聯系。（JNLP 是 Java Network Launching Protocol 的首字母縮略字。JNLP 文件確定哪些 JAR 文件和資源有助於客戶端的 Java 應用程序。）一旦 Web 瀏覽器被關閉並重新啟動，用戶可以再次單擊相同的鏈接來啟動所要的應用程序。Web 瀏覽器然後將與 Java Web Start 聯系，並且應用程序將開始啟動過程。
「Developer's Guide for Java Web Start」 （請參閱 參考資料）包含能夠查出本地是否安裝了 Java Web Start 的 JavaScript 和 Visual Basic 腳本。
用 Java Web Start 啟動應用程序
當用戶首次單擊一個鏈接來啟動一個客戶端的 Java 應用程序時，發生下面的過程：
Web 瀏覽器被指示運行 Java Web Start。
Java Web Start 以啟動閃屏開始
然後 Java Web Start 與指定的 Web 伺服器聯系，並且確定是否為所要的 Java 應用程序下載了所有的文件。
把適當的文件下載到本地機。
Java Web Start 運行下載的應用程序。
在整個安裝和啟動過程中，Java Web Start 與 Java Web Start 應用程序管理器一起提供了一個外觀和感覺一致的界面，同時還向用戶提供了反饋。圖 3 表示了當 Java Web Start 首次試圖啟動一個客戶機 Java 應用程序時出現的窗口。
圖 3. Java Web Start 下載客戶機 JAR 文件
Java Web Start 把一個應用程序下載到了本地機之後，客戶機程序就被執行了。將來，當程序再次從 Java Web Start 啟動時，Java Web Start 將試圖判定客戶機是否有應用程序的最新版本。在此過程中，用戶將可以看到一個與圖 4 所示的相似的窗口。
圖 4. Java Web Start 檢查應用程序的版本
從用戶的觀點來看，該窗口提供了該 Java 應用程序是在啟動過程還是在更新過程的可視化反饋。另外，進度條和文本反饋不僅通知用戶每個過程所需的時間，還讓用戶可以了解更新或啟動什麼時候將完成。這也許是該產品的最有用的特性之一，它可以確保在應用程序的啟動過程的每一步都通知了用戶正在發生什麼。
回頁首
圖形用戶界面（GUI）
應用程序管理器的 GUI （圖形用戶界面）提供了一個簡單的卻合理的界面，該界面允許用戶在啟動應用程序時可以指定多種的選項。每次啟動應用程序管理器時，出現一個閃屏，如圖 5 所示。
圖 5. 應用程序管理器閃屏
一旦閃屏消失，應用程序管理器的主窗口就顯示出來，如圖 6 所示。
圖 6. 應用程序管理器的主窗口
在 Applications 框中，可以看到和啟動所有的從 Java Web Start 啟動的應用程序。在下面的框中，提供了關於選中的 Java 應用程序的附加信息（在圖 6 中，即為 Draw 4），如供應商、可以獲得關於該應用程序的更多信息的主頁以及程序的描述。這條信息是直接從該應用程序的 JNLP 文件（稍後有更多關於 JNLP 的介紹）派生的。
在 File Preferences，有讓用戶調整和校準的多種設置。盡管大多數設置已經由 Java Web Start 自動配置了，但仍然允許用戶覆蓋不同的設置，如代理設置，如下面的圖 7 所示。
圖 7. 應用程序管理器的 Preferences 選項卡
用戶還可以指定當啟動應用程序時使用 JRE 的什麼版本，如圖 8 所示。
圖 8. 指定 JRE
本質上，應用程序管理器的目的在於為管理所有的遵照 Java Web Start 指導方針和策略的應用程序提供了一個統一的實用程序。另外，應用程序管理器允許有經驗的用戶配置一些應用程序設置。這樣免除了一些開發者將在其它方面需要做的工作，比如寫腳本或批處理文件來啟動或配置應用程序。要注意應用程序管理器僅對為 Java 2 平台編寫的而且與 Java Web Start 兼容的應用程序有用，注意到這一點是很重要的。實用程序不能查出駐留在本地機的其它 Java 應用程序。
要考慮的問題
當選擇是否為與 Java Web Start 兼容而開發應用程序時，明智的做法是對用戶體驗做全面考慮。
Java Web Start 必須安裝在每台從 Web 或從 Java 應用程序管理器啟動客戶機 Java 應用程序的機器上。所以，雖然客戶機 Java 應用程序可以從 Web 頁面啟動，但如果最初沒有 Java Web Start 安裝在本地機上的話，該應用程序本身是不能啟動的；這樣 Web 瀏覽器僅提供啟動程序的方便的鏈接 ― 不多不少。
Java Web Start 僅對正確打包的並且依照 Java Web Start 指導方針的應用程序有用。另外，需要 Web 伺服器，而且 Web 伺服器必須正確的配置來解釋 所有的JNLP 和 MIME 標記。所以，除非下載的或是從 Web 啟動的所有的客戶機 Java 應用程序滿足了這些要求，每個客戶機 Java 應用程序才能從 Java Web Start 被啟動和被管理的。
在用戶中也許有點關於 Java Web Start 和 Java 插件的應用程序與 applet 間的不同之處的困惑。用戶可能理解或還不理解為什麼 Java Web Start 能管理和啟動許多的客戶機 Java 應用程序，卻不能與以 Java 插件運行的 Java Applets 建立任何連接，盡管事實是任一程序都可以從 Web 瀏覽器啟動。
對於被要求去為僅僅一個客戶機應用程序而下載 Java Web Start 的用戶來說，可能又認為對一個客戶機 Java 應用程序的執行來說，Java Web Start 應用程序管理器的特性很累贅，安裝過程「麻煩」太多。
Java Web Start 僅能用於為 Java 2 平台編寫的客戶機 Java 應用程序。
當前，Java Web Start 可在 Windows 95/98/NT/2000、Linux 和 Solaris 操作系統上執行。
回頁首
為 Java Web Start 做開發
從開發的觀點，您應該能象為常規的客戶端應用程序一樣能為與 Java Web Start 的兼容性編寫和設計代碼。您應該相對的不用擔心更新現存的客戶機代碼所需的打包問題和變通技術。下面是您在開發和部署 Java Web Start 的客戶端 Java 應用程序時需要依照的一些簡單的規則：
應用程序可以作為針對 Java 2 平台的獨立的應用程序正常的編寫。
如果您的應用程序需要訪問本地系統，那麼 JAR 文件中的每個條目都必須被簽名。
應用程序的所有的文件必須保存在一個 JAR 文件集中，該文件集包含如圖像和聲音文件等資源。
裝入資源（如圖像）的任何訪問都必須使用有類裝載器的 getResource 方法。請參閱下面的使用 getResource 方法示例的清單 1。
清單 1. 使用 ClassLoader 對象從 JAR 文件裝入資源
//Obtain the current classloader
ClassLoader classLoader = this.getClass().getClassLoader();
//Load the company logo image
Image companyLogo = classLoader.getResource("images/companyLogo.gif");
更新應用程序代碼
從 Web 伺服器首次下載一個應用程序時，應用程序的所有的相關的 JAR 文件被下載到了本地機。Java Web Start 將自動決定該把這些文件下載到何處，這是因為預設的安全性協議（如本地磁碟存取）在起作用。下面將進一步討論安全性。
從應用程序開發和維護的觀點來看，Java Web Start 使更新應用程序代碼很容易。因為下載的應用程序的所有文件必須包含在客戶機的 JAR 文件集中，您只需更新存儲在 Web 伺服器的 JAR 文件集。Java Web Start 將根據下面將討論的版本編號方案來決定當應用程序最初被啟動時需要下載和更新客戶機的哪些文件和資源。每次用戶啟動一個應用程序時，Java Web Start 將與包含 JAR 文件集的 Web 伺服器連接，並將下載適當的文件。注意客戶機可以下載的資源僅為 JAR 文件、圖像和 JNLP 文件。
Java Web Start 使用 HTTP 請求來從 Web 伺服器獲得資源文件，並且允許客戶機端 Java 應用程序從代理伺服器或防火牆後執行。最初，Java Web Start 將既使用通用的代理自動配置腳本也試著檢測本地機的預設 Web 瀏覽器中定義的代理設置。如果需要附加信息，可用應用程序管理器使用 Preferences 部分來指定埠和代理。
回頁首
Java Web Start 的核心：JNLP
為使 Java 應用程序能用 Java Web Start 執行，您必須為應用程序創建一個 Java 網路語言協議（Java Networking Language Protocol，JNLP）文件。JNLP 是一個為應用程序提供基本的元素和描述的 XML 文件。JNLP 符合規范號為 JSR 000056（請參閱 參考資料）的 Java Community Process （JCP）。
JNLP 文件的目的如下：
指定從 Web 伺服器下載的 JAR 文件
提供其它的可能的包需要
指定系統屬性
考慮到任何必要的運行時參數
指定使用哪個版本的 Java 2 平台
JNLP 文件的一個示例
JNLP 文件以一種與 Web 瀏覽器相似的方式（僅用 URL 而不是特定的文件名）來獲得並定位文件。清單 2 表示了 JNLP 文件的一個示例。
清單 2. JNLP 文件的一個示例：clientApp.jnlp
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase=http://www.companySite.com/javaApp>
<href="clientApp.jnlp">
<information>
<title>This is my company's Java client application</title>
<vendor>Company name</vendor>
<icon href="companyLogo.gif"/>
<homepage ref="reference/tips.html">
<offline-allowed/>
</information>
<resources>
<j2se version=1.3/>
<jar href="companySong.jar" part="music" download="lazy"/>
</resources>
<resources os="Windows"/>
<nativelib="windowIconsForWindowOS.jar" part="windowIcons"
download="eager"/>
<application-desc main-class="com.company.ui.Client"/>
<security>
<all-permissions/>
</security>
</jnlp>
清單 2 的注釋
接下來對 JNLP 文件的示例的評述也許在您創建自己的文件時對您有所幫助：
第一行，您可以看到文件的編碼是 UTF-8 字元編碼。所以，當編輯 JNLP 文件時，最終文件要用與 JDK 一起提供的 native2ascii工具轉換來確保文件的編碼正確。
jnlp codebase 屬性用於在 JNLP 文件中指定所有的相關 URL。 href 屬性設置（要求的）是為了讓應用程序並入 Java Web Start 應用程序管理器。
information 標記（如 title、vendor 等）用於提供來自 Java Web Start 應用程序管理器的關於應用程序的附加信息。 homepage ref 屬性是專門用於指向 Web URL 從而用戶可以去提供了關於應用程序的更多的信息的 Web 頁面。最有趣的 information 標記是 offline-allowed 屬性；該屬性決定了客戶機 Java 應用程序是否能離線啟動。當離線運行客戶機 Java 應用程序時，Java Web Start 將繼續判定來自 Web 伺服器的最新的文件；在多數情況下，這個方案將引起快速的超時（因為位置被指定要離線啟動），並且應用程序從本地高速緩存啟動。
resource 標記考慮到 JNLP 文件指定應用程序使用哪些 JAR 文件和如何下載 JAR 文件；即，是急切的還是不緊不慢的。這個特性在當用戶要下載大量的文件而對用戶來說不是所有的文件都是客戶機執行所需要的時是非常有幫助的。預設的，多數資源是急切的下載的，在這樣情況下，JAR 文件和資源在應用程序啟動前被下載。不緊不慢的下載的資源只有當 Java 虛擬機（JVM）觸發從應用程序載入資源或文件時才被下載。不緊不慢的下載資源的一個示例是客戶機的幫助文件；考慮到了客戶機的更快的啟動和執行，只有在用戶實際上向客戶機請求幫助文件時，才會下載這些文件。然而，一旦用戶請求了一個幫助文件，在請求過程中適當的 JAR 就會被下載，並伴有一個通知用戶大致的下載時間的窗口。
JNLP 文件中最後一個有趣的標記是 security 屬性。預設的，任何從 Java Web Start 客戶機啟動的 Java 應用程序在一個安全的、受限制的環境執行，該環境中不允許進行本地文件訪問、與其它計算機的網路連接等等。然而，對於要對客戶機和網路可以完全訪問的特性豐富的客戶機來說， all-permissions 值是用於給予客戶機完全訪問的許可權的。為具有對本地機的完全訪問，Java 應用程序所使用和裝入的所有 JAR 文件和資源必須被數字簽名。安全性將在下面將進一步討論。
回頁首
JNLP 和 WAR 文件
為與應用程序相關的 JNLP 文件和 JAR 文件提供更加方便有效的打包方案，Java Web Start 使 Web 壓縮文件（WAR）的分發成為可能。WAR 文件是一個目錄結構，它包含了一個與 JNLP 文件和 JAR 文件一起打包的 servlet，從而使整個包能夠方便的在 Web 伺服器上部署。該 servlet 自身被打包在 jnlp-servlet.jar 文件里，包里還有 JnlpDownloadServlet 類作為主要的執行 Java 類，這個類將負責不同的任務，如：
生成 JARDiff 文件
根據 WAR 文件中的每個文件或每個目錄進行版本編號
支持 JNLP 文件中定義的下載協議
自動安裝 URL 到 JNLP 文件，從而免除對開發者要進行硬編碼 URL 的要求。
為了從 Java Web Start 啟動應用程序，把應用程序和 WAR 文件打包在一起並非必需。然而，WAR 文件的加入可以改善存儲在 Web 伺服器的文件的管理和升級。WAR 文件的主題對於本文的范圍來講實在是太冗長了。請參閱 參考資料來獲得與附加信息的聯系。
回頁首
Java Web Start 中的版本變化
到目前為止，我們已經討論了想要實施 Java Web Start 的開發者和用戶所需的整體的部署和管理技術。在我們深入前，我要概括一下到目前為止我所講到的部署的步驟。
應用程序所用的文件存儲在 JAR 文件。
必須創建一個 JNLP 來通知 Java Web Start 應用程序使用哪些 JAR 文件、如何下載必要的文件等。
一個標準的 Web 伺服器被配置來接受被 Java Web Start 理解的 MIME 類型。
JAR 文件放在了 Web 伺服器上。
用戶需要下載和安裝 Java Web Start（僅一次）。
用戶首次運行應用程序；JAR 文件被下載並執行。
用戶可以再次運行應用程序，從 Java Web Start 應用程序管理器或 Web 頁面啟動。Java Web Start 將下載需要更新的全部文件，並且然後將啟動應用程序。
從技術角度來說，這個總結可能會引發問題：Java Web Startf 是如何決定哪些文件是有必要更新的呢？答案很簡單：JNLP 文件。一個有版本標識的唯一的 URL與每個 JNLP 文件中定義的資源相關聯。如清單 3 所示。
清單 3.JNLP文件中的一個基於版本的 JAR 文件的示例
<jar href=http://www.companySite.com/javaApp/imageFiles.jar
version="1.1+">
當啟動了一個應用程序時，Java Web Start 檢查 JNLP 文件並創建一個有 URL 和版本標識的 HTTP GET 請求。如果沒有 version 屬性，那麼 Java Web Start 就只是創建一個 JAR 文件的 HTTP GET 請求。Java Web Start 檢查 Web 伺服器的響應狀態代碼和 MIME 類型來決定此 JAR 文件是否有更新的版本。
JNLP 文件還允許使用 JARDiff 實用程序來遞增的更新 JAR 文件。 JARDiff 實用程序能只下載 JAR 文件中的特定文件（不是整個 JAR 文件本身），這樣使下載更快。請參閱 參考資料來獲得關於決定 JNLP 文件配置的更多信息。
回頁首
安全性
也許在決定是否為了與 Java Web Start 兼容而開發應用程序時，需要考慮的最重要的問題就是安全性。Java Web Start 允許客戶端 Java 應用程序訪問各種本地機資源，如文件訪問、剪貼板訪問等。源自 Java 2 平台，該產品繼承了該平台的安全性體系結構。如前面提到的，在 JNLP 文件中定義的 security 屬性決定了當應用程序通過 Java Web Start 啟動時所能有的安全性級別。預設的，使用受限環境，為應用程序授權對網路和本地機的有限的訪問。如同使用 applet 沙箱（sandbox），這樣可以保證惡意的應用程序不能造成任何破壞。
Java Web Start 的安全性的另一重要元素是數字簽名的使用。當啟動或更新一個應用程序時，它的 JAR 文件被下載到客戶機。Java Web Start 用那些文件中的數字編碼來判定在對文件初始簽名之後，是否有 JAR 文件已經被修改或改變。如果有不一致的或是文件尚未被簽名，應用程序就不能從 Java Web Start 啟動。正確簽名的應用程序可以訪問本地機。
用戶授權安全性
當運行要對本地機無限制訪問的應用程序時，用戶最初將看到一個對話框，該對話框說明了應用程序的出處或供應商，並且允許用戶給應用程序授予額外的許可權。此外，當應用程序要求使用本地機的資源並且還沒有被簽名的 JAR 文件時，Java Web Start 將允許用戶通過一個 Security Advisory 對話框顯式的授予應用程序訪問許可權。例如，如果客戶機 Java 應用程序需要能把信息粘貼到 Windows 操作系統剪貼板工具，將出現一個與圖 9 相似的對話框。
圖 9. 應用程序試圖訪問剪貼板的 Security Advisory 對話框
當應用程序試圖訪問客戶機的本地資源（如文件系統）時，將出現另外的對話框窗口，如圖 10 所示。
圖 10. 應用程序試圖訪問文件系統時的 Security Advisory 對話框
用戶可以在以下方面授予應用程序對本地機的訪問許可權：
在本地機存儲應用程序的當前狀態
查看本地文件的內容
保存文件到本地機
本地機打開文件
在本地機對隨機存取文件讀/寫
從本地機列印
JNLP API 庫中的很多的類允許開發者在不可靠的環境使用系統的資源，由用戶來負責決定操作是否是允許的。