Posts

前言 前陣子用 Node.js 開發時需要用一組加解密的 key 來將某個 url 的 query parameters 加密，就重新回頭研究一下對稱加密與非對稱加密的差異和手段，最後統一用 Node.js 的套件來簡單實作，留下此篇文章以供未來參考 密碼學在學什麼? 密碼學的目標可以簡單列出底下三個: 資訊保密: 確保只有授權者才能取得訊息 完整性驗證: 確保資訊沒有遭到算改 身分驗證: 驗證傳送方與接受方的身分 密碼學主要分為三種，先講結論: Encode(編碼) Two way 的轉換，只是編碼格式的轉換，不需要密碼，所以不算加密，沒有任何資安防護能力 Encrypt(加密) Two way 的轉換，需要密碼介入，可分成對稱加密與非對稱加密，前者是同一把金鑰，後者是有一組公私鑰，有防護資安的能力 Hash(雜湊) One way 的轉換(不可逆)，應用 Hashing 的演算法將待加密的字串轉換成一個獨一無二的 hash digest Encode(編碼) 只是換個方式來呈現資料 沒有加密，所以沒有安全性 只是各種平台使用數據的載體，ex: QRCode、UTF-8 為了配合網路傳輸的標準規範(RFC，Requests For Comment)，有時就必須透過編碼後才能傳送 Base64 是一種基於 64 個字符來表示的方法 Base64 中的 64 其實是有含意的，他會把資料轉成: a~z (26) A~Z (26) 0~9 (10) + (1) / (1) base64 的 64 就是上面五種字元的所有可能(26+26+10+1+1=64) 打開瀏覽器的 console 介面，用 Web API 就可以開箱及用...

前言 一直以來都只知道 DNS 是負責將域名(domain name)轉換成 ip 的網路服務，讓人類不需要去記又臭又長又難記的 ip，可以更輕鬆地透過類似門牌的域名來記憶網址．但隨著開發經驗愈來愈多之後，碰到各種網路上的問題，這時候就覺得自己懂的太少了，所以有了這篇來督促自己更深入的了解一下 DNS，以及它背後的其他元件． 主要的四種 DNS servers 圖片參考：cloudflare DNS server 又分成四種，各司其職的來完成 DNS Lookup Recursive Resolver 是 DNS Lookup 的第一步 當 client 遞迴的發送請求給 Recursive Resolver，他就會繼續往下一個 DNS server 發送請求來獲取 DNS record，直到 timeout 拋出錯誤或是成功找到 DNS record 為了避免同個 DNS record 每次都被 client 反覆請求，DNS 會有快取的機制以迅速回應相同的 DNS Lookup 若以圖書館來比喻，Recursive Resolver 就像是圖書館的管理員 Root Nameserver 是 DNS Resolve(Translate)的第一步 遵照 Recursive Resolver 想查找的 DNS record，去問下一個 TLD Nameserver 若以圖書館來比喻，Root Nameserver 就像是圖書館的索引(index)，指向不同書架上的書 TLD Nameserver TLD(top level domain)是一個網域的頂級網域，以 example....

前言 前陣子因為專案需求，需要把某個 docker 的 PostgreSQL container 資料備份到另一台 docker container 內，因此紀錄一下整體過程 簡例 首先，先拉取 postgresql 14.6 版的 image docker pull postgres:14.6 docker image | grep postgres # 取得image id 再來準備一份測試的 seed.csv，等等要匯入 postgresql 中 title,content Eric,Hello Madi,Hi Danny,GoAhead Kyle,Looks grood 將 postgresql 的 container 跑起來，並 bind mount 掛載剛剛的 csv 檔 docker run -itd --rm --name example -p 5432:5432 -v "$(pwd)"/seed.csv:/seed.csv -e POSTGRES_PASSWORD=postgres <image_id> 接著，跳進去 container 內，把 csv 的內容匯入 postgresql 中 docker exec -it example psql -U postgres -d postgres /* 要先依照csv的內容建立table */ CREATE TABLE article(title text, content text); /* 將csv匯入table */ COPY article (title, content) FROM '/seed....

前言 現今網路世界主要都是用 HTTP request-response 的 model 來做為溝通的模型，client 發送 request 給 server，server 再回傳 response 給 client，但是隨著 Web 的需求改變與技術的演進，漸漸需要另一種溝通方式，來讓 server 無須被 client 請求時就能主動傳送資料給 client，最常見的例子就是股票網站的股價更新、新聞網站的文章更新…等等，或是需要前後端雙方即時溝通的需求，衍生出 WebSockets 的誕生。技術上區分為 Client Pull 和 Server Push 兩種，本篇文章就稍微總結這兩種方式的差異，以及各自有哪些方法 實時更新的幾種方式 主要分成以下幾種方式: Client Pull Short Polling Long Polling Server Push WebSockets SSE (Server Send Event) Short Polling vs Long Polling 早期更新方式是透過 JavaScript 的 Polling(輪詢)來獲得 server 最新的資料 Short polling Short polling 是一個 AJAX-based 的 timer，讓 client 每隔一段時間去向 server 獲取資源，但效能不好，因為有可能 client 每隔 N 秒去問 server 時這 N 秒內資料都沒改動，就會浪費網路資源...

前言 前陣子入手一台 MacBook Pro，CPU 處理器是 Apple 自家的 M2 晶片，開發上意外發現使用 docker build 的 image 會無法運行在 AWS EC2 上的 Ubuntu 作業系統上，明顯違反了 docker 的口號: Build once, run everywhere，深入研究後才理解，原來這是跟 CPU 處理器的架構有關，稍微紀錄一下來龍去脈和問題解法，以供未來的自己回來參考 以 Python FastAPI 簡例還原問題 建置本地端的 docker image 首先，為了還原遇到的問題，用 python:3.9-slim 的 image 來 host 一個 container，並在裡頭運行一個簡單的 FastAPI server Python 環境建置、套件安裝 python3 -m venv venv source ./venv/bin/activate pip3 install fastapi uvicorn pip3 freeze > requirements.txt 並準備 FastAPI 主程式 from fastapi import FastAPI import uvicorn app = FastAPI() @app....