İndirme sırasında yüksek gecikme süresi

Başka olduğu gibi benim iş bağlantısı 5Mbps aynı sorun yaşıyorum gönderme bu sitede. Herhangi bir bilgisayar indirmeye başlar başlamaz, ISS (Bell) tarafından sağlanan DFG'mizden sonraki ilk sekmede gecikme süresi grafikten çıkar. Bu ilk atlama muhtemelen aynı binadadır ve sürekli olarak 1 ms'dir, bir indirme başlatın, örneğin windows güncellemesi ve 200-1000 ms'ye atlar.

Telefonda, maksimum kullanılabilir bant genişliğine ulaştığınızı söyleyerek destekli saatler geçirdim, gecikmenin başlaması normaldir. Ama okumam bana TCP ile bir şeyler kopardıklarını söylüyor. Bir ev Shaw bağlantısında ve hatta indirmeler çalıştıran ve hesabım için maksimum Mbps'ye ulaşan bir Rogers LTE üzerinde testler yaptım, ancak gecikme çatıdan geçmiyor.

Bell'in 2 uç nokta arasındaki mevcut bant genişliğine göre hızını yönetmek için TCP'nin yerleşik teknolojilerini kırmak için bir şeyler yaptığını anlamış mıyım?

Bell sana gerçeği söylüyor. 5Mbps (veya daha fazla) bir 5Mbps bağlantıya aktarmaya çalıştığınızda, her şey düzgün küçük bir sıraya (okuma: kuyruk) gönderilir. Ancak cevap şimdi kuyruğun sonunda. TCP tam olarak burada olması gerekeni yapıyor - gönderen izin verilen alma penceresini dolduruyor.

Efektleri azaltmaya yardımcı olmak için hattınızın yan tarafında (QoS, WRED, vb.) Yapabileceğiniz şeyler vardır, ancak bu, gönderen ve alıcı bant genişliği arasında büyük bir fark olduğunda göreceğiniz bir şeydir. Yıllarca onunla yaşadım (T1, 6Mbps DS3, hatta 10Mbps cablemodem) ISS'den yanlarındaki kuyruk boyutunu azaltmasını isteyebilirsiniz, ancak paket damlalarına neden olacağı için bunu yapmaları olası değildir. .

Günümüzde "QoS" formlarının çoğu AQM'yi içermez, çünkü satıcılar KIRMIZI otomatik olarak zarar vermeden yapılandırmayı çok zor bulmuştur. Bu, günümüzde birçok yaygın cihazda, özellikle kablo modemlerde ve kablosuzda gördüğünüz korkunç gecikmelere yol açar. Bu yüzden sadece "qos'u açmayı" tavsiye etmek yardımcı olmaz. Aslında Netgear'ın ürünlerinden en az birinde, "QoS" için hız sınırlayıcıyı açmak çok daha kötü sonuçlara yol açar ....

Son zamanlarda, son derece iyi ve daha iyi çalışıyor gibi görünen yeni bir adil kuyruk + AQM algoritması, hız sınırlayıcıyı ayarlamanın yanı sıra neredeyse hiç yapılandırma gerektirmiyor gibi görünmektedir. Buna fq_codel denir ve artık çoğu Linux'ta yaygın olarak bulunmaktadır ve BSD'ye de taşınmıştır. Openwrt bariyer kırıcı, cerowrt ve gargoyle'deki varsayılan "QoS" nin bir parçası, ACC adı verilen yenilikçi bir otomatik hız ayarlama şemasına sahip sfqred adlı (oldukça iyi) daha eski bir sürümü kullanıyor.

Böylece, yanlış davranan bağlantınızın önünde buna dayalı bir kutuyu çarpabilir, QoS hız sınırlayıcılarını açabilir (sağlayıcıların gelen ve giden ayarlarının biraz altında ayarlanır, böylece kontrolü ele alırsınız) + fq_codel ve onu kullanan herkes için çok daha iyi performans elde edebilirsiniz . Şaşırtıcı bir şekilde daha iyi demek istiyorum : aşağıdaki ietf demosuna, ietf'deki iccrg çalışma grubuna rapor vb.

Bufferbloat problemi ve bunun düzeltmeleri hakkında daha fazla bilgi için, bkz:

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

Elbette, çeşitli ISS CPE satıcılarını dikkat çekmeye ikna etmeye çalışıyoruz, aynı zamanda birkaç ay önce bu yeni şeylerin harika bir çalışmasını yayınlayan ve özellikle kablo modemlerin mevcut yanlış davranışı hakkında bazı ayrıntılar içeren kablo etiketleri.

http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

Gördüğünüz şey tamamen tipik. Birçok servis sağlayıcı, zaman zaman servis reddi saldırılarında kullanıldığından ICMP'nin önceliğini (geleneksel ping ve traceroute içeren) düşürmek için limiti değerlendirecek ve / veya bir QoS mekanizması kullanacaktır.

Bir bağlantı sıkışık olmasa da, azalan öncelik, trafik kuyruğa alınmadığı için hiçbir şeyi etkilemez. Bu dönemlerde, ICMP paketleri derhal iletileceği ve hiç gecikmeyeceği için gecikmeniz düşük kalır.

Bağlantı tıkandığında, yüksek öncelikli kuyruklar daha fazla dikkat çeker. Kuyruk mekanizmasına bağlı olarak, her paket için daha yüksek öncelikli bir kuyruktan birden çok paketi daha düşük öncelikli bir kuyruktan iletebilir veya yalnızca daha yüksek öncelikli kuyrukta hiçbir şey olmadığında iletebilir. Her halükarda, daha düşük öncelikli bir kuyruğa düşürülen bir paket, genellikle tıkanıklığı olmayan bir bağlantıdan daha uzun süre geri tutularak gecikmeyi artırır.

Muhtemelen bufferbloat'tan muzdaripsiniz ve AQM (Aktif Kuyruk Yönetimi) istiyorsunuz. Linux için bunu oldukça kolaylaştıran bir senaryo yazdım:

#!/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

En basitinden senaryoyu kurtarmak traffic-shapingve chmod a+xonu ve (açıkçası, kaynak kodu okuduktan sonra) root olarak çalıştırın.

Kullanım durumunuz için,

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