Performance

對於公司網路來說,什麼樣的延遲數字是合理的?

  • October 25, 2014

我是一名軟體開發人員,有時我想在家工作,但在 VPN 上編寫程式碼實在是太慢了。我嘗試了幾種不同的方法來嘗試使其更合理。在 VNC 上,我嘗試對其進行調整,使其盡可能輕。我嘗試過 X11 轉發,我嘗試過只使用純終端。這些都不是我能忍受超過幾分鐘的事情。

與其只是一個抱怨者,我想我會在兩個方向上用 traceroute 進行一些測量,看看它到底有多糟糕。現在我有了這些數字,但我不確定它們是否足以讓我們公司的 IT 專業人員採取一些行動,或者他們是否只會將我視為抱怨者(即沒有其他人對此抱怨)。所以這裡是數字。

從我的客戶端機器跟踪回我的伺服器:

$ tracert myserver

Tracing route to myserver.myco.com [169.129.70.27]
over a maximum of 30 hops:

 1   663 ms   685 ms   404 ms  169.129.85.51
 2   456 ms   295 ms   265 ms  169.129.85.40
 3   421 ms   409 ms   423 ms  41.41.125.109
 4   395 ms   411 ms   412 ms  41.41.125.122
 5   433 ms   409 ms   438 ms  169.129.74.51
 6   652 ms   404 ms   354 ms  myserver.myco.com [169.129.70.27]

Trace complete.

所以中位數是 404 毫秒,沒有丟包,但似乎所有延遲都立即發生,第一跳中位數為 663 毫秒……嗯……

從我的伺服器機器跟踪到我的客戶端:

> traceroute 169.129.85.51
traceroute to 169.129.85.51 (169.129.85.51), 30 hops max, 46 byte packets
1  169.129.169.51 (169.129.169.51)  0.274 ms  0.185 ms  0.185 ms
2  169.129.174.11 (169.129.174.11)  14.497 ms  14.437 ms  15.937 ms
3  41.3.125.121 (41.3.125.121)  24.215 ms  24.863 ms  24.213 ms
4  41.3.125.110 (41.3.125.110)  85.694 ms  87.208 ms  83.187 ms
5  169.129.85.51 (169.129.85.51)  85.937 ms *  89.498 ms

因此,這個方向的最大延遲為 89.5 毫秒,一個數據包被丟棄,但從每個停止點開始的進展似乎更合理,因為它在第一跳開始時很小,並隨著每一跳而增加。

那麼這是我應該要求修復的問題,還是 VPN 進入公司網路的典型行為?

更新

所以我能夠(大約)減少一半的時間。我注意到,當我四處尋找時,他們似乎將所有流量路由通過紐約,然後將其發送回這裡,這似乎每條腿大約需要 200 毫秒。所以我決定在那裡玩他們自己的遊戲,我在紐約的伺服器上開始了一個 VNC 會話,從而消除了旅途的一個環節。它仍然不完美,但可以忍受。如果他們讓我們直接在這裡訪問我們的伺服器,那將是非常好的,然後延遲將再次減少一半,並且真的很活潑……無論如何,今晚學習了一些網路知識!

作為比較,當我線上玩第一人稱射擊遊戲時,典型的延遲(ping 時間)介於 20 毫秒到 150 毫秒之間。甚至更低的數字也是可能的(儘管很少見)。除此之外,玩家會因為您導致延遲/取消註冊而開始對您生氣。遊戲中的玩家可能遍布全國,而這些數字往往適用於大多數人。任何超過 150 毫秒的東西都不太對勁。

對於與您的工作地點的 VPN 連接,您應該在物理上足夠接近以親自訪問辦公室,您應該能夠保持在該範圍的低端附近。也就是說,請仔細閱讀跟踪器。我在一所大學工作,最近我從家裡(當時在校園裡!)追踪到不到一個街區之外的校園伺服器。我使用的是 DSL 線路,而學院的供應商是時代華納的光纖線路。我們在內布拉斯加州農村,數據包在兩個提供商的網路最終對等之前通過丹佛跳到德克薩斯州,然後在返回城鎮的路上通過芝加哥。僅僅從不到 1/4 英里的地方拉出數據包就已經是一次相當大的旅行了。我切換到時代華納電纜線路以匹配大學的 ISP,我的跟踪器變得更加合理 - 它仍然跳到林肯,但它平均下降到 10 毫秒,其中大部分只是通過我使用了 6 年的舊無線路由器。因此,您可能會看到使用不同 ISP 的朋友是否可以獲得更好的結果。

一個方向的緩慢但另一個方向的緩慢也向我表明它可能與您公司的網關有關,特別是內容過濾器(如果有的話)。這些可能會增加處理數據包的大量成本(讀取:延遲)。您的 IT 人員可能專門繞過了一個方向的 VPN 流量的內容過濾器,但沒有(或者可能無法在沒有使過濾器沒有實際意義的情況下)繞過另一個方向的流量。

引用自:https://serverfault.com/questions/275842