Запущен tcp сервер он слушает порт 7 сколько сокетов связано

Обновлено: 05.07.2024

Состояние соединения TCP и изучение соответствующих команд

Что такое протокол TCP

Транспортный уровень (уровень 4) в модели OSI является сквозным транспортным протоколом.
Ориентированный на соединение и надежный протокол
Надежная передача через контрольную сумму, серийный номер, ответ подтверждения, контроль повторной передачи, контроль окна и другие механизмы
Он состоит из трех этапов: установление соединения, передача данных и освобождение соединения
Используйте три рукопожатия, чтобы установить соединение, и четыре волны, чтобы закрыть соединение

Чтобы понять состояние соединения TCP, вы должны сначала понять, что происходит с трехсторонним рукопожатием и четырехсторонней волной TCP.На следующем рисунке показана диаграмма перехода состояний трехстороннего рукопожатия и четырехсторонней волны TCP (рисунок из статьи «Zhuhu»)."Три рукопожатия, четыре волны" Вы действительно понимаете?》）：

Не путайте клиент / сервер на рисунке с клиентским сервером в проекте: сторона, которая инициирует соединение или активно закрывает соединение, является клиентом, а пассивная - сервером. Служба может выступать как клиентом, так и сервером.

TCP трехстороннее рукопожатие

Трехстороннее рукопожатие, чтобы клиент и сервер могли подтвердить, могут ли они получать и отправлять данные друг другу:

Первое рукопожатие: клиент сначала отправляет пакет SYN (j) в качестве запроса на установление соединения, подтверждая, является ли его способность отправки нормальной
Второе рукопожатие: Сервер отвечает ответом подтверждения пакета ACK (j + 1) на пакет SYN Клиента и отправляет пакет SYN (k) Клиенту, чтобы указать, что ему нужно установить соединение, подтверждая свою собственную передачу, подтверждая, что у него есть возможности приема. способность
Третье рукопожатие: после приема пакета SYN + ACK Клиент отправляет ответ подтверждения пакета ACK (k + 1), указывающий, что его возможности приема являются нормальными. В это время три установления связи завершены, чтобы установить надежное соединение

Четыре волны TCP

Четыре волны в основном позволяют клиенту и серверу нормально закрывать соединение, гарантируя, что данные не будут потеряны перед закрытием соединения:

Первая волна раздач: клиент отправляет пакет FIN для запроса на отключение
Вторая волна: Когда Сервер получает пакет FIN, он немедленно отвечает ACK для подтверждения ответа, указывая, что я получил ваш запрос на закрытие соединения. В настоящее время Сервер имеет возможность получать данные
Третья волна: через некоторое время, когда сервер подтверждает, что данные на клиенте приняты, он отправляет пакет FIN, чтобы закрыть соединение и больше не получать данные
Четвертая волна: когда Клиент получает FIN, он немедленно отвечает ACK для подтверждения, а затем ожидает 2MSL, чтобы закрыть соединение

Состояние TCP-соединения

Во время трехстороннего рукопожатия, передачи данных и четырехсторонней волны TCP мы определили множество состояний для клиента и сервера, чтобы описать весь процесс, и объединились с приведенной выше диаграммой перехода состояний, чтобы понять эти определения состояний:

LISTEN (сервер): прослушивание запросов на подключение от удаленного порта TCP.После запуска сервера он находится в состоянии LISTEN для отслеживания запросов TCP от разных клиентов и установления соединения.
SYN-SENT (клиент): во время трехстороннего рукопожатия клиент находится в состоянии ожидания установления соединения после отправки SYN для запроса
SYN_RCVD (сервер): во время трехстороннего установления связи, когда сервер получает сигнал SYN от клиента, он отправляет флаги ACK и SYN клиенту для установления соединения, и сервер находится в состоянии SYN_RCVD
УСТАНОВЛЕН (сервер и клиент): после успешного трехстороннего рукопожатия клиент и сервер находятся в состоянии передачи данных
FIN-WAIT-1 (клиент): при четырехкратном махании клиент отправляет запрос FIN прерывания FIN для получения подтверждения прерывания от сервера
CLOSE_WAIT (Сервер): при четырехкратном колебании Клиент получает от клиента ответ на запрос FIN и отвечает ACK, чтобы подтвердить состояние отправки пакета FIN
FIN-WAIT-2 (Клиент): Когда четыре раза размахивают, когда Клиент получает ACK ответа Сервера на FIN, а затем получает пакет FIN от Сервера.
LAST_ACK (сервер): при четырехкратном колебании сервер отправляет запрос FIN для закрытия соединения до состояния перед закрытием соединения
TIME_WAIT (клиент): когда клиент машет четыре раза, клиент отвечает ACK на FIN сервера в состояние до закрытия соединения, также известное как состояние 2MSL
ЗАКРЫТЬ (сервер и клиент): состояние после закрытия соединения между сервером и клиентом

При нормальных обстоятельствах процесс перехода состояния клиента выглядит следующим образом:

В нормальных условиях процесс перехода состояния сервера выглядит следующим образом:

Некоторые проблемы в TCP трехстороннем рукопожатии и четырехстороннем переходе состояния волны

Что такое MSL?

Что такое TTL?

Что такое RTT?

Что такое MTU?

Что такое MSS?

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

При четырехкратном махании, почему Клиент не закрывает соединение сразу после завершения ACK для Сервера, и должно быть состояние TIME_WAIT (2MSL)?

Как улучшить, если на сервере много TIME_WAIT?

Как улучшить, если на сервере много CLOSE_WAIT?

SYN FLOOD атака

О сокете

Одно TCP-соединение соответствует одному сокету
Уникальный идентификатор сокета:
Служба TCP в состоянии прослушивания может взаимодействовать с сокетами от нескольких клиентов одновременно
Разные процессы могут прослушивать один и тот же порт, если их протоколы (TCP / UDP) разные
Один процесс может открывать и закрывать несколько сокетов
Дочерний процесс может наследовать все файловые дескрипторы (FD) от родительского процесса, поэтому, если между различными процессами или потоками существуют отношения родитель-потомок, вы можете использовать один и тот же сокет
Службе TCP в состоянии прослушивания нужен только один порт прослушивания, но можно установить несколько сокетов
Число соединений с сокетами, которые могут быть созданы портом на сервере, теоретически не имеет верхнего предела, это зависит от объема памяти системы и верхнего предела файловых дескрипторов, которые могут быть созданы. Его можно установить, изменив верхний предел файловых дескрипторов.

Связанные команды в соединении TCP

команда netstat

netstat используется для печати сетевых подключений, таблиц маршрутизации, статистики данных подключений и т. д. С помощью этой команды можно подсчитать различные состояния подключения, которые мы ввели выше.

Введение параметра

Список всех соединений TCP:

Только список подключений, которые слушают:

Просмотр имени процесса и имени пользователя в мониторинге

Посмотреть сетевой интерфейс:

Тот же эффект, что и для ifconfig и ip a

Статистика TCP каждого состояния подключения информации:

команда ping

Команда ping используется для проверки доступности сети к хосту назначения. Она может получить имя домена или IP-адрес и не может проверить порт. Она работает на третьем уровне эталонной модели OSI - сетевом уровне.

Команда ping и команда traceroute реализованы по протоколу ICMP, хотя инструмент ping также может его обнаружить, но из-за ограничения заголовка ip, ping не может полностью записать проходящий маршрутизатор. Таким образом, traceroute просто заполняет этот недостаток, поэтому, если вы хотите запросить всю информацию о маршрутизации, вам все равно нужен traceroute

команда traceroute

Принцип raceroute заключается в использовании механизма уведомления ICMP с истекшим сроком действия ttl. Каждый раз при непрерывном увеличении ttl для непрерывного обнаружения маршрута следующего прыжка traceroute отправляет дейтаграмму с номером порта> 30000, поэтому, когда он достигает хоста назначения, он получает порт недоступным. ICMP ответил, что хост-источник знает, что хост может быть подключен.

Команда raceroute позволяет отслеживать маршрутизацию сетевых пакетов и время, потребляемое каждым шлюзом. Размер пакета по умолчанию составляет 40 байт.
Выходные данные raceroute увидят, что есть несколько строк, обозначенных звездочками, возможно потому, что брандмауэр заблокировал возвращаемую информацию ICMP, поэтому мы не можем получить какие-либо связанные пакеты данных для возврата данных
Каждый раз, когда пакет данных поступает в один и тот же пункт назначения из определенного источника, путь, по которому он идет, может отличаться, но в основном маршрут, по которому проходит большую часть времени, является одним и тем же.
По умолчанию каждый прыжок будет отправлять 3 пакета, но это может быть не тот же IP-адрес, поскольку между двумя шлюзами может быть стратегия балансировки нагрузки, поэтому в некоторых записях может быть 2 или 3 IP-адреса.
Список маршрутов, которые могут быть записаны заголовком ip, очень ограничен, поэтому traceroute увеличивает скорость отправки ttl, поэтому traceroute возвращается медленнее, чем дальше назад traceroute
Описание основных параметров:

команда lsof

lsof (список открытых файлов) - это инструмент для просмотра текущих системных файлов. В среде Linux все существует в форме файла. Через этот файл вы можете не только получать доступ к обычным данным, но также получать доступ к сетевым подключениям и оборудованию. Например, сокеты протокола управления передачей (TCP) и протокола пользовательских дейтаграмм (UDP) и т. Д., Система выделит дескриптор файла для приложения в фоновом режиме, дескриптор файла предоставляет много информации о самом приложении. ,

Это может быть очень простой вопрос, но он меня смущает.

могут ли два разных подключенных сокета совместно использовать порт? Я пишу сервер приложений, который должен обрабатывать более 100k параллельных подключений, и мы знаем, что количество портов, доступных в системе, составляет около 60k (16bit). Подключенный сокет присваивается новый (выделенный) порт, так что это означает, что количество одновременных подключений ограничено количеством портов, если несколько розеток, может общий порт. Итак, вопрос.

Спасибо за помощь заранее!

A сервер сокет прослушивает один порт. Все установленные клиентские соединения на этом сервере связаны с тем же самым портом прослушивания на стороне сервера подключение. Установленное соединение однозначно идентифицируется комбинацией пар IP/порт на стороне клиента и на стороне сервера. Несколько соединений на одном сервере могут совместно использовать один и тот же на стороне сервера пара IP / Port покуда они связаны с различным на стороне клиента пары IP / Port и сервер сможет обрабатывать столько клиентов, сколько позволяют доступные системные ресурсы.

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

Итак, что происходит, когда сервер прослушивает входящие соединения на TCP-порт? Например, скажем, у вас есть веб-сервер на порту 80. Предположим, что ваш компьютер имеет общедоступный IP-адрес 24.14.181.229, а человек, который пытается подключиться к вам, имеет IP-адрес 10.1.2.3. Этот человек может подключиться к вам, открыв TCP-сокет 24.14.181.229: 80. Все очень просто.

интуитивно (и ошибочно), большинство людей предполагают, что это выглядит примерно так:

это интуитивно, потому что с точки зрения клиента, он имеет IP-адрес и подключается к серверу по IP:порт. Так как клиент подключается к порту 80, то его порт тоже должен быть 80? Это разумная вещь, чтобы думать, но на самом деле не происходит. Если бы это было правильно, мы могли бы обслуживать только одного пользователя на иностранный IP-адрес. Как только удаленный компьютер подключится, он будет использовать порт 80 подключение к порту 80, и никто не мог подключиться.

необходимо понять три вещи:

1.) На сервере, процесс слушать на порт. Как только он получает соединение, он передает его другому потоку. Связь никогда не загоняет подслушивающий порт.

2.) Соединения однозначно идентифицируются ОС следующим 5-кортежем: (local-IP, local-port, remote-IP, remote-port, protocol). Если какой-либо элемент в кортеже другое, тогда это совершенно независимое соединение.

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

64k подключений к серверу для того же порта назначения.

Итак, это действительно то, что создается, когда клиент подключается к серверу:

глядя на то, что на самом деле происходит

во-первых, давайте использовать netstat, чтобы увидеть что происходит на этом компьютере. Мы будем использовать порт 500 вместо 80 (потому что на порту 80 происходит целая куча вещей, поскольку это общий порт, но функционально это не имеет значения).

как и ожидалось, выход пуст. Теперь давайте запустим веб-сервер:

теперь, вот результат запуска netstat снова:

Итак, теперь есть один процесс, который активно слушает (состояние: LISTEN) на порту 500. Местный житель адрес 0.0.0.0, который является кодом для "прослушивания всех ip-адресов". Простая ошибка-прослушивать только порт 127.0.0.1, который будет принимать соединения только с текущего компьютера. Таким образом, это не соединение, это просто означает, что процесс, запрошенный для привязки() к IP-Порту, и этот процесс отвечает за обработку всех подключений к этому порту. Это намекает на ограничение, что может быть только один процесс на компьютер, прослушивающий порт (есть способы обойти это использование мультиплексирования, но это гораздо более сложная тема). Если веб-сервер прослушивает порт 80, он не может совместно использовать этот порт с другими веб-серверами.

Итак, теперь давайте подключим пользователя к нашей машине:

это простой скрипт (https://github.com/grokit/quickweb), который открывает TCP-сокет, отправляет груз ("тест на грузоподъемность."в данном случае), ждет несколько секунд и отключается. Выполнение netstat снова, пока это происходит, отображает следующий:

если вы подключитесь к другому клиенту и снова выполните netstat, вы увидите следующее:

. то есть клиент использовал для подключения другой случайный порт. Поэтому никогда нет путаницы между IP-адресами.

подключенный сокет назначается новому (выделенному) порту

Это обычная интуиция, но это неправильно. Подключенный сокет не назначается новому / выделенному порту. Единственным фактическим ограничением, которое должен удовлетворять стек TCP, является то, что кортеж (local_address, local_port, remote_address, remote_port) должен быть уникальным для каждого соединения сокета. Таким образом, сервер может иметь много сокетов TCP, использующих один и тот же локальный порт, пока каждый из сокетов на порт подключен к другому удаленному местоположению.

Теоретически, да. Практика, нет. Большинство ядер (ВКЛ. linux) не позволяет вам второй bind() к уже выделенному порту. Это был не очень большой участок, чтобы сделать это разрешенным.

концептуально, мы должны различать между гнездо и порт. Сокеты - это двунаправленные конечные точки связи, то есть" вещи", где мы можем отправлять и получать байты. Это концептуальная вещь, нет такого поля в заголовке пакета с именем "розетка."

Port-это идентификатор, который способен идентифицировать сокет. В случае TCP порт является 16-битным целым числом, но есть и другие протоколы (например, в сокетах unix "порт" по существу является строкой).

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

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

Сервер TCP

Создание структуры сервера показано на следующей функциональной диаграмме:

Вот полный код программы SocketServer.cs:

Давайте рассмотрим структуру данной программы.

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

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

Создадим IPEndPoint для сервера, комбинируя первый IP-адрес хост-компьютера, полученный от метода Dns.Resolve(), с номером порта:

Здесь класс IPEndPoint представляет localhost на порте 11000. Далее новым экземпляром класса Socket создаем потоковый сокет. Установив локальную конечную точку для ожидания соединений, можно создать сокет:

Перечисление AddressFamily указывает схемы адресации, которые экземпляр класса Socket может использовать для разрешения адреса.

В параметре SocketType различаются сокеты TCP и UDP. В нем можно определить в том числе следующие значения:

Dgram

Поддерживает дейтаграммы. Значение Dgram требует указать Udp для типа протокола и InterNetwork в параметре семейства адресов.

Raw

Поддерживает доступ к базовому транспортному протоколу.

Stream

Поддерживает потоковые сокеты. Значение Stream требует указать Tcp для типа протокола.

Третий и последний параметр определяет тип протокола, требуемый для сокета. В параметре РrotocolType можно указать следующие наиболее важные значения - Tcp, Udp, Ip, Raw.

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

Метод Bind() связывает сокет с локальной конечной точкой. Вызывать метод Bind() надо до любых попыток обращения к методам Listen() и Accept().

В параметре определяется задел (backlog), указывающий максимальное число соединений, ожидающих обработки в очереди. В приведенном коде значение параметра допускает накопление в очереди до десяти соединений.

В состоянии прослушивания надо быть готовым дать согласие на соединение с клиентом, для чего используется метод Accept(). С помощью этого метода получается соединение клиента и завершается установление связи имен клиента и сервера. Метод Accept() блокирует поток вызывающей программы до поступления соединения.

Метод Accept() извлекает из очереди ожидающих запросов первый запрос на соединение и создает для его обработки новый сокет. Хотя новый сокет создан, первоначальный сокет продолжает слушать и может использоваться с многопоточной обработкой для приема нескольких запросов на соединение от клиентов. Никакое серверное приложение не должно закрывать слушающий сокет. Он должен продолжать работать наряду с сокетами, созданными методом Accept для обработки входящих запросов клиентов.

Когда обмен данными между сервером и клиентом завершается, нужно закрыть соединение используя методы Shutdown() и Close():

SocketShutdown — это перечисление, содержащее три значения для остановки: Both - останавливает отправку и получение данных сокетом, Receive - останавливает получение данных сокетом и Send - останавливает отправку данных сокетом.

Сокет закрывается при вызове метода Close(), который также устанавливает в свойстве Connected сокета значение false.

Клиент на TCP

Функции, которые используются для создания приложения-клиента, более или менее напоминают серверное приложение. Как и для сервера, используются те же методы для определения конечной точки, создания экземпляра сокета, отправки и получения данных и закрытия сокета:

Вот полный код для SocketClient.cs и его объяснение:

Единственный новый метод - метод Connect(), используется для соединения с удаленным сервером. На рисунке ниже показаны клиент и сервер в действии:

я наверное что-то не понимаю. как вообще может быть на одной машине больше 65536 открытых сокетов?

открытый сокет это не порт+айпи. Это айпи+порт на одной стороне + айпи+порт на другой. Т.е. это комбинация четырёх чисел, а не двух.

Но это только для ipv4 сокетов. Если брать юникс сокеты, то там грубо говоря всё ограничено только ресурсами ядра.

~~nanoolinux~~ ★★★★ ( 17.02.14 19:47:27 )
Последнее исправление: nanoolinux 17.02.14 19:48:45 (всего исправлений: 1)

точно, ведь необязательно один ip

Можно и на одном IP. Если ты слушаешь сокет и к тебе подсоединилось 100000 клиентов, с твой стороны это 100000 сокетов не только на одном IP но и на одном порту.

каким образом? что кроме sysctl net.ipv4.ip_local_port_range крутить чтобы столько открылось?

сколько максимально открывали на одном ip, что крутили для этого и где об этом почитать?

Ничего не надо крутить. Я же сказал, на слушающей стороне используется только один порт.

Ничего не надо крутить. Я же сказал, на слушающей стороне используется только один порт.

Да положим на сервере один ip и один порт, но при соединении на сервере создается сокет этого соединения. Вот это почитай:

Приведи пример как это обойти.

Ещё раз повторяю: количество сокетов ограничено только ресурсами системы и никак не связано с ограничением количества портов. На сервере используется _один_ порт, поэтому его эта проблема не касается и на нём будет создаваться столько сокетов, сколько хватит памяти. На клиентах, понятное дело, нужно тюнить диапазоны портов и/или использовать разные адреса.

может ulimit(1), недавно обсуждали. Ещё ulimit(3) и по ссылкам. Hint: Сокеты тоже файлы.

как вообще может быть на одной машине больше 65536 открытых сокетов?

порты никакого отношения к сокетам не имеют. Разве что слушать ты можешь не больше 65536 сокетов, ибо если один порт слушать двумя сокетами(сразу), получится ерунда.

но при соединении на сервере создается сокет этого соединения.

это уже после соединения.

положим есть сервер и есть миллион клиентов, каждый клиент ломится на один и тот же ip сервера, на один и тот же порт и устанавливает одно соединение. Но сервер когда делать accept() порождает новый сокет на каждое новое соединение, так вот упирается сервер в потолок. sysctl net.ipv4.ip_local_port_range помогает поднять потолок выше. но все одно это не миллион соединений. как сделать миллион на одном IP:PORT?

память свободная есть, ulimit поднят на файлы и память.

память свободная есть, ulimit поднят на файлы и память.

а что за ошибка?

количество pid например в системе всего 32767, хотя вроде и можно вкомпилить где-то в ядре чтобы больше

насколько я помню новые соединения просто не проходят и все. это давно был старый тест, буду писать новый

Но сервер когда делать accept() порождает новый сокет на каждое новое соединение, так вот упирается сервер в потолок. sysctl net.ipv4.ip_local_port_range помогает поднять потолок выше

насколько я помню новые соединения просто не проходят и все. это давно был старый тест, буду писать новый

давай код, посмотрим.

подправьте ip/port, сделайте ulimit -n 1000000, запустите server и натравите на него один или несколько client с одной или нескольких машин и добейтесь миллиона открытых соединений на сервере.

и как это заставить принять 1000 000 коннектов?

А что у тебя не получается конкретно, в каком месте затык?

Выставляем /proc/sys/fs/file-max, потом ulimit -Hn с ulimit -Sn, в сервере привязываем по INADDR_ANY и тогда даже с одной машины клиентами можно подключаться по любым адресам интерфейсов (то есть по 127.*.*.* при маске 255.0.0.0 на lo, по любым его aliasам (lo:1, lo:2, . с соответствующими IP) и т.д. для других интерфейсов) — каждый клиент количество портов исчерпывает, но на сервере соединений может быть сколько угодно (можно /proc/sys/net/ipv4/ip_local_port_range сделать совсем небольшим — не важно).

Вообще соединение это (адрес1, порт1, адрес2, порт2) — сервер берёт адрес1 и порт1, в простом случае клиенты на той же машине берут тот же адрес2 и исчерпывают порты в порт2, так что может показаться то что тебе кажется, но на самом деле ведь есть ещё адрес2 — локально его можно варьировать (как с INADDR_ANY), ну а нормально при разных машинах он будет и так разным.

как сделать миллион на одном IP:PORT

пойми простой момент, для идентификации соединения используется не пара IP:PORT, а четвёрка LOCAL_IP:LOCAL_PORT:REMOTE_IP:REMOTE_PORT

поэтому для одного ip и одного порта ты можешь открыть сколько угодно соединений от разных клиентов, хоть миллион (хотя наверное конечно есть какое то ограничение, может там я не знаю int 32-разрядный или ещё что.. но это точно не 65к, а сильно больше).

AndreyKl ★★★★★ ( 20.02.14 02:25:11 )
Последнее исправление: AndreyKl 20.02.14 02:28:04 (всего исправлений: 1)

локально его можно варьировать (как с INADDR_ANY)

То есть адрес сервера при INADDR_ANY может варьироваться. А адрес клиента можно прямо с помощью bind присваивать если на интерфейсе(ах) есть что. Например:

На каждом из параллельных клиентов на своих адресах (что их отличает) < 65K, на сервере — больше.

Если не введено дополнительных ограничений (типа maxfiles) то никак не надо - примет из коробки.

Читайте также: