关于JavaScript脚本中的alert的问题我在[关于JavaScript脚本中的alert思考 ]中曾经提过，也得到了大伙的回答。其实从某种观点上看这是个不值得一提的问题。但是我又把这个问题重新提出，我提出的目的不在于得到这个问题的结果：JavaScript脚本中的alert是一定会给服务器造成压力，还是不会造成压力。
我希望通过对问题的分析来让更多的人明白该如何去猜想，分析，解决，问题。从实际的数据中得到结果。有部分朋友在[关于JavaScript脚本中的alert思考 ]给出了回答，但是这些回答多少欠缺一点东西，比如说部分人回答说提出这个问题时对Http些细不了解。但是对于这种答案并没有解释问题的关键：为什么不会给浏览器造成压力。在此我重新对这个问题进行分析，我希望给大家提供一个分析问题的办法。
对于[JavaScript脚本中的alert的问题]我通过推想的办法来进行分析，首先我假设在alert会给造成压力，那么我就该对alert在不同的场合结合会造成压力的理由进行结果推测，比如说有说法由于alert可能使服务器和IE的通信一直被保持，直到alert被关闭。那么对于这种理由的推测想象就是监视服务器端的连接，其连接会一直保持着。如果结果不是如此，则说明原先的假设不成立。
[JavaScript脚本中的alert的问题]的几个有争议的地方有：
1：html是否在完全被传送到客户段之后才显示？
2:JavaScript是否在html完全显示后执行？
3：如果JavaScript在html没有被完全显示就可以执行，那么此时的alert会不会是浏览器本身与服务器端的通信处于等待状态？（ [JavaScript脚本中的alert的问题]alert状态下，浏览器会处于等待状态是指浏览器自身当前的线程处于等待状体）
首先我们先假设html是在完全被传送到客户段之后才显示。那么我们在打开网页的时候也就会有这种现象出现：如果打开很大的网页（指数据比较多，图片很大）时候，刚刚打开的时候会是一片空白，过了一段时间之后画面会突然出现。空白的时候是浏览器在与服务器请求数据，由于数据很大，请求的时间就会相应长。那么在这段时间内由于html数据没有传送完成，浏览器不会显示html的信息，所以会一片空白。
对此我做了一个测试试样：
private void Page_Load(object sender, System.EventArgs e)
{
for(int i=0;i<50;i++)
{
this.Page.Response.Write("<table> <tr><td>"); using (FileStream fs = File.OpenRead(@"D:\Inetpub\wwwroot\Test\123.bmp")) { byte[] b = new byte[1024]; while (fs.Read(b,0,b.Length) > 0) { this.Page.Response.Write(b);
} } this.Page.Response.Write("</table> </tr></td>"); }
}我通过直接将一大文件往网页内写。文件是一张比较大的图片：有2M多，通过50次的循环读写，那么发送到客户段的数据超过100M，这样浏览器的处理起来的时候就会比较慢。从测试的结果是浏览器逐步的显示出接收到的内容。与期望的一次性显示并不相同。
对于这个显现的原因是：浏览器在接收到的数据中，每当接受到一个完整的Table内容后就会显示，并不是将所有的数据都接收完成后一次性的显示出来。这种显现可能大伙在访问图片比较多的网站的时候可能会常常遇到，打开一个网页等了半天还是只显示了一部分。
这就说明了1：html是不是在完全被传送到客户段之后显示。
对于第二个问题我假设JavaScript脚本是在Html显示完全后才能被执行，对于设计的测试方法我只是简单的在循环操作开始前添加如下面依据话：
this.Page.Response.Write("<SCRIPT >alert(\"ee\");</SCRIPT>");
假如JavaScript脚本是在Html显示完全后才能被执行，那么在所有的信息显示完全之前不会弹出alert对话框。但是测试的结果是在页面内容显示之前就执行了脚本。
接下来网页会继续往下显示。
对于这个现象的原应是：浏览器在接受到部分相对完整的数据（比如说一个Table）就显示。在显示过程中如果遇到脚本就会执行。
这就说明了2：JavaScript脚本在是在Html显示过程中可以被执行。
由于有了1和2的不成立，才可以推断3。如果1和2都成立的话，那么由于脚本是在Html被发送完成之后再执行，那么此时浏览器已经与服务器断开的通信（由于HTTP协议的特点，在服务器将浏览器请求的数据发送完成之后，即断开与客户机的连接操作)那么此时执行alert即时使浏览器当前线程处于等待状态，也不会对服务器造成任何影响）
由于1和2的测试结果使3的答案无法定论。所以假设会给服务器造成压力，而造成压力的理由是：由于alert使浏览器处于等待状态，这个时候可能与服务器的通信还没有终止，所以会使客户端与服务器长时间连接在一起，从而造成压力。如果上叙理由成立，那么此时监视服务器就会发现IIS当前会一直处于激活状态。
通过软件测试，首先把IIS中的站点属性设置中将[启用HTTP激活]去掉。然后通过软件简单的监视IIS的连接数。
测试的结果是在alert没有被关闭之前，IIS并没有保持激活状态，这也就说明IIS并没有与客户端一直保持通信协议。
对于这个现象的原应是：由于通信协议的特点决定的，由于网络通信协议中是自底向上服务的特点，HTTP协议也是通过网络中的TCP/IP协议进行通信。由于通信协议的服务特点，所以即使是浏览器处于正待状态，这并不影响底层的TCP通信。因为TCP自下向上服务，对于上层调用不去过多的理会下层的操作状态。
好了这个问题也就解释清楚了，希望能够对大伙有所帮助。
