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

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

??MVC 是 Model－View－Controller 的簡寫。Model 代表的是應(yīng)用的業(yè)務(wù)邏輯（通過
JavaBean，EJB 組件實(shí)現(xiàn)）， View 是應(yīng)用的表示面（由 JSP 頁面產(chǎn)生），Controller 是提供應(yīng)用的處理過程控制（一般是一個(gè) 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ù)用這個(gè)通道傳輸數(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 在消息中增加版本號(hào)，用于兼容性判斷。
??b) HTTP/1.1 增加了OPTIONS 方法，它允許客戶端獲取一個(gè)服務(wù)器支持的方法列表。
??c) 為了與未來的協(xié)議規(guī)范兼容，HTTP/1.1 在請(qǐng)求消息中包含了Upgrade 頭域，通過該頭域，客戶端可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)議與客戶端進(jìn)行通信。

2)緩存

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

3)帶寬優(yōu)化

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

4)長連接

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

5)消息傳遞

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

6)Host 頭域

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

7)錯(cuò)誤提示

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

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

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

??1)GET 請(qǐng)求的數(shù)據(jù)會(huì)附在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í)這樣說是錯(cuò)誤的，不準(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ī)范沒有對(duì) URL 長度進(jìn)行限制。這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制。IE 對(duì)URL 長度的限制是2083 字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox 等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持。

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

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

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

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

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

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

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

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

??jsp 本質(zhì)上就是一個(gè)Servlet，它是 Servlet 的一種特殊形式（由 SUN 公司推出），每個(gè) jsp 頁面都是一個(gè)servlet實(shí)例。
??Servlet 是由 Java 提供用于開發(fā) web 服務(wù)器應(yīng)用程序的一個(gè)組件，運(yùn)行在服務(wù)端，由 servlet 容器管理，用來生成動(dòng)態(tài)內(nèi)容。一個(gè) 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 只能識(shí)別 Java 類，并不能識(shí)別 jsp 代碼！web 容器收到以.jsp 為擴(kuò)展名的 url 請(qǐng)求時(shí)，會(huì)將訪問請(qǐng)求交給tomcat 中 jsp 引擎處理，每個(gè) jsp 頁面第一次被訪問時(shí)，jsp 引擎將 jsp 代碼解釋為一個(gè) servlet 源程序，接著編譯servlet 源程序生成.class 文件，再有 web 容器 servlet 引擎去裝載執(zhí)行servlet 程序，實(shí)現(xiàn)頁面交互。

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

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

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

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

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