前段時間一直在面試，也沒怎麼寫博客，現在找到實習工作了，也有時間去寫了。在這裏分享一下我面試之前做的一些準備。
（以下內容是我從網上查找整理得到的...紅色標註爲面試提及的，但不一定是我整理的內容）
TCP/IP
簡述TCP三次握手的過程？
答：在TCP/IP協議中，TCP協議提供可靠的連接服務，採用三次握手建立一個連接。第一次握手：建立連接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認。第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態。第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。完成三次握手，客戶端與服務器開始傳送數據簡版：首先A向B發SYN（同步請求），然後B回覆SYN+ACK（同步請求應答），最後A回覆ACK確認，這樣TCP的一次連接（三次握手）的過程就建立了。
爲什麼連接的時候是三次握手，關閉的時候卻是四次握手？
這是因爲當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。
但是關閉連接時，當Client端發送FIN報文僅僅表示它不再發送數據了但是還能接收數據，Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
HTTP
https://blog.51cto.com/13570193/2108347
SHELL
https://www.cnblogs.com/gala1021/p/8519456.html
https://www.jb51.net/article/135168.htm
常用命令
top(能瞭解top後的每一個字段意思)
grep,sed,awk
Apache
https://blog.csdn.net/keda8997110/article/details/19696337
Tomcat
https://blog.csdn.net/xlgen157387/article/details/79006434
Tomcat工作模式？
Tomcat是一個JSP/Servlet容器。其作爲Servlet容器，有三種工作模式：獨立的Servlet容器、進程內的Servlet容器和進程外的Servlet容器。
進入Tomcat的請求可以根據Tomcat的工作模式分爲如下兩類：
Tomcat作爲應用程序服務器：請求來自於前端的web服務器，這可能是Apache, IIS, Nginx等；
Tomcat作爲獨立服務器：請求來自於web瀏覽器；
Haproxy
簡介
HAproxy：HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。HAProxy特別適用於那些負載特大的web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬件上，完全可以支持數以萬計的併發連接。並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中，同時可以保護你的web服務器不被暴露到網絡上。
特點
1）HAProxy 也是支持虛擬主機的。
2）HAProxy 的優點能夠補充 Nginx 的一些缺點，比如支持 Session 的保持，Cookie的引導；同時支持通過獲取指定的 url 來檢測後端服務器的狀態。
3）HAProxy 跟 LVS 類似，本身就只是一款負載均衡軟件；單純從效率上來講HAProxy 會比 Nginx 有更出色的負載均衡速度，在併發處理上也是優於 Nginx 的。
4）HAProxy 支持 TCP 協議的負載均衡轉發，可以對 MySQL 讀進行負載均衡，對後端的 MySQL 節點進行檢測和負載均衡，大家可以用 LVS+Keepalived 對 MySQL主從做負載均衡。
負載均衡算法
Haproxy有8種負載均衡算法（balance），分別如下：
1.balance roundrobin # 輪詢，軟負載均衡基本都具備這種算法
2.balance static-rr # 根據權重，建議使用
3.balance leastconn # 最少連接者先處理，建議使用
4.balance source # 根據請求源IP，建議使用
5.balance uri # 根據請求的URI
6.balance url_param，# 根據請求的URl參數'balance url_param' requires an URL parameter name
7.balance hdr(name) # 根據HTTP請求頭來鎖定每一次HTTP請求
8.balance rdp-cookie(name) # 根據據cookie(name)來鎖定並哈希每一次TCP請求
會話保持
由於負載請求分發到不同服務器，可能導致Session會話不同步的問題，若想實現會話共享或保持，可採用如下3種方式：
1.用戶IP 識別
haroxy 將用戶IP經過hash計算後 指定到固定的真實服務器上（類似於nginx 的IP hash 指令）
配置指令:balance source
2.Cookie 識別
haproxy 將WEB服務端發送給客戶端的cookie中插入(或添加加前綴)haproxy定義的後端的服務器COOKIE ID。
配置指令例舉:cookie SESSION_COOKIE insert indirect nocache
用firebug可以觀察到用戶的請求頭的cookie裏 有類似” Cookie jsessionid=0bc588656ca05ecf7588c65f9be214f5; SESSION_COOKIE=app1” SESSION_COOKIE=app1就是haproxy添加的內容
3.Session 識別
haproxy 將後端服務器產生的session和後端服務器標識存在haproxy中的一張表裏。客戶端請求時先查詢這張表。
配置指令例舉:appsession JSESSIONID len 64 timeout 5h request-learn
Keepalived
Keepalived：Keepalived是一個保證集羣高可用的服務軟件，用來防止單點故障，使用VRRP協議實現。在master和backup之間通過master主動降低自己的權值或者backup檢測到master出現故障時，backup將會接管master的工作，繼續服務。
Mysql
http://www.imooc.com/article/280936
主從、主主、性能調優、數據備份恢復
詳述MySQL主從複製原理及配置主從的完整步驟
主從複製的原理如下：
主庫開啓binlog功能並授權從庫連接主庫，從庫通過change master得到主庫的相關同步信息,然後連接主庫進行驗證，主庫IO線程根據從庫slave線程的請求，從master.info開始記錄的位置點向下開始取信息，同時把取到的位置點和最新的位置與binlog信息一同發給從庫IO線程，從庫將相關的sql語句存放在relay-log裏面，最終從庫的sql線程將relay-log裏的sql語句應用到從庫上，至此整個同步過程完成，之後將是無限重複上述過程
完整步驟如下：
1、主庫開啓binlog功能，並進行全備，將全備文件推送到從庫服務器上
2、show master status\G 記錄下當前的位置信息及二進制文件名
3、登陸從庫恢復全備文件
4、執行change master to 語句
5、執行start slave and show slave status\G
Zabbix
Ansible、Jenkins、Gitlab
ansible
https://www.jianshu.com/p/c82737b5485c
Docker
https://blog.csdn.net/zisefeizhu/article/details/83345398
雜七雜八
假如有人反應，調取後端接口時特別慢，你會如何排查？
筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這麼說的：問清楚反應的人哪個服務應用或者頁面調取哪個接口慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網絡加載、大圖片、還是某個文件內容等），如果有，就對症下藥去解決（圖片慢就優化圖片、網絡慢就查看內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問接口日誌纔會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。
當一個網站訪問慢時，你怎麼去優化
翻譯爲: 當一個網站訪問慢時, 你都是怎麼去查找問題,和解決問題以達到優化效果的
第一,用5分鐘排除網絡因素,藉助工具(如pagespeed)分析頁面加載過程1. 某個元素或者圖片加載過慢: 具體原因具體分析
2. DNS解析時長問題: 可以通過購買解析服務, 來讓自己的域名在各地DNS更多緩存
3. 網絡帶寬瓶頸: 考慮增加帶寬
4. 網絡線路波動: 考慮CDN,或者鏡像站第二,要考慮到服務器問題1. 是否有服務器過載: 考慮增加硬件
2. I/O操作:數據庫的頻繁讀寫，服務器的頻繁請求（包括靜態文件的讀取，圖片的讀取）等都屬於I/O問題。對於數據庫的問題，首先要優化SQL，存儲過程等。如果單表數據量過大要考慮做分割或者運用程序來控制分表。如果請求量過大，要考慮做集羣。對於服務器（靜態）文件的I/O問題，則可以考慮做CDN，這樣也可以解決地域性問題。對於動態文件的訪問，則涉及到代碼優化及負載均衡兩項。
3. 具體應用優化: nginx針對訪問量修改配置文件,調高Buffers 調低keep alive空連接時間等第三,安全方面1. 查看web\mail等其它服務日誌,是否存在被攻擊現象: 針對安全方面加固
2. 是否有其它攻擊存在DDOS,WEB CC等
簡述一下DNS的解析過程
解答：
1、在瀏覽器中輸入www.qq.com域名，操作系統會先檢查自己本地的hosts文件是否有這個網址映射關係，如果有，就先調用這個IP地址映射，完成域名解析。
2、如果hosts裏沒有這個域名的映射，則查找本地DNS解析器緩存，是否有這個網址映射關係，如果有，直接返回，完成域名解析。
3、如果hosts與本地DNS解析器緩存都沒有相應的網址映射關係，首先會找TCP/IP參數中設置的首選DNS服務器，在此我們叫它本地DNS服務器，此服務器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。
4、如果要查詢的域名，不由本地DNS服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個IP地址映射，完成域名解析，此解析不具有權威性。
5、如果本地DNS服務器本地區域文件與緩存解析都失效，則根據本地DNS服務器的設置（是否設置轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至13臺根DNS，根DNS服務器收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名服務器的一個IP。本地DNS服務器收到IP信息後，將會聯繫負責.com域的這臺服務器。這臺負責.com域的服務器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS服務器地址(qq.com)給本地DNS服務器。當本地DNS服務器收到這個地址後，就會找qq.com域服務器，重複上面的動作，進行查詢，直至找到www.qq.com主機。
6、如果用的是轉發模式，此DNS服務器就會把請求轉發至上一級DNS服務器，由上一級服務器進行解析，上一級服務器如果不能解析，或找根DNS或把轉請求轉至上上級，以此循環。不管是本地DNS服務器用是是轉發，還是根提示，最後都是把結果返回給本地DNS服務器，由此DNS服務器再返回給客戶機。
從客戶端到本地DNS服務器是屬於遞歸查詢，而DNS服務器之間就是的交互查詢就是迭代查詢。
linux系統的啓動過程
1.加載BIOS
2.讀取MBR
3.Boot Loader
4.加載內核
5.用戶層init根據inittab文件來設定運行級別
6.init進程執行rc.sysinit
7.啓動內核模塊
8.執行不同運行級別的腳本程序
9.執行/etc/rc.d/rc.local
10.執行/bi/login程序，進入登陸狀態
FTP的主動模式和被動模式
FTP協議有兩種工作方式：PORT方式和PASV方式，中文意思爲主動式和被動式。
PORT（主動）方式的連接過程是：客戶端向服務器的FTP端口（默認是21）發送連接請 求，服務器接受連接，建立一條命令鏈路。當需要傳送數據時，客戶端在命令鏈路上用PORT 命令告訴服務器：“我打開了XX端口，你過來連接我”。於是服務器從20端口向客戶端的 XX端口發送連接請求，建立一條數據鏈路來傳送數據。
PASV（被動）方式的連接過程是：客戶端向服務器的FTP端口（默認是21）發送連接請 求，服務器接受連接，建立一條命令鏈路。當需要傳送數據時，服務器在命令鏈路上用PASV 命令告訴客戶端：“我打開了XX端口，你過來連接我”。於是客戶端向服務器的XX端口 發送連接請求，建立一條數據鏈路來傳送數據。
從上面可以看出，兩種方式的命令鏈路連接方法是一樣的，而數據鏈路的建立方法就完 全不同。
彙總
https://www.linuxidc.com/Linux/2018-08/153699.htm