當你用你自己的計算機連線到網路上另一臺計算，你有會有很好的使用TCP/IP傳送位元組資料的機會，因為這個過程非常成功的融合了網際網路協議和傳輸控制協議。網際網路協議（IP）負責定址和傳輸資料包，傳輸控制協議（TCP）是用於確保被髮送的資料能夠完全並且以正確的順序被接收方接收。

　　因為TCP/IP是無處不在的並且得到了很好的支援，因此它通常是網路應用程式的預設選擇。在一些場景中，TCP增加了很多開銷，因此一些應用程式可能使用UDP協議，這是一個不保證順序和可靠性的更簡單的協議。

　　雖然TCP和UDP（還有IP）是現今最常用的協議，但是這並不意味著他們是唯一的選擇。在底層（傳送原始乙太網資料包或者藍芽框架）和上層（例如QUIC,它是比UDP更上層的協議）都存在一些其他協議可以選擇。

　　在libp2p中，我們呼叫這些基本協議，使得資料在transports層流轉，libp2p的其中一個重要需求就是使傳輸層協議不可知。這就意味著決定使用什麼樣的傳輸層協議完全依賴開發者，事實上，一個應用程式可以同時支援許多不同的傳輸層協議。

監聽和撥號

　　傳輸層有兩個核心操作，監聽和撥號。

　　不論傳輸層實現提供的是什麼樣的設施，監聽意味著你都可以接收來自其它對等節點的連結。例如，Unix作業系統平臺上的TCP協議是用bind和listen系統呼叫來實現嚮應用程式的TCP埠傳送系統流量資料的。

　　Dialing是向外傳送連線請求到監聽節點的過程。與監聽一樣，實現決定了它的特定過程，但是在libp2p實現中，每個傳輸協議都會共享使用相同的程式設計介面。

定址

　　在你可以撥號一個對等節點和建立連結之前，你需要先知道如何才能聯絡到它們。因為每種傳輸協議很可能都有它自己的地址框架，libp2p使用一個慣例上稱作多地址或者multiaddr的方法來編碼編碼許多不同的定址框架。

　　文件addressing doc講述了更詳細的資訊， 但是整體上了解多地址是如何工作的對理解撥號和監聽介面是非常有幫助的。

　　這裡有一個關於TCP/IP傳輸協議的多地址的例子：

　　這個和我們熟悉的7.7.7.7:6542格式是等價的，但是它還有其他好處，比如它顯示的描述了這個協議，從它的多地址格式上，我們可以瞭解到它的地址7.7.7.7是屬於IPv4協議，而且6543是輸入TCP協議。

　　想要了解更為複雜的示例，可以看Addressing。

　　撥號和監聽都可以處理多地址形式。當監聽時，你給傳輸協議指定你要監聽的地址，當撥號時，你提供要被撥號的地址。

　　當要撥號遠端對等節點時，這個多地址應該包含你將要試圖建立連線的節點的PeerId。這可以讓libp2p建立一個安全的通道，並阻止假冒。

　　一個包含PeerId的多地址例子：

　　/p2p/QmcEPrat8ShnCph8WjkREzt5CPXF2RwhYxYBALDcLC1iV6唯一的標識了一個遠端對等節點， 它是有該節點的公鑰雜湊得來的。想要了解更多，請看Peer Identity。

小貼士：

　　當節點路由可以使用時，你可以直接使用它們的PeerId進行撥號，而不需要提前知道它們的傳輸層地址。

支援多種傳輸協議

　　Libp2p應用程式通常需要同時支援多種傳輸協議。例如，你可能需要你的服務即對使用TCP協議的長期執行的應用可用，也可以接收來自執行在網路瀏覽器上的節點發送的連結。

　　Libp2p中用於管理傳輸協議的元件叫做switch，它也會與protocol negotiation,stream multiplexing,establishing secure communication等一些連結升級的其他形式的協議進行協作。

　　Switch為撥號和監聽提供單一實體點，並且使你的應用程式程式碼不用擔心特定的傳輸協議或者其他被底層使用到的連線技術棧。