Переменные ядра Linux в sysctl

Thank you for reading this post, don't forget to subscribe!

Sysctl поз­во­ля­ет вно­сить изме­не­ния в рабо­та­ю­щее ядро Linux. Рас­смот­рим неко­то­рые пере­мен­ные ядра Linux в sysctl в этой статье.

> net.ipv4.conf.default.forwarding=1

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

> fs.file-max = 64000

Мак­си­маль­ное зна­че­ние откры­тых фай­лов. Что бы его узнать, выполните
коман­ду cat /proc/sys/fs/file-max

> net.ipv4.conf.all.rp_filter = 1

Эта пере­мен­ная сооб­ща­ет ядру о необ­хо­ди­мо­сти филь­тра­ции паке­тов по их исхо­дя­ще­му адресу.

> kernel.sysrq = 0

Отклю­ча­ет­ся ком­би­на­ция кла­виш sysrq, кото­рая исполь­зу­ет­ся при крахе
системы.

> net.ipv4.conf.default.rp_filter=1

Фильтр обрат­но­го пути (когда пакет при­хо­дит с одно­го интер­фей­са, а
ухо­дит на другой)

> net.ipv4.conf.all.accept_source_route = 0

Марш­ру­ти­за­ция от источ­ни­ка (source routing) поз­во­ля­ет отправителю
опре­де­лить путь, по кото­ро­му пакет дол­жен прой­ти по сети Internet, чтобы
достиг­нуть пунк­та назна­че­ния. Это очень удоб­но для изу­че­ния и отладки
рабо­ты сети, но нару­ши­тель полу­ча­ет воз­мож­ность под­ме­ны адресов
ком­пью­те­ров локаль­ной сети. 0 озна­ча­ет, что марш­ру­ти­за­ция отклю­че­на, 1 —
наоборот.

> net.ipv4.tcp_syncookies=1

Разрешает/запрещает пере­да­чу так назы­ва­е­мых syncookies вызы­ва­ю­ще­му хосту
в слу­чае пере­пол­не­ния оче­ре­ди SYN-паке­тов для задан­но­го соке­та. Когда в
систе­му посту­па­ет слиш­ком мно­го запро­сов на соеди­не­ние, то оче­редь может
пере­пол­нить­ся и тогда запус­ка­ет­ся пере­да­ча syncookies в ответ на каждый
SYN-запрос. Эта пере­мен­ная исполь­зу­ет­ся для предот­вра­ще­ния syn-flood
атак. Пере­мен­ная может при­ни­мать два зна­че­ния 0 (выклю­че­но) и 1
(вклю­че­но). Зна­че­ние по-умол­ча­нию 0 (выклю­че­но). Эта функ­ция будет
рабо­тать толь­ко в том слу­чае, если ядро собра­но с опцией
CONFIG_SYN_COOKIES.

(прим. перев.) В про­шлом было мно­го дис­кус­сий по пово­ду про­блем и
недо­стат­ков, свя­зан­ных с syncookies. Лич­но я рас­смат­ри­ваю эту
воз­мож­ность как доста­точ­но удоб­ную и без­опас­ную. Одна­ко, в некоторых
слу­ча­ях, исполь­зо­ва­ние этой опции может пред­став­лять неко­то­рую угрозу,
см. ниже. Опция tcp_syncookies под­ра­зу­ме­ва­ет, что на систе­мах с высокой
нагруз­кой новые соеди­не­ния будут уста­на­ли­вать­ся без таких фишек, как ECN
и SACK. Если пере­да­ча syncookies сра­ба­ты­вет при невы­со­ких нагруз­ках, то
вам сле­ду­ет под­кор­рек­ти­ро­вать пара­метр, зада­ю­щий дли­ну оче­ре­ди. Не
сле­ду­ет исполь­зо­вать эту воз­мож­ность на систе­мах с высо­кой нагрузкой.
Если в систем­ный жур­нал посту­па­ют пре­ду­пре­жде­ния о syn flood для вполне
закон­ных соеди­не­ний, то може­те попро­бо­вать под­стро­ить переменные
tcp_max_syn_backlog, tcp_synack_retries и tcp_abort_on_overflow.

> net.ipv4.ip_default_ttl = 64

Уста­нав­ли­ва­ет зна­че­ние по-умол­ча­нию для вели­чи­ны Time To Live исходящих
паке­тов. Это чис­ло опре­де­ля­ет про­дол­жи­тель­ность жиз­ни паке­та в Internet.
Каж­дый раз, когда пакет попа­да­ет на оче­ред­ной роу­тер, бранд­мау­эр и т.п.,
вели­чи­на TTL паке­та умень­ша­ет­ся на 1. Зна­че­ние по-умол­ча­нию 64. Это
доста­точ­но при­ем­ле­мое зна­че­ние. Очень труд­но пред­ста­вить себе ситуацию,
когда это чис­ло ока­за­лось бы недо­ста­точ­ным. Пере­мен­ная при­ни­ма­ет целое
чис­ло без зна­ка в диа­па­зоне от 0 до 255 вклю­чи­тель­но, одна­ко, значение
255 слиш­ком вели­ко, а если поста­вить 0 то вы вооб­ще лиши­тесь выхо­да в
сеть. Чис­ло 64 доста­точ­но хоро­шее, если вы не пыта­е­тесь установить
соеди­не­ние с ком­пью­те­ром, отсто­я­щим от вас на зна­чи­тель­ном расстоянии,
изме­ря­е­мом в пере­хо­дах (hops). Тогда этой вели­чи­ны TTL может и не
хва­тить. Одна­ко, я в сво­ей прак­ти­ке еще не встре­чал­ся с компьютерами,
отсто­я­щи­ми от меня более чем на 30 пере­хо­дов (hops) и я не думаю, что
вам при­дет­ся уве­ли­чи­вать зна­че­ние этой пере­мен­ной. Уве­ли­че­ние TTL пакета
до 255 может иметь свои нега­тив­ные послед­ствия. Если пред­ста­вить себе,
что где-то про­изо­шел сбой в 2-х марш­ру­ти­за­то­рах и пакет зацик­лил­ся между
ними, тогда пакет нач­нет бегать туда-сюда меж­ду маршрутизаторами,
погло­щая про­пуск­ную спо­соб­ность кана­ла, до тех пор, пока TTL паке­та не
исте­чет. Как пра­ви­ло, вели­чи­ну TTL не уста­нав­ли­ва­ют боль­ше 100.

> net.ipv4.ip_dynaddr = 0

Пере­мен­ная исполь­зу­ет­ся для раз­ре­ше­ния неко­то­рых про­блем, свя­зан­ных с
дина­ми­че­ской адре­са­ци­ей. Поз­во­ля­ет демо­ну diald одновременно
уста­нав­ли­вать соеди­не­ние и изме­нять исхо­дя­щий адрес в паке­тах (и сокетах
для локаль­ных про­цес­сов). Эта воз­мож­ность была реа­ли­зо­ван в для поддержки
TCP по ком­му­ти­ру­е­мым соеди­не­ни­ям и соеди­не­ни­ям с маскарадингом
(masqueradig). Эта опция поз­во­ля­ет мас­ка­ра­дить исхо­дя­щий адрес пакета
при изме­не­нии дина­ми­че­ско­го IP-адреса.В пере­мен­ную мож­но запи­сать одно
из 3-х зна­че­ний: 0, 1 или 2. (0 опция выклю­че­на, это значение
по-умол­ча­нию. 1 опция вклю­че­на.) Любое дру­гое зна­че­ние, отли­ча­ю­ще­е­ся от
0 и 1 под­ра­зу­ме­ва­ет вклю­че­ние этой опции в мно­го­слов­ном (verbose)
режи­ме, что при­во­дит к запи­си в систем­ный жур­нал отла­доч­ных сообщений.
Что про­ис­хо­дит, если изме­ня­ет­ся адрес исхо­дя­ще­го интер­фей­са при
вклю­чен­ной опции ip_dynaddr: Исхо­дя­щий адрес паке­та и соке­та изменяется
ПРИ ПОВТОРНОЙ ПЕРЕДАЧЕ, когда он нахо­дит­ся в состо­я­нии SYN_SENT. Это
каса­ет­ся локаль­ных про­цес­сов. Для тран­зит­ных паке­тов исхо­дя­щий адрес
паке­та изме­ня­ет­ся на выхо­де, когда внут­рен­ний хост выпол­ня­ет ПОВТОРНУЮ
ПЕРЕДАЧУ, пока не будет при­нят внеш­ний пакет. Эта опция осо­бен­но полезна
для слу­ча­ев авто­до­зво­на, когда в момент уста­нов­ле­ния свя­зи исходящий
адрес еще не изве­стен. Любой запрос на соеди­не­ние застав­ля­ет diald
под­нять исхо­дя­щий интер­фейс, после чего паке­ты отправ­ля­ют­ся через него.
Это озна­ча­ет, что нет необ­хо­ди­мо­сти сна­ча­ла выда­вать запрос который
под­ни­мет исхо­дя­щий интер­фейс, а затем выда­вать реаль­ный запрос на
соеди­не­ние, вме­сто это­го мы про­сто уста­нав­ли­ва­ем соединение.

> net.ipv4.ip_local_port_range = 32768 61000

Содер­жит два целых чис­ла, кото­рые опре­де­ля­ют диа­па­зон локаль­ных портов,
кото­рые исполь­зу­ют­ся в кли­ент­ских соеди­не­ни­ях, т.е. для исходящих
соеди­не­ний, кото­рые свя­зы­ва­ют нашу систе­му с неко­то­рым узлом сети, где
мы высту­па­ем в каче­стве кли­ен­та. Пер­вое чис­ло зада­ет ниж­нюю границу
диа­па­зо­на, вто­рое верх­нюю. Зна­че­ния по-умол­ча­нию зави­сят от имеющегося
объ­е­ма ОЗУ. Если уста­нов­ле­но более чем 128 Мб, то ниж­няя гра­ни­ца будет
32768, а верх­няя 61000. При мень­шем объ­е­ме ОЗУ ниж­няя гра­ни­ца будет
1024 а верх­няя 4999 или даже мень­ше. Этот диа­па­зон определяет
коли­че­ство актив­ных соеди­не­ний, кото­рые могут быть запущены
одно­вре­мен­но, с дру­гой систе­мой, кото­рая не под­дер­жи­ва­ет TCP-расширение
timestamp. Диа­па­зо­на 1024-4999 вполне доста­точ­но для уста­нов­ки до 2000
соеди­не­ний в секун­ду с систе­ма­ми, не под­дер­жи­ва­ю­щи­ми timestamp. Проще
гово­ря, это­го вполне доста­точ­но для боль­шин­ства применений.

> net.ipv4.ip_no_pmtu_disc = 0

