Где протокол http лежит в структуре rails? - PullRequest
Новая
       40

Где протокол http лежит в структуре rails?

1 голос
/ 11 мая 2019

Я просто хотел знать, где находится платформа HTTP в рельсах и как реализовать другой протокол для взаимодействия клиент-сервер с использованием другого сетевого уровня?

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

Ответы [ 2 ]

3 голосов
/ 11 мая 2019

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

Rails <---> Rack <---> Web Server <---> Web Client

Вот крошечный сервер Rack с надписью «Привет, мир!» . 

require "rack"
require "thin"

class HelloWorld
  def call(env)
    [ 200, { "Content-Type" => "text/plain" }, ["Hello World"] ]
  end
end

Rack::Handler::Thin.run HelloWorld.new

Rack::Handler::Thin обращается к крошечному веб-серверу thin, передавая ему ответ, состоящий из кода HTTP, заголовков HTTP и тела ответа.

Возможно, вам повезло. Веб-сервер LiteSpeed ​​ поддерживает QUIC, а Rack имеет обработчик LiteSpeed ​​. Это может просто сработать.

2 голосов
/ 11 мая 2019

Как обсуждалось в комментариях, QUIC еще формально не стандартизирован, поэтому неудивительно, что он недоступен в большинстве инструментов. Ни один из основных веб-серверов (например, Apache, Nginx или IIS) даже не указал, что они еще работают над ним. Он должен быть завершен в июле, а затем отправлен на стандартизацию, которая займет несколько месяцев после этого. После этого я ожидаю, что реализации станут доступны.

Google изобрел QUIC и имеет версию на своих серверах и в Chrome. Это формирует основу QUIC, который будет стандартизирован, но оба разошлись и не совместимы. Таким образом, вы можете реализовать версию Google QUIC, если хотите, и некоторые серверы, такие как LiteSpeed ​​, и некоторые CDN, такие как Akamai , делают это. Как и сами Google на своей облачной платформе . Они в основном делают это путем реинжиниринга кода Google Chrome с открытым исходным кодом. Кроме того, поскольку Google выполняет итерацию QUIC и перестает поддерживать старые версии, они должны продолжать работать, иначе он перестанет работать. В конечном итоге, Google QUIC устареет, а затем прекратит работу, как только выйдет стандартизированный IETF QUIC.

QUIC также невероятно сложен! Реализация будет нелегкой и потребует значительных усилий и времени. Это не так просто, как найти код HTTP, скопировать и вставить его и изменить несколько вещей. Это огромный новый протокол, который переопределяет части TCP, TLS и HTTP / 2. HTTP / 3 - это то, что осталось от HTTP / 2 и должно быть реализовано, а также QUIC, чтобы быть полезным.

Наконец, влияние QUIC может быть не таким значительным, как вы думаете. QUIC представляет собой эволюцию HTTP / 2 и устраняет один крайний случай, когда HTTP / 2 может работать медленнее, чем HTTP / 1.1, если происходит очень большая потеря пакетов. Помимо этого сценария начальные версии QUIC будут очень похожи на HTTP / 2 и TLSv1.3, которые доступны сейчас. Одна из основных причин QUIC - дать ему возможность быстро развиваться, так как TCP практически невозможно изменить, так как он так запутан. Будущие версии QUIC , вероятно, будут включать прямое исправление ошибок (для автоматического воссоздания отброшенных пакетов) миграция соединения (чтобы вы могли беспрепятственно переключаться с Wi-Fi на мобильный телефон), а также быть доступной для более чем HTTP, но они выходят за рамки начальной версии, как определено в Уставе рабочей группы QUIC , потому что даже без эти вопросы являются сложными. Кроме того, протокол TCP оптимизирован для операционных систем и сетевых стеков, поэтому QUIC, вероятно, будет более дорогостоящим и медленным, особенно на начальном этапе, а также могут возникнуть другие проблемы, которые необходимо решить .

В общем, если вы хотите использовать QUIC сейчас, посмотрите на один из веб-серверов, CDN или Google Cloud Platform и поместите его перед сервером приложений. Как и HTTP / 2, это обычно дает основные преимущества и означает, что вам не нужно беспокоиться обо всех вышеперечисленных сложностях. Но для меня QUIC - один из тех, кто следит за будущим, а не то, что я хочу сейчас сделать.

Если вам интересно узнать больше о HTTP / 2, HTTP / 3 и QUIC, а также о некоторых сложностях, вы можете проверить мою книгу на эту тему: https://www.manning.com/books/http2-in-action

...