?作者簡介：熱愛國學(xué)的Java后端開發(fā)者，修心和技術(shù)同步精進(jìn)。
🍎個人主頁：Java Fans的博客
🍊個人信條：不遷怒，不貳過。小知識，大智慧。
💞當(dāng)前專欄：Java面試題總結(jié)
?特色專欄：國學(xué)周更-心性養(yǎng)成之路
🥭本文內(nèi)容：Java Web基礎(chǔ)面試題
更多內(nèi)容點(diǎn)擊👇
??????Java序列化與注解面試題

• • Q01. MVC 的各個部分都有那些技術(shù)來實(shí)現(xiàn)?如何實(shí)現(xiàn)?
  • Q02. http 的長連接和短連接
  • Q03. HTTP/1.1 與HTTP/1.0 的區(qū)別
  • Q04. http 常見的狀態(tài)碼有哪些？
  • Q05.GET 和POST 的區(qū)別？
  • Q06. http 中重定向和請求轉(zhuǎn)發(fā)的區(qū)別？
  • Q07. Cookie 和Session 的區(qū)別
  • Q08. 在單點(diǎn)登錄中，如果 cookie 被禁用了怎么辦？
  • Q09. 什么是jsp，什么是Servlet？jsp 和Servlet 有什么區(qū)別？
  • Q10. jsp有哪些域?qū)ο蠛蛢?nèi)置對象及他們的作用？
  • Q11. jsonp 原理
  • Q12. 談?wù)勀銓jax 的認(rèn)識？
  • Q13. Tomcat 的優(yōu)化經(jīng)驗(yàn)
  • Q14. HTTP 請求的 GET 與 POST 方式的區(qū)別
  • Q15. 解釋一下什么是 servlet;
  • Q16. 說一說 Servlet 的生命周期?
  • Q17. Servlet 的基本架構(gòu)
  • Q18. SERVLET API 中forward() 與redirect()的區(qū)別？
  • Q19. 什么情況下調(diào)用 doGet()和 doPost()？
  • Q20. Request 對象的主要方法：
  • Q21. forward 和 redirect 的區(qū)別
  • Q22. jsp 有哪些內(nèi)置對象?作用分別是什么? 分別有什么方法？
  • Q23. jsp有哪些動作?作用分別是什么?
  • Q24. JSP 的常用指令
  • Q25. JSP 中動態(tài) INCLUDE 與靜態(tài) INCLUDE 的區(qū)別？
  • Q26. 兩種跳轉(zhuǎn)方式分別是什么?有什么區(qū)別?
  • Q27. 頁面間對象傳遞的方法
  • Q28. JSP 和Servlet 有哪些相同點(diǎn)和不同點(diǎn)，他們之間的聯(lián)系是什么？
  • Q29. 我們在web 應(yīng)用開發(fā)過程中經(jīng)常遇到輸出某種編碼的字符，如iso8859-1 等，如何輸出一個某種編碼的字符串？

??MVC 是 Model－View－Controller 的簡寫。Model 代表的是應(yīng)用的業(yè)務(wù)邏輯（通過
JavaBean，EJB 組件實(shí)現(xiàn)）， View 是應(yīng)用的表示面（由 JSP 頁面產(chǎn)生），Controller 是提供應(yīng)用的處理過程控制（一般是一個 Servlet），通過這種設(shè)計(jì)模型把應(yīng)用邏輯，處理過程和顯示邏輯分成不同的組件實(shí)現(xiàn)。這些組件可以進(jìn)行交互和重用。

HTTP 協(xié)議有 HTTP/1.0 版本和 HTTP/1.1 版本：

??1、HTTP1.1 默認(rèn)保持長連接（HTTP persistent connection，也翻譯為持久連接），數(shù)據(jù)傳輸完成了保持 TCP 連接不斷開（不發(fā) RST 包、不四次握手），等待在同域名下繼續(xù)用這個通道傳輸數(shù)據(jù)；相反的就是短連接。

??2、在 HTTP/1.0 中，默認(rèn)使用的是短連接。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次 HTTP 操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。從 HTTP/1.1 起，默認(rèn)使用的是長連接，用以保持連接特性。

1)可擴(kuò)展性

??a) HTTP/1.1 在消息中增加版本號，用于兼容性判斷。
??b) HTTP/1.1 增加了OPTIONS 方法，它允許客戶端獲取一個服務(wù)器支持的方法列表。
??c) 為了與未來的協(xié)議規(guī)范兼容，HTTP/1.1 在請求消息中包含了Upgrade 頭域，通過該頭域，客戶端可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)議與客戶端進(jìn)行通信。

2)緩存

