Введение rfc 2068

Содержание

RFC и STD — сущность и процедура формирования

IETF (Internet Engineering Task Force — Рабочая группа по проектированию Интернет-технологий, www.ietf.org) по существу является большим международным открытым сообществом разработчиков, операторов, изготовителей и исследователей в области сетевых технологий, занимающихся вопросами развития архитектуры сети Интернет и способов ее использования. Она открыта для всех, кто интересуется Интернет-технологиями. Основная сфера деятельности IETF состоит собственно в разработке стандартов сети Интернет, их эффективной реализации и тестировании.

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

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

Система Интернет-стандартов характеризуется большим динамизмом, что отражается, в частности, составом стадий стандартизации (stage of standardization), включающим следующие стадии:

· Экспериментальные протоколы (Experimental).

· Предложения (Proposed Standards).

· Проекты (Draft Standards).

· Исторические документы (Historic).

Состояние системы Интернет-стандартов на текущий момент времени фиксируется в списках RFC-документа, называемого Треком стандартов (Standards Track). Этот документ содержит ссылки на спецификации, называемые также официальными стандартами Интернет-протоколов (Internet Official Protocol Standards). Для каждой стадии в Треке стандартов существует собственный список Интернет-протоколов, находящихся на данной стадии процесса стандартизации.

Кроме этого в Треке поддерживается список RFC-документов, разработанных вне IETF-стандартизации. Этот список называется «лучшая современная практика» (the Best Current Practice list).

Помимо серии RFC-документов введены еще две серии. Одна STD-серия — для Интернет-протоколов, находящихся на стадии стандарт. Другая BCP-серия — для документов, относящихся к рубрике «лучшая современная практика». При этом нумерация в этих сериях является независимой от нумерации, принятой для RFC-документов.

Следует отметить, что описание одного стандарта может покрываться несколькими RFC-документами. Так, например, стандарт STD5 для протокола IP охватывает шесть RFC-документов. В этом случае полная ссылка на конкретную спецификацию протокола будет иметь вид STDXX/RFCXXX. На документы можно ссылаться, используя и их серийные номера.

Отметим также, что IETF разрабатывает проекты спецификаций и осуществляет их экспериментальную отработку. Когда спецификации становятся достаточно стабильными и приобретают определенную поддержку, они поступают для рассмотрения в IESG и IAB. В случае одобрения спецификации поступают в подразделение RFC Editor — орган, финансируемый IAB, где приобретают окончательную форму и публикуются от имени IAB (через Internet) в виде RFC-документов.

Стандарты Консорциума W3C:

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

● помочь компьютерным программам достичь способности ко взаимодействию в Сети (т. н. «сетева́я интеропера́бельность», англ. Web interoperability). Применение единых стандартов в Сети — это ключевой шаг для достижения такого взаимодействия.

● обеспечить полную «интернационализа́цию Сети́» и сделать Сеть доступной для людей с ограниченными возможностями.

Процесс стандартизации. Любой стандарт W3C проходит 5 стадий согласования:

· Черновик спецификации (англ. Draft);

· Рабочий проект (англ. Working Draft);

· Последний созыв (англ. Last Call);

· Возможная рекомендация (англ. Candidate Recommendation);

· Предлагаемая рекомендация (англ. Proposed Recommendation);

и только после этого официально становится рекомендацией W3C.

Рекомендации могут время от времени обновляться. К рекомендациям публикуются сообщения о выявившихся ошибках и неточностях (англ. errata). Когда накапливается достаточный запас выявленных ошибок, выходит новая, исправленная и доработанная редакция (англ. edition) рекомендации (например, «редакция 1.1»). В исключительных случаях вся рекомендация может быть отозвана консорциумом для переработки.

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Увлечёшься девушкой-вырастут хвосты, займёшься учебой-вырастут рога 9791 — | 7666 — или читать все.

188.64.174.135 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

Отключите adBlock!
и обновите страницу (F5)

очень нужно

Введение / rfc 2068

404 — год 404 (число) Ошибка 404 Группа 404 … Википедия

404 (значения) — 404: 404 год 404 (число) Ошибка 404 Список значений слова или словосочетания со ссылками на соотв … Википедия

Ошибка 403 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Ошибка 200 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

404 (число) — У этого термина существуют и другие значения, см. 404 (значения). 404 четыреста четыре 401 · 402 · 403 · 404 · 405 · 406 · 407 Факторизация: 101×22 Римская запись: CDIV Двоичное: 110010100 Восьмерич … Википедия

HTTP 404 — HTTP Постоянное соединение · Сжатие · HTTPS Методы OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH Заголовки Cookie · ETag · Location · Referer DNT · X Forwarded For … Википедия

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

Код 200 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Код состояния HTTP — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Коды состояния HTTP — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожие статьи

Установка SSL сертификата на IIS – сервере

Chef — управление сетью. Плюсы и минусы

Свитер и борода — как стать системным администратором?

Про Google Password Checkup

HyperText Transfer Protocol (HTTP)

Работает прямо сейчас

4 минуты чтения

The HyperText Transfer Protocol, или HTTP, это самый распространенный в мире протокол уровня приложений модели OSI на сегодняшний день. Протокол HTTP образует пространство, которое большинство людей называют сетью Интернет. Основной задачей протокола HTTP является извлечение HTML (HyperText Markup Language) или любых других документов с WEB – сайтов через сеть Интернет. Каждый раз, когда вы открываете интернет — браузер, в дело вступает протокол HTTP, оперируя поверх стека протоколов TCP/IP.

Протокол HTTP был впервые выпущен на свет вначале 1990 года и имел три версии:

  • HTTP/0.9: Простейшая реализация протокола, позволяющая только получать WEB – страницы
  • HTTP/1.0: Даная версия обнародована Инженерным советом Интернета (Internet Engineering Task Force, IETF) в рамках RFC 1945 в 1996 году. В данной версии было добавлено большое количество дополнительных полей, именуемых заголовками в этой спецификации. Эта версия протокола расширяла взаимодействие между клиентом и сервером.
  • HTTP/1.1: Версия 1.1 определена в RFC 2068 советом IETF как доработанная и улучшенная версия протокола HTTP поверх спецификации 1.0. Одним из самых заметных улучшений версии 1.1 по сравнению с 1.0 стало внедрений методов постоянных TCP сессий, возможность отправки нескольких HTTP запросов одновременно, не дожидаясь ответа сервера (повышение скорости работы) и реализация алгоритма кэширования.

На сегодняшний день, большинство современных интернет – браузеров поддерживают обе версии 1.0 и 1.1 протокола HTTP. Важно отметить, что современные браузеры обеспечивают полную совместимость данных версий, то есть при условии отправки запрос версии 1.0 и получения ответа 1.1, данные будут успешно обработаны.

Получение веб страницы по HTTP

Рассмотрим процесс получения WEB – страницы обычным интернет браузером с сервера. Любая HTML страница содержит в себе множество объектов, тэгов и изображений. В целом, HTML можно рассматривать как структуру страницы, в которой все объекты расставлены на свои места. В свою очередь, интернет – браузер получает инструкции в рамках этого HTML документа, откуда брать шрифты, цвета, фон и прочие элементы оформления страницы. Порядок таков:

  1. Клиент (браузер) отправляет запрос на WEB – сервер для запрашиваемой страницы.
  2. Сервер анализирует запрос и отправляет HTML код необходимый для формирования страницы.
  3. Клиент начинает анализировать полученный документ и формировать WEB – страницу.
  4. Клиент в последующих запросах будет формировать изображения, видео или любую другую форму внутренних объектов из источников WEB – сервера.

Когда все элементы страницы получены, клиент (интернет браузер) отобразит запрошенную WEB – страницу. Порядок и время работы зависят от версии протокола (1.0 или 1.1).

HTTP запросы

Протокол HTTP (HyperText Transfer Protocol) позволяет не только получать HTML документы с Web – серверов, но и передавать информацию от клиента к серверу. Заголовки запросов в протокол HTTP версий 1.0 и 1.1 указаны в таблице ниже:

Запрос Описание HTTP/1.0 HTTP/1.1
GET Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
HEAD Это запрос почти аналогичен запросу GET. Отличие в том, что сервер не должен возвращать в ответ содержание HTML, а только HTTP заголовок. Да Да
POST Позволяет клиенту отправлять информацию в сторону сервера, например через различные встроенные в сайт формы Да Да
PUT Позволяет клиенту добавить файл в определенную директорию сервера. Нет Да
DELETE Позволяет клиенту удалить файл указанный в рамках запроса. Нет Да
TRACE Позволяет клиенту отслеживать свой запрос к серверу. Нет Да
OPTIONS Позволяет клиенту определять параметры взаимодействия с сервером. Нет Да

В стандартном понимании Web – сайта, запросы GET и POST являются наиболее часто используемыми. Метода GET используется клиентом для получения каждого отдельного объекта страницы, в то время как POST зачастую используется в интернет магазинах, где необходимо отправить информацию в строну сервера.

Что такое URL?

Uniform Resource Locator (URL) одна из самых важных составляющих любого GET запроса, который состоит из хоста, на котором находится сайт, схемы обращения (сетевой протокол) и полного пути к HTML файлу. Опционально, URL может содержать в себе информацию о номере TCP порта и определенной точки на странице. Ниже приведен типичный пример URL:

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

RFC (Request for Comments)

RFC (англ. Request for Comments — Рабочее предложение) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации ISOC (англ. Internet Society, ISOC ). Правами на RFC обладает именно Общество Интернета.

Содержание

История

Формат RFC появился в 1969 году при обсуждении проекта ARPANET. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.

Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса (UCLA).

С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC институту информационных наук Университета Южной Калифорнии.

Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.

Содержимое RFC

Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь — проект). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:

  1. Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
  2. Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
  3. Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
  4. Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
  5. Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)

Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:

  1. Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
  2. Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
  3. Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.

Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).

Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.

Производство и эволюция

Редактор RFC присваивает каждому RFC в серийный номер . После того, как присваивается номер и опубликован RFC, RFC никогда не аннулируется или измененяется; если документ требует внесения поправок, авторы публикуют пересмотренный документ. Таким образом, некоторые RFC вытесняют другие; замененный RFC называются устаревшим или замененным RFC. Вместе пронумерованные RFC составляют непрерывную запись истории эволюции стандартов и практик Интернет. Процесс RFC описан в RFC 2026 (Процесс стандартизации Интернет, пересмотренный вариант 3)

Процесс производства RFC отличается от стандартизации процесса формальных организаций по стандартизации , таких как ISO . Эксперты интернет технологий не могут представить интернет-проект без поддержки со стороны внешнего учреждения. Стандарты RFC публикуются с одобрения IETF, и, как правило, производятся специалистами, участвующими в рабочих группах, которые сначала публикуют интернет-проект. Такой подход облегчает начальный этап рецензирования документов, прежде чем превращается в RFC.

Большинство RFC используют общий набор терминов, таких как «ДОЛЖЕН» и «НЕ РЕКОМЕНДУЕТСЯ» (как определено в RFC 2119 ), дополненной Бэкуса-Наура (ABNF) ( RFC 5234 ) в качестве мета-языка, и простого текстового формата для того, чтобы содержать RFC последовательным и понятным. [1]

Подсерии

Серия RFC содержит три подсерии для IETF RFC:

BCP (Best Current Practice) обязательные IETF RFC не стандартным путем.

FYI (For Your Information) информационные RFC, продвигаемые IETF , как указано в RFC 1150 (FYI 1). В 2011 году RFC 6360 устарел FYI 1 и завершил подсерию.

STD (Standard) Раньше это был третий и самый завершенный из IETF стандартов, указанный в RFC 2026 (BCP 9). В 2011 году RFC 6410 (новая часть BCP 9) снизил стандарты.

RFC 2068

[1]

  1. 1 Introduction. 7
    1. 1.1 Purpose . 7
    2. 1.2 Requirements . 7
    3. 1.3 Terminology . 8
      • 和訳 (部分) : 接続 , メッセージ , 要求 , 応答 , 資源 , 実体 , 表現 , 内容折衝 , 変種 , クライアント , 利用者エージェント , サーバー , 起源サーバー , 串 , 関門 , トンネル , キャッシュ , キャッシュ可能 , 初手 , 明示満期時刻 , 発見的満期時刻 , 齢 , 新鮮寿命 , 新鮮 , 腐敗 , 意味的透過 , 検証子
    4. 1.4 Overall Operation . 11
  2. 2 Notational Conventions and Generic Grammar. 13
    1. 2.1 Augmented BNF . 13
    2. 2.2 Basic Rules . 15
      • 和訳 : HTTP//メッセージ
      • 参考 : token , tspecials , quoted-string , comment , ctext
  3. 3 Protocol Parameters. 17
    1. 3.1 HTTP Version . 17 HTTP-Version
    2. 3.2 Uniform Resource >HTTP//URI
      1. 3.2.1 General Syntax . 18
      2. 3.2.2 http URL . 19
      3. 3.2.3 URI Comparison . 20
    3. 3.3 Date/Time Formats . 21 HTTPの日付形式
      1. 3.3.1 Full Date . 21
      2. 3.3.2 Delta Seconds . 22
    4. 3.4 Character Sets . 22 charset//HTTP
    5. 3.5 Content Codings . 23
      • 和訳 : 内容符号化
    6. 3.6 Transfer Codings . 24
      • 和訳 : 転送符号化
    7. 3.7 Media Types . 25 媒体型//HTTP
      1. 3.7.1 Canonicalization and Text Defaults . 26 text/*//正規化
      2. 3.7.2 Multipart Types . 27 multipart/*//HTTP
    8. 3.8 Product Tokens . 28
    9. 3.9 Quality Values . 28
      • qvalue
    10. 3.10 Language Tags . 28
    11. 3.11 Entity Tags . 29
      • entity-tag
    12. 3.12 Range Units . 30
  4. 4 HTTP Message. 30
    1. 4.1 Message Types . 30
    2. 4.2 Message Headers . 31
    3. 4.3 Message Body . 32
    4. 4.4 Message Length . 32
    5. 4.5 General Header Fields . 34
  5. 5 Request. 34
    1. 5.1 Request-Line . 34
      1. 5.1.1 Method . 35
      2. 5.1.2 Request-URI . 35
    2. 5.2 The Resource >内容折衝
      1. 12.1 Server-driven Negotiation . 68
        • サーバー駆動折衝
      2. 12.2 Agent-driven Negotiation . 69
        • エージェント駆動折衝
      3. 12.3 Transparent Negotiation . 70
        • 透過折衝
    3. 13 Caching in HTTP. 70
      1. 13.1.1 Cache Correctness . 72
        1. 13.1.2 Warnings . 73
        2. 13.1.3 Cache-control Mechanisms . 74
        3. 13.1.4 Explicit User Agent Warnings . 74
        4. 13.1.5 Exceptions to the Rules and Warnings . 75
        5. 13.1.6 Client-controlled Behavior . 75
      2. 13.2 Expiration Model . 75
        1. 13.2.1 Server-Specified Expiration . 75
        2. 13.2.2 Heuristic Expiration . 76
        3. 13.2.3 Age Calculations . 77
        4. 13.2.4 Expiration Calculations . 79
        5. 13.2.5 Disambiguating Expiration Values . 80
        6. 13.2.6 Disambiguating Multiple Responses . 80
      3. 13.3 Val >内容折衝//キャッシュ
      4. 13.7 Shared and Non-Shared Caches . 91
      5. 13.8 Errors or Incomplete Response Cache Behavior . 91
      6. 13.9 S >Content-Type//仕様書から
      7. 14.19 Date . 116
      8. 14.20 ETag . 117
      9. 14.21 Expires . 117
      10. 14.22 From . 118
      11. 14.23 Host . 119
      12. 14.24 If-Modified-Since . 119
      13. 14.25 If-Match . 121
      14. 14.26 If-None-Match . 122
      15. 14.27 If-Range . 123
      16. 14.28 If-Unmodified-Since . 124
      17. 14.29 Last-Modified . 124
      18. 14.30 Location . 125
      19. 14.31 Max-Forwards . 125
      20. 14.32 Pragma . 126
      21. 14.33 Proxy-Authenticate . 127
      22. 14.34 Proxy-Authorization . 127
      23. 14.35 Public . 127
      24. 14.36 Range . 128
        1. 14.36.1 Byte Ranges . 128
        2. 14.36.2 Range Retrieval Requests . 130
      25. 14.37 Referer . 131
      26. 14.38 Retry-After . 131
      27. 14.39 Server . 132
      28. 14.40 Transfer-Encoding . 132
      29. 14.41 Upgrade . 132
      30. 14.42 User-Agent . 134
      31. 14.43 Vary . 134
      32. 14.44 Via . 135
      33. 14.45 Warning . 137
      34. 14.46 WWW-Authenticate . 139
    4. 15 Security Cons >Accept-Language
    5. 15.8 DNS Spoofing . 144
    6. 15.9 Location Headers and Spoofing . 144
  6. 16 Acknowledgments. 144
  7. 17 References. 146
  8. 18 Authors’ Addresses. 149
  9. 19 Appendices. 150
    1. 19.1 Internet Media Type message/http . 150
    2. 19.2 Internet Media Type multipart/byteranges . 150
    3. 19.3 Tolerant Applications . 151
      • 2桁西暦年号の解釈 (抜粋)
    4. 19.4 Differences Between HTTP Entities and MIME Entities. 152
      1. 19.4.1 Conversion to Canonical Form . 152
      2. 19.4.2 Conversion of Date Formats . 153
      3. 19.4.3 Introduction of Content-Encoding . 153
      4. 19.4.4 No Content-Transfer-Encoding . 153
      5. 19.4.5 HTTP Header Fields in Multipart Body-Parts . 153
      6. 19.4.6 Introduction of Transfer-Encoding . 154
      7. 19.4.7 MIME-Version . 154
    5. 19.5 Changes from HTTP/1.0 . 154
      1. 19.5.1 Changes to Simplify Multi-homed Web Servers and
      2. Conserve IP Addresses . 155
    6. 19.6 Additional Features . 156
      1. 19.6.1 Additional Request Methods . 156
      2. 19.6.2 Additional Header Field Definitions . 156
        • Content-Version , Link , URI:
    7. 19.7 Compatibility with Previous Versions . 160
      1. 19.7.1 Compatibility with HTTP/1.0 Persistent
      2. Connections. 161

© Authors. See license terms (CC BY-SA / GFDL). There might also be additional terms applied for this page.

Протокол HTTP

Протокол HTTP используется в World Wide Web (WWW) начиная с 1990 года. Его версия описана 1.0 в RFC 1945, версия 1.1 в RFC 2068/

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из строки запроса (ответа), сопровождаемой вспомогательными строками заголовка и тела. Строки заголовка отделяются друг от друга парой символов . Тело отделяется от заголовков пустой строкой. Заголовки могут быть любой длины, и сервер обязан либо обработать длинный заголовок, либо выдать соответствующий код ошибки. Тело запроса (ответа) представляет последовательность байтов, на которую не накладывается никаких ограничений.

Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80)., и, не дожидаясь никакой реакции от сервера, посылает запрос, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например:

В примере используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html с виртуального сервера www.example.com.

Послав запрос и заголовки, клиент может отправить дополнительные данные. Эти данные используются главным с методом POST для передачи .

Сервер отвечает на запрос клиента следующим образом:

Первая часть строка ответа сервера — строка состояния, содержащая три поля: версию HTTP, числовой код ответа и текстовое описание этого кода.

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

HTTP не сохраняет информацию по транзакциям, каждая пара запрос-ответ проводится независимо, даже в рамках одного TCP соединения.

Методы

Метод — это HTTP-команда, с которой начинается первая строка запроса клиента.Реально используются GET, HEAD и POST. При задании имен методов учитывается регистр, поэтому GET и get различаются.

Приведенные ниже методы определены, но практически не используются:

Метод GET

GET — это запрос к серверу, который ничего не изменяет на сервере, например, выполняет считывание записи из БД.

В URL кодируются параметры запроса. Сначала идут позиционные параметры, разделенные знаком ‘/’, а затем, после символа ‘&’ — именованные в виде пар ключ-значение. Пары отделяются друг от друга амперсандом ‘&’. Например:

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

Хотя позиционные параметры могут выглядеть, как имена каталогов и файлов, реальная интерпретация зависит от реализации на стороне сервера. Например, следующая запись может означать запуск скрипта /cgi-bin/display.pl для вывода файла /text/doc.txt (а может и не означать):

Метод POST

Метод POST это запрос к серверу, который изменяет состояние сервера, например вносит запись в БД.

Параметры запроса в методе POST могут передаваться в теле запроса. В этом случае их общая длина ничем не ограничена.

Метод HEAD

Метод HEAD аналогичен методу GET, за исключением того, что сервер ничего не посылает в информационной части ответа. Метод HEAD запрашивает только информацию заголовка о файле или ресурсе. Этот метод используется, когда клиент хочет получить информацию о документе, не получая его. Например, клиента может интересовать:

  • время изменения документа;
  • размер документа;
  • тип документа;
  • тип сервера.

Некоторые заголовки не являются обязательными и могут отсутствовать в ответе сервера.

Авторизация

Если ресурс требует авторизации пользователя, то сервер в ответ на запрос может вернуть код ответа 401 Unauthorized и строку заголовка с указанием области доступа для которой требуется авторизация

Чтобы получить права доступа, клиент посылает в последующих запросах идентификатор пользователя и пароль, разделенные символом двоеточия «:». Строка авторизации кодируется в base64.

В реальной жизни используется тип авторизации Basic и NTLM.

Заголовки запроса

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

Во втором случае передается только путь к документу.

В этом случае имя и порт хоста, может быть передано в строке заголовка Host:

Наличие имени хоста необходимо для обращений к прокси-серверу, или для обращения к одному из виртуальных хостов размещенных на одном сервере. Если хост, заданный одним из двух способов, не существует, то сервер возвращает ответ 400- Bad Request.

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

Передача данных в ответе сервера

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

Content-Type: Тип сообщения, аналогичен типу содержимого в стандарте MIME и указывается в формате тип/подтип.

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

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

Content-Encoding: Для 8 битового протокола HTTP, данный заголовок означает, что данные дополнительно закодированы, например сжаты. Определены три типа кодирования gzip, compress, deflate, что соответствует форматам программ gzip, compress и библиотеки zlib. Например:

Большое значение в реализации протокола HTTP имеет уведомление клиента о размере данных в теле ответа, т.к. в силу 8 битовости протокола тело ответа не может сопровождаться каким либо ограничителем.

Content-Length: Длина тела сообщения. В протоколе HTTP/1.0 это была единственная возможность передать клиенту информацию о размере данных.

Кодирование данных кусками (chunced) было введено в HTTP/1.1. В заголовках ответа должна присутствовать строка

А тело сообщения строится по следующим правилам

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

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

