Что такое прокси - сервер?

Сервер прокси - сервера состоит из двух типов:

1) бессистемный прокси - сервер: простая функция пересылки, выберите пункт назначения и маршрут пересылки запроса информации. Сообщение пересылается и удаляется.

2) прокси - сервер статуса: регистрирует входящий запрос и отправляет запрошенную информацию (в частности, состояние операции) и использует эту информацию для управления обработкой будущих сообщений. У него также есть сообщение для функции Fork.

 1 имеет статус прокси - сервера

Статус прокси - сервера - это чисто бизнес - движок.

Как показано на диаграмме 1, прокси - сервер имеет один терминал и один или несколько связанных с ним клиентов. это два более продвинутых модуля обработки прокси: ядро прокси.

когда запрос поступает, сначала создайте сервер для обработки запроса, затем ядро определяет маршрут запроса и выбирает одно или несколько следующих перескоков, поэтому создайте несколько клиентов для отправки запроса.stateful proxy server model

при получении запроса агент должен выполнить запрос:

1, запрос проверки

2, предварительно обработанная маршрутная информация

Определение цели запроса (Цель)

4. пересылать просьбу в каждое место назначения

5, обработать все ответы

 

запрос проверки

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

1), грамматика права

2) Программа URI

3) Максимальное количество пересылки

4) проверка контура

5, агентские требования

6) доверенность

1) грамматика права

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

3) Максимальное количество пересылки

если запрос содержит поле заголовка Max Forwards и поле заголовка 0, агент не может пересылать запрос. Однако, если запрос является запросом OPTIONS, агент может ответить на запрос как конечный ответ.

(5) Проверка агентских требований

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

если запрос содержит поле заголовка Proxy Require (20. 29), и агент не может понять один или несколько параметров. После этого агент должен возвратить ошибку 420 (BadExtension), и ответ на эту ошибку должен содержать поле заголовка Unsupported (20. 40), в котором указаны опции, которые не могут поддерживаться агентом.

3 Предварительная обработка маршрутизации информации

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

если первое значение поля заголовка Route - Это агент, агент должен удалить его из запроса.

Определение цели запроса

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

2) если агент отвечает за запрос в указанный URI район, он может использовать любой механизм для определения места отправки запроса. агент может добавить цель при пересылке запроса. Он может использовать доступную информацию для определения нового пункта назначения. например, агент может выбрать, чтобы объединить адрес контакта, указанный в ответе на пересылку (3xx), в коллекцию назначения.

запрос пересылать

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

Копировать полученный запрос

2) запрос на обновление URI

3) обновление поля заголовка Max Forwards

4) дополнительно добавить заголовок "маршрутизация записи"

5) добавлено дополнительное поле заголовка

6) обработка информации о маршрутизации после ее обработки

7) установить следующий адрес узла, порт и протокол связи.

8) увеличить значение поля заголовка Via

9) если необходимо, добавить заголовок Content - Length

10) пересылать эту новую просьбу

11), установка таймера C

(2) запрос на обновление URI

Копирование запроса URI должно быть заменено адресным URI.

3) Максимальное количество пересылки

Если поле заголовка копий содержит Max Forwards, агент должен уменьшить значение этого поля на 1.

Если поле заголовка не содержит поля заголовка Max Forwards, агент должен добавить поле заголовка самостоятельно. значение по умолчанию - 70. некоторые UA сейчас не заполняют поля заголовков Max Forwards в запросе.

4) маршруты регистрации

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

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

запись маршрута в поле заголовка не позволяет URI быть SIP или SIPS URI. URI должен содержать аргументы lr.

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

6) обработка маршрутной информации

Если Запрашиваемая копия содержит поле заголовка Route, агент должен проверить первое значение поля заголовка Route. Если URI не содержит параметр lr, агент должен изменить запрос следующим образом:

- агент должен поместить запрос URI в поле заголовка Route.

- агент должен поместить значение первого поля маршрута в запрос URI и удалить его из заголовка маршрута.

7) определение адреса, порта и Протокола связи для следующего узла.

У прокси - сервера есть своя стратегия для отправки запросов на определённые IP - адреса, порты и передачи, не учитывая значения Route или request URI.

агент также может применить RFC 3263 для определения того, куда следует направлять запрос.

8) добавить значение поля заголовка Via.

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

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

(8) установите таймер C.

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

обработка откликов

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

когда клиент передает ответ агенту, исполняется следующие шаги:

1) найти соответствующий контекст ответа.

2) обновить таймер C с временным ответом

3) Удалить Via

4) добавить ответ в контекст ответа

5), проверьте, нужно ли отправить ответ немедленно

6) выбор наилучшего окончательного ответа из контекста ответа, если это необходимо.

7) необходимо объединить идентификационные знаки,,,,,,,,,,,,, поля и значения d.

8) необязательное изменение записи маршрутизатора заголовка

положительная реакция

10) подготовка соответствующего запроса CANCEL.

3) удаление отверстий с верхней части

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

4) увеличить отклик в контексте реакции

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

(5) Проверьте, нужно ли отправить ответ немедленно

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

- любой временный ответ не 100 (попытка)

- ответ на любые вопросы.

если вы получите ответ от 6xx, он не будет сразу пересылаться. если у него есть статус - агент, то необходимо отменить все клиенты, зависящие от этого дела (как указано в разделе 10), и не создавать их в контексте. Новая ветвь.

после отправки окончательного ответа на серверное дело следует немедленно отправить следующий ответ:

- ответ на запрос INVITE 2 xx.

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

6) выбор оптимального ответа (опущен)

8) маршруты регистрации

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

9) пересылка ответов

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

агент должен передать ответ на Сообщение сервера, связанное с контекстом ответа. Это приведёт к отправке ответа в верхнее поле заголовка Via.

6 прокси - маршрутизация

В случае отсутствия локальной стратегии обработка запросов, содержащих заголовок Route, может быть произведена следующим образом:

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

агент проверит URI в верхней части заголовка Route. Если URI указывает на прокси, то агент будет удален из поля заголовка Route (этот узел маршрута прибыл).

агент передает запрос в URI, обозначенный в верхней точке заголовка "Route" или "request URI" (если нет поля заголовка "Route"). агент использует RFC3263 для создания адреса, порта, Протокола связи и т.д.

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

агент без состояний

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

агент без статуса не имеет понятия операции, не описывает ситуацию, в которой агент имеет статус. Вместо этого, агенты без статуса обрабатывают сообщения, как по запросу, так и по запросу, непосредственно с уровня связи. Разумеется, Агентство "нет" само по себе не пересылает эти сообщения. Они просто пересылают все полученные ими пересылаемые сообщения (они сами не могут различать пересылаемые и оригинальные). Кроме того, когда запрос обрабатывается бессистемно, узел не генерирует собственного 100 (тринг) или другого временного ответа.

Следующий пост:IP pbx телефонная система