程式設計思想和網絡協定處理

1.JAVA程式設計思想

最近在看《JAVA程式設計思想》，賜予我思想吧，我要程式設計，字字珠玑，遍地思想啊！

2.最近在實作一個協定

如何判斷一段資料是一個IP資料報，這個問題很簡單，但是暴露的卻是一個大問題。引發的是更多的思想。

3.OpenSSL的心髒流血

一個資料包的標頭長度字段辨別的長度并不是資料包的真實長度，關鍵是你為何憑空信任所謂的對端發來的資料。

4.記憶體保護

不要指望代碼的行為是正常的，關鍵是保護好你的記憶體，使用mprotect取消所有的通路權限，當你真的要通路的時候再開放權限，一般可以在SIGSEGV的進行中開放權限。最底層的保護最靠譜！對于所有的計算機處理而言，根本的東西就是記憶體裡面的東西。

它不是一蹴而就從無到有的，而是站在了許多巨人和侏儒的肩上。

1.網際網路通信協定并非從頭開始設計的，完全是在電信網(電話通信網)的基礎上設計的；

2.網際網路通信協定最初運作于通用計算機(以及少量專有嵌入式裝置)，設計之初的原則是，協定頭盡可能的要小以節省帶寬。

3.第2點所示的原則稱為吝啬原則，設計之初，CPU資源也是一種稀缺資源，是以協定頭不但要小，還要簡單，便于解析。

4.在更早的終端年代，行規程負責定義格式而對其進行解釋，随後影響了網絡協定棧的形成。

對個體的分類以及描述，是一種進入文明社會的象征，動物世界和原始人沒有描述，它們隻有感官形成的觀念，文明社會的人類除了人本身還有描述，比如身份證，檔案，特征描寫，....有人說這是柏拉圖的遺毒，但實際上，我們正是生活在柏拉圖的抽象的世界裡。

      類型的出現，作為一種程式設計的文明社會的開始，意義非凡，它一改曾經的不在乎類型的觀念，曾經，你可以做強制類型轉換，但是沒人沒保證這麼轉換的正确性，可是在對象的世界裡，類型是一個最基本的觀念，任何資料都要有一個描述來标示自身，這些描述甚至連字段的名字都包含在内，這樣你就可以做反射，内省，序列化，要知道動物和野蠻人是不懂内省的...在對象的世界程式設計，終于可以回答“我是誰？”的問題了，以前，拿到一個指針，你不知道它是什麼類型，現在可以知道了。在C語言中，我們執行以下代碼：

正确嗎？實際上隻有一種情況下這麼轉型才是安全的，取決于struct A的定義：

看出什麼了嗎？這就是類型！在對象的世界程式設計，如果有一個變量，你可以用反射機制得到它的類型，得到該類型的所有特征。在非對象的世界，大量的系統崩潰都是因為“不恰當的轉型”引發的，所有的代碼絲毫沒有類型檢查機制，所有的東西都在記憶體裡，程式可以任意解釋記憶體裡資料的内容，實際上正确的做法是，内容的中繼資料，内容的類型資訊，描述資訊等也要和内容儲存在一起，正如我們的身份證要随身攜帶一樣，按照嚴格的做法，如果我不能證明你的身份資訊，我甚至都不能證明自己是一個人，之是以人家覺得我起碼還是一個人，可能是因為對方覺得我和他長得差不多，但是這種方式是不嚴格的。

對于網絡資料包而言，你無法證明該資料包就是一個嚴格的IP資料包或者就是一個HTTP資料包，當然我不能如此苛刻的對待IP這種已經很完美的協定，幸運的是，由于繼承了電信信令協定的簡單性特征，我們真的沒必要對IP太苛刻，換句話說，我們可以經過很少的檢測證明一段資料就是一個IP資料包，因為我們隻需要判斷不多的幾個字段符合IP協定頭的格式即可。但是對于應用協定，這種做法就不合适了。

      資料通信領域可以分為兩個子系統，位于傳輸層之上的屬于内容子系統，而此之下的屬于傳輸子系統，等價的分類是我們熟悉的資源子網和通信子網之間的分類。對于通信子網而言，協定是标準的，是以可以使用電信網的那一套規程，但是現如今人們把那套做法移植到了應用層，這就是滋生BUG的溫床。雖然很多應用層協定也是标準化的，但是這種标準化是不能指望的，你不能說它恰好沒有出錯就說這種方式一定就是合适的。在很早之前的一篇文章中我就說過，應用層協定一定要有一種自解釋的機制，應用層協定的目的是資訊交換，這就涉及到了編碼和對編碼的解釋，是不是很像對象的序列化和反序列化，這種情況下，能拿到的隻有交換資料本身而不能指望其它，指望其它就意味着可能被欺騙，而通信子網的目的并不是資訊交換，它隻是一種辨別機制，不會涉及複雜的解釋問題，是以不需要自解釋。

      對象的序列化是一種方式，而更為普遍的是XML和ASN.1方式，對于XML而言，除了資料内容之外，還有節點屬性，名字等，對于ASN.1而言，任何東西都可以用一種統一的TLV形式編碼，包括内容和描述。我們抛開網絡協定，隻考慮一種情景，給你一段二進制資料，請告訴我它是什麼類型。當你實作這個的時候，你是模仿IP的方式還是使用ASN.1的方式呢？

      RMI是一種融合了邏輯處理的資料交換，可能更好？

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1394532