Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.

Чтобы теоретически определить лучшее физическое место для размещения своего сервера, я объединил общедоступные данные о задержках с собственными журналами доступа к веб-серверу. Я стремлюсь получить грубый, количественный, ответ, основанный на реальном наборе данных.


По мере роста сетевых задержек могут происходить странные вещи: «толстые» сайты могут стать более быстрыми (особенно если они полностью обслуживаются из CDN), а «тонкие» сайты, использующие API-интерфейсы, могут стать более медленными. Для пользователя настольного ПК/ноутбука типичная задержка достигает 200 мс, а для мобильного пользователя 4G составляет 300–400 мс. В этой статье предполагается, что пропускная способность равна 40 Мбит/с, поддерживается TLS, задержка CDN равна 40 мс и нет существующих соединений. «Исходная точка» здесь означает основной веб-сервер (в отличие от «пограничных» кэшей CDN).

Почему местоположение имеет значение

Время пересечения Интернета добавляется ко времени, затраченному на ответ на запрос. Даже если ваш API-интерфейс способен ответить на запрос за 1 мс, когда пользователь находится в Лондоне, а API-сервер — в Калифорнии, пользователю всё равно придется ждать ответа около 130 мс.

Весь процесс занимает немного больше 130 мс. В зависимости от того, что делают пользователи, в конечном счёте они могут совершить несколько таких операций передачи и подтверждения. Для загрузки веб-страницы обычно требуется пять полных операций передачи и подтверждения: одна  — для разрешения доменного имени с помощью DNS, одна — для установления TCP-соединения, ещё две — для настройки зашифрованного сеанса с TLS, и, наконец, одна — для страницы, которую вы хотели получить в первую очередь.

В последующих запросах можно (но не всегда) повторно использовать настройки DNS, TCP и TLS, но при каждом обращении к серверу, например при вызове API-интерфейса или при создании новой страницы, по-прежнему требуется новая операция передачи и подтверждения.

Сначала кажется, что 130 мс — это быстро, но вся эта долгая и муторная процедура с простым получением страницы и последующим выполнением пары API-вызовов может легко занять большую часть секунды только с точки зрения времени ожидания сетевого сигнала. Всё остальное необходимое время — время выбора сервером ответа на запрос, время загрузки нужных данных, а затем время визуализации содержимого в браузере — всё это дополнительное время.

Два вида понятия «быстрый» для сетей

При обсуждении сетей сбивает с толку то, что люди говорят о получении «более быстрых» сетей: «более быстрая» домашняя широкополосная связь, например, или «быстрый ethernet» (скорость «100 мегабит в секунду» уже не впечатляет).

Понятие «быстрее» этого вида на самом деле не свидетельствует о скорости. Более высокая скорость привела бы к сокращению задержки и, соответственно, к ускорению операций передачи и подтверждения. Вместо этого понятие «более быстрых» сетей фактически означает более высокую пропускную способность, т. е. передаётся больше байт в секунду.

API-интерфейсы, или сети CDN

Существует сеть, в которой операции выполняются быстрее, — это сеть дистрибуции содержимого (Content Distribution Network, CDN). Вместо того чтобы пройти весь путь до Калифорнии, возможно, вы сможете получить часть веб-страницы из кэша в Центральном Лондоне. Такой подход экономит время. Операция может занять всего 50 мс. Экономия достигает 60 %. Кэш отлично работает для CSS-файлов, изображений и JavaScript, т. е. для ресурсов, которые не меняются для всех пользователей. Он не так хорошо работает для ответов на API-вызовы, так как ответы различны для каждого пользователя, а порой и всегда.

Количественный подход

Немногие счастливчики все запросы могут обрабатывать с помощью CDN. Новостные сайты, например, показывают всем одно и то же. Другие менее удачливы и могут применять кэширование лишь в ограниченном объёме или вообще не использовать его. Эти несчастные люди должны выбрать такое место для своего основного сервера, чтобы максимально быстро доставлять свои данные пользователям, которые в них нуждаются. Если этот выбор направлен лишь на уменьшение задержки, какое место они должны выбрать?

