web安全與性能優化（web 攻擊）

前端經典專案框架如下

全堆疊專案經典后端框架如下

前端技術堆疊如下：（可自行百度看API檔案）
–elementUI
– Vue.js
– Npm
– Webpack
– WebSocket
– Node

后端技術堆疊如下：
– 基礎Web服務，微服務架構
– Mysql
– Redis
– ElasticS
– Nginx
– CDN

Redis?
Redis 是完全開源的，遵守 BSD 協議，是一個高性能的key-value 資料庫，
– Redis支持資料的持久化，可以將記憶體中的資料保存在磁盤中，重啟的時候可以再次加載進行使用，
– 性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s ，
– Redis支持資料的備份，即master-slave模式的資料備份，

ElasticSearch
? Elasticsearch 是一個分布式、高擴展、高實時的搜索與 資料分析引擎，它能很方便的使大量資料具有搜索、分 析和探索的能力，

? Elasticsearch 的實作原理主要分為以下幾個步驟：
– 用戶將資料提交到Elasticsearch 資料庫
– 通過分詞控制器去將對應的陳述句分詞，將其權重和分詞結 果一并存入資料庫
– 當用戶搜索資料時候，再根據權重將結果排名，打分，再 將回傳結果呈現給用戶，

Nginx
? Nginx 是一個高性能的HTTP和反向代理web服務器，同 時也提供了IMAP/POP3/SMTP服務，

CDN
? CDN的全稱是Content Delivery Network，即內容分發
網路，CDN是構建在現有網路基礎之上的智能虛擬網路，
依靠部署在各地的邊緣服務器，通過中心平臺的負載均
衡、內容分發、調度等功能模塊，使用戶就近獲取所需
內容，降低網路擁塞，提高用戶訪問回應速度和命中率，
CDN的關鍵技術主要有內容存盤和分發技術，

CDN邊緣服務器實作負載均衡、內容分發、調度等功能如下：

? CDN快取原理：

? CDN節省骨干網帶寬，提高服務器訪問速度與穩定性，
能克服網站分布不均的問題：

資料庫優化
? 資料庫優化主要包含以下幾類：

– SQL調優與索引（解決大部分問題）

SQL以及索引的優化是最重要的，首先要根據需求寫出結構良好的
SQL，然后根據SQL在表中建立有效的索引，但是如果索引太多，不
但會影響寫入的效率，對查詢也有一定的影響，

– 資料結構
– 系統配置
– 硬體


– SQL調優與索引（解決大部分問題）
– 資料結構
要根據一些范式來進行表結構的設計，設計表結構時，就需要考慮如
何設計才能夠更有效的查詢，
– 系統配置
– 硬體

– SQL調優與索引（解決大部分問題）
– 資料結構
– 系統配置
系統配置的優化，MySQL資料庫是基于檔案的，如果打開的檔案數達
到一定的數量，無法打開之后就會進行頻繁的IO操作，
– 硬體


– SQL調優與索引（解決大部分問題）
– 資料結構
– 系統配置
– 硬體
硬體優化，更快的IO、更多的記憶體，一般來說記憶體越大，對于資料庫
的操作越好，但是CPU多就不一定了，因為他并不會用到太多的CPU
數量，有很多的查詢都是單CPU，另外使用高的IO（SSD、RAID），

– HTML靜態化：
效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使
我們的網站上的頁面采用靜態頁面來實作，這個最簡單的方法其實也
是最有效的方法，但是對于大量內容并且頻繁更新的網站，我們無法
全部手動去挨個實作，于是出現了我們常見的資訊發布系統CMS，像
我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是
通過資訊發布系統來管理和實作的，

– 圖片服務器分離
– 快取
– 負載均衡


– HTML靜態化
– 圖片服務器分離
– 快取
– 負載均衡
負載均衡將是大型網站解決高負荷訪問和大量并發請求采用的高端解
決辦法，可以使用Nginx實作，

請求回應優化
? 減少DNS查找：每次主機名的決議都需要一次網路往返， 從而增加了請求的延遲時間，同時還會阻塞后續的請求，
? 減少HTTP重定向，HTTP沖定向需要額外的DNS查詢、 TCP握手等非常耗時，最佳的重定向次數為0.
? 使用CDN（內容分發網路）：把資料放在離用戶地理位 置更近的地方，可以明顯減少每次TCP連接的網路延遲， 增大吞吐量，

洗掉沒有必要請求的資源，
? 在客戶端快取資源：快取必要的應用資源，避免每次都 重復請求相同的內容，例如多圖片下載可以考慮使用緩 存，
? 內容在傳輸前先壓縮：傳輸資料之前應該先壓縮應用資 源，把要傳輸的位元組減少到最小，在壓縮的時候確保對 每種不同的資源采用最好的壓縮手段，

? 消除不必要的請求開銷：減少請求的HTTP首部資料（比 如HTTP cookie）. ? 并行處理請求和回應：請求和回應的派對都會導致延遲，
可以嘗試并行的處理請求和回應（利用多個HTTP1.1連 接實作并行下載，在可能的情況下使用HTTP管道計數），
? 1針對協議版本采取優化措施，升級到HTTP2.0，

常見Web安全問題及解決方案(面試會問到)

? 常見Web安全問題有：
（自行了解）
? SQL注入問題
? XSS跨站腳本攻擊
? XSRF跨站請求偽造
? Session劫持

SQL注入即是指web應用程式對用戶輸入資料的合法性
沒有判斷或過濾不嚴，攻擊者可以在web應用程式中事
先定義好的查詢陳述句的結尾上添加額外的SQL陳述句，在
管理員不知情的情況下實作非法操作，以此來實作欺騙
資料庫服務器執行非授權的任意查詢，從而進一步得到
相應的資料資訊，

一般用戶登錄用的SQL陳述句為：

SELECT * FROM user WHERE username='admin' AND password='password' 

此處admin和passwd分別為用戶輸入的用戶名和密碼，
如果程式員沒有對用戶輸入的用戶名和密碼做處理，就
可以構造萬能密碼成功繞過登錄驗證，如：

#輸入密碼： 'or'1'=='1 
SELECT * FROM user WHERE username=='' AND password=''
or '1'=='1'

? SQL注入問題的解決方案：
– 做好客戶端表單驗證，
– 做好服務端引數驗證，
– 資料庫使用預編譯的SQL陳述句，

XSS跨站腳本攻擊

? XSS是跨站腳本攻擊(Cross Site Scripting)，為不和層疊
樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故
將跨站腳本攻擊縮寫為XSS，惡意攻擊者往Web頁面里
插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中
Web里面的Script代碼會被執行，從而達到惡意攻擊用
戶的目的，

這里舉一個簡單的例子，留言板通常的任務就是把用戶
留言的內容展示出來，正常情況下，用戶的留言都是正
常的語言文字，留言板顯示的內容也就沒毛病，然而這
個時候如果有人不按套路出牌，在留言內容中丟進去一
行：

<script> alert("hey!you are attacked") </script>

那么留言板的內容將會變為以下代碼：

XSS的危害有如下幾類：
– 竊取網頁瀏覽中的cookie值
在網頁瀏覽中我們常常涉及到用戶登錄，登錄完畢之后服務端會回傳 一個cookie值，這個cookie值相當于一個令牌，拿著這張令牌就等同 于證明了你是某個用戶，
– 劫持流量實作惡意跳轉
– 竊取網頁瀏覽中的cookie值 – 劫持流量實作惡意跳轉
這個很簡單，就是在網頁中想辦法插入一句像這樣的陳述句：

<script>window.location.href="http://www.baidu.com"; </script>

? XSS的解決方案：
使用轉義解決，將<轉義為&lt; >轉義為&gt;

XSRF跨站請求偽造

? 跨站請求偽造（英語：Cross-site request forgery），
也被稱為 ·one-click attack· 或者 ·session riding·，通常
縮寫為 CSRF 或者 XSRF， 是一種 挾制用戶 在當前已登 錄的 Web應用程式上執行非本意的操作的 攻擊方法，跟
**跨網站腳本（XSS）**相比，XSS 利用的是用戶對指定網 站的信任，CSRF 利用的是網站對用戶網頁瀏覽器的信任，

XSRF跨站請求偽造
例如：
– 假如一家銀行用以運行轉賬操作的URL地址如下：

http://www.examplebank.com/withdraw?
account=zhangsan&amount=1000&for=lisi

– 那么，一個惡意攻擊者可以在另一個網站上放置如下代碼：

<img src="http://www.examplebank.com/withdraw?
account=zhangsan&amount=1000&for=Badman">

如果有賬戶名為Alice的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，
登錄資訊尚未過期，那么她就會損失1000資金，

? XSRF常見解決方案：
– token驗證
– CSRF，關鍵在于在請求中放入黑客所不能偽造的資訊，并
且該資訊不存在于 cookie 之中，可以在 HTTP 請求中以 引數的形式加入一個符合某種規則的 token，并在服務器
端建立一個攔截器來驗證這個 token，如果請求中沒有
token 或者 token 內容不正確，則認為可能是 CSRF 攻擊
而拒絕該請求，

Session劫持

? http協議本身是無狀態的，但是現代站點很多都需要維
持登錄態，也就是維持會話，所以現在大多數站點采用
基于cookie的session管理方式：用戶登陸成功后，設定
一個唯一的cookie標識本次會話，基于這個標識進行用 戶授權，只要請求中帶有這個標識，都認為是登錄態，

? Session劫持的解決方案：
– 解決XSS， – Session、IP雙重認證，
– Token機制，