Web 2.0服務越來越依賴大型計算基礎架構來支持快速迭代和部署周期。為了更快地構建，測試和發布軟體，這些服務通常在尋找方法來升級其系統，以利用分布式點對點網絡中的新知識和新工具。
在IPFS Camp 2019之後，Netflix和IPFS開始合作尋找將對等服務整合到Netflix開發人員工具中的方法。在一起，我們找到了一種利用IPFS加速雲構建，設計以及測試解決方案的方法，以通過高效的p2p容器鏡像分發提供支持更快的持續集成（CI）通道。
作為此次合作的一部分，我們在過去兩個季度中對Bitswap進行了重大改進，Bitswap是IPFS在兩個或更多對等端之間傳輸文件片段的機制。進行此項改進的一個關鍵因素是p2plab（一種由Netflix創建的性能基準測試工具，用於運行可重複的測試），使我們能夠確定和衡量改進。
我們特別關注的是Netflix想要解決的容器分發挑戰：如何在大規模，多區域環境中有效地提取容器圖像。圖像層通常位於不同的區域。
利用IPFS作為點對點CDN，可以使Netflix基礎架構內的節點進行協作並將共同的種子播種到相鄰節點，從而有助於更快地分發容器。
為了進一步加快速度，我們在Bitswap協議中添加了一些有用的新功能，該功能將圍繞容器分發基準用例的傳輸速度降低了一半。
在以前版本的Bitswap中，平均需要花費9.08秒將300 MiB圖像下載到32個下載節點上。經過優化的分支將這一時間縮短至3.16秒！比DockerHub（3.93秒）快20％！
當下載節點的數量超過種子節點時，我們觀察到下載的片段會被重新播種，從而減少了種子節點的紛爭。
獲取容器鏡像的總時效對比：
IPFS將文件分成稱為塊的碎片，由內容標識符（CID）進行識別。當運行Bitswap協議的節點要獲取文件時，它們會向其他對等方發送「請求列表」。
為了找出哪些對等點具有構成文件的塊，Bitswap節點首先向其連接的所有對等點發送對根塊CID的需求。如果對等方沒有該塊，則該節點查詢分布式哈希表（DHT）來詢問誰擁有根塊。
任何使用根塊響應的對等方都將添加到會話中。從現在開始，Bitswap只向會話中的對等方發送請求，以免向網絡發送請求。
節點將每個CID的需求並行發送給會話中的多個對等方，因為並非所有對等方都會擁有所有塊。如果節點開始接收大量重複塊，則它將每個CID的需求發送給較少的對等方。
如果該節點等待塊超時，它將向每個對等方發送每個CID的請求。這樣，節點嘗試在沒有太多重複塊的情況下保持較高的下載速度。
為了提高Bitswap的性能和效率，IPFS團隊對Bitswap提取塊的方式進行了一些更改。
最初，一個節點想知道其哪個對等方具有根塊，但實際上並不想接收該塊本身（因為它向許多對等方發送了這個「發現」需求）。
因此，一個新的變化是，當Bitswap發送請求時，它可以請求HAVE消息作為響應（而不是取回整個塊）。
一旦節點將對等體添加到會話中，它也可以使用這些HAVE消息來找出哪個會話對等體具有相對便宜的其餘塊需求，因為它不必擔心重複的塊。
在此階段，節點還希望對等方說出它是否沒有該塊。因此，我們添加了一個DONT_HAVE響應。
通過這些更改，節點可以廉價地算出如何在其對等節點之間分配塊，並且可以更精確地定向對塊的請求，從而提高總體下載速度並減少重複塊的數量。該節點還可以快速識別會話中的所有沒包含它所需塊的節點，同時通過DHT找出誰擁有塊。
Netflix開發人員會定期在Netflix容器管理平臺 Titus上部署數百萬個容器。由於這些容器中有許多可以處理為Netflix提供支持的關鍵工作負載，因此通常需要將它們部署在世界各地的許多地區，以適應該地理位置的流量。
當開發人員將發布鏡像推送到生產環境時，該鏡像需要複製到其他區域的Docker註冊表中，否則部署將遭受跨區域數據成本和緩慢的傳輸速度的困擾。
Docker註冊表旨在將「alpine」之類的圖像引用以及通過內容尋址能力包含在圖像內部的數據分離開來。這與IPFS的數據模型並行，後者的數據始終由其CID表示。
p2plab
Netflix基礎架構部署在全球多個可用性區域和地區的Amazon Web Services（AWS）上。為了模擬這種環境，創建了p2plab來測量多區域集群中IPFS網絡上數據傳輸的吞吐量。
使用p2plab，我們可以可靠地確定IPFS的更改是否會提高性能。操作員能夠使用群集定義來配置活動群集，並使用方案定義對數據傳輸方案進行基準測試。
p2plab群集中的節點還可以熱交換被測IPFS二進位文件，從而使Protocol Labs和Netflix工程師能夠快速測試IPFS組件（如bitwap）的分支。
支持p2plab的內存驅動程序已經存在。可以嘗試拉取至自己的倉庫，並立即在本地系統上試用！