Akamai odrazil rekordní útok, přicházelo při něm 809 milionů paketů za sekundu

1 byte nákladu, urcite? Payload, se bezne preklada jako "zatez". https://cs.wikipedia.org/wiki/Paket

Payload se překládá jako užitečná zátěž nebo náklad. Důležitý je smysl toho sdělení, ne přesný překlad jednoho slova. Z hlediska paketu jsou užitečná data nákladem.

Kapku jste přehlédnul, že se nenacházíte v mezinárodní lodní dopravě. Ale když si může někdo napsat do vizitky „Linux odborník“, tak se to dá pochopit.

Jaký je tedy správný pojem mimo lodní dopravu?

Já jsem si takovou věc nikdy do vizitky nedal, to by mi upadla ruka. Kolegy jsem žádal, aby to opravili, myslím, že už by to nikde takhle být napsané nemělo. Pokud to někde ještě uvidím, nechám to znovu předělat.

Např. (užitečný) obsah nebo data. Všiměte si, že se jedná o výrazy zcela neutrální - zbytečné užití přenesených významů, natož okřídlených výrazů či doslovných překladů nemá v technickém jazyku co dělat.

Možná, ale podepsaný jste tam byl vy, ne ti kolegové.

V mezinárodní lodní dopravě by „zátěž“dávalo mnohem větší smysl, než u paketu. Myslím, že náklad na lodi má nějakou tíhu, virtuální bajty nikoli.

Měli bysme zrušit i označení jako zatížení/vytížení systému/procesoru, když ty virtuální bajty nic neváží.

Především si myslím, že to v češtině není nijak ustálené. Technici jsou líní hledat česká slova, dávají i v česky psaném textu přednost anglickým. Vypadá to příšerně, je to nekulturní, ale mnozí to považují za přednost a atribut jejich vzdělání.

Dělá mi radost, když vidím snahu sdělovacích prostředků užívat náš jazyk. Náklad paketu je podle mě v češtině výstižnější, než zátěž. V jiných oborech může být zátěž naopak příhodnějším překladem.

Hlavně je konina takovou okrajovost vůbec řešit :).

Z hlediska jazykového purismu je samozřejmě i náklad paketu špatně. Pakety sice nosil Švejk, ale Hašek to použil jako jasný germanismus.
Z mého pohledu je náklad paketu příjemně srozumitelný.

Podle mě naopak míchání anglické a české terminologie by byla známka nedostatečné odbornosti. Rootu v propagování české terminologie fandím.

26. 6. 2020, 14:10 editováno autorem komentáře

Myslím si, že po těch tisících článků, zpráviček, přednášek, školení a minimálně jedné knihy už má Petr na "Linux odborník" na vizitce nárok.

Odhliadnuc od toho, že takýto otrocký preklad výrazu z angličtiny znie príšerne (malo by to byť skôr "Odborník na Linux"), súhlasím.

To jakože když se stanu znalým v jednom oboru, tak mi to dává právo na prznění jiného oboru?

Achjo, pak se divíme, že IT lidé jsou považováni za asociály. :-)

Palec nahoru kdo poprve slysi vyraz "náklad" pro payload.

Vidím to poprvé, ale přišlo mi to hned srozumitelné a příhodně zvolené.

Asi Vám nic nebrání to tak používat, podle mě to bude srozumitelné stejně tak.

Mě spíš zaujalo UDP :-)
*UDP* na port 80? To já už bych posílal radši TCP SYN :-) A popravdě... na portu 80 poběží nejspíš jenom nějaký jednořádkový redirect na HTTPS na portu 443... Velmi energické plácnutí do vody... nebo ne? Žeby někdo testoval konkrétně QUIC?
https://en.wikipedia.org/wiki/QUIC

Nojo, ale kdyby šlo o QUIC (UDP na portu 80) tak 1 bajt payloadu by byl stejně asi málo i na počáteční handshake...
To vážně vypadá spíš jako stress-test infrastruktury switchů a routerů.

Proti SYN flood útoku už dlouho existují velmi účinné ochrany prakticky všude po cestě k cíli (např. stateful firewally to rozpoznají a zaříznou), zatímco ten UDP flood proleze bez omezení.

28. 6. 2020, 11:50 editováno autorem komentáře

Díky za reakci, zjevně máte přehled. Měl byste čas to trochu rozvést? Mě totiž překvapuje, že čekáte obranu proti SYN flood "všude po cestě". Já bych to na základě svých reznoucích zkušeností viděl trochu jinak :-)

Pokud začnu na konci u zombíka = na napadeném počítači u někoho doma nebo v malé firmě, tak první po cestě bude nějaký SoHo router. Ten určitě dělá NAT/maškarádu směrem ven, takže stateful inspection a connection tracking tabulka tam bude určitě. Ale rate-limit na TCP SYN směrem ven? Pochybuju. Ačkoli je možné, že i ten jeden zombík malému SoHo routeru pěkně ucpe conntrack tabulku, zejména pokud bude střídat zdrojové TCP porty = tomu bych rozuměl.

Pokud není po cestě od zombíka do divokého internetu žádný další NAT, tak už bych tam tím méně čekal box, který bude mít sílu, dělat jednotlivým SoHo koncákům rate-limit proti SYN floodingu. (Možná jsem mimo branži už moc dlouho.) Pokud to neudělá CPE, tak osobně na access vsázím míň. Páteře se tím myslím už vůbec nezabývají (core, provider edge a podobné routery) - ledaže v dnešní době SDN by měly API pro selektivní filtrování příchozího trafficu na konkrétní lokální cíle, na požádání. To si cucám z prstu.

Jak se blížíme k serverovému konci tak uznávám, že banky a podobné finanční instituce mívají nejeden firewall, a nebývají to firewally levné :-) Ovšem pokud se týče samotného webového "serveru v první linii", tak před ním může být předsunutý cca 1 firewall. Pokud vůbec nějaký. Konkrétně když slyším AKAMAI, tak mi to zní spíš jako nějaký cloud/farma, nájemné paralelizované řešení stavěné na vysokou průchodnost. Tam bych před serverem nečekal předsunutý klasický dýchavičný firewall - ale co třeba content switch? Nějaký load-balancer, patrně postavený na HW akceleraci. A souhlas, ten by asi mohl umět reagovat na SYN flood.

Takže nakonec, pokud srovnám možnost zaútočit na port 80 TCP, vs. port 80 UDP, tak při použití TCP SYN floodingu aspoň trochu potrápím connection tracking na straně serveru (resp. v předsunutém content switchi) - kdežto UDP na port 80 bude padat rovnou do /dev/null, pokud náhodou není ve firewallu / content switchi explicitně nakonfigurován jako podporovaný. Pokud UDP není podporovaný, tak jeho dropnutí je výpočetně mnohem míň náročné, než reakce na TCP syn flooding na bázi rate-limitu navázaného na connection tracking.

Hm tyjo... tak jsem si přečetl takové povrchní overview, co všechno umí Cisco Nexus v rámci "Inband Network Telemetry" a trochu mi klesla čelist :-)