Đánh dấu cổng VPN không ưu tiên cuộc gọi thoại

Đánh dấu cổng UDP của VPN là ưu tiên cao là thay đổi QoS cho thoại phổ biến nhất, và nó không tách cuộc gọi khỏi việc truyền tệp dùng chung đường hầm đó. Cả hai luồng đều đi ra qua cùng một socket đã mã hóa. Dấu hiệu nói với chặng kế tiếp rằng mọi thứ đều quan trọng như nhau, điều này cũng giống như không nói gì. Thứ bảo vệ cuộc gọi là phân loại đáng tin cậy trước khi mã hóa cùng một hàng đợi bạn thực sự kiểm soát.

Đường hầm giấu luồng bạn muốn phân loại

Mã hóa thay thế các tiêu đề bên trong bằng một tiêu đề bên ngoài cho mỗi đường hầm. Sau đó, thoại và lưu lượng sao lưu trình bày cùng nguồn, đích và cổng vận chuyển, nên bộ phân loại dựa trên cổng đường hầm không thể phân biệt chúng. Bạn nâng cấp thứ gì thì cũng nâng cấp toàn bộ.

Giá trị DSCP do ứng dụng gốc đặt chỉ tồn tại nếu có thứ gì đó sao chép nó ra ngoài. OpenVPN 2.6 có passtos, được ghi tài liệu với phạm vi IPv4; IPsec áp dụng chính sách sao chép hoặc ánh xạ của riêng nó tại ranh giới đường hầm. Không có bước đó, gói bên ngoài được đánh dấu bằng bất kỳ giá trị mặc định nào mà giao diện đường hầm dùng, và hàng đợi phía dưới không bao giờ biết rằng bên trong có một cuộc gọi.

Các dấu hiệu được sao chép đáng bị nghi ngờ như mọi giá trị do máy khách cung cấp. Một máy trạm có thể yêu cầu chuyển tiếp nhanh cho một tác vụ sao lưu, nên việc chấp nhận và đánh dấu lại tại ranh giới tin cậy phải nằm trong thiết kế trước khi tin vào dấu hiệu.

Ưu tiên chỉ có ý nghĩa ở nơi hình thành hàng đợi

Một liên kết lên bị bão hòa là thứ biến codec tốt thành giọng robot, và hàng đợi bị đầy thường nằm trong thiết bị truy cập hoặc trong bộ đệm của nhà cung cấp. Định hình đường ra theo tốc độ sử dụng được, trừ chi phí đường hầm và liên kết, là thứ giữ hàng đợi đó trên phần cứng bạn quản trị chứ không phải trong bộ đệm của người khác.

Hàng đợi công bằng và quản lý hàng đợi chủ động giúp ích ngay cả khi không có lớp thoại, vì chúng ngăn một luồng lớn lấp đầy bộ đệm. CAKE trên Linux gộp định hình, công bằng theo luồng và các lớp Diffserv tùy chọn vào một qdisc, và trình quản lý mạng đã triển khai nên sở hữu cấu hình đó thay vì thiết lập hàng đợi cạnh tranh thứ hai. Không có định hình, một lớp cao hơn lưu lượng lớn vẫn chờ sau một bộ đệm đã đầy.

Xử lý lưu lượng đến không phải vô ích, nhưng nó chỉ tác động sau khi gói đã đi qua liên kết nhận. Nó có thể ảnh hưởng đến bên gửi phản hồi và không thể hoàn lại độ trễ đã tiêu ở phía trên, nên đây là biện pháp giảm nhẹ chứ không phải bảo đảm.

Điều gì tồn tại trên internet công cộng

Kiến trúc Diffserv mô tả cách đối xử bên trong các miền quản trị, vì thế nhà cung cấp có thể bỏ qua hoặc viết lại một dấu hiệu tại ranh giới. Khẳng định ngược lại, rằng mọi mạng luôn loại bỏ nó, cũng thiếu cơ sở như vậy. Câu hỏi trung thực là con đường cụ thể này được hợp đồng và giám sát để làm gì. Hãy kiểm tra bằng một đầu dò đã đánh dấu thay vì lặp lại một quy tắc đọc được ở đâu đó.

Hỏi nhà cung cấp làm gì với lớp đó, rồi đo lại. Một dấu hiệu được giữ nhưng không được lập lịch là trang trí; một con đường lập lịch mà không thấy dấu hiệu là vấn đề khác, và cả hai cần cách khắc phục khác nhau.

Một kế hoạch đo tách riêng từng giai đoạn

Thực hiện một cuộc gọi thông thường với tải lên cạnh tranh được kiểm soát, rồi lặp lại trên liên kết có dây. Xem cuộc gọi mất gì, bộ đếm lớp ghi lại gì và giao diện chạy gần giới hạn thực của nó đến mức nào thay vì tốc độ quảng cáo của gói dịch vụ.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

Nếu bộ đếm của lớp thoại vẫn bằng không, phân loại hoặc sao chép dấu hiệu bị hỏng và không mức ưu tiên nào giúp được. Nếu bộ đếm lớp di chuyển cục bộ trong khi độ trễ vẫn tăng, nút cổ chai nằm ngoài cổng của bạn. Không kết quả nào trong hai kết quả được khắc phục bằng cách tăng giá trị ưu tiên.