Skip to content
Բոլոր հոդվածները
Ստանդարտներ և մեթոդիկա

Ինչպես ենք փորձարկում TCP թողունակությունը. պատուհան, RTT և SLA

Alexander Zemskov 4 րոպե ընթերցում
Ինչպես ենք փորձարկում TCP թողունակությունը. պատուհան, RTT և SLA

Պրովայդերը վաճառել է 1 Gbit/s։ Y.1564 ընդունման թեստը և RFC 2544 թեստն անցել են line rate-ով՝ զրո կորստով, գրասենյակից speed test-ը ցույց է տալիս 900-ից ավելի, իսկ գիշերային backup-ը դեպի երկրորդ տվյալների կենտրոն աշխատում է 28 Mbit/s արագությամբ։ Ոչ ոք չի ստում։ Speed test-ը խոսում է մի քանի միլիվայրկյան հեռավորության վրա գտնվող սերվերի հետ բազմաթիվ հոսքերով, UDP թեստը լցնելու պատուհան չունի, իսկ backup-ը մեկ TCP կապ է 92 մվ RTT-ով։ RFC 6349-ը չափում է հենց երրորդ դեպքը, այն, որից բողոքում են օգտատերերը։

Ստենդը

RFC 6349-ին պետք են երկու TCP host, որոնցում կարելի է սահմանել պատուհանը, գրանցել յուրաքանչյուր վերահաղորդում և ժամանակային դրոշմ դնել սեգմենտներին։ CloudLAB-ում host-երի դերը կատարում են տրաֆիկի գեներատորի պորտերը՝ ապարատային TCP stack-երով մինչև 100 GbE, կենդանի կապուղում մենք թեստային host-եր ենք դնում երկու ծայրերում։ Նրանց միջև ուղին է՝ հաճախորդի կապուղի, փորձարկվող սարք կամ WAN էմուլյատոր՝ թիրախային ցանցի RTT-ով և կորուստով, 1-ից 300 մվ և 0-ից 1%։

Մինչ ուղին կմիացվի, երկու host-երը միացվում են անմիջապես իրար և պետք է լցնեն կապուղին առանց որևէ վերահաղորդման։ 64 KB լռելյայն պատուհանով նոութբուքը չափում է իր սեփական սահմանը և այն անվանում ցանց։

Ինչ ենք ստուգում

  • Ուղու MTU. զոնդավորում ըստ RFC 4821-ի յուրաքանչյուր ուղղությամբ, առանց ICMP-ին վստահելու, քանի որ firewall-ները այն նետում են, հետագա բոլոր թեստերի MSS-ը որոշվում է այս արժեքով
  • Բազային RTT. առնվազն մեկ րոպե չափումներ ազատ ուղում՝ նվազագույն, միջին և առավելագույն
  • Նեղ տեղի թողունակություն. layer 2/3 թեստ գտնված MTU-ով, պահանջվում է զրո կորուստ, RTT-ի հետ միասին այն տալիս է bandwidth-delay product-ը՝ 2,5 MB 1 Gbit/s-ի և 20 մվ-ի դեպքում
  • Մեկ կապ BDP-ին հավասար պատուհանով. 30 վայրկյան, երեք թեստ, այն, ինչ ստանում է մեկ backup հոսքը
  • Մի քանի կապ. 4, 8 կամ 16, որոնց պատուհանների գումարը հավասար է BDP-ին, 1-ի և N-ի տարբերությունը ցույց է տալիս սահմանափակում մեկ հոսքի մակարդակում
  • Երկու ուղղություն. յուրաքանչյուրն առանձին, ապա երկուսը միասին, որտեղ երևում են ասիմետրիկ shaper-ը կամ ACK compression-ը հետադարձ ուղում
  • Երեք մետրիկա յուրաքանչյուր կետի համար. TCP Transfer Time Ratio՝ իդեալականի դիմաց, TCP Efficiency՝ առաջին անգամից ուղարկված բայթերի բաժինը, Buffer Delay՝ RTT-ի աճը բեռի տակ
  • TCP-ի վրա ազդող սարքեր. firewall, shaper կամ SD-WAN edge host-երի միջև, չափում դրանով և առանց դրա

Մեկ մետրիկան պատճառը չի անվանում, ուստի կարդում ենք երեքը միասին։ 100%-ից ցածր Efficiency-ն նշանակում է կորուստ ուղում։ Բարձր Buffer Delay առանց կորստի նշանակում է հերթ նեղ տեղից առաջ։ Տասնյակների հասնող Transfer Time Ratio մաքուր մյուս մետրիկաներով նշանակում է host-ի պատուհան։

