Pull to refresh
3

User

Send message
Я правильно полагаю, что пока Хабр не включится в ipv6, вы мне не ответите?

Неправильно полагаете, поскольку давно изобретен NAT64
Вот в обратном направлении есть определенные проблемы, и без прокси-серверов уже не обойтись. Но да, не могу сказать, что там большие проблемы, просто надо помнить… о нюансах, скажем так.

Ну, лично я никогда и не ставил акценты в таком ключе, что кто-то из них лучше. Я лишь говорил о своем личном опыте, что однажды я обнаружил, что мне IPv6 необходим и я для этого сменил провайдера только потому, что старый не давал ни статики по IPv4, чтобы работал туннель до Hurricane Electric, ни собственного IPv6. Потом я съездил в штаты и с удивлением узнал, что у T-Mobile, а это, на секундочку, один из крупнейших мобильных операторов США, оказывается IPv6 доступен изначально, а вот IPv4 надо открывать дополнительным соглашением, но без этого соглашения и так интернет прекрасно работает. И что это никакой не как-бы экспериментальный протокол для гиков, а вполне себе коммерческое решение, широко используемое во всем мире. Доля IPv6 мировом трафике растет огромными темпами, даже в Китае и Индии, и только бывший совок плетется в хвосте. И вот тут мне становится немного непонятно, не происходит ли тут технологическое отставание нашей страны в базовых для информатизации вещах. А после вала сообщений здесь типа "наши деды всегда трутом и кресалом огонь добывали, зачем нам ваши зажигалки" я понял ещё одну вещь, что тут не только налицо само технологическое отставание, это как раз можно преодолеть. Налицо ещё и психологическое нежелание это отставание преодолевать, поскольку это выводит из зоны комфорта. Ну ок, я не собираюсь здесь проповедовать, мессия из меня никакой. Это скорее просто ещё один небольшой довод в копилку для того, чтобы завести трактор.

Ну так по WiFi они и так уже сейчас связываются, и по bluetooth — тоже. Кто-то тут говорил про подмену понятий?

И отправит траффик до Кореи через Европу — ну а что, достаточно же, дойдет. Может быть действительно там нехватка каналов, но что-то я думаю что костыльность нынешнего ipv4 заключается не только в несоотвествии числа адресов и хостов, но и алгоритм тоже неидеальный.

И правильно сделает, что отправит через Европу, что бы Вы лично хотели больше, пинг 500мс и 100% доставка(ну ладно, почти 100%), или 90мс и потери в 10%? Чуда ведь не будет, какой протокол не придумай. Кроме того, нужно учитывать тот факт, что у любого провайдера на периферии самый толстый и надежный канал будет в Москву и СПб, потому что хотите Вы того, или нет, но 60-70% трафика будет именно туда. Будут ли вообще какие-то другие каналы вообще — тут вопрос, есть ли у провайдера деньги на дополнительные плюшки. Чаще всего их, денег, на все плюшки не хватает.


Широта и долгота вообще-то не очень человеко-читаемые единицы, тем более в сжатом виде, strawman же..

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

какой голос? его доля в магистральных каналах исчезающе мала.

Это ничего не меняет. Магистральщики — это отдельный вид разумных существ, с интернет-провайдерами они не скрещиваются ;)


вы уверены, что линки в 600 и 400 гигабит по SDH идут?

А Вы уверены, что это пропускная способность единичного канала, а не агрегированная из множества каналов STM-64? Или речь о том, что провайдерам SDH не виден, им виден MPLS, а что там в канале, они не знают и им всё равно?

Обработку заголовков можно сделать за микро-наносекунды

Она и происходит за наносекунды. Проблема в том, что эта операция происходит очень много раз. И набегают миллисекунды. Но хуже того, чтобы усилить сигнал в оптоволокне, нужно раз в 50-100км преобразовывать его в электрическую копию, восстанавливать форму сигнала и потом преобразовывать его в свет обратно. И вот тут всё происходит ну просто ужас как медленно по сравнению с остальными процессами. Придумайте, как сделать это быстрее хотя бы раза в два — в три, станете очень богатым человеком.


Кроме того, 500 мс для общения голосом это чрезвычайно некомфортно тоже.
Задержка голоса в 500мс вполне себе бывает в мобильных сетях. Особо не мешает. Разве что эхо раздражает.
Но вообще я не пойму, что лично Вы хотите? Чтобы Ваш провайдер проложил оптоволоконную магистраль прямо в Сеул? Каким образом это относится к обсуждению исходной темы?

