Tcp протокол

Содержание:

Протоколы TCP против SCTP

И TCP (протокол управления передачей), и SCTP (протокол управления передачей данных) находятся на транспортном уровне и обеспечивают транспортные функции в основном в интернет-приложениях. TCP обеспечивает надежную передачу данных со строгим порядком доставки пакетов, но для некоторых приложений требуется надежная передача, но не 100% последовательность доставки пакетов. В этих случаях TCP может вызвать ненужную задержку во втором варианте, когда важна надежность, но не 100% последовательная доставка.

При транспортировке пакетов существует два основных ограничения: одно — надежность, другое — время ожидания. Надежность гарантируется доставкой пакета, а задержка — своевременной доставкой пакета. Оба не могут быть достигнуты пика одновременно, но могут быть оптимизированы.

SCTP разработан в основном для передачи сигналов PSTN по IP-сетям. (СИГТРАН). Но в наши дни другие приложения также считают, что SCTP хорошо соответствует их требованиям.

TCP:

Определено в RFC 793

TCP — это сквозной надежный протокол, ориентированный на соединение, обеспечивающий гарантированную передачу данных. TCP гарантирует надежность от самого установления соединения. Некоторые из основных функций TCP — это трехстороннее подтверждение (SYN, SYN-ACK, ACK), обнаружение ошибок, медленный запуск, управление потоком, управление перегрузкой.

TCP — надежный транспортный механизм, поэтому он будет использоваться там, где доставка пакетов необходима даже в условиях перегрузки. Типичный пример для приложений TCP и номеров портов: данные FTP (20), управление FTP (21), SSH (222), Telnet (23), почта (25), DNS (53), HTTP (80), POP3 (110). , SNMP (161) и HTTPS (443). Это хорошо известные приложения TCP.

SCTP:

Определено в RFC4960

SCTP (Stream Control Transmission Protocol) — это транспортный протокол IP, например TCP и UDP. SCTP — это протокол одноадресной рассылки, который поддерживает сквозную доставку данных ровно через две конечные точки. Но конечные точки могут иметь более одного IP-адреса.

SCTP — это полнодуплексный протокол передачи с такими функциями, как повторная передача, управление потоком и поддержание последовательности.

Помимо TCP, SCTP имеет больше функций, некоторые из которых перечислены ниже.

Функция многопотоковой передачи SCTP

SCTP позволяет разделять данные на несколько потоков, и каждый поток имеет свою собственную последовательность доставки. Рассмотрим случай телефонной сигнализации: необходимо поддерживать последовательность пакетов, которая влияет на один и тот же сеанс или ресурс. (Пример: тот же вызов или та же внешняя линия). Таким образом, отслеживания последовательности на основе потоков достаточно, и это приведет к более высокой производительности, чем одна полная потоковая передача.

SCTP множественная адресация

Эта функция позволяет одной конечной точке SCTP иметь несколько IP-адресов. Основная причина этого — поддерживать доступность конечной точки через несколько избыточных маршрутов маршрутизации.

Выбор пути

Счетчик поддерживается для отслеживания неуспешных подтверждений передачи конкретному адресату. Определен порог, и если он превышает адрес назначения, он объявляется неактивным, и SCTP начинает отправлять на альтернативный адрес.

Резюме:

(1) TCP и SCTP поддерживают надежные транспортные службы. (2) TCP поддерживает единый поток доставки данных, тогда как SCTP поддерживает множественные потоки доставки данных. (3) TCP поддерживает одну конечную точку TCP, чтобы иметь один IP-адрес, тогда как, поскольку SCTP поддерживает, одна конечная точка SCTP может иметь несколько IP-адресов в основном для целей избыточности. (4) Скорее TCP, SCTP более безопасен. (5) Процессы инициации и завершения SCTP отличаются от TCP.

TCP vs self-made UDP. Final fighting

• Send/recv buffer: для своего протокола можно делать mutable buffer, с TCP будут проблемы с buffer bloat.
• Congestion control вы можете использовать существующие. У UDP они любые. 
• Новый Congestion control трудно добавить в TCP, потому что нужно модифицировать acknowledgement, вы не можете это сделать на клиенте.
• Мультиплексирование — критичная проблема. Случается head-of-line blocking, при потере пакета вы не можете мультиплексировать в TCP. Поэтому HTTP2.0 по TCP не должен давать серьезного прироста.
• Случаи, когда вы можете получить установку соединения за 0-RTT в TCP крайне редки, порядка 5 %, и порядка 97 % для self-made UDP.

• IP Migration — не такая важная фича, но в случае сложных подписок и хранения состояния на сервере она однозначно нужна, но в TCP никак не реализована.
• Nat unbinding не в пользу UDP. В этом случае в UDP надо часто делать ping-pong пакеты.
• Packet pacing в UDP простой, пока нет оптимизации, в TCP эта опция не работает.
•  MTU и исправление ошибок и там, и там примерно сравнимы.
• По скорости TCP, конечно, быстрее, чем UDP сейчас, если вы раздаете тонну трафика. Но зато какие-то оптимизации очень долго доставляются.

Выбираем UDP!

Когда и почему следует сбрасывать стек TCP/IP

Со временем Windows сохраняет кэш сетевых данных, включая IP-адреса. В системном реестре также есть параметры, которые напрямую связаны с интернет-протоколом. В любой момент они могут быть повреждены, что приведет к невозможности подключения к Интернету, даже если все остальные настройки выполнены правильно.

Повреждение стека может даже быть причиной того, что трафик вашего компьютера направляется на старый IP-адрес и не может обновить новый в кеше.

Иногда недостаточно изменить IP-адрес вашего компьютера или просто перезапустить его. Именно тогда пользователь должен прибегнуть к этому решению и сбросить свои настройки TCP / IP.

Соединение TCP

TCP для передачи данных использует соединение. Соединение нужно установить перед тем, как начать передачу данных, а после того как передача данных завершена, соединение разрывается.

Задачи соединения

• Убедиться в том, что отправитель и получатель действительно хотят передавать данные друг другу
• Договориться о нумерации потоков байт. С точки зрения практической реализации нельзя всегда нумеровать данные в потоке байт с нуля. Каждый раз начальное значение для нумерации байт выбираются по определенному алгоритму и отправитель и получатель должны договориться между собой какое начальное значение они будут использовать для нумерации потока байт.
• При установке соединения происходит договоренность о некоторых параметрах соединения.

Установка соединения в TCP

Отправитель посылает запрос на установку соединения сообщение SYN от слова синхронизация. Также в сегмент включаются порядковый номер передаваемого байта.

Получатель в ответ передаёт сообщение SYN, куда включает подтверждение получения предыдущего сообщения ACK от слова acknowledge и порядковый номер байта, который он ожидает 7538, потому что на предыдущем этапе был получен байт с номером 7537.

Также отправитель включает в сегмент номер байта в потоке байт 36829. Номера байт в первом сообщении не могут быть всегда нулевыми, они выбираются по достаточно сложным алгоритмам, но для простоты можно представлять себе что эти номера выбираются случайным образом.

На третьем этапе пересылается подтверждение получения предыдущего запроса на установку соединения ACK номер следующего ожидаемого байта 36830, а также номер байта в сообщении. После этого соединение считается установленным и можно передавать данные.

Разрыв соединения в TCP

Соединение в TCP дуплексное — это означает, что после установки соединения передавать данные можно в две стороны. Есть две схемы разрыва соединения. Возможен одновременный разрыв соединения, в этом случае обе стороны разрывают соединение в одно и то же время, либо односторонние, в этом случае одна сторона говорит о том, что данные для передачи у нее закончились, но другая сторона может передавать данные еще достаточно долго.

Протокол TCP предусматривает два варианта разрыва соединения: корректное, с помощью одностороннего разрыва соединения и сообщения FIN и разрыв из-за критической ситуации с помощью сообщения RST.

Рассмотрим, как выполняется корректный разрыв соединения. Сторона, которая хочет разорвать соединение пересылает другой стороне сообщение FIN и в ответ получает сообщение ACK. Однако соединение разорвано только с одной стороны.

Когда другая сторона решила, что данные для передачи у нее закончились, она также передает сообщение FIN в ответ получает сообщение ACK подтверждение. На этом этапе соединение закрыто полностью в обе стороны.