Пере­мен­ная ip_no_pmtu_disc запре­ща­ет поиск PMTU (от англ. Path Maximum
Transfer Unit Мак­си­маль­ный Раз­мер Паке­та для выбран­но­го Пути). Для
боль­шин­ства слу­ча­ев луч­ше уста­но­вить в эту пере­мен­ную зна­че­ние FALSE,
или 0 (т.е. систе­ма будет пытать­ся опре­де­лить мак­си­маль­ный размер
паке­та, при кото­ром не потре­бу­ет­ся выпол­нять их фраг­мен­та­цию, для
пере­да­чи на задан­ный хост). Но ино­гда, в отдель­ных слу­ча­ях, такое
пове­де­ние систе­мы может при­во­дить к сры­вам соеди­не­ний. Если у вас
воз­ни­ка­ют такие про­бле­мы, то вам сле­ду­ет попро­бо­вать отклю­чить эту опцию
(т.е. запи­сать в пере­мен­ную чис­ло 1) и уста­но­вить нуж­ное зна­че­ние MTU.
Хочу обра­тить ваше вни­ма­ние на то, что MTU и PMTU это не одно и то же!
MTU (от англ. Maximum Transfer Unit мак­си­маль­ный раз­мер пакета)
опре­де­ля­ет мак­си­маль­ный раз­мер паке­та для наших сете­вых интер­фей­сов, но
не для сете­вых интер­фей­сов на дру­гом кон­це. PMTU опция, которая
застав­ля­ет систе­му вычис­лять мак­си­маль­ный раз­мер паке­та, при кото­ром не
потре­бу­ет­ся фраг­мен­та­ция паке­тов, для марш­ру­та к задан­но­му хосту,
вклю­чая все про­ме­жу­точ­ные пере­хо­ды. Зна­че­ние по-умол­ча­нию FALSE (0),
т.е. функ­ция опре­де­ле­ния раз­ре­ше­на. Если запи­сать чис­ло 1 в эту
пере­мен­ную, то функ­ция опре­де­ле­ния PMTU будет запре­ще­на. Переменная
ip_no_pmtu_disc может при­ни­мать зна­че­ние 0 или 1.

> net.ipv4.ip_nonlocal_bind = 0

Уста­нов­ка этой пере­мен­ной поз­во­ля­ет отдель­ным локаль­ным процессам
высту­пать от име­ни внеш­не­го (чужо­го) IP адре­са. Это может оказаться
полез­ным в неко­то­рых слу­ча­ях, когда необ­хо­ди­мо про­слу­ши­вать внешние
(чужие) IP адре­са, напри­мер сниф­финг чужо­го траф­фи­ка. Одна­ко, эта опция
может ока­зы­вать отри­ца­тель­ное вли­я­ние на рабо­то­спо­соб­ность отдельных
при­ло­же­ний. Эта пере­мен­ная может иметь два зна­че­ния 0 или 1. Если
уста­нов­ле­но зна­че­ние 0, то опция отклю­че­на, 1 вклю­че­на. Значение
по-умол­ча­нию 0.

> net.ipv4.ipfrag_low_thresh = 196608

Пере­мен­ная зада­ет мак­си­маль­ный объ­ем памя­ти, выде­ля­е­мый под очередь
фраг­мен­ти­ро­ван­ных паке­тов. Когда дли­на оче­ре­ди дости­га­ет это­го порога,
то обра­бот­чик фраг­мен­тов будет отвер­гать все фраг­мен­ти­ро­ван­ные паке­ты до
тех пор, пока дли­на оче­ре­ди не умень­шит­ся до зна­че­ния переменной
ipfrag_low_thresh. Это озна­ча­ет, что все отверг­ну­тые фрагментированные
паке­ты долж­ны быть повтор­но пере­да­ны узлом-отпра­ви­те­лем. Пакеты
фраг­мен­ти­ру­ют­ся в том слу­чае, если их раз­мер слиш­ком велик, что­бы быть
пере­дан­ны­ми по дан­но­му кана­лу. Узел-отпра­ви­тель, в этом слу­чае, режет
паке­ты на более мел­кие части и затем пере­да­ет их одну за дру­гой. На
узле-полу­ча­те­ле эти фраг­мен­ты опять соби­ра­ют­ся в пол­но­цен­ный пакет.
При­ме­ча­тель­но, что идея фраг­мен­та­ции паке­тов, сама по себе, вещь
заме­ча­тель­ная, но, к сожа­ле­нию, может быть исполь­зо­ва­на в весьма
небла­го­вид­ных целях. Пере­мен­ная содер­жит целое чис­ло в диа­па­зоне 0 ..
2147483647 и озна­ча­ет верх­ний порог дли­ны оче­ре­ди фраг­мен­тов в байтах.
Зна­че­ние по-умол­ча­нию 262144 байт, или 256 Кб. Это­го коли­че­ства, как
пра­ви­ло, вполне доста­точ­но даже для самых край­них случаев.

> net.ipv4.ipfrag_time = 30

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

> net.ipv4.inet_peer_gc_maxtime = 120

Пере­мен­ная inet_peer_gc_maxtime опре­де­ля­ет часто­ту сбор­ки мусо­ра при
незна­чи­тель­ном объ­е­ме дан­ных. Эта пере­мен­ная име­ет то же предназначение,
что и inet_peer_gc_mintime, толь­ко выбор, какой пере­мен­ной пользоваться,
про­из­во­дит­ся в зави­си­мо­сти от вели­чи­ны нагруз­ки на систе­му. Переменная
при­ни­ма­ет целое чис­ло, изме­ря­е­мое в тиках. Зна­че­ние по-умол­ча­нию 120
тиков, чего вполне доста­точ­но для боль­шин­ства сер­ве­ров и рабочих
станций.

> net.ipv4.inet_peer_gc_mintime = 10

Пере­мен­ная inet_peer_gc_maxtime опре­де­ля­ет часто­ту сбор­ки мусо­ра при
незна­чи­тель­ном объ­е­ме дан­ных. Эта пере­мен­ная име­ет то же предназначение,
что и inet_peer_gc_mintime, толь­ко выбор, какой пере­мен­ной пользоваться,
про­из­во­дит­ся в зави­си­мо­сти от вели­чи­ны нагруз­ки на систе­му. Переменная
при­ни­ма­ет целое чис­ло, изме­ря­е­мое в тиках. Зна­че­ние по-умол­ча­нию 120
тиков, чего вполне доста­точ­но для боль­шин­ства сер­ве­ров и рабочих
станций.

> net.ipv4.inet_peer_maxttl = 600

Это мак­си­маль­ное вре­мя хра­не­ния запи­сей. При незна­чи­тель­ных нагруз­ках на
систе­му неис­поль­зу­е­мые запи­си будут уда­лять­ся через дан­ный промежуток
времени.

> net.ipv4.inet_peer_minttl = 120

Пере­мен­ная опре­де­ля­ет мини­маль­ное вре­мя хра­не­ния дан­ных в inet peer
storage. Это вре­мя долж­но быть доста­точ­но боль­шим, что­бы пере­крыть время
сбор­ки фраг­мен­тов на про­ти­во­по­лож­ной сто­роне. Мини­маль­ное вре­мя хранения
явля­ет­ся гаран­ти­ей того, что раз­мер пула будет мень­ше чем величина
inet_peer_threshold.

> net.ipv4.inet_peer_threshold = 65664

Пере­мен­ная опре­де­ля­ет мини­маль­ное вре­мя хра­не­ния дан­ных в inet peer
storage. Это вре­мя долж­но быть доста­точ­но боль­шим, что­бы пере­крыть время
сбор­ки фраг­мен­тов на про­ти­во­по­лож­ной сто­роне. Мини­маль­ное вре­мя хранения
явля­ет­ся гаран­ти­ей того, что раз­мер пула будет мень­ше чем величина
inet_peer_threshold.

> net.ipv4.tcp_abort_on_overflow = 0

Эта пере­мен­ная застав­ля­ет ядро отвер­гать новые соеди­не­ния, если их
посту­па­ет такое коли­че­ство, что систе­ма не в состо­я­нии спра­вить­ся с
таким пото­ком. Что это озна­ча­ет? Допу­стим, что на систе­му обрушивается
шквал запро­сов на соеди­не­ние, тогда они могут быть про­сто отвергнуты,
если пере­мен­ная будет вклю­че­на, посколь­ку систе­ма не в состоянии
обра­бо­тать их все. Если пере­мен­ная не уста­нов­ле­на, то систе­ма будет
пытать­ся обслу­жить все запро­сы. Пере­мен­ная может иметь два значение
0(выключено) или 1(включено). Зна­че­ние по-умол­ча­нию 0. Вклю­че­ние этой
опции сле­ду­ет рас­це­ни­вать как край­нюю меру. Перед этим необходимо
попы­тать­ся под­нять про­из­во­ди­тель­ность сервисов.

> net.ipv4.tcp_adv_win_scale = 2

Эта пере­мен­ная вли­я­ет на вычис­ле­ние объ­е­ма памя­ти в буфе­ре сокета,
выде­ля­е­мой под раз­мер TCP-окна и под буфер при­ло­же­ния. Если величина
tcp_adv_win_scale отри­ца­тель­ная, то для вычис­ле­ния раз­ме­ра используется
сле­ду­ю­щее выра­же­ние: Где bytes это раз­мер окна в бай­тах. Если величина
tcp_adv_win_scale поло­жи­тель­ная, то для опре­де­ле­ния раз­ме­ра используется
сле­ду­ю­щее выра­же­ние: Пере­мен­ная при­ни­ма­ет целое зна­че­ние. Значение
по-умол­ча­нию 2, т.е. под буфер при­ло­же­ния отво­дит­ся 1/4 часть объема,
опре­де­ля­е­мо­го пере­мен­ной tcp_rmem.

> net.ipv4.tcp_app_win = 31

Эта пере­мен­ная опре­де­ля­ет коли­че­ство байт, резер­ви­ру­е­мых под TCP-окно в
при­ем­ном буфе­ре соке­та. Выра­же­ние, соглас­но кото­ро­му дела­ет­ся расчет,
выгля­дит сле­ду­ю­щим обра­зом: Как вид­но из выра­же­ния чем боль­ше значение
пере­мен­ной, тем мень­ше будет раз­мер буфе­ра окна. Исклю­че­ние составляет
зна­че­ние 0. В этом слу­чае резер­ви­ро­ва­ние не про­из­во­дит­ся. Значение
по-умол­ча­нию 31. Не изме­няй­те эту пере­мен­ную, если вы не уве­ре­ны в том,
что делаете.

> net.ipv4.tcp_dsack = 1

