最初驅動了Internet的設計，並且使得Internet今日如此成功的原則，RFC 1958這份文檔列出了這些原則，並且對他們進行了討論。對於所有的協議設計者都必須好好的看看這份文檔，也是必修課。以下概要地列出這10條原則。
1、保證協議能夠工作。
直到有多個原型系統能夠可以成功地相互通信之後，纔可以最終確定設計或者確定標準協議。現在的設計者往往先編寫出一份1000頁的標準，並申請批准之後，才發現標準中有嚴重的缺陷，而且它根本不能夠工作。然後他們再編寫1.1版本的標準，這並不是正確的工作方式。
毫無疑問，任何時候都應該使用最簡單的方案。奧卡姆的威廉（William of Occam）在14世紀的時候就已經提出了這條原則了（稱爲奧卡姆的剃刀 Occam‘s razor），換成現代的術語就是：決鬥特性（fight feature）。如果一項特性並非絕對本質的的特性，那麼就不應該考慮該特性，尤其是，如果通過組合其他的特性也能夠獲得同樣的效果的情況下。
如果有幾種方法可以完成相同的事情，則選擇其中一種方法。用兩種或者多種方法來做同樣的事情簡直就是自找麻煩。通常標準會有多個選項，或者有多種模式，或者有一些參數，因爲實力強大的參與方堅持認爲他們的方法是最好的。而設計者必須堅決抵制這種傾向，要學會說“不”。
這條原則直接導致了協議棧的思想，每一層上的協議獨立於其它的協議。按照這種方法，如果實際環境中要求改變一個模式或者一層，則其它的模塊不會受到影響。
在任何一個大型的網絡中，不同的硬件、傳輸設施和應用都有可能存在，爲了能夠對它們進行處理，網絡的設計必須簡單、通用和靈活。
如果不可避免要使用參數的話（比如最大的分組長度），那麼，最好的辦法就是讓發送方和接收方協商一個值，而不是定義固定的參數值。
通常設計者有一個好的設計，但它不能夠處理一些怪異的特例，那麼，設計者不應該爲此而對該設計進行大幅度的修改，而應該堅持這個好的設計，並且將支持怪異特例的負擔轉移到那些對此有特殊需求的人身上。
換句話說，只發送那些嚴格符合標準的分組，但是，容許接收到的分組可能是不完全符合標準的，並且要試圖對它們進行處理。
如果一個系統需要有效地處理上百萬臺主機和幾十億用戶，那麼，存在任何一箇中心化的數據庫都是難於容忍的，也就是說，不能使用中心化的數據庫，同時，必須將負載儘可能均勻的分佈到所有可利用的資源上。
如果一個網絡的性能很差，或者代價特別高，那麼沒有人會使用這樣的網絡。
--《計算機網絡（第四版）》