О да, списки роскомпозора — отличное чтиво для любознательных. Полез читать сайт, который был заблокирован 14.12.2015, и залип там надолго. ;)

link/ether e4:95:11:11:11:11 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e695:1111:1111:1111/64 scope link

Гы-гы-гы. Нет IPv6. Ну ок.

На сайте OpenWRT для GL-AR750S я не нашел никаких упоминаний о прошивке 3.101
Есть 19.07.01
В dmesg от её загрузки явственно видно


[   21.734875] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   21.768425] br-lan: port 1(eth0.1) entered blocking state
[   21.774015] br-lan: port 1(eth0.1) entered forwarding state
[   21.780071] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.2: link becomes ready
[   21.892225] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready

И? Будем извиняться?

OpenWRT 19.07.1, самая последняя версия. Raspberry Pi3.
Чистая свежезалитая прошивка.


4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether b8:27:eb:b4:a6:b4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fdb3:4c8a:6296::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:feb4:a6b4/64 scope link 
       valid_lft forever preferred_lft forever

Вот не надо врать то. Всё на месте. Адрес из Local IPv6 unicast addresses (см rfc4193), это полный аналог 192.168.1.1

Как протокол сетевого уровня может исправить то, что невозможно сделать исходя из ограничений физического и канального уровней? Два приемопередатчика мобильных телефонов не умеют связываться между собой. Только с базовой станцией мобильного оператора. А вот там уже возможны варианты. Но сейчас, при текущих настройках, базовая станция отправляет полученные пакеты от пользователя сразу поближе к ядру сети, туда, где биллинг, аппаратура по закону Яровой, где пакет данных будет обмерен, проклассифицирован и копия которого будет сложена на три года ждать оперативных действий силовиков. А уж потом он вернется назад на эту же базовую станцию (может быть, пройдя при этом сотни и тысячи километров) и с неё будет отправлен другому телефону.

Ну нет же. Вы, вместе с авторами NDN, пытаетесь в сущности, предназначенные исключительно для машинной обработки, вложить удобные человеку понятия, категории и смыслы. Безусловно, это можно сделать. Но это лишь усложнит машинную обработку и, внезапно, не принесет никакой выгоды человеку. Вы на практике не пользуетесь IP адресами, вы используете DNS имя, которое как раз и предназначено для удобного использования человеком. А маршрутизатору абсолютно всё равно, есть ли какой-то физический смысл в IP адресе, который он сейчас форвардит, ему достаточно одной записи в таблице маршрутизации, по которой он примет решение.

отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.

А кто Вам сказал, что существует канал Владивосток-Сеул или Хабаровск-Сеул, что он не загружен настолько, что в этом канале возникают потери и маршрутизация на автомате не начинает избегать этого канала?


в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения.

Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета. На практике цифра и голос делят одни и те же мощности и выделение нового канала передачи данных — это выделение очередного контейнера в SDH в магистральном канале. Да, может быть такое, что Ваш провайдер по IPv4 подписал один договор, и по IPv6 — другой, с другим поставщиком. Но вероятность этого исчезающе мала исключительно по экономическим причинам.


"зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми.

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

Это недостижимо по политическим причинам. Государство просто не допустит существование таких протоколов передачи данных. Ни у нас, ни в самых распрекрасных оплотах демократии. Но особенно у нас. Поэтому только так, любой чих — через мобильного оператора. И — в папочку.

Что понимается под словами "напрямую, минуя провайдера"? Минуя маршрутизацию через оборудование мобильного оператора? Нет, и тут версия протокола или адресация не при чем. Канальный уровень, передача сигналов в сотовой сети так устроена, что это невозможно.

Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.

Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул. Или Новосибирск-Сеул. Что цена на аренду канала в нем конкурентноспособна с остальными вариантами. Да что там цена, вообще просто есть возможность аренды, он не перегружен. Что Ваш провайдер прямо заинтересован в быстрой доставке контента из Южной Кореи своим потребителям и готов понести на это некоторые финансовые затраты. В таком идеальном мире да, до Новосибирска возможен пинг в 90мс. До Москвы — сильно сомневаюсь, на одной ретрансляции только больше потеряется. Это если не считать 50-60мс чистой задержки в стекле. Будет ближе к 200мс. Сорри, законы физики не обмануть.


от я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети?

Нет, это вообще никоим боком к версии IP не имеет. Физический и канальный уровень определяет всё и он никак не зависит от (желаемой) сетевой маршрутизации. А именно он будет определять задержки в канале. Есть прямой канал из X в Y, возможно на сетевом уровне будет принято решение использовать его. Нет прямого, из X в Y пакеты пойдут через Z. Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус. Чуть меньше в IPv6 только из-за того, что там пока чуть меньше загрузка канала.

