Kami baru-baru ini meningkatkan situs jarak jauh dari serat 10 / 10Mbps menjadi 20 / 20Mbps link serat (itu adalah serat ke ruang bawah tanah, kemudian VDSL dari ruang bawah tanah ke kantor, sekitar 30 meter). Ada salinan file besar (multi-gig) biasa antara situs ini dan situs pusat, jadi teorinya adalah bahwa meningkatkan tautan ke 20/20 akan mengurangi separuh waktu transfer.
Untuk transfer untuk menyalin file (misalnya menggunakan robocopyuntuk menyalin file di kedua arah, atau replikasi Veeam Backup and Recovery) mereka dibatasi pada 10Mbps.
Sebelum meningkatkan:
Setelah peningkatan ( robocopy):
Hampir identik (abaikan perbedaan lamanya waktu transfer).
Transfer sedang dilakukan melalui terowongan IPSec antara Cisco ASA5520 dan Mikrotik RB2011UiAS-RM .
Pikiran pertama:
- QoS - tidak. Ada aturan QoS tetapi tidak ada yang mempengaruhi aliran ini. Saya menonaktifkan semua aturan selama beberapa menit untuk memeriksa, dan tidak ada perubahan
- Batas yang ditentukan perangkat lunak. Sebagian besar lalu lintas ini adalah pengiriman Veeam Backup and Recovery di luar situs, tetapi tidak ada batasan yang ditentukan di sana. Selain itu, saya hanya melakukan straight
robocopydan melihat statistik yang persis sama. - Perangkat keras tidak mampu. Nah, angka kinerja yang diterbitkan 5520 adalah 225Mbps data 3DES, dan Mikrotik tidak mempublikasikan angka tetapi akan lebih dari 10Mbps. Mikrotik memiliki sekitar 25% -33% penggunaan CPU saat melakukan tes transfer ini. (Juga, melakukan transfer HTTP melalui terowongan IPSec mencapai hampir 20Mbps)
- Latensi dikombinasikan dengan ukuran Jendela TCP? Yah itu latency 15ms antara situs, jadi bahkan kasus terburuk ukuran jendela 32KB
32*0.015adalah maksimum 2,1 MB / detik. Selain itu, beberapa transfer konkuren masih hanya menambahkan hingga 10Mbps, yang tidak mendukung teori ini - Mungkin sumber dan tujuannya sama-sama sial? Yah sumbernya bisa mendorong pembacaan berurutan 1.6GB / detik berkelanjutan, jadi bukan itu. Tujuan dapat melakukan 200 MB / detik berkelanjutan menulis berurutan, jadi bukan itu juga.
Ini adalah situasi yang sangat aneh. Saya belum pernah melihat sesuatu yang nyata seperti ini sebelumnya.
Di mana lagi saya bisa melihat?
Pada penyelidikan lebih lanjut, saya yakin menunjuk ke terowongan IPSec sebagai masalahnya. Saya membuat contoh yang dibuat dan melakukan beberapa tes langsung antara dua alamat IP publik di situs, dan kemudian melakukan tes yang sama persis menggunakan alamat IP internal, dan saya dapat mereplikasi 20Mbps melalui internet yang tidak terenkripsi, dan hanya 10Mbps pada IPSec sisi.
Versi sebelumnya memiliki herring merah tentang HTTP. Lupakan ini, ini adalah mekanisme pengujian yang salah.
Sesuai saran dari Xeon dan didengungkan oleh ISP saya ketika saya meminta dukungan mereka, saya telah menyiapkan aturan mangle untuk menjatuhkan MSS untuk data IPSec ke 1422 - berdasarkan perhitungan ini :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Untuk masuk ke dalam ISP 1480 MTU. Tetapi sayangnya ini tidak membuat perbedaan yang efektif.
Setelah membandingkan tangkapan wireshark, sesi TCP menegosiasikan MSS 1380 di kedua ujungnya sekarang (setelah men-tweak beberapa hal dan menambahkan buffer jika matematika saya payah. Petunjuk: mungkin memang demikian). 1380 juga merupakan MSS default ASA, jadi mungkin saja ini sudah dinegosiasikan.
Saya melihat beberapa data aneh di alat di dalam Mikrotik yang saya gunakan untuk mengukur lalu lintas. Bisa jadi bukan apa-apa. Saya tidak melihat ini sebelumnya karena saya menggunakan permintaan difilter, dan saya hanya melihat ini ketika saya menghapus filter.
1394adalah MTU terbesar yang bisa saya lalui.
