Compressione dei nomi di dominio

Sono curioso di sapere come si possa comprimere in modo molto compatto il dominio di un nome host IDN arbitrario (come definito da RFC5890 ) e sospetto che questo potrebbe diventare una sfida interessante. Un host Unicode o un nome di dominio (etichetta U) è costituito da una stringa di caratteri Unicode, in genere vincolati a una lingua a seconda del dominio di primo livello (ad esempio lettere greche sotto .gr), che è codificato in una stringa ASCII che inizia con xn--(il corrispondente Un'etichetta).

Uno può costruire modelli di dati non solo dai requisiti formali che

ogni etichetta non Unicode deve corrispondere a una stringa ^[a-z\d]([a-z\d\-]{0,61}[a-z\d])?$;
ogni etichetta A deve corrispondere a una stringa ^xn--[a-z\d]([a-z\d\-]{0,57}[a-z\d])?$; e
la lunghezza totale dell'intero dominio (etichette A e etichette non IDN concatenate con i delimitatori '.') non deve superare 255 caratteri

ma anche da varie euristiche, tra cui:

le etichette a U di ordine inferiore sono spesso frasi valide dal punto di vista lessicale, sintattico e semantico in un linguaggio naturale compresi nomi e numeri propri (non punteggiati tranne il trattino, spogliato di spazi bianchi e piegati per Nameprep ), con una preferenza per frasi più brevi; e
le etichette di ordine superiore sono tratte da un dizionario di SLD e TLD e forniscono un contesto per prevedere quale linguaggio naturale viene utilizzato nelle etichette di ordine inferiore.

Temo che ottenere una buona compressione di stringhe così brevi sia difficile senza considerare queste caratteristiche specifiche dei dati e, inoltre, che le librerie esistenti produrranno spese generali non necessarie al fine di soddisfare i loro casi d'uso più generali.

Leggendo il libro online di Matt Mahoney spiegato Compressione dei dati , è chiaro che un certo numero di tecniche esistenti potrebbero essere impiegate per trarre vantaggio dalle ipotesi di modellazione sopra (e / o altre) che dovrebbero tradursi in una compressione di gran lunga superiore rispetto a strumenti meno specifici.

A titolo di contesto, questa domanda è una derivazione da una precedente su SO .

Pensieri iniziali

Mi sembra che questo problema sia un ottimo candidato per la formazione offline e immagino un formato di dati compresso secondo le seguenti linee:

Una codifica Huffman del " suffisso pubblico ", con probabilità tratte da alcune fonti pubblicate di registrazione del dominio o volumi di traffico;
Una codifica Huffman di cui viene utilizzato il modello (linguaggio naturale) per le rimanenti etichette a U, con probabilità tratte da alcune fonti pubblicate di registrazione del dominio o volumi di traffico dati il contesto del suffisso del dominio;
Applicare alcune trasformazioni basate su dizionario dal modello di linguaggio naturale specificato; e
Una codifica aritmetica di ciascun personaggio nelle etichette a U, con probabilità tratte da modelli di linguaggio naturale contestualmente adattivi derivati dall'addestramento offline (e forse anche online, anche se sospetto che i dati potrebbero essere troppo brevi per fornire una visione significativa?).

— eggyal
fonte

Forse potresti scaricare un elenco di tutti i nomi di dominio e assegnare a ciascuno un numero. Questo sarebbe molto compatto.

@Dietrich Epp: In effetti - e in effetti, avevo pensato che forse i registrar avrebbero potuto pubblicare su WHOIS un numero seriale di ogni registrazione da cui questo poteva essere costruito in modo affidabile, ma purtroppo non lo fanno. Realisticamente, penso che le sfide pratiche nel mantenere un tale database lo rendano impossibile: per non parlare del fatto che tali database non gestiscono i sottodomini.

— Eggyal

... beh, se un numero è sufficiente, basta prendere i 4/6 byte dell'indirizzo ipv4 / 6: /

@arnaud: invertire è un problema - si basa su un puntatore corretto in .in-addr.arpa; si rompe anche se l'IP cambia mai.

— Eggyal

Con il metodo di Dietrich Epp (basato su circa 196 m di domini) è possibile memorizzare un nome di dominio in 28 bit (due caratteri unicode) e non si può fare di meglio. Naturalmente, una distribuzione di probabilità sui nomi di dominio può darti un numero di bit previsto molto migliore. Potresti almeno usare la codifica aritmetica per i 1 milione di domini più popolari e usare uno schema ad-hoc per il resto.

— Peter,

La codifica di Huffman è ottimale per le lettere e può sicuramente essere adattata alle sequenze. Ad esempio, se la sequenza "ab" risulta in un numero inferiore di bit rispetto ai bit per "a" e "b", è sufficiente aggiungerlo all'albero ... e così via.

... probabilmente puoi anche usare una semplice libreria che fa tutto per te con prestazioni quasi ottimali, in modo da non guadagnare molto usando il tuo algoritmo di compressione super fantasia su misura.

Penso che Huffman non sia del tutto ottimale (arrotonda al bit più vicino): la codifica aritmetica dovrebbe sempre sovraperformare. E a meno che non si applichi un modello accurato dei dati compressi, si otterranno sempre risultati non ottimali ... quindi se ogni bit è importante, le librerie generiche non possono essere sufficienti.

— Eggyal

La codifica di Huffman è asintoticamente ottimale se ignori le correlazioni tra le lettere (ad esempio, se vedi un q, allora la lettera successiva ha molte più probabilità di essere una udi quanto non sarebbe altrimenti). Ma questo non è un presupposto realistico. In pratica, queste correlazioni sono enormi e consentono di fare molto meglio dell'ingenua codifica Huffman in pratica.

— DW

@DW hai qualche consiglio su come si potrebbe fare di meglio? Sarebbe forse utile consentire la codifica di coppie o triple di personaggi contigui tramite Huffman?

— Ryan,