Velocità di download di CloudFront in Europa: prevista vs. riferibile

Come utente in Europa, qual è la velocità di download che dovrei aspettarmi da un servizio offerto da AWS / CloudFront? A che punto devo segnalare una lentezza ea chi?

Per WeTransfer, da un link di esempio ottengo un URL di download di esempio (disponibile nella console di rete, F12). Quindi uso iftopper vedere quale host mi sta offrendo il file e mtrper vedere se si evidenzia qualche evidente problema (anche se il traceroute dal loro host alla mia macchina può essere diverso dall'altro modo).

Ieri, il file è stato pubblicato dal margine Madrid di CloudFront , qualcosa del genere server-54-192-61-242.mad50.r.cloudfront.net, e la mia velocità di download non è andata oltre i 300 KiB / s, rimanendo a 150-200 KiB / s per la maggior parte del tempo. È terribilmente lento. * Non ho salvato il traceroute ma non c'è stata alcuna ovvia perdita di pacchetti o latenza; I pacchetti IIRC sono passati attraverso Telia.

Oggi il file viene servito da server-54-240-166-250.lhr5.r.cloudfront.net(Londra) e ottengo 1,1 MiB / s a ​​casa, 13 MiB / s in media (e 25 MiB / s di picco) su un server del Nord Europa. Questo è quello che mi aspetto.

Dato che Amazon / AWS ha cambiato l'host da ieri e ora le cose funzionano, sembra ancora più probabile che il problema fosse con loro. Tuttavia, il client AWS su La velocità di download è lento dice che non farà nulla. I documenti di CloudFront e i forum AWS non hanno informazioni su come segnalare problemi di rete / routing / peering. Cosa fare in questi casi? Immagino che solo il client AWS sia in grado di fare qualcosa, ma solo se la persona che riceve il rapporto è in grado di comprendere la rete.

Il mio traceroute su CloudFront Madrid è qualcosa del genere:

10.|-- 62-101-124-129.fastres.net                   0.0%    50    4.6  13.8   3.5 101.1  20.3
11.|-- 89.96.200.21                                 0.0%    50   17.6  16.6   2.6  92.9  22.0
12.|-- mno-b2-link.telia.net                        4.0%    50   52.6  26.3  13.1  69.2  13.7
13.|-- mei-b1-link.telia.net                        0.0%    50   23.7  30.3  20.4  87.7  11.3
14.|-- bcn-b2-link.telia.net                        0.0%    50   47.5  53.7  30.2  92.9  16.4
15.|-- mad-b2-link.telia.net                        0.0%    50   62.7  57.7  36.1 102.2  14.4
16.|-- mad-b1-link.telia.net                        0.0%    50   37.7  42.1  34.3  59.8   5.6
17.|-- a100-ic-314004-mad-b1.c.telia.net            0.0%    50   70.2  58.5  39.7  87.2  12.5
18.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
19.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
20.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
21.|-- server-54-192-61-242.mad50.r.cloudfront.net  2.0%    50   71.1  83.5  56.4 156.2  19.5

Il traceroute è ora qualcosa del genere:

10.|-- 62-101-124-94.fastres.net                    0.0%    50   68.6  79.5  36.1 108.8  15.4
11.|-- 89.96.200.110                                0.0%    50   75.9  94.8  46.0 141.8  17.6
12.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
13.|-- 54.239.4.248                                 2.0%    50  107.2 112.9  71.6 146.7  18.2
14.|-- 54.239.41.135                                0.0%    50  112.8 108.7  72.8 147.6  15.0
15.|-- 178.236.3.22                                 0.0%    50  115.8 102.3  58.4 127.9  16.9
16.|-- 176.32.106.11                                4.0%    50   95.8 103.2  73.7 130.7  14.2
17.|-- 176.32.106.11                               40.0%    50  110.6 108.6  80.4 136.1  14.7
18.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
19.|-- ???                                         100.0    50    0.0   0.0   0.0   0.0   0.0
20.|-- server-54-240-166-250.lhr5.r.cloudfront.net 60.0%    50   88.7 100.0  57.6 131.9  18.0

Come osserva la prima risposta, è molto importante che il file sia già stato memorizzato nella cache sul bordo CloudFront o meno. Ecco un esempio di una cache mancata (che in questo momento riesce a saturare la mia larghezza di banda):

$ LANG='en' wget -S 'https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip'
--2016-02-27 21:34:39--  https://download.wetransfer.com/wetransfer-eu1/f7a2031249f56fdeeda9040adda5a26f20160224143804/wetransfer-f7a203.zip?expiration=1456605646&escaped=false&signature=3d916716d49e415f637b4f824c7709f7483b67a8f02588caece30d6c2a3ed0ea&filename=wetransfer-f7a203.zip
Resolving download.wetransfer.com (download.wetransfer.com)... 54.192.61.62, 54.192.61.196, 54.192.61.80, ...
Connecting to download.wetransfer.com (download.wetransfer.com)|54.192.61.62|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 1449534395
Connection: keep-alive
Server: nginx
Date: Sat, 27 Feb 2016 20:34:39 GMT
Content-Transfer-Encoding: binary
Content-Encoding: none
Cache-Control: private, no-transform, no-store
Allow: GET, HEAD
Accept-Ranges: bytes
Content-Disposition: attachment; filename="wetransfer-f7a203.zip"
X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804
X-Cache: Miss from cloudfront
Via: 1.1 943ab292a0096b706fe263560805857e.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 4hEZcZL56GWMBn8z1T2txF-O3TTdrAC6OxCtqVDZUoJREUd9_EBo6A==
Length: 1449534395 (1.3G) [application/octet-stream]

Su ulteriori test , ho sempre gewt X-Cache: Miss from cloudfront, anche alla sesta volta che richiedo la stessa risorsa, quindi sembra che WeTransfer non stia memorizzando nella cache nulla su CloudFront (o meno file di queste dimensioni). È interessante notare che l' X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804intestazione è sempre la stessa anche se l'URL di download effettivo che ottengo facendo clic sul pulsante di download varia; anche le intestazioni Viae X-Amz-Cf-Idvariano. A partire da questo aggiornamento, la prima volta che richiedo un determinato URL di download è molto veloce, la seconda molto lenta, la terza 404. Ho provato e posso avere due download simultanei, uno al secondo tentativo e uno al primo tentativo: il primo sarà molto lento e il secondo molto veloce, anche se le condizioni di rete sono chiaramente le stesse.

Vedi https://paste.debian.net/408552/ per un test dal mio server del Nord Europa: scarica A * sono un URL, B * un altro; A-2 è dopo A-1 e B-2 dopo B-1, ma B * è iniziato mentre A-2 era in esecuzione. Eppure A-1 e B-1 erano molto veloci, A-2 e B-2 molto lenti.

Questo sembra sempre più un problema con la qualità del servizio / QoS noto anche come limitazione. CloudFront può limitarmi a perdere cache o dovremmo solo incolpare il loro client?

(*) Nota: ho una connessione FTTH 10/10 Mb / s con Fastweb. La larghezza di banda disponibile non scende mai sotto questa velocità garantita. L'ISP non è noto per applicare la limitazione della QoS, ma a volte presenta alcuni problemi di routing al di fuori dell'Italia. Quando ho osservato il problema, non ho avuto alcun problema a saturare la mia larghezza di banda con altri servizi.

Se non sei un rappresentante dell'account AWS che possiede la distribuzione CloudFront - e il fraseggio usato nella domanda fa sembrare che non lo sia - il tuo punto di contatto appropriato è il sito web in cui stai riscontrando problemi prestazione.

Sarebbe quindi loro responsabilità aprire un incidente di supporto con il supporto AWS, se lo ritengono opportuno, poiché sono clienti di CloudFront.

CloudFront è progettato per indirizzare la tua richiesta alla posizione del bordo CloudFront più ottimale (dove "ottimale" spesso ma non sempre significa geograficamente vicino) all'interno della fascia di prezzo selezionata dal proprietario della distribuzione (i proprietari possono scegliere di non pagare per bordi più costosi, dove Amazon i costi sono più elevati, nel qual caso le richieste per quel sito eviteranno tali limiti, o almeno eviteranno i prezzi premium anche se CloudFront può, a loro discrezione, utilizzare una posizione di costo più elevata ma fatturare alla tariffa più bassa).

Il limite ottimale per la posizione di un determinato downloader si sposterà nel tempo, a causa di una moltitudine di fattori, tra cui latenza, congestione, luppolo e dimensioni del percorso AS, larghezza di banda del collegamento e qualsiasi numero di altri fattori ... che non sono informazioni pubbliche, ma vengono presi in considerazione dagli algoritmi di routing CloudFront che determinano quale risposta DNS si riceve quando ci si connette a un sito basato su CloudFront. La risposta DNS varia in base all'indirizzo IP del client richiedente.

Da un unico indirizzo IP nel sud dell'Ohio (USA) vedo il mio percorso del sito di test CloudFront attraverso una posizione periferica che cambia tra South Bend (IN, US), Chicago (IL, US) e Ashburn (VA, US) su un base abbastanza regolare - senza l'indirizzo IP effettivo sto richiedendo la modifica della pagina. Da una configurazione simile a meno di 5 miglia di distanza, ma con un diverso indirizzo IP di origine statica che utilizza un ISP diverso, ricevo risposte altrettanto diverse ma spesso diverse.

Ciò può essere facilmente spiegato dagli algoritmi di CloudFront che provano a selezionare il bordo più appropriato, in base a fattori che non sono evidenti dall'esterno.

Per quanto ne sai, il tuo comportamento lento sulle connessioni a CloudFront di ieri potrebbe essere stato rilevato e ha innescato l'algoritmo di selezione per scegliere una strategia diversa, causando così il "problema" delle prestazioni. È anche possibile che il bordo di Madrid sia stato utilizzato come scelta non ottimale a causa di problemi di disponibilità in una migliore posizione.

Potrebbe essersi verificato anche un problema tra CloudFront e il server di origine. Le intestazioni di risposta di CloudFront ti avrebbero dato un po 'più di informazioni ... Se X-Cache: Hit from Cloudfrontè presente, ti viene servito dalla cache del bordo e l' Age:intestazione ti dirà da quanto tempo è stato memorizzato nella cache del bordo. SeX-Cache: Miss from Cloudfront, quindi il download non è stato memorizzato nella cache al limite e il file attualmente in fase di ricezione viene recuperato dal server di origine e contemporaneamente messo in scena per la cache e trasmesso in streaming a te. Consentire il completamento completo del download, quindi eseguire nuovamente il download con una richiesta identica dovrebbe ottenere la copia memorizzata nella cache, presupponendo che la richiesta successiva raggiunga lo stesso limite e la differenza di velocità, se presente, è approssimativamente indicativa della velocità di connessione al server di origine . CloudFront è un CDN pull-through; gli oggetti non vengono replicati ai bordi, vengono memorizzati solo nei punti in cui sono stati richiesti, dopo la richiesta iniziale.

Come client CloudFront, non ho mai avuto la necessità di segnalare download lenti. Ciò non significa che sia perfetto, ma il servizio sembra essere progettato in modo molto solido per prestazioni e resilienza.