Комментарии 14
А что это за SSL трафик, который так адски сжимается?
И, я так понимаю, на уровне приложений для оптимизации трафика там особо ничего не делалось? Для того же SMB всякие DFS и BranchCache…
И, я так понимаю, на уровне приложений для оптимизации трафика там особо ничего не делалось? Для того же SMB всякие DFS и BranchCache…
В первую очередь SSL в отчете — это OWA.
Riverbed оптимизирует SMB с помощью нескольких техник:
— дедупликация (сжатие)
— ускорения на транспортном уровне TCP (спутниковый режим SCPS)
— ускорение на уровне приложений
Подобным образом выполняется оптимизация и других самых распространенных типов приложений.
Riverbed оптимизирует SMB с помощью нескольких техник:
— дедупликация (сжатие)
— ускорения на транспортном уровне TCP (спутниковый режим SCPS)
— ускорение на уровне приложений
Подобным образом выполняется оптимизация и других самых распространенных типов приложений.
В первую очередь SSL в отчете — это OWA.
Я правильно понимаю, что на канале стоит пара девайсов с импортированными сертификатами, которые расшифровывают трафик, жмут и на другом конце шифруют снова?
Riverbed оптимизирует SMB с помощью нескольких техник:
Я о другом. «Поставили в неоптимизированную инфраструктуру и порадовались» — тоже жизненный сценарий, конечно. Но, как трафик ни оптимизируй, а всё равно файлы грузить с удаленного сервера. С другой стороны, DFS и BranchCache в винде из коробки и решают вопросы с SMB-трафиком куда более радикально (причем в случае BranchCache даже локальный сервер может не понадобиться). Вот и было бы интересно посмотреть, даст ли что-то Riverbed в ситуации, когда другие пути оптимизации тоже задействованы.
1. Да, все верно. Единственное добавлю, что сертификат импортируется только на один оптимизатор, установленный в ЦОД. Есть и другие варианты архитектуры, но эта в данной ситуации оптимальна.
2. Дело в том, что оптимизатор не кеширует файлы целиком в прямом понимании этого слова. Оптимизатор хранит самые часто используемые сегменты данных в словаре (механизм SDR – Scalable Data Reference) и нет привязки к протоколу, по которому будет получен файл в филиале. Например, файл презентации PowerPoint передали по почте в филиал. А затем в случае загрузки этого же файла по FTP, но с небольшими изменениями, будет переданы только изменения, остальные данные будет переданы в виде коротких ссылок на сегменты данных. Т.е. весь файл передаваться полностью не будет. В случае, если файл >10 Мбайт и канал связи спутниковый, то это значительно экономит полосу пропускания.
2. Дело в том, что оптимизатор не кеширует файлы целиком в прямом понимании этого слова. Оптимизатор хранит самые часто используемые сегменты данных в словаре (механизм SDR – Scalable Data Reference) и нет привязки к протоколу, по которому будет получен файл в филиале. Например, файл презентации PowerPoint передали по почте в филиал. А затем в случае загрузки этого же файла по FTP, но с небольшими изменениями, будет переданы только изменения, остальные данные будет переданы в виде коротких ссылок на сегменты данных. Т.е. весь файл передаваться полностью не будет. В случае, если файл >10 Мбайт и канал связи спутниковый, то это значительно экономит полосу пропускания.
файл презентации PowerPoint передали по почте...С почтой не хороший пример, так как файл претерпит UUE кодирование, и это будут совсем не те данные, что по FTP.
И вообще, при смене протокола передачи файла, меняются и заголовки пакетов, которые передают содержимое, да и само содержимое может по пакетам быть распихано по другому. Как в таком случае строится словарь данных, и на сколько такое кеширование эффективно?
В оптимизатор встроены декодеры. Словарь оптимизатора заполняется оригинальными данными после декодирования. Это не совсем кеширование (точнее совсем не кеширование). Это дедупликация данных за счет замены уже записанных паттернов оригинальных данных ссылками. Эффективность высокая. Конкретные цифры зависят от количества избыточности в передаваемых данных. Опыт показывает, что эта избыточность есть всегда.
Подскажите пожалуйста, какая в итоге задержка на канале? Для спутника латентность должна быть достаточно высокой. Как работает RDP?
Реальная задержка на каналах связи = 600 — 700 мс RTT. И в зависимости от внешних факторов может ухудшаться.
Если канал связи не загружен, то мы не увидим заметного ускорения работы RDP. Но с другой стороны, если канал связи сильно загружен, то оптимизаторы позволяют разгрузить канал связи, приоритезировать приложения и за счет этого повысить стабильность и ускорить RDP. В нашем случае мы добились заметного улучшение работы RDP.
Если канал связи не загружен, то мы не увидим заметного ускорения работы RDP. Но с другой стороны, если канал связи сильно загружен, то оптимизаторы позволяют разгрузить канал связи, приоритезировать приложения и за счет этого повысить стабильность и ускорить RDP. В нашем случае мы добились заметного улучшение работы RDP.
Вообще RDP работает приемлимо на канале в 700мс RTT? С какими приложениями? Есть ли шансы на просмотр CAD графики?
Расскажите, пожалуйста.
Расскажите, пожалуйста.
На задержках 700ms RDP тормозит… Шанс есть, все зависит от устойчивости Вашей нервной системы или правильных успокаивающих средств Шучу! Не все так плохо.
Здесь многое будут зависеть от наличия потерь и доступной полосы пропускания.
В случае с RDP оптимизатор может побороть тормоза связанные с потерями и полосой пропускания (за счет сжатия и прозрачного проксирования TCP), но не задержками.
Здесь многое будут зависеть от наличия потерь и доступной полосы пропускания.
В случае с RDP оптимизатор может побороть тормоза связанные с потерями и полосой пропускания (за счет сжатия и прозрачного проксирования TCP), но не задержками.
По картинкам (вторая, третья) видно, что оборудование посылает запрос и ждет ответ, перед тем, как что-то еще отправить.
Придумаем очень простой протокол, например, для калькулятора.
На сервер будем передавать задания: пара чисел и операцию. Ожидать будем результат (допустим, он нам нужен для последующего вычисления) И что с этим может сделать эта волшебная железка?
Я правильно понял, что оптимизации поддаются только протоколы, где оптимизатор может предугадать ответ. Например, в случае SMTP будет всегда быстро отвечать «250 OK» несмотря на то, что допустим, ящик адресата на самом деле уже удален с сервера?
Придумаем очень простой протокол, например, для калькулятора.
На сервер будем передавать задания: пара чисел и операцию. Ожидать будем результат (допустим, он нам нужен для последующего вычисления) И что с этим может сделать эта волшебная железка?
Я правильно понял, что оптимизации поддаются только протоколы, где оптимизатор может предугадать ответ. Например, в случае SMTP будет всегда быстро отвечать «250 OK» несмотря на то, что допустим, ящик адресата на самом деле уже удален с сервера?
По роду деятельности я немного знаком с ривербедами, потому отвечу вам.
1. У них есть режим работы с предустановкой tcp-соединений, что на канале с высоким RTT даёт выигрыш времени на установку соединения. При типичном RTT 700ms на установку обычного TCP-соединения нужно 2.1 секунды. Если мы заранее установим сессию — мы сэкономим это время.
2. Сжатие данных, в случае простого калькулятора — эффекта будет мало, а для работы среднего приложения по API с передачей данных json/xml выгоды будет существенно больше.
1. У них есть режим работы с предустановкой tcp-соединений, что на канале с высоким RTT даёт выигрыш времени на установку соединения. При типичном RTT 700ms на установку обычного TCP-соединения нужно 2.1 секунды. Если мы заранее установим сессию — мы сэкономим это время.
2. Сжатие данных, в случае простого калькулятора — эффекта будет мало, а для работы среднего приложения по API с передачей данных json/xml выгоды будет существенно больше.
С точки зрения калькулятора, есть два варианта –
1. В случае, если это приложение работает посредством «толстого» клиента, то эффекта от оптимизации будет мало. Т.к. будут выполняться короткие запросы-ответы, могу даже сделать сравнение такого приложения с работой telnet.
2. Если представить, что это приложение работает на базе http (как большинство современных приложений), то эффект будет значительный.
Во-первых за счет оптимизации http, который сжимается и оптимизируется очень хорошо – т.к. нужно как минимум загрузить web форму (того же калькулятора) в браузер клиента.
Во-вторых, если представить, что в виде ответа от сервера на заполненные поля в web форме мы получаем некий объемный отчет, который как правило избыточный, то эффект от использования оптимизатора за счет де-дупликации будет так же значительный.
Для каждого конкретного протокола прикладного уровня (из списка ускоряемых на L7) оптимизатор применяет свой специфический алгоритм оптимизации. Если мы говорим об SMTP, то здесь основной задачей является “вскрыть” шифрование. SMTP соединение устанавливается до SSL-соединения, таким образом, возникают сложности в определении момент запуска SSL-оптимизации. На помощь приходит L7 блейд оптимизатора, отвечающий за SMTP. Более того использование L7 блейда обеспечивает, что не нужно делать TLS-handshake для отправки каждого письма.
За нашу практику не встречали ситуаций когда из-за оптимизатора пользователь мог скачать удаленный файл или посмотреть удаленное письмо:)
1. В случае, если это приложение работает посредством «толстого» клиента, то эффекта от оптимизации будет мало. Т.к. будут выполняться короткие запросы-ответы, могу даже сделать сравнение такого приложения с работой telnet.
2. Если представить, что это приложение работает на базе http (как большинство современных приложений), то эффект будет значительный.
Во-первых за счет оптимизации http, который сжимается и оптимизируется очень хорошо – т.к. нужно как минимум загрузить web форму (того же калькулятора) в браузер клиента.
Во-вторых, если представить, что в виде ответа от сервера на заполненные поля в web форме мы получаем некий объемный отчет, который как правило избыточный, то эффект от использования оптимизатора за счет де-дупликации будет так же значительный.
Для каждого конкретного протокола прикладного уровня (из списка ускоряемых на L7) оптимизатор применяет свой специфический алгоритм оптимизации. Если мы говорим об SMTP, то здесь основной задачей является “вскрыть” шифрование. SMTP соединение устанавливается до SSL-соединения, таким образом, возникают сложности в определении момент запуска SSL-оптимизации. На помощь приходит L7 блейд оптимизатора, отвечающий за SMTP. Более того использование L7 блейда обеспечивает, что не нужно делать TLS-handshake для отправки каждого письма.
За нашу практику не встречали ситуаций когда из-за оптимизатора пользователь мог скачать удаленный файл или посмотреть удаленное письмо:)
Между прочим (пишу комментом, т.к. с этим словом часто возникают вопросы и несколько раз спорили на работе):
Источник.
Вопрос № 190204
Есть три варианта написания слов: «приоритизация», «приоритезация» и «приоритетизация». Которое из них правильное и имеет право на существование? Контекст: «Приоритизация привлекательных рынков» Спасибо
Гликин Г.Я.
— Ответ справочной службы русского языка
Слово не зафиксировано в словарях. Видимо, происходит усечение основы (ср. без усечения было бы приоритетизация), поэтому корректно: приоритизация.
Источник.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация каналов связи для добычи полезных ископаемых на севере России