1為什麼需要https
使用https的原因其實很簡單，就是因為http的不安全。
當我們往伺服器傳送比較隱私的資料（比如說你的銀行卡，身份證）時，如果使用http進行通訊。那麼安全性將得不到保障。
首先資料在傳輸的過程中，資料可能被中間人抓包拿到，那麼資料就會被中間人竊取。
其次資料被中間人拿到後，中間人可能對資料進行修改或者替換，然後發往伺服器。
最後伺服器收到資料後，也無法確定資料有沒有被修改或替換，當然，如果伺服器也無法判斷資料就真的是**於客戶端。
https就是為了解決上述問題應運而生的。
2基本概念
為了解決http中存在的問題，https採用了一些加解密，數字證書，數字簽名的技術來實現。下面先介紹一下這些技術的基本概念
為了保證訊息的保密性，就需要用到加密和解密。加解密演算法目前主流的分為對稱加密和非對稱加密。
1.對稱加密（共享密匙加密）：客戶端和伺服器公用乙個密匙用來對訊息加解密，這種方式稱為對稱加密。客戶端和伺服器約定好乙個加密的密匙。客戶端在發訊息前用該密匙對訊息加密，傳送給伺服器後，伺服器再用該密匙進行解密拿到訊息。
對稱加密的優點：
對稱加密解決了http中訊息保密性的問題
對稱加密的缺點：
1.對稱加密雖然保證了訊息保密性，但是因為客戶端和伺服器共享乙個密匙，這樣就使得密匙特別容易洩露。
2.因為密匙洩露風險較高，所以很難保證****的可靠性、訊息的完整性和準確性。
2.非對稱加密（公有密匙加密）：既然對稱加密中，密匙那麼容易洩露，那麼我們可以採用一種非對稱加密的方式來解決。
採用非對稱加密時，客戶端和服務端均擁有乙個公有密匙和乙個私有密匙。公有密匙可以對外暴露，而私有密匙只有自己可見。
使用公有密匙加密的訊息，只有對應的私有密匙才能解開。反過來，使用私有密匙加密的訊息，只有公有密匙才能解開。這樣客戶端在傳送訊息前，先用伺服器的公匙對訊息進行加密，伺服器收到後再用自己的私匙進行解密。
非對稱加密的優點：
1.非對稱加密採用公有密匙和私有密匙的方式，解決了http中訊息保密性問題，而且使得私有密匙洩露的風險降低。
2.因為公匙加密的訊息只有對應的私匙才能解開，所以較大程度上保證了訊息的**性以及訊息的準確性和完整性。
非對稱加密的缺點：
非對稱加密時需要使用到接收方的公匙對訊息進行加密，但是公匙不是保密的，任何人都可以拿到，中間人也可以。那麼中間人可以做兩件事，第一件是中間人可以在客戶端與伺服器交換公匙的時候，將客戶端的公匙替換成自己的。這樣伺服器拿到的公匙將不是客戶端的，而是伺服器的。伺服器也無法判斷公匙**的正確性。第二件是中間人可以不替換公匙，但是他可以截獲客戶端發來的訊息，然後篡改，然後用伺服器的公匙加密再發往伺服器，伺服器將收到錯誤的訊息。
數字證書與數字簽名
為了解決非對稱加密中公匙**的不安全性。我們可以使用數字證書和數字簽名來解決。
1.數字證書的申請
在現實中，有一些專門的權威機構用來頒發數字證書，我們稱這些機構為認證中心（ca certificate authority）。
我們（伺服器）可以向這些ca來申請數字證書。
申請的過程大致是：
自己本地先生成一對密匙，然後拿著自己的公匙以及其他資訊（比如說企業名稱啊什麼的）去ca申請數字證書。
ca在拿到這些資訊後，會選擇一種單向hash演算法（比如說常見的md5）對這些資訊進行加密，加密之後的東西我們稱之為摘要。
單向hash演算法有一種特點就是單向不可逆的，只要原始內容有一點變化，加密後的資料都將會是千差萬別（當然也有很小的可能性會重複，有興趣的小夥伴鴿巢原理了解一下），這樣就防止了資訊被篡改。
生成摘要後還不算完，ca還會用自己的私匙對摘要進行加密，摘要加密後的資料我們稱之為數字簽名。
最後，ca將會把我們的申請資訊（包含伺服器的公匙）和數字簽名整合在一起，由此而生成數字證書。然後ca將數字證書傳遞給我們。
2.數字證書怎麼起作用
伺服器在獲取到數字證書後，伺服器會將數字證書傳送給客戶端，客戶端就需要用ca的公匙解密數字證書並驗證數字證書的合法性。那我們如何能拿到ca的公匙呢？我們的電腦和瀏覽器中已經內建了一部分權威機構的根證書，這些根證書中包含了ca的公匙。
之所以是根證書，是因為現實生活中，認證中心是分層級的，也就是說有頂級認證中心，也有下面的各個子級的認證中心，是乙個樹狀結構，計算機中內建的是最頂級機構的根證書，不過不用擔心，根證書的公匙在子級也是適用的。
客戶端用ca的公匙解密數字證書，如果解密成功則說明證書**於合法的認證機構。解密成功後，客戶端就拿到了摘要。
此時，客戶端會按照和ca一樣的hash演算法將申請資訊生成乙份摘要，並和解密出來的那份做對比，如果相同則說明內容完整，沒有被篡改。最後，客戶端安全的從證書中拿到伺服器的公匙就可以和伺服器進行安全的非對稱加密通訊了。伺服器想獲得客戶端的公匙也可以通過相同方式。
https原理
https的建立
1.客戶端通過傳送client hello報文開始ssl通訊。報文中包含客戶端支援的ssl的指定版本、加密元件（cipher suite）列表（所使用的加密演算法及密匙長度等）。
2.伺服器可進行ssl通訊時，會以server hello報文作為應答。和客戶端一樣，在報文中包含ssl版本以及加密元件。伺服器的加密元件內容時從接收到的客戶端加密元件內篩選出來的。
3.伺服器傳送證書報文。報文中包含公開密匙證書。
4.最後伺服器傳送server hello done報文通知客戶端，最初階段的ssl握手協商部分結束。
5.ssl第一次握手結束之後，客戶端以client key exchange報文作為回應。報文包含通訊加密中使用的一種被稱為pre-master secret的隨機密碼串。該報文已用步驟3中的公開密匙進行加密。
6.接著客戶端繼續傳送change cipher spec報文。該報文會提示伺服器，在此報文之後的通訊會採用pre-master secret密匙加密。
7.客戶端傳送finished報文。該報文包含連線至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標準。
8.伺服器同樣傳送change cipher spec報文
9.伺服器同樣傳送finished報文
10.伺服器和客戶端的finished報文交換完畢之後，ssl連線就算建立完成。當然，通訊會收到ssl的保護。從此處開始進行應用層協議的通訊，即傳送http請求。
11.應用層協議通訊，即傳送http相應。
12.最後由客戶端斷開連線。斷開連線時，傳送close_notify報文。上圖做了一些省略，這步之後再傳送tcp fin報文來關閉與tcp的通訊。
經過上面的介紹，我們可以看出https先是利用數字證書保證伺服器端的公匙可以安全無誤的到達客戶端。然後再用非對稱加密安全的傳遞共享密匙，最後用共享密匙安全的交換資料。
https的使用
https那麼的安全，是不是我們在什麼場景下都要去使用https進行通訊呢？答案是否定的。
1.https雖然提供了訊息安全傳輸的通道，但是每次訊息的加解密十分耗時，訊息系統資源。所以，除非在一些對安全性比較高的場景下，比如銀行系統，購物系統中我們必須要使用https進行通訊，其他一些對安全性要求不高的場景，我們其實沒必要使用https。
2.使用https需要使用到數字證書，但是一般權威機構頒發的數字證書都是收費的，而且**也是不菲的，所以對於一些個人**特別是學生來講，如果對安全性要求不高，也沒必要使用https。
閱讀筆記02
需求 需求收集方法 軟體需求可以來自方方面面，這取決於所開發產品的性質和開發環境。需從不同使用者代表和 收集需求，這說明了需求工程是以相互交流為核心的性質。下面是幾個軟體需求的典型 1 訪問並與有潛力的使用者 為找出新軟體產品的使用者需求，最直截了當的方法是詢問他們。2 把對目前的或競爭產品的描述寫...
閱讀筆記02
第二階段 需求分析階段 在第二個階段重點就是粒度的細化，從主題域我需要細化一層到識別了關鍵業務物件的領域檢視，從業務事件進行流程分析我們需要講業務事件細化一層到具體的業務活動，而業務活動正式我們在識別用例的時候的重要參考。所以在這裡我們基本清楚了第二階段剛開始是通過業務事件進行業務流程分析，業務實體...
閱讀筆記02
第六章 應對大型專案 1 常用的設計與實現方法 1 視覺化軟體過程和使用準則 2 重要的框架 3 積極的分解 4 多平台支援 5 物件導向技術 6 運算子過載 7 庫，元件和程序 8 對於處理的積極使用 2 大多數的大型專案使用乙個複雜的編譯過程，這類過程一般能夠處理配置選項 多種型別的輸入輸出檔案...