Введение в веб- технологии
Интернеет — всемирная система объединённых компьютерных сетей для хранения и передачи информации. Часто упоминается как Всемирная сеть и Глобальная сеть, а также просто Сеть. Построена на базе стека протоколов TCP/IP. Сеть Веб представляет собой глобальное информационное пространство, основанное на физической инфраструктуре Интернета и протоколе передачи данных HTTP . https://ru.wikipedia.org/wiki/Интернет https://ru.wikipedia.org/wiki/Всемирная_паутина
Поставщик услуг Интернета
Интернет — самая большая в мире сеть, не имеющая единого центра управления ( децентрализованная ), но работающая по единым правилам и предоставляющая своим пользователям единый набор услуг. Интернет можно рассматривать как «сеть сетей», каждая из которых управляется независимым оператором – поставщиком услуг ( провайдером ) Интернета ( ISP , Internet Service Provider).
Услуги и категории Интернет-провайдеров
К основным услугам интернет-провайдеров относят: широкополосный доступ в Интернет , коммутируемый доступ в Интернет, беспроводной доступ в Интернет, выделение дискового пространства для хранения и обеспечения работы сайтов ( хостинг ), поддержка электронных почтовых ящиков или виртуального почтового сервера , размещение оборудования клиента на площадке провайдера ( колокация ), аренда выделенных и виртуальных серверов ( VPS , VDS), резервирование данных .
В соответствии с предоставляемыми услугами их можно разделить на категории: провайдеры доступа, хостинг-провайдеры , магистральные провайдеры, канальные провайдеры, провайдеры последней мили (канал, соединяющий конечное (клиентское) оборудование с узлом доступа провайдера ).
Хост (host)
С точки зрения пользователей Интернет представляет собой набор информационных ресурсов, рассредоточенных по различным сетям, включая ISP-сети (провайдеры), корпоративные сети и отдельные компьютеры домашних пользователей. Каждый отдельный компьютер в данной сети называется хостом (от английского термина host).
RFC и стандартизация
“Тема для обсуждения”, “запрос на отзывы” ( англ. Request for Comments, RFC ) — документ из серии пронумерованных информационных документов Интернета , содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета ( англ. Internet Society, ISOC ). https://ru.wikipedia.org/wiki/RFC Несмотря на название, запросы на отзывы RFC сейчас рассматриваются как стандарты Интернета (а рабочие версии стандартов обычно называют драфтами , от англ. draft — проект). Согласно RFC 2026 , жизненный цикл стандарта выглядит следующим образом: 1. Выносится на всеобщее рассмотрение интернет-проект ( Internet Draft ). Проекты не имеют официального статуса и удаляются из базы через шесть месяцев после последнего изменения. 2. Если проект стандарта оказывается достаточно удачным и непротиворечивым, он получает статус предложенного стандарта ( Proposed Standard ), и свой номер RFC. 3. Следующая стадия — проект стандарта ( Draft Standard ) — означает, что предложенный стандарт принят сообществом, в частности, существуют две независимые по коду совместимые реализации разных команд разработчиков. 4. Высший уровень — стандарт Интернета ( Internet Standard ). Это спецификации с большим успешным опытом применения и зрелой формулировкой. Параллельно с нумерацией RFC они имеют свою собственную нумерацию STD.
Примеры популярных RFC
RFC 791 — IP RFC 793 — TCP RFC 959 — FTP RFC 1034 — DNS — концепция RFC 1035 — DNS — внедрение RFC 1591 — Структура доменных имен RFC 1738 — URL RFC 2231 — Кодировка символов RFC 2616 — HTTP RFC 2822 — Формат электронной почты
Модель OSI
Сетевая модель OSI ( англ. open systems interconnection basic reference model — базовая эталонная модель взаимодействия открытых систем) — сетевая модель стека сетевых протоколов OSI/ISO. В связи с затянувшейся разработкой протоколов OSI, в настоящее время основным используемым стеком протоколов является TCP/IP, разработанный ещё до принятия модели OSI и вне связи с ней.
RFCs
RFC documents contain technical specifications and organizational notes for the Internet.
RFCs produced by the IETF cover many aspects of computer networking. They describe the Internet’s technical foundations, such as addressing, routing, and transport technologies. RFCs also specify protocols like TLS 1.3, QUIC, and WebRTC that are used to deliver services used by billions of people every day, such as real-time collaboration, email, and the domain name system.
Only some RFCs are standards. Depending on their maturity level and what they cover, RFCs are labeled with different statuses: Internet Standard, Proposed Standard, Best Current Practice, Experimental, Informational, and Historic.
The RFC Series includes documents produced by the IETF, the Internet Architecture Board (IAB), the Internet Research Task Force (IRTF), and independent submitters. All RFCs are published by the RFC Editor, which is the authoritative source for retrieving RFCs.
RFCs usually begin as Internet-Drafts (I-Ds) written by an individual or a small group. In the IETF, these are then usually adopted by a working group, and improved and revised. Less often, I-Ds are considered within the IETF as “individual submissions” sponsored by an Area Director. While not every I-D becomes an RFC, a well-defined set of processes (also documented in RFCs) guides the consideration and progression of a document. When they are published, RFCs are freely available online.
Software developers, hardware manufacturers, and network operators around the world voluntarily implement and adopt the technical specifications described by RFCs.
The IETF recognizes that security vulnerabilities will be discovered in IETF protocols and welcomes their critical evaluation by researchers. The Internet Engineering Steering Group has provided guidance on how to report vulnerabilities believed to be discovered in IETF protocols.
The first document in this series, RFC 1, was written in 1969. It was soon followed by others, including those that describe the core Internet Protocol (IP) still used in the Internet today. RFCs started as informal technical notes and the name originally stood for “Request For Comments” but now they are simply known as RFCs. The collaborative process used to develop early RFCs remains an important part of the IETF spirit. Today, there are more than 9000 individually numbered documents in the series.
RFC — лучший путеводитель по стандартам
Часто в процесе разработки какого либо приложения возникают вопрос о свойствах тех или иных объэктах, какой разделитель использовать для параметров, какая максимальная длина может быть для тех или иных параметров, например максимальная длина для E-Mail адреса — на все эти вопросы можно найти ответ в RFC докумендах. RFC в переводе с английского означает «Запрос комментариев» (англ. Request for Comments, RFC) «Request for Comments» ещё можно перевести как «заявка на обсуждение» или «тема для обсуждения». В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (англ. Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.
Максимальная длина E-Mail адреса
Так например если мы хотим выяснить максимально возможную длину для E-Mail адреса, то нам следует обратится к спецификации «Mail Transfer Protocol» воспользовавшись страницей поиска. В результате могут быть RFC стандарты с одинаковым наименованием и разным номером RFC, в таком случае следует дополнительно обращать внимание на значение в графе «Status». Так например по нашему запросу «Mail Transfer Protocol» мы получили примерно такой результат:
Document Title Date Status -------------------------------------------------------------------------------- RFC 772 Mail Transfer Protocol 1980-09 RFC 772 (Unknown) RFC 780 Mail Transfer Protocol 1981-05 RFC 780 (Unknown) . RFC 788 Simple Mail Transfer Protocol 1981-11 RFC 788 (Unknown) RFC 821 Simple Mail Transfer Protocol 1982-08 RFC 821 (Standard) RFC 2821 Simple Mail Transfer Protocol 2001-04 RFC 2821 (Proposed Standard) RFC 3461 Simple Mail Transfer Protocol 2003-01 RFC 3461 (Draft Standard)
- Unknown — Неизвестно
- Standard — Текущий/действующий стандарт
- Experimental — Експериментальный
- Historic — Исторический
- Informational — Информационный
- Proposed Standard — Предложенный стандарт
- Draft Standard — Проект стандарта
В нашем случае мы хотим определится с максимальной длиной E-Mail адреса, а поэтому выбираем для прочтения документ «RFC 821» описывающий стандарт «Simple Mail Transfer Protocol» и имеющий соответствующий статус «Standard», доступный по адресу http://datatracker.ietf.org/doc/rfc821/:
RFC 821 SIMPLE MAIL TRANSFER PROTOCOL Jonathan B. Postel August 1982 **************************************************** * * * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * * OF THESE OBJECTS SHOULD BE USED. * * * **************************************************** user The maximum total length of a user name is 64 characters. domain The maximum total length of a domain name or number is 64 characters.
Из документа «RFC 821» который описывает стандарт «Simple Mail Transfer Protocol» следует, что для имени E-Mail пользователя и имени E-Mail домена максимальная длина установлена в 64-е символа, а следовательно 64 + @ + 64 = 129 максимально возможная длина E-Mail адреса составляет 129 символов.
Но, если мы просмотрим документ «RFC 2821 Simple Mail Transfer Protocol» предложенный J. Klensin из AT&T Laboratories, который устарел с выходом «RFC 5321 Simple Mail Transfer Protocol«, то обнаружим, что предлагается количество сомволов в имени E-Mail домена расширить до 255-ти символов:
local-part The maximum total length of a user name or other local-part is 64 characters. domain The maximum total length of a domain name or number is 255 characters.
Возможно J. Klensin из AT&T Laboratories и мае рацию и количество сомволов в имени E-Mail домена следовало бы расширить до 255-ти символов для каких то отдельных случаев но, подумайте сами. как вы будете набирать имя почтового домена состоящее из 255-ти символов ?:)
С взглядом в будущее максимальная длина E-Mail адреса будет равна 64 + @ + 255 = 320 символам, я решил остановится на действующем стандарте «RFC 821» 64 + @ + 64 = 129 максимально возможная длина E-Mail адреса 129 символов и с небольшим взглядом в будущее общее число символов для E-Mail адреса увеличил до 255-ти, мало ли что !:))
Ограничение длины URL-адреса
В документе RFC 2616 «Протокол HTTP/1.1» не определены требования к длине URL-адреса но, в Microsoft Internet Explorer максимальная длина URL-адреса ограничена 2083 символами. Кроме того, максимально допустимая длина пути в Internet Explorer составляет 2048 символов. Эти ограничения относятся к URL-адресам как для запросов POST, так и для запросов GET.
При использовании метода GET ограничение составляет 2048 символов за вычетом количества символов в текущем пути. В то же время метод POST не ограничен размером URL-адреса при отправке пар имя/значение. Эти пары пересылаются в заголовке, а не в URL-адресе.
Дополнительная информация
Если нужно определится со свойствами тех или иных объэктов, какой разделитель использовать для параметров, какая максимальная длина может быть для тех или иных параметров, то эту информацию следует черпать из стандартов описаных в RFC документах и не тратить попусту время на постинг подобных вопросов на различных форумах, сайтах, wikipedia-х и т.д. — RFC документы должны стоять на первом месте.
Потому как в настоящее время первичной публикацией документов RFC занимается IETF, то соответственно самую свежую и достоверную информацию о RFC стандартах интернета следует черпать именно из этого источника, а не откуда попало.
Далее небольшой список ссылок на полезные RFC стандарты:
- RFC 793 Transmission Control Protocol (TCP)
- RFC 791 Internet Protocol (IP)
- RFC 1700 Assigned Numbers
- RFC 1001 NetBIOS Concepts and methods
- RFC 1002 NetBIOS Detailed specifications
- RFC 1088 IP datagrams over NetBIOS networks
- RFC 1203 Interactive Mail Access Protocol: Version 3 (IMAP)
- RFC 3501 INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1
- RFC 1945 Hypertext Transfer Protocol — HTTP/1.0
- RFC 2616 Hypertext Transfer Protocol — HTTP/1.1
- RFC 854 Telnet Protocol Specification