Такой вопрос. Базовый IPv4 пакет не учитывает порт. А вот TCP/UDP — уже идет обязательно по конкретному порту.
Этот порт — чему-то соответствует? Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535? Почему выбрано именно 2 байта?
=сначала спроси у GPT=
Re: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Базовый IPv4 пакет не учитывает порт. А вот TCP/UDP — уже идет обязательно по конкретному порту.
SCTP тоже.
S>Этот порт — чему-то соответствует? Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535? Почему выбрано именно 2 байта?
Условное, соединяет одновременно две характеристики — уникальную идентификацию участника (дополнение до хоста, в пределах жизни соединения) и идентификацию (обще-)известного сервиса (well-known service).
2 байта — потому что считали, что больше не нужно. На самом деле для случаев серьёзной нагрузки это сейчас реальная гиря на ногах (например, если граничный прокси-балансер передаёт соединения внутренним серверам), выкручиваются назначением множественных IP адресов.
Мне сильно жаль, что с переходом на IPv6 не расширили тут до 4 байт.
The God is real, unless declared integer.
Re: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Базовый IPv4 пакет не учитывает порт.
Потому что это IP-трафик. Вот едет фура по дороге, и ей абсолютно фиолетово, что там в кузове лежит. Мотор тянет? Колёса едут? Тогда вперёд!
S>А вот TCP/UDP — уже идет обязательно по конкретному порту. Этот порт — чему-то соответствует? Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535? Почему выбрано именно 2 байта?
Именно условное число. Цель — найти приложение-хозяина, которому отдать эти данные. Как подарки под ёлкой: ёлка одна и та же, но на коробочках написано "для Пети", "для Саши", "для Маши"...
Re: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Базовый IPv4 пакет не учитывает порт. А вот TCP/UDP — уже идет обязательно по конкретному порту.
А ICMP не идёт. Ну так, для полноты.
S>Этот порт — чему-то соответствует?
Порт на исходящем сокете обычно ничему не соответствует и выбирается случайный или около того. Порт на входящем сокете соответствует приложению, которое этот порт слушает.
S>Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535?
Порт 0 не используется. А так — да, просто условное число от 1 до 65535. Никаким портам процессора это не соответствует, от сетевой карты все пакеты приходят единообразно и уже ядро ОС разбирается, что с пакетом делать.
S>Почему выбрано именно 2 байта?
С одной стороны достаточно для практики, по крайней мере я не слышал, чтобы кто-то сильно страдал от недостатка портов. С другой стороны раздувание размера пакета это накладные расходы, пусть и не большие, но зачем. TCP/UDP это практически весь трафик в интернете, даже на один промилле увеличивать их неразумно.
Re: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Shmj, Вы писали:
S>Такой вопрос. Базовый IPv4 пакет не учитывает порт. А вот TCP/UDP — уже идет обязательно по конкретному порту. S>Этот порт — чему-то соответствует? Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535? Почему выбрано именно 2 байта?
Открой OSI Model. Физический уровень это layer 1. И вообще это всё про сеть, процессор тут вообще не в тему.
IP с адресами это layer 3, а TCP с портами — layer 4.
Выбор 65535 — произвольная условность, обозначать разную прикладную функциональность на том же адресе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
N>2 байта — потому что считали, что больше не нужно. На самом деле для случаев серьёзной нагрузки это сейчас реальная гиря на ногах (например, если граничный прокси-балансер передаёт соединения внутренним серверам), выкручиваются назначением множественных IP адресов. N>Мне сильно жаль, что с переходом на IPv6 не расширили тут до 4 байт.
Тогда это был бы TCPv6, UDPv6...
Re[3]: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Mr.Delphist, Вы писали:
N>>2 байта — потому что считали, что больше не нужно. На самом деле для случаев серьёзной нагрузки это сейчас реальная гиря на ногах (например, если граничный прокси-балансер передаёт соединения внутренним серверам), выкручиваются назначением множественных IP адресов. N>>Мне сильно жаль, что с переходом на IPv6 не расширили тут до 4 байт.
MD>Тогда это был бы TCPv6, UDPv6...
И что в этом плохого было бы?
Сейчас и так: seqnums мало 4 байта, дополнительно гоняют timestamp; окну мало 2 байта, придумали size scale (причём всегда; например, если оно выставлено в 64, грануляция размера тоже будет: 0, 64, 128...); проблему замершего нулевого окна костылят; urgent pointer можно убрать, всё равно не в тему; ещё с десяток прочих улучшений давно пора бы сделать... А логика самого TCP была бы всё равно единой, менялись бы только правила упаковки и распаковки данных.
The God is real, unless declared integer.
Re[4]: Физическое представление порта в TCP/UDP- протоколе
MD>>Тогда это был бы TCPv6, UDPv6...
N>И что в этом плохого было бы?
Новый протокол — новый ID. Значит, надо
1) обновить кучу SDK, чтобы там эти константы появились
2) обновить кучу кода по схеме "if (TCP or TCPv6)"
3) ряд оборудования будет действовать по схеме "неизвестный протокол -> dev/null", и обновить/поменять это железо дело крайне не быстрое (вспоминаем, сколько лет проблеме исчерпания адресов IPv4 и насколько распространён IPv6 даже сегодня)
Re[5]: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>Тогда это был бы TCPv6, UDPv6...
N>>И что в этом плохого было бы?
MD>Новый протокол — новый ID. Значит, надо MD>1) обновить кучу SDK, чтобы там эти константы появились MD>2) обновить кучу кода по схеме "if (TCP or TCPv6)" MD>3) ряд оборудования будет действовать по схеме "неизвестный протокол -> dev/null", и обновить/поменять это железо дело крайне не быстрое (вспоминаем, сколько лет проблеме исчерпания адресов IPv4 и насколько распространён IPv6 даже сегодня)
Если бы это прошло одним пакетом изменений с IPv6, никто бы не заметил проблем в переходе.
The God is real, unless declared integer.
Re[6]: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Shmj, Вы писали:
S>>Такой вопрос. Базовый IPv4 пакет не учитывает порт. А вот TCP/UDP — уже идет обязательно по конкретному порту. S>>Этот порт — чему-то соответствует? Ну типа некому порту ввода-вывода процессора или еще чего? Или просто условное число от 0 до 65535? Почему выбрано именно 2 байта? ·>Открой OSI Model. Физический уровень это layer 1. И вообще это всё про сеть, процессор тут вообще не в тему. ·>IP с адресами это layer 3, а TCP с портами — layer 4.
А ICMP это какой layer?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Физическое представление порта в TCP/UDP- протоколе
S>·>Открой OSI Model. Физический уровень это layer 1. И вообще это всё про сеть, процессор тут вообще не в тему. S>·>IP с адресами это layer 3, а TCP с портами — layer 4. S>А ICMP это какой layer?
Третий. Вики пишет:
ICMP is a network-layer protocol. There is no TCP or UDP port number associated with ICMP packets as these numbers are associated with the transport layer above.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Физическое представление порта в TCP/UDP- протоколе
Здравствуйте, Mr.Delphist, Вы писали:
N>>Если бы это прошло одним пакетом изменений с IPv6, никто бы не заметил проблем в переходе.
MD>Ну, было б не легче. Сейчас распространённость IPv6 в среднем ~35% трафика. Пруф от Гугла
MD>Т.е. переход, мягко говоря, ещё не слишком начат
Что ты понимаешь под переходом? От IPv4 отказываться никто вроде не собирается. IPv6 всегда будет сосуществовать рядом с IPv4, а не заменять его. И 35% трафика это вполне себе показатель отого, что IPv6 уже давно реальность, с которой надо считаться всем заинтересованным лицам.
Здравствуйте, vsb, Вы писали:
vsb>Что ты понимаешь под переходом? От IPv4 отказываться никто вроде не собирается. IPv6 всегда будет сосуществовать рядом с IPv4, а не заменять его.
IPv4 станет примерно как FTP — будет постепенно выходить из оборота, в связи с врождёнными ограничениями, затем стнет legacy-нишей для старых необновляемых решений, чтобы затем просто исчезнуть из дефолтной поддержки со стороны ОС. Времени на это понадобится лет 40-50, глядя реалистично. Но он уйдёт.
vsb>И 35% трафика это вполне себе показатель отого, что IPv6 уже давно реальность, с которой надо считаться всем заинтересованным лицам.
Полностью согласен — все новые решения должны учитывать IPv6