Как номер порта действительно работает в TCP?

Ответ 1

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

• Вы открываете браузер, чтобы вытащить веб-сайт, скажем, google.com. В процессе указания веб-сайта ваш компьютер будет произвольно выбирать номер порта для использования в качестве "исходного порта". Число будет выше 49152, что является началом "Динамических, частных или эфемерных портов", но ниже 65535, что является самым большим доступным номером порта. Выбранный номер порта связан с этим экземпляром браузера.

• Просто для удовольствия вы открываете новую вкладку в браузере, а также набираете "google.com" на линии URL. Ваша цель состоит в том, чтобы запустить два примера google.com, потому что вы ищете разные вещи. Затем ваш компьютер выбирает второй номер порта для этого сеанса, отличный от "исходного" порта, который он использовал для первого сеанса. Вы могли бы сделать это много раз, и каждый сеанс будет иметь уникальный "исходный" порт, связанный с каждым экземпляром.

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

• google.com получает ваш первый запрос. В его ответе будет указываться порт 80 в качестве исходного порта. Здесь, где это становится интересным. Каждый запрос google.com, полученный от вас, будет рассматриваться как "сокет" , который представляет собой комбинацию вашего IP-адреса и конкретного номера порта, связанного с процессом, связанным с google.com. Так, например, мы скажем, что ваш IP-адрес составляет 165.40.30.12, а номер исходного порта, который ваш компьютер использовал в качестве исходного порта для четырех экземпляров сообщений с google.com(скажем, четыре разных вкладки, все открывающие google.com), были 61235, 62421, 58392 и 53925. Эти четыре "гнезда" будут тогда 165.40.30.12:61235, 165.40.30.12:62421, 165.40.30.12:58392 и 165.40.30.12:53925. Каждая комбинация "IP-адрес: номер порта источника" уникальна, и google.com будет рассматривать каждый экземпляр как уникальный. google.com отвечает и связывается с "сокетом", то есть комбинацией IP-адреса и порта.

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

• "Но," вы думаете ", что, если кто-то случайно использует тот же номер порта - скажем, 61235 - как я использовал для моего исходного номера? Разве это не путает google.com?" Совсем нет, потому что google.com отслеживает "сокеты", которые представляют собой комбинацию IP-адреса и номера порта. Кто-то еще, естественно, и мы искренне надеемся, использует другой IP-адрес от того, который вы используете, скажем 152.126.11.27, а комбинация IP-адреса и номера порта уникальна - 152.126.11.27:61235 - дифференцируется по их разные IP-адреса, хотя номера портов одинаковы.

• Не имеет значения, получает ли google.com 1000 запросов от 1000 пользователей, все используют порт 80 в качестве номера порта назначения (порт google.com прослушивает входящие сообщения), потому что каждый из этих 1000 пользователей все будут иметь уникальные IP-адреса. google.com отслеживает своих клиентов своим уникальным - и они всегда должны быть уникальными, не так ли? - номера сокетов, состоящие из их IP-адреса и номера порта источника. Даже если каждый из этих 1000 клиентов каким-то образом сумел использовать один и тот же "номер порта" (маловероятный для максимального), у них все равно будут разные IP-адреса, что делает их "сокет" уникальным среди всех остальных.

• Это довольно просто, когда вы видите, что это объясняется именно так. Это дает понять, что веб-сервер всегда может прослушивать один порт (80) и по-прежнему отличаться от разных клиентов. Он не просто смотрит на IP-адрес, который он получил в запросе - вы думаете, что все они должны быть уникальными с первого раза, пока вы не поймете, что на этом веб-сервере может быть несколько веб-страниц, но в исходном порту номер, который в совокупности делает каждый запрос уникальным. Надеюсь, это довольно ясно. Это элегантная система, когда вы об этом думаете, но простой, как только вы ее понимаете.

Ответ 2

Принимая во внимание ваши вопросы:

Соединение определяется следующим образом:

{протокол, локальный IP-адрес, локальный порт, удаленный IP-адрес, удаленный порт}

(Лучше сказать локальный и удаленный, а не источник и пункт назначения, поскольку локальный порт является источником при отправке, но пункт назначения, когда вы получаете.)

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

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

В то время как протокол позволяет использовать один и тот же локальный порт при подключении к различным удаленным серверам или портам, большинство стеков TCP этого не позволят. API для привязки к локальному порту тот же, независимо от того, используете ли вы его для исходящего соединения или слушаете входящее соединение, и намерение не указывается до тех пор, пока ПОСЛЕ порта не будет привязан. Поскольку только один сокет может прослушивать определенный порт, API просто отказывается разрешить нескольким сокетам связываться с портом (есть специальное исключение, но это не относится к этому обсуждению). В результате все исходящие соединения будут использовать разные локальные порты. Поэтому, когда браузер открывает несколько соединений (на одном и том же или разных веб-серверах), они будут иметь разные локальные порты.

Ответ 3

Я прочитал вышеупомянутый вопрос на соответствующем форуме, но я думаю, люди там также не согласны друг с другом.

Я не вижу разногласий ни в одном из вопросов, которые вы упомянули.

Я хочу знать, что именно определяет сокет Connection

(sockid, исходный ip, исходный порт, dext ip, dest port)

или только

(исходный ip, исходный порт, dext ip, dest port)

Последний. Первый - это воображение воображения. Он не упоминается ни в одном из тем, которые вы цитируете.

Я хочу спросить, может ли два разных процесса, таких как два разные Браузеры общаются с веб-сервером на том же источнике порт. (По умолчанию порт Dest будет одинаковым).

Нет, если они имеют одинаковый IP-адрес источника. Это нарушит определение идентификации, указанное выше.

Что в случае разных вкладок в одном браузере.

Да, из-за пула соединений. Если вы говорите об отдельных соединениях, ответа по-прежнему нет.

Также, как упоминалось в одном из ответов, одна веб-страница пытается подключаться к различным серверам, таким как серверы объявлений и т.д. Таким образом, Chrome или firefox в этом отношении соединяются с одним и тем же портом с разными серверов или использовать один порт.

Вам придется объяснить это. В чем разница между "одним и тем же портом" и "одним портом"? Не настоящий вопрос.