Протокол управления передачей ( TCP ) является одним из основных протоколов набора протоколов Интернета . Он возник в первоначальной реализации сети, в которой он дополнял Интернет-протокол (IP). Поэтому весь пакет обычно называют TCP/IP . TCP обеспечивает надежную , упорядоченную и проверенную на ошибки доставку потока октетов ( байтов) между приложениями, работающими на хостах, взаимодействующих через IP-сеть . Основные интернет-приложения, такие как Всемирная паутина , электронная почта, удаленное администрирование и передача файлов , используют протокол TCP, который является частью транспортного уровня пакета TCP/IP. SSL/TLS часто работает поверх TCP.
TCP ориентирован на соединение , и соединение между клиентом и сервером устанавливается до отправки данных. Сервер должен прослушивать (пассивно открываться) запросы на подключение от клиентов, прежде чем соединение будет установлено. Трехстороннее рукопожатие (активное открытие), повторная передача и обнаружение ошибок повышают надежность, но удлиняют задержку . Приложения, которым не требуется надежная служба потоков данных , могут вместо этого использовать протокол пользовательских дейтаграмм (UDP), который обеспечивает службу дейтаграмм без установления соединения , в которой время отдается приоритету над надежностью. TCP использует предотвращение перегрузки сети . Однако в TCP существуют уязвимости, в том числе отказ в обслуживании , перехват соединения , вето TCP и атака сброса .
В мае 1974 года Винт Серф и Боб Кан описали протокол межсетевого взаимодействия для совместного использования ресурсов с использованием коммутации пакетов между сетевыми узлами. [1] Авторы работали с Жераром Ле Ланном над включением концепций французского проекта CYCLADES в новую сеть. [2] Спецификация полученного протокола, RFC 675 ( Спецификация программы управления передачей через Интернет ), была написана Винтом Серфом, Йогеном Далалом и Карлом Саншайном и опубликована в декабре 1974 года. [3] Он содержит первое засвидетельствованное использование термин Интернет , как сокращение от межсетевого взаимодействия . [ нужна цитата ]
Центральным компонентом управления этой модели была программа управления передачей , которая включала как каналы, ориентированные на соединение, так и службы дейтаграмм между хостами. Монолитная программа управления передачей позже была разделена на модульную архитектуру, состоящую из протокола управления передачей и интернет-протокола . В результате появилась сетевая модель, которая неофициально стала известна как TCP/IP , хотя формально ее по-разному называли моделью Министерства обороны (DOD), моделью ARPANET и, в конечном итоге, также набором протоколов Интернета .
В 2004 году Винт Серф и Боб Кан получили Премию Тьюринга за фундаментальную работу над TCP/IP. [4] [5]
Протокол управления передачей обеспечивает службу связи на промежуточном уровне между прикладной программой и Интернет-протоколом. Он обеспечивает соединение между хостами на транспортном уровне модели Интернета . Приложению не нужно знать конкретные механизмы отправки данных по каналу на другой хост, например, необходимую IP-фрагментацию для размещения максимальной единицы передачи в среде передачи. На транспортном уровне TCP обрабатывает все детали установления связи и передачи и представляет приложению абстракцию сетевого подключения, обычно через интерфейс сетевого сокета .
На нижних уровнях стека протоколов из-за перегрузки сети , балансировки нагрузки трафика или непредсказуемого поведения сети IP-пакеты могут теряться , дублироваться или доставляться с нарушением порядка . TCP обнаруживает эти проблемы, запрашивает повторную передачу потерянных данных, упорядочивает неупорядоченные данные и даже помогает минимизировать перегрузку сети, чтобы уменьшить возникновение других проблем. Если данные по-прежнему не доставлены, источник уведомляется об этой ошибке. Как только получатель TCP заново собрал последовательность первоначально переданных октетов, он передает их принимающему приложению. Таким образом, TCP абстрагирует взаимодействие приложения от основных сетевых деталей.
TCP широко используется многими интернет-приложениями, включая World Wide Web (WWW), электронную почту, протокол передачи файлов , Secure Shell , одноранговый обмен файлами и потоковую передачу мультимедиа .
TCP оптимизирован для точной доставки, а не для своевременной доставки, и может вызывать относительно длительные задержки (порядка секунд) при ожидании сообщений, находящихся вне очереди, или повторной передачи потерянных сообщений. Поэтому он не особенно подходит для приложений реального времени, таких как передача голоса по IP . Для таких приложений обычно рекомендуются такие протоколы, как транспортный протокол реального времени (RTP), работающий поверх протокола пользовательских дейтаграмм (UDP). [6]
TCP — это надежная служба доставки потока байтов , которая гарантирует, что все полученные байты будут идентичны и в том же порядке, что и отправленные. Поскольку передача пакетов во многих сетях ненадежна, TCP достигает этого с помощью метода, известного как положительное подтверждение с повторной передачей . Для этого получатель должен ответить подтверждающим сообщением при получении данных. Отправитель ведет учет каждого отправляемого пакета и поддерживает таймер с момента отправки пакета. Отправитель повторно передает пакет, если таймер истекает до получения подтверждения. Таймер необходим на случай потери или повреждения пакета. [6]
В то время как IP занимается фактической доставкой данных, TCP отслеживает сегменты — отдельные единицы передачи данных, на которые делится сообщение для эффективной маршрутизации по сети. Например, когда файл HTML отправляется с веб-сервера, уровень программного обеспечения TCP этого сервера делит файл на сегменты и пересылает их индивидуально на интернет-уровень сетевого стека . Программное обеспечение интернет-уровня инкапсулирует каждый сегмент TCP в IP-пакет, добавляя заголовок, который включает (помимо других данных) IP-адрес назначения . Когда клиентская программа на целевом компьютере получает их, программное обеспечение TCP на транспортном уровне повторно собирает сегменты и обеспечивает их правильный порядок и отсутствие ошибок при потоковой передаче содержимого файла принимающему приложению.
Протокол управления передачей принимает данные из потока данных, делит их на фрагменты и добавляет заголовок TCP, создавая сегмент TCP. Затем сегмент TCP инкапсулируется в дейтаграмму Интернет-протокола (IP) и обменивается данными с одноранговыми узлами. [7]
Термин TCP-пакет встречается как в неофициальном, так и в формальном использовании, тогда как в более точной терминологии сегмент относится к блоку данных протокола TCP (PDU), дейтаграмма [8] к IP PDU и кадр к PDU канального уровня :
Процессы передают данные, вызывая TCP и передавая буферы данных в качестве аргументов. TCP упаковывает данные из этих буферов в сегменты и вызывает интернет-модуль [например, IP] для передачи каждого сегмента в TCP-адрес назначения. [9]
Сегмент TCP состоит из заголовка сегмента и раздела данных . Заголовок сегмента содержит 10 обязательных полей и необязательное поле расширения ( Параметры , розовый фон в таблице). Раздел данных следует за заголовком и представляет собой полезные данные, переносимые для приложения. [10] Длина раздела данных не указана в заголовке сегмента; ее можно рассчитать путем вычитания общей длины заголовка сегмента и заголовка IP из общей длины датаграммы IP, указанной в заголовке IP. [ нужна цитата ]
[SYN]. Option-Kind и стандартная длина, заданная как (Option-Kind, Option-Length).
Операции протокола TCP можно разделить на три фазы. Установление соединения — это многоэтапный процесс установления связи, который устанавливает соединение перед переходом к этапу передачи данных . После завершения передачи данных завершение соединения закрывает соединение и освобождает все выделенные ресурсы.
TCP-соединение управляется операционной системой через ресурс, который представляет собой локальную конечную точку связи — интернет-сокет . За время существования TCP-соединения локальная конечная точка претерпевает ряд изменений состояния : [23]
Прежде чем клиент попытается подключиться к серверу, сервер должен сначала привязаться к порту и прослушать его, чтобы открыть его для соединений: это называется пассивным открытием. После установления пассивного открытия клиент может установить соединение, инициировав активное открытие с помощью трехэтапного (или трехэтапного) рукопожатия:
Шаги 1 и 2 устанавливают и подтверждают порядковый номер для одного направления (от клиента к серверу). Шаги 2 и 3 устанавливают и подтверждают порядковый номер для другого направления (от сервера к клиенту). После завершения этих шагов и клиент, и сервер получили подтверждения и установилась полнодуплексная связь.
На этапе завершения соединения используется четырехстороннее рукопожатие, при этом каждая сторона соединения завершается независимо. Когда конечная точка желает прекратить свою половину соединения, она передает пакет FIN, который другой конец подтверждает подтверждением ACK. Таким образом, для типичного отключения требуется пара сегментов FIN и ACK от каждой конечной точки TCP. После того, как сторона, отправившая первый FIN, ответила окончательным подтверждением ACK, она ждет тайм-аут, прежде чем окончательно закрыть соединение, в течение которого локальный порт недоступен для новых соединений; это состояние позволяет TCP-клиенту повторно отправить окончательное подтверждение на сервер в случае потери ACK при передаче. Продолжительность времени зависит от реализации, но некоторые общие значения составляют 30 секунд, 1 минуту и 2 минуты. По истечении таймаута клиент переходит в состояние ЗАКРЫТО и локальный порт становится доступен для новых подключений. [24]
Также возможно разорвать соединение с помощью трехстороннего рукопожатия, когда хост A отправляет FIN, хост B отвечает FIN и ACK (объединяя два шага в один), а хост A отвечает ACK. [25]
Некоторые операционные системы, такие как Linux и HP-UX , реализуют полудуплексную последовательность закрытия. Если хост активно закрывает соединение, хотя все еще имеет доступные непрочитанные входящие данные, хост отправляет сигнал RST (теряя все полученные данные) вместо FIN. Это гарантирует, что приложение TCP знает о потере данных. [26]
Соединение может находиться в полуоткрытом состоянии, и в этом случае одна сторона разорвала соединение, а другая — нет. Сторона, которая завершила соединение, больше не может отправлять какие-либо данные в соединение, а другая сторона может. Завершающая сторона должна продолжать чтение данных до тех пор, пока другая сторона также не завершится. [ нужна цитата ]
В большинстве реализаций в таблице выделяется запись, которая сопоставляет сеанс с запущенным процессом операционной системы. Поскольку пакеты TCP не содержат идентификатор сеанса, обе конечные точки идентифицируют сеанс, используя адрес и порт клиента. Всякий раз при получении пакета реализация TCP должна выполнить поиск в этой таблице, чтобы найти процесс назначения. Каждая запись в таблице известна как блок управления передачей или TCB. Он содержит информацию о конечных точках (IP и порт), состоянии соединения, текущих данных о пакетах, которыми обмениваются, и буферах для отправки и получения данных.
Количество сеансов на стороне сервера ограничено только объемом памяти и может увеличиваться по мере поступления новых подключений, но клиент должен выделить временный порт перед отправкой первого SYN на сервер. Этот порт остается выделенным на протяжении всего разговора и эффективно ограничивает количество исходящих подключений с каждого IP-адреса клиента. Если приложению не удается должным образом закрыть ненужные соединения, у клиента могут исчерпаться ресурсы и он не сможет устанавливать новые TCP-соединения даже из других приложений.
Обе конечные точки также должны выделить пространство для неподтвержденных пакетов и полученных (но непрочитанных) данных.
Протокол управления передачей отличается от протокола пользовательских дейтаграмм несколькими ключевыми особенностями :
TCP использует порядковый номер для идентификации каждого байта данных. Порядковый номер определяет порядок байтов, отправленных с каждого компьютера, чтобы данные можно было восстановить по порядку, независимо от возможной доставки с нарушением порядка . Порядковый номер первого байта выбирается передатчиком для первого пакета, который помечен флагом SYN. Это число может быть произвольным и фактически должно быть непредсказуемым для защиты от атак с предсказанием последовательности TCP .
Подтверждения (ACK) отправляются получателем данных с порядковым номером, чтобы сообщить отправителю, что данные были получены в указанном байте. ACK не означают, что данные были доставлены приложению, они просто означают, что теперь ответственность за доставку данных лежит на получателе.
Надежность достигается за счет того, что отправитель обнаруживает потерянные данные и повторно передает их. TCP использует два основных метода для выявления потерь. Тайм-аут повторной передачи (RTO) и повторяющиеся совокупные подтверждения (DupAcks).
При повторной передаче сегмента TCP он сохраняет тот же порядковый номер, что и исходная попытка доставки. Такое сочетание доставки и логического порядка данных означает, что, когда подтверждение получено после повторной передачи, отправитель не может определить, подтверждается ли исходная передача или повторная передача, так называемая неоднозначность повторной передачи . [27] TCP усложняется из-за неоднозначности повторной передачи. [28]
Если один сегмент (скажем, номер сегмента 100) в потоке потерян, то получатель не может подтвердить пакеты, превышающие этот номер сегмента (100), поскольку он использует накопительные подтверждения. Следовательно, получатель снова подтверждает пакет 99 при получении другого пакета данных. Это дублированное подтверждение используется как сигнал потери пакета. То есть, если отправитель получает три повторяющихся подтверждения, он повторно передает последний неподтвержденный пакет. Используется пороговое значение, равное трем, поскольку сеть может изменить порядок сегментов, что приведет к дублированию подтверждений. Было продемонстрировано, что этот порог позволяет избежать ложных повторных передач из-за изменения порядка. [29] Некоторые реализации TCP используют выборочные подтверждения (SACK) для предоставления явной обратной связи о полученных сегментах. Это значительно улучшает способность TCP повторно передавать нужные сегменты.
Неоднозначность повторной передачи может привести к ложным быстрым повторным передачам и предотвращению перегрузки, если переупорядочение выходит за пределы порога дублированного подтверждения. [30]
Когда отправитель передает сегмент, он инициализирует таймер с консервативной оценкой времени прибытия подтверждения. Сегмент передается повторно, если время таймера истекает, с новым пороговым значением тайм-аута, в два раза превышающим предыдущее значение, что приводит к экспоненциальной отсрочке передачи . Обычно начальное значение таймера равно , где — степень детализации часов. [31] Это защищает от чрезмерного трафика передачи из-за неисправных или злонамеренных субъектов, таких как злоумышленники, осуществляющие отказ в обслуживании .
Точные оценки RTT важны для восстановления потерь, поскольку они позволяют отправителю предположить, что неподтвержденный пакет будет потерян по истечении достаточного времени (т. е. определения времени RTO). [32] Неоднозначность повторной передачи может привести к тому, что оценка RTT отправителем будет неточной. [32] В среде с переменными значениями RTT могут возникать ложные тайм-ауты: [33] если значение RTT занижено, то RTO срабатывает и запускает ненужную повторную передачу и медленный старт. После ложной повторной передачи, когда приходят подтверждения исходной передачи, отправитель может полагать, что он подтверждает повторную передачу, и ошибочно заключить, что сегменты, отправленные между исходной передачей и повторной передачей, были потеряны, вызывая дальнейшие ненужные повторные передачи до такой степени, что канал действительно становится перегруженным; [34] [35] Выборочное подтверждение может уменьшить этот эффект. [36] RFC 6298 указывает, что реализации не должны использовать повторно передаваемые сегменты при оценке RTT. [37] Алгоритм Карна гарантирует, что в конечном итоге будет получена хорошая оценка RTT, ожидая однозначного подтверждения перед корректировкой RTO. [38] Однако после ложных повторных передач может пройти значительное время, прежде чем придет такое однозначное подтверждение, что в это время ухудшает производительность. [39] Временные метки TCP также решают проблему неоднозначности повторной передачи при установке RTO, [37] хотя они не обязательно улучшают оценку RTT. [40]
Порядковые номера позволяют получателям отбрасывать повторяющиеся пакеты и правильно упорядочивать пакеты, нарушающие порядок. Подтверждения позволяют отправителям определить, когда следует повторно передать потерянные пакеты.
Для обеспечения правильности включено поле контрольной суммы; подробности см. в § Вычисление контрольной суммы. Контрольная сумма TCP является слабой проверкой по современным стандартам и обычно сочетается с проверкой целостности CRC на уровне 2 , ниже TCP и IP, например, который используется в PPP или кадре Ethernet . Однако появление ошибок в пакетах между узлами, защищенными CRC, является обычным явлением, и 16-битная контрольная сумма TCP улавливает большинство из них. [41]
TCP использует сквозной протокол управления потоком , чтобы отправитель не отправлял данные слишком быстро, чтобы получатель TCP мог их надежно получить и обработать. Наличие механизма управления потоком имеет важное значение в среде, где обмениваются данными машины с разными скоростями сети. Например, если ПК отправляет данные на смартфон, который медленно обрабатывает полученные данные, смартфон должен иметь возможность регулировать поток данных, чтобы не перегружаться. [6]
TCP использует протокол управления потоком скользящего окна . В каждом сегменте TCP получатель указывает в поле окна приема объем дополнительно полученных данных (в байтах), которые он готов буферизовать для соединения. Отправляющий узел может отправлять только этот объем данных, прежде чем ему придется дождаться подтверждения и получить обновление окна от принимающего узла.
Когда получатель объявляет размер окна равный 0, отправитель прекращает отправку данных и запускает таймер сохранения . Таймер сохранения используется для защиты TCP от ситуации взаимоблокировки , которая может возникнуть, если последующее обновление размера окна от получателя потеряно, и отправитель не сможет отправить больше данных до тех пор, пока не получит новое обновление размера окна от получателя. По истечении времени таймера сохранения отправитель TCP пытается восстановиться, отправляя небольшой пакет, а получатель в ответ отправляет еще одно подтверждение, содержащее новый размер окна.
Если получатель обрабатывает входящие данные небольшими порциями, он может неоднократно объявлять небольшое окно приема. Это называется синдромом глупого окна , поскольку неэффективно отправлять только несколько байтов данных в сегменте TCP, учитывая относительно большие накладные расходы заголовка TCP.
Последним основным аспектом TCP является контроль перегрузки . TCP использует ряд механизмов для достижения высокой производительности и предотвращения перегрузочного коллапса — тупиковой ситуации, когда производительность сети серьезно снижается. Эти механизмы контролируют скорость поступления данных в сеть, удерживая поток данных ниже скорости, которая может привести к коллапсу. Они также обеспечивают приблизительно максимально-минимальное справедливое распределение между потоками.
Подтверждения отправленных данных или отсутствие подтверждений используются отправителями для определения состояния сети между отправителем и получателем TCP. В сочетании с таймерами отправители и получатели TCP могут изменять поведение потока данных. В более общем смысле это называется контролем перегрузок или предотвращением перегрузок.
Современные реализации TCP содержат четыре переплетенных алгоритма: медленный старт , предотвращение перегрузки , быстрая повторная передача и быстрое восстановление . [42]
Кроме того, отправители используют тайм-аут повторной передачи (RTO), который основан на расчетном времени прохождения туда и обратно (RTT) между отправителем и получателем, а также на разнице этого времени прохождения туда и обратно. [43] В оценке RTT есть свои тонкости. Например, отправители должны быть осторожны при вычислении выборок RTT для повторно передаваемых пакетов; обычно они используют алгоритм Карна или временные метки TCP. [18] Эти отдельные выборки RTT затем усредняются по времени для создания сглаженного времени прохождения туда и обратно (SRTT) с использованием алгоритма Джейкобсона. Это значение SRTT используется в качестве оценки времени прохождения туда и обратно.
Улучшение TCP для надежной обработки потерь, минимизации ошибок, управления перегрузками и быстрой работы в очень высокоскоростных средах — это постоянные области исследований и разработки стандартов. В результате существует ряд вариантов алгоритма предотвращения перегрузки TCP .
Максимальный размер сегмента (MSS) — это наибольший объем данных, указанный в байтах, который TCP готов получить в одном сегменте. Для достижения наилучшей производительности MSS должен быть установлен достаточно маленьким, чтобы избежать фрагментации IP , которая может привести к потере пакетов и чрезмерным повторным передачам. Для этого каждая сторона обычно объявляет MSS с использованием опции MSS при установке TCP-соединения. Значение параметра выводится из максимального размера единицы передачи (MTU) уровня канала передачи данных сетей, к которым напрямую подключены отправитель и получатель. Отправители TCP могут использовать обнаружение MTU пути , чтобы определить минимальный MTU на сетевом пути между отправителем и получателем и использовать его для динамической настройки MSS, чтобы избежать фрагментации IP внутри сети.
Объявление MSS также можно назвать согласованием MSS , но, строго говоря, MSS не согласовывается . Два полностью независимых значения MSS разрешены для двух направлений потока данных в TCP-соединении, [44] [9] , поэтому нет необходимости согласовывать общую конфигурацию MSS для двунаправленного соединения.
Если полагаться исключительно на схему кумулятивного подтверждения, используемую исходным TCP, это может привести к неэффективности при потере пакетов. Например, предположим, что байты с порядковыми номерами от 1000 до 10999 отправляются в 10 различных сегментах TCP одинакового размера, а второй сегмент (порядковые номера от 2000 до 2999) теряется во время передачи. В протоколе чистого кумулятивного подтверждения получатель может отправить только совокупное значение ACK, равное 2000 (порядковый номер, следующий сразу за последним порядковым номером полученных данных), и не может сказать, что он успешно получил байты с 3000 по 10999. Таким образом, отправителю, возможно, придется повторно отправить все данные, начиная с порядкового номера 2000.
Чтобы решить эту проблему, TCP использует опцию выборочного подтверждения (SACK) , определенную в 1996 году в RFC 2018, которая позволяет получателю подтверждать прерывистые блоки пакетов, которые были получены правильно, в дополнение к порядковому номеру, следующему сразу за последним порядковым номером пакета. последний непрерывный байт получен последовательно, как и в базовом подтверждении TCP. Подтверждение может включать в себя несколько блоков SACK , где каждый блок SACK передается по левому краю блока (первый порядковый номер блока) и правом краю блока (порядковый номер, следующий сразу за последним порядковым номером блока). ), где Блок представляет собой непрерывный диапазон, который получатель правильно принял. В приведенном выше примере получатель отправит сегмент ACK с совокупным значением ACK 2000 и заголовком опции SACK с порядковыми номерами 3000 и 11000. Соответственно, отправитель будет повторно передавать только второй сегмент с порядковыми номерами от 2000 до 2999.
Отправитель TCP может интерпретировать доставку сегмента с нарушением порядка как потерянный сегмент. Если это произойдет, отправитель TCP повторно передаст сегмент, предшествующий пакету с нарушением порядка, и замедлит скорость доставки данных для этого соединения. Опция дублирования SACK, расширение опции SACK, определенной в мае 2000 года в RFC 2883, решает эту проблему. Получатель TCP отправляет D-ACK, чтобы указать, что ни один сегмент не был потерян, и отправитель TCP может затем восстановить более высокую скорость передачи.
Опция SACK не является обязательной и вступает в силу только в том случае, если обе стороны ее поддерживают. Это согласовывается при установке соединения. SACK использует опцию заголовка TCP (подробнее см. § Структура сегмента TCP). Использование SACK получило широкое распространение — его поддерживают все популярные стеки TCP. Выборочное подтверждение также используется в протоколе передачи управления потоком (SCTP).
Выборочные подтверждения могут быть «отменены», когда получатель в одностороннем порядке отбрасывает выборочно подтвержденные данные. RFC 2018 не одобрял такое поведение, но не запрещал давать получателям возможность отказаться, если у них, например, закончилось буферное пространство. [45] Возможность отказа приводит к сложности реализации как для отправителей, так и для получателей, а также требует затрат памяти для отправителя. [46]
Для более эффективного использования сетей с высокой пропускной способностью можно использовать больший размер окна TCP. 16-битное поле размера окна TCP управляет потоком данных, и его значение ограничено 65 535 байтами. Поскольку поле размера не может быть расширено за пределы этого предела, используется коэффициент масштабирования. Параметр масштабирования окна TCP , определенный в RFC 1323, представляет собой параметр, используемый для увеличения максимального размера окна до 1 гигабайта. Масштабирование до этих больших размеров окна необходимо для настройки TCP .
Параметр масштабирования окна используется только во время трехстороннего установления связи TCP. Значение масштаба окна представляет собой количество битов, на которое можно сдвинуть влево 16-битное поле размера окна при его интерпретации. Значение масштаба окна можно установить от 0 (без смещения) до 14 для каждого направления независимо. Обе стороны должны отправить опцию в своих сегментах SYN, чтобы включить масштабирование окна в любом направлении.
Некоторые маршрутизаторы и пакетные межсетевые экраны переписывают коэффициент масштабирования окна во время передачи. Это приводит к тому, что отправляющая и принимающая стороны принимают разные размеры окна TCP. В результате получается нестабильный трафик, который может быть очень медленным. Проблема видна на некоторых сайтах за неисправным роутером. [47]
Временные метки TCP, определенные в RFC 1323 в 1992 году, могут помочь TCP определить, в каком порядке были отправлены пакеты. Временные метки TCP обычно не привязаны к системным часам и начинаются с некоторого случайного значения. Многие операционные системы увеличивают временную метку каждую прошедшую миллисекунду; однако в RFC указано только, что отметки должны быть пропорциональными.
Есть два поля временных меток:
Временные метки TCP используются в алгоритме, известном как защита от завернутых порядковых номеров или PAWS . PAWS используется, когда окно приема пересекает границу переноса порядкового номера. В случае, когда пакет потенциально был передан повторно, он отвечает на вопрос: «Этот порядковый номер находится в первых 4 ГБ или во вторых?» И временная метка используется для разрыва связи.
Кроме того, алгоритм обнаружения Eifel использует временные метки TCP, чтобы определить, происходят ли повторные передачи из-за того, что пакеты потеряны или просто вышли из строя. [48]
Временные метки TCP включены по умолчанию в Linux [49] и отключены по умолчанию в Windows Server 2008, 2012 и 2016. [50]
Недавняя статистика показывает, что уровень внедрения временных меток TCP остался на уровне ~40% из-за прекращения поддержки Windows Server с момента выпуска Windows Server 2008. [51]
Можно прервать или прервать поток в очереди вместо того, чтобы ждать завершения потока. Это делается путем указания данных как срочных . Это помечает передачу как внеполосные данные (OOB) и сообщает принимающей программе немедленно обработать ее. По завершении TCP информирует приложение и возобновляет очередь потока. Примером может служить TCP, используемый для сеанса удаленного входа в систему, когда пользователь может отправить последовательность клавиш, которая прерывает или прерывает удаленно работающую программу, не дожидаясь, пока программа завершит свою текущую передачу. [6]
Указатель срочности изменяет только обработку на удаленном хосте и не ускоряет обработку в самой сети. Эта возможность реализована по-разному или плохо в разных системах или может не поддерживаться. Там, где это возможно, разумно предположить, что будут надежно обрабатываться только отдельные байты данных OOB. [52] [53] Поскольку эта функция используется нечасто, она недостаточно протестирована на некоторых платформах и связана с уязвимостями , например WinNuke .
Обычно TCP ожидает отправки полного пакета данных в течение 200 мс ( алгоритм Нэгла пытается сгруппировать небольшие сообщения в один пакет). Такое ожидание создает небольшие, но потенциально серьезные задержки, если оно повторяется постоянно во время передачи файла. Например, типичный блок отправки будет 4 КБ, типичный MSS — 1460, поэтому 2 пакета отправляются по Ethernet со скоростью 10 Мбит / с, занимая ~ 1,2 мс каждый, а затем третий передает оставшиеся 1176 после паузы в 197 мс, потому что TCP ожидает полного буфера. В случае telnet каждое нажатие клавиши пользователя отражается сервером до того, как пользователь увидит его на экране. Эта задержка будет очень раздражать.
Установка параметра сокетаTCP_NODELAY отменяет задержку отправки по умолчанию в 200 мс. Прикладные программы используют эту опцию сокета, чтобы принудительно отправить вывод после записи символа или строки символов.
RFC [ какой? ] определяет PSHpush-бит как «сообщение принимающему TCP-стеку о необходимости немедленной отправки этих данных принимающему приложению». [6] Невозможно указать или контролировать его в пользовательском пространстве с помощью сокетов Беркли ; он контролируется только стеком протоколов . [54]
TCP может быть атакован различными способами. Результаты тщательной оценки безопасности TCP, а также возможные способы устранения выявленных проблем были опубликованы в 2009 году [55] и продолжались в IETF до 2012 года . [56] Известные уязвимости включают отказ в обслуживании, перехват соединения, TCP вето и атака сброса TCP .
Используя поддельный IP-адрес и неоднократно отправляя специально собранные пакеты SYN, за которыми следует множество пакетов ACK, злоумышленники могут заставить сервер потреблять большое количество ресурсов для отслеживания фиктивных соединений. Это известно как SYN-флуд -атака. Предлагаемые решения этой проблемы включают файлы cookie SYN и криптографические головоломки, хотя файлы cookie SYN имеют свой собственный набор уязвимостей. [57] Sockstress — аналогичная атака, которую можно смягчить с помощью управления системными ресурсами. [58] Продвинутая DoS-атака, включающая использование таймера сохранения TCP , была проанализирована в Phrack № 66. [59] Другими вариантами являются PUSH- и ACK-флуды . [60]
Злоумышленник, который может подслушать сеанс TCP и перенаправить пакеты, может перехватить TCP-соединение. Для этого злоумышленник узнает порядковый номер из текущего обмена данными и создает ложный сегмент, который выглядит как следующий сегмент в потоке. Простой захват может привести к тому, что один пакет будет ошибочно принят на одном конце. Когда принимающий хост подтверждает ложный сегмент, синхронизация теряется. [61] Перехват может сочетаться с подменой ARP или другими атаками на маршрутизацию, которые позволяют злоумышленнику получить постоянный контроль над TCP-соединением.
До RFC 1948, когда исходный порядковый номер можно было легко угадать, выдать себя за другой IP-адрес не было сложно. Более ранние реализации позволяли злоумышленнику слепо отправлять последовательность пакетов, которые, по мнению получателя, пришли с другого IP-адреса, без необходимости перехвата связи через ARP или атаки маршрутизации: достаточно убедиться, что законный хост с выдающимся IP-адресом адрес не работает, или доведите его до этого состояния с помощью атак типа «отказ в обслуживании» . Вот почему начальный порядковый номер теперь выбирается случайным образом.
Злоумышленник, который может подслушать и предсказать размер следующего отправляемого пакета, может заставить получателя принять вредоносную полезную нагрузку, не нарушая существующее соединение. Злоумышленник внедряет вредоносный пакет с порядковым номером и размером полезной нагрузки следующего ожидаемого пакета. Когда законный пакет в конечном итоге получен, обнаруживается, что он имеет тот же порядковый номер и длину, что и уже полученный пакет, и автоматически отбрасывается, как обычный дубликат пакета - злонамеренный пакет накладывает вето на законный пакет. В отличие от перехвата соединения, соединение никогда не десинхронизируется, и связь продолжается в обычном режиме после принятия вредоносной полезной нагрузки. TCP-вето дает злоумышленнику меньший контроль над связью, но делает атаку особенно устойчивой к обнаружению. Единственным доказательством для получателя того, что что-то не так, является один дублирующийся пакет, что является обычным явлением в IP-сети. Отправитель пакета, на который наложено вето, никогда не видит никаких доказательств атаки. [62]
TCP-соединение идентифицируется четырьмя кортежами : адрес источника, порт источника , адрес назначения и порт назначения. [d] [63] [64] Номера портов используются для идентификации различных служб и для разрешения нескольких соединений между хостами. [7] TCP использует 16-битные номера портов, предоставляя 65 536 возможных значений для каждого порта источника и назначения. [10] Зависимость идентификатора соединения от адресов означает, что TCP-соединения привязаны к одному сетевому пути; TCP не может использовать другие маршруты, доступные многосетевым узлам , и соединения разрываются при изменении адреса конечной точки. [65]
Номера портов делятся на три основные категории: общеизвестные, зарегистрированные и динамические или частные. Хорошо известные порты назначаются Управлением по присвоению номеров Интернета (IANA) и обычно используются процессами системного уровня. Эти порты обычно используются хорошо известными приложениями, работающими как серверы и пассивно прослушивающими соединения. Некоторые примеры включают: FTP (20 и 21), SSH (22), TELNET (23), SMTP (25), HTTP через SSL/TLS (443) и HTTP (80). [e] Зарегистрированные порты обычно используются приложениями конечных пользователей в качестве временных исходных портов при обращении к серверам, но они также могут идентифицировать именованные службы, зарегистрированные третьей стороной. Динамические или частные порты также могут использоваться приложениями конечных пользователей, однако эти порты обычно не несут никакого значения за пределами конкретного TCP-соединения.
Трансляция сетевых адресов (NAT) обычно использует динамические номера портов на общедоступной стороне, чтобы устранить неоднозначность потока трафика, проходящего между общедоступной сетью и частной подсетью , тем самым позволяя использовать множество IP-адресов (и их портов) в одной сети. подсеть, которая будет обслуживаться одним общедоступным адресом.
TCP — сложный протокол. Однако, несмотря на то, что за прошедшие годы были сделаны и предложены значительные усовершенствования, его основные операции существенно не изменились со времени его первой спецификации RFC 675 в 1974 году и спецификации v4 RFC 793, опубликованной в сентябре 1981 года. RFC 1122, опубликованной в октябре 1989 года. , уточнил ряд требований к реализации протокола TCP. Список из 8 обязательных спецификаций и более 20 настоятельно рекомендуемых улучшений доступен в RFC 7414. В этот список входит RFC 2581, TCP Congestion Control, один из наиболее важных RFC, связанных с TCP, за последние годы, описывающий обновленные алгоритмы, позволяющие избежать ненужной перегрузки. . В 2001 году был написан RFC 3168 для описания явного уведомления о перегрузке (ECN), механизма сигнализации предотвращения перегрузки.
Исходный алгоритм предотвращения перегрузки TCP был известен как TCP Tahoe , но с тех пор было предложено множество альтернативных алгоритмов (включая TCP Reno , TCP Vegas , FAST TCP , TCP New Reno и TCP Hybla ).
Многопутевой TCP (MPTCP) [66] [67] — это постоянная работа в рамках IETF, цель которой — разрешить TCP-соединению использовать несколько путей для максимального использования ресурсов и повышения избыточности. Избыточность, обеспечиваемая Multipath TCP в контексте беспроводных сетей, позволяет одновременно использовать разные сети, что обеспечивает более высокую пропускную способность и лучшие возможности передачи обслуживания. Multipath TCP также обеспечивает повышение производительности в средах центров обработки данных. [68] Эталонная реализация [69] Multipath TCP была разработана в ядре Linux. [70] Multipath TCP используется для поддержки приложения распознавания голоса Siri на iPhone, iPad и Mac. [71]
tcpcrypt — это расширение, предложенное в июле 2010 года для обеспечения шифрования транспортного уровня непосредственно в самом TCP. Он предназначен для прозрачной работы и не требует какой-либо настройки. В отличие от TLS (SSL), tcpcrypt сам по себе не обеспечивает аутентификацию, но предоставляет для этого приложению простые примитивы. RFC tcpcrypt был опубликован IETF в мае 2019 года. [72]
TCP Fast Open — это расширение, позволяющее ускорить открытие последовательных TCP-соединений между двумя конечными точками. Он работает, пропуская трехстороннее рукопожатие с использованием криптографического «cookie». Оно похоже на более раннее предложение под названием T/TCP , которое не получило широкого распространения из-за проблем безопасности. [73] TCP Fast Open был опубликован как RFC 7413 в 2014 году. [74]
Пропорциональное снижение скорости (PRR), предложенное в мае 2013 года, представляет собой расширение TCP, разработанное инженерами Google. PRR гарантирует, что размер окна TCP после восстановления будет как можно ближе к порогу медленного запуска . [75] Алгоритм предназначен для повышения скорости восстановления и является алгоритмом управления перегрузкой по умолчанию в ядрах Linux 3.2+. [76]
TCP Cookie Transactions (TCPCT) — это расширение, предложенное в декабре 2009 года [77] для защиты серверов от атак типа «отказ в обслуживании». В отличие от файлов cookie SYN, TCPCT не конфликтует с другими расширениями TCP, такими как масштабирование окон . TCPCT был разработан в связи с необходимостью DNSSEC , где серверам приходится обрабатывать большое количество кратковременных TCP-соединений. В 2016 году TCPCT был устаревшим в пользу TCP Fast Open . Статус исходного RFC был изменен на «исторический». [78]
Одним из способов преодоления требований к вычислительной мощности TCP является создание его аппаратных реализаций, широко известных как механизмы разгрузки TCP (TOE). Основная проблема ОО заключается в том, что их трудно интегрировать в вычислительные системы, что требует значительных изменений в операционной системе компьютера или устройства. Одной из компаний, разработавших такое устройство, была Alacritech.
Проводной образ TCP предоставляет наблюдателям на пути значительные возможности по сбору и модификации информации, поскольку метаданные протокола передаются в открытом виде . [79] [80] Хотя такая прозрачность полезна сетевым операторам [81] и исследователям, [82] информация, полученная из метаданных протокола, может снизить конфиденциальность конечного пользователя. [83] Такая видимость и гибкость метаданных привели к тому, что TCP стало трудно расширять (случай окостенения протокола ), поскольку любой промежуточный узел (« промежуточный блок ») может принимать решения на основе этих метаданных или даже изменять их, [84] [ 85] нарушая сквозной принцип . [86] Одно измерение показало, что треть путей в Интернете сталкивается как минимум с одним посредником, который изменяет метаданные TCP, а 6,5% путей сталкиваются с вредным закостенением эффектов со стороны посредников. [87] Избегание угроз расширяемости со стороны посредников наложило значительные ограничения на разработку MPTCP , [88] [89] , а трудности, вызванные посредниками, препятствовали развертыванию TCP Fast Open в веб-браузерах . [90] Другим источником закостенения является сложность модификации функций TCP на конечных точках, обычно в ядре операционной системы [91] или в аппаратном обеспечении с механизмом разгрузки TCP . [92]
Поскольку TCP предоставляет приложениям абстракцию надежного потока байтов , он может страдать от блокировки начала строки : если пакеты переупорядочиваются или теряются и их необходимо передать повторно (и, следовательно, они поступают не по порядку), данные из последовательно части потока могут быть приняты раньше последовательно более ранних частей потока; однако более поздние данные обычно не могут быть использованы до тех пор, пока не будут получены более ранние данные, что приводит к задержке в сети . Если несколько независимых сообщений более высокого уровня инкапсулируются и мультиплексируются в одном TCP-соединении, то блокировка начала строки может привести к тому, что полностью полученное сообщение, отправленное позже, будет обработано в ожидании доставки сообщения, отправленного ранее. [93] Веб-браузеры пытаются смягчить блокировку начала линии, открывая несколько параллельных соединений. Это влечет за собой повторные затраты на установление соединения, а также увеличение ресурсов, необходимых для отслеживания этих соединений в конечных точках. [94] Параллельные соединения также имеют контроль перегрузки, работающий независимо друг от друга, вместо того, чтобы объединять информацию и более оперативно реагировать на наблюдаемые условия сети; [95] Агрессивные шаблоны начальной отправки TCP могут вызвать перегрузку, если открыто несколько параллельных соединений; а модель справедливости для каждого соединения приводит к монополизации ресурсов приложениями, использующими этот подход. [96]
Установление соединения является основным фактором задержки, с которым сталкиваются веб-пользователи. [97] [98] Трехстороннее рукопожатие TCP вводит задержку в один RTT во время установления соединения, прежде чем данные могут быть отправлены. [98] Для коротких потоков эти задержки очень значительны. [99] Безопасность транспортного уровня (TLS) требует собственного подтверждения связи для обмена ключами при установлении соединения. Из-за многоуровневой конструкции подтверждение TCP и подтверждение TLS выполняются последовательно: подтверждение TLS не может начаться до тех пор, пока подтверждение TCP не завершится. [100] Для установления соединения с TLS 1.3 через TCP требуются два RTT . [101] TLS 1.3 допускает возобновление соединения с нулевым RTT в некоторых обстоятельствах, но при наложении на TCP один RTT по-прежнему требуется для подтверждения TCP, и это не может способствовать первоначальному соединению; Нулевые рукопожатия RTT также создают криптографические проблемы, поскольку эффективный, безопасный для воспроизведения и прямой безопасный неинтерактивный обмен ключами является открытой темой исследований. [102] TCP Fast Open позволяет передавать данные в начальных (т. е. SYN и SYN-ACK) пакетах, устраняя задержку на один RTT во время установления соединения. [103] Однако TCP Fast Open было сложно развернуть из-за окостенения протокола; в 2020 году ни один веб-браузер не использовал его по умолчанию. [90]
На пропускную способность TCP влияет переупорядочение пакетов . Переупорядоченные пакеты могут привести к отправке дублирующих подтверждений, которые, если они превысят пороговое значение, вызовут ложную повторную передачу и контроль перегрузки. Поведение передачи также может стать менее плавным и более прерывистым, поскольку большие диапазоны подтверждаются сразу при получении переупорядоченного пакета в начале диапазона (аналогично тому, как блокировка начала строки влияет на приложения). [104] Блэнтон и Оллман (2002) обнаружили, что пропускная способность обратно пропорциональна количеству переупорядочивания, вплоть до предела, при котором любое переупорядочение вызывает ложную повторную передачу. [105] Смягчение переупорядочения зависит от способности отправителя определить, что он отправил ложную повторную передачу, и, следовательно, от разрешения неоднозначности повторной передачи. [106] Снижение количества ложных повторных передач, вызванных переупорядочением, идет вразрез с быстрым восстановлением после реальных потерь. [107]
Выборочное подтверждение может существенно повысить пропускную способность; Bruyeron, Hemon & Zhang (1998) зафиксировали прирост до 45%. [108] Важным фактором улучшения является то, что избирательное подтверждение позволяет чаще избегать медленного старта после потери и, следовательно, может лучше использовать доступную полосу пропускания. [109] Однако TCP может выборочно подтвердить максимум три блока порядковых номеров. Это может ограничить скорость повторной передачи и, следовательно, восстановление потерь или вызвать ненужные повторные передачи, особенно в средах с высокими потерями. [110] [111]
TCP изначально был разработан для проводных сетей. Потеря пакетов считается результатом перегрузки сети , и в качестве меры предосторожности размер окна перегрузки резко уменьшается. Однако известно, что беспроводные линии связи испытывают спорадические и обычно временные потери из-за замираний, затенения, переключения, помех и других радиоэффектов, которые не являются строго перегрузкой. После (ошибочного) уменьшения размера окна перегрузки из-за потери беспроводных пакетов может возникнуть фаза предотвращения перегрузки с консервативным уменьшением размера окна. Это приводит к недостаточному использованию радиосвязи. Были проведены обширные исследования по борьбе с этими вредными последствиями. Предлагаемые решения можно разделить на комплексные решения, требующие внесения изменений на клиенте или сервере, [112] решения канального уровня, такие как протокол радиосвязи ( RLP ) в сотовых сетях, или решения на основе прокси, требующие некоторых изменений. в сети без изменения конечных узлов. [112] [113]
Для решения проблемы беспроводной связи был предложен ряд альтернативных алгоритмов контроля перегрузки, таких как Vegas , Westwood , Veno и Santa Cruz. [ нужна цитата ]
Идея TCP-ускорителя состоит в том, чтобы завершить TCP-соединения внутри сетевого процессора и затем передать данные на второе соединение к конечной системе. Пакеты данных, исходящие от отправителя, буферизуются на узле-ускорителе, который отвечает за выполнение локальной повторной передачи в случае потери пакета. Таким образом, в случае потерь контур обратной связи между отправителем и получателем сокращается до контура между узлом ускорения и получателем, что гарантирует более быструю доставку данных получателю.
Поскольку TCP является протоколом, адаптирующимся к скорости, скорость, с которой отправитель TCP вводит пакеты в сеть, прямо пропорциональна преобладающему состоянию нагрузки в сети, а также вычислительной мощности получателя. О преобладающих условиях в сети отправитель судит на основании полученных им подтверждений. Узел ускорения разделяет контур обратной связи между отправителем и получателем и, таким образом, гарантирует более короткое время прохождения туда и обратно (RTT) для каждого пакета. Более короткий RTT выгоден, поскольку обеспечивает более быстрое время реакции на любые изменения в сети и более быструю адаптацию отправителя для борьбы с этими изменениями.
К недостаткам метода можно отнести тот факт, что TCP-сессия должна проходить через ускоритель; это означает, что если маршрутизация изменится и ускорителя больше не будет на пути, соединение будет разорвано. Это также разрушает сквозное свойство механизма подтверждения TCP; когда подтверждение получено отправителем, пакет был сохранен ускорителем, а не доставлен получателю.
Анализатор пакетов , который перехватывает TCP-трафик по сетевому каналу, может быть полезен при отладке сетей, сетевых стеков и приложений, использующих TCP, показывая пользователю, какие пакеты проходят по каналу. Некоторые сетевые стеки поддерживают опцию сокета SO_DEBUG, которую можно включить в сокете с помощью setsockopt. Эта опция сбрасывает все пакеты, состояния TCP и события в этом сокете, что полезно при отладке. Netstat — еще одна утилита, которую можно использовать для отладки.
Для многих приложений TCP не подходит. Одна из проблем (по крайней мере, в обычных реализациях) заключается в том, что приложение не может получить доступ к пакетам, идущим после потерянного пакета, до тех пор, пока не будет получена повторно переданная копия потерянного пакета. Это вызывает проблемы для приложений реального времени, таких как потоковое мультимедиа, многопользовательские игры в реальном времени и передача голоса по IP (VoIP), где обычно полезнее получать большую часть данных своевременно, чем получать все данные. чтобы.
По историческим причинам и из соображений производительности большинство сетей хранения данных (SAN) используют протокол Fibre Channel (FCP) поверх соединений Fibre Channel .
Кроме того, для встроенных систем , сетевой загрузки и серверов, которые обслуживают простые запросы от огромного количества клиентов (например, DNS- серверов), сложность TCP может стать проблемой. Наконец, некоторые трюки, такие как передача данных между двумя хостами, которые оба находятся за NAT (с использованием STUN или аналогичных систем), намного проще без использования относительно сложного протокола, такого как TCP.
Обычно там, где TCP не подходит, используется протокол пользовательских дейтаграмм (UDP). Это обеспечивает мультиплексирование приложений и контрольные суммы, которые выполняет TCP, но не обрабатывает потоки или повторную передачу, что дает разработчику приложения возможность кодировать их способом, подходящим для конкретной ситуации, или заменять их другими методами, такими как упреждающее исправление ошибок или интерполяция .
Протокол передачи управления потоком (SCTP) — это еще один протокол, который предоставляет надежные потоко-ориентированные услуги, аналогичные TCP. Он новее и значительно сложнее TCP, и еще не получил широкого распространения. Однако он специально разработан для использования в ситуациях, когда важны надежность и оперативность, близкая к реальному времени.
Транспортный протокол Вентури (VTP) — это запатентованный собственный протокол , предназначенный для прозрачной замены TCP и устранения предполагаемой неэффективности, связанной с беспроводной передачей данных.
TCP также имеет проблемы в средах с высокой пропускной способностью. Алгоритм предотвращения перегрузки TCP очень хорошо работает в специальных средах, где отправитель данных заранее неизвестен. Если среда предсказуема, протокол на основе синхронизации, такой как асинхронный режим передачи (ATM), может избежать накладных расходов на повторную передачу TCP.
Протокол передачи данных (UDT) на основе UDP имеет более высокую эффективность и справедливость, чем TCP, в сетях с высокой задержкой полосы пропускания . [114]
Многоцелевой протокол транзакций (MTP/IP) — это запатентованное программное обеспечение, предназначенное для адаптивного достижения высокой пропускной способности и производительности транзакций в самых разных сетевых условиях, особенно в тех, где TCP считается неэффективным.
Когда TCP работает через IPv4 , метод, используемый для вычисления контрольной суммы, определяется следующим образом: [9]
Поле контрольной суммы представляет собой 16-битное дополнение суммы всех 16-битных слов в заголовке и тексте. Вычисление контрольной суммы должно гарантировать 16-битное выравнивание суммируемых данных. Если сегмент содержит нечетное количество октетов заголовка и текста, выравнивания можно добиться, дополнив последний октет нулями справа, чтобы сформировать 16-битное слово для целей контрольной суммы. Контактная площадка не передается как часть сегмента. При вычислении контрольной суммы само поле контрольной суммы заменяется нулями.
Другими словами, после соответствующего заполнения все 16-битные слова добавляются с использованием арифметики дополнения до единиц . Затем сумма побитово дополняется и вставляется в качестве поля контрольной суммы. Псевдозаголовок, имитирующий заголовок пакета IPv4, используемый при вычислении контрольной суммы, показан в таблице ниже.
Адреса источника и назначения соответствуют заголовкам IPv4. Значение протокола для TCP равно 6 (см. Список номеров протоколов IP ). Поле длины TCP — это длина заголовка TCP и данных (измеряется в октетах).
Когда TCP работает через IPv6 , метод, используемый для вычисления контрольной суммы, изменяется: [115]
Любой транспортный или другой протокол верхнего уровня, который включает адреса из заголовка IP в расчет контрольной суммы, должен быть изменен для использования через IPv6, чтобы включать 128-битные адреса IPv6 вместо 32-битных адресов IPv4.
Псевдозаголовок, имитирующий заголовок IPv6 для вычисления контрольной суммы, показан ниже.
Многие реализации программного стека TCP/IP предоставляют возможности использования аппаратной помощи для автоматического вычисления контрольной суммы в сетевом адаптере перед передачей в сеть или после приема из сети для проверки. Это может избавить ОС от использования драгоценных циклов ЦП для расчета контрольной суммы. Следовательно, общая производительность сети увеличивается.
Эта функция может привести к тому, что анализаторы пакетов , которые не знают или не уверены в использовании разгрузки контрольной суммы, будут сообщать о неверных контрольных суммах в исходящих пакетах, которые еще не достигли сетевого адаптера. [116] Это произойдет только для пакетов, которые перехватываются перед передачей сетевым адаптером; все пакеты, передаваемые сетевым адаптером по сети, будут иметь действительные контрольные суммы. [117] Эта проблема также может возникнуть при мониторинге пакетов, передаваемых между виртуальными машинами на одном и том же хосте, когда драйвер виртуального устройства может опустить вычисление контрольной суммы (в качестве оптимизации), зная, что контрольная сумма будет вычислена позже ядром хоста виртуальной машины. или его физическое оборудование.
{{cite book}}: CS1 maint: location missing publisher (link){{cite book}}: |journal=игнорируется ( помощь ){{cite web}}: CS1 maint: bot: original URL status unknown (link){{cite book}}: |journal=игнорируется ( помощь )Wireshark перехватывает пакеты перед их отправкой сетевому адаптеру. Он не увидит правильную контрольную сумму, поскольку она еще не рассчитана. Хуже того, большинство ОС не утруждают себя инициализацией этих данных, поэтому вы, вероятно, видите небольшие участки памяти, которых не должно быть. Новые установки Wireshark 1.2 и более поздних версий по умолчанию отключают проверку контрольной суммы IP, TCP и UDP. При необходимости вы можете вручную отключить проверку контрольной суммы в каждом из этих анализаторов.
Выгрузка контрольной суммы часто вызывает путаницу, поскольку передаваемые сетевые пакеты передаются в Wireshark до фактического расчета контрольных сумм. Wireshark получает эти «пустые» контрольные суммы и отображает их как недействительные, даже если пакеты будут содержать действительные контрольные суммы, когда они покинут сетевое оборудование позже.
