linux運維（八）

    面了一家網絡工程師，感受明天要拿Offer了，但這不是我從事的職位，這只是保底Offer，唉，好但願有點底氣哦！這幾周勞資花了太多錢了，我又有了新的目標，明天不過一場小考驗，檢驗我這幾天的複習成果，其實我真正的目標，是下週的互聯網金融。我太容易墮落了，必須找到目標

一、linux系統中如何獲取pid爲100的進程的全部TCP鏈接，請給出詳細命令？（不看操做界面是作不出來的，固然有思路就行，就說awk條件判斷）

答：[root@192 1dir]# netstat -tnlp|awk '{print $7}'|awk -F "/" '$1==100{print $0}'

二、Squid如何查看緩存命中率和清理緩存信息。

答：安裝squid時自帶的squidclient工具，suqid命中率很低的緣由多是請求的動態內容太多，而squid主要緩存靜態內容。Web緩存典型的cache命中率在30%到60%之間，在這裏端口是能夠是3128也能夠是80、

squidclient -p 3128 mgr:info

squidclient -p 3128 -m PURGE http://www.361way.com  #強制更新某個url,即清理某鏈接的squid

參考文檔：http://www.361way.com/squid-percentage/1951.html

三、主機A須要給主機B傳輸一份10GB的數據，從應用層上能夠作哪些傳輸優化？從TCP上能夠作哪些傳輸優化？請分別列舉優化措施。

答：（1）應用層上通過壓縮再進行傳輸。

（2）把10個GB大小的數據分紅一個一個小段進行傳輸，這是爲了流量控制，避免發送方發的太快了。

（3）TCP層上，首部控制信息上能不能加少點，好比不加填充選項，另外能把TCP改成UDP嗎，由於UDP系統開銷要小點，數據原本就大，否則傳輸太浪費時間了。

四、說一下linux 的啓動流程（我特麼多但願能考這個題啊！）

答：（1）BIOS 加電自檢，決定從網絡、硬盤或者USB、光盤等方式啓動

（2）讀取MBR，加載bootloader，出現grub 菜單，加載內核

（3）啓動第一個進程即init 進程，讀取/etc/inittab，決定從哪一個運行級別啓動

（4）偵測硬件，加載驅動程序，執行/etc/rc.sysint 系統初始化，好比網絡、時區等

（5）運行一些某個級別下開機自啓服務，啓動內核模塊

（6）讀取/etc/rc.local，執行開機運行腳本

（7）miggety 程序運行/bin/login，出現用戶登陸界面，通過身份認證後，用戶方可以使用操做系統

五、儘量多的列出你知道的安裝linux操做系統的方法。（媽蛋，這特麼啥垃圾問題）

答：（1）PXE kickstart無人值守自動安裝

（2）在光盤放入鏡像，分區格式化等等。

（3）在虛擬機中克隆其餘的操做系統

六、簡述下傳統機械硬盤和SSD的性能差別，並列舉幾種。（沒見過固態硬盤、衡量一個硬盤主要是存儲容量、讀寫能力、以及穩定性）

答：區別（1）機械硬盤的磁盤讀寫能力不如固態硬盤

（2）抗震性和穩定性，固態硬盤優於機械硬盤

（3）外觀上，機械硬盤是用磁盤轉的，磁頭、扇區、柱面等尋道比較消耗系統資源，而固態硬盤就是個芯片似的

舉例：機械：SAS、SCSI、IDE硬盤、SATA  固態硬盤：SSD

七、簡述DHCP的獲取IP地址的過程。（這我要好好整理下了）

答：四次報文的交互過程。服務器端UDP 67端口，客戶端68端口。

（1）客戶端廣播發送一個DHCP discover報文，詢問該網段中有誰能給我提供IP地址。

（2）全部本網段的DHCP服務器都能收到該offer報文，給客戶端返回一個DHCP offer報文，依然是廣播，由於客戶端沒有IP地址

（3）客戶端選擇第一個到達的DHCP offer報文，做爲他的服務器，而後廣播發送DHCP request報文，表示我選中這臺服務器給我發IP了。

