Протокол IP не ориентирован на соединение, поскольку он не устанавливает сеанс связи перед тем как начать обмен данными. Протокол IP ненадежный - он не гарантирует доставку, хотя делает все возможное для доставки пакета. По пути пакет может быть потерян, доставлен в неправильной последовательности, продублирован или задержан.
Протокол IP не требует подтверждения при приеме данных. Отправитель или получатель не информируются при потере пакета или доставке его в неправильной последовательности. Ответственность за подтверждение получения пакетов несут высокоуровневые транспортные протоколы, например, TCP. Поля IP-датаграммы в приведенной ниже таблице добавляются в заголовок пакета при его получении с транспортного уровня.
Поле
Описание
Source IP-address (IP-адрес отправителя)
Идентифицирует отправителя датаграммы при помощи IP-адреса.
Destination IP-address (IP-адресполучателя)
Идентифицирует получателя датаграммы при помощи IP-адреса.
Protocol (Протокол)
Информирует протокол IP узла-получателя о том, какому протоколу верхнего уровня - TCP ил UDP - его следует передать.
Checksum (Контрольная сумма)
Легко вычисляемое значение для проверки целостности пришедшего пакета.
Time to live, TTL (Времяжизни)
Определяет, сколько секунд находится датаграмма в сети перед тем, как она будет отвергнута (discarded). Предотвращает бесконечное блуждание пакетов по сети. Маршрутизаторы должны уменьшать TTL на количество секунд, проведенных датаграммой на маршрутизаторе. TTL уменьшается по меньшей мере на 1 секунду каждый раз, когда датаграмма проходит через маршрутизатор. По умолчанию в Windows NT 4.0 TTL равно 128 секундам.
Если протокол IP идентифицирует адрес получателя как локальный, то он передаст пакет на этот узел напрямую. Если же IP-адрес получателя идентифицирован как удаленный, то IP начнет искать маршрут к удаленному узлу в локальной таблице маршрутизации. Если он не найдет подходящего маршрута, то отправит пакет на шлюз по умолчанию, заданный в конфигурации узла-отправителя. Шлюз по умолчанию (default gateway) также называют маршрутизатором (router). Реализация IP на маршрутизаторе Маршрутизатор обрабатывает полученные им IP-пакеты следующим образом. 1. Уменьшает значение TTL на 1 секунду или больше, если пакет надолго задерживается на маршрутизаторе. Если значение TTL достигает нуля, пакет отвергается. 2. Пакет может быть фрагментирован, если его размер слишком велик для сети дальнейшего следования. 3. Если пакет фрагментирован, то IP создает для каждого нового пакета (фрагмента) отдельный заголовок, устанавливая: Flag (флаг), указывающий, что существуют и другие фрагменты, которые будут отправлены следом. Fragment ID (Идентификатор фрагмента), идентифицирующий все фрагменты, составляющие один пакет. Fragment Offset (Смещение фрагмента), обеспечивающее правильную сборку пакета на узле-получателе. 4. Вычисляет новую контрольную сумму. 5. Определяет адрес сетевого адаптера следующего маршрутизатора. 6. Направляет пакет дальше в сеть. На следующем уровне пакет попадает по стеку протоколов к TCP или UDP. Этот процесс повторяется на каждом маршрутизаторе до тех пор, пока пакет не дойдет до адресата. Там протокол IP собирает из фрагментов пакет в первоначальном виде. Структура IP-пакета Поля заголовка IP-Пакета (для IP версии 4) приведены в следующей таблице:
Поле
Описание
Version (Версия)
4 бита используются для отображения версии протокола IP. Текущая версия - четвертая. Следующей будет шестая.
Header Length (Длина заголовка)
4 бита используются для отображения количества 32-битных слов в заголовке IP-пакета. Минимальный размер слова - 20 байт, следовательно, длина минимального заголовка - 0×5. Опции IP могут увеличить минимальный размер заголовка на 4 байта. Если опция не использует их все, то оставшиеся биты заполняются нулями, поэтому длина заголовка всегда кратна 4 байтам.
Поле
Описание
Version (Версия)
4 бита используются для отображения версии протокола IP. Текущая версия - четвертая. Следующей будет шестая.
Header Length (Длина заголовка)
4 бита используются для отображения количества 32-битных слов в заголовке IP-пакета. Минимальный размер слова - 20 байт, следовательно, длина минимального заголовка - 0×5. Опции IP могут увеличить минимальный размер заголовка на 4 байта. Если опция не использует их все, то оставшиеся биты заполняются нулями, поэтому длина заголовка всегда кратна 4 байтам.
Type of Service (Типобслуживания)
8 бит используются для обозначения требуемого для этой датаграммы качества обслуживания при доставке через маршрутизаторы объединенной IP-сети. В них есть биты, выделенные для приоритета, задержки, пропускной способности и характеристики надежности.
Total Length (Общая длина)
16 бит используются для отображения общей длины датаграммы протокола IP (заголовок IP-пакета + его содержание). Сюда не включен заголовок сетевого кадра.
Identification (Идентификация)
16 бит используются в качестве идентификатора данного IP-пакета. Если IP-пакет фрагментирован, то все фрагменты имеют одинаковые идентификаторы, используемые при сборке узлом-получателем.
Fragmentations Flags (Фрагментационные флаги)
3 бита зарезервированы для флагов фрагментации, однако только 2 бита определены для текущего использования. Один флаг служит для обозначения фрагментированного пакета, другой - для идентификации последнего фрагмента.
Fragment Offset (Смещение фрагмента)
13 бит используются как счетчик смещения для указания положения фрагментов относительно начала поля данных IP-пакета. Если фрагментации нет, то смещение равно 0×0.
Time To Live (Время существования)
8 бит используются в качестве индикатора времени (транзитов IP-пакета), максимально допустимого перед тем, как пакет будет отвергнут. Поле TTL используется как счетчик времени (в секундах), проведенного пакетом на маршрутизаторе, который соответственно уменьшает TTL. Современные маршрутизаторы почти всегда перенаправляют датаграммы менее чем за 1 секунду, однако, по требованиям RFC 791, они должны уменьшать TTL не менее чем на единицу. Поэтому TTL становится счетчиком максимального числа транзитов.
Protocol (Протокол)
8 бит используются в качестве идентификатора протокола, данные которого инкапсулированы в IP-пакет. Поле протокола применяется для передачи IP-пакета протоколу верхнего уровня.
Header Checksum (Контрольная сумма заголовка)
16 бит используются в качестве контрольной суммы заголовка IP-пакета. Данные пакета не учитываются и могу иметь свою собственную контрольную сумму для проверки ошибок. Когда узел получает пакет, он проводит проверку контрольной суммы и при несовпадении значений отвергает пакет. Когда маршрутизатор пересылает пакет, он, как минимум, уменьшает TTL. Поэтому контрольная сумма вычисляется снова при каждом транзите ну пути от отправителя к получателю.
Source Address (Адрес отправителя)
32 бита используются для хранения IP-адреса узла-отправителя.
Destination Address (Адресполучателя)
32 бита используются для хранения IP-адреса узла-получателя.
Options and Padding (Опции и заполнение)
Для хранения опций используется кратное 32 число бит. Если же опции не занимают это место целиком, остаток заполняется нулями. Таким образом, длина IP-заголовка всегда может быть выражена количеством четверок байт и записана в поле Header Length.
Протокол TCP Протокол TCP предоставляет надежную, ориентированную на соединение службу доставки. Данные протокола TCP передаются сегментами, и соединение должно быть установлено до того, как узлы начнут обмениваться данными. TCP использует потоки, в которых данные представлены в виде последовательности байт. TCP обеспечивает надежность, присваивая номера последовательности (sequence number) каждому передаваемому сегменту. Если сегмент разбивается на мелкие пакеты, то узел-получатель сможет узнать, все ли части получены. Для этого используются подтверждения. Для каждого отправленного сегмента узел-получатель должен вернуть отправителю подтверждение (acknowledgement, ACK) в течение определенного времени. Если отправитель не получил ACK, то данные передаются повторно. Если сегмент поврежден, то узел-получатель отвергает его. Поскольку ACK в этом случае не посылается, отправитель передает сегмент еще раз.
Порты и сокеты Приложения, использующие сокеты, идентифицирую себя на компьютере посредством номера порта протокола (protocol port number). Например, FTP-сервер использует определенный tCP-порт, поэтому другие приложения могут с ним связаться. Порты могут иметь любой номер от 0 до 65536. Номера портов для приложений клиентов динамически назначаются операционной системой при обработке запроса на обслуживание. Известные (well-known) номера портов для приложений-серверов назначаются группой Internet Assigned Numbers Authority (IANA) и не меняются. Вы можете узнать номера портов, просмотрев файл Service, находящийся в папке [C:\ W] в Windows 9x или [C:\ W\ System32\ Drivers\ Etc\ Services] в Windows NT. Номера известных портов расположены в интервале от 1 до 1024. Окончательный список известных номеров портов задокументирован в RFC 1700. Сокет (socket) во многом аналогичен дескриптору файла (file handler). Он обеспечивает конечную точку сетевого соединения. Приложение, создавая сокет, указывает три параметра: IP-адрес узла, тип обслуживания (протокол TCP для ориентированного на соединение обслуживания и UDP для не ориентированного) и порт, используемый приложением. Приложение может создать сокет и использовать его для отправки не ориентированного на соединение трафика удаленным приложениям или же подключить его к сокету другого приложения. Во втором случае данные будут посланы по надежному соединению. Порт протокола TCP указывает место доставки сообщений. Номера портов, меньшие 256, определены как широко используемые. В таблице перечислены некоторые из таких портов:
Главная 
