JavaEE入门之Servlet——Java服务器端小应用

什么是JavaEE

                                

        JavaEE（Java Enterprise Edition），Java企业版，是一个用于企业级web开发（不需要使用控制台）平台。最早由Sun公司定制并发布，后由Oracle负责维护。在JavaEE平台共包含了13个技术规范（随着JavaEE版本的变化所包含的技术点的数量会有增多）。它们分别是：JDBC、JNDI、EJB、RMI、Servlet、JSP、XML、JMS、Java IDL、JPA、JTA、JavaMail和JAF。

JavaEE案例特点

1. JavaEE案例要使用到浏览器、服务器（Tomcat）、数据库。

2. JavaEE案例程序不是通过main方法来运行，而是要放在服务器（Tomcat）来运行。

3. JavaEE案例要使用到Servlet和jsp两个技术，而且多了一个web.xml文件做配置。

4. JavaEE案例是将结果给打印到了浏览器上，而不是控制台上！

5. JavaEE案例可以让更多的人去访问它、使用它！

HTTP协议

        浏览器与服务器之间发送数据的时候，是要有格式的，是双方约定好的格式。这样双方才能认识对方发送的数据！这个格式我们称之为协议（在互联网中主机与主机之间进行访问沟通都需要使用特定的协议），这里我们访问的是Tomcat，想访问Tomcat，就必须知道http协议。

什么是HTTP协议

• HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写, HTTP是万维网（WWW:World Wide Web）的数据通信的基础。

（超文本是用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。超文本更是一种用户界面范式，用以显示文本及与文本之间相关的内容。 ）

• HTTP是一个简单的请求-响应协议，是基于TCP/IP通信协议来传递数据（HTML文件, 图片文件, 查询结果等）。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

网络分层模型回顾及两种连接协议

网络分层模型

层	作用	举例说明
物理层	负责光电信号的传输	以太网线、同轴电缆
数据链路层	负责设备之间数据帧的传送和识别	网卡设备驱动、帧同步、冲突检测、CRC
网络层	负责地址管理和路由选择	IP标识主机、路由表规划传输路线
传输层	负责两台主机之间的数据传输	传输控制协议（TCP）
应用层	负责应用程序间沟通	Http、SMTP、FTP、Telnet、网络编程主要针对应用层

TCP协议与UDP协议及区别

TCP协议	UDP协议
面向连接	非面向连接
点到点的通信	可以广播发送
高可靠性：三次握手、四次挥手	传输不可靠、可能丢失
占用系统资源多、效率低	非常简单的协议、开销小
生活案例：打电话	生活案例：发送短信

HTTP协议的特点

• 支持客户端/服务器模式

• 简单快速

• 灵活(传输的数据类型多样)

• 短连接

  短链接是指每次请求响应完成后，连接会自动断开。 从http1.1开始，我们使用的是长连接，长连接是每次请求响应完成后，连接会保持一小段的存活时间，供之后的请求使用。长连接要比短连接的效率高。

• 单向性

  服务端永远是被动的等待客户端（浏览器）的请求。

• 无状态

  无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大，用户体验度也不好。为了解决HTTP协议无状态，于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session。

HTTP协议中的URL、URI

URL

        URL(Uniform Resource Location统一资源定位符)，可以帮助我们唯一定位互联网上的某一个资源，相当于是互联网资源的身份证号。URL由五个元素组成：

• 传送协议

• 域名或者IP地址

• 端口号（以数字方式表示，若为HTTP的默认值“:80”可省略）

• 请求资源路径

• 传递数据（在URL中传递数据是以key=value的结构进行数据绑定，以“?”字符为起点，每个参数以“&”隔开通常以UTF8的URL编码，避开字符冲突的问题）

URI

        URI：（Uniform Resource Identifier统一资源标识符），是一个用于标识某一互联网资源名称的字符串。

URI是一个特别抽象的概念，URL包含了URI。

在Java中，当获取请求URI时，常是/demo1/HelloServlet。

HTTP协议的请求

        http协议就是用来规范请求与响应的数据格式的。

Request（请求） 消息分为3部分

• 第一部分叫Request line 请求行

  • 请求方式

  • uri

  • 协议及版本号

• 第二部分叫Request header 请求头

  • key：value

                Host 客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。

Connection 连接方式。如果值是close则表示基于短连接方式，如果该值是keep-alive，网络连接就是持久的，在一定时间范围内不会关闭，使得对同一个服务器的请求可继续在该连接上完成。

Upgrade-Insecure-Requests 服务端是否支持https加密协议。

Cache-Control 指定请求和响应遵循的缓存机制。

User-Agent 浏览器表明自己的身份（是哪种浏览器）。例如Chrome浏览器：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36。

Accept 告诉WEB服务器自己接受什么介质类型，/ 表示任何类型，type/* 表示该类型下的所有子类型。

Accept-Encoding 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）。

Accept-Language 浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等。

Accept-Charset 浏览器告诉服务器自己能接收的字符集。

Referer 浏览器向WEB 服务器表明自己是从哪个网页URL获得点击当前请求中的网址/URL。

Refresh 表示浏览器应该在多少时间之后刷新文档，以秒计时。

Cookie 可向服务端传递数据一种模型。

• 第三部分是Request body 请求体

  • 客户端传递给服务器的数据。比如：表单使用post方式提交的数据、上传文件数据等。

  • get请求没有请求体，将数据通过url直接传递

  • post有请求体，将数据通过请求体传递

        （Request header和Request body之间有个空行。）

请求方式

• GET 向指定的资源发出“显示”请求。 GET请求中会将请求中传递的数据包含在URL中并在浏览器的地址栏中显示。 GET请求传递数据时要求数据必须是ASCII字符。 GET请求可以被浏览器缓存。

• POST 向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。 数据被包含在请求体中。 POST请求传递数据时，数据可以是ASCII字符也可以是字节型数据，默认为字节型。 POST请求默认情况下不会被浏览器所缓存。

• HEAD 向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头度中的元信息。

• PUT 向指定资源位置上传其最新内容。

• DELETE 请求服务器删除Request-URI所标识的资源。

• TRACE 回显服务器收到的请求，主要用于测试或诊断。

• OPTIONS 这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用'*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。

• CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

GET请求方式和POST请求方式的区别

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

• GET请求只能进行url编码，而POST支持多种编码方式。

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

• GET请求在URL中传送的参数是有长度限制的，而POST则没有。对参数的数据类型GET只接受ASCII字符，

• POST既可是字符也可是字节。

• GET相比POST来说不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

• GET参数通过URL传递，POST放在Request body中。

HTTP的响应

Response消息也由三部分组成

• 第一部分叫Response line

        相应行。和请求消息相比，响应消息多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果。

常见状态码及含义

• 200 - 请求成功，已经正常处理完毕

• 301 - 请求永久重定向，转移到其它URL

• 302 - 请求临时重定向

• 304 - 请求被重定向到客户端本地缓存

• 400 - 客户端请求存在语法错误（客户端传递的数据类型不是后端想要的类型）

• 401 - 客户端请求没有经过授权

• 403 - 客户端的请求被服务器拒绝，一般为客户端没有访问权限

• 404 - 资源未找到，客户端请求的URL在服务端不存在

• 405 – 请求方式不支持

• 500 - 服务端出现异常

• 第二部分叫Response header

        响应头用于告知浏览器当前响应中的详细信息，浏览器通过获取响应头中的信息可以知道应该如何处理响应结果。响应头中信息的格式为key:value。

• 第三部分叫Response body

        响应体就是响应的消息体，如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码，如果是JS就是JS代码，如此之类。

服务器

分类

JavaEE应用服务器

        应用服务器是Java EE规范的具体实现, 可以执行/驱动基于JavaEE平台开发的web项目。绝大部分的应用服务器都是付费产品。 ​常见的应用服务器：

• Weblogic（BEA Oracle 收费）
• Webshpere（IBM 收费）
• JBoss（RedHad 收费）
• Resin（Caucho 收费）
• JRun（Macromedia 收费）
• Geronimo（Apache 免费）

Web容器

        只实现了JavaEE平台下部分技术标准，如Servlet，Jsp，JNDI，JavaMail。Web容器是开源免费的。

• Tomcat（Apache 开源免费）

• Jetty（Jetty 开源免费）

Tomcat容器

目录结构介绍

• bin：用来存放Tomcat服务器的可执行程序，主要有两大类，一类是以.sh结尾的（linux命令），另一类是以.bat结尾的（windows命令）。

• conf：用来存放Tomcat服务器的配置文件

• lib：用来存放Tomcat服务器的jar包

• logs：用来存放Tomcat服务器运行时输出的日志信息

• temp：用来存放Tomcat服务器运行时产生的临时数据

• webapps：用来存放Tomcat服务器部署的工程

• work：是Tomcat工作时的目录，用来存放Tomcat运行时jsp翻译为Servlet的源码和编译后的文件

启动、关闭及访问方式

Tomcat启动

• 方式一

  运行startup.bat文件。

• 方式二

  catlina.bat start

  其中catlina.bat是命令文件，start是启动Tomcat参数。

Tomcat关闭

• 方式一

  运行shutdown.bat文件。

• 方式二

  catlina.bat stop

  其中catlina.bat是命令文件，stop是关闭Tomcat参数。

• 方式三

  直接关闭掉控制台窗口。

访问Tomcat

• 访问Tomcat的URL格式：http://ip:port

• 访问本机Tomcat的URL格式：http://localhost:8080

Tomcat常见配置

配置文件介绍

Tomcat 的配置文件由4个xml组成，分别是 context.xml、web.xml、server.xml、tomcat-users.xml。每个文件都有自己的功能与配置方法。

context.xml context.xml 是 Tomcat 公用的环境配置。 Tomcat 服务器会定时去扫描这个文件。一旦发现文件被修改（时间戳改变了），就会自动重新加载这个文件，而不需要重启服务器 。

web.xml Web应用程序描述文件，都是关于是Web应用程序的配置文件。所有Web应用的 web.xml 文件的父文件。

server.xml 是 tomcat 服务器的核心配置文件，server.xml的每一个元素都对应了 tomcat中的一个组件(pojo对象)，通过对xml中元素的配置，实现对 tomcat中的各个组件和端口的配置。

tomcat-users.xml 配置访问Tomcat的用户以及角色的配置文件。

常见配置

解决控制台乱码

        控制台产生乱码的原因是在Tomcat在输出日志中使用的是UTF-8编码，而我们中文的Windows操作系统使用的是GBK编码。由于编码格式不统一，所以出现了乱码。

解决方式：修改conf目录中的logging.properties文件重新指定的编码方式。如果还是不行,那么 就删除该行即可

java.util.logging.ConsoleHandler.encoding = GBK

修改Tomcat监听的端口号

        Tomcat默认监听端口为8080。可通过修改server.xml文件来改变Tomcat监听端口。

<Connector port="8080" protocol="HTTP/1.1" 
connectionTimeout="20000" redirectPort="8443" />

配置Tomcat并发数

        Tomcat的最大并发数是可以配置的，实际运用中，最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件，更多的处理器都会使Tomcat支持更多的并发。 这个并发能力还与应用的逻辑密切相关，如果逻辑很复杂需要大量的计算，那并发能力势必会下降。

• 最大并发数: maxThreads="1000"

• 初始化时创建的线程数: minSpareThreads="100"

• 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程:maxSpareThreads="500"

• 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理: acceptCount="700"

<Connector port="8080" protocol="HTTP/1.1" 
 minSpareThreads="100"  maxSpareThreads="500" 
maxThreads="1000" acceptCount="700" 
connectionTimeout="20000" redirectPort="8443" />

配置虚拟主机（Host）

        虚拟主机（英语：virtual hosting），又称虚拟服务器, Host组件位于Engine(执行引擎)中用于接收请求并进行相应处理的虚拟主机。

<Host name="localhost"  appBase="webapps"
 unpackWARs="true" autoDeploy="true">

name：虚拟主机的名称，Tomcat通过在请求URL中的域名与name中的值匹配，用于查找能够处理该请求的虚拟主机。如果未找到则交给在Engine中defaultHost指定的主机处理；

appBase：此Host的webapps目录，即指定存放web应用程序的目录的路径；

autoDeploy：在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy(部署)；默认为true；

unpackWARs：在启用此webapps时是否对WAR格式的归档文件先进行展开；默认为true；

添加Context

• Context是Host的子组件，代表指定一个Web应用，它运行在某个指定的虚拟主机（Host）上；每个Web应用都是一个WAR文件，或文件的目录。

<Host name="www.bjsxt.com"  appBase="d:/bjsxt"
      unpackWARs="true" autoDeploy="true">
    <!-- 配置了Context, 可以自动到D:\bjsxt\test中寻找访问的资源 -->
    <Context path="/" docBase="D:\bjsxt\test" />
</Host>

Servlet概述

        我们知道浏览器发送请求给服务器，服务器接收到请求后进行解析，然后找对应的代码处理该请求。 这里的代码是我们提前写好放在Tomcat服务器中的， 它支持Servlet规范。

• Servlet是Server Applet的简称，称为服务端小程序，是JavaEE平台下的技术标准，基于Java语言编写的服务端程序。 Web 容器或应用服务器实现了Servlet标准所以Servlet需要运行在Web容器或应用服务器中。Servlet主要功能在于能够在服务器中执行并生成数据。

• Servlet指的是一个接口规范，具体的体现为接口及其接口的实现类。该接口的名字就是Servlet

• Servlet是JavaWeb开发的三大组件之一（另外两个是过滤器filter与监听器listener）

部署后的Servlet Web工程目录结构

Tomcat运行过程

1. 用户访问localhost:8080/test/helloword，请求被发送到Tomcat，被监听8080端口并处理 HTTP/1.1 协议的Connector获得。

2. Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。

3. Engine获得请求localhost/test/helloword，匹配所有的虚拟主机Host。

4. Engine匹配到名为localhost的Host虚拟主机来处理/test/helloword请求（即使匹配不到会请求交给默认Host处理）。

5. 匹配到的Context获得请求/helloword。

6. 构造HttpServletRequest对象和HttpServletResponse对象.执行业务逻辑、数据存储等程序。

7. Context把执行完之后的结果通过HttpServletResponse对象返回给Host。

8. Host把HttpServletResponse返回给Engine。

9. Engine把HttpServletResponse对象返回Connector。

10. Connector把HttpServletResponse对象返回给客户Browser。