近些年，隨著網域名稱劫持、資訊洩漏等網路安全事件的頻繁發生，**安全也變得越來越重要，也促成了網路傳輸協議從 http 到 https 再到 hsts 的轉變。
http（超文字傳輸協議） 是一種用於分布式、協作式和超**資訊系統的應用層協議。http 是網際網路資料通訊的基礎。它是由全球資訊網協會（w3c）和網際網路工程任務組（ietf）進行協調制定了 http 的標準，最終發布了一系列的 rfc，並且在2023年6月公布的 rfc 2616，定義了 http 協議中現今廣泛使用的乙個版本——http 1.1。
http 屬於 tcp/ip 模型中的應用層協議，當瀏覽器與伺服器進行互相通訊時，需要先建立tcp 連線，之後伺服器才會接收瀏覽器的請求資訊，當接收到資訊之後，伺服器返回相應的資訊。最後瀏覽器接受對伺服器的資訊應答後，對這些資料進行解釋執行。
△http 1.0 請求模式
http 1.0 時，瀏覽器每次訪問都要單獨建立連線，這會造成資源的浪費。
後來http 1.1可以在一次連線中處理多個請求，並且將多個請求重疊進行
△http 1.1 請求模式
簡單、快速、靈活：當使用者想伺服器傳送請求時，只需傳送請求方法和路徑即可，http 允許傳輸任意型別的資料物件。並且http協議簡單易用，http 伺服器規模小，保證了網路通訊的速度；
無連線、無狀態：http協議限制每次連線只處理單個請求，當伺服器收到使用者請求後就會斷開連線，保證了傳輸時間的節省。同時http協議對事務處理沒有記憶能力，如果後續的請求需要使用前面的資訊就必須重傳資料；
管線化和內容編碼：隨著管線化技術的出現，http 請求比永續性連線速度更快，並且當某些報文的內容過大時，為了減少傳輸的時間，http 會採取壓縮檔案的方式；
http 支援客戶/伺服器模式
http 協議由於其簡單快速、占用資源少，一直被用於**伺服器和瀏覽器之間進行資料傳輸。但是在資料傳輸的過程中也存在很明顯的問題，由於 http 是明文協議，不會對資料進行任何方式的加密。當黑客攻擊竊取了**伺服器和瀏覽器之間的傳輸報文的時，可以直接讀取傳輸的資訊，造成**、使用者資料的洩密。因此 http 不適用於敏感資訊的傳播，這個時候需要引入 https（超文字傳輸安全協議）。
https（hypertext transfer protocol secure ）是一種以計算機網路安全通訊為目的的傳輸協議。在http下加入了ssl層，從而具有了保護交換資料隱私和完整性和提供對**伺服器身份認證的功能，簡單來說它就是安全版的 http 。
△ http、https 差異
https在進行資料傳輸之前會與**伺服器和web瀏覽器進行一次握手，在握手時確定雙方的加密密碼資訊。
具體過程如下：
web 瀏覽器將支援的加密資訊傳送給**伺服器；
**伺服器會選擇出一套加密演算法和雜湊演算法，將驗證身份的資訊以證書（證書發布ca機構、證書有效期、公鑰、證書所有者、簽名等）的形式傳送給web瀏覽器；
當 web 瀏覽器收到證書之後首先需要驗證證書的合法性，如果證書受到瀏覽器信任則在瀏覽器位址列會有標誌顯示，否則就會顯示不受信的標識。當證書受信之後，web 瀏覽器會隨機生成一串密碼，並使用證書中的公鑰加密。之後就是使用約定好的雜湊演算法握手訊息，並生成隨機數對訊息進行加密，再將之前生成的資訊傳送給**；
△ chrome 瀏覽器 https安全標識
4. 當**伺服器接收到瀏覽器傳送過來的資料後，會使用**本身的私鑰將資訊解密確定密碼，然後通過密碼解密web瀏覽器傳送過來的握手資訊，並驗證雜湊是否與web瀏覽器一致。然後伺服器會使用密碼加密新的握手資訊，傳送給瀏覽器；
5. 最後瀏覽器解密並計算經過雜湊演算法加密的握手訊息，如果與服務傳送過來的雜湊一致，則此握手過程結束後，伺服器與瀏覽器會使用之前瀏覽器生成的隨機密碼和對稱加密演算法進行加密交換資料。
△ https 握手過程
為了保護資料的安全，https 運用了諸多加密演算法：
1. 對稱加密：有流式、分組兩種，加密和解密都是使用的同乙個金鑰。
例如：des、aes-gcm、chacha20-poly1305 等。
2. 非對稱加密：加密使用的金鑰和解密使用的金鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法效能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的資料長度也是有限的。
例如：rsa、dsa、ecdsa、 dh、ecdhe 等。
3. 雜湊演算法：將任意長度的資訊轉換為較短的固定長度的值，通常其長度要比資訊小得多，且演算法不可逆。
例如：md5、sha-1、sha-2、sha-256 等。
4. 數字簽名：簽名就是在資訊的後面再加上一段內容（資訊經過 hash 後的值），可以證明資訊沒有被修改過。hash 值一般都會加密後（也就是簽名）再和資訊一起傳送，以保證這個 hash 值不被修改。
但是當**傳輸協議從 http 到 https 之後，資料傳輸真的安全了嗎？
由於使用者習慣，通常準備訪問某個**時，在瀏覽器中只會輸入乙個網域名稱，而不會在網域名稱前面加上 http:// 或者 https://，而是由瀏覽器自動填充，當前所有瀏覽器預設填充的都是http://。一般情況**管理員會採用了 301/302 跳轉的方式由 http 跳轉到 https，但是這個過程總使用到 http 因此容易發生劫持，受到第三方的攻擊。
這個時候就需要用到 hsts（http 嚴格安全傳輸）。
△ http 請求劫持
hsts是國際網際網路工程組織 ietf 正在推行一種新的 web 安全協議，**採用 hsts 後，使用者訪問時無需手動在位址列中輸入 https，瀏覽器會自動採用 https 訪問**位址，從而保證使用者始終訪問到**的加密鏈結，保護資料傳輸安全。
hsts 主要是通過伺服器傳送響應頭的方式來控制瀏覽器操作：
1. 首先在伺服器響應頭中新增 hsts 響應頭：
strict-transport-security: max-age=expiretime [; includesubdomains] [; preload]2. 設定 max-age 引數，時間設定不宜過長，建議設定時間為 6 個月；
3. 當使用者下次使用 http 訪問，客戶端就會進行內部跳轉，並且能夠看到 307 redirect internel 的響應碼；
4. **伺服器變成了 https 訪問源伺服器。
開啟 hsts 後**可以有效防範中間人的攻擊，同時也會省去** 301/302 跳轉花費的時間，大大提公升安全係數和使用者體驗。
開啟 hsts 以後，可以到 ssllabs 進行測試，**的安全等級會進一步提公升。
開啟前等級為：a
開啟後等級變為：a+
從 http 到 https 再到 hsts，**的安全係數一直在上公升，防止 dns 劫持、資料洩密的力度也再加大。國內公有雲服務商比如又拍雲提供了完整的 https和hsts的解決方案，不僅支援 ssl 證書快速申請，https 一鍵部署，還支援一鍵開啟 hsts，感興趣的同學可以前往又拍雲官網了解。
從 HTTP 到 HTTPS 再到 HSTS
近些年，隨著網域名稱劫持 資訊洩漏等網路安全事件的頻繁發生，安全也變得越來越重要，也促成了網路傳輸協議從 http 到 https 再到 hsts 的轉變。http 超文字傳輸協議 是一種用於分布式 協作式和超 資訊系統的應用層協議。http 是網際網路資料通訊的基礎。它是由全球資訊網協會 w3c ...
從PGM到HMM再到CRF self note
問 有一點不太明白 想請教 mrf和crf看起來好像就是p x,y 和p y x 的差別，為什麼他們兩個模型的應用差距那麼的大呢？mrf廣泛運用在各種領域，crf大部分都用的linear 答 忽略掉生成模型和判別模型的差別，如果只是給定了觀測變數x要計算隱變數y的概率話，而不需要生成乙個新的樣本的話...
從CVPR，到ICCV，再到ECCV
記得大四我剛進實驗室做畢設的時候，看到一篇相關的 這篇 發表在cvpr上，當時我在想cvpr是個什麼東西，後來師兄告訴我這是我們計算機視覺領域乙個頂級國際會議的名字，它和iccv，eccv並稱為視覺三大。從此我潛意識裡一直覺得這些都是遙不可及的。轉眼兩年過去了，來到研二上學期。在過去的1年多時間裡，...