（4）被選中的那臺服務器收到後，給客戶端發送DHCP ACK報文，該報文中含有租約、主機所需IP、網關、子網掩碼、以及DNS

八、ftp的主動模式和被動模式，各有什麼使用場景，並簡述兩種模式下，ftp的鏈接創建過程？（使用場景有點新穎）

答：場景：主動模式用於下載，被動模式用於上傳。由於下載必須由服務器主動傳過來，而上傳是客戶端主動（服務端被動）傳過來的。

注意：創建控制鏈接前都要創建TCP鏈接，隨機端口N大於1024

（2）主動模式：客戶端打開一個控制端口N，同時開啓一個數據端口N+1，控制端口N 與服務端的21 端口創建鏈接；而後客戶端發送Port命令告知對方服務端

個人數據端口是N+1,因而服務端用20 端口和客戶端的數據端口N+1 創建通道，從而開始傳輸數據

（3）被動模式：也是客戶端打開一個控制端口N，同時開啓另外一個數據端口N+1,和服務端的21端口初始化創建控制鏈接。客戶端發送PASV命令，詢問對方數據端口P是否可用，若是可用，服務端打開P端口，返回ACK確認信息，而後客戶端就去主動連服務端的數據通道端口了。

九、linux系統中如何獲取pid爲100的進程所監聽的tcp端口，請給出詳細命令。（問題很新穎呀）

答：netstat -antup |grep 100

十、須要抓取eth1網卡上從127.10.32.5發到本機8080端口的數據包，請列舉你能想到的工具或者方法？並給出一個具體的方法的實現（詳細命令或者代碼）？

答：tcpdump tcp port 8080 -i eth1 and src host  127.10.32.5 ##tcpdump -i eth1 src net 127.0.0.0

十一、服務器交付業務方使用後，使用netstat命令發現有大量的time_wait鏈接，請簡述time_wait鏈接存在的緣由？如何解決。（注意，緣由不是做用）

答：（1）緣由：通常線上出現大量time_wait的重要背景是業務使用了nginx代理。因爲nginx使用短鏈接的方式和客戶端大量交互，

（2）危害：若是是由服務器主動關閉客戶端的鏈接,將致使服務器端存在大量的處於TIME_WAIT狀態的socket,甚至比處於Established狀態下的socket多的多,嚴重影響服務器的處理能力,甚至耗盡可用的socket,中止服務。另外，若是客戶端的併發量持續很高，此時部分客戶端就會顯示鏈接不上。

（3）解決方法：發現系統存在大量TIME_WAIT狀態的鏈接，經過調整內核參數解決，

vi /etc/sysctl.conf 編輯文件，加入如下內容：

net.ipv4.tcp_syncookies = 1  #表示開啓SYN Cookies。當出現SYN等待隊列溢出時，啓用cookies來處理，可防範少許SYN***，默認爲0，表示關閉

net.ipv4.tcp_tw_reuse = 1  #表示開啓重用。容許將TIME-WAIT sockets從新用於新的TCP鏈接，默認爲0，表示關閉；

net.ipv4.tcp_tw_recycle = 1 #表示開啓TCP鏈接中TIME-WAIT sockets的快速回收，默認爲0，表示關閉。

net.ipv4.tcp_fin_timeout = 30 #修改系統默認的 TIMEOUT 時間，

而後執行 /sbin/sysctl -p 讓參數生效

十二、短鏈接和長鏈接有什麼區別？什麼場景下用短鏈接？何時用長鏈接？

答：（1）區別：短鏈接是指通訊雙方有數據交互時，就創建一個TCP鏈接，數據發送完成後，則斷開此TCP鏈接；鏈接→數據傳輸→關閉鏈接；所謂長鏈接，指在一個TCP鏈接上能夠連續發送多個數據包，在TCP鏈接維持期間，若是沒有數據包發送，須要雙方發檢測包以維持此鏈接，通常須要本身作在線維持（不發生RST包和四次揮手）。 

（2）優勢：短鏈接：管理起來比較簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段，長鏈接減小系統開銷，避免頻繁三次握手。

（3）場景：銀行或者電子商務使用短鏈接，使用完畢就斷開。長鏈接多用於操做頻繁（讀寫），點對點的通信，並且鏈接數不能太多狀況，例如：數據庫的鏈接用長鏈接，若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket 建立也是對資源的浪費。

參考文檔：http://www.cnblogs.com/onlysun/p/4520553.html

1三、http的keepalive的做用是什麼，有什麼優缺點？它和tcp的keepalive有何區別？

答：（1）TCP的keep alive是檢查當前TCP鏈接是否活着；HTTP的Keep-alive是要讓一個TCP鏈接活久點。它們是不一樣層次的概念。

（2）

1四、LVS的持久鏈接機制是什麼？session綁定和session共享有何區別？如何理解會話保持時間Persistence？

答：（1）當一個客戶端發起請求時，無論TCP鏈接有沒有斷開，只要這個客戶訪問過，咱們的LVS就會在內存緩衝區當中，未來自客戶端第一次發起請求的鏈接IP地址和給他所選定的real server綁定映射關係，不管使用何種算法。當客戶端再次訪問時，直接查看這個會話表，若持久鏈接模板沒有超時，則交給同一個real server處理。

（2）區別：session綁定就是在一臺機器上，通常是調度器，映射客戶端IP和服務端IP的關係，只要是你這個客戶端，那麼只要不超時，你客戶端的請求都是後端某臺固定的機器來處理的，session綁定就是持久鏈接。而sesion共享是針對多臺服務器共享一個會話信息，同時也能避免session複製的開銷。session綁定通常用在lvs的場景下，而session共享通常用在數據庫服務器中，專門搭建一臺Memcached來進行存儲session。

（3）persistence:這個會話保持時間是最大無響應超時時間，也就是說，用戶在操做動態頁面時，若是50秒內沒有執行任何操做，那麼接下來的操做會被分發到另外的節點，可是若是用戶一直在操做動態頁面，則不受50秒的時間限制。（起初我還覺得每臺服務器處理的固定時間呢，看來是由客戶端影響的）

參考文檔：http://wenku.baidu.com/view/f5ec0c65ee06eff9aef80779.html?from=search

1五、keepalived的工做原理機制是什麼，並說明LVS+keepalived如何測試？

答：keepalived使用D類組播地址224.0.0.18進行心跳檢測，keepalived使用vrrp協議進行通訊，在keepalived配置文件中生成兩個VRRP實例，將兩臺物理服務器虛擬成一個邏輯服務器，並使用同一個虛擬IP（這裏沒有虛擬MAC，由於在Internet中的網關不是LVS調度器），在網絡和系統正常狀況下，主控調度器將客戶端發往虛擬IP的請求進行分組轉發，而備份調度器不作什麼事，當主控調度器掛掉以後，備份調度器可以檢測到，並進行故障的切換，備份機器開始替代成爲主控機器，從而不影響客戶端的訪問，從而實現系統的高可用性。

測試：（1）停掉主控機器的keepalived或者直接把主控機器直接關機，在備份機器上查看系統日誌/var/log/message，以及tcpdump vrrp，檢測到VIP漂移到備份

機器上，而且成爲Master角色。

（2）在瀏覽器訪問VIP 80端口的時候，檢測是否頁面交替出現，則證實負載均衡的效果。而後停掉後端某一臺真實web服務器，檢測客戶端是否依然能正常訪問

某一個頁面。

1六、Memcached工做原理，有何特色，做用、應用場景、端口號以及經常使用命令有哪些？（握草，這就難了，但是簡歷已經寫了，本想湊個字數，現在添麻煩啊）

答：（1）內存管理機制中，SlabAllocator的基本原理是按照預先規定的數據塊大小，將已分配的內存分割成特定長度的塊（chunk），這裏有一個增加因子的說法，並把尺寸相同的塊分紅一個組（class），當用戶發來key-value存儲請求時，memcached會計算key+value的大小，看看屬於哪一個slab。肯定slab後看裏面的是否有空閒chunk放置key+value，若是不夠就再向系統申請一個內存頁面page，若是已經到達了申請上限，則使用LRU算法移除已有的一些數據。

