Скорость загрузки CloudFront в Европе: ожидаемая и отчетная

Question

Как пользователь в Европе, какую скорость загрузки мне следует ожидать от сервиса на платформе AWS/CloudFront? В какой момент я должен сообщить о медлительности и кому?

Для WeTransfer из примерной ссылки я получаю примерный URL-адрес для загрузки (находится в сетевой консоли, F12). Затем я использую iftop чтобы посмотреть, какой хост передает мне файл, и mtr чтобы определить, не выявлена ли какая-либо очевидная проблема (хотя трассировка маршрута от их хоста до моей машины может отличаться от другой).

Вчера файл был доставлен из мадридского края CloudFront, что-то вроде server-54-192-61-242.mad50.r.cloudfront.net , и моя скорость загрузки не превышала 300 КиБ / с, оставаясь на уровне 150-200 КиБ / с большую часть времени. Это ужасно медленно.* Я не сохранил traceroute, но не было очевидной потери пакетов или задержки; Пакеты IIRC прошли через Telia.

Сегодня файл подается с server-54-240-166-250.lhr5.r.cloudfront.net (Лондон), и я получаю 1,1 МБ / с дома, в среднем 13 МБ / с (и пик 25 МБ / с) на сервере Северной Европы. Это то, что я ожидаю.

Учитывая, что Amazon/AWS изменил хост со вчерашнего дня, и теперь все работает, кажется, еще более вероятно, что проблема была с ними. Тем не менее, клиент AWS на скорости загрузки медленно говорит, что они ничего не будут делать. Документация CloudFront и форумы AWS не содержат информации о том, как сообщать о проблемах с сетью / маршрутизацией / пирингом. Что делать в таких случаях тогда? Я полагаю, что только клиент AWS может что-то сделать, но только в том случае, если человек, который получает отчет, способен понять работу сети.

Мой маршрут к CloudFront Madrid выглядит примерно так:

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

Трассировка маршрута теперь выглядит примерно так:

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

Как отмечается в первом ответе, очень важно, был ли файл уже кэширован на границе CloudFront или нет. Вот пример пропадания кеша (которому сейчас удается насытить мою пропускную способность):

$ 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]

При дальнейшем тестировании я всегда получаю X-Cache: Miss from cloudfront , даже в 6-й раз я запрашиваю тот же ресурс, поэтому кажется, что WeTransfer ничего не кэширует в CloudFront (или нет файлов такого размера). Интересно, что заголовок X-Transfer-Id: f7a2031249f56fdeeda9040adda5a26f20160224143804 всегда один и тот же, хотя фактический URL-адрес загрузки, который я получаю, нажимая кнопку загрузки, меняется; заголовки Via и X-Amz-Cf-Id также различаются. Начиная с этого обновления, первый раз, когда я запрашиваю заданный URL-адрес для загрузки, очень быстро, второй - очень медленно, третий - 404. Я попытался, и у меня может быть две одновременные загрузки, одна со второй попытки и одна с первой попытки: первая будет очень медленной, а вторая очень быстрой, хотя сетевые условия явно одинаковы.

См. Https://paste.debian.net/408552/ для теста с моего сервера в Северной Европе: загрузка A * - это один URL, B * - другой; A-2 - после A-1, а B-2 - после B-1, но B * запущен во время работы A-2. Все же A-1 и B-1 были очень быстрыми, A-2 и B-2 очень медленными.

Это все больше похоже на проблему с качеством обслуживания /QoS, также называемым регулированием. Может CloudFront задушить меня из-за промахов кэша, или мы должны винить только их клиента?

(*) Примечание: у меня есть соединение FTTH 10/10 Мбит / с с Fastweb. Доступная пропускная способность никогда не идет под этой гарантированной скоростью. Интернет-провайдер, как известно, не применяет регулирование QoS, но иногда имеет некоторые проблемы с маршрутизацией за пределами Италии. Когда я заметил проблему, у меня не было проблем с насыщением полосы пропускания другими службами.

Answer 1

Если вы не являетесь представителем учетной записи AWS, владеющей дистрибутивом CloudFront, - и из фразы, использованной в вопросе, создается впечатление, что это не так, - тогда вашим подходящим контактным лицом является веб-сайт, на котором вы испытываете трудности спектакль.

Тогда было бы их ответственность открыть поддержку инцидент с поддержкой AWS, если они сочтут это целесообразным, так как они клиенты CloudFront в.

CloudFront предназначен для направления вашего запроса в самое оптимальное пограничное местоположение CloudFront (где "оптимальное" часто, но не всегда означает географически близкое расположение) в рамках уровня цен, выбранного владельцем дистрибутива (владельцы могут не платить за более дорогие ребра, где Amazon затраты выше, и в этом случае запросы на этот сайт позволят избежать этих ограничений или, по крайней мере, избежать премиальных цен, даже если CloudFront может, по их выбору, использовать местоположение с более высокой стоимостью, но выставлять счета по более низкой ставке).

Оптимальный фронт для определенного местоположения загрузчика будет сдвигаться со временем из-за множества факторов, включая задержку, перегрузку, размеры прыжков и пути AS, пропускную способность канала и любое количество других факторов ... которые не являются общедоступной информацией, но учитываются алгоритмами маршрутизации CloudFront, которые определяют, какой ответ DNS вы получите, когда подключаетесь к сайту на основе CloudFront. Ответ DNS зависит от IP-адреса запрашивающего клиента.

С одного IP-адреса источника в Южном Огайо (США) я вижу маршрут моего испытательного сайта CloudFront через периферийное местоположение, которое меняется между Саут-Бенд (IN, США), Чикаго (Иллинойс, США) и Ашберном (VA, США) на довольно регулярное основание - без фактического IP-адреса я требую, чтобы страница даже изменилась. От аналогичной установки, расположенной на расстоянии менее 5 миль, но с другим статическим IP-адресом источника, использующим другого провайдера, я получаю одинаково разные, но часто разные ответы.

Это легче всего объяснить с помощью алгоритмов CloudFront, которые пытаются выбрать наиболее подходящее преимущество, основываясь на факторах, которые не очевидны извне.

Насколько вам известно, ваше медленное поведение на вчерашних подключениях к CloudFront могло быть обнаружено и вызвало алгоритм выбора, чтобы выбрать другую стратегию, что привело к тому, что проблема с производительностью «сама себя исправила». Также возможно, что Мадридский край использовался как неоптимальный выбор из-за проблем доступности в лучшем местоположении местоположения.

Также могла быть проблема между CloudFront и исходным сервером. Заголовки ответа от CloudFront дали бы вам немного больше информации ... Если X-Cache: Hit from Cloudfront присутствует, вы обслуживаетесь из пограничного кэша, а заголовок Age: сообщит вам, как долго объект был кэширован на границе. Если X-Cache: Miss from Cloudfront , то ваша загрузка не была кэширована на грани, и файл, который вы получаете в настоящее время, извлекается с исходного сервера и одновременно переносится в кэш и передается обратно вам. Разрешение этой загрузки полностью завершиться, а затем повторная загрузка с идентичным запросом должна получить кэшированную копию, при условии, что ваш следующий запрос достигнет того же края, а разница в скорости, если таковая имеется, приблизительно указывает на скорость соединения с исходным сервером. , CloudFront - это сквозная сеть CDN; объекты не реплицируются по краям, они хранятся только в тех местах, где они были запрошены, после первоначального запроса.

Как клиент CloudFront, у меня никогда не было необходимости сообщать о медленных загрузках. Это не значит, что он идеален, но сервис, похоже, очень надежно спроектирован для обеспечения производительности и отказоустойчивости.