Для разрыва соединения в критической ситуации из-за ошибок в приложении или с оборудованием используется одно сообщение RST. В этом случае соединение закрывается в обе стороны. Хотя сообщение RST предназначено для использования в критических ситуациях, некоторые протоколы используют его для быстрого закрытия соединения.

Differences between OSI and TCP/IP models

Difference between OSI and TCP/IP model

Here, are some important differences between the OSI and TCP/IP model:

OSI Model	TCP/IP model
It is developed by ISO (International Standard Organization)	It is developed by ARPANET (Advanced Research Project Agency Network).
OSI model provides a clear distinction between interfaces, services, and protocols.	TCP/IP doesn’t have any clear distinguishing points between services, interfaces, and protocols.
OSI refers to Open Systems Interconnection.	TCP refers to Transmission Control Protocol.
OSI uses the network layer to define routing standards and protocols.	TCP/IP uses only the Internet layer.
OSI follows a vertical approach.	TCP/IP follows a horizontal approach.
OSI model use two separate layers physical and data link to define the functionality of the bottom layers.	TCP/IP uses only one layer (link).
OSI layers have seven layers.	TCP/IP has four layers.
OSI model, the transport layer is only connection-oriented.	A layer of the TCP/IP model is both connection-oriented and connectionless.
In the OSI model, the data link layer and physical are separate layers.	In TCP, physical and data link are both combined as a single host-to-network layer.
Session and presentation layers are not a part of the TCP model.	There is no session and presentation layer in TCP model.
It is defined after the advent of the Internet.	It is defined before the advent of the internet.
The minimum size of the OSI header is 5 bytes.	Minimum header size is 20 bytes.

Application Layer

Application layer interacts with an application program, which is the highest level of OSI model. The application layer is the OSI layer, which is closest to the end-user. It means the OSI application layer allows users to interact with other software application.

Application layer interacts with software applications to implement a communicating component. The interpretation of data by the application program is always outside the scope of the OSI model.

The function of the Application Layers are:

• Application-layer helps you to identify communication partners, determining resource availability, and synchronizing communication.
• It allows users to log on to a remote host
• This layer provides various e-mail services
• This application offers distributed database sources and access for global information about various objects and services.

Как сделать выбор: TCP или UDP для vpn?

Программа Whoer VPN по умолчанию использует TCP-протокол, но при необходимости вы можете сменить его на UDP в Настройках одним кликом.

Наши клиенты часто спрашивают, какой протокол лучше: tcp или udp для vpn. Прочитав этой статье о tcp и udp протоколах, вы сами можете решить, какой из них лучше подходит именно вам. OpenVPN приложения работают как с UDP, так и с TCP, и оба протокола безопасны и обеспечивают анонимность. Какой из них использовать, зависит от того, для чего вы используете VPN.

В дополнение к собственному впн-клиенту, мы предоставляем нашим пользователям Openvpn конфиги для использования с любым подходящим клиентом на выбранной платформе. Рекомендуем вам посмотреть видео-инструкцию Меняем TCP на UDP в OpenVPN на нашем youtube-канале, если вы используете OpenVPN клиент.

Подписывайтесь на нас в соцсетях, задавайте вопросы и делитесь полезной информацией с друзьями и близкими!

Шлюзы по умолчанию

Если компьютер tCP/IP должен общаться с хостом в другой сети, он обычно общается с помощью устройства, называемого маршрутизатором. В терминах TCP/IP маршрутизатор, указанный в хосте, который связывает подсеть хостов с другими сетями, называется шлюзом по умолчанию. В этом разделе объясняется, как TCP/IP определяет, отправлять ли пакеты в шлюз по умолчанию для достижения другого компьютера или устройства в сети.

Когда хост пытается взаимодействовать с другим устройством с помощью TCP/IP, он выполняет процесс сравнения с помощью определенной подсети и IP-адреса назначения по сравнению с подсети и собственным IP-адресом. В результате этого сравнения компьютеру сообщается, является ли назначение локальным хостом или удаленным хостом.

