永無止境：網(wǎng)站的伸縮性架構(gòu)

1. 所謂網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設(shè)計(jì)，僅僅通過改變部署的服務(wù)器數(shù)量就可以擴(kuò)大或者縮小網(wǎng)站的服務(wù)能力。

2. 網(wǎng)站架構(gòu)的伸縮性設(shè)計(jì)：

? ? 1). 不同功能進(jìn)行物理分離實(shí)現(xiàn)伸縮性：通過增加服務(wù)器提高網(wǎng)站處理能力，新增服務(wù)器總是從現(xiàn)有服務(wù)器中分離出部分功能和服務(wù)

? ? ? ? ?縱向分離(分層后分離)：將業(yè)務(wù)處理流程上不同部分分離部署，實(shí)現(xiàn)系統(tǒng)伸縮性。

? ? ? ? ?橫向分離(業(yè)務(wù)分割后分離)：將不同的業(yè)務(wù)模塊分離部署，實(shí)現(xiàn)系統(tǒng)伸縮性。橫向分離的粒度可以非常小，甚至可以一個(gè)關(guān)鍵網(wǎng)頁部署一個(gè)獨(dú)立服務(wù)。

? ? 2). 單一功能通過集群規(guī)模實(shí)現(xiàn)伸縮：使用集群，即將相同服務(wù)部署在多臺(tái)服務(wù)器上構(gòu)成一個(gè)集群整體對(duì)外提供服務(wù)。

? ? ? ? ? 集群伸縮性又可以分為應(yīng)用服務(wù)器集群伸縮性和數(shù)據(jù)服務(wù)集群伸縮性，而數(shù)據(jù)服務(wù)器集群又可分為緩存數(shù)據(jù)服務(wù)器集群和存儲(chǔ)數(shù)據(jù)服務(wù)器集群。

3. 應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)：應(yīng)用服務(wù)器應(yīng)該設(shè)計(jì)成無狀態(tài)的，即應(yīng)用服務(wù)器不存儲(chǔ)請(qǐng)求上下文信息，如果將部署有相同應(yīng)用的服務(wù)器組成一個(gè)集群，每次用戶請(qǐng)求都可以發(fā)送到集群中任意一臺(tái)服務(wù)器上去

? ? 處理，任何一臺(tái)服務(wù)器的處理結(jié)果都是相同的。

? ? 如果HTTP請(qǐng)求分發(fā)裝置可以感知或者可以配置集群的服務(wù)器數(shù)量，可以及時(shí)發(fā)現(xiàn)集群中新上線或下線的服務(wù)器，并能向新上線的服務(wù)器分發(fā)請(qǐng)求，停止向已下線的服務(wù)器分發(fā)請(qǐng)求，那么就實(shí)現(xiàn)了應(yīng)用服務(wù)器集群的伸縮性。

? ? 負(fù)載均衡的幾種方式：

? ? 1). HTTP重定向負(fù)載：簡(jiǎn)單，但需要兩次請(qǐng)求服務(wù)器才能完成一次訪問，性能差。可能會(huì)成為網(wǎng)站訪問的瓶頸，使用不多。

? ? 2). DNS域名解析負(fù)載均衡：這是利用DNS處理域名解析請(qǐng)求的同時(shí)進(jìn)行負(fù)載均衡處理的一種方案。

? ? ? ? ?優(yōu)點(diǎn)：將負(fù)載均衡的工作轉(zhuǎn)交給DNS，同時(shí)許多DNS還支持基于地理位置的域名解析，即會(huì)將域名解析成舉例用戶地理最近的一份服務(wù)器地址。

? ? ? ? ?缺點(diǎn)：可能也會(huì)將域名解析到已經(jīng)下線的服務(wù)器，導(dǎo)致用戶訪問失敗。

? ? ? ? ?事實(shí)上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級(jí)負(fù)載均衡手段，即域名解析得到的一組服務(wù)器并不是實(shí)際提供Web服務(wù)的物理服務(wù)器，而是將同樣提供負(fù)載均衡服務(wù)的內(nèi)部服務(wù)器，

? ? ? ? ?這組內(nèi)部負(fù)載均衡服務(wù)器再次負(fù)載均衡，經(jīng)請(qǐng)求分發(fā)到真正的Web服務(wù)器。

? ? 3). 反向代理負(fù)載均衡：大多數(shù)反向代理同時(shí)提供負(fù)載均衡的功能，管理一組Web服務(wù)器，將請(qǐng)求根據(jù)負(fù)載均衡算法轉(zhuǎn)發(fā)到不同的Web服務(wù)器上。

? ? ? ? ?優(yōu)點(diǎn)：負(fù)載均衡和反向代理服務(wù)器功能集成在一起，部署簡(jiǎn)單。

? ? ? ? ?缺點(diǎn)：反向代理是所有請(qǐng)求和響應(yīng)的中轉(zhuǎn)站，其性能可能會(huì)成為瓶頸。

? ? 4). IP負(fù)載均衡：在網(wǎng)絡(luò)層通過修改請(qǐng)求目標(biāo)地址進(jìn)行負(fù)載均衡。

? ? 5). 數(shù)據(jù)鏈路層負(fù)載均衡：數(shù)據(jù)鏈路層負(fù)載均衡方式是指在通信協(xié)議的數(shù)據(jù)鏈路層修改mac地址進(jìn)行負(fù)載均衡，又稱為三角傳輸模式，直接路由方式。

? ? ? ? ?使用三角傳輸模式的鏈路層負(fù)載均衡是目前大型網(wǎng)站使用最廣泛的一種負(fù)載手段。在Linux平臺(tái)最好的鏈路層負(fù)載均衡開源產(chǎn)品時(shí)LVS(Linux Virtual Server).

4. 一般對(duì)負(fù)載均衡的使用是隨著網(wǎng)站規(guī)模的提升根據(jù)不同的階段來使用不同的技術(shù)。具體的應(yīng)用需求還得具體分析，如果是中小型的Web應(yīng)用，比如日PV小于1000萬，用Nginx就完全可以了；如果機(jī)器不少，可以用DNS輪詢，

? ? LVS所耗費(fèi)的機(jī)器還是比較多的；大型網(wǎng)站或重要的服務(wù)，且服務(wù)器比較多時(shí)，可以考慮用LVS。

? ? 參考：http://www.ha97.com/5646.html

5. 負(fù)載均衡算法：

? ? 負(fù)載均衡服務(wù)器的實(shí)現(xiàn)可以分成兩個(gè)部分：

? ? a. 根據(jù)負(fù)載均衡算法和Web服務(wù)器列表計(jì)算得到集群中的一臺(tái)Web服務(wù)器地址

? ? b. 將請(qǐng)求數(shù)據(jù)發(fā)送到該地址對(duì)應(yīng)的Web服務(wù)器上

? ? 具體的輪詢算法有一下幾種：

? ? a. 輪詢

? ? b. 加權(quán)輪詢：根據(jù)應(yīng)用服務(wù)器硬件性能的情況，在輪詢的基礎(chǔ)上，按照配置的權(quán)重將請(qǐng)求分發(fā)到每個(gè)服務(wù)器，高性能的服務(wù)器能分配更多的請(qǐng)求。

? ? c. 隨機(jī)：請(qǐng)求被隨機(jī)分配到各個(gè)應(yīng)用服務(wù)器，在許多場(chǎng)合下，這種方案都很簡(jiǎn)單實(shí)用，因?yàn)楹玫碾S機(jī)數(shù)本身就很均衡。即使應(yīng)用服務(wù)器硬件配置不同，也可以使用加權(quán)隨機(jī)算法。

? ? d. 最少連接：記錄每個(gè)應(yīng)用服務(wù)器長(zhǎng)在處理的連接數(shù)(請(qǐng)求數(shù))，將新到的請(qǐng)求分發(fā)到最少連接的服務(wù)器上，應(yīng)該說，這是最符合負(fù)載均衡定義的算法。同樣，最少連接算法也可以實(shí)現(xiàn)加權(quán)最少連接。

? ? e. 源地址散列：根據(jù)請(qǐng)求來源的IP地址進(jìn)行Hash計(jì)算，得到應(yīng)用服務(wù)器，這樣來自同一個(gè)IP地址的請(qǐng)求總是在同一個(gè)服務(wù)器地址上，該請(qǐng)求的上下文信息可以存儲(chǔ)在這臺(tái)服務(wù)器上，在一個(gè)會(huì)話周期內(nèi)重復(fù)使用，從而實(shí)現(xiàn)會(huì)話粘滯。

6. 分布式緩存集群的伸縮性設(shè)計(jì)

7. 數(shù)據(jù)存儲(chǔ)服務(wù)器集群的伸縮性設(shè)計(jì) ?

? ? 1). 關(guān)系型數(shù)據(jù)庫集群的伸縮性設(shè)計(jì)：

? ? ? ? ?a. 主從讀寫分離

? ? ? ? ?b. 數(shù)據(jù)分庫，這種方式的制約條件時(shí)跨庫表不能進(jìn)行Join操作

? ? ? ? ?在大型網(wǎng)站的實(shí)際應(yīng)用中，即使進(jìn)行了分庫和主從復(fù)制，對(duì)一些單表數(shù)據(jù)仍然很大的表，還需要進(jìn)行分片，將一張表拆開分別存儲(chǔ)在多個(gè)數(shù)據(jù)庫中。目前網(wǎng)站在線業(yè)務(wù)應(yīng)用中比較成熟的支持?jǐn)?shù)據(jù)分片的

? ? ? ? ?分布式關(guān)系數(shù)據(jù)庫產(chǎn)品主要有開源的的Amoeba和Cobar。這兩個(gè)產(chǎn)品有相似的架構(gòu)：

? ? ? ? ?Cobar是一個(gè)分布式關(guān)系數(shù)據(jù)庫訪問代理，介于應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器之間。應(yīng)用程序通過JDBC驅(qū)動(dòng)訪問Cobar集群，Cobar服務(wù)器根據(jù)SQL和分庫規(guī)則分解SQL，分發(fā)到MYSQL集群不同的數(shù)據(jù)庫實(shí)例上執(zhí)行(每

? ? ? ? ?個(gè)MySQL實(shí)例都部署為主從結(jié)構(gòu)，保證數(shù)據(jù)高可用)，執(zhí)行完將結(jié)果返回至SQL執(zhí)行模塊，通過結(jié)果合并模塊將兩個(gè)返回值合并成一個(gè)結(jié)果集，最終返回給應(yīng)用程序，完成分布式數(shù)據(jù)庫的一次訪問。

? ? ? ? ?select * from users where userid in (12,22,23) ?可以被拆分為：select * from users where userid in (12,22) 和 ?select * from users where userid in (23) ? ? ? ? ? ? ?

? ? ? ? ?那么Cobar如何做集群的伸縮性呢？

? ? ? ? ?Cobar的伸縮有兩種：Cobar服務(wù)集群的伸縮和MySQL服務(wù)集群的伸縮。

? ? ? ? ?Cobar服務(wù)器可以看作是無狀態(tài)的應(yīng)用服務(wù)器，因此其集群伸縮可以簡(jiǎn)單實(shí)用負(fù)載均衡的手段實(shí)現(xiàn)。而MySQL中存儲(chǔ)著數(shù)據(jù)，要想保證集群擴(kuò)容后數(shù)據(jù)一致負(fù)載均衡，必須做數(shù)據(jù)遷移，將集群中原來機(jī)器中的

