Độ trễ cao trong quá trình tải xuống

Tôi đang gặp vấn đề tương tự về kết nối kinh doanh 5Mbps của mình như trong một bài đăng khác trên trang web này. Ngay khi bất kỳ máy tính nào bắt đầu tải xuống, độ trễ trên bước nhảy đầu tiên vượt qua DFG do ISP của chúng tôi cung cấp sẽ tắt khỏi biểu đồ. Bước nhảy đầu tiên này có khả năng trong cùng tòa nhà của chúng tôi và liên tục trong 1ms, bắt đầu tải xuống, ví dụ: cập nhật windows và nó nhảy lên 200-1000ms.

Tôi đã dành hàng giờ trên điện thoại với sự hỗ trợ tất cả nói rằng bạn đã đạt được băng thông tối đa có sẵn, điều đó là bình thường khi độ trễ của bạn tăng đột biến. Nhưng việc đọc của tôi cho tôi biết họ đang phá vỡ thứ gì đó bằng TCP. Tôi đã chạy thử nghiệm trên kết nối Shaw tại nhà và thậm chí trên Rogers LTE đang chạy các bản tải xuống và đạt tốc độ tối đa Mbps cho tài khoản của tôi nhưng độ trễ không đi qua mái nhà.

Tôi có hiểu đúng rằng Bell đang làm gì đó để phá vỡ các công nghệ tích hợp của TCP để quản lý tốc độ của nó dựa trên băng thông có sẵn giữa 2 điểm cuối không?

Bell đang nói với bạn sự thật. Khi bạn cố gắng đẩy 5Mbps (hoặc nhiều hơn) vào kết nối 5Mbps, mọi thứ sẽ được sắp xếp theo thứ tự nhỏ gọn (đọc: queue.) Ping của bạn sẽ tắt mà không bị trì hoãn vì không tồn đọng. Trả lời, tuy nhiên, bây giờ là ở cuối hàng đợi. TCP đang thực hiện chính xác những gì nó được yêu cầu ở đây - người gửi đang lấp đầy cửa sổ nhận được cho phép.

Có những điều bạn có thể làm bên lề của mình (QoS, WRED, v.v.) để giúp giảm hiệu ứng, nhưng đây là điều bạn sẽ thấy khi có sự khác biệt lớn giữa băng thông của người gửi và người nhận. Tôi đã sống với nó trong nhiều năm (T1, 6Mbps DS3, thậm chí 10Mbps cablemodem) Bạn có thể yêu cầu ISP giảm kích thước hàng đợi về phía họ, nhưng họ sẽ không làm điều đó, vì nó sẽ làm giảm gói tin .

Hầu hết các dạng "QoS" ngày nay không bao gồm AQM vì các nhà cung cấp thấy quá khó để cấu hình RED tự động mà không gây hại. Điều này dẫn đến sự chậm trễ khủng khiếp mà bạn thấy trên nhiều thiết bị phổ biến hiện nay, đáng chú ý là modem cáp và không dây. Vì vậy, chỉ đề xuất "bật qos" ... không giúp được gì. Trên thực tế trên ít nhất một trong các sản phẩm của Netgear, việc bật giới hạn tốc độ cho "QoS" dẫn đến kết quả tồi tệ hơn nhiều ....

Gần đây, một thuật toán xếp hàng + AQM công bằng mới đã xuất hiện có vẻ hoạt động rất tốt và tốt hơn, hầu như không cần cấu hình bên cạnh việc đặt giới hạn tốc độ. Nó được gọi là fq_codel và hiện đã có mặt rộng rãi trong hầu hết các Linux và cũng đã được chuyển sang BSD. Đó là một phần của "QoS" mặc định trong bộ ngắt rào cản openwrt, cerowrt và gargoyle sử dụng phiên bản trước đó (khá tốt) được gọi là sfqred với sơ đồ điều chỉnh tốc độ tự động sáng tạo được gọi là ACC.

