Используют ли веб-браузеры разные исходящие порты для разных вкладок?


58

В веб-браузере, который поддерживает наличие нескольких вкладок, таких как Firefox, используют ли разные вкладки, которые переходят на разные домены сайта, выделенный порт для каждого домена?

Или браузер использует один порт для управления всеми вкладками и, следовательно, всеми доменами?


Браузеры используют 2 порта при подключении к веб-сайтам, 80 - для http-подключений, 443 - для https-подключений. en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Моав,

7
Я знаю порты, используемые для подключения к серверу, но мне было интересно узнать о номерах портов, используемых для подключения с клиента (хост-компьютера).
yoyo_fun

2
Я думаю, что термин «исходящие порты» является неточным. Порты двунаправленные. Может быть, вы могли бы сказать. "локальные порты" вместо. Локальные порты используются в качестве исходных (исходящих) портов для отправки запросов и конечных (входящих) портов для получения ответов.
Рон Мопин

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

1
@ExUmbris: Это может быть разумной и простой стратегией, но TCP-соединения идентифицируются с помощью четырех {локальный IP, локальный порт, удаленный IP, удаленный порт}. Локальный порт не нужен для уникальности, и это хорошо: веб-сервер вообще не может использовать свой локальный порт для уникальности. И с точки зрения веб-сервера, удаленный IP также не уникален, так как несколько пользователей могут находиться за одним шлюзом / прокси.
MSalters

Ответы:


55

Используют ли браузеры разные порты для подключения к разным веб-сайтам?

Да, они делают.

Вот пример, показывающий мои текущие подключения Firefox (у меня 9 открытых вкладок) в Windows 7:

введите описание изображения здесь

Примечания:

  • Вы можете видеть, что все локальные порты разные.

  • Удаленные порты обычно 80 (HTTP), 443 (HTTPS) или 8080 (альтернативный HTTP).

  • Полный процесс рендеринга веб-страницы описан ниже. Смотрите, в частности, шаги 5, 6, 13 и 15 (которые выделены жирным шрифтом):

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

    • Это связано с тем, что веб-страницы часто содержат ресурсы, размещенные в других местах (файлы JavaScript и т. Д.).

  • Несколько соединений с одним и тем же веб-сайтом (например, stackoverflow.com) также имеют разные локальные порты (поскольку они являются отдельными соединениями на разных вкладках, отображающих разные страницы).


Рендеринг веб-страницы - шаг за шагом

Примечание:

  • Шаги 5, 6, 13 и 15 (выделены жирным шрифтом) имеют прямое отношение к вопросу.

Задумывались ли вы о том, что происходит, когда вы путешествуете в Интернете? Это не так просто, как кажется:

  1. Вы вводите URL в адресную строку в вашем браузере.
  2. Браузер анализирует URL-адрес, чтобы найти протокол, хост, порт и путь.
  3. Он формирует HTTP-запрос (это, скорее всего, протокол)
  4. Чтобы добраться до хоста, сначала нужно перевести понятный человеку хост в IP-номер, и это делается путем поиска DNS на хосте.
  5. Затем необходимо открыть сокет с компьютера пользователя по этому IP-номеру на указанном порту (чаще всего это порт 80).
  6. Когда соединение открыто, HTTP-запрос отправляется на хост
  7. Хост перенаправляет запрос на серверное программное обеспечение (чаще всего Apache), настроенное для прослушивания на указанном порту.
  8. Сервер проверяет запрос (чаще всего только путь) и запускает плагин сервера, необходимый для обработки запроса (соответствующий используемому вами языку сервера: PHP, Java, .NET, Python?)
  9. Плагин получает доступ к полному запросу и начинает готовить HTTP-ответ.
  10. Для построения ответа к базе данных (скорее всего) обращаются. Поиск в базе данных производится на основе параметров в пути (или данных) запроса
  11. Данные из базы данных вместе с другой информацией, которую плагин решает добавить, объединяются в длинную строку текста (возможно, HTML).
  12. Плагин объединяет эти данные с некоторыми метаданными (в виде заголовков HTTP) и отправляет ответ HTTP обратно в браузер.
  13. Браузер получает ответ и анализирует HTML (который с вероятностью 95% не работает) в ответе
  14. Дерево DOM построено из сломанного HTML
  15. Новые запросы отправляются на сервер для каждого нового ресурса, который находится в источнике HTML (обычно изображения, таблицы стилей и файлы JavaScript). Вернитесь к шагу 3 и повторите для каждого ресурса.
  16. Таблицы стилей анализируются, и информация рендеринга в каждом из них прикрепляется к соответствующему узлу в дереве DOM
  17. Javascript анализируется и выполняется, а узлы DOM перемещаются, и информация о стиле обновляется соответственно
  18. Браузер отображает страницу на экране в соответствии с деревом DOM и информацией о стиле для каждого узла.
  19. Вы видите страницу на экране
  20. Вы раздражаетесь, весь процесс был слишком медленным.

Источник Рендеринг веб-страницы - шаг за шагом


63

Каждое соединение с веб-сайтом использует отдельный сокет с TCP-портом назначения 80 по умолчанию для простого HTTP и 443 для HTTPS. Чтобы сокет был уникальным, комбинация IP-адреса источника, TCP-порта источника, IP-адреса назначения и TCP-порта назначения должна отличаться.

Если у вас есть несколько подключений к одному веб-сайту (при условии, что веб-сайт использует только 1 IP-адрес) с одного и того же компьютера, необходимо использовать другой исходный порт TCP. Таким образом, каждое соединение уникально.