??在 HTTP/1.0 中，使用 Expire 頭域來判斷資源的 fresh 或 stale，并使用條件請求（conditional request）來判斷資源是否仍有效。HTTP/1.1 在 1.0 的基礎(chǔ)上加入了一些 cache 的新特性，當(dāng)緩存對象的 Age 超過 Expire 時變?yōu)閟tale 對象，cache 不需要直接拋棄stale 對象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。

3)帶寬優(yōu)化

??HTTP/1.0 中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務(wù)器卻將整個對象送過來了。例如，客戶端只需要顯示一個文檔的部分內(nèi)容，又比如下載大文件時需要支持?jǐn)帱c(diǎn)續(xù)傳功能，而不是在發(fā)生斷連后不得不重新下載完整的包。
??HTTP/1.1 中在請求消息中引入了 range 頭域，它允許只請求資源的某個部分。在響應(yīng)消息中 Content-Range 頭域聲明了返回的這部分對象的偏移值和長度。如果服務(wù)器相應(yīng)地返回了對象所請求范圍的內(nèi)容，則響應(yīng)碼為 206（Partial Content），它可以防止 Cache 將響應(yīng)誤以為是完整的一個對象。
??另外一種情況是請求消息中如果包含比較大的實(shí)體內(nèi)容，但不確定服務(wù)器是否能夠接收該請求（如是否有權(quán)限）， 此時若貿(mào)然發(fā)出帶實(shí)體的請求，如果被拒絕也會浪費(fèi)帶寬。
??HTTP/1.1 加入了一個新的狀態(tài)碼 100（Continue）?？蛻舳耸孪劝l(fā)送一個只帶頭域的請求，如果服務(wù)器因?yàn)闄?quán)限拒絕了請求，就回送響應(yīng)碼 401（Unauthorized）；如果服務(wù)器接收此請求就回送響應(yīng)碼 100，客戶端就可以繼續(xù)發(fā)送帶實(shí)體的完整請求了。注意，HTTP/1.0 的客戶端不支持 100 響應(yīng)碼。但可以讓客戶端在請求消息中加入 Expect 頭域，并將它的值設(shè)置為 100-continue。
??節(jié)省帶寬資源的一個非常有效的做法就是壓縮要傳送的數(shù)據(jù)。Content-Encoding 是對消息進(jìn)行端到端（end-to-end）的編碼，它可能是資源在服務(wù)器上保存的固有格式（如 jpeg 圖片格式）；在請求消息中加入 Accept-Encoding頭域，它可以告訴服務(wù)器客戶端能夠解碼的編碼方式。

4)長連接

??HTTP/1.0 規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請求都需要與服務(wù)器建立一個 TCP 連接，服務(wù)器完成請求處理后立即斷開 TCP 連接，服務(wù)器不跟蹤每個客戶也不記錄過去的請求。此外，由于大多數(shù)網(wǎng)頁的流量都比較小，一次 TCP 連接很少能通過slow-start 區(qū)，不利于提高帶寬利用率。
??HTTP 1.1 支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個 TCP 連接上可以傳送多個 HTTP 請求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲。例如：一個包含有許多圖像的網(wǎng)頁文件的多個請求和應(yīng)答可以在一個連接中傳輸，但每個單獨(dú)的網(wǎng)頁文件的請求和應(yīng)答仍然需要使用各自的連接。
??HTTP 1.1 還允許客戶端不用等待上一次請求結(jié)果返回，就可以發(fā)出下一次請求，但服務(wù)器端必須按照接收到客戶端請求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個下載過程所需要的時間。

5)消息傳遞

??HTTP 消息中可以包含任意長度的實(shí)體，通常它們使用 Content-Length 來給出消息結(jié)束標(biāo)志。但是，對于很多動態(tài)產(chǎn)生的響應(yīng)，只能通過緩沖完整的消息來判斷消息的大小，但這樣做會加大延遲。如果不使用長連接，還可以通過連接關(guān)閉的信號來判定一個消息的結(jié)束。
??HTTP/1.1 中引入了 Chunkedtransfer-coding來解決上面這個問題，發(fā)送方將消息分割成若干個任意大小的數(shù)據(jù)塊，每個數(shù)據(jù)塊在發(fā)送時都會附上塊的長度，最后用一個零長度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個片段，避免緩沖整個消息帶來的過載。
??在 HTTP/1.0 中，有一個 Content-MD5 的頭域，要計(jì)算這個頭域需要發(fā)送方緩沖完整個消息后才能進(jìn)行。而HTTP/1.1 中，采用 chunked 分塊傳遞的消息在最后一個塊（零長度）結(jié)束之后會再傳遞一個拖尾（trailer），它包含一個或多個頭域，這些頭域是發(fā)送方在傳遞完所有塊之后再計(jì)算出值的。發(fā)送方會在消息中包含一個 Trailer 頭域告訴接收方這個拖尾的存在。

