feat(nalsd): add practice 1 intro

src/essay/web/http.md

@@ -31,7 +31,7 @@ HTTP 建立在 [TCP](./tcp.md) 之上，雖然 TCP 可以確保連線的穩定
 
 ### 協定資訊
 
-這是請求（或回應）的第一行。
+這是請求或回應的第一行。
 
 如果是請求方，內容就包括你用了什麼版本的 HTTP，
 你針對應用程式的哪個地方（[HTTP Path](https://developer.mozilla.org/en-US/docs/Web/API/URL/pathname)），
@@ -42,7 +42,7 @@ GET /hello HTTP/2
 ...接下來是參數設定...
 ```
 
-就是使用 `GET` 方法到應用程式的 `/hello` 去做請求。
+就是使用 `GET` 方法到應用程式的 `/hello` 這個位置去做 HTTP/2 的請求。
 
 如果是回應，
 則是會有版本和回應的狀態（[HTTP Status](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)），例如：
@@ -52,7 +52,9 @@ HTTP/2 200
 ...接下來是參數設定...
 ```
 
-就是回應 200 這個編號。
+就是回應 *200* 這個編號，
+在 [RFC-9110](https://httpwg.org/specs/rfc9110.html#overview.of.status.codes) 中，
+*200* 這個編號代表 `OK`。
 
 ### 參數設定
 
@@ -70,8 +72,8 @@ payload
 上述範例可以看到標頭（[Header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)）總共有兩個，
 這是因為第二行到下一個空行之間總共有兩行。
 
-標頭的格式很單純，大小寫有差，行首到冒號之前為鍵（key），不可以有空格；
-冒號後為值（value），需要忽略前面的空格。
+標頭的格式很單純，行首到冒號之前為鍵（key），大小寫沒差，不可以有空格；
+冒號後為值（value），大小寫有差，需要忽略前面的空格。
 
 由此誕生極其複雜的應用設定環境。
 身為使用者通常你不用太擔心這件事情，因為偉大的瀏覽器和相關規範，例如
@@ -94,36 +96,39 @@ header2: value
 我的名字是呂學洲，幫我訂機票。
 ```
 
-至於存放的內容要[用什麼格式](../../feedback/distributed-systems-with-node.js/protocol.md)，就可以根據應用程式自己去選擇了。
+至於存放的內容要[用什麼格式](../../feedback/distributed-systems-with-node.js/protocol.md)，
+就可以根據應用程式自己去選擇了。
 
-## 維運要注意的標頭
+## 標頭：參數設定
 
-### Access-Control-Max-Age
+### 維運要注意的標頭
+
+#### Access-Control-Max-Age
 
 [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age)
 
 它是用來處理 Preflight 請求的快取。
 
-## 資安要注意的標頭
+### 資安要注意的標頭
 
-### X-Forwarded-For
+#### X-Forwarded-For
 
 把請求方的 IP 傳遞下去，但是在開放網路下，是可以被篡改，要小心使用。
 
-### Meta
+#### Meta
 
 set the cookie
 
-### Content-Encoding
+#### Content-Encoding
 
 避免 [CRLF Injection](https://www.praetorian.com/blog/using-crlf-injection-to-bypass-akamai-web-app-firewall/)
 
-### Connection
+#### Connection
 
 如果請求有這個 Header，服務方在回應後，就會主動關閉連線。
 關閉連線的那方是要負擔較大的 TCP 開銷，並貯存 [TCP `TIME_WAIT`](tcp.md#四次揮手) 的連線。
 
-### ETag
+#### ETag
 
 用來標誌資源的版本，可以使用這個增加快取機制，例如：
 
@@ -141,16 +146,26 @@ Server 收到 `if-match` 後就可以檢查是否有競賽問題（同時有兩
 或者也可以透過 `if-none-match` 檢查是否為舊版的 content 然後就回傳 304（Not Modified），
 避免網路資源的耗用。
 
-## 靜態網站要注意的標頭
+### 靜態網站要注意的標頭
 
-### Cache-Control
+#### Cache-Control
 
 設定 `public max-age=0 must-revalidate` 代表：
 
 > 幫我快取這東西，但是馬上讓他過期，並重新和我驗證這東西的
 >
 > [More Aggressive Cache Header](https://macarthur.me/posts/more-aggressive-cache-headers)
 
+## 不同版本的差異
+
+目前 HTTP 主流上共有三種版本：1.1、2 和 3。
+整個公開網路環境中，HTTP/3 的使用率在 2024/06 時，已經來到
+[30%](https://w3techs.com/technologies/details/ce-http3)，
+但是 [Cloudflare 的文章](https://blog.cloudflare.com/http3-usage-one-year-on)指出，
+大部分使用 HTTP/3 的場景是在瀏覽器和服務的溝通。
+如果是 API 形式，則主要還是 HTTP/1.1，
+這也說明任何一個新協定的推廣都需要漫長的適應期。
+
 ## 一些常見的問題
 
 !!! question "我的應用程式是用 HTTP 溝通嗎"

src/feedback/site-reliability-workbook/index.md

@@ -14,9 +14,9 @@ The Site Reliability Workbook, Practical Ways to Implement SRE
 透過**把可用性變成產品功能**的認知，彌平兩者之間的鴻溝。
 在設計之初缺乏可用性的考量相當於用更高的營運成本去設計更少的功能，
 相反的，考量可用性下持續設計、迭代產品，最終透過低營運成本達到穩健且可擴充的產品，
-這種設計方式，稱為 *務實大型系統設計*（Non-Abstract Large System Design）。
+這種設計方式，稱為 *非抽象大型系統設計*（Non-Abstract Large System Design）。
 
-SRE（Site Reliability Engineering）就是兩團隊的橋樑，也是實踐務實大型系統設計的基礎。
+SRE（Site Reliability Engineering）就是兩團隊的橋樑，也是實踐非抽象大型系統設計的基礎。
 SRE 不一定是一個團隊，也可以是一種深入在開發團隊和維運團隊的文化。
 
 什麼文化？以下將從各個面向去探討：
@@ -28,7 +28,7 @@ SRE 不一定是一個團隊，也可以是一種深入在開發團隊和維運
 - [災難管理](./incident-response.md)，緊急事件時的責任劃分，並且常態且實際的訓練。
 - [事後析誤文化](./postmortem-culture.md)，如何讓企業在災難發生後，學習到最多？
 - [負載管理](./managing-load.md)，好的負載管理機制通常是複合型的，但建構後，又有哪些維運上的建議呢？
-- [務實大型系統設計](./nalsd.md)，讓開發者設計系統架構時能有個依據去建立穩健而又高擴充的系統。
+- [非抽象大型系統設計](./nalsd.md)，讓開發者設計系統架構時能有個依據去建立穩健而又高擴充的系統。
 - [資料管線設計](./data-pipelines.md)，資料管線幫助整合資料，其設計和線上系統有異曲同工之妙。
 - [設定檔的最佳實踐](./configuration-best-practice.md)，好的服務設定方式，會減少緊急情況的發生。
 - [金絲雀部署](./canary-release.md)，部署工程也是確保服務穩定的重要工具。

src/feedback/site-reliability-workbook/nalsd.md

@@ -2,11 +2,11 @@
 tags: SRE-workbook
 ---
 
-# 務實大型系統設計
+# 非抽象大型系統設計
 
-務實大型系統設計的目的在於讓開發者設計系統架構時，有個依據建立穩健而又高擴充的系統。
+非抽象大型系統設計的目的在於讓開發者設計系統架構時，有個依據建立穩健而又高擴充的系統。
 
-本文先透過定義問題，收集需求並透過迭代的方式循序改善設計，最終得到一個可靠的系統設計解方。
+本文先透過定義問題，收集需求並反覆審視、循序改善架構的設計，最終得到一個可靠的系統設計解方。
 目標是讓開發者能設計出一個在初期便擁有高穩健性且同時擁有未來調整的環境，
 而這個過程，就是把抽象的需求，降成實際可被估量的實踐。
 這些實踐包括：
@@ -17,21 +17,43 @@ tags: SRE-workbook
 
 這些實踐讓 SRE 有能力在面對系統設計時，
 思考系統的擴充性和可能的瓶頸，並專注在這些點上。
-在接下來的練習中，每一次迭代的設計，都可以問問自己這四個問題：
+在接下來的練習中，每一次設計的迭代，都可以反覆問自己這四個問題：
 
-- 這個設計可能嗎？
-- 有沒有更好的方法？
-- 這方法可以在有限的時間和金錢內達成嗎？
-- 如果專案有了其他干擾或插件，這方法仍能成功嗎？
+- 這個設計可能嗎？假設不去管資源議題，這個設計可以滿足需求嗎？
+- 有沒有更好的方法？可以讓他更快、更輕便、更有效率嗎？
+- 這方法可以在有限的設備數量、時間和金錢內達成嗎？
+- 這個架構允許降能嗎？當某組建壞掉會發生什麼事？當資料中心壞掉會發生什麼事？
 
 !!! success "練習的目的"
-    練習中的假設和推估會比最終實際結果重要。
+    所有的系統最終都要實際跑在真實的資料中心和真實的設備上，
+    我們需要反覆練習將白板上的架構圖，轉化成實際要使用的設備數量等等。
+    聽起來很瑣碎，但是不去練習和規劃，當我們實際上線時，可能會付出更慘痛的代價。
 
-    早期的假設會很大程度影響最終的成果，但是在務實大型系統設計中，
+    練習中的假設和推估會比最終實際結果重要。
+    早期的假設會很大程度影響最終的成果，但是在非抽象大型系統設計中，
     我們並不是要練習出完美的假設，而是在多個**不完美但是合理的假設**中導出一個更好被詮釋的結果
 
 ## 練習一：AdWords
 
 AdWords 是 Google 一項產品，用來在使用者透過 Google 搜尋時，推出純文字的廣告。
-這次練習，是要設計出一個系統，可以觀測並回報正確的 *click-through rate*（CTR，*使用者點擊廣告次數* 除以 *廣告推播數*）。
+這次練習，是要設計出一個系統，可以觀測並回報正確的 *click-through rate*
+（CTR，*使用者點擊廣告次數* 除以 *廣告推播數*）。
 搜尋系統的日誌會紀錄每次搜尋有放哪些廣告，而廣告被點擊的紀錄則是放在廣告系統的日誌中。
+
+開始前，先簡述一下流程。
+我們將使用反覆迭代的方式去設計系統，每次迭代都會定義出相關的設計並找出它的優勢和弱點。
+而每次迭代的分析，都會幫助我們找出優點在下一次的迭代中設計出更好的系統。
+在初始階段我們會根據以下兩個問題來設計系統：
+
+- 這個設計可能嗎？
+- 有沒有更好的方法？
+
+接著我們會去思考針對**初始設計的擴充性**，這時就會再去回應以下三個問題：
+
+- 這方法可以在有限的設備數量、時間和金錢內達成嗎？
+- 這個架構允許降能嗎？
+- 有沒有更好的方法？
+
+雖然這裡列出順序，但實際練習時這些問題可能是反覆詰問的。
+例如在初始階段，我們可能就會先考慮它的可擴充性。
+如果這個設計在後面的問題無法得到好的回答，我們就會修正或替換某個組件，接著重頭開始。

src/index.md

@@ -5,9 +5,12 @@ exclude_from_blog: true
 
 你好，我叫呂學洲。我在 104 資訊科技工作，歡迎發 PR 做任何修改。
 
-這裡有一些[心得](feedback/index.md)跟[隨筆](essay/index.md)。
+這個網站方便我做資訊的整理，
+也可以發一些 [issues](https://github.com/evan361425/evan361425.github.io/issues) 來當作備忘錄。
 
-這裡方便我做整理，和做 [issues](https://github.com/evan361425/evan361425.github.io/issues) 來提醒自己待做事項。
+- [隨筆](essay/index.md)：學到的東西落成文字，例如 IP/TCP 等等；
+- [心得](feedback/index.md)：讀書或文章的心得；
+- [年度回顧](review/index.md)：每年的回顧。
 
 ## 最近的異動