最近在Istio實驗中經常遇到HTTP，HTTPS，TLS等名詞，感覺忘得差不多，需要復習一下計算機網絡的知識了。
本文參考 http://www.techug.com/post/https-ssl-tls.html
https://blog.fleeto.us/post/istio-security-notes/
1. “HTTP”是干嘛用滴？
首先，HTTP 是一個網絡協議，是專門用來幫你傳輸 Web 內容滴。關於這個協議，就算你不了解，至少也聽說過吧？比如你訪問博客的主頁，瀏覽器地址欄會出現如下的網址
http://www.techug.com/
加了粗體的部分就是指 HTTP 協議。大部分網站都是通過 HTTP 協議來傳輸 Web 頁面、以及 Web 頁面上包含的各種東東（圖片、CSS 樣式、JS 腳本）。
2. “SSL/TLS”是干嘛用滴？
SSL 是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明了很多 Web 的基礎設施——比如“CSS 樣式表”和“JS 腳本”）
為啥要發明 SSL 這個協議捏？因為原先互聯網上使用的 HTTP 協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是為了解決這些問題。
到了1999年，SSL 因為應用廣泛，已經成為互聯網上的事實標准。IETF 就在那年把 SSL 標准化。標准化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協議”。
很多相關的文章都把這兩者並列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。
3. “HTTPS”是啥意思？
解釋完 HTTP 和 SSL/TLS，現在就可以來解釋 HTTPS 啦。咱們通常所說的 HTTPS 協議，說白了就是“HTTP 協議”和“SSL/TLS 協議”的組合。你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差不多）。
再來說說 HTTP 協議的特點
作為背景知識介紹，還需要再稍微談一下 HTTP 協議本身的特點。HTTP 本身有很多特點，只談那些和 HTTPS 相關的特點。
1. HTTP 的版本和歷史
如今咱們用的 HTTP 協議，版本號是 1.1（也就是 HTTP 1.1）。這個 1.1 版本是1995年底開始起草的（技術文檔是 RFC2068），並在1999年正式發布（技術文檔是 RFC2616）。
在 1.1 之前，還有曾經出現過兩個版本“0.9 和 1.0”，其中的 HTTP 0.9 【沒有】被廣泛使用，而 HTTP 1.0 被廣泛使用過。
2. HTTP 和 TCP 之間的關系
簡單地說，TCP 協議是 HTTP 協議的基石——HTTP 協議需要依靠 TCP 協議來傳輸數據。
在網絡分層模型中，TCP 被稱為“傳輸層協議”，而 HTTP 被稱為“應用層協議”。
有很多常見的應用層協議是以 TCP 為基礎的，比如“FTP、SMTP、POP、IMAP”等。
TCP 被稱為“面向連接”的傳輸層協議。你只需知道：傳輸層主要有兩個協議，分別是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 協議想象成某個水管，發送端這頭進水，接收端那頭就出水。並且 TCP 協議能夠確保，先發送的數據先到達（與之相反，UDP 不保證這點）。
3. HTTP 協議如何使用 TCP 連接？
HTTP 對 TCP 連接的使用，分為兩種方式：俗稱“短連接”和“長連接”（“長連接”又稱“持久連接”，“Keep-Alive”或“Persistent Connection”）
假設有一個網頁，里面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件。在“短連接”的模式下，瀏覽器會先發起一個 TCP 連接，拿到該網頁的 HTML 源代碼（拿到 HTML 之后，這個 TCP 連接就關閉了）。然后，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含很多外部資源（圖片、CSS、JS）。然后針對【每一個】外部資源，再分別發起一個個 TCP 連接，把這些文件獲取到本地（同樣的，每抓取一個外部資源后，相應的 TCP 就斷開）
相反，如果是“長連接”的方式，瀏覽器也會先發起一個 TCP 連接去抓取頁面。但是抓取頁面之后，該 TCP 連接並不會立即關閉，而是暫時先保持着（所謂的“Keep-Alive”）。然后瀏覽器分析 HTML 源碼之后，發現有很多外部資源，就用剛才那個 TCP 連接去抓取此頁面的外部資源。
在 HTTP 1.0 版本，【默認】使用的是“短連接”（那時候是 Web 誕生初期，網頁相對簡單，“短連接”的問題不大）；
到了1995年底開始制定 HTTP 1.1 草案的時候，網頁已經開始變得復雜（網頁內的圖片、腳本越來越多了）。這時候再用短連接的方式，效率太低下了（因為建立 TCP 連接是有“時間成本”和“CPU 成本”滴）。所以，在 HTTP 1.1 中，【默認】采用的是“Keep-Alive”的方式。
Istio雙向 TLS 支持
雙向 TLS 支持主要針對的是通信方面，把明文傳輸的服務通信，通過轉換為 Envoy 之間的加密通信。這一安全設置較為基礎，可以在全局、Namespace 或者單個服務的范圍內生效。
這一功能主要通過兩個 Istio CRD 對象來完成：
Policy
例如 Basic Authentication Policy 中的一個樣例，用於給單個服務設置 mtls：
apiVersion: "authentication.istio.io/v1alpha1" kind: "Policy" metadata: name: "example-2" spec: targets: - name: httpbin peers: - mtls: 其中 target 是可選項，如果去掉的話，作用域將擴展到整個 Namespace。
DestinationRule
同樣的一個例子里面的目標規則如下：
apiVersion: "networking.istio.io/v1alpha3" kind: "DestinationRule" metadata: name: "example-2" spec: host: httpbin.bar.svc.cluster.local trafficPolicy: tls: mode: DISABLE portLevelSettings: - port: number: 1234 tls: mode: ISTIO_MUTUAL 這個也很容易理解，這一規則用於指派對該地址的訪問方式：
tls.mode = DISABLE，這個服務缺省是不開啟 tls 支持的，如果取值ISTIO_MUTUAL，則代表這個地址（服務）的所有端口都開啟 TLS。port...ISTIO_MUTUAL，只針對這一個端口啟用 mTLS 支持。
創建 Policy 之后，Citadel 會生成證書文件，並傳遞給 Envoy，我們可以在 Envoy 容器（kube-proxy）的 /etc/certs/ 目錄中看到這幾個 *.pem 文件。如果使用 openssl x509 -text -noout 查看 cert-chain.pem 的證書內容，會看到 spiffe 編碼的 ServiceAccount 內容來作為 SAN：
X509v3 Subject Alternative Name:
URI:spiffe://cluster.local/ns/default/sa/default
規則生效之后，原有的服務間調用是沒有差異的，但是如果在網格之外，就必須 https，結合上面談到的證書來訪問目標服務才能完成訪問。