1.請(qǐng)介紹一下，XML文檔定義的幾種形式，它們之間有何本質(zhì)區(qū)別？再說(shuō)說(shuō)，解析XML文檔又有哪幾種方式？
參考回答：
a: 兩種形式 dtd schema
b: 本質(zhì)區(qū)別:schema本身是xml的，可以被XML解析器解析(這也是從DTD上發(fā)展schema的根本目的)
c:有DOM,SAX,STAX等
DOM:處理大型文件時(shí)其性能下降的非常厲害。這個(gè)問(wèn)題是由DOM的樹(shù)結(jié)構(gòu)所造成的，這種結(jié)構(gòu)占用的內(nèi)存較多，而且DOM必須在解析文件之前把整個(gè)文檔裝入內(nèi)存,適合對(duì)XML的隨機(jī)訪問(wèn)
SAX:不現(xiàn)于DOM,SAX是事件驅(qū)動(dòng)型的XML解析方式。它順序讀取XML文件，不需要一次全部裝載整個(gè)文件。當(dāng)遇到像文件開(kāi)頭，文檔結(jié)束，或者標(biāo)簽開(kāi)頭與標(biāo)簽結(jié)束時(shí)，它會(huì)觸發(fā)一個(gè)事件，用戶通過(guò)在其回調(diào)事件中寫(xiě)入處理代碼來(lái)處理XML文件，適合對(duì)XML的順序訪問(wèn)
STAX:Streaming API for XML (StAX)
xml文檔有兩種定義方法：
dtd：數(shù)據(jù)類型定義（data type definition），用以描述XML文檔的文檔結(jié)構(gòu)，是早期的XML文檔定義形式。
schema：其本身是基于XML語(yǔ)言編寫(xiě)的，在類型和語(yǔ)法上的限定能力比dtd強(qiáng)，處理也比較方便，因?yàn)榇苏饾u代替dtd成為新的模式定義語(yǔ)言。
2.談一談，Java規(guī)范中和 與Web Service相關(guān)的 規(guī)范有哪些？
參考回答：
Java規(guī)范中和Web Service相關(guān)的有三個(gè)：
- JAX-WS(JSR 224)：這個(gè)規(guī)范是早期的基于SOAP的Web Service規(guī)范JAX-RPC的替代版本，它并不提供向下兼容性，因?yàn)镽PC樣式的WSDL以及相關(guān)的API已經(jīng)在Java EE5中被移除了。WS-MetaData是JAX-WS的依賴規(guī)范，提供了基于注解配置Web Service和SOAP消息的相關(guān)API。
- JAXM(JSR 67)：定義了發(fā)送和接收消息所需的API,相當(dāng)于Web Service的服務(wù)器端。
- JAX-RS(JSR 311 & JSR 339 & JSR 370)：是Java針對(duì)REST（Representation State Transfer）架構(gòu)風(fēng)格制定的一套Web Service規(guī)范。REST是一種軟件架構(gòu)模式，是一種風(fēng)格，它不像SOAP那樣本身承載著一種消息協(xié)議， (兩種風(fēng)格的Web Service均采用了HTTP做傳輸協(xié)議，因?yàn)镠TTP協(xié)議能穿越防火墻，Java的遠(yuǎn)程方法調(diào)用（RMI）等是重量級(jí)協(xié)議，通常不能穿越防火墻），因此可以將REST視為基于HTTP協(xié)議的軟件架構(gòu)。REST中最重要的兩個(gè)概念是資源定位和資源操作，而HTTP協(xié)議恰好完整的提供了這兩個(gè)點(diǎn)。HTTP協(xié)議中的URI可以完成資源定位，而GET、POST、OPTION、DELETE方法可以完成資源操作。因此REST完全依賴HTTP協(xié)議就可以完成Web Service，而不像SOAP協(xié)議那樣只利用了HTTP的傳輸特性，定位和操作都是由SOAP協(xié)議自身完成的，也正是由于SOAP消息的存在使得基于SOAP的Web Service顯得笨重而逐漸被淘汰。
3. 請(qǐng)你談?wù)剬?duì)SOAP、WSDL、UDDI的了解。
參考回答：
- SOAP：簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議（Simple Object Access Protocol），是Web Service中交換數(shù)據(jù)的一種協(xié)議規(guī)范。
- WSDL：Web服務(wù)描述語(yǔ)言（Web Service Description Language），它描述了Web服務(wù)的公共接口。這是一個(gè)基于XML的關(guān)于如何與Web服務(wù)通訊和使用的服務(wù)描述；也就是描述與目錄中列出的Web服務(wù)進(jìn)行交互時(shí)需要綁定的協(xié)議和信息格式。通常采用抽象語(yǔ)言描述該服務(wù)支持的操作和信息，使用的時(shí)候再將實(shí)際的網(wǎng)絡(luò)協(xié)議和信息格式綁定給該服務(wù)。
- UDDI：統(tǒng)一描述、發(fā)現(xiàn)和集成（Universal Description, Discovery and Integration），它是一個(gè)基于XML的跨平臺(tái)的描述規(guī)范，可以使世界范圍內(nèi)的企業(yè)在互聯(lián)網(wǎng)上發(fā)布自己所提供的服務(wù)。簡(jiǎn)單的說(shuō)，UDDI是訪問(wèn)各種WSDL的一個(gè)門(mén)面（可以參考設(shè)計(jì)模式中的門(mén)面模式）。
4.WEB SERVICE名詞解釋，JSWDL開(kāi)發(fā)包的介紹，JAXP、JAXM的解釋。SOAP、UDDI,WSDL解釋。
參考回答：
Web ServiceWeb Service是基于網(wǎng)絡(luò)的、分布式的模塊化組件，它執(zhí)行特定的任務(wù)，遵守具體的技術(shù)規(guī)范，這些規(guī)范使得WebService能與其他兼容的組件進(jìn)行互操作。
JAXP(Java API for XML Parsing) 定義了在Java中使用DOM, SAX, XSLT的通用的接口。這樣在你的程序中你只要使用這些通用的接口，當(dāng)你需要改變具體的實(shí)現(xiàn)時(shí)候也不需要修改代碼。
JAXM(Java API for XML Messaging) 是為SOAP通信提供訪問(wèn)方法和傳輸機(jī)制的API。WSDL是一種 XML 格式，用于將網(wǎng)絡(luò)服務(wù)描述為一組端點(diǎn)，這些端點(diǎn)對(duì)包含面向文檔信息或面向過(guò)程信息的消息進(jìn)行操作。這種格式首先對(duì)操作和消息進(jìn)行抽象描述，然后將其綁定到具體的網(wǎng)絡(luò)協(xié)議和消息格式上以定義端點(diǎn)。相關(guān)的具體端點(diǎn)即組合成為抽象端點(diǎn)（服務(wù)）。
SOAP即簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議(Simple Object Access Protocol)，它是用于交換XML編碼信息的輕量級(jí)協(xié)議。
UDDI 的目的是為電子商務(wù)建立標(biāo)準(zhǔn)；UDDI是一套基于Web的、分布式的、為Web Service提供的、信息注冊(cè)中心的實(shí)現(xiàn)標(biāo)準(zhǔn)規(guī)范，同時(shí)也包含一組使企業(yè)能將自身提供的Web Service注冊(cè)，以使別的企業(yè)能夠發(fā)現(xiàn)的訪問(wèn)協(xié)議的實(shí)現(xiàn)標(biāo)準(zhǔn)。
soap是web service最關(guān)鍵的技術(shù)，是web service中數(shù)據(jù)和方法調(diào)傳輸?shù)慕橘|(zhì)。WSDL（web service definition language）描述了web service的接口和功能。
5.計(jì)算機(jī)網(wǎng)絡(luò)分層
參考回答：
6.請(qǐng)你說(shuō)明一下，TCP協(xié)議的4次握手。
參考回答：
由于TCP連接是全雙工的，因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這個(gè)原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(shù)據(jù)流動(dòng)，一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。
TCP的連接的拆除需要發(fā)送四個(gè)包，因此稱為四次揮手(four-way handshake)。客戶端或服務(wù)器均可主動(dòng)發(fā)起揮手動(dòng)作，在socket編程中，任何一方執(zhí)行close()操作即可產(chǎn)生揮手操作。
（1）客戶端A發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶A到服務(wù)器B的數(shù)據(jù)傳送。
（2）服務(wù)器B收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)序號(hào)為收到的序號(hào)加1。和SYN一樣，一個(gè)FIN將占用一個(gè)序號(hào)。
（3）服務(wù)器B關(guān)閉與客戶端A的連接，發(fā)送一個(gè)FIN給客戶端A。
（4）客戶端A發(fā)回ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)設(shè)置為收到序號(hào)加1。
7.談一下，為什么tcp為什么要建立連接？
參考回答：
保證可靠傳輸。
8.請(qǐng)你解釋一下TCP為什么可靠一些
參考回答：
三次握手，超時(shí)重傳，滑動(dòng)窗口，擁塞控制。
9.請(qǐng)說(shuō)明一下哪種應(yīng)用場(chǎng)景會(huì)使用TCP協(xié)議，使用它的意義
參考回答：
當(dāng)對(duì)網(wǎng)絡(luò)通訊質(zhì)量有要求的時(shí)候，比如：整個(gè)數(shù)據(jù)要準(zhǔn)確無(wú)誤的傳遞給對(duì)方，這往往用于一些要求可靠的應(yīng)用，比如HTTP、HTTPS、FTP等傳輸文件的協(xié)議，POP、SMTP等郵件傳輸?shù)膮f(xié)議
10.簡(jiǎn)單描述一下，TCP的連接和釋放過(guò)程。
參考回答：
三次握手的過(guò)程
1）主機(jī)A向主機(jī)B發(fā)送TCP連接請(qǐng)求數(shù)據(jù)包，其中包含主機(jī)A的初始序列號(hào)seq(A)=x。（其中報(bào)文中同步標(biāo)志位SYN=1，ACK=0，表示這是一個(gè)TCP連接請(qǐng)求數(shù)據(jù)報(bào)文；序號(hào)seq=x，表明傳輸數(shù)據(jù)時(shí)的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)是x）；
2）主機(jī)B收到請(qǐng)求后，會(huì)發(fā)回連接確認(rèn)數(shù)據(jù)包。（其中確認(rèn)報(bào)文段中，標(biāo)識(shí)位SYN=1，ACK=1，表示這是一個(gè)TCP連接響應(yīng)數(shù)據(jù)報(bào)文，并含主機(jī)B的初始序列號(hào)seq(B)=y，以及主機(jī)B對(duì)主機(jī)A初始序列號(hào)的確認(rèn)號(hào)ack(B)=seq(A)+1=x+1）
3）第三次，主機(jī)A收到主機(jī)B的確認(rèn)報(bào)文后，還需作出確認(rèn)，即發(fā)送一個(gè)序列號(hào)seq(A)=x+1；確認(rèn)號(hào)為ack(A)=y+1的報(bào)文；
四次揮手過(guò)程
假設(shè)主機(jī)A為客戶端，主機(jī)B為服務(wù)器，其釋放TCP連接的過(guò)程如下：
1） 關(guān)閉客戶端到服務(wù)器的連接：首先客戶端A發(fā)送一個(gè)FIN，用來(lái)關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送，然后等待服務(wù)器的確認(rèn)。其中終止標(biāo)志位FIN=1，序列號(hào)seq=u。
2） 服務(wù)器收到這個(gè)FIN，它發(fā)回一個(gè)ACK，確認(rèn)號(hào)ack為收到的序號(hào)加1。
3） 關(guān)閉服務(wù)器到客戶端的連接：也是發(fā)送一個(gè)FIN給客戶端。
4） 客戶段收到FIN后，并發(fā)回一個(gè)ACK報(bào)文確認(rèn)，并將確認(rèn)序號(hào)seq設(shè)置為收到序號(hào)加1。 首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方執(zhí)行被動(dòng)關(guān)閉。
11.請(qǐng)解釋一下，http請(qǐng)求中的304狀態(tài)碼的含義
參考回答：
304(未修改)自從上次請(qǐng)求后，請(qǐng)求的網(wǎng)頁(yè)未修改過(guò)。服務(wù)器返回此響應(yīng)時(shí)，不會(huì)返回網(wǎng)頁(yè)內(nèi)容。如果網(wǎng)頁(yè)自請(qǐng)求者上次請(qǐng)求后再也沒(méi)有更改過(guò)，您應(yīng)將服務(wù)器配置為返回此響應(yīng)(稱為 If-Modified-Since HTTP 標(biāo)頭)。服務(wù)器可以告訴 Googlebot 自從上次抓取后網(wǎng)頁(yè)沒(méi)有變更，進(jìn)而節(jié)省帶寬和開(kāi)銷。
12. 請(qǐng)你說(shuō)明一下，SSL四次握手的過(guò)程
參考回答：
1、 客戶端發(fā)出請(qǐng)求
首先，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請(qǐng)求，這被叫做ClientHello請(qǐng)求。
2、服務(wù)器回應(yīng)
服務(wù)器收到客戶端請(qǐng)求后，向客戶端發(fā)出回應(yīng)，這叫做SeverHello。
3、客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書(shū)。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致、或者證書(shū)已經(jīng)過(guò)期，就會(huì)向訪問(wèn)者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。
4、服務(wù)器的最后回應(yīng)
服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話所用的"會(huì)話密鑰"。然后，向客戶端最后發(fā)送下面信息。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供客戶端校驗(yàn)。
至此，整個(gè)握手階段全部結(jié)束。接下來(lái)，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過(guò)用"會(huì)話密鑰"加密內(nèi)容。
13.請(qǐng)你講講http1.1和1.0的區(qū)別
參考回答：
主要區(qū)別主要體現(xiàn)在：
緩存處理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來(lái)做為緩存判斷的標(biāo)準(zhǔn)，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來(lái)控制緩存策略。
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用，HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能，HTTP1.1則在請(qǐng)求頭引入了range頭域，它允許只請(qǐng)求資源的某個(gè)部分，即返回碼是206（Partial Content），這樣就方便了開(kāi)發(fā)者自由的選擇以便于充分利用帶寬和連接。
錯(cuò)誤通知的管理，在HTTP1.1中新增了24個(gè)錯(cuò)誤狀態(tài)響應(yīng)碼，如409（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。
Host頭處理，在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(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)求消息中如果沒(méi)有Host頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。
長(zhǎng)連接，HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認(rèn)開(kāi)啟Connection： keep-alive，一定程度上彌補(bǔ)了HTTP1.0每次請(qǐng)求都要?jiǎng)?chuàng)建連接的缺點(diǎn)。
14.請(qǐng)談一下，你知道的http請(qǐng)求，并說(shuō)明應(yīng)答碼502和504的區(qū)別
參考回答：
OPTIONS：返回服務(wù)器針對(duì)特定資源所支持的HTTP請(qǐng)求方法。也可以利用向Web服務(wù)器發(fā)送'*'的請(qǐng)求來(lái)測(cè)試服務(wù)器的功能性。
HEAD：向服務(wù)器索要與GET請(qǐng)求相一致的響應(yīng)，只不過(guò)響應(yīng)體將不會(huì)被返回。這一方法可以在不必傳輸整個(gè)響應(yīng)內(nèi)容的情況下，就可以獲取包含在響應(yīng)消息頭中的元信息。
GET：向特定的資源發(fā)出請(qǐng)求。
POST：向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的創(chuàng)建和/或已有資源的修改。
PUT：向指定資源位置上傳其最新內(nèi)容。
DELETE：請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源。
TRACE：回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
CONNECT：HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
雖然HTTP的請(qǐng)求方式有8種，但是我們?cè)趯?shí)際應(yīng)用中常用的也就是get和post，其他請(qǐng)求方式也都可以通過(guò)這兩種方式間接的來(lái)實(shí)現(xiàn)。
502：作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從上游服務(wù)器接收到無(wú)效的響應(yīng)。
504：作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，未能及時(shí)從上游服務(wù)器（URI標(biāo)識(shí)出的服務(wù)器，例如HTTP、FTP、LDAP）或者輔助服務(wù)器（例如DNS）收到響應(yīng)。
15.請(qǐng)說(shuō)明一下http和https的區(qū)別
參考回答；
1）https協(xié)議要申請(qǐng)證書(shū)到ca，需要一定經(jīng)濟(jì)成本；
2） http是明文傳輸，https是加密的安全傳輸；
3） 連接的端口不一樣，http是80，https是443；
4）http連接很簡(jiǎn)單，沒(méi)有狀態(tài)；https是ssl加密的傳輸，身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，相對(duì)http傳輸比較安全。
16. 請(qǐng)講一下瀏覽器從接收到一個(gè)URL，到最后展示出頁(yè)面，經(jīng)歷了哪些過(guò)程。
1.DNS解析
2.TCP鏈接
3.發(fā)送HTTP請(qǐng)求
4.服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文
5.瀏覽器渲染界面顯示
17. 請(qǐng)簡(jiǎn)單解釋一下，arp協(xié)議和arp攻擊。
參考回答：
地址解析協(xié)議。ARP攻擊的第一步就是ARP欺騙。由上述“ARP協(xié)議的工作過(guò)程”我們知道，ARP協(xié)議基本沒(méi)有對(duì)網(wǎng)絡(luò)的安全性做任何思考，當(dāng)時(shí)人們考慮的重點(diǎn)是如何保證網(wǎng)絡(luò)通信能夠正確和快速的完成——ARP協(xié)議工作的前提是默認(rèn)了其所在的網(wǎng)絡(luò)是一個(gè)善良的網(wǎng)絡(luò)，每臺(tái)主機(jī)在向網(wǎng)絡(luò)中發(fā)送應(yīng)答信號(hào)時(shí)都是使用的真實(shí)身份。不過(guò)后來(lái)，人們發(fā)現(xiàn)ARP應(yīng)答中的IP地址和MAC地址中的信息是可以偽造的，并不一定是自己的真實(shí)IP地址和MAC地址，由此，ARP欺騙就產(chǎn)生了。
18.什么是icmp協(xié)議，它的作用是什么？
參考回答：
它是TCP/IP協(xié)議族的一個(gè)子協(xié)議，用于在IP主機(jī)、路由器之間傳遞控制消息。控制消息是指網(wǎng)絡(luò)通不通、主機(jī)是否可達(dá)、路由是否可用等網(wǎng)絡(luò)本身的消息。這些控制消息雖然并不傳輸用戶數(shù)據(jù)，但是對(duì)于用戶數(shù)據(jù)的傳遞起著重要的作用。
19. 請(qǐng)你講一下路由器和交換機(jī)的區(qū)別？
參考回答：
交換機(jī)用于同一網(wǎng)絡(luò)內(nèi)部數(shù)據(jù)的快速傳輸轉(zhuǎn)發(fā)決策通過(guò)查看二層頭部完成轉(zhuǎn)發(fā)不需要修改數(shù)據(jù)幀工作在 TCP/IP 協(xié)議的二層 —— 數(shù)據(jù)鏈路層工作簡(jiǎn)單，直接使用硬件處理路由器用于不同網(wǎng)絡(luò)間數(shù)據(jù)的跨網(wǎng)絡(luò)傳輸轉(zhuǎn)發(fā)決策通過(guò)查看三層頭部完成轉(zhuǎn)發(fā)需要修改 TTL ，IP 頭部校驗(yàn)和需要重新計(jì)算，數(shù)據(jù)幀需要重新封裝工作在 TCP/IP 協(xié)議的三層 —— 網(wǎng)絡(luò)層工作復(fù)雜，使用軟件處理。
1、工作層次不同：交換機(jī)比路由器更簡(jiǎn)單，路由器比交換器能獲取更多信息
交換機(jī)工作在數(shù)據(jù)鏈路層，而路由器工作在網(wǎng)絡(luò)層
2、數(shù)據(jù)轉(zhuǎn)發(fā)所依據(jù)的對(duì)象不同
交換機(jī)的數(shù)據(jù)轉(zhuǎn)發(fā)依據(jù)是利用物理地址或者說(shuō)MAC地址來(lái)確定轉(zhuǎn)發(fā)數(shù)據(jù)的目的地址,，而路由器是依據(jù)ip地址進(jìn)行工作的
3、傳統(tǒng)的交換機(jī)只能分割沖突域，不能分割廣播域;而路由器可以分割廣播域
20.請(qǐng)你談?wù)凞NS的尋址過(guò)程。
參考回答：
1、在瀏覽器中輸入www.qq.com域名，操作系統(tǒng)會(huì)先檢查自己本地的hosts文件是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，就先調(diào)用這個(gè)IP地址映射，完成域名解析。
2、如果hosts里沒(méi)有這個(gè)域名的映射，則查找本地DNS解析器緩存，是否有這個(gè)網(wǎng)址映射關(guān)系，如果有，直接返回，完成域名解析。
3、如果hosts與本地DNS解析器緩存都沒(méi)有相應(yīng)的網(wǎng)址映射關(guān)系，首先會(huì)找TCP/ip參數(shù)中設(shè)置的首選DNS服務(wù)器，在此我們叫它本地DNS服務(wù)器，此服務(wù)器收到查詢時(shí)，如果要查詢的域名，包含在本地配置區(qū)域資源中，則返回解析結(jié)果給客戶機(jī)，完成域名解析，此解析具有權(quán)威性。
4、如果要查詢的域名，不由本地DNS服務(wù)器區(qū)域解析，但該服務(wù)器已緩存了此網(wǎng)址映射關(guān)系，則調(diào)用這個(gè)IP地址映射，完成域名解析，此解析不具有權(quán)威性。
5、如果本地DNS服務(wù)器本地區(qū)域文件與緩存解析都失效，則根據(jù)本地DNS服務(wù)器的設(shè)置（是否設(shè)置轉(zhuǎn)發(fā)器）進(jìn)行查詢，如果未用轉(zhuǎn)發(fā)模式，本地DNS就把請(qǐng)求發(fā)至13臺(tái)根DNS，根DNS服務(wù)器收到請(qǐng)求后會(huì)判斷這個(gè)域名(.com)是誰(shuí)來(lái)授權(quán)管理，并會(huì)返回一個(gè)負(fù)責(zé)該頂級(jí)域名服務(wù)器的一個(gè)IP。本地DNS服務(wù)器收到IP信息后，將會(huì)聯(lián)系負(fù)責(zé).com域的這臺(tái)服務(wù)器。這臺(tái)負(fù)責(zé).com域的服務(wù)器收到請(qǐng)求后，如果自己無(wú)法解析，它就會(huì)找一個(gè)管理.com域的下一級(jí)DNS服務(wù)器地址(qq.com)給本地DNS服務(wù)器。當(dāng)本地DNS服務(wù)器收到這個(gè)地址后，就會(huì)找qq.com域服務(wù)器，重復(fù)上面的動(dòng)作，進(jìn)行查詢，直至找到www.qq.com主機(jī)。
6、如果用的是轉(zhuǎn)發(fā)模式，此DNS服務(wù)器就會(huì)把請(qǐng)求轉(zhuǎn)發(fā)至上一級(jí)DNS服務(wù)器，由上一級(jí)服務(wù)器進(jìn)行解析，上一級(jí)服務(wù)器如果不能解析，或找根DNS或把轉(zhuǎn)請(qǐng)求轉(zhuǎn)至上上級(jí)，以此循環(huán)。不管是本地DNS服務(wù)器用是是轉(zhuǎn)發(fā)，還是根提示，最后都是把結(jié)果返回給本地DNS服務(wù)器，由此DNS服務(wù)器再返回給客戶機(jī)。
從客戶端到本地DNS服務(wù)器是屬于遞歸查詢，而DNS服務(wù)器之間就是的交互查詢就是迭代查詢。
21.請(qǐng)你簡(jiǎn)單講解一下，負(fù)載均衡 反向代理模式的優(yōu)點(diǎn)、缺點(diǎn)
參考回答：
（1）反向代理（Reverse Proxy）方式是指以代理服務(wù)器來(lái)接受internet上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)服務(wù)器。
（2）反向代理負(fù)載均衡技術(shù)是把將來(lái)自internet上的連接請(qǐng)求以反向代理的方式動(dòng)態(tài)地轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的多臺(tái)服務(wù)器進(jìn)行處理，從而達(dá)到負(fù)載均衡的目的。
（3）反向代理負(fù)載均衡能以軟件方式來(lái)實(shí)現(xiàn)，如apache mod_proxy、netscape proxy等，也可以在高速緩存器、負(fù)載均衡器等硬件設(shè)備上實(shí)現(xiàn)。反向代理負(fù)載均衡可以將優(yōu)化的負(fù)載均衡策略和代理服務(wù)器的高速緩存技術(shù)結(jié)合在一起，提升靜態(tài)網(wǎng)頁(yè)的訪問(wèn)速度，提供有益的性能；由于網(wǎng)絡(luò)外部用戶不能直接訪問(wèn)真實(shí)的服務(wù)器，具備額外的安全性（同理，NAT負(fù)載均衡技術(shù)也有此優(yōu)點(diǎn)）。
（4）其缺點(diǎn)主要表現(xiàn)在以下兩個(gè)方面
反向代理是處于OSI參考模型第七層應(yīng)用的，所以就必須為每一種應(yīng)用服務(wù)專門(mén)開(kāi)發(fā)一個(gè)反向代理服務(wù)器，這樣就限制了反向代理負(fù)載均衡技術(shù)的應(yīng)用范圍，現(xiàn)在一般都用于對(duì)web服務(wù)器的負(fù)載均衡。
針對(duì)每一次代理，代理服務(wù)器就必須打開(kāi)兩個(gè)連接，一個(gè)對(duì)外，一個(gè)對(duì)內(nèi)，因此在并發(fā)連接請(qǐng)求數(shù)量非常大的時(shí)候，代理服務(wù)器的負(fù)載也就非常大了，在最后代理服務(wù)器本身會(huì)成為服務(wù)的瓶頸。
一般來(lái)講，可以用它來(lái)對(duì)連接數(shù)量不是特別大，但每次連接都需要消耗大量處理資源的站點(diǎn)進(jìn)行負(fù)載均衡，如search等。
