與HTTP類似，IPFS是基於TCP/IP的應用層協議，同時作為一個分佈式的文件系統，IPFS提供了一個支持部署和寫入的平臺，同時能夠支持大文件的分發和版本管理。IPFS協議棧由七層負責不同功能的子協議構成：
- 身份層：管理節點身份生成和驗證。
- 網絡層：管理與其他對等體的連接，使用各種底層網絡協議。
- 路由層：維護信息以定位特定的對等體和對象。響應本地和遠程查詢。默認為DHT，但可更換。
- 交換層：一種支持有效塊分配的新型塊交換協議（BitSwap），模擬可信市場，弱化數據複製，防作弊。
- 對象層：具有鏈接的內容尋址不可更改對象的Merkle DAG，用於表示任意數據結構，例如文件層次和通信系統。
- 文件層：由Git啟發的版本化文件系統層次結構。
- 命名層：自我認證的可變名稱系統。
1、身份層（Identity）
所有節點在IPFS網絡中都要一個唯一的NodeId進行標識，其實就是一個公鑰的哈希，然而為了增加攻擊者的成本，IPFS使用了S/Kademlia中提到的算法增加創建新身份的成本，源碼如下：
difficulty = <integer>
n = Node{}
do {
n.PubKey,n.PrivKey = PKI.genKeyPair()
n.NodeId = hash(n.PubKey)
p = count_preceding_zero_bits(hash(n.NodeId))
} while (p<difficulty>/<integer>
S/K要求每個節點在接入網絡前必須解決兩個密碼學問題。靜態問題是：產生一對公鑰和私鑰，公鑰兩次哈希運算後，具有C1個前導零。公鑰的一次哈希值就是節點的NodeID。動態問題是：不斷生成一個隨機數X，將X與NodeID求XOR再求哈希，哈希值要求C2個前導零。這樣設計，第一個靜態問題，保證節點不能再自由選擇節點ID，後一個動態問題，提高了大量生成ID的成本。女巫攻擊和日蝕攻擊將難以進行。
每一個節點在IPFS網絡中由Node結構體來表示，其中只包含NodeId以及一個公私鑰對：
type NodeId Multihash
type Multihash []byte //子描述加密哈希摘要
type PublicKey []byte
type PrivateKey []byte // 子描述的私鑰
type Node struct {
NodeId NodeID
PubKey PublicKey
PriKey PrivateKey
}
身份系統的主要作用是標識IPFS網絡中的每一個節點，有點像用戶信息的生成。在節點建立首次連接時，對等節點將交換公鑰，並檢查hash（other.PublicKey）是否等於other.NodeId，相當於校驗用戶信息，如果校驗結果不相等，則用戶信息不匹配，節點連接立即終止。
IPFS的哈希算法比較靈活，支持根據輸入自定義值來調整，默認以Multihash格式存儲，源碼定義如下：
<function><digest><digest>
/<digest>/<digest>/<function>
這種加密方式有兩個優勢：
- 根據需求選擇最佳功能用例。在更強的安全性和更快的性能之間做一個平衡取捨。
- 隨著功能的變化而演變，自定義值可以兼容不同場景下的參數選擇。
2、網絡層（Network）
IPFS節點與其他節點連接通信的時候，會跨越廣域網，IPFS網絡堆棧的特點如下：
- 1.傳輸：IPFS兼容現有的主流傳輸協議，其中最適合瀏覽器端使用的WebRTC Data Channels，低延時uTP（LEDBAT）傳輸協議等。
- 2.可靠性：使用uTP和sctp來保障，這兩種協議可以動態調整網絡狀態。
- 3.可連接性：使用ICE等NAT穿越技術來實現廣域網的可連接性。
- 4.完整性：使用哈希校驗檢查數據完整性，IPFS中所有數據塊都有唯一的Hash。
- 5.可驗證性：使用數據發送者的公鑰以及HMAC消息認證碼來檢查消息的真實性。
WebRTC（Web browser Real Time Conmunication）網頁實時通信技術，適用於網頁間音視頻實時通信，點對點數據共享。免費開源的WebRTC內置於瀏覽器中，用戶不需要使用任何插件或者軟件通過瀏覽器實現實時通信。
如需更多對WebRTC的連接，查看如下網頁：詳解WebRTC——網頁實時通信技術
LEDBAT(Low Extra Delay Background Transport)是一種在不阻塞網絡的情況下快速傳輸數據的方法。LEDBAT是一種基於延遲的擁塞控制算法，它使用所有可用的帶寬，同時限制延遲的增加。它通過測量單向延遲和使用測量的變化來限制LEDBAT流本身在網絡中引發的擁塞。
IPFS可以使用任意的網絡進行通信，並沒有完全依賴於IP層，IPFS是通過multiaddr的格式來表示目標地址和使用的協議，以此來兼容和擴展未來可能出現的其他網絡協議：
# an SCTP/IPv4 connection
/ip4/10.20.30.40/sctp/1234/
# an SCTP/IPv4 connection proxied over TCP/IPv4
/ip4/5.6.7.8/tcp/5678/ip4/1.2.3.4/sctp/1234/
這也意味著IPFS的網絡通信模型是遵循覆蓋網絡（Overlay Network）的理念設計的，下面的模型圖說明IPFS的網絡架構模型是疊加的虛擬化技術模式，建立在已有網絡的虛擬網，用邏輯節點和邏輯鏈路構成。多個容器在跨主機通信的時候，使用Overlay Network這個網絡模式，會虛擬出一個網絡比如10.0.9.3這個IP地址，一個類似服務網關的地址，然後把數據包轉發到Host物理服務器地址，最終通過路由和交換，達到另一個Host服務器的IP地址。
三、路由層（Routing）
IPFS節點需要一個路由系統，可用於查找：
- 同伴節點的網絡地址。
- 服務特定對象的對等節點。
IPFS路由層數據結構使用的是S/Kademlia和Coral技術的分佈式鬆散哈希表（DSHT），IPFS的DSHT結構會根據所存數據的大小值進行區分：小的值（等於或小於1KB）直接存儲在DHT上，更大的值，DHT只存儲值索引，這個索引就是一個對等節點的NodeId，該對等節點可以提供對該類型值的具體服務，DSHT的接口位於libP2P模塊中，如下：
type IpfsRouting interface {
ConnectRouting //內容路由
PeerRouting //節點路由：獲取特定NodeId的網絡地址
ValueStore //數據操作：對DHT中的元數據進行操作
Bootstrap(context.Context) error
}
type ConnectRouting interface {
Provide(context.Context,*cid.Cid,bool) error
FindProvidersAsync(context.Context,*cid.Cid,int) }
type PeerRouting interface{
FindPeer(context.Context,peer.ID)(pstore.PeerInfo,error)
}
type ValueStore interface {
PutValue(context.Context,string,[]byte) error
GetValue(context.Context,string) ([]byte,error)
GetValues(c context.Context,k string,count int) ([]RecvdVal,error)
}
IPFS的路由層需要實現三種基本的功能：內容路由，節點路由和數據存儲。集成這些功能的接口降低了系統的耦合度，可以讓開發者根據業務需求進行底層自定義的同時也不會影響系統其它部分的正常工作。
閱讀更多 星系雲科技 的文章
