Считается ли, что протоколы без сохранения состояния лучше использовать над протоколами с контролем состояния?

Question

Я вижу, что протоколы с отслеживанием состояния приводят к менее испорченному «эмулированному состоянию», как файлы cookie.

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

Считается ли лучшей практикой всегда использовать протоколы без сохранения состояния или это действительно специфично для домена?

Я думаю, что аутентификация становится проще при работе с протоколами с отслеживанием состояния, но есть ли другие причины, по которым вам следует использовать протокол с отслеживанием состояния?

Answer 1

Преимущества лиц без гражданства:

1. Высокая масштабируемость (вы можете отправить запрос на любой узел, вы можете добавить узлы в любое время)
2. Высокая доступность (если один узел выходит из строя, нет потерянного состояния, просто отправьте запрос другому узлу)
3. Высокая скорость (состояние отсутствует, результаты кешируются)

Answer 2

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

Что касается того, когда выбирать, какие из них следует учитывать. Во-первых, хотя варианты реализации либо / или, проблемное пространство является континуумом. У всех задач в реальном мире есть хотя бы небольшое состояние, вопрос в том, сколько их стоит, и стоит ли их преодолевать, стоит того, чтобы отслеживать их с обеих сторон. И второе, вы обычно имеете дело со стеком протоколов, а не с одним протоколом; убедившись, что все живет на должном уровне, можно чрезвычайно упростить вещи.

Answer 3

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

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

Answer 4

Я лично не знаком со всеми проблемами проектирования с сохранением состояния и сохранением состояния, но я знаю, что NFSv4 сохраняет состояние после 15-летней давности предыдущих версий NFS, не имеющих состояния, поэтому, очевидно, отсутствие состояния стало существенным ограничением для Дизайнеры NFS.

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

Answer 5

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

Answer 6

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

Answer 7

Stateful лучше. Тогда вам не нужно отправлять состояние все время. Протокол становится проще.