Есть две технологии в ИТ, которые казалось должны были исчезнуть на рубеже прошлого века, но их живучесть и удобство раз за разом отодвигает их уход со сцены. Речь идет об IPv4 и X11. Если первый из них практически во всех аспектах уступает IPv6, то преимущества Wayland, как технологии над X11 очевидны не всем. Wayland вовсе не универсален, как X Windows System, он намного более прост. Это дает ему ряд преимуществ по сравнению с иксами, но в этом же кроются его недостатки.
Если говорить о преимуществах, то это в первую очередь простота реализации и долгожданное избавление пользователей графической среды Linux от таких артефактов перерисовки, как разрывы изображения, a․ k․ a․ tearing. С этим особенно часто сталкиваются обладатели видеокарт NVidia. Хватает и недостатков и противники замены X-сервера напирают на гибкость использования сетевых возможностей в различных сценариях.
As mentioned, X is essentially a networking protocol with graphical displaying capabilities.
На самом деле X11 сетевой протокол с графическими возможностями, а не наоборот. Из этого простого факта следует, что даже если в скором времени основные дистрибутивы Linux перейдут на протокол Wayland, многие из возможностей и примеров использования X сервера будут востребованы еще достаточно долгое время. Удаленный доступ к приложениям и сессиям X.Org - современной реализации X Window System, одна из таких ключевых особенностей системы.
▍ Сетевая структура взаимодействий X-сервера
Наиболее распространенным IPC, т․ е․ способом взаимодействия между процессами, X-клиента и X-сервера, являются сокеты. Их роль в предоставлении API связи с использование TCP/IP, а также сокетов домена Unix. Помимо сокетов клиент и сервер для коммуникации могут также использовать иные каналы IPC, например MIT Shared Memory Extension.
Доменные сокеты Unix (от англ. Unix Domain Sockets, UDS) являются POSIX-механизмом IPC, с помощью которого различные процессы ОС могут взаимодействовать друг с другом. Такие сокеты эффективнее локальных TCP/IP соединений, так как не требуют дополнительных байтов в заголовке протокола. Подобно сокетам TCP/IP, доменные сокеты Unix поддерживают надёжную потоковую передачу данных с помощью SOCK_STREAM. Они также могут работать в режиме упорядоченной ( см․ SOCK_SEQPACKET) и неупорядоченной ( см․ SOCK_DGRAM) передачи датаграмм.
Рис. 1 Сетевое взаимодействие между клиентом и сервером X с помощью UDS.
UDS используют файловую систему ОС в качестве адресного пространства имён (например
/tmp/my_xapp), сами сокеты в ней всего лишь inode, а процессы обращаются к сокетам, так же, как к файлу. Однако обмен данными в активном соединении использует не файловую систему, а только буферы памяти ядра.
Рис. 2 Сетевое взаимодействие между клиентом и сервером X поверх TCP/IP.
Сокеты TCP/IP и UDS создаются с помощью функции CreateWellKnownSockets(). Для этого она обращается к
_XSERVTransMakeAllCOTSServerListeners. Эта процедура пробегает по каждому интерфейсу транспорта, поддерживаемого сервером.static Bool
TryCreateSocket(int num, int *partial)
{
char port[20];
snprintf(port, sizeof(port), "%d", num);
<span class="hljs-keyword" style="color: rgb(0, 0, 255);">return</span> (_XSERVTransMakeAllCOTSServerListeners(port, partial,
&ListenTransCount,
&ListenTransConns) >= <span class="hljs-number" style="color: rgb(0, 128, 0);">0</span>);
}Количество таких интерфейсов определено константой
NUMTRANS в файле X11/Xtrans/Xtrans.c.#define NUMTRANS (sizeof(Xtransports)/sizeof(Xtransport_table))Таблица
Xtransports[] определена в том же самом файле и содержит 10 элементов, таким образом NUMTRANS ≤ 10.|admin@redeye:[~]> grep '{ &TRANS' /usr/include/X11/Xtrans/Xtrans.c
{ &TRANS(SocketTCPFuncs), TRANS_SOCKET_TCP_INDEX },
{ &TRANS(SocketINET6Funcs), TRANS_SOCKET_INET6_INDEX },
{ &TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
{ &TRANS(SocketLocalFuncs), TRANS_SOCKET_LOCAL_INDEX },
{ &TRANS(SocketUNIXFuncs), TRANS_SOCKET_UNIX_INDEX },
{ &TRANS(LocalFuncs), TRANS_LOCAL_LOCAL_INDEX },
{ &TRANS(PTSFuncs), TRANS_LOCAL_PTS_INDEX },
{ &TRANS(NAMEDFuncs), TRANS_LOCAL_NAMED_INDEX },
{ &TRANS(PIPEFuncs), TRANS_LOCAL_PIPE_INDEX },
{ &TRANS(SCOFuncs), TRANS_LOCAL_SCO_INDEX },Сами же флаги, которые во время сборки определяют транспортные интерфейсы X сервера, можно найти в
xc/config/cf/linux.cf.#if HasDECnet
# define ConnectionFlags -DUNIXCONN -DTCPCONN -DDNETCONN
# define ExtraLibraries -ldnet
#else
# define ConnectionFlags -DUNIXCONN -DTCPCONN
#endifПроследив цепочку до системного вызова
socket() находим такую последовательность транспортных процедур.TRANS(MakeAllCOTSServerListeners)
|
v +-------------------------+
+----->TRANS(OpenCOTSServer)+--->|TRANS(SocketSelectFamily)|
| | |TRANS(SocketOpen) |
| v +-------+-----------------+
| TRANS(Open) |
| | |
| v v
+------+TRANS(ParseAddress) socket()Серверный процесс стартует с вызова функции
TRANS(CreateListener) из Xtrans.c. Далее переход в состояние ожидания входящего соединения происходит в такой последовательности.TRANS(MakeAllCOTSServerListeners)
|
v
TRANS(CreateListener)
|
v
TRANS(SocketCreateListener)
|
v
bind()
В файле
Xtransmit.h можно обнаружить X_TCP_PORT. Первое клиентское соединение будет использовать порт 6000, второе — 6001 и т․ д․#define X_TCP_PORT 6000▍ Взгляд изнутри трафика между клиентом и сервером X
Запустим простейшую иксовую программу Xclock и проверим как все это работает на практике.
|admin@redeye:[~]> DISPLAY=tcp/192.168.10.10:0.0 strace -e trace=network -f xclock 2>& 1 |grep -A3 TCP
1. socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_TCP) = 3
2. setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
3. setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
4. connect(3, {sa_family=AF_INET, sin_port=htons(6000), sin_addr=inet_addr("192.168.10.10")}, 16) = 0
В первой строке вывода видим, что системный вызов
socket() завершился успешно и вернул файловый десткриптор 3. Далее, во второй строке setsockopt() выставляет параметр TCP_NODELAY, с которым TCP фрагменты отправляются по сети как можно ранее, даже если эти фрагменты слишком малы. В третьей строке опять встречается setsockopt() на это раз для активации опции SO_KEEPALIVE. Данный параметр поддерживает соединение в активном состоянии, с помощью периодической отправки служебных сообщений. Наконец в четвертой строке системный вызов connect() соединяет клиент X с сервером, по TCP порту 6000.Используемый TCP порт напрямую связан с количеством соединений и номером переменной
$DISPLAY, если бы использовалось DISPLAY=tcp/192.168.10.10:1.0, то тогда в последней строке connect() состоялся бы по TCP порту 6001.После рукопожатия обмен данными происходит с использованием структур X-клиента —
xConnClientPrefix, и X-сервера — xConnSetupPrefix, XconnSetup, определенных в файле /usr/include/X11/Xproto.h. Размер занимаемой памяти в структур в байтах определен в #define директивах заголовочного файла.#define sz_xConnClientPrefix 12
#define sz_xConnSetupPrefix 8
#define sz_xConnSetup 32
...
typedef struct {
CARD8 byteOrder;
BYTE pad;
CARD16 majorVersion, minorVersion;
CARD16 nbytesAuthProto; /* Authorization protocol */
CARD16 nbytesAuthString; /* Authorization string */
CARD16 pad2;
} xConnClientPrefix;
...
typedef struct {
CARD8 success;
BYTE lengthReason; /*num bytes in string following if failure */
CARD16 majorVersion,
minorVersion;
CARD16 length; /* 1/4 additional bytes in setup info */
} xConnSetupPrefix;
Рис. 3 Установка параметров соединения в сессии X11.
Можно также пронаблюдать за процессом с помощью сетевого анализатора, клиентский запрос Initial connection request соответствует вызову
xConnClientPrefix. Соответственно Initial connection reply в следующем пакете создан со стороны xConnSetupPrefix и xConnSetup. Для сбора трафика можно запустить Wireshark и слушать локальный интерфейс, либо с помощью следующей команды tcpdump.|root@redeye:[~]> tcpdump -i lo -vv not arp -w x11_trace.pcapngДалее, сам файл можно открыть в Wireshark и отфильтровать просмотр по протоколу
x11. Обычно для сбора трафика нужны привилегии root.
Рис. 4 Сетевой след соединения X11 в WireShark.
То же самое и во всех подробностях можно увидеть в tshark в текстовом формате. Так выглядит клиентский запрос X11 в сторону сервера.
Frame 11: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits)
Encapsulation type: Ethernet (1)
...
[Protocols in frame: eth:ethertype:ipv6:tcp:x11]
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)
Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
...
Internet Protocol Version 6, Src: ::1, Dst: ::1
0110 .... = Version: 6
...
Transmission Control Protocol, Src Port: 49202, Dst Port: 6010, Seq: 1, Ack: 1, Len: 48
Source Port: 49202
Destination Port: 6010
...
X11, Request, Initial connection request
byte-order: 0x6c (Little-endian)
unused
protocol-major-version: 11
protocol-minor-version: 0
authorization-protocol-name-length: 18
authorization-protocol-data-length: 16
unused
authorization-protocol-name: MIT-MAGIC-COOKIE-1Пакет с ответом со стороны X-сервера совсем не так лаконичен, в нем указаны все необходимые детали для форматирования графического вывода на экран.
Frame 13: 14698 bytes on wire (117584 bits), 14698 bytes captured (117584 bits)
Encapsulation type: Ethernet (1)
...
[Protocols in frame: eth:ethertype:ipv6:tcp:x11]
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Destination: 00:00:00_00:00:00 (00:00:00:00:00:00)
Address: 00:00:00_00:00:00 (00:00:00:00:00:00)
...
Internet Protocol Version 6, Src: ::1, Dst: ::1
0110 .... = Version: 6
...
Transmission Control Protocol, Src Port: 6010, Dst Port: 49202, Seq: 1, Ack: 49, Len: 14612
Source Port: 6010
...
X11, Reply, Initial connection reply
success: 1
unused
protocol-major-version: 11
protocol-minor-version: 0
replylength: 3651
release-number: 12011000
resource-id-base: 0x0b200000
resource-id-mask: 0x001fffff
motion-buffer-size: 256
length-of-vendor: 20
maximum-request-length: 65535
number-of-screens-in-roots: 1
number-of-formats-in-pixmap-formats: 7
image-byte-order: 0x00 (LSBFirst)
bitmap-format-bit-order: 0x00 (LSBFirst)
bitmap-format-scanline-unit: 32
bitmap-format-scanline-pad: 32
min-keycode: 8
max-keycode: 255
unused
vendor: The X.Org Foundation
pixmap-format
pixmap-format
...
pixmap-format
...
screen
screen (000007a4: 1920 x 1080 x 24)
root: 0x000007a4
default_colormap: 0x00000020
white_pixel: 0x00ffffff
black_pixel: 0x00000000
current_input_masks: 0x00fa8033
width_in_pixels: 1920
height_in_pixels: 1080
width_in_millimeters: 451
height_in_millimeters: 254
min_installed_maps: 1
max_installed_maps: 1
root_visual: 0x00000021
backing_stores: 0x01
save_unders: False
root_depth: 24
allowed_depths_len: 7
depth-detail
depth-detail
depth: 24
unused
visualtypes-numbers: 576
unused
visualtype
visualtype
...
visualtype
...
visualtype
...
▍ Удаленное подключение к X-серверу по ssh
Переходя от теории сетевых взаимодействий X Window System к практике, рассмотрим, как запустить графическое приложение на уделенном X-сервере при подключении по ssh.
|admin@redeye:[~]> ssh -X my.remote.host
|admin@redeye:[~]> ssh -Y my.remote.host- Подключение необходимо запускать с ключом
-X, который активирует переадресацию X11. На практике, однако из-за X11 SECURITY extension это часто не работает. В таких случаях используют-Yдля подключения с доверительной переадресацией X11. - Убедитесь, что на удаленном сервере установлен пакет
xauth, который создаст файл~/.Xauthorityy. Если все нормально, то файл уже создан и проверка показывает на наличие MAGIC COOKIE.
|admin@redeye:[~]> xauth list
host/unix:0 MIT-MAGIC-COOKIE-1 00000000000000111111111111111111- Имеет смысл в качестве проверки иксов выполнить xclock прежде, чем запускать JAVA installer, или мастер настроек некоей корпоративной CRM, или ERP системы. Если показалось окно xclock, то соединение с X-сервером работает как надо.
Рис. 5 Собственно xclock, значит удаленные иксы настроены и работают.
- Если после логина по ssh была выполнена команда смены пользователя
sudo su -для перехода в root, то тогда необходимо выставить переменную DISPLAY. Этого не надо делать, если используется изначальный пользователь и сеанс shell.
|admin@redeye:[~]> export DISPLAY=:0
echo $DISPLAY
:0Я стараюсь по мере возможности тестировать сеанс Wayland при каждом новом релизе KDE Plasma, несмотря на многочисленные улучшения с каждым разом, на версии kde-apps-21.04.3 работать можно лишь на Plasma-X11. В чем бы не состояли преимущества Wayland, до тех пор пока в терминале зависает команда man, хаотично прыгают элементы ниспадающего меню и блуждает внешний монитор, старый и добрый X Window System остается вне конкуренции. Надеюсь так не будет продолжаться долго.
▍ Для дополнительной информации
- X Window system internals
- Can't start X11 applications after su...
- Xterm cannot open display?
- Xlib — C Language X Interface
Комментарии (56)
event1
26.08.2021 19:25-1Речь идет об IPv4 и X11. Если первый из них практически во всех аспектах уступает IPv6,
Дальше читать не стал. Даже неискушённому читателю должно быть очевидно, что если и за 25 лет IPv6 так и не вытеснил IPv4, то не настолько он и лучше.
thatsme
26.08.2021 23:20+1У IPv6 страшный длинный адрес, не предназначенный для запоминания админом... Т.к. его внедрение "долгое и упорное", никак не станет массовым, уровень отлаженности стэка в разных фирмварях и осях очень разный, что не способствует дальнейшему продвижению. Странно, но в линуксе стэк IPv6 на удивление шустрый. Данных сейчас нет, в прошлом году очень удивился, что при переходе на IPv6 скорость значительно выросла (возможно это не от того, что IPv6 шустрый, а от того, что для него firewall-ов в сети настроено небыло, докапываться до причин тогда времени небыло). Со стороны программиста разница минимальная.
nullc0de
27.08.2021 00:13+3Тут уже было отвечено по поводу IPv6 и его внедрению habr.com/ru/company/ruvds/blog/574266
IPv6 быстрее по двум основным причинам:
1. Из заголовка пакета убрали контрольную сумму, она не нужна и довольно дорогая операция. Расчет контрольный суммы и его сверка переложена с протокола на клиент-серверное ПО. Контрольная сумма есть на канальном уровне, и сетевые устройства сверяют ее, незачем контрольная сумма на сетевом уровне, только лишняя дублирующая операция и нагрузка на железо.
2. Не нужен NAT. NAT создает довольно большую нагрузку на оборудование.
IPv6 на оборудование создает минимум на 30% меньше нагрузку на оборудование, отсюда меньше задержки.
У меня лично большая часть трафика по IPv6 ходит.event1
27.08.2021 13:06Из заголовка пакета убрали контрольную сумму
В принципе вы правы, но на практике CRC считается на стороне железки и не стоит, практически ничего
Не нужен NAT. NAT создает довольно большую нагрузку на оборудование.
Не совсем так. Дело в том, что NAT состоит из двух частей: отслеживание соединений (conntrack в линуксе) и собственно трансляция адресов. Нетрудно догадаться, что отслеживание соединений куда более дорогая операция, чем трансляция. Ведь надо хранить собственно таблицу соединений и на каждый пакет бегать по ней. Так вот, отслеживание соединений всё-равно нужно, потому что мы не хотим пускать к пользователю любой мусор из интернета, имеющий адрес пользовательского терминала в своём пакете. Через это самая дорогая часть NATа останется с нами и в новом ipv6 мире, только теперь адреса там будут в 4 раза длиннее.
nullc0de
27.08.2021 13:39но на практике CRC считается на стороне железки
Не правильно. Одно дело когда мы считаем пару раз в секунду, используем таблицы для ускорения, но другое дело когда поток пакетов большой, он уже создает заметную нагрузку.Дело в том, что NAT состоит из двух частей: отслеживание соединений (conntrack в линуксе) и собственно трансляция адресов.
Опять не совсем правильно. В IPv6 мы можем уменьшить количество промежуточных узлов, тем самым тоже уменьшить задержки. Изучайте стандарт. На нагруженных роутерах пропускную способность на практике удается повысить где-то на 30%. 30% это существенная экономия на оборудовании при масштабировании. В интернете можно найти графики крупных компаний, где показаны преимущество IPv6. Если не верите графикам, возьмите просто iperf и прогоните тест.
IPv6 не дураки придумали и самое главное он развивается, и есть кучу улучшений.event1
27.08.2021 13:55+1Не правильно. Одно дело когда мы считаем пару раз в секунду, используем таблицы для ускорения, но другое дело когда поток пакетов большой, он уже создает заметную нагрузку.
Но происходит это внутри сетевой карты, так что всем плевать.
В IPv6 мы можем уменьшить количество промежуточных узлов, тем самым тоже уменьшить задержки
Да пожалуйста. Но причём тут NAT?
kemm
28.08.2021 00:05+1В принципе вы правы, но на практике CRC считается на стороне железки и не стоит, практически ничего
Вы не путаете с чексуммой канального уровня? Я что-то не помню, чтобы карты считали чексуммы в IP самостоятельно… См., например, arch/x86/include/asm/checksum_64.h в линуксе (ip_fast_csum)
event1
28.08.2021 01:19+1Конечно по стандарту карты должны считать только суммы в датаграммах канального уровня. Однако, на практике, в современных картах столько мощи, что они могут делать всякое. Бывают даже встроенные ПЛИС для предобработки. Но это если по-дорогому. В обычных картах есть всякие техники известные под общим термином offload. В линуксах можно настроить/посмотреть с помощью
ethtool -k.Например, на моей ( Marvell 88E8072 PCI-E Gigabit Ethernet Controller) вот так:event@tosh ~ $ ethtool -k enp7s0 Features for enp7s0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: on tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [fixed] tx-tcp-mangleid-segmentation: off tx-tcp6-segmentation: off [fixed] generic-segmentation-offload: on generic-receive-offload: on large-receive-offload: off [fixed] rx-vlan-offload: on tx-vlan-offload: on ...rx-checksumming — это как раз проверка контрольной суммы входящих пакетов. Причём, по-моему, она протоколы 4-го уровня тоже проверяет сразу
Sheti
12.09.2021 16:23раньше дешевые сетевые карты всё на процессор складывали. В случае сетевого шторма ПК вис из-за обработки пакетов. Лично наблюдал сие чудное явление. При этом на ПК с более умными сетевухами всё было отлично.
event1
27.08.2021 13:21+1Можно перечислять много особенностей и практически ни одну нельзя будет назвать однозначно позитивной: длинный адрес — трудно запомнить, ограничения на MTU — "а как посылать маленькие пакеты?", нет широковещания — "аналог ping 255.255.255.255?". Вместо простых и привычных ARP и DHCP, в ipv6 NDP, ICMPv6 и (иногда) DHCPv6. Единственное, что практически однозначно хорошо — убрали контрольные суммы. Достаточно тех что есть на канальном уровне и в протоколах верхних уровней. Но это улучшение, в общем-то незначительное.
По-этому внедрение и идёт черепашьими темпами.
nullc0de
27.08.2021 13:44+2Вы пишете полный бред. IP адреса в здравом уме никто не запоминает. Даже в локальной сети все к серверам обращаются по имени. Роутеры и промежуточные узлы, зачастую имеют короткую форму в IPv6, которую запомнить не сложнее IPv4. Внедрение стопорится больше из-за мифов, типа тех, что распространяете вы и из-за безграмотности людей, и их психологических проблем.
Скажи, насколько сложно запомнить?2606:4700:4700::64
2606:4700:4700::6400event1
27.08.2021 14:02+1IP адреса в здравом уме никто не запоминает
Вы излишне категоричны. Если никто из вашего окружения не запоминает, это не значит что никто вообще не запоминает. Да и вы сами, наверняка, знаете, что такое 8.8.8.8 или 1.1.1.1, но не знаете их ipv6 аналогов.
Внедрение стопорится больше из-за мифов, типа тех, что распространяете вы и из-за безграмотности людей, и их психологических проблем.
То есть, необходимость покупки провайдероми нового оборудования и разработки стратегии миграции при отсутствии внятного выхлопа — это фигня. А вот "мифы" — это да. Настоящая проблема.
nullc0de
27.08.2021 14:09То есть, необходимость покупки провайдероми нового оборудования и разработки стратегии миграции при отсутствии внятного выхлопа — это фигня. А вот «мифы» — это да. Настоящая проблема.
Какое новое оборудование? Даже старое оборудование поддерживает IPv6. Вы же сами писали, что протоколу 25 лет. По вашему за 25 лет в оборудование не смогли завезти IPv6? Мы гоняли IPv6 еще в 2004 году…event1
27.08.2021 14:23+1Ну, у себя дома вы могли гонять всё что угодно. У провайдеров другая история: оборудование дорогое, меняют его редко, а перенастраивать никто не любит, потому что дорого и простои. По-этому, кое-где присутствуют системы без поддержки ipv6. Может на коммутаторах этой проблемы и нету, но кроме коммутаторов, там куча всякого разного. Представляете, мы такие модные и молодёжные переехали на ipv6 а у нас биллинг сломался. Или аналитика. Будет обидно.
Sheti
12.09.2021 12:51Тут скорее "перенастраивать не любит". Потому что мне сложно себе представить провайдера у которого за 25 лет оборудование не поменялось нигде.
Starwalker
27.08.2021 15:20Да и вы сами, наверняка, знаете, что такое 8.8.8.8 или 1.1.1.1, но не знаете их ipv6 аналогов
Запомнить труднее, но все же можно: 2001:4860:4860::8888 ; 2606:4700:4700::1111
Вопрос тут в другом - а зачем?
event1
27.08.2021 15:45+1ping 8.8.8.8 — это самый простой и надёжный способ проверить, подключена ли система к интернету. Эту команду легко запомнить и легко передать. Даже по телефону, даже непрофессионалу, даже если и мой и его английский оставляют желать лучшего.
nullc0de
27.08.2021 16:21Совсем с памятью плохо, что сложно запомнить 2606:4700:4700::64? Так память надо развивать, чтобы в старчестве снизить риск болезни паркинсона.
Starwalker
27.08.2021 18:05+2Давайте мух от котлет отделим.
Во-первых, 'ping 8.8.8.8' это несерьезно. Ну да, удобно. Но тогда уж давайте 'ping ok.ru' раз мы скатились на этот уровень ;-) Мы так и DNS заодно проверим. А вот мне интересно, вот говорите вы по телефону "плиз, тайп пинг, спейс, зен ейт дот ейт дот ейт дот ейт енд прес ентер... йес, зэт биг батон он зе райт сайд оф ьор кейборд, мэм". Ну тетка такая "Request timed out". И что? О чем это говорит? Возможных проблем - тьма. Куда копать в начале? Почему именно туда? Это в корне неверный подход, потеря времени. Легче просто спросить "фейсбук открывается?". Если нет, тогда начинать уже нормальный траблшутинг - ARP (ND для IPv6), routing table, traceroute, nslookup...
Во-вторых, а что ' ping -6 google.com' это как-то сложнее? Ну или 'traceroute -6 google.com'? Скажете "А если проблема с DNS?" Ну так и ошибка же будет "Name or service not known", сразу поймете что к чему. Да и nslookup в помощь.
Я к чему клоню - у вас привычки, которые вы не хотите менять и которые мешают вам работать с IPv6 сетями.
event1
27.08.2021 19:53В вашем юзкейсе это действительно не важно. В каком-то другом это может быть удобно. Я же не утверждаю, что это прямо самая важная возможность при отладке сетей. Но, иногда это удобно. Особенно если DNS-а нет и не предполагается.
Starwalker
27.08.2021 20:31+1Если позволите, я дам один непрошеный совет - никогда не стройте IPv6 сети без DNS. Это крайне не рекомендуется. Понимаю, что иногда это кажется избыточным, но человеку почти невозможно запомнить IPv6 адрес (если только его специально не сделали легко запоминающимся). Поэтому можно колхозить и выдумывать легкие адреса для loopback интерфейсов сетевых устройств, но сами понимаете, это не масштабируется на все use cases.
nullc0de
27.08.2021 20:37+2Starwalker так даже с IPv4 без DNS строить сеть это перебор, даже в страшном сне себе не могу представить ситуацию, когда мне надо будет запоминать IPv4 адреса: 172.20.77.36 Главбух, 172.22.38.65 — Генеральный директор и т.д… Мне приходилось работать в компаниях с 3000+ сотрудников. Даже если компьютеров всего 100 будет в сети их не запомнить!
Starwalker
27.08.2021 21:00+2Я сетевик, в основном на хосты не лажу, но согласен, DNS решает. Кстати, один раз наблюдал забавное. Огромная корпорация, новый датацентр готовится к запуску в продакшн, идут тесты. Что-то где-то не сходилось, не помню уже, но вроде EVPN на некоторых Leaf работал не так, как нужно. Ок, мы (саппорт вендора) с одной стороны, консультант, ответственный за сеть с другой. Ну вобщем запись сессии, все контролируется, пришлось через его комп лезть. Чтоб он видел что и почему мы делаем. Банальшина, нужен SSH к пятку устройств. Говорю ему: "давай, брат, нам доступ вот к этим устройствам... "
Увиденное превзошло все ожидания. Вобщем картина маслом - топология сети в Visio, на ней из полезной информации только хостнеймы устройств. Консультатнт находит в визио хост, копирует его хостнейм. Затем лезет в одну Excel таблицу, там в хреновой туче вкладок находит вкладку - таблица с айпишниками лупбеков и хостнеймами, ищет запись, копирует айпишник. Ок, открывает терминал. SSH, Ctrl+V, Enter. Коммутатор просит юзернейм и пароль. Консультант открывает опять какие-то Excel таблицы, там уже находит пароль, вводит... И так для каждого коммутатора.
Вот люди со стальными шарами - не ленятся как некоторые с такаксами да радиусами - отважно пароли хранят в эскеле... DNS себе ручной придумали через Excel. А вы тут разленились, 100 айпишников не хотите запомнить ;-)
P.S. Надеюсь перед запуском в продакшн там прошелся безопасник и каленым железом выжег это все. Но опыт подсказывает, что не факт ;-)
event1
27.08.2021 22:10да, боже упаси меня вообще строить сети. Я ж программист, а не сетевик. Это клиенты проклятые. Думают, если сеть IoT, то DNS и не нужен. Там же людей нет, правильно? Я бы и рад им сказать: "ну раз вы такие дураки, то мы с вами бизнес не будем делать!" Но, меня за такое лишат довольствия, а мне без довольствия никак нельзя.
Starwalker
27.08.2021 22:23Ну раз программист, тогда mDNS хотя бы. Тут, как говорится, уже все в ваших руках, так как реализация сего добра исключительно на клиентах.
Но он работает в рамках одного VLAN, если не городить на роутерах mDNS gateway ну или полноценную маршрутизируемую мультикаст сеть с PIM'ом и Join'ами ;-)
Starwalker
27.08.2021 15:18+1если и за 25 лет IPv6 так и не вытеснил IPv4, то не настолько он и лучше
Как-то сомнительно звучит, как аргумент. Проблемы с имплементацией IPv6 вначале были в кривой поддержке протокола ASIC'ами. Сейчас все уже давно работает в line-rate, особых проблем с поддержкой IPv6 на нормальном оборудовании не встречал. На данном этапе проблема с внедрением IPv6 одна - люди.
Люди, которые привыкли запоминать айпишники.
Люди, которые "ниасилили" разные виды IPv6 адресов и им физически больно от отсутствия RFC1918 адресов в их уютной сеточке.
Люди, которые не могут поднять нормальный DNS в сети.
Люди, которые думают, что NAT это такой инструмент обеспечения безопасности.
Я могу долго перечислять все проблемы, но root cause всегда один - человек.Выход - "бесчеловечные" сетки вроде всяческих SDN. Возможно, после их повсеместного внедрения ситуация с IPv6 изменится в лучшую (для прогресса) сторону.
event1
27.08.2021 16:04<sarcasm> Повсеместное внедрение линукса на десктопе тормозится из-за людей. Эти глупые пользователи просто не могу выучить несколько десятков простых команд и почему-то недовольны прекрасным чёрным терминалом с красивыми зелёненькими буквами </sarcasm>
Люди следуют первому правилу инженера: не надо чинить то, что работает. Если выгоды от внедрения меньше чем затраты на него, разумно и правильно от внедрения отказаться.
nullc0de
27.08.2021 16:16+1Это не правило инженера, это правило плохого специалиста, который не уверен в своих силах. Инженеры создали IPv6 для решения существующих проблем безопасности и производительности. И эти люди на голову умнее и опытнее вас, сотрудничают с трансмагистральными компаниями и спонсируются ими для решения существующих проблем. Садитесь опять двойка!
event1
27.08.2021 16:27Это, кстати, распространённая ошибка начинающих инженеров: мол сетевые протоколы, прошивки и ядра операционных систем разрабатываются некими магическими супер-программистами с двумя головами. На самом деле, там работают точно такие же обычные люди как мы с вами.
Starwalker
27.08.2021 17:49Как типичный представитель фриков "btw, I use Arch" чуть не бомбанул, спасибо за теги ;-)
Смотрите, что затратнее по-вашему - CG-NAT или IPv6 dual-stack? Кстати, сам я ответа не знаю, но CG-NAT вызывает рвотный рефлекс даже в виде схемы, как это чудо поддерживается провайдерами даже знать не хочу, надеюсь им больно. Вот скажите мне, чем можно объяснить неготовность провайдера городить NAT64 (что задумывалось как временное решение пока не перейдем на IPv6-only) но пионерское "Всегда готов!" городить это уродство CG-NAT, без сомнения являющееся тупиком? Вот в чем различие кроме неграмотности сетевиков?
На мой взгляд сейчас есть проблема с дуал-стеком. На самом деле неприятно поддерживать 2 протокола, особенно если IPv6 мало пользуются. Я понимаю это, все же ресурсы ограничены и во многих коммутаторах ресурсы делятся между IPv4 и IPv6. Естественно нужно оправдание использования этих ресурсов под дополнительный протокол, без которого (будем честны) пока еще жить можно.Есть большие провайдеры, которые до сих пор для домашних потребителей не внедрили IPv6 и никто не чешется, никто не требует его внедрения. Замкнутый круг. IPv6 не используется, потому что многие провайдеры его не поддерживают. Провайдеры его не поддерживают, потому что IPv6 не используется.
Но все же есть огромное психологическое неприятие IPv6 среди сетевиков, которые не привыкли к нему и не хотят меняться. Этот протокол им непонятен, некомфортен. Но если бы они вникли хоть немного, возможно что-то бы изменилось. А то, что вникать не хотят, это я знаю не понаслышке. Ну например когда вижу в сети OSPFv2 и OSPFv3 работающие параллельно. Зачем? Ну как, v2 для IPv4, v3 для IPv6 ... Шапито... :-D
nullc0de
27.08.2021 17:59Starwalker так все магистральные провайдеры его уже давно поддерживают, все уперлось в последнюю милю. Притом с каждом годом доля IPv6 растет во всем мире. Проблема внедрения сугубо психологическая. Протокол даже в чем-то проще IPv4. Но люди привыкли себе придумывать несуществующие проблемы на ровном месте, когда их нет. Сами не знают IPv6, но зато столько мифов про IPv6 могут рассказать.
Starwalker
27.08.2021 18:07Подписываюсь под каждым вашим словом, я именно это и пытаюсь коллеге объяснить. Все дело в закостенелых и ленивых сетевиках. Технически уже нет никаких проблем, даже на last mile, даже с клиентскими устройствами. Уже по-моему любой чайник поддерживает IPv6...
Sheti
12.09.2021 13:01цена на IPv4 адреса в конце концов сломает спину слона. Времена когда ещё была WinXP и теоретически могли быть проблемы давно прошли. Большинство клиентов провайдера сами не настраивают роутеры, а те кто настраивают могут и в IPv6. Так что остаётся только одна проблема - лень менять пока стоимость владения остаётся приемлемой.
event1
27.08.2021 21:20Смотрите, что затратнее по-вашему - CG-NAT или IPv6 dual-stack?
Если CG-NAT уже есть, а DS надо строить? Тогда DS затратнее.
Но все же есть огромное психологическое неприятие IPv6 среди сетевиков, которые не привыкли к нему и не хотят меняться
Вот представьте, что я техдир какого-нибудь провайдера на миллион абонентов. И я, прям борец за IPv6. И вот, я прихожу в совет директоров и говорю, мол ребята, есть охренительная штука: новая версия IP-протокола. Там новые технологии, 21ый век и вообще всё отлично. Даже гугл рекомендует. Тогда совет директоров мне и говорит: "а сколько это стоит?". Я прикинул расходы на замену оборудования, обучение персонала и т.п. и такой говорю уверено: "лям!". А совет мне в ответ: "а сколько мы на этом заработаем? Будет ли у нас больше пользователей, или сможем ли мы повысить абонентскую плату". А я, такой: "нет не будет и не сможем. Пользователям всё равно какая версия IP протокола работает в их сетях. Они и слов таких не знают". А совет мне и отвечает: "не дадим мы тебе денег. Не нужен нам IPv6. Лучше будем ретроградами, но с лямом".
Starwalker
27.08.2021 21:43Логика неправильная, скорее всего новое оборудование не понадобится.
Хотя сама ситуация типичная, спорить не буду. Именно из за нее, как я уже упоминал, у многих даже больших провайдеров нет IPv6 для домашних потребителей. Замкнутый круг. Хотя есть надежда - в один момент айпишники закончатся, юзверей, которые хотят "белый" адрес станет много. Тогда может что-то поменяется. Жаль, конечно, потому что сама технология вполне ничего, много интересных идей. В том числе для провайдеров. К примеру идея о том, что next-hop не должен быть global unicast address. Сколько лет провайдеры лепили эти вечные 'ip unnumbered' на внутренних линках. Или даже IS-IS вообще без айпишников на линках. А тут тебе "искаробки" next-hop на link-local соседа. Суммаризация маршрутов на IPv6 - песня. Адресов - хренова туча, поэтому таблица маршрутизации может быть меньше на несколько порядков. Если только конечно сети не планировались заклятыми "четверочниками", которые делят /64 на сабнеты :))))
event1
27.08.2021 22:25даже если не понадобится именно оборудование, то надо будет обучить персонал или хотя бы переписать скрипты для индусов из поддержки, надо будет переписать конфиги, надо будет починить падения после переписывания конфигов. Всё это выльется в какую-то сумму.
С другой стороны, внедрение, конечно движется по-тихонечку. Но очень неспешно. У меня, например, ipv6 распространяется путём письма провайдеру с просьбой переключить на ipv6. Там DS-lite. В мобильных сетях у нас, да и в Европе (за исключением Германии) ipv6 пока редкий гость.
romancelover
27.08.2021 23:16Не такой уж и редкий, во многих странах (даже в России) есть IPv6 хотя бы у одного крупного оператора. Смотрел в регионе "Восточная Европа" на stats.labs.apnic.net/ipv6.
В России и Беларуси у МТС, в Польше - Orange, в Чехии O2 и Vodafone, в Венгрии Magyar Telekom / Vodafon / Telenor, в Румынии Digi. Только на Украине и в Болгарии всё плохо с IPv6.
Sheti
12.09.2021 13:06оборудование менять не придётся, а так же будет выигрыш от меньшей нагрузки на оборудования. Это не говоря о том, что можно будет выкинуть на свалку истории провайдерский NAT. А я даже боюсь представить стоимость такого NAT даже для городского провайдера средней руки при современных то нагрузках и потоковом видео.
event1
12.09.2021 16:12Как уже указывалось выше, самая толстая часть NAT — connection tracking — никуда не денется. Провайдеры просто не могут открыть конечных пользователей в дикий интернет. Кроме того, само отслеживание будет дороже, из-за более длинных адресов: раньше ключ (два адреса и два порта) в таблице соединений был 12 байт, а теперь 68 байт. Это 3 линии кэша, если что.
Sheti
12.09.2021 16:16Это почему провайдеры не могут выпустить пользователей? Достаточно примитивнейшей настройки фаервола, чтобы отрубить большинство ботов. А в остальных случаях NAT не поможет.
event1
12.09.2021 16:52Достаточно примитивнейшей настройки фаервола, чтобы отрубить большинство ботов
Да, она называется "запретить инициировать соединения снаружи вовнутрь". Но чтобы её реализовать нужно отслеживать соединения
temujin Автор
05.09.2021 12:21Сеанс KDE на базе Wayland признан стабильным. Жду, когда появится на Генте.
13werwolf13
есть у "иксов" много того чего "вяленый" не умеет и не факт что научится. кроме сетевой работы можно ещё упомянуть мультисит, один комп, одна система, два юзверя, у каждого свой монитор и "клавамышь". на иксах это реализуется редактированием одного конфига (вроде даже на одной видеокарте можно), а вот в вяленом единственное решение это две видюхи одна из которых прокинута в виртуалку в которой стоит отдельная ОС.
щас кто нибудь напишет что это ненужно в 21 веке и закидает меня минусами конечно, но я сторонник идеи что лучше иметь возможность и не использовать её чем не иметь возможности когда она понадобится.
Ritan
8 лет назад это было возможно, а сейчас нет? Звучит неправдоподобно
https://www.reddit.com/r/linux/comments/1fk6wf/multiple_seat_support_on_wayland/
Просто это всё вынесено из сервера в клиенты
13werwolf13
как-то странно видео выглядит.. почему окна на одном экране.. что за..
rPman
к сожалению на одной видеокарте просто не получится, решение там — запустить второй x-сервер xephyr, работающий в окне первого
но да, при использовании двух видеокарт все очень и очень просто
Tarik02
Wayland не ограничивает эту возможность. Он просто отдает необходимость реализации этого функционала в реализацию сервера.
13werwolf13
Речи про "ограничивает" и не шло. Просто пока не реализовано..