Al momento stiamo cercando di decidere se spostare il nostro datacenter dalla costa occidentale alla costa orientale.

Tuttavia, vedo alcuni inquietanti numeri di latenza dalla mia posizione sulla costa occidentale alla costa orientale. Ecco un risultato di esempio, recuperando un piccolo file logo .png in Google Chrome e usando gli strumenti dev per vedere quanto tempo impiega la richiesta:

• Costa occidentale e costa orientale:
  latenza 215 ms, tempo di trasferimento 46 ms, 261 ms totali
• Costa occidentale e costa occidentale:
  latenza 114 ms, tempo di trasferimento 41 ms, 155 ms totali

È logico che Corvallis, OR sia geograficamente più vicino alla mia posizione a Berkeley, in California, quindi mi aspetto che la connessione sia un po 'più veloce .. ma vedo un aumento della latenza di + 100 ms quando eseguo lo stesso test a New York server. Sembra .. eccessivo per me. Soprattutto dal momento che il tempo impiegato per il trasferimento dei dati effettivi è aumentato solo del 10%, ma la latenza è aumentata del 100%!

Mi sembra ... sbagliato ... per me.

Ho trovato alcuni link utili (tramite Google non meno!) ...

• La distanza di routing influisce in modo significativo sulle prestazioni?
• In che modo la geografia influisce sulla latenza della rete?
• Latenza nelle connessioni Internet dall'Europa agli Stati Uniti

... ma niente di autorevole.

Quindi, è normale? Non sembra normale. Qual è la latenza "tipica" che dovrei aspettarmi quando si spostano i pacchetti di rete dalla costa orientale <--> costa occidentale degli Stati Uniti?

Velocità della luce:
non batterai la velocità della luce come un interessante punto accademico. Questo collegamento funziona da Stanford a Boston al miglior tempo possibile di circa 40 ms. Quando questa persona ha fatto il calcolo, ha deciso che Internet funziona a circa "entro un fattore pari a due della velocità della luce", quindi il tempo di trasferimento è di circa 85 ms.

Dimensione finestra TCP:
se si verificano problemi di velocità di trasferimento, potrebbe essere necessario aumentare la dimensione tcp della finestra di ricezione. Potrebbe anche essere necessario abilitare il ridimensionamento della finestra se si tratta di una connessione ad alta larghezza di banda con latenza elevata (chiamata "pipa lunga e grassa"). Quindi, se si sta trasferendo un file di grandi dimensioni, è necessario disporre di una finestra di ricezione abbastanza grande da riempire la pipe senza dover attendere gli aggiornamenti della finestra. Sono entrato in alcuni dettagli su come calcolarlo nella mia risposta Tuning an Elephant .

Geografia e latenza:
un punto debole di alcune reti CDN (Content Distribtuion Networks) è che identificano latenza e geografia. Google ha fatto molte ricerche con la propria rete e trovato difetti in questo, ha pubblicato i risultati nel white paper Andando oltre le informazioni sul percorso end-to-end per ottimizzare le prestazioni della CDN :

In primo luogo, anche se la maggior parte dei client è servita da un nodo CDN geograficamente vicino, una considerevole frazione di client ha una latenza superiore di altre decine di millisecondi rispetto ad altri client nella stessa regione. In secondo luogo, scopriamo che i ritardi di accodamento spesso prevalgono sui vantaggi di un client che interagisce con un server vicino.

Peerings BGP:
anche se inizi a studiare BGP (core internet routing protocol) e il modo in cui gli ISP scelgono i peerings, scoprirai che spesso si tratta più di finanze e politica, quindi potresti non ottenere sempre il percorso "migliore" verso determinate località geografiche a seconda sul tuo ISP. Puoi vedere come il tuo IP è collegato ad altri ISP (sistemi autonomi) usando un router di vetro . Puoi anche utilizzare un servizio whois speciale :

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

È anche divertente esplorarli come peerings con uno strumento gui come linkrank , ti dà una foto di Internet intorno a te.

Questo sito suggerisce una latenza di circa 70-80 ms tra la costa est / ovest degli Stati Uniti (ad esempio da San Francisco a New York).

Sentiero transatlantico
NY 78 Londra
Lavare 87 Francoforte

Percorso Trans-Pacifico
SF 147 Hong Kong

Percorso Trans-USA
SF 72 NY

Ecco i miei tempi (sono a Londra, in Inghilterra, quindi i miei tempi sulla costa occidentale sono più alti di quelli orientali). Ottengo una differenza di latenza di 74 ms, che sembra supportare il valore di quel sito.

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

