Programming Language Notes

  超文本傳輸協定（HyperText Transfer Protocol，縮寫: HTTP），主要做為數據通訊的基礎協定，舉凡我們上網的網頁、圖片…，都是由HTTP協定為基底標準，讓服務端與用戶端可以相互通訊，達到互動、傳遞資訊的作用，而從最初版的單向傳輸也隨著時代的演進，應用漸趨複雜的趨勢下慢慢優化到雙向互動，而大數據的時代下，龐大的數據量也凸顯了傳輸效率的問題，因而也對這部分進行改善，讓傳輸更加順暢，就讓我們一起來看看HTTP的演進史吧！ HTTP 1.0的遠古時代 每一次都需要建立連線，並且只能有一次的請求。 HTTP 1.1 做了些改進 HTTP1.1版本之下，在一個請求中可以夾帶多個請求，並回傳，以此來減少多次連線的開銷，以此來改善HTTP1.0多次連線的問題。 到了HTTP/2的現代又有什麼大躍進？ 在HTTP1的時代雖然做了很多連線上的改進，但是隨著用來越多應用都搬移到網路上，雙向溝通的需求也越趨明顯，而1.x版的架構下並沒有支援Server端主動通知Client端的機制，在HTTP 2也都加入了這些特性。 在傳輸上也將原本整包資料的傳送方式切碎成小包小包， 並給予每一包一個編號， 送到目的地之後再重組， 如此一來就可以傳送多批資料也不會有等待一批資料過於久的現象。 幾個優點如下： Header壓縮，減少傳輸成本。 支援Server Push，由伺服器推送資料到瀏覽器。 連線重複使用，減少開銷。 下一個未來發展的重點「HTTP/3」 我們在簡介說明的部分有稍微提到，未來隨著數據量以及更多的需求轉移到互聯網時，為了避免堵塞造成使用體驗不佳，因而在傳書上持續的演化，而HTTP/2之前仍然是追求可靠性傳輸的TCP協定，在HTTP/3大膽的引進了UDP不可靠傳輸的概念，但也並非完全不可靠，而是基於UDP做了一些改良，這個協定稱為QUIC： 由上圖，很明顯的看到我們原本三次的傳輸來確認雙方可以進行通訊的過程，改良到只要一次就完成，更何況TCP + TLS更多次確認的過程，這邊其實QUIC的過程已經包含TLS了，只是未將詳細過程羅列，有興趣者請參考Wiki。 但我們的心中一定充滿著幾個疑問： 為什麼QUIC能保證可靠性呢？ ⇒ 因為加入了RAID5的演算機制，一次的傳送多個封包中，會加入一包檢驗的加總，並且可以反推

  軟體世界隨著現實應用越來越複雜，需要處理的資料量也就隨之倍數增長，假設我們每一個動作都要等待處理完畢後再回應，那麼勢必對於廣大用戶的使用者體驗大打折扣，因此這個過程如果有一個中間人幫我們處理掉先來後到的流程，那麼是不是我只要將要進行的動作交給中間人即可，而背後處理的服務商則透過中間人依序處理，處理完畢後再告知業主即可，相信會大幅提升使用效率。 同步與非同步任務 在進入Message Queue之前我們先來了解一下同步/非同步任務的概念。 圖片來源 菜單稱為訊息(Message), 為工作內容描述。 送出菜單的客人稱為生產者(Producer), 負責建立訊息。 櫃台就相當於Queue, 負責接單並依序處理。 廚師就是消費者的概念, 負責消化Queue裡面的訊息。 什麼是Message Queue? 採生產者/消費者模式，主要提供不同process之間通訊的方式之一。 Producer: 負責生產訊息。 Consumer: 負責接收及處理訊息。 應用場景 應用解耦 用戶下單後, 訂單系統需要通知庫存系統, 但是假設庫存系統故障, 就會導致客戶下單失敗。 圖片來源 引入Message Queue之後 圖片來源 訂單系統: 用戶下單後, 訂單系統完成持久化工作後, 發布消息到Message Queue, 並返回下單成功。 庫存系統: 向Message Queue訂閱下單的消息, 再根據下單的訊息內容進行庫存的更新。 如此一來客戶下單時假設庫存系統故障, 仍可正常下單。 並行處理 圖片來源 帳號註冊成功後還需要發送Mail及簡訊, 如果還沒有Message Queue時勢必需要依序發送, 但如果中間隔了一層Message Queue時, 簡訊系統及Mail系統就可以各自獲取訊息並處理。 流量控制 電商平台常常推出限時搶購活動, 但如果大家都在同一時間發出請求, 那麼當訂單系統無法負荷時將造成下單失敗, 勢必引來使用者抱怨的狀況, 而為了防止這種後端被壓垮的狀況, 可以導入MQ的架構來因應, 透過Queue來堆積下單的請求, 當系統有能力處理時再進行處理。 下單系統收到請求後就先丟到Queue，當Queue已經超出最大設定值時就reject請求。 訂單處理系統根據Queue的依序請求訊息進行後續處理。

  CDN全名為 Content Delivery(Distribution) Network，內容傳遞網路，光看名字應該還不知道能夠做什麼吧！那為什麼又要有CDN呢？ 主要是因為現在的時代，很多事務都開始搬上網際網路，而且參與的對象已經是全世界了，假若因為距離太遠，導致載入時間過久，相信對於使用者體驗必然大打折扣，因此CDN的出現主要是克服了這樣的限制，至於為什麼能夠克服呢？ 接下來的主題就是來談談這個部分。 沒有CDN時，遇到什麼樣的問題？ 當使用者距離我們的伺服器越遠時，傳輸速度必然會因為物理限制下減緩，加上如果流量又多，勢必會造成塞車的狀況，就像我們早期在瀏覽國外網站時一般，光是載入一個簡單的靜態頁面就足足等了幾分鐘之久，對於使用體驗上來說已經大打折扣。 加速的方式 其實就是分身的概念，建設多台伺服器的佈署，每一個節點都有儲存快取資料，因此當我們在瀏覽一個國外網站時，會優先以該國家附近的伺服器節點開始抓取快取資料並展示於瀏覽器，不需要全部連回主伺服器，也因此減少了主伺服器的壓力，讓讀取更加快速。 一個網站如果剛開始建置時，流量不大，都不會造成負擔，但當有一天營運的規模快速增長時，回應速度可能就隨之減慢，延遲時間也隨之變長，過往我們通常會再採購一台伺服器並搭配Proxy來進行轉發，負擔原本伺服器的壓力，但仍沒有解決物理距離的問題，因此CDN就很聰明的做為緩存伺服器分散在世界各處，並定期將網頁伺服器的快取資料同步到各個CDN節點。 就想像成物流中心，在各個地區都設置區域性的物流倉儲，前一天統一集貨到各個地區的物流倉儲，再由各地區的司機去運送，減少運輸時間。 CDN伺服器如果沒有資料怎麼辦？ CDN伺服器也有可能因為當機的因素，沒有緩存到網站伺服器的資料，這時候當瀏覽器存取最近的CDN伺服器時，若取不到資料就會再往下一台找，直到找回網站伺服器為止。 對於使用者端來說要怎麼自動找其他節點？ 通常我們會經過一個DNS伺服器幫我們決定去哪裡抓資料，就將其想像成查號台，我們先打過去查詢目的地的號碼，再進行打電話。 除了讓網頁更快的載入還有什麼作用？ 這時代最流行莫過於影音直播了，假設沒有CDN的分散負擔，當千萬人都透過一台伺服器讀取直播內容時很容易發生延遲的狀況，因為我們的頻寬就是這麼大，流量就是這麼擠，試想當高速公路塞車時的盛況就可想而知

  Latency 延遲 執行一個操作要花費的「時間長度」。 舉例來說，時速100公里的前提下，從台北到高雄大約花費4個小時，而這個花費的耗時就稱為延遲。 Throughput 吞吐量 以一個時間區間作為單位，單位時間內可以執行「幾次」操作，或運算的「次數」。 舉例來說，時速100公里的前提下，從台北到高雄的路段，每一個小時能夠乘載的量能，以高速公路來說，一台車可以乘載4個人的理想狀況之下，那麼從台北到高雄一台車需要耗費3.5個小時，也就是平均一個小時可以乘載1.14個人。 Bandwidth 頻寬 以高速公路來說，假設A地到B地的路段都是四線道，理想的狀況下，四線道都通車，且不塞車的狀況下，同時並行四輛車就稱為頻寬。 結語 對於以上的名詞具有基本的認識之後，我們可能會想，如何減少延遲與提高吞吐量呢？ 減少延遲最簡單的方式就是提高時速、減少風阻...，也就是提升硬體資源，讓處理速度更快，減少延遲。 提高吞吐量的部分重點在於如何在有限的道路限制下運載更多的量到目的地，以高速公路來說，我們可能會採取高乘載管制，盡量讓每一台車(封包)，塞滿人(資料)，達到最有效率的運輸，讓道路的空間發揮到極致，並搭配最低限速來減少塞車的狀況。 增加頻寬雖有助於提升運載量，但如果沒有從減少延遲與提高吞吐量來改善的話，很容易誤入加大頻寬解決一切的陷阱。 其實我們會發現很多生活中的例子都應用在軟體領域的解決方案之上，我想兩者是相輔相成的，所有的解決方案都是基於我們人類的智慧，因此不論是虛擬甚至是實體生活，我們只要好好思考出一個策略就能解決眼前遇到的困難。 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入？ 歡迎加入一起練習寫作，賺取知識，累積財富！ ⭐ 跟著「阿Han」一起來閱讀、撰寫文章，讓知識變現吧! ⭐

  進入本篇章前建議您可以先了解以下兩個篇章，主要是介紹單向過程中的訂閱概念： 【Web微知識系列】訂閱技術的基石，RSS Feed是什麼？ 【Web微知識系列】系統之間的訂閱機制，Webhook是什麼？ 這種雙向溝通機制主要是為了更即時的反應，舉例來說今天我們有一個應用是即時語音辨識，那麼勢必會有一個互動的過程，使用者端進行錄音後，即時的送到伺服器進行辨識並將辨識結果即時呈現於畫面上時，就必須透過這種雙向溝通機制才能完成。 簡介 傳統的Http是一種Stateless的傳輸方式， 因此不會維持原本狀態， 而是需要更新、新增、查詢...等操作時才進行請求， 因此假設有即時性互動的應用時就不太適用了， 因為每進行一個動作就要向Server端發送請求， 而每次的請求都必須經過交握式連接的過程， 在效能上就不是那麼理想了， Websocket允許瀏覽器跟Server端只經過一次的交握過程， 就能建立一條長連接的溝通管道， 並透過這條管道進行「雙向傳輸」。 Websocket與TCP、HTTP的關係 Websocket與HTTP屬於應用層， 同樣都是基於TCP來進行傳輸， 而進行Handshake時也會透過HTTP進行， 但真正傳輸資料時就不必經過HTTP的方式。 與HTTP一樣可以進行加密傳輸， HTTP的部份為 https ， Websocket則為 wss 。 為什麼要使用Websocket？ 其實以往我們網頁資料刷新有以下幾種方式可以實作： Polling 這種方式是早期透過Javascript定時( setInterval 、 setTimeout )來向後端請求最新資料並呈現於頁面之上， 這麼做的好處是容易實現， 但我們並不知曉Server端何時會更新， 只能傻傻的定時獲取， 造成的影響就是頻寬的浪費以及資料呈現不即時。 Long-Polling 長時間輪詢的方式就是收到前端請求後， Server端會等待， 若這段時間有資料就會將最新資料回傳給前端， 因此等待的這段期間Client什麼事情也不用做， 等待資料回傳後再發送下一個請求， 雖然長時間的連接解決了Polling開銷的問題， 但如果在更新資料很頻繁的狀況下也會造成連續的Polling的動作產生， 未必效能較佳。 Server Sent Events 這種