Имитация протокола для повышения производительности

Введение

Доброкачественное моделирование протокола

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

Методы подделки

В большинстве случаев применения спуфинга протокола коммуникационное устройство, такое как модем или маршрутизатор, имитирует ("спуфит") удалённую конечную точку соединения с локально подключённым хостом, при этом используя более подходящий протокол для связи с совместимым удалённым устройством, которое выполняет аналогичный спуфинг на другом конце канала связи.

Подделка передачи файлов

Протоколы коррекции ошибок и передачи файлов обычно работают путем вычисления контрольной суммы или CRC для блока данных, известного как пакет, и передачи полученного числа в конце пакета. На другом конце соединения приемник пересчитывает это число на основе полученных данных и сравнивает результат с тем, что было отправлено с удаленной машины. Если оба значения совпадают, пакет был передан правильно, и приемник посылает ACK (подтверждение), чтобы сообщить о готовности принять следующий пакет. Время передачи ACK обратно отправителю зависит от характеристик телефонной линии, а не от скорости модема, и обычно составляет около 1/10 секунды для коротких соединений и может быть значительно больше для линий связи большой протяженности или сетей передачи данных, таких как X.25. Для протокола, использующего небольшие пакеты, эта задержка может превышать время, необходимое для отправки самого пакета. Например, протокол UUCP "g" и Kermit используют пакеты размером 64 байта, отправка которых на линии со скоростью 9600 бит/с занимает около 1/20 секунды. XMODEM использовал немного больший пакет размером 128 байт, отправка которого занимает около 1/10 секунды. Следующий пакет данных не может быть отправлен до получения ACK для предыдущего пакета. В случае XMODEM это означает, что для завершения полного цикла обработки одного пакета требуется минимум 2/10 секунды. Следовательно, общая скорость передачи данных составляет лишь половину теоретического максимума, что соответствует 50% эффективности канала. "Спофинг" протокола решает эту проблему, позволяя локальному модему распознавать факт передачи данных, часто путем поиска заголовков пакетов. Обнаружив их, модем определяет конец пакета, обычно зная количество байтов в пакете. Например, пакет XMODEM содержит 132 байта, включая 128 байтов фактических данных, а также заголовок и контрольную сумму. Как только модем обнаруживает конец пакета, он немедленно отправляет "поддельное" сообщение ACK обратно хосту. Это заставляет локальный компьютер немедленно отправить следующий пакет, избегая задержки, связанной с ожиданием ACK от удаленной машины. Данные для нескольких пакетов хранятся во внутреннем буфере, пока модем отправляет их на удаленную машину. Это позволяет отправлять пакеты непрерывно, значительно повышая эффективность канала. Однако это также требует, чтобы соединение между двумя системами было безошибочным, поскольку модем уже подтверждает пакеты до их фактической отправки. Обычно это решалось с помощью протокола коррекции ошибок на уровне модема, например, сетевых протоколов Microcom. "Спофинг" протокола также широко использовался в сочетании с другой особенностью ранних высокоскоростных модемов. До появления эхоподавления в протоколах V.32 и более поздних, высокоскоростные модемы обычно имели очень медленный "обратный канал" для отправки таких сообщений, как ACK, обратно отправителю. Например, модем TrailBlazer со скоростью ~18 500 бит/с мог отправлять до 35 пакетов UUCP в секунду приемнику, но обратный канал обеспечивал скорость всего 75 бит/с, чего было недостаточно для передачи 35 байтов (280 бит) сообщений ACK, генерируемых удаленным хостом. В этом случае "спофинг" позволял отправляющему модему продолжать отправлять пакеты с максимально возможной скоростью. Одновременно модем на удаленном принимающем конце отбрасывал пакеты ACK, генерируемые программным обеспечением локального компьютера, сохраняя пропускную способность обратного канала. Поскольку эффективность канала стала серьезной проблемой только при скоростях выше 2400 бит/с, а модемы, способные работать быстрее, обычно обладали достаточной вычислительной мощностью, "спофинг" протокола в основном использовался в этих более высокоскоростных системах.

Error correction and file transfer protocols typically work by calculating a checksum or CRC for a block of data known as a packet, and transmitting the resulting number at the end of the packet. At the other end of the connection, the receiver re calculates the number based on the data it received and compares that result to what was sent from the remote machine. If the two match the packet was transmitted correctly, and the receiver sends an ACK to signal that it's ready to receive the next packet. The time to transmit the ACK back to the sender is a function of the phone lines, as opposed to the modem's speed, and is typically about 1/10 of a second on short links and may be much longer on long distance links or data networks like X.25. For a protocol using small packets, this delay can be larger than the time needed to send a packet. For instance, the UUCP "g" protocol and Kermit both use 64 byte packets, which on a 9600 bit/s link takes about 1/20 of a second to send. XMODEM used a slightly larger 128 byte packet, which takes about 1/10 of a second to send. The next packet of data cannot be sent until the ACK for the previous packet is received. In the case of XMODEM, for instance, that means it takes a minimum of 2/10 of a second for the entire cycle to complete for a single packet. This means that the overall speed is only half the theoretical maximum, a 50% channel efficiency. Protocol spoofing addresses this problem by having the local modem recognize that a data transfer is underway, often by looking for packet headers. When these are seen, the modem then looks for the end of the packet, normally by knowing the number of bytes in a single packet. XMODEM, for instance, has 132 bytes in a packet due to the header and checksum being added to the 128 bytes of actual data. When the modem sees the packet has ended, it immediately sends of spoofed ACK message back to the host. This causes the local computer to immediately send another packet, avoiding the latency of waiting for an ACK from the remote machine. The data for multiple packets is held in an internal buffer while the modem is sending it to the remote machine. This allows the packets to be sent continually, greatly improving channel efficiency. However, this also requires the link between the two systems to be error free, as the modem has already ACKed the packets even before they have been sent. This was normally addressed by using a modem level error correction protocol, like Microcom Networking Protocols. Protocol spoofing was also widely used with another feature of earlier high speed modems. Before the introduction of echo cancellation in V.32 and later protocols, high speed modems typically had a very slow "backchannel" for sending things like these ACKs back to the sender. On the ~18,500 bit/s TrailBlazer, for instance, the modem could send as many as 35 UUCP packets a second to the receiver, but the backchannel offered only 75 bit/s, not nearly enough for the 35 bytes, 280 bits, of ACK messages generated by the remote host. In this case, the spoofing allowed the sending modem to continue sending packets as fast as it could. At the same time, the modem on the remote receiving end dropped the ACK packets being generated by the local computer's software, keeping the backchannel clear. Since the channel efficiency only became a major problem at speeds over 2400 bit/s, and modems able to run faster than that typically had significant processing power anyway, protocol spoofing was mostly associated with these higher speed systems.

TCP-подделывание

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

Подделка данных в РПП/ППП

SAP и RIP периодически транслируют информацию о сети, даже если таблицы маршрутизации/услуг не изменились. Каналы WAN с выбором номера по требованию в сетях IPX, таким образом, никогда не переходят в неактивное состояние и не отключаются. Злоумышленнический маршрутизатор или модем будет перехватывать широковещательные сообщения SAP и RIP и повторно транслировать объявления из собственной таблицы маршрутизации/услуг, которая обновляется только при активации канала по другим причинам.