Еще одной возможностью для кодирования данных является использование для тела сообщения типа multipart/bytranges – эквивалентного MIME multipart/*

Если размер сообщения не указан, не используется кодирование кусками и тип тела сообщения не multipart/bytranges, то клиент определяет конец тела ответа по закрытию TCP соединения.

RFC 2068 дополненная БНФ

Я пытаюсь разобрать заголовки запроса авторизации, см. Https://www.ietf.org/rfc/rfc2617.txt раздел 3.2.2. Там дайджест-ответ определяется следующим образом:

Используемый здесь расширенный BNF определен в http://www.ietf.org/rfc/rfc2068.txt , раздел 2.1.

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

У меня есть несколько вопросов относительно определения дайджест-ответа:

1) Является ли следующий дайджест-ответ действительным (если нет, то почему)? username_1, username_2

2) Допустим ли следующий дайджест-ответ (если нет, то почему)? имя пользователя, область, nonce, дайджест-URI

3) Является ли следующий дайджест-ответ действительным (если нет, то почему)? username_1, realm, nonce, digest-uri, ответ, username_2

4) Как выглядят возможные произведения для 1 # (a | b) и 1 # (a | [b]), и в чем разница?

Введение / rfc 2068

404 — год 404 (число) Ошибка 404 Группа 404 … Википедия

404 (значения) — 404: 404 год 404 (число) Ошибка 404 Список значений слова или словосочетания со ссылками на соотв … Википедия

Ошибка 403 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Ошибка 200 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

404 (число) — У этого термина существуют и другие значения, см. 404 (значения). 404 четыреста четыре 401 · 402 · 403 · 404 · 405 · 406 · 407 Факторизация: 101×22 Римская запись: CDIV Двоичное: 110010100 Восьмерич … Википедия

HTTP 404 — HTTP Постоянное соединение · Сжатие · HTTPS Методы OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH Заголовки Cookie · ETag · Location · Referer DNT · X Forwarded For … Википедия

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

Код 200 — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Код состояния HTTP — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Коды состояния HTTP — SSL Заголовки (список) Cookie · ETag · Referer · User Agent Коды состояния Код состояния англ. HTTP status code) является частью первой строки ответа сервера. Он представляет собой целое число из трех арабских цифр. Первая цифра указывает на… … Википедия

Веб-сервер на C++ и сокетах

Создадим HTTP-сервер, который обрабатывает запросы браузера и возвращает ответ в виде HTML-страницы.

Введение в HTTP

Для начала разберемся, что из себя представляет HTTP. Это текстовый протокол для обмена данными между браузером и веб-сервером.

Пример HTTP-запроса:

Первая строка передает метод запроса, идентификатор ресурса (URI) и версию HTTP-протокола. Затем перечисляются заголовки запроса, в которых браузер передает имя хоста, поддерживаемые кодировки, cookie и другие служебные параметры. После каждого заголовка ставится символ переноса строки \r\n .

У некоторых запросов есть тело. Когда отправляется форма методом POST, в теле запроса передаются значения полей этой формы.

Тело запроса отделяется от заголовков одной пустой строкой. Заголовок «Content-Type» говорит серверу, в каком формате закодировано тело запроса. По умолчанию, в HTML-форме данные кодируются методом «application/x-www-form-urlencoded».

Иногда необходимо передать данные в другом формате. Например, при загрузке файлов на сервер, бинарные данные кодируются методом «multipart/form-data».

Сервер обрабатывает запрос клиента и возвращает ответ.

Пример ответа сервера:

В первой строке ответа передается версия протокола и статус ответа. Для успешных запросов обычно используется статус «200 OK». Если ресурс не найден на сервере, возвращается «404 Not Found».

Тело ответа так же, как и у запроса, отделяется от заголовков одной пустой строкой.

Полная спецификации протокола HTTP описывается в стандарте rfc-2068. По понятным причинам, мы не будем реализовывать все возможности протокола в рамках этого материала. Достаточно реализовать поддержку работы с заголовками запроса и ответа, получение метода запроса, версии протокола и URL-адреса.

Что будет делать сервер?

Сервер будет принимать запросы клиентов, парсить заголовки и тело запроса, и возвращать тестовую HTML-страничку, на которой отображены данные запроса клиента (запрошенный URL, метод запроса, cookie и другие заголовки).

О сокетах

Для работы с сетью на низком уровне традиционно используют сокеты. Сокет — это абстракция, которая позволяет работать с сетевыми ресурсами, как с файлами. Мы можем писать и читать данные из сокета почти так же, как из обычного файла.

В этом материале мы будем работать с виндовой реализацией сокетов, которая находится в заголовочном файле . В Unix-подобных ОС принцип работы с сокетами такой же, только отличается API. Вы можете подробнее почитать о сокетах Беркли, которые используются в GNU/Linux.

Создание сокета

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

Мы подготовили все данные, которые необходимо для создания сокета и создали сам сокет. Функция socket возвращает целочисленное значение файлового дескриптора, который выделен операционной системой под сокет.

Привязка сокета к адресу (bind)

Следующим шагом, нам необходимо привязать IP-адрес к сокету, чтобы он мог принимать входящие соединения. Для привязки конкретного адреса к сокету используется фукнция bind . Она принимает целочисленный идентификатор файлового дескриптора сокета, адрес (поле ai_addr из структуры addrinfo ) и размер адреса в байтах (используется для поддержки IPv6).

Подготовка сокета к принятию входящих соединений (listen)

Подготовим сокет к принятию входящих соединений от клиентов. Это делается с помощью функции listen . Она принимает дескриптор слушающего сокета и максимальное количество одновременных соединений.

В случае ошибки, функция listen возращает значение константы SOCKET_ERROR . При успешном выполнении она вернет 0.

В константе SOMAXCONN хранится максимально возможное число одновременных TCP-соединений. Это ограничение работает на уровне ядра ОС.

Ожидание входящего соединения (accept)

Функция accept ожидает запрос на установку TCP-соединения от удаленного хоста. В качестве аргумента ей передается дескриптор слушающего сокета.

При успешной установке TCP-соединения, для него создается новый сокет. Функция accept возвращает дескриптор этого сокета. Если произошла ошибка соединения, то возвращается значение INVALID_SOCKET .

Получение запроса и отправка ответа

После установки соединение с сервером, браузер отправляет HTTP-запрос. Мы получаем содержимое запроса через функцию recv . Она принимает дескриптор TCP-соединения (в нашем случае это client_socket ), указатель на буфер для сохранения полученных данных, размер буфера в байтах и дополнительные флаги (которые сейчас нас не интересуют).

При успешном выполнении функция recv вернет размер полученных данных. В случае ошибки возвращается значение SOCKET_ERROR . Если соединение было закрыто клиентом, то возвращается 0.

Мы создадим буфер размером 1024 байта для сохранения HTTP-запроса.

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

В случае ошибки, функция возвращает значение SOCKET_ERROR . В случае успеха — количество переданных байт.

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

Если скомпилировать и запустить программу, то окно консоли «подвиснет» в ожидании запроса на установление TCP-соединения. Откройте в браузере адрес http://127.0.0.1:8000/. Сервер вернет ответ, как на рисунке ниже и завершит работу.

Последовательная обработка запросов

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

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

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

Примечание: если вы используете MinGW в Windows, то библиотеку Ws2_32.lib нужно вручную прописать в настройках линковщика.

Введение / rfc 2068

Протокол управления пересылкой
(Transmission Control Protocol)
Проект DARPA Internet
Спецификация протокола

подготовлено для
Агенства оборонных проектов расширенных исследований
Офис технологий обработки информации
1400 Wilson Boulevard
Arlington, Virginia 22209

Институтом Информатики
Университетом Южной Калифорнии
4676 Admiralty Way
Marina del Rey, California 90291

(перевод Радика Усманова ноябрь 1994)

Содержание
Предисловие
1. Введение
1.1 Мотивация
1.2 Цель
1.3 О данном документе
1.4 Интерфейсы
1.5 Действие
2. Идеология протокола
2.1 Элементы системы объединенных сетей
2.2 Модель действия
2.3 Программное обеспечение хост-компьютера
2.4 Интерфейсы
2.5 Связь с другими протоколами
2.6 Надежные коммуникации
2.7 Установка соединения и его отмена
2.8 Коммутация данных
2.9 Приоритет и безопасность
2.10 Принцип устойчивости
3. Спецификация для функций протокола
3.1 Формат заголовка
3.2 Терминология
3.3 Номера последовательности
3.4 Установка соединения
3.5 Закрытие соединения
3.6 Приоритет и безопасность
3.7 Коммутация данных
3.8 Интерфейсы
3.9 Обработка событий
Словарь
Ссылки

Предисловие
Данный документ описывает Протокол управления пересылкой в DoD стандарте (TCP). Данный стандарт основывается на девяти предыдущих изданиях ARPA спецификации TCP, данный текст сильно отличается от них. В него внесены большие изменения как в отношении концепций, так и в отношении текста. Данное издание проясняет некоторые детали протокола и не включает выравнивания по размеру буфера в конце письма, а также переопределяет механизм писем как push функцию.
Джон Полтел (Jon Postel)
Редактор
RFC: 793
заменяет RFC 761 и IENs: 129, 124, 112, 81, 55, 44, 40, 27, 21, 5

Протокол управления передачей
Протокол DARPA Internet
Спецификация протокола

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

1.1 Мотивация
Компьютерные коммуникационные системы играют все более важную роль в военных, правительственных и гражданских приложениях. Этот документ в первую очередь освещает требования к компьютерным коммуникациям в военной области, и особенно к устойчивости в условиях недостаточной надежности коммуникаций и возможности перегрузок. Тем не менее, многие из этих проблем имеют место также в гражданском и правительственном
секторе. В условиях, когда стратегические и тактические сети компьютерных коммуникаций возникают и исчезают, важно обеспечить средства для их соединения, а также стандартные протоколы коммуникации между процессами, которые бы поддерживали большой диапазон прикладных программ. Предвидя потребность в таких стандартах, Представительство Секретариата Обороны по научно-исследовательским и опытно-конструкторским работам предъявило протокол управления передачей (Transmission Control Protocol — TCP), описанный здесь, на основе стандартизации DoD протокола коммуникаций между процессами.
TCP — это протокол обеспечения надежности прямых соединений, созданный для многоуровневой иерархии протоколов, поддерживающих межсетевые приложения. Протокол TCP обеспечивает надежность коммуникаций между парами процессов на хост-компьютерах, включенных в различные компьютерные коммуникационные сети, которые объединены в единую систему.
В отношении надежности протоколов более низкого, чем TCP, уровня сделаны весьма скромные запросы. TCP предполагает, что он может получить простой, потенциально ненадежный сервис для своих датаграмм со стороны протоколов нижнего уровня. В принципе, протокол TCP должен быть работоспособен на большом наборе коммуникационных систем, начиная с кабельных соединений и кончая сетями с переключением пакетов или электрических цепей.
Протокол TCP основывается на концепциях, впервые описанных авторами Cerf и Kahn в документе [1]. TCP занимает в многоуровневой архитектуре протоколов нишу непосредственно над протоколом Internet, который позволяет протоколу TCP отправлять и получать сегменты информации переменной длины, заключенные в оболочку Internet датаграмм. Internet датаграмма предоставляет средства для адресации отправителя и получателя сегментов TCP в различных сетях. Протокол Internet также осуществляет любую фрагментацию и сборку сегментов TCP, необходимую для осуществления передачи и доставки через множество сетей и промежуточных шлюзов. Протокол Internet также обработывает информацию о приоритете, классификации безопасности, а также осуществляет разграничение TCP сегментов. Так что данная информация может быть передана напрямую через множество сетей.

Рис. 1
Большая часть этого документа написана всвязи с реализациями TCP протокола, которые вместе с протоколами более высокого уровня присутствуют на хост-компьютере. Некоторые компьютерные системы будут включаться в сети через главные компьютеры, содержащие протоколы уровней TCP и Internet, а также специфическое сетевое программое обеспечение. Спецификация TCP описывает ее интерфейс с протоколами более высокого уровня, которые оказались осуществимы даже в случае главного компьютера, если реализован соответствующий протокол общения между хосткомпьютером и главным компьютером.

1.2 Цель
Протокол TCP обязан обеспечить надежный сервис для коммуникаций между процессами в многосетевой системе. Протокол TCP должен быть общим протоколом для коммуникаций между хост-компьютерами во множестве сетей.

1.3 О данном документе
Данный документ предоставляет описание поведения, ожидаемого от любой реализации протокола TCP, а также его взаимодействия как с протоколами более высокого уровня, так и с протоколами TCP на других компьютерах. Оставшаяся часть данной главы дает очень краткий обзор действия протокола и его интерфейсов. Глава 2 суммирует идейный базис для создания протокола TCP. Глава 3 дает как детальное описание поведения, требуемого от протокола TCP при появлении различных событий (прибытие новых сегментов, запрос от пользователя, ошибки и т.д.), так и описание деталей форматов TCP сегментов.

1.4 Интерфейсы
Протокол TCP взаимодействует с одной стороны с пользователем или прикладной программой, а с другой — с протоколом более низкого уровня, таким как протокол Internet. Интерфейс между прикладным процессом и протоколом TCP мы поясняем с приемлемой детализацией. Этот интерфейс состоит из набора вызовов, которые похожи на вызовы операционной системы, предоставляемые прикладному процессу для управления файлами. Например, в этом случае имеются вызовы для открытия и закрытия соединений, для отправки и получения данных на установленных соединениях. Предполагается также, что протокол TCP сможет асинхронно взаимодействовать с прикладными программами. Хотя разработчикам TCP протокола и предоставлена значительная свобода в создании интерфейсов, которые соответствуют свойствам конкретной операционной системы, все же от любой приемлемой реализации требуются некие обязательные минимальные функции интерфейса между протоколом TCP и пользователем.
Интерфейс между протоколом TCP и протоколами более низкого уровня задан в значительно меньшей степени, за исключением того, что должен существовать некий механизм, с помощью которого эти два уровня могут асинхронно обмениваться информацией друг с другом. Обычно полагают, что протокол нижнего уровня задает данный интерфейс. Протокол TCP спроектирован так, чтобы работать с весьма разнообразной средой объединенных компьютерных сетей. В данном документе предполагается, что протокол более низкого уровня — это Internet [2].

1.5 Действие
Как указывалось ранее, главной целью протокола TCP является обеспечение надежного, безопасного сервиса для логических цепей или соединений между парами процессов. Чтобы обеспечить такой сервис, основываясь на менее надежных коммуникациях Internet, система должна иметь возможности для работы в следующих областях:

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

    Базовая передача данных
    Протокол TCP способен передавать непрерывные потоки октетов
    между своими клиентами в обоих направлениях, пакуя некое количес-
    тво октетов в сегменты для передачи через системы Internet. В об-
    щем случае протоколы TCP решают по своему усмотрению, когда произ-
    водить блокировку и передачу данных.
    Иногда пользователям бывает необходимо убедиться в том, что все
    данные, переданные ими протоколу TCP, уже отправлены. Для этой це-
    ли определена функция проталкивания (push). Чтобы убедиться в том,
    что данные, отправленные протоколу TCP, действительно переданы,
    отправитель указывает, что их следует протолкнуть к получателю.
    Проталкивание приводит к тому, что программы протокола TCP сразу
    осуществляют отправление и, соответственно, получение остающихся
    данных. Правильно осуществленное проталкивание может быть невидимо
    для получателя, а сама функция проталкивания может не иметь
    маркера границы записи.
    Достоверность
    Протокол TCP должен иметь защиту от разрушения данных, потери,
    дублирования и нарушения очередности получения, вызываемых
    коммуникационной системой Internet. Это достигается присвоением
    очередного номера каждому передаваемому октету, а также
    требованием подтверждения (ACK) от программы TCP, принимающей
    данные. Если подтверждения не получено в течении контрольного
    интервала времени, то данные посылаются повторно. Со стороны
    получателя номера очереди используются для восстановления
    очередности сегментов, которые могут быть получены в неправильном
    порядке, а также для ограничения возможности появления дубликатов.
    Повреждения фиксируются посредством добавления к каждому
    передаваемому сегменту контрольной суммы, проверки ее при
    получении и последующей ликвидации дефектных сегментов.
    До тех пор, пока программы протокола TCP продолжают функциони-
    ровать корректно, а система Internet не развалилась полностью на
    составные части, ошибки пересылки не будут влиять на правильное
    получение данных. Протокол TCP защищает от ошибок коммуникационной
    системы Internet.
    Управление потоком
    Протокол TCP дает средства получателю управлять количеством
    данных, посылаемых ему отправителем. Это достигается возвратом так
    называемого «окна» (window) вместе с каждым подтверждением, кото-
    рое указывает диапазон приемлемых номеров, следующих за номером
    последнего успешно принятого сегмента. Окно определяет количество
    октетов, которое отправитель может послать до получения дальнейших
    указаний.
    Разделение каналов
    Чтобы позволить на отдельно взятом компьютере многим процессам
    одновременно использовать коммуникационные возможности уровня TCP,
    протокол TCP предоставляет на каждом хост-компьютере набор адресов
    или портов. Вместе с адресами сетей и хост-компьютеров на коммни-
    кационном уровне Internet они образуют сокет (socket — разъем).
    Каждое соединение уникальным образом идентифицируется парой соке-
    тов. Таким образом, любой сокет может одновременно использоваться
    во многих соединениях.
    Соотнесение портов и процесов осуществляется каждым хост-
    компьютером самостоятельно. Однако оказывается полезным связывать
    часто используемые процессы (такие как «logger» или сервис с раз-
    делением времени) с фиксированными документированными сокетами.
    Этот сервис можно впоследствии использовать через известные адре-
    са. Установка и настройка адресов портов для других процессов мо-
    жет включать более динамичные механизмы.
    Работа с соединениями
    Механизмы управления потоком и обеспечения достоверности, опи-
    санные выше, требуют, чтобы программы протокола TCP инициализиро-
    вали и поддерживали определенную информацию о состоянии каждого
    потока данных. Набор такой информации, включающий сокеты, номера
    очереди, размеры окон, называется соединением. Каждое соединение
    уникальным образом идентифицируется парой сокетов на двух концах.
    Если два процесса желают обмениваться информацией, соответству-
    ющие программы протокола TCP должны сперва установить соединение
    (на каждой стороне инициализировать информаицию о статусе). По за-
    вершении обмена информацией соединение должно быть расторгнуто или
    закрыто, чтобы освободить ресурсы для предоставления другим поль-
    зователям.
    Поскольку соединения должны устанавливаться между ненадежными
    хост-компьютерами и через ненадежную коммуникационную систему
    Internet, то во избежание ошибочной инициализации соединений ис-
    пользуется механизм подтверждения связи с хронометрированными но-
    мерами очереди.
    Приоритет и безопасность
    Пользователи протокола TCP могут затребовать для своего соеди-
    нения приоритет и безопасность. Предусмотрены принимаемые по умол-
    чанию характеристики соединений, когда такие параметры не требуют-
    ся.

    2. Идеология протокола

    2.1 Элементы системы обединенных сетей
    Среда объединенных сетей состоит из хост-компьютеров, включенных в
    сети, которые в свою очередь соединятся друг с другом через шлюзы.
    Здесь предполагается, что компьютерные сети могут быть либо локальны-
    ми (например, ETHERNET), либо большими сетями (например ARPANET), но
    в любом случае они основываются на технологии коммутации пакетов. Ре-
    альными агентами, создающими и потребляющими сообщения, циркулирующие
    в сети, являются процессы. Протоколы различных уровней в сетях, на
    шлюзах и на хост-компьютерах поддерживают систему коммуникаций между
    процессами, которая обеспечивает двунаправленный поток данных по ло-
    гическим соединениям между портами процессов.
    Термин пакет используется здесь в общем случае для обозначения
    порции данных, участвующей в отдельном элементарном акте взаимодей-
    ствия между сетью и соединенным с ней хост-компьютером. В общем слу-
    чае нас не будет касаться формат блоков данных, циркулирующих в сети.
    С точки зрения коммуникационных сетей, хост-компьютеры — это ком-
    пьютеры, связанные с сетью и являющиеся отправителями и получателями
    пакетов. Процессы рассматриваются как активные элементы на хост-
    компьютерах (согласно наболее общему определению процессов как испол-
    няющихся программ). Предполагается, что даже терминалы, файлы и дру-
    гие устройства ввода-вывода взаимодействуют друг с другом посредством
    процессов. Таким образом, любые коммуникации рассматриваются как ком-
    муникации между процессами.
    Поскольку процесс может контролировать несколько коммуникационных
    потоков, ведущих от него к другому процессу (или другим процессам),
    то мы постулируем, что каждый процесс может иметь набор портов, через
    которые он общается с портами других процессов.

    2.2 Модель действия
    Процесс пересылает данные, вызывая программу протокола TCP и пере-
    давая ей в качестве аргументов буферы с данными. Протокол TCP пакует
    данные из этих буферов в сегменты, а затем вызывает модуль Internet
    для передачи каждого сегмента на программу протокола TCP, являющуюся
    адресатом. Этот адресат в свою очередь помещает данные из сегмента в
    буферы получателя и затем оповещает свего клиента о прибытии предназ-
    наченных ему данных. Программы протокола TCP помещают в сегменты кон-
    трольную информацию, которая затем используется ими для проверки оче-
    редности передачи данных.
    Модель Internet коммуникаций состоит в том, что с каждой програм-
    мой протокола TCP связан модуль протокола Internet, обеспечивающий ей
    интерфейс с локальной сетью. Данный модуль Internet помещает сегменты
    TCP в Internet датаграммы, а затем направляет их на другой Internet
    модуль или же промежуточный шлюз. Для передачи датаграммы по локаль-
    ной сети она в свою очередь помещается в пакет соответствующего типа.
    Коммутаторы пакетов могут осуществлять дальнейшую упаковку, фраг-
    ментацию или другие операции с тем, чтобы в локальной сети осущест-
    вить передачу пакетов по назначению на модуль Internet.
    На шлюзах между локальными сетями датаграмма Internet освобождает-
    ся от пакета локальной сети и исследуется с тем, чтобы определить, по
    какой сети она должна в дальнейшем идти. Затем Internet датаграмма
    упаковывается в пакет, соответствующий выбранной локальной сети, и
    посылается на следующий шлюз или же прямо к конечному получателю.
    Шлюз имеет возможность разбивать Internet датаграмму на более мел-
    кие датаграммы-фрагменты, если это необходимо для передачи по очеред-
    ной локальной сети. Чтобы осуществить это, шлюз сам создает набор
    Internet датаграмм, помещая в каждую по одному фрагменты. В дальней-
    шем фрагменты могут быть снова разбиты следующими шлюзами на еще бо-
    лее мелкие части. Формат фрагмента Internet датаграммы спроектирован
    так, чтобы адресат — модуль Internet смог собрать фрагменты снова в
    исходные Internet датаграммы.
    Internet модуль, являющийся адресатом, выделяет сегмент из дата-
    граммы (после ее сборки в случае необходимости) и затем передает его
    по назначению на программу протокола TCP.
    Данная простая модель действия протокола зачастую замалчивает мно-
    жество деталей. Одной из важных характеристик является тип сервиса.
    Этот признак дает указание шлюзу (или модулю Internet) о выборе пара-
    метров сервиса, которые должны использоваться при передаче датаграммы
    в очередной локальной сети. Приоритет датаграммы указывается среди
    информации о типе сервиса. Датаграммы также могут нести информацию о
    безопасности с тем, чтобы позволить хост-компьютерам и шлюзам, дей-
    ствующим в многоуровневой системе безопасности, подвергать проверке
    соотвествующие датаграммы.

    2.3 Программное обеспечение хост-компьютера
    Предполагается, что программа протокола TCP является модулем опе-
    рационной системы. Клиенты обращаются к протоколу TCP в значительной
    степени так же, как если бы они обращались к файловой системе. Сам
    протокол TCP может обращаться к другим функциям операционной системы,
    к примеру, для управления структурами данных. Предполагается, что
    собственно интерфейс с локальной сетью осуществляется драйвером
    устройства. Протокол TCP не обращается непосредственно к драйверам
    сетевых устройств, а вместо этого делает вызов для модуля Internet
    протокола, который в свою очередь и обращается к драйверу устройства.
    Механизм протокола TCP не исключает его реализации на входном про-
    цессоре. Однако, при такой реализации протокол общения между входными
    процессорами должен обеспечивать средства для поддержки описанного в
    этом документе интерфейса между пользователем и протоколом TCP.

    2.4 Интерфейсы
    Для запросов со стороны пользователя к протоколу TCP интерфейс
    TCP/пользователь обеспечивает открытие и закрытие соединения, посылку
    и получение данных или же получение статуса соединения. Эти запросы
    похожи на другие запросы программы пользователя к операционной систе-
    ме, например, на запросы открытия, чтения и закрытия файла.
    Интерфейс между протоколами TCP и Internet поддерживает запросы на
    посылку и получение датаграмм, адресованных на модули TCP в хост-
    компьютерах в любом месте сети Internet. Рассматриваемые запросы име-
    ют аргументы для указания адреса, типа сервиса, приоритета, безопас-
    ности, а также передачи другой правляющей информации.

    2.5 Связь с другими протоколами
    Нижеприведенная диаграмма иллюстрирует место протокола TCP в
    иерархии протоколов

    Рис.2 Взаимосвязь протоколов
    Предполагается, что протокол TCP будет в состоянии эффективно поддер-
    живать протоколы более высокого уровня. Протокол TCP должен легко
    взаимодействовать с такими протоколами более высокого уровня, как
    ARPANET Telnet или AUDIN II THP to the TCP.

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

    2.7 Установка соединения и его отмена
    Чтобы идентифицировать отдельные потоки данных, поддерживаемые
    протоколом TCP, последний определяет идентификаторы портов. Поскольку
    идентификаторы портов выбираются каждой программой протокола TCP не-
    зависимо, то они не будут уникальны. Чтобы обеспечить уникальность
    адресов для каждой программы протокола TCP, мы объединяем идентифици-
    рующий эту программу Internet адрес и идентификатор порта. В резуль-
    тате получаем сокет, который будет уникален во всех локальных сетях,
    объединенных в единое целое.
    Соединение полностью определяется парой сокетов на своих концах.
    Локальный сокет может принимать участие во многих соединениях с раз-
    личными чужими сокетами. Соединение можно использовать для передачи
    данных в обоих направлениях, иными словами, оно является «полностью
    дуплексным».
    Протокол TCP волен произвольным образом связывать порты с процес-
    сами. Однако при любой реализации протокола необходимо придерживаться
    нескольких основополагающих концепций. Должны присутствовать общеиз-
    вестные сокеты, которые протокол TCP ассоциирует исключительно с
    «соответствующими им» процессами. Мы представляем себе, как будто
    процессы могут «владеть»портами и что процессы могут инициировать со-
    единения только с тех портов, которыми они владеют. (С точки зрения
    реализации протокола «владение» ограничивается хост-компьютером, од-
    нако мы можем представить себе команду пользователя по запросу порта
    (Request Port) или же метод выделения группы уникальных портов данно-
    му процессу, например посредством ассоциирования старших байтов в
    имени порта с данным процессом).
    Соединение задается командой OPEN (открыть), сделанной с локально-
    го порта и имеющей аргументом чужой сокет. В ответ на такой запрос
    программа протокола TCP предоставляет имя локального (короткого) со-
    единения. По этому имени пользователь адресуется к данному соединению
    при последующих вызовах. О соединениях следует помнить кое-какие вещи.
    Мы предполагаем, что имеется некая структура данных, называемая бло-
    ком управления передачей (Transmission Control Block -TCB), предназ-
    наченная для сохранения описанной выше информации. Можно было бы ре-
    ализовать протокол таким образом, чтобы локальное имя для соединения
    было бы указателем на структуру TCB последнего. Запрос OPEN указывает
    также, осуществляется ли соединение активным образом, или же происхо-
    дит пассивное ожидание соединения извне.
    Запрос на пассивное открытие соединения означает, что процесс ждет
    получения извне запросов на соединение, вместо того, чтобы пытаться
    самому установить его. Часто процесс, сделавший запрос на пассивное
    открытие, будет принимать запросы на соединение от любого другого
    процесса. В этом случае чужой сокет указывается как состоящий целиком
    из нулей, что означает неопределенность. Неопределенные чужие сокеты
    могут присутствовать лишь в командах пассивного открытия.
    Сервисный процесс, желающий обслужить другие, неизвестные ему про-
    цессы, мог бы осуществить запрос на пассивное открытие с указанием
    неопределенного сокета. В этом случае соединение может быть установ-
    лено с любым процессом, запросившим соединения с этим локальным соке-
    том. Такая процедура будет полезна, если известно, что выбранный ло-
    кальный сокет ассоциирован с определенным сервисом.
    Общеизвестные сокеты представляют собой удобный механизм априорно-
    го привязывания адреса сокета с каким-либо стандартным сервисом. На-
    пример, процесс «сервер для программы Telnet» жестко связан с кон-
    кретным сокетом. Другие сокеты могут быть зарезервированы за передат-
    чиком файлов, Remote Job Entry, текстовым генератором, эхо-сервером,
    а также Sink-процессами (последние три пункта связаны с обработкой
    текстов). Адрес сокета может быть зарезервирован для доступа к проце-
    дуре «просмотра», которая могла бы указывать сокет, через который
    можно было бы получить новообразованные услуги. Концепция общеизвест-
    ного сокета является частью TCP спецификации, однако собственно асо-
    циирование сокетов с услугами выходит за рамки данного описания про-
    токола (см. документ [4]).
    Процессы могут осуществлять пассивные открытия соединений и ждать,
    пока от других процессов придут соответсвующие завпросы на активное
    открытие, а протокол TCP проинформирует их об установлении соедине-
    ния. Два процесса, сделавшие друг другу одновременно запросы на ак-
    тивное открытие, получат корректное соединение. Гибкость такого под-
    хода становится критичной при поддержке распределенных вычислений,
    когда компоненты системы взаимодействуют друг с другом асинхронным
    образом.
    Когда осуществляется подбор сокетов для локального запроса пассив-
    ного открытия и чужого запроса на активное открытие, то принципиаль-
    ное значение имеют два случая. В первом сслучае местное пассивное от-
    крытие полностью определяет чужой сокет. При этом подбор должен осу-
    ществляться очень аккуратно. Во втором случае во время местного пас-
    сивного открытия чужой сокет не указывается. Тогда в принципе может
    быть установлено соединение с любых чужих сокетов. Во всех остальных
    случаях подбор сокетов имеет частичные ограничения.
    Если на один и тот же местный сокет осуществлено несколько ждущих
    пассивных запросов на открытие (записанных в блоки TCB), и осущест-
    вляется извне активный запрос на открытие, то чужой активный сокет
    будет связываться с тем блоком TCB, где было указание именно на этот
    запросивший соединения сокет. И только если такого блока TCB не су-
    ществует, выбор партнера осуществляется среди блоков TCB с неопреде-
    ленным чужим сокетом.
    Процедура установки соединения использует флаг управления синхро-
    низацией (SYN) и трижды обменивается сообщениями. Такой обмен называ-
    ется трехвариантным подтверждением [3].
    Соединение инициируется при встрече пришедшего сегмента, несущего
    флаг синхронизации (SYN), и ждущей его записи в блоке TCB. И сегмент
    и запись создаются пришедшими от пользователей запросами на открытие.
    Соответствие местного и чужого сокетов устанавливается при инициали-
    зации соединения. Соединение признается установленным, когда номера
    очередей синхронизированы в обоих направлениях между сокетами.
    Отмена соединения также включает обмен сегментами, несущими на
    этот раз управляющий флаг FIN.

    2.8 Коммуникация данных
    Набор данных, передаваемых по соединению, можно рассматривать как
    поток октетов. Пользователь, отправляющий данные, указывает при за-
    просе по посылку, следует ли данные, отправляемые при этом запросе,
    немедленно проталкивать через сеть к получателю. Указание осуществля-
    ется установкой флага PUSH (проталкивание).
    Программа протокола TCP может собирать данные, принимаемые от
    пользователя, а затем передавать их в сеть по своему усмотрению в ви-
    де сегментов. Если же выставлен запрос на проталкивание, то протокол
    должен передать все неотправленные ранее данные. Когда программа про-
    токола TCP, принимающая данные, сталкивается с флагом проталкивания,
    ей не следует ожидать получения новых данных по сети до тех пор, пока
    уже имеющиеся данные не будут переданы ждущему их местному процессу.
    Нет нужды привязывать функции проталкивания к границам сегмента.
    Данные, содержащиеся в каком-либо сегменте, могут быть результатом
    одного или нескольких запросов на посылку. Или же один запрос может
    породить несколько сегментов.
    Целью функции проталкивания и флага PUSH является проталкивание
    данных через сеть от отправителя к получателю. Функция не
    осуществляет обработки самих данных.
    Существует связь между функцией проталкивания и использованием
    буферов данных в интерфейсе между пользователем и протоколом TCP.
    Каждый раз, когда в буфер получателя приходят данные с флагом PUSH,
    содержимое этого буфера передается пользователдю на обработку, даже
    если буфер и не был заполнен. Если приходящие данные заполняют буфер
    пользователя до того, как получена команда проталкивания,
    пользователю отправляется блок данных, соответствующий размеру
    буфера. Протокол TCP имеет также средства для сообщения получателю,
    что с некоторого момента он имеет дело со срочными данными. Протокол
    TCP не пытается определить, что именно пользователь делает со ждущими
    обработки срочными данными. Однако обычно предполагается, что
    получающий данные процесс будет предпринимать усилия для быстрой
    обработки срочных данных.

    2.9 Приоритет и безопасность
    Протокол TCP использует тип сервиса и опцию безопасности протокола
    Internet с тем, чтобы пользователям протокола TCP обеспечить приори-
    тет и безопасность на каждом соединении. Не все модули протокола TCP
    обязательно будут действовать в многоуровневой системе обеспечения
    безопасности. Некоторые модули ограничиваются только обычными, неспе-
    цифическими соединениями, другие ограничиваются лишь первым уровнем
    безопасности и закрытости. Следовательно, некоторые реализации прото-
    кола TCP и услуг для пользователей могут использовать лишь часть мно-
    гоуровневой системы безопасности.
    Модули TCP, действующие в многоуровневой системе безопасности,
    должны адекватным образом выставлять в отсылаемых сегментах флаги
    безопасности и приоритета. Такие модули TCP должны также позволять
    своим клиентам или вышестоящим протоколам, таким как Telnet и THP,
    указывать требуемый уровень безопасности, закрытости и приоритета для
    устанавливаемых соединений.

    2.10 Принцип устойчивости
    Все реализации протокола TCP будут следовать общему принципу
    устойчивости: быть консервативным в своих действиях и предоставлять
    свободу для других.

    3 Спецификация для функций протокола

    3.1 Формат заголовка
    Передача TCP сегментов осуществляется в виде Internet датаграмм.
    Заголовок датаграммы в Internet протоколе имеет несколько информаци-
    онных полей, включая адреса отправляющего и принимающего хост-
    компьютеров [2]. Заголовок TCP следует за Internet заголовком и до-
    полняет его информацией, специфической для TCP протокола. Такое де-
    ление допускает использование на уровне хост-компьютеров протоколов,
    иных нежели TCP.
    Формат TCP заголовка

    Рис. 3 Формат TCP заголовка
    Отметим, что каждая метка указывает здесь место для соответствующего
    бита.
    Source Port (порт отправителя) 16 бит
    номер порта отправителя
    Destination Port (порт получателя) 16 бит
    номер порта получателя
    Sequence Number (номер очереди) 32 бита
    Номер очереди для первого октета данных в данном сегменте (за ис-
    ключением тех случаев, когда присутствует флаг синхронизации SYN).
    Если же флаг SYN присутствует, то номер очереди является инициали-
    зационным (ISN), а номер первого октета данных — ISN+1.
    Acknowledgment Number (номер подтверждения) 32 бита
    Если установлен контрольный бит ACK, то это поле содержит следущий
    номер очереди, который отправитель данной датаграммы желает полу-
    чить в обратном направлении. Номера подтверждения посылаются по-
    стоянно, как только соединение будет установлено.
    Data Offset (смещение данных) 4 бита
    Количество 32-битных слов в TCP заголовке. Указывает на начало по-
    ля данных. TCP заголовок всегда кончается на 32-битной границе
    слова, даже если он содержит опции.
    Reserved 6 бит
    Это резервное поле, должно быть заполнено нулями.
    Control Bits (контрольные биты) 6 бит
    Биты этого поля слева направо
    URG: поле срочного указателя задействовано
    ACK: поле подтверждения задействовано
    PSH: функция проталкивания
    RST: перезагрузка данного соединения
    SYN: синхронизация номеров очереди
    FIN: нет больше данных для передачи
    Window (окно) 16 бит
    Количество октетов данных, начиная с октета, чей номер указан в
    поле подтверждения. Количество октетов, получения которых ждет
    отправитель настоящего сегмента.
    Checksum (контрольная сумма) 16 бит
    Поле контрольной суммы — это 16-битное дополненение суммы всех 16-
    битных слов заголовка и текста. Если сегмент содержит в заголовке
    и тексте нечетное количество октетов, подлежащих учету в контоль-
    ной сумме, последний октет будет дополнен нулями справа с тем,
    чтобы образовать для предоставления контрольной сумме 16-битное
    слово. Возникший при таком выравнивании октет не передается вместе
    с сегментом по сети. Перед вычислением контрольной суммы поле этой
    суммы заполняется нулями.
    Контрольная сумма, помимо всего прочего, учитывает 96 бит псев-
    дозаголовка, который для внутреннего употребления ставится перед
    TCP заголовком. Этот псевдозаголовок содержит адрес отправителя,
    адрес получателя, протокол и длину TCP сегмента. Такой подход
    обеспечивает защиту протокола TCP от ошибшихся в маршруте сегмен-
    тов. Эту информацию обрабатывает Internet протокол. Она передается
    через интерфейс протокол TCP/локальная сеть в качестве аргументов
    или результатов запросов от протокола TCP к протоколу IP.

    Длина TCP сегмента — это длина TCP заголовка и поля данных, из-
    меренная в октетах. Это не является точным указанием количества
    передаваемых по сети октетов, она не учитывает 12 октетов псевдо-
    заголовка, но тем не менее расчет этого параметра все же произво-
    дится.
    Urgent Pointer (срочный указатель) 16 бит
    Это поле сообщает текущее значение срочного указателя. Последний
    является положительной величиной — смещением относительно номера
    очереди данного сегмента. Срочный указатель сообщает номер очереди
    для октета, следующего за срочными данными. Это поле интерпретиру-
    ется только в том случае, когда в сегменте выставлен контрольный
    бит URG.
    Options (опции) длина переменная
    Опции могут располагаться в конце TCP заголовка, а их длина кратна
    8 бит. Все опции учитываются при расчете контрольной суммы. Опции
    могут начинаться с любого октета. Они могут иметь два формата:
    — однооктетный тип опций;
    — октет типа опции, октет длины опции и октеты данных
    рассматриваемой опции.
    В октете длины опции учитываются октет типа опции, сам октет
    длины, а также все октеты с данными.
    Заметим, что список опций может оказаться короче, чем можно ука-
    зать в поле Data Offset. Место в заголовке, остающееся за опцией
    «End-of-Option», должно быть заполнено нулями. Протокол TCP должен
    быть готов обрабатывать все опции.
    В настоящее время определены следующие опции:
    Тип Длина Значение
    0 — конец списка опций
    1 — нет операций
    2 4 максимальный размер сегмента
    Определения указанных опций
    Конец списка опций

    Этот код опции определяет конец списка опций. Конец списка может
    не совпадать с концом TCP заголовка, указанным в поле Data Offset.
    Эта опция используется после всех опций, но не после каждой из
    них. Опцию необходимо использовать только в том случае, если иначе
    не будет совпадения с концом TCP заголовка.
    Нет операций

    Опции этого типа могут ставиться между опциями. Целью при этом
    может служить выравнивание очередной опции по границе слова. Нет
    гарантии, что отправители будут использовать данную опцию. Поэтому
    получатели должны быть готовы обрабатывать опции, даже если они не
    будут начинаться на границе слова.
    Максимальный размер сегмента

    тип 2 длина=4
    Поле данных опции — 16 бит. Если опция присутствует в списке,
    то она указывает для программы протокола TCP максимальный размер
    получаемого сегмента, отправившей сегмент с этой опцией. Эту опцию
    следует посылать лишь при первоначальном запросе на установление
    соединения (т.е. в сегментах с установленным контрольным битом
    SYN). Если данная опция не была использована, ограничения на раз-
    мер отсутствуют.
    Padding (выравнивание) длина переменная
    Выравнивание TCP заголовка осуществляется с тем, чтобы убедиться в
    том, что TCP заголовок заканчивается, а поле данных сегмента начи-
    нается на 32-битной границе. Выравнивание выполняется нулями.

    3.2 Терминология
    Прежде чем мы сможем обсудить многие детали действия TCP протоко-
    ла, нам необходимо ввести подробную терминологию. Для поддержания TCP
    соединения необходиом иметь несколько переменных. Мы решили, что эти
    переменные будут помещены в соответствующую запись — блок управления
    передачей (Transmission Control Block — TCB). Среди переменных блока
    TCB имеются номера местного и чужого сокетов, флаги безопасности и
    приоритета для данного соединения, указатели буферов посылки и полу-
    чения, указатели текущего сегмента и очереди повторной посылки. Кроме
    всего этого в TCB имеются несколько переменных, имеющих отношение к
    номерам очередей отправителя и получателя.

    Отправление
    SND.UNA — посылка неподтверждена
    SND.NXT — послать следующий сегмент
    SND.WND — отправить окно
    SND.UP — отправить срочный указатель
    SND.WL1 — номер очереди сегмента, использованный для обновления
    последнего окна
    SND.WL2 — номер подтверждения в сегменте, используемый для обновления
    последнего окна
    ISS — первоначальный номер очереди отправления

    Получение
    RCV.NXT — получить следующий сегмент
    RCV.WND — получить окно
    RCV.UP — получить срочный указатель
    IRS — первоначальный номер очереди получения

    Нижеприведенные диаграммы могут помочь связать некоторые из этих
    переменных с местом в очереди

    1. — старые номера очереди, которые получили подтверждение
    2. — номера очереди для данных, не получивших подтверждения
    3. — номера очереди, допущенные к новой передаче
    4. — следующие номера очереди, чья передача еще не разрешена
    Рис. 4 Очередь отправления
    Окно отправления — это участок очереди, отмеченный меткой 3 на
    рисунке 4.

    1. — старые номера очереди, которые получили подтверждение
    2. — номера очереди, допущенные к очередному этапу получения
    3. — следующие номера очереди, еще не получившие разрешения
    Рис. 5 Очередь получения
    Окно получения — это участок очереди, отмеченный меткой 2 на рисунке
    5.
    В обсуждении также часто используются некоторые переменные,
    берущие свое значение из полей очередного сегмента.
    Переменные для очередного сегмента
    SEG.SEQ — номер очереди для сегмента
    SEG.ACK — номер подтвержения для сегмента
    SEG.LEN — длина сегмента
    SEG.WND — окно для сегмента
    SEG.UP — срочный указатель для сегмента
    SEG.PRC — приоритет для сегмента
    Соединение во время функционирования проходит через серии промежу-
    точных состояний. Это состояния LISTEN, SYN-SENT, SYN-RECEIVED,
    ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK,
    TIME-WAIT, а также фиктивное состояние CLOSED. Состояние CLOSED явля-
    ется фиктивным, поскольку оно представляет состояние, когда не су-
    ществует блока TCP, а потому и нет соединения. Краткое описание сос-
    тояний:
    LISTEN — Ожидание запроса на соединение со стороны чужих портов
    и программ TCP
    SYN-SENT — Ожидание парного запроса на установление соединения. С
    нашей стороны запрос уже сделан.
    SYN-RECEIVED — Ожидание подтверждения после того, как запрос
    соединения уже принят и отправлен.
    ESTABLISHED — Состояние открытого соединения, принимаемые данные
    можно представить пользователю. Это нормальное
    состояние соединения в фазе передачи данных.
    FIN-WAIT-1 — Ожидание запроса от чужой программы TCP, или
    подтверждения ранее отправленного запроса на закрытие
    соединения.
    FIN-WAIT-2 — Ожидание запроса на закрытие соединения со стороны
    чужой программы TCP.
    CLOSE-WAIT — Ожидание запроса на закрытие соединения со стороны
    своего клиента.
    CLOSING — Ожидание подтверждения со стороны чужой программы TCP
    запроса о закрытии соединения.
    LAST-ACK — Ожидание запроса на закрытие соединения, ранее
    отправленного чужой программе TCP (запрос включал
    также подтверждение получения чужого запроса на
    закрытие соединения).
    TIME-WAIT — Ожидание когда истечет достаточное количество времени
    и можно быть уверенным, что чужая программа TCP
    получила подтверждение своего запроса на закрытие
    соединения.
    CLOSED — Состояние полного отсутствия соединения.
    Соединение TCP переходит с одного состояния на другое в ответ на со-
    бытия. Событие — это запросы клиента (открытие, посылка, получение,
    закрытие, отказ, получение состояния соединения), приход сегментов, и
    особенно тех, которые содержат флаги SYN, ACK, RST и FIN, а также ис-
    течение выделенного времени.
    Диаграмма состояний на рисунке 6 иллюстрирует лишь смену состояний, а
    также вызвавшие это события, производимые действия, но не адреса, ус-
    ловия ошибок, не действия, не связанные прямо с изменением состояния.
    Более подробные сведения о действиях программы протокола TCP в ответ
    на события приведены в последней главе.
    Замечание. Данная диаграмма является лишь сводной, но не должна
    восприниматься как полная спецификация.

    3.3 Номер очереди
    Основополагающей идеей в проектировании протокола является то, что
    каждый октет данных, посылаемый на TCP соединение, имеет номер очере-
    ди. Поскольку каждый октет пронумерован, то каждый из них может быть
    опознан. Приемлемый механизм опознания является накопительным, так
    что опознание номера X означает, что все октеты с предыдущими номера-
    ми уже получены. Этот механизм позволяет регистрировать появление
    дубликатов в условиях повторной передачи. Нумерация октетов в преде-
    лах сегмента осуществляется так, чтобы первый октет данных сразу
    вслед за заголовком имел наименьший номер, а следующие за ним октеты
    имели номера по возрастающей.
    Важно помнить о том, что количество номеров для очереди, хоть и
    велико, но ограничено. Диапазон номеров — от 0 до 2**32-1. Поскольку
    набор ограничен, то все арифметические операции с номерами очередей
    должны осуществляться по модулю 2**32. Это совсем не означает всякий
    раз предварительную арифметическую проверку номеров очереди на попа-
    дание в диапазон от 2**32-1 до 0. В работе с модульной арифметикой
    есть некие тонкости, поэтому нужно аккурактно программировать сравне-
    ние столь больших величин. Так символ ‘=

    Заметим, что когда окно, получения нулевое, никакие сегменты прини-
    маться не будут за исключением ACK сегментов. Таким образом, протокол
    TCP может устанавливать нулевое окно получения при передаче данных и
    получении подтверждений. Однако даже когда окно получения нулевое,
    программа протокола TCP обязана обрабатывать поля RST и URG всех при-
    ходящих сегментов.
    Мы получили преимущество данной схемы нумерации в том, что она
    допускает также защиту для определенной управляющей информации. Это
    достигается косвенным образом посредством включения некоторых кон-
    трольных флагов в очередь, так что они могут быть повторно посланы и
    подтверждены без сбоя (т.е. будет задействована одна или несколько
    копий). Управляющая информация реально находится не в поле данных
    сегмента. Следовательно, мы должны принять правила косвенного присво-
    ения номеров очереди сегментам управления. SYN и FIN являются един-
    ственными управляющими сигналами, приемлемыми для такой защиты, и они
    используются только при открытии и закрытии соединения. Для целей
    поддержания очередности, сигнал SYN рассматривается как стоящий перед
    первым действительным октетом данных в сегменте, куда оба они были
    помещены. В то же время FIN считается стоящим после последнего реаль-
    ного октета данных в сегменте. Длина сегмента (SEG.LEN) учитывает как
    данные, так и номера очереди, отведенные под управление. В случае,
    когда присутствует SYN, значение SEG.SEQ соответствует номеру в оче-
    реди для сигнала SYN.

    Выбор первоначального номера для очереди
    Протокол не накладывает ограничения на многократное повторное ис-
    пользование конкретного соединения. Соединение задается подбором пары
    сегментов. Новые запросы на установление какого-либо соединения будут
    рассматриваться как повторные реализации этого соединения. Вследствие
    такого подхода возникает следующая проблема: «Как протокол TCP отли-
    чает дубликаты сегментов, оставшиеся от предыдущей реализации этого
    соединения?» Эта проблема становится явной, если соединение быстро
    открывается и закрывается несколько раз подряд, или же если соедине-
    ние прерывает свою работу с потерей информации, хранившейся в опера-
    тивной памяти компьютера, и затем устанавливается повторно. Чтобы
    избежать сбоя, мы должны избегать использования сегментов данной реа-
    лизации соединения, когда в сети еще присутствуют те же самые номера
    очереди, оставшиеся от предыдущей реализации соединения. Мы желаем
    застраховаться от этого, даже если программа протокола TCP даст сбой
    и потеряет всю информацию об используемых ею номерах очередей. При
    создании новых соединений применяется генератор первоначальных номе-
    ров очереди (ISN), который выбирает новые 32 битные значения ISN.
    Генератор привязан к 32-битным часам (вероятно, фиктивным), чье зна-
    чение меняется каждые 4 микросекунды. Таким образом, полный цикл ча-
    сов ISN составляет примерно 4.55 часа. Поскольку мы полагаем, что
    сегменты будут существовать в сети не более максимального времени
    жизни сегмента (Maximum Segment Lifatime — MSL), и что MSL меньше,
    чем 4.55 часа, то мы можем с основанием полагать, что номера ISN бу-
    дут уникальны.
    Для каждого соединения существует номер в очереди отправления и
    номер в очереди получения. Первоначальный номер в очереди отправления
    (ISS) выбирается программой TCP, посылающей данные в этой очереди, а
    первоначальный номер в очереди получения (IRS) выясняется во время
    установления соединения.
    Во время установления или инициализации какого-либо соединения обе
    программы протокола TCP должны синхронизировать друг с другом перво-
    начальные номера очередей. Это осуществляется посредством обмена сег-
    ментами, устанавливающими соединения, несущими контрольный бит, назы-
    ваемый «SYN» (for synchronize — для синхронизации), несущими исходные
    номера для очередей. Для краткости, сегменты, несущие бит SYN, также
    называются SYN сегментами. Следовательно, решение проблемы требует
    приемлемого механизма для подбора первоначального номера очереди и
    немногочисленных сигналов подтверждения при обмене номерами ISN.
    Синхронизация требует, чтобы каждая сторона, участвующая в соеди-
    нении, посылала свой собственный первоначальный номер очереди, а так-
    же получала подтверждение на это от напарника. Каждая сторона должна
    также получить первоначальный номер очереди от напарника и послать
    подтверждение.
    1) A B сигнал SYN: мой номер очереди X
    2) A B сигнал ACK: ваш номер очереди Y
    Поскольку шаги 2 и 3 можно объединить в одно сообщение, последнее
    называется подтверждением трех путей (трех сообщений).
    Подтверждение трех путей необходимо, поскольку номера очереди не
    привязываются к неким глобальным часам данной компьютерной сети, и
    программы TCP могут иметь различные механизмы для подбора номеров
    ISN. Получатель первого сигнала SYN не может знать, задержался ли
    этот сигнал и уже устарел, или это не так, даже если получатель не
    помнит последний номер очереди, использованный этим соединением (что
    тоже не всегда возможно). Так что он должен попросить отправителя
    проверить этот сигнал SYN. Подтверждение трех путей и преимущества
    хронометрированной схемы обсуждаются в статье [3].

    Период молчания
    Чтобы быть уверенным в том, что программа TCP не создает сегмента,
    несущего номер очереди, который уже используется старым сегментом,
    все еще «ходящим» по сети, программа TCP должна сохранять молчание по
    крайней мере в течении времени жизни сегмента (MSL) до тех пор, пока
    она не назначит какие-либо номера очереди при запуске или восстанов-
    лении после сбоя, когда записи в пямяти для прежних номеров из очере-
    ди были потеряны. В данной спецификации MSL берется равным 2 минуты.
    Это значение выбрано разработчиками и может быть изменено, если прак-
    тика покажет необходимость в этом. Заметим, что если программа прото-
    кола в некотором смысле повторно инициализируется, но при этом в па-
    мяти остались применявшиеся ранее номера очереди, то в ожидании нужды
    нет; следует лишь убедиться в том, что новые рабочие номера очередей
    больше, чем применявшиеся ранее.

    Концепция периода молчания в протоколе TCP
    Данная спецификация ставит условие что компьютеры, потерпевшие
    крах с потерей всей информации о последних номерах очередей, переда-
    ваемых по открытым (т.е. не закрытым специальной командой) соедине-
    ниям, будут воздерживаться от посылки каких-либо TCP сегментов в те-
    чении по крайней мере максимального времени жизни сегмента (Maximum
    Segment Lifetime — MSL) в системе Internet, чей частью и является
    данный хост. В последующих параграфах приводится объяснение для этой
    спецификации. Некоторые реализации протокола TCP могут нарушать со-
    глашение о периоде молчания, рискуя при этом тем, что некоторые полу-
    чатели в системе Internet будут воспринимать старые данные как новые,
    или новые данные будут отброшены словно дубликаты в действительности
    устаревших сегментов.
    Программы протокола используют новые номер очереди всякий раз,
    когда какой-либо сегмент формируется и помещается на хосте в очередь
    отправления по сети. Процедура фиксирования дубликатов и алгоритм
    очереди в протоколе TCP полагаются на уникальное связывание данных
    сегмента с местом в очереди. Номера очереди не успевают пройти весь
    диапазон в 2**32 значения, прежде чем связанные с ними данные из от-
    правленного сегмента получат подтверждение от получателя, а все
    копии-дубликаты упомянутого сегмента покинут сеть Internet. Без этого
    условия можно предположить, что двум отдельным TCP сегментам могут
    быть назначены одинаковые или перекрывающиеся номера, что вызовет
    проблему у получателя при определении, какие данные являются новыми,
    а какие устаревшими. Напомним, что каждый сегмент привязан как ко
    множеству следующих друг за другом номеров очереди, так и к имеющимся
    в этом сегменте октетам данных.
    При обычных условиях программы TCP отслеживают текущий номер оче-
    реди, подлежащий отправке, а также самое старое из ожидаемый подтвер-
    ждений, что позволяет избежать ошибочного использования номера очере-
    ди, прежде чем будет получено подтверждение от более раннего исполь-
    зования этого же номера. Одно это не гарантирует, что старые данные —
    дубликаты будут удалены из сети, поэтому номера очереди сделаны очень
    большими, чтобы уменьшить вероятность того, что странствующие по сети
    дубликаты вызовут сбой по прибытии. При скорости обмена 2
    мегабайта/сек очереди в 2**32 октета хватает на 4.5 часа. Поскольку
    максимальное время жизни сегмента в сети вряд ли превышает несколько
    десятков секунд, это считается достаточной защитой для будущих сетей,
    даже если скорости передачи данных возрастут до десятков мегабит/сек.
    При скорости 100 мегабит/сек один цикл использования всех номеров
    очереди составляет 5.4 минуты, что может быть достаточно мало, но еще
    остается приемлемым.
    Однако основной механизм регистрации дублей и поддержания очередей
    может быть отменен, если программа протокола TCP, посылающая данные,
    не имеет места в памяти для хранения номеров в очереди, которые она
    использовала в последний раз для конкретного соединения. Например,
    если программа TCP при создании всех соединений начинает с номера
    очереди 0, то при сбое и повторном запуске программа TCP может по-
    вторно сформировать прежнее соединение (возможно, после анализа напо-
    ловину открытого соединения) и послать по нему пакеты, чьи номера в
    очереди полностью совпадают или лишь частично перекрывают номера па-
    кетов, которые еще присутствуют в сети и были отправлены предыдущей
    реалиизацией этого же соединения. В отсутствие сведений о номерах
    очереди, прежде использовавшихся для передачи информации по данному
    конкретному соединению, спецификация протокола TCP рекомендует отпра-
    вителю воздержаться на MSL секунд от посылки сегментов по этому со-
    единению, что даст возможность сегментам, запущенным в сеть старой
    реализацией соединения, покинуть систему.
    От этой проблемы не защищены даже те хост-компьютеры, которые мо-
    гут отслеживать текущее время и использовать его при выборе исходных
    номеров очереди (т.е. даже если время используется для выбора исход-
    ного номера при реализации каждого нового соединения).
    В качестве примера предположим, что соединение открыто со старто-
    вым номером очереди S. Предположим также, что это соединение исполь-
    зуется не столь часто и возможно, функция определения исходного номе-
    ра очереди (ISN(t)) принимает значение (скажем, S1), равное номеру
    последнего сегмента, отправленного данной программой TCP, по этому
    конкретному соединению, Теперь предположим, что именно в этот момент
    хост-компьютер дал сбой, восстановился и устанавливает новую реализа-
    цию этого соединения. Первоначальный номер очереди при этом будет
    S1=ISN(t), а это последний номер очереди в старой реализации соедине-
    ния! Если восстановление произойдет достаточно быстро, то старые ду-
    бликаты, созданные с номером очереди, близким к номеру S1, могут быть
    получены своим адресатом и обработаны так, как будто бы это новые
    пакеты в новой реализации соединения.
    Проблема состоит в том, что хост-компьютер — получатель может не
    знать, как долго он был в состоянии сбоя и существуют ли еще в систе-
    ме старые дубликаты, оставшиеся от прежних реализаций соединений.
    Одним из путей решения этой проблемы является преднамеренная за-
    держка в отправлении сегментов в течении времени MSL после восстанов-
    ления вслед за крахом — это спецификация периода молчания. Хост-
    компьютеры, предпочитающие избегать паузы, рискуют получить проблему
    столкновения старых и новых пакетов на каком-либо адресате, пожелав-
    шем не прибегать к периоду молчания.
    Реализации протокола могут предложить пользователям TCP возмож-
    ность выбора между ожиданием в соединениях после сбоя и несоблюдением
    периода молчания для любых соединений. Очевидно, что для тех про-
    грамм, где пользователь выбрал режим ожидания, в действительности, в
    этом нет нужды после того, как компьютер был выключен по крайней мере
    MSL секунд.
    Итак, каждый отправленный сегмент занимает один или несколько но-
    меров в очереди ожидания. Номера, отведенные под сегмент, являются
    «занятыми» или «в работе», пока не истекут MSL секунд. При сбое опре-
    деленное место в очереди в течении определенного времени продолжает
    оставаться занятым октетами из последнего отправленного сегмента.
    Если вскоре создается новое соединение и оно испльзует какие-либо
    номера из очереди в момент, когда ими еще пользуется сегмент из пре-
    дыдущей реализации соединения, то следовательно эта область перекры-
    вания номеров очередей может являться причиной проблем у получателя.

    3.4 Установление соединения
    «Подтверждение трех путей» — это процедура, используемая при уста-
    новлении соединения. Эта процедура обычно инициируется программой
    протокола TCP в ответ на запрос другой программы TCP. Данная процеду-
    ра также работает, если две программы TCP инициируют ее одновременно.
    Когда попытка инициализации осуществляется с обоих концов одновремен-
    но, каждая программа протокола TCP получает сегмент «SYN», который не
    несет подтверждения для уже отправленного ею «SYN». Конечно, прибытие
    старых дубликатов сегмента «SYN» может произвести впечатление на по-
    лучателя, будто осуществляется одновременное открытие соединения.
    Корректное применение сегментов «перезагрузки» может предотвратить
    двусмысленность таких ситуаций.
    Ниже приведены несколько примеров инициализации соединений. Хотя
    эти примеры не показывают синхронизации соединения с помощью сегмен-
    тов, несущих данные, это совершенно правомерно, поскольку программа
    TCP, получающая сегменты, не передаст данные своему клиенту, пока не
    станет очевидным корректность данных (т.е. данные должны
    «складироваться» пользователем до тех пор, пока соединение не перей-
    дет в состояние ESTABLISHED). Подтверждение трех путей уменьшает ве-
    роятность появления ложных соединений. Получение информации для такой
    проверки достигается посредством реализации обмена между памятью ком-
    пьютера и циркулирующими в сети сообщениями.
    Простейшая процедура подтверждения трех путей показана ниже на
    рисунке 7. Рисунки следует интерпретировать следующим образом. Для
    удобства каждая строка пронумерована. Правые стрелки () показывают
    отправление TCP сегмента от программы TCP A в программу TCB B, или же
    получение сегмента программой B из программы A. Левые стрелки (

    Рисунок 7.
    На строке 2 рисунка 7 программа TCP A начинает с посылки сигнала
    SYN, показывая тем самым, что она будет использовать нимера очереди,
    начиная с номера 100. На строке 3 программа TCB B посылает сигнал
    SYN, а также подтверждение о том, что сигнал SYN со стороны программы
    TCP A получен. Заметим, что поле подтверждения информирует о том, что
    программа TCP B в данный момент ожидает получение номера 101. Послед-
    нее также подтверждает, что сигнал SYN уже занял место в очереди под
    номером 100.
    На строке 4 для отправленного программой TCP B в строке 3 сигнала
    SYN программа TCP A дает ответ с помощью пустого сегмента, содержаще-
    го сигнал ACK . В строке 5 программа TCP A передает по сети уже некую
    порцию данных. Заметим, что сегмент в строке 5 имеет тот же номер
    очереди, что был у сегмента в строке 4, поскольку сигнал ACK в очере-
    ди места не занимает (если бы это было не так, то нам следовало обза-
    вестись подтверждением -ACK- для самого подтверждения!).
    На рисунке 8 показана та же инициализация с незначительными услож-
    нениями. Каждая программа TCP проходит по очереди состояния CLOSED,
    SYN-SENT, SYN-RECIEVED и наконец, ESTABLISHED.

    Рисунок 8
    Главной причиной для приненения подтверждения трех путей является
    попытка преотвратить возникновение сбоев при получении старых дубли-
    катов, инициирующих соединение. Для работы с подтверждением трех пу-
    тей придумано специальное контрольное сообщение — перезагрузка
    (reset). Если получающая сигнал программа TCP находится не в синхро-
    низированном состоянии (т.е. в SYN-SENT, SYN-RECEIVED), то она воз-
    вращает сигнал LISTEN, показывая, что она получила приемлемый сигнал
    перезагрузки. Если же программа TCP находится в одном из синхронизи-
    рованных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
    CLOSING, LAST-ACK, TIME-WAIT), то она ликвидирует соединение и про-
    информирует об этом своего клиента. Мы обсудим ниже такую ситуацию
    при рассмотрении «наполовину открытых» соединений.

    Рисунок 9
    В качестве простого примера рассмотрим ситуацию с получением ста-
    рых дубликатов на рисунке 9. На строке 3 старый дубликат сигнала SYN
    достигает программу TCP B. Последняя не может определить, что это
    старый дубликат, и поэтому отвечает обычным образом (строка 4). Про-
    грамма TCP A обнаруживает ошибочное значение в поле ACK и поэтому
    возвращает сигнал RST (перезагрузка). При этом значение поля SEQ вы-
    бирается таким образом, чтобы сделать сегмент правдоподобным. Про-
    грамма TCP B по получении сигнала RST переходит в состояние LISTEN.
    Когда на строке 6 сигнал SYN, действительный, а не устаревший, дости-
    гает программу TCP B, процесс синхронизации происходит нормально.
    Если же сигнал SYN на строке 6 достигает программу TCP B прежде сиг-
    нала RST, может возникнуть более сложная комбинация обмена с посылкой
    RST в обоих направлениях.

    Наполовину открытые соединения и другие аномалии
    Уже установившееся соединение называется «наполовину открытым»,
    если одна из программ TCP закрыла соединение, или отказалась от него.
    Причем сделала это на своем конце, не предупредив своего партнера.
    Также такая ситуация может возникнуть, если нарушена синхронизация на
    концах линии вследствие сбоя, приведшего к потере информации в памя-
    ти. Если на таких соединениях делается попытка отправить данные в
    каком-либо направлении, то автоматически производится перезагрузка
    соединения. Однако пердполагается, что наполовину открытые соединения
    являются редкостью, а процедура восстановления применяется в сети
    весьма умеренно.
    Если на конце A соединение считается уже несуществующим, а клиент
    на конце B пытается послать данные, то это приведет к тому, что про-
    грамма TCP на конце B получит контрольное сообщение о перезагрузке.
    Такое сообщение показывает программе TCP на конце B, что что-то не-
    правильно и ей предлагается ликвидировать это соединение.
    Предположим, что два клиента в точках A и B общаются друг с дру-
    гом, и в этот момент происходит крах, приводящий к потере информации
    в памяти у программы TCP на конце A. В зависимости от операционной
    системы, обслуживающей программу TCP A, вероятно, будет задейстовован
    некий механизм исправления ошибки. Когда программа TCP A будет запу-
    щена вновь, она, вероятно, вновь начнет свою работу с самого начала
    или же с инструкции преодоления сбоя. В результате, программа A, ве-
    роятно, попытается открыть (OPEN) соединение или послать информацию
    (SEND) через соединение, которое, как она полагает, является откры-
    тым. В последнем случае от местной программы TCP (на конце A) будет
    получено сообщение «соединение не открыто». При попытке установить
    соединение программа TCP A будет посылать сегмент, содержащий сигнал
    SYN. Такой сценарий приводит к ситуации, показанной на рисунке 10.
    После того, как программа TCP A потерпит крах, пользователь попытает-
    ся повторно открыть соединение. Программа TCP B тем временем продол-
    жает полагать, будто соединение остается открытым.

    Рисунок 10
    Когда на строке 3 сигнал SYN достигает программу TCP B, находящую-
    ся в синхронизированном состоянии, а пришедший сегмент находится за
    пределами окна, программа TCP B отвечает на это его подтверждением,
    показывает номер очереди, который она желает получить (ACK=100). Про-
    грамма TCP A, видя, что сегмент на строке 4 не подтвердил отправлен-
    ную ею информацию, фиксирует отсутствие синхронизации и посылает сиг-
    нал перезагрузки (RST), поскольку обнаружено, что соединение является
    открытым наполовину. На строке 5 программа TCP B ликвидирует соедине-
    ние. Программа TCP A будет продолжать попытки установить соедлинение.
    Теперь возникшая проблема решается простым подтверждением трех путей
    (рисунок 7).
    Другой интересный сюжет имеет место, если программа TCP A терпит
    крах, а программа TCP B, полагая, что находится в состоянии синхрони-
    зации, пытается послать данные. Эта ситуация показана на рисунке 11.
    В этом случае данные, отправленные программой TCP B, и пришедшие на
    программу TCP A (строка 2). будут отвергнуты, поскольку используемого
    ими соединения не существует. На основании этого программа TCP A по-
    сылает сигнал RST. Как только сигнал RST принят программой TCP B, он
    будет рассмотрен, а использованное прежде соединение будет ликвидиро-
    вано.

    Рисунок 11
    На рисунке 12 показано, что две программы TCP — A и B — ,имея
    пасивное состояние, ждут сигнала SYN. Старый дубликат сигнала, дости-
    гает программу TCP B (строка 2), запускает ее. Возвращается сигнал
    SYN-ACK (строка 3) и заставляет программу TCP A генерировать сигнал
    RST (на строке 3 сигнал ACK неприемлем). Программа TCP B принимает
    команду перезагрузки и волзвращается в пассивное состояние LISTEN.

    Рисунок 12
    Может быть множество других вариаций, которые могут быть объяснены
    нижеописанными правилами для создания и обработки сигналов RST.

    Создание сигнала перезагрузки
    Согласно главному правилу, сигнал перезагрузки (RST) должен посы-
    латься всякий раз, когда приходит сегмент, который очевидным образом
    не предназначен для данного соединения. Если непонятно, имеет ли мес-
    то данный случай, следует воздержаться от перезагрузки.
    Можно выделить три группы состояний для соединения:
    1. Если соединения не существует (CLOSED), то сигнал перезагрузки по-
    сылается в ответ на любой пришедший сегмент, за исключением
    встречного сигнала перезагрузки. В частности, сигналы SYN, адресо-
    ванные на несуществующее соединение, ответгаются именно таким об-
    разом.
    Если приходящий сегмент имеет флаг в поле ACK, то сегмент с сигна-
    лом перезагрузки получает номер для очереди из поля ACK первого
    сегмента. В противном случае сегмент с сигналом перезагрузки имеет
    нулевой номер очереди и значение в поле ACK, равным сумме номера
    очереди пришедшего сегмента и его же длины. Соединение остается в
    состоянии CLOSED.
    2. Если соединение находится в каком-либо несинхронизированном состо-
    янии (LISTEN, SYN-SENT, SYN-RECEIVED), если какие-либо подтвержде-
    ния пришедшего сегмента еще не отправлены (сегмент несет неприем-
    лемое значение в поле ACK) или пришедший сегмент имеет уровень
    безопасности/закрытости не соответствующий уровню и защите данного
    соединения, то отправляется сигнал перезагрузки.
    Если наш сигнал SYN не был подтвержден, а уровень приоритета при-
    шедшего сегмента больше запрошенного уровня, то либо будет увели-
    чен местный уровень приоритета (если это приемлемо для пользовате-
    ля и системы), либо будет послан сигнал перезагрузки. Или же если
    уровень приоритета пришедшего сегмента меньше запрошенного, то об-
    работка будет продолжена далее, как если бы уровень был таким же
    (если чужая программа TCP не может повысить уровень приоритета до
    нашего, то это будет отмечено в следующем отправляемом ею сегмен-
    те, тогда и будет закрыто соединение). Если наш сигнал SYN получил
    подтверждение (возможно в пришедшем к нам сегменте), то уровень
    приоритета пришедшего сегмента должен точно соответствовать мест-
    ному уровню. Если последнее условие не выполняется, посылается
    сигнал перезагрузки.
    Если приходящий сегмент несет сигнал ACK, то сигнал перезагрузки
    будет иметь номер в очереди, соответствующий номеру сигнала ACK в
    пришедшем сегменте. В противном случае сигнал перезагрузки будет
    иметь нулевой номер очереди, а сигнал ACK — номер, равный сумме
    номера пришедшего сегмента и его же длины. Соединение не меняет
    своего состояния.
    3. Если соединение находится в синхронизированном состоянии
    (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-
    ACK, TIME-WAIT), то любой неприемлемый сегмент (не попадающий в
    окно номеров очереди, несущий неправильный номер подтверждения)
    должен приводить к появлению сегмента с пустым полем подтвержде-
    ния, содержащего текущий номер в очереди на посылку, а также под-
    тверждение, указывающее на следующий ожидаемый с этого соединения
    номер. Соединение остается в своем прежнем состоянии.
    Если пришедший сегмент имеет уровень защиты, изоляции или прио-
    ритета, не соответствующий местному уровню соединения, то отправ-
    ляется сигнал перезагрузки, а соединение переходит в состояние
    CLOSED. Сигнал перезагрузки имеет номер очереди, соответствующий
    номеру сигнала ACK в пришедшем сегменте.

    Обработка сигнала на перезагрузку
    Для всех состояний, кроме SYN-SENT, все сегменты с сигналом пере-
    загрузки (RST) проходят проверку полей SEQ. Сигнал перезагрузки приз-
    нается, если его номер очереди попадает в окно. В состоянии же SYN-
    SENT (сигнал RST получен в ответ на посылку инициирующего сигнала
    SYN), сигнал RST признается, если поле ACK подтверждает ранее сделан-
    ную посылку сигнала SYN.
    Получатель сигнала RST сперва проверяет его, и лишь потом меняет
    свое состояние. Если получатель находился в состоянии LISTEN, то он
    игнорирует сигнал. Если получатель находился в состоянии SYN-
    RECEIVED, то он возвращается вновь в состояние LISTEN. В иных случаях
    плучатель ликивдирует соединение и переходит в состояние CLOSED. Если
    получатель находтся в каком-либо ином состоянии, то он ликвидирует
    соединение и прежде чем перейти в состояние CLOSED, оповещает об этом
    своего клиента.

    3.5 Закрытие соединения
    Состояние CLOSED означает «я не имею данных для передачи». Конеч-
    но, закрытие полнодуплексного соединения является предметом множества
    интерпретаций, поскольку не очевидно, как интерпретировать в соедине-
    нии сторону, получающую информацию. Мы решили интерпретировать CLOSE
    в упрощенной манере. Клиент, находящийся в состоянии CLOSE, может все
    еще получать информацию (RECEIVE) до тех пор, пока партнер тоже не
    сообщит, что переходит в состояние CLOSE. Таким образом, клиент может
    изящно завершить работу на своем конце соединения. Программа протоко-
    ла TCP гарантированно получит все буферы с информацией, отправленные
    до того, как соединение было закрыто. Поэтому клиенту, не ждущему
    информации с соединения, следует лишь ждать сообщения об успешном
    закрытии этого соединения, что означает, что все данные получены про-
    граммой TCP, принимающей информацию. Клиенты должны сохранять уже
    закрытые ими для чтения информации соединения до тех пор, пока про-
    грамма протокола TCP не сообщит им, что такой информации больше нет.
    Особое значение имеют три случая:
    1) клиент инициирует закрытие соединения, дав команду своей программе
    протокола TCP.
    2) закрытие соединения начинается с того, что напарник посылает сюда
    управляющий сигнал FIN.
    3) оба клиента дают команду на закрытие одновременно.
    Случай 1 Местный клиент инициирует закрытие
    В этом случае создается сегмент с сигналом FIN и помещается в
    очередь сегментов, ждущих отправления. После этого программа TCP
    уже не будет принимать от этого клиента каких-либо команд на от-
    правление данных по закрытому соединению, а сама переходит в со-
    стояние FIN-WAIT-1. Тем не менее, в этом состоянии еще возможно
    получение клиентом данных с этого соединения. Все сегменты, стоя-
    щие в очереди, и сам сегмент с сигналом FIN будут в случае необхо-
    димости посылаться напарнику вновь и вновь, пока не получат своего
    подтверждения. Когда программа TCP партнера подтвердит получение
    сигнала FIN, и сама отправит сюда свой сигнал FIN, местная про-
    грамма может подтвердить получение последнего. Заметим, что про-
    грамма TCP, получающая сигнал FIN, будет подтверждать его, но не
    будет посылать своего собственного сигнала FIN до тех пор, пока ее
    клиент тоже не закроет соединения.
    Случай 2 Программа TCP получает из сети сигнал FIN.
    Если из сети приходит невостребованный сигнал FIN, то принимаю-
    щая его программа TCP может подтвердить получение такого сигнала и
    оповестить своего клиента о том, что соединение закрыто. Клиент
    ответит командой CLOSE, по которой программа TCP может после пере-
    сылки оставшихся данных послать партнеру сигнал FIN. После этого
    программа TCP ждет, пока не прийдет подтверждение на отправленный
    ею сигнал FIN, после чего она ликвидирует соединение. Если под-
    тверждения не было по истечении отведенного времени, то соединение
    ликвидируется в принудительном порядке, о чем дается сообщение
    клиенту.
    Случай 3 Оба клиента закрывают соединение одновременно.
    Одновременное закрытие соединения клиентами на обоих концах
    приводит к обмену сегментами с сигналом FIN. Когда все сегменты,
    стоящие в очереди перед сегментом с FIN, будут переданы и получат
    подтверждение, каждая программа TCP может послать подтверждение на
    полученный ею сигнал FIN. Обе программы по получении этих под-
    тверждений будут ликвидировать соединение.

    Нормальная процедура закрытия
    Рисунок 13

    Процедура одновременного закрытия соединения с обоих концов
    Рисунок 14

    3.6 Приоритет и безопасность
    Замысел этой части протокола состоит в том, что соединение может
    существовать лишь между портами, имеющими одинаковое значение без-
    опасности и закрытости, а уровень приоритета должен соответствовать
    наибольшему из запрошенных этими двумя портами значений.
    Параметры приоритета и безопасности, применяемые в протоколе TCP,
    в точности соответствуют заявленным в протоколе Internet (IP) [2]. В
    спецификации протокола TCP понятие «безопасность» должно включать
    используемые в IP параметры, которые включают собственно безопас-
    ность, закрытость, определение группы для пользователей, а также под-
    держку различных ограничений.
    Попытка соединиться с неприемлемыми значениями безопасности/ за-
    крытости или же с недостаточно малым значением приоритета должна
    отвергаться через посылку сигнала перезагрузки. Отказ в соединении по
    причине недостаточного приоритета может осуществляться только после
    получения подтверждения на сигнал SYN.
    Заметим, что модули TCP, работающие лишь с значением приоритета,
    установленным по умолчанию, будут тем не менее проверять приоритет
    пришедших сегментов и, в случае необходимости, повышать уровень прио-
    ритета, применяемый в данном конкретном соединении.
    Параметры безопасности могут быть использованы даже программами
    TCP, не поддерживающими систему безопасности (значения поля безопас-
    ности относилось бы к неклассифицируемым данным). Таким образом,
    хост-компьютеры, не поддерживающие систему безопасности, должны быть
    готовы принимать параметры безопасности, хотя сами они в посылке та-
    ких параметров не нуждаются.

    3.7 Передача данных
    Коль соединение установлено, передача данных осуществляется с по-
    мощью обмена сегментами. Т.к. сегменты могут быть потеряны в резуль-
    тате ошибок (например, ошибки в контрольной сумме) или перегрузки
    сети, то программа протокола TCP использует механизм повторной посыл-
    ки (по истечении определенного времени) с тем, чтобы убедиться в по-
    лучении каждого сегмента. В главе, посвященной номерам очередей, об-
    суждалось, как программа TCP в сегментах осуществляет проверку номе-
    ров очередей и номеров подтверждения на предмет их корректности.
    Отправитель данных с помощью значения переменной SND.NXT отслежи-
    вает следующий номер в очереди, подлежащий отправке. Получатель дан-
    ных с помощью переменной RCV.NXT отслеживает следующий номер, прибы-
    тие которого он ожидает. В переменную SND.UNA отправитель данных по-
    мещает значение самого старого номера, который был отправлен, но еще
    не получил подтверждения. Если бы поток данных моментально иссяк, а
    все отправленные данные получили подтверждение, то тогда бы все эти
    при переменные содержали одинаковое значение.
    Когда отправитель информации создает и посылает некий сегмент, он
    увеличивает значение переменной SND.NXT. Адресат по получении сегмен-
    та увеличивает значение переменной RCV.NXT и отправляет подтвержде-
    ние. Когда программа TCP, пославшая данные, получает подтверждение,
    она увеличивает значение SND.UNA. Разность в значениях этих перемен-
    ных является мерой, характеризующей задержку сегментов в сети. Вели-
    чина, на которую надо всякий раз осуществлять приращение значения
    этих переменных, является длиной поля данных в сегменте. Заметим, что
    поскольку соеднения находятся в состоянии ESTABLISHED, все сегменты,
    в дополнение к собственно данным, должны нести некую информацию о
    подтверждении ранее отправленных сегментов.
    Запрос пользователя о закрытии соединения (CLOSE) подразумевает
    использование функции проталкивания, что осуществляется с помощью
    контрольного флага FIN приходящем сегменте

    Контрольное время повторной посылки
    Вследствие непостоянства сетей, составляющих единую объединенную
    систему, и большого числа клиентов, пользующихся услугами TCP соеди-
    нений, существует необходимость в динамическом определении контроль-
    ного времени повторной посылки. В качестве иллюстрации здесь приво-
    дится одна из процедур определения этого времени.

    Пример процедуры измерения контрольного времени для повторной
    посылки сегментов
    Во-первых, измерьте время, прошедшее между посылкой октета дан-
    ных, имеющего некий определенный номер в очереди, и получение под-
    тверждения, указывающего наряду с другими и на этот номер (посыла-
    емые сегменты не обязаны соответствовать полученным сегментам).
    Измеренная временная задержка — это время обращения (Round Trip
    Time — RTT). Следующий шаг — вычисление усредненного времени обра-
    щения (Smoothed Round Trip Time — SRTT):
    SRTT = (ALPHA * RSTT) + ( (1-ALPHA) * RTT)
    Затем с помощью найденного значения определяется контрольное время
    повторной посылки (Retransmission Timeout — RTO):
    RTO = min[ UBOUND, max[ LBOUND, (BETA * SRTT) ]]
    где UBOUND — верний предел контрольного времени (например, 1 мин),
    LBOUND — нижний предел (например, 1 сек). ALPHA — фактор сглажива-
    ния (например, от 0.8 до 0.9), а BETA — фактор изменения задержки
    (например, от 1.3 до 2.0).

    Передача срочной информации
    Механизм срочной передачи протокола TCP предназначен для того,
    чтобы клиент, отправляющий данные, мог побудить получателя принять
    некую срочную информацию, а также позволить программе TCP, принимаю-
    щей данные, информировать своего клиента, когда вся имеющаяся на на-
    стоящий момент информация будет получена.
    Данный механизм позволяет помечать некую точку в потоке данных как
    конец блока срочной информации. Когда в программе TCP, принимающей
    данные, данная точка окажется впереди индикатора номера в очереди
    получения (RCV.NXT), эта программа TCP должна дать команду своему
    клиенту перейти в «срочный режим». Когда номер в очереди получения
    догонит срочный указатель в потоке данных, программа TCP должна дать
    команду клиенту прийти в «нормальный режим». Если срочный указатель
    сменит свое положение, когда клиент находится в «срочном режиме»,
    последний не узнает об этом.
    Данный метод использует поле флага срочности, котрый присутствует
    во всех передаваемых сегментах. Единица в поле контрольного флага URG
    означает, что задействовано поле срочности . Чтобы получить указатель
    этого поля в потоке данных, необходимо дополнить его номером рассмат-
    риваемого сегмента в очереди. Отсутствие флага URG означает отсут-
    ствие у отправителя непосланных срочных данных.
    При указании срочности клиент должен также послать по крайней мере
    один октет данных. Если клиент, помещающий данные, дополнительно за-
    кажет функцию проталкивания, то передача срочной информации ждущему
    ее процессу многократно ускорится.

    Управление окном
    Окно, посылаемое с каждым сегментом, указывает диапазон номаров
    очереди, которые отправитель окна (он же получатель данных) готов
    принять в настоящее время. Предполагается, что такой механизм связан
    с наличием в данный момент места в буфере данных.
    Указание окна большого размера стимулирует передачу. Но если при-
    шло большее количество данных, чем может быть принято программой TCP,
    данные будут отброшены. Это приведет к излишним пересылкам информации
    и ненужному увеличению нагрузки на сеть и программу TCP. Указание
    окна малого размера может ограничить передачу данных скоростью, кото-
    рая определяется временем путешествия по сети после каждого посыла-
    емого сегмента.
    Такие механизмы протокола позволяют программе TCP заявлять большое
    окно, но впоследствии объявлять окна намного меньшего размера и не
    принимать такое большое количество данных. Такое, так называемое,
    сокращение окна выглядит довольно обескураживающе. Принцип устойчиво-
    сти диктует, чтобы программа протокола TCP не сокращала сама окно, но
    была бы готова к таким действиям со стороны другой программы TCP.
    Программа TCP, посылающая данные, должна быть готова принять от
    клиента и передать по сети по крайней мере один октет новых данных,
    даже если окно отправления равно нулю. Программа TCP должна периоди-
    чески повторно посылать данные другой программе TCP, даже если окно
    нулевое. В случае нулевого окна рекомендуется использовать интервал
    повторной посылки в две минуты. Такие повторные посылки важны для
    того, чтобы гарантировать, что в случае, когда одна из двух программ
    TCP имеет нулевое окно, открытие этого окна будет гарантированно со-
    общено партнеру.
    Когда программа TCP, получающая данные, имеет нулевое окно, но к
    ней приходит сегмент, то эта программа должна послать подтверждение и
    указать, какой следующий номер в очереди она ожидает и какое у нее
    окно в настоящий момент (окно нулевое).
    Программа TCP пакует предназначенные к в пересылке данные в сег-
    менты, заполняющие текущее окно. Однако она не может перепаковать уже
    имеющиеся сегменты в очереди на повторную посылку. Такая перепаковка
    хоть и не обязательна, но может быть полезна.
    В соединении, имеющем односторонний поток данных, информация об
    окне будет передаваться с сегментами подтверждения, а они будут все
    иметь одинаковый номер очереди. Поэтому не будет способа восстановить
    их очередность при получении. Это не является серьезной проблемой, но
    может случайно привести к получению информации об окне из какого-
    нибудь устаревшего сообщения. Во избежание такой проблемы должен осу-
    ществляться отсев и информация об окне должна браться из сегментов,
    имеющих самый большой номер в очереди (это сегменты, чей номер под-
    тверждения больше или равен наибольшему из ранее полученных номеров).
    Процедура управления окном оказывает значительное влияние на ха-
    рактеристики коммуникаций. Дальнейшие комментарии содержат пожелания
    разработчикам.

    Пожелания по управлению окном
    Выделение очень малого окна приводит к передаче данных очень
    маленькими сегментами, тогда как лучший режим осуществляется при
    использовании сегментов большего размера.
    Чтобы избежать применения малых окон, получателю данных предла-
    гается откладывать изменение окна до тех пор, пока свободное место
    не составит X процентов от максимально возможного в памяти для
    этого соединения (где X может быть от 20 до 40).
    Другой совет, чтобы не посылать малые сегменты, состоит в том,
    чтобы отправитель не спешил с посылкой данных, пока окно не станет
    достаточно большим. Но если клиент дает команду на использование
    функции проталкивания, то данные следует немедленно отправлять,
    даже если это будет осуществляться малым сегментом.
    Заметим, что во избежание ненужных повторных пересылок не нужно
    медлить с посылкой подтверждений. Стратегия может заключаться в
    посылке подтверждения при получении сегмента малого размера (без
    обновления информации обокне), затем посылается другое другое под-
    тверждение с новой информацией об окне, если последнее расширяет-
    ся.
    Сегмент, посылаемый для проверки нулевого окна, может иницииро-
    вать разбивку передавамых данных на все более и более мелкие сег-
    менты. Если сегмент, содержащий единичный октет данных и отправ-
    ленный для проверки нулевого окна, получен, то он займет один ок-
    тет в имеющемся в данный момент окне. Если же программа TCP просто
    посылает столько данных, сколько может, всякий раз, когда окно
    ненулевое, то передаваемые данные будут разбиваться на большие и
    малые сегменты. По истечении некоторого времени случающиеся паузы
    в выделении окна получателем данны приведут к разбивке больших
    сегментов на многочисленные и уже не столь большие пары. Итак, по
    прошествии некоторого времени передача данных будет осуществляться
    преимущественно малыми сегментами.
    Предложение состоит в том, чтобы реализации протокола TCP ак-
    тивно пытались объединить малые окна в более крупые, поскольку
    механизмы управления окном стремятся ввести много малых окон в
    простейших реализациях протокола.

    3.8 Интерфейсы
    Конечно, здесь затрагиваются два интерфейса. Интерфейс клиент/
    протокол TCP и интерфейс протокол TCP/протокол нижнего уровня. Мы
    имеем более тщательно разработанную модель для первого из них. Но
    здесь не рассматривается интерфейс с модулем протокола нижнего
    уровня, поскольку это сделано в спецификации последнего. Для слу-
    чая, когда в интерфейсе нижний уровень — это протокол IP, мы лишь
    отметим некоторые из допустимых параметров, используемых протоко-
    лом TCP.

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

    TCP команды клиента
    В следующих параграфах функционально характеризуется интерфейс
    клиент/протокол TCP. Нотация вызова подобна нотации большинства
    процедур или нотации вызова функции в языках высокого уровня, од-
    нако это не означает неправомерность вызовов на обслуживание в
    виде ловушек (trap) (например SVC, UUO, EMT).
    Описанные ниже команды клиента определяют основные операции,
    которые должна выполнять программа протокола TCP для поддержки
    коммуникаций между процессами. Отдельные реализации протокола дол-
    жны определять свой собственный конкретный формат и могут обеспе-
    чить комбинации или наборы базовых функций для одиночных вызовов.
    В частности, некоторые реализации могут автоматически открывать
    соединение (OPEN), как только по нему клиент дает первую команду
    посылки (SEND) или получения (RECEIVE).
    Для того, чтобы поддерживать интерфейс между процессами, про-
    грамма TCP должна не только принимать команды, но и возвращать
    некую информацию обслуживаемым процессам. Эта информация состоит
    из:
    a) общей информации о соединении (т.е. прерываний, закрытия соеди-
    нения партнером, управление связью с непредопределенным чужим
    сокетом).
    b) ответа на конкретные команды клиента, указыващего на успешность
    действий или различные типы ошибок.

    Команда открытия
    Формат
    OPEN (свой порт, чужой порт, активный/пассивный [,контрольное
    время] [,приоритет] [,безопасность] [,опции]) -> местное имя
    для соединения
    Мы полагаем, что местная программа TCP несет ответственность
    за идентификацию обслуживаемых процессов и будет проверять при-
    надлежность процессов, желающих обратиться к данному соедине-
    нию. В зависимости от реализации протокола TCP, либо программа
    TCP, либо протокол более нижнего уровня (например, IP) будут
    создавать адрес отправителя, а точнее, идентификаторы для ло-
    кальной сети и интерфейса TCP. Такая предусмотрительность явля-
    ется результатом учета безопасности, а именно того, чтобы ни
    одна из программ TCP не смогла замаскироваться под какую-либо
    другую, и т.д. Аналогичным образом ни один процесс не должен
    замаскироваться под другой без того, чтобы не иметь конфликт с
    протоколом TCP.
    Если флаг активный/пассивный установлен в состояние
    «пассивный», то это означает, что дан запрос на «прослушивание»
    (LISTEN) сигнала установления соединения извне. Пассивное от-
    крытие может дать либо полное описание чужого сокета, с которым
    должно быть установлено данное соединение, либо не давать ника-
    ких указаний по поводу чужого сокета, который должен дать сиг-
    нал. Пассивное открытие соединения с четко определенным чужим
    сокетом может стать в любой момент активным открытым соединени-
    ем, если будет дана команда на посылку данных (SEND). Создается
    блок управления передачей (TCB) и частично заполняется информа-
    цией, полученной от параметров команды OPEN.
    В случае команды на активное открытие (OPEN) протокол TCP
    немедленно запустит процедуру синхронизации (точнее, установле-
    ния) соединения.
    Контрольное время, если оно присутствует среди параметров
    функции, позволяет клиенту установить контрольное время ликви-
    дации для всех данных, посылаемых от имени протокола TCP. Если
    в течение этого контрольного времени какие-либо данные не до-
    стигли своего адресата, программа TCP ликвидирует соединение. В
    настоящее время общепринятым контрольным временем являются пять
    минут.
    Программа протокола TCP или какая-либо компонента операцион-
    ной системы будет проверять права клиента на открытие соедине-
    ния, имеющего заказанные клиентом приоритет и безопасность. Ес-
    ли приоритет или безопасность/закрытость не указаны, должен ис-
    пользоваться вызов CALL, использующий значения этих параметров,
    принятые по умолчанию.
    Программа протокола TCP будет воспринимать приходящие запро-
    сы только если они имеют тот же самый уровень безопасности/за-
    крытости. Приоритет запросов должен быть равен или превышать
    приоритет, указанный в команда открытия (OPEN).
    Если приоритет для соединения оказывается больше, чем значе-
    ние, указанное в запросе CALL, то берется приоритет из пришед-
    шего запроса и становится постоянной характеристикой соедине-
    ния. Разработчики могут перепоручить клиентам ведение перегово-
    ров по поводу установления приоритета соединения. Например,
    клиент может указывать приоритет, который должен быть присвоен
    соединению. В другом примере, любая попытка повысить приоритет
    соединения должна получить санкцию клиента.
    По завершении операции протокол TCP возвращает клиенту мест-
    ное название для открытого соединения. Впоследствии имя соеди-
    нения может использоваться в качестве короткого обозначения для
    соединения, идентифицируемого парой .

    Команда на посылку данных
    Формат
    SEND (местное название соединения, адрес буфера, количество
    байтов с данными, флаг проталкивания, флаг срочности
    [контрольное время])
    Данная команда приводит к тому, что данные, содержащиеся в
    указанном клиентом буфере, передаются на указанное соединение.
    Если соединение не было к этому времени открытым, команда SEND
    является ошибочной. Некоторые реализации протокола TCP могут
    позволить клиентам начинать общение сразу с команды SEND. При
    этом команда OPEN должна осуществляться автоматически. Если
    процесс, давший команду на посылку, не уполномочен использовать
    данное соединение, команда возвращает клиенту ошибку.
    Если установлен флаг проталкивания (PUSH), то данные должны
    быть переданы по назначению с соответствующим сообщением, а бит
    PUSH должен быть установлен на последний из созданных в буфере
    TCP сегментов. Если флаг PUSH не выставлен, то имеющиеся данные
    могут быть объединены с данными из посылаемых следом датаграмм.
    Кроме того, хост-компьютер, посылающий данные, может получить
    сообщение от шлюза об истечении контрольного времени.
    Если хост-компьютер, осуществляющий сборку фрагментов дата-
    граммы, не может в отведенное для этого время завершить свою
    работу из-за получения ошибочного фрагмента, то он выкидывает
    датаграмму и может послать сообщение об превышении контрольного
    времени. Этого сообщения не следует посылать вовсе, если не был
    получен нулевой фрагмент датаграммы.
    От шлюза приходит сообщение с кодом 0 ,а от хост-компьютера
    — сообщение с кодом 1.

    Поля IP протокола:
    Адрес получателя
    Компьютерная сеть и адрес отправителя заносятся в дата-
    грамму, возвращающую ошибку. Клиенты могут использовать ко-
    манду STATUS для определения состояния соединения. В некото-
    рых реализациях протокол TCP может оповещать клиента, когда
    выходит на связь незаказанный сокет.
    Если было указано контрольное время, то в этом соединении
    его текущее значение, заданное клиентом, будет изменено.
    В простейших реализациях команда SEND не предает управле-
    ние обратно вызвавшей ее программе, пока не будет завершена
    передача или пока не будет превышено контрольное время. Од-
    нако, такой простой метод может приводить к блокировке (на-
    пример, когда обе стороны на концах соединения пытаются
    сперва выполнить команду SEND, а лишь потом — RECEIVE) и
    плохим эксплуатационным характеристикам. Поэтому такой под-
    ход не рекомендуется использовать. В более сложной реализа-
    ции возврат из функции SEND осуществляется незамедлительно,
    что позволяет процессу выполняться параллельно с вводом/вы-
    водом в компьютерную сеть. И даже более того — позволяет вы-
    полнять одновременно несколько команд SEND. Множественные
    команды SEND обрабатываются по принципу «первый пришел —
    первый обслужен», поэтому протокол TCP будет иметь очередь,
    которая не может быть обслужена мгновенно.
    Косвенным образом мы предположили асинхронность интерфей-
    са с клиентом, при которой команда SEND вызывает появление
    особого рода сигнала или псевдо-прерывания изобслуживающей
    программы TCP. Альтернатива состоит в немедленном возврате
    из команды. Например, команды SEND могут возвращать немед-
    ленно подтверждение от местной системы, даже если посланный
    сегмент не получил подтверждения от чужой программы TCP. Мы
    оптимистически относимся к возможному успеху этой операции.
    Если мы ошибаемся, то соединение в любом случае будет разор-
    вано по истечении контрольного времени. В реализациях прото-
    кола TCP такого типа (синхронных) будет все равно оставаться
    некоторые асинхронные сигналы, одноко они будут относиться к
    самому соединению, а не к конкретным сегментам или буферам.
    Чтобы процесс мог различать сообщения об ошибках и успеш-
    ное рапорты от различных команд SEND, может оказаться удоб-
    ным возвращать в ответ на запрос SEND адрес буфера наряду с
    кодированным ответом. Сигналы между клиентом и протоколом
    TCP обсуждаются ниже и определяют ту информацию, которую
    следует возвращать отправившему команду процессу.

    Команда получения
    Формат
    RECEIVE (местное имя соединения, адрес буфера, счетчик байт) ->
    счетчик байт, флаг срочности, флаг проталкивания
    Данная команда размещает получаемую информацию в буфере,
    связанном с конкретным соединением. Если команде не предшеству-
    ет команда OPEN или если процесс, осуществляющий вызов, не
    уполномочен на использование данного соединения, то возвращает-
    ся ошибка.
    В простейшей реализации протокола управление не должно пере-
    даваться осуществившей вызов программе до тех пор, пока либо не
    будет заполнен буфер, либо не произойдет какая-либо ошибка. Од-
    нако данная схема в значительной мере подвержена блокировкам.
    Более сложная реализация могла бы позволить за раз выдвигать
    несколько команд RECEIVE. Эти запросы будут выполняться по мере
    поступления сегментов с данными. Такая стратегия позволяет уве-
    личить пропускную способность за счет применения более развитой
    схемы (возможно, асинхронной), а также оповещения программы о
    том, что получен сигнал проталкивания PUSH или заполнен буфер.
    Если получено достаточное количество данных, чтобы заполнить
    буфер до того, как получен сигнал проталкивания PUSH, то в от-
    вет на RECEIVE не будет установлен флаг PUSH. Буфер будет со-
    держать столько данных, насколько позволяет его емкость. Если
    сигнал PUSH обнаружен до того, как буфер заполнился, то буфер
    будет возвращен заполненным частично и с сигналом PUSH.
    Если обнаружены срочные данные, то сразу же по их прибытии
    клиент будет оповещен сигналом от программы протокола TCP. Кли-
    ент, получающий данные, должен по этому сигналу перейти в
    «срочный режим». Если флаг срочности URGENT установлен, то до-
    полнительные срочные данные останутся неполученными. Если флаг
    URGENT сброшен, то данный запрос на получение RECEIVE возвратит
    все срочные данные и клиент может освободиться от «срочного ре-
    жима». Заметим, что данные, следующие за указателем срочности
    (несрочные данные) не могут быть доставлены к клиенту в одном и
    том же буфере с предыдущими срочными данными, если сам клиент
    не определил четко границу.
    Чтобы проводить различие между несколькими сделанными коман-
    дами на получение RECEIVED и следить за заполнением буферов,
    код, возвращаемый клиенту сопровождается как указателем на бу-
    фер, так и количеством действительно полученных данных.
    Другие реализации команды RECEIVE могут сами выделять буфер
    для размещения получаемых данных или же программа протокола TCP
    может одновременно с клиентом пользоваться циклическим буфером.

    Команда закрытия соединения
    Формат
    CLOSE (локальное имя соединения)
    Данная команда приводит к закрытию указанного соединения.
    Если соединение не открыто или отдавший команду процесс не
    уполномочен использовать данное соединение, то возвращается со-
    общение об ошибке. Предполагается, что закрытие соединения бу-
    дет медлительной операцией в том смысле, что оставшиеся команды
    посылки SEND будут еще некоторое время передавать данные (и да-
    же, в случае необходимости, делать это повторно), насколько это
    позволит управление потоком, и не будет выполнена заказанная
    работа. Таким образом, можно будет сделать несколько команд по-
    сылки SEND, а затем закрыть соединение командой CLOSE, будучи
    уверенным, что отправленные данные достигнут адресата. Очевид-
    но, что клиенты должны продолжать давать команды получения дан-
    ных с уже закрытых соединений, поскольку чужая программа будет
    еще пытаться переслать оставшиеся у нее данные. Итак, команду
    CLOSE следует интерпретировать как «у меня нет больше данных
    для пересылки», а не как «я больше не хочу ничего получать».
    Может случиться (если протокол на уровне клиента не продуман до
    конца), что сторона, закрывающая соединение, не сможет изба-
    виться от всех своих данных до истечения контрольного времени.
    В этом случае команда CLOSE транслируется в ABORT, и программа
    TCP отказывается от соединения.
    Клиент может дать команду CLOSE в любой момент по своему
    собственному усмотрению, а также в ответ на различные сообщения
    от протокола TCP (например, когда выполнено закрытие соединения
    с чужой стороны, превышено контрольное время передачи, адресат
    недоступен).
    Поскольку закрытие соединения требует общения с чужой про-
    граммой TCP, то соединения могут пребывать в закрытом состоянии
    короткое время. Попытки повторно открыть соединение до того,
    как программа TCP отреагирует на команду CLOSE, приведет к воз-
    врату на вызов сообщения об ошибке.
    Команда закрытия предполагает выполнение операции проталки-
    вания данных через соединение.

    Команда определения статуса соединения
    Формат
    STATUS (местное имя соединения) -> информация о статусе
    Это команда клиента, зависящая от конкретной реализации. Она
    должна выполняться без опасных последствий для системы. Возвра-
    щаемая клиенту информация обычно получается из блока TCB, свя-
    занного с данным соединением, Данная команда возвращает блок
    данных с информацией о
    — местном сокете
    — чужом сокете
    — местном имени соединения
    — окне получения
    — окне отправления
    — статусе соединения
    — количестве буферов, ждущих подтверждения
    — количестве буферов, ожидающих получения данных
    — статусе срочности
    — приоритете
    — безопасности/закрытости
    — контрольном времени пересылки
    В зависимости от состояния соединения или от особенностей
    реализации протокола, часть указанной информации может быть не-
    доступна или не имеет смысла. Если процесс, осуществивший вы-
    зов, не имеет прав на использование данного соединения, то воз-
    вращается сообщение об ошибке. Такой подход не позволяет не
    имеющим полномочий процессам получать информацию о соединении.

    Команда ликвидации соединения
    Формат
    ABORT (местное имя соединения)
    Выполнение данной команды приводит к ликвидации всех неза-
    конченных операций посылки и получения данных. Блок TCB ликви-
    дируется, а также должно быть послано специальное сообщение
    RESET программе TCP на другом конце соединения. В зависимости
    от реализации протокола, клиенты могут получать сообщение о
    ликвидации в ответ на каждый оставшийся невыполненным запрос о
    посылке или получении данных. Или же клиенты вместо этого могут
    просто получить подтверждение команды ABORT.

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

    Интерфейс программы TCP с протоколом более низкого уровня
    Программа протокола TCP для реальной посылки информации по се-
    ти, а также для ее получения делает запросы к модулю протокола
    нижнего уровня. Одним из примеров такой реализации является систе-
    ма ARPA Internetwork, где модулем нижнего уровня является Internet
    протокол (IP) [2].
    Если протоколом более низкого уровня является IP, то он в ка-
    честве аргументов вызова запрашивает требуемый тип сервиса и время
    жизни данных в сети. Программа протокола TCP использует следующие
    значения для упомянутых параметров:
    Тип сервиса = приоритет: обычный, задержка: нормальная,
    пропускная способность: нормальная, надежность: нормальная,
    т.е. 00000000
    Время жизни = одна минута, или 00111100
    Заметим, что принято максимальное время жизни сегмента в две
    минуты. Здесь мы явным образом определяем, что сегмент должен быть
    ликвидирован, если он в течении одной минуты не достигает адресата
    в системе Internet.
    Если ниже расположен протокол IP (или какой-либо другой прото-
    кол с теми же функциями) и применяется процедура маршрутизации, то
    интерфейс должен допускать передачу информации о маршруте. Это
    особенно важно, поскольку адреса отправителя и получателя, учиты-
    ваемые в контрольной сумме TCP протокола, будут соответствовать
    действительному отправителю данных и самому последнему адресату.
    Важно также сохранять обратный маршрут для ответов на запросы со-
    стояния.
    Любой протокол нижнего уровня будет обязан предоставить адрес
    отправителя, адрес получателя, поля протокола, некую процедуру
    определения «длины TCP сообщения», необходимую как для сервистных
    функций протокола IP, так и для проверки контрольной суммы в самом
    протоколе TCP.

    3.9 Обработка событий
    Обработка, описанная в данной главе, является лишь примером
    одной из возможных реализаций протокола. Иные реализации могут
    иметь несколько иные процедуры обработки, однако они должны отли-
    чаться от описанных в данной главе лишь в деталях, но никак не по
    существу.
    Деятельность программы протокола TCP можно рассматривать как
    реагирование на события. Эти происходящие события можно разбивать
    на три категории: запросы клиентов, прибытие сегментов, истечение
    контрольного времени. Данная глава описывает деятельность в прото-
    коле TCP в ответ на каждое их этих событий. Во многих случаях не-
    обходимая обработка зависит от состояния соединения. События, ко-
    торые могут произойти:
    Команды клиента
    — на открытие соединения
    — на посылку данных
    — на получение данных
    — на закрытие соединения
    — на ликвидацию соединения
    — на определение статуса соединения
    Получения сегментов
    Истечение контрольного времени
    — для действий клиента
    — для повторной посылки
    — в состоянии ожидания
    Модель интерфейса TCP и клиента состоит в том, что команды кли-
    ента выполняются немедленно, а вероятный отложенный отчет предо-
    ставляется через механизм событий или псевдопрерываний. В дальней-
    шем описании понятие «сигнал» может обозначать некое основание для
    посылки отложенного отчета.
    Сообщение об ошибках пердоставляется в виде текстовых строк.
    Например, команды клиента, адресованные к несуществующим соедине-
    ниям, получат сообщение «error: connection not open».
    Пожалуйста учтите, что в дальнейшем вся арифметика для номеров
    очереди, номеров подтверждения, окон и т.д. осуществляется по мо-
    дулю 2**32, что соответствует размеру множества номеров очередей.
    Заметим также, что «= . Установить переменную SND.UNA в ISS, а
    SND.NXT — в ISS+1. Перейти в состояние SYN-SENT. Вернуть
    управление процессу, вызвавшему рассматриваемую команду.
    Если сделавший запрос клиент не получил доступа к указан-
    ному в запросе сокету, то вернуть сообщение «error:
    connection illegal for this process». Если для создания но-
    вого соединения нет места в памяти компьютера, то вернуть
    сообщение «error: insufficient resources».
    Состояние LISTEN
    Если происходит активизация и указан чужой сокет, то сме-
    нить состояние соединения с пассивного на активный, выбрать
    ISS. Послать сегмент с сигналом SYN, занести в SND.UNA зна-
    чение ISS, а в SND.NXT — ISS+1. Перейти в SYN-SEND состо-
    яние. Данные, указанные в команде SEND, могут быть посланы в
    том же сегменте с сигналом SYN, или же могут быть помещены в
    очередь на передачу, которая может быть осуществлена после
    перехода в ESTABLISHED состояние. Если в команде сделан за-
    прос на применение бита срочности, то в результате ее выпол-
    нения должны быть посланы сегменты данных. Если в очереди
    заказов на пересылку нет места, то в результате будет полу-
    чен ответ «error: insufficient resources». Если чужой сокет
    не указан, то вернуть сообщение «error: foreign socket
    unspecified»
    Состояния
    SYN-SENT
    SYN-RECEIVED
    ESTABLISHED
    FIN-WAIT-1
    FIN-WAIT-2
    CLOSE-WAIT
    CLOSING
    LAST-ACK
    TIME-WAIT
    возвращают в ответ на команду открытия сообщение «error:
    connection already exist»

    Запрос SEND
    Состояние CLOSED (например, нет блока TCB)
    Если клиент не имеет доступа к такому соединению, то вер-
    нуть сообщение «error: connection illegal for this process».
    В противном случае вернуть «error: connection does not
    exist».
    Состояние LISTEN
    Если указан чужой сокет, то сменить состояние соединения
    с пассивного на активный, выбрать номер ISS. Послать сегмент
    с сигналом SYN, установить SND.UNA в ISS, а SND.NXT — в
    ISS+1. Установить новое состояние SYN-SENT. Данные из вызова
    SEND могут быть посланы вместе с сигналом SYN, а могут быть
    помещены в очередь и отправлены уже после установления
    ESTABLISHED состояния. Если в команде дан запрос на примене-
    ние бита срочности, то он должен быть передан вместе с сег-
    ментом данных, возникающим при выполнении этой команды. Если
    в очереди нет места для запроса, то вернуть сообщение
    «error: insufficient resources». Если чужой сокет не указан,
    то вернуть «error: foreign socket unspecified».
    Состояние SYN-SENT
    Состояние SYN-RECEIVED
    Поместить данные в очередь с тем, чтобы отправить после
    установления ESTABLISHED состояния. Если в очереди нет мес-
    та, то вернуть сообщение «error: insufficient resources».
    Состояние ESTABLISHED
    Состояние CLOSE-WAIT
    Сегментировать буфер данных и переслать его с ответным
    подтверждением (значение подтверждения = RCV.NXT). Если для
    размещения этого буфера недостаточно места в памяти, то
    просто вернуть сообщение «error: insufficient resources».
    Если установлен флаг срочности, то занести в SND.UP зна-
    чение SND.NXT-1 и установить указатель срочности на уходящие
    сегменты.
    Состояния
    FIN-WAIT-1
    FIN-WAIT-2
    CLOSING
    LAST-ACK
    TIME-WAIT
    Вернуть сообщение «error: connection closing» и не выпол-
    нять запрос клиента.

    Запрос RECEIVE
    Состояние CLOSED (например, отсутствует блок TCB)
    Если клиент не имеет доступа к такому соединению, вернуть
    сообщение «error: connection illegal for this process». В
    противном случае вернуть сообщение «error: connection does
    not exist».
    Состояния
    LISTEN
    SYN-SENT
    SYN-RECEIVED
    Поместить запрос в очередь на обслуживание после установ-
    ления ESTABISHED состояния. Если в очереди для этого нет
    места, вернуть сообщение «error: insufficient resources».
    Состояния
    ESTABLISHED
    FIN-WAIT-1
    FIN-WAIT-2
    Если в пришедших сегментах недостаточно данных для выпол-
    нения данного запроса, поместить последний в очередь на об-
    служивание. Если же в очереди нет места для размещения за-
    проса RECEIVE, вернуть сообщение «error: insufficient
    resources».
    Собрать данные из приходящих сегментов в буфере получе-
    ния, а затем передать их клиенту. Установить флаг
    «обнаружено проталкивание» (PUSH), если это имеет место.
    Если данным, передаваемым в настоящий момент клиенту,
    предшествовал RCV.UP, то оповестить клиента о присутствии
    срочных данных. Когда протокол TCP берет на себя ответствен-
    ность за получение клиентом данных, то это фактически озна-
    чает обмен информацией с отправителем в виде подтверждений.
    Формирование такого подтверждения обсуждается ниже при рас-
    смотрении алгоритма обработки приходящего сегмента.
    Состояние CLOSE-WAIT
    Поскольку партнер на другом конце соединения уже послал
    сигнал FIN, то команды RECEIVE должны получать данные, уже
    имеющиеся в системе, а не только те, которые уже переданы
    клиенту. Если в системе больше нет текста, ждущего своего
    запроса RECIVE, то передать клиенту сообщение «error
    connection closing». В противном случае использовать для
    удовлетворения запроса RECEIVE любую имеющуюся информацию.
    Состояния
    CLOSING
    LAST-ACK
    TIME-WAIT
    Вернуть сообщение «error connection closing».

    Запрос CLOSE
    Состояние CLOSED (например, нет блока TCB)
    Если клиент не имеет доступа к такому соединению, вернуть
    сообщение «error: connection illegal for this process». В
    противном случае вернуть сообщение «error: connection does
    not exist».
    Состояние LISTEN
    Любые остающиеся неудовлетворенными запросы RECEIVE будут
    завершены с сообщением «error: closing». Стереть блок TCB,
    перейти в CLOSED состояние и вернуть управление клиенту.
    Состояние SYN-SENT
    Стереть блок TCB и вернуть сообщение «error closing» для
    любых еще остающихся в очередях запросов SEND или RECEIVE.
    Состояние SYN-RECEIVED
    Если не сделано каких-либо запросов SEND и нет данных,
    ожидающих отправки, то сформировать FIN сегмент и послать
    его, а затем перейти в FIN-WAIT-1 состояние. В противном
    случае поместить данные в очередь для рассмотрения после
    установления ESTABLISHED состояния.
    Состояние ESTABLISHED
    Поместить запрос в очередь в ожидании, когда все данные
    предшествующих команд будут сегментированы. Тогда сформиро-
    вать FIN сегмент и отправить его партнеру. В любом случае
    перейти в FIN-WAIT-1 состояние.
    Состояние FIN-WAIT-1
    Cостояние FIN-WAIT-2
    Строго говоря, такая ситуация является ошибочной и должна
    привести к получению клиентом сообщения «error: connection
    closing». Однако может быть приемлемым также ответ «Ok»,
    пока не отправлен второй FIN (хотя первый FIN может быть
    отправлен повторно).
    Состояние CLOSE-WAIT
    Поместить этот запрос в очередь, пока все предшествующие
    запросы SEND не будут помещены в сегменты. Затем послать
    сегмент с сигналом FIN, перейти в CLOSING состояние.
    Состояния
    CLOSING
    LAST-ACK
    TIME-WAIT
    Возвратить сообщение «error: connection closing».

    Запрос ABORT
    Состояние CLOSED (например, нет блока TCB)
    Если клиент не имеет доступа к такому соединению, вернуть
    сообщение «error: connection illegal for this process». В
    противном случае вернуть сообщение «error: connection does
    not exist».
    Состояние LISTEN
    Любые остающиеся запросы RECEIVED должны завершиться с
    возвратом сообщения «error: connection reset». Стереть блок
    TCB, перейти в состояние CLOSED, вернуть управление програм-
    ме клиента.
    Состояние SYN-SENT
    Все находящиеся в очереди запросы SEND и RECEIVE должны
    получить сообщение «connection reset», стереть блок TCB,
    перейти в состояние CLOSED, вернуть управление клиенту.
    Состояния
    SYN-RECEIVED
    ESTABLISHED
    FIN-WAIT-1
    FIN-WAIT-2
    CLOSE-WAIT
    Послать сегмент перезагрузки

    Все находящиеся в очереди запросы SEND и RECEIVED должны
    получить сообщение «connection reset». Все сегменты, находя-
    щиеся в очереди на передачу (за исключением только что сфор-
    мированного сигнала RST) и в очереди на повторную пересылку
    должны быть ликвидированы. Стереть блок TCB, перейти в
    CLOSED состояние, вернуть управление клиенту.
    Состояния
    CLOSING
    LAST-ACK
    TIME-WAIT
    Вернуть сообщение «ok» и стереть блок TCB, перейти в со-
    стояние CLOSED, вернуть управление клиенту.

    Запрос STATUS
    Состояние CLOSED (например, нет блока TCB)
    Если клиент не имеет доступа у такому соединению, то воз-
    вратить сообщение «error: connection illegal for this
    process». В противном случае вернуть «error: connection does
    not exist».
    Состояние LISTEN
    Вернуть сообщение «state=LISTEN» и указатель на блок TCB.
    Состояние SYN-SENT
    Вернуть сообщение «state=SYN-SENT» и указатель на блок TCB.
    Состояние SYN-RECEIVED
    Вернуть сообщение «state=SYNRECEIVED» и указатель на болк
    TCB.
    Состояние ESTABLISHED
    Вернуть сообщение «state=ESTABLISHED» и указатель на блок
    TCB.
    Состояние FIN-WAIT-1
    Вернуть сообщение «state=FIN-WAIT-1» и указатель на блок
    TCB.
    Состояние FIN-WAIT-2
    Вернуть сообщение «state=FIN-WAIT-2» и указатель на блок
    TCB.
    Состояние CLOSE-WAIT
    Вернуть сообщение «state=CLOSE-WAIT» и указатель на блок
    TCB.
    Состояние CLOSING
    Вернуть сообщение «state=CLOSING» и указатель на блок TCB.
    Состояние LAST-ACK
    Вернуть сообщение «state=LAST-ACK» и указатель на блок TCB.
    Состояние TIME-WAIT
    Вернуть сообщение «state=TIME-WAIT» и указатель на блок TCB.

    Истечение контрольного времени для клиента
    Если истекло контрольного время, то в каком бы состоянии не
    находилась программа, убрать все очереди, дать клиенту общий
    сигнал «error: connection aborted due to user timeout», такой
    же сигнал дать всем ждущим обработки запросам, ликвидировать
    блок TCB, перейти в состояние CLOSED, вернуть управление прер-
    ванной программе.
    Истечение контрольного времени для повторной посылки
    В каком бы состоянии не находилась программа, если для сег-
    мента в очереди на повторную посылку истекло контрольное время,
    послать этот сегмент еще раз, но уже вне очереди, произвести
    вновь инициализацию таймера повторной посылки, вернуть управле-
    ние прерванной программе.
    Истечение контрольного времени для состояния TIME-WAIT
    Если истекло контрольное время для состояния TIME-WAIT, то
    ликвидировать соединение и блок TCB, перейти в состояние
    CLOSED, вернуть управление прерванной программе.

    Словарь
    1822
    BBN Report 1822, «The Specification of the Interconnection of a
    Host and an IMP». Спецификация интерфейса между хост-компьюте-
    ром и сетью ARPANET.
    ACK
    Контрольный бит (подтверждения), не занимающий какого-либо мес-
    та в очереди. Бит информирует о том, что поле подтверждения в
    данном сегменте определяет номер очереди, который хочет полу-
    чить программа протокола TCP, пославшая данный сегмент. Это
    означает подтверждение факта получения всех предшествующих сег-
    ментов в очереди.
    ARPANET сообщение
    Единица посылки между хост-компьютером и IMP в сети ARPANET.
    Максимальный размер такой единицы около 1012 октетов (8096
    бит).
    ARPANET пакет
    Единица посылки между разными IMP внутри сети ARPANET. Макси-
    мальный размер такой единицы около 126 октетов (1008 бит).
    Соединение
    Логический путь для коммуникаций, определяемый парой сокетов.
    Датаграмма
    Сообщение, посылаемое через компьютерную коммуникационную си-
    стему с коммуникацией пакетов.
    Адрес получателя
    Адрес получателя — это обычно идентификаторы сети и хост-ком-
    пьютера
    FIN
    Контрольный бит (конечный), занимающий одно место в очереди и
    указывающий на то, что программа протокола TCP не будет более
    посылать данные или какие-либо команды, под которые следует в
    очереди отводить место.
    Фрагмент
    Часть логической единицы данных. В частности фрагмент Internet
    являются частью Internet датаграммы.
    FTP
    Протокол передачи файлов
    Заголовок
    Контрольная информация в начале сообщения, сегмента, фрагмента,
    пакета или блока данных
    хост-компьютер
    Просто компьютер. В частности, он является отправителем и полу-
    чателем сообщений с точки зрения коммуникационной сети.
    Идентификация
    Поле Internet протокола. Значение этого поля назначает отправи-
    тель для идентификации с тем, чтобы осуществлять сборку фраг-
    ментов датаграммы.
    IMP
    Процессор интерфейсных сообщений, переключатель пакетов в сети
    APRANET.
    Internet адрес
    Адрес отправителя или получателя на уровне хоста
    Internet датаграмма
    Блок данных, передаваемый между модулем протокола Internet и
    программой вышестоящего протокола, снабженное Internet заголов-
    ком.
    Internet фрагменты
    Часть данных из Internet датаграммы, которая обзавелась соб-
    ственным Internet заголовком.
    IP
    протокол Internet
    IRS
    Первоначальный номер в очереди получения. Первый номер очереди,
    который использует программа протокола TCP при посылке данных
    через соединение.
    ISN
    Первоначальный номер очереди. Первый номер, используемый соеди-
    нением (либо ISS либо IRS). Определяется процедурой выбора,
    использующей таймер.
    ISS
    Первоначальный номер в очереди посылки. Первый номер очереди,
    используемый программой протокола TCP при посылке данных через
    соединение.
    leader
    Некая контрольная информация в начале сообщения или блока дан-
    ных. В частности, в сети ARPANET контрольная информация о
    ARPANET сообщении записана в формате хост-IMP интерфейса.
    Остающаяся очередь
    Это следующий номер в очереди, который должен быть подтвержден
    программой TCP, получающей данные (или иначе — наименьший номер
    в очереди, еще не получивший в данный момент своего подтвержде-
    ния). Иногда на него ссылаются как на левый край окна посылки.
    Местный пакет
    Блок данных, передаваемый в местной сети
    Модуль
    Реализация, обычно программая, какого-либо протокола или иной
    процедуры.
    MSL
    Максимальное время жизни сегмента. Время, в течении которого
    TCP сегмент может существовать в системе объединенных сетей.
    Примерно оценивается в 2 минуты.
    Октет
    Байт, состоящий из восьми битов
    Опции
    Поле опций может содержать несколько опций, каждая опция может
    иметь длину в несколько октетов. В основном, опции используются
    для тестирования различных ситуаций. Например, опции могут нес-
    ти временной штамп. Поля с опциями могут иметь оба протокола
    Internet и TCP.
    Пакет
    Пакет данных, имеющий заголовок, который в свою очередь может
    быть логически завершенным, а может и не быть. Чаще это означа-
    ет физическую упаковку данных, нежели логическую.
    Порт
    Часть сокета, указывающая логический канал ввода или вывода для
    процесса, имеющего дело с данными.
    Процесс
    Некая использующаяся программа. Отправитель или получатель дан-
    ных с точки зрения протокола TCP или иных фрагментов уровня
    хост-хост.
    PUSH
    Контрольный бит, который не требует места в очереди и указывает
    на то, что данный сегмент содержит данные, которые следует
    «протолкнуть» к клиенту-адресату.
    RCV.NXT
    Следующий номер в очереди получения
    RCV.UP
    Срочный указатель для получения
    RCV.WND
    Окно получения
    Следующий номер в очереди получения
    Это следующий номер в очереди, который хочет получить местная
    программа протокола TCP
    Окно получения
    Это понятие характеризует номера в очереди, которые должна по-
    лучить местная программа протокола TCP. Таким образом, местная
    программа TCP считает, что сегменты, попадающие в диапазон от
    RCV.NXT до RCV.NXT+RCV.WND-1, несут данные и команды управле-
    ния, которые следует принимать во внимание. Сегменты, чьи номе-
    ра в очереди ни коим образом не попадают в этот диапазон, вос-
    принимаются как дубликаты и ликвидируются.
    RST
    Контрольный бит (бит перезагрузки), который не занимает места в
    очереди и указывает, что получатель этого бита должен ликвиди-
    ровать соединение без каких-либо дополнительных действий. Полу-
    чатель может, основываясь на анализе номера очереди и поля под-
    тверждения в сегменте, принесшем данный сегмент, решить, следу-
    ет ли выполнять операцию перезагрузки или же следует проигнори-
    ровать эту команду. Ни в коем случае получатель сегмента с би-
    том RST не должен давать в ответ ту же команду RST.
    RTP
    Протокол реального времени. Протокол для передачи критической
    информации между хост-компьютерами.
    SEG.ACK
    Подтверждение сегмента
    SEG.LEN
    Длина сегмента
    SEG.PRC
    Значение приоритета в сегменте
    SEG.SEQ
    Номер очереди для сегмента
    SEG.UP
    Поле срочного указателя для сегмента
    SEG.WND
    Поле окна в сегменте
    Сегмент
    Логический блок данных. В частности, сегмент TCP является бло-
    ком данных, который передается между парой TCP модулей.
    Подтверждение сегмента
    Номер для очереди в поле подтверждения в пришедшем сегменте
    Длина сегмента
    Место в очереди, которое занимают данные этого сегмента (с уче-
    том также всех команд, под которые тоже отводится место в оче-
    реди).
    Номер сегмента в очереди
    Значение в поле номера у пришедшего сегмента
    Номер в очереди отправления
    Следующий номер очереди для местной программы протокола TCP,
    отправляющей данные и использующей эти номера для управления
    соединением. Первоначальный номер очереди (ISN) выбирается про-
    цедурой инициализации, а затем увеличивается на единицу с пере-
    дачей по сети каждого октета данных или некоторой команды.
    Окно посылки
    Окно представляет собой набор номеров из очереди, которые жела-
    ет получить чужая программа протокола TCP. Информация о грани-
    цах этого окна берется из сегментов, пришедших от чужой про-
    граммы TCP, получающей данные. Программе протокола TCP дозволя-
    ется посылать данные с номерами от SND.NXT до SND.UNA+SND.WND-1
    (конечно, это подразумевает повторную посылку тех данных, чьи
    номера лежат между SND.UNA и SND.NXT).
    SND.NXT
    Очередь на посылку
    SND.UNA
    Очередь еще не посланных данных
    SND.UP
    Срочный указатель в очереди на посылку
    SND.WL1
    Номер очереди сегмента в последнем обновленном окне
    SND.WL2
    Номер подтверждения сегмента в последнем обновленном окне
    SND.WND
    Окно посылки
    Сокет
    Адрес, который особым образом включает в себя идентификатор
    порта. А именно, он включает связь Internet адреса с TCP портом
    Адрес отправителя
    Адрес отправления, обычно состоящий из идентификаторов сети и
    хост-компьютера.
    SYN
    Контрльный бит в приходящем сегменте, который занимает одно
    место в очереди и используется для инициализации соединения,
    для указания, где начинается отсчет номеров очереди.
    TCB
    Контрольный блок для передачи, некая структура данных, где за-
    писан статус соединения.
    TCB.PRC
    Приоритет данного соединения
    TCP
    Протокол управления пересылкой, протокол для надежной передачи
    информации между хост-компьютерами в системе объединенных се-
    тей.
    TOS
    Тип сервиса, поле заголовка в Internet протоколе
    Тип сервиса
    Поле заголовка в Internet протоколе, которое определяет тип
    сервиса для данного фрагмента в стандарте Internet.
    URG
    Контрольный бит (бит срочности), который не требует места в
    очереди. Этот бит требует, чтобы клиенту был послан приказ ис-
    пользовать ускоренную обработку до тех пор, пока имеются дан-
    ные, чьи номера в очереди меньше, чем указано в срочном указа-
    теле.
    Срочный указатель
    Срочный указатель имеет значение лишь если установлен бит URG.
    В поле срочного указателя определается значение, которое указы-
    вает на некий октет данных,. Последний был связан с запросом
    клиента на срочную пересылку

    Ссылки
    [1] Cerf, V., and R. Kahn, «A Protocol for Packet Network
    Intercommunication», IEEE Transactions on Communications,
    Vol. COM-22, No. 5, pp 637-648, May 1974.
    [2] Postel, J, (ed.) «Internet Protocol — DARPA Internet Program
    Protocol Specification», RFC 791, USC/Information Sciences
    Institute, September 1981.
    [3] Dalal, Y. and C.Sunshine, «Connection Management in Transport
    Protocols», Computer Networks, Vol. 2, No. 6, pp. 454-473,
    December 1978.
    [4] Posterl, J, «Assigned Numbers», RFC 790, USC/Information
    Sciences Institute, September 1981.


    2014-07-27, lissyara
    gmirror
    Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов. 2013-08-20, zentarim
    Scan+Print server FreeBSD 9
    Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540 2011-11-20, BlackCat
    Разъём на WiFi-карту
    Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма 2011-09-14, manefesto
    Настройка git+gitosis
    Настройка системы контроля версия исходного кода в связке git+gitosis+ssh 2011-08-14, zentarim
    Wi-FI роутер + DHCP + DNS
    Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ 2011-06-15, -ZG-
    Охранная система на FreeBSD+LPT
    В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией. 2011-03-13, terminus
    ng_nat
    Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat 2011-02-20, Капитан
    Nagios+Digitemp
    Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp. 2011-02-17, Le1
    Zyxel Configuration
    Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл. 2011-02-16, fox
    hast carp zfs ucarp cluster
    HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления… 2011-02-04, BlackCat
    Восстановление ZFS
    История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий. 2011-02-03, Капитан
    1-Wire
    Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp. 2011-01-28, Капитан
    Температура в серверной
    Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG 2011-01-21, m4rkell
    Syslog server
    Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк 2011-01-07, lissyara
    Canon/gphotofs
    Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты. 2010-12-13, Al
    IPSec
    Описание принципов работы IPSEC и способов аутентификации. 2010-12-07, manefesto
    FreeBSD on flash
    Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =) 2010-12-05, Fomalhaut
    root ZFS, GPT
    Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы — ZFS 2010-09-05, Cancer
    Настройка аудиоплеера на ximp3
    Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к 2010-08-31, Cancer
    Установка и настройка OpenVPN
    На днях появилась задача — объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах. 2010-08-25, manefesto
    freebsd lvm
    Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела 2010-04-30, gonzo111
    proftpd file auth&quota
    Proftpd — квоты и авторизация из файлов, без использования базы данных и/или системных пользователей 2010-04-22, lissyara
    tw_cli
    Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email. 2010-04-14, fox
    MySQL Master+Master
    MySQL (Master Master) and (Master Slave) Как настроить репликацию… 2010-03-09, terminus
    DNS zones
    Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон. 2010-03-09, aspera
    Squid+AD (group access)
    Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы 2010-03-02, BlackCat
    Шлюз: Часть 4
    Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org. 2010-03-01, BlackCat
    Шлюз: Часть 3
    Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов. 2010-03-01, BlackCat
    Шлюз: Часть 2
    Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента 2010-03-01, BlackCat
    Шлюз: Часть 1
    Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding. 2010-02-23, Morty
    darkstat
    Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики 2010-01-23, gonzo111
    squid+sams+sqstat
    Пилим squid и sams — примеры конфигов с объяснениями. Установка SqStat. 2009-12-19, schizoid
    mpd5 + radius + ng_car + Abills
    Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car 2009-11-16, lissyara
    UFS->ZFS
    Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386. 2009-11-13, gx_ua
    fusefs-ntfs
    Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD 2009-11-12, Morty
    LiveCD
    Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД. 2009-09-27, lissyara
    Samba как PDC
    Контроллер домена — аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =) 2009-08-30, terminus
    ipfw nat
    Подробное руководство по ipfw nat, сложные случаи конфигурации. 2009-08-24, levantuev
    HotSpot
    Установка Hotspot системы в общественное заведение. 2009-08-18, lissyara
    diskless
    Создание бездисковых терминалов под управлением FreeBSD — с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов. 2009-07-29, BAV_Lug
    Видеонаблюдение
    Настройка бюджетного варианта видеонаблюдения на удаленном объекте 2009-07-22, Cancer
    OpenLDAP адресная книга
    Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin 2009-06-30, SergeySL
    AimSniff
    Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений 2009-06-25, atrium
    Управление правами доступа
    Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX. 2009-06-16, DNK
    Exim+PgSQL
    Установка почтовой системы exim+pgsql на FreeBSD 7.1 2009-05-30, mvalery
    HDD(mbr) -> HDD(gpt)
    Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора. 2009-05-22, Cancer
    SendXMPP
    Отправка сообщений на Джаббер сервер по средствам SendXMPP 2009-05-11, Raven2000
    Network UPS Tools
    Network UPS Tools представляет собой набор программ, которые обеспечивают общий интерфейс для мониторинга и администрирование UPS оборудования. 2009-04-29, m0ps
    IPSEC over GRE with RIP
    Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco. 2009-04-24, WhiteBear777
    qemu network
    Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet. 2009-04-22, vp
    freebsd + huawei 162 gsm modem
    В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools 2009-04-12, mvalery
    Мониторинг RAID
    Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078) 2009-04-09, texnotronic
    RAID1 via LAN
    Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror. 2009-04-03, Raven2000
    Оптимизация хоста для CMS
    В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и

    10 сайтов/CMS. 2009-04-01, atrium
    VSFTPD + AD && MySQL
    Настройка самого безопасного сервера FTP — vsftpd. 2009-03-31, Dron
    Peoplenet + C-motech (3G)
    Описание подключения к сети Peoplenet посредством 3G модема С-motech CCu-650U на FreeBSD 2009-03-25, lissyara
    mod_auth_external
    mod_auth_external — авторизация пользователей в apache c помощью внешней программы — например, системных пользователей. 2009-03-24, gx_ua
    Lightsquid
    Частично lightsquid может заменить sams: быстрая и простая инсталляция, быстрый парсер, cgi скрипт для динамической генерации отчета, нет привязки к БД, различные графические отчеты, мультиязычный инт 2009-03-18, LHC
    Установка Zabbix-1.6
    Установка и первоначальная настройка системы мониторинга Zabbix (версия 1.6) 2009-03-16, Cancer
    Принт-Сервер Samba+LPD & AD
    Простейшая настройка Принт-Сервера на FreeBSD используя Samba+LPD & AD 2009-03-04, Mad_caterpillar
    ipsec_vpnc
    Настройка VPN IPSec концентратора на FreeBSD 6.2 для клиента cisco с использованием ipsec-tools и авторизацией в активной директории 2009-02-18, Andy
    Free-SA
    Программа анализирует log файлы Squid’а и формирует по ним отчет. 2009-02-02, Cancer
    Openfire Jabber Server
    Установка Jabber сервера на примере Openfire 2009-01-28, Cancer
    mpd5 + сжатие и шифрование
    Установка VPN сервера mpd5 + сжатие и шифрование 2009-01-26, vp
    freebsd + webcamera
    Подключение и настройка вебмкамеры для работы с freebsd на примере Logitech QCam STX 2009-01-10, Grishun_U_S
    конфиг для офисов
    В статье разбирается конфиг для офиса, пользователи которого имеют строгие ограничения по портам. Заворачиваем www трафик на транспарентный прокси, а остальное NAT’им. Эффективно делим канал интернет 2008-12-27, Storoge
    sftp+chroot
    Возникла необходимость дать возможность нескольким пользователям заливать на сервер контент для своих сайтов через sftp, чтобы при этом не страдала безопасность. 2008-12-13, Morty
    PurefFTPd
    Администрирование pureftpd-сервера с помощью вэб интерфейса Usermanager 2008-12-11, lissyara
    termlog
    Небольшая простая утилита, использующаяся для записи в файл всего что происходит на терминалах системы. Полезно, когда есть доступ по ssh у тех, кому не очень доверяете. Паранойя — это не плохо =) 2008-11-26, Cancer
    SQUID+SAMS +Rejik-(ADLDAP)
    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты, 2008-11-22, dvg_lab
    php5-oci8
    Решение проблем segmentation fault (core dumped) при работе с oracle8-client и php5-oci8 2008-11-21, m0ps
    NTP
    Пример настройки NTP сервера для локальной сети и клиента, для синхронизации времени с локальный NTP сервером. Обновление ntpd из портов. 2008-11-20, Cancer
    SQUID+SAMS +Rejik-(NTLM)
    Установка Прокси сервера SQUID с аутентификацией по NTL с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf, РЕЖИК собственно рубит банеры и запрещает пользователям хо 2008-11-20, UA
    Hotspot
    Настройка безпроводной точки доступа (WiFi) на freebsd 2008-11-12, Shaman
    Enemy Territory
    Появилась у меня такое желание поднять сервер Enemy Territory. Поискал погуглил, ничего толкового не нашел пришлось все самому делать. И вот решил поделиться опытом. Начинаем. 2008-11-11, lissyara
    Samba+ NT ACL
    Использование vfs самбы — модули full_audit и recycle. Настройка для использования в качестве файлопомойки с 500+ одновременно работающих юзеров. Раздача прав через нативный виндовый интерфейс. 2008-11-11, Raven2000
    Upgrading OpenBSD
    Сегодня мы будем обновлять OpenBSD. Систему необходимо поддерживать в актуальном виде и следить, чтобы все работало, как часы и все дырки были залатаны до прихода врага =) 2008-11-10, lexy
    SMSTools 3
    Как автоматизировать отправку и обработку входящих сообщений при помощи мобильного телефона, датакабеля и компа 2008-11-06, Cancer
    Asterisk IP PBX
    Установка VoiP сервера Asterisk IP PBX для соединения двух шлюзов и АТС 2008-10-30, atrium
    Samba & CUPS & AD & ACL
    Настройка Samba в роли доменного файл-сервера, и CUPS в роли принт-сервера для Windows клиентов 2008-10-17, Raven2000
    src & ports
    Конечно, в OpenBSD система портов никогда не сможет быть полной сравнение с той же системой во FreeBSD. Связано это с тем, что разработчики включают в порты лишь те приложение которые протестированн 2008-10-13, Morty
    Mysql — базовое описание
    Базовое описание и принципы работы с MySQL 2008-10-10, Cancer
    exim&dovecot + fetchmail + SSL
    Exim & Dovecot + Postfixadmin & Roundcube + Fetchmail & smtp_relay С возможностью отправлять письма через смтп релей провайдера. С использование SSL шифрование: POP3s IMAPs sSMTP 2008-10-09, m0ps
    Дополнительные порты для роутера
    Увеличение количества Ethernet портов маршрутизатора за счет свободных портов коммутатора пробросив vlan с сабинтерфейса роутера на интерфейс коммутатора. 2008-10-06, princeps
    Bacula
    Настройка сервера системы резервного копирования Bacula на FreeBSD для бэкапов FreeBSD и Windows машин 2008-10-02, zheromo
    Postfix + DBMail
    Создание почтовой системы на основе Postfix + DBMail + SASL2 + TLS + DSpam + ClamAV + RoundCubeWebMail 2008-10-02, Cancer
    SugarForge CRM
    SugarForge CRM предоставляет подавляющее большинство функциональных возможностей CRM систем 2008-09-12, arksu
    ng_ipacct + squid
    Подсчет трафика с помощью ng_ipacct. Связка ng_ipacct + squid + парсер логов + авторизатор + nginx + mysql и куча служебных скриптов для работы всей системы. 2008-09-03, Raven2000
    GLPI
    Мне надо было найти замену существующей программы инвентаризации, чтобы за компьютерами, принтерами, картриджами, лицензиями и тп был учет. Желательно с дополнительными бонусами типа системы подачи. 2008-09-03, salimk
    POWERDNS
    Статья о том как мигрировать с DNS сетвера ISC Bind на POWERDNS 2008-09-03, DNK
    Rinetd
    Редирект TCP портов с помощью утилиты rinetd — просто до безобразия — само прилодение простое, конфиг в одну строчку — что ещё надо для счастья? =) 2008-09-03, L!Ner
    eGroupWare
    Это сервер групповой работы. Он укомплектован собственным веб-интерфейсом, который обеспечивает доступ к вашим данным с любой платформы по всей планете. 2008-08-30, jafff
    MAC адрес
    У девайса VoIP Planet VIP-000 слетел MAC адрес и стал FF-FF-FF-FF-FF-FF, как я его востанавливал 2008-08-30, Morty
    clonehdd
    Перенесение, бэкапирование HDD,легко и просто 2008-07-31, Raven2000
    Proxy Auto Configuration
    Возникла необходимость автоматически настраивать прокси для всех компов и не бегать например если поменялось что-то на сервере прокси. Для этого давно существует технология Proxy Auto Configuration. 2008-07-29, f0s
    NNTP сервер
    Конфигурирование собственного NNTP-сервера. 2008-07-28, Al
    spamooborona
    настройка yandex spamooborona в качестве smtp-proxy для работы с exim 2008-07-28, Cancer
    SQUID+SAMS +Rejik-(NCSA)
    Установка Прокси сервера SQUID с красивой мордой SAMS и редиректором REJIK,для учета кто куда ходил + графики в pdf,РЕЖИК собственно рубит банеры и запрещает пользователям ходить на запрещенные сайты, 2008-07-20, Raven2000
    Pax
    Эта замечательная утилита поставляется с FreeBSD по умолчанию, и она имеет неплохой потенциал. Можно создавать архивы модифицировать их, а так же живьем переносить всю операционную систему с данными 2008-07-16, Andy2k
    BIND & AD
    Настройка BIND для обслуживания запросов контроллеров Active Directory. Альтернатива поднятию DNS от Microsoft. 2008-07-16, aleksey.kravchenko
    Samba (PDC+BDC)
    Поднять главный (офис) и резервный (филиал) контроллер домена на базе Samba и OpenLDAP, организовать синхронизацию и репликацию между ними. Запись в LDAP должена выполняться только на PDC. 2008-07-14, aleksey.kravchenko
    OpenVPN + LDAP
    Статья о том, как настроить OpenVPN с авторизацией пользователей в OpenLDAP. 2008-07-14, aleksey.kravchenko
    ProFTPd + LDAP
    ProFTPd с авторизацией пользователей в OpenLDAP 2008-07-13, lissyara
    Asus Eee PC
    Дали на несколько дней поиграться Asus Eee PC — мелкий ноутбок по смешной цене. Ну, первым делом ставим правильный ОС и смотрим — что из этого получиться. 2008-07-09, terminus
    DNS сервер Unbound
    Установка и настройка кеширующего DNS сервера Unbound под управлением FreeBSD 7.0 2008-07-08, f0s
    mozilla autoconfig
    Автонастройка браузера и почты Mozilla Seamonkey пользователям 2008-07-05, lissyara
    iftop
    Утилита предназначена для мониторинга загрузки канала в режиме реального времени — позволяет видеть кто именно занял полосу. Полезно для организаций с FreeBSD на шлюзовой машине. 2008-07-02, manefesto
    snd_hda
    Патчим snd_hda для корректной работы с наушниками 2008-06-27, Grishun_U_S
    dd : бэкапируем windows
    Клонирование разделов windows с помощью загрузочного диска FreeBSD 2008-06-25, terminus
    DNS сервер NSD
    Установка и настройка авторитарного DNS сервера NSD под управлением FreeBSD 7.0 2008-06-17, Al
    NetXtreme BCM5722
    Драйвер для сетевой карты NetXtreme BCM5722 Gigabit Ethernet 2008-06-15, tango
    Amanda
    Установка и настройка сервера резервного копирования Amanda на FreeBSD. 2008-06-12, LMik
    Виртуальный свитч
    Статья описывает создание виртуального коммутатора для соединения удаленных физических ethernet сетей. 2008-06-08, littlesavage
    SiS*Mirage*1 на D201GLY2
    Как заставить работать видеоrарту SiS*Mirage*1 на материнской D201GLY2 2008-06-06, nsand
    Рыбалка на FreeBSD
    Стьатья о том как настроить рыбалку со спутника под FreeBSD 2008-06-06, nsand
    TT budget S-1401
    Настройка драйвера ttbudget (SkyStar3) под FreeBSD 2008-05-30, Andy2k
    NOD32 mirror
    Скрипт для создания зеркала обновлений для антивируса NOD. Автоматически ищет нужные логин-пароль для получения обновлений. В теории не требует обслуживания. 2008-05-25, Romzes
    метаданные exif
    Пример сортировки фотографий сделаных разными фотоаппаратами, с разными названиями, датами создания/модификации. Из под консоли, конечно. 2008-05-23, FenX
    svn+apache+trac
    Установка связки Apache2.2 + Subversion + Trac (Установка и настройка SVN сервера с доступом к репозиториям по http протоколу) 2008-05-22, Grishun_U_S
    простой конфиг PF
    В статье разбирается простой конфигурационный файл pf «изнутри можно все» 2008-05-20, KrivoSoft
    HAVP
    HAVP(HTTP AntiVirus proxy)- работает как http прокси, проверяющий файлики используя LibClamav. В заметке описан процес прикручивания антивируса к уже работающему прокси серверу squid. 2008-05-20, Covax
    ALTQ в IPFW
    Исполльзование ALTQ вместе с IPFW 2008-05-19, nonalog2007
    pppoe
    Настройка ADSL-модема для подключения к Интернет. 2008-05-04, Abigor
    php + mssql
    Настройка php на freebsd для работы с базами в mssql по доменной авторизации. 2008-04-28, serge
    i386=>amd64
    Рассматриваеться способ удаленной миграции с архитектуры i386 на amd64 на рабочем сервере. 2008-04-24, Mr.Y
    Lan over Bluetooth
    Статья описывает как используя Bluetooth, объединить две FreeBSD машины в сеть. 2008-04-19, lissyara
    WiFi WPA
    Подключение FreeBSD к беспроводной WiFi сети с использованием шифрования WPA. 2008-04-18, nikll
    nginx+php-fpm+mysql
    Статья о настройке мощного веб сервера который не ляжет от хорошей нагрузки. 2008-04-16, nikll
    qmail-ldap + AD
    Статья о том как я прикрутил qmail к АД win2003 (с упровлением почтовыми аккаунтами через консоль mmc из под винды) 2008-04-14, SHPAk
    Приглашение csh/tcsh
    Приглашение csh/tcsh не всегда удобно. Здесь описано как помянять оное. 2008-04-07, inspirra
    deltup, xdelta, bdelta
    Некоторые тонкости создания бинарных патчей. И использование «The dynamic deltup server network» для экономии на обновлениях исходников программ устанавливаемых из портов. 2008-04-02, fr33man
    exim + cyrus-imapd
    Руководство по настройке почтовой системы на базе OpenBSD-4.2: exim + cyrus-imapd + mysql 2008-03-30, Morty
    LiveCD (+restore)
    LiveCD, который развернет мне на жёсткий диск готовую настроенную систему 2008-03-25, lissyara
    BlueTooth mouse
    Краткое повествование о том, как привернуть BlueTooth мышь к FreeBSD. Краткое — потому как делается это с полпинка. 2008-03-21, moonug
    ProFTPD+iconv
    Порт позволяющий включить перекодировку имён файлов в proftpd. Раньше для этого был патч, а щас всё поломали =)) 2008-03-11, helloworld
    vsftpd + mysql
    Настройка фтп сервера vsftpd с пользователями из mysql 2008-03-06, Raven2000
    Call of Duty 4
    Call of Duty 4: Modern Warfare — компьютерная игра, продолжение серии COD, разработанное студией Infinity Ward. Это первая игра в серии, действие которой происходит не во время мировой войны. 2008-03-04, schizoid
    NeTAMS 2
    Netams, статистика, биллинг, огрнаичение и подсчет трафика 2008-03-04, schizoid
    NeTAMS
    Программа для учета и управления сетевым трафиком 2008-03-01, Le1
    EA Battlefield 2 server
    Установка игрового сервера EA Battlefield 2 под ОС FreeBSD 2008-02-25, dikens3
    Dynamic DNS
    Свой сервер с динамическим IP-Адресом. 2008-02-23, fr33man
    squid ntlm
    Настройка Squid с аутентификацией ntlm, под OpenBSD. Решение проблем сборки с поддержкой АД. 2008-02-18, lissyara
    BlueTooth
    Встала задача залить на Нокию гиг музыки через BlueTooth. ОС — правильный — FreeBSD, вот про то как это сделать из под неё — и рассказ. Также немного про нынешнее состояние дел с голубыми зубами =) 2008-02-17, Raven2000
    NFS & Win2k3
    При работе с UNIX системами на предприятиях часто приходится организовывать совместную работу с Windows. Необходимо обеспечить взаимодействие UNIX<>WIN бывает, что доступ по FTP или др не устраивает. 2008-02-14, Morty
    Lightsquid
    Снятие статистики с OOPS, SQUID с помощью lightsquid — нечто на подобии SARGa, и выполняет туже задачу, подбивает статистику пользования прокси сервером 2008-02-14, Morty
    OOPS
    Краткое описание установки и настройки прозрачного прокси-сервера OOPS 2008-02-12, fr33man
    Apache
    Настройка web-сервера apache, на базе OpenBSD. Нужен был web сервер. Стандартно нужно было ставить apache. Но я помнил, когда раньше работал с OpenBSD, что апач поставляется вместе с системой. Так 2008-02-11, Raven2000
    Установка OpenBSD
    OpenBSD — свободная многоплатформенная операционная система, основанная на 4.4BSD — BSD-реализации UNIX системы. Основным отличием OpenBSD от других свободных операционных систем, базирующихся на 2008-01-31, serge
    ApacheStats
    Сбор статистики с веб-сервера Apache в Cacti с использованием модулей mod_status и mod_info. Отображается число хитов в секунду, загрузка чилдренов и прочая полезная инфа. 2008-01-30, Raven2000
    CVSUP и софт через Proxy
    При работе за прокси люди испытывают неудобство при обновление портов и установки портов. Хотя, наверное, догадываются, что FreeBSD может элегантно обходить эти камни, но не знают как. 2008-01-25, nikll
    kde и smb
    статья о том как фрю сделать членом win2003 домена и о том как в кде 3.5 ходить по доменным шарам с нормальной русской кодировкой 2008-01-21, Fastman
    Создание программ на QT4/С++
    Установка и настройка QT4. Пример создание приложения с GUI. 2008-01-17, Morty
    stunnel для pop3,smtp
    Создание защищенного подключения для сервисов POP3, SMTP, Imap , www с помощью stunnel 2008-01-09, lissyara
    Atheros AR5007EG
    Прикручивание карточки Atheros AR5007EG (в ноутбуке Toshiba L40-139) под FreeBSD. 2008-01-04, LMik
    growfs
    Статья наглядно описывает изменение размера раздела диска в FreeBSD при помощи growfs, без потери данных находящихся на диске. 2007-12-23, serge
    FreeBSD на VDS
    Рассматривается настройка FreeBSD6.2 на VDS с чистой ОС. 2007-12-22, serge
    OTRS на Apache1
    Рассматривается установка Open Ticket Request System для работы на хостинг сервере в связке apache1.3 + mod_perl + mysql50. 2007-12-11, INFected
    SkyStar-2+SlonAx
    Встала задача организовать прием трафика от спутникового провайдера. Естественно на раздающем сервере должна быть FreeBSD. А как же иначе? 2007-12-08, netcat
    GEOM-ELI
    Шифрование файловых систем посредством класса GEOM-ELI 2007-12-07, helloworld
    PVPGN
    Настройка сервера Battle.net в небольшой локальной сети. 2007-12-06, seacon
    ESET NOD32
    Описание настройки антивирусной системы NOD32 ESET File Security 2007-11-23, azu
    Bluetooth proximity monitor
    Описание и скрипты для отслеживания удаленности bluetooth устройства. 2007-11-19, catdog_
    verlihub (p2p)
    описывается, как установить, настроить p2p-сервер и как им управлять 2007-11-14, UA
    OpenVPN
    руководство по настройке openvpn между FreeBSD и Windows 2007-11-11, AlkoGekS
    atacontrol
    Проверка работы raid-1 с помощью штатной утилиты atacontrol на freebsd 6.2 2007-11-08, Raven2000
    Transport Tycoon Deluxe
    Transport Tycoon Deluxe (сокращенно — TTD) — экономическая транспортная стратегия, в которой целью игрока является создание максимально доходной транспортной империи. 2007-11-06, lissyara
    squid+AD
    Инструкция — как авторизовать пользователей в домене, разделив доступ к ресурсам по виндовым группам — кому куда можно, а кому нельзя, с использованием squid2.6. Ну и объяснение — почему пока не 3.0. 2007-11-03, schizoid
    icecast2
    Вещание интернет радио в локальной сети с помощью icecast2 2007-11-02, AlkoGekS
    RoundCube
    Возникла необходимость перевести пользователей с squirrelmail на roundcube, завязать все это хотелось на postgresql, чтобы и в ней разобратьс заодно. 2007-10-30, SniZ
    queues
    Краткая заметка по использованию очередей В IPFW 2007-10-29, s@sh@
    LACP и VLAN
    Описание настройки LACP отдельно и совместно с VLAN во FreeBSD 7.0 2007-10-26, Al
    portaudit
    Эти приложение используется для контроля уязвимостей и обновления приложений, установленных из портов. 2007-10-24, -cat-
    Заметки об IPFW
    Заметки о настройке IPFW, подключение IPFW и NATD, принцип взаимодействия, принципы построения правил IPFW. 2007-10-23, Raven2000
    X-Bomber
    Представляю вниманию отличную аркаду которая скрасит наш быт и существование в офисном пространстве именуемая как «работа» И так прошу любить и жаловать X-Bomber 2007-10-22, Raven2000
    TeamSpeak
    Teamspeak (тимспик) — семейство программ, предназначенных для общения голосом в сети. От классического телефона отличается практически неограниченным количеством абонентов, разговаривающих одноврем 2007-10-22, RageLT
    Nginx+php+fcgi
    «Nginx + PHP + Spawn-fcgi» — установка nginx под FreeBSD и настройка для выполнения PHP скриптов. 2007-10-20, dikens3
    UFS2
    Как устроена UFS2. Небольшой взгляд изнутри. 2007-10-19, Al
    Nagios — мониторинг сети
    настройка мониторинга сети с использованием Nagios 2007-10-19, BlackCat
    FFS из-под WinXP
    Описание програмки для чтения BSD разделов под Windows. К сожалению, диск подключается в режиме только чтения — но и это уже неплохо. 2007-10-14, dikens3
    recovery files
    Восстановление файлов на FreeBSD с использованием foremost, sleuthkit, photorec. Немного теории о хранении файлов на диске. 2007-10-05, lissyara
    ClamAV mirror
    Понадобилось создать внутри локальной сети зеркало обновлений ClamAV, c учётом того, что разработчики это не привтствуют — пришлось изобретать подпорки и велосипеды. 2007-10-04, SeeD
    irc + services
    Установка irc сервера (unreailircd) + сервисов (anope) на FreeBSD 6.0. Приведён тот необходимый минимум, который вполне подойдет для одиночных серверов. 2007-10-04, lissyara
    установка по сети
    Столкнувшись с невозможностью поставить FreeBSD на старенький ноут с CD-ROM (толи диск царапаный, толи чё), пришлось изгаляться с установкой по сети — благо на нём был PXE у встроенной сетевухи. 2007-10-04, Al
    cups-samba на samba+AD
    Пример настройки сервера печати с использованием CUPS, Samba и AD. Пример установки и настройки клиентских (для винды) драйверов принтера на сервер с использованием порта cups-samba. 2007-10-03, schizoid
    ipcalc
    Скрипт для вычисления широковещательного адреса, диапазон хостов, шаблон сетевой маски по полученному IP и сетевой маске. Может использоваться для конструирования сетей и подсетей, а также в обучающих 2007-09-26, lissyara
    немного о ssh
    Краткое описание как пробросить порты с удалённой локальной сети на локальную машину при помощи ssh. Может быть полезным, когда нет VPN в удалённую сеть, а есть ssh, и нужен доступ к какому-то сервису 2007-09-26, SniZ
    mod_ntlm2
    mod_ntlm2 — модуль для apache22, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к содержимому корпоротивного 2007-09-18, lissyara
    klaptopdaemon
    даемон KDE для мониторинга состояния батареи ноутбука. Наверное, самое удобное и функциональное из того, что я перебрал. 2007-09-17, bisyarin
    Удаленное разбиение HDD
    В статье рассмотрен пример удаленной доразбивки винчестера. Показан путь решения задачи как с использованием sysinstall, так и с помощью утилит fdisk, bsdlabel и newfs. 2007-09-14, freeman_tnu
    DSL-G804V и FreeBSD 6.2
    Настройка VPN-туннеля между D-Link DSL-G804V и FreeBSD 6.2 2007-09-13, lissyara
    KNemo
    Служба KDE отображающая в трее значка сетевого подключения, с богатым функционалом — позволяет собирать статистику, строить графики, выполнять скрипты при изменении статуса сетевого подключения. 2007-09-12, lissyara
    desktopbsd-tools
    Набор утилит для упрощения жизни под KDE. Включают в себя утилиты трея для слежения за сетью, монтирования/ демонтирования, информацию о заряде батереи. Также несколько апплетов для контрольной панели 2007-09-06, lissyara
    nettop
    Приложение позволяющее отслеживать сетевую активность по портам-протоколам, и отображать скорость передачи данных по этим портам и протоколам. Весьма удобно для наблюдения — что происходит на сервере. 2007-09-04, squid
    sshd & AD
    Использование одной учетной записи на FreeBSD и Windows — используя AD для авторизации пользователей по ssh 2007-09-02, lissyara
    ISPmanager
    Краткое описание того, как заменить дефолтовый майлер на ISPmanager, если он у вас — sendmail. Может пригодится тем кто берёт виртуальный сервер, и хочет большей гибкости в настройке. 2007-08-25, serge
    mod_ntlm
    mod_ntlm — модуль для apache13, позволяющий прозрачно авторизовать пользователя использую его доменную учетную запись. Удобно, если необходимо сделать ограниченный доступ к сайту. 2007-08-15, lissyara
    colorize
    colorize — утилита для подсветки ключевых слов в просматриваемых логах. Весьма удобно — становится более понятно и доходчиво, тока временами слишком уж пёстро :))) 2007-08-13, Raven2000
    Документация на Unix
    Здесь представляем список необходимой документации для чтения и полного освоения FreeBSD как основной серверной операционной системы. И не только ее. 2007-08-06, lissyara
    QTFW
    Графический интерфейс для составления и редактирования правил файрволла IPFW — абсолютно бесполезная приблуда. 2007-08-01, Raven2000
    Counter-Strike 1.6
    По просьбам трудящихся, точнее по их заявлениям, о том что нужна им Counter-Strike 1.6 хоть «убейся об стену». Решил разобраться, наконец, с этим вопросом, что и сделал. И так поехали. :) 2007-07-31, f0s
    LDAP: samba, dns, dhcp
    Настраиваем PDC на самбе, все данные в LDAP. Попутно вешаем DDNS+DHCP — их данные тоже храним в LDAP. 2007-07-27, lissyara
    root-tail
    Практически бесполезное, но довольно забавное приложение, показывающее логи на рабочем стол. Может пригодится лишь если на ваш десктоп логи передаются с удалённых хостов. 2007-07-27, lissyara
    laptop battery
    Краткий обзор программ мониторинга состояния заряда батареи ноутбука — что можно использовать на FreeBSD7.0 (CURRENT) и AMD64. 2007-07-24, Raven2000
    phpBB-2/3
    phpBB – это мощное, полностью масштабируемое и легко изменяемое программное обеспечение с открытым исходным кодом для создания конференций. Основанный на мощном языке PHP и имеющий поддержку серверов 2007-07-23, lissyara
    apache 2.0
    Настройка WEB-сервера на apache2 и php в режиме CGI с использованием mod_fastcgi. 2007-07-15, lissyara
    geom_uzip
    Создание образа сжатой ФС с загрузкой по сети — данный метод может использоваться для создания загрузочных дисков/сидюков и прочего — на машинах где мало оперативки, например. 2007-07-06, bdmalex
    2 CD -> 1 DVD
    FreeBSD: Заменим 2 инсталляционных диска на 1 DVD. чтобы коллекцию дисков уменьшить. 2007-07-04, Andy
    NSPluginWrapper
    Перевод с французского очень хорошего мануала, досконально объясняющего, как инсталлировать линуксовые плугины для firefox, используя NSPluginWrapper. В том числе и 9-й flash. 2007-07-01, lissyara
    sshit
    Перловый скрипт мониторящий попытки подбора паролей для ssh/ftp в режиме реального времени, и блокирующий атакующего используя файрволл — pf/ipfw/ipfw2 — просто и со вкусом :) 2007-06-19, Raven2000
    CMS — TYPO3
    Ставим CMS TYРOЗ — Корпоративная система управления веб-контентом TYРOЗ — система управления сайтами (CMS/CMF) с открытым исходным кодом и свободной лицензией. Написана на PHP, для хранения данных. 2007-06-15, lissyara
    SAMBA+ACL
    SAMBA + правка расширенных пермишенов (ACL) через виндовые галочки — полезно для передачи управления шарами на самбе виндовым админам, ничё кроме галок и не умеющим :) 2007-06-13, roygbiv
    ntop 4.10
    Установка, настройка, оптимизация сетевого анализатора трафика ntop 4.1 stable с плагинами (в т.ч.SPAN-Sniffer и NetFlow) на FreeBSD 8.2 release. Описание nProbe. 2007-06-09, Andy
    vsftpd
    перевод мана на vsftpd 2007-06-04, lissyara
    exim + dovecot + win2003 AD
    Как заставить связку exim+dovecot использовать в качестве БД пользователей виндовый домен. Статья неполноценная — тока основные моменты и ссылки, где взять остальное. Скорее — просто заметка для себя. 2007-05-30, lissyara
    exim + exchange
    Настройка релея на exim для сервера M$ exchange находящегося внутри локальной сети. Настройка перезаписи адресов локального домена на внешний. 2007-05-13, Raven2000
    Бронированный FreeBSD
    Как и любую другую систему FreeBSD нужно так же защищать от посягательств на нее. Она не так уж защищена, как много людей о ней думают и ее можно так же сломать и крякнуть, как и тот же Windows. 2007-05-12, alex3
    Печать из фри в винду
    Печать из FreeBSD на сетевой принтер виндов 2007-05-03, Raven2000
    Десктоп c FreeBSD
    По просьбам трудящихся возьмусь за неблагодарную тему по одомашниванию FreeBSD.Начнем с одомашниванием консоли закончим русским KDE и настройками видео карт. 2007-04-28, fr33man
    iPod
    Использование iPod во FreeBSD 2007-04-25, lissyara
    AutoMount
    Как настроить автоматическое монтирование флэшек и CD-ROM в KDE. Заодно пришлось победить грабли с неверной русской кодировкой на флэшках. 2007-04-24, Fastman
    Socket сервер на FreeBSD.
    Пишем tcp демона на С++ ! 2007-04-14, BAV_Lug
    ATSlog
    Ведение статистики звонков с офисной мини-АТС. 2007-04-11, nk
    Backup MX
    Настройка fetchmail для сбора писем с сервера провайдера или резервного сервера и дальнейшая передача их локальному MTA 2007-04-11, Raven2000
    Quake III Arena
    Представляю установку всеми любимого игро-мясо-экшена Quake III Arena именно так и никак не иначе! Будет чем заняться Васе и Пете (и отделу) во время работы, т.е. вместо нее :) И так Kill’em All!! 2007-03-31, Raven2000
    Работа с HDD
    Есть много вопросов как грамотно разбить диск, выделить своп и диагностировать узкие места дисковой системы и т.к.дисковая подсистема-узкое место и разбивка его во многом определяет производительность 2007-03-29, Abigor
    mpd + freeradius + mysql
    Настройка связки mpd + freeradius + mysql с дальнейшим превращением ее в биллинговую систему. Может пригодится совсем мелкому домашнему провайдеру 2007-03-27, fr33man
    Exim + LDAP
    Настройка почтового сервера на базе Exim, с хранением информации в директориях LDAP. 2007-03-21, dikens3
    PBR & IPFW
    Настройка 2-х каналов в Интернет. 2007-03-16, fr33man
    Samba(PDC) + Ldap
    Множество неточностей заставили меня полностью переписать статью по настройке Samba + LDAP. 2007-03-16, lissyara
    IPSEC
    Настройка шифрованного туннеля с использованием IPSEC на FreeBSD6.2, с использованем сертификатов. Используются только штатные прграммы (не считая racoon из портов). 2007-03-11, Raven2000
    make.conf
    Так как мы сидим под фряхой и ставим все исключительно из портов (как умные ;)) компилим ядра и тд то неплохо было бы оптимизировать процесс компиляции многие часто не придают этому значение, но ведь 2007-03-07, lissyara
    /usr/sbin
    Системные приложения из ‘/usr/sbin’ 2007-03-06, lissyara
    /usr/bin
    Системные приложения из ‘/usr/bin’ 2007-03-02, lissyara
    /sbin
    Это даже не статья, а просто однострочное описание каждого приложения находящегося в ‘/sbin’. К каждому приложению можно оставить комментарий, что уже и сделано для многих — примеры использования. 2007-02-28, lissyara
    /bin
    Краткое описание (в одну строку, в основном) всех системных приложений из ‘/bin’ 2007-02-22, Raven2000
    Jabber — OpenFire
    OpenFire — это свободный многофункциональный и отказоустойчивый Jabber-сервер написанный на Java.На базе использования данной технологии было создано множество частных и корпоративных серверов Jabber. 2007-02-07, lissyara
    ru man
    Интересный проект нашёлся — товарисчи переводят маны от FreeBSD. Народу не много, перевели тоже не много — но всё же, хоть что-то. Дело нужное — поэтому ставим. 2007-02-05, Raven2000
    SkyLink-CDMA
    SkyLink-CDMA + FreeBSD 6.1 Подрубаем телефоны SkyLinkие т.е. CDMA к нашей любимой фряхе :) Например мне надо было подключить к BSD 2 телефона, мобильный Ubiquam UM-105 и стационарник RWT FCT-CDMA.2 2007-01-29, dikens3
    Rejik
    Блокирование баннеров с помощью SQUID+REJIK 2007-01-25, lissyara
    Samba как PDC
    Понадобилось поднять домен без винды — намучавшись со всякими LDAP`ами сделал по простому — на системных учётках. Работает и работает — разве что пришлось десяток скриптов на шелле написать. 2007-01-15, Raven2000
    Настройка AWStats
    Статистика с AWStats 6.6 AWStats – еще один парсер, написанный на perl. Поддерживает запуск из командной строки и динамически через CGI Настройка для Аpache, Proftp, Postfix, Sendmail, QMail, MDae 2007-01-14, lissyara
    loader.conf
    Перевод комментариев файла loader.conf (FreeBSD 6.2 RC2RC2) В нём довольно много интересных вещщей, в частности, через него можно добавить некоторые возможности без сборки нового ядра. 2006-12-27, dikens3
    if_bridge
    Настройка DMZ при помощи if_bridge 2006-12-18, lissyara
    BIOS & PXE
    Прошивка загрузочного PXE биоса для сетевых плат RTL8139(A/B/C)/RTL8130 прямо в БИОС материнской платы — полезно, когда на сетевухах нет кроватки под микросхему, или когда нет самих микросхем :) 2006-12-12, lissyara
    DSPAM
    Наиболее эффективное использование этой программы — в качестве второго фильтра, на спам. Первичный «грубый» отсев стоит проводить самим MTA Exim, благо он обладает широкими возможностями фильтрации. 2006-12-01, seacon
    D-Link DWL-G520
    Понадобилось сделать радиолинк на базе карточки DWL-G520 и апэшки DWL-2100AP, особых проблем вроде не возникло. 2006-11-29, lissyara
    pppd
    Понадобилось поднять dial-in сервер на фре. Ввиду того, что этот самый сервер, будучи под виндой достал всех, решили на новом оторваться по полной :)) Но — сервак всё равно подняли :))) 2006-11-27, fr33man
    newsyslog
    Программа для ротации логов — newsyslog. 2006-11-25, lissyara
    NetMos NM9845
    Понадобилось много com-портов под фрёй, тока вот на тех платах, что купили, определились не все — четыре вместо шести. Жалко — с двух плат четыре порта пропало. Пришлось рыться — почему не подцепились 2006-11-23, dysel
    MRTG
    Недавно назрела необходимость снимать статистику с ADSL модема. Изначально закралось подозрение, что копать нужно в сторону SNMP. Недолгие копания в мануале модема это подозрение подтвердили. 2006-11-18, lissyara
    bsnmpd
    Штатный SNMP-даемон. Позволяет удалённо снимать с хоста статистику интерфейсов, количество залогиненых юзеров, насколько заполнены разделы, среднюю загрузку системы и прочие прелести протокола SNMP. 2006-11-17, lissyara
    diskless
    Бездисковые терминалы на FreeBSD — тонкие клиенты грузящиеся по сети и коннектящиеся к виндовому серверу терминалов. Офигенная экономия на железе. В ход идёт всё — первые пни и выше. Может даже 486. 2006-11-16, lissyara
    mount_nullfs
    Эта системная утилита позволяет монтировать одну директорию в другую, поверх старой. Очень полезно, когда на одной машине в разных местах надо держать одно и то же (типичный пример — jail) 2006-11-14, BAV_Lug
    Контроль провайдера
    Как попытаться доказать провайдеру, что у Вас не было интернета 2006-11-11, fr33man
    maildrop & postfix
    Настройка MDA maildrop и postfix. 2006-11-09, fr33man
    Postfix + LDAP
    Настройка Postfix с хранением информации о пользователях в БД LDAP. 2006-11-08, fr33man
    rsync
    Архивируем по rsync 2006-11-08, fr33man
    auth_ldap
    auth_ldap — это модуль апача, который позволяет авторизовать пользователей, беря информацию о них из LDAP. 2006-11-08, fr33man
    Apache + SSL
    Прикручиваем SSL к Apache 2.2.0 2006-11-08, fr33man
    knockd
    Технология port knocking позволяет выполнять любые действия на сервере, даже если все порты на нем закрыты. Вам достаточно соедениться с определенными портами, в определенной последовательности. 2006-11-08, fr33man
    Inet»>КПК + FreeBSD
    Привязываем КПК(HP hx4700) к FreeBSD по протоколу bluetooth — избавляемся от проводов дома 2006-11-08, fr33man
    LAM
    Совершенно случайно наткнулся на то, что Вы видите в листинге, то бишь lam(LDAP Account Manager). Решил установить, так как давно хотел скрипт для добавления пользователей написать. 2006-11-08, fr33man
    SAMBA + LDAP
    Хранение учётных записей пользователей SAMBA в LDAP. 2006-11-08, fr33man
    LDAP auth
    Хранение в LDAP пользователей. Привяка пользователей из LDAP к системе. 2006-11-08, fr33man
    LDAP+SSL
    Шифруем при помощи SSL данные передаваемые по LDAP — в целях безопасности. 2006-11-08, fr33man
    Основы LDAP
    Cлужба каталогов LDAP (Light Weight Directory Access Protocol) — описание принципов работы. 2006-11-08, fr33man
    PBR & PF
    Понадобилось настроить роутер, между сетями. Так как на cisco начальство раскошеливаться не захотело(это намек =)), пришлось ставить на компутер ОС — FreeBSD. Ну и файрволл — pf. 2006-11-06, serge
    dvd в avi
    Скрипт кодирования dvd в avi. Кодек DIVX (FMP4), 2 прохода, качество выбирается вручную, размер видео 700 Мб. 2006-11-04, fr33man
    pfctl
    Подсчет трафика с помощью pf 2006-11-02, lissyara
    gmirror
    Использование gmirror для создания программного зеркалирования дисков. Полезно, когда нет аппаратного RAID-контроллера. 2006-10-30, lissyara
    D-Link DGE530T
    Сетевуха D-Link DGE530T не поддерживалась. Вернее — поддерживалась, но фря её определить не могла. Пришлось чутка подправить руками исходники драйвера в ядре. 2006-10-24, lissyara
    hosting
    Настройка хостинга под apache + PHP + MySQL. Боремся со спамерами — какой-то клиент спам рассылает, а при php модулем — неизвестно кто.. Вот и приходится изгаляться. 2006-10-23, serge
    Обновление мира («world»)
    Обновленная версия статьи в которой постарался учесть все пожелания и замечания оставленные в комментариях. Рассматривается переход с версии 6.1 на 6.2. 2006-10-19, Abigor
    cvsupd
    cvsupd — зеркало обновлений сиходных текстов системы FreeBSD и портов 2006-10-17, Abigor
    monit
    Настройка monit для мониторинга работы системы. 2006-10-17, lissyara
    monitord
    Программа для наблюдения за работой сервисов на локальной машине, при необходимости (если сервис упал, или его кто-то остановил) перезапускает их. Шлёт уведомления на почту, в случае сбоев. 2006-10-06, serge
    pdf в html
    Данный материал может пригодится для организации веб-доступа к большому архиву pdf документов. Причем исключается необходимость передачи самого pdf документа клиенту. 2006-09-29, 100kg
    Ntpdate/Ntpd
    FreeBSD поставляется с утилитой ntpdate, которая одноразово синхронизирует наши часы, и с сервером NTP 2006-09-20, lissyara
    bsdstats
    Программа (вернее, — shell-скрипт) собирает данные о версии OC, используемом железе и шлёт на сайт где эта статистика лежит. Цели — популяризация BSD-систем. Мне, проект показался полезным. 2006-09-01, lissyara
    hylafax
    Очень хорошая программа, позволяющая принимать-отправлять программы под FreeBSD. Одно условие — необходим `железный` модем, или софтверный на lucent`овском чипе. Умеет слать факсы на почту, и наоборот 2006-08-25, m`ax
    mpd – легко и просто!
    Как mpd помог мне сделать так, чтобы пользователи подключались к серверу по VPN тем самым открывая себе доступ в интернет. 2006-08-24, bonh
    DDNS+DHCP
    DNS и DHCP два очень хороших сервера, а в связке DHCP с DNS, получается красотища да и только… 2006-08-11, lissyara
    HDD->HDD
    Возникла необходимость поменятьхард на работающем почтовом сервере. Всё переставлять — неоправданно долго, да и там куча специфического ПО — посему надо просто перенести с одного на другой, и всё. 2006-08-10, lissyara
    jail
    Установка и настройка «клетки» (jail) под FreeBSD. Может пригодиться для виртуального хостинга, и при необходимости запускать несколько одинаковых приложений на одной машине. 2006-08-09, lissyara
    LANTECH 1601F
    Достался по наследству управляемый свич, почти единственный в конторе, но тока в него отвёртку уронили, во время работы. А так, по словам оставившего, хорошая, вполне рабочая железяка. Была :) 2006-08-02, lissyara
    imapsync
    Рассмотрено использование небольшой утилиты для перенса почты с одного сервера на другой. Может быть полезна при смене почтового сервера. Работает по протоколу imap (хотя, по слухам есть и для pop3) 2006-07-30, northern
    CP1251 на FreeBSD
    CP1251 locale для FreeBSD, монтирование дисковых разделов других файловых систем в cp1251 2006-07-30, lissyara
    sendmail -> exim
    Кратенькая статья по миграции с sendmail на exim. Вариант с использованием системных пользователей. Особых сложностей нет, вернее даже их вообще нет. Но, раз народ задаёт вопросы, — есть неясности. 2006-07-27, lissyara
    Marvell 88E8053
    Как прикрутить драйвер на сетевуху 88E8053 Yukon PCI-E Gigabit Ethernet Controller, на которую не оказалось родного драйвера в FreeBSD. Но — помог производитель, озаботившийся выпуском этого драйвера. 2006-07-08, lissyara
    MySQL
    Кратенький рассказ о установке, и некоторой настройке сервера БД MySQL. Может, кому-то окажется полезным, хотя ничего особо глубокого не рассматривается.
    вверх

    Статистика сайта
    Сейчас на сайте находится: 14 чел.
    За последние 30 мин было: 87 человек
    За сегодня было
    9437 показов,
    1133 уникальных IP

    Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
    Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

    Илон Маск рекомендует:  Описание float
  • Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL