suffixes

title: suffixes(7)

summary: список суффиксов имён файлов

text:
# suffixes(7)

## ИМЯ
suffixes - список суффиксов имён файлов

## ОПИСАНИЕ
Обычно, чтобы указать на содержимое файла, в конец имени добавляют суффикс, который состоит из точки и одной или нескольких букв. Многие стандартные утилиты, такие как компиляторы, используют это, чтобы распознать тип файла, который им передан. Утилита make(1) работает по правилам на основе суффиксов файлов.

Ниже представлен список суффиксов, которые, вероятно, можно найти в системе Linux.

Суффикс

Тип файла

,v

файлы RCS (Revision Control System)

-

резервная копия файла

.C

исходный код C++, эквивалент .cc

.F

исходный код Fortran с директивами cpp(1)

или файл, сжатый с помощью freeze

.S

исходный код ассемблера с директивами cpp(1)

.Y

файл, сжатый с помощью yabba

.Z

файл, сжатый с помощью compress(1)

.[0-9]+gf

файлы обычных шрифтов TeX

.[0-9]+pk

файлы упакованных шрифтов TeX

.[1-9]

справочная страница из соответствующего раздела

.[1-9][a-z]

справочная страница из раздела плюс подраздел

.a

библиотека статического объектного кода

.ad

файл ресурсов по умолчанию приложения для X

.ada

исходный код на языке Ада (тело, спецификация или оба сразу)

.adb

исходный код тела на языке Ада

.ads

исходный код спецификации на языке Ада

.afm

метрика шрифта PostScript

.al

автозагружаемый файл Perl

.am

входной файл для automake(1)

.arc

архив arc(1)

.arj

архив arj(1)

.asc

данные в кодировке ASCII, защищённые PGP

.asm

файл исходного кода на ассемблере (GNU)

.au

Звуковой файл

.aux

вспомогательный файл LaTeX

.avi

видео (msvideo)

.awk

программа на языке AWK

.b

образ системного загрузчика LILO

.bak

резервная копия файла

.bash

сценарий оболочки bash(1)

.bb

данные простого блочного листинга, созданные

gcc -ftest-coverage

.bbg

данные простого блочного графа, созданные

gcc -ftest-coverage

.bbl

вывод BibTeX

.bdf

файл шрифта X

.bib

библиографическая база данных TeX, входные данные BibTeX

.bm

исходный текст для растровых изображений

.bmp

bitmap

.bz2

файл, сжатый с помощью bzip2(1)

.c

исходный код на языке Си

.cat

файлы каталога сообщений

.cc

исходный код на языке Си++

.cf

файл с настройками

.cfg

файл с настройками

.cgi

сценарий или программа, генерирующая информацию для WWW

.cls

определение класса LaTeX

.class

скомпилированный байт-код Java

.conf

файл с настройками

.config

файл с настройками

.cpp

эквивалентно .cc

.csh

сценарий оболочки csh(1)

.cxx

эквивалентно .cc

.dat

файл данных

.deb

пакет ПО Debian

.def

исходный код Modula-2 для определения модулей

.def

файлы других определений

.desc

начальная часть почтового сообщения, распакованного

munpack(1)

.diff

файл различий (результат команды diff(1))

.dir

каталожный файл базы данных dbm

.doc

файл документации

.dsc

Debian Source Control (пакет с исходным кодом)

.dtx

исходный файл пакета LaTeX

.dvi

вывод TeX для независимого устройства

.el

исходный код на языке Emacs-Lisp

.elc

скомпилированный код на языке Emacs-Lisp

.eps

инкапсулированный PostScript

.exp

исходный код на языке Expect

.f

исходный код на языке Фортран

.f77

исходный код на языке Фортран77

.f90

исходный код на языке Фортран90

.fas

прекомпилированный Common-Lisp

.fi

включаемые файлы на языке Фортран

.fig

файл изображения FIG (используется xfig(1))

.fmt

форматный файл TeX

.gif

файл в формате Compuserve Graphics Image File

.gmo

каталог сообщений в формате GNU

.gsf

шрифты Ghostscript

.gz

файл, сжатый с помощью gzip(1)

.h

заголовочные файлы C или C++

.help

файл справки

.hf

эквивалентно .help

.hlp

эквивалентно .help

.htm

сокращение .html

.html

документ HTML, используемый в World Wide Web

.hqx

файл Macintosh в 7-битной кодировке

.i

файл исходного кода на C после предварительной обработки

.icon

исходный текст для растровых изображений

.idx

файл ссылок или список данных для гипертекста

или системы базы данных

.image

исходный текст для растровых изображений

.in

шаблон конфигурации, в частности для GNU Autoconf

.info

файлы для навигатора по информации Emacs

.info-[0-9]+

раздельные файлы info

.ins

файл установочного пакета LaTeX для docstrip

.itcl

файл исходного кода для itcl;

itcl ([incr Tcl]) — объектно-ориентированное расширение tcl

.java

файл исходного кода на языке Java

.jpeg

формат Joint Photographic Experts Group

.jpg

сокращение .jpeg

.kmap

клавиатурная раскладка lyx(1)

.l

эквивалентно файлам .lex или .lisp

.lex

lex(1) или flex(1)

.lha

архив lharc

.lib

библиотека Common-Lisp

.lisp

исходный код на языке Lisp

.ln

файлы для lint(1)

.log

файл журнала, в частности, создаваемый TeX

.lsm

запись для Linux Software Map

.lsp

исходный код на языке Common-Lisp

.lzh

архив lharc

.m

исходный код на языке Objective-C

.m4

исходный код на языке m4(1)

.mac

файлы макросов для различных программ

.man

справочная страница (обычно, исходный текст, а не отформатированная)

.map

файлы карт для различных программ

.me

исходный код для nroff, в котором используется пакет макросов me

.mf

исходный код для metafont (генератор шрифтов для TeX)

.mgp

файл MagicPoint

.mm

исходный код для groff(1) в формате mm

.mo

двоичный файл каталога сообщений

.mod

исходный код на языке Modula-2 для реализации модулей

.mov

видео (quicktime)

.mp

исходный код для Metapost

.mp2

файл MPEG Layer 2 (аудио)

.mp3

файл MPEG Layer 3 (аудио)

.mpeg

видео файл

.o

объектный файл

.old

старый файл или резервная копия

.orig

резервная версия файла (до изменений), созданная patch(1)

.out

файл результата, часто исполняемая программа (a.out)

.p

файл исходного кода на языке Pascal

.pag

файл базы данный dbm

.patch

файл различий для patch(1)

.pbm

переносимый формат растровой графики

.pcf

файлы шрифтов X11

.pdf

переносимый формат данных Adobe

(используется в Acrobat/acroread или xpdf)

.perl

исходный код на языке Perl (смотрите .ph, .pl и .pm)

.pfa

файлы описания шрифтов PostScript в формате ASCII

.pfb

файлы описания шрифтов PostScript в двоичном формате

.pgm

переносимый формат полутонов

.pgp

двоичные данные PGP

.ph

файл заголовка Perl

.php

файл программы на языке PHP

.php3

файл программы на языке PHP3

.pid

файл для хранения PID службы (например, crond.pid)

.pl

файл списка свойств TeX или библиотечный файл Perl

.pm

модуль Perl

.png

файл в формате Portable Network Graphics

.po

исходный файл каталога сообщений

.pod

файл для perldoc(1)

.ppm

переносимый формат pixmap

.pr

исходный текст для растровых изображений

.ps

файл PostScript

.py

файл исходного кода на языке Python

.pyc

скомпилированный python

.qt

видео quicktime

.r

исходный код для RATFOR (устарел)

.rej

заплаты, которые patch(1) не удалось наложить

.rpm

ПО в пакете RPM

.rtf

файл в формате Rich Text Format

.rules

правила чего-нибудь

.s

исходный код на ассемблере

.sa

библиотеки-заглушки для общих библиотек a.out

.sc

электронная таблица с командами sc(1)

.scm

исходный код на языке Scheme

.sed

файл исходного кода для sed

.sgml

файл исходного кода на языке SGML

.sh

сценарии sh(1)

.shar

архив, созданный утилитой shar(1)

.so

общая библиотека или динамически загружаемый объект

.sql

исходный код на языке SQL

.sqml

схема SQML или программа-запрос

.sty

файлы стилей LaTeX

.sym

скомпилированные модули определений Modula-2

.tar

архив, созданный утилитой tar(1)

.tar.Z

архив tar(1), сжатый с помощью compress(1)

.tar.bz2

архив tar(1), сжатый с помощью bzip2(1)

.tar.gz

архив tar(1), сжатый с помощью gzip(1)

.taz

архив tar(1), сжатый с помощью compress(1)

.tcl

исходный код на языке tcl

.tex

исходный код на языке TeX или LaTeX

.texi

эквивалентно .texinfo

.texinfo

исходный код документации в формате Texinfo

.text

текстовый файл

.tfm

файл метрики шрифта TeX

.tgz

архив tar, сжатый с помощью gzip(1)

.tif

сокращение .tiff

.tiff

размеченный формат файлов изображений (TIFF)

.tk

сценарий на tcl/tk

.tmp

временный файл

.tmpl

файлы шаблонов

.txt

эквивалентно .text

.uu

эквивалентно .uue

.uue

двоичный файл, закодированный с помощью uuencode(1)

.vf

файл виртуального шрифта TeX

.vpl

файл виртуального списка свойств TeX

.w

CWEB Сильвио Леви

.wav

звуковой файл

.web

WEB Дональда Кнута

.wml

исходный файл для Web Meta Language

.xbm

исходный текст для растровых изображений X11

.xcf

графика GIMP

.xml

файл на языке eXtended Markup Language

.xpm

исходный код изображений X11

.xs

файл Perl xsub, создаваемый h2xs

.xsl

таблица стилей XSL

.y

файлы для yacc(1) или bison(1) (генератор разборщика)

.z

файл, сжатый с помощью pack(1) (или старой версией gzip(1))

.zip

архив zip(1)

.zoo

архив zoo(1)

~

резервная копия файла Emacs или patch(1)

rc

файл запуска («run control»), например .newsrc

## СООТВЕТСТВИЕ СТАНДАРТАМ
Условные обозначения UNIX.

## ДЕФЕКТЫ
Этот список далеко не полон.

## СМОТРИТЕ ТАКЖЕ
file(1), make(1)


symlink

package: man-pages-ru

title: symlink(7)

summary: работа с символьными ссылками

text:
# symlink(7)

## ИМЯ
symlink - работа с символьными ссылками

## ОПИСАНИЕ
Символьные ссылки — это файлы, которые служат указателями на другие файлы. Чтобы понять их работу, сперва вы должны понять как работают жёсткие ссылки.

Жёсткая ссылка на файл не отличима от оригинального файла, так как это ссылка на объект, на который указывает оригинальное имя файла (более точно: каждая из жёстких ссылок на файл — это ссылка на один номер inode, где номер inode — индекс в таблице inode, в которой содержатся метаданные о всех файлах файловой системы; смотрите stat(2)). Изменения файла не зависят от используемого при этом имени файла. Жёсткие ссылки не могут указывать на каталоги (чтобы не возникало петель в дереве файловой системы, что могло бы привести к неправильной работе многих программ) и на файлы из разных файловых систем (так как номера inode не уникальны в файловых системах).

Символьная ссылка — это специальный тип файла, чьё содержимое представляет собой строку, содержащую имя другого файла — файла, на который указывает ссылка (содержимое символьной ссылки можно прочитать с помощью readlink(2)). Другими словами, символьная ссылка — это указатель на другое имя, а не на сам объект. В следствии этого, символьные ссылки могут указывать на каталоги и могут указывать на файлы в разных файловых системах.

Объект с именем, на которое ссылается символьная ссылка, может не существовать. Символьную ссылку, указывающую на не существующее имя, называют оборванной ссылкой (dangling link).

Поскольку символьная ссылка и объект, на который она ссылается, сосуществуют в пространство имён файловой системы, можно запутаться при различении самой ссылки и объекта, на который она ссылается. Старые системы, команды и системные вызовы имели собственные соглашения о ссылках, специально для этого созданные. Здесь в общих чертах описаны правила, которые одинаково реализованы в Linux и других системах. Важно, чтобы локальное приложение также соответствовало этим правилам, и пользовательский интерфейс был максимально одинаков.