Эта опция необ­хо­ди­ма для выпол­не­ния пере­да­чи дуб­ли­ру­ю­щих SACK-пакетов
(от англ. Selective ACKnowledgement Выбо­роч­ное Под­твер­жде­ние Приема,
прим. перев.). Тех­ни­ка выбо­роч­но­го под­твер­жде­ния крат­ко опи­са­на в
раз­де­ле, посвя­щен­ном пере­мен­ной tcp_sack. Деталь­ное опи­са­ние мож­но найти
в RFC 2883. Здесь подроб­но опи­сы­ва­ют­ся дей­ствия по обра­бот­ке ситуаций,
когда полу­чен дуб­ли­кат паке­та, при­шед­ше­го ранее, или когда пакеты
посту­па­ют не в той оче­ред­но­сти. D-SACK это рас­ши­ре­ние стан­дар­та SACK и
исполь­зу­ет­ся для уве­дом­ле­ния хоста-отпра­ви­те­ля о том, что пакет был
полу­чен два­жды (т.е. про­дуб­ли­ро­ван). Эту инфор­ма­цию хост-отправитель
может исполь­зо­вать для кор­рек­ти­ров­ки сете­вых настро­ек и т.п.. Эта опция
гаран­ти­ру­ет 100%-ную обрат­ную сов­ме­сти­мость с уста­рев­ши­ми реализациями
TCP, если в них тех­ни­ка SACK не реа­ли­зо­ва­на каким-либо нестандартным
обра­зом. Но это чрез­вы­чай­но ред­кий слу­чай, а посе­му у вас едва ли будут
воз­ни­кать про­бле­мы с этим. Пере­мен­ная может иметь два состо­я­ния 1
(вклю­че­но) и 0 (выклю­че­но). Зна­че­ние по-умол­ча­нию 1 (вклю­че­но). И, само
собой разу­ме­ет­ся, уста­нов­ка этой пере­мен­ной име­ет смысл толь­ко если
вклю­че­на пере­мен­ная tcp_sack, посколь­ку tcp_dsack очень тес­но свя­за­на с
ней. В боль­шин­стве слу­ча­ев разум­ным будет оста­вить переменную
включенной.

> net.ipv4.tcp_ecn = 0

Пере­мен­ная tcp_ecn отве­ча­ет за рабо­ту Explicit Congestion Notification
(Явное Уве­дом­ле­ние о Пере­гру­жен­но­сти) в TCP-соеди­не­ни­ях. Используется
для уве­дом­ле­ния о воз­ник­но­ве­нии зато­ра на марш­ру­те к задан­но­му хосту или
сети. Может исполь­зо­вать­ся для изве­ще­ния хоста-отпра­ви­те­ля о
необ­хо­ди­мо­сти сни­зить ско­рость пере­да­чи паке­тов через конкретный
марш­ру­ти­за­тор или бранд­мау­эр. Explicit Congestion Notification (ECN)
деталь­но опи­са­но в RFC 3168 — The Addition of Explicit Congestion
Notification (ECN) to IP. Допол­ни­тель­ную инфор­ма­цию о ECN вы най­де­те в
RFC 2884 — Performance Evaluation of Explicit Congestion Notification
(ECN) in IP Networks. Корот­ко: этот доку­мент подроб­но опи­сы­ва­ет как
долж­но пере­да­вать­ся уве­дом­ле­ние о пере­гру­жен­но­сти хосту-отправителю,
кото­рый, в свою оче­редь, может выбрать дру­гой марш­рут или начать снижать
ско­рость пере­да­чи до тех пор, пока к нему не пере­ста­нут поступать
ECN-паке­ты. В Интер­не­те еще встре­ча­ют­ся марш­ру­ти­за­то­ры и брандмауэры,
кото­рые не про­пус­ка­ют паке­ты с уста­нов­лен­ным фла­гом ECN и, если вам не
пове­зет, то вы може­те столк­нуть­ся с ними. При воз­ник­но­ве­нии про­блем с
про­хож­де­ни­ем ECN попро­буй­те отклю­чить эту опцию. Если вам встретится
подоб­ный марш­ру­ти­за­тор, то може­те попро­бо­вать всту­пить в кон­такт с
адми­ни­стра­то­ром и пре­ду­пре­дить его об име­ю­щих­ся про­бле­мах. Подробное
опи­са­ние про­бле­мы и общий спи­сок аппа­ра­ту­ры, явля­ю­щей­ся при­чи­ной этой
непри­ят­но­сти, вы най­де­те в при­ло­же­нии Ссыл­ки в пунк­те ECN-under-Linux
Unofficial Vendor Support Page. Пере­мен­ная может иметь два состо­я­ния 0
(выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0 (выклю­че­но).

> net.ipv4.tcp_fack = 1

Пере­мен­ная tcp_fack ответ­ствен­на за систе­му Forward Acknowledgement
(Упре­жда­ю­щее Под­твер­жде­ние) в Linux. Forward Acknowledgement это
спе­ци­аль­ный алго­ритм, кото­рый рабо­та­ет поверх SACK, и пред­на­зна­чен для
кон­тро­ля зато­ров. Глав­ная идея алго­рит­ма FACK состо­ит в отслеживании
наи­боль­ше­го номе­ра выбо­роч­но под­твер­жден­ной после­до­ва­тель­но­сти как
при­зна­ка того, что все преды­ду­щие не под­твер­жден­ные (выбо­роч­но) сегменты
были поте­ря­ны. Это поз­во­ля­ет опти­ми­зи­ро­вать вос­ста­нов­ле­ние потерь.
Одна­ко, этот алго­ритм ста­но­вит­ся нера­бо­то­спо­соб­ным в случае
неупо­ря­до­чен­но­го пото­ка дан­ных, тогда он (алго­ритм) автоматически
отклю­ча­ет­ся для дан­но­го кон­крет­но­го соеди­не­ния. Изна­чаль­но алго­ритм FACK
был раз­ра­бо­тан Мэттью Мати­сом (Matthew Mathis) с соав­то­ра­ми. Документ,
опи­сы­ва­ю­щий алго­ритм, мож­но най­ти на http://www.psc.edu/~mathis/.
Пере­мен­ная может при­ни­мать два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но).
Зна­че­ние по-умол­ча­нию 1 (вклю­че­но). Эта опция исполь­зу­ет­ся только
тогда, когда вклю­че­на пере­мен­ная tcp_sack.

> net.ipv4.tcp_fin_timeout = 60

Пере­мен­ная зада­ет мак­си­маль­ное вре­мя пре­бы­ва­ния соке­та в состоянии
FIN-WAIT-2. Исполь­зу­ет­ся в тех слу­ча­ях, когда дру­гая сто­ро­на по тем или
иным при­чи­нам не закры­ла соеди­не­ние со сво­ей сто­ро­ны. Каж­дый сокет
зани­ма­ет в памя­ти поряд­ка 1.5 Кб, что может при­ве­сти к значительным
утеч­кам памя­ти в неко­то­рых слу­ча­ях. Пере­мен­ная при­ни­ма­ет целое число.
Зна­че­ние по-умол­ча­нию 60 секунд. В ядрах серии 2.2 это зна­че­ние было
рав­но 180 секун­дам, но было умень­ше­но, посколь­ку ино­гда возникали
про­бле­мы, свя­зан­ные с нехват­кой памя­ти, на web-сер­ве­рах, кото­рые, как
пра­ви­ло, обслу­жи­ва­ют огром­ное коли­че­ство под­клю­че­ний. За дополнительной
инфор­ма­ци­ей обра­щай­тесь к опи­са­нию пере­мен­ных tcp_max_orphans и
tcp_orphan_retries.

> net.ipv4.tcp_keepalive_intvl = 75

Пере­мен­ная опре­де­ля­ет интер­вал про­вер­ки жиз­не­спо­соб­ность соке­та. Это
зна­че­ние учи­ты­ва­ет­ся при под­сче­те вре­ме­ни, кото­рое долж­но прой­ти перед
тем как соеди­не­ние будет разо­рва­но. Пере­мен­ная при­ни­ма­ет целое число.
Зна­че­ние по-умол­ча­нию 75 секунд. Это доста­точ­но высо­кое зна­че­ние, чтобы
рас­смат­ри­вать его как нор­маль­ное. Зна­че­ния переменных
tcp_keepalive_probes и tcp_keepalive_intvl могут исполь­зо­вать­ся для
опре­де­ле­ния вре­ме­ни, через кото­рое соеди­не­ние будет разо­рва­но. Со
зна­че­ни­я­ми по-умол­ча­нию (9 попы­ток с интер­ва­лом 75 секунд) это займет
при­мер­но 11 минут. Попыт­ки опре­де­ле­ния жиз­не­спо­соб­но­сти, в свою очередь,
нач­нут­ся через 2 часа после того, как через дан­ное соединение
про­сле­до­вал послед­ний пакет.

> net.ipv4.tcp_keepalive_probes = 9

Пере­мен­ная опре­де­ля­ет коли­че­ство попы­ток про­вер­ки жизнеспособности
преж­де, чем будет при­ня­то реше­нии о раз­ры­ве соеди­не­ния. Переменная
при­ни­ма­ет целое чис­ло, кото­рое не сле­ду­ет уста­нав­ли­вать боль­ше 50-ти.
Зна­че­ние по-умол­ча­нию 9. Это озна­ча­ет, что будет выпол­не­но 9 попыток
про­вер­ки соеди­не­ния, что­бы убе­дить­ся в том, что соеди­не­ние разорвано.

> net.ipv4.tcp_keepalive_time = 7200

Пере­мен­ная опре­де­ля­ет как часто сле­ду­ет про­ве­рять соеди­не­ние, если оно
дав­но не исполь­зу­ет­ся. Зна­че­ние пере­мен­ной име­ет смысл толь­ко для тех
соке­тов, кото­рые были созда­ны с фла­гом SO_KEEPALIVE. Переменная
при­ни­ма­ет целое чис­ло секунд. Зна­че­ние по-умол­ча­нию 7200 секунд, или 2
часа. Не умень­шай­те это чис­ло без необ­хо­ди­мо­сти, посколь­ку это может
при­ве­сти к уве­ли­че­нию излиш­не­го трафика.

> net.ipv4.tcp_max_orphans = 65536

Пере­мен­ная зада­ет мак­си­маль­ное чис­ло оси­ро­тев­ших (не свя­зан­ных ни с
одним про­цес­сом) соке­тов. Если это чис­ло будет пре­вы­ше­но, то такие
соеди­не­ния раз­ры­ва­ют­ся, а в систем­ный жур­нал пишет­ся пре­ду­пре­жде­ние. Это
огра­ни­че­ние суще­ству­ет исклю­чи­тель­но ради предот­вра­ще­ния простейших
раз­но­вид­но­стей DoS-атак. Вооб­ще вы не долж­ны пола­гать­ся на эту
пере­мен­ную! Не реко­мен­ду­ет­ся умень­шать это чис­ло. Сете­вая сре­да может
потре­бо­вать уве­ли­че­ние это­го поро­га, одна­ко, такое уве­ли­че­ние может
при­ве­сти к необ­хо­ди­мо­сти уве­ли­че­ния объ­е­ма ОЗУ в систе­ме. Преж­де чем
под­ни­мать этот пре­дел попро­буй­те пере­на­стро­ить сете­вые сер­ви­сы на более
агрес­сив­ное пове­де­ние по отно­ше­нию к оси­ро­тев­шим соке­там. Переменная
при­ни­ма­ет целое чис­ло. Зна­че­ние по-умол­ча­нию 8192, одна­ко оно очень
силь­но зави­сит от объ­е­ма памя­ти в систе­ме. Каж­дый оси­ро­тев­ший сокет
съе­да­ет при­мер­но 64 Кб памя­ти, кото­рая не может быть сбро­ше­на в своп
(swap). При воз­ник­но­ве­нии про­блем, свя­зан­ных с этим огра­ни­че­ни­ем в
систем­ный жур­нал будет запи­са­но сооб­ще­ние, подоб­ное это­му: TCP: too many
of orphaned sockets Это может слу­жить пово­дом к тому, что­бы пересмотреть
зна­че­ния пере­мен­ных tcp_fin_timeout или tcp_orphans_retries.