Questi sono stati misurati utilizzando gli strumenti di sviluppo di Google Chrome.

Misurare prima con ICMP se possibile. I test ICMP utilizzano in genere un payload molto piccolo per impostazione predefinita, non utilizzano una stretta di mano a tre vie e non devono interagire con un'altra applicazione nello stack come HTTP. In ogni caso, è della massima importanza che i risultati HTTP non vengano confusi con i risultati ICMP. Sono mele e arance.

Passando dalla risposta di Rich Adams e utilizzando il sito che ha raccomandato, puoi vedere che sulla spina dorsale di AT&T, ci vogliono 72 ms per il traffico ICMP per spostarsi tra i loro endpoint SF e NY. È un numero equo da seguire, ma è necessario tenere presente che si trova su una rete completamente controllata da AT&T. Non tiene conto del passaggio alla rete domestica o dell'ufficio.

Se esegui un ping contro careers.stackoverflow.com dalla tua rete di origine, dovresti vedere qualcosa di non troppo lontano di 72 ms (forse +/- 20 ms). In tal caso, probabilmente puoi presumere che il percorso di rete tra voi due sia corretto e che funzioni entro intervalli normali. Altrimenti, non farti prendere dal panico e misura da pochi altri posti. Potrebbe essere il tuo ISP.

Supponendo che ciò sia stato superato, il passaggio successivo consiste nell'affrontare il livello dell'applicazione e determinare se c'è qualcosa di sbagliato nell'overhead aggiuntivo che si riscontra nelle richieste HTTP. Questo può variare da un'app all'altra a causa dell'hardware, del sistema operativo e dello stack di applicazioni, ma poiché disponi di apparecchiature approssimativamente identiche su entrambe le coste est e ovest, potresti avere utenti della costa orientale che colpiscono i server della costa occidentale e gli utenti della costa occidentale che colpiscono l'est costa. Se entrambi i siti sono configurati correttamente, mi aspetterei di vedere tutti i numeri come meno uguali e quindi di dimostrare che ciò che stai vedendo è praticamente alla pari dei grossolani.

Se quei tempi HTTP hanno una varianza ampia, non sarei sorpreso se ci fosse un problema di configurazione sul sito con prestazioni più lente.

Ora, una volta arrivato a questo punto, puoi provare a fare qualche ottimizzazione più aggressiva sul lato app per vedere se quei numeri possono essere ridotti del tutto. Ad esempio, se usi IIS 7, stai sfruttando le sue capacità di memorizzazione nella cache, ecc.? Forse potresti vincere qualcosa lì, forse no. Quando si tratta di modificare elementi di basso livello come le finestre TCP, sono molto scettico sul fatto che avrebbe un grande impatto per qualcosa come Stack Overflow. Ma hey - non lo saprai fino a quando non lo proverai e misurerai.

Molte delle risposte qui stanno usando ping e traceroute per le loro spiegazioni. Questi strumenti hanno il loro posto, ma non sono affidabili per la misurazione delle prestazioni della rete.

In particolare, (almeno alcuni) i router Juniper inviano l'elaborazione degli eventi ICMP al piano di controllo del router. Questo è MOLTO più lento del piano di inoltro, specialmente in un router backbone.

Vi sono altre circostanze in cui la risposta ICMP può essere molto più lenta delle prestazioni di inoltro effettive di un router. Ad esempio, immagina un router interamente software (nessun hardware di inoltro specializzato) con una capacità della CPU pari al 99%, ma che sta ancora spostando bene il traffico. Vuoi che impieghi molti cicli a elaborare le risposte traceroute o a inoltrare il traffico? Quindi l'elaborazione della risposta è una priorità estremamente bassa.

Di conseguenza, ping / traceroute ti danno limiti superiori ragionevoli - le cose stanno andando almeno così velocemente - ma non ti dicono davvero quanto velocemente sta andando il traffico reale.

In ogni caso -

Ecco un esempio di traceroute dall'Università del Michigan (Stati Uniti centrali) a Stanford (costa occidentale degli Stati Uniti). (Succede a Washington, DC (costa orientale degli Stati Uniti), che si trova a 500 miglia nella direzione "sbagliata".

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

In particolare, notare la differenza di tempo tra i risultati del traceroute dal router di lavaggio e dal router di atla (hop 7 e 8). il percorso di rete va prima a lavare e poi ad atla. il lavaggio richiede 50-100 ms per rispondere, atla dura circa 28ms. Chiaramente atla è più lontano, ma i suoi risultati traceroute suggeriscono che è più vicino.

Vedi http://www.internet2.edu/performance/ per molte informazioni sulla misurazione della rete. (disclaimer, un tempo lavoravo per internet2). Vedi anche: https://fasterdata.es.net/

Per aggiungere una rilevanza specifica alla domanda originale ... Come puoi vedere, ho avuto un tempo di ping di andata e ritorno di 83 ms a Stanford, quindi sappiamo che la rete può andare almeno così velocemente.

Si noti che il percorso della rete di ricerca e istruzione che ho intrapreso su questo traceroute è probabilmente più veloce di un percorso Internet delle materie prime. Le reti di ricerca e sviluppo generalmente eseguono il provisioning eccessivo delle connessioni, il che rende improbabile il buffering in ciascun router. Inoltre, nota il lungo percorso fisico, più lungo della costa da costa a costa, sebbene chiaramente rappresentativo del traffico reale.

Michigan-> washington, dc-> atlanta-> houston-> los angeles-> stanford

Vedo differenze consistenti e sono seduto in Norvegia:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

Ciò è stato misurato con il metodo scientifico accurato e comprovato di utilizzare la visualizzazione delle risorse di Google Chrome e di aggiornare ripetutamente ogni collegamento.

Traceroute a serverfault

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

Traceroute alle carriere

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

Sfortunatamente, ora inizia ad andare in un ciclo o quant'altro e continua a dare stelle e timeout fino a 30 salti e poi finisce.

Nota, i traceroute provengono da un host diverso rispetto ai tempi all'inizio, ho dovuto eseguire il RDP sul mio server ospitato per eseguirli

Vedo una latenza di circa 80-90 ms su collegamenti ben gestiti e ben misurati tra le coste est e ovest.

Sarebbe interessante vedere dove stai guadagnando latenza: prova uno strumento come traceroute di livello quattro (lft). È molto probabile che si guadagni durante l '"ultimo miglio" (vale a dire nel provider di banda larga locale).

È prevedibile che il tempo di trasferimento sia stato leggermente influenzato: la perdita di pacchetti e il jitter sono misurazioni più utili da esaminare quando si studiano le differenze di tempo di trasferimento tra due posizioni.

Solo per divertimento, quando ho giocato al gioco online Lineage 2 NA dall'interno dell'Europa:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

La differenza sembra sostenere che fino a 100 ms è ragionevole, considerata la natura imprevedibile di Internet.

Utilizzando l'acclamato test di aggiornamento di Chrome, ottengo un tempo di caricamento del documento che si differenzia per circa 130 ms.

tutti qui hanno un punto davvero buono. e sono corretti nel loro POV.

E tutto si riduce a non c'è una vera risposta esatta qui, perché ci sono così tante variabili che ogni risposta data può sempre essere smentita solo cambiando una delle cento variabili.

Come la latenza da 72 ms NY a SF è la latenza da PoP a PoP di un corriere di un pacchetto. Questo non tiene conto di nessuno degli altri grandi punti che alcuni hanno sottolineato qui sulla congestione, la perdita di pacchetti, la qualità del servizio, i pacchetti fuori ordine o le dimensioni dei pacchetti o il reindirizzamento della rete proprio tra il mondo perfetto del PoP e PoP .

E poi quando aggiungi l'ultimo miglio (generalmente molte miglia) dal PoP alla tua posizione effettiva all'interno delle due città in cui tutte queste variabili diventano molto più fluide, la cosa inizia a crescere esponenzialmente da ragionevole capacità di indovinare!

Ad esempio, ho eseguito un test tra New York City e San Francisco durante una giornata lavorativa. L'ho fatto un giorno se non ci fossero stati "incidenti" importanti in tutto il mondo che avrebbero causato un picco nel traffico. Quindi forse questo non era nella media nel mondo di oggi! Tuttavia, è stato il mio test. In realtà ho misurato da una sede aziendale all'altra in questo periodo e durante il normale orario lavorativo di ciascuna costa.

Allo stesso tempo, ho monitorato i numeri dei fornitori di circuiti sul web.

I risultati sono stati numeri di latenza tra 88 e 100 ms da porta a porta delle sedi aziendali. Ciò non includeva alcun numero di latenza della rete tra uffici.

La latenza delle reti dei fornitori di servizi variava tra 70 e 80 ms. Ciò significa che la latenza dell'ultimo miglio avrebbe potuto variare tra 18 e 30 ms. Non ho correlato i picchi e i minimi esatti tra i due ambienti.

Orari di New York:

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

Utilizzando Chrome, su una connessione residenziale.

Utilizzo di lft da un VPS in un datacenter a Newark, New Jersey:

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms