Практический (против теоретического) максимальный предел размера пакета TCP

Question

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

Мой вопрос касается размера пакета по TCP.

Поступающие сообщения со скоростью 10 000 сообщений в секунду со скоростью 2 КБ на сообщение. Я пытался найти максимальное, максимально безопасное или максимально практичное ограничение размера пакета. Я видел в нескольких непроверенных местах (т.е. не в технической документации), что максимальный теоретический размер составляет 64 КБ. Это верно? В этом случае мой пример отправки 2 КБ сообщений легко поместился бы в одном пакете и уменьшил бы сложность этой системы.

Если 64KB - неправильный номер, каким будет правильный номер? Кроме того, я не просто пытаюсь понять максимальный теоретический размер, но и максимальный практический размер. Я хочу охватить крайние случаи, когда сообщения могут быть немного больше, чем целевые 2 КБ, а также оставить место для различных заголовков, которые нужны TCP.

Answer 1

Ethernet всегда оказывал влияние на размеры пакетов TCP/IP. Ethernet имеет стандартный MTU 1500 байт, который после типичных служебных данных заголовка IPv4 в 20 байтов и типичных современных служебных данных заголовка TCP в 32 байта (раньше это было 20 байтов, но в настоящее время мы добавляем опцию метки времени в 12 байтов) приводит к TCP Максимальный размер сегмента 1448 байт.

PPPoE, который популярен среди ISP-провайдеров на основе DSL, добавляет еще 8 байтов служебной информации, поэтому TCP-соединения, пересекающие канал PPPoE, в итоге получают TCP MSS размером 1440 байт. Другие технологии могут добавить больше накладных расходов.

Большинство современных стеков TCP/IP выполняют "Обнаружение MTU пути" (PMTUD), поэтому им никогда не придется полагаться на фрагментацию IP. К сожалению, некоторые сайты блокируют сообщения ICMP, необходимые для работы PMTUD, случайно создавая "черные дыры PMTUD", где PMTUD не работает. Чтобы позволить людям, стоящим за черными дырами PMTUD, по-прежнему подключаться к своим сервисам, сайты Google решили договориться об очень консервативном TCP MSS в 1380 байт (последний раз, когда я проверял).

Таким образом, я бы сказал, что можно привести довольно хороший аргумент, что если вы хотите адаптировать то, как ваше приложение выполняет запись, чтобы убедиться, что они заполняют только один пакет большую часть времени, сделать ваши записи не более 1448 байтов, и, возможно, нет больше чем 1380 байтов.

Дейтаграммы IPv4 могут достигать 64 КБ, но очень немногие пути в Интернете имеют MTU 64 КБ, так что это число не имеет отношения к большинству планирования размера пакета. Ваш теоретический сервер протокола обмена сообщениями, вероятно, подключен к Ethernet-подобной сети, которая, вероятно, использует стандартные 1500-байтовые кадры, поэтому стек IP вашего собственного сервера должен будет фрагментировать эту 64-килобайтную запись в 46 или около того отдельных пакетов, прежде чем он сможет даже начать их передачу на первом прыжке. Даже сети Ethernet, настроенные на использование нестандартных "гигантских кадров", обычно имеют максимальный размер в 9000 байтов MTU. Вдобавок ко всему, я даже не могу назвать физическую сетевую технологию / канал передачи данных (уровень 1/2), которая допускает MTU 64 КБ. Может быть, IP через Thunderbolt.