Ack лучше grep

Хочу рассказать об одной утилите для поиска, которая очень сильно упрощает жизнь. Когда я попадаю на сервер и мне надо что-то поискать я первым делом проверяю установлен ли ack. Эта утилита является прекрасной заменой grep, а также в какой-то мере find и wc. Почему не grep? Ack имеет более приятные настройки из коробки, более человеко-читаемые опции, perl регулярки и систему конфигов. Если вы любите( приходится ) искать через терминал, то вам однозначно стоит ее попробовать.

Базовые возможности

Ack по умолчанию рекурсивен, а писать меньше опций всегда хорошо.

Мы можем использовать флаг -w, чтобы сказать утилите искать экземпляр нашего шаблона, окруженный границами слов(пробельными символами, слэшом и т.д.).

Ack поддерживает поиск по типу файлов. Например, найдем версию модуля в json файлах.

Полный список поддерживаемых типов файлов можно посмотреть с помощью:

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

Считаем сколько раз process встречается в файле test.log, не учитывая регистр (-i).

Мы можем посчитать вхождения не просто в одном конкретном файле, а в группе. Доработаем предыдущий поиск слова mysql: посчитаем кол-во вхождений слов (-с) в *.js файлах(—js), исключив файлы в которых ничего не найдено (-h) и просуммировав итог.

Кроме того, мы можем получить развернутый отчет по кол-ву вхождений в каждый файл с помощью (-l)

Если вам необходим дополнительный контекст для поиcка, можно попросить ack
показать строки до (-B) и после (-A) найденного выражения. Для этого надо указать после опции кол-во строк, которое необходимо показать.

А если нужно и то и другое, то используйте (-С)

Имеется также опция(-v) для инвертирования поиска, т.е показывать строки в которых нет заданного шаблона.

Регулярные выражение

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

Более сложный пример

Ack имеет полезные опции —range-start и —range-end. Они помогают, когда
данные хранятся не одной строкой, а в многострочном виде.

Например, есть файл с sql кодом

Извлечем названия колонок. Началом блока будет строка начинающаяся на SELECT, а концом строка начинающаяся на FROM.

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

Работа с файлами

Получить список файлов с определенным расширением

Найти все js файлы имя которых начинается с P*, используя опцию(-g).

Конфигурация