（2）特色：它是內存緩存服務器，自己沒法決定緩存任何數據，一半依賴於客戶端，一半依賴於服務端，惰性機制（過時了也不清理），基於LRU最近最少使用算法移除數據（有種說法是不刪除數據，只是不顯示給客戶端），影響業務自己，但不影響元數據自己。緩存對象大小各不同，內存碎片問題是主要問題，沒法根治。分佈式緩存服務器（即多臺Memcached服務器）彼此是不通訊的。

（3）做用：對查詢頻繁的數據進行緩存，從而減少後端數據庫服務器的處理查詢壓力。

（4）場景：在Mysql一主多從架構中，對從服務器集羣的查詢緩存。

（5）端口號：11211 ，經過telnet localhost 11211進行測試

（6）六個經常使用命令：get set stats add delelte append等

memcached會優先使用已超時的記錄的空間，但即便如此，也會發生追加新記錄時空間不足的狀況，此時就要使用名爲 Least Recently Used（LRU）機制來分配空間。顧名思義，這是刪除「最近最少使用」的記錄的機制。所以，當memcached的內存空間不足時（沒法從slab 

class 獲取到新的空間時），就從最近未被使用的記錄中搜索，並將其空間分配給新的記錄。從緩存的實用角度來看，該模型十分理想

參考文檔：http://blog.163.com/czg_e/blog/static/4610456120114755125970/

1七、Memcached如何優化？

答：以最大可能解決內存碎片問題。

1，-n 參數的設置，注意將此參數設置爲1024能夠整除的數（還要考慮48B的差值），不然餘下來的部分就浪費了。

2，不要存儲超過1m的數據。由於要拆成多個chunk，計算和時間成本都成倍增長。

3，善用stats命令查看memcached狀態。

4，消滅eviction（被刪除的數據）。形成eviction是由於內存不夠，有三個思路：一是在CPU有餘力的狀況下開啓壓縮（PHP擴展）；二是增長內存；三是調整 -f 參數，減小內存浪費。

5，調整業務代碼，提升命中率。

6，緩存小數據。省帶寬，省網絡I/O時間，省內存。

7，根據業務特色，爲數據尺寸區間小的業務分配專用的memcached實例。這樣能夠調小 -f 參數，使數據集中存在少數幾個slab上，內存浪費較少。

參考文檔：https://my.oschina.net/liuxd/blog/63129

1八、rsync的工做原理？工做方式，有何特色？

答：（1）rsync基於C/S客戶服務器模式，rsync服務器打開873端口通道，等待客戶端鏈接過來，若是口令認證經過，則容許同步到遠程客戶機，第一次同步的時候，把要同步的文件所有經過TCP/IP網絡發送過去，第二次同步的時候，會經過某種算法比較已經存在的文件和將要同步的文件之間的差別，再把差別部分傳輸過去，從而提升傳輸的效率。

（2）本地模式：經過rsync命令進行推、拉操做。 daemon模式：結合inotify內核監控機制，寫入一個rsync腳本進行觸發式同步操做  crond模式：定時週期性的進行遠程同步。

（3）特色：①增量備份②保持文件的屬性不變③支持刪除目的機器有而源機器沒有有④能夠指定某些文件不進行同步⑤支持傳輸前進行壓縮，從而節省帶寬。

1九、exec、source以及bash的區別。（真的很差理解）

答：（1）exec:在原進程中執行，可是同時會終止原進程。

（2）source:在原進程中執行，可是不產生子進程。

（3）bash:父進程會用fork方法建立一個子進程，shell script在子進程中執行。

20、磁盤分區的實質是什麼？什麼是主分區、擴展分區、邏輯分區，那它與/root分區，swap分區這些有什麼聯繫嗎？（說實話，這個是真難理解啊！磁道、扇區啥的更很差描述）

答：（1）分區實質：對磁盤的格式化。分區的好處或者說緣由：提升其可管理性，不一樣的分區有不一樣的做用。

（2）主分區：能夠寫入操做系統相關信息的分區，進行引導系統啓動，至關於windows的C盤。擴展分區：擴展分區也是一個主分區，但不能直接使用，目的是容納邏輯分區，能夠說沒有擴展分區就沒有邏輯分區，邏輯分區的存在必須有擴展分區。用「咱們的面不能吃，可是面作成了餃子或者餅就能吃」來比喻。邏輯分區：相似於windows中的D/E/F盤，幾塊邏輯上獨立的存儲介質。

（3）最多4個主分區，最多1個擴展分區，能夠。即1主、1擴、多邏輯；或者2主1擴、多邏輯；再或者3主、1擴、多邏輯；若是是4主，那麼不可能有邏輯分區。

（4）硬盤的容量＝主分區的容量＋擴展分區的容量，擴展分區的容量＝各個邏輯分區的容量之和。即硬盤=主分區+各個邏輯分區。

/             根目錄         ext3        hda1    

/home     用戶目錄         ext3        hda2

/boot 引導分區 ext4 hda3

Swap     交換分區         swap        hda5  ##邏輯分區的設備名稱號碼由5開始,好比還有/var,/usr等

2一、格式化有何目的，是先格式化仍是先掛載？MBR有何做用？

答：（1）格式化的目的是寫入文件系統。先格式化（mkfs命令）後掛載（mount），使用完畢後要卸載（umount）。

（2）磁道：就是磁盤上面的不少個同心圓;而每個磁道按512個字節爲單位劃分的弧段叫作扇區;柱面：從立體空間來看，相同編號的磁道稱爲柱面；簇：相鄰磁道之間的扇區的空隙之處，

（3）MBR：主引導記錄，位於第0柱面、第0磁道、第1個扇區，加載BootLoader，引導系統啓動。

2二、簡述https原理，創建通訊的過程。（貌似之前整理過，也記不住）

答：（1）客戶端發送一個client hello報文，攜帶了客戶端所支持的算法和隨機數，以及SSL版本號。

（2）服務端收到client hello報文後，會返回給客戶端Server hello報文，該Server hello報文中攜帶協商好的算法，以及公鑰和CA證書。

（3）客戶端驗證證書的合法性，並使用服務端的公鑰對報文進行加密，將加密後的報文發過去。

（4）服務端使用它本身的私鑰進行解密，握手階段基本完成。

參考文檔：http://hittyt.iteye.com/blog/1618497

2三、說說一致性哈希算法。（這個不看視頻徹底不懂）

答：（1）先構造一個長度爲0~2^32（2的32次冪）個的整數環（又稱：一致性Hash環），根據節點名稱的Hash值將緩存服務器節點防置在這個Hash環中，如上圖中的node1，node2等；

（2）根據須要緩存的數據的KEY計算獲得其Hash值，如上圖中右半部分的「鍵」，計算其Hash值後離node2很近；

（3）在Hash環上順時針查找距離這個KEY的Hash值最近的緩存服務器節點，完成KEY到服務器的Hash映射查找，如上圖中離右邊這個鍵的Hash值最近的順時針方向的服務器節點是node2，所以這個KEY會到node2中讀取數據；

當緩存服務器集羣須要擴容的時候，只須要將新加入的節點名稱（如node5）的Hash值放入一致性Hash環中，因爲KEY老是順時針查找距離其最近的節點，所以新加入的節點隻影響整個環中的一部分。以下圖中所示，添加node5後，隻影響右邊逆時針方向的三個Key/Value對數據，只佔整個Hash環中的一小部分。

參考文檔：http://www.wtoutiao.com/p/231Kcfk.html

2四、http中301和302區別

答：（1）302重定向是暫時的重定向，搜索引擎會抓取新的內容而保留舊的網址。由於服務器返回302代碼，搜索引擎認爲新的網址只是暫時的。302多是URL劫持的一種表現。

（2）301重定向是永久的重定向，搜索引擎在抓取新內容的同時也將舊的網址替換爲重定向以後的網址。

參考文檔：http://blog.csdn.net/xlinsist/article/details/41987973

2五、加密算法怎麼實現，公鑰私鑰有什麼區別，加密解密流程？（考到這些安全問題，真心很差回答，不過確實很重要）

答：（1）公鑰和私鑰區別：公鑰即公開的密鑰，你們都知道的密鑰，私鑰即私有的密鑰，只有他本身知道。