Однако следует отметить, что с HTTP 1.1 все соединения являются постоянными в течение определенного периода времени (если не указано иное). Это означает, что браузер может повторно использовать одно и то же соединение, если запрашивается несколько ресурсов с одного веб-сайта (например, файлы css / js). Это также применяется, если у вас есть несколько экземпляров одного и того же веб-сайта в вашем браузере.

Если вы работаете в Windows, netstat -no -p TCPкоманда покажет вам все активные сокеты TCP и соответствующие им идентификаторы процессов, в том числе вашего браузера:

введите описание изображения здесь

Если вы используете Unix / Linux (в данном случае Debian), вы можете использовать команду netstat -ntpor ss -t:

введите описание изображения здесь


4
Обратите внимание, что netstat также будет отображать соединения, не связанные с браузером, например, почтовые соединения для почтового клиента, новостные соединения для программы чтения новостей. Эти соединения будут на разных удаленных портах.
DavidPostill

Если я что-то не упустил, похоже, вы предполагаете, что спрашивающий использует Windows, хотя он не упомянул операционную систему. Также хорошо перечислять, на какую ОС вы ссылаетесь, когда предоставляете консольные команды.
user45623

9
@ user45623: Хотя снимок экрана является снимком экрана Windows, он netstat -nдолжен работать в большинстве операционных систем, включая Linux и Mac OS.
Хайнци

1
В Windows (возможно, и в других ОС) вы можете использовать, netstat -n -oчтобы увидеть, какой процесс создал какое соединение. Или вы можете запустить tcpview от SysInternal, чтобы увидеть список в графическом интерфейсе, с именами процессов, значками и всем остальным .
Джонатан

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

11

Что касается вкладок на разных веб-сайтах, в TCP нет ничего, что требовало бы, чтобы локальный порт был другим, если кортеж {локальный IP, локальный порт, целевой IP, целевой порт} уникален. Для вкладок на том же сайте ситуация гораздо сложнее.

Браузер, как и любая другая часть клиентского программного обеспечения, использует другой локальный порт для исходящего соединения с той же целью. Как правило, он формирует несколько соединений с любым конкретным веб-сайтом для извлечения встроенных ресурсов, таких как изображения, CSS, JavaScript и т. Д. Он также объединяет эти соединения для возможного повторного использования.

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


Благодарю. Что означает «объединение» соединения?
yoyo_fun

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

Таким образом, пул - это структура данных в памяти, которая хранит открытые и еще не закрытые соединения?
yoyo_fun

Это правильно, как правило, карта с ключом целевого IP: порт.
user207421

2
@EJP: обратите внимание, что для HTTPS небезопасно указывать карту по целевому IP и порту; вам также необходимо различать соединения с разными именами хостов, даже если они разрешаются на один и тот же IP-адрес и порт. Возможно, браузер также должен хранить соединения для разных вкладок раздельно, если хотя бы одна вкладка находится в режиме инкогнито.
Хеннинг Махолм

6

Да. Может быть По-разному.

Во-первых, браузер может использовать любую из этих стратегий для соединений:

  1. Одиночное соединение (маловероятно для любого браузера, более позднего, чем 1995)
  2. Одно соединение на вкладку (в основном то же самое, что и # 1, только немного лучше)
  3. Одно соединение на ресурс (наивно, но не так уж плохо)
  4. Пул соединений с поддержкой активности, повторным использованием соединений
  5. Нечто другое (читай как: странные вещи)

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

Во-вторых, как работает TCP, у вас есть порт источника и порт назначения для каждого соединения. Пара источника и адреса назначения / порта определяет соединение.
Вы всегда [1] используете известный порт (например, 80 или 443) для подключения к серверу (который он прослушивает по своему объявленному адресу), но другой порт выбирается случайным образом. Таким образом, в зависимости от того, с какой стороны вы смотрите на соединение, оно имеет один или несколько возможных портов.

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

Поскольку в вопросе явно упоминается исходящий , в «нормальном» случае номера портов будут одинаковыми независимо от того, на какой вкладке они находятся, или на одном из двух возможных портов (80 и 443). Хотя, конечно, можно явно запросить другой порт (например, 8080) в URL. Это довольно редко, хотя.


[1] Ну, не всегда ... но давайте не будем слишком усложнять.


Еще один фактор ... порт на стороне клиента обычно выбирается ОС, а не браузером; и порт на стороне клиента, который видит сервер, может отличаться от того, что видит браузер, если соединение проходит через устройство NAT. Большинство ОС распределяют линейно или случайным образом в пределах (настраиваемого) эфемерного диапазона портов, но браузер может запрашивать один и тот же порт-источник для нескольких соединений с разными серверами. (И ОП спрашивает о клиентских портах, а не о портах сервера.)
Дэвид

@ Давид: Трудно сказать, какой из них правильный (или что ответить), так как вопрос Q является двусмысленным, поэтому моя довольно продолжительная экскурсия на все случаи жизни. ОП запрашивает исходящий порт на клиенте. «Клиент» предполагает, что мы говорим о порте источника (в терминах TCP), который выбирается свободно или случайным образом (реализацией), но «исходящий» предполагает, что это действительно порт назначения, о котором мы говорим. Который намного лучше описан как "порт на сервере" в словах неспециалиста. Ваш комментарий о NAT правильный, как видно с сервера, но не влияет на клиента.
Деймон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.