Что такое RFC
RFC (Request for Comments) — запрос комментариев (или заявка на обсуждение или тема для обсуждения). Документы содержащие технические спецификации и стандарты, широко применяемые в Интернет. В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.
Документация и переводы на русский язык RFC
| Номер 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. Методы и структура протокола HTTP | RFC 2068 Русский- описывает протокол Коды состояния HTTP. Методы и структура протокола HTTP/1.1. RFC 2616:Hypertext Transfer Protocol — HTTP/1.1. rfc2068 Протокол передачи гипертекста более подробный перевод на русский. | |
| RFC 959 | RFC 959 | Описан протокол Раздел FTP: Протокол FTP, серверы, клиенты FTP для Linux и Windows | |
| RFC 4954 | RFC 4954 | Расширение диалога SMTP — простой протокол передачи почты командой AUTH |
11 Самых Популярных Статей
- ulimit (limits.conf) управление ограничениями ресурсов ОС Linux
- 7 способов сравнения файлов по содержимому в Windows или Linux
- Что такое страны tier 1,2,3 и как правильно выбрать ГЕО для рекламной кампании
- Настройка, использование GitLab CI/CD
- Что означает «> /dev/null 2>&1» или перенаправление STDIN, STDOUT и STDERR?
- Настройка и использование сервера OpenVPN в Linux
- PostgreSQL: создать БД, пользователя, таблицу, установить права
- Виды кодировок символов
- Использование rsync в примерах
- my.cnf примеры конфигурации MySQL, MariaDB
- dig проверка DNS сервера
11 Самых Популярных Обзоров
- ТОП 4 лучших антидетект браузеров в 2023 (Бесплатные & Платные)
- Обзор и отзывы о Namecheap в 2023 году
- Хостинг Zomro (Зомро)
- Обзор браузера Dolphin
- ТОП 3 Проверенных VPN, Прокси, Хостинг VPS Турция в 2023
- Что такое абузоустойчивый хостинг (bulletproof)?
- Обзор и отзывы о 4VPS (FourServer) в 2023 году
- Обзор и отзывы AstroProxy в 2023 году
- Обзор и отзывы о PQ Hosting в 2023 году
- Обзор и отзывы о Hostinger в 2023 году: преимущества и недостатки
- Проверенные VPS / VDS хостинг провайдеры
Rfc что это такое
Рабочее предложение (англ. 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 замещены более новыми версиями под новыми номерами или вышли из употребления. Такие документы получают статус исторических ( 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 |
| 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 |
См. также
Ссылки
- База данных RFC (англ.)
- Запросы RFC на сайте IETF (англ.)
- Русские Переводы RFC (рус.)
- Стандарты Интернета
Rfc что это такое
Запрос на комментарии (Request for Comments, RFC) — это официальный документ рабочей группы по проектированию Интернета (IETF), в котором содержатся спецификации и организационные замечания по темам, связанным с интернетом и компьютерными сетями.
Практически все стандарты веба существуют в качества RFC-публикаций, посвященных таким темам, как маршрутизация, адресация, транспортные технологии и многим другим.
IETF — большое международное сообщество, в которое входят исследователи, поставщики, операторы и проектировщики сетей, работающие над функционированием и развитием интернета. Примеры:
- RFC 791 — IPv4,
- RFC 826 — ARP,
- RFC 2131 — DHCP.
Жизненный цикл RFC
Все начинается с первоначального проекта, называемого Internet-Draft (I-D). Этот проект обычно создается отдельным человеком или небольшой группой. Затем I-D принимается рабочей группой, которая рассматривает, улучшает и пересматривает содержание документа.
Рабочие группы состоят из добровольцев со всего мира и включают в себя таких членов, как производители оборудования, разработчики программного обеспечения и операторы сетей. Группы организованы по конкретным технологическим областям и управляются директорами областей.
RFC выпускаются в основном Архитектурным советом Интернета (IAB), Исследовательской целевой группой Интернета (IRTF) и IETF.
Однако отдельные лица или группы, не входящие в эти организации, могут подавать RFC на рассмотрение, хотя подобные индивидуальные заявки встречаются не так часто.
После того как RFC прошел через процесс рассмотрения и редактирования, он получает окончательную проверку на наличие ошибок, а также на стиль и редакционные вопросы. После подготовки удовлетворительного документа, Центр производства RFC (RPC) присваивает RFC уникальный номер и публикует его.
Прямая маршрутизация — определения и стандарты RFC
В этой статье описывается, как прямая маршрутизация телефонов Teams реализует протоколы rfc-standard. Эта статья предназначена для администраторов голосовой связи, которые отвечают за настройку подключения между локальным пограничным контроллером сеансов (SBC) и прокси-службой протокола SIP.
Клиент SBC взаимодействует со следующими компонентами в серверной части Microsoft Teams:
- Прокси-сервер SIP для сигнализации. Этот компонент является компонентом прямой маршрутизации с выходом в Интернет, который обрабатывает sip-подключения (TLS) между SBC и прямой маршрутизацией.
- Обработчики мультимедиа для мультимедиа. Этот компонент является компонентом прямой маршрутизации с выходом в Интернет, который обрабатывает трафик мультимедиа. Этот компонент использует протоколы SRTP и SRTCP.
Дополнительные сведения о прямой маршрутизации см. в разделе Прямая маршрутизация телефонов Teams.
Дополнительные сведения о том, как прямая маршрутизация реализует протокол SIP, см. в разделе Прямая маршрутизация — протокол SIP.
Стандарты RFC
Прямая маршрутизация соответствует стандартам RFC. SBC, подключенный к прямой маршрутизации, также должен соответствовать следующим RFC (или их преемникам).
Стандарты, применимые к устройствам, поддерживающим режим обхода без мультимедиа
Следующие стандарты применимы к устройствам, поддерживающим только режим обхода без мультимедиа.
- ПРОТОКОЛ SIP RFC 3261: протокол инициации сеанса
- RFC 3325. Частное расширение протокола инициации сеанса для утверждения удостоверения в доверенных сетях — разделы об обработке заголовка P-Asserted-Identity. Прямая маршрутизация отправляет P-Asserted-Identity с заголовками идентификатора конфиденциальности.
- RFC 4244 Расширение протокола SIP для необходимых сведений журнала. Дополнительные сведения см. в статье Описание протокола SIP маршрутизации.
- RFC 3892 Механизм Referred-By протокола инициации сеанса
- RFC 3891 Заголовок «Replaces» для протокола sip (SIP)
- RFC 6337 Использование модели предложения и ответа по протоколу SIP. См. раздел «Отклонения от RFC».
- RFC 3711 и RFC 4771. Защита трафика RTP с помощью SRTP. SBC должен иметь возможность устанавливать ключи с помощью SDES.
- RFC 8035 Уточнение предложений и ответов по протоколу описания сеанса (SDP) для мультиплексирования RTP/RTCP
Стандарты, применимые к устройствам, поддерживающим режим обхода мультимедиа
В дополнение к стандартам, перечисленным как применимые к режиму nonbypass, для режима обхода мультимедиа используются следующие стандарты:
- RFC 5245 Interactive Connectivity Establishment (ICE) для обхода мультимедиа. SBC должен поддерживать следующее:
- ICE Lite — клиенты Teams являются полными клиентами ICE
- Перезапуски ICE. См. дополнительные сведения о варианте использования перезапусков ICE и примерах в разделе Перезапуск ICE: вызов обхода мультимедиа, перенесенный в конечную точку, которая не поддерживает обход мультимедиа
Стандарты, применимые к поддержке передачи сведений о местоположении поставщикам E911
Отклонения от RFC
В следующей таблице перечислены разделы RFC, в которых реализация SIP или стека мультимедиа корпорации Майкрософт отклоняется от стандартного:
RFC и разделы Описание Отклонение RFC 6337, раздел 5.3 Удержание и возобновление мультимедиа RFC позволяет использовать «a=inactive», «a=sendonly», a=recvonly» для размещения вызова на удержание. Прокси-сервер SIP поддерживает только «a=inactive» и не понимает, отправляет ли SBC «a=sendonly» или «a=recvonly». RFC 6337, раздел 5.4 Поведение при получении SDP с c=0.0.0.0 RFC3264 требуется, чтобы агент был способен получать SDP с адресом подключения 0.0.0.0. В этом случае это означает, что ни RTP, ни RTCP не должны отправляться в одноранговый узел. Прокси-сервер SIP не поддерживает этот параметр. RFC 3261, раздел 25 Дополненная BNF для протокола SIP Символ «#» должен быть отправлен как «%23» Прокси-сервер SIP отправляет символ «#» в неэкранированном запросе URI. Рекомендации по транспортировке TCP/TLS
При отправке SIP-запроса (нового или в диалоге) прокси-сервер Microsoft SIP может открыть новое подключение TCP/TLS или повторно использовать существующее подключение, если оно существует.
- Существует не более двух подключений TCP/TLS для каждого удаленного полного доменного имени или IP-адреса на каждую виртуальную машину прокси-сервера SIP. Перед отправкой запроса SIP прокси-сервер SIP проверяет наличие активных TCP-подключений с разрешенным IP-адресом целевого SBC/Trunk FQDN. Если два подключения существуют, они используются повторно. Если два подключения не существуют, открывается новое подключение.
- Эта логика соответствует виртуальной машине прокси-сервера SIP.
- IP-адреса прокси SIP обслуживаются несколькими виртуальными машинами в каждом регионе.
- С точки зрения SBC может быть несколько входящих прокси-подключений из всех регионов прокси-сервера SIP.
- Исходящие TCP-подключения прокси SIP только для исходящих запросов SIP-прокси (к SBC) и связанных ответов.
- Входящий прокси-сервер SIP TCP-подключений (из SBC) обслуживает только входящие SIP-запросы и связанные ответы.
Политики времени ожидания
- Время ожидания простоя TCP прокси-сервера SIP составляет две минуты. Таймер сбрасывается при выполнении транзакции SIP через подключение.
- Прокси-сервер SIP отправляет приложение CRLF в соответствии с RFC 5626: управление подключениями Client-Initiated в протоколе инициации сеанса (SIP).
- При сохранении активности таймер простоя TCP не сбрасывается.
- CRLF, отправленный поставщиком SBC, сбрасывает таймер простоя TCP.
Notes
- Рекомендуется, чтобы SBC активно повторно использует подключения, например прокси-сервер SIP. Этот метод экономит время, необходимое для подключений TCP и TLS.
- SBC должен обновлять подключение по крайней мере один раз в час.
- При отправке нового сертификата SBC он должен обновить все подключения.
- При обновлении конфигураций домена рекомендуется обновить подключения SBC. В противном случае после обновления внутреннего кэша прокси-сервера SIP будет применена новая конфигурация — до четырех часов.
Рабочие режимы
Существует два режима работы прямой маршрутизации:
- Без обхода мультимедиа , при котором весь трафик RTP проходит между клиентом Teams, обработчиками мультимедиа и SBC.
- С обходом мультимедиа , в котором все rtp-носители передаются между конечными точками Teams и SBC.
Трафик SIP всегда проходит через прокси-сервер SIP.
DTMF
Встроенный DTMF не поддерживается стеком мультимедиа.