Вот что я сделал:

  1. Я взял собственные журналы доступа за две недели в сентябре сразу после того, как опубликовал что-то новое. За этот период я получил около миллиона запросов от 143 тыс. уникальных IP-адресов. Я исключил очевидных роботов (на которые пришлись около 10 % запросов).

  2. Я использовал базу данных GeoIP компании Maxmind для привязки каждого IP-адреса в этих журналах доступа к соответствующим географическим координатам.

  3. Затем я использовал опубликованные на сайте WonderNetwork данные о задержках в интернет-соединениях между примерно 240 городами мира.

  4. Я сопоставил (полуавтоматически, что было довольно мучительно) названия этих городов с идентификаторами Geonames, что позволило получить координаты городов.

  5. Затем я загрузили всё вышеперечисленное в базу данных Postgres с установленным расширением PostGIS для выполнения географических запросов.

  6. Я запросил оценку длительности (в процентах) выполнения запросов в ситуациях, когда мой сервер находился бы в каждом из 200 городов.

Результаты

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

  • среднее («P50»);

  • для трёх четвертей запросов («P75»);

  • для 99 % запросов («P99»).

Все числа выражены в миллисекундах.

Все результаты см. в таблице

City

p50

p75

p99

Manhattan

74

97

238

Detroit

89

115

245

Secaucus

71

96

246

Piscataway

75

98

251

Washington

82

105

253

Chicago

90

121

253

Kansas City

98

130

254

Indianapolis

96

125

254

St Louis

96

127

256

Cincinnati

92

121

257

Houston

104

134

257

Syracuse

77

102

257

Scranton

78

103

258

Quebec City

83

113

259

South Bend

92

118

259

Montreal

83

104

259

Charlotte

91

110

259

Salem

74

98

259

Buffalo

80

111

259

Albany

75

100

260

Monticello

94

123

260

Baltimore

80

105

260

Asheville

95

118

260

New York

77

103

261

Berkeley Springs

84

112

261

Minneapolis

102

133

261

Barcelona

102

148

261

Dallas

112

140

262

Des Moines

104

131

262

San Jose

139

165

263

Brunswick

77

101

264

Atlanta

88

113

264

San Francisco

136

168

264

Halifax

80

102

265

Philadelphia

77

100

266

Basel

97

146

267

Green Bay

103

131

267

Pittsburgh

88

117

267

Bern

99

147

267

Denver

112

141

267

Miami

103

129

267

Raleigh

88

111

268

Knoxville

114

135

268

Boston

77

105

268

Valencia

108

148

268

Jackson

105

132

268

Memphis

101

131

268

Jacksonville

95

122

268

Madrid

95

138

268

London

76

130

268

San Diego

138

162

269

San Antonio

112

138

269

Salt Lake City

120

151

269

Toronto

87

111

269

Cleveland

97

122

269

Austin

113

141

270

Colorado Springs

110

136

270

Orlando

103

126

270

Antwerp

93

137

271

Oklahoma City

114

147

271

Saskatoon

115

140

272

Lansing

98

127

272

Seattle

141

164

272

Columbus

92

120

273

Bristol

76

129

274

Tampa

104

130

274

Lausanne

95

139

274

Ottawa

85

111

274

Falkenstein

91

137

275

Maidstone

76

129

275

Paris

80

129

275

Toledo

102

129

275

Savannah

117

146

276

The Hague

82

138

276

Liege

87

136

277

Lincoln

100

124

277

New Orleans

115

142

278

Amsterdam

82

140

278

Las Vegas

136

163

279

Vienna

102

149

279

Coventry

80

132

279

Cromwell

80

106

280

Arezzo

109

160

280

Cheltenham

79

131

280

Sacramento

137

167

280

Alblasserdam

82

137

281

Vancouver

142

165

281

Fremont

131

157

283

Gosport

76

137

284

Frankfurt

93

136

284

Carlow

88

136

285

Phoenix

128

153

285

Portland

132

159

285

Cardiff

78

131

285

Luxembourg

87

137

285

Bruges

83

135

285

Eindhoven

85

133

285

Groningen

87

139

286

Manchester

80

137

286

Brussels

90

139

287

Brno

106

148

287

Edinburgh

84

136

287

Nuremberg

89

136

288

Albuquerque

125

159

289

Los Angeles

141

164

289

Ljubljana

110

152

289

Lugano

97

147

290

Zurich

103

146

290

Dronten

84

133

290

Newcastle

87

147

290

Rome

96

147

291

Dusseldorf

90

140

291

Munich

98

144

291

Venice

106

156

292

Edmonton

139

165

292

Copenhagen

96

145

292

St Petersburg

113

163

293

Dublin

