一：如果chmod-x/bin/chmod執行上述命令後，如何恢復 Per版：sudo perl-e’chmod 0775,”/bin/chmod” Python3版：sudo python-c”import os;os.chmod(“/bin/chmod”,0755)” 二:一臺電腦配置無限好，可 ...
一：如果chmod-x/bin/chmod執行上述命令後，如何恢復
- 重裝coreutils
- 安裝busybox，使用busybox chmod + x /bin/chmod改回來
Per版：sudo perl-e’chmod 0775,”/bin/chmod”
Python3版：sudo python-c”import os;os.chmod(“/bin/chmod”,0755)”
二:一臺電腦配置無限好，可以同時打開多少個網頁？
65535-1024=64511（埠數）
三：IP地址能被偽造嗎？
http頭部可以被篡改，但是只能修改X_FORWARDED_FOR，真實ip地址（REMOTE_ADDR）很難修改（除非是路由器去修改），因為真實IP是底層會話IP地址，而且因為TCP3次握手的存在，連接無法建立，偽造的意義不大，至於UDP的話，一般是內網才使用UDP通信。
四：有100萬個獎品，每個人可以中獎3次，先到先得，怎麼控制併發，不能發超，並保證完全的先到先得模式？
如果獎品相同，則在redis中初始化一個值5為100萬的KV值，每當一個用戶抽獎時，現在Redis判斷該用戶的抽獎記錄，如果抽獎記錄小於3則可去抽獎，並增加抽獎記錄。否則重定向到靜態頁面，直到100W獎品抽完為止。如果獎品不通，需要根據獎品種類初始化獎品種類數量的KV值，重覆上面過程。
五：Memcache和Redis的區別？
- Redis中，並不是所有的數據都一直存儲在記憶體中的，這是和Memcache相比一個最大的區別。
- Redis在很多方面具備資料庫的特征，或者說就是一個資料庫系統，而Memcache只是簡單的K/V緩存。
- 他們的擴展都需要做集群；實現方式：master-slave、Hash。
- 在100k以上的數據中，Memcache性能要高於Redis
- 如果要說記憶體使用效率，使用簡單的key-value存儲的話，Memcached的記憶體利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其記憶體利用率會高於Memcache。當然這和你的應用場景和數據特性有關。
- 如果你對數據持久化和數據同步有所要求，那麼推薦你選擇Redis，因為這兩個特性Memcache都不具備。即使你只是希望在升級或者重啟系統後緩存數據不會丟失，選擇Redis也是明智的。
- Redis和Memcache在寫入性能上面差別不打，讀取性能上面尤其是批量讀取性能上面Memcache更強
- Redis支持多種數據結構，如string,list,dict,set,,zset,hyperloglog一個網頁從輸入地址回車，到完整展示網頁內容這段時間里，做了哪些工作，越詳細越好。
- 瀏覽器本地緩存匹配
- 本地hosts映射對比
- 本地dns緩存解析
- 遠程dns解析獲得伺服器Ip地址
- 瀏覽器發送tcp連接請求包（syn）
- 請求包經過傳輸層、網路層、數據鏈路層封裝通過網卡到達路由器
- 路由器轉發數據包到所屬運營商伺服器
- 運營商伺服器通過定址最短路徑通過中繼節點到達指定IP地址
- 伺服器端可能存在反向代理或者負載均衡，都是直接轉發請求之上游伺服器，當然也可以制定安全防禦規則直接丟齊請求包
- 上游伺服器收到連接請求，在自身可用的情況下，返回（syn+ack）
- 瀏覽器校驗ack，再次發送（syn+ack）
- 伺服器校驗ack切換連接狀態至established，然後根據請求傳輸數據包
- 當transform-encoding為chunked時瀏覽器開始渲染頁面；四次揮手，連接關閉
- 渲染數據完成
六：HTTP Keep-Alive是什麼？
HTTP協議採用“請求-應答”模式，當使用普通模式，即5非KeepAlive模式時，每個請求/應答客戶和伺服器都要新建一個連接，完成之後立即斷開連接（Http協議為無連接的協議），當時用Keep-Alive模式（又稱持久連接、連接重用）時，Keep-Alive功能使客戶端到伺服器端的連接持續有效，當出現對伺服器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。
Http1.0中預設是關閉的，需要在http頭加入“Connection:Keep-Alive”，才能啟用Keep-Alive;http1.1中預設啟用Keep-Alive如果加入“Connection:close”，才關閉目前大部分瀏覽器都是用http1.1協議，也就是說預設都會發起Keep-Alive的連接請求了，所以是否能完成一個完整的Keep- Alive連接就看伺服器設置情況。
七：myisam跟innodb有什麼區別？
- InnoDB支持事務，MyISAM不支持，對於InnoDB每一條SQL語言都預設封裝成事務，自動提交，這樣會影響速度，所以最好把多條SQL語言放在begin和commit之間，組成一個事務；
- InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB表轉為MYISAM會失敗；
- InnoDB是聚集索引，數據文件是和索引綁在一起的，必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然後再通過主鍵查詢到數據。因此，主鍵不應該過大，因為主鍵太大，其他索引也都會很大。而MyISAM是非聚集索引，數據文件是分離的，索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。
- InnoDB不保存表的具體行數，執行select count(*) from table時需要全表掃描。而MyISAM用一個變數保存了整個表的行數，執行上述語句時只需要讀出該變數即可，速度很快；
- Innodb不支持全文索引，而MyISAM支持全文索引，查詢效率上MyISAM要高；
八：什麼是 CSRF 攻擊 ？XSS 攻擊？如何防範？
XSS定義的主語是“腳本”，是一種跨站執行的腳本，也就是javascript腳本，指的是在網站上註入我們的javascript腳本，執行非法操作。
CSRF定義的主語是”請求“，是一種跨站的偽造的請求，指的是跨站偽造用戶的請求，模擬用戶的操作。
防禦XSS攻擊可以通過以下兩方面操作：
對用戶表單輸入的數據進行過濾，對javascript代碼進行轉義，然後再存入資料庫；
在信息的展示頁面，也要進行轉義，防止javascript在頁面上執行。
CSRF攻擊的防禦可以通過以下兩方面操作：
所有需要用戶登錄之後才能執行的操作屬於重要操作，這些操作傳遞參數應該使用post方式，更加安全；
為防止跨站請求偽造，我們在某次請求的時候都要帶上一個csrf_token參數，用於標識請求來源是否合法，csrf_token參數由系統生成，存儲在SESSION中。
