整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
代計算機系統(tǒng)功能日漸復(fù)雜，信息化日漸強大，正在對社會各行各業(yè)產(chǎn)生巨大深遠的影響，但同時由于其開放性特點，使得安全問題越來越突出。然而，隨著人們對計算機網(wǎng)絡(luò)依賴程度的日漸加深，信息化安全也表現(xiàn)得越來越重要。為防止不同類型的系統(tǒng)安全隱患，所以構(gòu)建一個安全的系統(tǒng)是非常重要的。
1、安裝防病毒軟件
計算機病毒的危害日益加重，我們必須在服務(wù)器上安裝防病毒軟件。
2、關(guān)掉不需要的服務(wù)
安裝完應(yīng)用系統(tǒng)后，我們就應(yīng)該禁止掉該服務(wù)器不承擔的任何網(wǎng)絡(luò)服務(wù)程序。
3、對系統(tǒng)帳戶進行安全設(shè)置
一些公司的管理員創(chuàng)建賬號的時候往往用公司名、計算機名做用戶名，然后又把這些用戶的密碼設(shè)置得太簡單，比如“welcome”等等。因此，要注意密碼的復(fù)雜性，還要記住經(jīng)常改密碼。
4、關(guān)閉不需要的端口
用端口掃描器掃描系統(tǒng)所開放的端口，確定開放了哪些端口，關(guān)閉不必要的端口。
網(wǎng)絡(luò)通訊與訪問的安全防護主要在于保證信息在網(wǎng)絡(luò)上被安全地傳輸，保證通過網(wǎng)絡(luò)線路和設(shè)備訪問開源字節(jié)應(yīng)用系統(tǒng)及數(shù)據(jù)信息的訪問者的合法性，保證企業(yè)內(nèi)部數(shù)據(jù)信息不被企業(yè)外部攻擊者所竊取。
1、使用防火墻
在保證網(wǎng)絡(luò)安全方面，防火墻(Firewall)被廣泛使用。在接入Internet的組織中，經(jīng)常使用來保護內(nèi)部網(wǎng)及資源，也可以將防火墻用于內(nèi)部網(wǎng)內(nèi)對保密信息或其他敏感信息的限制訪問，使得只有限定的授權(quán)的操作可以通過防火墻。
2、使用VPN技術(shù)
基于公共網(wǎng)的VPN通過隧道技術(shù)、數(shù)據(jù)加密技術(shù)以及QoS機制，使企業(yè)的遠程用戶可以在安全的前提下迅速接入企業(yè)內(nèi)部網(wǎng)，以實現(xiàn)對內(nèi)部網(wǎng)的相關(guān)操作。
3、使用SSL安全機制
我們的系統(tǒng)支持MySQL7及以上的版本，對于數(shù)據(jù)庫來說數(shù)據(jù)的安全主要體現(xiàn)于以下幾個方面：
1、使用安全賬戶建立應(yīng)用數(shù)據(jù)庫的管理
賬戶，通過數(shù)據(jù)庫的權(quán)限系統(tǒng)給管理賬戶分配指定的操作權(quán)限，防止因為誤操作導致數(shù)據(jù)庫數(shù)據(jù)丟失。
在我們的軟件的管理中，用戶的管理和權(quán)限在最大的限度上與數(shù)據(jù)庫的安全管理相結(jié)合，來保障數(shù)據(jù)的安全。
2、使用安全的密碼策略
數(shù)據(jù)庫用戶的密碼過于簡單是被攻擊的主要原因之一，對于數(shù)據(jù)庫用戶的密碼一定要使用字符、數(shù)字、符號相結(jié)合，如同系統(tǒng)用戶的密碼一樣重要。對于管理員的密碼更要注意，應(yīng)該定期的更改密碼。
3、數(shù)據(jù)自動備份
在創(chuàng)建數(shù)據(jù)庫的同時，我們會創(chuàng)建系統(tǒng)任務(wù)和備份計劃，每天自動的進行數(shù)據(jù)備份，防止出現(xiàn)因數(shù)據(jù)庫被破壞等因素導致數(shù)據(jù)丟失的情況，可以利用備份恢復(fù)數(shù)據(jù)。默認策略為每天中午和晚上各備份一次，提高系統(tǒng)數(shù)據(jù)的容錯率。
系統(tǒng)提供的軟件安全設(shè)計有功能權(quán)限設(shè)置、數(shù)據(jù)權(quán)限設(shè)置和操作日志管理，以及防止系統(tǒng)奔潰設(shè)計。
1、功能權(quán)限設(shè)置
可以設(shè)置每個人使用的功能范圍。
2、數(shù)據(jù)權(quán)限設(shè)置
可以控制每個人查看和修改數(shù)據(jù)的范圍，例如有些數(shù)據(jù)只能看不能改等。對于權(quán)限的分配采取劃分角色的方式來實現(xiàn)成批人員權(quán)限的設(shè)置和維護。
3、操作日志管理
是應(yīng)用系統(tǒng)自動把每個操作人員從進入系統(tǒng)到退出系統(tǒng)的每一步操作都詳細記錄下來，哪一天，什么時間，進行了什么操作。當出現(xiàn)問題時，可以起到查找原因的作用。
通過系統(tǒng)應(yīng)用層就可以實現(xiàn)對每個操作人員使用范圍、使用時間、如何使用的管理和監(jiān)督。
4、防止系統(tǒng)奔潰
系統(tǒng)設(shè)計的不合理同樣會導致系統(tǒng)奔潰，在這方面我們做了許多的優(yōu)化設(shè)計，如導入業(yè)務(wù)數(shù)據(jù)時限制單次導入數(shù)據(jù)的上限，減少不必要的大批量數(shù)據(jù)操作，優(yōu)化JVM服務(wù)器參數(shù)配置，防止因內(nèi)存溢出而導致系統(tǒng)宕機等。
如若轉(zhuǎn)載，請注明出處：開源字節(jié) https://sourcebyte.vip/article/304.html
果用的是三星、HTC等，可以對手機進行root，然后使用“權(quán)限管理”找到“自啟動管理”，找到QQ和微信，關(guān)閉即可。
一般現(xiàn)在的手機都自帶自啟動管理，可以直接設(shè)置。
較老的手機可以下載“一鍵root”之類的root應(yīng)用或者連接電腦root，然后使用“百度手機衛(wèi)士”或者“授權(quán)管理”管理應(yīng)用自啟權(quán)限、通知權(quán)限等。
root前需要注意的事項為：root中與root后一切因root而引起的造成手機受損、無法使用的后果，即使手機在保修期內(nèi)，手機廠商、售后、維保中心也是不提供免費維保服務(wù)的，維修費用以及數(shù)據(jù)被竊取、失去的損失全由用戶自行承擔。
以上所指的后果包括但不限于：
1：root時修改系統(tǒng)文件失敗造成的手機芯片損毀、無法開機、黑屏；
2：root后手機遭受病毒的攻擊造成的手機芯片損毀、無法開機、黑屏、GPS被利用、數(shù)據(jù)外泄、數(shù)據(jù)丟失。
然后在左邊菜單中切換到如圖所示，然后再選擇某個你所要禁止自啟動的程序（個人認為，除了通話，輸入法，安全類的一般就不會停用的都可以禁止）
然后這里點擊權(quán)限管理
便是進入到了程序的權(quán)限界面，我們這里講自啟動那個滑塊滑動即可
然后便成如圖便是成功了，這種方法比較適合你對軟件進行一些比較詳細的權(quán)限查詢。接下來再說一種比較簡便的方法，只針對軟件的自啟動。
我們這里點擊安全中心
然后下一步選擇“內(nèi)存優(yōu)化”
這里我們也是可以看到自啟動管理的，相對來說這里便是更加方便了，如果遇到很多軟件需要進行管理。
http://jingyan.baidu.com/article/86fae346d3a3043c49121a3b.html
以上回答你滿意么？
設(shè)定-開發(fā)者選項-不保留活動（離開后立即清除每個活動）/限制后臺進程（標準限制/無后臺程序/最多1個程序/最多2個程序/最多3個程序/最多4個程序）。若系統(tǒng)自動隱藏了開發(fā)者選項，此功能僅適用于開發(fā)人員測試使用，所以將該菜單隱藏，避免用戶造成誤操作而帶來使用上的不便，請諒解。如需開啟，方式：
功能表-設(shè)定-更多（右上方）-關(guān)于設(shè)備-內(nèi)部版本號7次連續(xù)點擊-會提示開發(fā)者模式已啟用，返回上一級菜單即可看到開發(fā)者選項。
下文章來源于一口LINUX
我是程序員小賤
從面試出發(fā)，解剖各個知識點，讓我們向上成長！這里除了學習，還有音樂，生活攝影，籃球等，期待你的加入！
本文將從以下幾個方面進行分享。其中包括HTTP發(fā)展史，HTTP緩存代理機制，常用的web攻擊，HTTP和HTTPS的流量識別，網(wǎng)絡(luò)協(xié)議學習的工具推薦以及高頻HTTP與HTTPS的高頻面試題題解等，開工。
提綱
1989年，蒂姆·伯納斯 - 李（Tim Berners-Lee）在論文中提出可以在互聯(lián)網(wǎng)上構(gòu)建超鏈接文檔，并提出了三點.
URI：統(tǒng)一資源標識符。互聯(lián)網(wǎng)的唯一ID
HTML：超文本文檔
HTTP:傳輸超文本的文本傳輸協(xié)議
學習一門知識，采用五分鐘時間看看這個知識是干啥的可能會更加有目的性。HTTP可謂無處不在，這里例舉出幾個。
HTTP應(yīng)用場景
HTTP(hypertext transport protocol)翻譯過來為"超文本傳輸協(xié)議"，文本可以理解為簡單的字符文字組合，也可以理解為更為復(fù)雜的音頻或者圖像等。那么將這個詞語拆分為三個部分。
超文本傳輸協(xié)議
"超文本"和"文本"相比多了一個字"超"，這樣看來比文本豐富，因為它可以將多種文本/圖像等進行混合，更重要的是可以從一個文本跳轉(zhuǎn)到另一個文本(文本連接)。
"傳輸"，傳輸?shù)倪^程中需要溝通，溝通即可能一對一溝通也可能一對多溝通(進行內(nèi)容協(xié)商)，無論怎么樣，參加溝通的人數(shù)>1，想盡一切一切辦法更快更好的完成相應(yīng)的任務(wù)。
"協(xié)議"，無規(guī)矩不成方圓，做機密項目之前需要簽署保密協(xié)議，找工作要簽"三方協(xié)議"，三方協(xié)議是學校，公司，和個人組成的協(xié)議，都是為了讓大家受一定的約束，違反了即有相應(yīng)的懲罰。
三方協(xié)議
HTTP/0.9
當時網(wǎng)絡(luò)資源匱乏，0.9版本相對簡單，采用純文本格式，且設(shè)置為只讀，所以當時只能使用"Get"的方式從服務(wù)器獲得HTML文檔，響應(yīng)以后則關(guān)閉。如下圖所示
GET /Mysite.html
響應(yīng)中只包含了文檔本身。響應(yīng)內(nèi)容無響應(yīng)頭，無錯誤碼，無狀態(tài)碼，可以說是"裸奔"。
<HTML>
Hello world
</HTML>
HTTP/1.0
此時HTTP/0.9請求過程如下
HTTP 0.9
HTTP1.0
隨著時代的進步，僅僅文本的傳輸無法滿足需求，更多情況需要采用圖文的方式才能生動的表達出自己的觀點。隨著1995年開發(fā)出Apache，同時其他的多媒體等技術(shù)發(fā)展迅速，從而進一步的促使HTTP新功能的出現(xiàn)。HTTP1.0在1996年誕生，增加了一下幾個方面：
典型的請求過程
GET /image.html HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64)
200 OK
Date: Tue, 17 Nov 2020 09:15:31 GMT
Content-Type: text/html
<HTML>
一個包含圖片的頁面
<IMG SRC="/image.gif">
</HTML>
HTTP1.0通信過程
HTTP1.0
HTTP /1.1
1995年是不平凡的一年，網(wǎng)景公司和微軟開啟瀏覽器大戰(zhàn)，誰都想當老大。1999年HTTP/1.1發(fā)布并成為標準，寫入RFC，以為以后不管是網(wǎng)關(guān)還是APP等，只要你要使用HTTP，就得遵守這個標準。
隨著文件越來越大，圖片等信息越來越復(fù)雜，如果每一次上傳下載文件都需要建立連接斷開連接的過程將增加大量的開銷。為此，提出了持久連接，也就是一次TCP連接可以具有多個HTTP請求。當然持久連接是可選擇的，如果考慮關(guān)閉，只需要使用Connecttion:close關(guān)閉即可。長連接如下圖所示
長連接
我們知道，在電商系統(tǒng)中，經(jīng)常會因為促銷活動導致流量飆升，為了緩解流量，其中有種方法即加緩存或者加服務(wù)器。如果是單臺服務(wù)器負載過大，數(shù)據(jù)庫可能分庫分表。數(shù)據(jù)結(jié)構(gòu)算法中分而治之方法亦是如此。那么HTTP中，同樣的道理，如果文件太大，就大文件切分為小文件塊發(fā)送。
HTTP /2
HTTP/1.1的出現(xiàn)，幾年間出來大量牛掰的互聯(lián)網(wǎng)公司，發(fā)展實在是太快，但是HTTP1.1中這幾點成為詬病
顧名思義，"慢啟動"從0到1循循漸進。轎車啟動不會按下按鈕就直接起飛，而是緩慢調(diào)節(jié)到適合的速度。這不是挺好的？為什么會帶來性能問題呢。我們知道一個頁面有靜態(tài)數(shù)據(jù)，動態(tài)頁面，很多小文件在加載的過程中就會直接發(fā)起請求，這樣導致太多的請求都會經(jīng)歷慢啟動過程，花費時間太多。
帶寬固定，多條TCP連接同時發(fā)起競爭帶寬資源，由于各個TCP連接之間沒有通信機制，也無法得知哪些資源優(yōu)先級更高，從而導致想快速下載的資源反而延遲下載。
阻塞，在網(wǎng)絡(luò)編程中，我們采用異步，多路復(fù)用(epoll)方式盡量讓cpu少等待多干事。在HTTP1.1中，雖然大家共用了一條TCP通道，但是第一個請求沒有結(jié)束，第二請求就可能阻塞等待，也就是說不能同時發(fā)送接收數(shù)據(jù)。那么一個網(wǎng)頁很多數(shù)據(jù)文件，如果能夠同時發(fā)出請求，讓部分數(shù)據(jù)文件能夠得到響應(yīng)并預(yù)處理，這樣就大大的利用了帶寬和cpu的資源。基于這些因素，在HTTP2中出現(xiàn)了新的方案
如何解決頭部阻塞呢？
HTTP是一問一答的模式，大家都在這個隊列排隊導致堵塞，那就多個隊列并發(fā)進行，也就是"對同一個域名發(fā)起多個長連接"。舉個例子，在火車站排隊買票的時候，如果只有一個窗口可用，大家只能苦等，多開幾個窗口就可緩解這個問題。
這個時候用戶數(shù) * 并發(fā)數(shù)(上限6-8)已經(jīng)不錯得效果，但是互聯(lián)網(wǎng)速度太快，火車站就這么大，窗口也就這么多，怎么辦，建新的火車站進行分流(大部分城市都有什么東站 西站)。在這里叫做"域名分片"，使用多個域名，這些域名指向同一服務(wù)器。
HTTP/3
HTTP/2看似很完美了吧，但是Google輪子哥可不服，其他人在研究HTTP/2的時候，它們就在琢磨QUIC。那QUIC有啥牛掰的地方呢
QUIC是Google開發(fā)的一個基于UDP且能像TCP一樣具有可靠性特點的協(xié)議。具備像HTTP/2一樣的應(yīng)用數(shù)據(jù)二進制分幀傳輸。其主要解決的問題有兩個。
客戶端與服務(wù)端進行交互的信息為報文。客戶端為請求報文，服務(wù)端為響應(yīng)報文。我們先用wireshark抓一個博客看看
報文層次結(jié)構(gòu)
GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip
請求報文
請求報文
請求報文通常由三部分組成：
起始行：描述請求或者響應(yīng)的基本信息
頭部字段集合：key-value形式說明報文
消息正文：實際傳輸諸如圖片等信息。具體如下圖試試
1 請求方法：一共有八種方法選擇，如下圖所示。采用不同的方法獲取不同的資源
HTTP請求方法詳解
說一下非常常見的幾種請求方法
Get：從服務(wù)器中取資源。可以請求圖片，視頻等
HEAD:和Get類似，但是從服務(wù)器請求的資源不會返回請求的實體數(shù)據(jù)，只會返回響應(yīng)頭
POST/PUT：對應(yīng)于GET，向服務(wù)器發(fā)送數(shù)據(jù)
2 URI
統(tǒng)一資源標識符(Uniform Resource Identifier),嚴格來說不等于網(wǎng)址，它包含URL和URN，可是URL太出名了以致于URL="網(wǎng)址"。無論開發(fā)，測試運維配置都離不開URI,所以好好掌握。
網(wǎng)絡(luò)層的IP主要目的是解決路由和尋址。現(xiàn)在的IP地址按照"."分割，總共2的32次方大約42億。對于計算機來說比較方便，但是對于人類來說還是不容易記憶，此時出現(xiàn)DNS了，他把IP地址映射為我們平時常見的"redis.org"，按照"."分割域名，從左到右級別越高，最右邊為"頂級域名"。如下圖所示
域名體系
好了，現(xiàn)在TCP提供可靠(數(shù)據(jù)不丟失)且字節(jié)流(數(shù)據(jù)完整性)，而且也有方便我們記憶的域名，但是互聯(lián)網(wǎng)資源千萬種，也不知道訪問什么(圖片，文字，視頻一大堆)，這個時候URI(統(tǒng)一資源標識符)出現(xiàn)了，那長啥樣？
URI格式
協(xié)議名:HTTP協(xié)議，另外還有ftp等協(xié)議。告知訪問資源時使用什么協(xié)議。
緊接著是分隔符:"://"
主機名：標記互聯(lián)網(wǎng)主機，可以是IP也可以是域名，如果不寫端口則使用默認端口，例如HTTP為80，HTTPS為443.
登錄認證信息：登錄主機時的用戶名密碼(不建議，直接告訴了別人你的隱私信息)
主機名：此處可以是域名也可以是IP，如果不寫端口號則是默認端口。比如HTTP默認端口為80，HTTPS默認端口為443
資源所在位置：資源在主機上的位置，使用“/”分隔多級目錄，在這里是“/en/download.html”。注意，必須"/"開頭
參數(shù)：用"?"開始，表示額外的請求要求。通常使用"key=value"的方式存在，如果多個"key=value"則使用"&"相連。
看幾個例子
http://nginx.org/en/download.html
file:///E:/Demo/index/
這里注意是三個"///"，因為前面"://"作為分隔符，資源路徑按照"/"開頭。
既然規(guī)則這么多，對于接收方而言需要完成的解析也需要遵守規(guī)則，全球用戶很多使用HTTP，每個國家地區(qū)所使用語言不同，HTTP為了能對其進行統(tǒng)一處理，引入了URI編碼，方法比較簡單，將非ASCII或者特殊字符全部轉(zhuǎn)換為十六進制字節(jié)值，同時在前面加入"%"。比如空格被轉(zhuǎn)換為"%20","中國"就編碼為"%E4%B8%AD%E5%9B%BD%0A"。
3 請求體
響應(yīng)報文
響應(yīng)報文
狀態(tài)行----服務(wù)器響應(yīng)的狀態(tài)
<1> 版本號：使用的HTTP什么版本
<2> 狀態(tài)碼：不同數(shù)字代表不同的結(jié)果，就如我們在編碼時，通過返回不同的值代表不同的語義。
狀態(tài)碼一共分為5類。
1××：處于中間狀態(tài)，還需后續(xù)操作
2××：成功收到報文并正確處理
"200 OK"
最常見的成功狀態(tài)碼，表示一切正常，客戶端獲得期許的處理結(jié)果。如果不是Head請求，那么在響應(yīng)頭中通常會有body數(shù)據(jù)。
"204 No Content"
這個的含義和"200"很相似，不同之處在于它的響應(yīng)頭中沒有body數(shù)據(jù)。
"206 Partial Content"
是 HTTP 分塊下載或斷點續(xù)傳的基礎(chǔ)，在客戶端發(fā)送“范圍請求”、要求獲取資源的部分數(shù)據(jù)時出現(xiàn)，它與 200 一樣，也是服務(wù)器成功處理了請求，但 body 里的數(shù)據(jù)不是資源的全部，而是其中的一部分。狀態(tài)碼 206 通常還會伴隨著頭字段“Content-Range”，表示響應(yīng)報文里 body 數(shù)據(jù)的具體范圍，供客戶端確認，例如“Content-Range: bytes 0-99/5000”，意思是此次獲取的是總計 5000 個字節(jié)的前 100 個字節(jié)。
3××：重定向到其他資源位置
"301 Moved Permanently"
“永久重定向”，意思是本地請求的資源以及不存在，使用新的URI再次訪問。
“302 Found”
“Moved Temporarily”，“臨時重定向”，臨時則所請求的資源暫時還在，但是目前需要用另一個URI訪問。
301 和 302 通過在字段Location中表明需要跳轉(zhuǎn)的URI。兩者最大的不同在于一個是臨時改變，一個是永久改變。舉個例子，有時候需要將網(wǎng)站全部升級為HTTPS，這種永久性改變就需要配置永久的"301"。有時候晚上更新系統(tǒng)，系統(tǒng)暫時不可用，可以配置"302"臨時訪問，此時不會做緩存優(yōu)化，第二天還會訪問原來的地址。
“304 Not Modified”
運用于緩存控制。它用于 If-Modified-Since 等條件請求，表示資源未修改，可以理解成“重定向已到緩存的文件”（即“緩存重定向”）。
4××：請求報文有誤，服務(wù)器無法處理
"400 Bad Request”
通用錯誤碼，表示請求報文有錯誤，但是這個錯誤過于籠統(tǒng)。不知道是客戶端還是哪里的錯誤，所以在實際應(yīng)用中，通常會返回含有明確含義的狀態(tài)碼。
“403 Forbidden”
注意了，這一個是表示服務(wù)器禁止訪問資源。原因比如涉及到敏感詞匯、法律禁止等。當然，如果能讓客戶端有一個清晰的認識，可以考慮說明拒絕的原因并返回即可。
“404 Not Found”
這可能是我們都知道且都不想看到的狀態(tài)碼之一，它的本意是想要的資源在本地未找到從而無法提供給服務(wù)端，但是現(xiàn)在，只要服務(wù)器"耍脾氣"就會給你返回 404，而我們也無從得知后面到底是真的未找到，還是有什么別的原因，
"405 Method Not Allowed"
獲取資源的方法好幾種，我們可以對某些方法進行限制。例如不允許 POST 只能 GET；
"406 Not Acceptable"
客戶端資源無法滿足客戶端請求的條件，例如請求需要中文但只有英文；
"408 Request Timeout"
請求超時，服務(wù)器等待了過長的時間；
"409 Conflict"：
多個請求發(fā)生了沖突，可以理解為多線程并發(fā)時的競態(tài)；
413 Request Entity Too Large：
請求報文里的 body 太大；
414 Request-URI Too Long：請求行里的 URI 太大；
429 Too Many Requests：客戶端發(fā)送了太多的請求，
通常是由于服務(wù)器的限連策略；
431 Request Header Fields Too Large：請求頭某個字
段或總體太大；
5××：服務(wù)器錯誤，服務(wù)器對請求出的時候發(fā)生內(nèi)部錯誤。
“500 Internal Server Error”
和400 類似，屬于一個通用的錯誤碼，但是服務(wù)器到底是什么錯誤我們不得而知。其實這是好事，盡量少的將服務(wù)器資源暴露外網(wǎng)，盡量保證服務(wù)器的安全。
“502 Bad Gateway”
通常是服務(wù)器作為網(wǎng)關(guān)或者代理時返回的錯誤碼，表示服務(wù)器自身工作正常，訪問后端服務(wù)器時發(fā)生了錯誤，但具體的錯誤原因也是不知道的。
“503 Service Unavailable”
表示服務(wù)器當前很忙，暫時無法響應(yīng)服務(wù)，我們上網(wǎng)時有時候遇到的“網(wǎng)絡(luò)服務(wù)正忙，請稍后重試”的提示信息就是狀態(tài)碼 503。
503 是一個“臨時”的狀態(tài)，
暫時比較忙，稍后提供服務(wù)。在響應(yīng)報文中的“Retry-After”字段，指示客戶端可以在多久以后再次嘗試發(fā)送請求。
4 請求體
上面大部分都是涉及到header部分，還有非常重要的body，everybody
頭字段注意事項
<1> 字段名不區(qū)分大小寫，例如“Host”也可以寫成“host”，但首字母大寫的可讀性更好；
<2> 字段名里不允許出現(xiàn)空格，可以使用連字符“-”，但不能使用下劃線"_"。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正確的字段名；
<3> 字段名后面必須緊接著“:”，不能有空格，而":"后的字段值前可以有多個空格；
<4> 字段的順序是沒有意義的，可以任意排列不影響語義；
<5> 字段原則上不能重復(fù)，除非這個字段本身的語義允許，例如 Set-Cookie。
HTTP的body常常被分為這幾種的類別
<1> text:超文本text/html,純文本text/plain
<2> audio/video:音視頻數(shù)據(jù)
<3> application: 可能是文本，也可能是二進制，交給上層應(yīng)用處理
<4> image: 圖像文件。image/png等
但是帶寬一定，數(shù)據(jù)大了通常考慮使用壓縮算法進行壓縮，在HTTP中使用Encoding type表示，常用的壓縮方式有下面幾種
<1> gzip:
一種數(shù)據(jù)格式，默認且目前僅使用deflate算法壓縮data部分
<2> deflate:
deflate是一種壓縮算法，是huffman編碼的一種加強
<3> br:
br通過變種的LZ77算法、Huffman編碼以及二階文本建模等方式進行數(shù)據(jù)壓縮，其他壓縮算法相比，它有著更高的壓塑壓縮效率
使用相應(yīng)的壓縮方法在帶寬一定的情況下確實有不錯的效果，但是gzip等主要針對文件壓縮效果不錯，但是對視頻就不行了。這個時候是不是可以使用數(shù)據(jù)結(jié)構(gòu)中常用的分而治之，大化小再合并的方式呢，
文件拆分
ok，在報文中使用"Transer-Encoding:chunked"表示，代表body部分數(shù)據(jù)是分塊傳輸的。另外在body中存在一個content-length字段表示body的長度，兩者不能共存，另外很多時候是流式數(shù)據(jù)，body中沒有指明content-length，這個時候一般就是chunked傳輸了。
現(xiàn)在可以通過采用分塊的方式增強帶寬的利用率，那他的編碼規(guī)則如何呢
<1> 每一個分塊包含長度和數(shù)據(jù)塊
<2> 長度頭按照CRLF結(jié)束
<3> 數(shù)據(jù)塊在長度快后，且最后CRLF結(jié)尾
<4> 使用長度0表示結(jié)束，"0\r\n\r\n"
我們還是看圖加深印象
chunked分塊
分塊解決了咋們一部分問題，但是有的時候我們想截斷發(fā)送怎么辦呢。在HTTP中提供了使用字段“Accept - Ranges: bytes”，明確告知客戶端：“我是支持范圍請求的”。那么Range范圍是怎樣的呢，Range從0開始計算，比如Range:0-5則讀取前6個字節(jié)，服務(wù)器收到了這個請求，將如何回應(yīng)呢
<1> 合法性檢查。比如一共只有20字節(jié)，但是請求range：100-200。此時會返回416----"范圍請求有誤"
<2> 范圍正常，則返回216，表示請求數(shù)據(jù)知識一部分
<3> 服務(wù)器端在相應(yīng)投資端增加Content-Range,格式"bytes x-y/length"。
敲黑板：斷點續(xù)傳怎么操作？
<1> 查看服務(wù)器是否支持范圍請求并記錄文件大小
<2> 多個線程分別負責不同的range
<3> 下載同時記錄進度，即使因為網(wǎng)絡(luò)等原因中斷也沒事，Range請求剩余即可
現(xiàn)在我們通過MIME-TYPE和Encoding-type可以知道body部分的類型，下一步將是對內(nèi)容進行協(xié)商。HTTP中，請求體中使用Accept告訴服務(wù)端需要什么類型數(shù)據(jù)(我能處理哪些類型數(shù)據(jù))，響應(yīng)頭中使用Content表明發(fā)送了什么類型數(shù)據(jù)，具體如下圖所示
好了，為了各個國家民族順利友好的溝通和明確的區(qū)分。HTTP請求頭中使用"type-subtype"，注意此時分隔符是"-"。比如en-GB表示英式英語，zh-CN表示常用的漢語，那對于客戶端而言，它通過Accept-Language來標記自己可以理解的自然語言，對應(yīng)的服務(wù)端使用Content-Language表明實體數(shù)據(jù)使用的語言類型，如下圖所示。
字符集和編碼
Cookie機制
HTTP是無狀態(tài)、無記憶的，Cookie機制的出現(xiàn)讓其有記憶功能，是怎么個實現(xiàn)呢
Cookie
從上圖我們可以知道Cookie是由瀏覽器負責存儲，并不是操作系統(tǒng)負責，我們換個瀏覽器打開同樣的網(wǎng)頁，服務(wù)就認不出來了。
Cookie常見的應(yīng)用一個是身份識別，一個是廣告追蹤，比如我們在訪問網(wǎng)頁視頻或者圖片的時候，廣告商會悄悄給我們Cookie打上標記，方便做關(guān)聯(lián)分析和行為分析，從而給我推薦一些相關(guān)內(nèi)容。
HTTP代理
之前介紹的都是一問一答的情景，但是在大部分的情況下都會存在多臺服務(wù)器進行通信服務(wù)。其中比較常見的就是在請求方與應(yīng)答方中間增加一個中間代理。
代理
代理作為中間位置，相對請求方為服務(wù)端，相當于后端服務(wù)端為請求方。代理常見的功能為負載均衡。在負載均衡中需要區(qū)分正向代理與反向代理，其中也就會涉及調(diào)度算法，比如輪詢，一致性哈希等。
正向代理與反向代理
那么問題來了，代理作為隱藏身份，相當于隱藏了真實的客戶端與服務(wù)端，那在是不是
好人占多數(shù)，壞人也不少。總有些要搞壞事，因為HTTP是明文，所以需要想辦法保護明文，從而出現(xiàn)了https。
安全是什么
安全四要素
機密性
對信息進行保密，只能可信的人可以訪問(讓我想起時間管理者)。
完整性
數(shù)據(jù)在傳輸過程中內(nèi)容不被"篡改"。雖然機密性對數(shù)據(jù)進行保密了，但是有上策也有下策(hack)
身份認證
證明自己的身份是本人，保證其消息發(fā)給可信的人
不可否認
君子一言駟馬難追，說話算數(shù)，說過的話做過的事要有所保證
HTTPS
HTTP和HTTPS
從上圖我們知道HTTPS無非是在傳輸層和應(yīng)用層中間加了一層TLS，正是TLS緊跟當代密碼學的步伐，盡全力的保障用戶的安全。老規(guī)矩，我們用wireshark看看長什么樣子。
TLS
可以看出在交互的過程中多了不少新東西，了解TLS,TLS由SSL握手協(xié)議，SSL修改密碼規(guī)范協(xié)議，SSL警報協(xié)議，SSL記錄協(xié)議組成。
TLS組成
SSL握手協(xié)議：
相對于三次握手
記錄協(xié)議
記錄為TLS發(fā)送接收數(shù)據(jù)的基本單位。它的自協(xié)議需要通過記錄協(xié)議發(fā)出。如果多個紀錄數(shù)據(jù)則可以一個TCP包一次性發(fā)出。
警報協(xié)議
類似HTTP狀態(tài)碼，通過反饋不同的消息進行不同的策略。
變更密碼規(guī)范協(xié)議
告訴對方，從此刻開始，后續(xù)的數(shù)據(jù)將使用加密算法進行加密再傳輸。
對稱加密與非對稱加密
對稱加密
對稱加密，顧名思義，加密方與解密方使用同一鑰匙(秘鑰)。具體一些就是，發(fā)送方通過使用相應(yīng)的加密算法和秘鑰，對將要發(fā)送的信息進行加密；對于接收方而言，使用解密算法和相同的秘鑰解鎖信息，從而有能力閱讀信息。
對稱加密
非對稱加密
在對稱加密中，發(fā)送方與接收方使用相同的秘鑰。那么在非對稱加密中則是發(fā)送方與接收方使用的不同的秘鑰。其主要解決的問題是防止在秘鑰協(xié)商的過程中發(fā)生泄漏。比如在對稱加密中，小藍將需要發(fā)送的消息加密，然后告訴你密碼是123balala,ok,對于其他人而言，很容易就能劫持到密碼是123balala。那么在非對稱的情況下，小藍告訴所有人密碼是123balala,對于中間人而言，拿到也沒用，因為沒有私鑰。所以，非對稱密鑰其實主要解決了密鑰分發(fā)的難題。如下圖
非對稱加密
其實我們經(jīng)常都在使用非對稱加密，比如使用多臺服務(wù)器搭建大數(shù)據(jù)平臺hadoop，為了方便多臺機器設(shè)置免密登錄，是不是就會涉及到秘鑰分發(fā)。再比如搭建docker集群也會使用相關(guān)非對稱加密算法。
混合加密
非對稱加密算法，大多數(shù)是從數(shù)學問題演變而來，運算速度較慢。混合加密所謂取長補短。通信過程中使用RSA等解決密鑰交換問題，然后使用隨機數(shù)產(chǎn)生的在對稱算法中的會話密鑰，最后使用加密。對方使用私鑰解密得到的密文取出會話秘鑰，這樣就實現(xiàn)了密鑰交換。
混合加密
通過混淆加密等方式完成了機密性任務(wù)，作為Hack只需要偽造發(fā)布公鑰或者作為之間人竊聽密文。但是我們知道安全是四要素，還需要保證數(shù)據(jù)的完整性，身份認證等。
摘要
摘要算法可以理解為一種特殊的"單向"加密算法，無密鑰，不可逆。在平時項目中，應(yīng)該大家都是用過MD5，SHA-1。但是在TLS中使用SHA-2。
假設(shè)小A轉(zhuǎn)賬5000給小C，小A加上SHA-2摘要。網(wǎng)站計算摘要并對比，如果一致則完整可信。
摘要可信
此時小B想修改小A給的money，這個時候網(wǎng)站計算摘要就會發(fā)現(xiàn)不一樣，不可信
摘要不可信
HTTPS請求建立連接過程
HTTP握手過程
注意：
根據(jù)wireshak結(jié)果，對TLS進一步剖析。TCP三次握手建立連接，作為禮貌，Client先打招呼"Client Hello"。里面包含了Client的版本號、所支持的密碼套件和隨機數(shù)，如下圖所示
Client Hello
Server端表示尊重，回復(fù)"Server Hello",同時進行版本校對，給出隨機數(shù)(Server Random)，從Client算法列表中選擇一個密碼套件，在這里選擇的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"。
cipher Suite
這里的"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"什么意思呢
密碼套件選擇橢圓曲線加RSA、AES、SHA256
雙方通過證書驗證身份。因為本機服務(wù)器選用了ECDHE算法，為了實現(xiàn)密鑰交換算法，它會發(fā)送證書后把橢圓曲線的公鑰（Server Params）連帶"Server Key Exchange"消息發(fā)送出去。
Server Key Exchange
意思是，剛才混合加密套件比較復(fù)雜，給你個算法參數(shù)，好好記住，別弄丟了。
ServerHelloDone
隨后服務(wù)端回復(fù)"hello done"告知打招呼完畢
打完招呼完畢后，客戶端對證書進行核實。然后根據(jù)密碼套件也生成橢圓曲線的公鑰，用"Client Key Exchange"消息發(fā)給服務(wù)器
Client Key Exchange
此時客戶端和服務(wù)端都有了密鑰交換的兩個參數(shù)(Client Params、ServerParams），然后通過 ECDHE 算法算出了一個新的值，叫“Pre-Master”
有了主密鑰和會話密鑰，客戶端發(fā)送“Change Cipher Spec”和“Finished”消息，最后將所有消息加上摘要發(fā)送給服務(wù)器驗證。
服務(wù)器同樣發(fā)送“Change Cipher Spec”和“Finished”消息，握手結(jié)束，開始進行HTTP請求與響應(yīng)
4 初探域名
我們知道域名的出現(xiàn)讓我們更容易記憶，按照"."分割，越靠近右邊級別越高。域名本質(zhì)是一個名字空間系統(tǒng)，采用多級域名的方式區(qū)分不同的國家，公司等，作為一種身份的標識。
根域名服務(wù)器（Root DNS Server）：管理頂級域名服務(wù)器，返回“com”“net”“cn”等頂級域名服務(wù)器的 IP 地址；
頂級域名服務(wù)器（Top-level DNS Server）：管理各自域名下的權(quán)威域名服務(wù)器，比如
com 頂級域名服務(wù)器可以返回 apple.com 域名服務(wù)器的 IP 地址；
權(quán)威域名服務(wù)器（Authoritative DNS Server）：管理自己域名下主機的 IP 地址，比如apple.com 權(quán)威域名服務(wù)器可以返回 www.apple.com 的 IP 地址**
寫到這里，說它簡單是假的，簡單的東西通常更具有擴展的可能性。根據(jù)需求的變更，越來越復(fù)雜。
1：靈活且易擴展，他的頭部字段很多都是可定制且可擴展
2：應(yīng)用廣泛。各個領(lǐng)域都有涉及。"跨平臺，跨語言"
3：無狀態(tài)。沒有記憶功能，少功能即少占用資源。另外無狀態(tài)更容易搭建集群，通過負載均衡將請求轉(zhuǎn)發(fā)到任意一臺服務(wù)器。缺點是無法支持需要連續(xù)步驟的"事務(wù)"操作。我們知道TCP協(xié)議有11種狀態(tài)，不同狀態(tài)代表通信過程中不同的含義。同樣操作系統(tǒng)中的進程也有執(zhí)行，就緒，活動阻塞等多種狀態(tài)。但是HTTP全程都是"懵逼"無狀態(tài)。比如小華請求服務(wù)器獲取視頻X，服務(wù)器覺得可行就發(fā)給小華。小華還想獲取視頻Y，這時服務(wù)器不會記錄之前的狀態(tài)，也就不知道這兩個請求是否是同一個，所以小華還得告訴服務(wù)器自己的身份。
4：明文。優(yōu)點是能讓開發(fā)人員通過wireshark工具更直觀的調(diào)試。缺點即裸奔互聯(lián)網(wǎng)，沒隱私可言。
5:可靠傳輸。HTTP為應(yīng)用層協(xié)議，基于TCP/IP，而TCP為“可靠”傳輸協(xié)議，因此HTTP能在請求應(yīng)答中"可靠"傳輸數(shù)據(jù)。
6：應(yīng)用層協(xié)議。應(yīng)用層協(xié)議很多，其中常用的郵件協(xié)議SMTP，上傳下載文件ftp，默認端口22/23，SSH遠程登錄(XSHELL)。這些應(yīng)用層協(xié)議都太專一，而HTTP通過各種頭部字段，實體數(shù)據(jù)的組合，并綜合緩存代理等功能，不得不說是網(wǎng)絡(luò)中的冠希哥。
這里說的識別，通過代碼層面(libpcap封裝)實現(xiàn)HTTP的識別，也能進一步體現(xiàn)TCP/IP協(xié)議棧的分層特性。先看回憶一下IP頭部格式。
IP頭部
注意頭部中的協(xié)議字段，如果此字段值為0x0600則為TCP分組。當知道了是TCP分組后，是不是可以通過TCP頭部中端口(80)就可以判斷為HTTP呢，不能的，很多情況都會使用動態(tài)端口的方式進行部署。此時可以通過HTTP中的關(guān)鍵字進行判斷。如果為HTTP，再通過頭部字段中的"Content-type"，charset等確認文本信息，編碼方式，最后采用解碼算法進行還原。
方法一也是比較直接的方法是直接通過抓包工具，插件配置即可。這里想給大家分享另一種思路和在Linux持續(xù)捕包的方法。
使用python的dpkt庫(pip install dpkt即可)，dpkt庫方便對每一層協(xié)議進行拆解，同時也能進行流的拆分以及特征的提取。下面舉一個通過無頭瀏覽的方式自動化采集流量(ps如果需要較大規(guī)模的流量采集則可以考慮使用docker集群的方式)
Read_pcap
SVM
識別結(jié)果
希望大家看完本文，下面的這些面試是不是可以秒殺了
RPC既可以基于TCP也可以基于HTTP協(xié)議，但是HTTP通常都是基于HTTP
RPC可以基于thrift實現(xiàn)高效二進制傳輸。HTTP大部分通過json實現(xiàn)，無論從字節(jié)大小還是序列化耗時都比t'hrift耗時
RPC基本上自帶負載均衡策略，而HTTP需要配置Nginx實現(xiàn)。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
