Сообщение Re: Максимальная длина TCP пакета в сети от 10.02.2020 20:26
Изменено 11.02.2020 7:16 netch80
Re: Максимальная длина TCP пакета в сети
Здравствуйте, AlexGin, Вы писали:
AG>Вопросы:
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных?
AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Я не вижу там цифру типа 14KB. Вижу 1400. Вы один ноль не додумали?
По сути:
1. Как уже сказано, TCP поддерживает просто октетный поток. Что отправлено с одной стороны, придёт на другую, в том же порядке и том же составе, без добавлений, потерь и модификаций. Ну, точнее, бывают разные случаи: бывает, что у маршрутизаторов память битая, или какое ещё безобразие. Какими порциями будет читаться на приёме — неизвестно, поэтому надеяться на передачу теми же порциями нельзя, нужно иметь метки в самом потоке.
2. MTU определяется как детектированный минимум из всех линков по дороге пакета до ремотного хоста. Именно что всех, а не только ближайших. Реально в нынешнем мире не бывает интерфейса, кроме loopback и спец. локальных настроек, у которых MTU самого линка более 1500. Меньше — бывает — если проследует через интерфейс. И ещё вычтите 52 байта на IP+TCP (иногда 40, но это всё реже и реже).
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Пакетов — может. Но волновать не должно, если не стоит задача выжать дополнительные проценты скорости (а в таком случае TCP вообще не в тему).
AG>Вышеуказанные данные получены экспериментально.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
Это loopback, ему можно. Бывает ethernet jumbo frames, до 9000.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP?
AG>Как защититься от изменения порядка следования пакетов?
Не должно волновать.
AG>Вопросы:
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных?
AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Я не вижу там цифру типа 14KB. Вижу 1400. Вы один ноль не додумали?
По сути:
1. Как уже сказано, TCP поддерживает просто октетный поток. Что отправлено с одной стороны, придёт на другую, в том же порядке и том же составе, без добавлений, потерь и модификаций. Ну, точнее, бывают разные случаи: бывает, что у маршрутизаторов память битая, или какое ещё безобразие. Какими порциями будет читаться на приёме — неизвестно, поэтому надеяться на передачу теми же порциями нельзя, нужно иметь метки в самом потоке.
2. MTU определяется как детектированный минимум из всех линков по дороге пакета до ремотного хоста. Именно что всех, а не только ближайших. Реально в нынешнем мире не бывает интерфейса, кроме loopback и спец. локальных настроек, у которых MTU самого линка более 1500. Меньше — бывает — если проследует через интерфейс. И ещё вычтите 52 байта на IP+TCP (иногда 40, но это всё реже и реже).
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Пакетов — может. Но волновать не должно, если не стоит задача выжать дополнительные проценты скорости (а в таком случае TCP вообще не в тему).
AG>Вышеуказанные данные получены экспериментально.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
Это loopback, ему можно. Бывает ethernet jumbo frames, до 9000.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP?
AG>Как защититься от изменения порядка следования пакетов?
Не должно волновать.
Re: Максимальная длина TCP пакета в сети
Здравствуйте, AlexGin, Вы писали:
AG>Вопросы:
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных?
AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Я не вижу там цифру типа 14KB. Вижу 1400. Вы один ноль не додумали?
По сути:
1. Как уже сказано, TCP поддерживает просто октетный поток. Что отправлено с одной стороны, придёт (если вообще придёт) на другую, в том же порядке и том же составе, без добавлений, потерь и модификаций. Ну, точнее, бывают разные случаи: бывает, что у маршрутизаторов память битая, или какое ещё безобразие. Какими порциями будет читаться на приёме — неизвестно, поэтому надеяться на передачу теми же порциями нельзя, нужно иметь метки в самом потоке.
2. MTU определяется как детектированный минимум из всех линков по дороге пакета до ремотного хоста. Именно что всех, а не только ближайших. Реально в нынешнем мире не бывает интерфейса, кроме loopback и спец. локальных настроек, у которых MTU самого линка более 1500. Меньше — бывает — если проследует через интерфейс. И ещё вычтите 52 байта на IP+TCP (иногда 40, но это всё реже и реже).
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Пакетов — может. Но волновать не должно, если не стоит задача выжать дополнительные проценты скорости (а в таком случае TCP вообще не в тему).
AG>Вышеуказанные данные получены экспериментально.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
Это loopback, ему можно. Бывает ethernet jumbo frames, до 9000 — но только в локальных сетях.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP?
AG>Как защититься от изменения порядка следования пакетов?
Не должно волновать.
AG>Вопросы:
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных?
AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Я не вижу там цифру типа 14KB. Вижу 1400. Вы один ноль не додумали?
По сути:
1. Как уже сказано, TCP поддерживает просто октетный поток. Что отправлено с одной стороны, придёт (если вообще придёт) на другую, в том же порядке и том же составе, без добавлений, потерь и модификаций. Ну, точнее, бывают разные случаи: бывает, что у маршрутизаторов память битая, или какое ещё безобразие. Какими порциями будет читаться на приёме — неизвестно, поэтому надеяться на передачу теми же порциями нельзя, нужно иметь метки в самом потоке.
2. MTU определяется как детектированный минимум из всех линков по дороге пакета до ремотного хоста. Именно что всех, а не только ближайших. Реально в нынешнем мире не бывает интерфейса, кроме loopback и спец. локальных настроек, у которых MTU самого линка более 1500. Меньше — бывает — если проследует через интерфейс. И ещё вычтите 52 байта на IP+TCP (иногда 40, но это всё реже и реже).
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Пакетов — может. Но волновать не должно, если не стоит задача выжать дополнительные проценты скорости (а в таком случае TCP вообще не в тему).
AG>Вышеуказанные данные получены экспериментально.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
Это loopback, ему можно. Бывает ethernet jumbo frames, до 9000 — но только в локальных сетях.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP?
AG>Как защититься от изменения порядка следования пакетов?
Не должно волновать.