服務(wù)器流量攻擊怎么防御?服務(wù)器是為網(wǎng)絡(luò)提供計(jì)算服務(wù)的設(shè)備，∞在企業(yè)網(wǎng)站中起著重要的作用。所以平時(shí)一定要注重對(duì)服務(wù)器安全問題。如何防范服務(wù)器被攻擊呢?
成都創(chuàng)新互聯(lián)是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營(yíng)銷，專業(yè)領(lǐng)域包括成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、電商網(wǎng)站制作開發(fā)、微信小程序開發(fā)、微信營(yíng)銷、系統(tǒng)平臺(tái)開發(fā)，與其他網(wǎng)站設(shè)計(jì)及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗(yàn)和互聯(lián)網(wǎng)整合營(yíng)銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評(píng)估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！
服務(wù)器被攻擊的常見方式有兩種：一種是CC，一種是ddos。如果是CC攻擊方式，機(jī)房技術(shù)會(huì)根據(jù)攻擊的類型及時(shí)調(diào)整策略，CDN的服務(wù)在策略上可以先過一層，有效針對(duì)CC攻擊。
如果是DDOS，必須要機(jī)房有硬防才可以防御，這個(gè)必須需要帶寬充足才可以解決的，同時(shí)CDN進(jìn)行分流和清洗等。對(duì)于服務(wù)器被攻擊并不是不可防范的，用戶在使用服務(wù)器之前，銳速云可以通過一些簡(jiǎn)單的措施來提升服務(wù)器的安全。
1、服務(wù)器租用一定要把a(bǔ)dministrator禁用;禁止響應(yīng)ICMP路由通告報(bào)文;禁用服務(wù)里的Workstation。
2、主機(jī)租用系統(tǒng)升級(jí)、打操作系統(tǒng)補(bǔ)丁，尤其是IIS6.0補(bǔ)丁、SQL SP3a補(bǔ)丁，甚至IE6.0補(bǔ)丁也要打，同時(shí)及時(shí)跟蹤最新漏洞補(bǔ)丁。
3、啟動(dòng)系統(tǒng)自帶的Internet連接防火墻，在設(shè)置服務(wù)選項(xiàng)中勾選Web服務(wù)器;阻止IUSR用戶提升權(quán)限;防止SQL注入。
做好服務(wù)器的ddos防御措施，以防為主被攻擊還是很有必要的。若是黑客或者競(jìng)爭(zhēng)對(duì)手要一直盯著你的服務(wù)器或者網(wǎng)站，經(jīng)常性的進(jìn)行一些攻擊，那也是一件很要命的事情。
酷酷云服務(wù)器為您誠(chéng)意解答，服務(wù)器租戶的選擇，酷酷云值得信賴。
服務(wù)器安全一般都是采用軟件輔助+手工服務(wù)的安全設(shè)置，有錢人都是買好幾W的硬件來做服務(wù)器安全。但是對(duì)于我一個(gè)小小的站長(zhǎng)，哪能承受的了。一年的服務(wù)器托管才5000多，建議你找專業(yè)做服務(wù)器安全的公司或者團(tuán)隊(duì)，來給你做服務(wù)器安全維護(hù)。
安全這問題，很重要，我上次就是為了省錢，在網(wǎng)上搜索了一些服務(wù)器安全設(shè)置的文章，對(duì)著文章，我一個(gè)一個(gè)的設(shè)置起來，費(fèi)了好幾天的時(shí)間才設(shè)置完，沒想到，服務(wù)器竟然癱瘓了，網(wǎng)站都打不開了，也最終明白了，免費(fèi)的東西，也是最貴的，損失真的很大，數(shù)據(jù)庫(kù)都給我回檔了，我哪個(gè)后悔啊。娘個(gè)咪的。最后還是讓機(jī)房把系統(tǒng)重裝了，然后找的sine安全公司給做的網(wǎng)站服務(wù)器安全維護(hù)。跟他們還簽了合同，真的是一份價(jià)格一份服務(wù)，專業(yè)的服務(wù) 安全非常穩(wěn)定。也只有網(wǎng)站安全了，才能帶來安全穩(wěn)定的客戶源。道理也是經(jīng)歷了才明白。說了這么多經(jīng)歷，希望能幫到更多和我一樣的網(wǎng)站站長(zhǎng)。
下面是關(guān)于安全方面的解決辦法！
建站一段時(shí)間后總能聽得到什么什么網(wǎng)站被掛馬，什么網(wǎng)站被黑。好像入侵掛馬似乎是件很簡(jiǎn)單的事情。其實(shí)，入侵不簡(jiǎn)單，簡(jiǎn)單的是你的網(wǎng)站的必要安全措施并未做好。
有條件建議找專業(yè)做網(wǎng)站安全的sine安全來做安全維護(hù)。
一：掛馬預(yù)防措施：
1、建議用戶通過ftp來上傳、維護(hù)網(wǎng)頁(yè)，盡量不安裝asp的上傳程序。
2、定期對(duì)網(wǎng)站進(jìn)行安全的檢測(cè)，具體可以利用網(wǎng)上一些工具，如sinesafe網(wǎng)站掛馬檢測(cè)工具！
3、asp程序管理員的用戶名和密碼要有一定復(fù)雜性，不能過于簡(jiǎn)單，還要注意定期更換。
4、到正規(guī)網(wǎng)站下載asp程序，下載后要對(duì)其數(shù)據(jù)庫(kù)名稱和存放路徑進(jìn)行修改，數(shù)據(jù)庫(kù)文件名稱也要有一定復(fù)雜性。
5、要盡量保持程序是最新版本。
6、不要在網(wǎng)頁(yè)上加注后臺(tái)管理程序登陸頁(yè)面的鏈接。
7、為防止程序有未知漏洞，可以在維護(hù)后刪除后臺(tái)管理程序的登陸頁(yè)面，下次維護(hù)時(shí)再通過ftp上傳即可。
8、要時(shí)常備份數(shù)據(jù)庫(kù)等重要文件。
9、日常要多維護(hù)，并注意空間中是否有來歷不明的asp文件。記?。阂环趾顾?，換一分安全!
10、一旦發(fā)現(xiàn)被入侵，除非自己能識(shí)別出所有木馬文件，否則要?jiǎng)h除所有文件。
11、對(duì)asp上傳程序的調(diào)用一定要進(jìn)行身份認(rèn)證，并只允許信任的人使用上傳程序。這其中包括各種新聞發(fā)布、商城及論壇。
二：掛馬恢復(fù)措施：
1.修改帳號(hào)密碼
不管是商業(yè)或不是，初始密碼多半都是admin。因此你接到網(wǎng)站程序第一件事情就是“修改帳號(hào)密碼”。
帳號(hào)密碼就不要在使用以前你習(xí)慣的，換點(diǎn)特別的。盡量將字母數(shù)字及符號(hào)一起。此外密碼最好超過15位。尚若你使用SQL的話應(yīng)該使用特別點(diǎn)的帳號(hào)密碼，不要在使用什么什么admin之類，否則很容易被入侵。
2.創(chuàng)建一個(gè)robots.txt
Robots能夠有效的防范利用搜索引擎竊取信息的駭客。
3.修改后臺(tái)文件
第一步：修改后臺(tái)里的驗(yàn)證文件的名稱。
第二步：修改conn.asp，防止非法下載，也可對(duì)數(shù)據(jù)庫(kù)加密后在修改conn.asp。
第三步：修改ACESS數(shù)據(jù)庫(kù)名稱，越復(fù)雜越好，可以的話將數(shù)據(jù)所在目錄的換一下。
4.限制登陸后臺(tái)IP
此方法是最有效的，每位虛擬主機(jī)用戶應(yīng)該都有個(gè)功能。你的IP不固定的話就麻煩點(diǎn)每次改一下咯，安全第一嘛。
5.自定義404頁(yè)面及自定義傳送ASP錯(cuò)誤信息
404能夠讓駭客批量查找你的后臺(tái)一些重要文件及檢查網(wǎng)頁(yè)是否存在注入漏洞。
ASP錯(cuò)誤嘛，可能會(huì)向不明來意者傳送對(duì)方想要的信息。
6.慎重選擇網(wǎng)站程序
注意一下網(wǎng)站程序是否本身存在漏洞，好壞你我心里該有把秤。
7.謹(jǐn)慎上傳漏洞
據(jù)悉，上傳漏洞往往是最簡(jiǎn)單也是最嚴(yán)重的，能夠讓黑客或駭客們輕松控制你的網(wǎng)站。
可以禁止上傳或著限制上傳的文件類型。不懂的話可以找專業(yè)做網(wǎng)站安全的sinesafe公司。
8. cookie 保護(hù)
登陸時(shí)盡量不要去訪問其他站點(diǎn)，以防止 cookie 泄密。切記退出時(shí)要點(diǎn)退出在關(guān)閉所有瀏覽器。
9.目錄權(quán)限
請(qǐng)管理員設(shè)置好一些重要的目錄權(quán)限，防止非正常的訪問。如不要給上傳目錄執(zhí)行腳本權(quán)限及不要給非上傳目錄給于寫入權(quán)。
10.自我測(cè)試
如今在網(wǎng)上黑客工具一籮筐，不防找一些來測(cè)試下你的網(wǎng)站是否OK。
11.例行維護(hù)
a.定期備份數(shù)據(jù)。最好每日備份一次，下載了備份文件后應(yīng)該及時(shí)刪除主機(jī)上的備份文件。
b.定期更改數(shù)據(jù)庫(kù)的名字及管理員帳密。
c.借WEB或FTP管理，查看所有目錄體積，最后修改時(shí)間以及文件數(shù)，檢查是文件是否有異常，以及查看是否有異常的賬號(hào)。
網(wǎng)站被掛馬一般都是網(wǎng)站程序存在漏洞或者服務(wù)器安全性能不達(dá)標(biāo)被不法黑客入侵攻擊而掛馬的。
網(wǎng)站被掛馬是普遍存在現(xiàn)象然而也是每一個(gè)網(wǎng)站運(yùn)營(yíng)者的心腹之患。
您是否因?yàn)榫W(wǎng)站和服務(wù)器天天被入侵掛馬等問題也曾有過想放棄的想法呢，您否也因?yàn)椴惶私饩W(wǎng)站技術(shù)的問題而耽誤了網(wǎng)站的運(yùn)營(yíng)，您是否也因?yàn)榫倪\(yùn)營(yíng)的網(wǎng)站反反復(fù)復(fù)被一些無聊的黑客入侵掛馬感到徬彷且很無耐。有條件建議找專業(yè)做網(wǎng)站安全的sine安全來做安全維護(hù)。
維基百科關(guān)于 HTTP/2 的介紹，可以看下定義和發(fā)展歷史:
Wiki
RFC 7540 定義了 HTTP/2 的協(xié)議規(guī)范和細(xì)節(jié)，本文的細(xì)節(jié)主要來自此文檔，建議先看一遍本文，再回過頭來照著協(xié)議大致過一遍 RFC，如果想深入某些細(xì)節(jié)再仔細(xì)翻看 RFC
RFC7540
1、 TCP 連接數(shù)限制
對(duì)于同一個(gè)域名，瀏覽器最多只能同時(shí)創(chuàng)建 6~8 個(gè) TCP 連接 (不同瀏覽器不一樣)。為了解決數(shù)量限制，出現(xiàn)了 域名分片 技術(shù)，其實(shí)就是資源分域，將資源放在不同域名下 (比如二級(jí)子域名下)，這樣就可以針對(duì)不同域名創(chuàng)建連接并請(qǐng)求，以一種討巧的方式突破限制，但是濫用此技術(shù)也會(huì)造成很多問題，比如每個(gè) TCP 連接本身需要經(jīng)過 DNS 查詢、三步握手、慢啟動(dòng)等，還占用額外的 CPU 和內(nèi)存，對(duì)于服務(wù)器來說過多連接也容易造成網(wǎng)絡(luò)擁擠、交通阻塞等，對(duì)于移動(dòng)端來說問題更明顯，可以參考這篇文章: Why Domain Sharding is Bad News for Mobile Performance and Users
在圖中可以看到新建了六個(gè) TCP 連接，每次新建連接 DNS 解析需要時(shí)間(幾 ms 到幾百 ms 不等)、TCP 慢啟動(dòng)也需要時(shí)間、TLS 握手又要時(shí)間，而且后續(xù)請(qǐng)求都要等待隊(duì)列調(diào)度
2、 線頭阻塞 (Head Of Line Blocking) 問題
每個(gè) TCP 連接同時(shí)只能處理一個(gè)請(qǐng)求 - 響應(yīng)，瀏覽器按 FIFO 原則處理請(qǐng)求，如果上一個(gè)響應(yīng)沒返回，后續(xù)請(qǐng)求 - 響應(yīng)都會(huì)受阻。為了解決此問題，出現(xiàn)了 管線化 - pipelining 技術(shù)，但是管線化存在諸多問題，比如第一個(gè)響應(yīng)慢還是會(huì)阻塞后續(xù)響應(yīng)、服務(wù)器為了按序返回相應(yīng)需要緩存多個(gè)響應(yīng)占用更多資源、瀏覽器中途斷連重試服務(wù)器可能得重新處理多個(gè)請(qǐng)求、還有必須客戶端 - 代理 - 服務(wù)器都支持管線化
3、Header 內(nèi)容多，而且每次請(qǐng)求 Header 不會(huì)變化太多，沒有相應(yīng)的壓縮傳輸優(yōu)化方案
4、為了盡可能減少請(qǐng)求數(shù)，需要做合并文件、雪碧圖、資源內(nèi)聯(lián)等優(yōu)化工作，但是這無疑造成了單個(gè)請(qǐng)求內(nèi)容變大延遲變高的問題，且內(nèi)嵌的資源不能有效地使用緩存機(jī)制
5、明文傳輸不安全
幀是數(shù)據(jù)傳輸?shù)淖钚挝?，以二進(jìn)制傳輸代替原本的明文傳輸，原本的報(bào)文消息被劃分為更小的數(shù)據(jù)幀:
h1 和 h2 的報(bào)文對(duì)比:
圖中 h2 的報(bào)文是重組解析過后的，可以發(fā)現(xiàn)一些頭字段發(fā)生了變化，而且所有頭字段均小寫
關(guān)于幀詳見: How does it work ？- 幀
在一個(gè) TCP 連接上，我們可以向?qū)Ψ讲粩喟l(fā)送幀，每幀的 stream identifier 的標(biāo)明這一幀屬于哪個(gè)流，然后在對(duì)方接收時(shí)，根據(jù) stream identifier 拼接每個(gè)流的所有幀組成一整塊數(shù)據(jù)。
把 HTTP/1.1 每個(gè)請(qǐng)求都當(dāng)作一個(gè)流，那么多個(gè)請(qǐng)求變成多個(gè)流，請(qǐng)求響應(yīng)數(shù)據(jù)分成多個(gè)幀，不同流中的幀交錯(cuò)地發(fā)送給對(duì)方，這就是 HTTP/2 中的多路復(fù)用。
流的概念實(shí)現(xiàn)了單連接上多請(qǐng)求 - 響應(yīng)并行，解決了線頭阻塞的問題，減少了 TCP 連接數(shù)量和 TCP 連接慢啟動(dòng)造成的問題
所以 http2 對(duì)于同一域名只需要?jiǎng)?chuàng)建一個(gè)連接，而不是像 http/1.1 那樣創(chuàng)建 6~8 個(gè)連接:
關(guān)于流詳見: How does it work ？- 流
瀏覽器發(fā)送一個(gè)請(qǐng)求，服務(wù)器主動(dòng)向?yàn)g覽器推送與這個(gè)請(qǐng)求相關(guān)的資源，這樣瀏覽器就不用發(fā)起后續(xù)請(qǐng)求。
Server-Push 主要是針對(duì)資源內(nèi)聯(lián)做出的優(yōu)化，相較于 http/1.1 資源內(nèi)聯(lián)的優(yōu)勢(shì):
關(guān)于服務(wù)端推送詳見: How does it work ？- Server-Push
使用 HPACK 算法來壓縮首部?jī)?nèi)容
關(guān)于 HPACK 詳見: How does it work ？- HPACK
對(duì)于 HTTP/1 來說，是通過設(shè)置 tcp segment 里的 reset flag 來通知對(duì)端關(guān)閉連接的。這種方式會(huì)直接斷開連接，下次再發(fā)請(qǐng)求就必須重新建立連接。HTTP/2 引入 RST_STREAM 類型的 frame，可以在不斷開連接的前提下取消某個(gè) request 的 stream，表現(xiàn)更好。
HTTP/2 里的每個(gè) stream 都可以設(shè)置依賴 (Dependency) 和權(quán)重，可以按依賴樹分配優(yōu)先級(jí)，解決了關(guān)鍵請(qǐng)求被阻塞的問題
每個(gè) http2 流都擁有自己的公示的流量窗口，它可以限制另一端發(fā)送數(shù)據(jù)。對(duì)于每個(gè)流來說，兩端都必須告訴對(duì)方自己還有足夠的空間來處理新的數(shù)據(jù)，而在該窗口被擴(kuò)大前，另一端只被允許發(fā)送這么多數(shù)據(jù)。
關(guān)于流量控制詳見: How does it work ？- 流量控制
合并文件、內(nèi)聯(lián)資源、雪碧圖、域名分片對(duì)于 HTTP/2 來說是不必要的，使用 h2 盡可能將資源細(xì)粒化，文件分解地盡可能散，不用擔(dān)心請(qǐng)求數(shù)多
所有幀都是一個(gè)固定的 9 字節(jié)頭部 (payload 之前) 跟一個(gè)指定長(zhǎng)度的負(fù)載 (payload):
共分為十種類型的幀:
DATA 幀有如下標(biāo)識(shí) (flags):
例子:
HEADERS 幀有以下標(biāo)識(shí) (flags):
例子:
HTTP/2 里的首部字段也是一個(gè)鍵具有一個(gè)或多個(gè)值。這些首部字段用于 HTTP 請(qǐng)求和響應(yīng)消息，也用于服務(wù)端推送操作。
首部列表 (Header List) 是零個(gè)或多個(gè)首部字段 (Header Field) 的集合。當(dāng)通過連接傳送時(shí)，首部列表通過壓縮算法(即下文 HPACK) 序列化成首部塊 (Header Block)。然后，序列化的首部塊又被劃分成一個(gè)或多個(gè)叫做首部塊片段 (Header Block Fragment) 的字節(jié)序列，并通過 HEADERS、PUSH_PROMISE，或者 CONTINUATION 幀進(jìn)行有效負(fù)載傳送。
一個(gè)完整的首部塊有兩種可能
必須將首部塊作為連續(xù)的幀序列傳送，不能插入任何其他類型或其他流的幀。尾幀設(shè)置 END_HEADERS 標(biāo)識(shí)代表首部塊結(jié)束，這讓首部塊在邏輯上等價(jià)于一個(gè)單獨(dú)的幀。接收端連接片段重組首部塊，然后解壓首部塊重建首部列表。
一個(gè) SETTINGS 幀的 payload 由零個(gè)或多個(gè)參數(shù)組成，每個(gè)參數(shù)的形式如下:
在建立連接開始時(shí)雙方都要發(fā)送 SETTINGS 幀以表明自己期許對(duì)方應(yīng)做的配置，對(duì)方接收后同意配置參數(shù)便返回帶有 ACK 標(biāo)識(shí)的空 SETTINGS 幀表示確認(rèn)，而且連接后任意時(shí)刻任意一方也都可能再發(fā)送 SETTINGS 幀調(diào)整，SETTINGS 幀中的參數(shù)會(huì)被最新接收到的參數(shù)覆蓋
SETTINGS 幀作用于整個(gè)連接，而不是某個(gè)流，而且 SETTINGS 幀的 stream identifier 必須是 0x0，否則接收方會(huì)認(rèn)為錯(cuò)誤 (PROTOCOL_ERROR)。
SETTINGS 幀包含以下參數(shù):
SETTINGS 幀有以下標(biāo)識(shí) (flags):
例子:
實(shí)際抓包會(huì)發(fā)現(xiàn) HTTP2 請(qǐng)求創(chuàng)建連接發(fā)送 SETTINGS 幀初始化前還有一個(gè) Magic 幀 (建立 HTTP/2 請(qǐng)求的前言)。
在 HTTP/2 中，要求兩端都要發(fā)送一個(gè)連接前言，作為對(duì)所使用協(xié)議的最終確認(rèn)，并確定 HTTP/2 連接的初始設(shè)置，客戶端和服務(wù)端各自發(fā)送不同的連接前言。
客戶端的前言內(nèi)容 (對(duì)應(yīng)上圖中編號(hào) 23 的幀) 包含一個(gè)內(nèi)容為 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n 的序列加上一個(gè)可以為空的 SETTINGS 幀，在收到 101(Switching Protocols) 響應(yīng) (代表 upgrade 成功) 后發(fā)送，或者作為 TLS 連接的第一個(gè)傳輸?shù)膽?yīng)用數(shù)據(jù)。如果在預(yù)先知道服務(wù)端支持 HTTP/2 的情況下啟用 HTTP/2 連接，客戶端連接前言在連接建立時(shí)發(fā)送。
服務(wù)端的前言 (對(duì)應(yīng)上圖中編號(hào) 26 的幀) 包含一個(gè)可以為空的 SETTINGS 幀，在建立 HTTP/2 連接后作為第一幀發(fā)送。詳見 HTTP/2 Connection Preface
發(fā)送完前言后雙方都得向?qū)Ψ桨l(fā)送帶有 ACK 標(biāo)識(shí)的 SETTINGS 幀表示確認(rèn)，對(duì)應(yīng)上圖中編號(hào) 29 和 31 的幀。
請(qǐng)求站點(diǎn)的全部幀序列，幀后面的數(shù)字代表所屬流的 id，最后以 GOAWAY 幀關(guān)閉連接:
GOAWAY 幀帶有最大的那個(gè)流標(biāo)識(shí)符 (比如圖中第 29 幀是最大流)，對(duì)于發(fā)送方來說會(huì)繼續(xù)處理完不大于此數(shù)字的流，然后再真正關(guān)閉連接
流只是一個(gè)邏輯上的概念，代表 HTTP/2 連接中在客戶端和服務(wù)器之間交換的獨(dú)立雙向幀序列，每個(gè)幀的 Stream Identifier 字段指明了它屬于哪個(gè)流。
流有以下特性:
所有流以“空閑”狀態(tài)開始。在這種狀態(tài)下，沒有任何幀的交換
其狀態(tài)轉(zhuǎn)換:
此狀態(tài)下接收到 HEADERS 和 PRIORITY 以外的幀被視為 PROTOCOL_ERROR
狀態(tài)圖中 send PP 和 recv PP 是指連接的雙方端點(diǎn)發(fā)送或接收了 PUSH_PROMISE，不是指某個(gè)空閑流發(fā)送或接收了 PUSH_PROMISE，是 PUSH_PROMISE 的出現(xiàn)促使一個(gè)預(yù)示的流從 idle 狀態(tài)轉(zhuǎn)為 reserved
PUSH_PROMISE 預(yù)示的流由 idle 狀態(tài)進(jìn)入此狀態(tài)，代表準(zhǔn)備進(jìn)行 Server push
其狀態(tài)轉(zhuǎn)換:
reserved(local) 狀態(tài)下的流不能發(fā)送 HEADERS、RST_STREAM、PRIORITY 以外的幀，接收到 RST_STREAM、PRIORITY、WINDOW_UPDATE 以外的幀被視為 PROTOCOL_ERROR
reserved(remote) 狀態(tài)下的流不能發(fā)送 RST_STREAM、WINDOW_UPDATE、PRIORITY 以外的幀，接收到 HEADERS、RST_STREAM、PRIORITY 以外的幀被視為 PROTOCOL_ERROR
處于 open 狀態(tài)的流可以被兩個(gè)對(duì)端用來發(fā)送任何類型的幀
其狀態(tài)轉(zhuǎn)換:
流是雙向的，半關(guān)閉表示這個(gè)流單向關(guān)閉了，local 代表本端到對(duì)端的方向關(guān)閉了，remote 代表對(duì)端到本端的方向關(guān)閉了
此狀態(tài)下的流不能發(fā)送 WINDOW_UPDATE、PRIORITY、RST_STREAM 以外的幀
當(dāng)此狀態(tài)下的流收到帶有 END_STREAM 標(biāo)識(shí)的幀或者任一方發(fā)送 RST_STREAM 幀，會(huì)轉(zhuǎn)為 closed 狀態(tài)
此狀態(tài)下的流收到的 PRIORITY 幀用以調(diào)整流的依賴關(guān)系順序，可以看下文的流優(yōu)先級(jí)
此狀態(tài)下的流不會(huì)被對(duì)端用于發(fā)送幀，執(zhí)行流量控制的端點(diǎn)不再有義務(wù)維護(hù)接收方的流控制窗口。
一個(gè)端點(diǎn)在此狀態(tài)的流上接收到 WINDOW_UPDATE、PRIORITY、RST_STREAM 以外的幀，應(yīng)該響應(yīng)一個(gè) STREAM_CLOSED 流錯(cuò)誤
此狀態(tài)下的流可以被端點(diǎn)用于發(fā)送任意類型的幀，且此狀態(tài)下該端點(diǎn)仍會(huì)觀察流級(jí)別的流控制的限制
當(dāng)此狀態(tài)下的流發(fā)送帶有 END_STREAM 標(biāo)識(shí)的幀或者任一方發(fā)送 RST_STREAM 幀，會(huì)轉(zhuǎn)為 closed 狀態(tài)
代表流已關(guān)閉
此狀態(tài)下的流不能發(fā)送 PRIORITY 以外的幀，發(fā)送 PRIORITY 幀是調(diào)整那些依賴這個(gè)已關(guān)閉的流的流優(yōu)先級(jí)，端點(diǎn)都應(yīng)該處理 PRIORITY 幀，盡管如果該流從依賴關(guān)系樹中移除了也可以忽略優(yōu)先級(jí)幀
此狀態(tài)下在收到帶有 END_STREAM 標(biāo)識(shí)的 DATA 或 HEADERS 幀后的一小段時(shí)間內(nèi) (period) 仍可能接收到 WINDOW_UPDATE 或 RST_STREAM 幀，因?yàn)樵谶h(yuǎn)程對(duì)端接收并處理 RST_STREAM 或帶有 END_STREAM 標(biāo)志的幀之前，它可能會(huì)發(fā)送這些類型的幀。但是端點(diǎn)必須忽略接收到的 WINDOW_UPDATE 或 RST_STREAM
如果一個(gè)流發(fā)送了 RST_STREAM 幀后轉(zhuǎn)入此狀態(tài)，而對(duì)端接收到 RST_STREAM 幀時(shí)可能已經(jīng)發(fā)送了或者處在發(fā)送隊(duì)列中，這些幀是不可撤銷的，發(fā)送 RST_STREAM 幀的端點(diǎn)必須忽略這些幀。
一個(gè)端點(diǎn)可以限制 period 的長(zhǎng)短，在 period 內(nèi)接受的幀會(huì)忽略，超出 period 的幀被視為錯(cuò)誤。
一個(gè)端點(diǎn)發(fā)送了 RST_STREAM 幀后接收到流控制幀(比如 DATA)，仍會(huì)計(jì)入流量窗口，即使這些幀會(huì)被忽略，因?yàn)閷?duì)端肯定是在接收到 RST_STREAM 幀前發(fā)送的流控制幀，對(duì)端會(huì)認(rèn)為流控制已生效
一個(gè)端點(diǎn)可能會(huì)在發(fā)送了 RST_STREAM 幀后收到 PUSH_PROMISE 幀，即便預(yù)示的流已經(jīng)被重置 (reset)，PUSH_PROMISE 幀也能使預(yù)示流變成 reserved 狀態(tài)。因此，需要 RST_STREAM 來關(guān)閉一個(gè)不想要的預(yù)示流。
下面看兩個(gè)例子來理解流狀態(tài):
(1)、Server 在 Client 發(fā)起的一個(gè)流上發(fā)送 PUSH_PROMISE 幀，其 Promised Stream ID 指定一個(gè)預(yù)示流用于后續(xù)推送，send PP 后這個(gè)預(yù)示流在服務(wù)端從 idle 狀態(tài)轉(zhuǎn)為 reserve(local) 狀態(tài)，客戶端 recv PP 后這個(gè)流從 idle 狀態(tài)轉(zhuǎn)為 reserve(remote) 狀態(tài)
(2)(3)、此時(shí)預(yù)示流處于保留狀態(tài)，客戶端如果選擇拒絕接受推送，可以發(fā)送 RST 幀關(guān)閉這個(gè)流；服務(wù)端如果此時(shí)出問題了也可以發(fā)送 RST 幀取消推送。不管哪一方發(fā)送或接收到 RST，此狀態(tài)都轉(zhuǎn)為 closed
(4)、沒有出現(xiàn)重置說明推送仍有效，則服務(wù)端開始推送，首先發(fā)送的肯定是響應(yīng)的 HEADERS 首部塊，此時(shí)流狀態(tài)轉(zhuǎn)為半關(guān)閉 half-closed(remote)；客戶端接收到 HEADERS 后流狀態(tài)轉(zhuǎn)為半關(guān)閉 half-closed(local)
(5)(6)、半關(guān)閉狀態(tài)下的流應(yīng)該還會(huì)繼續(xù)推送諸如 DATA 幀、CONTINUATION 幀這樣的數(shù)據(jù)幀，如果這個(gè)過程碰到任一方發(fā)起重置，則流會(huì)關(guān)閉進(jìn)入 closed 狀態(tài)
(7)、如果一切順利，資源隨著數(shù)據(jù)幀響應(yīng)完畢，最后一幀會(huì)帶上 END_STREAM 標(biāo)識(shí)代表這個(gè)流結(jié)束了，此時(shí)流轉(zhuǎn)為 closed 狀態(tài)
(1)、客戶端發(fā)起請(qǐng)求，首先發(fā)送一個(gè) HEADERS 幀，其 Stream Identifier 創(chuàng)建一個(gè)新流，此流從 idle 狀態(tài)轉(zhuǎn)為 open 狀態(tài)
(2)(3)、如果客戶端取消請(qǐng)求可以發(fā)送 RST 幀，服務(wù)端出錯(cuò)也可以發(fā)送 RST 幀，不管哪一方接收或發(fā)送 RST，流關(guān)閉進(jìn)入 closed 狀態(tài)；
(4)、如果請(qǐng)求結(jié)束(END_STREAM)，流轉(zhuǎn)為半關(guān)閉狀態(tài)。假如是 GET 請(qǐng)求，一般 HEADERS 幀就是最后一幀，send H 后流會(huì)立即進(jìn)入半關(guān)閉狀態(tài)。假如是 POST 請(qǐng)求，待數(shù)據(jù)傳完，最后一幀帶上 END_STREAM 標(biāo)識(shí)，流轉(zhuǎn)為半關(guān)閉
(5)(6)、客戶端半關(guān)閉后服務(wù)端開始返回響應(yīng)，此時(shí)任一方接收或發(fā)送 RST，流關(guān)閉；
(7)、如果一切順利，等待響應(yīng)結(jié)束(END_STREAM)，流關(guān)閉
流 ID 是 31 位無符號(hào)整數(shù)，客戶端發(fā)起的流必須是奇數(shù)，服務(wù)端發(fā)起的流必須是偶數(shù)，0x0 保留為連接控制消息不能用于建立新流。
HTTP/1.1 Upgrade to HTTP/2 時(shí)響應(yīng)的流 ID 是 0x1，在升級(jí)完成之后，流 0x1 在客戶端會(huì)轉(zhuǎn)為 half-closed (local) 狀態(tài)，因此這種情況下客戶端不能用 0x1 初始化一個(gè)流
新建立的流的 ID 必須大于所有已使用過的數(shù)字，接收到一個(gè)錯(cuò)誤大小的 ID 應(yīng)該返回 PROTOCOL_ERROR 響應(yīng)
使用一個(gè)新流時(shí)隱式地關(guān)閉了對(duì)端發(fā)起的 ID 小于當(dāng)前流的且處于 idle 狀態(tài)的流，比如一個(gè)流發(fā)送一個(gè) HEADERS 幀打開了 ID 為 7 的流，但還從未向 ID 為 5 的流發(fā)送過幀，則流 0x5 會(huì)在 0x7 發(fā)送完或接收完第一幀后轉(zhuǎn)為 closed 狀態(tài)
一個(gè)連接內(nèi)的流 ID 不能重用
客戶端可以通過 HEADERS 幀的 PRIORITY 信息指定一個(gè)新建立流的優(yōu)先級(jí)，其他期間也可以發(fā)送 PRIORITY 幀調(diào)整流優(yōu)先級(jí)
設(shè)置優(yōu)先級(jí)的目的是為了讓端點(diǎn)表達(dá)它所期望對(duì)端在并發(fā)的多個(gè)流之間如何分配資源的行為。更重要的是，當(dāng)發(fā)送容量有限時(shí)，可以使用優(yōu)先級(jí)來選擇用于發(fā)送幀的流。
流可以被標(biāo)記為依賴其他流，所依賴的流完成后再處理當(dāng)前流。每個(gè)依賴 (dependency) 后都跟著一個(gè)權(quán)重 (weight)，這一數(shù)字是用來確定依賴于相同的流的可分配可用資源的相對(duì)比例
每個(gè)流都可以顯示地依賴另一個(gè)流，包含依賴關(guān)系表示優(yōu)先將資源分配給指定的流(上層節(jié)點(diǎn))而不是依賴流
一個(gè)不依賴于其他流的流會(huì)指定 stream dependency 為 0x0 值，因?yàn)椴淮嬖诘?0x0 流代表依賴樹的根
一個(gè)依賴于其他流的流叫做 依賴流 ，被依賴的流是當(dāng)前流的父級(jí)。如果被依賴的流不在當(dāng)前依賴樹中(比如狀態(tài)為 idle 的流)，被依賴的流會(huì)使用一個(gè)默認(rèn)優(yōu)先級(jí)
當(dāng)依賴一個(gè)流時(shí)，該流會(huì)添加進(jìn)父級(jí)的依賴關(guān)系中，共享相同父級(jí)的依賴流不會(huì)相對(duì)于彼此進(jìn)行排序，比如 B 和 C 依賴 A，新添加一個(gè)依賴流 D，BCD 的順序是不固定的:
獨(dú)占標(biāo)識(shí) (exclusive) 允許插入一個(gè)新層級(jí)(新的依賴關(guān)系)，獨(dú)占標(biāo)識(shí)導(dǎo)致該流成為父級(jí)的唯一依賴流，而其他依賴流變?yōu)槠渥蛹?jí)，比如同樣插入一個(gè)新依賴流 E (帶有 exclusive):
在依賴關(guān)系樹中，只有當(dāng)一個(gè)依賴流所依賴的所有流(父級(jí)最高為 0x0 的鏈)被關(guān)閉或者無法繼續(xù)在上面執(zhí)行，這個(gè)依賴流才應(yīng)該被分配資源
所有依賴流都會(huì)分配一個(gè) 1~256 權(quán)重值
相同父級(jí)的依賴流按權(quán)重比例分配資源，比如流 B 依賴于 A 且權(quán)重值為 4，流 C 依賴于 A 且權(quán)重值為 12，當(dāng) A 不再執(zhí)行時(shí)，B 理論上能分配的資源只有 C 的三分之一
使用 PRIORITY 幀可以調(diào)整流優(yōu)先級(jí)
PRIORITY 幀內(nèi)容與 HEADERS 幀的優(yōu)先級(jí)模塊相同:
看下面這個(gè)例子: 第一個(gè)圖是初始關(guān)系樹，現(xiàn)在 A 要調(diào)整為依賴 D，根據(jù)第二點(diǎn)，現(xiàn)將 D 移至 x 之下，再把 A 調(diào)整為 D 的子樹(圖 3)，如果 A 調(diào)整時(shí)帶有獨(dú)占標(biāo)識(shí)根據(jù)第一點(diǎn) F 也歸為 A 子級(jí)(圖 4)
當(dāng)一個(gè)流從依賴樹中移除，它的子級(jí)可以調(diào)整為依賴被關(guān)閉流的父級(jí)(應(yīng)該就是連接上一層節(jié)點(diǎn))，新的依賴權(quán)重將根據(jù)關(guān)閉流的權(quán)重以及流自身的權(quán)重重新計(jì)算。
從依賴樹中移除流會(huì)導(dǎo)致某些優(yōu)先級(jí)信息丟失。資源在具有相同父級(jí)的流之間共享，這意味著如果這個(gè)集合中的某個(gè)流關(guān)閉或者阻塞，任何空閑容量將分配給最近的相鄰流。然而，如果此集合的共有依賴(即父級(jí)節(jié)點(diǎn))從樹中移除，這些子流將與更上一層的流共享資源
一個(gè)例子: 流 A 和流 B 依賴相同父級(jí)節(jié)點(diǎn)，而流 C 和流 D 都依賴 A，在移除流 A 之前的一段時(shí)間內(nèi)，A 和 D 都無法執(zhí)行(可能任務(wù)阻塞了)，則 C 會(huì)分配到 A 的所有資源；
如果 A 被移除出樹了，A 的權(quán)重按比重新計(jì)算分配給 C 和 D，此時(shí) D 仍舊阻塞，C 分配的資源相較之前變少了。對(duì)于同等的初始權(quán)重，C 獲取到的可用資源是三分之一而不是二分之一(為什么是三分之一?文檔中沒有說明細(xì)節(jié)，權(quán)重如何重新分配也不太清楚，下面是按我的理解解釋的)
X 的資源為 1，ABCD 初始權(quán)重均為 16，*號(hào)代表節(jié)點(diǎn)當(dāng)前不可用，圖一中 C 和 B 各占一半資源，而 A 移除后 CD 的權(quán)重重新分配變?yōu)?8，所以圖二中 C 和 B 占比變?yōu)?1:2，R(C) 變?yōu)?1/3
可能向一個(gè)流創(chuàng)建依賴關(guān)系的優(yōu)先級(jí)信息還在傳輸中，那個(gè)流就已經(jīng)關(guān)閉了。如果一個(gè)依賴流的依賴指向沒有相關(guān)優(yōu)先級(jí)信息(即父節(jié)點(diǎn)無效)，則這個(gè)依賴流會(huì)分配默認(rèn)優(yōu)先級(jí)，這可能會(huì)造成不理想的優(yōu)先級(jí)，因?yàn)榻o流分配了不在預(yù)期的優(yōu)先級(jí)。
為了避免上述問題，一個(gè)端點(diǎn)應(yīng)該在流關(guān)閉后的一段時(shí)間內(nèi)保留流的優(yōu)先級(jí)調(diào)整狀態(tài)信息，此狀態(tài)保留時(shí)間越長(zhǎng)，流被分配錯(cuò)誤的或者默認(rèn)的優(yōu)先級(jí)可能性越低。
類似地，處于“空閑”狀態(tài)的流可以被分配優(yōu)先級(jí)或成為其他流的父節(jié)點(diǎn)。這允許在依賴關(guān)系樹中創(chuàng)建分組節(jié)點(diǎn)，從而實(shí)現(xiàn)更靈活的優(yōu)先級(jí)表達(dá)式?？臻e流以默認(rèn)優(yōu)先級(jí)開始
流優(yōu)先級(jí)狀態(tài)信息的保留可能增加終端的負(fù)擔(dān)，因此這種狀態(tài)可以被限制。終端可能根據(jù)負(fù)荷來決定保留的額外的狀態(tài)的數(shù)目；在高負(fù)荷下，可以丟棄額外的優(yōu)先級(jí)狀態(tài)來限制資源的任務(wù)。在極端情況下，終端甚至可以丟棄激活或者保留狀態(tài)流的優(yōu)先級(jí)信息。如果使用了固定的限制，終端應(yīng)當(dāng)至少保留跟 SETTINGS_MAX_CONCURRENT_STREAMS 設(shè)置一樣大小的流狀態(tài)
所有流都是初始為非獨(dú)占地依賴于流 0x0。
Pushed 流初始依賴于相關(guān)的流(見 Server-Push)。
以上兩種情況，流的權(quán)重都指定為 16。
PUSH_PROMISE 幀有以下標(biāo)識(shí) (flags):
結(jié)合上文關(guān)于 Server-Push 的流狀態(tài)轉(zhuǎn)換
PUSH_PROMISE 幀只能在對(duì)端(客戶端)發(fā)起的且流狀態(tài)為 open 或者 half-closed (remote) 的流上發(fā)送
PUSH_PROMISE 幀準(zhǔn)備推送的響應(yīng)總是和來自于客戶端的請(qǐng)求相關(guān)聯(lián)。服務(wù)端在該請(qǐng)求所在的流上發(fā)送 PUSH_PROMISE 幀。PUSH_PROMISE 幀包含一個(gè) Promised Stream ID，該流標(biāo)識(shí)符是從服務(wù)端可用的流標(biāo)識(shí)符里選出來的。
如果服務(wù)端收到了一個(gè)對(duì)文檔的請(qǐng)求，該文檔包含內(nèi)嵌的指向多個(gè)圖片文件的鏈接，且服務(wù)端選擇向客戶端推送那些額外的圖片，那么在發(fā)送包含圖片鏈接的 DATA 幀之前發(fā)送 PUSH_PROMISE 幀可以確?？蛻舳嗽诎l(fā)現(xiàn)內(nèi)嵌的鏈接之前，能夠知道有一個(gè)資源將要被推送過來。同樣地，如果服務(wù)端準(zhǔn)備推送被首部塊引用的響應(yīng) (比如，在 Link 首部字段 里的)，在發(fā)送首部塊之前發(fā)送一個(gè) PUSH_PROMISE 幀，可以確?？蛻舳瞬辉僬?qǐng)求那些資源
一旦客戶端收到了 PUSH_PROMISE 幀，并選擇接收被推送的響應(yīng)，客戶端就不應(yīng)該為準(zhǔn)備推送的響應(yīng)發(fā)起任何請(qǐng)求，直到預(yù)示的流被關(guān)閉以后。
不管出于什么原因，如果客戶端決定不再?gòu)姆?wù)端接收準(zhǔn)備推送的響應(yīng)，或者如果服務(wù)端花費(fèi)了太長(zhǎng)時(shí)間準(zhǔn)備發(fā)送被預(yù)示的響應(yīng)，客戶端可以發(fā)送一個(gè) RST_STREAM 幀，該幀可以使用 CANCEL 或者 REFUSED_STEAM 碼，并引用被推送的流標(biāo)識(shí)符。
以 nginx 為例，從版本 1.13.9 開始正式支持 hppt2 serverpush 功能，
在相應(yīng) server 或 location 模塊中加入 http2_push 字段加上相對(duì)路徑的文件即可在請(qǐng)求該資源時(shí)推送相關(guān)資源，比如我的博客設(shè)置如下，訪問首頁(yè)時(shí)有四個(gè)文件會(huì)由服務(wù)器主動(dòng)推送過去而不需要客戶端請(qǐng)求:
通過瀏覽器控制臺(tái)可以查看 Push 響應(yīng):
也可以用 nghttp 測(cè)試 push 響應(yīng) (* 號(hào)代表是服務(wù)端推送的):
上面 http2_push 的設(shè)置適合靜態(tài)資源，服務(wù)端事先知道哪些文件是客戶端需要的，然后選擇性推送
假如是后臺(tái)應(yīng)用動(dòng)態(tài)生成的文件(比如 json 文件)，服務(wù)器事先不知道要推送什么，可以用 Link 響應(yīng)頭來做自動(dòng)推送
在 server 模塊中添加 http2_push_preload on;
然后設(shè)置響應(yīng)頭 (add_header) 或者后臺(tái)程序生成數(shù)據(jù)文件返回時(shí)帶上響應(yīng)頭 Link 標(biāo)簽，比如
nginx 會(huì)根據(jù) Link 響應(yīng)頭主動(dòng)推送這些資源
更多nginx 官方介紹見 Introducing HTTP/2 Server Push with NGINX 1.13.9
看了這篇文章 HTTP/2 中的 Server Push 討論 ，發(fā)現(xiàn) Server-Push 有個(gè)潛在的問題
Server-Push 滿足條件時(shí)便會(huì)發(fā)起推送，可是客戶端已經(jīng)有緩存了想發(fā)送 RST 拒收，而服務(wù)器在收到 RST 之前已經(jīng)推送資源了，雖然這部分推送無效但是肯定會(huì)占用帶寬
比如我上面博客關(guān)于 http2_push 的配置，我每次打開首頁(yè)服務(wù)器都會(huì)推送那四個(gè)文件，而實(shí)際上瀏覽器知道自己有緩存使用的也是本地緩存，也就是說本地緩存未失效的期間內(nèi)，服務(wù)器的 Server-Push 只是起到了占用帶寬的作用
當(dāng)然實(shí)際上對(duì)我的小站點(diǎn)來說影響并不大，但是如果網(wǎng)站需要大量推送的話，需要考慮并測(cè)試 Server-Push 是否會(huì)影響用戶的后續(xù)訪問
另外服
技術(shù)在近年來獲得前所未有的增長(zhǎng)。云技術(shù)如今已被運(yùn)用到銀行、學(xué)校、政府以及大量的商業(yè)組織。但是云計(jì)算也并非萬能的，和其他IT部署架構(gòu)一樣存在某些難以彌補(bǔ)的缺陷。例如公有云典型代表：服務(wù)器，用戶數(shù)據(jù)存儲(chǔ)在云計(jì)算基礎(chǔ)平臺(tái)的存儲(chǔ)系統(tǒng)中，但敏感的信息和應(yīng)用程序同樣面臨著網(wǎng)絡(luò)攻擊和黑客入侵的威脅。以下就是壹基比小喻要講的服務(wù)器面臨的九大安全威脅。
哪些因素會(huì)對(duì)服務(wù)器安全有危害？
一、數(shù)據(jù)漏洞
云環(huán)境面臨著許多和傳統(tǒng)企業(yè)網(wǎng)絡(luò)相同的安全威脅，但由于極大量的數(shù)據(jù)被儲(chǔ)存在服務(wù)器上，服務(wù)器供應(yīng)商則很可能成為盜取數(shù)據(jù)的目標(biāo)。供應(yīng)商通常會(huì)部署安全控件來保護(hù)其環(huán)境，但最終還需要企業(yè)自己來負(fù)責(zé)保護(hù)云中的數(shù)據(jù)。公司可能會(huì)面臨：訴訟、犯罪指控、調(diào)查和商業(yè)損失。
二、密碼和證書
數(shù)據(jù)漏洞和其他攻擊通常來源于不嚴(yán)格的認(rèn)證、較弱的口令和密鑰或者證書管理。企業(yè)應(yīng)當(dāng)權(quán)衡集中身份的便利性和使儲(chǔ)存地點(diǎn)變成攻擊者首要目標(biāo)的風(fēng)險(xiǎn)性。使用服務(wù)器，建議采用多種形式的認(rèn)證，例如：一次性密碼、手機(jī)認(rèn)證和智能卡保護(hù)。
三、界面和API的入侵
IT團(tuán)隊(duì)使用界面和API來管理和與服務(wù)器互動(dòng)，包括云的供應(yīng)、管理、編制和監(jiān)管。API和界面是系統(tǒng)中最暴露在外的一部分，因?yàn)樗鼈兺ǔ？梢酝ㄟ^開放的互聯(lián)網(wǎng)進(jìn)入。服務(wù)器供應(yīng)商，應(yīng)做好安全方面的編碼檢查和嚴(yán)格的進(jìn)入檢測(cè)。運(yùn)用API安全成分，例如：認(rèn)證、進(jìn)入控制和活動(dòng)監(jiān)管。
四、已開發(fā)的系統(tǒng)的脆弱性
企業(yè)和其他企業(yè)之間共享經(jīng)驗(yàn)、數(shù)據(jù)庫(kù)和其他一些資源，形成了新的攻擊對(duì)象。幸運(yùn)的是，對(duì)系統(tǒng)脆弱性的攻擊可以通過使用“基本IT過程”來減輕。盡快添加補(bǔ)丁——進(jìn)行緊急補(bǔ)丁的變化控制過程保證了補(bǔ)救措施可以被正確記錄，并被技術(shù)團(tuán)隊(duì)復(fù)查。容易被攻擊的目標(biāo)：可開發(fā)的bug和系統(tǒng)脆弱性。
五、賬戶劫持
釣魚網(wǎng)站、詐騙和軟件開發(fā)仍舊在肆虐，服務(wù)器又使威脅上升了新的層次，因?yàn)楣粽咭坏┏晒?*、操控業(yè)務(wù)以及篡改數(shù)據(jù)，將造成嚴(yán)重后果。因此所有云服務(wù)器的管理賬戶，甚至是服務(wù)賬戶，都應(yīng)該形成嚴(yán)格監(jiān)管，這樣每一筆交易都可以追蹤到一個(gè)所有者。關(guān)鍵點(diǎn)在于保護(hù)賬戶綁定的安全認(rèn)證不被竊取。有效的攻擊載體：釣魚網(wǎng)站、詐騙、軟件開發(fā)。
六、居心叵測(cè)的內(nèi)部人員
內(nèi)部人員的威脅來自諸多方面：現(xiàn)任或前員工、系統(tǒng)管理者、承包商或者是商業(yè)伙伴。惡意的來源十分廣泛，包括竊取數(shù)據(jù)和報(bào)復(fù)。單一的依靠服務(wù)器供應(yīng)商來保證安全的系統(tǒng)，例如加密，是最為危險(xiǎn)的。有效的日志、監(jiān)管和審查管理者的活動(dòng)十分重要。企業(yè)必須最小化暴露在外的訪問：加密過程和密鑰、最小化訪問。
七、APT病毒
APT通過滲透服務(wù)器中的系統(tǒng)來建立立足點(diǎn)，然后在很長(zhǎng)的一段時(shí)間內(nèi)悄悄地竊取數(shù)據(jù)和知識(shí)產(chǎn)權(quán)。IT部門必須及時(shí)了解最新的高級(jí)攻擊，針對(duì)服務(wù)器部署相關(guān)保護(hù)策略（ID:ydotpub）。此外，經(jīng)常地強(qiáng)化通知程序來警示用戶，可以減少被APT的迷惑使之進(jìn)入。進(jìn)入的常見方式：魚叉式網(wǎng)絡(luò)釣魚、直接攻擊、USB驅(qū)動(dòng)。
八、永久性的數(shù)據(jù)丟失
關(guān)于供應(yīng)商出錯(cuò)導(dǎo)致的永久性數(shù)據(jù)丟失的報(bào)告已經(jīng)鮮少出現(xiàn)。但居心叵測(cè)的黑客仍會(huì)采用永久刪除云數(shù)據(jù)的方式來傷害企業(yè)和云數(shù)據(jù)中心。遵循政策中通常規(guī)定了企必須保留多久的審計(jì)記錄及其他文件。丟失這些數(shù)據(jù)會(huì)導(dǎo)致嚴(yán)重的監(jiān)管后果。建議云服務(wù)器供應(yīng)商分散數(shù)據(jù)和應(yīng)用程序來加強(qiáng)保護(hù)：每日備份、線下儲(chǔ)存。
九、共享引發(fā)潛在危機(jī)
共享技術(shù)的脆弱性為服務(wù)器帶來了很大的威脅。服務(wù)器供應(yīng)商共享基礎(chǔ)設(shè)施、平臺(tái)以及應(yīng)用程序，如果脆弱性出現(xiàn)在任何一層內(nèi)，就會(huì)影響所有。如果一個(gè)整體的部分被損壞——例如管理程序、共享的平臺(tái)部分或者應(yīng)用程序——就會(huì)將整個(gè)環(huán)境暴露在潛在的威脅和漏洞下
重慶分公司
重慶分公司
