На каком порту работает браузер
Ошибка 312 (net :: ERR_UNSAFE_PORT): неизвестная ошибка.
Есть ли простой способ решить эту проблему, не перестраивая Chrome из исходного кода ?
В Windows :
Щелкните правой кнопкой мыши на ярлыке Chrome >> Свойства >>
Затем добавить --explicitly-allowed-ports=xxx к ярлыку цели
C: \ Documents and Settings \ Пользователь \ Локальные настройки \ Данные приложения \ Google \ Chrome \ Application \ chrome.exe --explicitly-allow-ports = 6666
Добавление флагов командной строки на Mac - боль в заднице; если вы добавляете их в комплект приложений, они часто получают ядро в обновлениях.
Вы можете отключить это в Google Chrome, но вы делаете это на свой страх и риск. На самом деле есть хорошая причина безопасности, почему Chrome блокирует эти порты: в основном вы открываете свой браузер, чтобы стать открытым прокси-сервером для атакующих, чтобы использовать их для атаки на другие сервисы в вашей сети.
Если он не проверен, то любой вредоносный код может отправлять запросы на URL с произвольными портами. Возможно, это не оптимальное решение, но, блокируя другие порты, вы оставляете злоумышленникам только 80 и 443 для использования.
На Mac вы можете создать приложение, запускающее Chrome, с параметрами, упомянутыми в других ответах, с помощью встроенного в Automator приложения Apple:
В качестве «Типа документа» выберите «Приложение»
Добавить действие «Выполнить скрипт оболочки»
Замените cat скрипт- заполнитель в этом действии:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --explicitly-allowed-ports=5000,6000,7000
Сохраните созданное приложение как «Google Chrome с разрешенными небезопасными портами» в папке «Приложение».
Используйте это новое приложение вместо Google Chrome напрямую
(необязательно) Замените значок по умолчанию для созданного «приложения» - робота Automator - на Chrome, используя этот метод (примечание: добавьте ответ, если вам это нравится!)
для портов 5000, 6000 и 7000.
Как сказал subanki, вы должны добавить -explicitly-allowed-ports опцию в команду запуска Chrome.
В Ubuntu вы можете сделать это (как пользователь root), отредактировав скрипт "google-chrome" в папке установки Chrome
Вы можете получить каталог, набрав:
Затем отредактируйте файл "google-chrome", добавив упомянутый переключатель в строку EXEC:
Просто измените «6000» с запятыми значений может потребоваться (пример: -explicitly-allowed-ports=5000,6000,7000 )
ПРИМЕЧАНИЕ: для UNIX переключатель НЕ начинается с «-», он запускается с одного «-»
FWIW, -- on unix - это соглашение, специфичное для GNU. Его эмулируют многие, но не все утилиты Unix.
1. Я так понял: Если браузеру нужно загрузить сайт он выбирает случайный порт и с него шлет пакеты на сервер.
А сервер шлет ответы на порт который был выбран браузером.
Для каждого сайта (или сессии с сайтом) выбирается свой порт.
Правильно?
2. Как именно браузер выбирает порт? По какому алгоритму?
3. Как поведет себя шлюз с nat если через него PC1 и PC2 отправят пакет на сервер X c одинакового порта?
Получается что шлюз не сможет какой эээ. ответ от сервера какому PC принадлежит. Что будет делать шлюз в таком случае? Есть ли какая то защита от выше описанной ситуации?
- Вопрос задан более трёх лет назад
- 1734 просмотра
Браузер порты сам не выбирает, а полагается на операционную систему. И уже она выбирает по собственным алгоритмам
3. Как поведет себя шлюз с nat если через него PC1 и PC2 отправят пакет на сервер X c одинакового порта?
у второго исходящего соединения кроме адреса отправителя поменяет еще и номер порта, делов-то. А может и у первого соединения поменяет, если по какой-либо причине решит, что так удобнее.
1.Часто браузер для одного сайта открывает не одно соединение, а сразу пачку и качает ресурсы параллельно. Порты в этом случае для каждого соединения разные. Кроме того на одной странице могут быть ссылки ведущие на разные сайты, для них браузер открывает новые соединения.
2.Как было сказано порт выбирает ОС. При открытии сокета браузер указывает, что нужен "любой локальный порт". Считайте, что ОС выбирает первый свободный порт из динамического диапазона. На самом деле сложнее, конечно, но конкретный алгоритм обычно не важен.
3.В общем случае шлюз с NAT подменяет и адрес и порт, поэтому сервер увидит не адрес и порт отправителя, а адрес и порт шлюза. Все это происходит прозрачно для сервера и для клиента. Клиент думает, что он общается на прямую с сервером, а сервер думает, что клиент - это шлюз с NAT и не подозревает, что по пути пакета реальный адрес/порт клиента был подменен NATом.
1) правильно
2) каждый раз (каждая вкладка) порт увеличивается, но ты и 1000 вкладок не откроешь - не хватит или памяти или процессора ( про голову молчу)
3) NAT распределяет по IP адресу и вообще не парится за порты, смотри как файрволлы реализованы
Предположим, что он ввёл в адресной строке следующее:
Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:
Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):
URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:
При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.
Как прочитать ответ?
Стартовая строка ответа имеет следующую структуру:
Версия протокола здесь задаётся так же, как в запросе.
Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.
После стартовой строки следуют заголовки, а также тело ответа. Например:
Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).
Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.
В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.
Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.
А что с безопасностью?
А есть дополнительные возможности?
Что-то ещё, кстати, используют?
Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.
На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.
И что, всё?
Ну и, конечно, не забывайте, что любая технология становится намного проще и понятнее тогда, когда вы фактически начинаете ей пользоваться.
Вы абсолютно правы. Я изменил порт по умолчанию для своих веб-серверов с 80 на 90,91,92 и 93. Нагрузка на сервер резко упала.
80 это просто порт, используемый для http. Когда вы говорите "что-то.com"; (или даже "thing.com "), браузер завершает его, чтобы запросить" нечто.com:80 "; (на 80-м порту, так как это стандартный http-порт по умолчанию). То же самое для https на 443. Если вы решите изменить его, вы должны будете сказать это в URL: "myserver.com:1280"; в противном случае браузер попытается подключиться к порту 80 и не найдет его. Список можно увидеть в Википедии
В дополнение к этому недружелюбию нет никакого выигрыша в производительности: порт - только одна часть (dst ip:port, src ip:port) 4-кортежа, который однозначно идентифицирует соединение TCP. Если два соединения совместно используют dst ip:port , это не значит, что они совместно используют какой-то системный ресурс - они могут находиться в разных потоках или разных процессах.
Сервер не тратит ресурсы, обрабатывая соединения в одном или нескольких портах. Ресурсы сервера выделяются для обработки соединений, а номер порта - это просто способ подключения конкретной программы к определенному соединению.
Я бы добавил к этому ответу, что порт 80 не используется пользователем, отправляющим ему свой запрос. Вот почему использование только порта 80 (или любого другого известного порта для входящего протокола, который вы просматриваете) не является узким местом для масштабируемости.
Некоторые программы для веб-серверов имеют ограничения на экземпляры и / или процессы. Иногда может быть хорошей идеей запускать несколько экземпляров, но для этого на одной и той же машине требуется другой порт прослушивания, первый (TCP80 / 443) перенаправляет соединения на первый экземпляр.
Вы, кажется, думаете о портах как о чем-то реальном; это просто 16-битное число без знака (0-65535), это метка в заголовке IP-пакета. Это помогает с мультиплексированием на уровне приложений. Когда входящий пакет поступает на сетевую карту, ОС получает уведомление. Он проверяет, на какой порт был направлен входящий пакет, и затем перенаправляет пакет только нужному приложению. Если вы используете свой веб-сервер (nginx) для прослушивания порта 80, только nginx получает пакеты, отправленные на порт 80.
Каждый IP-пакет имеет в заголовке IP-адреса источника и назначения и порт, доступный для него. ОС и приложение (веб-браузер или веб-сервер) могут использовать и то, и другое, чтобы выяснить, как выполнить обработку пакета.
Если вы хотите, чтобы веб-сервер прослушивал любые другие порты, пользователи должны вручную добавить порт в URL-адрес, или он должен быть закодирован в любой ссылке на этот конкретный порт.
Кроме того, большинство прокси-серверов и брандмауэров не разрешают подключения к этим портам, если они специально не настроены для этого (без настройки исходящие прокси-серверы не будут прослушивать порты не по умолчанию, поэтому не будут перенаправлять запрос на веб-серверы, в то время как брандмауэры просто блокировать попытки соединения не-TCP80 / 443)
Все это ограничивает то, что можно сделать на уровне TCP / IP
Одним из способов повышения производительности было бы наличие устройства / службы балансировки нагрузки, прослушивающих TCP80 / 443, который затем перенаправлял бы запрос на серверы на разных портах и / или ip (локальное балансирование) или даже на другие удаленные сайты (глобальное балансирование). Но это совсем другая тема
В веб-браузере, который поддерживает наличие нескольких вкладок, таких как Firefox, используют ли разные вкладки, которые переходят на разные домены сайта, выделенный порт для каждого домена?
Или браузер использует один порт для управления всеми вкладками и, следовательно, всеми доменами?
Я знаю порты, используемые для подключения к серверу, но мне было интересно узнать о номерах портов, используемых для подключения с клиента (хост-компьютера).
Порты назначаются ОС, и каждому новому соединению назначается новый локальный порт, чтобы отличать его от всех других открытых соединений.
@ExUmbris: Это может быть разумной и простой стратегией, но TCP-соединения идентифицируются с помощью четырех <локальный IP, локальный порт, удаленный IP, удаленный порт>. Локальный порт не нужен для уникальности, и это хорошо: веб-сервер вообще не может использовать свой локальный порт для уникальности. И с точки зрения веб-сервера, удаленный IP также не уникален, так как несколько пользователей могут находиться за одним шлюзом / прокси.локальный>
Используют ли браузеры разные порты для подключения к разным веб-сайтам?
Вот пример, показывающий мои текущие подключения Firefox (у меня 9 открытых вкладок) в Windows 7:
Вы можете видеть, что все локальные порты разные.
Полный процесс рендеринга веб-страницы описан ниже. Смотрите, в частности, шаги 5, 6, 13 и 15 (которые выделены жирным шрифтом):
В общем случае для рендеринга одной веб-страницы используется несколько соединений, не все из которых будут иметь один и тот же удаленный адрес.
Это связано с тем, что веб-страницы часто содержат ресурсы, размещенные в других местах (файлы JavaScript и т. Д.).
Рендеринг веб-страницы - шаг за шагом
- Шаги 5, 6, 13 и 15 (выделены жирным шрифтом) имеют прямое отношение к вопросу.
Если у вас есть несколько подключений к одному веб-сайту (при условии, что веб-сайт использует только 1 IP-адрес) с одного и того же компьютера, необходимо использовать другой исходный порт TCP. Таким образом, каждое соединение уникально.
Если вы работаете в Windows, netstat -no -p TCP команда покажет вам все активные сокеты TCP и соответствующие им идентификаторы процессов, в том числе вашего браузера:
Если вы используете Unix / Linux (в данном случае Debian), вы можете использовать команду netstat -ntp or ss -t :
Обратите внимание, что netstat также будет отображать соединения, не связанные с браузером, например, почтовые соединения для почтового клиента, новостные соединения для программы чтения новостей. Эти соединения будут на разных удаленных портах.
Если я что-то не упустил, похоже, вы предполагаете, что спрашивающий использует Windows, хотя он не упомянул операционную систему. Также хорошо перечислять, на какую ОС вы ссылаетесь, когда предоставляете консольные команды.
@ user45623: Хотя снимок экрана является снимком экрана Windows, он netstat -n должен работать в большинстве операционных систем, включая Linux и Mac OS.
В Windows (возможно, и в других ОС) вы можете использовать, netstat -n -o чтобы увидеть, какой процесс создал какое соединение. Или вы можете запустить tcpview от SysInternal, чтобы увидеть список в графическом интерфейсе, с именами процессов, значками и всем остальным .
Теперь вопрос заключается в том, могут ли веб-браузеры повторно использовать соединения из разных вкладок, если они ведут на один и тот же сервер?
Что касается вкладок на разных веб-сайтах, в TCP нет ничего, что требовало бы, чтобы локальный порт был другим, если кортеж уникален. Для вкладок на том же сайте ситуация гораздо сложнее.
Браузер, как и любая другая часть клиентского программного обеспечения, использует другой локальный порт для исходящего соединения с той же целью. Как правило, он формирует несколько соединений с любым конкретным веб-сайтом для извлечения встроенных ресурсов, таких как изображения, CSS, JavaScript и т. Д. Он также объединяет эти соединения для возможного повторного использования.
Невозможно сказать, будут ли разные вкладки одного и того же веб-сайта использовать разные подключения, потому что (а) в любом случае обычно не существует одного подключения на вкладку, и (б) в зависимости от времени и аутентификации соединения могут быть повторно используется между вкладками; и поскольку невозможно идентифицировать соединения, следовательно, также невозможно идентифицировать локальные порты.
Таким образом, пул - это структура данных в памяти, которая хранит открытые и еще не закрытые соединения?
Да. Может быть По-разному.
Во-первых, браузер может использовать любую из этих стратегий для соединений:
У вас нет способа узнать, какую стратегию будет использовать браузер, хотя использование пула соединений (и повторное использование соединений) является разумным предположением.
Во-вторых, как работает TCP, у вас есть порт источника и порт назначения для каждого соединения. Пара источника и адреса назначения / порта определяет соединение.
Вы всегда [1] используете известный порт (например, 80 или 443) для подключения к серверу (который он прослушивает по своему объявленному адресу), но другой порт выбирается случайным образом. Таким образом, в зависимости от того, с какой стороны вы смотрите на соединение, оно имеет один или несколько возможных портов.
Таким образом, одна и та же вкладка может (и обычно будет) использовать несколько разных портов на своем конце, но в принципе разные вкладки могут (если соединения объединяются в пул и разные ресурсы в разных вкладках загружаются с одного и того же сервера) использовать один и тот же порт.
Поскольку в вопросе явно упоминается исходящий , в «нормальном» случае номера портов будут одинаковыми независимо от того, на какой вкладке они находятся, или на одном из двух возможных портов (80 и 443). Хотя, конечно, можно явно запросить другой порт (например, 8080) в URL. Это довольно редко, хотя.
[1] Ну, не всегда . но давайте не будем слишком усложнять.
Еще один фактор . порт на стороне клиента обычно выбирается ОС, а не браузером; и порт на стороне клиента, который видит сервер, может отличаться от того, что видит браузер, если соединение проходит через устройство NAT. Большинство ОС распределяют линейно или случайным образом в пределах (настраиваемого) эфемерного диапазона портов, но браузер может запрашивать один и тот же порт-источник для нескольких соединений с разными серверами. (И ОП спрашивает о клиентских портах, а не о портах сервера.)
@ Давид: Трудно сказать, какой из них правильный (или что ответить), так как вопрос Q является двусмысленным, поэтому моя довольно продолжительная экскурсия на все случаи жизни. ОП запрашивает исходящий порт на клиенте. «Клиент» предполагает, что мы говорим о порте источника (в терминах TCP), который выбирается свободно или случайным образом (реализацией), но «исходящий» предполагает, что это действительно порт назначения, о котором мы говорим. Который намного лучше описан как "порт на сервере" в словах неспециалиста. Ваш комментарий о NAT правильный, как видно с сервера, но не влияет на клиента.
Читайте также: