很長一段時間以來，我的網路都遇到了難以捉摸的問題。
我更換了路由器、接入點並建立了有線無線連接，以尋找效能竊賊，但沒有進一步了解我的設定出了什麼問題。
這個問題就像「網路感覺很慢」一樣模糊，而且該問題的任何特定症狀都沒有持續足夠的時間讓我找到其根本原因。
我目前的基礎設施由以下部分組成：
在 esxi 上運作的 pfsense 虛擬機器。目前唯一運行在主機（Proliant ML110、Core 2 Duo）上的虛擬機器可以消除其他虛擬機器的效能竊賊。伺服器有兩張網路卡，一個用於 WAN，一個用於 LAN。
三個 Procurve 1800/1810 8 和 24 連接埠交換器。兩個 VLAN，一個用於 LAN，一個用於 WAN。
一台 Ubiquiti Unifi UAP-AC。
此網路為 20 多個具有連接性的單位提供服務。
昨天有一個更持久的問題，我無法在 Netflix 上觀看電影，谷歌搜尋給我帶來了這裡Netflix 支援人員告訴我問題不在於他們，而是我的 ISP。
那裡的描述與我遇到的問題很好地匹配，啟動應用程式非常慢，播放並不總是有效。
我嘗試拔掉 Apple-TV 的插頭並使用同一條電纜連接我的 Macbook。在電腦上，Netflix 運作順利。在該電纜上運行速度測試，我驗證了我的頻寬為 100 雙向兆位元。重新連接 Apple-TV Netflix 無法正常運作。
將 Apple-TV 連接的連接埠上的 VLAN 從 LAN 變更為 WAN，使其可以透過公共 IP 直接連接到互聯網，從而可以毫無問題地傳輸電影。
放回區域網路播放又失敗了。我斷開了除 Apple-TV 和交換器上行鏈路之外的所有設備。進入有網路存取的交換機，斷開所有連接，除了兩個 pfsense 連接埠、光纖轉換器的連接以及與 Apple-TV 的交換器的上行鏈路。之後就可以開始播放了。
因此，我認為我應該能夠透過重新連接所有設備並查看哪條電纜終止播放來找出麻煩製造者。沒有人這樣做。當一切再次連接時，一切都繼續工作。
這是我每次嘗試找出連接性能不佳的原因時的經歷。在 100 雙向兆比特上，它應該相當快，但我已經好幾次關閉手機上的 WiFi，因為 4G 更快。速度測試始終顯示 100 兆位元。
串流媒體似乎特別難以處理，使用 Airplay 鏡像我的螢幕實際上毫無用處。使用相同的技術播放音樂是可行的，但播放中斷很常見。
雖然昨天繞過防火牆似乎表明它是這一切的騙子，但今天的結果卻相反：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
另外，為了嘗試驗證網路的 MTU（根據蘋果論壇理論），我嘗試從 WAN 上 ping 不同大小的包，我的測試顯示大包無法很好地穿越網路：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
有些實驗似乎驗證了 WAN 上的 MTU 確實是 1500：
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
在 LAN 上，斷點位於相同的資料包大小上，但我必須手動指定不允許資料包分段：
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
我不明白我的網路出了什麼問題，也不知道如何進一步排除故障。請幫我重新調整我的故障排除，以便我可以一勞永逸地消除網路中的幽靈。
編輯，關於我的 DNS 設定：
如果我理解正確的話，這意味著 google 解析器僅在 ISP 分配的 DHCP 名稱伺服器不可用時用作後備。那是對的嗎？或者我是否隨機向遙遠的名稱伺服器詢問地址？
正如您在下面看到的，pfsense 首先嘗試自行處理名稱解析，然後詢問 ISP，然後再詢問 ISP，然後僅求助於 google 作為第四和第五個選項，這對我來說似乎很合理？
Apple TV 具有 DHCP 分配的網路設置，並使用網關作為名稱伺服器。 DHCP 伺服器沒有專用的 dns 設置，但繼承了上面的名稱伺服器列表：
編輯，關於 for 迴圈：
使用 100 個資料包運行 ping 100 次而不是一次的原因是每次都執行名稱解析，因為當我手動運行它時，似乎需要相當長的時間才能“啟動”ping，我想也許我通過將動作乘以100 可以讓這種感覺更加明顯。
鑑於 Ubuntu 有以下配置：
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
這個想法可能有點傻強…
編輯，關於Apple TV：
我已將 Apple TV 重設為出廠預設值。我曾多次拔掉該設備的插頭（有時血液中充滿了憤怒）。
編輯，pfSense：
前幾天我在工廠預設了 pfSense，只重新啟用了其中更重要的部分（dns、dhcp、nat、靜態 dhcp 租用、一些連接埠轉送），但昨天 Netflix 仍然停止播放中流。不過問題又消失了，所以重新開始電影就成功了。
我想知道 Netflix 中流是否需要 DNS，感覺那時應該已經解決了。
由於伺服器正在運行最新的 pfsense 版本 (2.2.2)，因此它使用不受約束的預設情況下。
可以透過使用診斷工具進行兩次連續查找來驗證解析器是否成功快取了解析：
但不同的答案讓我感到困惑。
編輯，MTU：
MTU 設定為自動。
編輯，ATV速度測試：
在 Apple TV 上進行速度測試會在 pfsense 上產生以下圖表：
之後，Apple TV 會顯示“測試成功完成”，但只持續了一秒鐘，然後又變成：
儘管出現錯誤，我仍然可以使用 Netflix。
答案1
確保使用本機 ISP 的 DNS 伺服器，而不是遠端 DNS 服務。
您可以下載或串流到 Apple TV 的大部分內容都透過 Akamai CDN 提供（Apple 多年來一直是 Akamai 最大的客戶之一）。 Akamai 根據您的 DNS 查找來源尋找距離您最近的 CDN 邊緣節點（伺服器），而您的 DNS 查找通常來自您已設定用戶端裝置使用的本機遞歸/解析 DNS 伺服器。
確保您的Apple TV 設定為使用本地ISP 的DNS 伺服器，而不是某些潛在的遠端伺服器，例如Google DNS（8.8.8.8 和8.8.4.4）或Level 3 (4.2.2.x) 或OpenDNS 或類似伺服器。請注意，您的 Apple TV 可能會透過 DHCP 取得其 DNS 設置，而您的 DHCP 伺服器可能是路由器/網關上的一個進程。如果 DHCP 伺服器告訴您的 Apple TV 使用 NAT 閘道（或其他本機防火牆或路由器）的私人 IP 位址作為其 DNS 位址，則表示您的 NAT 閘道正在充當 DNS 代理程式。如果您想繼續這樣做，請確保 NAT 網關使用您本地 ISP 的 DNS 伺服器作為它是DNS 伺服器。
透過使用本機DNS 伺服器，Akamai 將引導您的用戶端從離您最近的瑞典Akamai 伺服器發出下載/串流請求，而不是例如美國Google 資料中心附近的某個伺服器，其中Google 的8.8.8.8 DNS 伺服器位於位於。
[即使這對你來說不是正確的答案，但對於其他發現這個問題的人來說可能是正確的答案，所以無論如何我都會把它留在這裡。