一、三次握手四次揮手
1.1 為什么連接的時候是三次握手，關(guān)閉的時候卻是四次握手？
答：因為當(dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當(dāng)Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，”你發(fā)的FIN報文我收到了”。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。
1.2?為什么TIME_WAIT狀態(tài)需要經(jīng)過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？
MSL（MaximumSegment Lifetime），TCP允許不同的實現(xiàn)可以設(shè)置不同的MSL值。第一，保證客戶端發(fā)送的最后一個ACK報文能夠到達(dá)服務(wù)器，因為這個ACK報文可能丟失，站在服務(wù)器的角度看來，我已經(jīng)發(fā)送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應(yīng)，應(yīng)該是我發(fā)送的請求斷開報文它沒有收到，于是服務(wù)器又會重新發(fā)送一次，而客戶端就能在這個2MSL時間段內(nèi)收到這個重傳的報文，接著給出回應(yīng)報文，并且會重啟2MSL計時器。第二，防止類似與“三次握手”中提到了的“已經(jīng)失效的連接請求報文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個確認(rèn)報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。
1.3 為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？
建立連接的時候，服務(wù)器在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端。而關(guān)閉連接時，服務(wù)器收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對方了，所以己方可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會分開發(fā)送，從而導(dǎo)致多了一次。
1.4 為什么不能用兩次握手進(jìn)行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號進(jìn)行協(xié)商，這個序列號在握手過程中被發(fā)送和確認(rèn)?，F(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機(jī)S和C之間的通信，假定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā)送了確認(rèn)應(yīng)答分組。按照兩次握手的協(xié)定，S認(rèn)為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組?？墒?，C在S的應(yīng)答分組在傳輸中被丟失的情況下，將不知道S是否已準(zhǔn)備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認(rèn)為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分組，只等待連接確認(rèn)應(yīng)答分組。而S在發(fā)出的分組超時后，重復(fù)發(fā)送同樣的分組。這樣就形成了死鎖。
1.5 如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
TCP還設(shè)有一個保活計時器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費(fèi)資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。
1.6 為什么要三次握手？
保證可靠的核心就是雙方都需要確認(rèn)自己發(fā)送和接受信息的功能正常,但因為網(wǎng)絡(luò)環(huán)境的不穩(wěn)定性,這一秒能收發(fā)下一秒可能網(wǎng)絡(luò)核心就發(fā)生嚴(yán)重?fù)砣?所以世界上不存在完全可靠的通信協(xié)議.兩次握手會怎樣?若建立連接只需兩次握手，客戶端并沒有太大的變化，在獲得服務(wù)端的應(yīng)答后進(jìn)入ESTABLISHED狀態(tài)，即確認(rèn)自己的發(fā)送和接受信息的功能正常.但如果服務(wù)端在收到連接請求后就進(jìn)入ESTABLISHED狀態(tài),不能保證客戶端能收到自己的信息,此時如果網(wǎng)絡(luò)擁塞，客戶端發(fā)送的連接請求遲遲到不了服務(wù)端，客戶端便超時重發(fā)請求，如果服務(wù)端正確接收并確認(rèn)應(yīng)答，雙方便開始通信，通信結(jié)束后釋放連接。此時，如果那個失效的連接請求抵達(dá)了服務(wù)端，由于只有兩次握手，服務(wù)端收到請求就會進(jìn)入ESTABLISHED狀態(tài)，等待發(fā)送數(shù)據(jù)或主動發(fā)送數(shù)據(jù)。但此時的客戶端早已進(jìn)入CLOSED狀態(tài)，服務(wù)端將會一直等待下去，這樣浪費(fèi)服務(wù)端連接資源。
1.7 為什么要四次揮手？
TCP連接的釋放一共需要四步,因此稱為『四次揮手』.我們知道,TCP連接是雙向的,因此在四次揮手中,前兩次揮手用于斷開一個方向的連接，后兩次揮手用于斷開另一方向的連接。第一次揮手:若A認(rèn)為數(shù)據(jù)發(fā)送完成,則它需要向B發(fā)送連接釋放請求.該請求只有報文頭,頭中攜帶的主要參數(shù)為:FIN=1,seq=u.此時,A將進(jìn)入FIN-WAIT-1狀態(tài)。1，F(xiàn)IN=1表示該報文段是一個連接釋放請求.
2，seq=u,u-1是A向B發(fā)送的最后一個字節(jié)的序號.
第二次揮手:
B收到連接釋放請求后,會通知相應(yīng)的應(yīng)用程序,告訴它A向B這個方向的連接已經(jīng)釋放.此時B進(jìn)入CLOSE-WAIT狀態(tài),并向A發(fā)送連接釋放的應(yīng)答,其報文頭包含:ACK=1,seq=v,ack=u+1.
ACK=1：除TCP連接請求報文段以外,TCP通信過程中所有數(shù)據(jù)報的ACK都為1，表示應(yīng)答.
1，seq=v，v-1是B向A發(fā)送的最后一個字節(jié)的序號.
2，ack=u+1表示希望收到從第u+1個字節(jié)開始的報文段,并且已經(jīng)成功接收了前u個字節(jié).A收到該應(yīng)答,進(jìn)入FIN-WAIT-2狀態(tài),等待B發(fā)送連接釋放請求.
第二次揮手完成后，A到B方向的連接已經(jīng)釋放，B不會再接收數(shù)據(jù)，A也不會再發(fā)送數(shù)據(jù)。但B到A方向的連接仍然存在，B可以繼續(xù)向A發(fā)送數(shù)據(jù)。
第三次揮手:
當(dāng)B向A發(fā)完所有數(shù)據(jù)后,向A發(fā)送連接釋放請求,請求頭中包含:
FIN=1,ACK=1,seq=w,ack=u+1.隨后B進(jìn)入LAST-ACK狀態(tài).
第四次揮手:
A收到釋放請求后,向B發(fā)送確認(rèn)應(yīng)答,此時A進(jìn)入TIME-WAIT狀態(tài).該狀態(tài)會持續(xù)2MSL時間,若該時間段內(nèi)沒有B的重發(fā)請求的話,就進(jìn)入CLOSED狀態(tài),撤銷TCB.當(dāng)B收到確認(rèn)應(yīng)答后,也便進(jìn)入CLOSED狀態(tài),撤銷TCB。
1.8 為什么TCP客戶端最后還要發(fā)送一次確認(rèn)呢？
一句話，主要防止已經(jīng)失效的連接請求報文突然又傳送到了服務(wù)器，從而產(chǎn)生錯誤。如果使用的是兩次握手建立連接，假設(shè)有這樣一種場景，客戶端發(fā)送了第一個請求連接并且沒有丟失，只是因為在網(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認(rèn)報文，以為服務(wù)器沒有收到，此時重新向服務(wù)器發(fā)送這條報文，此后客戶端和服務(wù)器經(jīng)過兩次握手完成連接，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時此前滯留的那一次請求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個報文本該是失效的，但是，兩次握手的機(jī)制將會讓客戶端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯誤和資源的浪費(fèi)。如果采用的是三次握手，就算是那一次失效的報文傳送過來了，服務(wù)端接受到了那條失效報文并且回復(fù)了確認(rèn)報文，但是客戶端不會再次發(fā)出確認(rèn)。由于服務(wù)器收不到確認(rèn)，就知道客戶端并沒有請求連接。
1.9 簡述TCP三次握手的過程？
答：在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個連接。第一次握手：建立連接時，客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)。第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)簡版：首先A向B發(fā)SYN（同步請求），然后B回復(fù)SYN+ACK（同步請求應(yīng)答），最后A回復(fù)ACK確認(rèn)，這樣TCP的一次連接（三次握手）的過程就建立了。三次握手我們先明確兩個定義：
1，client為數(shù)據(jù)發(fā)送方
2，server為數(shù)據(jù)接收方
好，下面進(jìn)行三次握手的總結(jié)：
1，client想要向server發(fā)送數(shù)據(jù)，請求連接。這時client想服務(wù)器發(fā)送一個數(shù)據(jù)包，其中同步位（SYN）被置為1，表明client申請TCP連接，序號為j。
2，當(dāng)server接收到了來自client的數(shù)據(jù)包時，解析發(fā)現(xiàn)同步位為1，便知道client是想要簡歷TCP連接，于是將當(dāng)前client的IP、端口之類的加入未連接隊列中，并向client回復(fù)接受連接請求，想client發(fā)送數(shù)據(jù)包，其中同步位為1，并附帶確認(rèn)位ACK=j+1，表明server已經(jīng)準(zhǔn)備好分配資源了，并向client發(fā)起連接請求，請求client為建立TCP連接而分配資源。
3，client向server回復(fù)一個ACK，并分配資源建立連接。server收到這個確認(rèn)時也分配資源進(jìn)行連接的建立。
那么問題來了為什么需要第三次握手？第三次握手失敗了怎么辦？三次握手有什么缺陷可以被黑客利用，用來對服務(wù)器進(jìn)行攻擊？
怎么防范這種攻擊？
接下來進(jìn)行一一解答。
1.9.1 為什么需要第三次握手？
答：如果沒有第三次握手，可能會出現(xiàn)如下情況：如果只有兩次握手，那么server收到了client的SYN=1的請求連接數(shù)據(jù)包之后，便會分配資源并且向client發(fā)送一個確認(rèn)位ACK回復(fù)數(shù)據(jù)包。那么，如果在client與server建立連接的過程中，由于網(wǎng)絡(luò)不順暢等原因造成的通信鏈路中存在著殘留數(shù)據(jù)包，即client向server發(fā)送的請求建立連接的數(shù)據(jù)包由于數(shù)據(jù)鏈路的擁塞或者質(zhì)量不佳導(dǎo)致該連接請求數(shù)據(jù)包仍然在網(wǎng)絡(luò)的鏈路中，這些殘留數(shù)據(jù)包會造成如下危害危害：當(dāng)client與server建立連接，數(shù)據(jù)發(fā)送完畢并且關(guān)閉TCP連接之后，如果鏈路中的殘留數(shù)據(jù)包才到達(dá)server，那么server就會認(rèn)為client重新發(fā)送了一次連接申請，便會回復(fù)ACK包并且分配資源。并且一直等待client發(fā)送數(shù)據(jù)，這就會造成server的資源浪費(fèi)。
1.9.2 第三次握手失敗了怎么辦？
答：當(dāng)client與server的第三次握手失敗了之后，即client發(fā)送至server的確認(rèn)建立連接報文段未能到達(dá)server，server在等待client回復(fù)ACK的過程中超時了，那么server會向client發(fā)送一個RTS報文段并進(jìn)入關(guān)閉狀態(tài)，即：并不等待client第三次握手的ACK包重傳，直接關(guān)閉連接請求，這主要是為了防止泛洪攻擊，即壞人偽造許多IP向server發(fā)送連接請求，從而將server的未連接隊列塞滿，浪費(fèi)server的資源。
1.9.3 三次握手有什么缺陷可以被黑客利用，用來對服務(wù)器進(jìn)行攻擊？
答：黑客仿造IP大量的向server發(fā)送TCP連接請求報文包，從而將server的半連接隊列（上文所說的未連接隊列，即server收到連接請求SYN之后將client加入半連接隊列中）占滿，從而使得server拒絕其他正常的連接請求。即拒絕服務(wù)攻擊
1.9.4 怎么防范這種攻擊？
1，縮短服務(wù)器接收客戶端SYN報文之后的等待連接時間，即SYNtimeout時間，也就是server接收到SYN報文段，到最后放棄此連接請求的超時時間，將SYNtimeout設(shè)置的更低，便可以成倍的減少server的負(fù)荷，但是過低的SYNtimeout可能會影響正常的TCP連接的建立，一旦網(wǎng)絡(luò)不通暢便可能導(dǎo)致client連接請求失敗2，SYNcookie + SYN proxy 無縫集成（較好的解決方案）SYNcookie：當(dāng)server接收到client的SYN之后，不立即分配資源，而是根據(jù)client發(fā)送過來的SYN包計算出一個cookie值，這個cookie值用來存儲server返回給client的SYN+ACK數(shù)據(jù)包中的初始序列號，當(dāng)client返回第三次握手的ACK包之后進(jìn)行校驗，如果校驗成功則server分配資源，建立連接。SYNproxy代理，作為server與client連接的代理，代替server與client建立三次握手的連接，同時SYNproxy與client建立好了三次握手連接之后，確保是正常的TCP連接，而不是TCP泛洪攻擊，那么SYNproxy就與server建立三次握手連接，作為代理（網(wǎng)關(guān)？）來連通client與server。（類似VPN了解一下。）
二、路由
2.1 填空題。
1.靜態(tài)路由設(shè)定后，若 網(wǎng)絡(luò) 拓?fù)浣Y(jié)構(gòu)發(fā)生變化，需由系統(tǒng) 管理員 修改路由的 設(shè)置 。
2.網(wǎng)絡(luò)管理的重要任務(wù)是：控制和?監(jiān)控。
3.在安裝Linux系統(tǒng)中，使用netconfig程序?qū)W(wǎng)絡(luò)進(jìn)行配置，該安裝程序會一步步提示用戶輸入主機(jī)名、域名、域名服務(wù)器、IP地址、網(wǎng)關(guān)地址和子網(wǎng)掩碼等必要信息。
4.RIP協(xié)議是最為普遍的一種內(nèi)部協(xié)議，一般稱為動態(tài)路由信息協(xié)議。
5.DHCP可以實現(xiàn)動態(tài)IP地址分配。
6.網(wǎng)絡(luò)管理通常由監(jiān)測、傳輸和管理三部分組成，其中管理部分是整個網(wǎng)絡(luò)管理的中心。
7.?Ping命令可以測試網(wǎng)絡(luò)中本機(jī)系統(tǒng)是否能到達(dá)一臺遠(yuǎn)程主機(jī)，所以常常用于測試網(wǎng)絡(luò)的連通性。
8.進(jìn)行遠(yuǎn)程登錄的命令是telnet。
9.DHCP是動態(tài)主機(jī)配置協(xié)議的簡稱，其作用是：?為網(wǎng)絡(luò)中的主機(jī)分配IP?地址。
10.路由選擇協(xié)議（RIP）的跳數(shù)表示到達(dá)目的地之前必須通過的網(wǎng)關(guān)數(shù)，RIP接受的最長距離是?15?跳。
11.ping命令用于測試網(wǎng)絡(luò)的連通性，ping命令通過?ICMP?協(xié)議（internet控制信息協(xié)議）來實現(xiàn)。
2.2 選擇題。
12.下面的網(wǎng)絡(luò)協(xié)議中，面向連接的的協(xié)議是：?A?。
A?傳輸控制協(xié)議
B?用戶數(shù)據(jù)報協(xié)議
C?網(wǎng)際協(xié)議
D?網(wǎng)際控制報文協(xié)議
13.一臺主機(jī)要實現(xiàn)通過局域網(wǎng)與另一個局域網(wǎng)通信，需要做的工作是?C?。
A?配置域名服務(wù)器
B?定義一條本機(jī)指向所在網(wǎng)絡(luò)的路由
C?定義一條本機(jī)指向所在網(wǎng)絡(luò)網(wǎng)關(guān)的路由
D?定義一條本機(jī)指向目標(biāo)網(wǎng)絡(luò)網(wǎng)關(guān)的路由
14.局域網(wǎng)的網(wǎng)絡(luò)地址192.168.1.0/24，局域網(wǎng)絡(luò)連接其它網(wǎng)絡(luò)的網(wǎng)關(guān)地址是192.168.1.1。主機(jī)192.168.1.20訪問172.16.1.0/24網(wǎng)絡(luò)時，其路由設(shè)置正確的是?B?。
A?route add –net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0metric1
B?route add –net 172.16.1.0 gw 192.168.1.1 netmask 255.255.255.255metric1
C?route add –net 172.16.1.0 gw 172.16.1.1 netmask 255.255.255.0metric 1
D?route add default 192.168.1.0 netmask 172.168.1.1 metric 1
15.下列提法中，不屬于ifconfig命令作用范圍的是?D?。
A?配置本地回環(huán)地址
B?配置網(wǎng)卡的IP地址
C?激活網(wǎng)絡(luò)適配器
D?加載網(wǎng)卡到內(nèi)核中
16.在局域網(wǎng)絡(luò)內(nèi)的某臺主機(jī)用ping?命令測試網(wǎng)絡(luò)連接時發(fā)現(xiàn)網(wǎng)絡(luò)內(nèi)部的主機(jī)都可以連同，而不能與公網(wǎng)連通，問題可能是?C?。
A?主機(jī)IP設(shè)置有誤
B?沒有設(shè)置連接局域網(wǎng)的網(wǎng)關(guān)
C?局域網(wǎng)的網(wǎng)關(guān)或主機(jī)的網(wǎng)關(guān)設(shè)置有誤
D?局域網(wǎng)DNS服務(wù)器設(shè)置有誤
17.下列文件中，包含了主機(jī)名到IP?地址的映射關(guān)系的文件是：?B?。
A?/etc/HOSTNAME
B?/etc/hosts
C?/etc/resolv.conf
D?/etc/networks
18.在TCP/IP?模型中，應(yīng)用層包含了所有的高層協(xié)議，在下列的一些應(yīng)用協(xié)議中，?B?是能夠?qū)崿F(xiàn)本地與遠(yuǎn)程主機(jī)之間的文件傳輸工作。
A?telnet
B?FTP
C?SNMP
D?NFS
19.當(dāng)我們與某遠(yuǎn)程網(wǎng)絡(luò)連接不上時，就需要跟蹤路由查看，以便了解在網(wǎng)絡(luò)的什么位置出現(xiàn)了問題，滿足該目的的命令是?C?。
A?ping
B?ifconfig
C?traceroute
D?netstat
20.DNS域名系統(tǒng)主要負(fù)責(zé)主機(jī)名和?A?之間的解析。
A?IP地址
B?MAC地址
C?網(wǎng)絡(luò)地址
D?主機(jī)別名
21.WWW服務(wù)器是在Internet上使用最為廣泛，它采用的是?B?結(jié)構(gòu)。
A?服務(wù)器/工作站
B?B/S
C?集中式
D?分布式
22.網(wǎng)絡(luò)管理具備以下幾大功能：配置管理、?A?、性能管理、安全管理和計費(fèi)管理等。
A?故障管理
B?日常備份管理
C?升級管理
D?發(fā)送郵件
23.關(guān)于代理服務(wù)器的論述，正確的是?A?。
A?使用internet?上已有的公開代理服務(wù)器，只需配置客戶端。
B?代理服務(wù)器只能代理客戶端http?的請求。
C?設(shè)置好的代理服務(wù)器可以被網(wǎng)絡(luò)上任何主機(jī)使用。
D?使用代理服務(wù)器的客戶端沒有自己的ip?地址。
24.實現(xiàn)從IP地址到以太網(wǎng)MAC地址轉(zhuǎn)換的命令為：?C?。
A?ping
B?ifconfig
C?arp
D?traceroute
25.在DNS系統(tǒng)測試時，設(shè)named進(jìn)程號是53，命令?D?通知進(jìn)程重讀配置文件。
A?kill –USR2 53
B?kill –USR1 53
C?kill -INT 63
D?kill –HUP 53
26.在DNS配置文件中，用于表示某主機(jī)別名的是：?B?。
A?NS
B?CNAME
C?NAME
D?CN
27.為保證在啟動服務(wù)器時自動啟動DHCP?進(jìn)程，應(yīng)對?B?文件進(jìn)行編輯。
A?/etc/rc.d/rc.inet2
B?/etc/rc.d/rc.inet1
C?/etc/dhcpd.conf
D?/etc/rc.d/rc.S
2.3 簡答題。
28．寫一條192.168.10.0網(wǎng)段從網(wǎng)關(guān)192.168.9.1出去的路由
答：routeadd -net 192.168.10.0/24gw 192.168.9.1
29.給主機(jī)host：172.16.0.2增加gateway10.0.0.1
答：routeadd 172.16.0.2 gw 10.0.0.1或者網(wǎng)卡配置文件更改
30.網(wǎng)站出現(xiàn)500,502,400,403,404都是什么意思，怎么排查和解決
答：500：服務(wù)器內(nèi)部錯誤，因為服務(wù)器上的程序?qū)懙挠袉栴}，需要打開錯誤日志，查看日志，分析錯誤信息。502：網(wǎng)關(guān)錯誤，服務(wù)器作為網(wǎng)關(guān)或代理，從上游服務(wù)器收到無效響應(yīng)。Nginx出現(xiàn)最多，出現(xiàn)502要么是nginx配置的不對，要么是php-fpm資源不夠，可以分析php-fpm的慢執(zhí)行日志，優(yōu)化php-fpm的執(zhí)行速度。400：錯誤請求，服務(wù)器不理解請求的語法。這可能是用戶發(fā)起的請求不合理，需要檢查客戶端的請求。
403：服務(wù)器拒絕請求。檢查服務(wù)器配置，是不是對客戶端做了限制。
404：未找到請求的資源。檢查服務(wù)器上是否存在請求的資源，看是否是配置問題。
31.TCP有哪些了解，TCP連接狀態(tài)中“TIME_WAIT”是什么意思，影響什么？
答：關(guān)于tcp有點(diǎn)復(fù)雜，直接上圖吧，更直觀
need-to-insert-img
狀態(tài)描述：
CLOSED：這個沒什么好說的了，表示初始狀態(tài)。
LISTEN：這個也是非常容易理解的一個狀態(tài)，表示服務(wù)器端的某個SOCKET處于監(jiān)聽狀態(tài)，可以接受連接了。
SYN_RCVD：這個狀態(tài)表示接受到了SYN報文，在正常情況下，這個狀態(tài)是服務(wù)器端的SOCKET在建立TCP連接時的三次握手會話過程中的一個中間狀態(tài)，很短暫，基本上用netstat你是很難看到這種狀態(tài)的，除非你特意寫了一個客戶端測試程序，故意將三次TCP握手過程中最后一個ACK報文不予發(fā)送。因此這種狀態(tài)時，當(dāng)收到客戶端的ACK報文后，它會進(jìn)入到ESTABLISHED狀態(tài)。
SYN_SENT：這個狀態(tài)與SYN_RCVD遙想呼應(yīng)，當(dāng)客戶端SOCKET執(zhí)行CONNECT連接時，它首先發(fā)送SYN報文，因此也隨即它會進(jìn)入到了SYN_SENT狀態(tài)，并等待服務(wù)端的發(fā)送三次握手中的第2個報文。SYN_SENT狀態(tài)表示客戶端已發(fā)送SYN報文。
ESTABLISHED：這個容易理解了，表示連接已經(jīng)建立了。
FIN_WAIT_1：這個狀態(tài)要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進(jìn)入到FIN_WAIT_1狀態(tài)。而當(dāng)對方回應(yīng)ACK報文后，則進(jìn)入到FIN_WAIT_2狀態(tài)，當(dāng)然在實際的正常情況下，無論對方何種情況下，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常?？梢杂胣etstat看到。
FIN_WAIT_2：上面已經(jīng)詳細(xì)解釋了這種狀態(tài)，實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點(diǎn)數(shù)據(jù)需要傳送給你，稍后再關(guān)閉連接。
TIME_WAIT：表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN_WAIT_1狀態(tài)下，收到了對方同時帶FIN標(biāo)志和ACK標(biāo)志的報文時，可以直接進(jìn)入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。
CLOSING：這種狀態(tài)比較特殊，實際情況中應(yīng)該是很少見，屬于一種比較罕見的例外狀態(tài)。正常情況下，當(dāng)你發(fā)送FIN報文后，按理來說是應(yīng)該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。但是CLOSING狀態(tài)表示你發(fā)送FIN報文后，并沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什么情況下會出現(xiàn)此種情況呢？其實細(xì)想一下，也不難得出結(jié)論：那就是如果雙方幾乎在同時close一個SOCKET的話，那么就出現(xiàn)了雙方同時發(fā)送FIN報文的情況，也即會出現(xiàn)CLOSING狀態(tài)，表示雙方都正在關(guān)閉SOCKET連接。
CLOSE_WAIT：這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢？當(dāng)對方close一個SOCKET后發(fā)送FIN報文給自己，你系統(tǒng)毫無疑問地會回應(yīng)一個ACK報文給對方，此時則進(jìn)入到CLOSE_WAIT狀態(tài)。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以close這個SOCKET，發(fā)送FIN報文給對方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接。
LAST_ACK：這個狀態(tài)還是比較容易好理解的，它是被動關(guān)閉一方在發(fā)送FIN報文后，最后等待對方的ACK報文。當(dāng)收到ACK報文后，也即可以進(jìn)入到CLOSED可用狀態(tài)了。
32.簡述DNS進(jìn)行域名解析的過程。
參考答案：首先，客戶端發(fā)出DNS請求翻譯IP地址或主機(jī)名。DNS服務(wù)器在收到客戶機(jī)的請求后：（1）檢查DNS服務(wù)器的緩存，若查到請求的地址或名字，即向客戶機(jī)發(fā)出應(yīng)答信息；（2）若沒有查到，則在數(shù)據(jù)庫中查找，若查到請求的地址或名字，即向客戶機(jī)發(fā)出應(yīng)答信息；
（3）若沒有查到，則將請求發(fā)給根域DNS?服務(wù)器，并依序從根域查找頂級域，由頂級查找二級域，二級域查找三級，直至找到要解析的地址或名字，即向客戶機(jī)所在網(wǎng)絡(luò)的DNS服務(wù)器發(fā)出應(yīng)答信息，DNS服務(wù)器收到應(yīng)答后現(xiàn)在緩存中存儲，然后，將解析結(jié)果發(fā)給客戶機(jī)。
（4）若沒有找到，則返回錯誤信息。
33.什么是靜態(tài)路由，其特點(diǎn)是什么？什么是動態(tài)路由，其特點(diǎn)是什么？
參考答案：靜態(tài)路由是由系統(tǒng)管理員設(shè)計與構(gòu)建的路由表規(guī)定的路由。適用于網(wǎng)關(guān)數(shù)量有限的場合，且網(wǎng)絡(luò)拓樸結(jié)構(gòu)不經(jīng)常變化的網(wǎng)絡(luò)。其缺點(diǎn)是不能動態(tài)地適用網(wǎng)絡(luò)狀況的變化，當(dāng)網(wǎng)絡(luò)狀況變化后必須由網(wǎng)絡(luò)管理員修改路由表。動態(tài)路由是由路由選擇協(xié)議而動態(tài)構(gòu)建的，路由協(xié)議之間通過交換各自所擁有的路由信息實時更新路由表的內(nèi)容。動態(tài)路由可以自動學(xué)習(xí) 網(wǎng)絡(luò)的拓樸結(jié)構(gòu)，并更新路由表。其缺點(diǎn)是路由廣播更新信息將占據(jù)大量的網(wǎng)絡(luò)帶寬。
34.linux下常用的DNS服務(wù)軟件是什么，舉出幾種常用的DNS記錄，如果域名abc.com配置好了一臺郵件服務(wù)器,IP地址為202.106.0.20，我該如何做相關(guān)的解析？是否了解bind的智能解析，如果了解請簡述一下其原理。
答案：1)常用的DNS軟件是bind2)A記錄地址記錄MX記錄郵件交換記錄
CNAME記錄別名域記錄
3)修改abc.com?域名的配置文件，增加以下記錄
INMX 10 mail.abc.com.
mailIN A 202.106.0.20
4)bind根據(jù)請求解析客戶端的IP地址，做出不同的解析，其原理是在配置文件中，設(shè)定了view，在每個view都有客戶端的IP地址段，bind服務(wù)器根據(jù)請求解析客戶端的IP地址，匹配不同的view,再根據(jù)該view的配置，到相應(yīng)的配置文件進(jìn)行查詢，將結(jié)果返回給請求的客戶端。
35.AB網(wǎng)絡(luò)是通的，最少列出五種傳輸文件的服務(wù)
nfs，ftp，scp，rsync，samba，http://
36.我們都知道，dns既采用了tcp協(xié)議，又采用了udp協(xié)議，什么時候采用tcp協(xié)議？什么時候采用udp協(xié)議？為什么要這么設(shè)計？
答：這個題需要理解的東西比較的多，分一下幾個方面a，從數(shù)據(jù)包大小上分：UDP的最大包長度是65507個字節(jié)，響應(yīng)dns查詢的時候數(shù)據(jù)包長度超過512個字節(jié)，而返回的只要前512個字節(jié)，這時名字解釋器通常使用TCP 從發(fā)原來的請求。b，從協(xié)議本身來分：大部分的情況下使用UDP協(xié)議，大家都知道UDP協(xié)議是一種不可靠的協(xié)議，dns不像其它的使用UDP的Internet應(yīng)用(如：TFTP，BOOTP和SNMP等)，大部分集中在局域網(wǎng)，dns查詢和響應(yīng)需要經(jīng)過廣域網(wǎng)，分組丟失和往返時間的不確定性在廣域網(wǎng)比局域網(wǎng)上更大，這就要求dns客戶端需要好的重傳和超時算法，這時候使用TCP。
三、七層模型
3.1 說說TCP/IP的七層模型
應(yīng)用層?(Application)：網(wǎng)絡(luò)服務(wù)與最終用戶的一個接口。協(xié)議有：HTTP?FTP?TFTP?SMTP?SNMP?DNS?TELNET?HTTPS?POP3?DHCP表示層（Presentation?Layer）：
數(shù)據(jù)的表示、安全、壓縮。（在五層模型里面已經(jīng)合并到了應(yīng)用層）
格式有，JPEG、ASCll、DECOIC、加密格式等
會話層（Session?Layer）：
建立、管理、終止會話。（在五層模型里面已經(jīng)合并到了應(yīng)用層）
對應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會話
傳輸層?(Transport)：
定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗。
協(xié)議有：TCP?UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層
網(wǎng)絡(luò)層?(Network)：
進(jìn)行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。
協(xié)議有：ICMP?IGMP?IP（IPV4?IPV6）?ARP?RARP
數(shù)據(jù)鏈路層?(Link)：
建立邏輯連接、進(jìn)行硬件地址尋址、差錯校驗等功能。（由底層網(wǎng)絡(luò)定義協(xié)議）
將比特組合成字節(jié)進(jìn)而組合成幀，用MAC地址訪問介質(zhì)，錯誤發(fā)現(xiàn)但不能糾正。
物理層（Physical?Layer）：
是計算機(jī)網(wǎng)絡(luò)OSI模型中最低的一層。
物理層規(guī)定：為傳輸數(shù)據(jù)所需要的物理鏈路創(chuàng)建、維持、拆除而提供具有機(jī)械的，電子的，功能的和規(guī)范的特性。
簡單的說，物理層確保原始的數(shù)據(jù)可在各種物理媒體上傳輸。局域網(wǎng)與廣域網(wǎng)皆屬第1、2層。物理層是OSI的第一層，它雖然處于最底層，卻是整個開放系統(tǒng)的基礎(chǔ)。物理層為設(shè)備之間的數(shù)據(jù)通信提供傳輸媒體及互連設(shè)備，為數(shù)據(jù)傳輸提供可靠的環(huán)境。如果您想要用盡量少的詞來記住這個第一層，那就是“信號和介質(zhì)”。
