Оптимизация операции открытия протокола через открытие TCP-соединения

Question

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

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

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

Сравнение общего протокола и протокола DITP http://www.disnetwork.info/uploads/3/8/0/1/38014/705893.png?490x241

Вы можете прочитать следующую заметку в блоге для более подробного объяснения. http://www.disnetwork.info/1/post/2008/08/optimizing-ditp-connection-open.html

У меня было два вопроса к специалистам по сетевому программированию StackOverflow:

1. Это предположение верно?

2. Почему обычные протоколы не используют это?

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

РЕДАКТИРОВАТЬ: Ой большая ошибка. HTTP использует оптимизированный метод, когда клиент отправляет запрос напрямую. Транзакция приветствия отсутствует, как в случае SMTP. См. Википедия Протокол передачи гипертекста Страница.

Answer 1

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

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

Answer 2

Это не сделано в значительной степени потому что:

a.) Клиенту может понадобиться узнать, какую версию протокола использует сервер

b.) Вы даже не узнаете, что действительно разговариваете с сервером, поддерживающим протокол.

Короче говоря, часто имеет смысл знать, о чем вы говорите, прежде чем извергать в него данные.

Answer 3

1. Теоретически , это правильно.
2. Обычные протоколы не используют это, потому что это неэффективно. Клиенту придется разделить потоки данных, чтобы они были различимы. Сервер должен был бы позаботиться об этом, например, упаковав каждый фрагмент данных в контейнер (XML, JSON, Bitorrent-подобный, Вы называете это). А контейнер - это просто ненужные накладные расходы, замедляющие передачу.

Почему нельзя просто открыть несколько сокетов TCP и отправить отдельные запросы по этим нескольким соединениям? Никаких накладных расходов здесь! О, это уже делается, например некоторыми современными веб-браузерами. Используйте wireshark или tcpdump для проверки пакетов и убедитесь сами.

Это нечто большее. Для установки сокета TCP требуется время (SYN, некоторое время, SYN + ACK, некоторое время, ACK ...). Кто-то считал, что сбрасывать соединение после каждого запроса - пустая трата времени, поэтому некоторые современные HTTP-серверы и клиенты используют Connection: keep-alive, чтобы указать, что они хотят повторно использовать соединение.

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

Answer 4

Целями разработки протоколов, таких как HTTP, SMTP, были не скорость, а надежность в условиях нестабильной физической сети и скудное использование полосы пропускания. В значительной степени эти условия изменились сейчас с улучшением оборудования.

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

Answer 5

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

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