（2）第一種加密流程：Bob將他的公開密鑰傳送給Alice。Alice用Bob的公開密鑰加密她的消息，而後傳送給Bob。Bob用他的私人密鑰解密Alice的消息。

第二種加密流程：Alice用她的私人密鑰對文件加密，從而對文件簽名。Alice將簽名的文件傳送給Bob。Bob用Alice的公鑰解密文件，從而驗證簽名。

（3）加密算法的實現：使用加密密鑰對原始明文進行一系列置換或者移位操做，最後獲得密文的過程。這樣即便非法用戶得到加密過的資料，也沒法理解其真實含義。

參考文檔：http://blog.sina.com.cn/s/blog_45497dfa0100y0k5.html

2六、http和https有何區別？

答：（1） HTTP協議 的URL以http://開頭，而HTTPS協議的URL以https:// 開頭。

（2）HTTP 是不安全的，而 HTTPS 是安全的。

（3）HTTP 標準端口是80 ，而 HTTPS 的標準端口是443。

（4）在OSI 網絡模型中，HTTP工做於應用層，而SSL工做在應用層和傳輸層之間的抽象層。

（5） HTTP 沒法對傳輸數據進行加密，而HTTPS 對傳輸的數據進行加密。

（6）HTTP無需證書，而HTTPS 須要CA機構的頒發的SSL證書。

2七、linux系統下如何查看CPU的總核數？（核數就是一塊CPU上面能處理數據的芯片組的數量.）

答：總核數=物理CPU的個數*每顆CPU的核數

查看物理CPU的個數：cat /proc/cpuinfo|grep "physical id"

查看每顆物理CPU的核數：cat /proc/cpuinfo|grep "cpu cores"

邏輯CPU的個數=總核心數*超線程數：即cat /proc/cpuinfo|grep "processor"

查看CPU的型號：cat /proc/cpuinfo|grep name 

2八、假如如今有個文本，即左邊是隨機字母，右邊是隨機數字。（難，awk最TM難用了）

a  1

b  3

c  2

d  7

b  5

a  3 

g  2

f  6

d  9

現要求寫個腳本使其輸出格式爲,即將相同的字母后面的數字累加在一塊兒，按字母的順序輸出。

a  4

b  8

c  2

d  16

f  6

g  2

答：awk '{a[$1]+=$2}END{for(i in a){print i,a[i]}}' file.txt

2九、有哪些因素可能致使mysql主從不一樣步，若是主從不一樣步，報錯了，怎麼恢復？

答:（1）版本不一致，特別是高版本是主，低版本爲從的狀況下，主數據庫上面支持的功能，從數據庫上面不支持該功能。

（2）自己就是異步複製，網絡延遲形成的

（3）主從兩臺機器的負載不一致，當中任何一臺機器的負載很高，忙不過來，致使其中的任何一個線程出現資源不足，都將出現主從不一致的狀況。

（4）主庫重啓致使從庫數據不一樣步，並且主鍵衝突

（5）Binlog日誌格式設置的很差。

解決：鎖住Master表，（主庫通常不能停啊，TMD注意了，別SB了），停掉slave，而後從新change master_to進行同步，最後啓動slave，若是報錯，就執行

命令set global sql_slave_skip_counter=1用來跳過錯誤進行同步。

參考文檔：http://storysky.blog.51cto.com/628458/259280/

30、生產場景，一主多從環境，某一臺從庫宕機，如今又修好了，請問你如何恢復主從同步？若是主庫宕機又修好了，那又怎麼恢復主從同步過程？（沒讓說原理我就不哭了，這個問題必須思考）

答：從庫宕機：若是隻是某一臺從機器宕機了，那麼查詢的壓力就分配在其餘機器上，等這臺機器修復好了，在其餘從庫或者主庫mysqldump備份，在scp遠程同步過來數據,從新導入.sql文件，而後stop slave，change master to，start slave 等

主庫宕機：從新提高slave1做爲主控機器，其餘salve從slave1中複製數據，若是原來的主庫修好了，那麼把他加入從庫集羣隊列中。

參考文檔：http://ucode.blog.51cto.com/10837891/1747078/