爬蟲之初識爬蟲

1,爬蟲的介紹:

• 引入

咱們都知道,咱們當前所處的環境是一個大數據的時代,油漆是互聯網,數掌握了數據,誰就掌握了市場的先機,要想掌控數據,就得先獲取數據,而爬蟲就可讓咱們獲取到數據源,而且這些數據源考科一根據咱們的目的進行採集

優酷的火星情報局就是基於網絡爬蟲和數據分析製做完成的,其中每期的節目話題都是從相關熱門的互動平臺進行相關數據的爬取,而後對爬取的數據進行數據分析而得來的,而另外一方面優酷根據用戶實時觀看視頻的前進,後退等行爲,可以推測出計算出冠照片那個的興趣點和愛好點,這樣有助於節目的剪輯和 後期節目方案的編寫.

今日頭條做爲一個新聞推薦類的應用,器內部的新聞數據都是經過爬蟲程序在各個新聞網站進行新聞數據的爬取,而後經過處理和運算將用戶感興趣的新聞話題推送到用戶的手機上

• 爬蟲簡介
• 爬蟲分類
• robots協議
• 反爬機制
• 反反爬策略

本節內容:

• 什麼是爬蟲:
  • 爬蟲就是經過編寫程序模擬瀏覽器上網,而後讓其去互聯網撒花姑娘抓取數據的過程
• 那些語言能夠實現爬蟲
  1. php:能夠實現爬蟲,可是php在實現爬蟲中支持多線程和多進程的當面作的很差
  2. java:能夠實現爬蟲,java能夠很是好的處理和實現爬蟲,是惟一能夠與python並駕齊驅且是python的頭號勁敵,可是java實現爬蟲代碼較爲臃腫,重構成本較大
  3. c,c++能夠實現爬蟲,可是使用這種方式實現爬蟲純粹是技術大牛的能力的體現,卻不是明智和合理的選擇
  4. python: 能夠實現爬蟲,Python實現和處理爬蟲語法簡單,代碼優美,支持的模塊繁多,學習成本低,具備很是強大的框架(scrapy框架)
• 爬蟲的分類
  1. 通用爬蟲:通用爬蟲是搜索引擎(Baidu,Google, Yahoo)"抓取系統"的重要組成部分.主要目的是將互聯網的網下載到本地,造成一個互聯網內容的鏡像備份,簡單來說簡單來說就是儘量的;把互聯網上全部的網頁下載下來,放到本地服務器裏造成備份,在對這些網頁作相關處理(處理關鍵字,去掉廣告),而後提供一個用戶檢索接口
     • 搜索引擎抓取互聯網上的網站數據
     • 門戶網站主動向搜索引擎公司提供其網站的url
     • 搜索引擎公司與DNS服務商合做, 獲取網站的url
     • 門戶網站主動掛靠在一些知名網站的友情鏈接中
  2. 聚焦爬蟲:聚焦爬蟲是根據指定的需求抓取網絡上指定的數據.列如:獲取豆瓣電影的名稱和影評,而不是獲取整張頁面中全部的數據值
     • robots.txt協議:若是本身的門戶網站中的指定頁面中的數據不想讓爬蟲程序爬到的話,name則能夠經過編寫一個robots.txt的協議文件來約束爬蟲程序的數據爬取.robots協議的編寫格式能夠觀察淘寶網的robots(www.taobao.com/robots.txt).可是須要注意的是,該協議執行只是至關於口頭的協議,並無使用相關技術輕質進行技術的管制,所以,該協議是防君子,不放小人
     • 反爬蟲:門戶網站經過相應的策略和技術手段,防止爬蟲程序進行網站數據的爬取
     • 反反爬策略:爬蟲程序經過相應的策略和 技術手段,破解門戶網站的反爬手段,從而爬取到相應的數據

2,python爬蟲的http協議和https

 

 

1. 官方概念:HTTP協議是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫,適用於萬維網(www:World Wide Web)服務器傳輸超文本到本地瀏覽器的傳輸協議
2. 白話概念:HTTP協議就是該服務器(Server)和客戶端(Client)之間進行數據交互(相互傳輸數據)的一種形式,咱們能夠將Server和Client進行擬人化,那麼該協議就是Server和Client這倆兄弟間進行指定的一種溝通方式.
3. HTTP工做原理:HTTP協議工做與客戶端-服務端架構上.瀏覽器做爲HTTP服務器接web服務器發送請求,web服務器根據收到的請求後,向客戶端發送響應信息
5. HTTP四點注意事項:
   
   1. HTTP容許傳輸任意類型的數據對象,正在傳輸的類型由Content-Type加以標記
   2. HTTP是無鏈接的,無鏈接的含義是限制每次鏈接值處理一個請求,服務器處理完客戶的請求,並受到客戶的應答後,即斷開鏈接.採用這種方式能夠節省傳輸時間
   3. HTTP是媒體獨立的,這意味着,只要客戶端和服務器知道如何處理數據的內容,任何類型的數據均可以 經過HTTP發送,客戶端以及服務器指定使用適合的MIME-type.
   4. HTTP是無狀態的:HTTP協議是無狀態協議,無狀態協議對於事物處理沒有記憶能力,缺乏狀態意味着若是後續處理須要前面的信息,則它必須重傳,這樣可能致使每次鏈接傳輸的數據量增大.另外一方面,在服務器不須要先前信息時它的應答就較快
   5. HTTP值url:HTTP使用統一 資源標識符(Uniform Resource Identifiers, URL)來傳輸數據和創建鏈接,URL是一種特殊的URL,包含了用於查找某個資源 的足夠到的信息
6. URL:全稱是UniformResourceLocator,中文叫統一資源定位符,是互聯網上用來標識某一處資源地址,一下面這個url爲例,介紹下普通url各組成部分: https://i.cnblogs.com/EditDiary.aspx?postid=10296205從這個url能夠看出包含如下幾部分:
   
   • 協議部分:該url的協議部分爲"https":,這個網頁表明使用的是HTTP協議,在Internet中農可使用多種協議,如HTTPS,FTP等,本例使用的是HTTPS協議 ,在HTTPS後邊的"//"表示分隔符
   • 域名部分:跟在域名後端的是端口.域名和端口之間用":"做爲分隔,端口不是一個URL必須的部分,若是省略端口部分 ,則採用默認端口
   • 虛擬目錄部分:從域名後的第一個"/"開始到最後一個爲止"/"是虛擬目錄部分,虛擬目錄也不是一個URL必須的部分,本例的虛擬部分是i.cnblogs.com
   • 文件名部分:從域名後的最後一個"/"開始到"?"爲止,是文件名部分,若是沒有"?",則是從域名的最後一個"/"開始到"#"爲止,是文件部分,若是沒有"?"和"#",那麼從域名後的最後一個"/"開始到結束,都是文件名的部分,本例中是:EditDiary.aspx
   • 錨部分:從"#"開始到最後,都是錨部分,本例中的錨部分是:沒有,錨部分也不是一個url的必須部分
   • 參數部分"從"?"開始到"#"爲止之間的部分爲參數部分,又稱搜索部分,查詢部分,本例的參數部分是:postid=10296205
7. HTTP之Request:

• • 客戶端 發送的一個HTTP請求到服務器的請求消息,包括如下組成部分:

• 報文頭:常被叫作請求體,請求體中存儲的是將要傳輸/發送給服務器的數據信息
• HTTP之Response:
• 服務器傳回一個HTTP響應都客戶端的響應信息包括如下幾部分:

狀態碼:以清晰的語言告訴客戶端本次請求的處理結果.

• HTTP響應狀態碼由5段組成:
  • 1xx消息,通常是告訴客戶端,請求已經收到了,正在處理,別急...
  • 2xx處理成功,通常表示:請求收悉,我明白你要的,請求已受理,已經處理完信息等
  • 3xx重定向到其餘地方,他讓客戶端再發起一個請求以完成處理結果
  • 4xx 處理髮生錯誤,責任在客戶端,如客戶端的一個請求不存在的資源,客戶端未被受權,禁止訪問等
  • 5xx處理髮生錯誤,責任在服務器,如服務端拋出異常,路由出錯,HTTP版本不支持等
• HTTP響應的詳解:
  • 100 Continue: 客戶端應當繼續發送請求這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收到了,且仍未被拒絕,客戶端應該當繼續發送請求的剩餘部分,或者若是請求已經完成,忽略這個響應.服務器必須在請求完成後向客戶端發送一個最終響應
  • 101 Switich Protocols: 服務器已經瞭解了客戶端的請求,並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求在發送完這個響應
  • 102 Processing:由WebDAV(RFC2518)擴展的狀態碼,表明處理將繼續執行
  • 200 OK: 請求成功,請求所但願的響應頭或數據體將隨此響應返回,出現此狀態碼錶示正常狀態.
  • 201 Created: 請求已經被實現,並且有一個新的資源已經依據請求的須要而創建,且器url已經隨Location頭信息返回,加入須要的資源,沒法及時創建,返回的是"202 Accepted"
  • 202 Accepted: 服務器已經接受請求,但還沒有處理.正如他可能被拒絕同樣,最終該請求可能會可能不會被執行,在異步操做的場合下,沒有比發這個狀態碼更方便的了, 返回202狀態的響應的目的是容許服務器接收其餘過程的請求(列如某個天天只執行一次的基於批處理的操做)而沒必要讓客戶一致保持與 服務器鏈接直到操做所有完成,在接收請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息,以及指向處理狀態預測的指針,以便用戶可以估計操做是否已經完成
  • 203 Non-Authoritative Information: 服務器已經處理了請求,但返回的實體頭部包括元信息不是在原始服務器上有效的肯定集合,而是來自本地或者第三方的拷貝,當前的信息多是原始版本的子集或者超集.列如,包含資源的元數據可能致使原始服務器知道元信息的超集.但用此狀態碼不是必須的,並且只有響應不使用此狀態便會返回200 ok的狀況下才是合適的.
  • 204 No Content: 服務器成功處理了請求, 但不須要返回任何實體內容,而且但願返回更新了的元信息.響應可能經過實體頭部的形狀返回新的或更新後的元信息,若是存在這些頭部信息,則應當與所請求的變量相呼應.,若是客戶端是瀏覽器的話,那麼用戶瀏覽器應保留髮送了該請求的頁面,而 不產生任何文檔視圖上的變化,即便按照規範新的或更新後的元信息應當被運用到用戶瀏覽器活動視圖中的文檔
  • 205 Reset Content: 服務器成功處理了請求,且沒有返回任何內容,可是與204響應不一樣,返回此狀態碼的響應要求請求者重置文檔視圖,該響應主要是被用於接收用戶輸入後,當即重置表單,以便可以輕鬆地開始另外一次輸入
  • 206 Partial Content: 服務器已經成功處理了部分GET請求,相似於flashGet或者迅雷這類的HTTP下載
    具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。
    該請求必須包含 Range 頭信息來指示客戶端但願獲得的內容範圍，而且可能包含 If-Range 來做爲請求條件。
    響應必須包含以下的頭部域：
    Content-Range 用以指示本次響應中返回的內容的範圍；若是是 Content-Type 爲 multipart/byteranges 的多段下載，則每一 multipart 段中都應包含 Content-Range 域用以指示本段的內容範圍。假如響應中包含 Content-Length，那麼它的數值必須匹配它返回的內容範圍的真實字節數。
    Date
    ETag 和/或 Content-Location，假如一樣的請求本應該返回200響應。
    Expires, Cache-Control，和/或 Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。
    假如本響應請求使用了 If-Range 強緩存驗證，那麼本次響應不該該包含其餘實體頭；假如本響應的請求使用了 If-Range 弱緩存驗證，那麼本次響應禁止包含其餘實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。不然，本響應就應當包含全部本應該返回200響應中應當返回的全部實體頭部域。
    假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與以前任何緩存過的內容組合在一塊兒。
  • 207 Multiple Choices: 
    被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。
    除非這是一個 HEAD 請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。
    若是服務器自己已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。
  • 301 Moved Permanently :
    被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。
    新的永久性的URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求，不然響應的實體中應當包含指向新的 URI 的超連接及簡短說明。
    若是這不是一個 GET 或者 HEAD 請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
    注意：對於某些使用 HTTP/1.0 協議的瀏覽器，當它們發送的 POST 請求獲得了一個301響應的話，接下來的重定向請求將會變成 GET 方式。
  • Moved temporarily:
    請求的資源臨時從不一樣的 URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。
    上文有說起。
    若是這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
    注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用 GET 方式訪問在 Location 中規定的 URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。
  •  
    303 See Other:
    對應當前請求的響應能夠在另外一個 URL 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。
    注意：許多 HTTP/1.1 版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。
  • 304 Not Modified: 
    若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。
    該響應必須包含如下的頭信息：
    Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。
    ETag 和/或 Content-Location，假如一樣的請求本應返回200響應。
    Expires, Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。
    假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。
    假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。
    假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。
  • 305 Use Proxy: 
    被請求的資源必須經過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。
    注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。
  • 306 Switch Proxy: 在最新版的規範中，306狀態碼已經再也不被使用。
  • 307 Temporary Redirect: 
    請求的資源臨時從不一樣的URI 響應請求。
    新的臨時性的URI 應當在響應的 Location 域中返回。除非這是一個HEAD 請求，不然響應的實體中應當包含指向新的URI 的超連接及簡短說明。由於部分瀏覽器不能識別307響應，所以須要添加上述必要信息以便用戶可以理解並向新的 URI 發出訪問請求。
    若是這不是一個GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
  • 400 Bad Request: 
    一、語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。
    二、請求參數有誤。
  • 401 Unauthorized: 當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。參見RFC 2617。
  • 402 Payment Required: 該狀態碼死爲了未來可能的需求而預留的
  • 403 Forbidden :服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個 HEAD 請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。
  • 404 Not Found:請求失敗，請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。出現這個錯誤的最有可能的緣由是服務器端沒有這個頁面。
  • 405 Method Not Allowed: 
    請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。
    鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。
  • Not Acceptable :
    請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。
    除非這是一個 HEAD 請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。
  • 407 Proxy Authentication Required: 與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端能夠返回一個 Proxy-Authorization 信息頭用以驗證。參見RFC 2617
  • 408 Request Timeout: 請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。
  • 409 Conflict :
    因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。
    衝突一般發生於對 PUT 請求的處理中。例如，在採用版本檢查的環境下，某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與以前的某個（第三方）請求向衝突，那麼此時服務器就應該返回一個409錯誤，告知用戶請求沒法完成。此時，響應實體中極可能會包含兩個衝突版本之間的差別比較，以便用戶從新提交歸併之後的新版本。
  • 410 Gone:  
    被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用404狀態碼。除非額外說明，不然這個響應是可緩存的。
    410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經再也不可用，而且服務器擁有者但願全部指向這個資源的遠端鏈接也被刪除。這類事件在限時、增值服務中很廣泛。一樣，410響應也被用於通知客戶端在當前服務器站點上，本來屬於某個我的的資源已經再也不可用。固然，是否須要把全部永久不可用的資源標記爲'410 Gone'，以及是否須要保持此標記多長時間，徹底取決於服務器擁有者
  • 500 Internal Server Error: 服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器端的源代碼出現錯誤時出現。
  • 501 Not Implemented: 服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求
  • 502 Bad Gateway: 做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應
  • 503 Server Unavaiable: 因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理500響應的方式處理它
  • 504 Gateway Timeout: 
    做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。
    注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤
  • 505 HTTP Version Not Supported: 服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。

詳情訪問網址:https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin

 

3,HTTPS協議:

1. 官方概念:HTTPS(secure Hypertext Transder Protocol)安全超文本傳輸協議,HTTPS是在HTTP上創建ssl加密層,並對傳輸數據 進行加密,HTTP協議的安全版
2. 普通理解:加了密鑰版的HTTP協議
3.  
4. HTTPS採用的加密技術
   • SSL加密技術:SSL採用的加密技術叫"共享密鑰加密",也叫做"對稱密鑰加密",這種加密方法是這樣的,好比客戶端向服務器發送一條消息,首先客戶端會採用已知的算法進行加密,好比md5或者base64加密,接收端加密的信息進行解密的時候須要用到密鑰,中間會傳遞密鑰,(加密和解密的密鑰是同一個),密鑰在傳輸過程當中是被加密的,這種方式看起來安全,可是仍有潛在的危險,一旦被竊聽,或者信息被挾持,就有可能破解密鑰,從而破解其中的信息.所以"共享密鑰加密"這種方式存在安全隱患:

   • 非對稱密鑰加密技術:"非對稱密鑰加密"使用的時候有2把鎖,一把叫作"公有私鑰"一把是"公開密鑰",使用非對象加密方式的時候,服務器首先告訴客戶端按照本身給定 的公開密鑰進行加密處理,客戶端按照公開密鑰加密之後,服務器接收到信息再經過本身的私有密鑰進行解密,這樣作的好處就是解密的密鑰根本不會進行傳輸,所以也就避免了被挾持的風險,就算公開密鑰被竊聽或者拿了,它也很難進行破解,由於解密過程是對離散對數求值,這可不是垂手可得就能作到的事.

   • 可是非對稱密鑰加密也存在以下缺點:
   • 第一個就是:如何保證接收端向發送端發出公開密鑰的時候,發送端確保收到的是預先要發送的,而不會被挾持,只要是發送密鑰,就有可能被挾持的可能
   • 第二個是:非對稱加密的方式效率比較低,它處理起來更復雜,通訊過程當中使用就有必定的效率問題而影響通訊速度
5. HTTPS的證書機構,在上面咱們講了非對稱加密的缺點,其中第一個就是公鑰極可能存在被挾持的狀況,沒法保證客戶端收到公開密鑰就是服務器發行的公開密鑰,此時就引出了公開密鑰證書機制,數字證書認證機構是客戶端與服務器均可信賴的第三方機構.證書的具體傳播過程以下:
   1. 服務器的開發者攜帶公開密鑰,向數字證書認證機構提出公開密鑰的申請,數字證書認證機構在認清申請者的身份,審覈經過後,會對開發申請的公開密鑰作數字簽名,而後分配這個已簽名的公開密鑰,並將密鑰放在證書裏,綁定在一塊兒.
   2. 服務器將這份數字證書發送給客戶端,由於客戶端也承認證書機構,客戶端能夠經過數字證書籤名來驗證公鑰的真僞,來確保服務器傳過來的公開密鑰是真實的,通常狀況下證書的數字簽名是很難僞造的,這取決於證書機構的公信力.一旦確認無誤後,客戶端會經過公鑰對報文進行加密發送.服務器接收到之後用本身的私鑰進行解密.
6.