㈠ 如何正确防御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 库中的很多的类允许开发者在不可靠的环境使用系统的资源，由用户来负责决定操作是否是允许的。