MSS (англ. Maximum segment size ) является параметром протокола TCP и определяет максимальный размер полезного блока данных в байтах для TCP-пакета (сегмента). Таким образом этот параметр не учитывает длину заголовков TCP и IP [1] .
Для установления корректной TCP-сессии с удалённым хостом должно соблюдаться следующее условие:
- MSS + заголовок TCP + заголовок IP ≤ MTU
Таким образом, максимальный размер MSS = MTU − размер заголовка IP − размер заголовка TCP.
Так каждый хост требует доступности для MSS:
- IPv4 — последних 536 октетов (= 576 − 20 − 20)
- IPv6 — последних 1220 октетов (= 1280 − 40 − 20).
Обычно конкретное значение MSS определяется операционной системой во время «TCP-рукопожатия» с целевым хостом исходя из значений MTU или PMTUD [en] (англ. Path MTU Discovery ) [2] .
Однако промежуточный маршрутизатор (например, имея линк с малым MTU) может подслушивать TCP SYN пакеты и подменять значения MSS, анонсируемые конечными устройствами. В результате конечные узлы "договорятся" о меньших MSS и пакеты не придётся фрагментировать.
TCP требует явного указания максимального размера сегмента в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока менее, чем стандартный размер блока (MTU) Ethernet (1500 байт).
В протоколах туннелирования, таких как GRE, IPIP а также PPPoE MTU туннеля меньше чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Поскольку фрагментация в подавляющем большинстве случаев запрещена, то такие пакеты отбрасываются.
Проявление этой проблемы выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера.
Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.
MSS может также управляться параметрами операционной системы.
Обнаружение ошибок при передаче данных
Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым. Так в 2008 году не обнаруженная сетевыми средствами ошибка в передаче одного бита, привела к остановке серверов системы Amazon Web Services.
В общем случае распределенным сетевым приложениям рекомендуется использовать дополнительные программные средства для гарантирования целостности передаваемой информации.
Атаки на протокол
Недостатки протокола проявляются в успешных теоретических и практических атаках, при которых злоумышленник может получить доступ к передаваемым данным, выдать себя за другую сторону или привести систему в нерабочее состояние.
Освобождение от расчёта контрольной суммы
Многие реализации стека TCP/IP предоставляют возможности использования аппаратной поддержки для автоматического расчёта контрольной суммы в сетевом адаптере до передачи в сеть или после приёма из сети для верификации. Это может освобождать операционную систему от использования ценных тактов процессора при вычислении контрольной суммы.
Эта функция может приводить к тому, что анализаторы трафика, перехватывающие исходящие пакеты до их передачи в сетевой адаптер и не знающие о делегировании расчёта контрольной суммы сетевому адаптеру, могут сообщать об ошибке контрольной суммы в исходящих пакетах.
UDP
UDP (англ. User Datagram Protocol — протокол пользовательских дейтаграмм) — это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор — 0x11.
В отличие от TCP, UDP не подтверждает доставку данных, не заботится о корректном порядке доставки и не делает повторов. Поэтому аббревиатуру UDP иногда расшифровывают как Unreliable Datagram Protocol (протокол ненадёжных датаграмм). Зато отсутствие соединения, дополнительного трафика и возможность широковещательных рассылок делают его удобным для применений, где малы потери, в массовых рассылках локальной подсети, в медиапротоколах и т.п.
Не нашли то, что искали? Воспользуйтесь поиском:
Лучшие изречения: На стипендию можно купить что-нибудь, но не больше. 9418 — 
| 7463 — 
или читать все.
Известные проблемы
Завершение соединения
Передача данных
При обмене данными приемник использует номер последовательности, содержащийся в получаемых сегментах, для восстановления их исходного порядка. Приемник уведомляет передающую сторону о номере последовательности байт, до которой он успешно получил данные, включая его в поле «номер подтверждения». Все получаемые данные, относящиеся к промежутку подтвержденных последовательностей, игнорируются. Если полученный сегмент содержит номер последовательности больший, чем ожидаемый, то данные из сегмента буферизируются, но номер подтвержденной последовательности не изменяется. Если впоследствии будет принят сегмент, относящийся к ожидаемому номеру последовательности, то порядок данных будет автоматически восстановлен исходя из номеров последовательностей в сегментах.
Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приемник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приемника передающей стороне в поле «окно» указывается текущий размер приемного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приемник. Если приемник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, до тех пор пока приемник не сообщит о большем размере окна.
В некоторых случаях передающее приложение может явно затребовать протолкнуть данные до некоторой последовательности принимающему приложению, не буферизируя их. Для этого используется флаг PSH. Если в полученном сегменте обнаруживается флаг PSH, то реализация TCP отдает все буферизированные на текущий момент данные принимающему приложению. «Проталкивание» используется, например, в интерактивных приложениях. В сетевых терминалах нет смысла ожидать ввода пользователя после того, как он закончил набирать команду. Поэтому последний сегмент, содержащий команду, обязан содержать флаг PSH, чтобы приложение на принимающей стороне смогло начать её выполнение.
Завершение соединения можно рассмотреть в три этапа:
- Посылка серверу от клиента флагов FIN и ACK на завершение соединения.
- Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
- После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.
TCP требует явного указания максимального размера сегмента в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока менее, чем стандартный размер блока (MTU) Ethernet (1500 байт).
В протоколах туннелирования, таких как GRE, IPIP а также PPPoE MTU туннеля меньше чем стандартный, поэтому сегмент TCP максимального размера имеет длину пакета больше, чем MTU. Поскольку фрагментация в подавляющем большинстве случаев запрещена, то такие пакеты отбрасываются.
Проявление этой проблемы выглядит как «зависание» соединений. При этом «зависание» может происходить в произвольные моменты времени, а именно тогда, когда отправитель использовал сегменты длиннее допустимого размера.
Для решения этой проблемы на маршрутизаторах применяются правила Firewall-а, добавляющие параметр MSS во все пакеты, инициирующие соединения, чтобы отправитель использовал сегменты допустимого размера.
MSS может также управляться параметрами операционной системы.
Дата добавления: 2014-12-16 ; Просмотров: 339 ; Нарушение авторских прав?
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
