Gần đây, chúng tôi đã nâng cấp một trang web từ xa từ sợi 10 / 10Mbps lên liên kết sợi 20 / 20Mbps (đó là cáp đến tầng hầm, sau đó là VDSL từ tầng hầm đến văn phòng, khoảng 30 mét). Có các bản sao tệp lớn (nhiều gig) thường xuyên giữa trang này và một trang trung tâm, vì vậy lý thuyết là việc tăng liên kết lên 20/20 nên thực sự giảm một nửa thời gian chuyển.
Đối với chuyển để sao chép tệp (ví dụ: sử dụng robocopyđể sao chép tệp theo một trong hai hướng, hoặc sao chép của Veeam Backup and Recovery), chúng được giới hạn ở tốc độ 10Mb / giây.
Trước khi nâng cấp:
Sau khi nâng cấp ( robocopy):
Gần như giống hệt nhau (bỏ qua sự khác biệt về thời gian chuyển tiền).
Việc chuyển tiền đang được thực hiện qua một đường hầm IPSec giữa Cisco ASA5520 và Mikrotik RB2011UiAS-RM .
Suy nghĩ đầu tiên:
- QoS - không. Có các quy tắc QoS nhưng không có quy tắc nào ảnh hưởng đến luồng này. Tôi đã vô hiệu hóa tất cả các quy tắc trong vài phút để kiểm tra và không thay đổi
- Giới hạn xác định bằng phần mềm. Hầu hết lưu lượng truy cập này là Veeam Backup and Recovery vận chuyển ngoài trang web, nhưng không có giới hạn nào được xác định trong đó. Ngoài ra, tôi chỉ cần làm thẳng
robocopyvà thấy chính xác số liệu thống kê. - Phần cứng không có khả năng. Chà, con số hiệu suất được công bố của 5520 là 225Mb / giây dữ liệu 3DES và Mikrotik không công bố số nhưng nó sẽ cao hơn 10Mb / giây. Mikrotik có mức sử dụng CPU khoảng 25% -33% khi thực hiện các bài kiểm tra chuyển này. (Ngoài ra, thực hiện chuyển HTTP qua đường hầm IPSec đạt gần 20Mb / giây)
- Độ trễ kết hợp với kích thước cửa sổ TCP? Chà, độ trễ 15ms giữa các trang web, do đó, ngay cả trường hợp xấu nhất kích thước cửa sổ 32KB
32*0.015là tối đa 2,1 MB / giây. Ngoài ra, nhiều lần chuyển đồng thời vẫn chỉ thêm tối đa 10Mb / giây, không hỗ trợ lý thuyết này - Có lẽ nguồn và đích là cả hai? Chà, nguồn có thể đẩy 1.6GB / giây đọc liên tục liên tục, vì vậy không phải vậy. Đích có thể thực hiện ghi tuần tự liên tục 200 MB / giây, do đó, điều đó cũng không phải.
Đây là một tình huống rất kỳ quặc. Tôi chưa bao giờ thấy bất cứ điều gì biểu hiện khá theo cách này trước đây.
Tôi có thể tìm ở đâu nữa?
Khi điều tra thêm, tôi tự tin chỉ ra đường hầm IPSec là vấn đề. Tôi đã tạo một ví dụ giả định và thực hiện một số thử nghiệm trực tiếp giữa hai địa chỉ IP công cộng trên các trang web và sau đó thực hiện thử nghiệm chính xác bằng cách sử dụng các địa chỉ IP nội bộ và tôi có thể sao chép 20Mbps qua internet không được mã hóa và chỉ 10Mbps trên IPSec bên.
Phiên bản trước có cá trích đỏ về HTTP. Hãy quên điều này đi, đây là một cơ chế thử nghiệm bị lỗi.
Theo đề nghị từ Xeon và echo'd bởi ISP của tôi khi tôi yêu cầu họ hỗ trợ, tôi đã thiết lập quy tắc quản lý để giảm MSS cho dữ liệu IPSec xuống 1422 - dựa trên tính toán này :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Để phù hợp với 1480 MTU của ISP. Nhưng than ôi điều này đã không có sự khác biệt hiệu quả.
Sau khi so sánh các kết quả của wireshark, phiên TCP sẽ đàm phán MSS là 1380 ở cả hai đầu (sau khi điều chỉnh một vài điều và thêm một bộ đệm trong trường hợp toán học của tôi bị mất. Gợi ý: có lẽ là như vậy). 1380 dù sao cũng là MSS mặc định của ASA, vì vậy dù sao nó cũng có thể đã đàm phán điều này.
Tôi đang thấy một số dữ liệu lạ trong công cụ bên trong Mikrotik mà tôi đã sử dụng để đo lưu lượng. Nó có thể không là gì cả. Tôi đã không nhận thấy điều này trước đây khi tôi đang sử dụng truy vấn được lọc và tôi chỉ thấy điều này khi xóa bộ lọc.
1394là MTU lớn nhất mà tôi có thể vượt qua.