Люто поддержу. И даже не "космос", а вообще наука, даже научно-популярные программы неинтересны. Особенно хорошо это заметно по телевидению и кино. Научно-популярные каналы смотрят единицы и потому они перекочевывают у кабельных операторов из общих пакетов в пакеты "для извращенцев". Ещё не в категорию "клубничка", но уже близко. Зато их место заселяют те самые экстрасенсы. А в кино на экраны вместо бравых космических десантников, топчущих пыльные дорожки далеких планет, прочно поселились зомби, вампиры и прочая шушера из городских средневековых страшилок. Вместо мечты и романтики будущего мы вдруг (??? ой ли?) решили вернуться к темным страхам прошлого.

А кто сказал, что пользователей можно привлечь к решению задач, которые им неинтересны?
Кроме SETI@Home существует минимум десяток аналогичных проектов, но ни один из них не набрал и сотой доли такой же популярности. А значит и мощностями они располагают… даже не суперкомпьютерными.

Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS

Уже всё давно придумали до нас
Это всё просто замечательно, адреса типа ru/msk/south_butovo/gorchakova_st/43/app123 вообще прекрасно человекочитаемы и вполне себе содержат географические данные. Но. Сущая малость. Надо теперь научить машины(маршрутизатор, он тоже машина, только сильно заточенная на один специфический вид деятельности) разбирать такие адреса миллионами в секунду и на их основе строить маршрут доставки. Это такая малость, но портит абсолютно всё.

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

Людям, которые пытаются порулить таблицами маршрутизации, надо бить по шаловливым ручкам. Разные там BGP не зря придуманы и десятки лет отлизывались.
А машинные алгоритмы при выборе маршрута как раз и оперируют той же задержкой сигнала, как одним из многих параметров. Но только одним из многих.


Да мне без разницы, каким способом, просто я хочу, чтобы скажем, у меня пинг до Кореи был не 500 мс, а хотя бы 90.

И как этому может помочь впендюривание географических координат в IP адрес?
Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ и выберите правильного провайдера с нужной связностью. Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.


traceroute как он есть. И что тут могут сделать шаловливые ручки людей?
traceroute to ppomppu.co.kr (110.45.151.153), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  ae-35.a01.nycmny17.us.bb.gin.ntt.net (128.241.2.249)  2.161 ms  2.214 ms  2.217 ms
 6  * * *
 7  ae-3.r22.asbnva02.us.bb.gin.ntt.net (129.250.6.116)  7.875 ms  8.931 ms  7.908 ms
 8  ae-5.r23.lsanca07.us.bb.gin.ntt.net (129.250.3.189)  79.181 ms  79.198 ms  79.103 ms
 9  ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49)  72.243 ms  76.325 ms  73.715 ms
10  ae-1.a01.lsanca20.us.bb.gin.ntt.net (129.250.2.214)  72.316 ms  76.786 ms  77.942 ms
11  ae-0.lgu.lsanca20.us.bb.gin.ntt.net (168.143.229.202)  69.884 ms  69.874 ms  68.233 ms
12  1.213.145.25 (1.213.145.25)  184.072 ms 1.213.149.161 (1.213.149.161)  71.271 ms  67.078 ms
13  1.208.105.17 (1.208.105.17)  236.061 ms 1.208.104.89 (1.208.104.89)  232.588 ms 1.208.105.17 (1.208.105.17)  232.250 ms
14  * * *
15  1.208.167.94 (1.208.167.94)  228.812 ms 1.208.172.38 (1.208.172.38)  255.913 ms 1.213.152.194 (1.213.152.194)  247.512 ms
16  1.213.149.13 (1.213.149.13)  239.558 ms 1.213.150.250 (1.213.150.250)  245.855 ms 1.208.175.126 (1.208.175.126)  239.431 ms
17  117.52.240.50 (117.52.240.50)  231.977 ms 117.52.240.38 (117.52.240.38)  241.309 ms  228.226 ms
18  61-111-1-118.kidc.net (61.111.1.118)  237.097 ms * 117.52.240.34 (117.52.240.34)  241.652 ms
19  110.45.151.153 (110.45.151.153)  243.424 ms  245.889 ms *
20  * 110.45.151.153 (110.45.151.153)  237.823 ms  247.705 ms

И ничего с этим не сделать

Information

Rating
Does not participate
Registered
Activity