java ee服务器/应用服务器的理解

42.由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持,最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现。
43.可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应HTML(标准通用标记语言下的一个应用)页面的访问请求。
43,。可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应HTML(标准通用标记语言下的一个应用)页面的访问请求。

44.诀窍是,当配置正确时,Apache 为HTML页面服务,而Tomcat 实际上运行JSP 页面和Servlet。另外,Tomcat和IIS等Web服务器一样,具有处理HTML页面的功能,另外它还是一个Servlet和JSP容器,独立的Servlet容器是Tomcat的默认模式。不过,Tomcat处理静态HTML的能力不如Apache服务器。

45.不过,Tomcat处理静态HTML的能力不如Apache服务器。
45.不过,Tomcat处理静态HTML的能力不如Apache服务器。
46.Tomcat中的应用程序是一个WAR(Web Archive)文件。WAR是Sun提出的一种Web应用程序格式,与JAR类似,也是许多文件的一个压缩包。这个包中的文件按一定目录结构来组织:通常其根目录下包含有Html和Jsp文件或者包含这两种文件的目录,另外还会有一个WEB-INF目录,这个目录很重要。通常在WEB-INF目录下有一个web.xml文件和一个classes目录,web.xml是这个应用的配置文件,而classes目录下则包含编译好的Servlet类和Jsp或Servlet所依赖的其它类(如JavaBean)。通常这些所依赖的类也可以打包成JAR放到WEB-INF下的lib目录下,当然也可以放到系统的CLASSPATH中,但那样移植和管理起来不方便在Tomcat中,应用程序的部署很简单,你只需将你的WAR放到Tomcat的webapp目录下,Tomcat会自动检测到这个文件,并将其解压。你在浏览器中访问这个应用的Jsp时,通常第一次会很慢,因为Tomcat要将Jsp转化为Servlet文件,然后编译。编译以后,访问将会很快。

47.Tomcat中的应用程序是一个WAR(Web Archive)文件。
48.Tomcat中的应用程序是一个WAR(Web Archive)文件。
49.Tomcat中的应用程序是一个WAR(Web Archive)文件。
50.基于Tomcat的开发其实主要是Jsp和Servlet的开发,开发Jsp和Servlet非常简单,你可以用普通的文本编辑器或者IDE,然后将其打包成WAR即可。
51.基于Tomcat的开发其实主要是Jsp和Servlet的开发,开发Jsp和Servlet非常简单,你可以用普通的文本编辑器或者IDE,然后将其打包成WAR即可。
52.Ant:你需要写一个build.xml文件,然后运行Ant就可以完成xml文件中定义的工作。ant可以完成xml中定义的工作。
53.ant可以完成xml中定义的工作。
54.ant可以完成xml中定义的工作。

1.tomcat里的session就是一个本地内存中的hashmap。是保存在本地机器内存里的。
所以单点登录时,维护保持用户登录信息,可以采用专门缓存服务器存储token或者采用各个不同的服务器session同步的机制。
2.但session同步效率太低,不建议使用。
3.单点登录是一个热门话题,是指在多系统应用群中登录一个系统,便可在其他所有系统中得到授权而无需再次登录,包括单点登录与单点注销两部分。
4.传统的session是将用户信息存入内存,维护一个哈希表。每一次请求携带JSESSIONID到服务端,根据此JSESSIONID查找到对应的用户信息。
由此出发我们想到可以利用Redis等内存数据库进行用户信息的存储,自定义Token生成规则将用户信息写入Redis中。这样将用户信息的存储和业务系统进行拆分,使系统更加健
壮,更易于扩展。新加的系统只需要从SSO中获取相关的认证即可进行横向的业务扩展。而且Redis本身的性质也易于进行集群化的部署。
5.JDK jar包无外乎包括三种包,一根 是读取本地文件的,java.io包,一个是网络jar包,java.net,一个是数据库jar包,java.sql。

1. 我从c语言的角度描述下这个问题吧。

首先,http是建立在tcp上的,系统在每个tcp连接建立的时候(也就是每个线程发起一个请求),会产生不同的描述符(句柄),这样针对不同描述符进行recv/send操作就不会错乱。
httpresponse应该归根结底,是对tcp连接的封装,看这个名字好像是一个类,那就用实例来对应描述符,只要看看这个http response是来源于哪个request对象,或者有其它的封装,在每建立一个连接的时候都会生成一个实例,那么只要探测这http response是哪个实例的,就能知道是什么request的响应了。

30.据说服务有两种:

收到一个请求就处理,这个时候就不能处理新的请求,这种为阻塞
收到一个请求就新开一个线程去处理任务,主线程返回,继续处理下一个任务,这种为非阻塞。
首先,服务器的实现不止有这两种方式。

先谈谈题主说的这两种服务器模型:

1、收到一个请求就处理,这个时候就不能处理新的请求,这种为阻塞
这个是单线程模型,无法并发,一个请求没处理完服务器就会阻塞,不会处理下一个请求。一般的服务器不会使用这种方式实现。

2、收到一个请求就新开一个线程去处理任务,主线程返回,继续处理下一个任务,这种为非阻塞
首先纠正一个错误,这并不是非阻塞,它也是阻塞的。相对第一个模型来说,它解决了主线程阻塞的问题,有了一定程度的并发量,但是在每个新开的线程中还是阻塞的。如果100个人同时访问,将会开100个线程,那1000个人,10000个人呢?频繁开关线程很消耗资源,这样实现的服务器性能依然不高。

除了上面的两种方式,接下来的说说其他更好的方式:

3、类似2的模型,但是不是每次收到请求就开一个新的线程,而是使用线程池
如果不了解线程池,你可能会了解数据库连接池,由于频繁创建、关闭数据库连接会消耗资源,所以会用数据库连接池来保存一定数量的连接,如果需要就从连接池里取连接,不需要则放回连接池,不在频繁创建。线程池也是一样的道理,线程池管理多线程,性能比频繁创建线程高得多。这种方式实现的服务器性能会比2高。不过,它依然是阻塞的。线程池的线程数量通常有限制的,如果所有线程都被阻塞(例如网速慢,或者被人恶意占用连接),那么接下来的请求将会排队等待。

4、基于Java NIO实现的服务器模型
上面说到的几种模型,都是基于BIO(阻塞IO)。而NIO则是非阻塞IO,它是基于IO多路复用技术(例如Reactor模式)实现,只需要一个线程或者少量线程,就可以处理大量请求。从性能上来说NIO实现的服务器并发性一般大于BIO,所以可以实现高性能的服务器。如果感兴趣,可以学习一些基于NIO的网络编程框架,例如Netty、MINA。

最后,回答一下题主说到的Tomcat。Tomcat运行可以选择BIO或者NIO模型,原理分别对应上面的3和4两种方式。Tomcat默认是BIO方式运行,如果想要换成NIO,可以配置server.xml:

<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" .../>

从性能上考虑建议使用NIO。

原文地址:https://www.cnblogs.com/panxuejun/p/6480612.html