【運維心得】運維面試，你應該知道這些（1）

最近正巧看到關於運維面試的問題，經過自己的篩選，把重要的問題和答案摘錄一下，以備將來面試時使用，也分享給大家。

網絡須知

爲什麼不能兩次握手，必須三次握手？

保證可靠的核心就是雙方都需要確認自己發送和接受信息的功能正常,但因爲網絡環境的不穩定性,這一秒能收發下一秒可能網絡核心就發生嚴重擁塞,所以世界上不存在完全可靠的通信協議.
兩次握手會怎樣?
若建立連接只需兩次握手，客戶端並沒有太大的變化，在獲得服務端的應答後進入ESTABLISHED狀態，即確認自己的發送和接受信息的功能正常.但如果服務端在收到連接請求後就進入ESTABLISHED狀態,不能保證客戶端能收到自己的信息,此時如果網絡擁塞，客戶端發送的連接請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收並確認應答，雙方便開始通信，通信結束後釋放連接。此時，如果那個失效的連接請求抵達了服務端，由於只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送數據或主動發送數據。但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端連接資源。
死鎖是可能發生的？
作爲例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認爲連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認爲連接還未建立成功，將忽略S發來的任何數據分組，只等待連接確認應答分組。而S在發出的分組超時後，重複發送同樣的分組。這樣就形成了死鎖。

爲什麼要四次揮手？

因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

三次握手有什麼缺陷可以被黑客利用？

黑客仿造IP大量的向server發送TCP連接請求報文包，從而將server的半連接隊列（上文所說的未連接隊列，即server收到連接請求SYN之後將client加入半連接隊列中）佔滿，從而使得server拒絕其他正常的連接請求。即拒絕服務攻擊

怎麼防範拒絕服務攻擊？

1. 縮短服務器接收客戶端SYN報文之後的等待連接時間，即SYNtimeout時間，也就是server接收到SYN報文段，到最後放棄此連接請求的超時時間，將SYNtimeout設置的更低，便可以成倍的減少server的負荷，但是過低的SYNtimeout可能會影響正常的TCP連接的建立，一旦網絡不通暢便可能導致client連接請求失敗。
2. SYNcookie + SYN proxy 無縫集成（較好的解決方案）SYNcookie：當server接收到client的SYN之後，不立即分配資源，而是根據client發送過來的SYN包計算出一個cookie值，這個cookie值用來存儲server返回給client的SYN+ACK數據包中的初始序列號，當client返回第三次握手的ACK包之後進行校驗，如果校驗成功則server分配資源，建立連接。SYNproxy代理，作爲server與client連接的代理，代替server與client建立三次握手的連接，同時SYNproxy與client建立好了三次握手連接之後，確保是正常的TCP連接，而不是TCP泛洪攻擊，類似VPN。

局域網的網絡地址192.168.1.0/24，局域網絡連接其它網絡的網關地址是192.168.1.1。主機192.168.1.20訪問172.16.1.0/24網絡時，其路由設置正確的是：

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

在局域網絡內的某臺主機用ping 命令測試網絡連接時發現網絡內部的主機都可以連同，而不能與公網連通，問題可能是：

A 主機IP設置有誤

B 沒有設置連接局域網的網關

C 局域網的網關或主機的網關設置有誤

D 局域網DNS服務器設置有誤

寫一條192.168.10.0網段從網關192.168.9.1出去的路由

routeadd -net 192.168.10.0/24gw 192.168.9.1

給主機host：172.16.0.2增加gateway10.0.0.1

1. routeadd 172.16.0.2 gw 10.0.0.1
2. 或者網卡配置文件更改

網站出現500,502,400,403,404都是什麼意思，怎麼排查和解決

500：服務器內部錯誤，因爲服務器上的程序寫的有問題，需要打開錯誤日誌，查看日誌，分析錯誤信息。
502：網關錯誤，服務器作爲網關或代理，從上游服務器收到無效響應。Nginx出現最多，出現502要麼是nginx配置的不對，要麼是php-fpm資源不夠，可以分析php-fpm的慢執行日誌，優化php-fpm的執行速度。
400：錯誤請求，服務器不理解請求的語法。這可能是用戶發起的請求不合理，需要檢查客戶端的請求。
403：服務器拒絕請求。檢查服務器配置，是不是對客戶端做了限制。
404：未找到請求的資源。檢查服務器上是否存在請求的資源，看是否是配置問題。

什麼是靜態路由、動態路由？其特點是什麼？

靜態路由
是由系統管理員設計與構建的路由表規定的路由。適用於網關數量有限的場合，且網絡拓樸結構不經常變化的網絡。其缺點是不能動態地適用網絡狀況的變化，當網絡狀況變化後必須由網絡管理員修改路由表。
動態路由
是由路由選擇協議而動態構建的，路由協議之間通過交換各自所擁有的路由信息實時更新路由表的內容。動態路由可以自動學習網絡的拓樸結構，並更新路由表。其缺點是路由廣播更新信息將佔據大量的網絡帶寬。

dns既採用了tcp協議，又採用了udp協議，什麼時候採用tcp協議？什麼時候採用udp協議？爲什麼要這麼設計？

首先明確一個重要概念：UDP報文的最大長度爲512字節，而TCP則允許報文長度超過512字節。

1. 輔助DNS服務器同步採用TCP協議
   DNS的規範規定了2種類型的DNS服務器，一個叫主DNS服務器，一個叫輔助DNS服務器。在一個區中主DNS服務器從自己本機的數據文件中讀取該區的DNS數據信息，而輔助DNS服務器則從區的主DNS服務器中讀取該區的DNS數據信息。當一個輔助DNS服務器啓動時，它需要與主DNS服務器通信，並加載數據信息，這就叫做區傳送（zone transfer）。輔助域名服務器會定時（一般是3小時）向主域名服務器進行查詢以便了解數據是否有變動。如有變動，則會執行一次區域傳送，進行數據同步。區域傳送將使用TCP而不是UDP，因爲數據同步傳送的數據量比一個請求和應答的數據量要多得多。
2. 域名解析時使用UDP協議
   客戶端向DNS服務器查詢域名，一般返回的內容都不超過512字節，用UDP傳輸即可。不用經過TCP三次握手，這樣DNS服務器負載更低，響應更快。