上一節我們講到，手機 App 經過了一個復雜的程序，終于拿到了電商網站的 SLB 的 IP 地址，是不是該下單了？
別忙，俗話說的好，買東西要貨比三家，大部分客戶在購物之前要看很多商品圖片，比來比去，最后好不容易才下決心，點了下單按鈕，下單按鈕一按，就要開始建立連接，建立連接這個程序也挺復雜的，最侄訓要經過層層封裝，才構建出一個完整的網路包，今天我們就來看這個程序，
4. 購物之前看圖片，靜態資源 CDN
客戶想要在購物網站買一件東西的時候，一般是先去詳情頁看看圖片，是不是想買的那一款，
我們部署電商應用的時候，一般會把靜態資源保存在兩個地方，一個是接入層 nginx 后面的 varnish 快取里面，一般是靜態頁面；對于比較大的、不經常更新的靜態圖片，會保存在物件存盤里面，這兩個地方的靜態資源都會配置 CDN，將資源下發到邊緣節點，
配置了 CDN 之后，權威 DNS 服務器上，會為靜態資源設定一個 CNAME 別名，指向另外一個域名 cdn.com ，回傳給本地 DNS 服務器，
當本地 DNS 服務器拿到這個新的域名時，需要繼續決議這個新的域名，這個時候，再訪問的時候就不是原來的權威 DNS 服務器了，而是 cdn.com 的權威 DNS 服務器，這是 CDN 自己的權威 DNS 服務器，
在這個服務器上，還是會設定一個 CNAME，指向另外一個域名，也即 CDN 網路的全域負載均衡器，
本地 DNS 服務器去請求 CDN 的全域負載均衡器決議域名，全域負載均衡器會為用戶選擇一臺合適的快取服務器提供服務，將 IP 回傳給客戶端，客戶端去訪問這個邊緣節點，下載資源，快取服務器回應用戶請求，將用戶所需內容傳送到用戶終端，
如果這臺快取服務器上并沒有用戶想要的內容，那么這臺服務器就要向它的上一級快取服務器請求內容，直至追溯到網站的源服務器，將內容拉到本地，
5. 看上寶貝點下單，雙方開始建連接
當你瀏覽了很多圖片，發現實在喜歡某個商品，于是決定下單購買，
電商網站會對下單的情況提供 RESTful 的下單介面，而對于下單這種需要保密的操作，需要通過 HTTPS 協議進行請求，
在所有這些操作之前，首先要做的事情是建立連接，
HTTPS 協議是基于 TCP 協議的，因而要先建立 TCP 的連接，在這個例子中，TCP 的連接是在手機上的 App 和負載均衡器 SLB 之間的，
盡管中間要經過很多的路由器和交換機，但是 TCP 的連接是端到端的，TCP 這一層和更上層的 HTTPS 無法看到中間的包的程序，盡管建立連接的時候，所有的包都逃不過在這些路由器和交換機之間的轉發，轉發的細節我們放到那個下單請求的發送程序中詳細解讀，這里只看端到端的行為，
對于 TCP 連接來講，需要通過三次握手建立連接，為了維護這個連接，雙方都需要在 TCP 層維護一個連接的狀態機，
一開始，客戶端和服務端都處于 CLOSED 狀態，服務端先是主動監聽某個埠，處于 LISTEN 狀態，然后客戶端主動發起連接 SYN，之后處于 SYN-SENT 狀態，服務端收到發起的連接，回傳 SYN，并且 ACK 客戶端的 SYN，之后處于 SYN-RCVD 狀態，
客戶端收到服務端發送的 SYN 和 ACK 之后，發送 ACK 的 ACK，之后處于 ESTABLISHED 狀態，這是因為，它一發一收成功了，服務端收到 ACK 的 ACK 之后，也會處于 ESTABLISHED 狀態，因為它的一發一收也成功了，
當 TCP 層的連接建立完畢之后，接下來輪到 HTTPS 層建立連接了，在 HTTPS 的交換程序中，TCP 層始終處于 ESTABLISHED，
對于 HTTPS，客戶端會發送 Client Hello 訊息到服務器，用明文傳輸 TLS 版本資訊、加密套件候選串列、壓縮演算法候選串列等資訊，另外，還會有一個亂數，在協商對稱密鑰的時候使用，
然后，服務器會回傳 Server Hello 訊息，告訴客戶端，服務器選擇使用的協議版本、加密套件、壓縮演算法等，這也有一個亂數，用于后續的密鑰協商，
然后，服務器會給你一個服務器端的證書，然后說：“Server Hello Done，我這里就這些資訊了，”
客戶端當然不相信這個證書，于是從自己信任的 CA 倉庫中，拿 CA 的證書里面的公鑰去解密電商網站的證書，如果能夠成功，則說明電商網站是可信的，這個程序中，你可能會不斷往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，反正直到一個授信的 CA，就可以了，
證書驗證完畢之后，覺得這個服務端是可信的，于是客戶端計算產生亂數字 Pre-master，發送 Client Key Exchange，用證書中的公鑰加密，再發送給服務器，服務器可以通過私鑰解密出來，
接下來，無論是客戶端還是服務器，都有了三個亂數，分別是：自己的、對端的，以及剛生成的 Pre-Master 亂數，通過這三個亂數，可以在客戶端和服務器產生相同的對稱密鑰，
有了對稱密鑰，客戶端就可以說：“Change Cipher Spec，咱們以后都采用協商的通信密鑰和加密演算法進行加密通信了，”
然后客戶端發送一個 Encrypted Handshake Message，將已經商定好的引數等，采用協商密鑰進行加密，發送給服務器用于資料與握手驗證，
同樣，服務器也可以發送 Change Cipher Spec，說：“沒問題，咱們以后都采用協商的通信密鑰和加密演算法進行加密通信了”，并且也發送 Encrypted Handshake Message 的訊息試試，
當雙方握手結束之后，就可以通過對稱密鑰進行加密傳輸了，
真正的下單請求封裝成網路包的發送程序，我們先放一放，我們來接著講這個網路包的故事，
6. 發送下單請求網路包，西行需要出網關
當客戶端和服務端之間建立了連接后，接下來就要發送下單請求的網路包了，
在用戶層發送的是 HTTP 的網路包，因為服務端提供的是 RESTful API，因而 HTTP 層發送的就是一個請求，
POST /purchaseOrder HTTP/1.1
Host: www.geektime.com
Content-Type: application/json; charset=utf-8
Content-Length: nnn
{
"order": {
"date": "2018-07-01",
"className": "趣談網路協議",
"Author": "劉超",
"price": "68"
}
}
HTTP 的報文大概分為三大部分，第一部分是請求行，第二部分是請求的首部，第三部分才是請求的正文物體，
在請求行中，URL 就是 www.geektime.com/purchaseOrder ，版本為 HTTP 1.1，
請求的型別叫作 POST，它需要主動告訴服務端一些資訊，而非獲取，需要告訴服務端什么呢？一般會放在正文里面，正文可以有各種各樣的格式，常見的格式是 JSON，
請求行下面就是我們的首部欄位，首部是 key value，通過冒號分隔，
Content-Type 是指正文的格式，例如，我們進行 POST 的請求，如果正文是 JSON，那么我們就應該將這個值設定為 JSON，
接下來是正文，這里是一個 JSON 字串，里面通過文本的形式描述了，要買一個課程，作者是誰，多少錢，
這樣，HTTP 請求的報文格式就拼湊好了，接下來瀏覽器或者移動 App 會把它交給下一層傳輸層，
怎么交給傳輸層呢？也是用 Socket 進行程式設計，如果用的是瀏覽器，這些程式不需要你自己寫，有人已經幫你寫好了；如果在移動 APP 里面，一般會用一個 HTTP 的客戶端工具來發送，并且幫你封裝好，
HTTP 協議是基于 TCP 協議的，所以它使用面向連接的方式發送請求，通過 Stream 二進制流的方式傳給對方，當然，到了 TCP 層，它會把二進制流變成一個個報文段發送給服務器，
在 TCP 頭里面，會有源埠號和目標埠號，目標埠號一般是服務端監聽的埠號，源埠號在手機端，往往是隨機分配一個埠號，這個埠號在客戶端和服務端用于區分請求和回傳，發給那個應用，
在 IP 頭里面，都需要加上自己的地址（即源地址）和它想要去的地方（即目標地址），當一個手機上線的時候，PGW 會給這個手機分配一個 IP 地址，這就是源地址，而目標地址則是云平臺的負載均衡器的外網 IP 地址，
在 IP 層，客戶端需要查看目標地址和自己是否是在同一個局域網，計算是否是同一個網段，往往需要通過 CIDR 子網掩碼來計算，
對于這個下單場景，目標 IP 和源 IP 不會在同一個網段，因而需要發送到默認的網關，一般通過 DHCP 分配 IP 地址的時候，同時配置默認網關的 IP 地址，
但是客戶端不會直接使用默認網關的 IP 地址，而是發送 ARP 協議，來獲取網關的 MAC 地址，然后將網關 MAC 作為目標 MAC，自己的 MAC 作為源 MAC，放入 MAC 頭，發送出去，
一個完整的網路包的格式是這樣的，
真不容易啊，本來以為上篇就發送下單包了，結果到中篇這個包還沒發送出去，只是封裝了一個如此長的網路包，別著急，你可以自己先預想一下，接下來該做什么了？
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/211569.html
標籤：其他