Yoru Karu Studio

🚀 MQTT 協定詳解 MQTT 在網路模型中的位置 ┌──────────────────────────────────────────────────────────┐ │ OSI 七層模型 TCP/IP 四層模型 │ ├──────────────────────────────────────────────────────────┤ │ 7. 應用層 (Application) │ │ ├─ MQTT ───────────────┐ 應用層 (Application) │ │ │ (MQTT, HTTP, STOMP...) │ ├─────────────────────────────┤ │ │ 6. 表現層 (Presentation) │ │ ├─────────────────────────────┤ │ │ 5. 會話層 (Session) │ │ ├─────────────────────────────┼─────────────────────────────┤ │ 4. 傳輸層 (Transport) │ 傳輸層 (Transport) │ │ └─ TCP ─────────────────┘ (TCP) │ ├─────────────────────────────┼─────────────────────────────┤ │ 3. 網路層 (Network) │ 網際網路層 (Internet) │ │ └─ IP │ (IP, ICMP, ARP) │ ├─────────────────────────────┼─────────────────────────────┤ │ 2.

08-3. 分布式鎖實現 📌 什麼是分布式鎖？ 在分布式系統中，當多台服務器需要訪問同一個共享資源時，需要一種機制來協調它們的訪問順序，這就是分布式鎖。 為什麼需要分布式鎖？ 單機環境 vs 分布式環境 # ❌ 單機環境：Python 線程鎖可以工作 import threading lock = threading.Lock() def update_inventory(): with lock: # 臨界區代碼 inventory = get_inventory() inventory -= 1 save_inventory(inventory)問題： 當有多台 Django 服務器時，每台服務器有自己的內存空間，threading.Lock() 無法跨進程工作！ 服務器 A (lock 1) → 數據庫 ← 服務器 B (lock 2) ↓ ↓ 各自的鎖互不影響，仍然會出現競態條件！ 🎯 分布式鎖的特性 一個好的分布式鎖應該具備： 1. 互斥性 在任意時刻，只有一個客戶端能持有鎖 2. 不會死鎖 即使持有鎖的客戶端崩潰，鎖最終也能被釋放 3. 容錯性 只要大部分節點正常運行，客戶端就能加鎖和解鎖 4. 加鎖和解鎖必須是同一個客戶端 不能把別人的鎖給解了 💻 實現方式對比 方案 優點 缺點 適用場景 Redis 性能高、實現簡單 可能存在鎖丟失風險 大部分場景 數據庫 可靠性高、無需額外組件 性能較差 低並發場景 Zookeeper 可靠性最高、支持阻塞鎖 複雜度高、需額外維護 對一致性要求極高的場景 🔴 方案 1：Redis 分布式鎖（推薦） 基礎版本：SETNX + EXPIRE import redis import time import uuid class RedisLock: """基礎版本的 Redis 分布式鎖""" def __init__(self, redis_client, lock_name, expire_time=10): """ :param redis_client: Redis 客戶端 :param lock_name: 鎖的名稱 :param expire_time: 鎖的過期時間（秒） """ self.

