本文目录✅作者简介:热爱国学的Java后端开发者,修心和技术同步精进。
🍎个人主页:Java Fans的博客
🍊个人信条:不迁怒,不贰过。小知识,大智慧。
💞当前专栏:Java面试题总结
✨特色专栏:国学周更-心性养成之路
🥭本文内容:Java Web基础面试题
更多内容点击👇
Java序列化与注解面试题
MVC 是 Model-View-Controller 的简写。Model 代表的是应用的业务逻辑(通过
JavaBean,EJB 组件实现), View 是应用的表示面(由 JSP 页面产生),Controller 是提供应用的处理过程控制(一般是一个 Servlet),通过这种设计模型把应用逻辑,处理过程和显示逻辑分成不同的组件实现。这些组件可以进行交互和重用。
HTTP 协议有 HTTP/1.0 版本和 HTTP/1.1 版本:
1、HTTP1.1 默认保持长连接(HTTP persistent connection,也翻译为持久连接),数据传输完成了保持 TCP 连接不断开(不发 RST 包、不四次握手),等待在同域名下继续用这个通道传输数据;相反的就是短连接。
2、在 HTTP/1.0 中,默认使用的是短连接。也就是说,浏览器和服务器每进行一次 HTTP 操作,就建立一次连接,任务结束就中断连接。从 HTTP/1.1 起,默认使用的是长连接,用以保持连接特性。
Q03. HTTP/1.1 与HTTP/1.0 的区别1)可扩展性
a) HTTP/1.1 在消息中增加版本号,用于兼容性判断。
b) HTTP/1.1 增加了OPTIONS 方法,它允许客户端获取一个服务器支持的方法列表。
c) 为了与未来的协议规范兼容,HTTP/1.1 在请求消息中包含了Upgrade 头域,通过该头域,客户端可以让服务器知道它能够支持的其它备用通信协议,服务器可以据此进行协议切换,使用备用协议与客户端进行通信。
2)缓存
在 HTTP/1.0 中,使用 Expire 头域来判断资源的 fresh 或 stale,并使用条件请求(conditional request)来判断资源是否仍有效。HTTP/1.1 在 1.0 的基础上加入了一些 cache 的新特性,当缓存对象的 Age 超过 Expire 时变为stale 对象,cache 不需要直接抛弃stale 对象,而是与源服务器进行重新激活(revalidation)。
3)带宽优化
HTTP/1.0 中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了。例如,客户端只需要显示一个文档的部分内容,又比如下载大文件时需要支持断点续传功能,而不是在发生断连后不得不重新下载完整的包。
HTTP/1.1 中在请求消息中引入了 range 头域,它允许只请求资源的某个部分。在响应消息中 Content-Range 头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容,则响应码为 206(Partial Content),它可以防止 Cache 将响应误以为是完整的一个对象。
另外一种情况是请求消息中如果包含比较大的实体内容,但不确定服务器是否能够接收该请求(如是否有权限), 此时若贸然发出带实体的请求,如果被拒绝也会浪费带宽。
HTTP/1.1 加入了一个新的状态码 100(Continue)。客户端事先发送一个只带头域的请求,如果服务器因为权限拒绝了请求,就回送响应码 401(Unauthorized);如果服务器接收此请求就回送响应码 100,客户端就可以继续发送带实体的完整请求了。注意,HTTP/1.0 的客户端不支持 100 响应码。但可以让客户端在请求消息中加入 Expect 头域,并将它的值设置为 100-continue。
节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding 是对消息进行端到端(end-to-end)的编码,它可能是资源在服务器上保存的固有格式(如 jpeg 图片格式);在请求消息中加入 Accept-Encoding头域,它可以告诉服务器客户端能够解码的编码方式。
4)长连接
HTTP/1.0 规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个 TCP 连接,服务器完成请求处理后立即断开 TCP 连接,服务器不跟踪每个客户也不记录过去的请求。此外,由于大多数网页的流量都比较小,一次 TCP 连接很少能通过slow-start 区,不利于提高带宽利用率。
HTTP 1.1 支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟。例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输,但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
HTTP 1.1 还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间。
5)消息传递
HTTP 消息中可以包含任意长度的实体,通常它们使用 Content-Length 来给出消息结束标志。但是,对于很多动态产生的响应,只能通过缓冲完整的消息来判断消息的大小,但这样做会加大延迟。如果不使用长连接,还可以通过连接关闭的信号来判定一个消息的结束。
HTTP/1.1 中引入了 Chunkedtransfer-coding来解决上面这个问题,发送方将消息分割成若干个任意大小的数据块,每个数据块在发送时都会附上块的长度,最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段,避免缓冲整个消息带来的过载。
在 HTTP/1.0 中,有一个 Content-MD5 的头域,要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1 中,采用 chunked 分块传递的消息在最后一个块(零长度)结束之后会再传递一个拖尾(trailer),它包含一个或多个头域,这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个 Trailer 头域告诉接收方这个拖尾的存在。
6)Host 头域
在HTTP1.0 中认为每台服务器都绑定一个唯一的IP 地址,因此,请求消息中的URL 并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个 IP 地址。
HTTP1.1 的请求消息和响应消息都应支持 Host 头域,且请求消息中如果没有 Host 头域会报告一个错误(400 Bad Request)。此外,服务器应该接受以绝对路径标记的资源请求。
7)错误提示
HTTP/1.0 中只定义了 16 个状态响应码,对错误或警告的提示不够具体。HTTP/1.1 引入了一个 Warning 头域, 增加对错误或警告信息的描述。
此外,在 HTTP/1.1 中新增了 24 个状态响应码,如 409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。
200 OK //客户端请求成功
301 Moved Permanently(永久移除),请求的 URL 已移走。Response 中应该包含一个Location URL, 说明资源现在所处的位置
302 found 重定向
400 Bad Request //客户端请求有语法错误,不能被服务器所理解
401 Unauthorized //请求未经授权,这个状态代码必须和 WWW-Authenticate 报头域一起使用
403 Forbidden //服务器收到请求,但是拒绝提供服务
404 Not Found //请求资源不存在,eg:输入了错误的 URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
从表面现像上面看 GET 和POST 的区别:
1)GET 请求的数据会附在URL 之后(就是把数据放置在 HTTP 协议头中),以?分割URL 和传输数据,参数之间以&相连,如:login.action?name=zhagnsan&password=123456。POST 把提交的数据则放置在是 HTTP 包的包体中。
2)GET 方式提交的数据最多只能是 1024 字节,理论上POST 没有限制,可传较大量的数据。其实这样说是错误的,不准确的:“GET 方式提交的数据最多只能是 1024 字节",因为 GET 是通过 URL 提交数据,那么 GET 可提交的数据量就跟URL 的长度有直接关系了。而实际上,URL 不存在参数上限的问题,HTTP 协议规范没有对 URL 长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE 对URL 长度的限制是2083 字节(2K+35)。对于其他浏览器,如Netscape、FireFox 等,理论上没有长度限制,其限制取决于操作系统的支持。
3)POST 的安全性要比GET 的安全性高。注意:这里所说的安全性和上面 GET 提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改,而这里安全的含义是真正的 Security 的含义,比如:通过 GET 提交数据,用户名和密码将明文出现在 URL 上,因为(1)登录页面有可能被浏览器缓存,(2)其他人查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码了,除此之外,使用 GET 提交数据还可能会造成 Cross-site request forgery 攻击。
Get 是向服务器发索取数据的一种请求,而 Post 是向服务器提交数据的一种请求,在 FORM(表单)中,Method默认为"GET",实质上,GET 和 POST 只是发送机制不同,并不是一个取一个发!
Q06. http 中重定向和请求转发的区别?本质区别:转发是服务器行为,重定向是客户端行为。
重定向特点:两次请求,浏览器地址发生变化,可以访问自己 web 之外的资源,传输的数据会丢失。请求转发特点:一次强求,浏览器地址不变,访问的是自己本身的 web 资源,传输的数据不会丢失。
Q07. Cookie 和Session 的区别Cookie 是 web 服务器发送给浏览器的一块信息,浏览器会在本地一个文件中给每个 web 服务器存储 cookie。以后浏览器再给特定的 web 服务器发送请求时,同时会发送所有为该服务器存储的 cookie。
Session 是存储在 web 服务器端的一块信息。session 对象存储特定用户会话所需的属性及配置信息。当用户在应用程序的 Web 页之间跳转时,存储在 Session 对象中的变量将不会丢失,而是在整个用户会话中一直存在下去。
Cookie 和session 的不同点:
1)无论客户端做怎样的设置,session 都能够正常工作。当客户端禁用 cookie 时将无法使用 cookie。
2)在存储的数据量方面:session 能够存储任意的java 对象,cookie 只能存储 String 类型的对象。
单点登录的原理是后端生成一个 session ID,然后设置到 cookie,后面的所有请求浏览器都会带上 cookie, 然后服务端从 cookie 里获取 session ID,再查询到用户信息。所以,保持登录的关键不是 cookie,而是通过cookie 保存和传输的 session ID,其本质是能获取用户信息的数据。除了 cookie,还通常使用 HTTP 请求头来传输。但是这个请求头浏览器不会像 cookie 一样自动携带,需要手工处理。
Q09. 什么是jsp,什么是Servlet?jsp 和Servlet 有什么区别? jsp 本质上就是一个Servlet,它是 Servlet 的一种特殊形式(由 SUN 公司推出),每个 jsp 页面都是一个servlet实例。
Servlet 是由 Java 提供用于开发 web 服务器应用程序的一个组件,运行在服务端,由 servlet 容器管理,用来生成动态内容。一个 servlet 实例是实现了特殊接口 Servlet 的 Java 类,所有自定义的 servlet 均必须实现 Servlet 接口。
区别:
1、jsp 是 html 页面中内嵌的Java 代码,侧重页面显示;
2、Servlet 是 html 代码和 Java 代码分离,侧重逻辑控制,mvc 设计思想中jsp 位于视图层,servlet 位于控制层。
Jsp 运行机制:如下图:
JVM 只能识别 Java 类,并不能识别 jsp 代码!web 容器收到以.jsp 为扩展名的 url 请求时,会将访问请求交给tomcat 中 jsp 引擎处理,每个 jsp 页面第一次被访问时,jsp 引擎将 jsp 代码解释为一个 servlet 源程序,接着编译servlet 源程序生成.class 文件,再有 web 容器 servlet 引擎去装载执行servlet 程序,实现页面交互。
Q10. jsp有哪些域对象和内置对象及他们的作用?四大域对象:
1、pageContext page 域-指当前页面,在当前jsp 页面有效,跳到其它页面失效
2、request request 域-指一次请求范围内有效,从 http 请求到服务器处理结束,返回响应的整个过程。在这个过程中使用forward(请求转发)方式跳转多个 jsp,在这些页面里你都可以使用这个变量
3、session session 域-指当前会话有效范围,浏览器从打开到关闭过程中,转发、重定向均可以使用
4、application context 域-指只能在同一个web 中使用,服务器未关闭或者重启,数据就有九大内置对象:
生命周期 | 作用域 | 使用情况 | |
---|---|---|---|
Request | 一次请求 | 只在 Jsp 页面内有效 | 用于接受通过 HTTP 协议传送到服务器的数据(包括头信息、系统信息、请求方式以及请求参数等)。 |
Reponse | 一次响应 | 只在 Jsp 页面内有效 | 表示服务器端对客户端的回应。主要用于设置头信息、跳转、Cookie 等 |
Session | 从存入数据开始,默认闲置 30 分钟后失效 | 会话内有效 | 用于存储特定的用户会话所需的信息 |
Out | http://www.cnblogs.com/leirenyuan/p/6016063.html | 用于在 Web浏览器内输出信息,并且管理应用服务器上的输出缓冲区 | |
PageContext | 详细了解:http://www.cnblogs.com/leirenyuan/p/6016063.html | 用于存取其他隐含对象,如 request、reponse、session、application 等对象。(实际上,pageContext 对象提供了对 JSP 页面所有的对象及命名空间的访问。 | |
Page | http://www.cnblogs.com/leirenyuan/p/6016063.html | page 对象代表 JSP 本身(对应 this),只有在 JSP 页面内才是合法的 | |
Exception | http://www.cnblogs.com/leirenyuan/p/6016063.html | 显示异常信息,必须在 page 指令中设定< %@ page isErrorPage=“true” %>才能使用,在一般的 JSP 页面中使用该对象将无法编译 JSP 文件 | |
Application | 服务器启动发送第一个请求时就产生了Application 对象,直到服务器关闭。 | 用于存储和访问来自任何页面的变量所有的用户分享一个 Application 对象 | |
Config | http://www.cnblogs.com/leirenyuan/p/6016063.html | 取得服务器的配置信息 |
JavaScript 是一种在Web 开发中经常使用的前端动态脚本技术。在 JavaScript 中,有一个很重要的安全性限制, 被称为“Same-Origin Policy”(同源策略)。这一策略对于 JavaScript 代码能够访问的页面内容做了很重要的限制,即JavaScript 只能访问与包含它的文档在同一域下的内容。
JavaScript 这个安全策略在进行多 iframe 或多窗口编程、以及 Ajax 编程时显得尤为重要。根据这个策略, 在 baidu.com 下的页面中包含的 JavaScript 代码,不能访问在 google.com 域名下的页面内容;甚至不同的子域名之间的页面也不能通过 JavaScript 代码互相访问。对于 Ajax 的影响在于,通过XMLHttpRequest 实现的Ajax 请求,不能向不同的域提交请求,例如,在 abc.example.com 下的页面,不能向 def.example.com 提交Ajax 请求,等等。
然而,当进行一些比较深入的前端编程的时候,不可避免地需要进行跨域操作,这时候“同源策略”就显得过于苛刻。JSONP 跨域 GET 请求是一个常用的解决方案,下面我们来看一下 JSONP 跨域是如何实现的,并且探讨下 JSONP 跨域的原理。
jsonp 的最基本的原理是:动态添加一个