Если в результате этого процесса определяется назначение локального хоста, компьютер отправляет пакет в локальной подсети. Если в результате сравнения определяется назначение удаленного хоста, компьютер перенаправлен пакет в шлюз по умолчанию, определенный в свойствах TCP/IP. После этого маршрутизатор несет ответственность за перенаправку пакета в правильную подсеть.

TCP vs self-made UDP

• С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
• Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
• Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.

• Профиль Видео, когда вы подключаетесь и стримите тот или иной контент. Скорость соединения увеличивается, как на верхнем графике. Требования к этому протоколу: низкие задержки и адаптация битрейта.
• Вариант просмотра Ленты: импульсная загрузка данных, фоновые запросы, промежутки простоя. Требования к этому протоколу: получаемые данные мультиплексируются и приоритизируются, приоритет пользовательского контента выше фоновых процессов, есть отмена загрузки.

Отличия HTTP 2.0

• бинарный, сжатие заголовков;
• мультиплексирование данных;
• приоритизация;
• возможна отмена загрузки;
• server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

• Профилях сети: Wi-Fi, 3G, LTE.
• Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

• пакеты 1 и 2 уже отправлены, для них получено подтверждение;
• пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
• остальные пакеты находятся в очереди.

Вывод:

Congestion control

• Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
• У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.

• Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
• Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.

• На верхней схеме сеть, в которой все хорошо. Пакеты отправляются с заданной частотой, с такой же частотой возвращаются подтверждения. 
• Во второй строке начинается перегруз сети: пакеты идут чаще, acknowledgements приходят с задержкой. 
• Данные копятся в буферах на маршрутизаторах и других устройствах и в какой-то момент начинают пропускать пакеты, acknowledgements на эти пакеты не приходят (нижняя схема).

• Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
• BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

• BBR понимает, что идет переполнение буфера, и пытается схлопнуть окно, уменьшить нагрузку на маршрутизатор. 
• Cubic дожидается потери пакета и после этого схлопывает окно.

jitterHighLoad++

Какой Congestion control выбрать

Выводы про congestion control:

• Для видео всегда хорош BBR. 
• В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
• С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

Как мы пришли к TCP/IP

Сегодня в мире компьютерных сетей используется одна сетевая модель: TCP/IP. Однако мир не всегда был таким простым. Когда-то не существовало сетевых протоколов, включая TCP/IP. Производители создали первые сетевые протоколы; эти протоколы поддерживали только компьютеры конкретного производителя.

Например, IBM, компьютерная компания с самой большой долей на многих рынках в 1970-х и 1980-х годах, опубликовала свою сетевую модель Systems Network Architecture (SNA) в 1974 году. Другие производители также создали свои собственные проприетарные сетевые модели. В результате, если ваша компания покупала компьютеры трех производителей, сетевым инженерам часто приходилось создавать три разные сети на основе сетевых моделей, созданных каждой компанией, а затем каким-то образом соединять эти сети, что значительно усложняло объединенные сети. В левой части рисунка 1 показано общее представление о том, как могла бы выглядеть корпоративная сеть компании в 1980-х годах, до того, как TCP/IP стал обычным явлением в корпоративных объединенных сетях.

Рисунок 1 – История развития: движение от проприетарных моделей к открытой модели TCP/IP

Хотя проприетарные сетевые модели, определяемые производителями, часто работают хорошо, наличие открытой сетевой модели, не зависящей от производителя, может способствовать конкуренции и снизить сложность. Международная организация по стандартизации (ISO) взяла на себя задачу создать такую модель, начав еще в конце 1970-х годов работу над так называемой сетевой моделью взаимодействия открытых систем (OSI, Open Systems Interconnection). ISO поставила перед моделью OSI благородную цель: стандартизировать сетевые протоколы передачи данных, чтобы обеспечить связь между всеми компьютерами на всей планете. Во время работы ISO над достижением этой амбициозной и благородной цели в процессе были задействованы участники из большинства технологически развитых стран мира.

Вторая, менее формальная попытка создать открытую, нейтральную по отношению к производителям открытую сетевую модель возникла в результате контракта Министерства обороны США (DoD, Department of Defense). Исследователи из различных университетов вызвались помочь в дальнейшей разработке протоколов, относящихся к исходной работе Министерства обороны США. Эти усилия привели к созданию конкурирующей открытой сетевой модели под названием TCP/IP.

