Посты для тега : ‘клиент’

Маршрутизация по умолчанию, основной и резервный каналы, плюс частичная маршрутизация

Этот вариант подключения представляет собой тот же самое, что и предыдущий, за исключением того, что клиент способен принимать частичную маршрутизацию от провайдера. Такая схема подключения показана на рис. 7.10. В случае использования подхода, представленного на рис. 7.10, клиент имеет дополнительную гибкость в выборе точки выхода, так как в этом случае ему предоставляется больше маршрутной информации. […]

Читать далее »

Маршрутизация только по умолчанию: один канал основной и один резервный

При такой схеме подключения клиент конфигурирует маршрутизацию по умолчанию в сторону провайдера и не принимает никакой информации о частичных или полных маршрутах. Клиент может по умолчанию работать с двумя каналами сразу. На рис. 7.9                        клиент может использовать один канал как основной для всего трафика, а другой — иметь в качестве резервного и работать по нему […]

Читать далее »

Маршрутизация по умолчанию: один основной и один резервный каналы, плюс частичная и полная маршрутизация

При  подключении  одного  узла  к  различным  провайдерам  нет  необходимости  в получении полных маршрутов от одного или обеих провайдеров, если только клиент не планирует сам стать провайдером и передавать через свой узел все маршруты своим клиентам (т.е. чтобы его AS работала в транзитном режиме). На рис. 7.16 представлена схема подобного подключения.

Читать далее »

Упреждающая выборка в HTTP

После установления ТСР-соединения Web-клиент выдает НТТР-запрос Web- серверу. Даже если клиент имеет кэшировапную копию запрашиваемого ресурса, у пего может возникнуть необходимость связаться с сервером для проверки актуальности кэшированной версий. Время ожидания получения НТТР-ответа зависит от множества факторов, в том числе от времени создания ответа на сервере, размера сообщения-ответа и пропускной способности сети. Клиент может замаскировать […]

Читать далее »

Клиент как программа

Web-клиент представляет собой разновидность программного обеспечения. Главная задача Web-клиента — отправлять Web-запросы от имени пользователя и принимать ответы. Клиент также используется для многих других целей. Web была разработана после появления традиционной архитектуры программного обеспечения клиент-сервер, в которой клиент связывается с сервером и отправляет ему запрос, после чего получает ответ сервера. На момент создания Web другие […]

Читать далее »

Проблемы, связанные с внедрением дельта-механизма в НТТР/1.1

Внедрение дельта-мехаиизма требует изучения изменений, которые необходимо будет впести в протокол НТТР/1.1. Клиент или прокси-сервер должен иметь возможность заявить о своей поддержке дельта-механизма. Сервер, принимающий запрос, должен уметь генерировать разности для различных версий ресурсов и идентифицировать соответствующие разности. Рабочий проект [MKD+01J для этого предложения прошел несколько этапов стандартизации и на момент издания этой книги имел […]

Читать далее »

Механизм Expect/Continue

Если HTTP-сервер не может обрабатывать запросы большого объема, было бы полезно для клиента знать об этом до того, как посылается запрос. Клиент может извлечь выгоду, зная, что его ожидания соответствуют действительности до отправки запросов на большие ресурсы. Рассмотрим пример обработки Web-сервером больших форм с помощью методов PUT или POST. Хотя протокол не накладывает ограничений на […]

Читать далее »

Упреждающее установление соединений

Составной частью обработки HTTP-запроса является установление ТСР-соеди- нения с Web-сервером или с промежуточным компонентом, таким как прокси-сер- вер. Открытие TCP-соединения требует грехэтапного обмена между клиентом и сервером, о чем рассказывалось в главе 5 (раздел 5.2). Время задержки на этом этапе зависит от времени прохождения пакетов в обоих направлениях между компьютерами, а также от задержки в […]

Читать далее »

Real Time Streaming Protocol

Протокол (RTSP) дает возможность клиенту запрашивать живые или предварительно записанные потоки с мультимедийных серверов, подобно тому, как HTTP позволяет клиентам выдавать запросы к Web-cepверам. Фактически RTSP перенял большую часть своего синтаксиса и семантики от НТТР/1.1, поскольку формалыю оба протокола выполняют схожие функции. Сходство подчеркивает общий характер многих реализованных в HTTP концепций. Однако протоколы имеют ряд […]

Читать далее »

Сохранение состояния TIME_WAIT

Сильно загруженные Web-серверы обрабатывают большое количество запросов на создание новых TCP-соединений. Поддержка большого числа ТСР-соедииепий требует большого объема оперативной памяти и приводит к большим накладным расходам при обработке получаемых пакетов. В идеале оиерационная система могла бы освобождать эти ресурсы сразу же, как только соединение закрывается. Но протокол TCP требует, чтобы один или оба комиыотера сохраняли […]

Читать далее »
 
Rambler's Top100