### Владельцы, права и отметки времени символьных ссылок
Владельца и группу существующей символьной ссылки можно изменить с помощью lchown(2). Владельцы символьной ссылки учитываются только, когда символьная ссылка удаляется или переименовывается в каталоге, на котором установлен бит закрепления (sticky bit) (смотрите stat(2)).

Время последнего обращения и изменения символьной ссылки можно изменять с помощью utimensat(2) или lutimes(3).

В Linux права на символьную ссылку при операциях не учитываются; права всегда имеют значение 0777 (чтение, запись и исполнение для всех категорий пользователей) и это нельзя изменить (заметим, что есть несколько «магических» символьных ссылок в дереве каталогов /proc — например, файлы /proc/[pid]/fd/* — с другим набором прав).

### Получение файлового дескриптора, который указывает на символьную ссылку
Для работы с самой символьной ссылкой (а не файлом, на который она указывает) нужно указать комбинацию флагов O_PATH и O_NOFOLLOW вызов open(2) вернёт файловый дескриптор, который можно передавать в аргументе dirfd в такие системные вызовы как fstatat(2), fchownat(2), fchmodat(2), linkat(2) и readlinkat(2).

По умолчанию (т. е., если не указан флаг AT_SYMLINK_FOLLOW), если name_to_handle_at(2) вызывается для символьной ссылки, то он возвращает описатель символьной ссылки (а не файла, на который она указывает). Затем с его помощью можно получить файловый дескриптор символьной ссылки (а не файла, на который она указывает), указав флаг O_PATH в последующем вызове open_by_handle_at(2). Данный файловый дескриптор можно использовать в вышеупомянутых системных вызовах для работы с самой символьной ссылкой.

### Трактовка символьных ссылок в системных вызовах и командах
При работе с символьными ссылками можно воздействовать на сами символьные ссылки или на объекты, на которые они указывают. В последнем случае про приложение или системный вызов говорят, что он переходит (follow) по ссылке. Символьные ссылки могут указывать на другие символьные ссылки; в этом случае ссылки разыменовываются до нахождения объекта, который не является символьной ссылкой, символьной ссылки, которая указывает на несуществующий файл, или до обнаружения зацикливания (обнаружение зацикливания выполняется заданием максимального количества переходов по ссылкам, при превышении которого возвращается ошибка).

Есть три области, которые требуют обсуждения:

1.

Использование символьных ссылок в виде имён файлов в аргументах системных вызовов.

2.

Символьные ссылки, указываемые в аргументах командной строки утилит, которые не выполняют обход дерева файлов.

3.

Символьные ссылки, встреченные утилитами при обходе дерева файлов (задаваемые в командной строке или встреченные как часть файла при обходе иерархии).

### Системные вызовы
Рассмотрим использование символьных ссылок в виде имён файлов в аргументах системных вызовов.

За исключениями, описанными ниже, все системные вызовы переходят по символьным ссылкам. Например, если есть символьная ссылка slink, которая указывает на файл с именем afile, то системный вызов open("slink" ...) вернёт файловый дескриптор, ссылающийся на файл afile.

Некоторые системные вызовы не переходят по ссылкам, а работают с самими ссылками: lchown(2), lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2), rename(2), rmdir(2) и unlink(2).

Другие системные вызовы могут переходить по ссылкам: faccessat(2), fchownat(2), fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2) и utimensat(2); подробности смотрите в их справочных страницах. Так как remove(3) является псевдонимом unlink(2), библиотечная функция также не переходит по символьным ссылкам. При указании символьной ссылки rmdir(2) вызов завершается с ошибкой ENOTDIR.

Вызов link(2) заслуживает отдельного описания. В POSIX.1-2001 говорится, что link(2) должен разыменовывать oldpath, если это символьная ссылка. Однако в Linux этого не делается (по умолчанию Solaris делается тоже самое, но в POSIX.1-2001 определяется как такое поведение можно получить с помощью специальных параметров компилятора). В POSIX.1-2008 изменено описание, которое позволяет реализовывать любое из этих вариантов поведения.

### Команды, не выполняющие обход дерева файлов
Рассмотрим случай с символьными ссылками, указываемыми в аргументах командной строки утилит, которые не выполняют обход дерева файлов.

За исключением, описанным далее, команды переходят по ссылкам, указанным в аргументах командной строки. Например, если slink — символьная ссылка, которая указывает на файл с именем afile, то команда cat slink выведет содержимое файла afile.

Важно понимать, что это правило учитывается командами, которые не обязательно выполняют обход дерева файлов; например, команда chown file следует этому правилу, а команда chown -R file, выполняющая обход дерева, нет (последняя описана далее).

Если команде явно указано воздействовать на символьную ссылку, а не переходить по символьной ссылке, например, требуется, чтобы chown slink изменила права на файл slink, независимо от того, является ли он символьной ссылкой или нет, то нужно использовать параметр -h. В примере выше chown root slink изменяет права на файл, на который указывает slink, а chown -h root slink изменяет права на саму ссылку slink.

Есть несколько исключений из этого правила:

- Команды mv(1) и rm(1) не переходят по символьным ссылкам, указанным в аргументах, а пытаются переименовать и удалить их (заметим, если символьная ссылка указывает на файл через относительный путь, то перемещение файла в другой каталог с большой вероятностью вызовет проблемы, так как путь может оказаться неправильным).

- Команда ls(1) также является исключением из этого правила. Для совместимости со старыми системами (когда ls(1) не делает обход дерева, то есть не указан параметр -R), команда ls(1) переходит по символьным ссылкам, указанным в аргументах, если задан параметр -H или -L, или если не указан параметр -F, -d или -l (команда ls(1) — единственная команда, у которой параметры -H и -L влияют на поведение даже когда не выполняется обход дерева файлов).

- Команда file(1) также является исключением из этого правила. По умолчанию file(1) не переходит по символьной ссылке, указанной в аргументе. Команда file(1) переходит по символьной ссылке, указанной в аргументе, если указан параметр -L.

### Команды, выполняющие обход дерева файлов
Следующие команды могут или всегда обходят дерево файлов: chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1) и tar(1).

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

Первое правило применяется к символьным ссылкам, которые указывают на файлы, а не на каталоги. Операции, которые применимы к символьным ссылкам, выполняются с самими ссылками, но другие ссылки игнорируется.

Команда rm -r slink каталог удалит slink, а также все символьные ссылки, обнаруженные при обходе каталога, так как символьные ссылки могут быть удалены. Команда rm(1) никогда не удаляет файл, на который указывает slink.

Второе правило применяется к символьным ссылкам, которые указывают на каталоги. По умолчанию такие символьные ссылки никогда не разыменовываются. Часто об этом говорят как о «физическом» обходе, в противовес «логическому» обходу (когда выполняется переход по символьным ссылкам, указывающем на каталог).

При обходе дерева файлов командами соблюдаются (должны) определённые соглашения, если это возможно:

*

Команду можно заставить перейти по любой символьной ссылке, указанной в командной строке, независимо от типа файла, на который она ссылаются, указав параметр -H (от «half-logical»). Этот параметр заставляет пространство имён командной строки выглядеть как логическое пространство имён (заметим, что команды, которые не всегда делают обход дерева файлов, будут игнорировать флаг -H, если также не указан флаг -R).

Например, команда chown -HR user slink выполнит обход файловой иерархии с корнем как у файла, указанном slink. Заметим, что здесь -H делает не тоже самое, что и флаг -h, описанный ранее. При флаге -H символьные ссылки, указанные в командной строке, будут разыменовываться и при обходе файлового дерева и как если бы пользователь указал имя файла, на которое указывает символьная ссылка.

*

Команду можно заставить перейти по любой символьной ссылке, указанной в командной строке, а также по всем символьным ссылкам, встреченным при обходе, независимо от типа файла, на который она ссылается, указав параметр -H (от «half-logical»). Этот параметр заставляет всё пространство имён выглядеть как логическое пространство имён (заметим, что команды, которые не всегда делают обход дерева файлов, будут игнорировать флаг -L, если также не указан флаг -R).

Например, команда chown -LR user slink изменит владельца файла, на который указывает slink. Если slink указывает на каталог, то chown обойдёт дерево файлов с корнем в этом каталоге. Также, если символьные ссылки встречаются в любом файловом дереве, которое обходит chown, то с ними будет сделано тоже что и с slink.

*

Команду можно заставить следовать поведению по умолчанию, указав флаг -P (от «physical»). Этот флаг предназначен для работы со всем пространством имён как с физическим пространством имён.

Команды, которые по умолчанию не выполняют обход дерева файлов, игнорируют флаги -H, -L и -P, если не указан флаг -R. Также вы можете указать параметры -H, -L и -P более одного раза; последний указанный параметр определяет поведение команды. Это позволяет создавать псевдонимы команд с некоторым поведением, а затем переопределять это поведение в командной строке.

У команд ls(1) и rm(1) есть исключения из этих правил:

- Команда rm(1) работает с символьными ссылками, а не с файлами, на который они ссылаются, и поэтому никогда не переходит по символьной ссылке. Команда rm(1) не поддерживает параметры -H, -L и -P.

- Для совместимости со старыми системами работа команды ls(1) чуть отличается. Если не указан параметр -F, -d или -l, то ls(1) переходит по символьной ссылке, указанной в командной строке. Если указан флаг -L, то ls(1) переходит по всем символьным ссылкам независимо от их типа и где они встретились — в командной строке или при обходе дерева.

## СМОТРИТЕ ТАКЖЕ
chgrp(1), chmod(1), find(1), ln(1), ls(1), mv(1), namei(1), rm(1), lchown(2), link(2), lstat(2), readlink(2), rename(2), symlink(2), unlink(2), utimensat(2), lutimes(3), path_resolution(7)

branch: sisyphus


sysvipc

title: sysvipc(7)

text:
# sysvipc(7)

## ИМЯ
sysvipc - механизмы межпроцессного взаимодействия System V

## ОБЗОР

```
#include <sys/msg.h>
#include <sys/sem.h>
#include <sys/shm.h>
```

## ОПИСАНИЕ
Данная справочная страница описывает реализацию механизмов межпроцессного взаимодействия (IPC) System V в Linux: очереди сообщений, наборы семафоров и сегменты разделяемой памяти. В дальнейшем под словом ресурс будет подразумеваться экземпляр одного из этих механизмов.

### Права доступа к ресурсу
Для каждого ресурса система использует общую структуру типа struct ipc_perm, хранящую необходимую информацию о правах для проведения IPC-операции. Структура ipc_perm включает следующие поля:

```
struct ipc_perm {

    uid_t          cuid;   /* ID пользователя создателя */

    gid_t          cgid;   /* ID группы создателя */

    uid_t          uid;    /* ID пользователя владельца */

    gid_t          gid;    /* ID группы владельца */

    unsigned short mode;   /* права для чтения-записи */
};
```

Поле mode из структуры ipc_perm определяет в нижних 9 битах права доступа к ресурсу для вызвавшего системный вызов IPC процесса. Права определены следующим образом:

```
    0400    Чтение пользователем

    0200    Запись пользователем

    0040    Чтение группой

    0020    Запись группой

    0004    Чтение остальными

    0002    Запись остальными
```

Биты 0100, 0010 и 0001 (биты запуска) системой не используется. Кроме того, «запись» для набора семафоров на самом деле означает «изменение».

Тот же системный заголовочный файл определяет следующие символические константы:

IPC_CREAT

Создать запись, если ключ не существует.

IPC_EXCL

Завершиться ошибкой, если ключ существует.

IPC_NOWAIT

Ошибка, если запрос должен ждать.

IPC_PRIVATE

Частный ключ.

IPC_RMID

Удалить ресурс.

IPC_SET

Установить параметры ресурса.

IPC_STAT

Получить параметры ресурса.

Заметьте, что IPC_PRIVATE является типом key_t, когда как остальные символические константы являются флагами и могут быть объединены с помощью логического ИЛИ в переменную типа int.

### Очереди сообщений
Очередь сообщений уникально идентифицируется положительным целым (msqid) и имеет связанную структуру данных struct msqid_ds, определенную в <sys/msg.h> и содержащую следующие поля:

```
struct msqid_ds {

    struct ipc_perm msg_perm;

    msgqnum_t       msg_qnum;    /* в очереди не сообщений */

    msglen_t        msg_qbytes;  /* макс. байт в очереди */

    pid_t           msg_lspid;   /* PID последнего вызова  msgsnd(2) */

    pid_t           msg_lrpid;   /* PID последнего вызова msgrcv(2) */

