Re[3]: Максимальная длина TCP пакета в сети
От: vsb Казахстан  
Дата: 10.02.20 17:02
Оценка: 4 (1)
Здравствуйте, AlexGin, Вы писали:

AG>Здравствуйте, уважаемый vsb, Вы писали:


vsb>>TCP не оперирует пакетами. TCP это поточный протокол.

AG>+100500
AG>Да, может я и неправильно назвал данную сущность, но для моей задачи — характерны блоки данных (которые я назвал пакетами).

Я бы не советовал смешивать пакеты на уровне протокола и пакеты на уровне IP. Да, если пишешь 500 байтов в сокет и больше ничего не делаешь, то скорей всего они так и приедут в одном IP-пакете (с прицепленными TCP и IP заголовками). Но на "скорее всего" полагаться нельзя. В общем случае это сущности разные. Может и в одном IP пакете быть куча пакетов протокола. Может быть и наоборот.

AG>>>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?


vsb>>MTU это размер IP пакета.

AG>То есть — для уровня TCP, это значение может оказаться лишённое смысла...

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

AG>>>MTU равный примерно 1.5 KBytes — это для произвольных данных?

AG>>>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?

vsb>>Размер IP пакета не зависит от того, какого рода данные в него кладут. Это гораздо более низкий уровень абстракции.

AG>
AG>Эту теорию я знаю уже не первый год. Вот почему же на практике иначе?

Что именно на практике иначе, я не совсем понимаю? Как меряете?


vsb>>При использовании TCP обо всех проблемах заботится операционная система. Программисту про это думать нужды нет.


AG>Это только в теории...

AG>Впрочем, я также думал до недавнего времени. Пока не столкнулся с ситуацией:
AG>Когда сервер и клиент — на одном и том же компе — всё работает как швейцарские часы.
AG>Но вот если сервер и клиент — соединены проводом и через хаб — как это в реальной жизни — то тут начинается практика...

На практике в TCP протоколе может рваться соединение, потому, что какая-нибудь дурацкая коробка посредине так решила. Чтобы в TCP-протоколе терялись байты или приходили не в том порядке — такого быть не может. Ну т.е. понятно, что если коробка посредине зловредная, то всё может быть, но обычно в реальной жизни зловредных коробок нет. И скорей всего баг в вашем коде, который не проявляется при очень быстрой сети (на локалхосте скорость практически бесконечная) и проявляется в реальной сети. Например частая ошибка — люди всё же трактуют TCP как пакетный протокол, хоть он и поточный. Думают, что если записали в него тысячу байтов, то на другом конце чтение вернёт все эти тысячу байтов. А не факт. Оно может возвращать тысячу раз по одному байту. Т.е. понятно, что в конечном счёте все байты придут и прочитаются, но вот именно read совершенно не обязан читать весь пакет целиком. Это я пытаюсь играть в оракула по косвенным данным определяя баг (: Может быть даже угадаю.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.