85

143

293

Redding

142

178

293

Vilnius

110

162

293

Belfast

79

125

294

Nis

113

158

294

Douglas

87

143

294

Rotterdam

82

139

295

Bergen

107

157

295

Strasbourg

89

141

295

Roseburg

148

172

296

Graz

104

147

296

San Juan

117

141

298

Warsaw

108

161

299

Frosinone

105

153

299

Riyadh

159

206

300

Prague

103

152

301

Ktis

102

158

302

Mexico

139

164

302

Belgrade

113

160

302

Guadalajara

128

155

303

Milan

96

146

305

Bratislava

102

154

306

Osaka

181

240

307

Zagreb

103

150

308

Tallinn

108

162

308

Helsinki

105

156

308

Hamburg

127

166

309

Oslo

98

153

311

Bucharest

120

162

311

Riga

113

159

312

Panama

150

177

313

Tokyo

188

238

313

Kiev

119

168

313

Stockholm

102

153

314

Budapest

110

162

314

Kharkiv

128

169

315

Gothenburg

115

167

316

Pristina

122

167

316

Tirana

128

184

316

Geneva

96

142

316

Siauliai

113

163

317

Cairo

133

182

318

Sapporo

196

255

318

Bogota

170

188

319

Palermo

119

183

320

Gdansk

107

152

320

Caracas

149

176

320

Sofia

114

161

321

Westpoort

79

134

321

Honolulu

173

196

321

Roubaix

102

157

321

Kazan

138

190

322

Winnipeg

169

190

322

Varna

120

173

322

Tel Aviv

138

194

322

Lisbon

115

166

324

Jerusalem

145

198

324

Ankara

139

195

327

Heredia

164

188

327

Athens

128

183

329

Reykjavik

127

180

329

Paramaribo

166

194

330

Algiers

120

173

332

Chisinau

127

180

333

Bursa

135

188

334

Thessaloniki

134

187

336

Limassol

141

186

337

Lyon

95

145

340

Mumbai

204

248

340

Medellin

163

186

344

Valletta

120

176

345

Baku

160

205

346

Melbourne

227

269

346

Fez

149

198

348

Tunis

124

180

348

Koto

217

254

348

Dubai

192

243

350

Tbilisi

153

208

351

Malaysia

195

235

352

Hyderabad

214

260

354

Bangalore

212

252

355

Izmir

137

187

357

Adelaide

241

272

359

Chennai

221

248

359

Moscow

127

172

359

Lahore

217

270

361

Novosibirsk

163

206

362

Sydney

237

272

363

Karaganda

180

231

363

Vladivostok

223

264

364

Taipei

265

293

364

Lima

169

199

364

Istanbul

135

182

366

Hong Kong

199

223

366

Auckland

244

291

367

Jakarta

207

245

368

Seoul

231

277

371

Beirut

136

195

372

Accra

168

216

373

Singapore

190

246

374

Sao Paulo

193

213

375

Joao Pessoa

182

220

378

Perth

243

267

379

Ho Chi Minh City

253

287

380

Wellington

251

295

383

Brasilia

226

249

384

Manila

251

281

385

Pune

202

251

386

Dhaka

231

268

386

Phnom Penh

243

267

386

Santiago

202

230

390

Lagos

191

233

391

Quito

162

188

392

New Delhi

230

264

395

Johannesburg

237

283

398

Bangkok

222

254

401

Canberra

262

295

402

Dar es Salaam

214

267

407

Dagupan

239

268

408

Christchurch

257

309

409

Hanoi

235

264

415

Cape Town

216

262

417

Buenos Aires

232

253

417

Guatemala

217

249

418

Brisbane

261

288

422

Indore

304

352

457

Zhangjiakou

236

264

457

Nairobi

233

277

468

Kampala

244

287

480

Hangzhou

239

267

517

Shenzhen

242

275

523

Shanghai

300

367

551

Montevideo

738

775

902

Вы также можете загрузить все результаты как csv-файл, если так проще.

Результат: восточное побережье Северной Америки — хорошо, прямо в Атлантике — лучше

Все лучшие места находятся в Северной Америке. Это, вероятно, не стало полным сюрпризом, учитывая, что это довольно плотный кластер носителей английского языка, от которого не так далеко (с точки зрения задержки), в Великобритании/Ирландской Республике, находится другой кластер. Кроме того, в Европе много тех, для кого английский — второй язык. Лучше всего находиться прямо в Атлантике: в штатах Нью-Джерси и Нью-Йорк есть много отличных мест для P99, и показатели в верхней части, между P50 и P99, варьируются не слишком сильно.

Если вам интересно, почему небольшие города в Нью-Джерси, такие как Секокус и Пискатауэй, так хорошо связаны, — в них есть большие центры обработки данных, используемые финансовым сектором Америки.

В настоящее время мой сервер находится в Хельсинки. Это был самый дешёвый вариант, что необычно для Финляндии. За этот сервер я плачу около трёх фунтов в месяц, всего лишь. Если бы я переместил его куда-нибудь в Нью-Джерси и потратил больше денег, в целом пользователи определённо сэкономили бы время: половина операций передачи и подтверждения была бы завершена за 75, а не за 105 мс, что позволило бы сэкономить 30 %. За несколько операций передачи и подтверждения время, вероятно, увеличилось бы примерно на шестую долю секунды по сравнению со средним показателем загрузки первой страницы, что не так уж плохо. Если вы не можете сказать, что этот веб-сайт очень обременителен для веб-браузеров с точки зрения визуализации, сокращение времени ожидания в сети сделает его значительно быстрее.

Поскольку на этом сайте ничего не генерируется динамически, в действительности мне лучше всего использовать CDN. Это действительно сэкономило бы много времени для всех: обслуживание из CDN почти в два раза лучше (~40 мс) установки сервера в самом быстром месте (71 мс).

Как это может меняться со временем

Задержки не фиксированы, и со временем они могут уменьшиться. Здесь предлагается таблиц задержек операций передачи и подтверждения при передаче данных из Лондона в другие города мира с населением более 5 млн. человек. Значения сравниваются с теоретической максимальной скоростью — скоростью света:

Город

Расстояние (км)

Реальная задержка

Теоретический максимум

Фактор замедления

Нью-Йорк

5 585

71

37

1,9

Лима

10 160

162

68

2,4

Джакарта

11 719

194

78

2,5

Каир

3 513

60

23

2,6

Санкт-Петербург

2 105

38

14

2,7

Бангалор

8 041

144

54

2,7

Богота

8 500

160

57

2,8

Буэнос-Айрес

11 103

220

74

3,0

Лагос

5 006

99

33

3,0

Москва

2 508

51

17

3,0

Сан-Паулу

9 473

193

63

3,1

Бангкок

9 543

213

64

3,3

Гонконг

9 644

221

64

3,4

Стамбул

2 504

60

17

3,6

Лахор

6 298

151

42

3,6

Токио

9 582

239

64

3,7

Ханчжоу

9 237

232

62

3,8

Шанхай

9 217

241

61

3,9

Mumbai

7 200

190

48

4,0

Тайбэй

9 800

268

65

4,1

Дакка

8 017

229

53

4,3

Сеул

8 880

269

59

4,5

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

Как видно из таблицы, задержка в Нью-Йорке находится в пределах коэффициента 2 от значения для скорости света, но маршруты в другие места, такие как Дакка и Сеул, намного медленнее: они в 4 раза превышают значения для скорости света. Вероятно, маршрут между Лондоном и Нью-Йорком так хорошо оптимизирован по вполне понятным причинам. Я сомневаюсь, что то, что между этими городами в основном лежит океан, представляет большую проблему, так как подводные кабели можно прокладывать напрямую. Добираться до Сеула или Дакки придётся более окольным путём.

Вероятно, следует упомянуть, что новые протоколы обещают уменьшить количество операций передачи и подтверждения. Версия TLS 1.3 позволяет создать зашифрованный сеанс с одной операцией передачи и подтверждения, а HTTP3 может объединить операции передачи и подтверждения протоколов HTTP и TLS. Это означает, что теперь нужны лишь три такие операции: одна — для DNS, одна-единственная операция передачи и подтверждения — для соединения и зашифрованного сеанса, и, наконец, третья — для темы запроса.

Некоторые люди ложно надеются, что новые протоколы, такие как HTTP3, устранят необходимость в объединении (bundling) JavaScript/CSS. Это основано на недоразумении: в то время как HTTP/3 удаляет некоторые исходные операции передачи и подтверждения, эта версия не удаляет последующие операции передачи и подтверждения для дополнительных данных JavaScript или CSS. Так что объединение, к сожалению, никуда не делось.

Слабые стороны данных

Хотя, как мне кажется, это и интересное упражнение — и, надеюсь, показательное, — я должен честно признать, что качество используемых мной данных целиком относится к категории «от среднего до низкого».

Во-первых, база данных GeoIP неоднозначно показывает местоположение IP-адресов. Заявленная (т. е., вероятно, оптимистичная) точность колеблется до 1000 км в некоторых случаях, хотя для моего набора данных утверждается, что средняя точность составляет 132 км со стандартным отклонением 276 км. Это не так уж точно, но я думаю, всё ещё полезно.

Мой источник данных о задержке, WonderNetwork, действительно сообщает данные о задержке на момент их получения (30 ноября 2020 года) в отличие от долгосрочных данных. Иногда в определённых местах Интернет «барахлит».

У WonderNetwork много станций, но их охват не идеален. На Западе всё отлично — в Великобритании представлены даже второстепенные города (вроде Ковентри). Их охват во всём мире по-прежнему хорош, но более неоднозначен. У них не так много мест в Африке или Южной Америке, а некоторые задержки в Юго-Восточной Азии кажутся странными: задержка между Гонконгом и Шэньчжэнем составляет 140 мс, тогда как эти города находятся всего в 50 км друг от друга. Этот фактор замедления более чем в тысячу раз превышает значение для скорости света. Для других городов континентального Китая проверка связи также показывает плохие результаты (что странно), хотя и не в таком масштабе. Может быть, эти коммунисты проверяют каждый ICMP-пакет вручную?

Другая проблема с данными о задержке заключается в отсутствии истинных координат центров обработки данных, в которых находятся серверы. Мне пришлось самому геокодировать данные с помощью некоторых сценариев и большого количества ручного ввода данных в Excel (я опубликовал эту таблицу Excel в github, чтобы никому не пришлось делать эту работу заново). Я очень старательно проверял данные, но ошибки всё ещё могут быть.

Однако, по моему мнению, самая большая слабость заключается в том, что все начинают отсчёт прямо от центра своего ближайшего города. На практике это не так и добавляемое из-за этого смещение может варьироваться. Здесь, в Великобритании, домашний доступ к Интернету — это сложный процесс, основанный на отправке высокочастотных сигналов по медным телефонным линиям. Моя собственная задержка для других хостов в Лондоне достигает 9 мс, что плохо для такого короткого расстояния, но всё ещё на 31 мс лучше среднего значения. Многие маршрутизаторы потребительского уровня не очень хороши и добавляют значительную задержку. Печально известная проблема излишней сетевой буферизации — ещё один распространённый источник задержки. Особенно это влияет на процессы, для хорошей работы которых требуется последовательный уровень задержки. В качестве примера можно привести видеоконференц-связь и многопользовательские компьютерные игры. Использование сети мобильных телефонов тоже не помогает. Сети 4G в хороших условиях добавляют около 100 мс задержки, но, конечно, всё гораздо хуже, когда уровень сигнала низок и есть много ретрансляций на уровне канала.

Я пытался предположить глобальную среднюю задержку на километр (около 0,03 мс), чтобы компенсировать расстояние до ближайшего города, но обнаружил, что это просто добавило кучу шума к моим результатам, так как для многих IP-адресов в моём наборе данных окольный путь был нереалистичным: ближайший город, который я им приписал, совсем не так близок.

Универсальность

Возникает справедливый вопрос: в какой степени мои результаты изменились бы для другого места? Трудно сказать, но я подозреваю, что результаты будут примерно такими же для других англоязычных мест без какой-либо особой географической составляющей. Это потому, что я думаю, что люди, читающие этот блог, вероятно, довольно равномерно распределены по англоязычной популяции мира.

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

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

Бесплатные операции передачи и подтверждения

Выбор хорошего места для вашего сервера заходит так далеко. Даже в хороших случаях у вас всё ещё будет почти 100 мс задержки за каждую операцию передачи и подтверждения. Как я писал выше, при посещении страницы может быть до пяти операций передачи и подтверждения.

Наличие ненужных операция передачи и подтверждения действительно замедлит процесс. Одна дополнительная операция передачи и подтверждения сводит на нет изрядную долю выигрыша от размещения сервера в быстром месте.