В течение 1990-х годов компании начали добавлять OSI, TCP/IP или и то, и другое в свои корпоративные сети. Однако к концу 1990-х TCP/IP стал основным, и OSI отпала. Центральная часть рисунка 1 показывает общую идею корпоративных сетей того десятилетия – сети, построенные на нескольких сетевых моделях, но включающие TCP/IP.

Сейчас, в двадцать первом веке, доминирует TCP/IP. Проприетарные сетевые модели всё еще существуют, но в основном от них отказались в пользу TCP/IP. Модель OSI, развитие которой частично пострадало из-за более медленного официального процесса стандартизации по сравнению с TCP/IP, так и не добилось успеха на рынке. И TCP/IP, сетевая модель, изначально созданная почти целиком группой добровольцев, стала самой успешной сетевой моделью за всю историю, как показано на правой части рисунка 1.

В данной главе вы прочитаете о некоторых основах TCP/IP. Хотя вы узнаете некоторые интересные факты о TCP/IP, настоящая цель – помочь вам понять, что на самом деле представляет собой сетевая модель или сетевая архитектура, и как она работает.

Transport Layer

Transport layer builds on the network layer in order to provide data transport from a process on a source system machine to a process on a destination system. It is hosted using single or multiple networks, and also maintains the quality of service functions.

It determines how much data should be sent where and at what rate. This layer builds on the message which are received from the application layer. It helps ensure that data units are delivered error-free and in sequence.

Transport layer helps you to control the reliability of a link through flow control, error control, and segmentation or de-segmentation.

The transport layer also offers an acknowledgment of the successful data transmission and sends the next data in case no errors occurred. TCP is the best-known example of the transport layer.

Important functions of Transport Layers:

• It divides the message received from the session layer into segments and numbers them to make a sequence.
• Transport layer makes sure that the message is delivered to the correct process on the destination machine.
• It also makes sure that the entire message arrives without any error else it should be retransmitted.

The Network Interface Layer

Network Interface Layer is this layer of the four-layer TCP/IP model. This layer is also called a network access layer. It helps you to defines details of how data should be sent using the network.

It also includes how bits should optically be signaled by hardware devices which directly interfaces with a network medium, like coaxial, optical, coaxial, fiber, or twisted-pair cables.

A network layer is a combination of the data line and defined in the article of OSI reference model. This layer defines how the data should be sent physically through the network. This layer is responsible for the transmission of the data between two devices on the same network.

Что есть MAC-адрес

Дело в том, что пересылаемые пакеты в сети адресуются компьютерам не по их именам и не на IP-адрес. Пакет предназначается устройству с конкретным адресом, который и называется MAC-адресом.

MAC-адрес — это уникальный адрес сетевого устройства, который заложен в него изготовителем оборудования, т.е. это этакий проштампованный номер Вашей сетевой карты. Первая половина MAC-адрес представляет собой идентификатор изготовителя, вторая — уникальный номер данного устройства.

Как правило MAC-адрес бывает требуется для идентификации, скажем, у провайдера (если провайдер использует привязку по мак-адресу вместо логина-пароля) или при настройке маршрутизатора.

Обзор сетевой модели TCP/IP

Модель TCP/IP определяет и опирается на большой набор протоколов, которые позволяют компьютерам обмениваться данными. Чтобы определить протокол, TCP/IP использует документы, называемые RFC (Requests For Comments) (вы можете найти эти RFC в Интернете с помощью любой поисковой системы). Модель TCP/IP также позволяет избежать повторения работы, уже проделанной другим органом по стандартизации или консорциумом производителей, просто ссылаясь на стандарты или протоколы, созданные этими группами. Например, Институт инженеров по электротехнике и электронике (IEEE) определяет локальные сети Ethernet; модель TCP/IP не определяет Ethernet в RFC, но в качестве дополнения ссылается на IEEE Ethernet.

