Programming Language Notes

  今天來聊聊我們常常使用的網頁，背後怎麼讓我們用的更順暢的一門傳輸方式，HTTP Keep-Alive，透過一點點的小改變，讓傳輸效率提升，減少非必要的浪費。 圖片來源 當我們溝通的過程中沒有KeepAlive的狀況下，會有多次往來的狀況，這樣對雙方來說開銷成本是非常大的，因此為了改善這個現象，加入了一個機制，就是當前期的握手協議建立之後，就可以不斷的發送請求跟回應，其實就跟通訊軟體一樣，當我們與對方建立關係之後，就能與對方不斷往來進行聊天，但是當今天我們帳號不斷的切換，那麼每次都要先打招呼，打完招呼之後等對方同意才有機會聊天。 與TCP的Keep Alive相同嗎？ 一樣都是Keep Alive，看上去非常相似，但實際上是完全不同的兩個面向，由於HTTP是基於TCP之上的，因此對於TCP本身來說也應該要有Keep Alive的機制，不然的話就算我們的HTTP那一層做的在完美，TCP沒有長連接的機制也是枉然，而本篇不會提到TCP的Keep Alive的機制，目的僅在說明這樣的機制大概是什麼樣的概念，幫助建立比較基礎的知識。 HTTP Keep-Alive具備哪些優點？ ● 減少用戶端與伺服端的負擔，不用頻繁請求，定期確保與對方沒有斷線即可。 ● 提升傳輸效率。 ● 確保與對方持續連線。 -------------------------------------------------------------------------------- 喜歡撰寫文章的你，不妨來了解一下： Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 - 為什麼要加入？ 歡迎加入一起練習寫作，賺取知識，累積財富！

  越來越多的應用都在網頁上完成了，猶如過往的Excel、Word，現在都能直接用網頁來編輯使用，但我們想過嗎？ 所有的運算，除了伺服器以外，網頁是不是也會有一些複雜的計算呢？ 那對於這些複雜的計算，如果讓整個網頁卡住，勢必會影響到使用者的體驗，因此系統運算中的多工技術也被搬移到網頁端了，讓使用者一邊可以正常使用，背後將多餘的資源拿來進行較為複雜的計算。 但網頁端主要使用的語言是Javascript，原本的主要目的是簡單的互動，因此設計為單執行序，但隨著時代的演進，越來越多的功能都依賴這樣的程式進行運算，詳細我們將逐一說明。 為什麼javascript要設計為單執行緒? javascript主要功能是與user操作頁面互動及操作dom，試想若使用多執行緒的概念，那麼一個動作是新增至某個dom節點，另一個動作則是修改該dom節點，此時瀏覽器應該使用哪個動作為準? 所以為了避免複雜性才設計為單執行緒。 理解javascript非同步的概念 單執行緒就表示說所有任務都需要排隊處理，相對的效率較低落，IO或Network request通常需要等待較長的時間，如果前端頁面常常因為這些動作發生堵塞則user看到的畫面就是整個鎖死的，因此javascript使用了一些機制來避免這個問題，主要將任務分為兩種： ● 同步任務： 主執行緒上排隊執行的任務。 ● 異步任務： 不進入主執行緒，而是進入任務佇列等待執行。 上圖的執行機制 1. 主程序會先從stack中執行function 2. 執行過程中遇到setTimeout這類的非同步API呼叫，會透過事件委託的機制掛一個callback到setTimeout之類的Web API，執行完畢後會將該callback傳入上圖的callback queue等待。 3. 執行堆棧空閒時才從callback queue中取出任務執行。 4. 因此我們才會使用setTimeout的技巧讓一些需要長時間計算的任務排到任務佇列中等待，然而主執行緒就不會因為這個任務發生阻塞現象，可以先執行觸發loading動畫的事件後才處理這些耗時的任務，讓user感覺到畫面並非被鎖死。 上面的技巧雖然解決了畫面被鎖死的問題，但實際上執行的時間並沒有減少，因此發展出了Web Worker的機制，讓我們在web上也能有多執行緒的功能，最大化的利用系統資源，但是仍...

  企業常常有代理人機制， 當我們有重要的事情需要請假時， 就會有代理人幫我們處理公司事務， 相當於「我們授權代理人處理什麼事情」，而這樣的代理機制在軟體世界也是常見的一種機制， 尤其是在分散式運算的架構下。 那代理能為我們帶來什麼好處呢？ 又為什麼非用不可？ 這也是我們今天著重探討的主題。 其實代理就是你跟我之間隔著一層， 彼此不知道對方， 只知道往哪邊遞送資料， 從而解決雙方的依賴， 尤其伺服器端如果是一群機器在服務， 撇開代理， 用戶端勢必得自己管控要送到哪一台機器去處理， 那刪減及增加機器時怎麼辦？ 對於用戶端不就得常常停機，更新這些機器的位置， 這對於應用上來講就大打折扣了，因此有了代理之後，這樣的問題就迎刃而解了。 另外我們可能也聽過反向代理這個詞， 後面也會進行介紹，說明一下什麼是正向代理，什麼又是反向代理。 使用代理帶來哪些好處？ 快取 由於Server與Client之間隔著一層Proxy Server，因此該台機器就可以加入緩存機制，當資料未發生變化時，每次Client的存取所看到的結果都會是一樣的，因此我們就可以將緩存的資料直接送往Client端，而不用往伺服器發送，減緩伺服器的壓力。 匿名性 透過Proxy的轉發，Client端並不知道真正處理請求的機器到底是哪一台，只知道要把這個請求送給Proxy請它代理處理。 流量控制 有了Proxy做為中間人，在這裡就能夠掌握流量，並且依序負荷程度進行適當的調配，避免阻塞。 稽核日誌 由於所有請求都會經過Proxy，因此在這裡非常容易掌控來源與目的，想當然也就更容易達到稽核的目的了。 先來搞懂正向代理與反向代理吧！ 正向代理 其實正向代理就是以Client端為出發點，Proxy的角色就是中間人，中間人可以為Client進行服務，代為向伺服端發送對應的請求，那麼相對的以這個角度來說，應該站在Client的立場進行服務，包括匿名、翻牆…都是正向代理的服務範疇。 反向代理 而反向代理就不一樣囉，以服務端為出發點，替他們站在最前線，阻擋非必要的需求，就很像PM跟PG的角色，PM站在最前線釐清需求後，再往後派工。 反向代理能夠帶來什麼好處？ 負載平衡： 由於運算量比較大的負擔會在伺服器端，因此在最前線的Proxy自然可以做到分散負擔的任務，才不至於太多的請求...

  Business Analyst簡稱BA，即業務分析師，在軟體開發職位打滾了幾年也是最近才聽到這個名詞，好奇心所趨之下來了解BA到底是什麼？ 主要的工作內容是什麼？ 在公司裡又是扮演什麼樣的角色？ 我們可能會想說BA不就只是每天與客戶溝通而已，寫寫使用者故事，主持主持會議，有時候又做為夾心餅，不斷的在客戶與開發團隊之間忙得不可開交，常常被挑戰不合理的需求怎麼開發，被質疑這種需求應該要能夠做到，為什麼不行，我想這對於外行來說常常看到的就是這樣的表面吧！ 但其實BA並非我們想像的那麼簡單，最終目標就是「用對方聽得懂的話去告訴對方不懂的事」，因此邏輯能力與溝通能力非常重要，當我們越具備這種能力，所能發揮的影響力也越大，在公司的地位相對的也越高。 尤其是現在任何商機都是講求數據的時代，若身為一個商業分析師能夠掌握數據、分析數據，相信用數據說話能夠引領公司做好一個重大的決策。 扮演著什麼樣的角色？ 如何計劃一個專案？ 制定商業目標： 找出客戶的痛點，制定藥方研發計畫。 蒐集商業需求： 探訪客戶痛點的過程中想方設法蒐集更多需求，並思考如何將這些需求轉化為專案目標。 分配資源： 需要什麼樣的工程團隊？ 工程、數據、…，需要什麼樣的內部資源？這些都是需要思考的範疇，並找出這些資源進行分配。 扮演利害關係人與工程團隊的橋樑。 蒐集客戶的反饋： 做為持續優化的養分。 建立報告： 透過專業技能將資料分析為有用的報表，並以報告方式呈現。 成果發表。 需要哪些專業技能？ BA不只是簡單的溝通而已，更重要的是手上掌握了許多資料，如何使用專業技能將這些資料有效的分析，並提供給老闆、客戶、工程團隊進行有效溝通，減少隔閡，而不是單純著扮演著橋梁的角色，別人提供什麼輸入就原封不動的進行輸出，反而是要轉化、分析、以對方聽得懂的語言去進行溝通才能發揮最大的價值。 具有哪些責任？ 解決企業內部遇到的挑戰。 分析數據，從資料中挖金，探嗅商業機會。 為客戶制定策略與解決方案。 做為公司各部門與客戶間重要的核心橋梁。 改善流程、策略制定。 結語 數位化的時代之下，軟體的需求也越發重要，複雜性也越來越高，我們常常發現需求與理解的過程會不斷的發生矛盾，而面對這樣的矛盾就需要有一個橋樑去化解，因此軟體開發不只是硬技能重要，軟技能也是不可或缺的能力之一，...

  超文本傳輸協定（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的分散負擔，當千萬人都透過一台伺服器讀取直播內容時很容易發生延遲的狀況，因為我們的頻寬就是這麼大，流量就是這麼擠，試想當高速公路塞車時的盛況就...