Операции передачи и подтверждения легко добавить случайно. Особенно удивительным источником операций передачи и подтверждения служат предварительные запросы общего доступа к ресурсам независимо от источника (CORS). По соображениям безопасности, связанным с предотвращением атак на основе межсайтового скриптинга, браузеры должны «проверять» определённые HTTP-запросы, созданные кодом JavaScript. Для этого на тот же URL-адрес предварительно отправляется запрос с помощью специальной команды OPTIONS. На основе полученного ответа принимается решение о допустимости исходного запроса. Правила, определяющие точный момент отправки предварительных запросов, сложны, но в сети появляется удивительное количество запросов: в частности, включая POST-запросы JSON к поддоменам (например, к поддомену api.foo.com от домена foo.com) и сторонние веб-шрифты. В предварительных проверках на основе CORS-запросов используется другой набор заголовков кэширования по сравнению с остальным HTTP-кэшированием, которые редко задаются правильно и в любом случае применимы только к последующим запросам.

В наши дни многие сайты написаны как «одностраничные приложения», где вы загружаете некоторый статический пакет JavaScript (надеюсь, из CDN), а затем создаёте (надеюсь, небольшое) количество API-запросов внутри своего браузера, чтобы решить, что показывать на странице. Есть надежда, что этот процесс станет быстрее после первого запроса, так как не придётся перерисовывать весь экран, когда пользователь попросит загрузить вторую страницу. Как правило, это не помогает, потому что одна HTML-страница обычно заменяется несколькими последовательными API-вызовами. Пара последовательных API-вызовов к исходному серверу почти всегда обрабатывается медленнее перерисовки всего экрана, особенно в сети мобильной связи.

Я всегда считаю немного вздорной ситуацию, когда я получаю загружающуюся панель на веб-странице — вы уже отправили мне страницу, но почему сразу не отправили нужную мне страницу?! Один из величайших парадоксов Интернета заключается в том, что, хотя Google не очень хорошо справляется с обходом таких одностраничных приложений, эта компания, безусловно, создаёт большое их количество. Особенно дьявольской является «консоль поиска» (веб-сайт, ранее известный как «средства веб-мастера»). Я полагаю, Google не нужно слишком беспокоиться об оптимизации поисковых систем (SEO).

Пропускная способность быстро увеличивается, но задержка уменьшается медленно

Пропускная способность Интернета становится всё лучше и лучше. Сейчас можно передавать гораздо больше байт в секунду, чем даже несколько лет назад. Однако улучшения задержки довольно редки, и по мере приближения к значению для скорости света они совсем сойдут на нет.

100 мегаватт в секунду менее убедительны, когда вам по-прежнему приходится ждать всё те же полсекунды для загрузки каждой страницы.

Смотрите также

В прошлом году в центре APNIC проанализировали производительность CDN по всему миру и пришли к выводу, что задержка 40 мс типична. Мне бы хотелось, чтобы в эту публикацию были включены процентильные данные, но у меня сохраняется смутное впечатление, что сети CDN лучше всего работают на Западе и менее хорошо в Южной Америке, Китае и Африке, что является проблемой, учитывая, что большинство серверов находится на Западе.

Пока я писал эту статью, произошла вспышка «клубов», основанных на весе страницы, таких как Клуб 1МБ и, предположительно, более элитный Клуб 512К. Пожалуй, я одобряю это чувство (и всё это во имя веселья, я уверен). Я думаю, что они слишком подчёркивают размер передаваемых данных. Если вы в Лондоне запрашиваете динамически генерируемую страницу из Калифорнии, весь процесс всё равно займёт большую часть секунды (130 мс умножить на 5 операций передачи и подтверждения), независимо от того, насколько велик размер этой страницы.

На карту подводных кабелей всегда приятно смотреть. Если вы хотите увидеть признак разной важности разных мест: Нормандские острова (население 170 тыс. человек) имеют 8 подводных кабелей, в том числе два, которые просто соединяют Гернси и Джерси. У Мадагаскара (население 26 млн. человек) их всего четыре. Я также считаю забавным то, что, хотя Аляска и Россия довольно близки, между ними нет ни одного кабеля.

На случай, если вы захотите воспроизвести мои результаты, я опубликовал свой код и данные в Github. Боюсь, что сюда не входят мои журналы доступа, которые я не могу обнародовать по соображениям конфиденциальности. Пожалуйста, не ждите, что я создам для вас повторяемый процесс сборки: это требует гораздо больше времени и усилий, и поэтому он предоставляется по принципу «требуется некоторая сборка».

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсы