在聽 Will 保哥在疫情期間中有介紹 SSL/TLS 的一些觀，過程中有提到一個 Chrome 小技巧 ByPass Https Error 在內部網頁服務的使用過程中，可能會遇到各種憑證問題導致無法正常瀏覽網頁 要確認網頁是安全的才可以繼續瀏覽 但是如果頁面有繼續瀏覽的選項可以點擊，但也不是太麻煩 但就怕沒有繼續按鈕可以使用，這個時候我都會開啟 Safari 去信任憑證，然後透過 Safari 瀏覽 鍵盤要注意是小寫 根據影片中述說，在 Chrome 的憑證或不安全的頁面中輸入 thisisunsafe 就可以順利繼續瀏覽 Chrome Flags 這個在開發一些網頁服務的時候蠻方便的，不然偶爾就要一直重新按繼續瀏覽，真的是非常麻煩 透過在 chrome 瀏覽器網址中輸入 chrome://flags/#allow-insecure-localhost，並將此設定開啟 Ref 深入理解 TLS/SSL 安全加密協定 Chrome: Bypass “Your connection is not private” Message

雖然專注在後端技術上，對前端只有初學者左右的程度，但還是多少對前端的技術很感興趣 而且這個技術對後端相對方便的，如果可以在前端技術上有更多精進的能力，多少可以解決更多問題 WebAssembly 簡介 WebAssembly 是一個以二進制表示的低階語言，可以在瀏覽器上運行，由於是二進制所以運行速度肯定會快點 特點則是說可以接近原生的效能，我個人觀點則是可以突破某些狀況下的限制和效能的提升，所以也有可能變慢囉！要謹慎使用 並且 2019 年時 WebAssembly正式成為W3C推薦的網頁應用標準 WebAssembly 與 JS 共存，輔助加強 JS 產生更多的應用並提升性能 目前可以使用 C/C++、Go、Rust 透過 Emscripten 編譯成 WebAssembly WebAssembly - Go Go 1.11 開始支援 WebAssembly 可以透過 Go 來進行開發 首先需要將 wasm_exec.js 複製到需專案目錄中，稍候需要 js 調用 wasm 檔案 1 cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" . Sample 寫個簡單的程式，先練練手培養的感覺 1 2 3 4 5 6 7 package main import "fmt" func main(){ fmt.Println("Hello, WebAssembly!") } 然後對此進行編譯，參數則是 GOOS=js 的 GOARCH=wasm，稍候就可以透過 js 來呼叫 wasm

最近看到 Netflix 藉由 TLS 1.3 降低使用者延遲，並且由於 TLS 1.3 重新設計了交握協定 簡化的交握方式及更高的安全性，讓我想讓 Golang 同時支持 TLS 1.2 及 TLS 1.3 TLS 1.2 vs TLS 1.3 在交握上，整體差了一個往返的過程，就可以差至約 100 ms 在大量用戶的負載下，可以位伺服器降低很多資源消耗 優勢 TLS False Start 0-RTT Chiper Suite TLS 1.2 提供眾多的密碼套件可供選擇 相對的由於 TLS 1.3 不包含金鑰交換及簽章功能 測試 接下來透過 Golang 測試 TLS 1.3 支持，並基於 Golang 來測試 TLS 1.3 的速度的進步 憑證 可以透過自簽 RSA 或者 ECC 的憑證進行測試，當然正式服務還是希望可以購買付費憑證 當然最低限度就是使用 Let’s Encrypt，只是沒有受到 電子簽章法 保障，做一個簡單的比較以供參考 自簽 免費 付費 有效期限 自訂 3 個月 1 - 2 年 網站綠勾 無 有 有 賠償機制 無 無 有 用戶 個人 個人、非營利 公司、政府、重點服務 接下來回到正題，繼續自簽憑證

開始學習如何提升某部分演算法的效能，對於如何運用多工開發邏輯的釐清和整理 跟以往單工開發的邏輯差上許多，必須考慮到整合、處理邏輯、場景等等的因素 多執行緒(線程) Multi-Thread 啟動 Thread 的速度就不會比 Process 來的快，但是彼此之間的記憶體是共享的 但是在處理的過程中沒有小心處理，可能會導致彼此之間搞的一踏糊塗 多進程 Multi-Process 啟動 Process 的速度是比較快的，擁有獨立的記憶體空間及資源 多個 Process 之間由於記憶體獨立的關係，彼此之間不能直接交換資料 需要透過一個通道進行傳遞，才能有辦法使 Process 之間溝通 然而一個 Process 內是可以擁有多個 Thread Multi-Thread vs. Multi-Process Process 較厚重 獨立記憶體空間 彼此通信過程緩慢繁雜 Thread 較輕量 擁有所處共同記憶體空間 彼此通訊過程迅速方便 並發 Concurrency 依照上圖的情境說明，依照 A 處理 Job1、B 處理 Job2、C 處理 Job3 但是 A、B、C 彼此牽制，好比搶奪一個辦公桌 誰坐在上面就能開始工作，離開崗位後其他人利馬搶辦公桌來使用 平行 Parallelism 依照上圖的情境說明，依照 A、B、C 進行工作處理分別為 Job1、Job2、Job3 但是 A、B、C 同時依序進行工作，沒有誰先誰後的問題，同時的進行處理 Concurrency vs. Parallelism Parallelism 同時進行處理 能夠使用多核 執行順序可以預期 Concurrency 輪流進行處理 只能使用單核 執行順序無法預期 (Race Condition) Concurrency 沒有辦法同時運作，那要他何用！？

最近辦了一張國泰的VISA金融卡，終於有了郵局以外的卡片了 想起 Apple Pay 可以使用，便把卡片加入 IPhone 錢包裡面 預設是密碼付款，不過如果不小心掉手機後 又不小心被看到付款的密碼，感覺就很不安全 依稀記得可以使用 Face ID 付款，想轉換成 Face ID 提高一點安全性 最初未啟用 Face ID 的 Apple Pay 是使用密碼付款 順便秀一下可愛的拉拉熊 尋找思路 最初我是在錢包中尋找 Face ID 的啟用 很直覺得往錢包中尋找設定 不過並沒有找到 Face ID 的相關設定 啟用 Face id 付款 換個思路尋覓，從設置中進入 Face ID 居然把 Face ID 付款功能設置在這裡，某種意義上放在這邊確實沒錯 只是其他 APP 都直接在 APP 的設定頁面中 結語 找了老半天終於找到設置位置，當功能太多確實會越來越雜亂 不過只放在這裡貌似也沒錯，單純思路沒考慮到 後來看了一下，官方原來有講在哪裡 😳 參考資料 https://support.apple.com/zh-tw/HT208109