Птс в: Что такое ПТС — зачем и кто выдает, как выглядит дубликат

Стек TCP / IP — это модель, которая представляет, как данные организованы и обмениваются по сети с использованием протокола TCP / IP. Он изображает серию уровней, которые представляют способ обработки и упаковки данных с помощью ряда протоколов, когда они проходят от клиента к серверу и наоборот.

Как и модель OSI, стек представляет собой концептуальную модель для стандартов обмена данными, где данные переупаковываются на каждом уровне в зависимости от его функциональности и транспортных протоколов.

Разница между двумя моделями заключается в уровне специфичности. Модель OSI — это более абстрактное представление способа обмена данными, не зависящее от какого-либо протокола. Это структура для общих сетевых систем. Стек TCP / IP более конкретен и состоит из доминирующего набора протоколов, используемых для обмена данными. OSI является абстрактным и более функциональным, тогда как стек TCP / IP конкретен и основан на протоколе. Модель OSI имеет семь уровней, тогда как модель TCP / IP — только четыре.

Запросы поступают на сервер через стек, начиная с уровня приложения в виде данных. Оттуда информация разбивается на пакеты разных типов на каждом уровне. Данных перемещается:

• из приложения на транспортный уровень, где он сортируется по сегментам TCP;
• на уровень Интернета, где он становится дейтаграммой ;
• на уровень сетевого интерфейса, где он снова разбивается на биты и кадры; и
• , наконец, сервер отвечает, и информация проходит вверх по стеку, чтобы попасть на уровень приложения в виде данных.

TCP существует на транспортном уровне с другими протоколами, такими как UDP. Протоколы на этом уровне обеспечивают безошибочную передачу данных источнику, за исключением UDP, поскольку он имеет более ограниченные возможности проверки ошибок. Заголовок дейтаграммы UDP содержит гораздо меньше информации, чем заголовок сегмента TCP, и подвергается гораздо меньшей обработке на транспортном уровне в интересах уменьшения задержки.

TCP против HTTP: объяснения определений и различий

Вы, наверное, слышали о TCP и, возможно, знаете, что он имеет какое-то отношение к отправке и получению информации через Интернет.Вы, несомненно, видели HTTP перед URL-адресами почти каждый раз, когда они появляются в вашем веб-браузере.

Но когда дело доходит до понимания того, как эти два протокола взаимодействуют, а также той роли, которую они играют в общей головоломке передачи данных, все может запутаться. Давайте разберемся, что такое TCP и HTTP, что их отличает и как они работают вместе.

Что такое TCP?

Потоковая передача данных от источника к месту назначения разделяется на блоки, известные как «пакеты», для более управляемой передачи.Всякий раз, когда вы отправляете или получаете пакет данных, появляется масса информации об этих данных. Сюда входит информация, добавленная протоколом управления передачей или TCP.

TCP — гарантировать, что все данные, отправляемые в потоке, перемещаются из точки A в точку B в правильном порядке и без изменений. Такие протоколы, как TCP, сообщают конечному компьютеру, какое приложение должно получать указанные данные. TCP, в частности, жертвует чистой скоростью, чтобы гарантировать надежность передаваемых данных. Обратите внимание, что некоторые формы передачи данных, такие как потоковое видео, где идеальная точность имеет гораздо меньшее значение, чем скорость, лучше использовать разные протоколы, которые оптимизируют скорость, а не точность.

Передача пакетов, если ее оставить на собственное усмотрение, не будет полностью надежной. Вот почему TCP использует метод, известный как положительное подтверждение с повторной передачей, требующий от принимающей стороны передачи ответа о том, какие данные были получены. Благодаря этому отправитель знает, какие пакеты отправлять дальше или, возможно, повторно отправить, чтобы поддерживать безупречный поток данных. Таким образом, отправленные байты могут точно соответствовать полученным байтам. Никакие данные не изменяются и не теряются в процессе.

Если вы хотите узнать больше о том, как работает этот процесс проверки, щелкните здесь.

Что такое HTTP?

В то время как TCP содержит информацию о том, какие данные были или еще не получены, HTTP содержит конкретные инструкции о том, как читать и обрабатывать эти данные после их поступления. Перед тем, как данные будут отправлены с одного узла Интернета на другой, они упаковываются в информацию, подробно описывающую характер отправляемого запроса или ответ на указанный запрос. Это делается с помощью HTTP или протокола передачи гипертекста.

Когда вы вводите URL-адрес в свой веб-браузер, вы отправляете HTTP-запрос на веб-сервер. Затем этот сервер ответит, снова используя форматирование HTTP. (Если вам интересно узнать о HTTPS, который вы могли заметить на самых популярных в наши дни сайтах, буква «S» означает «безопасный» — это означает, что эти пакеты зашифрованы.)

Двумя наиболее распространенными примерами HTTP-запросов являются: 1. «POST», означающий, что он содержит данные, которые должны быть отправлены на сервер. 2. «GET», запрос на выборку ресурса с сервера

Итак: TCP управляет потоком данных, а HTTP описывает, что данные в этом потоке содержат.

TCP против HTTP: Семислойный лук

Огры подобны луку; пакеты данных тоже.

HTTP расположен на уровне 7 модели взаимодействия открытых систем (модель OSI), также известном как самый внутренний и вызывающий слезы кусочек луковицы. TCP находится на L4. Вы также можете думать об этом как об уровнях абстракции от самих данных, содержащихся в пакете. L1, физический уровень, представляет собой осязаемые электрические сигналы (или, возможно, радиосигналы или другой физический носитель), в которые данные преобразуются для передачи.Таким образом, L1 — самый дальний уровень от внутренних данных.

