Nové RFC 10055 popisuje, jak zapnout ECN u UDP socketů na Linuxu, Windows i macOS

Směrovač, kterému se plní fronta, nemusí paket zahodit. Může ho označit ve dvou bitech hlavičky IP a příjemce pak tu značku ohlásí odesílateli, jehož řízení zahlcení na ni zareaguje. Tomu se říká explicitní oznamování zahlcení (ECN) a pole pro něj zavedlo RFC 3168 už v roce 2001. U TCP to aplikace neřeší, protože značky zpracuje jádro samo a programu zbývá funkci zapnout nebo vypnout. Protokoly nad UDP, které běží v uživatelském prostoru, si ale musí značku z příchozího paketu vytáhnout samy.

Právě na ně míří RFC 10055, které IETF vydalo v říjnu 2026 jako informační dokument. Napsal ho Martin Duke z Googlu při zavádění ECN do implementace protokolu QUIC v Chromiu. Podle úvodu se tehdy ukázalo, že rozhraní socketů pro ECN jsou na řadě platforem zdokumentovaná jen chabě. RFC proto zapisuje, co se zjistilo pokusy, a samo upozorňuje, že jde o snímek stavu v době psaní. Žádné nové rozhraní nezavádí a platformám nic nepředepisuje.

Od osobního návrhu k RFC trvalo dva roky

První verze vyšla 23. srpna 2024 jako osobní návrh draft-duke-tsvwg-udp-ecn. Pracovní skupina TSVWG (Transport and Services Working Group) ho v prosinci 2024 přijala za svůj a poslední revize 08 je ze 4. května 2026, jak ukazuje záznam v datatrackeru IETF. Dokument se drží jazyků C a C++. „Apple“ v něm znamená macOS i iOS a pokyny pro Linux platí i pro Android.

Příjem chce na Linuxu jednu volbu navíc

Aby socket značky u příchozích paketů vůbec hlásil, zapíná se to na Linuxu, macOS a FreeBSD voláním setsockopt(): u IPv4 volbou IP_RECVTOS, u IPv6 volbou IPV6_RECVTCLASS. Past je v socketu IPv6, který přijímá i IPv4. Linux u něj potřebuje navíc IP_RECVTOS, jinak u paketů IPv4 značku nedostane. Apple a FreeBSD to nežádají.

Samotnou značku pak program čte z pomocných dat (ancillary data), která vrací volání recvmsg(). Linux u IPv4 přiloží zprávu typu IP_TOS s jedním bajtem a u IPv6 zprávu IPV6_TCLASS s hodnotou typu int. Apple a FreeBSD typ zprávy u IPv4 pojmenovaly jinak, IP_RECVTOS, tedy stejně jako volbu, kterou se příjem zapíná. Ve všech třech případech dostane program celý bajt, ve kterém je i šestibitové pole DSCP pro třídy provozu, a ECN jsou jeho dva nejnižší bity. RFC k tomu připomíná, že rozhraní dál mluví o bajtu „Type of Service“, přestože ho RFC 2474 nahradilo už v roce 1998.

int on = 1;
setsockopt(fd, IPPROTO_IP, IP_RECVTOS, &on, sizeof(on));
/* po recvmsg() u zprávy typu IP_TOS: */
unsigned char tos = *(unsigned char *)CMSG_DATA(cmsg);
int ecn = tos & 0x03;

Windows má vlastní funkci WSASetRecvIPEcn(). Podle dokumentace Microsoftu ji systém zná od Windows 10 Build 20348 a platí jen pro datagramové sockety. Stejného výsledku dosáhne setsockopt() s volbami IP_RECVECN a IPV6_RECVECN. RFC přidává dvě nástrahy, o kterých stránka funkce mlčí. U socketu IPv6, který přijímá i IPv4, funkce příjem pro IPv4 nezapne. U socketu navázaného na adresu IPv4 zabalenou do IPv6 (tvar ::ffff:…) vrátí chybu EINVAL. V obou případech je potřeba zvlášť zavolat setsockopt() s IP_RECVECN. Čtení je zato na Windows jednodušší: zpráva IP_ECN nebo IPV6_ECN nese jako int jen samotnou značku, bez bitů DSCP.

Odesílání umí přepsat cizí nastavení DSCP

U odchozích paketů RFC rozlišuje dva postupy. Spojení, které posílá pořád stejnou značku, si ji nastaví jednou pro celý socket, což je úspornější. Server, který přijímá všechna spojení na jediném socketu, musí značku nastavovat u každého paketu zvlášť, protože jednotlivá spojení podporují ECN různě.

Pro celý socket slouží na Linuxu, macOS a FreeBSD volba IP_TOS u IPv4 a IPV6_TCLASS u IPv6. Kromě systémů Applu ale tatáž volba přepíše i DSCP ve zbytku bajtu. Aplikace by si proto podle RFC měla dosavadní hodnotu nejdřív přečíst přes getsockopt(), aby nepřepsala, co nastavila jiná část programu. Když bajt mění víc vláken, je potřeba další ochrana. Windows nastavení pro celý socket podle dokumentu nenabízí vůbec a značku dovolí jen u jednotlivých paketů v pomocných datech typu IP_ECN nebo IPV6_ECN. Ostatní systémy k témuž používají IP_TOS a IPV6_TCLASS, s jedním rozdílem: FreeBSD bere u IPv4 jeden bajt, Linux a Apple int.

Zájem o ECN nad UDP zvedl QUIC

Podle RFC vzbudil zájem o ECN nad UDP až QUIC spolu s architekturou L4S z RFC 9330, která na značkách ECN staví nízkou latenci. U starších protokolů nad UDP je nasazení slabé. K ECN pro RTP podle RFC 6679 zná IETF výzkumnou implementaci, komerční nasazení ale potvrdit nemůže. O pokusech předávat značky mezi SCTP a socketem UDP neví vůbec.

Oddíl o bezpečnosti obsahuje jednu věc, která v původním RFC 3168 není. Když ECN umí jen některé platformy, prozradí to protějšku, jaký operační systém na druhé straně běží, a to se týká soukromí. Dokument chce tuhle možnost zmenšit tím, že popisuje všechny velké platformy najednou.

Kdo si údaje chce ověřit u sebe, má k tomu repozitář ecn-examples, na který RFC odkazuje. Napsal ho Michael Tüxen a jsou v něm jen čtyři krátké programy v C, odesílač a přijímač zvlášť pro IPv4 a IPv6. Dokument navíc jmenuje konkrétní commity zdrojových souborů Chromia z června 2026, ve kterých je postup použitý v praxi.

Zdroje

• RFC 10055: Configuring UDP Sockets for Explicit Congestion Notification (ECN) for Common Platforms
• IETF Datatracker: RFC 10055 a jeho předchozí koncepty
• Microsoft Learn: WSASetRecvIPEcn function (ws2tcpip.h)
• GitHub: nplab/ecn-examples
• RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP