一：如果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中。

轉載于:https://www.cnblogs.com/hjp0516-qq/p/11178390.html

總結

以上是生活随笔為你收集整理的面试经常提问的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。