    time_t          msg_stime;   /* время последнего msgsnd(2) */

    time_t          msg_rtime;   /* время последнего  msgrcv(2) */

    time_t          msg_ctime;   /* последнее время изменения */
};
```

msg_perm

Структура ipc_perm, определяющая права доступа к очереди сообщений.

msg_qnum

Число сообщений, находящихся в данный момент в очереди сообщений.

msg_qbytes

Максимальная длина сообщения в байтах, разрешенная в очереди сообщений.

msg_lspid

ID процесса, выполнившего последний системный вызов msgsnd(2).

msg_lrpid

ID процесса, выполнившего последний системный вызов msgrcv(2).

msg_stime

Время последнего вызова msgsnd(2).

msg_rtime

Время последнего вызова msgrcv(2).

msg_ctime

Время последнего системного вызова, изменившего поля структуры msgid_ds.

### Наборы семафоров
Набор семафора уникально идентифицируется положительным целым (semid) и имеет связанную структуру типа struct semid_ds, определенную в <sys/sem.h> и содержащую следующие поля:

```
struct semid_ds {

    struct ipc_perm sem_perm;

    time_t          sem_otime;   /* время последней операции */

    time_t          sem_ctime;   /* время последнего изменения */

    unsigned long   sem_nsems;   /* число семафоров в наборе */
};

```

sem_perm

Структура ipc_perm, определяющая права доступа к набору семафоров.

sem_otime

Время последнего системного вызова semop(2).

sem_ctime

Время последнего системного вызова semctl(2), который изменил поле указанной структуры или один из семафоров, принадлежащих набору.

sem_nsems

Число семафоров в наборе. Каждый семафор описывается неотрицательным целым числом от 0 до sem_nsems-1.

Семафор является структурой данных типа struct sem, содержащие следующие поля:

```
struct sem {

    int semval;  /* значение семафора */

    int sempid;  /* PID последнего изменившего процесса */
};
```

semval

Значение семафора, неотрицательное целое.

sempid

PID последнего процесса, изменившего значение данного семафора.

### Сегменты общей памяти
Сегмент общей памяти уникально идентифицируется положительным целым (shmid) и имеет связанную структуру данных struct shmid_ds, определённую в <sys/shm.h> и содержащую следующие поля:

```
struct shmid_ds {

    struct ipc_perm shm_perm;

    size_t          shm_segsz;   /* размер сегмента */

    pid_t           shm_cpid;    /* PID создателя */

    pid_t           shm_lpid;    /* PID последней операции */

    shmatt_t        shm_nattch;  /* число текущих подключений */

    time_t          shm_atime;   /* время последнего подключения */

    time_t          shm_dtime;   /* время последнего отключения */

    time_t          shm_ctime;   /* время последнего изменения */
};
```

shm_perm

Структура ipc_perm, описывающая права доступа к сегменту общей памяти.

shm_segsz

Размер в байтах сегмента общей памяти.

shm_cpid

ID процесса, создавшего сегмент общей памяти.

shm_lpid

ID последнего процесса, выполнившего системный вызов shmat(2) или shmdt(2).

shm_nattch

Количество текущих подключений для данного сегмента общей памяти.

shm_atime

Время последнего системного вызова shmat(2).

shm_dtime

Время последнего системного вызова shmdt(2).

shm_ctime

Время последнего системного вызова shmctl(2), изменившего shmid_ds.

### Пространства имён IPC
Обсуждение связи объектов System V IPC с пространствами IPC смотрите в ipc_namespaces(7).

## СМОТРИТЕ ТАКЖЕ
ipcmk(1), ipcrm(1), ipcs(1), lsipc(1), ipc(2), msgctl(2), msgget(2), msgrcv(2), msgsnd(2), semctl(2), semget(2), semop(2), shmat(2), shmctl(2), shmdt(2), shmget(2), ftok(3), ipc_namespaces(7)


tcp

title: tcp(7)

summary: протокол TCP

text:
# tcp(7)

## ИМЯ
tcp - протокол TCP

## ОБЗОР
\#include <sys/socket.h>

\#include <netinet/in.h>

\#include <netinet/tcp.h>

tcp_socket = socket(AF_INET, SOCK_STREAM, 0);

## ОПИСАНИЕ
Эта реализация протокола TCP, описанного в RFC 793, RFC 1122 и RFC 2001 с расширениями NewReno и SACK. Данный протокол предоставляет пользователю надёжное полнодуплексное соединение двух сокетов для потоковой передачи поверх ip(7) версий v4 и v6. TCP гарантирует доставку данных в правильном порядке и повторно передаёт потерявшиеся пакеты. Для выявления ошибок передачи протоколом генерируются и проверяются контрольные суммы пакетов. TCP не сохраняет границы записей.

Только что созданный сокет TCP не имеет локального или удалённого адреса и не является полностью определённым. Для создания исходящего соединения TCP с другим сокетом TCP используйте connect(2). Для приёма новых входящих соединений сперва подключите сокет к локальному адресу и порту с помощью bind(2), а затем вызовите listen(2) для перевода сокета в режим прослушивания. После этого через новый сокет можно принимать каждое входящее соединение с помощью accept(2). Сокет, для которого успешно отработали accept(2) или connect(2), является полностью определённым и может передавать данные. Данные не могут быть переданы через слушающий или ещё не соединённый сокет.

Linux поддерживает высокопроизводительные расширения TCP RFC 1323. Они включают в себя: защиту против оборотной последовательности номеров (PAWS), масштабирование окна и метки времени. Масштабирование окна позволяет использовать большие (> 64 КБ) окна TCP для поддержки соединений с большой задержкой или высокой пропускной способностью. Для их использования необходимо увеличить размеры буферов приёма и передачи. Это можно сделать глобально через файлы /proc/sys/net/ipv4/tcp_wmem и /proc/sys/net/ipv4/tcp_rmem, или для отдельных сокетов, используя параметры сокетов SO_SNDBUF и SO_RCVBUF в вызове setsockopt(2).

Максимальный размер буферов сокета объявляется, используя механизмы SO_SNDBUF и SO_RCVBUF и ограничен значениями в файлах /proc/sys/net/core/rmem_max и /proc/sys/net/core/wmem_max. Заметим, что TCP в действительности бронирует в два раза больше места, чем размер буфера, запрошенный в вызове setsockopt(2), поэтому последующий вызов getsockopt(2) не возвратит тот же размер буфера, что был запрошен в вызове setsockopt(2). TCP использует дополнительное пространство в административных целях и для внутренних структур ядра, а значения в файлах в /proc отражают большие размеры, по сравнению с действительными окнами TCP. Для отдельных соединений размер буфера сокета должен быть установлен до вызова listen(2) или connect(2). Дополнительную информацию смотрите в socket(7).

TCP поддерживает срочные данные. Срочные данные используются для уведомления принимающей стороны о том, что частью потока данных является некоторое важное сообщение, которое должно быть обработано как можно скорее. Для отправки срочных данных укажите параметр MSG_OOB в вызове send(2). При поступлении срочных данных ядро посылает сигнал SIGURG процессу или группе процессов, который указан как «владелец» сокета с помощью ioctl-вызовов SIOCSPGRP или FIOSETOWN (или с помощью определённой в POSIX.1 операции F_SETOWN для fcntl(2)). Если задан параметр сокета SO_OOBINLINE, то срочные данные будут помещены в обычный поток данных (программа может проверить его размещение с помощью ioctl-вызова SIOCATMARK, описанного далее), в противном случае они могут быть получены, только если для recv(2) или recvmsg(2) установлен флаг MSG_OOB.

При наличии внеполосных данных select(2) помечает файловый дескриптор как имеющий исключительное условие, а poll (2) отмечает это событием POLLPRI.

В Linux 2.4 представлено несколько изменений по улучшению пропускной способности и масштабирования, а также дополнительные возможности: поддержка «нулевого» копирования (zero-copy) в sendfile(2), явное уведомление о перегрузке, новое управление сокетами TIME_WAIT, параметры поддержки сокетов в рабочем состоянии и поддержка расширений Duplicate SACK.

### Форматы адресов
Протокол TCP построен поверх протокола IP (смотрите ip(7)). Форматы адресов, определённые в ip(7), относятся и к TCP. TCP поддерживает только соединения типа точка-точка (point-to-point); широковещательная и многоадресная передача не поддерживаются.

### Интерфейсы /proc
Системные настройки параметров TCP хранятся в каталоге /proc/sys/net/ipv4/. Также, большинство интерфейсов /proc для IP также применимы и к TCP (смотрите ip(7)). Переменные, описанные как Boolean, являются целочисленными, где ненулевое значение («истина, true») означает, что соответствующий параметр включён, а нулевое значение («ложь, false») означает, что параметр включён.

tcp_abc (Integer; по умолчанию: 0; в Linux 2.6.15 по Linux 3.8)

Управляет подсчётом выделенных байтов (Appropriate Byte Count — ABC), определён в RFC 3465. ABC — это более плавный способ увеличения окна перегрузки (cwnd) в ответ на частичные подтверждения. Возможные значения:

0

увеличивать cwnd при каждом подтверждении (ABC выключен)

1

увеличивать cwnd при каждом подтверждении всего сегмента

2

разрешить увеличение cwnd на два, если подтверждение касается двух сегментов, что компенсирует задержку подтверждений.

tcp_abort_on_overflow (Boolean; по умолчанию: выключен; начиная с Linux 2.4)

Включает сброс (resetting) соединений, если слушающий сервис слишком медленно работает и не может поддержать существующие или принять новые соединения. Это означает, что при возникновении переполнения из-за всплеска подключений (burst), соединение будет восстановлено. Включайте этот параметр только, если вы действительно уверены, что слушающая программа не может быть настроена более быстрый приём соединений. Включение этого параметра может нарушить работу клиентов вашего сервера.

tcp_adv_win_scale (integer; по умолчанию: 2; начиная с Linux 2.4)

Рассчитывает переполнение буфера по формуле bytes/2^tcp_adv_win_scale, если tcp_adv_win_scale больше 0, или bytes-bytes/2^(-tcp_adv_win_scale), если значение tcp_adv_win_scale меньше или равно 0.

Пространство буфера приёма сокета является общим для приложения и ядра. TCP обслуживает часть буфера как окно TCP, о размере этого окна приёма извещается другая сторона. Остаток пространства используется как «буфер приложения», используемый для изолирования сети от задержек планирования или приложения. Значение по умолчанию tcp_adv_win_scale — 2 — означает, что для буфера приложения используется четверть всего пространства.

tcp_allowed_congestion_control (String; по умолчанию: смотрите описание; начиная с Linux 2.4.20)

Показывает/назначает алгоритм управления перегрузкой из списка доступных для непривилегированных процессов (смотрите описание параметра сокета TCP_CONGESTION). Элементы списка разделяются пробелом и завершаются символом новой строки. В списке содержатся несколько значений из перечисленных в tcp_available_congestion_control. Значением по умолчанию является «reno» плюс значение по умолчанию из tcp_congestion_control.

tcp_autocorking (Boolean; по умолчанию: включено; начиная с Linux 3.14)

Если тот параметр установлен, то ядро пытается объединить вместе как можно больше маленьких частей записываемых данных (от следующих друг за другом вызовов write(2) и sendmsg(2)), чтобы уменьшить общее количество посылаемых пакетов. Объединение (coalescing) выполняется, если, как минимум, один предыдущий пакет потока ждёт в очередях Qdisc или очереди отправки на устройство. Приложения по-прежнему могут использовать параметр сокета TCP_CORK для получения оптимального поведения, когда они знают как/когда включать вывод (uncork) из своих сокетов.

tcp_available_congestion_control (String; только для чтения; начиная с Linux 2.4.20)

Показывает список зарегистрированных алгоритмов управления перегрузкой. Элементы списка разделяются пробелом и завершаются символом новой строки. Список представляет собой сокращённый набор из tcp_allowed_congestion_control. Дополнительные алгоритмы управления перегрузкой могут быть доступны в виде модулей, но они не загружены.

tcp_app_win (integer; по умолчанию: 31; начиная с Linux 2.4)

Эта переменная определяет, сколько байтов окна TCP зарезервировано для буферизации издержек (overhead).

Для буфера приложения будет зарезервировано максимум (window/2^tcp_app_win, mss) байт в окне. Значение 0 обозначает, что ничего не зарезервировано.

tcp_base_mss (Integer; по умолчанию: 512; начиная с Linux 2.6.17)

Начальное значение для search_low, которое будет использовано уровнем упаковки при обнаружении Path MTU (зондирование MTU). Если зондирование (probing) MTU включено, то в соединении для этого используется начальное значение MSS.

tcp_bic (Boolean; default: выключено; в Linux 2.4.27/2.6.6 по 2.6.13)

Включает алгоритм управления перегрузкой BIC TCP. Алгоритм BIC-TCP действует только на стороне отправляющего, при этом обеспечивается линейная справедливость RTT при больших окнах и предлагается масштабируемость и дружественность к TCP. Протокол объединяет две схемы, называемые аддитивное увеличение (additive increase) и увеличение дихотомическим поиском (binary search increase). Когда окно перегрузки велико, аддитивное увеличение с большим приращением обеспечивает линейную справедливость RTT, а также хорошую масштабируемость. При маленьких окнах перегрузки, увеличение дихотомическим поиском предоставляет дружественность к TCP.

tcp_bic_low_window (integer; по умолчанию: 14; в Linux 2.4.27/2.6.6 по 2.6.13)

Устанавливает порог окна (в пакетах) после которого запускается BIC TCP для регулировки окна перегрузки. Ниже этого порога BIC TCP действует как алгоритм по умолчанию — TCP Reno.

tcp_bic_fast_convergence (Boolean; по умолчанию: включено; в Linux 2.4.27/2.6.6 по 2.6.13)

Заставляет BIC TCP реагировать на изменения окна перегрузки более быстро. Позволяет двум потокам сообща использовать одно соединение для более быстрой сходимости.

tcp_congestion_control (String; по умолчанию: смотрите описание; начиная с Linux 2.4.13)

Включает алгоритм управления перегрузкой по умолчанию для новых соединений. Алгоритм «reno» доступен всегда, но в зависимости от настроек ядра могут быть и другие. Значение по умолчанию для этого файла задаётся в настройке ядра.

tcp_dma_copybreak (integer; по умолчанию: 4096; начиная с Linux 2.6.24)

Нижний предел (в байтах) на количество читаемых из сокета данных, которое будет снято из механизма копирования DMA, если он есть в системе и ядро было настроено с параметром CONFIG_NET_DMA.

tcp_dsack (Boolean; по умолчанию: включено; начиная с Linux 2.4)

Включает поддержку RFC 2883 TCP Duplicate SACK.

tcp_ecn (Integer; по умолчанию: смотрите далее; начиная с Linux 2.4)

Включает RFC 3168 — уведомление о явной перегрузке (Explicit Congestion Notification).

В этом файле могут быть следующие значения:

0

Отключить ECN. Не посылать и не принимать ECN. Было включено по умолчанию до Linux 2.6.30 включительно.

1

Включать ECN при запросе входящими соединениями, а также запрашивать ECN при попытках исходящих соединений.

2

Включать ECN при запросе входящими соединениями, но не запрашивать ECN при попытках исходящих соединений. Данное значение поддерживается и включено по умолчанию начиная с Linux 2.6.31.

При включении может пропасть возможность установления соединений с некоторыми узлами из-за некорректно работающих маршрутизаторов по пути следования, что выражается в обрыве (dropped) соединения. Однако для улучшения и содействия внедрению со значением 1 и для обхода такого некорректного оборудования был введён параметр tcp_ecn_fallback.

tcp_ecn_fallback (Boolean; по умолчанию: включено; начиная с Linux 4.1)

Включает переход на резервный вариант RFC 3168, Section 6.1.1.1. При включении исходящие устанавливающие ECN SYNы, на которые не было ответа за обычное время перепосылки SYN, будут перепосланы со сброшенными CWR и ECE.

tcp_fack (Boolean; по умолчанию: включено; начиная с Linux 2.2)

Включает поддержку TCP Forward Acknowledgement (подтверждение передачи).

tcp_fin_timeout (integer; по умолчанию: 60; начиная с Linux 2.2)

Устанавливает количество секунд, в течение которых необходимо ждать последний пакет FIN перед принудительным закрытием сокета. Строго говоря, это нарушение спецификации TCP, но оно необходимо для предотвращения атак отказа в обслуживании (DoS). Значение по умолчанию в ядрах 2.2 равно 180.

tcp_frto (integer; по умолчанию: смотрите далее; начиная с Linux 2.4.21/2.6)

Включает F-RTO — расширенный алгоритм восстановления пауз при повторных передачах TCP (RTO). В частности, он полезен в беспроводных средах, где потеря пакетов обычно происходит из-за произвольного возникающих радиопомех, а не из-за перегрузки промежуточного маршрутизатора. Подробности смотрите в RFC 4138.

В этом файле могут быть следующие значения:

0

Отключено. Было включено по умолчанию до Linux 2.6.23 включительно.

1

Включить базовую версию алгоритма F-RTO.

2

Включить расширенный SACK алгоритм F-RTO, если поток использует SACK. Когда используется SACK, также может использоваться и базовая версия, хотя при этом возникают случаи, где F-RTO сработает плохо при подсчёте пакетов в потоке TCP с включённым SACK. Данное значение введено по умолчанию начиная с Linux 2.6.24.

До Linux 2.6.22 этот параметр имел тип Boolean, в котором поддерживаются только значения 0 и 1.

tcp_frto_response (integer; по умолчанию: 0; начиная с Linux 2.6.22)

Если F-RTO обнаруживает, что пауза при повторной передаче TCP не типична (т.е., паузы можно было бы избежать, если в TCP была бы установлена более длительная пауза повторной передачи), то у TCP есть несколько вариантов, что сделать дальше. Возможные значения:

0

Уменьшение скорости (rate) вдвое; плавный и осторожный ответ, приводит к уменьшению окна перегрузки (cwnd) вдвое и предельной величине медленного старта (ssthresh) после одного RTT.

1

Очень осторожный ответ; не рекомендуется, так как хотя и допускается, но плохо взаимодействует с остальным Linux TCP; немедленно уменьшает cwnd и ssthresh вдвое.

2

Активный ответ; отменяет оценки управления перегрузкой, которые теперь не нужны (игнорируется возможность потери повторной передачи, которая бы требовала от TCP большей бережливости); значения cwnd и ssthresh восстанавливаются в значения до паузы.

tcp_keepalive_intvl (integer; по умолчанию: 75; начиная с Linux 2.4)

Количество секунд между отправкой «поддерживающих» (keep-alive) проверочных пакетов.

tcp_keepalive_probes (integer; по умолчанию: 9; начиная с Linux 2.2)

Максимальное количество отправляемых «поддерживающих» (keep-alive) пакетов TCP до разрыва соединения, если не будет получено ответа от другой стороны.

tcp_keepalive_time (integer; по умолчанию: 7200; начиная с Linux 2.2)

Количество секунд между отсутствием передаваемых данных и отправкой через соединение «поддерживающих» пакетов. Эти пакеты будут отправляться, только если установлен параметра сокета SO_KEEPALIVE. Значение по умолчанию равно 7200 секунд (2 часа). Бездействующее соединение разрывается примерно через 11 минут (9 пакетов, с интервалом 75 секунд) при включённом режиме keep-alive.

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

tcp_low_latency (Boolean; по умолчанию: выключено; начиная с Linux 2.4.21/2.6)

Если включён, то при работе стека TCP отдаётся предпочтение меньшей задержке, а не более высокой производительности. Если параметр выключен, то предпочтение отдаётся высокой производительности. В качестве примера приложения, для которого нужно включить этот параметр, можно привести вычислительный кластер Beowulf.

tcp_max_orphans (integer; по умолчанию: смотрите далее; начиная с Linux 2.4)

Максимальное количество брошенных (orphaned, не присоединённых ни к одному пользовательскому обработчику файлов) сокетов TCP, разрешённых в системе. Если это количество превышается, то брошенные соединения сбрасываются и выводится предупреждение. Данное ограничение существует только для предотвращения простейших атак в обслуживании (DoS). Понижать этот лимит не рекомендуется. Иногда для сети может потребоваться увеличить это количество, но заметим, что на каждое такое брошенное соединение расходуется до 64 КБ невыгружаемой памяти. Значение по умолчанию равно значению параметра ядра NR_FILE. Значение по умолчанию может изменяться в зависимости от количества памяти в системе.

tcp_max_syn_backlog (integer; по умолчанию: смотрите далее; начиная с Linux 2.2)

Максимальное количество запросов на соединение в очереди, которые пока не получили подтверждения от клиентов. Если это количество превышается, то ядро начнёт отбрасывать запросы. Значение по умолчанию (256) увеличивается до 1024, если в системе достаточно памяти (>= 128 МБ) и уменьшается до 128, если памяти мало (<= 32 МБ).

До Linux 2.6.20 рекомендовалось, что если необходимо значение больше 1024, то нужно изменить размер хэш-таблицы SYNACK (TCP_SYNQ_HSIZE)в include/net/tcp.h сохраняя условие

TCP_SYNQ_HSIZE * 16 <= tcp_max_syn_backlog

и пересобрать ядро. В Linux 2.6.20 постоянный размер TCP_SYNQ_HSIZE был заменён на динамически изменяемый.

tcp_max_tw_buckets (integer; по умолчанию: смотрите далее; начиная с Linux 2.4)

Максимальное количество сокетов в состоянии TIME_WAIT, разрешённое в системе. Это ограничение существует только для предотвращения простейших атак DoS. По умолчанию равно NR_FILE*2 и изменяется в зависимости от количества памяти в системе. Если это значение превышено, то сокет закрывается и выводится предупреждение.

tcp_moderate_rcvbuf (Boolean; по умолчанию: включено; начиная с Linux 2.4.17/2.6.7)

Если включён, то для TCP включается автоматическая настройка приёмного буфера; при этом размер буфера (не более чем tcp_rmem[2]) автоматически подгоняется под размер, используемый на пути прохождения трафика, в целях достижения максимальной пропускной способности.

tcp_mem (начиная с Linux 2.4)

Вектор из 3 целочисленных значений: [low, pressure, high]. Представляют собой границы, измеряемые в системных страницах памяти, используются в TCP для отслеживания использования памяти. По умолчанию рассчитываются во время загрузки ОС, зависят от количества памяти в системе (для этого в TCP может использоваться только нижняя память (low memory), которая в 32-битных системах ограничена 900-ми мегабайтами. В 64-битных системах этого ограничения нет).

low

TCP не регулирует распределение своей памяти, если число страниц, выделенных глобально, ниже этого значения.

pressure

Когда количество страниц, размещённых TCP, превышает это значение, то TCP изменяет свой метод использования памяти. Это состояние отменяется при падении количества размещённых страниц ниже значения low.

high

Глобальное (общее) максимальное количество страниц, которое может использовать TCP. Это значение переопределяет все другие ограничения, накладываемые ядром.

tcp_mtu_probing (integer; по умолчанию: 0; начиная с Linux 2.6.17)

Этот параметр контролирует TCP Packetization-Layer Path MTU Discovery. В файле могут указываться следующие значения:

0

Выключен

1

Включать при обнаружении чёрной дыры (black hole) ICMP

2

Всегда включено, использовать начальное значение MSS из tcp_base_mss.

tcp_no_metrics_save (Boolean; по умолчанию: выключено; начиная с Linux 2.6.6)

По умолчанию, TCP сохраняет различные метрики соединения в кэше маршрутов при закрытии соединения для того, чтобы соединения, устанавливаемые в ближайшем будущем, могли использовать этот набор начальных состояний. Обычно, это увеличивает общую производительность, но иногда может и уменьшить её. Если tcp_no_metrics_save включено, то TCP не кэширует метрики при закрытии соединений.

tcp_orphan_retries (integer; по умолчанию: 8; начиная с Linux 2.4)

Максимальное количество попыток проверки другой стороны соединения перед закрытием с нашей стороны.

tcp_reordering (integer; по умолчанию: 3; начиная с Linux 2.4)

Максимальное количество пакетов, которое может быть переупорядочено в потоке TCP, при котором TCP ещё не считает что произошли потери и не переходит в состояние медленного запуска (slow start). Не рекомендуется менять это значение. Данная метрика обнаружения переупорядочивания пакетов предназначена для минимизации повторных передач, обусловленных переупорядочиванием пакетов в соединении.

tcp_retrans_collapse (Boolean; по умолчанию: включено; начиная с Linux 2.2)

При повторной передаче пробовать посылать полноразмерные пакеты.

tcp_retries1 (integer; по умолчанию: 3; начиная с Linux 2.2)

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

tcp_retries2 (integer; по умолчанию: 15; начиная с Linux 2.2)

Максимальное количество попыток повторной передачи пакетов TCP по установленному соединению до того, как оно будет считаться разорванным. По умолчанию равно 15, что соответствует времени примерно от 13 до 30 минут, в зависимости от значения таймера повторной передачи. В RFC 1122 установлена минимальная граница в 100 секунд, которая обычно считается слишком маленькой.

tcp_rfc1337 (Boolean; по умолчанию: выключено; начиная с Linux 2.2)

Включает поведение TCP, совместимое с RFC 1337. Если выключено, то: если в состоянии TIME_WAIT принимается RST, то сокет закрывается немедленно, не дожидаясь конца периода TIME_WAIT.

tcp_rmem (начиная с Linux 2.4)

Вектор из 3 целочисленных значений: [min, default, max]. Эти параметры используются TCP для регулирования размера буфера приёма. TCP динамически корректирует размер буфера приёма от значений по умолчанию, указанных ниже, в диапазоне этих переменных и в зависимости от количества памяти в системе.

min

Минимальный размер буфера приёма, используемый каждым сокетом TCP. По умолчанию равен размеру системной страницы (в Linux 2.4 равно 4 КБ и может уменьшаться до PAGE_SIZE байт в системах с малым количеством памяти). Это значение используется для того, чтобы размещение страниц памяти меньше этого значения в режиме давления (pressure) все равно выполнялось. Не ограничивает размер буфера приёма, объявленного для сокета с помощью SO_RCVBUF.

default

Размер буфера приёма по умолчанию для сокетов TCP. Это значение переопределяет начальный размер буфера по умолчанию, взятый из общей глобальной переменной net.core.rmem_default, определённой для всех протоколов. По умолчанию равен 87380 байт (в Linux 2.4 это значение может уменьшаться до 43689 в системах с малым количеством памяти). Если желательны большие размеры буфера приёма, то это значение должно быть увеличено (влияет на все сокеты). Для разрешения больших размеров окон TCP должно быть включено net.ipv4.tcp_window_scaling (по умолчанию).

max

Максимальный размер буфера приёма, используемый каждым сокетом TCP. Это значение не переопределяет значение глобальной переменной net.core.rmem_max. Не используется для ограничения размера буфера приёма, объявленного для сокета через SO_RCVBUF. Значение по умолчанию рассчитывается по следующей формуле

max(87380, min(4 МБ, tcp_mem[1]*PAGE_SIZE/128))

(в Linux 2.4 значение по умолчанию равно 87380*2 байт, уменьшается до 87380 в системах с малым количеством памяти).

tcp_sack (Boolean; по умолчанию: включено; начиная с Linux 2.2)

Включает выборочные подтверждения TCP (TCP Selective Acknowledgements), описанные в RFC 2018.

tcp_slow_start_after_idle (Boolean; по умолчанию: включено; начиная с Linux 2.6.18)

Если включено, то разрешается поведение согласно RFC 2861 и таймаут окна перегрузки после периода простоя. Период простоя определяется текущим значением RTO (таймаут повторной передачи). Если выключено, то после окна перегрузки не следует таймаут после периода простоя.

tcp_stdurg (Boolean; по умолчанию: выключено; начиная с Linux 2.2)

Если значение включено, то для поля указателя срочных данных TCP используется интерпретация RFC 1122. Согласно этому указатель срочности указывает на последний байт срочных данных. Если это значение выключено, то для указателя на срочные данные применяется интерпретация, совместимая с BSD: указатель срочности указывает на первый байт после срочных данных. Включение этого значения может привести к проблемам с взаимодействием сетей.

tcp_syn_retries (integer; по умолчанию: 5; начиная с Linux 2.2)

Максимальное количество посылаемых начальных пакетов SYN у активного соединения TCP. Значение должно быть меньше 255. Значение по умолчанию равно 5, что соответствует примерно 180 секундам.

tcp_synack_retries (integer; по умолчанию: 5; начиная с Linux 2.2)

Максимальное количество попыток повторной передачи сегмента SYN/ACK у пассивного соединения TCP. Значение должно быть меньше 255.

tcp_syncookies (Boolean; начиная с Linux 2.2)

Включает TCP syncookies. Ядро должно быть собрано с параметром CONFIG_SYN_COOKIES. Это вызывает отправку syncookies при переполнении у сокета очереди syn backlog. Возможность syncookies создана для защиты сокета от атак переполнения SYN. Используйте её в самую последнюю очередь, а лучше вообще не используйте. Это является нарушением протокола TCP и конфликтует со многими другими областями TCP, например с расширениями TCP. Может привести к проблемам в работе клиентов и релеев. Не рекомендуется к использованию на высокозагруженных серверах в качестве «быстрой помощи» при перегрузках или некорректных настройках. В качестве рекомендуемой альтернативы смотрите tcp_max_syn_backlog, tcp_synack_retries и tcp_abort_on_overflow.

tcp_timestamps (integer; по умолчанию: 1; начиная с Linux 2.2)

Устанавливается в одно из следующих значений для включения меток времени RFC 1323 TCP:

0

Отключить метки времени.

1

Включить метки времени, определённые в RFC1323, и использовать случайное смещение для каждого соединения, а не просто использовать текущее время.

2

Как при значении 1, но без случайных смещений. Назначение tcp_timestamps этого значения работает начиная с Linux 4.10.

tcp_tso_win_divisor (integer; по умолчанию: 3; начиная с Linux 2.6.9)

Контролирует процент окна перегрузки, который может быть использован одиночным кадром TCP Segmentation Offload (TSO). Значение этого параметра — компромисс между временной нагрузкой (burstiness) и построением больших кадров TSO.

tcp_tw_recycle (Boolean; по умолчанию: выключено; в Linux 2.4 по 4.11)

Включает быстрое повторное использование сокетов с TIME_WAIT. Включение данного параметра не рекомендуется, так как удалённый IP может не использовать монотонно увеличивающиеся метки времени (устройства за NAT, устройства с выделенными на подключение смещёнными метками времени). Смотрите RFC 1323 (PAWS) и RFC 6191.

tcp_tw_reuse (Boolean; по умолчанию: выключено; начиная с Linux 2.4.19/2.6)

Позволяет повторно использовать сокеты TIME_WAIT для новых соединений, если это безопасно с точки зрения протокола. Значение не должно изменяться без совета/запроса технических специалистов.

tcp_vegas_cong_avoid (Boolean; по умолчанию: выключено; с Linux 2.2 по 2.6.13)

Включает алгоритм избежания перегрузок TCP Vegas. TCP Vegas действует на стороне отправителя; он ожидает начала перегрузки, оценивая пропускную способность. TCP Vegas подгоняет частоту отправки, изменяя окно перегрузки. При включённом TCP Vegas обеспечиваются меньшие потери пакетов, но он не так стремителен как TCP Reno.

tcp_westwood (Boolean; по умолчанию: выключено; с Linux 2.4.26/2.6.3 по 2.6.13)

Включает алгоритм управления перегрузками TCP Westwood+. TCP Westwood+ действует на стороне отправителя и является модификацией стека протокола TCP Reno, ориентированной на производительность управления перегрузками TCP. Он основан на оценке полосы пропускания от точки передачи до точки приёма при изменении окна перегрузки и порога медленного старта после возникновения перегрузки. Используя эту оценку TCP Westwood+ подстраивает порог медленного старта и окно перегрузки, принимая во внимание пропускную способность, полученную во время перегрузки. TCP Westwood+ значительно увеличивает плавность (fairness), по сравнению с TCP Reno, в проводных сетях и пропускную способность в беспроводных сетях.

tcp_window_scaling (Boolean; по умолчанию: включено; начиная с Linux 2.2)

Включает изменение размера окна TCP, описанное в RFC 1323 Эта возможность позволяет использовать большие (> 64 КБ) окна для соединений TCP, но она должна также поддерживаться на другой стороне соединения. Обычно, 16-ти битовый размер поля длины окна в заголовке TCP ограничивает его размер до 64 КБ. Если нужно обеспечить больший размер окна, то приложение должно увеличить размер своих буферов сокетов и включить возможность масштабирования окна. Если значение tcp_window_scaling выключено, то TCP не будет согласовывать использование масштабирования окон с другой стороной во время установки соединения.

tcp_wmem (начиная с Linux 2.4)

Вектор из 3 целочисленных значений: [min, default, max]. Эти параметры используются TCP для управления размером буфера отправления. TCP динамически корректирует размер буфера отправления от значений по умолчанию, указанных ниже, в диапазоне этих переменных и в зависимости от количества доступной памяти.

min

Минимальный размер буфера отправления, используемый каждым сокетом TCP По умолчанию равен размеру системной страницы (в Linux 2.4 значение равно 4 КБ). Это значение используется для того, чтобы размещение страниц памяти меньше этого значения в режиме давления (pressure) все равно выполнялось. Не ограничивает размер буфера отправления, объявленного для сокета с помощью SO_SNDBUF.

default

Размер буфера отправления по умолчанию для сокетов TCP Это значение переопределяет начальный размер буфера по умолчанию, взятый из общей глобальной переменной /proc/sys/net/core/wmem_default, определённой для всех протоколов. По умолчанию равно 16 КБ. Если желательны большие размеры буферов отправления, то это значение должно быть увеличено (влияет на все сокеты). Для разрешения больших размеров окон TCP значение /proc/sys/net/ipv4/tcp_window_scaling должно быть ненулевым (по умолчанию).

max

Максимальный размер буфера отправления, используемый каждым сокетом TCP. Это значение не переопределяет значение переменной /proc/sys/net/core/wmem_max. Не используется для ограничения размера буфера отправления, объявленного для сокета через SO_SNDBUF. Значение по умолчанию рассчитывается по следующей формуле

max(65536, min(4 МБ, tcp_mem[1]*PAGE_SIZE/128))

(в Linux 2.4 значение по умолчанию равно 128 КБ, уменьшается до 64 КБ в системах с малым количеством памяти).

tcp_workaround_signed_windows (Boolean; по умолчанию: выключено; начиная с Linux 2.6.26)

Если включено, то предполагать, что неполучение параметра окна масштабирования означает, что удалённый TCP повреждён и считать размер окна как число со знаком. Если выключено, то предполагается, что удалённый TCP не повреждён, даже если мы не получаем от него параметр окна масштабирования.

### Параметры сокета
Для получения и задания параметров сокетов TCP используйте вызов getsockopt(2) и setsockopt(2), соответственно. Значение аргумента уровня параметров должно быть равно IPPROTO_TCP. Если не указано обратное, optval — это указатель на int. Кроме того, сокетам TCP доступно большинство параметров сокета IPPROTO_IP. Дополнительная информация приведена в ip(7).

В следующем списке представлены параметры только для сокетов TCP. О других параметрах, применимых к сокетам TCP, читайте в socket(7).

TCP_CONGESTION (начиная с Linux 2.6.13)

Аргументом этого параметра является строка. Данный параметр позволяет вызывающему задать используемый алгоритм управления перегрузкой TCP, для каждого сокета. Для непривилегированных процессов выбор ограничен одним из алгоритмов tcp_allowed_congestion_control (описано выше). Привилегированные процессы (CAP_NET_ADMIN) могут выбирать любой из доступных алгоритмов контроля перегрузки (смотрите описание tcp_available_congestion_control выше).

TCP_CORK (начиная с Linux 2.2)

Если установлен, то не посылать частичные кадры. Все поставленные в очередь частичные кадры будут отосланы, когда этот параметр будет очищен. Это полезно для подготовки заголовков перед вызовом sendfile(2) или для оптимизации пропускной способности. В текущей реализации отводится максимум (ceiling) 200 миллисекунд, в течение которых вывод закупоривается (corked) из-за TCP_CORK. Если этот максимум достигнут, то данные в очереди передаются автоматически. Этот параметр можно совмещать с TCP_NODELAY только начиная с Linux 2.5.71. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_DEFER_ACCEPT (начиная с Linux 2.4)

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

TCP_INFO (начиная с Linux 2.4)

Используется для сбора информации об этом сокете. Ядро возвращает структуру struct tcp_info, определённую в файле /usr/include/linux/tcp.h. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_KEEPCNT (начиная с Linux 2.4)

Максимальное число проверок (keepalive probes) TCP, отправляемых перед сбросом соединения. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_KEEPIDLE (начиная с Linux 2.4)

Время (в секундах) простоя (idle) соединения, по прошествии которого TCP начнёт отправлять проверочные пакеты (keepalive probes), если для сокета включён параметр SO_KEEPALIVE. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_KEEPINTVL (начиная с Linux 2.4)

Время в секундах между отправками отдельных проверочных пакетов (keepalive probes). Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_LINGER2 (начиная с Linux 2.4)

Время жизни брошенных (orphaned) сокетов в состоянии FIN_WAIT2. Этот параметр может использоваться для переопределения общесистемного параметра из файла /proc/sys/net/ipv4/tcp_fin_timeout данного сокета. Значение не должно противоречить параметру SO_LINGER уровня сокета socket(7). Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_MAXSEG

Максимальный размер сегмента для исходящих пакетов TCP. В Linux 2.2 и ранее, и в Linux 2.6.28 и новее, если этот параметр задан до установления соединения, то меняется также и значение MSS, сообщаемое другой стороне в начальном пакете. Значения, превышающие MTU интерфейса, игнорируются. TCP также будет определять минимальную и максимальную границу поверх этих значений.

TCP_NODELAY

Если включён, то отменяется выполнение алгоритма Nagle. Это означает, что сегменты всегда отсылаются при первой же возможности, даже если к отправке назначено небольшое количество данных. Если выключен, то данные буферизируются и будут отправлены только после набора достаточно большого количества данных, поэтому небольшие пакеты с данными не отправляются. Этот параметр переопределяется TCP_CORK; однако, установка данного параметра вызывает явную очистку ожидающих вывода данных, даже если установлен TCP_CORK.

TCP_QUICKACK (начиная с Linux 2.4.4)

Включает режим quickack при установке или выключает при сбросе. В этом режиме все уведомления отправляются немедленно, а не с некоторой задержкой в соответствии с обычной работой TCP. Этот флаг не постоянный, он только включает или выключает режим quickack. Последующие операции с протоколом TCP будут по своему включать/выключать этот режим в зависимости от своих внутренних протоколов, настроек и факторов. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_SYNCNT (начиная с Linux 2.4)

Устанавливает количество повторных передач SYN, которое должен послать TCP до отмены попытки установки соединения. Не должно превышать 255. Данный параметр не должен использоваться, если требуется переносимость кода.

TCP_USER_TIMEOUT (начиная с Linux 2.6.37)

Типом аргумента этого параметра является unsigned int. Если значение больше 0, то им задаётся максимальное количество времени в миллисекундах, которое передаваемые данные могут оставаться неподтверждёнными до того, как TCP принудительно закроет соответствующее соединение и приложению вернётся ETIMEDOUT. Если значение равно 0, то TCP будет использовать значение по умолчанию.

Увеличение пользовательского времени задержки позволяет соединению TCP продолжать существовать дополнительные периоды при отсутствии связи. Уменьшение пользовательского времени задержки позволяет приложениям «быстро упасть», если это нужно. В противном случае ошибка может быть отложена до 20 минут при текущих системных значениях по умолчанию в обычной среде WAN.

Этот параметр может быть задан при любом состоянии соединения TCP, но будет задействован только при синхронизации состояний соединения (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING и LAST-ACK). Кроме этого, когда используется параметр поддержания TCP (SO_KEEPALIVE), TCP_USER_TIMEOUT отменит действие поддержания для определения нужно ли закрывать соединение из-за ошибки поддержания.

Этот параметр не действует, если TCP перепосылает пакет, или посылается проба поддержания.

Этот параметр, как и многие другие, наследуется сокетом, возвращаемым accept(2), если он установлен у прослушивающего сокета.

Подробней о свойстве пользовательского времени задержки смотрите RFC 793 и RFC 5482 («TCP User Timeout Option»).

TCP_WINDOW_CLAMP (начиная с Linux 2.4)

Ограничивает размер предлагаемого окна указанным значением. Ядро считает минимальный размер как SOCK_MIN_RCVBUF/2. Данный параметр не должен использоваться, если требуется переносимость кода.

### Программный интерфейс сокетов
TCP предоставляет ограниченную поддержку внеполосных данных в виде (одного байта) срочных данных. В Linux это означает, что если другая сторона посылает новые внеполосные данные, то старые срочные данные вставляются как обычные данные в поток (даже когда SO_OOBINLINE не установлен). В этом отличие от реализации стека в BSD.

По умолчанию в Linux используется совместимая с BSD интерпретация поля срочного указателя. Это нарушает RFC 1122, но требуется для правильного взаимодействия с другими стеками. Это можно изменить через /proc/sys/net/ipv4/tcp_stdurg.

Возможно получить внеполосные данные с помощью recv(2) и флага MSG_PEEK.

Начиная с версии 2.4, Linux поддерживает использование MSG_TRUNC в аргументе flags вызова recv(2) (и recvmsg(2)). Этот флаг принуждает отбросить принятые байты данных, а не передавать их обратно в буфер, предоставленный вызывающим. Начиная с Linux 2.4.4, MSG_TRUNC также обладает этим свойством, если используется вместе с MSG_OOB для приёма внеполосных данных.

### Системные вызовы (ioctl)
Следующие вызовы ioctl(2) возвращают информацию в аргументе value. Синтаксис:

```
int value;
error = ioctl(tcp_socket, ioctl_type, &value);
```

Значением ioctl_type может быть одно из:

SIOCINQ

Возвращает количество непрочитанных данных в очереди в приёмном буфере. Сокет не должен быть в состоянии LISTEN, иначе возвращается ошибка (EINVAL). Значение SIOCINQ определено в <linux/sockios.h>. В качестве альтернативы вы можете использовать синоним FIONREAD, определённый в <sys/ioctl.h>.

SIOCATMARK

Возвращает истинное значение (т.е., value отличное от нуля), если входящие данные потока отмечены как срочные.

Если установлен параметр сокета SO_OOBINLINE и SIOCATMARK возвращает истинное значение, то при следующем чтении из сокета будут получены срочные данные. Если параметр сокета SO_OOBINLINE не установлен и SIOCATMARK возвращает истинное значение, то при следующем чтении из сокета будут получены байты, размещённые после срочных (для действительного чтения срочных данных требуется флаг recv(MSG_OOB)).

Заметим, что при чтении никогда не происходит чтения за меткой срочности. Если приложение проинформировано о наличии срочных данных с помощью select(2) (с аргументом exceptfds) или доставкой сигнала SIGURG, то оно может переместить метку дальше с помощью цикла, в котором постоянно проверяется SIOCATMARK, и выполнить чтение (запросив любое количество байт) пока SIOCATMARK возвращает ложь.

SIOCOUTQ

Возвращает количество не отправленных данных в очереди отправки сокета. Сокет не должен быть в состоянии прослушивания LISTEN, иначе возвратится ошибка (EINVAL). Значение SIOCOUTQ определено в <linux/sockios.h>. Или же вы можете использовать его аналог TIOCOUTQ, определённый в <sys/ioctl.h>.

### Обработка ошибок
При возникновении сетевой ошибки TCP пытается отправить пакет повторно. Если в течение некоторого времени этого сделать не удаётся, то возвращается либо ETIMEDOUT, либо последняя ошибка, произошедшая в этом соединении.

Для некоторых приложений требуется более быстрое уведомление об ошибках. Это может быть выполнено на уровне IPPROTO_IP с помощью параметра сокета IP_RECVERR. Если этот параметр включён, то все входящие ошибки немедленно передаются программе пользователя. Используйте этот параметр осторожно: он приводит к тому, что TCP становится более чувствительным к сменам маршрутов и другим событиям, обычным для сети.

## ОШИБКИ
EAFNOTSUPPORT

Переданный в sin_family тип адреса сокета не равен AF_INET.

EPIPE

Другая сторона неожиданно закрыла сокет, или была произведена попытка чтения в отключённом сокете.

ETIMEDOUT

Другая сторона не подтвердила передачу данных через определённое время.

Все ошибки, определённые для ip(7) или общего слоя сокетов, также могут быть возвращены и для TCP.

## ВЕРСИИ
В версии 2.4 были представлены: поддержка явного уведомления о перегрузке (Explicit Congestion Notification), нулевое копирование sendfile(2), поддержка переупорядочения и некоторые расширения SACK (DSACK). Поддержка упреждающего подтверждения (FACK), повторение цикла TIME_WAIT и параметры сокетов проверочных пакетов (keepalive) для каждого соединения появились в версии 2.3.

## ДЕФЕКТЫ
Не все ошибки описаны.

Протокол IPv6 не описан.

## СМОТРИТЕ ТАКЖЕ
accept(2), bind(2), connect(2), getsockopt(2), listen(2), recvmsg(2), sendfile(2), sendmsg(2), socket(2), ip(7), socket(7)

В RFC 793 описан TCP.

В RFC 1122 перечислены требования TCP и дано описание алгоритма Нагла (Nagle).

В RFC 1323 описаны метки времени TCP и параметры масштабирования окна.

В RFC 1337 описаны факторы риска TIME_WAIT.

В RFC 3168 описано уведомление о явной перегрузке (Explicit Congestion Notification).

В RFC 2581 описаны алгоритмы управления перегрузками TCP.

В RFC 2018 и RFC 2883 описан SACK и расширения к SACK.


termio

title: termio(7)

summary: интерфейс драйвера терминала System V

text:
# termio(7)

## ИМЯ
termio - интерфейс драйвера терминала System V

## ОПИСАНИЕ
termio — название старого интерфейса драйвера терминала System V. В этом интерфейсе определена структура termio, которая используется для хранения настроек терминала, и набор операций ioctl(2) для выборки и изменения атрибутов терминала.

В настоящее время интерфейс termio устарел: в POSIX.1-1990 стандартизована изменённая версия данного интерфейса под именем termios. В POSIX.1 структура данных немного отличается от версии System V, а также в POSIX.1 определён комплект функций, заменяющих различные операции ioctl(2), которые существовали в System V (это сделано из-за нестандаризованности ioctl(2) и непостоянной длины (variadic) третьего аргумента, что не позволяет проверить тип аргумента).

Если вы ищете данные на странице с именем «termio», то большинство информации найдёте на странице termios(3) или ioctl_tty(2).

## СМОТРИТЕ ТАКЖЕ
reset(1), setterm(1), stty(1), ioctl_tty(2), termios(3), tty(4)


thread-keyring

title: thread-keyring(7)

summary: связка ключей нити

text:
# thread-keyring(7)

## ИМЯ
thread-keyring - связка ключей нити

## ОПИСАНИЕ
Связка ключей нити — это связка ключей, используемая для привязки ключей нити. Она создаётся только по запросу нити. Связка ключей нити имеет имя (описание) _tid.

Существует специальный серийный номер, KEY_SPEC_THREAD_KEYRING, который можно указывать вместо реального серийного номера связки ключей сеанса вызывающей нити.

В утилите keyctl(1) подобным образом можно использовать «@t» вместо числового ID ключа, но так как keyctl(1) выполняется после разветвления, это не используется.

Связка ключей нити не наследуется при clone(2) и fork(2) и очищается при execve(2). Связка ключей нити уничтожается по завершению ссылающейся на неё нити.

Первоначально, нить не имеет связки ключей нити. Если нить не имеет связки ключей нити при обращении, то связка создаётся, если выполняется её изменение; в противном случает операция завершается ошибкой ENOKEY.

## СМОТРИТЕ ТАКЖЕ
keyctl(1), keyctl(3), keyrings(7), persistent-keyring(7), process-keyring(7), session-keyring(7), user-keyring(7), user-session-keyring(7)


time

title: time(7)

summary: обзор времени и таймеров

text:
# time(7)

## ИМЯ
time - обзор времени и таймеров

## ОПИСАНИЕ

### Реальное время и время процесса
Реальное время (real time) — время, измеряемое от некоторой постоянной точки, или от стандартной точки в прошлом (смотрите описание эпохи (Epoch) и календарного времени далее), или от некоторой точки (например, с момента запуска) в жизни процесса (прошедшее время (elapsed time)).

Время процесса (process time) — количество процессорного времени, использованного процессом. Иногда его делят на пользовательское (user) и системное (system). Пользовательское время ЦП — это время, потраченное на исполнение кода в режиме пользователя. Системное время ЦП — это время, потраченное ядром, выполняющемся в системном режиме, для процесса (например, на обработку системных вызовов). Команда time(1) позволяет определить количество процессорного времени, затраченного при выполнении программы. Программа может определить количество потраченного процессорного времени с помощью times(2), getrusage(2) или clock(3).

### Аппаратные часы
В большинстве компьютеров (оснащённых батареей) имеются аппаратные часы, которые ядро читает при запуске для инициализации программных часов. Подробности смотрите в rtc(4) и hwclock(8).

### Программные часы, HZ и миги (jiffies)
Точность различных системных вызовов, которые задают время ожидания (timeouts) (например, select(2), sigtimedwait(2)) и измеряют процессорное время (например, getrusage(2)), ограничена точностью программных часов (software clock) — часов, поддерживаемых ядром, у которых время измеряется в мигах (jiffies). Размер мига определяется значением константы ядра HZ.

Значение HZ различно в разных версиях ядра и аппаратных платформах. Для i386: в ядрах до версии 2.4.x включительно, HZ равно 100, то есть значение мига равно 0.01 секунды; начиная с версии 2.6.0 значение HZ увеличено до 1000 и миг равен 0.001 секунды. Начиная с ядра 2.6.13 значение HZ задаётся в параметре настройки ядра и может быть равно 100, 250 (по умолчанию) или 1000, что делает значение мига равным, соответственно, 0.01, 0.004 или 0.001 секунды. Начиная с ядра 2.6.20 добавлено ещё одна частота: 300, количество, которое делится нацело на распространённые частоты видеокадров (PAL — 25 HZ; NTSC — 30 HZ).

Системный вызов times(2) — это особый случай. Он выдаёт время с точностью, определяемой константой ядра USER_HZ. Приложения пользовательского пространства могут определить значение этой константы с помощью sysconf(_SC_CLK_TCK).

### Таймеры высокой точности
До Linux 2.6.21 точность системных вызовов таймера и сна (смотрите далее) была ограничена размером мига.

Начиная с Linux 2.6.21, Linux поддерживает таймеры высокой точности (HRT), включаемые через CONFIG_HIGH_RES_TIMERS. В системе, которая поддерживает HRT, точность сна и таймеров в системных вызовах больше не ограничена мигом, а только точностью аппаратуры (в современной аппаратуре, обычно, микросекундная точность). Вы можете определить поддерживаются ли таймеры высокой точности, проверив результат вызова clock_getres(2) или поискав записи «resolution» в /proc/timer_list.

HRT поддерживаются не на всех аппаратных архитектурах (среди имеющих отметим x86, arm и powerpc).

### Эпоха
В системах UNIX время считается в секундах и начинается с эпохи (Epoch), 1970-01-01 00:00:00 +0000 (UTC).

Программа может определить календарное время c помощью часов CLOCK_REALTIME через clock_gettime(2), которые возвращают время (в секундах и наносекундах), прошедшее с начала эпохи; вызов time(2) выдаёт подобную информацию, но с точностью только до ближайшей секунды. Системное время можно изменять с помощью clock_settime(2).

### Календарное время, разделённое на компоненты
Некоторые библиотечные функции используют структуру с типом tm для представления календарного времени, разделённого на компоненты (broken-down time), в которой время хранится в виде отдельных составляющих (год, месяц, день, час, минута, секунда и т. д.). Эта структура описана в ctime(3), в которой также описаны функции, преобразующие календарное время в разделённое на компоненты и обратно. Функции представления календарного времени, разделённого на компоненты, в печатную строку описаны в ctime(3), strftime(3) и strptime(3).

### Таймеры сна и их установка
Различные системные вызовы и функции позволяют программе спать (приостанавливать выполнение) заданный промежуток времени; смотрите nanosleep(2), clock_nanosleep(2) и sleep(3).

Различные системные вызовы позволяют процессу устанавливать таймеры, которые срабатывают в какой-то момент в будущем, и, возможно, через определённые интервалы; смотрите alarm(2), getitimer(2), timerfd_create(2) и timer_create(2).

### Допуск таймера
Начиная с Linux 2.6.28, возможно контролировать значение «допуска таймера» (timer slack) нити. Допуск таймера — это промежуток времени, на который ядро может задержать пробуждение определённых системных вызовов, заблокированных на время. Эта задержка позволяет ядру объединять события пробуждения, таким образом сокращая количество системных пробуждений и экономя энергию. Подробней смотрите описание PR_SET_TIMERSLACK в prctl(2).

## СМОТРИТЕ ТАКЖЕ
date(1), time(1), timeout(1), adjtimex(2), alarm(2), clock_gettime(2), clock_nanosleep(2), getitimer(2), getrlimit(2), getrusage(2), gettimeofday(2), nanosleep(2), stat(2), time(2), timer_create(2), timerfd_create(2), times(2), utime(2), adjtime(3), clock(3), clock_getcpuclockid(3), ctime(3), ntp_adjtime(3), ntp_gettime(3), pthread_getcpuclockid(3), sleep(3), strftime(3), strptime(3), timeradd(3), usleep(3), rtc(4), hwclock(8)


udp

title: udp(7)

text:
# udp(7)

## ИМЯ
udp - протокол UDP (User Datagram Protocol) для IPv4

## ОБЗОР
\#include <sys/socket.h>

\#include <netinet/in.h>

\#include <netinet/udp.h>

udp_socket = socket(AF_INET, SOCK_DGRAM, 0);

## ОПИСАНИЕ
Это реализация протокола пользовательских датаграмм (User Datagram Protocol, UDP), который описан в RFC 768. Он обеспечивает ненадежную передачу датаграмм без установления соединения. При пересылке пакеты могут дублироваться, а их порядок может быть нарушен. UDP генерирует и проверяет контрольные суммы, чтобы отловить ошибки передачи.

При создании UDP-сокета его локальный и удалённый адрес не указываются. Датаграммы могут быть посланы немедленно с помощью sendto(2) или sendmsg(2) с правильным адресом назначения в качестве аргумента. Когда для сокета вызывается connect(2), то устанавливается адрес назначения по умолчанию и с этого момента датаграммы могут отсылаться с помощью send(2) или write(2) без указания адреса назначения. При этом всё ещё сохраняется возможность послать пакет другому адресату, передавая его адрес через вызовы sendto(2) или sendmsg(2). Для получения пакетов сокет сначала можно привязать к локальному адресу с помощью bind(2). В противном случае сокетный уровень автоматически присвоит свободный локальный порт из диапазона, заданного в /proc/sys/net/ipv4/ip_local_port_range, и привяжет сокет к INADDR_ANY.

Все операции приёма возвращают только один пакет. Если пакет меньше, чем размер буфера приема, то он возвращается целиком; если пакет больше, то он обрезается и устанавливается флаг MSG_TRUNC. Флаг MSG_WAITALL не поддерживается.

Параметры IP могут быть посланы или получены при помощи параметров сокета, описанных в ip(7). Они обрабатываются ядром, только если включён соответствующий параметр в /proc (но даже если он отключен, параметры всё равно передаются пользователю). Смотрите ip(7).

Если при отсылке установлен флаг MSG_DONTROUTE, то адрес назначения должен указывать на адрес локального интерфейса, и пакеты посылаются только на этот интерфейс.

По умолчанию, Linux UDP выполняет обнаружение MTU (Maximum Transmission Unit) пути. Это означает, что ядро будет следить за MTU до IP-адреса назначения и возвращать EMSGSIZE, если запись пакета UDP превысит это значение. Когда это происходит, приложение должно уменьшить размер пакета. Также обнаружение MTU пути можно выключить с помощью параметра сокета IP_MTU_DISCOVER или в файле /proc/sys/net/ipv4/ip_no_pmtu_disc; подробней смотрите в ip(7). При отключении обнаружения UDP фрагментирует исходящий пакет, если его общий размер превышает MTU интерфейса. Однако по соображениям производительности и надёжности отключение не рекомендуется.

### Формат адреса
В UDP используется формат адреса IPv4 sockaddr_in, который описан в ip(7).

### Обработка ошибок
Все критические ошибки передаются пользователю в виде кода ошибки, который возвращается, даже если сокет не был соединен. Это относится также и к асинхронным ошибкам, при работе с сетью. Вы можете получить ошибку, относящуюся к предыдущим пакетам, посланным на том же сокете. Такое поведение отличается от поведения многих других реализаций BSD-сокетов, которые никогда не передают коды ошибок, если на сокете не установлено соединение. Поведение Linux в этом случае соответствует RFC 1122.

Для совместимости со старым кодом в Linux 2.0 и 2.2 можно установить параметр SOL_SOCKET равным SO_BSDCOMPAT, чтобы получать ошибки при работе с сетью, только если сокет был соединён (кроме ошибок EPROTO и EMSGSIZE). Ошибки, возникшие локально, передаются всегда. Поддержка данного параметра сокета была удалена в более новых ядрах; подробней смотрите в socket(7).

Если включён параметр IP_RECVERR, то все ошибки хранятся в очереди ошибок сокета и могут быть получены с помощью вызова recvmsg(2) с установленным флагом MSG_ERRQUEUE.

### Интерфейс /proc
Системные настройки параметров UDP доступны через файлы в каталоге /proc/sys/net/ipv4/.

udp_mem (начиная с Linux 2.6.25)

Вектор из трёх значений, управляющий количеством страниц, выделенных для очереди под все сокеты UDP.

min

При значении ниже этого количества страниц UDP не беспокоится о том, как потребляется память. Когда количество памяти, выделенной для UDP, превышает это значение, UDP начинает регулировать расход памяти.

pressure

Формат этого значения совпадает с tcp_mem (смотрите tcp(7)).

max

Количество страниц, выделенных для очереди под все сокеты UDP.

Значения по умолчанию этих трёх параметров вычисляются при запуске ОС исходя из количества имеющейся памяти.

udp_rmem_min (integer; значение по умолчанию: PAGE_SIZE; начиная с Linux 2.6.25)

Минимальный размер (в байтах) буферов приёма, используемых сокетами UDP в режиме регулирования. Каждый сокет UDP может использовать этот объём принимаемых данных, даже если общее количество страниц сокетов UDP превышает ограничение udp_mem.

udp_wmem_min (integer; значение по умолчанию: PAGE_SIZE; начиная с Linux 2.6.25)

Минимальный размер (в байтах) буферов отправки, используемых сокетами UDP в режиме регулирования. Каждый сокет UDP может использовать этот объём отправляемых данных, даже если общее количество страниц сокетов UDP превышает ограничение udp_mem.

### Параметры сокета
Для получения и задания параметров сокетов UDP используйте вызовы getsockopt(2) и setsockopt(2), соответственно. Значение аргумента уровня параметров должно быть равно IPPROTO_UDP. Если не указано обратного, значение optval является указателем на int.

В следующем списке представлены параметры только для сокетов UDP. О других параметрах, применимых к сокетам UDP, читайте в socket(7).

UDP_CORK (начиная с Linux 2.5.44)

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

### Вызовы ioctl
Данные ioctl доступны через вызов ioctl(2). Синтаксис:

```
int value;
error = ioctl(udp_socket, ioctl_type, &value);
```

FIONREAD (SIOCINQ)

В качестве параметра ожидается указатель на integer. Возвращает размер (в байтах) следующей ожидающей датаграммы, помещая его по указанному адресу, или 0, если нет ожидающей датаграммы. Предупреждение: при использовании FIONREAD невозможно понять, есть ли ожидающие датаграммы или просто следующая датаграмма не содержит данных. В этих случаях безопасней использовать select(2), poll(2), или epoll(7).

TIOCOUTQ (SIOCOUTQ)

Возвращает количество байт данных в локальной очереди отправки. Поддерживается только в Linux 2.4 и выше.

Дополнительно поддерживаются все ioctl, описанные в ip(7) и socket(7).

## ОШИБКИ
При отправке или приёме на сокете UDP могут быть получены все коды ошибок, описанные в socket(7) или ip(7).

ECONNREFUSED

С адресом назначения не связан ни один получатель. Эта ошибка может быть вызвана предыдущим пакетом, посланным через этот сокет.

## ВЕРСИИ
Параметр IP_RECVERR появился в Linux 2.2.

## СМОТРИТЕ ТАКЖЕ
ip(7), raw(7), socket(7), udplite(7)

Протокол пользовательских датаграмм описан в RFC 768.

В RFC 1122 описаны требования к узлу.

В RFC 1191 описан процесс обнаружения MTU маршрута.


udplite

title: udplite(7)

text:
# udplite(7)

## ИМЯ
udplite - облегчённый протокол пользовательских датаграмм

## ОБЗОР
\#include <sys/socket.h>

sockfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);

## ОПИСАНИЕ
Это реализация облегчённого протокола пользовательских датаграмм (UDP-Lite), описанная в RFC 3828.

UDP-Lite представляет собой расширение UDP (RFC 768), содержащее поддержку контрольных сумм переменной длины. Это даёт преимущества при передаче данных некоторых типов мультимедиа, для которых допустимо использовать слегка повреждённые датаграммы, если бы они не отбрасывались другими нижележащими протоколами.

Охват (coverage) контрольной суммы переменной длины задаётся с помощью параметра через setsockopt(2). Если параметр не установлен, то отличием от UDP будет только другой идентификатор протокола IP (номер по IANA — 136).

Реализация UDP-Lite представляет собой полноценное расширение udp(7) — используется тот же программный интерфейс и поведение; кроме этого имеются два параметра сокета для управления охватом контрольной суммы.

### Формат адреса
В UDP-Litev4 используется формат адреса sockaddr_in, описанный в ip(7). В UDP-Litev6 используется формат адреса sockaddr_in6, описанный в ipv6(7).

### Параметры сокета
Для получения и задания параметров сокетов UDP-Lite, используйте вызовы getsockopt(2) и setsockopt(2), соответственно. Значение аргумента уровня параметров должно быть равно IPPROTO_UDPLITE. Кроме того, сокетам UDP-Lite доступно большинство параметров сокета IPPROTO_UDP. Дополнительная информация приведена в udp(7).

Следующие параметры относятся только к UDP-Lite.

UDPLITE_SEND_CSCOV

Этим параметром задаётся охват данных контрольной суммой; в качестве аргумента ожидается значение типа int, которым задаётся охват в диапазоне 0..2^16-1.

Значение 0 означает, что охватывается вся датаграмма. Значения 1-7 некорректны (RFC 3828, 3.1) и округляются до минимального охвата — 8.

При использовании джумбограмм (jumbograms) IPv6 (RFC 2675), охват контрольной суммы в UDP-Litev6 ограничен первыми 2^16-1 октетами (согласно RFC 3828, 3.5). Большие значения безошибочно урезаются до 2^16-1. Текущее значение охвата всегда можно запросить с помощью getsockopt(2).

UDPLITE_RECV_CSCOV

Это аналог с приёмной стороны, использует тот же формат аргумента и диапазон значений, что и у UDPLITE_SEND_CSCOV. Данный параметр не требуется для приёма трафика с контрольной суммой частичного охвата. Он предназначен для фильтрации трафика: если включён, то это указывает ядру отбрасывать все пакеты, у которых охват менее заданного значения.

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

## ОШИБКИ
Могут быть возвращены любые ошибки, описанные для udp(7). UDP-Lite не вносит никаких дополнительных типов ошибок.

## ФАЙЛЫ
/proc/net/snmp

Основные счётчики статистики UDP-Litev4.

/proc/net/snmp6

Основные счётчики статистики UDP-Litev6.

## ВЕРСИИ
UDP-Litev4/v6 впервые появился в Linux 2.6.20.

## ДЕФЕКТЫ
Если поддержка в glibc отсутствует, то требуются следующие определения:

```
#define IPPROTO_UDPLITE     136
#define UDPLITE_SEND_CSCOV  10
#define UDPLITE_RECV_CSCOV  11
```

## СМОТРИТЕ ТАКЖЕ
ip(7), ipv6(7), socket(7), udp(7)

В RFC 3828 описан облегчённый протокол пользовательских датаграмм (Lightweight User Datagram Protocol — UDP-Lite).

Файл Documentation/networking/udplite.txt в дереве исходного кода ядра Linux


unicode

title: unicode(7)

summary: универсальный набор символов

text:
# unicode(7)

## ИМЯ
unicode - универсальный набор символов

## ОПИСАНИЕ
Universal Character Set (UCS) (универсальный набор символов — Юникод) определён в международном стандарте ISO 10646. UCS содержит все символы других стандартов. Его использование гарантирует «полную взаимозаменяемость», другими словами, таблицы для преобразований могут быть построены таким образом, что не произойдёт потери информации при преобразовании строки из сторонней кодировки в UCS и обратно.

UCS содержит символы, необходимые для представления практически всех известных сейчас языковых символов. В него включены не только языковые символы из латинской, греческой, кириллицы, иврита, арабской, армянской, грузинской письменности, но и китайские, японские и корейские идеограммы, а также символы из таких письменностей как хирагана, катакана, хангул, деванагари, бенгальской, гурмуки, гуджарати, ория, тамильской, телугской, каннада, малаяламской, тайской, лаосской, кхмерской, бопомофо, тибетской, рунической, эфиопской, канадского слогового письма, чероки, монгольской, охамской, мьянмарской, синхальской,таанской, юи и других. По ещё не включённым письменностям постоянно ведутся работы для поиска их самой оптимальной кодировки для компьютеров и добавлении. К ним относятся не только различные иероглифы и письменности из индо-европейской исторической группы, но и некоторые искусственные языки, такие как тенгвар, сирт и клингонский. Также UCS содержит большое множество графических, типографических, математических и научных символов, используемых в таких программах, как TeX, Postscript, APL, MS-DOS, MS-Windows, Macintosh, шрифтах OCR и многих других текстовых процессорах и издательских системах.

Стандарт UCS (ISO 10646) описывает 31-битную архитектуру набора символов, состоящую из 128 24-битных групп, каждая из которых разделена на 256 16-битных плоскостей, которые, в свою очередь, состоят из 256 8-битных строк и 256 колонок, каждая для одного символа. В 1 части стандарта (ISO 10646-1) определяются первые 65534 кодируемых позиций (с 0x0000 по 0xfffd), каждая из которых образует Basic Multilingual Plane (BMP) (основную многоязычную матрицу), являющуюся плоскостью 0 в группе 0. В 2 части стандарта (ISO 10646-2) добавляются символы, не вошедшие в BMP, в некоторые дополнительные плоскости в диапазоне от 0x10000 до 0x10ffff группы 0. Пока нет планов по добавлению символов за предел 0x10ffff в существующий стандарт, поэтому в обозримом будущем во всём закодированном пространстве в действительности будет использоваться только малая часть группы 0. BMP содержит все символы, используемые в других наборах символов. Дополнительные плоскости, добавляемые ISO 10646-2 покрывают некоторые особенные, специальные и экзотические символы, используемые в науке, при печати словарей, издательской индустрии, протоколах высокого уровня и некоторыми энтузиастами.

Представление каждого символа в UCS в виде -байтного слова называют формой UCS-2 (только для символов BMP), UCS-4 называют представление каждого символа 4-байтным словом. Также существуют 2 формы кодировки: UTF-8 — для совместимости со старым ПО, работающим с кодировкой ASCII, и UTF-16 — для совместимости с ПО, работающим с кодировкой UCS-2, для не BMP символов до 0x10ffff позиции.

Символы UCS от 0x0000 до 0x007f идентичны обычному набору символов US-ASCII, а символы в диапазоне от 0x0000 до 0x00ff идентичны символам ISO 8859-1 (Latin-1).

### Комбинирующие символы
Некоторые позиции в UCS зарезервированы для комбинирующих символов. Они аналогичны клавишам печатной машинки, которые служат для набора букв с ударением. Комбинирующий символ лишь добавляет ударение к предыдущему символу. Наиболее употребляемые символы, требующие ударения, имеют собственный код в UCS, однако комбинирующий символ позволяет добавить ударение или другой диакритический знак к любому символу. Комбинирующие символы всегда указываются после буквы, которую они изменяют. Например, немецкий символ «умляут-А» (латинская заглавная буква А с диерезой) может быть представлен как зарезервированный специальный символ UCS с кодом 0x00c4, или как комбинация обыкновенной «латинской заглавной буквы А» и последующей «комбинирующей диерезы: 0x0041 0x0308.

Комбинирующие символы являются необходимым инструментом для кодирования символов тайского языка, математики и для пользователей международного фонетического алфавита (International Phonetic Alphabet).

### Уровни реализации
Так как не все системы могут поддерживать такой сложный механизм, как реализацию комбинирующих символов, стандарт ISO 10646-1 предусматривает следующие три уровня реализации UCS:

Уровень 1

Комбинирующие символы и символы Hangul Jamo (вариант кодировки корейского письма, где слоги хангыль кодируются по два или по три гласных кода) не поддерживаются.

Уровень 2

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

Уровень 3

Поддерживаются все символы UCS.

Стандарт Unicode 3.0, опубликованный Unicode Consortium, содержит точную реализацию UCS Basic Multilingual Plane на уровне 3, как описано в стандарте ISO 10646-1:2000. В Unicode 3.1 добавлены дополнительные плоскости ISO 10646-2. Стандарт Юникода и технические сообщения, публикуемые Unicode Consortium, предоставляют много дополнительной информации по семантике и рекомендации по использованию разных символов. Также поясняются принципы и алгоритмы для редактирования, сортировки, сравнения, нормализации, преобразования и вывода строк Юникода.

### Юникод в Linux
В системах GNU/Linux тип языка Cи wchar_t является 32-битным знаковым целым типом. Его значения всегда интерпретируются библиотекой Си как значения кодов UCS (во всех локалях); в этом случае, согласно стандарту ISO C99, библиотека GNU C определяет константу __STDC_ISO_10646__.

UCS/Unicode может использоваться подобно ASCII в потоках ввода/вывода, соединениях с терминалами, в текстовых файлах, названиях файлов и в переменных окружения в виде многобайтовой кодировке UTF-8, совместимой с ASCII. Для обозначения использования UTF-8 как кодировки во всех приложениях должна быть выбрана подходящая локаль через переменные окружения (например, «LANG=ru_RU.UTF-8»).

Функция nl_langinfo(CODESET) возвращает название выбранной кодировки. Библиотечные функции, такие как wctomb(3) и mbsrtowcs(3), могут использоваться для преобразования внутренних символов wchar_t и строк в кодировку системных символов и наоборот; wcwidth(3) определяет, на сколько позиций (0–2) сместился курсор при выводе символа.

### Закрытые используемые области (Private Use Areas, PUA)
В основной многоязычной матрице диапазон с 0xe000 до 0xf8ff никогда не будет использован для обозначения стандартных символов, он зарезервирован для частного использования. В Linux эта закрытая область делится на: диапазон 0xe000 по 0xefff может использоваться конечным пользователем; диапазон 0xf000 по 0xf8ff (так называемая зона Linux) может использоваться для расширений, согласованных среди пользователей Linux. В настоящее время регистрацией символов в зоне Linux занимается LANANA, а сам реестр находится в файле Documentation/admin-guide/unicode.rst исходного кода ядра Linux (в Documentation/unicode.txt до Linux 4.10).

Две другие плоскости зарезервированы для закрытого использования, плоскость 15 (дополнительная закрытая используемая область-A, диапазон от 0xf0000 до 0xffffd) и плоскость 16 (дополнительная закрытая используемая область-B, диапазон от 0x100000 до 0x10fffd).

### Литература
*

Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane. International Standard ISO/IEC 10646-1, International Organization for Standardization, Geneva, 2000.

Официальная спецификация UCS. Доступна с http://www.iso.ch/.

- The Unicode Standard, Version 3.0. The Unicode Consortium, Addison-Wesley, Reading, MA, 2000, ISBN 0-201-61633-5.

- S. Harbison, G. Steele. C: A Reference Manual. Fourth edition, Prentice Hall, Englewood Cliffs, 1995, ISBN 0-13-326224-3.

Хорошая книга о программировании на языке Си. Четвёртое издание включает в себя описание поправки 1, сделанной в стандарте ISO C90 в 1994 году. Эта поправка добавляет к стандарту большое количество новых библиотечных функций Си для поддержки кодирования широких и многобайтовых символов, но она не так полна как стандарт ISO C99, который расширяет поддержку широких и многобайтовых символов.

*

Unicode Technical Reports.

http://www.unicode.org/reports/

*

Markus Kuhn: UTF-8 and Unicode FAQ for UNIX/Linux.

http://www.cl.cam.ac.uk/~mgk25/unicode.html

*

Bruno Haible: Unicode HOWTO.

http://www.tldp.org/HOWTO/Unicode-HOWTO.html

## СМОТРИТЕ ТАКЖЕ
locale(1), setlocale(3), charsets(7), utf-8(7)