Корейский CDN заработал

[dil]

но… что это, Бэрримор?!

$ tcptraceroute 175.41.12.116
Tracing the path to 175.41.12.116 on TCP port 80 (http), 30 hops max
 9  * * *
10  TenGE10-3.br01.hkg12.pccwbtn.net (63.218.174.37)  376.228 ms  358.686 ms  362.742 ms
11  cdnetworks.ge10-9.br01.hkg12.pccwbtn.net (63.218.175.214)  361.105 ms  366.016 ms  365.778 ms
12  175.41.9.54  358.396 ms  358.214 ms  356.355 ms
13  175.41.12.116 [open]  368.201 ms  -196.318 ms  358.779 ms

Оригинал этой записи в личном блоге.

Comments

Мелко плаваешь...

[ufm]

9 175.41.12.116 [open] 211.032 ms -9971.182 ms 211.151 ms

[zeleny.livejournal.com]

"- а мы вас уже заждались, граждане. вот и ответ на ваш еще не заданный вопрос приготовили. и даже отправили."

[dil]

Таки вы будете смеяться, но оказалось, что так оно и есть: http://dil.dreamwidth.org/1280591.html?thread=8954703#cmt8954703

[lazyboa.ya.ru]

Если Корея северная, то у них передача может превышать скорость света.

[tejblum.livejournal.com]

Ну а что, сервер решил поретрансмитить syn-ack до того, как получил следующий syn.

[dil]

Разве сразу с первым syn-ack'ом это делается? И если да, то такой эффект в tcptraceroute наблюдался бы довольно часто, а я первый раз увидел. И теперь воспроизвести не могу, хотя время прохождения пакетов и сейчас примерно такое же, иногда даже больше.

[tejblum.livejournal.com]

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

Я прямо отрицательного времени в tcptraceroute не видел, но у меня ping до них чуть больше 200ms, а второе и третее время в tcptraceroute обычно гораздо меньше (сейчас вот 12ms вылезло). (Но у меня tcptraceroute очень старый, не знаю, менялся ли он с тех пор, как я его поставил)

[dil]

Это в теории он должен быть быстрый, а конкретно до этого у меня

--- 175.41.12.116 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19002ms
rtt min/avg/max/mdev = 358.837/422.214/771.207/105.513 ms

Я посмотрел, что за пакеты ходят от tcptraceroute, он на самом деле на SYN-ACK каждый раз честно отвечает RST.

Интересно, что от 175.41.12.116 второе время всегда существенно меньше, чем первое и третье.

Обычно последовательность последних пакетов (которые уже доходят до самого сервера), выглядит так: (SYN туда, SYN-ACK обратно, RST туда){3 раза}.

А конкретно на 175.41.12.116 получается так: (SYN туда, SYN-ACK обратно, RST туда){3 раза}, а потом ещё (SYN-ACK обратно, RST туда){3 раза}. И судя по sequence number в ответах, приходят они по две штуки на каждый SYN:

12:39:22.615256 IP (tos 0x0, ttl 12, id 16100, offset 0, flags [none], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [S], cksum 0x4a75 (correct), seq 160077776, win 0, length 0
12:39:23.069180 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x5774 (correct), seq 2929470615, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.069217 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

12:39:23.069760 IP (tos 0x0, ttl 12, id 21560, offset 0, flags [none], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [S], cksum 0x4a75 (correct), seq 160077776, win 0, length 0
12:39:23.139962 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x5774 (correct), seq 2929470615, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.139980 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

12:39:23.140049 IP (tos 0x0, ttl 12, id 4246, offset 0, flags [none], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [S], cksum 0x4a75 (correct), seq 160077776, win 0, length 0
12:39:23.430190 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x3924 (correct), seq 2935114385, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.430216 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

12:39:23.489890 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x3924 (correct), seq 2935114385, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.489908 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

12:39:23.509410 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x6131 (correct), seq 2936349297, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.509423 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

12:39:23.590477 IP (tos 0x0, ttl 54, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    175.41.12.116.80 > A.B.C.D.43214: Flags [S.], cksum 0x6131 (correct), seq 2936349297, ack 160077777, win 65535, options [mss 1460], length 0
12:39:23.590489 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    A.B.C.D.43214 > 175.41.12.116.80: Flags [R], cksum 0x4a72 (correct), seq 160077777, win 0, length 0

Возможно, у них там сильно заниженный таймаут на повторную передачу пакетов, и они успевают два раза отправить SYN-ACK, прежде чем получат первый RST. Или у них там просто какой-то кривой TCP..

[tejblum.livejournal.com]

Ну, RST-то, мне кажется, ядро шлёт, а не tcptraceroute.

[dil]

Возможно, но в данном случае это не принципиально.