- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Mini-ITX
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Piacvezető tandem OLED panellel érkezik az iPad Pro
- A Fractal Design fával díszített toronyházának testvére született
- Gaming notebook topik
- A régi node-okra koncentrál a szankciók miatt Kína
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Sony MILC fényképezőgépcsalád
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Micro Four Thirds
Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Megjelenési dátumot kapott a Star Wars: Hunters
gp A tervek szerint június elején végre befut a teljes kiadás mobilokra/tabletekre és Nintendo Switch-re.
-
PROHARDVER!
Haladó szintű hálózati témák topikja
Új hozzászólás Aktív témák
-
őstag
válasz #25954560 #2520 üzenetére
Hmm..
Honnan derül ez ki, hogy "ARP DoS" a hiba oka, ha "csak" switch-ek vannak a hálózatban mint hálózati eszköz? Vagy a menedzselhető switcheken lévő opsys-el ilyeneket ki tudtál deríteni?
proxy-arp beállítás elérhető-e a switcheken? FixIP-s eszközöknek esetleg ki lehetne osztani statikusan. Több ötletem nincs, nem találkoztam még ilyen problémával.
-
MtHq
tag
válasz #25954560 #2531 üzenetére
Kicsit buta kérdés elsőre, vírus vagy Man in the middle gyanú nem merül fel? ARP Poison-olás velejárója a sok ARP csomag megjelenése. Nem lehet, hogy valamelyik géppel Man in the middle támadást hajtanak végre? Ez megmagyarázná azt is, hogy miért nem kerül bele az ARP gyorsítótárba (illetve miért ürül ki hamar=szinte azonnal) a bejegyzés. Esetleg ha managelhető a switch, belenéznék a port statisztikákba is, sok minden kiderül belőle.
[ Szerkesztve ]
-
crok
nagyúr
válasz #25954560 #10835 üzenetére
[link] + [link] és igencsak a fogadó- és|vagy küldő oldali puffer lesz a gond. Wireshark-al is nézz bele hogy követi a WIN-t az átvitel, mennyire van hézag a csomagok közt, mennyi volt az idő delta a syn és a synack közt és mennyi idő van az utolsó csomag és az ack közt, van-e psh, mekkora a WIN egyébként, van-e sack, van-e packetloss, retransmit, reorder.. etc.
[ Szerkesztve ]
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
inf3rno
nagyúr
válasz #25954560 #10835 üzenetére
Szia! :-)
Szerintem csak a protokollok (IP, TCP) fejléceit kell levonogatni a csomagméretből, aztán elosztani a csomagmérettel, és úgy kijön, hogy mi a tényleges és az elméleti sávszél aránya. Itt nagyjából le van írva, hogy melyik header mekkora: [link], illetve wireshark, amivel ellenőrizhető is a gyakorlatban a fejlécek mérete. Ennél lehet alacsonyabb, ha szakadozik a kapcsolat vagy sok a hibás csomag, amit újraküldenek. De szerintem ezeket te tudod. Lehet, hogy befolyásolja még más is ezen kívül, de ahhoz a részéhez én már nem értek. Igazából ehhez sem. :-)
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz #25954560 #10835 üzenetére
Ja bocs, most nézem, hogy wrk. Ott még hozzájön a HTTP kapcsolat felépítése és a HTTP fejlécek is minden alkalommal. Én úgy sejtem, hogy amikor elkezded letölteni a fájlt, akkor csak az elején van ez a HTTP fejléc, utána a maradék már TCP alapon megy. Van még HTTP range header, ha félbemaradt egy fájl küldés, akkor azzal lehet folytatni ugyanonnan, de egy normál letöltésnél ennek szerintem nincs szerepe. Viszont maga a kérés úgy megy, hogy a kliens küld egy HTTP GET kérést jó sok fejléccel, amire jön egy HTTP válasz szintén jó sok fejléccel és kliens és szerver beállítás függő, hogy melyik mennyi. A wrk dokumentációjában lehet, hogy benne van ez a része. Ha nincs, akkor ez wiresharkkal szintén ellenőrizhető. Gondolom itt a 100 Gbps-t úgy kell érteni, hogy csak az egyik irányba, ezért a válasz fejléceket kell csak nézned, a HTTP kérés biztosan kisebb, mint a válasz, ha 64 KB-os a HTML fájl.
Elvileg még függhet attól is, hogy egyszerre mennyi kapcsolatot tud felépíteni a webszervered. Talán még a maximális memória méret is blokkolhatja ilyen szempontból. Nézted, hogy mennyi memóriát és processzort fogyaszt az apache, és hogy tud e egyáltalán annyi szálat létrehozni, amennyire szüksége van a kiszolgáláshoz?
[ Szerkesztve ]
Buliban hasznos! =]
-
crok
nagyúr
válasz #25954560 #10842 üzenetére
"mar befolyasolja az atvitel sebesseget" -> nem, ha nem az eszközön magán veszel mintát, hanem mondjuk egy line-rate switchporton kitükrözöd a forgalmat, simán megy, tudom, én is így csinálom ha kell. Meg minek tennéd pcap-be a data-t, neked csak a header kell, nem kell a data, a data-t elkapni se kell, csomagnagyságot állítsd megfelelően kicsire hogy a data már benne se legyen. Az átvitel közepén kezdeni badarság, akkor van értelme ha megvan az eleje meg hogy mennyi a delta a syn, synack és ack közt (akkor már tudod mennyi az RTT a két Layer 7 közt, ping-el csak L3-ig (jó, L4..) tudod de onnan még fel kell kerüljön az alkalmazáshoz viszont így tudnád mennyi idő kell a csomagnak/szegmensnek az út oda-vissza és mennyi idő kell a NIC-től az alkalmazásig). Ekkora sávszél és ilyen kis idők közt számít csak igazán. Az, hogy a NIC hardware queue mekkora az nem feltétlen direkt okozója hasonló gondnak, azt a NIC stat. mutatná hogy nem fért be queue-ba valami (plusz lenne retransmit, akár csak fast), ellenben ha már maga a TCP stack nem kap elég puffert és mondjuk a küldő oldal kifogy magából a küldhető adatból akkor még a TX WIN elérése előtt lenne push-al a küldött szegmens (de a NIC ettől még nem mutatna semmit.. nem a NIC fogyott ki, ott nincs drop), de az már jel arra hogy kevés a TCP stack TX buffer mert a PSH mutatja hogy nem tud több adatot tartani a rendszer mert ha volna drop és kell retransmit akkor vissza kell szednie valahonnan az adatot, nem dobhatja a puffer tartalmát hogy új adattal töltse fel. A másik hogy a túloldalról érkezik-e pl. 0 WIN, nem-e terlhelődik szét a túloldal és nem tudja fogadni az adatot. De te tudod. Ha van TCP chimney / offload / mindegy az adott rendszer minek hívja akkor akár kapcsold ki egy próbára mert sokszor nem dolgozik jól össze a NIC az OS-el. A két linket még én írtam pár éve de ettől még a matek az matek. Ekkora különbség a UDP és a TCP header nagyságának különbségéből biztosan nem jön ki.
Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..
-
bambano
titán
válasz #25954560 #10835 üzenetére
első körben megnézném, hogy minden proci mag kap-e interruptot
második körben nem 64 Ks- html-t húzatnék le, hanem csinálnék hiányos fájlt tesztfájlnak. pl:dd if=/dev/zero of=test.dd bs=1024 seek=9999999999 count=1
és ezt tölteném le.
emellett torlódásvezérlést is lehet állítani, a default cubicnál a google féle bbr lehet jobb.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
inf3rno
nagyúr
-
gergogazd
csendes tag
válasz #25954560 #10873 üzenetére
Hát ez problémás. Az egy dolog, hogy nem csináltam ilyet soha, de a másik eszköz egy telefon. Szerintem egyszerűbb, ha abból indulunk ki, hogy a gép ssl kliensével van gond, ez esetben mit kéne csinálnom? Amúgy itt a topikban hallok először arról, hogy az ssl kliens az nem a böngésző része, hanem rendszerkomponens.
A brummogás az élet asztala.
Új hozzászólás Aktív témák
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Politika
- Mibe tegyem a megtakarításaimat?
- Android alkalmazások - szoftver kibeszélő topik
- Huawei Mate 10 Pro - mestersége az intelligencia
- gban: Ingyen kellene, de tegnapra
- Realme 8 - az igazi nyolcas
- Mini-ITX
- Kerékpárosok, bringások ide!
- Autós topik látogatók beszélgetős, offolós topikja
- További aktív témák...