RFC — это… Что такое RFC?
Эта статья о Request for Comments.
Рабочее предложение (англ. Request for Comments, RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.
История
Формат RFC появился в 1969 году при обсуждении проекта ARPANET. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.
Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса и Стэнфордском исследовательском институте.
С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC Институту информационных наук Университета Южной Калифорнии.
Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.
Содержимое RFC
Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft здесь — проект). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:
- Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
- Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
- Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
- Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
- Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус
Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:
- Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
- Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
- Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.
Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).
Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.
Примеры популярных запросов на отзывы
| Номер RFC | Тема |
|---|---|
| RFC 768 (англ.) RFC 768 (рус.) | UDP |
| RFC 791 (англ.) RFC 791 (рус.) | IP |
| RFC 792 (англ.) RFC 792 (рус.) | ICMP |
| RFC 793 (англ.) RFC 793 (рус.) | TCP |
| RFC 821 (англ.) | SMTP, заменён RFC 2821 |
| RFC 822 (англ.) | Формат электронной почты, заменён RFC 2822 |
| RFC 826 (англ.) | Протокол разрешения адреса (ARP) |
| RFC 894 (англ.) RFC 894 (рус.) | IP по Ethernet |
| RFC 951 (англ.) | Протокол начальной загрузки (BOOTP) |
| RFC 959 (англ.) | FTP |
| RFC 977 (англ.) | NNTP — устаревший, дополнен RFC 2980 , заменён RFC 3977 |
| RFC 1034 (англ.) | DNS — концепция |
| RFC 1035 (англ.) | DNS — внедрение |
| RFC 1122 (англ.) RFC 1122 (рус.) | Требования к хосту 1 |
| RFC 1123 (англ.) RFC 1123 (рус.) | Требования к хосту 2 |
| RFC 1191 (англ.) RFC 1191 (рус.) | Определение MTU пути |
| RFC 1256 (англ.) | Обнаружение маршрутизатора в сети |
| RFC 1323 (англ.) | Высокопроизводительный протокол TCP |
| RFC 1350 (англ.) | TFTP |
| RFC 1403 (англ.) | Взаимодействие BGP и OSPF |
| RFC 1459 (англ.) RFC 1459 (рус.) | IRC |
| RFC 1498 (англ.) | Архитектурная дискуссия |
| RFC 1518 (англ.) | Присвоение адресов CIDR |
| RFC 1519 (англ.) | Междоменная маршрутизация |
| RFC 1591 (англ.) | Структура доменных имён |
| RFC 1661 (англ.) | PPP |
| RFC 1738 (англ.) | URL |
| RFC 1771 (англ.) | BGP версии 4 |
| RFC 1772 (англ.) | Приложение BGP |
| RFC 1789 (англ.) | Телефония по Интернет (заменён стандартами VoIP) |
| RFC 1812 (англ.) | Требования к маршрутизаторам IPv4 |
| RFC 1855 (англ.) | Руководство по Нетикету |
| RFC 1889 (англ.) | Транспорт реального времени |
| RFC 1905 (англ.) | SNMP |
| RFC 1907 (англ.) | SNMP версии 2 |
| RFC 1918 (англ.) RFC 1918 (рус.) | «Сеть 10» |
| RFC 1939 (англ.) RFC 1939 (рус.) | Протокол POP версии 3 (POP3) |
| RFC 2001 (англ.) RFC 2001 (рус.) | Расширения производительности TCP |
| RFC 2026 (англ.) | Процесс стандартизации в Интернете |
| RFC 2045 (англ.) | MIME |
| RFC 2046 (англ.) | |
| RFC 2047 (англ.) | |
| RFC 2048 (англ.) | |
| RFC 2049 (англ.) | |
| RFC 2060 (англ.) RFC 2060 (рус.) | IMAP версии 4 (IMAP4), заменён RFC 3501 |
| RFC 2131 (англ.) | DHCP |
| RFC 2223 (англ.) | Инструкции для авторов RFC |
| RFC 2246 (англ.) RFC 2246 (рус.) | SSL и TLS |
| RFC 2231 (англ.) | Кодировка символов |
| RFC 2328 (англ.) | OSPF |
| RFC 2401 (англ.) | Архитектура безопасности протокола IP (IPsec) |
| RFC 2453 (англ.) | RIP |
| RFC 2516 (англ.) RFC 2516 (рус.) | PPPoE |
| RFC 2525 (англ.) | Проблемы TCP |
| RFC 2535 (англ.) | Безопасность DNS |
| RFC 2581 (англ.) RFC 2581 (рус.) | Контроль заторов в TCP |
| RFC 2616 (англ.) | HTTP |
| RFC 2637 (англ.) | PPTP |
| RFC 2663 (англ.) | Трансляция сетевых адресов |
| RFC 2766 (англ.) | NAT-PT |
| RFC 2821 (англ.) RFC 2821 (рус.) | SMTP, заменён RFC 5321 |
| RFC 2822 (англ.) | Формат электронной почты |
| RFC 2865 (англ.) | RADIUS |
| RFC 2866 (англ.) RFC 2866 (рус.) | Средства учёта RADIUS |
| RFC 2960 (англ.) | SCTP |
| RFC 2980 (англ.) | Общие расширения NNTP, дополняет RFC 977, заменён RFC 3977 |
| RFC 3010 (англ.) | NFS |
| RFC 3031 (англ.) | Архитектура MPLS |
| RFC 3066 (англ.) | Языковые теги |
| RFC 3092 (англ.) | Этимология «Foo» |
| RFC 3098 (англ.) | Ответственная реклама по электронной почте |
| RFC 3160 (англ.) | Гид по IETF |
| RFC 3168 (англ.) RFC 3168 (рус.) | ECN |
| RFC 3261 (англ.) | SIP |
| RFC 3501 (англ.) | IMAP версии 4 издание 1 (IMAP4rev1) |
| RFC 3977 (англ.) | NNTP, заменяет RFC 977, дополняет RFC 2980 |
См. также
Ссылки
- Официальные источники
- Другие сайты
dic.academic.ru
RFC — это… Что такое RFC?
- регулирование потока рециркуляции
- предложение для обсуждения
- заявка на внесение изменений (в проект)
- запрос на изменение (RFC)
- запрос на изменение
- запрос комментариев — информационные документы интернета
- запрос для обсуждения
- де-факто стандарт Интернета
де-факто стандарт Интернета
досл. «предлагается к обсуждению»
Дословно, «request for comments» означает публикацию предложения по стандартизации с целью обсуждения. Фактически, к документам RFC относятся как к сложившимся стандартам.
Документы RFC можно свободно получить по адресу http://www.ietf.org/rfc/rfcN.txt, где N — номер документа.
[http://www.morepc.ru/dict/]
Тематики
- информационные технологии в целом
Синонимы
- «предлагается к обсуждению»
EN
запрос для обсуждения
Серия документов, начатая в 1969 году и содержащая описания набора протоколов Internet и связанную с ними информацию.
Не все (фактически, очень немногие) RFC описывают стандарты Internet, но все стандарты Internet описаны в RFC. Документы RFC можно найти на сервере IETF
[http://www.lexikon.ru/dict/net/index.html]
Тематики
- сети вычислительные
EN
запрос комментариев — информационные документы интернета
—
[ГОСТ Р 54325-2011 (IEC/TS 61850-2:2003)]]
Тематики
- релейная защита
EN
запрос на изменение
Формальное предложение на реализацию изменения. RFC включает в себя детальное описание предложенного изменения, и может быть записано в бумажном или электронном формате.
[http://www.dtln.ru/slovar-terminov]
Тематики
- информационные технологии в целом
EN
запрос на изменение
RFC
(ITIL Service Transition)
Формальное предложение на выполнение изменения. Запрос на изменения включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде. Термин «запрос на изменение» часто неверно употребляется в значениях «запись об изменении» или «изменение» само по себе.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
EN
request for change
RFC
(ITIL Service Transition)
A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
- информационные технологии в целом
EN
заявка на внесение изменений (в проект)
—
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
- энергетика в целом
EN
предложение для обсуждения
Серия нормативных документов, издаваемая с 1969 года под эгидой IETF в целях стандартизации и развития протоколов Internet. He все документы RFC являются официальными стандартами Internet. Часть из них носит рекомендательный характер, представляет справочный материал или содержит описание какой-либо проблемы. Концепция стандартизации определена документом RFC 2800, в котором описывается схема классификации протоколов в зависимости от их назначения и статуса (см. табл. R-4). Стандарты проходят три основные стадии рассмотрения: предложение, проект и окончательная версия стандарта. На этих стадиях им может быть присвоен один из трех статусов: обязательный, рекомендуемый или избирательного применения. В последнем случае может быть реализован один из нескольких вариантов протоколов по усмотрению разработчика. После завершения процесса согласования стандарту присваивается номер STD, который является одинаковым у всех спецификаций, которые логически связаны друг с другом (пример записи — STD13/RFC1034).
Таблица R-4. Классификация документов RFC
[Л.М. Невдяев. Телекоммуникационные технологии. Англо-русский толковый словарь-справочник. Под редакцией Ю.М. Горностаева. Москва, 2002]
Тематики
- электросвязь, основные понятия
EN
регулирование потока рециркуляции
(напр. теплоносителя в ядерном реакторе, дымовых газов в топке котла)
[А.С.Гольдберг. Англо-русский энергетический словарь. 2006 г.]
Тематики
- энергетика в целом
EN
- recirculation flow control
- RFC
Англо-русский словарь нормативно-технической терминологии. academic.ru. 2015.
normative_en_ru.academic.ru
RFC — Википедия. Что такое RFC
Рабочее предложение (англ. Request for Comments, RFC) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Название «Request for Comments» ещё можно перевести как «заявка (запрос) на отзывы» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.
История
Формат RFC появился в 1969 году при обсуждении проекта ARPANET, его предложил Стив Крокер и он же написал первый RFC. RFC 1 был опубликован 7 апреля 1969 г. и назывался «Host Software». Первые RFC распространялись в печатном виде на бумаге в виде обычных писем, но уже с декабря 1969 г., когда заработали первые сегменты ARPANET, документы начали распространяться в электронном виде.
Большинство ранних RFC были созданы в Калифорнийском университете Лос-Анджелеса и Стэнфордском исследовательском институте (англ.).
С 1969 по 1998 гг. бессменным и единственным редактором RFC был Джон Постел. После его смерти Общество Интернета (ISOC) поручило редактирование и публикацию RFC Институту информационных наук (англ.) Университета Южной Калифорнии.
Очерк истории RFC за 30 лет с 1969 по 1999 гг. представлен в RFC 2555.
Содержимое RFC
Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами, от англ. draft — черновой проект). Согласно RFC 2026, жизненный цикл стандарта выглядит следующим образом:
- Выносится на всеобщее рассмотрение интернет-проект (Internet Draft). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения.
- Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта (Proposed Standard), и свой номер RFC. Наличие программной реализации стандарта желательно, но не обязательно.
- Следующая стадия — проект стандарта (Draft Standard) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. В проекты стандартов ещё могут вноситься мелкие правки, но они считаются достаточно стабильными и рекомендуются для реализации.
- Высший уровень — стандарт Интернета (Internet Standard). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD. Список стандартов имеется в документе STD 1 (сейчас это RFC 5000, но нумерация может измениться). Из более чем трёх тысяч RFC этого уровня достигли только несколько десятков.
- Многие старые RFC замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических (Historic)
Практически все стандарты Глобальной сети существуют в виде опубликованных заявок RFC. Но в виде документов RFC выходят не только стандарты, но также концепции, введения в новые направления в исследованиях, исторические справки, результаты экспериментов, руководства по внедрению технологий, предложения и рекомендации по развитию существующих Стандартов и другие новые идеи в информационных технологиях:
- Экспериментальные (Experimental) спецификации содержат информацию об экспериментальных исследованиях, интересных для интернет-сообщества. Это могут быть, например, прототипы, реализующие новые концепции.
- Информационные (Informational) RFC предназначены для ознакомления общественности, не являются стандартами и не являются результатом консенсуса или рекомендациями. Некоторые проекты, не получившие статуса Предложенного стандарта, но представляющие интерес, могут быть опубликованы как Информационные RFC.
- Лучший современный опыт (Best Current Practice). Эта серия RFC содержит рекомендации по реализации стандартов, в том числе от сторонних организаций, а также внутренние документы о структуре и процедурах стандартизации.
Почти все стандарты разрабатываются под эгидой каких-либо научных или интернет-организаций (например W3C, IETF, консорциум Юникода, Интернет2).
Запросы на отзывы официально существуют только на английском языке. Строгих требований к оформлению нет. Встречаются RFC, написанные в строгом академическом стиле, иные — в дружеской неформальной манере. Существует традиция выпуска первоапрельских шуточных RFC, например, RFC 1149 рассказывает о передаче пакетов IP с помощью почтовых голубей.
Примеры популярных запросов на отзывы
| Номер RFC | Тема |
|---|---|
| RFC 768 (англ.) RFC 768 (рус.) | UDP |
| RFC 791 (англ.) RFC 791 (рус.) | IP |
| RFC 792 (англ.) RFC 792 (рус.) | ICMP |
| RFC 793 (англ.) RFC 793 (рус.) | TCP |
| RFC 821 (англ.) | SMTP, заменён RFC 2821 |
| RFC 822 (англ.) | Формат электронной почты, заменён RFC 2822 |
| RFC 826 (англ.) | Протокол разрешения адреса (ARP) |
| RFC 894 (англ.) RFC 894 (рус.) | IP по Ethernet |
| RFC 951 (англ.) | Протокол начальной загрузки (BOOTP) |
| RFC 959 (англ.) | FTP |
| RFC 977 (англ.) | NNTP — устаревший, дополнен RFC 2980 , заменён RFC 3977 |
| RFC 1034 (англ.) | DNS — концепция |
| RFC 1035 (англ.) | DNS — внедрение |
| RFC 1122 (англ.) RFC 1122 (рус.) | Требования к хосту 1 |
| RFC 1123 (англ.) RFC 1123 (рус.) | Требования к хосту 2 |
| RFC 1191 (англ.) RFC 1191 (рус.) | Определение MTU пути |
| RFC 1256 (англ.) | Обнаружение маршрутизатора в сети |
| RFC 1323 (англ.) | Высокопроизводительный протокол TCP |
| RFC 1350 (англ.) | TFTP |
| RFC 1403 (англ.) | Взаимодействие BGP и OSPF |
| RFC 1459 (англ.) RFC 1459 (рус.) | IRC |
| RFC 1498 (англ.) | Архитектурная дискуссия |
| RFC 1518 (англ.) | Присвоение адресов CIDR |
| RFC 1519 (англ.) | Междоменная маршрутизация |
| RFC 1591 (англ.) | Структура доменных имён |
| RFC 1661 (англ.) | PPP |
| RFC 1738 (англ.) | URL |
| RFC 1771 (англ.) | BGP версии 4 |
| RFC 1772 (англ.) | Приложение BGP |
| RFC 1789 (англ.) | Телефония по Интернет (заменён стандартами VoIP) |
| RFC 1812 (англ.) | Требования к маршрутизаторам IPv4 |
| RFC 1855 (англ.) | Руководство по Нетикету |
| RFC 1889 (англ.) | Транспорт реального времени |
| RFC 1905 (англ.) | SNMP |
| RFC 1907 (англ.) | SNMP версии 2 |
| RFC 1918 (англ.) RFC 1918 (рус.) | «Сеть 10» |
| RFC 1939 (англ.) RFC 1939 (рус.) | Протокол POP версии 3 (POP3) |
| RFC 2001 (англ.) RFC 2001 (рус.) | Расширения производительности TCP |
| RFC 2026 (англ.) | Процесс стандартизации в Интернете |
| RFC 2045 (англ.) | MIME |
| RFC 2046 (англ.) | |
| RFC 2047 (англ.) | |
| RFC 2048 (англ.) | |
| RFC 2049 (англ.) | |
| RFC 2060 (англ.) RFC 2060 (рус.) | IMAP версии 4 (IMAP4), заменён RFC 3501 |
| RFC 2131 (англ.) | DHCP |
| RFC 2223 (англ.) RFC 2223 (рус.) | Инструкции для авторов RFC |
| RFC 2246 (англ.) RFC 2246 (рус.) | SSL и TLS |
| RFC 2231 (англ.) | Кодировка символов |
| RFC 2328 (англ.) | OSPF |
| RFC 2401 (англ.) | Архитектура безопасности протокола IP (IPsec) |
| RFC 2453 (англ.) | RIP |
| RFC 2516 (англ.) RFC 2516 (рус.) | PPPoE |
| RFC 2525 (англ.) | Проблемы TCP |
| RFC 2535 (англ.) | Безопасность DNS |
| RFC 2581 (англ.) RFC 2581 (рус.) | Контроль заторов в TCP |
| RFC 2616 (англ.) | HTTP |
| RFC 2637 (англ.) | PPTP |
| RFC 2663 (англ.) | Трансляция сетевых адресов |
| RFC 2766 (англ.) | NAT-PT |
| RFC 2821 (англ.) RFC 2821 (рус.) | SMTP, заменён RFC 5321 |
| RFC 2822 (англ.) | Формат электронной почты |
| RFC 2865 (англ.) | RADIUS |
| RFC 2866 (англ.) RFC 2866 (рус.) | Средства учёта RADIUS |
| RFC 2960 (англ.) | SCTP |
| RFC 2980 (англ.) | Общие расширения NNTP, дополняет RFC 977, заменён RFC 3977 |
| RFC 3010 (англ.) | NFS |
| RFC 3031 (англ.) | Архитектура MPLS |
| RFC 3066 (англ.) | Языковые теги |
| RFC 3092 (англ.) | Этимология «Foo» |
| RFC 3098 (англ.) | Ответственная реклама по электронной почте |
| RFC 3160 (англ.) | Гид по IETF |
| RFC 3168 (англ.) RFC 3168 (рус.) | ECN |
| RFC 3261 (англ.) | SIP |
| RFC 3501 (англ.) | IMAP версии 4 издание 1 (IMAP4rev1) |
| RFC 3977 (англ.) | NNTP, заменяет RFC 977, дополняет RFC 2980 |
См. также
Ссылки
- Официальные источники
- Другие сайты
wiki.sc
| Номер RFC | Описание | Ссылка | Примечание |
|---|---|---|---|
| RFC 822 | Формат электронной почты, заменён RFC 2822 | Bog BOS: Формат сообщений интернет (от RFC822 к RFC2822) | |
| RFC 2822 | Формат электронной почты | ||
| RFC 3550 | Описан RTP -Real-Time Transport Protocol | ||
| RFC 3261 | Описан Описание RFC протокола SIP: Session Initiation Protocol | 3261 | Документ довольно объемный, но тем, кто желает стать специалистом в Asterisk, рекомендуем прочитать по крайней мере первые 100 страниц и разобраться,как устанавливать соединения, поскольку эти знания будут необходимы для работы с историей SIP (sip debug из консоли Asterisk) и поиска с ее помощью причины невозможности установления соединений. |
| RFC 1918 | Address Allocation for Private Internets | Описаны частные, серые, фейковый IP | 10.0.0.0 — 10.255.255.255 (10/8 prefix) 172.16.0.0 — 172.31.255.255 (172.16/12 prefix) 192.168.0.0 — 192.168.255.255 (192.168/16 prefix) |
| RFC 1321 | The MD5 Message-Digest Algorithm | Наиболее важные детали русского перевода RFC 1321 | |
| RFC 2425 | MIME Content-Type for Directory Information | RFC 2425 | |
| RFC 2426 | vCard MIME Directory Profile | RFC 2426 | |
| RFC 2516 | Описан принцип работы протокола PPPoE (Point to Point Protocol over Ethernet) | ||
| 3711 | |||
| 3875 | The Common Gateway Interface (CGI) Version 1.1 | ||
| 4771 | |||
| 3330 | Special-Use IPv4 Addresses. | Зарезервированные адреса IPv4 | |
| 1392 | Internet Users’ Glossary, например Хакер | ||
| RFC 2131 | RFC 2131 | Описание протокола Настройка DHCP сервера Linux, FreeBSD | |
| RFC 2606 | RFC 2606 | Зарезервированные доменные имена, например example.com, example.net и др. | |
| RFC 821 | FQDN | Fully Qualified Domain Name — полностью определённое имя домена | |
| RFC 3761 | Технология ENUM | ||
| RFC 2068 | Описывает протокол Методы и структура протокола HTTP | RFC 2068 Русский- описывает протокол Методы и структура протокола HTTP/1.1. RFC 2616:Hypertext Transfer Protocol — HTTP/1.1. rfc2068 Протокол передачи гипертекста более подробный перевод на русский. | |
| RFC 959 | RFC 959 | Описан протокол Протокол FTP протокол передачи файлов | |
| RFC 4954 | RFC 4954 | Расширение диалога SMTP — простой протокол передачи почты командой AUTH | |
wiki.dieg.info
RFC — это… Что такое RFC?
RFC — steht für: Request for Comments, eine englische Bezeichnung für eine Aufforderung zum Kommentieren eines Vorschlags; bezeichnet oft eine Reihe von technischen und organisatorischen Dokumenten zum Internet RFC Editor, eine Gruppe innerhalb der… … Deutsch Wikipedia
RFC — Saltar a navegación, búsqueda El término RFC puede referirse a: El acrónimo de Request For Comments. El Registro Federal de Contribuyentes. Remote Function Call, otra forma de llamar al Remote Procedure Call. Al Cuerpo Aéreo Real inglés. Obtenido … Wikipedia Español
RFC — RFC, a three letter initialism, may refer to: Technology * Request for Comments, formalized memoranda addressing Internet standards * Request for Change, a call to change information technology infrastructure * Remote function call, from within… … Wikipedia
RFC — Reconstruction Finance Corporation Short Dictionary of (mostly American) Legal Terms and Abbreviations … Law dictionary
RFC — [Abk. für Request for Comments, dt. » Aufforderung zu Stellungnahmen«], eine bereits 1969 begonnene Serie von Dokumenten über die Standards im Internet bzw. seinem damaligen Vorläufer, dem ARPANet. Die RFCs werden von der IETC herausgegeben;… … Universal-Lexikon
RFC — (Request For Comments) n. series of documents containing suggestions for new or updated Internet standards (Computers) … English contemporary dictionary
RFC — ► ABBREVIATION ▪ Rugby Football Club … English terms dictionary
RFC — Эта статья о Request for Comments. Рабочее предложение (англ. Request for Comments, RFC) документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во… … Википедия
RFC — Request for comments Pour les articles homonymes, voir RFC (homonymie). Steve Crocker, auteur de la … Wikipédia en Français
Rfc — Die Abkürzung RFC wird für eine Reihe von Gegenständen verwendet: Request for Comments, eine englische Bezeichnung für eine Aufforderung zum Kommentieren eines Vorschlags; bezeichnet oft eine Reihe von technischen und organisatorischen Dokumenten … Deutsch Wikipedia
RFC — ● ►en sg. f. ►INTERNET Request For Comment. Document au contenu variable, sur l Internet. Ce peut être de la documentation générale, des standards, la description d un protocole, etc. Elles sont accessibles sur ftp.inria.fr ou ftp.enst.fr, en FTP … Dictionnaire d’informatique francophone
dic.academic.ru
RFC — это… Что такое RFC?
RFC — steht für: Request for Comments, eine englische Bezeichnung für eine Aufforderung zum Kommentieren eines Vorschlags; bezeichnet oft eine Reihe von technischen und organisatorischen Dokumenten zum Internet RFC Editor, eine Gruppe innerhalb der… … Deutsch Wikipedia
RFC — Saltar a navegación, búsqueda El término RFC puede referirse a: El acrónimo de Request For Comments. El Registro Federal de Contribuyentes. Remote Function Call, otra forma de llamar al Remote Procedure Call. Al Cuerpo Aéreo Real inglés. Obtenido … Wikipedia Español
RFC — RFC, a three letter initialism, may refer to: Technology * Request for Comments, formalized memoranda addressing Internet standards * Request for Change, a call to change information technology infrastructure * Remote function call, from within… … Wikipedia
RFC — Reconstruction Finance Corporation Short Dictionary of (mostly American) Legal Terms and Abbreviations … Law dictionary
RFC — [Abk. für Request for Comments, dt. » Aufforderung zu Stellungnahmen«], eine bereits 1969 begonnene Serie von Dokumenten über die Standards im Internet bzw. seinem damaligen Vorläufer, dem ARPANet. Die RFCs werden von der IETC herausgegeben;… … Universal-Lexikon
RFC — (Request For Comments) n. series of documents containing suggestions for new or updated Internet standards (Computers) … English contemporary dictionary
RFC — ► ABBREVIATION ▪ Rugby Football Club … English terms dictionary
RFC — Эта статья о Request for Comments. Рабочее предложение (англ. Request for Comments, RFC) документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во… … Википедия
RFC — Request for comments Pour les articles homonymes, voir RFC (homonymie). Steve Crocker, auteur de la … Wikipédia en Français
Rfc — Die Abkürzung RFC wird für eine Reihe von Gegenständen verwendet: Request for Comments, eine englische Bezeichnung für eine Aufforderung zum Kommentieren eines Vorschlags; bezeichnet oft eine Reihe von technischen und organisatorischen Dokumenten … Deutsch Wikipedia
RFC — ● ►en sg. f. ►INTERNET Request For Comment. Document au contenu variable, sur l Internet. Ce peut être de la documentation générale, des standards, la description d un protocole, etc. Elles sont accessibles sur ftp.inria.fr ou ftp.enst.fr, en FTP … Dictionnaire d’informatique francophone
dic.academic.ru
Описание RFC протокола SIP [АйТи бубен]
Протокол Session Initiation Protocol (SIP), обычно применяемый в VoIP-телефонах (как аппаратных, так и программных), отвечает за установку и разъединение соединения, а также за любые изменения, происходящие во время соединения, такие как переадресации. Назначение SIP – помочь двум конечным точкам поговорить друг с другом (по возможности напрямую). Протокол SIP – это просто протокол обмена сигналами, то есть его задачей является лишь обеспечить возможность двум конечным точкам говорить друг с другом, но не работа с носителем вызова (голосом). Передача голоса осуществляется с помощью другого протокола – Real-Time Transport Protocol (транспортный протокол реального времени – RTP; RFC 3550) – для передачи медиа-данных непосредственно между двумя конечными точками.
VoIP (Voice over IP; IP-телефония) — система связи, обеспечивающая передачу речевого сигнала по сети Интернет или по любым другим IP-сетям. Сигнал по каналу связи передаётся в цифровом виде и, как правило, перед передачей преобразовывается (сжимается) с тем, чтобы удалить избыточность.
Тем, кто соберётся делать собственную реализацию протокола SIP, пригодится список RFC, описывающих протокол и его дополнения:
- 2543: Первоначальное описание SIP/2.0
- RFC 2976: передача информации, не изменяющей состояние сессии (метод INFO)
- RFC 2279: Сообщения протокола SIP (запросы и ответы)
- RFC 3262: Расширение протокола SIP: метод Provisional Response ACKnowledgement (PRACK) и тэг 100rel
- RFC 3263: поиск SIP серверов с помощью DNS (записи SRV)
- RFC 3265: подписка на получение уведомлений о событии (методы SUBSCRIBE и NOTIFY)
- RFC 3311: Обновление сессии без изменения диалога (метод UPDATE)
- RFC 3372: модификация SIP-T (интерконнект ISUP — SIP)
- RFC 3398: сопоставление параметров ISUP и SIP (Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping)
- RFC 3428: Расширение SIP для передачи мгновенных сообщений (Instant Messaging) и метод MESSAGE
- RFC 3515: метод REFER
- RFC 3903: публикация события на сервере (метод PUBLISH)
- RFC 4235: Пакет событий, инициируемых по INVITE (An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP))
- RFC 4262: SIP Event Lists (SUBSCRIBE, NOTIFY, Presence)
- RFC 5806: Diversion Indication in SIP
SIP- запросы
Запросы: В первоначальной версии протокола SIP (RFC 3261) было определено шесть типов запросов. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т. д. Тип запроса указывается в стартовой строке.
- INVITE — Приглашает пользователя к сеансу связи. Обычно содержит Протокол SDP -описание сеанса. Запрос INVITE, который отправлен для уже установленного сеанса связи, называется методом re-INVITE. re-INVITE позволяет менять адреса или порты сеансов, может добавлять поток медиаданных, удалять поток медиаданных, и т.д.
АСК — Подтверждает приём ответа на запрос INVITE.
BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
OPTIONS — Запрашивает информацию о функциональных возможностях терминала. Передача информации о возможностях вызывающего и вызываемого SIP телефонов.
Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:
- PRACK — временное подтверждение (RFC 3262)
- SUBSCRIBE — подписка на получение уведомлений о событии (RFC 3265)
- NOTIFY — уведомление подписчика о событии (RFC 3265)
- PUBLISH — публикация события на сервере (RFC 3903)
- INFO — передача информации, которая не изменяет состояние сессии (RFC 2976)
- REFER — запрос получателя о передаче запроса SIP (RFC 3515)
- MESSAGE — передача мгновенных сообщений средствами SIP (RFC 3428)
- UPDATE — модификация состояния сессии без изменения состояния диалога (RFC 3311)
Адресация SIP логическая, того же типа, что URL в Методы и структура протокола HTTP. Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов — так называемые SIP URL (Universal Resource Locators).
SIP- адреса бывают четырех типов:
Таким образом, адрес состоит из двух частей. Первая часть — это имя пользователя, зарегистрированного в домене или на рабочей станции. Если вторая часть адреса идентифицирует какой-либо шлюз, то в первой указывается телефонный номер абонента.
Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP- адреса устройства необходимо обратиться к службе доменных имен — Что такое DNS. Если же во второй части SIP- адреса размещается IP- адрес, то с рабочей станцией можно связаться напрямую.
В начале SIP- адреса ставится слово «sip:», указывающее, что это именно SIP- адрес. Примеры SIP- адресов:
sip: [email protected] sip: [email protected] sip: [email protected]
В SIP поддерживает функции messaging и presence. Первая обеспечивает обмен в реальном времени короткими сообщениями (как ICQ на ПК или SMS в сетях GSM), вторая позволяет определять состояние абонента, т. е. на месте ли он, не занят ли и т. д. (в ICQ тоже есть такая возможность). Благодаря этим двум функциям SIP позволяет реагировать на события, а также рассылать сообщения «по событию».
SIP поддерживает специальный довольно мощный язык CPL (Call Processing Language -язык обработки звонков) на основе Введение в XML, предназначенный для написания телефонных скриптов, позволяющий указать, кто кому когда и зачем звонит, что делать, если трубку не берут или берут не там, и т. д. В силу всего этого в рамках SIP легко строить самые разнообразные сервисы.
Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.
Поскольку все современные ERP-, CRM- и т. п. системы работают по протоколу IP, SIP без особых проблем интегрируется с ними (в отличие от H.323, которому его телефонная природа мешает взаимодействовать с большинством приложений).
между пользователями
Первый пользователь снимает трубку и набирает номер, SIP-клиент генерирует сигнал INVITE (приглашение), у второго пользователя звонит телефон, его SIP-клиент выдает сообщение 180 (Ringing, звонок), затем пользователь берет трубку, SIP-клиент выдает сообщение 200 (OK), первый SIP-клиент посылает второму сигнал ACK (подтверждение) – и далее начинается передача голосового потока по протоколу RTP (Real-time Transport Protocol). Когда разговор окончен и один из пользователей вешает трубку, SIP-клиент посылает сигнал BYE. Вот и все.
в сети предприятия
Но такая схема абсолютно неэффективна, когда клиентов в сети не два, а два миллиарда. SIP-сетям с большим числом пользователей необходима инфраструктура, и ее создают различные серверы SIP. Сервер регистрации (registrar) занимается учетом и авторизацией пользователей, сервер локализации (allocation) ищет их и определяет их местонахождение, сервер переадресации (redirect) переводит звонки абонентам туда, где они фактически находятся в данный момент, – если меня, например, нет в Москве, потому что я уехал в Америку, сервер переведет звонок на мой американский номер. Наиболее сложные функции ложатся на прокси-сервер (SIP Proxy), обеспечивающий взаимодействие внутренней (например, учрежденческой) IP-телефонной сети с внешним миром, – именно он определяет все политики, правила общения и т. д. Существуют и другие серверы SIP (например, сервер конференций), но они менее важны. На рисунке показано, как может работать SIP в сети предприятия.
Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.
До выхода SIP 2.0, который поддерживается любым современным оборудованием и ПО, разрешалась передача паролей чуть ли не открытым текстом (HTTP Basic Authentication), что в настоящее время вообще немыслимо. Однако, применяемая в SIP 2.0 авторизация на основе дайджеста от случайной строки и пароля (HTTP Хеш-сумма Authentication), также относительно уязвима. Ведь если злоумышленник перехватывает случайную строку и полученный дайджест (MD5 или SHA-1), он имеет возможность автономно подобрать пароль (по словарю или перебором), и ему не понадобится даже подключаться к SIP-серверу. Это главная причина, по которой настоятельно рекомендуется использовать сложные пароли длиной не менее 10 символов.
Прохождение авторизации в SIP протоколе зависит от «Что такое realm sip?», различного для каждого защищаемого домена.
md5 алгоритм на входе принимает любую длину символов и на выходе выдать 128-битный отпечаток (finger-print) или профиль сообщения (message digest), которое было подано на вход алгоритма. Гипотетически считается, что два сообщения, которые имеют один и тот же профиль сообщения или выработаны любым сообщением, имеют определенный профиль сообщения.
Message digest — коротка цифровая строка фиксированной длины, формируется из более длинного сообщения с использованием специального алгоритма. Алгоритм md5 назначен для цифровой подписи (digital signature) приложений, где большие файлы должны быть «сжаты» в безопасный способ, до того как они будут закриптованы с помощью публичного или скрытого ключа с помощью криптосистемы с открытым ключом, например RSA. Digital signature — цифровая подпись, которая является уникальным электронным идентификатором, обеспечивающим проверку сообщения с установлением подлинности отправителя и гарантии то, что документ не был изменен с момента подписания.
Последовательность действий для авторизации клиентского оборудования на сервере.
Вариант №1. Абонент: высылает серверу сообщение с заголовком REGISTER. Если в настройках абонента не указан secret, то этого достаточно, сервер присылает ответ SIP/2.0 200 OK и процесс регистрации заканчивается.
Вариант №2. Если secret указан. Сервер на запрос REGISTER присылает ответ SIP/2.0 401 Unauthorized (нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль).
На третьем этапе абонент высылает серверу строку в сообщении REGISTER
Authorization: Digest username="203",realm="asterisk",nonce="29b8191d",uri="sip:local", response="7306cfba1b131f2f04363b68d908f855",algorithm=MD5
Где параметр response — строка, состоящая из 32 шестнадцатиричных разрядов и удостоверяющая, что пользователю известен пароль. Формируется с помощью применения функции хеширования к значениям nonce, nc, cnonce, qop, uri, username, realm, типу запроса и паролю password. По умолчанию хеширование производится по алгоритму MD5.
- Вариант №3. Если используется внешний сервер для аутентификации (процедура проверки подлинности) по протоколу RADIUS сервер. Сервер на запрос REGISTER присылает ответ SIP/2.0 407 Proxy Authentication Required — необходима аутентификация на прокси-сервере).
SIP URI – это схема адресации SIP, используемая для вызова абонента с помощью SIP. Другими словами, SIP URI является номером SIP-телефона пользователя. SIP URI похож на адрес электронной почты и записывается в следующем формате:
SIP URI = sip:x@y:Port Где x=имя пользователя и y=хост (домен или IP)
Примеры:
sip:[email protected] sip:[email protected] sip:[email protected]
sip.txt · Последние изменения: 2018/11/01 16:15 (внешнее изменение)
wiki.dieg.info