Это почему это не трогать? Потому что они не знают что это такое, или знают и боятся? На слабых каналах именно MTU и таймауты соединения играют большую роль.
Это почему это не трогать? Потому что они не знают что это такое, или знают и боятся? На слабых каналах именно MTU и таймауты соединения играют большую роль.
С одной стороны правильно, а с другой MTU бы влиял на все сетевые приложения. Это ведь нижний уровень OSI.
Абсолютно верно. Только другие сетевые приложения вполне возможно не отдают поток в 400к за одну сессию. и по этому кивают "на лотус". Практически во всех случая "обрыва" TCP соединений оказалось виновато само сетевое соединение во всех его ипостасях. В одном случае правда отличилась CISCO ASA со своим интеллектуальным фильтром...
Constantin A Chervonenko
Green Team
Похоже, тут всем эта проблема интереснее, чем у нас на местеКстати, верное замечание, не мешает проверить, что там и как трафик фаерволлит...
Смысл в изменении самого протокола передачи - возможно, там другие тайм-ауты используются. Сомнительно, конечно, но попробовать-то можно
У нас роли распределены, есть сетевые админы, есть СБ, как обычно стрелки друг на друга, ну и в конечном счете на лотус. Про то что канал слабый не спорят, а вот в тонкости ни кому уже не интересно вникать. А у меня дальше лотуса прав нет.
Вообщем пока тема притихла, пользователям на локале настроила как выше писала.
Всем больше спасибо за участие
Constantin A Chervonenko
Green Team
Тайм-ауты - Господь с ними (точнее - на них своя строчка в ini). А вот MTU там точно тот-же
А есть какой нибудь документ, который говорит о необходимом размере канала для комфортного использования ?
(базы по 150-300 мб, сами документы по 4-5 мб с вложениями)
(базы по 150-300 мб, сами документы по 4-5 мб с вложениями)
Обучение наступательной кибербезопасности в игровой форме. Начать игру!