Vì vậy, bạn có thể đóng hộp một hộp dựa trên liên kết này trước liên kết hoạt động sai của mình, bật bộ giới hạn tốc độ QoS của họ (đặt ngay bên dưới các nhà cung cấp của bạn cài đặt trong và ngoài để bạn kiểm soát) + fq_codel và có hiệu suất tốt hơn cho mọi người sử dụng nó . Ý tôi là tốt hơn đáng kinh ngạc : xem bản demo ietf bên dưới, báo cáo cho nhóm làm việc iccrg tại ietf, v.v.

Để biết thêm chi tiết về vấn đề bộ đệm và cách khắc phục, hãy xem:

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-video

Tất nhiên, chúng tôi đang cố gắng thuyết phục các nhà cung cấp CPE ISP khác nhau chú ý, như cablelabs, đã công bố một nghiên cứu tuyệt vời về công cụ mới này vài tháng trước, trong đó cũng có một số chi tiết về sự sai lệch hiện tại của modem cáp.

http://www.cablelabs.com/doads/pub/Active_Queue_Quản lý_Alacticms_DOCSIS_3_0.pdf

Những gì bạn đang thấy là hoàn toàn điển hình. Nhiều nhà cung cấp dịch vụ sẽ xếp hạng giới hạn và / hoặc sử dụng cơ chế QoS để giảm mức độ ưu tiên của ICMP (bao gồm ping và traceroute truyền thống) vì đôi khi nó đã được sử dụng để từ chối các cuộc tấn công dịch vụ.

Mặc dù liên kết không bị tắc nghẽn, mức độ ưu tiên thấp hơn không ảnh hưởng đến bất cứ điều gì vì không có lưu lượng nào được xếp hàng. Trong những khoảng thời gian này, độ trễ của bạn vẫn ở mức thấp vì các gói ICMP sẽ được chuyển tiếp ngay lập tức và hoàn toàn không bị trì hoãn.

Khi liên kết bị tắc nghẽn, hàng đợi ưu tiên cao hơn sẽ được chú ý nhiều hơn. Tùy thuộc vào cơ chế xếp hàng, nó có thể chuyển tiếp nhiều gói từ hàng đợi ưu tiên cao hơn cho mỗi gói từ hàng đợi ưu tiên thấp hơn hoặc thậm chí chỉ chuyển tiếp khi không có gì trong hàng đợi ưu tiên cao hơn. Trong mọi trường hợp, một gói được chuyển xuống hàng đợi ưu tiên thấp hơn thường sẽ được giữ lại lâu hơn trên một liên kết không có tắc nghẽn, làm tăng độ trễ.

Có lẽ bạn đang bị đệmbloat và bạn muốn AQM (Quản lý hàng đợi hoạt động). Tôi đã viết một kịch bản cho Linux, điều này làm cho việc này khá dễ dàng:

#!/bin/bash
# Traffic shaping script (AQM, fq_codel+tbf)
# Copyright 2018 Mikko Rantalainen <mikko.rantalainen@gmail.com>
# License: MIT (X11)
# Usage:
#   21/0.8 Mbps connection (ADSL2): DOWNLINK_RATE=21.7Mbit UPLINK_RATE=0.8Mbit TBF_LATENCY=500ms bin/traffic-shaping start
#   100/100 Mbps connection: ./traffic-shaping
#   1/1 GBps connection: DOWNLINK_RATE=1Gbit UPLINK_RATE=1Gbit TBF_LATENCY=10ms bin/traffic-shaping start
# Note that using low TBF_LATENCY will require powerful CPU.
#   

set -e

DEV="${DEV:=$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")}"

# ingress:
DOWNLINK_RATE="${DOWNLINK_RATE:=104000kbit}" # or e.g. "21.5Mbit"
# egress:
UPLINK_RATE="${UPLINK_RATE:=105000kbit}"

CODEL_INTERVAL="${CODEL_INTERVAL:=100ms}" # usually 100ms, high speed links with low latency may need lower values
CODEL_TARGET="${CODEL_TARGET:=5ms}" # unit "us" is also available, usually 5%-10% of CODEL_INTERVAL
CODEL_LIMIT="${CODEL_LIMIT:=1001}" # decrease to reduce latency, too low values will limit throughput
CODEL_FLOWS="${CODEL_FLOWS:=1024}"

# set burst as high as possible without causing dropped packets at the start of the connections
DOWNLINK_BURST="${DOWNLINK_BURST:=6500}"
UPLINK_BURST="${UPLINK_BURST:=6500}"

TBF_LATENCY="${TBF_LATENCY:=14ms}" # set to lower latency to improve control over bandwidth limiting, UPLINK_BURST bytes must be able to be sent in this time

IFB="$DEV.ingress"

INITCWND="${INITCWND:=20}"
INITRWND="${INITRWND:=20}"

configure_shaping()
{
    # EGRESS (outgoing traffic, "uploads"):

    # setup bandwidth limiting:
    tc qdisc add dev "$DEV" root handle 1: tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$DEV" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" noecn


    # INGRESS (incoming traffic, "downloads"):

    # setup bandwidth limiting (ingress limiting needs IFB or Intermediate Functional Block, see https://wiki.linuxfoundation.org/networking/ifb):
    tc qdisc add dev "$DEV" handle ffff: ingress
    ip link add name "$IFB" type ifb
    tc qdisc add dev "$IFB" root handle 1: tbf rate "$DOWNLINK_RATE" burst "$DOWNLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$IFB" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" ecn
    ip link set dev "$IFB" up

    # connect ingress filtering to actual WAN device
    tc filter add dev "$DEV" parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev "$IFB"

    # configure initcwnd and initrwnd
    ip route change $(ip route | grep ^default) initcwnd "$INITCWND" initrwnd "$INITRWND"
}

remove_shaping()
{
    tc qdisc list | grep -q "ingress" && tc qdisc del dev "$DEV" ingress || true
    tc qdisc list | grep -q "codel" && tc qdisc del dev "$DEV" root || true
    ip link show | grep -q "$IFB" && ip link del "$IFB" || true
}

status()
{
        echo "─── queue discipline configuration: ──────────────────"
        tc qdisc list
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV ingress' to remove ingress filtering"
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV root' to remove egress filtering"
        echo "─── ip link show: ────────────────────────────────────"
        ip link show
        echo "   TIP: use e.g. 'sudo ip link del $IFB' to remove ingress device"
}

color_status()
{
    status | grep --color=auto -E "^|$DEV|$IFB|rate [^ ]+"
}

# handle parameters

ACTION="$1"
shift || true

while [ ! -z "$1" ]
do
    case "$1" in
        -v|--verbose)
            echo "Device: $DEV"
            echo "Downlink rate (ingress): $DOWNLINK_RATE"
            echo "Uplink rate (egress): $UPLINK_RATE"
            set -x
            ;;
        *)
            if [ ! -z "$2" ]; then
                echo "Unknown parameter: '$2'" 1>&2
                exit 1
            fi
            ;;
    esac
    shift
done

case "$ACTION" in
    start)
        remove_shaping
        configure_shaping
        ;;
    stop)
        remove_shaping
        ;;
    status)
        color_status
        ;;
    restart)
        remove_shaping
        configure_shaping
        ;;
    *)
        echo "Unknown action: $1" 1>&2
        echo "Usage: $0 <start|stop|restart|status> [--verbose|-v]" 1>&2
        exit 1
esac

Bạn chỉ cần lưu tập lệnh như traffic-shapingvà chmod a+xnó và chạy nó dưới quyền root (sau khi đọc mã nguồn, rõ ràng).

Đối với trường hợp sử dụng của bạn, tôi đề nghị

DOWNLINK_RATE=5.0Mbit UPLINK_RATE=5.0Mbit TBF_LATENCY=500ms ./traffic-shaping start