6)Host 頭域

??在HTTP1.0 中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP 地址，因此，請求消息中的URL 并沒有傳遞主機(jī)名（hostname）。但隨著虛擬主機(jī)技術(shù)的發(fā)展，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個 IP 地址。
??HTTP1.1 的請求消息和響應(yīng)消息都應(yīng)支持 Host 頭域，且請求消息中如果沒有 Host 頭域會報(bào)告一個錯誤（400 Bad Request）。此外，服務(wù)器應(yīng)該接受以絕對路徑標(biāo)記的資源請求。

7)錯誤提示

??HTTP/1.0 中只定義了 16 個狀態(tài)響應(yīng)碼，對錯誤或警告的提示不夠具體。HTTP/1.1 引入了一個 Warning 頭域， 增加對錯誤或警告信息的描述。
??此外，在 HTTP/1.1 中新增了 24 個狀態(tài)響應(yīng)碼，如 409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。

200 OK //客戶端請求成功
301 Moved Permanently（永久移除)，請求的 URL 已移走。Response 中應(yīng)該包含一個Location URL, 說明資源現(xiàn)在所處的位置
302 found 重定向
400 Bad Request //客戶端請求有語法錯誤，不能被服務(wù)器所理解
401 Unauthorized //請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用
403 Forbidden //服務(wù)器收到請求，但是拒絕提供服務(wù)
404 Not Found //請求資源不存在，eg：輸入了錯誤的 URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請求，一段時間后可能恢復(fù)正常

從表面現(xiàn)像上面看 GET 和POST 的區(qū)別：

??1)GET 請求的數(shù)據(jù)會附在URL 之后（就是把數(shù)據(jù)放置在 HTTP 協(xié)議頭中），以?分割URL 和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如：login.action?name=zhagnsan&password=123456。POST 把提交的數(shù)據(jù)則放置在是 HTTP 包的包體中。

??2)GET 方式提交的數(shù)據(jù)最多只能是 1024 字節(jié)，理論上POST 沒有限制，可傳較大量的數(shù)據(jù)。其實(shí)這樣說是錯誤的，不準(zhǔn)確的：“GET 方式提交的數(shù)據(jù)最多只能是 1024 字節(jié)"，因?yàn)?GET 是通過 URL 提交數(shù)據(jù)，那么 GET 可提交的數(shù)據(jù)量就跟URL 的長度有直接關(guān)系了。而實(shí)際上，URL 不存在參數(shù)上限的問題，HTTP 協(xié)議規(guī)范沒有對 URL 長度進(jìn)行限制。這個限制是特定的瀏覽器及服務(wù)器對它的限制。IE 對URL 長度的限制是2083 字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox 等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持。

??3)POST 的安全性要比GET 的安全性高。注意：這里所說的安全性和上面 GET 提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的 Security 的含義，比如：通過 GET 提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在 URL 上，因?yàn)?1)登錄頁面有可能被瀏覽器緩存，(2)其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號和密碼了，除此之外，使用 GET 提交數(shù)據(jù)還可能會造成 Cross-site request forgery 攻擊。

??Get 是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請求，而 Post 是向服務(wù)器提交數(shù)據(jù)的一種請求，在 FORM（表單）中，Method默認(rèn)為"GET"，實(shí)質(zhì)上，GET 和 POST 只是發(fā)送機(jī)制不同，并不是一個取一個發(fā)！

??本質(zhì)區(qū)別：轉(zhuǎn)發(fā)是服務(wù)器行為，重定向是客戶端行為。

??重定向特點(diǎn)：兩次請求，瀏覽器地址發(fā)生變化，可以訪問自己 web 之外的資源，傳輸?shù)臄?shù)據(jù)會丟失。請求轉(zhuǎn)發(fā)特點(diǎn)：一次強(qiáng)求，瀏覽器地址不變，訪問的是自己本身的 web 資源，傳輸?shù)臄?shù)據(jù)不會丟失。

??Cookie 是 web 服務(wù)器發(fā)送給瀏覽器的一塊信息，瀏覽器會在本地一個文件中給每個 web 服務(wù)器存儲 cookie。以后瀏覽器再給特定的 web 服務(wù)器發(fā)送請求時，同時會發(fā)送所有為該服務(wù)器存儲的 cookie。

??Session 是存儲在 web 服務(wù)器端的一塊信息。session 對象存儲特定用戶會話所需的屬性及配置信息。當(dāng)用戶在應(yīng)用程序的 Web 頁之間跳轉(zhuǎn)時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下去。

Cookie 和session 的不同點(diǎn)：
??1)無論客戶端做怎樣的設(shè)置，session 都能夠正常工作。當(dāng)客戶端禁用 cookie 時將無法使用 cookie。
??2)在存儲的數(shù)據(jù)量方面：session 能夠存儲任意的java 對象，cookie 只能存儲 String 類型的對象。