Почему существуют эти отдельные слои? Скажем, например, что данные поступают с веб-сервера на наш компьютер для загрузки веб-сайта. Наш компьютер улавливает физическое электричество, которое в некотором смысле «оборачивает» пакет нематериальных данных для транспортировки. По мере продвижения к L4 без TCP компьютер не знал бы, в какое приложение направить пакет. Здесь TCP может указать компьютеру направить пакет в наш веб-браузер.

В приложении, таком как Firefox или Chrome, читаются инструкции HTTP. Браузер узнает природу входящих данных и, наконец, может правильно загружать содержимое веб-страницы.

Итак, распутывающие слои действуют как сборочная линия, работая последовательно, чтобы привести исходные материалы в пакете данных в пригодное для использования состояние.

Улучшение использования Интернет-протоколов также улучшает опыт пользователей. Ознакомьтесь с нашим техническим документом о том, как оптимизировать производительность TCP, и получите множество ценных советов!

TCP: Как работает протокол управления передачей

Отдельные компоненты или поля заголовка протокола TCP имеют следующее значение:

Порт источника (16 бит): определяет номер порта отправителя.

Порт назначения (16 бит): определяет номер порта приемника.

Порядковый номер (32 бита): порядковый номер указывает первый байт прикрепленных данных полезной нагрузки или отправляется при установлении или завершении соединения. Он также используется для проверки и сортировки сегментов после передачи.

Номер подтверждения (32 бита): это поле содержит следующий порядковый номер, который ожидает отправитель. Флаг ACK (в поле «Флаги») является предварительным условием действительности.

Смещение (4 бита): поле «Смещение» указывает длину заголовка TCP в 32-битных словах, чтобы выделить начальную точку данных полезной нагрузки. Эта начальная точка варьируется от сегмента к сегменту из-за переменной поля «Параметры».

Зарезервировано (6 бит): Зарезервировано для будущего использования в соответствии с RFC 793 и еще не используется. В этом поле всегда должно быть установлено значение 0.

Flags (6 бит): шесть возможных одиночных битов в поле «Flags» разрешают различные действия TCP для организации связи и обработки данных.Следующие флаги либо установлены, либо не установлены для этих действий:

• URG : Флаг «Срочно» сигнализирует приложению TCP, что данные полезной нагрузки должны быть обработаны немедленно до установленного указателя Срочно (см. Выше).
• ACK : В сочетании с номером подтверждения флаг ACK подтверждает получение пакетов TCP. Если флаг не установлен, номер подтверждения также недействителен.
• PSH : Флаг «Push» гарантирует, что сегмент TCP будет немедленно пропущен без предварительной отправки в буфер отправителя и получателя.
• RST : Если во время передачи произошла ошибка, для сброса соединения можно использовать пакет TCP с установленным флагом RST.
• SYN : сообщения с установленным флагом SYN представляют собой первый шаг трехстороннего рукопожатия, то есть инициируют соединение.
• FIN : Флаг «Готово» сигнализирует другой стороне, что отправитель завершает передачу.

Размер окна (16 бит): в этом поле указывается количество байтов, которое отправитель желает получить.

Контрольная сумма (16 бит): протокол управления передачей может надежно обнаруживать ошибки передачи. Для этой цели используется контрольная сумма, вычисленная из заголовка, данных полезной нагрузки и псевдозаголовка.

Указатель срочности (16 бит): указатель срочности указывает позицию первого байта после данных полезной нагрузки, который должен быть срочно обработан. В результате это поле действительно и актуально, только если установлен флаг URG.

Параметры (0–320 бит): используйте поле Параметры, если вы хотите включить функции TCP, которые не входят в общий заголовок, например, если вы хотите определить максимальный размер сегмента.Длина параметров всегда должна быть кратна 32, в противном случае требуется заполнение нулями.

Что такое TCP | Структура заголовка для DDoS-соединения

Что такое протокол управления передачей (TCP)

Протокол управления передачей (TCP) — это интернет-стандарт, обеспечивающий успешный обмен пакетами данных между устройствами по сети. TCP является основным протоколом связи для широкого спектра приложений, включая веб-серверы и веб-сайты, приложения электронной почты, FTP и одноранговые приложения.

TCP работает с интернет-протоколом (IP), чтобы указать способ обмена данными в сети. IP отвечает за отправку каждого пакета по назначению, в то время как TCP гарантирует, что байты передаются в том порядке, в котором они были отправлены, без ошибок или пропусков. Вместе эти два протокола называются TCP / IP.

Установление TCP-соединения: трехстороннее рукопожатие

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

1. Клиент отправляет серверу SYN-пакет — запрос на соединение от порта источника к порту назначения сервера.
2. Сервер отвечает пакетом SYN / ACK, подтверждая получение запроса на соединение.
3. Клиент получает пакет SYN / ACK и отвечает собственным пакетом ACK.

После установления соединения TCP разбивает передаваемые данные на сегменты, каждый из которых упаковывается в дейтаграмму и отправляется по назначению.

Структура заголовка TCP

TCP оборачивает каждый пакет данных заголовком, содержащим 10 обязательных полей общим размером 20 байтов (или октетов). Каждый заголовок содержит информацию о соединении и текущих отправляемых данных.

Ниже приведены 10 полей заголовка TCP:

1. Порт источника — Порт отправляющего устройства.
2. Порт назначения — Порт принимающего устройства.
3. Порядковый номер — устройство, инициирующее TCP-соединение, должно выбрать случайный начальный порядковый номер, который затем увеличивается в соответствии с количеством переданных байтов.
4. Номер подтверждения — Принимающее устройство поддерживает номер подтверждения, начинающийся с нуля. Он увеличивает это число в соответствии с количеством полученных байтов.
5. Смещение данных TCP — определяет размер заголовка TCP, выраженный 32-битными словами.Одно слово представляет четыре байта.
6. Зарезервированные данные — Зарезервированное поле всегда равно нулю.
7. Управляющие флаги — TCP использует девять управляющих флагов для управления потоком данных в определенных ситуациях, таких как инициация сброса.
8. Размер окна Контрольная сумма TCP — Отправитель генерирует контрольную сумму и передает ее в каждом заголовке пакета. Принимающее устройство может использовать контрольную сумму для проверки ошибок в полученном заголовке и полезной нагрузке.
9. Указатель срочности — Если установлен флаг управления URG, это значение указывает смещение от порядкового номера, указывая на последний байт срочных данных.
10. Дополнительные данные mTCP — Это необязательные поля для установки максимальных размеров сегмента, выборочных подтверждений и включения масштабирования окна для более эффективного использования сетей с высокой пропускной способностью.

Уязвимости TCP DDoS и методы устранения

TCP уязвим для нескольких типов DDoS-атак, в том числе:

SYN флуд

SYN-лавина происходит на начальном этапе трехстороннего рукопожатия, когда запросы TCP-соединения (SYN-пакеты) отправляются на каждый порт целевой машины быстрее, чем она может обрабатывать запросы.Сервер пытается обработать фальшивые SYN-запросы злоумышленника и перестает отвечать на легитимные TCP-запросы, не позволяя завершить рукопожатие.

Развитие атаки SYN flood.

Это заставляет целевую машину исчерпать все свои доступные порты. Во многих случаях пакеты SYN являются полезной нагрузкой и используются просто для насыщения сетевого канала цели.

Есть несколько способов смягчить последствия SYN-флуда, в том числе:

1. Микроблоки — Сервер выделяет микрозапись в своей памяти для каждого запроса SYN вместо полного объекта соединения, тем самым снижая потенциальную нагрузку на ресурсы из-за слишком большого количества запросов.
2. Файлы cookie SYN — Сервер использует криптографическое хеширование для проверки запроса TCP перед выделением памяти.
3. Файлы cookie RST — Сервер намеренно отправляет неверный ответ после первоначального запроса SYN. Если клиент является легитимным, сервер получает пакет RST, сообщающий серверу, что что-то не так.
4. Настройка стека TCP — Вы можете уменьшить время ожидания для освобождения памяти, выделенной для соединения, или выборочно отбрасывать входящие соединения.

Обратите внимание, что в дополнение к «классическому» методу атаки SYN flood, многие злоумышленники DDoS используют поддельные полезные данные SYN для организации общих атак сетевого уровня — тип, который просто нацелен на перегрузку сети с перегрузкой поддельных пакетов. Для смягчения этих атак требуется возможность масштабирования сетевых ресурсов по запросу, например, с помощью облачного решения для смягчения последствий.

STOMP DDoS-атака

STOMP — это текстовый протокол, который позволяет приложениям взаимодействовать с брокерами сообщений с помощью TCP.В DDoS-атаке STOMP злоумышленники используют ботнет для открытия большого количества TCP-рукопожатий с приложениями. Затем злоумышленники отправляют нежелательные данные, замаскированные под STOMP TCP-запросы, насыщая сеть. Если сервер подготовлен к синтаксическому анализу запросов STOMP, атака также может исчерпать ресурсы сервера.

Фрагментация TCP (слеза)

Атака «слезинка» — это тип атаки с фрагментацией IP, нацеленный на механизм повторной сборки TCP / IP, происходящий после завершения трехстороннего рукопожатия и передачи данных.Злоумышленник намеренно отправляет пакеты данных с дефектными полями смещения сегмента, что мешает получателю правильно собрать фрагментированные данные. Пакеты данных перекрываются и быстро перегружают серверы жертвы.

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

Узнайте, как Imperva DDoS Protection может помочь вам в борьбе с DDoS-атаками TCP.

Защита от DDoS-атак TCP

Imperva позволяет масштабировать сетевые ресурсы, обеспечивая поглощение TCP-атак любого размера. Наши специализированные решения для многотерабитной очистки используют глубокую проверку пакетов (DPI) для выявления и блокировки вредоносного трафика до того, как он достигнет вашего сервера.

Служба может быть развернута с помощью перенаправления на основе BGP или DNS, в качестве решения всегда или по требованию.

Сеть 101: Строительные блоки TCP Сеть (O’Reilly)

В начале 1984 года Джон Нэгл задокументировал состояние, известное как «перегрузка». коллапс «, который может повлиять на любую сеть с асимметричной пропускной способностью. емкость между узлами сети:

В отчете сделан вывод, что коллапс заторов еще не стал проблема для ARPANET, потому что большинство узлов имеют одинаковую пропускную способность, а магистраль имела значительную избыточную пропускную способность.Однако ни один из этих утверждения оставались верными долгое время. В 1986 году, когда число (5000+) и количество узлов в сети росло, серия коллапсов перегрузки инциденты охватили всю сеть — в некоторых случаях пропускная способность упало в 1000 раз, и сеть пришла в негодность.

Для решения этих проблем в TCP было реализовано несколько механизмов. для управления скоростью, с которой данные могут отправляться в обоих направлениях: контроль потока, контроль перегрузки и предотвращение перегрузки.

§Поток Контроль

Контроль потока — это механизм, предотвращающий перегрузку отправителя получатель с данными, которые он не может обработать — получатель может быть занятым, находящимся под большой нагрузкой, или может быть готов выделить только фиксированный объем буферного пространства. Чтобы решить эту проблему, каждая сторона TCP соединение объявляет (рис. 2-2) свое собственное окно приема (rwnd), которое сообщает размер доступного буферного пространства для хранения входящие данные.

Когда соединение устанавливается, обе стороны инициируют свои rwnd значения, используя их системные настройки по умолчанию. Типичная веб-страница будет передавать большую часть данных с сервера клиенту, сделать окно клиента вероятным узким местом. Однако если клиент передает большие объемы данных на сервер, например, в случае изображения или загрузки видео, тогда окно приема сервера может становятся ограничивающим фактором.

Если по какой-либо причине одна из сторон не может поспеть, то она может рекламировать отправителю меньшее окно. Если окно достигает ноль, то это рассматривается как сигнал о том, что больше не нужно отправлять данные пока существующие данные в буфере не будут очищены прикладной уровень. Этот рабочий процесс продолжается на протяжении всего срока службы каждое TCP-соединение: каждый пакет ACK содержит последнее значение rwnd для с каждой стороны, что позволяет обеим сторонам динамически регулировать скорость потока данных емкости и скорости обработки отправителя и получателя.Рисунок 2-2. Размер окна приема (rwnd) Реклама

§Масштабирование окна (RFC 1323)

Исходная спецификация TCP выделяла 16 бит для рекламы размер окна приема, который устанавливает жесткую верхнюю границу максимальное значение (2 ¹⁶ или 65 535 байт), которое может быть рекламируется отправителем и получателем. Оказывается, эта верхняя граница равна часто недостаточно для достижения оптимальной производительности, особенно в сетях которые демонстрируют продукт задержки с высокой пропускной способностью; больше об этом можно найти Продукт задержки полосы пропускания.

Чтобы решить эту проблему, RFC 1323 был разработан, чтобы предоставить «окно TCP масштабирование », которая позволяет увеличить максимальное окно приема размер от 65 535 байт до 1 гигабайта! Параметр масштабирования окна передается во время трехстороннего рукопожатия и имеет значение, которое представляет количество бит, чтобы сдвинуть влево размер 16-битного окна поле в будущих ACK.

Сегодня масштабирование окна TCP включено по умолчанию на всех основных платформы.Однако промежуточные узлы, маршрутизаторы и брандмауэры могут перепишите или даже полностью удалите эту опцию. Если ваше подключение к сервер или клиент не могут в полной мере использовать доступные пропускной способности, то проверка взаимодействия размеров ваших окон всегда хорошее место для начала. На платформах Linux масштабирование окна настройку можно проверить и включить с помощью следующих команд:

§Медленный старт

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

Чтобы проиллюстрировать один пример, когда такая адаптация полезна, представьте, что вы дома и смотрите потоковую передачу большого видео с пульта сервер, который сумел насытить ваш нисходящий канал, чтобы обеспечить максимальную качественный опыт.Затем другой пользователь в вашей домашней сети открывает новый подключение для загрузки некоторых обновлений программного обеспечения. Внезапно объем доступной полосы пропускания нисходящего канала для видеопотока очень велик меньше, и видеосервер должен настроить свою скорость передачи данных — в противном случае, если он продолжается с той же скоростью, данные просто накапливаются в некоторых промежуточный шлюз и пакеты будут отброшены, что приведет к неэффективное использование сети.

В 1988 году Ван Якобсон и Майкл Дж.Карелы задокументировали несколько алгоритмы для решения этих проблем: медленный старт, предотвращение перегрузки, быстрая ретрансляция и быстрое восстановление. Все четыре быстро стали обязательными часть спецификации TCP. На самом деле, широко распространено мнение, что это было эти обновления TCP, которые предотвратили обвал Интернета в 80-х и в начале 90-х, когда трафик продолжал расти в геометрической прогрессии. показатель.

Чтобы понять медленный старт, лучше всего увидеть его в действии.Итак, однажды Еще раз вернемся к нашему клиенту, который находится в Нью-Йорке, пытается получить файл с сервера в Лондоне. Во-первых, выполняется трехстороннее рукопожатие, во время которого обе стороны рекламируют их соответствующие размеры окна приема (rwnd) в пакетах ACK (Рисунок 2-2). Однажды заключительный пакет ACK помещается на провод, мы можем начать обмен Данные приложений.

Единственный способ оценить доступную емкость между клиентами и сервер должен измерить это путем обмена данными, и это именно для чего предназначен медленный старт.Для начала сервер инициализирует новую переменную окна перегрузки (cwnd) для каждого TCP-соединения и устанавливает его начальное значение на консервативное, заданное системой значение (initcwnd в Linux).

Размер окна перегрузки (cwnd)

Ограничение на стороне отправителя на объем данных, которые отправитель может иметь в полет до получения подтверждения (ACK) от клиента.

Переменная cwnd не объявляется и не обменивается между отправителем и получатель — в этом случае это будет частная переменная, поддерживаемая сервером в Лондоне.Далее вводится новое правило: максимум количество данных в пути (не подтвержденных) между клиентом и сервером — это минимум переменных rwnd и cwnd. Пока все хорошо, но как определяют ли сервер и клиент оптимальные значения для своих размеры окна скопления? В конце концов, сетевые условия меняются на все время, даже между теми же двумя сетевыми узлами, как мы видели ранее пример, и было бы здорово, если бы мы могли использовать алгоритм без необходимость вручную настраивать размеры окон для каждого соединения.

Решение — начать медленно и увеличивать размер окна по мере того, как пакеты подтверждаются: медленный старт! Первоначально начальное значение cwnd был установлен на 1 сегмент сети; RFC 2581 обновил это значение до 4 сегментов. в апреле 1999 г .; совсем недавно значение было увеличено еще раз до 10 сегментов по RFC 6928 в апреле 2013 г.

Максимальный объем передаваемых данных для нового TCP-соединения — это минимум значений rwnd и cwnd; следовательно, современный сервер может отправлять клиенту до десяти сетевых сегментов, после чего он должен остановиться и ждать подтверждения.Затем для каждого полученного ACK алгоритм медленного старта указывает, что сервер может увеличивать свой cwnd размер окна на один сегмент — для каждого ACKed пакета два новых пакета можно отправить. Эта фаза TCP-соединения широко известна как алгоритм «экспоненциального роста» (рис. 2-3), поскольку клиент и сервер пытается быстро использовать доступную пропускную способность на сетевой путь между ними. Рисунок 2-3. Контроль перегрузки и предотвращение перегрузки

Итак, почему медленный старт — важный фактор, о котором нужно помнить, когда мы создавать приложения для браузера? Ну, HTTP и многое другое протоколы приложений работают через TCP, и независимо от доступных пропускная способность, каждое TCP-соединение должно проходить фазу медленного старта — мы не можем сразу использовать всю емкость ссылки!

Вместо этого мы начинаем с небольшого окна перегрузки и удваиваем его для каждую поездку туда и обратно — i.е., экспоненциальный рост. В результате время требуется для достижения определенной цели пропускной способности, является функцией (Пора достичь размера cwnd размер N) времени двустороннего обмена между клиентом и сервером и начальный размер окна перегрузки.

Пора достичь размера cwnd размера N

В качестве практического примера воздействия медленного старта предположим, что следующий сценарий:

• Окна приема клиента и сервера: 65 535 байт (64 КБ)

• Окно начальной перегрузки: 10 сегментов (RFC 6928)

• Время туда и обратно: 56 мс (из Лондона в Нью-Йорк)

Несмотря на размер окна приема 64 КБ, пропускная способность нового TCP соединение изначально ограничено размером окна перегрузки.Фактически, чтобы достичь предела окна приема в 64 КБ, нам сначала нужно увеличить размер окна перегрузки до 45 сегментов, что займет 168 миллисекунды:

Это три обхода (рис. 2-4) для достижения 64 КБ пропускной способности. между клиентом и сервером! Тот факт, что клиент и сервер могут иметь возможность передачи со скоростью Мбит / с + не влияет на новый соединение установлено — это медленный старт.

В приведенном выше примере используется новое (RFC 6928) значение десять сетей. сегменты для начального окна перегрузки.В качестве упражнения повторите тот же расчет со старым размером четырех сегментов — вы обратите внимание, что это добавит дополнительные 56 миллисекунд туда и обратно к выше результат!

Для уменьшения количества времени, необходимого для увеличения перегрузки окна, мы можем уменьшить время обратного обмена между клиентом и сервер — например, переместите сервер географически ближе к клиенту.Или мы можем увеличить начальный размер окна перегрузки до нового RFC 6928 стоимость 10 сегментов.

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

Однако для многих HTTP-соединений, которые часто короткие и прерывистый, передача данных нередко завершается до достигнут максимальный размер окна.В результате производительность многих веб-приложения часто ограничены временем обратного обмена между серверами и клиент: медленный старт ограничивает доступную пропускную способность, что отрицательно сказывается на выполнении мелких переводов.

§Медленный перезапуск

В дополнение к регулированию скорости передачи новых соединений, TCP также реализует медленный перезапуск (SSR) механизм, который сбрасывает окно перегрузки соединения после он не использовался в течение определенного периода времени.Обоснование просто: условия сети могли измениться во время подключения простаивает, и, чтобы избежать перегрузки, окно сбрасывается до «безопасный» дефолт.

Неудивительно, что SSR может оказывать значительное влияние на производительность долгоживущих TCP-соединений, которые могут простаивать в течение некоторого времени — например, из-за бездействия пользователя. В результате обычно рекомендуется отключить SSR на сервере, чтобы повысить производительность долгоживущих HTTP-соединений.На платформах Linux настройка SSR можно проверить и отключить с помощью следующих команд:

Чтобы проиллюстрировать влияние трехстороннего рукопожатия и фаза медленного старта простой передачи HTTP. Предположим, что наш клиент в Нью-Йорке запрашивает файл размером 64 КБ с сервера в Лондоне более новое TCP-соединение (рис. 2-5) и следующее соединение параметры на месте:

• Время туда и обратно: 56 мс

• Пропускная способность клиента и сервера: 5 Мбит / с

• Окно приема клиента и сервера: 65 535 байт

• Окно начальной перегрузки: 10 сегментов ()

• Время обработки сервером ответа: 40 мс

• Нет потери пакетов, ACK на пакет, запрос GET помещается в один сегмент

0 мс

Клиент начинает квитирование TCP с пакета SYN.

28 мс

Сервер отвечает SYN-ACK и указывает размер rwnd.

56 мс

Клиент подтверждает SYN-ACK, указывает его размер rwnd и немедленно отправляет HTTP-запрос GET.

84 мс

Сервер получает HTTP-запрос.

124 мс

Сервер завершает формирование ответа размером 64 КБ и отправляет 10 TCP сегменты перед приостановкой для ACK (начальный размер cwnd равен 10).

152 мс

Клиент получает 10 сегментов TCP и ACK каждый.

180 мс

Сервер увеличивает свой cwnd для каждого ACK и отправляет 20 TCP сегменты.

208 мс

Клиент получает 20 сегментов TCP и ACK каждый.

236 мс

Сервер увеличивает свой cwnd для каждого ACK и отправляет оставшиеся 15 Сегменты TCP.

264 мс

Клиент получает 15 сегментов TCP, каждый из которых получает подтверждение.

264 мс для передачи файла размером 64 КБ по новому TCP-соединению с 56 мс время обмена между клиентом и сервером! Для сравнения, давайте сейчас предполагаем, что клиент может повторно использовать одно и то же TCP-соединение (Рисунок 2-6) и отправляет тот же запрос еще раз. Рисунок 2-6. Получение файла через существующее TCP-соединение

0 мс

Клиент отправляет HTTP-запрос.

28 мс

Сервер получает HTTP-запрос.

68 мс

Сервер завершает создание ответа размером 64 КБ, но cwnd значение уже превышает 45 сегментов, необходимых для отправки файл; следовательно, он отправляет все сегменты за один пакет.

96 мс

Клиент получает все 45 сегментов, каждый из которых получает ACK.

Тот же запрос, сделанный по тому же соединению, но без затрат трехстороннего рукопожатия и штрафа фазы медленного старта, теперь потребовалось 96 миллисекунд, что означает улучшение на 275% представление!

В обоих случаях тот факт, что и сервер, и клиент доступ к 5 Мбит / с пропускной способности восходящего потока не повлиял на запуск фаза TCP-соединения. Вместо этого задержка и перегрузка размеры окон были ограничивающими факторами.

Фактически разница в производительности между первым и вторым запрос, отправленный через существующее соединение, будет расширяться, только если мы увеличить время поездки туда и обратно; в качестве упражнения попробуйте несколько разные значения. Как только вы разовьете интуицию в механике Контроль перегрузки TCP, десятки оптимизаций, таких как поддержка активности, конвейерная обработка и мультиплексирование не потребуют дополнительной мотивации.

§Увеличение окна начальной загрузки TCP

Увеличение начального размера cwnd на сервере до нового RFC 6928 значение 10 сегментов (IW10) — один из самых простых способов улучшить производительность для всех пользователей и всех приложений, работающих через TCP.И хорошая новость в том, что многие операционные системы уже обновлены. их последние ядра, чтобы использовать увеличенное значение — проверьте соответствующая документация и примечания к выпуску.

Для Linux IW10 является новым значением по умолчанию для всех ядер выше 2.6.39. Однако не останавливайтесь на достигнутом: обновитесь до версии 3.2+, чтобы также воспользоваться преимуществами другие важные обновления; см. Пропорциональное снижение скорости для TCP.

§Предотвращение перегрузки

Важно понимать, что TCP специально разработан для использовать потерю пакетов как механизм обратной связи, чтобы помочь регулировать представление.Другими словами, речь идет не о , а о , а о вместо , когда произойдет потеря пакета . Медленный старт инициализирует соединение с консервативным окном и для каждого туда и обратно, удваивает объем данных в полете, пока он не превысит окно управления потоком получателя, перегрузка, настроенная системой пороговое окно (ssthresh) или до тех пор, пока пакет не будет потерян, после чего алгоритм предотвращения перегрузки (рисунок 2-3) вступает во владение.

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

После сброса окна перегрузки, предотвращение перегрузки указывает собственные алгоритмы увеличения окна, чтобы минимизировать дальнейшие потери.В определенный момент произойдет еще одно событие потери пакета, и процесс повторится еще раз. Если вы когда-нибудь смотрели на пропускную способность отслеживание TCP-соединения и обнаружил в нем пилообразный узор, теперь вы знаете, почему это выглядит так: это контроль перегрузки и алгоритмы предотвращения, регулирующие размер окна перегрузки для учета за потерю пакетов в сети.

Наконец, стоит отметить, что улучшение контроля перегрузки и избегание — активная область как для академических исследований, так и для коммерческих продукты: есть приспособления под разные типы сетей, разные типы передачи данных и так далее.Сегодня, в зависимости от вашей платформы, вы, вероятно, запустите один из множества вариантов: TCP Tahoe и Reno (оригинальные реализации), TCP Vegas, TCP New Reno, TCP BIC, TCP CUBIC (по умолчанию в Linux) или составной TCP (по умолчанию в Windows), среди многих другие. Однако, независимо от вкуса, основная производительность последствия контроля перегрузок и предотвращения перегрузок актуальны для всех.

§Пропорциональное снижение скорости для TCP

Определение оптимального способа восстановления после потери пакетов — это нетривиальное упражнение: если вы слишком агрессивны, то прерывистое потерянный пакет существенно повлияет на пропускную способность всего подключения, и если вы не настроитесь достаточно быстро, вы будете вызвать еще большую потерю пакетов!

Первоначально TCP использовал мультипликативное уменьшение и добавление Алгоритм увеличения (AIMD): при потере пакета уменьшите вдвое размер окна перегрузки, а затем медленно увеличивайте окно на фиксированная сумма за поездку туда и обратно.Однако во многих случаях AIMD слишком консервативны, а значит, были разработаны новые алгоритмы.

Пропорциональное снижение скорости (PRR) — это новый алгоритм, разработанный RFC 6937, целью которого является повышение скорости восстановления, когда пакет потерян. Насколько это лучше? Согласно сделанным измерениям в Google, где был разработан новый алгоритм, он обеспечивает 3–10% уменьшение средней задержки для соединений с потерей пакетов.

PRR теперь является алгоритмом предотвращения перегрузки по умолчанию в Linux. 3.2+ ядра — еще один веский повод обновить серверы!

