w00dpecker
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Поясните, пожалуйста, для тех, кто уже совсем с головой не дружит... http://forum.mikrotik.com/viewtopic.php?f=21&t=107422&p=534818&hilit=IPSEC+CCR1036+aes+256+cbc#p534818 Цитата: The problem is the hardware encryption driver (on CCR that means aes-*-cbc encryption) encrypts/sends packets out of order. This results in the client seeing packet loss, duplicate acks, out of order packets, etc, which cause performance issues with TCP (some benchmarking/real world traffic shows about 50% of packets are retransmits and duplicate acks). How much depends on a variety of things (like application, tcp window, latency, etc). Because of this, I actually use software encryption (aes-256-ctr) instead because I see about 10x faster single-threaded transfers. Here are some example numbers: Software/single stream: 75Mbps Software/multiple stream: 150Mbps (single cpu core maxed) Hardware/single stream: ~7.5Mbps Hardware/multiple stream: >500Mbps Note: Same tests performed. Only difference is toggling (default in /ip ipsec proposal) between CBC (hardware) and CTR (software). Also, you often have to flush installed SAs after changing this on both sides to get the session to actually switch over. | То есть самый шустрый алгоритм на данный момент это многопоточный аппаратный. Надо в proposal указать не aes-*-cbc, а aes-*-gcm? А если результат не устроит, тогда aes-*-ctr и будет вместо 10M хотя бы 75М... до 75M в зависимости от прочих правил-служб жаждущих проца... Так? | Всего записей: 21 | Зарегистр. 13-04-2016 | Отправлено: 15:34 16-06-2016 | Исправлено: w00dpecker, 15:43 16-06-2016 |
|