??單點(diǎn)登錄的原理是后端生成一個 session ID，然后設(shè)置到 cookie，后面的所有請求瀏覽器都會帶上 cookie， 然后服務(wù)端從 cookie 里獲取 session ID，再查詢到用戶信息。所以，保持登錄的關(guān)鍵不是 cookie，而是通過cookie 保存和傳輸?shù)?session ID，其本質(zhì)是能獲取用戶信息的數(shù)據(jù)。除了 cookie，還通常使用 HTTP 請求頭來傳輸。但是這個請求頭瀏覽器不會像 cookie 一樣自動攜帶，需要手工處理。

??jsp 本質(zhì)上就是一個Servlet，它是 Servlet 的一種特殊形式（由 SUN 公司推出），每個 jsp 頁面都是一個servlet實(shí)例。
??Servlet 是由 Java 提供用于開發(fā) web 服務(wù)器應(yīng)用程序的一個組件，運(yùn)行在服務(wù)端，由 servlet 容器管理，用來生成動態(tài)內(nèi)容。一個 servlet 實(shí)例是實(shí)現(xiàn)了特殊接口 Servlet 的 Java 類，所有自定義的 servlet 均必須實(shí)現(xiàn) Servlet 接口。

區(qū)別：
??1、jsp 是 html 頁面中內(nèi)嵌的Java 代碼，側(cè)重頁面顯示；
??2、Servlet 是 html 代碼和 Java 代碼分離，側(cè)重邏輯控制，mvc 設(shè)計(jì)思想中jsp 位于視圖層，servlet 位于控制層。

Jsp 運(yùn)行機(jī)制：如下圖：

??JVM 只能識別 Java 類，并不能識別 jsp 代碼！web 容器收到以.jsp 為擴(kuò)展名的 url 請求時，會將訪問請求交給tomcat 中 jsp 引擎處理，每個 jsp 頁面第一次被訪問時，jsp 引擎將 jsp 代碼解釋為一個 servlet 源程序，接著編譯servlet 源程序生成.class 文件，再有 web 容器 servlet 引擎去裝載執(zhí)行servlet 程序，實(shí)現(xiàn)頁面交互。

四大域?qū)ο螅?br />??1、pageContext page 域-指當(dāng)前頁面，在當(dāng)前jsp 頁面有效，跳到其它頁面失效
??2、request request 域-指一次請求范圍內(nèi)有效，從 http 請求到服務(wù)器處理結(jié)束，返回響應(yīng)的整個過程。在這個過程中使用forward（請求轉(zhuǎn)發(fā)）方式跳轉(zhuǎn)多個 jsp，在這些頁面里你都可以使用這個變量
??3、session session 域-指當(dāng)前會話有效范圍，瀏覽器從打開到關(guān)閉過程中，轉(zhuǎn)發(fā)、重定向均可以使用
??4、application context 域-指只能在同一個web 中使用，服務(wù)器未關(guān)閉或者重啟，數(shù)據(jù)就有九大內(nèi)置對象：

??JavaScript 是一種在Web 開發(fā)中經(jīng)常使用的前端動態(tài)腳本技術(shù)。在 JavaScript 中，有一個很重要的安全性限制， 被稱為“Same-Origin Policy”（同源策略）。這一策略對于 JavaScript 代碼能夠訪問的頁面內(nèi)容做了很重要的限制，即JavaScript 只能訪問與包含它的文檔在同一域下的內(nèi)容。

??JavaScript 這個安全策略在進(jìn)行多 iframe 或多窗口編程、以及 Ajax 編程時顯得尤為重要。根據(jù)這個策略， 在 baidu.com 下的頁面中包含的 JavaScript 代碼，不能訪問在 google.com 域名下的頁面內(nèi)容；甚至不同的子域名之間的頁面也不能通過 JavaScript 代碼互相訪問。對于 Ajax 的影響在于，通過XMLHttpRequest 實(shí)現(xiàn)的Ajax 請求，不能向不同的域提交請求，例如，在 abc.example.com 下的頁面，不能向 def.example.com 提交Ajax 請求，等等。

??然而，當(dāng)進(jìn)行一些比較深入的前端編程的時候，不可避免地需要進(jìn)行跨域操作，這時候“同源策略”就顯得過于苛刻。JSONP 跨域 GET 請求是一個常用的解決方案，下面我們來看一下 JSONP 跨域是如何實(shí)現(xiàn)的，并且探討下 JSONP 跨域的原理。

??jsonp 的最基本的原理是：動態(tài)添加一個

<tfoot id="aosiw"></tfoot>