第一個問題！你好！
在 Ubuntu 16.04 上運行。
硬體資訊：lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2) I219-V
Kernel driver in use: e1000e
Kernel modules: e1000e
02:00.0 Network controller: Intel Corporation Device 093c (rev 3a)
Subsystem: Intel Corporation Device 7001
在運行 P2P 應用程式時，我遇到一些奇怪的乙太網路停頓 -> 更準確地說：https://github.com/prysmaticlabs/prysm。根據相同的應用程式日誌，大約 30 個對等點連接到我的電腦。頻寬利用率很低（峰值為 6 Mbps），我在 Cat6 電纜上運行，並獲得大約 120 Mbps 的光纖上行鏈路，並且端口正確轉發，如你可以看到我嗎組織。其他 P2P 應用程式（例如 torrent）不會顯示任何衝突的行為。
如前所述，症狀很奇怪。當我運行該應用程式時，它似乎沒有失去連接。但當另一個應用程式需要在網路上運行時（例如，網頁瀏覽、聊天、文件傳輸），介面會停滯幾秒鐘，甚至幾分鐘。我注意到這一點是因為瀏覽經常超時。
當發生停頓時，應用程式保持正常運行，但所有其他應用程式都會失去網路連線。我監控 ICMP (ping) 流量：
- 從主機到路由器
- 從另一臺本機到停止運作的主機
在這兩種設備中，它停止返回任何類型的回應（終端停止輸出，沒有回饋，也沒有超時）。經過長時間的拖延後，突然間，所有包裹都被確認了。請參閱此範例：
64 bytes from 192.168.1.1: icmp_seq=1122 ttl=64 time=0.304 ms
64 bytes from 192.168.1.1: icmp_seq=1123 ttl=64 time=0.303 ms
64 bytes from 192.168.1.1: icmp_seq=1124 ttl=64 time=0.313 ms
64 bytes from 192.168.1.1: icmp_seq=1125 ttl=64 time=0.263 ms
64 bytes from 192.168.1.1: icmp_seq=1126 ttl=64 time=0.266 ms
64 bytes from 192.168.1.1: icmp_seq=1127 ttl=64 time=0.273 ms
64 bytes from 192.168.1.1: icmp_seq=1128 ttl=64 time=0.289 ms
64 bytes from 192.168.1.1: icmp_seq=1129 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=1130 ttl=64 time=0.280 ms
64 bytes from 192.168.1.1: icmp_seq=1131 ttl=64 time=0.635 ms
64 bytes from 192.168.1.1: icmp_seq=1132 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=1133 ttl=64 time=0.537 ms
64 bytes from 192.168.1.1: icmp_seq=1134 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=1135 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=1136 ttl=64 time=27625 ms
64 bytes from 192.168.1.1: icmp_seq=1137 ttl=64 time=26635 ms
64 bytes from 192.168.1.1: icmp_seq=1138 ttl=64 time=25631 ms
64 bytes from 192.168.1.1: icmp_seq=1139 ttl=64 time=24640 ms
64 bytes from 192.168.1.1: icmp_seq=1140 ttl=64 time=23641 ms
64 bytes from 192.168.1.1: icmp_seq=1141 ttl=64 time=22671 ms
64 bytes from 192.168.1.1: icmp_seq=1142 ttl=64 time=21648 ms
64 bytes from 192.168.1.1: icmp_seq=1143 ttl=64 time=20652 ms
64 bytes from 192.168.1.1: icmp_seq=1144 ttl=64 time=19658 ms
64 bytes from 192.168.1.1: icmp_seq=1145 ttl=64 time=18655 ms
64 bytes from 192.168.1.1: icmp_seq=1146 ttl=64 time=17658 ms
64 bytes from 192.168.1.1: icmp_seq=1147 ttl=64 time=16659 ms
64 bytes from 192.168.1.1: icmp_seq=1148 ttl=64 time=15655 ms
64 bytes from 192.168.1.1: icmp_seq=1149 ttl=64 time=14632 ms
64 bytes from 192.168.1.1: icmp_seq=1150 ttl=64 time=13611 ms
64 bytes from 192.168.1.1: icmp_seq=1151 ttl=64 time=12588 ms
64 bytes from 192.168.1.1: icmp_seq=1152 ttl=64 time=11565 ms
64 bytes from 192.168.1.1: icmp_seq=1153 ttl=64 time=10542 ms
64 bytes from 192.168.1.1: icmp_seq=1154 ttl=64 time=9522 ms
64 bytes from 192.168.1.1: icmp_seq=1155 ttl=64 time=8501 ms
64 bytes from 192.168.1.1: icmp_seq=1156 ttl=64 time=7478 ms
64 bytes from 192.168.1.1: icmp_seq=1157 ttl=64 time=6459 ms
64 bytes from 192.168.1.1: icmp_seq=1158 ttl=64 time=5436 ms
64 bytes from 192.168.1.1: icmp_seq=1159 ttl=64 time=4415 ms
64 bytes from 192.168.1.1: icmp_seq=1160 ttl=64 time=3391 ms
64 bytes from 192.168.1.1: icmp_seq=1161 ttl=64 time=2370 ms
64 bytes from 192.168.1.1: icmp_seq=1162 ttl=64 time=1350 ms
64 bytes from 192.168.1.1: icmp_seq=1163 ttl=64 time=320 ms
64 bytes from 192.168.1.1: icmp_seq=1164 ttl=64 time=2.73 ms
64 bytes from 192.168.1.1: icmp_seq=1165 ttl=64 time=0.258 ms
64 bytes from 192.168.1.1: icmp_seq=1166 ttl=64 time=0.303 ms
然後網路恢復正常一段時間。
我嘗試過的事情：
- 將 MTU 從 1500 增加到 9000（無效果）
- 將 txqueuelen 從 1000 增加到 11000（無效果）
- 限制可以連接的對等點數量（無效）
- 虛擬化（無效果）
- 刪除連接埠轉送。這似乎有效，儘管它違背了應用程式的目的並且使其速度相當慢。
此時我有兩個理論：
1) 要嘛網關表現得很搞笑（無法檢查）。我放棄了這個，因為網路中的其他設備在本地連接和外部連接中都運行正常2）或者某種內存緩衝區被阻塞，但不知道是哪一個。
我很感激靈感！
答案1
答案2
經過對網路中所有元素的更多調試後，我發現雖然其他設備的影響不太明顯，但它們確實受到了交通堵塞的影響，所以這讓我認為問題出在路由器/交換器上，這可能難以滿足P2P 應用程式的需求，可能是因為NAT 轉換。我將嘗試獲得更先進的硬體來解決這個問題。