Ինչն է սովորաբար խափանվում

Պատուհանը։ Տիպիկ դեպք. միջազգային 1 Gbit/s կապուղի, RTT-ն 92 մվ է, BDP-ն՝ 11,5 MB, իսկ backup սերվերը պատուհանը սահմանափակում է 320 KB-ով։ 320 KB-ը 92 մվ-ի վրա տալիս է 28 Mbit/s։ Հայտը շաբաթներով շրջում է պրովայդերի և IT թիմի միջև։ BDP-ին հավասար պատուհանով և 8 կապով նույն կապուղին տվեց 905 Mbit/s, իսկ լուծումը սերվերի կարգավորումներում երկու տող էր։

Երկրորդ. կորուստ, որն աննկատ է։ 99,6% TCP Efficiency-ն հաշվետվությունում մաքուր է թվում։ 20 մվ RTT-ի դեպքում դա բավական է throughput-ը երկու երրորդով կրճատելու համար, քանի որ TCP-ն յուրաքանչյուր կորստից հետո դանդաղում է, և վերականգնվելու համար նրան պետք են բազմաթիվ RTT-ներ։ Այստեղ սովորաբար ավարտվում է պրովայդերի և հաճախորդի վեճը, քանի որ վերահաղորդումները capture-ում են՝ ժամանակով և ուղղությամբ։

Երրորդ. հերթը։ Պրովայդերի եզրում shaper-ն ունի խորը բուֆեր։ Throughput-ը լավ է թվում, իսկ RTT-ն աճում է ազատ ուղու 20 մվ-ից մինչև 37 մվ բեռի տակ, Buffer Delay-ը 85% է։ Նույն կապուղով ձայնը զգում է այդ 17 մվ-ից յուրաքանչյուրը։

Ինչ կա հաշվետվության մեջ

Մեկ աղյուսակ յուրաքանչյուր ուղղության համար՝ throughput ըստ կապերի քանակի Mbit/s-ով և որպես հասանելի առավելագույնի բաժին (949 Mbit/s 1 GbE-ում 1500 B MTU-ով), երեք մետրիկաները և MTU-ն ու RTT-ն, որոնցով դրանք չափվել են։ Host-երի կարգավորումները՝ TCP stack, window scaling, SACK, offload-ներ։ Capture յուրաքանչյուր տողի հետևում։ Յուրաքանչյուր ձախողված կետի համար ախտորոշման մեկ տող՝ host-ի պատուհան, կորուստ ուղում կամ հերթագրում։ Մենք վաճառում ենք թեստը, պրովայդերը վաճառում է կապուղին, ուստի երկու կողմերն էլ կարդում են նույն թվերը։

Որտեղից սկսել

Ուղարկեք մեզ ուղին՝ երկու վերջնակետերը, կապուղու արագությունը, RTT-ն, եթե այն հայտնի է, և այն, ինչ պետք է փոխանցվի դրանով։ Մենք պատասխանում ենք թեստի պլանի նախագծով՝ թեստերը, պատուհանները, կապերի քանակը և ժամկետները։ Հաշվետվությունը մնում է Ձեզ, և Դուք կարող եք այն ցույց տալ պրովայդերին։ Գրեք մեզ կամ տեսեք, թե էլ ինչ է անում ստենդը։

Հեղինակ

Alexander Zemskov

Ցանցերի և անվտանգության թեստավորման փորձագետ և վաճառք (19+ տարի) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel և այլն

Բլոգ

Կարդացեք նաև

Պահոցներ և տվյալների կենտրոններ

Ինչպես ենք փորձարկում պահեստավորման ցանցերը. incast, PFC և p99

NVMe/TCP պահեստավորման զանգվածի բնութագրում գրված է 11 GB/s։ Թիվը չափվել է ուղիղ մալուխով, բլոկի մեկ չափով և դատարկ պորտով։ Արտադրական ցանցում զանգվածը կանգնած է ToR զույ…

Alexander Zemskov 4 րոպե ընթերցում
Ստանդարտներ և մեթոդիկա

Ինչպես ենք փորձարկում վեբ պորտալները բեռի տակ. սցենարներ և p99

Պորտալի բեռնվածության թեստը հաճախ հանգում է մեկ URL-ի և մեկ թվի. գլխավոր էջը պատասխանում է, ասենք, վայրկյանում 8000 հարցման, ուրեմն կայքը պատրաստ է։ Հետո ժամը 9:00-ին մի …

Alexander Zemskov 4 րոպե ընթերցում