Алексей Федорчук

В самом первом очерке о Void Linux были сформулированы две претензии к этому дистрибутиву. К первой, касающейся шрифтов, я вернусь как-нибудь в другой раз, своевременно или несколько позже. А вот про вторую, связанную с загрузкой браузеров, речь пойдёт сейчас. Итак, цитирую указанный очерк:

все они (в Live-режиме — в Firefox’е, но после установки она же обнаружилась и в Pale Moon’е, и в Midori) грузятся не медленно, и не очень медленно, а медленно до невероятности. Всегда и везде: и в обычном Live-режиме, и в Live-режиме из оперативной памяти, с установки в виртуальной машине и на реальном HDD. И даже в системе инсталлированной на быстрый SSD, они всё равно грузятся медленно.

И не только при первом запуске, а при любом последующем, когда, казалось бы, весь контент мог бы и скешироваться. И касается это не только браузеров: чрезвычайно долго устанавливалось соединение в IM-клиентах (конкретно — в Pidgin’е и в Empathy). Наконец, задержка обнаруживалась при пинге, где её оказалось возможным оценить количественно при сравнении команд ping [имя сервера] и ping IP-адрес: в первом случае начало процесса было на порядок больше, чем во втором.

Причём что интересно: это касалось моего первого и главного провайдера, через которого я выхожу в сеть и с десктопа (по кабелю), и с Нотебучки (по WiFi). Когда же последнюю я переключал на роутер, подсоединённый ко второму провайдеру, всё происходило с совершенно нормальной скоростью.

И ещё интересный момент относительно первого провайдера: отмеченные задержки пинга имели место быть только в отношении заграничных серверов, например, google.com. Если же аргументом команды ping задавалось что-то вроде www.ru или yandex.ru, никаких задержек не было и в помине. В причины этого явления я здесь вдаваться не буду — о них можно только догадываться…

Кстати, назову обоих провайдеров, ибо страна должна знать своих героев. Имя первого — Ростелеком, известный под псевдонимом OnLime, второй же в девичестве звался МГТС, а сейчас — не помню как. И, если кто не в курсе, дело происходит в столице нашей Родины, известной также как Нерезиновая.

После проверки на вшивость второго провайдера стало ясно, что дело упирается в провайдера первого. Точнее, в сочетание настроек его DNS-сервера с таковыми дистрибутива Void Linux — ни в одном из других дистрибутивов, установленных (или устанавливаемых) на моих машинах со времён переключения на OnLime, ничего подобного не наблюдалось. И решений проблемы я видел несколько, но перечислять их не буду: ни одно из них меня не устраивало даже на 50% (вот здесь объясняется, что это значит).

И тут Станислав Шрамко aka stanis надоумил меня установить и настроить пакет dnsmasq, про который в Википедии сказано так:

Dnsmasq — легковесный и быстроконфигурируемый DNS-, DHCP- и TFTP-сервер, предназначенный для обеспечения доменными именами и связанными с ними сервисами небольшие сети.

При помощи Станиса я проделал эту процедуру, которая дала результат вполне превосходный. Каковой в рецептурном виде и описывается далее.

Первый пункт рецепта — поиск и установка пакета:

$ xbps-query -R -s dnsmasq
[-] dnsmasq-2.75_1 Lightweight, easy to configure DNS forwarder and DHCP server
$ sudo xbps-install -S dnsmasq-2.75_1 Lightweight

Пункт второй — правка конфигов /etc/dhclient.conf и /etc/dnsmasq.conf. В первый добавляется одна строка:

$ sudo echo 'supersede domain-name-servers 127.0.0.1;' >> /etc/dhclient.conf

В /etc/dnsmasq.conf требуется добавить аж три строки:

$ sudo echo 'server=8.8.8.8\nserver=8.8.4.4\nlisten-address=127.0.0.1' >> /etc/dnsmasq.conf

Разумеется, обе эти процедуры можно проделать и в текстовом редакторе от лица администратора. После чего остаётся только запустить сервис dnsmasq, помятуя о том, что система инициализации в Void Linux — не sysvinit, и даже не systemd, а вовсе runit, подробный разговор о которой предстоит в светлом будущем в (не очень, надеюсь) отдалённой перспективе. А пока — третий пункт рецепта:

$ cd /var/service
$ sudo ln -s /etc/sv/dnsmasq /var/services/

Теперь следует рестарт системы и проверка того, что получилось. А получиться должно следующее. Файл /etc/resolv.conf приобретает такой вид:

search OnLime_router
nameserver 127.0.0.1

А ответ на команду

$ sudo fuser 53/tcp

будет примерно таким:

53/tcp:                722

Задержки при пинге по IP и имени сервера должны примерно сравняться:

$ ping -c 3 8.8.8.8 && ping -c 3 google.com
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=3.31 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=3.13 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=3.13 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.130/3.192/3.312/0.106 ms
PING google.com (173.194.122.197) 56(84) bytes of data.
64 bytes from 173.194.122.197: icmp_seq=1 ttl=57 time=3.49 ms
64 bytes from 173.194.122.197: icmp_seq=2 ttl=57 time=3.12 ms
64 bytes from 173.194.122.197: icmp_seq=3 ttl=57 time=3.19 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.124/3.269/3.491/0.172 ms

Ну и главная проверка — практикой, жизненным опытом: браузер должен запускаться с такой скоростью, с какой ему и положено это делать с быстрого SSD.

Не знаю, подойдёт ли приведённое решение абонентам других провайдеров. Но, мне кажется, оно по крайней мере указывает направление, в котором следует копать (да и сам dnsmasq — штука как минимум не вредная). За что выражаю Станису свою искреннюю признательность — без него я ни в жизни не определил бы направления этой канавы. И пришлось бы удовлетвориться пятидесятипроцентным решением.

Оглавление