? ? ? ? ?數(shù)據(jù)遷移到新添加的機(jī)器中。實(shí)踐中，Cobar利用了MySQL的數(shù)據(jù)同步功能進(jìn)行數(shù)據(jù)遷移，數(shù)據(jù)同步不是以數(shù)據(jù)為單位，而是以Schema為單位。

? ? 2). NoSQL數(shù)據(jù)庫的伸縮性設(shè)計(jì)：NoSQL，主要指非關(guān)系的、分布式的數(shù)據(jù)庫設(shè)計(jì)模式。也有許多專家將NoSQL解讀為Not Only SQL ,表示NoSQL這是關(guān)系數(shù)據(jù)庫的補(bǔ)充，而不是替代方案。一般而言，NoSQL數(shù)據(jù)庫

? ? ? ? ? 都放棄了關(guān)系數(shù)據(jù)庫的兩大重要基礎(chǔ)：以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語言(SQL)和事務(wù)一致性保證(ACID)。而強(qiáng)化其他一些大型網(wǎng)站更關(guān)注的特性：高可用性和可伸縮性。

?

?

隨需應(yīng)變：網(wǎng)站的可擴(kuò)展性架構(gòu)

擴(kuò)展性(Extensibility)：指對(duì)現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能可持續(xù)擴(kuò)展或提升的能力

伸縮性(Scalability)：指系統(tǒng)通過增加(減少)自身資源規(guī)模的方式強(qiáng)化(減少)自己計(jì)算處理事務(wù)的能力。

1. 構(gòu)架可擴(kuò)展的網(wǎng)站架構(gòu)：開發(fā)低耦合系統(tǒng)是軟件設(shè)計(jì)的終極目標(biāo)之一。

? ? 軟件架構(gòu)師最大的價(jià)值不在于掌握多少先進(jìn)的技術(shù)，而在于將具有將一個(gè)大系統(tǒng)分成N個(gè)耦合的子模塊的能力，這些子模塊包含橫向的業(yè)務(wù)模塊，也包括縱向的基礎(chǔ)技術(shù)模塊。

? ? 設(shè)計(jì)網(wǎng)站可擴(kuò)展架構(gòu)的核心思想是模塊化，并在此基礎(chǔ)上，降低模塊間的耦合性，提高模塊的復(fù)用性。分層和分割也是模塊化設(shè)計(jì)的重要手段，利用分層和分割的方式將軟件分割為若干個(gè)低耦合的獨(dú)立的組件

? ? 模塊，這些組件模塊以消息傳遞及依賴調(diào)用的方式聚合成一個(gè)完整系統(tǒng)。

? ? 模塊分布式部署以后具體聚合方式主要有分布式消息隊(duì)列和分布式服務(wù)。

2. 利用分布式消息隊(duì)列降低系統(tǒng)耦合性

? ? 1). 事件驅(qū)動(dòng)架構(gòu)：通過在低耦合的模塊之間傳輸事件消息，以保持模塊的松散耦合，并借助事件消息的通信完成模塊間的合作。消息發(fā)布-訂閱的模式。

? ? 2). 分布式消息隊(duì)列：隊(duì)列是一種先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)，分布式消息隊(duì)列可以看作將這種數(shù)據(jù)結(jié)構(gòu)部署到獨(dú)立的服務(wù)器上，應(yīng)用程序可以通過遠(yuǎn)程訪問接口使用分布式消息隊(duì)列，進(jìn)行消息存儲(chǔ)操作，進(jìn)而實(shí)現(xiàn)分布式異步調(diào)用。

? ? ? ? ?開源的分布式消息隊(duì)列有很多，比較有名的是ActiveMQ等。伸縮性(分布式)，可用性(如果隊(duì)列已滿，會(huì)將消息寫入磁盤，消息推送模塊在將內(nèi)存隊(duì)列消息處理完成以后，將磁盤內(nèi)容添加到內(nèi)存隊(duì)列繼續(xù)處理)

? ? ? ? ?為了避免消息隊(duì)列宕機(jī)造成消息丟失，會(huì)將消息成功發(fā)送到消息隊(duì)列的消息存儲(chǔ)在消息生產(chǎn)者服務(wù)器，等消息真正被消息消費(fèi)者服務(wù)器處理后才刪除消息。在消息隊(duì)列服務(wù)器宕機(jī)后，生產(chǎn)者服務(wù)器會(huì)選擇分布式消息隊(duì)列

? ? ? ? ?服務(wù)器集群中的其他的服務(wù)器發(fā)布消息。

3. 利用分布式服務(wù)打造可復(fù)用的業(yè)務(wù)平臺(tái)：如果說分布式消息隊(duì)列通過消息對(duì)象分解系統(tǒng)耦合性，不同子系統(tǒng)處理同一個(gè)消息；那么分布式服務(wù)則通過接口分解系統(tǒng)耦合性，不同子系統(tǒng)通過相同的接口描述進(jìn)行服務(wù)調(diào)用。

? ? 1). Web Service與企業(yè)級(jí)分布式服務(wù)：服務(wù)提供者通過WSDL向注冊(cè)中心描述自身提供的服務(wù)接口屬性，注冊(cè)中心使用UDDI發(fā)布服務(wù)提供者提供的服務(wù)，服務(wù)請(qǐng)求者從注冊(cè)中心檢索到服務(wù)信息后，通過SOAP和服務(wù)

? ? ? ? ?通信使用相關(guān)業(yè)務(wù)。

? ? ? ? ?缺點(diǎn)：臃腫的注冊(cè)和發(fā)現(xiàn)機(jī)制，低效的XML序列化手段，開銷相對(duì)較高的HTTP遠(yuǎn)程通信，復(fù)雜的部署與維護(hù)手段

? ? 2). 大型網(wǎng)站分布式服務(wù)的需求與特定：

? ? ? ? ?對(duì)于大型網(wǎng)站，除了Web Service所提供的服務(wù)器注冊(cè)與發(fā)現(xiàn)，服務(wù)調(diào)用等標(biāo)準(zhǔn)功能，還需分布式服務(wù)框架能夠支持如下功能：

? ? ? ? ?a. 負(fù)載均衡

? ? ? ? ?b. 失效轉(zhuǎn)移

? ? ? ? ?c. 高效的遠(yuǎn)程通信

? ? ? ? ?d. 整合異構(gòu)系統(tǒng)：不同語言的系統(tǒng)

? ? ? ? ?e. 對(duì)應(yīng)用侵入最少

? ? ? ? ?f. 版本控制：分布式框架需要支持服務(wù)多版本發(fā)布，服務(wù)提供者先升級(jí)接口發(fā)布新版本的服務(wù)，并同時(shí)提供舊版本的服務(wù)供請(qǐng)求者調(diào)用，當(dāng)請(qǐng)求者調(diào)用接口升級(jí)后才可以關(guān)閉舊版本服務(wù)。

? ? ? ? ?g. 實(shí)時(shí)監(jiān)控

? ? 3). 分布式服務(wù)框架設(shè)計(jì)：

? ? ? ? ?以阿里巴巴分布式開源框架Dubbo為例，分析其架構(gòu)設(shè)計(jì)：

? ? ? ? ?服務(wù)消費(fèi)者程序通過服務(wù)接口使用服務(wù)，而服務(wù)接口通過代理加載具體服務(wù)，具體服務(wù)可以是本地的代碼模塊，也可以是遠(yuǎn)程服務(wù)，因此對(duì)應(yīng)用較少侵入：應(yīng)用程序只需要調(diào)用服務(wù)接口，服務(wù)框架根據(jù)

? ? ? ? ?配置自動(dòng)調(diào)用本地或遠(yuǎn)程實(shí)現(xiàn)。