> net.ipv4.tcp_max_syn_backlog = 1024

Пере­мен­ная опре­де­ля­ет мак­си­маль­ное вре­мя хра­не­ния SYN-запро­сов в памяти
до момен­та полу­че­ния тре­тье­го, завер­ша­ю­ще­го уста­нов­ле­ние соединения,
паке­та. Эта опция рабо­та­ет толь­ко тогда, когда вклю­че­на переменная
tcp_syncookies. Если сер­вер испы­ты­ва­ет серьез­ные нагруз­ки, то можно
попро­бо­вать немно­го уве­ли­чить этот пара­метр. Пере­мен­ная при­ни­ма­ет целое
чис­ло. Зна­че­ние по-умол­ча­нию зави­сит от коли­че­ства памя­ти, име­ю­щей­ся в
систе­ме. Если объ­ем памя­ти менее 128 Мб, то зна­че­ние по-умол­ча­нию равно
128, если боль­ше, то зна­че­ние по-умол­ча­нию рав­но 1024. Если вы
уве­ли­чи­ва­е­те эту пере­мен­ную до вели­чи­ны более чем 1024, то было бы
непло­хо изме­нить вели­чи­ну TCP_SYNQ_HSIZE и пере­со­брать ядро.
TCP_SYNQ_HSIZE нахо­дит­ся в фай­ле linux/include/tcp.h. Эта величина
рас­счи­ты­ва­ет­ся по фор­му­ле: TCP_SYNQ_HSIZE*16 tcp_max_syn_backlog

> net.ipv4.tcp_max_tw_buckets = 180000

Мак­си­маль­ное чис­ло соке­тов, нахо­дя­щих­ся в состо­я­нии TIME-WAIT
одно­вре­мен­но. При пре­вы­ше­нии это­го поро­га лиш­ний сокет раз­ру­ша­ет­ся и
пишет­ся сооб­ще­ние в систем­ный жур­нал. Цель этой переменной
предот­вра­ще­ние про­стей­ших раз­но­вид­но­стей DoS-атак. Пере­мен­ная принимает
целое чис­ло. Зна­че­ние по-умол­ча­нию 180000. На пер­вый взгляд может
пока­зать­ся, что это очень мно­го, но на самом деле это не так. Если у вас
начи­на­ют воз­ни­кать ошиб­ки, свя­зан­ные с этим пара­мет­ром, то попробуйте
уве­ли­чить его. Вам не сле­ду­ет умень­шать зна­че­ние этой пере­мен­ной. Вместо
это­го, если нача­ли посту­пать сооб­ще­ния в систем­ный жур­нал, ее следует
уве­ли­чить, одна­ко, это может потре­бо­вать нара­щи­ва­ния памя­ти в системе.

> net.ipv4.tcp_mem = 196608 262144 393216

В этой пере­мен­ной зада­ют­ся 3 зна­че­ния, опре­де­ля­ю­щие объ­ем памяти,
кото­рый может быть исполь­зо­ван сте­ком TCP. Зна­че­ния изме­ря­ют­ся в
стра­ни­цах памя­ти. Раз­мер одной стра­ни­цы зави­сит от аппа­ра­ту­ры и
кон­фи­гу­ра­ции ядра. Для архи­тек­ту­ры i386 раз­мер одной стра­ни­цы составляет
4Кб, или 4096 байт. Неко­то­рые, более новые аппа­рат­ные реа­ли­за­ции, имеют
раз­мер стра­ни­цы рав­ный 16, 32 или даже 64 Кб. Все три значения
по-умол­ча­нию рас­счи­ты­ва­ют­ся во вре­мя загруз­ки. Пер­вое чис­ло задает
ниж­ний порог. Ниже это­го поро­га, стек TCP вооб­ще никак не бес­по­ко­ит­ся об
управ­ле­нии памя­тью, исполь­зу­е­мой раз­лич­ны­ми TCP соке­та­ми. Когда объем
исполь­зу­е­мой памя­ти дости­га­ет вто­ро­го пре­де­ла (чис­ла), то TCP начинает
более энер­гич­но рас­тал­ки­вать память, стре­мясь осво­бо­дить ее как можно
быст­рее. Этот про­цесс про­дол­жа­ет­ся до тех пор, пока объ­ем используемой
памя­ти не достиг­нет ниж­не­го пре­де­ла. И послед­нее чис­ло максимальный
объ­ем памя­ти, кото­рый может исполь­зо­вать­ся для нужд TCP. Если
исполь­зу­е­мый объ­ем памя­ти достиг­нет это­го поро­га, то TCP про­сто начинает
терять паке­ты и соеди­не­ния до тех пор, пока объ­ем исполь­зу­е­мой памя­ти не
умень­шит­ся. Эта пере­мен­ная может поз­во­лить несколь­ко увеличить
про­пуск­ную спо­соб­ность на тол­стых кана­лах, если долж­ным образом
настро­ить пере­мен­ные tcp_mem, tcp_rmem и tcp_wmem. Впро­чем, переменная
tcp_rmem не тре­бу­ет осо­бо при­сталь­но­го вни­ма­ния, посколь­ку серия ядер
2.4 име­ет доста­точ­но хоро­шие настрой­ки этой пере­мен­ной, а вот на другие
две сле­ду­ет взгля­нуть побли­же. Допол­ни­тель­ную инфор­ма­цию об этом вы
най­де­те в руко­вод­стве TCP Tuning Guide.

> net.ipv4.tcp_orphan_retries = 0

Коли­че­ство попы­ток закрыть соеди­не­ние перед тем как оно будет разорвано
при­ну­ди­тель­но. Если вы адми­ни­стри­ру­е­те http-сер­вер, кото­рый испытывает
боль­шие нагруз­ки, то сто­ит поду­мать об умень­ше­нии это­го значения.
Пере­мен­ная при­ни­ма­ет целое чис­ло. Зна­че­ние по-умол­ча­нию 7, что
соот­вет­ству­ет, при­мер­но, от 50 секунд до 16 минут, в зави­си­мо­сти от
вели­чи­ны Retransmission Timeout (RTO Тай­маут для Повтор­ной Передачи.
прим. перев.). Деталь­ное опи­са­ние RTO вы най­де­те в раз­де­ле 3.7. Data
Communication RFC 793 — Transmission Control Protocol. Кро­ме того,
посмот­ри­те опи­са­ние пере­мен­ной tcp_max_orphans.

> net.ipv4.tcp_reordering = 3

Мак­си­маль­ное коли­че­ство паке­тов, при­шед­ших в пото­ке не по-порядку,
преж­де чем будет сде­ла­но пред­по­ло­же­ние о том, что пакет был потерян
где-то на марш­ру­те. Когда дела­ет­ся такое пред­по­ло­же­ние, то стек TCP
пере­хо­дит обрат­но в режим slow start (мед­лен­ный старт), посколь­ку пакет
дей­стви­тель­но мог быть уте­рян из-за пере­гру­жен­но­сти сети. Кро­ме того,
стек TCP отка­жет­ся от даль­ней­ше­го исполь­зо­ва­ния алго­рит­ма FACK при
обмене с этим хостом. Пере­мен­ная при­ни­ма­ет целое чис­ло. Значение
по-умол­ча­нию 3. Это доста­точ­но хоро­шее зна­че­ние и не сле­ду­ет его
изме­нять. Если этот пара­метр умень­шить, то это может значительно
ухуд­шить рабо­ту сете­вой под­си­сте­мы осо­бен­но, если паке­ты часто
переупорядочиваются.

> net.ipv4.tcp_retrans_collapse = 1

Включает/выключает эму­ля­цию ошиб­ки про­то­ко­ла TCP, делая возможным
сете­вое вза­и­мо­дей­ствие с неко­то­ры­ми устрой­ства­ми, в кото­рых реализация
сте­ка TCP име­ет эту ошиб­ку. Без ее эму­ля­ции было бы невоз­мож­ным работать
с отдель­ны­ми моде­ля­ми прин­те­ров. Ошиб­ка заклю­ча­ет­ся в отправке
пол­но­раз­мер­ных паке­тов при повтор­ной пере­да­че. Пере­мен­ная может
при­ни­мать два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Значение
по-умол­ча­нию 1 (вклю­че­но). Эму­ля­ция ошиб­ки никак не повредит
вза­и­мо­дей­ствию с дру­ги­ми узла­ми сети, но при этом поз­во­лит общать­ся с
устрой­ства­ми, име­ю­щи­ми ошиб­ку в реа­ли­за­ции сте­ка TCP. Вооб­ще эта опция
совер­шен­но без­опас­на, одна­ко, если в жур­нал пишут­ся непо­нят­ные сообщения
може­те попро­бо­вать отклю­чить ее.

> net.ipv4.tcp_retries1 = 3

Мак­си­маль­ное коли­че­ство попы­ток повтор­ной пере­да­чи паке­тов по
уста­нов­лен­но­му соеди­не­нию преж­де, чем сооб­ще­ние об ошиб­ке будет передано
сете­во­му уров­ню, в резуль­та­те чего может быть выбран дру­гой марш­рут для
отправ­ки после­ду­ю­щих паке­тов. Мини­маль­ное зна­че­ние это­го параметра
опре­де­ля­ет­ся в RFC ???? и рав­но 3. Это чис­ло явля­ет­ся значением
по-умол­ча­нию, что соот­вет­ству­ет интер­ва­лу вре­ме­ни от 3 секунд до 8
минут, в зави­си­мо­сти от вели­чи­ны Retransmission timeout (RTO). Детальное
опи­са­ние RTO вы най­де­те в раз­де­ле 3.7. Data Communication RFC 793 —
Transmission Control Protocol. Пере­мен­ная при­ни­ма­ет целое число.
Зна­че­ние по-умол­ча­нию 3. Стан­дар­ты опре­де­ля­ют диа­па­зон изме­не­ния этого
пара­мет­ра от 3 до 100.

> net.ipv4.tcp_retries2 = 15

Мак­си­маль­ное коли­че­ство попы­ток повтор­ной пере­да­чи паке­тов, до того как
соеди­не­ние будет счи­тать­ся разо­рван­ным. Это огра­ни­че­ние опре­де­ле­но в RFC
1122 и рав­но 100, но обыч­но его умень­ша­ют. Пере­мен­ная при­ни­ма­ет целое
чис­ло. Зна­че­ние по-умол­ча­нию 15, что соот­вет­ству­ет при­мер­но 13-30
мину­там в зави­си­мо­сти от вели­чи­ны Retransmission timeout (RTO). При
жела­нии може­те попро­бо­вать умень­шить этот параметр.

> net.ipv4.tcp_rfc1337 = 0

Пере­мен­ная tcp_rfc1337 явля­ет­ся реа­ли­за­ци­ей реше­ния проблемы,
опи­сы­ва­е­мой в RFC 1337 — TIME-WAIT Assassination Hazards in TCP.
Про­бле­ма свя­за­на с уста­рев­ши­ми дуб­ли­ка­та­ми паке­тов, кото­рые могут
вно­сить поме­хи во вновь уста­нав­ли­ва­е­мые соеди­не­ния и порож­дать три
раз­лич­ные про­бле­мы. Пер­вая уста­рев­ший дуб­ли­кат паке­та с дан­ны­ми может
быть оши­боч­но вос­при­нят в новом соеди­не­нии, что при­ве­дет к передаче
невер­ных дан­ных. Вто­рая соеди­не­ние может быть десин­хро­ни­зи­ро­ва­но и уйти
в ACK-цикл из-за уста­рев­ших дуб­ли­ка­тов, кото­рые порож­да­ют новые
соеди­не­ния (здесь автор име­ет вви­ду уста­рев­шие дуб­ли­ка­ты SYN-пакетов,
прим. перев.). И тре­тья, и послед­няя про­бле­ма уста­рев­шие дубликаты
могут про­ник­нуть в недав­но создан­ное соеди­не­ние и оши­боч­но уничтожить
его. Соглас­но упо­мя­ну­то­му RFC суще­ству­ют три воз­мож­ных реше­ния, однако,
одно из них реша­ет эту про­бле­му лишь частич­но, вто­рое тре­бу­ет внесения
зна­чи­тель­ных изме­не­ний в про­то­кол TCP. Окон­ча­тель­ное реше­ние состо­ит в
том, что RST-паке­ты долж­ны про­сто игно­ри­ро­вать­ся, пока сокет нахо­дит­ся в
состо­я­нии TIME_WAIT. Вме­сте с уста­нов­кой пара­мет­ра Maximum Segment Life
(MSL мак­си­маль­ное вре­мя жиз­ни сег­мен­та) рав­ным 2 мин. такой подход
реша­ет все три про­бле­мы, опи­сан­ные в RFC 1337.

> net.ipv4.tcp_rmem = 4096 87380 4194304

Пере­мен­ная содер­жит три чис­ла, кото­рые исполь­зу­ют­ся при управлении
раз­ме­ра­ми при­ем­ных буфе­ров. Пер­вое чис­ло мини­маль­ный раз­мер приемного
буфе­ра, кото­рый выде­ля­ет­ся для каж­до­го соке­та. Этот раз­мер буфера
выде­ля­ет­ся все­гда, даже при очень высо­ких нагруз­ках на систе­му. Значение
по-умол­ча­нию 4096 байт, или 4 Кб. В преды­ду­щих вер­си­ях ядра Linux это
зна­че­ние было 8192 байт. Это доста­точ­но боль­шой раз­мер и не следует
уве­ли­чи­вать его, ина­че, при взрыв­ных нагруз­ках на сеть, вы можете
столк­нуть с очень серьез­ны­ми про­бле­ма­ми. Вто­рое чис­ло раз­мер приемного
буфе­ра по-умол­ча­нию, кото­рый выде­ля­ет­ся для каж­до­го соке­та. Это значение
пере­кры­ва­ет зна­че­ние пере­мен­ной /proc/sys/net/core/rmem_default, которая
исполь­зу­ет­ся дру­ги­ми про­то­ко­ла­ми. Зна­че­ние по-умол­ча­нию 87380 байт, или
85 Кб. Сов­мест­но с пере­мен­ны­ми tcp_adv_win_scale и tcp_app_win эта
пере­мен­ная исполь­зу­ет­ся при рас­че­те раз­ме­ра TCP-окна. Это значение
исполь­зу­ет­ся при незна­чи­тель­ных нагруз­ках. Как и в слу­чае с первым
зна­че­ни­ем не сле­ду­ет без осо­бой нуж­ды изме­нять этот пара­метр. Эта
пере­мен­ная может дать неко­то­рый при­рост про­из­во­ди­тель­но­сти на толстых
кана­лах, если доста­точ­но кор­рект­но исполь­зу­ет­ся вме­сте с переменными
tcp_mem и tcp_wmem. tcp_rmem не тре­бу­ет вме­ша­тель­ства извне, поскольку
ядра серии 2.4 доста­точ­но хоро­шо настра­и­ва­ют ее авто­ма­ти­че­ски, а вот на
tcp_mem и tcp_wmem мож­но взгля­нуть попри­сталь­нее. Дополнительную
инфор­ма­цию, по настрой­ке пере­мен­ных, вы най­де­те в TCP Tuning Guide.
Тре­тье, и послед­нее, чис­ло мак­си­маль­но воз­мож­ный раз­мер приемного
буфе­ра, кото­рый может быть раз­ме­щен для каж­до­го соке­та. Этот параметр
пере­кры­ва­ет­ся пере­мен­ной /proc/sys/net/core/rmem_max, если зна­че­ние в
ipv4 ока­зы­ва­ет­ся боль­ше. Перед изме­не­ни­ем это­го пара­мет­ра вам следует
сна­ча­ла взгля­нуть на зна­че­ние /proc/sys/net/core/rmem_max. Значение
по-умол­ча­нию удво­ен­ное зна­че­ние вто­ро­го пара­мет­ра, т.е. 87380 * 2
bytes, или 174760 байт (170 Кб). Как пра­ви­ло этот пара­метр не нуждается
в корректировке.

> net.ipv4.tcp_sack = 1

Раз­ре­ша­ет Selective Acknowledgements (SACK Выбо­роч­ное Подтверждение),
деталь­ное опи­са­ние вы най­де­те в RFC 2883 — An Extension to Selective
Acknowledgement (SACK) Option for TCP и RFC 2883 — An Extension to
Selective Acknowledgement (SACK) Option for TCP. Если эта переменная
вклю­че­на (уста­нов­ле­на 1), то в TCP-заго­лов­ке будет устанавливаться
SACK-флаг при пере­да­че SYN-паке­та, сооб­щая тем самым уда­лен­но­му хосту,
что наша систе­ма в состо­я­нии обра­ба­ты­вать SACK, на что уда­лен­ный хост
может отве­тить ACK-паке­том с уста­нов­лен­ным фла­гом SACK. Этот режим
выбо­роч­но под­твер­жда­ет каж­дый сег­мент в TCP-окне. Это осо­бен­но полезно
на неустой­чи­вых соеди­не­ни­ях, посколь­ку поз­во­ля­ет про­из­во­дить повторную
пере­да­чу лишь отдель­ных, не под­твер­жден­ных фраг­мен­тов, а не всего
TCP-окна, как это дик­ту­ет­ся более ста­ры­ми стан­дар­та­ми. Если какой либо
сег­мент TCP-окна был уте­рян, то при­ем­ная сто­ро­на не при­шлет на него
SACK-под­твер­жде­ние о при­е­ме. Отпра­ви­тель, поняв это, повто­рит передачу
поте­ряв­ших­ся сег­мен­тов. Избы­точ­ные дан­ные сохра­ня­ют­ся в TCP-заголовке,
40 байт на сег­мент. Под­твер­жде­ние каж­до­го сег­мен­та это два 32-битных
без­зна­ко­вых целых чис­ла, таким обра­зом в заго­лов­ке может разместиться
под­твер­жде­ние 4-х сег­мен­тов. Одна­ко, как пра­ви­ло, сов­мест­но с опцией
SACK исполь­зу­ет­ся опция timestamp, кото­рая зани­ма­ет 10 байт и поэто­му в
одном паке­те может быть под­твер­жде­но не более 3 сег­мен­тов. Рекомендуется
вклю­чать эту опцию, если вы име­е­те неустой­чи­вые соеди­не­ния. Одна­ко, если
вы соеди­не­ны 1.5-метровым кабе­лем с дру­гой маши­ной, то в таком случае,
для дости­же­ния наи­выс­шей ско­ро­сти обме­на, сле­ду­ет эту опцию отключить.
Обыч­но эта опция не нуж­на, но луч­ше ее вклю­чить. Она обес­пе­чи­ва­ет 100%
обрат­ную сов­ме­сти­мость, т.е. вы не долж­ны испы­ты­вать ника­ких про­блем при
соеди­не­нии с хоста­ми, кото­рые эту опцию не под­дер­жи­ва­ют. В переменную
могут быть запи­са­ны два чис­ла 0 (выклю­че­но) и 1 (вклю­че­но). Значение
по-умол­ча­нию 1 (вклю­че­но).

> net.ipv4.tcp_stdurg = 0

Разрешает/запрещает соот­вет­ствие стан­дар­ту RFC 1122. Поведение
по-умол­ча­нию соот­вет­ству­ет стан­дар­ту исполь­зо­ва­ния фла­га URG BSD 4.2,
опи­сан­но­му в RFC 793. Если эта пере­мен­ная вклю­че­на, то воз­мож­ны сбои при
рабо­те с отдель­ны­ми узла­ми Интер­не­та, точ­нее с узла­ми, которые
при­дер­жи­ва­ют­ся стан­дар­та BSD 4.2. За допол­ни­тель­ной информацией
обра­щай­тесь к RFC 1122 — Requirements for Internet Hosts Communication
Layers сек­ция 4.2.2.4 Urgent Pointer: RFC 793 Section 3.1 explanation,
где име­ет­ся ссыл­ка на RFC 793 — Transmission Control Protocol.
Пере­мен­ная при­ни­ма­ет два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но).
Зна­че­ние по-умол­ча­нию 0 (выклю­че­но).

> net.ipv4.tcp_syn_retries = 5

Коли­че­ство попы­ток пере­да­чи SYN-паке­та при уста­нов­ле­нии нового
соеди­не­ния. Пере­мен­ная при­ни­ма­ет целое чис­ло, кото­рое не должно
уста­нав­ли­вать­ся боль­ше чем 255, посколь­ку каж­дая повтор­ная попытка
отни­ма­ет зна­чи­тель­ное вре­мя. На каж­дую попыт­ку отво­дит­ся при­мер­но 30-40
секунд. Зна­че­ние по-умол­ча­нию 5, что соот­вет­ству­ет, при­мер­но, 180
секундам.

> net.ipv4.tcp_synack_retries = 5

Коли­че­ство попы­ток пере­да­чи SYN,ACK-пакета в ответ на SYN-запрос.
Дру­ги­ми сло­ва­ми мак­си­маль­ное чис­ло попы­ток уста­но­вить пассивное
TCP-соеди­не­ние, ини­ци­и­ро­ван­ное дру­гим хостом. Пере­мен­ная при­ни­ма­ет целое
чис­ло, кото­рое не долж­но уста­нав­ли­вать­ся боль­ше чем 255 по тем же
при­чи­нам, что и в слу­чае с пере­мен­ной tcp_syn_retries. Значение
по-умол­ча­нию 5.

> net.ipv4.tcp_timestamps = 1

Разрешает/запрещает исполь­зо­ва­ние вре­мен­ных меток (timestamps), в
соот­вет­ствии с RFC 1323. Если корот­ко, то это рас­ши­ре­ние TCP
исполь­зу­ет­ся для рас­че­та Round Trip Measurement (опре­де­ле­ние времени
воз­вра­та) луч­шим спо­со­бом, неже­ли метод Retransmission timeout (RTO).
Эта опция долж­на сохра­нять обрат­ную сов­ме­сти­мость в боль­шин­стве случаев,
так что луч­ше оста­вить ее вклю­чен­ной, осо­бен­но если вы рабо­та­е­те в
высо­ко­ско­рост­ной сети (напри­мер LAN или 10mb Интер­нет). В случае
низ­ко­ско­рост­но­го соеди­не­ния (ска­жем модем­ное) вы пре­крас­но обой­де­тесь и
без этой опции, и будет даже луч­ше, если вы ее отклю­чи­те. Переменная
может при­ни­мать два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Значение
по-умол­ча­нию 1 (вклю­че­но). Более подроб­ную инфор­ма­цию вы най­де­те в
сек­ции 4 доку­мен­та RFC 1323 — TCP Extensions for High Performance.

> net.ipv4.tcp_tw_recycle = 0

Разрешает/запрещает быст­рую ути­ли­за­цию соке­тов, нахо­дя­щих­ся в состоянии
TIME-WAIT. Если вы не уве­ре­ны в сво­их дей­стви­ях, то вам луч­ше не трогать
эту пере­мен­ную. Пере­мен­ная при­ни­ма­ет целое чис­ло (а не буле­вое из
мое­го опы­та и мое­го пони­ма­ния исход­ных тек­стов ядра сле­ду­ет, что
опи­са­ние пере­мен­ной в linux/Documentation/ip-sysctl.txt содер­жит ошибку,
если я не оши­ба­юсь). Зна­че­ние по-умол­ча­нию 0. Не изме­няй­те эту
пере­мен­ную, если вы не уве­ре­ны в сво­их дей­стви­ях или не полу­чи­ли совет
от опыт­ных экс­пер­тов по ядру.

> net.ipv4.tcp_window_scaling = 1

Разрешает/запрещает мас­шта­би­ро­ва­ние TCP-окна, как опре­де­ле­но в RFC 1323.
В этом доку­мен­те опи­са­но как про­из­во­дит­ся мас­шта­би­ро­ва­ние TCP-окна при
пере­да­че по Large Fat Pipes (LFP тол­стый канал). При передаче
TCP-паке­тов по тол­стым кана­лам воз­ни­ка­ют суще­ствен­ные поте­ри пропускной
спо­соб­но­сти из-за того, что они не загру­же­ны пол­но­стью во вре­мя ожидания
под­твер­жде­ния о при­е­ме преды­ду­ще­го TCP-окна. Основ­ная про­бле­ма состо­ит в
том, что окно не может иметь раз­мер боль­ше, чем 216 байт (65 Кб).
Раз­ре­шая мас­шта­би­ро­ва­ние TCP-окна мы, тем самым, можем уве­ли­чить его
раз­мер и таким обра­зом умень­шить поте­ри про­пуск­ной способности.
Пере­мен­ная может при­ни­мать два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но).
Зна­че­ние по-умол­ча­нию 1 (вклю­че­но). Допол­ни­тель­ную инфор­ма­цию по этой
теме вы най­де­те в RFC 1323 — TCP Extensions for High Performance.

> net.ipv4.tcp_wmem = 4096 16384 4194304

Пере­мен­ная содер­жит три чис­ла, кото­рые исполь­зу­ют­ся при управлении
раз­ме­ра­ми буфе­ров пере­да­чи, выде­ля­е­мых для каж­до­го соке­та. Каж­дое из
зна­че­ний исполь­зу­ет­ся при опре­де­лен­ных усло­ви­ях. Пер­вое значение
мини­маль­ный раз­мер буфе­ра пере­да­чи для каж­до­го соке­та. Системой
гаран­ти­ру­ет­ся выде­ле­ние это­го про­стран­ства при откры­тии соке­та. Обычно
это зна­че­ние рав­но 4096 байт. Вто­рое зна­че­ние раз­мер пере­да­ю­ще­го буфера
по-умол­ча­нию. При попыт­ке уве­ли­чить раз­мер буфе­ра пере­да­чи боль­ше этого
огра­ни­че­ния, при­ло­же­ние может столк­нуть­ся с неже­ла­ни­ем систе­мы выделения
боль­ше­го объ­е­ма памя­ти при тяже­лых нагруз­ках. Это может даже при­ве­сти к
поте­ре паке­тов при очень высо­ких нагруз­ках. Зна­че­ние по-умол­ча­нию 16384
байт, или 16 Кб. Будет нера­зум­ным попы­тать­ся уве­ли­чить это значение.
Этот пара­метр пере­кры­ва­ет­ся пере­мен­ной /proc/sys/net/core/wmem_default,
кото­рая исполь­зу­ет­ся дру­ги­ми про­то­ко­ла­ми и, как пра­ви­ло, tcp_wmem должна
быть мень­ше чем /proc/sys/net/core/wmem_default. Тре­тье значение
мак­си­маль­ный раз­мер буфе­ра пере­да­чи для отдель­но­го соке­та. По-умолчанию
131072 байт, или 128 Кб. Это доста­точ­но разум­ное зна­че­ние и в
боль­шин­стве слу­ча­ев вам едва ли при­дет­ся кор­рек­ти­ро­вать его. Однако,
если вам при­дет­ся его уве­ли­чи­вать помни­те о суще­ство­ва­нии переменной
/proc/sys/net/core/wmem_max, кото­рая долж­на быть все­гда боль­ше чем
tcp_wmem. Эта пере­мен­ная может дать неко­то­рый при­рост производительности
на тол­стых кана­лах, если доста­точ­но кор­рект­но исполь­зу­ет­ся вме­сте с
пере­мен­ны­ми tcp_mem и tcp_rmem. tcp_wmem дает наи­боль­ший прирост
про­из­во­ди­тель­но­сти из этих трех пере­мен­ных. Заме­чу при этом, что вы
прак­ти­че­ски не полу­чи­те ника­ко­го выиг­ры­ша в сетях со ско­ро­стью передачи
менее 1 Гб. Допол­ни­тель­ную инфор­ма­цию, по настрой­ке пере­мен­ных, вы
най­де­те в TCP Tuning Guide.

> net.ipv4.icmp_echo_ignore_broadcasts = 1

Эта пере­мен­ная очень близ­ка по смыс­лу к icmp_echo_ignore_all, толь­ко в
дан­ном слу­чае будут игно­ри­ро­вать­ся ICMP сооб­ще­ния, отправ­лен­ные на
широ­ко­ве­ща­тель­ный или груп­по­вой адрес. Вполне оче­вид­но, поче­му полезно
вклю­чить этот пара­метр защи­та от smurf атак. Пере­мен­ная может принимать
два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0
(выклю­че­но).

> net.ipv4.icmp_ignore_bogus_error_responses = 1

Отдель­ные марш­ру­ти­за­то­ры, вопре­ки стан­дар­там, опи­сан­ным в RFC 1122,
отправ­ля­ют фик­тив­ные отве­ты в широ­ко­ве­ща­тель­ном диа­па­зоне. Обыч­но эти
ошиб­ки зано­сят­ся в систем­ный жур­нал. Если вы не жела­е­те регистрировать
их, то вклю­чи­те этот пара­метр и тем самым сбе­ре­же­те неко­то­рый объем
дис­ко­во­го про­стран­ства в сво­ей систе­ме. Пере­мен­ная может при­ни­мать два
зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0
(выклю­че­но).

> net.ipv4.icmp_ratelimit = 250

Мак­си­маль­ная часто­та гене­ра­ции ICMP-паке­тов с типом, ука­зан­ным в
icmp_ratemask (см. icmp_ratemask). Это зна­че­ние зада­ет­ся в тиках и
уста­нав­ли­ва­ет вре­мен­ной интер­вал меж­ду ICMP-посыл­ка­ми. Таким образом,
зна­че­ние 0 озна­ча­ет отсут­ствие огра­ни­че­ний. Обыч­но 1 тик равен 0.01
секун­ды, так зна­че­ние 1 в этой пере­мен­ной огра­ни­чи­ва­ет ско­рость передачи
не более 100 посы­лок в секун­ду, а зна­че­ние 100 не более 1 посыл­ки в
секун­ду. Зна­че­ние по-умол­ча­нию 100, что озна­ча­ет не более 1 ICMP
посыл­ки за интер­вал в 100 тиков.

> net.ipv4.icmp_ratemask = 6168

Мас­ка ICMP типов, на кото­рые накла­ды­ва­ет­ся огра­ни­че­ние по частоте
гене­ра­ции пере­мен­ной icmp_ratelimit. Каж­дый из ICMP типов маскируется
сво­им битом. icmp_ratemask это бито­вая мас­ка, где каж­дый ICMP тип
пред­став­лен сво­им битом. Соот­вет­ствие меж­ду сим­во­ли­че­ским назва­ни­ем ICMP
типа и его поряд­ко­вым номе­ром вы най­де­те в заго­ло­воч­ном файле
netinet/ip_icmp.h (обыч­но это /usr/include/netinet/ip_icmp.h). За
допол­ни­тель­ной инфор­ма­ци­ей обра­щай­тесь к RFC 792 — Internet Control
Message Protocol. Мате­ма­ти­че­ски мас­ка опре­де­ля­ет­ся так: где n принимает
зна­че­ния всех типов ICMP, кото­рые долж­ны быть огра­ни­че­ны. Например:
Огра­ни­чим пере­да­чу ICMP Destination Unreachable сооб­ще­ний. В
/usr/include/netinet/ip_icmp.h это­му типу соот­вет­ству­ет чис­ло 3.
Под­счи­та­ем зна­че­ние 23, что рав­но 8. Теперь нуж­но при­ба­вить это чис­ло к
име­ю­щей­ся бито­вой мас­ке. Допу­стим, что мас­ка уже рав­на чис­лу 6160 (в
дво­ич­ном виде 0001100000010000), тогда резуль­ти­ру­ю­щая мас­ка получится:
6160 + 8 = 6168 (в дво­ич­ном виде 0001100000011000). Перед добавлением
мас­ки подоб­ным обра­зом убе­ди­тесь сна­ча­ла, что нуж­ный вам бит сброшен,
ина­че вы полу­чи­те невер­ную мас­ку! К при­ме­ру, если у вас мас­ка является
чис­лом 256 и вы еще доба­ви­те чис­ло 256, то это при­ве­дет к
раз­мас­ки­ро­ва­нию ICMP Echo Request и мас­ки­ров­ке 9-го отсут­ству­ю­ще­го типа
ICMP. Зна­че­ние по-умол­ча­нию 6168 (в дво­ич­ном виде 0001100000011000),
что под­ра­зу­ме­ва­ет нало­же­ние огра­ни­че­ний на ICMP Destination Unreachable,
ICMP Source Quench, ICMP Time Exceeded и ICMP Parameter Problem, где
ICMP Destination Unreachable = 3, ICMP Source Quench = 4, ICMP Time
Exceeded = 11 и ICMP Parameter Problem = 12. Таким обра­зом, значение
по-умол­ча­нию соот­вет­ству­ет выра­же­нию: Зло­умыш­лен­ник может заставить
неко­то­рый марш­ру­ти­за­тор или хост зато­пить жерт­ву ICMP-посылками,
пере­да­ва­е­мы­ми в ответ на под­дель­ный ICMP пакет с обрат­ным адресом
жерт­вы. Поэто­му очень важ­но огра­ни­чить часто­ту гене­ра­ции отдель­ных видов
ICMP-сооб­ще­ний. На сай­те http://www.frozentux.net вы смо­же­те найти
неболь­шую про­грам­му ratemask, кото­рая может ока­зать­ся полез­ной при
созда­нии мас­ки для пере­мен­ной icmp_ratemasks или для дешифрации
суще­ству­ю­щей маски.

