tcpkill

當 TCP 已經建立連線後，使用者可在此連線下，持續傳送封包資料，這時候加上 firewall rule 擋掉該來源 IP 無法作用到已經建立的 TCP 連線上。在不停掉提供服務的 server 的狀況下，可以透過 tcpkill 強制關閉該 TCP 連線。

tcpkill 在 dsniff 套件中，在 CentOS 可透過 epel repo 安裝

yum -y install dsniff -enablerepo=epel

tcpkill 切斷 TCP 連線的原理是，模擬發送 RST 封包，但因為發送該封包必須要先知道 SEQ/ACK，所以執行 tcpkill 會發現程式並沒有馬上結束，而是持續在 listening 的狀態。

這時候 tcpkill 會持續監控網路封包，直到有收到符合條件的封包時，才能結束該 TCP 連線。

在使用前，可先用 netstat -anlp 查詢目前的所有網路連線 IP 及 Port 狀況。可用 ip host 或是 port 參數指定條件。

# tcpkill ip host 1.2.3.4
tcpkill: listening on eth0 [ip host 1.164.232.236]
1.2.3.4:38784 > 192.168.1.10:5556: R 305630104:305630104(0) win 0
1.2.3.4:38784 > 192.168.1.10:5556: R 305638604:305638604(0) win 0
1.2.3.4:38784 > 192.168.1.10:5556: R 305655604:305655604(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839752684:2839752684(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839754086:2839754086(0) win 0
192.168.1.10:5556 > 1.2.3.4:38784: R 2839756890:2839756890(0) win 0
^C

再利用 netstat 檢查 tcp 連線後，就可確認沒有來自該來源 IP 的 TCP 連線，後續因為設定了 firewall rule，確實擋掉了該 IP，也無法建立新的連線。

心理防衛機制 Defense Mechanism

心理防衛機制是人類的正常反應，人類在無意識中，透過心理防衛機制，減輕不能接受或可能有害的焦慮。

一個人會產生的防衛機制，跟心智成熟度有關，越原始的防衛方法，效果越差，維持的時間也會比較短。

原始的防衛機制

Denial 否認

拒絕現實發生的事情，假裝某個想法或事件沒有發生過。

Regression 退化

當承受過多壓力時，行為動作可能會回到嬰幼兒時期，像一個小孩一樣，這樣會比較有安全感

Acting Out 行動化

以極端的方式宣泄情緒，例如丟東西，搥牆壁，甚至是自殘。

Dissociation 解離

一個人失去時間感，或暫時失去人格完整性，例如在車禍後，喪失發生時那一個片段的記憶

Projection 投射

將自己無法接受的想法，賦予到別人身上，推卸責任藉此得到解脫。

Reaction Formation 反向作用

心裡想的跟實際做的完全相反，例如男生會故意捉弄喜歡的女生

稍微成熟一點的防衛機制

Repression 壓抑

遺忘造成心理創傷的事件，就不會被該事件影響

Displacement 替代

將接收到的情緒，轉移到別人身上，特別是身邊親密的人。例如工作上被責備，回家後對家人吼叫

Intellectualization 理智化作用

遇到悲傷的事，或是不如預期的事情，會想出一套說詞說服自己

Rationalization 合理化作用

用看似合理的藉口去解釋某些行為

Undoing 抵消

一個人試圖挽回下意識傷人的行為或話語

成熟的防衛機制

Sublimation 昇華

將心裡面不符合社會規範的衝動或慾望，以合於社會規則的方式表現出來。ex: 自嘲

Compensation 補償

當自己心理或生理有某些缺陷，會發展其他部分彌補這個缺陷

References

心理防衛機制是什麼？你我的潛意識都會保護自己 - Hello 醫師

心理防衛機制 - 維基百科，自由的百科全書

你心智多成熟？看你「心裡防禦機制」就知道！12種防禦機制！【心理學】 | 維思維 - YouTube

Gall’s Law

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and can not be made to work. You have to start over, beginning with a simple system." - John Gall, systems theorist.

一個複雜的系統，是由簡單的系統慢慢演化而來的。如果要從無到有，設計出一個複雜的系統，是絕對不可能成功的，任何複雜的東西，都要從簡單（基本）做起。

一個外表看起來複雜的系統，如果仔細去分析內部的架構，會發現它是由很多簡單的結構組合而成的。沒有一個系統可以無中生有憑空產生。

這是系統分析要做的事情，系統分析就是要透過設計的方法，將一個完整複雜的系統，切割為多個可被容易理解的子系統/流程。但分析不能太過注意細節，系統與流程的實作細節，要交給系統設計去處理。因為一個太精細的系統分析結果，反而會讓人難以整合出整個系統全貌。

跟 Gall’s Law 類似的法則是 KISS Principle。

Keep it simple, stupid (KISS) 就是在進行系統設計時，要盡可能保持簡單。換句話說，就是不能做過度設計 over design，過度設計的系統，會因為多餘的考量，讓使用者難以理解，也會犧牲掉運作的靈活/流暢度。

另外還有一個類似的奧卡姆剃刀原則 Occam's Razor

「切勿浪費較多東西，去做『用較少的東西，同樣可以做好的事情』。」

「如無必要，勿增實體。」(Do not multiply entities beyond necessity.)

這幾個原則都有一些共同的代名詞：化繁為簡、避重趨輕、避繁逐簡、以簡御繁、避虛就實。

References

对开发人员有用的定律、理论、原则和模式 - 腾讯产业互联网学堂

KISS原則 - 維基百科，自由的百科全書

奧坎剃刀 - 維基百科，自由的百科全書

Rate-Limit Algorithm

rate-limit 是在某個時間區間內，能夠被執行的次數限制。在大型分散式系統，必須要內建這個限制，避免系統因為短時間內收到大量的 requests 造成問題。

系統有可能會遇到的攻擊

1. brute force attacks

   攻擊者可能針對 login 及忘記密碼，用亂數帳號進行暴力的攻擊，試圖取得可以登入系統的帳號

2. Dos, DDos

   攻擊者利用大量的 requests 癱瘓系統運作，導致系統無法接受並處理正常的使用者的 requests

3. Web Scraping

   這是網頁抓取的方法，攻擊者可透過工具，分析網頁的內容，並抓取整個網站的所有可能的連結資料。

• Rate Limit

  限制 requests 在某段時間區間內，允許執行的數量

• Throttling

  控制 request 可被服務的頻率，ex: 控制 requests 每 100ms 可處理 10 個 requests，如果超過這個頻率的 request，可以允許另一個 threshold 的數量被處理，ex: 15/100ms，直到超過這個 threshold，就會被拒絕服務

Token Bucket

想像有一個水桶，裡面放 n 個 token，當使用者發出 request，必須要先到水桶取得一個 token，取得 token 後，就能繼續執行，如果無法取得 token，就會被拒絕。

水桶中的 token 會依照 1/n second 的速度，補充 token 到水桶中，直到補滿 n 個 token。

當水桶裡面有 n 個 token，可允許瞬間發生 n 個 requests，也就是同時被取走 n 個 tokens，也就是允許系統突然暴增的 requests。

Leaky Bucket

跟 Token Bucket 很相近，一樣想像有個水桶，預先設定了該水桶可流出 token 的速度，如果收到 requests 的速度超過允許流出的速度，就會累積在水桶裡面 (queue)，如果水桶裡面超過了 n 個 tokens，後續的 requests 會被丟棄。

系統不允許發生突然暴增的 requests。

Fixed Window Counter

預先定義每個時間區間下允許執行的 request 數量 n，時間區間是固定的 (ex: 00:00:01 ~ 00:00:02, 00:00:02 ~ 00:00:03)，每個時間區間都有一個 counter，當發生了新的 requests，就會計算這個時間區間的 counter，如果新增的 request 讓 counter 超過 n，就必須丟棄這個 request。

這個方法可能會遇到的問題是，如果時間區間 (00:00:01.500 ~ 00:00:02.000) 及 (00:00:02.000 ~ 00:00:02.500) 都產生了 n 個 requests，就等於在時間區間 (00:00:01.500 ~ 00:00:02.500) 發生了 2n 個 requests。

Sliding Window Logs

類似 Fixed Window Counter，記錄每一個 reuqest 發生的時間店，當有新的 request 發生時，會去比較目前的時間點到先前某一個時間點，這個時間區間的 requests 數量，用這個數量來衡量是否允許執行這個 request，如果超過了預先定義的數量，就會丟棄這個 request。

Sliding Window Counter

這個方法整合了 Fixed Window Counter 及 Sliding Window Log 的方法，概念上也是用 Fixed Window Counter，但將每個時間區間，又再切割了多個子區間。再比對某個 requst 是否允許執行時，就是比對目前這個時間點到先前多個子時間區間的 counter 總和，如果超過預先定義的值，就會丟棄該 request。

有了 Fixed Window Counter 及 Sliding Window Log 的優點，且實作並不困難。

References

實作 API Rate limiter George's blog

System Design Concept: Rate limiting

Rate limiting - Wikipedia