? ? ? ? ?服務(wù)架構(gòu)客戶端模塊通過服務(wù)注冊(cè)中心加載服務(wù)提供者列表(服務(wù)提供者啟動(dòng)后自動(dòng)向服務(wù)注冊(cè)中心注冊(cè)自己可提供的服務(wù)接口列表)，查找需要的服務(wù)接口，并根據(jù)配置的負(fù)載均衡策略將服務(wù)請(qǐng)求發(fā)送

? ? ? ? ?到某臺(tái)服務(wù)提供者服務(wù)器。如果服務(wù)調(diào)用失敗，客戶端模塊會(huì)自動(dòng)從服務(wù)提供者列表選擇一個(gè)可提供同樣服務(wù)的另一臺(tái)服務(wù)器重新請(qǐng)求服務(wù)，實(shí)現(xiàn)服務(wù)的自動(dòng)失效轉(zhuǎn)移，保證服務(wù)高可用性。

? ? ? ? ?Dubbo的遠(yuǎn)程服務(wù)通信模塊支持多種通信協(xié)議和數(shù)據(jù)序列化協(xié)議，使用NIO通信框架，具有較高的網(wǎng)絡(luò)通信性能。

4. 可擴(kuò)展的數(shù)據(jù)結(jié)構(gòu)：mongoDB ？

5. 利用開放平臺(tái)建設(shè)網(wǎng)站生態(tài)圈：

? ? 大型網(wǎng)站為了更好地服務(wù)自己的用戶，開發(fā)更多的增值業(yè)務(wù)，會(huì)把網(wǎng)站內(nèi)部的服務(wù)封裝成一些調(diào)用接口開放出去，供外部的第三方開發(fā)者使用，這個(gè)提供開放接口的平臺(tái)被稱為開放平臺(tái)。第三方開發(fā)者利用

? ? 這個(gè)開放的接口開發(fā)應(yīng)用程序或網(wǎng)站，為更多的用戶提供價(jià)值。網(wǎng)站、用戶、第三方開發(fā)者互相依賴，形成一個(gè)網(wǎng)站的生態(tài)圈。

? ? 開放平臺(tái)的架構(gòu)設(shè)計(jì)：API接口，協(xié)議轉(zhuǎn)換，安全，審計(jì)，路由，流程

?

?

固若金湯：網(wǎng)站的安全架構(gòu)

1. 道高一尺魔高一丈的網(wǎng)站應(yīng)用攻擊與防御

? ? 1). XSS攻擊：XSS攻擊即跨站點(diǎn)腳本攻擊(Cross Site Script)，指黑客通過篡改網(wǎng)頁，注入惡意HTML腳本，在用戶瀏覽網(wǎng)頁時(shí)，控制用戶瀏覽器惡意操作的一種攻擊方式。

? ? ? ? ?常見的XSS攻擊類型有兩種：

? ? ? ? ?a. 反射型：攻擊者誘使用戶點(diǎn)擊一個(gè)嵌入惡意腳本的鏈接，達(dá)到攻擊的目的。

? ? ? ? ?b. 持久性XSS攻擊：黑客提交含有惡意腳本的請(qǐng)求，保存在被攻擊的Web站點(diǎn)的數(shù)據(jù)庫中，用戶瀏覽網(wǎng)頁時(shí)，惡意腳本被包含在正常頁面，達(dá)到攻擊的目的。此攻擊經(jīng)常使用在論壇，博客等Web應(yīng)用中。

? ? ? ? ?防止XSS攻擊的手段主要有如下兩種：

? ? ? ? ?a. 消毒：XSS攻擊者一般都是通過在請(qǐng)求中嵌入惡意腳本達(dá)到攻擊的目的，這些腳本是一般用戶不使用的，如果進(jìn)行過濾和消毒處理，即對(duì)某些html危險(xiǎn)字符轉(zhuǎn)義，如">"轉(zhuǎn)義為"&gt"等，就可以防止大部分攻擊。

? ? ? ? ? ? ? ? ? ? ?為了避免對(duì)不必要的內(nèi)容錯(cuò)誤轉(zhuǎn)義，如"3<5"中的"<"需要進(jìn)行文本匹配后的轉(zhuǎn)義，如"<img src"這樣的上下問中的"<"才轉(zhuǎn)義。事實(shí)上消毒幾乎是所有網(wǎng)站必備的XSS防攻擊手段。

? ? ? ? ?b. HttpOnly：即瀏覽器禁止頁面JS訪問帶有HttpOnly屬性的Cookie。HttpOnly并不是直接對(duì)抗XSS攻擊的，而是通過防止XSS攻擊者竊取Cookie。對(duì)于敏感信息的Cookie，如用戶認(rèn)證信息等。可以通過對(duì)該

? ? ? ? ? ? ?Cookie添加HttpOnly屬性，避免被攻擊腳本竊取。

? ? 2). 注入攻擊：

? ? ? ? ?SQL注入需要攻擊者對(duì)表結(jié)構(gòu)有所了解，獲取表結(jié)構(gòu)的方法有一下集中：開源(開源網(wǎng)站搭建，別人也可能知道代碼)，錯(cuò)誤回顯(根據(jù)錯(cuò)誤信息，猜到代碼結(jié)構(gòu))，盲注(根據(jù)頁面變化，猜測(cè)SQL結(jié)構(gòu)，難度較大)

? ? ? ? ?防SQK注入攻擊：消毒(通過正則表達(dá)式匹配，過濾請(qǐng)求數(shù)據(jù)中可能注入的SQL)，參數(shù)綁定(使用預(yù)編譯手段，綁定參數(shù)是最好的防SQL注入方法)

? ? 3). CSRF攻擊：

? ? ? ? ?CSRF(Cross Site Request Forgery，跨站點(diǎn)請(qǐng)求偽造)，攻擊者通過跨站點(diǎn)請(qǐng)求，以合法用戶身份進(jìn)行非法操作，如轉(zhuǎn)賬交易、發(fā)表評(píng)論等。CSRF的主要手法是利用跨站點(diǎn)其請(qǐng)求，在用戶不知情的情況下，

? ? ? ? ?以用戶身份偽造請(qǐng)求。其核心是利用了瀏覽器的Cookie或服務(wù)器Session策略，盜取用戶身份。

? ? ? ? ?相應(yīng)的，CSRF的防御手段主要是識(shí)別請(qǐng)求者身份。主要有一下幾種方法：

? ? ? ? ?表單Token，驗(yàn)證碼(用戶體驗(yàn)較差)，Referer check(HTTP請(qǐng)求頭的Referer域記錄著請(qǐng)求來源，可通過檢查請(qǐng)求來源驗(yàn)證其是否合法。如防圖片盜用)

? ? 4). 其他攻擊和漏洞

? ? ? ? ?a. Error Code：錯(cuò)誤回顯。防御手段也很簡(jiǎn)單：通過配置Web服務(wù)器參數(shù)，跳轉(zhuǎn)500頁面(HTTP響應(yīng)碼500表示服務(wù)器內(nèi)部錯(cuò)誤)到專門錯(cuò)誤頁面即可，Web引用常用的MVC框架也有這功能。

? ? ? ? ?b. HMTL注釋

? ? ? ? ?c. 文件上傳：控制文件上傳類型

? ? ? ? ?d. 路徑遍歷：攻擊者在請(qǐng)求的URL中使用相對(duì)路徑，遍歷系統(tǒng)未開放地目錄和文件。防御方法主要是將JS、CSS等資源文件部署在獨(dú)立服務(wù)器、使用獨(dú)立域名，其他文件不使用靜態(tài)URL訪問，動(dòng)態(tài)參數(shù)不包含文件路徑信息。

? ? 5). Web應(yīng)用防火墻：

? ? ? ? ?ModSecurity是一個(gè)開源的Web應(yīng)用防火墻，探測(cè)攻擊并保護(hù)Web應(yīng)用程序，既可以嵌入到Web應(yīng)用服務(wù)器中，也可以作為一個(gè)獨(dú)立的應(yīng)用程序啟動(dòng)。ModSecurity最早只是Apache的一個(gè)模塊，現(xiàn)在應(yīng)有Java等多個(gè)版本，

? ? ? ? ?并且支持Nginx。

? ? 6). 網(wǎng)站安全漏洞掃描

2. 信息加密技術(shù)及密匙安全管理

? ? 1). 單向散列加密：將加密后的內(nèi)容保存到數(shù)據(jù)庫。用戶使用時(shí)，拿用戶的輸入信息加密后比較是否相同。常用算法:MD5,SHA等。

? ? 2). 對(duì)稱加密：指加密和解密使用的密匙是同一個(gè)密匙。 ? 優(yōu)點(diǎn)：算法簡(jiǎn)單，加密效率高，系統(tǒng)開銷小，適合對(duì)大量數(shù)據(jù)加密。 ? ? 缺點(diǎn)：遠(yuǎn)程通信的情況下如何安全交換密匙是一個(gè)難題，如果密匙丟失，會(huì)導(dǎo)致信息泄露。

? ? ? ? ? ? ? ? ? ? ? ? 常用算法：DES算法，RC算法等。

? ? 3). 非對(duì)稱加密：對(duì)外界公開的，被稱為公鑰，另一個(gè)只有所有者知道，被稱為私匙。用公鑰加密的信息必須用私匙才能解開，用私匙加密的信息只有公鑰才能解開。

? ? 4). 密匙的安全管理：

? ? ? ? ?a. 把密匙和算法放在一個(gè)獨(dú)立的服務(wù)器上，甚至做成一個(gè)專用的硬件設(shè)施，對(duì)外提供加密和解密服務(wù)，應(yīng)用系統(tǒng)調(diào)用這個(gè)服務(wù)，實(shí)現(xiàn)數(shù)據(jù)的加密。

? ? ? ? ?b. 將加密算法放到應(yīng)用系統(tǒng)中，密匙放到獨(dú)立服務(wù)器中，為了提高密匙的安全性，實(shí)際存儲(chǔ)事，密匙被切分成數(shù)片，加密后分別保存在不同的存儲(chǔ)介質(zhì)中，兼顧安全性的同時(shí)又改善了性能。

3. 信息過濾與反垃圾：

? ? 1). 文本匹配：Trie算法，構(gòu)造多級(jí)hash表進(jìn)行文本匹配。

? ? 2). 分類算法：

? ? 3). 黑名單

4. 電子商務(wù)風(fēng)險(xiǎn)控制：

? ? 1). 風(fēng)險(xiǎn)：

? ? ? ? ?a. 賬戶風(fēng)險(xiǎn)：包括賬戶被盜用，惡意注冊(cè)賬戶等

? ? ? ? ?b. 買家風(fēng)險(xiǎn)：惡意下單，黃牛利用促銷搶購(gòu)，良品拒收等

? ? ? ? ?c. 賣家風(fēng)險(xiǎn)：欺詐行為，虛假發(fā)貨等

? ? ? ? ?d. 交易風(fēng)險(xiǎn)：信用卡盜刷，支付欺詐，洗錢套現(xiàn)等

? ? 2). 風(fēng)控：

? ? ? ? ?a. 規(guī)則引擎：當(dāng)交易的某些指標(biāo)滿足一定條件時(shí)，就會(huì)被認(rèn)為具有高風(fēng)險(xiǎn)的欺詐可能性。

? ? ? ? ?b. 統(tǒng)計(jì)模型：智能統(tǒng)計(jì)，得到交易風(fēng)險(xiǎn)分值。? ? ??

?

轉(zhuǎn)載于:https://www.cnblogs.com/Jtianlin/p/5136340.html

總結(jié)

以上是生活随笔為你收集整理的大型网站技术架构03的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。