> net.ipv4.igmp_max_memberships = 20

Мак­си­маль­ное чис­ло групп на каж­дый сокет. Зна­че­ние по-умол­ча­нию 20 и
может быть изме­не­но по мере необходимости.

> net.ipv4.conf.all.accept_redirects = 0

Пере­мен­ная управ­ля­ет при­е­мом ICMP-сооб­ще­ний о пере­ад­ре­са­ции. Сообщения
ICMP Redirect исполь­зу­ют­ся для уве­дом­ле­ния марш­ру­ти­за­то­ров или хостов о
суще­ство­ва­нии луч­ше­го марш­ру­та дви­же­ния паке­тов к задан­но­му хосту,
кото­рый (марш­рут) может быть быст­рее или менее загру­жен. Переменная
может иметь два зна­че­ния 0 (выклю­че­но сооб­ще­ния о переадресации
игно­ри­ру­ют­ся) и 1 (вклю­че­но сооб­ще­ния о пере­ад­ре­са­ции принимаются).
Зна­че­ние по-умол­ча­нию 1 (вклю­че­но), одна­ко я посо­ве­то­вал бы отключать
эту опцию, посколь­ку она дале­ко небез­опас­на. В подав­ля­ю­щем большинстве
слу­ча­ев необ­хо­ди­мость в пере­ад­ре­са­ции отсут­ству­ет, поэто­му луч­ше держать
эту пере­мен­ную выклю­чен­ной, если конеч­но вы на 100% не уве­ре­ны в
обратном.

> net.ipv4.conf.all.accept_source_route = 0

Пере­мен­ная разрешает/запрещает марш­ру­ти­за­цию от источ­ни­ка. Маршрутизация
от источ­ни­ка весь­ма небез­опас­на. Допол­ни­тель­ную инфор­ма­цию по этой темы
вы смо­же­те почерп­нуть из ip-param.txt. Пере­мен­ная может иметь два
зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 1
(вклю­че­но).

> net.ipv4.conf.all.arp_filter = 0

Включает/выключает свя­зы­ва­ние IP-адре­са с ARP-адре­сом. Если эта опция
вклю­че­на, то ответ будет пере­да­вать­ся через тот интер­фейс, через который
посту­пил запрос. В прин­ци­пе, было бы не пло­хо, если бы отве­ты исходили
через тот же интер­фейс, через кото­рый был полу­чен запрос, одна­ко, в
отдель­ных слу­ча­ях, это может стать при­чи­ной оши­бок. Обыч­но включение
этой опции необ­хо­ди­мо толь­ко в том слу­чае, если на вашем хосте
про­из­во­дит­ся управ­ле­ние рас­пре­де­ле­ни­ем нагруз­ки меж­ду сетевыми
интер­фей­са­ми. Зна­че­ние по-умол­ча­нию 0 (выклю­че­но), посколь­ку эта опция
идет немно­го враз­рез с совре­мен­ным пони­ма­ни­ем прин­ци­пов IP-адресации.
Ранее IP-адре­са рас­смат­ри­ва­лись как путь к неко­то­ро­му устрой­ству, в
смыс­ле аппа­ра­ту­ры, теперь же их сле­ду­ет рас­смат­ри­вать как отдельную
служ­бу достав­ки, кото­рая долж­на выда­вать отве­ты на запро­сы вне
зави­си­мо­сти от того на какой интер­фейс эти запро­сы были получены.
Допол­ни­тель­ную инфор­ма­цию по дан­ной тема­ти­ке вы най­де­те в Guide to IP
Layer Network Administration with Linux.

> net.ipv4.conf.all.bootp_relay = 0

Пере­мен­ная разрешает/запрещает фор­вар­динг паке­тов с исхо­дя­щи­ми адресами
0.b.c.d. Демон BOOTP relay дол­жен пере­на­прав­лять эти паке­ты на
кор­рект­ный адрес. Пере­мен­ная может иметь два зна­че­ния 0 (выклю­че­но) и 1
(вклю­че­но). Зна­че­ние по-умол­ча­нию 0 (выклю­че­но). Обра­бот­ка переменной
bootp_relay еще не реа­ли­зо­ва­на. Если вы жела­е­те пред­ло­жить свою
реа­ли­за­цию мило­сти про­сим! С этой целью може­те всту­пить в кон­такт с
коман­дой раз­ра­бот­чи­ков netdev mailinglist.

> net.ipv4.conf.all.log_martians = 0

Пере­мен­ная включает/выключает функ­цию жур­на­ли­ро­ва­ния всех пакетов,
кото­рые содер­жат непра­виль­ные (невоз­мож­ные) адре­са (так называемые
martians мар­си­ан­ские паке­ты). Под невоз­мож­ны­ми адре­са­ми, в данном
слу­чае, сле­ду­ет пони­мать такие адре­са, кото­рые отсут­ству­ют в таблице
марш­ру­ти­за­ции. В неко­то­рых ситу­а­ци­ях эта опция поз­во­лит получить
допол­ни­тель­ную инфор­ма­цию, но вы долж­ны пони­мать, что эта инфор­ма­ция не
так подроб­на как мож­но было бы поду­мать. Основ­ны­ми причинами,
порож­да­ю­щи­ми запи­си в систем­ном жур­на­ле, могут быть: невозможность
пере­ад­ре­са­ции; пло­хая клас­си­фи­ка­ция; огра­ни­че­ния на широковещательные
сооб­ще­ния, или несо­от­вет­ствия в Forwarding Information Base (FIB).
Пере­мен­ная может иметь два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но).
Зна­че­ние по-умол­ча­нию 0 (выклю­че­но).

> net.ipv4.conf.all.mc_forwarding = 0

Включает/выключает под­держ­ку марш­ру­ти­за­ции груп­по­вых рас­сы­лок для
задан­но­го интер­фей­са. Кро­ме того, что­бы иметь под­держ­ку маршрутизации
груп­по­вых рас­сы­лок, необ­хо­ди­мо собрать ядро с вклю­чен­ной опцией
CONFIG_MROUTE. Допол­ни­тель­но в систе­ме дол­жен иметь­ся демон,
осу­ществ­ля­ю­щий груп­по­вую марш­ру­ти­за­цию. Его вы може­те полу­чить с
FTP-сай­та AT&T Research.. Этот демон реа­ли­зу­ет про­то­кол DVMRP (от англ.
Distance Vector Multicast Routing Protocol про­то­кол маршрутизации
груп­по­вых рас­сы­лок типа век­тор-рас­сто­я­ние). Еще один демон маршрутизации
груп­по­вых рас­сы­лок досту­пен на сай­те PIMd. Это реа­ли­за­ция разреженного
про­то­ко­ла PIM (от англ. Protocol Independent Multicast протокол
марш­ру­ти­за­ции груп­по­вых рас­сы­лок, неза­ви­си­мый от исполь­зу­е­мо­го протокола
марш­ру­ти­за­ции), или PIM-SM. Там же вы най­де­те ссыл­ки на другие
реа­ли­за­ции про­то­ко­лов PIM-DM (Protocol Independent Multicast-Dense Mode
про­то­кол марш­ру­ти­за­ции груп­по­вых рас­сы­лок, неза­ви­си­мый от используемого
про­то­ко­ла марш­ру­ти­за­ции, уплот­нен­но­го режи­ма) и PIM-SM (Protocol
Independant Multicast-Sparse Mode про­то­кол марш­ру­ти­за­ции групповых
рас­сы­лок, неза­ви­си­мый от исполь­зу­е­мо­го про­то­ко­ла маршрутизации,
раз­ре­жен­но­го режи­ма). Допол­ни­тель­ную инфор­ма­цию по груп­по­вой адресации
вы най­де­те в Multicast HOWTO. Груп­по­вая адре­са­ция исполь­зу­ет­ся в тех
слу­ча­ях, когда необ­хо­ди­мо выпол­нить достав­ку инфор­ма­ции сра­зу к
несколь­ким пунк­там назна­че­ния. Напри­мер, WEB-стра­нич­ка передается
отдель­но каж­до­му, кто ее запро­сил, а если несколь­ко чело­век решили
при­нять уча­стие в видео­кон­фе­рен­ции? Есть два пути реа­ли­за­ции доставки.
Либо каж­до­му участ­ни­ку отда­вать отдель­ный поток дан­ных (тогда трафик
будет таким огром­ным, что для него может про­сто не хва­тить пропускной
спо­соб­но­сти кана­ла), либо исполь­зо­вать груп­по­вую рас­сыл­ку. В этом случае
отпра­ви­тель созда­ет одну дей­та­грам­му с груп­по­вым адре­сом назна­че­ния, по
мере про­дви­же­ния через сеть дей­та­грам­ма будет дуб­ли­ро­вать­ся толь­ко на
раз­вил­ках марш­ру­тов от отпра­ви­те­ля к полу­ча­те­лям. Пере­мен­ная может иметь
два зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0
(выклю­че­но). Обра­ти­те вни­ма­ние нет ника­кой необ­хо­ди­мо­сти вклю­чать эту
опцию, если вы жела­е­те лишь полу­чать груп­по­вые паке­ты. Она необходима
толь­ко если вы соби­ра­е­тесь пере­на­прав­лять груп­по­вой тра­фик через вашу
систему.

> net.ipv4.conf.all.proxy_arp = 0