Модель TCP/IP создает набор правил, который позволяет всем нам вынуть компьютер (или мобильное устройство) из коробки, подключить все нужные кабели, включить его, подключиться к сети и использовать ее. Вы можете использовать веб-браузер для подключения к любимому веб-сайту, использовать практически любое приложение, и всё это работает. Как? Что ж, операционная система на компьютере реализует части модели TCP/IP. Сетевая карта Ethernet или карта беспроводной локальной сети, встроенная в компьютер, реализует стандарты локальной сети, на которые ссылается модель TCP/IP. Проще говоря, производители, создавшие аппаратное и программное обеспечение, реализовали TCP/IP.

Чтобы помочь людям понять сетевую модель, каждая модель разбивает функции на небольшое количество категорий, называемых уровнями. Каждый уровень включает в себя протоколы и стандарты, относящиеся к своей категории функций. Данное разбиение показано на рисунке 2.

Рисунок 2 – Уровни сетевой модели TCP/IP

Модель TCP/IP показывает общие термины и уровни, используемые сегодня, когда люди говорят о TCP/IP.

Нижний (физический) уровень фокусируется на том, как передавать биты по каждому отдельному каналу.

Канальный уровень ориентирован на отправку данных по одному типу физического канала: например, сети используют отличающиеся протоколы канала передачи данных для локальных сетей Ethernet по сравнению с беспроводными локальными сетями.

Сетевой (межсетевой) уровень фокусируется на доставке данных по всему пути от исходного компьютера-отправителя до конечного компьютера-получателя.

И два верхних уровня больше ориентированы на приложения, которым необходимо отправлять и получать данные.

ПРИМЕЧАНИЕ. В RFC 1122 используется несколько отличная четырехуровневая оригинальная версия модели TCP/IP (в которой физический и канальный уровни были объединены в уровень сетевого доступа), но и для реальных сетей, и для сегодняшней сертификации CCNA (2020 год, информация из «CCNA 200-301 Official Cert Guide» Уенделла Одома), используйте пятиуровневую модель, показанную здесь на рисунке 2.

Многие из вас уже слышали о нескольких протоколах TCP/IP (примеры, которых перечислены в таблице 1). Большинство протоколов и стандартов в этой таблице будут объяснены позже более подробно.

Таблица 1. Архитектурная модель TCP / IP и примеры протоколов

Уровень модели TCP/IP	Примеры протоколов
Прикладной уровень (уровень приложений)	Система имен	DNS
Конфигурация узла	BOOTP, DHCP
Электронная почта	SMTP, POP, IMAP
Передача файлов	FTP, TFTP
Веб	HTTP
Транспортный уровень	TCP, UDP
Сетевой (межсетевой) уровень	IP, NAT
Поддержка IP	ICMP
Протоколы маршрутизации	OSPF, EIGRP
Уровень сетевого доступа (канальный уровень и физический уровень)	ARP, PPP, Ethernet, 802.11 (Wi-Fi)

Далее в этой главе мы более подробно рассмотрим уровни модели TCP/IP.

Маска subnet

Второй элемент, необходимый для работы TCP/IP, — это маска подсети. Маска подсети используется протоколом TCP/IP для определения того, находится ли хост в локальной подсети или в удаленной сети.

В TCP/IP части IP-адреса, используемые в качестве сетевых и хост-адресов, не исправлены. Если у вас нет дополнительных сведений, то сетевые и хост-адреса выше не могут быть определены. Эта информация предоставляется в другом 32-битовом номере, называемом подсетевой маской. В этом примере маска подсети — 255.255.255.0. Это не очевидно, что это число означает, если вы не знаете 255 в двоичной нотации равно 11111111. Таким образом, подсетевая маска 1111111.1111111.11111111.000000000.

Разделять IP-адрес и подсетевую маску вместе, можно разделять сетевые и хост-части адреса:

110000000.10101000.01111011.10000100 — IP-адрес (192.168.123.132)
111111111.11111111.1111111.00000000 — маска subnet (255.255.255.0)

Первые 24 бита (количество из них в подсети) определены как сетевой адрес. Последние 8 битов (количество оставшихся нулей в маске подсети) определены как адрес хоста. Он дает следующие адреса:

110000000.10101000.0111011.000000000 — адрес сети (192.168.123.0)
00000000.00000000.0000000.10000100 — адрес хозяина (000.000.000.132)

Итак, в этом примере с помощью маски подсети 255.255.255.0 используется сетевой ID 192.168.123.0, а адрес хоста — 0.0.0.132. Когда пакет поступает в подсеть 192.168.123.0 (из локальной подсети или удаленной сети) и имеет адрес назначения 192.168.123.132, компьютер получает его из сети и обрабатывает его.

Почти все маски десятичных подсетей преобразуются в двоичные числа, которые являются слева, и все нули справа. Некоторые другие распространенные подсети маски:

Десятичный двоичный 255.255.255.192 1111111.11111111.1111111.11000000 0 255.255.255.224 1111111.11111111.1111111.11100000

Internet RFC 1878 (доступна в InterNIC-Public Information Regarding Internet Domain Name Registration Services)описывает допустимые подсети и подсети, которые можно использовать в сетях TCP/IP.

IP[править]

IP — протокол, лежащий в основе Интернета, его название так и расшифровывается: Internet Protocol.

В настоящее время используются следующие две версии протокола IP:

• IPv6 — сравнительно новая (текущая версия спецификации опубликована в декабре 1998); IP-адрес имеет разрядность 128 бит и записывается в виде восьми 16-битных полей, с использованием шестнадцатеричной системы счисления и с возможностью сокращения двух и более последовательных нулевых полей до ; пример: ;
• IPv4 — «классическая» (1981 г.); IP-адрес имеет разрядность 32 бита и записывается в виде четырех десятичных чисел в диапазоне 0 … 255 через точку; пример: .

Каждый узел может напрямую связаться только с узлами своей сети (например: подключенными к тому же сегменту Ethernet), для определения которых используется адрес сети — часть IP-адреса, определяемая маской сети. Связь с узлами других сетей осуществляется через промежуточные узлы — маршрутизаторы.

Посмотреть, как выглядит маршрут пакета от вашего компьютера к другим узлам, можно с помощью команды traceroute (в Linux) или tracert (в Windows).

TL;DR

HTTP (Hypertext Transfer Protocol) — прикладной протокол, с помощью которого сервер отдаёт странички нашему браузеру. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов. На картинке светильник на микроконтроллере с ОС Contiki на борту, в котором цвета задаются через браузер.

IPv6 | IPv4 | исходники

HTTP протокол текстовый и достаточно простой. Собственно вот так выглядит метод GET, посылаемый утилитой netcat на локальный IPv6 адрес сервера с лампочками:

~$ nc fe80::200:e2ff:fe58:b66b%mazko 80 <<EOF
GET /b HTTP/1.0

EOF

Метод HTTP (англ. HTTP Method) обычно представляет собой короткое английское слово, записанное заглавными буквами, чувствительно к регистру. Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Кроме методов GET и HEAD, часто применяется методы POST, PUT и DELETE. Метод GET используется для запроса содержимого указанного ресурса, в нашем случае тут где путь /b отвечает за цвет (синий). Ответ сервера:

HTTP/1.0 200 OK
Server: Contiki/2.4 http://www.sics.se/contiki/
Connection: close
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-type: text/html

<html><head><title>Contiki RGB</title></head><body>
<p style='color:red;'>Red is <a href='/r'>OFF</a></p>
<p style='color:green;'>Green is <a href='/g'>OFF</a></p>
<p style='color:blue;'>Blue is <a href='/b'>ON</a></p>
</body></html>

Код состояния (у нас 200) является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. В нашем случае сервер отработал без ошибок, всё пучком (ОК).

Как запрос, так и ответ содержат заголовки (каждая строка — отдельное поле заголовка, пара имя-значение разделена двоеточием). Заканчиваются заголовки пустой строкой, после чего могут идти данные.

Мой браузер отказывается открывать локальный IPv6-адрес, поэтому в прошивке микроконтроллера прописан дополнительный адрес и такой же префикс также нужно назначить виртуальному сетевому интерфейсу симулятора:

~$ sudo ip addr add abcd::1/64 dev mazko          # linux
~$ netsh interface ipv6 set address mazko abcd::1 # windows
~$ curl http://

Если curl отработал без ошибок, то ссылку можно спокойно открывать в браузере.