Порт в компьютерных сетях представляет собой натуральное число, которое записывается в заголовке протокола OSI. Он предназначен для идентификации процесса-получателя пакета в одном хосте.
Как правило, в пространстве пользователя на хосте с установленной ОС происходит несколько процессов одновременно, и в каждом из них работает определенная программа. Если же эти программы затрагивают компьютерную сеть, «оболочка» время от времени получает через нее IP-пакет, который предназначается для одной из программ.
Как это работает?
Если программа использует обмен данными через сеть, этот процесс может происходить следующим образом:
- У ОС запрашивается определенный номер порта. При этом система может как предоставить его программе, так и запретить передачу (это происходит в случаях, если этот номер порта уже используется другим приложением).
- У ОС запрашивается не конкретизированный номер порта, в любой свободный. Система сама выбирает его и предоставляет программе.
Как открыть порт (8080, 80 и так далее)? Внутри сети обмен информацией происходит согласно определенному протоколу (между двумя процессами). Чтобы соединение было установлено, требуется следующее:
- IP-адреса хостов получателя и отправителя (необходимы, чтобы между ними был построен маршрут);
- Номер протокола;
- Номера обоих портов (получателя и отправителя).
Если соединение происходит по протоколу TCP, то порт отправителя применяется как ОС получателя для передачи подтверждения о полученных данных, так и процессом получателем для передачи ответа.
Открытые и закрытые порты
Со стороны отправителя хост и номер порта выступают в качестве аналога обратного адреса, который указывается на конвертах. Такой номер называют обратным.
В случаях, когда какой-либо процесс на хосте на постоянной основе использует один и тот же номер порта, такой порт считается открытым. К примеру, программа, связанная с сервером, может все время использовать 80 или 8080 для связи. Когда процесс не может открыть порт, тот считается закрытым.
Номера портов
Все порты имеют свои номера, зарегистрированные в установленном порядке. Каждый из них предназначен для своей специфической цели. Так, при работе в интернете часто можно увидеть порт 8080. Для чего нужен такой функционал?
Согласно официальным данным, этот порт работает по протоколу TCP и предназначен для использования с HTTP. Неофициально он также используется контейнером сервлетов Tomcat, написанным на языке Java.
TCP-порт 8080 может использовать определенный протокол для связи, в зависимости от приложения. Протокол представляет собой набор формализованных правил, который объясняет, как данные передаются по сети. Это можно представить в качестве языка, который применяется между компьютерами, чтобы помочь им общаться более эффективно.
Протокол HTTP, который работает через 8080, определяет формат связи между интернет-браузерами и веб-сайтами. Другим примером является протокол IMAP, который определяет связь между почтовыми серверами IMAP и клиентами или, наконец, протокол SSL, в котором указывается формат, используемый для шифрованных сообщений.
Передача данных
Таким образом, TCP-порт 8080 использует протокол управления передачей. Он является одним из основных протоколов в сетях TCP/IP. В то время как протокол IP имеет дело только с пакетами, TCP позволяет двум хостам устанавливать соединение и обмениваться потоками данных. Он гарантирует их доставку, а также то, что пакеты будут доставлены на порт 8080 в том же порядке, в котором они были отправлены. Гарантированная связь по 8080 - это ключевое различие между TCP и UDP. UDP 8080 не гарантировал бы соединение так же.
Как открыть порт 8080 в Windows 7?
Для этого необходимо зайти в меню «Пуск» и найти Панель управления. В ней требуется нажать на подменю «Сеть» и найти в нем «Бранмауэр». Во вкладке «Исключения» найдите пункт «Добавить порт». У вас откроется диалоговое окно, в котором потребуется ввести номер порта. Убедитесь в том, что в настройках указан TCP, после чего выберите ОК.
Как закрыть порт 8080? Для этого достаточно настроить подключение на другой определенный порт.
Расширенная настройка прокси-сервера HTTP и TCP
Протокол HTTP работает поверх протокола TCP, но предоставляет дополнительную информацию о назначении сообщения. По этой причине два прокси настраиваются по-разному.
HTTP-трафик включает в себя целевой хост и порт для сообщения. Он отправляется по TCP-соединению с конечной точкой TCP, то есть между определенным хостом и портом. Как правило, HTTP-сообщение указывает на ту же конечную точку, что и TCP-соединение. Если вы изменяете конфигурацию клиента для использования прокси-сервера HTTP, соединение выполняется с другим хостом и портом, вместо указанного в URL-адресах HTTP. Это означает, что конечная точка TCP в сообщении отличается от той конечной, к которой она подключена.
Например, если HTTP-запрос отправлен на страницу http://192.0.2.1:8080/operation, запрос включает в себя «192.0.2.1:8080» в заголовке «Host» HTTP-сообщения, которое отправляется на 8080 порт на хосте 192.0.2.1.
Однако, если вы настроите HTTP-клиент на использование прокси-сервера, базовое TCP-соединение переходит к конечной точке TCP для него, в то время как сообщения все еще содержат исходную конечную точку.
Например, если вы настроите клиент на отправку своих сообщений на прокси-сервер по адресу 198281.100.1 порт 3128, а клиент отправит запрос для http://192.0.2.1:8080/operation, сообщение все еще содержит «192.0.2.1: 8080 »в заголовке« Host », а теперь также в поле« Request-Line ». Однако это сообщение теперь отправляется через TCP-соединение по адресу 198.51.100.1:3128. Таким образом, прокси-сервер HTTP может получать сообщения на одном порту (прокси-порт 8080) и может пересылать их нескольким различным службам на основе информации о получателе.
Как настроить прием подключений через порт 8080?
Итак, заголовок «Host» был добавлен в HTTP/1.1. Соединения HTTP/1.0 не включает его в себя. По этой причине такие соединения, которые не проходят через прокси, не включают в себя хост и порт для сообщения. Однако информация по HTTP/1.0, отправленная через прокси-сервер, по-прежнему содержит целевой хост и порт в «строке запроса». Поэтому отсутствие заголовка «Host» не вызывает проблемы для прокси.
Чтобы включить прокси-сервер TCP, вы должны изменить конфигурацию клиента с конечной точки TCP в реальном времени на заменяемую конечную точку. В отличие от HTTP, этот протокол не обеспечивает встроенную возможность использования прокси. То есть, если вы подключаетесь к прокси-серверу через TCP, для передачи информации конечному адресату не предусмотрен какой-либо механизм.
Как настроить множественное соединение с помощью 8080?
Единственный способ для прокси-сервера TCP разрешить соединения с несколькими системами (то есть с конечными точками назначения), независимо от того, какой трафик будет отправлен по этим соединениям, - это прослушивание другого порта для каждой из систем. Это позволяет подключать и поддерживать информацию о том, какой из ее номеров портов соответствует каждой конечной точке. Затем клиент настраивается с прокси-портом, соответствующим каждой системе, с которой ему нужно соединиться. Прокси-порты TCP для прослушивания и соответствующие им конечные точки настраиваются в операторах <forward> в файле конфигурации прокси, RTCP_install_dir / httptcp / registration.xml. В первую очередь, необходимо проверить порт 8080 – если он открыт по умолчанию, дальнейшие настройки будут сделаны за несколько минут.
В этом примере 198.51.100.1 является IP-адресом прокси-сервера. Любой трафик, отправленный на порт 3333 на прокси-сервер, отправляется на порт 8080 по адресу: www. Example. com:
<Forward bind = "198.51.100.1:3333" destination = "www. example. com:8080" />
Поэтому вы должны изменять файл конфигурации клиента всякий раз, когда вы добавляете новый пункт назначения для трафика. Это ограничение не распространяется на HTTP-прокси.
Взаимодействие между HTTP и TCP
Чтобы понять, как порты обрабатываются в прокси-серверах HTTP и TCP, предположим, что у вас есть две службы: на 192.0.2.1:8080 и 192.0.2.1:8081, и прокси-сервер, работающий на 198.51.100.1. Если же они отличаются по IP-адресу, а не по номеру порта, этот пример будет таким же, за исключением соответствующего адреса для каждой службы. Если они ожидают HTTP-трафик на один HTTP-прокси-порт, запросы на обе конечные точки TCP могут быть отправлены на него. Когда HTTP видит, что сообщение адресовано 192.0.2.1:8080, прокси перенаправляет сообщение на этот адрес или применяет любые правила, которые он имеет для этой службы. Эта же процедура применяется к 192.0.2.1:8081, используя тот же самый порт.
Если эти две службы вместо этого ожидают трафик TCP, должны быть открыты два TCP-прокси-порта, определенные двумя элементами <forward> в файле конфигурации:
<Forward bind = "198.51.100.1:3333" destination = "192.0.2.1:8080" />
<Forward bind = "198.51.100.1:3334" destination = "192.0.2.1:8081" />
Конфигурация клиента для первой службы изменяется с «192.0.2.1:8080» на «198.51.100.1:3333», а для второй - с «192.0.2.1:8081» до «198.51.100.1:3334». Клиент отправляет сообщение (пакет TCP) первой службе по первому адресу.
Прокси-сервер получает его на этом порту (3333), но не знает, какие данные отправляются по этому соединению. Все, что ему известно - это подключение к порту 3333. Поэтому прокси-сервер консультируется с его конфигурацией и видит, что трафик на этот порт должен быть перенаправлен на 192.0.2.1:8080 (или что к нему необходимо применить правило для этой службы). Если вы не можете перенаправить весь свой HTTP-трафик, поскольку конфигурация клиента не поддерживает конфигурацию прокси-сервера HTTP, вы должны использовать обратный HTTP-прокси.
В нем вместо целевого URL-адреса вы указываете нужный вам. Этот процесс аналогичен процессу настройки прокси-сервера TCP, в котором вы указываете его в качестве конечной точки TCP для сообщения в клиентской системе и создаете правило пересылки.
Разница заключается в том, что вы добавляете атрибут типа в правило, определяющее HTTP, как в следующем примере: <forward bind = "198.51.100.1:3333" destination = "192.0.2.1:8080" type = "HTTP" /> .
Как идет движение трафика?
Теперь прокси-сервер настроен на прием только HTTP-трафика на назначенный порт, и может применять более богатую фильтрацию. Например, сервер может отфильтровать трафик на заглушку, которая не имеет определенного пути в своем URL-адресе, или который не использует определенный HTTP-метод, такой как POST. Однако, поскольку заглушка не всегда работает, сервер все еще нуждается в адресате из элемента <forward>, чтобы иметь возможность отправлять трафик в систему. Например, предположим, что клиенту необходимо подключиться к службе на 192.0.2.1:8080 и использовать обратный HTTP-прокси на 198.51.100.1:3333.
Прежде, чем клиент сможет использовать прокси-сервер, конфигурацию клиента для этой службы необходимо изменить с URL-адреса, например http:// 192.0.2.1:8080/ operation, на http:// 198.51.100.1:3333/ operation. Запрос, который отправляется на этот новый URL-адрес, попадает в прокси-сервер.
Сообщение запроса содержит конечную точку TCP для прокси (198.51.100.1:3333) в заголовке «Хост», а не адрес системы, потому что клиент не знает, что он отправляет перенаправленное сообщение. Эта упрощенная клиентская роль определяет природу такого соединения. Таким образом, прокси использует элементы <forward>, чтобы знать, что запрос, поступающий на порт 3333, требует одно из следующих действий: он должен быть перенаправлен в живую систему на 192.0.2.1:8080, а заголовок «Host» в сообщении должен быть обновлен. Для сообщения должны применяться все правила этой службы, например, маршрутизация на заглушку.