Включает/выключает прок­си­ро­ва­ние arp-запро­сов для задан­но­го интерфейса.
ARP-прок­си поз­во­ля­ет марш­ру­ти­за­то­ру отве­чать на ARP запро­сы в одну сеть,
в то вре­мя как запра­ши­ва­е­мый хост нахо­дит­ся в дру­гой сети. С помощью
это­го сред­ства про­ис­хо­дит обман отпра­ви­те­ля, кото­рый отпра­вил ARP
запрос, после чего он дума­ет, что марш­ру­ти­за­тор явля­ет­ся хостом
назна­че­ния, тогда как в дей­стви­тель­но­сти хост назна­че­ния нахо­дит­ся на
дру­гой сто­роне марш­ру­ти­за­то­ра. Марш­ру­ти­за­тор высту­па­ет в роли
упол­но­мо­чен­но­го аген­та хоста назна­че­ния, пере­кла­ды­вая паке­ты от другого
хоста. Пере­мен­ная может иметь два зна­че­ния 0 (выклю­че­но) и 1
(вклю­че­но). Зна­че­ние по-умол­ча­нию 0 (выклю­че­но). Дополнительную
инфор­ма­цию вы най­де­те в Proxy-ARP mini HOWTO.

> net.ipv4.conf.all.rp_filter = 1

Включает/выключает reverse path filter (про­вер­ка обрат­но­го адре­са хотя
это слиш­ком воль­ный пере­вод тер­ми­на, но мне он кажет­ся наи­бо­лее близким
по смыс­лу. прим. перев.) для задан­но­го интер­фей­са. Смысл этой переменной
доста­точ­но прост все что посту­па­ет к нам про­хо­дит про­вер­ку на
соот­вет­ствие исхо­дя­ще­го адре­са с нашей таб­ли­цей марш­ру­ти­за­ции и такая
про­вер­ка счи­та­ет­ся успеш­ной, если при­ня­тый пакет пред­по­ла­га­ет передачу
отве­та через тот же самый интер­фейс. Если вы исполь­зу­е­те расширенную
марш­ру­ти­за­цию тем или иным обра­зом, то вам сле­ду­ет все­рьез заду­мать­ся о
выклю­че­нии этой пере­мен­ной, посколь­ку она может послу­жить причиной
поте­ри паке­тов. Напри­мер, в слу­чае, когда вхо­дя­щий тра­фик идет через
один марш­ру­ти­за­тор, а исхо­дя­щий через дру­гой. Так, WEB-сервер,
под­клю­чен­ный через один сете­вой интер­фейс к вход­но­му роу­те­ру, а через
дру­гой к выход­но­му (в слу­чае, когда вклю­чен rp_filter), будет просто
терять вхо­дя­щий тра­фик, посколь­ку обрат­ный марш­рут, в таблице
марш­ру­ти­за­ции, задан через дру­гой интер­фейс. Пере­мен­ная может иметь два
зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0
(выклю­че­но). Одна­ко в неко­то­рых дис­три­бу­ти­вах по-умол­ча­нию эта
пере­мен­ная вклю­ча­ет­ся в стар­то­вых скрип­тах на эта­пе загруз­ки. Поэтому,
если у вас эта пере­мен­ная вклю­че­на, а вам надо ее выклю­чить просмотрите
стар­то­вые скрип­ты в ката­ло­ге rc.d. Более деталь­ную инфор­ма­цию об этой
пере­мен­ной вы най­де­те в RFC 1812 — Requirements for IP Version 4 Routers
на стра­ни­цах 46-49 (сек­ция 4.2.2.11), стра­ни­це 55 (сек­ция 4.3.2.7) и
стра­ни­це 90 (сек­ция 5.3.3.3). Если вы все­рьез зани­ма­е­тесь проблемами
марш­ру­ти­за­ции, то вам опре­де­лен­но при­дет­ся изу­чить этот документ.

> net.ipv4.conf.all.secure_redirects = 1

Включает/выключает режим без­опас­ной пере­ад­ре­са­ции. Если переменная
выклю­че­на, то будут при­ни­мать­ся любые сооб­ще­ния ICMP Redirect от любого
хоста из любо­го места. Если пере­мен­ная вклю­че­на, то сооб­ще­ния о
пере­ад­ре­са­ции будут вос­при­ни­мать­ся толь­ко от тех шлю­зов (gateways),
кото­рые име­ют­ся в спис­ке шлю­зов по-умол­ча­нию. С помо­щью этой опции можно
избе­жать боль­шин­ства лож­ных пере­ад­ре­са­ций, кото­рые могут быть
исполь­зо­ва­ны для пере­хва­та тра­фи­ка. Пере­мен­ная может иметь два значения
0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 1 (вклю­че­но).
Обра­ти­те вни­ма­ние дей­ствие этой пере­мен­ной отме­ня­ет­ся переменной
shared_media, так что, если вы вклю­ча­е­те secure_redirects, то необходимо
вклю­чить и shared_media.

> net.ipv4.conf.all.send_redirects = 1

Включает/выключает выда­чу ICMP Redirect дру­гим хостам. Эта опция
обя­за­тель­но долж­на быть вклю­че­на, если хост высту­па­ет в роли
марш­ру­ти­за­то­ра любо­го рода. Как пра­ви­ло ICMP-сооб­ще­ния о переадресации
отправ­ля­ют­ся в том слу­чае, когда необ­хо­ди­мо сооб­щить хосту о том, что он
дол­жен всту­пить в кон­такт с дру­гим сер­ве­ром. Пере­мен­ная может иметь два
зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 1
(вклю­че­но). Если ком­пью­тер не высту­па­ет в роли марш­ру­ти­за­то­ра, то эту
пере­мен­ную мож­но отключить.

> net.ipv4.conf.all.shared_media = 1

Включает/выключает при­знак того, что физи­че­ская сеть явля­ет­ся носителем
несколь­ких логи­че­ских под­се­тей, напри­мер, когда на одном физическом
кабе­ле орга­ни­зо­ва­но несколь­ко под­се­тей с раз­лич­ны­ми сете­вы­ми масками.
Этот при­знак исполь­зу­ет­ся ядром при при­ня­тии реше­ния о необходимости
выда­чи ICMP-сооб­ще­ний о пере­ад­ре­са­ции. Пере­мен­ная может иметь два
зна­че­ния 0 (выклю­че­но) и 1 (вклю­че­но). Зна­че­ние по-умол­ча­нию 0
(выклю­че­но). Эта пере­мен­ная пере­кры­ва­ет дей­ствие переменной
secure_redirects.

> net.ipv4.route.error_burst = 1250

Пере­мен­ная исполь­зу­ет­ся в паре с error_cost для огра­ни­че­ния количества
гене­ри­ру­е­мых сооб­ще­ний ICMP Unreachable. Эта переменная
несет в себе смысл верх­не­го пре­де­ла сто­и­мо­сти пере­да­чи сооб­ще­ний, в то
вре­мя как error_cost обо­зна­ча­ет цену одно­го сооб­ще­ния. Когда error_burst
опу­сто­ша­ет­ся, то пере­да­ча сооб­ще­ний ICMP Unreachable
пре­кра­ща­ет­ся. Сооб­ще­ния ICMP Unreachable обыч­но отсылаются
тогда, когда невоз­мож­но опре­де­лить даль­ней­ший марш­рут дви­же­ния пакета.
Это­му могут быть три при­чи­ны: 1. Невоз­мож­но выпол­нить пере­да­чу хосту. 2.
Не изве­стен марш­рут к задан­но­му сег­мен­ту сети или хосту. 3.Если данный
марш­рут запре­щен набо­ром пра­вил марш­ру­ти­за­ции. В этих трех случаях
сете­вая под­си­сте­ма гене­ри­ру­ет сооб­ще­ние ICMP Unreachable,
свое для каж­до­го слу­чая: 1. ICMP Host Unreachable когда хост,
нахо­дя­щий­ся в той же сети, что и наш роу­тер недо­сту­пен (т.е. не
отве­ча­ет на ARP-запро­сы. прим. перев.). 2. ICMP Network Unreachable
когда в таб­ли­це марш­ру­ти­за­ции роу­те­ра нет ни одно­го марш­ру­та, по
кото­ро­му пакет мог бы быть отправ­лен даль­ше. 3. ICMP Communication
Administratively Prohibited By Filtering когда пакет не может быть
пере­прав­лен из-за нали­чия пра­вил марш­ру­ти­за­ции явно запрещающих
пере­да­чу. Зна­че­ние по-умол­ча­нию 500. Учи­ты­вая зна­че­ние по-умолчанию
пере­мен­ной error_cost (100) это соот­вет­ству­ет 5-ти сооб­ще­ни­ям ICMP
Destination Unreachables в секунду.

> net.ipv4.route.error_cost = 250

Более подроб­ное опи­са­ние см. выше error_burst. Основ­ной смысл этой
пере­мен­ной цена одно­го сооб­ще­ния ICMP Destination Unreachable. Значение
по-умол­ча­нию 100, что под­ра­зу­ме­ва­ет пере­да­чу не более 5-ти сообщений
ICMP Destination Unreachable за 1 секун­ду (если рас­чет про­из­во­дить с
уче­том зна­че­ния по-умол­ча­нию пере­мен­ной error_burst).

> net.ipv4.ipfrag_high_thresh = 262144

Пере­мен­ная зада­ет мак­си­маль­ный объ­ем памя­ти, выде­ля­е­мый под очередь
фраг­мен­ти­ро­ван­ных паке­тов. Когда дли­на оче­ре­ди дости­га­ет это­го порога,
то обра­бот­чик фраг­мен­тов будет отвер­гать все фраг­мен­ти­ро­ван­ные паке­ты до
тех пор, пока дли­на оче­ре­ди не умень­шит­ся до зна­че­ния переменной
ipfrag_low_thresh. Это озна­ча­ет, что все отверг­ну­тые фрагментированные
паке­ты долж­ны быть повтор­но пере­да­ны узлом-отпра­ви­те­лем. Пакеты
фраг­мен­ти­ру­ют­ся в том слу­чае, если их раз­мер слиш­ком велик, что­бы быть
пере­дан­ны­ми по дан­но­му кана­лу. Узел-отпра­ви­тель, в этом слу­чае, режет
паке­ты на более мел­кие части и затем пере­да­ет их одну за дру­гой. На
узле-полу­ча­те­ле эти фраг­мен­ты опять соби­ра­ют­ся в пол­но­цен­ный пакет.
При­ме­ча­тель­но, что идея фраг­мен­та­ции паке­тов, сама по себе, вещь
заме­ча­тель­ная, но, к сожа­ле­нию, может быть исполь­зо­ва­на в весьма
небла­го­вид­ных целях. Пере­мен­ная содер­жит целое чис­ло в диа­па­зоне 0 ..
2147483647 и озна­ча­ет верх­ний порог дли­ны оче­ре­ди фраг­мен­тов в байтах.
Зна­че­ние по-умол­ча­нию 262144 байт, или 256 Кб. Это­го коли­че­ства, как
пра­ви­ло, вполне доста­точ­но даже для самых край­них случаев.