Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Название:TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
- Автор:
- Жанр:
- Издательство:Лори
- Год:2000
- Город:Москва
- ISBN:5-85582-072-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) краткое содержание
Второе издание популярного справочника полностью переработано и расширено с целью предоставить читателю наиболее полное описание средств разработки, конфигурирования, использования и обслуживания сетей TCP/IP и соответствующих служб.
Книга написана увлекательно и доступно. Она содержит дополнительные материалы о нескольких протоколах Интернета, используемых серверами и браузерами WWW, а также рассматривает все последние изменения в этой области. В книгу включены главы о новом стандарте безопасности IP и протоколе IP следующего поколения, известном как IPng или IPv6. Рисунки и таблицы наглядно показывают влияние средств безопасности IP и IPng на существующие сетевые среды.
Издание содержит следующие дополнительные разделы:
• Безопасность IP и IPv6
• Описание средств WWW, новостей Интернета и приложений для работы с gopher
• Подробное описание серверов имен доменов (DNS), маски подсети и бесклассовой маршрутизации в Интернете
• Таблицы и протоколы маршрутизации
• Руководство по реализации средств безопасности для каждого из протоколов и приложений
• Примеры диалогов с новыми графическими инструментами
Новое издание бестселлера по TCP/IP станет незаменимым помощником для разработчиков сетей и приложений, для сетевых администраторов и конечных пользователей.
TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Ответ сервера объявляет об используемой версии HTTP (1.0) и коде статуса; 200 — означает успешное выполнение запроса. Далее следует серия подобных MIME заголовков. Пустая строка () сообщает о конце раздела заголовков и начале тела документа.
GET/HTTP/1.0
ACCEPT: text/html
HTTP/1.0 200 Document follows
Date: Sat, 28 Oct 1995 14:07:25 GMT
Server: NCSA/1.5.1
Content-type: text/html
Last-modified: Tue, 09 May 1995 01:22:41 GMT
Content-length: 1563
InterNIC Directory and Database Services
Welcome to InterNIC Directory and Database Services provided by AT&T.
These services are partially supported through a cooperative agreement with
the National Science Foundation.
. . .
Сервер закроет соединение, когда будет завершена пересылка.
19.8.2 Заголовки сообщения
В таблицах 19.2–19.5 представлены краткие описания заголовков в запросах и ответах.
Таблица 19.2 Главные заголовки HTTP
| Главные заголовки | Описание |
|---|---|
| Date: дата | Дата в формате универсального времени, например: Date: Sun, 29 Oct 1995 15:15:23 GMT |
| MIME-Version: версия | Версия MIME заголовка, например: MIME-Version: 1.0 |
| Pragma: директива | Реализация конкретной директивы, например: Pragma: no-cache (указывает прокси на извлечение более новой версии страницы, если данная страница уже кеширована). |
Таблица 19.3 Заголовки запросов HTTP
| Заголовки запросов | Описание |
|---|---|
| Authorization: мандат | Содержит информацию об аутентификации клиента для доступа к защищенным ресурсам. |
| From: идентификатор электронной почты | Подобен соответствующему полю в электронной почте. |
| If-Modified-Since: дата | Служит для организации условия в GET. Если затребованный документ не был изменен после указанной даты, в ответе будет содержаться только код 304, но не будет тела документа. |
| Referer: URL | Указание на источник получения ссылки на документ, например: Referrer: http://www.abc.com/index.html. |
| User-Agent: программа | Идентифицирует программное обеспечение клиента. |
Таблица 19.4 Заголовки ответов HTTP
| Заголовки ответов | Описание |
|---|---|
| Location: URL | Предпочитаемое сервером размещение документа. |
| Server: программа | Идентифицирует программное обеспечение сервера. |
| WWW-Authenticate: исследование | Предоставляет параметры для указания на схему аутентификации и необходимость аутентификации самого клиента. |
Таблица 19.5 Заголовки элементов HTTP
| Заголовки элементов | Описание |
|---|---|
| Allow: метод | Перечисление поддерживаемых ресурсом методов, например: Allow. GET, HEAD |
| Content- Encoding: кодирование содержимого | Для сжатого или зашифрованного содержимого; указывает на использованный алгоритм, например: Content-Encoding: x-gzip |
| Content-Length: длина | Описывает длину тела пересылаемого документа, например: Content-Length: 2048 |
| Content-Type: тип носителя | Определены IANA, например: Content-Type, text/html |
| Expires: дата | Элемент недостоверен после указанной даты. |
| Last-Modified: дата | Время последней модификации элемента. |
■ В сообщении первыми стоят главные заголовки как в запросах, так и в ответах (таблица 19.2).
■ Затем следуют заголовки, специфичные для запросов (таблица 19.3) или ответов (таблица 19.4).
■ Наконец последними стоят заголовки элементов, которые обеспечивают детальное описание данного элемента (таблица 19.5).
Нужно помнить, что запрос POST приводит к пересылке от клиента к серверу определенных элементов, например данных формы. Поэтому заголовки элементов могут появляться в запросах и ответах.
19.8.3 Коды состояния
Коды состояния используются подобно электронной почте и пересылке файлов (FTP). Наиболее распространенные значения кодов:
| 1xx | Информация. Не используется, но зарезервирован для применения в будущем. |
| 2xx | Успешно. Запрошенная операция была успешно получена, понята и принята для исполнения. |
| 3xx | Перенаправление. Для полного завершения требуются дополнительные действия. |
| 4xx | Ошибка клиента. Запрос имеет синтаксическую ошибку или не может быть выполнен. |
| 5xx | Ошибка сервера. Сервер не смог выполнить корректный запрос. |
Более детальные сведения обозначаются дополнительными кодами.
19.9 Продолжение совершенствования
В ответ на требования пользователей по обеспечению больших функциональных возможностей HTTP и HTML постоянно совершенствуются. На момент написания книги шла разработка стандартов для обеспечения безопасности взаимодействий клиент/сервер и для создания действительно защищенных коммерческих систем. Других достижений можно ожидать в области определения и реализации независимой от размещения ресурсов схемы именования (Uniform Resource Names — URN), поскольку существует проблема потери ссылки при перемещении документа на другой компьютер или в другой каталог.
URN делает доступным извлечение нужного документа из другого места сети. Можно указать несколько мест размещения документа с выбором оптимального варианта для извлечения.
19.10 Дополнительная литература
RFC 1738 содержит описание URL. RFC 1630 — это техническое руководство по Universal Resource Identifiers.
Спецификация HTTP 1.0 была опубликована в RFC 1945. Отдельные документы по HTML существуют в Интернете в форме проектов, к которым можно обратиться по ftp://ftp.internic.net/internet-drafts.
Информация о безопасности в HTTP, HTML и WWW доступна на сайте консорциума W3 (http://www.w3.org/).
Глава 20
SNMP
20.1 Введение
Сетевое управление далеко отстало по своим возможностям от других сетевых средств. Очень большие сети TCP/IP прекрасно работают, однако их администрирование и обслуживание требуют много времени и наличия квалифицированного технического персонала.
Особенно это справедливо для сети Интернет, которая быстро разрастается и усложняется. В конце 80-х гг. Совет по архитектуре Интернета (Internet Architecture Board — IAB) столкнулся с необходимостью определения технической политики Интернета, наиболее критичной частью которой являлось установление основ управления сетью и создание набора стандартов для соответствующих рабочих инструментов. Сделать это нужно было как можно быстрее.
Хотя большая часть работы уже была выполнена комитетом по созданию стандартов сетевого управления OSI, предстояло разработать реальные стандарты для инструментов управления сетями TCP/IP.
Рабочая группа Интернета создала простой протокол сетевого управления (Simple Network Management Protocol — SNMP), который решал сиюминутные потребности TCP/IP. Архитектура SNMP разрабатывалась в соответствии с моделью OSI. Была надежда, что стандарт сетевого управления OSI — общая информационная служба управления/общий протокол управляющей информации (Common Management Information Services/Common Management Information Protocol — CMIS/CMIP) — просуществует долго. Однако за несколько месяцев стало ясно, что SNMP требует независимой разработки и должен помочь в создании средств для управления сетями.
Читать дальшеИнтервал:
Закладка:
