一些錯誤的想法和錯誤的感悟

2021-06-22 00:06:57 字數 2082 閱讀 3934

記住,ssl只是乙個傳輸層上的封裝協議,傳輸層上的。它代表的語義一定要比傳輸層更具體而比應用層更不具體。怎麼能拿它來封裝乙個具體應用呢?這是典型的主次顛倒,本末倒置,喧賓奪主的極端做法!https只能在ssl之上,難道能在ssl之下嗎?

這裡最重要的是資料邊界問題,你是用你的應用協議來定義資料邊界還是用ssl來定義你的資料邊界?誰能定義資料邊界誰就要在外邊,顯然,作為且僅僅作為乙個傳輸層安全增強協議,ssl只能在裡面。如果在外面,那麼你就必須要處理ssl record邊界和真正的你的應用邊界之間的關係,而這種對應關係的處理是極其不便的,不是因為複雜,而是不便,因為,只要你顛倒ssl和你的應用協議之間的封裝關係,這個問題就能得到完美的解決。看看openvpn的協議,這就是答案!

使用ssl record來封裝應用資料是乙個顛倒的做法,乙個典型的以ssl為中心的錯誤做法。

注意到ipsec的每乙個包都攜帶spi,用於對等體識別sa,為何每個包都要攜帶乙個sa而不是在傳輸前搞乙個握手,建立乙個「連線」,這樣sa們就可以儲存在該連線中而不用每次傳輸了。事實上,這樣做是對的,因為ip層本來就是沒有連線的,在這個意義上,openvpn建議用udp封裝,我覺得是合理的。而ssl最初為tcp應用而設計,內在有乙個連線保持,建立乙個會話,ssl將這種識別機制內建在了會話中,因此sa類似的概念便可以分別儲存在端到端的本地,不需要傳輸,這是另一種方式,和ipsec不在乙個層次。但是如果要在應用層實現乙個ip層的vpn,則openvpn的udp方式統一了它們。

我理解的ipsec已經不再是乙個框架以及相關的實現,而是一套思想,因此也就沒有了「雖然不必定製應用但是需要定製作業系統協議棧而帶來了複雜性和不穩定性」這種和一旦和ssl相比較時總會被人提到的劣勢,而這個劣勢幾乎是ipsec的唯一劣勢。排除了這個劣勢後剩下的這個思想就是協商認證和安全傳輸的分離。這個思想不僅僅可以讓你保持ip的語義,幾乎任何乙個層次的語義都是可以保持的,其帶來的靈活性更是帶來了更多的實惠,你可以在認證機制之外重新協商傳輸金鑰,你可以在安全傳輸的同時重新用同一種方式或者不同的方式進行協商,隨便怎麼都行。

匹配演算法將會變得越來越重要,毫不誇張。早年接觸過asic晶元,後來又接觸了並行cam查詢硬體,在那個時候,我都是很激動的,如今,我在週末的時候寫出的模組體現了這些思想,那就是你如何讓多個匹配過程同時進行,然後將匹配結果相與得到最後的結果。

在軟體上,你需要乙個框架,而這個框架在硬體上就是那些閘電路,這個框架可以滿足任何匹配進入並給出是否匹配的結果。這個演算法可以硬體化,並且可以證明硬體還是比軟體高效,但是卻沒有軟體靈活,很多時候在靈活和高效兩邊,必須權衡,但是在並行匹配演算法方面,不用權衡。試想,用硬體來實現並行匹配查詢,失去了什麼,本來我真的不好用乙個詞來表達,恰恰昨天同事告訴了我乙個術語,那就是「短路」,誠然,硬體查詢難以實現短路,是的,但是硬體演算法根本不需要短路。如果有5個匹配,同時我有5個匹配硬體單元,如果要用軟體演算法,沒有短路機制的情況下,需要5個時間單元,就算在第乙個匹配後短路,也需要1個時間單元,但是用硬體的話,總共也就乙個時間單元。這就是硬體演算法的好處。

我設計了乙個基於路由匹配演算法的訪問控制軟體模組,實際上就是按照源和目的位址的匹配,按照這個思想,我的意思是還可以用別的match,而不僅僅是源和目的位址,我需要做的就是將所有這些match對映成和源/目標位址那樣的u32數值(或者別的任何型別的數值,oo而已),然後按照最長掩碼匹配進行精確匹配,天啊,最長掩碼匹配真是乙個思想而不僅僅是乙個方法!由於演算法是固定的,那麼我就很容易將其硬體化,簡單的cam而已...思想。

這是一本絕棒的書,我超級喜歡!

早在幾年前我就在公司的書架上看到了這本書,當時覺得這是一本暢銷書,加上書名也沒有神馬吸引我的地方,我就沒有在意,要知道我從不讀暢銷書,我喜歡那種出版幾十年上百年的那種,另外我也不喜歡花哨的書名,我比較喜歡學術化的書名,因此我錯過了這本書,直到上週,我才買了一本,發現很好。

好在什麼地方呢?推理!推理太嚴謹了,作者提出乙個問題,並不直接解決這個問題,而是將這個大問題一步步分解,然後也不是逐步解決這些小問題,絕妙的地方在於,在作者描述之後,這些問題不解自答,這讓讀者不自覺認定作者所述的都是真理。雖然作者的觀點並不一定是真理,但是這種毫無漏洞的論述方式不禁讓人嘆為觀止。

我不知道,反正都往裡面擠。便宜嗎?是的!家長缺錢嗎?不!關鍵是主導的傳統觀念在作怪。實際上就算公立幼兒園把小孩訓練成傻子,家長也很樂意將孩子送去,因為它是邁向高考的第一步。

我根本不屑於這種誇張。

錯誤處理的一些想法

錯誤處理在程式設計中是很重要的,可以在除錯,發布的時候少了很多麻煩,以往在做軟體的時候總是少了錯誤處理,導致使用者用來莫名其妙,在查詢問題的時候也是沒有頭緒 最近在總結一些錯誤處理技巧,總共有這麼一些方法 1.log log在關鍵的時刻可以救命的東西,因此我一直提議組裡的人多使用log,但是log記...

遞迴學習的一些錯誤總結與想法

1.找到停止遞迴的條件 2.找到每一層遞迴之間的聯絡 問題1 將多層迴圈簡化 找出從自然數1 2 m中任取k 個數的所有組合。例如m 5,k 3 案例 輸入5 3 的時候 5 35 4 3 5 4 2 5 4 1 5 3 2 5 3 1 5 2 1 4 3 2 4 3 1 4 2 1 3 2 1 分...

錯誤的想法

有很多我們經常使用的思想方法是錯誤的。敵人的敵人是朋友,我不知道要多麼愚蠢才能產生這樣的想法。多數情況下,敵人的敵人是更加危險的敵人。這一點不需要依靠邏輯和社會閱歷,就憑簡單的常識就應該理解。乙個最簡單的例子,劫財的強盜和劫色的強盜兩家互為敵人。要麼是一,要麼是二,沒有其他選擇。我不知道乙個人要愚蠢...