Утилита имеет свой конфиг файл. Можно иметь как глобальный конфиг для пользователя(

Большинство опций, которые прописываются в конфиги можно и руками прописывать при вызове. Разберем несколько из них.

Игнорировать папку при поиске

Источник

Установка и использование Ack, замены Grep, на сервере Ubuntu 14.04

Вступление

Linux- и Unix-подобные системы имеют множество инструментов для поиска текста в файле или каталоге. Один из наиболее распространенных – grep (что значит global regular expression print).

При помощи grep можно без труда найти любой представленный в виде регулярных выражений шаблон в пределах текстового ввода любого объема. Тем не менее, это не самый быстрый инструмент, он был создан как утилита общего назначения без какой-либо оптимизации. Так, для поиска исходного кода был изобретен инструмент по имени ack как альтернатива grep. Он использует регулярные выражения Perl для эффективного поиска исходного кода по шаблону и при этом отфильтровывает нежелательные результаты.

Данное руководство демонстрирует, как использовать ack в качестве мощной альтернативы grep для поиска шаблонов исходного кода. Инструмент ack доступен на любой платформе, которая может использовать Perl, но в данном руководстве используется Ubuntu 14.04.

Установка Ack

Для начала нужно установить инструмент ack на сервер.

На сервере Ubuntu или Debian это так же просто, как установить утилиту из репозитория по умолчанию. Пакет называется ack-grep:

sudo apt-get update
sudo apt-get install ack-grep

Поскольку исполняемый файл также называется ack-grep, можно сказать системе сократить его имя до ack, чтобы использовать его в командной строке, введя следующую команду:

Теперь инструмент будет отвечать на имя ack вместо ack-grep.

Установка ack на других системах может отличаться. Модуль Perl в CPAN называется App::Ack. На других дистрибутивах Linux имена пакетов данного инструмента могут отличаться.

На что обращает внимание ack?

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

Инструмент ack был разработан специально для поиска исходного кода программ. Потому ack ищет определенные файлы и игнорирует другие.

К примеру, при поиске структуры каталогов проекта иерархия репозитория системы управления версиями, как правило, не нужна. Она содержит информацию о более старых версиях файла и, скорее всего, приведет к многочисленным повторам. Ack понимает, что здесь искать не нужно, поэтому он игнорирует эти каталоги, благодаря чему результат получается более сжатым и содержит меньше ошибочных данных.
Подобным образом он игнорирует общие резервные файлы, созданные некоторыми текстовыми редакторами. Также нет смысла искать с помощью ack некоторые файлы, которые обычно встречаются в исходных каталогах: сжатые версии веб-файлов, изображения, PDF-файлы и т.д. Все эти функции положительно влияют на результаты почти каждого поиска. Кроме того, эти настройки всегда можно изменить.

Это выведет определенные по расширению файлы, а также файлы, вызвающие интерпретатор Python с использованием magic number:

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

Подготовка среды

Лучший способ продемонстрировать работу ack – это использовать его в каталоге исходного кода.

Дерево исходных кодов можно без труда загрузить с открытого сайта вроде GitHub. Установите git, чтобы скачать репозиторий:

sudo apt-get install git

Теперь можно загрузить какой-нибудь проект. Проект neovim – отличный пример, поскольку содержит большое количество различных файлов. Скопируйте репозиторий данного проекта в домашний каталог:

git clone https://github.com/neovim/neovim.git

Теперь перейдите в каталог этого проекта:

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

ls
BACKERS.md CMakeLists.txt Doxyfile scripts uncrustify.cfg
clint-files.txt config Makefile src vim-license.txt
clint.py contrib neovim.rb test
cmake CONTRIBUTING.md README.md third-party

Чтобы облегчить работу, нужно настроить некоторые функции.

Так, если результаты больше, чем окно терминала, то нужно передавать выход прямо в less, чтобы предотвратить выход результата за пределы экрана. Для этого наберите:

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

Простой поиск с ack

Для начала нужно ознакомиться с разницей между объектами поиска grep и ack.

Grep выводит каждый файл каталога, совпавший с шаблоном. Чтобы узнать общее количество файлов в проекте neovim, введите:

На момент написания статьи проект neovim состоит из 566 файлов. Теперь используйте ack, чтобы сравнить результат и увидеть, сколько файлов из общего их количества будет выведено:

Как видите, ack отбросил около 12% имеющихся файлов.

К примеру, нужно найти все файлы проекта, в которых встречается шаблон “restrict”. Для этого используйте:

Как видите, ack разделяет найденные экземпляры “restrict”, указывая файл, в котором было обнаружено совпадение. Кроме того, он дает точный номер строки.

Обратите внимание, некоторые из выведенных результатов неточно совпадают с шаблоном: кроме совпадений с “restrict” выведены также вариации вроде “restricted” и “restriction”. Но что если нужно найти только “restrict”?

Как можно видеть, теперь результат показывает только строки, содержащие “restrict”; вариации шаблона были отброшены, и результат имеет компактный вид.

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

Чтобы ack показывал только совпадения, обнаруженные в файлах Python, просто введите:

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

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

Анализ поиска

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

Этот результат содержит даже файлы, в которых нет совпадений с шаблоном.

Как видите, таких строк 101. Теперь устраните вариации шаблона, установив четкие границы слова, что значительно сократит результат:

Конечно, если указать, что нужны только файлы Python, то результат сузится до одного совпадения:

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

Это можно проверить, просмотрев сроки поиска при помощи команды time:

А теперь укажите язык поиска:

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

Изменение результатов поиска

Как видите, данный результат не содержит файлов, в которых не обнаружено совпадений с шаблоном.

Чтобы узнать столбец, в котором найдено совпадение, ack выведет эту информацию с помощью параметра –column:

Второе число (после номера строки) – это номер столбца, в котором находится первый символ совпадения. Некоторые текстовые редакторы позволяют перейти по номеру строки и столбца.

К примеру, если открыть файл client.py в редакторе vim, то можно перейти в точное местоположение совпадения, набрав 107G, чтобы перейти в нужную строку, а затем 31|, чтобы перейти в нужный столбец. Такое точное расположение может быть очень полезно, особенно при поиске общей подстроки в пределах больших слов.

Работа с типами файлов

Ранее были рассмотрены способы фильтрации файлов по их типу. Чтобы ack показывал только файлы языка С, наберите:

Чтобы просмотреть список языков, которые знает ack, а также узнать, какие расширения и свойства файлов он связывает с каждой категорией, наберите:

Как видите, это показывает это дает параметры соответствия для каждого типа файлов. Можно также сказать ack для исключить файлы определенной категории, предварительно введя “no”.

Таким образом, чтобы просмотреть количество имеющихся файлов языка С, наберите:

Можно выполнить обратную операцию и просмотреть количество файлов, не относящиеся к языку С:

Команда –type-add вносит дополнительные правила совпадения для указанного типа (TYPE). В данном случае фильтром (FILTER) является ext (совпадение по расширению файла).

Итак, команда будет иметь следующий вид:

Однако текущая команда не выполняет никакого поиска. Чтобы добавить поиск, введите:

Чтобы создать полностью новый тип, используйте опцию –type-set. Синтаксис имеет точно такой же вид, единственное отличие состоит в том, что он используется для определения несуществующего типа.

Как уже было отмечено, TYPE в базовом синтаксисе означает имя категории, а в качестве фильтра (FILTER) используется расширение файла, но можно использовать и другие фильтры.

Например, фильтр is используется для поиска файла по имени. Так, можно создать TYPE example, который совпадет с файлом example.txt, внеся в файл

Итоги

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

Источник

СОДЕРЖАНИЕ

Знаки подтверждения

Код ASCII включает в себя символ ACK (0000110 ₂ или 6 ₁₆ ), который может быть передан, чтобы указать успешное получение, и символ NAK (0010101 ₂ или 15 ₁₆ ), который может быть передан для указания невозможности или отказа при приеме. Unicode предоставляет видимые символы для этих символов: U + 2406 (␆) и U + 2415 (␕).

Использование протокола

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

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

Другие протоколы основаны на NAK, что означает, что они отвечают на сообщения только в случае возникновения проблемы. Примеры включают наиболее надежные протоколы многоадресной передачи, которые отправляют NAK, когда получатель обнаруживает отсутствующие пакеты. В других протоколах используются как NAK, так и ACK. Двоичные синхронные коммуникации (Bisync) и Adaptive Link Rate (для энергоэффективного Ethernet ) являются примерами.

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

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

Подтверждение оборудования

Последовательная шина I²C имеет временной интервал для бита подтверждения после каждого байта.

Источник

4.4.3 Протокол TCP

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

Предположим, что из точки А передаются данные в точку Б и эти точки непосредственно связаны каналом с пропускной способностью В, которая больше максимальной скорости передачи узла А (F_A). Пусть узел Б способен принимать данные со скоростью F_Б. Если узел А будет передавать данные со скоростью F_Б, потерь не будет. Но если А не знает значения F_Б, он будет пытаться осуществлять передачу со скоростью F_A. Это в конце концов приведет к переполнению буфера в узле Б и к потере пакетов. Отсутствие подтверждения получения пакета уведомит узел А о том, что скорость передачи слишком велика.

Проблема может быть решена методом итеративного алгоритма выбора скорости передачи с использованием детектирования отсутствия подтверждений или путем присылки узлом Б уровня заполнения его буфера. Второй вариант представляется на первый взгляд более привлекательным. Беда в том, что переполнение буфера и потери пакетов могут происходить не только в узле Б, но в любом другом промежуточном узле. Причем переполнение может происходить за счет какого-то конкурирующего трафика, источником которого не является узел А. Для задания скорости передачи отправителя был создан механизм “медленного” старта, который определял значения окна перегрузки (cwnd) и порога медленного старта (ssthresh).

Рассмотрим вариант локальной сети с тремя переключателями и шестью машинами (см. рис. ниже). Будем считать, что буферы имеются только на входе переключателя. В случае маршрутизаторов картина может оказаться сложнее. Пусть происходят одновременные обмены по маршрутам А-F; B-D; В-E, C-E и A-C. Эти обмены асинхронны и могут начинаться и завершаться в произвольные моменты времени.

Фрагмент локальной сети

Примером прикладного процесса, использующего TCP, может служить FTP, при этом будет работать стек протоколов ftp/tcp/ip/ethernet. Хотя протоколы UDP и TCP могли бы для сходных задач использовать разные номера портов, обычно этого не происходит. Модули TCP и UDP выполняют функции мультиплексоров/демультиплексоров между прикладными процессами и IP-модулем. При поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль согласно коду, записанному в поле протокола данного IP-пакета. Формат сегмента (пакета) TCP представлен ниже на рис. 4.4.3.1. Если вы хотите глубже разобраться с особенностями работы этого протокола, рекомендуется воспользоваться услугами программы tcpdump, которая позволяет отслеживать содержимое отправляемых и приходящих пакетов в ходе реализации сессии.

Если IP-протокол работает с адресами, то TCP, также как и UDP, с портами. Именно с номеров портов отправителя и получателя начинается заголовок TCP-сегмента. 32-битовое поле код позиции в сообщении определяет порядковый номер первого октета в поле данных пользователя. В приложениях передатчика и приемника этому полю соответствуют 32-разрядные счетчики числа байт, которые при переполнении обнуляются. При значении флага syn=1 в этом поле лежит код ISN (Initial Sequence Number; смотри ниже описание процедуры установления связи), выбираемый для конкретного соединения. Первому байту, передаваемому через созданное соединение, присваивается номер ISN+1. Значение ISN может задаваться случайным образом. Но в UNIX 4.4BSD при загрузке ОС ISN делается равным 1 (это нарушает требования RFC), а далее увеличивается на 640000 каждые полсекунды. Аналогичная инкрементация осуществляется при установлении нового соединения. В RFC рекомендуется увеличивать счетчик ISN на 1 каждые 4 микросекунды.

32-битовое поле номер октета, который должен прийти следующим содержит код, который на единицу больше номера последнего успешно доставленного (принятого) байта. Содержимое этого поля интерпретируется получателем сегмента, только если присутствует флаг ACK. В заголовках всех сегментов, передаваемых после установления соединения это поле заполняется, а флаг AСK=1.

Таблица 4.4.3.1 Значения бит поля флаги

Формат TCP-сегмента

Рис. 4.4.3.1 Формат TCP-сегмента

Поле опции зарезервировано на будущее и в заголовке может отсутствовать, его размер переменен и дополняется до кратного 32-бит с помощью поля заполнитель. Формат поля опции представлен на рис. 4.4.3.2. В настоящее время определены опции:

0 Конец списка опций.
1 Никаких операций. Используется для заполнения поля опции до числа октетов, кратного 4.
2 Максимальный размер сегмента (MSS).

В поле вид записывается код опции, поле LEN содержит число октетов в описании опции, включая поля вид и LEN. Определены также опции со значением вид=4,5,6,7. В предложении T/TCP (RFC-1644) описаны опции 11, 12 и 13. Поле данные может иметь переменную длину, верхняя его граница задается значением MSS (Maximum Segment Size). Значение MSS может быть задано при установлении соединения каждой из сторон независимо. Для Ethernet MSS=1452 байта.

Формат опций для TCP-сегментов

Рис. 4.4.3.2. Формат опций для TCP-сегментов

Поле данные в TCP-сегменте может и отсутствовать, характер и формат передаваемой информации задается исключительно прикладной программой, теоретически максимальный размер этого поля составляет в отсутствии опций 65495 байт (на практике, помимо MSS, нужно помнить, например, о значении MTU для Ethernet, которое немногим больше 1500 байт). TCP является протоколом, который ориентируется на согласованную работу ЭВМ и программного обеспечения партнеров, участвующих в обмене информацией. Установление связи клиент-сервер осуществляется в три этапа:

Стандартная процедура установления связи представлена на рисунке 4.4.3.3 (под словом “стандартная” подразумевается отсутствие каких-либо отклонений от штатного режима, например, одновременного открывание соединения со стороны сервера и клиента). Если же соединение одновременно инициируется клиентом и сервером, в конечном итоге будет создан только один виртуальный канал.

Рис. 4.4.3.3. Алгоритм установления связи. В рамках представлены состояния клиента и сервера; пунктиром отмечены изменения cостояния после посылки сообщения (см. также рис. 4.4.3.4)

Каждое соединение должно иметь свой неповторимый код ISN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа («passive open»), а операционная система на другом конце ставится в режим активного доступа («active open»). Протокол TCP предполагает реализацию 11 состояний (established, closed, listen, syn_sent, syn_received и т.д.; см. также RFC-793), переход между которыми строго регламентирован. Машина состояний для протокола TCP может быть описана диаграммой, представленной на рис. 4.4.3.4. Здесь состояние closed является начальной и конечной точкой последовательности переходов. Каждое соединение стартует из состояния closed. Из диаграммы машины состояний видно, что ни одному из состояний не поставлен в соответствие какой-либо таймер. Это означает, что машина состояний TCP может оставаться в любом из состояний сколь угодно долго. Исключение составляет keep-alive таймер, но его работа является опционной, а время по умолчанию составляет 2 часа. Это означает, что машина состояния может оставаться 2 часа без движения. В случае, когда две ЭВМ (C и S) попытаются установить связь друг с другом одновременно, реализуется режим simultaneous connection (RFC-793). Обе ЭВМ посылают друг другу сигналы SYN. При поучении этого сигнала партнеры посылают отклики SYN+ACK. Обе ЭВМ должны обнаружить, что SYN и SYN+ACK относятся к одному и тому же соединению. Когда C и S обнаружат, что SYN+ACK соответствует посланному ранее SYN, они выключат таймер установления соединения и перейдут непосредственно в состояние syn_recvd (смотри рис. 4.4.3.4).

Рассмотрим пример установления соединения для случая FTP-запроса (См. также http://www.cis.ohio-state.edu/

dolske/gradwork/cis694q). Пусть клиент С запускает процесс установления FTP-соединения с сервером s. Обычный порядок установления соединения показан ниже (см. рис. 4.4.3.3):

Сервер, получив SYN, откликается посылкой другого SYN. Когда С получает SYN от S (но не получает ACK, например, из-за его потери или злого умысла), он предполагает, что имеет место случай одновременного открытия соединения. В результате он посылает syn_ack, отключает таймер установления соединения и переходит в состояние syn_received. Сервер получает syn_ack от C, но не посылает отклика. Тогда С ожидает получения syn_ack в состоянии syn_received. Так как время пребывания в этом состоянии не контролируется таймером, С может остаться в состоянии syn_received вечно. Из-за того, что переходы из состояния в состояние не всегда четко определены, протокол TCP допускает и другие виды атак (некоторые из них описаны в разделе “Сетевая безопасность”), там же рассмотрены алгоритмы задания и изменения ISN.

Хотя TCP-соединение является полнодуплексным, при рассмотрении процесса разрыва связи проще его рассматривать как два полудуплексных канала, каждый из которых ликвидируется независимо. Сначала инициатор разрыва посылает сегмент с флагом FIN, сообщая этим партнеру, что не намерен более что-либо передавать (FIN посылается, как правило в результате вызова приложением функции close). Когда получение этого сегмента будет подтверждено (ACK), данное направление передачи считается ликвидированным (реализуется полузакрытие соединения). При этом передача информации в противоположном направлении может беспрепятственно продолжаться. Когда партнер закончит посылку данных, он также пошлет сегмент с флагом FIN. По получении отклика ACK виртуальный канал считается окончательно ликвидированным.

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

Всего в машине конечных состояний протокола TCP имеется 11 состояний (CLOSED, LISTEN, SYN_RCVD, SYN_SENT и т.д., введены в RFC-793). Состояние CLOSED является начальной и конечной точкой диаграммы. ESTABLISHED указывает на то, что система находится в состоянии с установленным соединением. Четыре состояния в левом углу помещены в границы зеленой зоны и соответствуют активному закрытию. Состояния CLOSE_WAIT и LAST_ACK относятся к пассивному закрытию. Переход из состояния SYN_RCVD в LISTEN возможно, если переход в SYN_RCVD осуществлен из состояния LISTEN, а не из состояния SYN_SENT (одновременное открытие двух соединений, получение RST вместо финального ACK).

Машина состояний для протокола TCP

Состояние TIME_WAIT часто называется ожиданием длительностью 2MSL (Maximum Segment Lifetime). Значение MSL задается конкретной реализацией и определяет предельную величину пребывания сегмента в сети. В RFC-793 рекомендуется задавать MSL равным 2 мин. Но нужно помнить, что ТСР-сегмент транспортируется в IP-дейтаграмме, содержащем поле TTL. Когда модуль выполнил активное закрытие и в ответ на FIN послал ACK, соединение должно оставаться в состоянии TIME_WAIT в течение времени, в два раза превышающем MSL. Сокет, используемый данным соединением не может быть задействован другим соединением в продолжении указанного времени. Все сегменты данного соединения, задержавшиеся в пути, во время TIMR_WAIT отбрасываются. Это гарантирует то, что сегменты старого соединения не будут восприняты новым соединением. Такая процедура препятствует перезапуску серверов в течение 1-4 минут, так как в течение данного времени не могут использоваться стандартные значения номеров портов.

Состояние FIN_WAIT_2 сопряжено со случаем, когда одна сторона послала сегмент FIN, а другая сторона подтвердила его получение. Если данное соединение не нужно, можно ждать, когда приложение другой стороны получит код конца файла и пришлет свой флаг FIN. Только после этого система перейдет из состояний FIN_WAIT_2 в состояние TIME_WAIT. Теоретически такое ожидание может быть бесконечным. Другая сторона при этом остается в состоянии CLOSE_WAIT, пока приложение не вызовет функцию close. Для решения проблемы часто вводят дополнительный таймер.

В ТСР возможна ситуация, когда обе стороны запускают процедуру закрытия одновременно (посылают FIN), что в протоколе ТСР вполне допустимо. Каждая из сторон при этом переходит из состояния ESTABLISHED в состояние FIN_WAIT_1 (после вызова операции closed). По получении FIN стороны переходят из состояния FIN_WAIT_1 в состояние CLOSING и посылают ACK. После получения ACK происходит переход в состояние TIME_WAIT.

Когда оператор, работая в диалоговом режиме, нажимает командную клавишу, сегмент, в который помещается эта управляющая последовательность, помечается флагом PSH (push). Это говорит приемнику, что информация из этого сегмента должна быть передана прикладному процессу как можно скорее, не дожидаясь прихода еще какой-либо информации. Сходную функцию выполняет флаг URG. URG позволяет выделить целый массив данных, так как активизирует указатель последнего байта важной информации. Будет ли какая-либо реакция на эту «важную» информацию определяет прикладная программа получателя. URG-режим используется для прерываний при работе с FTP, telnet или rlogin. Если до завершения обработки «важной» информации придет еще один сегмент с флагом URG, значение старого указателя конца «важного» сообщения будет утеряно. Это обстоятельство должно учитываться прикладными процессами. Так telnet в командных последовательностях всегда помещает префиксный байт с кодом 255.

Алгоритм Нагля

В режиме удаленного терминала (telnet/ssh) при нажатии любой клавиши формируется и поcылается 41-октетный сегмент (здесь не учитываются издержки Ethernet), который содержит всего один байт полезной информации. В локальной сети здесь проблем не возникает, но в буферах маршрутизаторов в среде Интернет могут возникнуть заторы. Эффективность работы может быть улучшена с помощью алгоритма Нагля (Nagle, 1984; RFC-896). Нагль предложил при однобайтовом обмене посылать первый байт, а последующие буферизовать до прихода подтверждения получения посланного. После этого посылаются все буферизованные октеты, а запись в буфер вводимых кодов возобновляется. Если оператор вводит символы быстро, а сеть работает медленно, этот алгоритм позволяет заметно понизить загрузку канала. Встречаются, впрочем, случаи, когда алгоритм Нагля желательно отключить, например, при работе в Интернет в режиме Х-терминала, где сигналы перемещения мышки должны пересылаться немедленно, чтобы не ввести в заблуждение пользователя относительно истинного положения маркера.

Синдром узкого окна

Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня.

Кларк предложил не посылать уведомление о ненулевом значении ширины окна при считывании одного байта, а лишь после освобождения достаточно большого пространства в буфере. Например, когда адресат готов принять MSS байтов или когда буфер наполовину пуст.

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

Идея скользящего окна отображена на рис. 4.4.3.5. Здесь предполагается, что ширина окна равна 7 (k=7; это число может меняться в очень широких пределах).

Рис. 4.4.3.5. Схема использования скользящего окна

Для протокола TCP механизм скользящего окна может работать на уровне октетов или сегментов. В первом случае нужно учитывать каждый раз размер поля данных переданного и подтвержденного сегмента. В TCP-протоколе используется три указателя (стрелки на рис. 4.4.3.3б):

Первый указатель определяет положение левого края окна, отделяя посланный сегмент, получивший подтверждение, от посланного сегмента, получение которого не подтверждено. Второй указатель отмечает правый край окна и указывает на сегмент, который может быть послан до получения очередного подтверждения. Третий указатель помечает границу внутри скользящего окна между уже посланными сегментами и теми, которые еще предстоит послать. Получатель организует аналогичные окна для обеспечения контроля потока данных. Если указатель 3 совпадет с указателем 2, отправитель должен прервать дальнейшее отправление пакетов до получения хотя бы одного подтверждения. Обычно получатель посылает одно подтверждение (ACK) на два полученных сегмента.

Эволюция ширины окна при медленном старте

Рис. 4.4.3.6. Эволюция ширины окна при медленном старте

Влияние потери пакетов на пропускную способность обсуждалась, например, в The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm. Matthew Mathis, Je rey Semke, Jamshid Mahdavi. В статье приводится формула зависимости пропускной способности Т [Мбит/с] для ТСР-сессии от вероятности потери пакета p.

Рис. 4.4.3.7. Зависимость пропускной способности от вероятности потери пакета

Таким образом в Интернет при вероятности потери пакета 1% и RTT=50 мсек максимальная пропускная способность будет меньше 3 Мбит/с вне зависимости от широкополосности канала.