TCP

Протокол управления передачей, или TCP, как мы будем называть его с этого момента, является одним из наиболее важных и хорошо известных протоколов в сегодняшних сетях. Используемый во всех типах сетей по всему миру, он позволяет миллионам передач данных достигать места назначения и работает как мост, соединяя узлы друг с другом и позволяя им использовать различные программы для обмена данными.

Необходимость надежной доставки

TCP определен в RFC 793 и был представлен миру в конце 1981 года. Мотивом создания такого протокола был тот факт, что еще в начале 80-х годов системы компьютерной связи играли очень важную роль для вооруженных сил и образования. и нормальная офисная среда. Таким образом, возникла необходимость в создании механизма, который бы обеспечивал надежную и полную передачу данных на различных носителях без больших потерь.

TCP был разработан, чтобы обеспечивать все вышеперечисленное, и поэтому он был быстро принят остальным миром.

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

Статья 1: TCP, транспортный протокол . Эта страница представляет собой краткое введение в TCP. Он покажет вам, как TCP вписывается в модель OSI, с помощью простых диаграмм.Это также поможет вам понять концепцию «транспортного протокола».

Статья 2: Краткий обзор TCP . Эта страница предназначена для читателей, которым нужен хороший и быстрый обзор функций протокола, не вдаваясь в технические детали.

Статья 3. Заголовок / сегмент TCP . Узнайте, к чему относятся «Заголовок TCP» и «Сегмент TCP». Эти два термина используются довольно часто, когда говорят о протоколе, поэтому важно, чтобы мы понимали, с чем связаны эти два термина.

Статья 4. Углубленный анализ заголовка TCP: Введение . Этот подраздел представляет собой отдельную тему и посвящен углубленному анализу заголовка TCP. Мы исследуем каждую область шаг за шагом, используя множество примеров и наши хорошо известные 3D-диаграммы, чтобы убедиться, что вы понимаете весь материал. Этот анализ охватывает более 7 страниц жесткой информации, так что будьте готовы!

Статья 5: Углубленный анализ заголовка TCP: Номер порта источника и назначения .Узнайте, что такое порты и как они используются при обычной передаче данных.

Статья 6. Углубленный анализ заголовка TCP: порядковые номера и номера подтверждения . Наконец, все, что вы хотели знать о порядковых номерах и номерах подтверждения. Мы рассмотрим их более подробно, используя множество диаграмм, чтобы у вас не остались вопросы без ответов.

Статья 7: Углубленный анализ заголовка TCP: длина заголовка . Мы исследуем значение этого поля и то, как оно рассчитывается.

Статья 8: Углубленный анализ заголовка TCP: параметры флага TCP . Это одна из самых важных страниц в нашем глубоком анализе. Здесь вы узнаете, что это за флаги, сколько флагов поддерживает протокол и, наконец, как они используются. Мы также рассмотрим, как хакеры могут использовать определенные флаги для получения важной информации об удаленных системах.

Статья 9: Углубленный анализ заголовка TCP: размер окна, контрольная сумма и срочный указатель . Эти поля играют одну из самых важных ролей в использовании полосы пропускания.Узнайте, как можно увеличить пропускную способность и минимизировать задержки между ссылками WAN, поигравшись с этими полями! Эта страница настоятельно рекомендуется всем, кто хочет получить подробную информацию об эффективности канала WAN и пропускной способности данных.

Статья 10. Углубленный анализ заголовка TCP: параметры TCP . Эта страница считается продолжением предыдущей. Здесь вы узнаете о выборочных подтверждениях, масштабировании окон и некоторых других параметрах, доступных для TCP, которые гарантируют, что данные обрабатываются наилучшим образом при их передаче к месту назначения.

Статья 11: Углубленный анализ заголовка TCP: данные TCP . Причина всего вышеперечисленного! В нашем последнем разделе представлен обзор протокола TCP и завершается несколькими полезными замечаниями.

Вы наверняка согласитесь, что в этом фантастическом протоколе есть что рассказать. Итак, не будем терять время и приступим к классному анализу! Если вам нужно перекусить, теперь у вас есть шанс, потому что, как только мы начнем … мы не остановимся, пока мы не закончим!

v. 3: TCP для транзакций, HTTP, NNTP и протоколы домена Unix (серия Addison-Wesley Professional Computing): Стивенс, В.Ричард, Райт, Гэри Р .: 9780201634952: Amazon.com: Книги

Введение и организация книги

Эта книга разделена на три части, каждая из которых посвящена отдельной теме:

TCP для транзакций, обычно называемый T / TCP. Это расширение TCP, призванное сделать транзакции клиент-сервер более быстрыми, эффективными и надежными.Это делается путем исключения трехстороннего подтверждения TCP в начале соединения и сокращения состояния TIME_WAIT в конце соединения. Мы увидим, что T / TCP может соответствовать производительности UDP для транзакции клиент-сервер и что T / TCP обеспечивает надежность и адаптируемость, что является значительным улучшением по сравнению с UDP.

Транзакция определяется как запрос клиента к серверу, за которым следует ответ сервера. (Термин транзакция не означает транзакцию базы данных с блокировкой, двухфазной фиксацией и возвратом.)

Приложения TCP / IP, в частности HTTP (протокол передачи гипертекста, основа всемирной паутины) и NNTP (протокол передачи сетевых новостей, основа системы новостей Usenet).

Протоколы домена Unix. Эти протоколы предоставляются всеми реализациями TCP / IP Unix и многими реализациями, отличными от Unix. Они обеспечивают форму межпроцессного взаимодействия (IPC) и используют тот же интерфейс сокетов, что и TCP / IP. Когда клиент и сервер находятся на одном хосте, протоколы домена Unix часто в два раза быстрее TCP / IP.

Часть 1, презентация T / TCP, состоит из двух частей. В главах 1–4 описан протокол и приведены многочисленные примеры его работы. Этот материал является важным расширением краткой презентации T / TCP в Разделе 24.7 Том 1 . Вторая часть, главы 5–12, описывает фактическую реализацию T / TCP в сетевом коде 4.4BSD-Lite (то есть код, представленный в том 2 ). Поскольку первая реализация T / TCP не была выпущена до сентября 1994 года, примерно через год после публикации Том 1 и сразу после завершения Том 2 , подробное представление T / TCP с примерами и всеми деталями реализации , пришлось ждать еще одного тома из этой серии.

Часть 2, приложения HTTP и NNTP, являются продолжением приложений TCP / IP, представленных в главах 25-30 Том 1 . За два года, прошедшие с момента публикации Том 1 , популярность HTTP сильно выросла, так как Интернет стал взрывным, а использование NNTP росло примерно на 75% в год на протяжении более 10 лет. HTTP также является прекрасным кандидатом для T / TCP, учитывая его типичное использование TCP: короткие соединения с небольшими объемами передаваемых данных, при которых общее время часто определяется установкой и разрывом соединения.Интенсивное использование HTTP (и, следовательно, TCP) на загруженном веб-сервере тысячами разных и разнообразных клиентов также предоставляет уникальную возможность проверить фактические пакеты на сервере (глава 14) и изучить многие функции TCP / IP, которые были представлены в томах 1 и 2 .

Протоколы домена Unix в Части 3 изначально рассматривались для Том 2 , но были опущены, когда его размер достиг 1200 страниц. Хотя может показаться странным рассматривать протоколы, отличные от TCP / IP, в серии под названием TCP / IP Illustrated , протоколы домена Unix были реализованы почти 15 лет назад в 4.2BSD наряду с первой реализацией BSD TCP / IP. Сегодня они широко используются в любом ядре, производном от Беркли, но обычно они используются «под прикрытием», и большинство пользователей не подозревают об их наличии. Помимо того, что она является основой для каналов Unix на ядре, производном от Беркли, еще одним активным пользователем является система X Window, когда клиент и сервер находятся на одном хосте (то есть на типичных рабочих станциях). Доменные сокеты Unix также используются для передачи дескрипторов между процессами, что является мощным методом межпроцессного взаимодействия.Поскольку API-интерфейс сокетов (интерфейс прикладной программы), используемый с протоколами домена Unix, почти идентичен API-интерфейсу сокетов, используемому с TCP / IP, протоколы домена Unix предоставляют простой способ повысить производительность локальных приложений с минимальными изменениями кода.

Каждую из трех частей можно прочитать отдельно.

Читатели

Части 1 и 2 предполагают базовое понимание того, как работают протоколы TCP / IP. Читатели, незнакомые с TCP / IP, должны обратиться к первому тому этой серии, Stevens 1994, для подробного описания набора протоколов TCP / IP. Первую половину части 1 (главы 1-4, концепции, лежащие в основе T / TCP вместе с примерами) можно читать независимо от , том 2 , но оставшуюся часть части 1 (главы 5-12, реализация T / TCP ) предполагает знакомство с сетевым кодом 4.4BSD-Lite, который предоставляется в Том 2 .По всему тексту дается множество прямых и обратных ссылок как на обе темы в этом тексте, так и на соответствующие разделы томов 1 и 2 для читателей, интересующихся более подробной информацией. Предоставляется подробный указатель, и список всех сокращений, используемых по всему тексту, вместе с составным термином для аббревиатуры, появляется на внутренней стороне передней обложки. Внутренние задние обложки содержат перекрестные ссылки в алфавитном порядке всех структур, функций и макросов, описанных в книге, и номер начальной страницы описания.Эта перекрестная ссылка также относится к определениям в Том 2 , когда этот объект ссылается на код в этом томе.

Исходный код Авторские права

Код таблицы маршрутизации в главе 6 содержит следующее уведомление об авторских правах:

Благодарности

Я благодарю технических рецензентов, которые прочитали рукопись и предоставили важные отзывы о жестком графике: Сами Булос, Алан Кокс, Тони Дезимоун, Пит Хейверлок, Крис Хейгэм, Мукеш Какер, Брайан Керниган, Арт Меллор, Джефф Могул, Марианна Мюллер, Андрас Ола, Крейг Партридж, Верн Паксон, Кейт Склоуэр, Ян Лэнс Тейлор и Гэри Райт. Особая благодарность редактору-консультанту Брайану Кернигану за его быстрые, подробные и полезные обзоры на протяжении всей книги, а также за его постоянную поддержку и поддержку.

Особая благодарность также выражается Верну Паксону и Андрасу Олаху за их невероятно подробные обзоры всей рукописи, обнаружение множества ошибок и предоставление ценных технических предложений. Я также благодарен Верну Паксону за предоставление своего программного обеспечения для анализа трассировок Tcpdump и Андрасу Олаху за его помощь с T / TCP за последний год. Я также благодарен Бобу Брейдену, разработчику T / TCP, который предоставил эталонную реализацию исходного кода, на которой основана первая часть этой книги.

Другие существенно помогли. Гэри Райт и Джим Хог представили систему, в которой были собраны данные для главы 14. Дуг Шмидт предоставил копию общедоступной программы TTCP, в которой используются сокеты домена Unix, для измерений времени в главе 16. Крейг Партридж предоставил копию исходного кода RDP для изучения.