2016-12-27 8 views
1

Я смотрел на диаграмме здесь:Должен ли конечный автомат спецификации http2 для жизненного цикла потока быть разделен на клиент и сервер?

https://http2.github.io/http2-spec/#StreamStatesFigure

но и по всей документации, серверы отправляют PUSH_PROMISE кадры клиентам не наоборот (по крайней мере, пока). Это означает, что состояние reserved (remote) будет ТОЛЬКО случаться на клиентском программном обеспечении, а состояние reserved (local) будет происходить только на серверном программном обеспечении. Это правда?

Т.е. если я пишу клиент, я думаю, что на самом деле у меня должно быть около 60% конечного автомата для клиента и 60% для сервера (из-за некоторого перекрытия я говорю 60%, а не 50%). Мысли?

ответ

2

Это правильно, от RFC 7540, section 8.2.1 Push Requests:

PUSH_PROMISE кадры НЕ ДОЛЖНЫ быть посланы клиенту.

и, как вы описали, то RFC продолжается:

Отправка PUSH_PROMISE кадр создает новый поток и помещает поток в «зарезервированных (местного)» состояние сервера и " зарезервированное (удаленное) состояние для клиента.

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

1

Ответ на ваш первый вопрос - «да», как объяснил Фредерик.

Это утверждение

Я имею в виду, я должен действительно только около 60% от государственной машины для клиента и 60% для сервера

не очень точны.

Это правда, что клиент никогда не войдет в состояние reserved(local), то же самое для сервера с reserved(remote). Однако, чтобы синхронизировать состояния потоков, самым простым (возможно, единственным) способом является также сохранение состояния сверстников. Фактически, состояние потока - это не одна конечная точка, а обе конечные точки. В любой момент жизненного цикла потока состояние потока состоит из состояния клиента и состояния сервера. Иногда они одинаковы (праздные, открытые, закрытые), иногда они не идентичны (зарезервированы, полузакрыты).

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

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

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

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

+0

Говоря о синхронизации, возможна ли отправка кадра и получение кадра одновременно? Sepcs сказал, что поток «двунаправленный», и что произошло, если отправка и получение произошли в одно и то же время и изменение состояния потока в конфликт? –

+1

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

 Смежные вопросы

  • Нет связанных вопросов^_^