容器中的網絡延遲相較於宿主機到底高多少？

今天一個歷來沒有用過docker容器的同事問了我一個網絡延遲的問題，很簡單，但我確沒有準確回答出來。通過簡單的驗證，如今我把過程及結果分享給各位粉絲。java

簡短對話

容器中的網絡延遲相較於宿主機有多高啊？web

我不假思索的回答能夠忽略不計吧docker

同事帶着疑惑的的說了句，那你說說docker網絡橋接的實現centos

在容器啓動時，Docker引擎將veth pair設備的一端放在新建立的容器中，並命名爲eth0，另外一端放在宿主機中；docker0子網中分配一個IP給容器使用，並設置docker0的IP地址爲容器的默認網關；這樣它們就組成了一個數據的通道，數據從一個設備進入，就會從另外一個設備出來。至關於多了一層網絡，就少不了網絡解封包開銷，看來是有影響的。bash

影響到底有多大呢？沒有作過這方面的測試......微信

驗證環境準備

本次驗證工具我使用了Netperf，Netperf是一種網絡性能的測量工具，能夠測試基於TCP或UDP吞吐、響應速率。Netperf包括Clien和Server端。Server端主要用來實現監聽工做，Client端進行測試。根據流量傳輸方式可分爲如下三種：網絡

單方向最大吞吐傳輸大量數據。app
雙方向交互傳輸數據，對於tcp爲單鏈接。tcp
針對tcp，每一個鏈接交互傳輸數據。編輯器

環境信息

總共兩臺機器，一臺機器啓動了NetPerf服務端；另一臺機器分別在容器內和宿主機上運行Netperf客戶端。

NetPerf服務端

1.下載wget http://repo.iotti.biz/CentOS/7/x86_64/netperf-2.7.0-1.el7.lux.x86_64.rpm

2.安裝 rpm -ivh netperf-2.7.0-1.el7.lux.x86_64.rpm

3.啓動 netserver

NetPerf客戶端

宿主機驗證

首先直接在宿主機上安裝Netperf，而後進行網絡性能測試，以下所示：

TCP_RR 是 netperf 裏專門用來測試網絡延時的，缺省每次運行10秒鐘。運行之後，咱們還要計算平均每秒鐘 TCP request/response 的次數，這個次數越高，就說明延時越小。如上所示，總共測試三輪，分別得出2014六、2024八、20221，平均是20221/s

容器中驗證

在同一臺客戶端機器上，啓動docker服務，並安裝Netperf進行驗證，命令以下所示[root@test ~]# docker run -d --name test -v /home/net/:/home/net/ docker.harbor.com/centos:7.8 sleep 36000

我這裏至關因而把Netperf掛載到容器內部，而後執行：docker exec -it test bash進入容器內部安裝Netperf。

一樣運行了三輪，分別得出的是1954六、1954一、19259，平均是19448/s。

從數據上看容器中比宿主機少了773次。773/20221= 4%也就是容器中網絡處理速度降低了4%，後來在網上找到了一些paper，有人得出結論是10%上下。

容器中共享宿主機網絡運行

[root@test ~]# docker run -d --name test --network host -v /home/net/:/home/net/ docker.harbor.com/centos:7.8 sleep 36000

能夠發現當使用共享宿主機網絡模式下，其網絡延遲跟宿主機基本沒有差別。

緣由分析

網絡延遲的緣由也不難想象，由於每次網絡數據傳輸都要通過veth接口，而後向外發送。這個虛擬的網絡設備除了沒有硬中斷，只有軟中斷處理過程，其它跟網卡發送數據邏輯基本類似，雖然發送速度很快。但即使如此也帶來了必定的網絡開銷，從而形成了網絡延遲。

總結

本文主要經過Netperf工具測試了宿主機和docker容器中的網絡延遲，總的來講，在可接受範圍以內，可是若是您的服務對延遲比較敏感，那麼就能夠考慮共享宿主機網絡，或者使用後來推出的macvlan/ipvlan（IPVlan 和 macvlan 相似，都是從一個主機接口虛擬出多個虛擬網絡接口，發送邏輯更簡單。）其性能基本上接近於宿主機。固然最近幾年Kubernetes定義了CNI標準，咱們能夠根據CNI實現本身的網絡轉發模式。好比Flannel、Calico、Weave和Canal都是基於該接口實現，讓Kubernetes生態系統中的網絡解決方案有更多樣的選擇，意味着大多數用戶將可以找到適合其當前需求和部署環境的CNI插件和解決方案。若有問題，請關注公衆號、加我微信，我拉你進羣討論！