⚠️ 免責聲明 本文內容僅供教育與學習用途。請勿將文中技術用於任何未經授權的系統或惡意目的。 📚 本篇重點 🎯 理解 DOM-based XSS 的獨特性 🔍 識別危險的 JavaScript API 🛡️ 學習前端防禦策略 💼 掌握實際案例與檢測方法 閱讀時間: 約 18 分鐘 難度: ⭐⭐⭐ 中高階 1️⃣ 什麼是 DOM-based XSS? 📖 定義 DOM-based XSS 是一種特殊的 XSS 攻擊,攻擊完全發生在客戶端(瀏覽器),惡意 Payload 從未發送到伺服器,而是通過操作 DOM(Document Object Model)直接在瀏覽器中執行。 🔑 關鍵差異 特徵 Reflected/Stored XSS DOM-based XSS 攻擊位置 伺服器端 → 客戶端 🔴 純客戶端 Payload 傳遞 HTTP 請求 → 響應 🔴 URL Fragment (#) 伺服器記錄 ✅ 有記錄 🔴 無記錄(# 後不發送) 檢測難度 較易 🔴 困難 防禦層 伺服器 + 客戶端 🔴 只能在客戶端 WAF 有效性 有效 🔴 無效 🔄 攻擊流程對比 傳統 XSS (Reflected/Stored):

📨 即時通訊協定概覽 🎯 什麼是即時通訊協定？ 想像一個郵局系統，有不同的郵寄方式： 平信：HTTP，寄出去就不管了，沒有回執 掛號信：有送達確認，但比較慢 快遞：專人配送，可以即時追蹤 郵政信箱：訂閱制，有新信就通知 即時通訊協定就像這些不同的郵寄方式，針對不同需求設計出不同的訊息傳遞機制。 🏗️ 常見的即時通訊協定 1️⃣ MQTT (Message Queuing Telemetry Transport) 特性：輕量級、低頻寬、低功耗 💡 比喻：訂閱制報紙 你訂閱了「體育版」，報社有新的體育新聞就會自動送到你家 不需要你每天去報社問「有新聞嗎？」適用場景： ⚡ IoT 物聯網裝置（智慧家居、感測器） 📱 行動裝置（省電、省流量） 🌐 網路不穩定環境 架構：發布/訂閱模式（Pub/Sub） Publisher → Broker → Subscriber 裝置 A 發布 "temperature/living-room" = 25°C 裝置 B 訂閱 "temperature/#" → 收到通知Python 範例： import paho.mqtt.client as mqtt # 訂閱者 def on_connect(client, userdata, flags, rc): print("連接成功") client.subscribe("home/temperature") # 訂閱溫度主題 def on_message(client, userdata, msg): print(f"收到訊息：{msg.topic} = {msg.

08-2. 秒殺系統設計 📌 什麼是秒殺系統？ 秒殺系統是電商平台在特定時間段內，以極低價格限量銷售商品的場景。 典型特徵 商品：iPhone 15 Pro Max 256GB 原價：NT$ 42,900 秒殺價：NT$ 9,999 數量：10 台 時間：2025-01-20 12:00:00 預期參與人數：100萬+ ⚡ 秒殺系統的挑戰 1. 瞬間流量暴增 正常流量：1,000 QPS（每秒請求數） 秒殺流量：100,000 QPS（100倍） 持續時間：幾秒到幾分鐘2. 讀寫比例失衡 讀操作（查詢庫存）：99.99% 寫操作（實際購買）：0.01%10萬人搶10台手機，只有10個人能成功。 3. 惡意請求 機器人刷單 腳本自動下單 惡意佔用資源 🏗️ 系統架構設計 整體架構圖 ┌─────────────┐ │ 用戶端 │ └──────┬──────┘ │ ┌──────▼──────┐ │ CDN + │ │ 靜態資源 │ └──────┬──────┘ │ ┌──────▼──────┐ │ Nginx │ │ 限流 + 防攻擊│ └──────┬──────┘ │ ┌─────────────────┼─────────────────┐ │ │ │ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │ Django │ │ Django │ │ Django │ │ Server │ │ Server │ │ Server │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ └─────────────────┼─────────────────┘ │ ┌─────────────────┼─────────────────┐ │ │ │ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ │ Redis │ │ Message │ │ MySQL │ │ 緩存 │ │ Queue │ │ 數據庫 │ └─────────┘ └─────────┘ └─────────┘ 🎯 核心設計思路 1.

⚠️ 免責聲明 本文內容僅供教育與學習用途。請勿將文中技術用於任何未經授權的系統或惡意目的。 📚 本篇重點 🎯 理解 Stored XSS 的攻擊原理與危害 💣 認識史上最著名的 XSS 蠕蟲攻擊 🛡️ 學習完整的資料庫存儲防禦策略 💼 掌握 Django 最佳實踐 閱讀時間: 約 20 分鐘 難度: ⭐⭐⭐ 中高階 1️⃣ 什麼是 Stored XSS? 📖 定義 Stored XSS(持久型跨站腳本攻擊)是一種將惡意腳本永久儲存在目標伺服器(資料庫、檔案系統、訊息論壇等)的攻擊。當其他用戶訪問包含惡意腳本的頁面時,腳本會自動執行。 💣 為什麼是最危險的 XSS? 特徵 Reflected XSS Stored XSS 影響範圍 單一用戶 🔴 所有訪問用戶 傳播能力 需要誘騙點擊 🔴 自動傳播 持續時間 一次性 🔴 永久存在 攻擊難度 較低 較高 檢測難度 較易 🔴 較難 清理難度 無需清理 🔴 需要清理資料庫 🔄 攻擊流程 Step 1: 攻擊者提交惡意腳本 ↓ Step 2: 伺服器儲存到資料庫(未驗證/未編碼) ↓ Step 3: 其他用戶訪問頁面 ↓ Step 4: 伺服器從資料庫讀取並顯示內容 ↓ Step 5: 受害者瀏覽器執行惡意腳本 ↓ Step 6: Cookie 被竊取 / 帳號被劫持 / 蠕蟲傳播🌟 生活比喻 想像一個公共布告欄: