Jak działają skracacze URL? Wyjaśnienie mechaniki

Otwórz elido.me/abc123, a coś musi zamienić ten krótki ciąg znaków w pełny adres internetowy, zanim przeglądarka cokolwiek wczyta. Mechanizm jest prostszy, niż większości osób się wydaje. Skracacz URL przechowuje mapowanie krótkiego kodu na długi adres docelowy. Gdy klikasz krótki link, usługa traktuje kod jako klucz wyszukiwania, znajduje adres docelowy i zwraca przekierowanie HTTP, które mówi przeglądarce, dokąd naprawdę ma przejść. Jedno żądanie na wejściu, jedno przekierowanie na wyjściu.

To cała idea. Cała reszta to inżynieria wokół trzech nacisków: sprawić, by wyszukiwanie było szybkie, utrzymać kody krótkie i unikalne oraz zarejestrować kliknięcie, nie spowalniając nikogo. Ten wpis krok po kroku pokazuje, jak działają skracacze URL od początku do końca, wykorzystując architekturę brzegową Elido jako konkretny przykład, ale zachowując wyjaśnienie prawdziwe także dla skracaczy w ogóle. Omówimy mapowanie slug-URL, sposób generowania krótkich kodów, miejsce przechowywania danych, wybór między przekierowaniem 301 a 302, który myli więcej osób niż cokolwiek innego, jak przekierowanie HTTP naprawdę wygląda "na drucie", dlaczego pamięć podręczna na brzegu sieci ma znaczenie, oraz jak kliknięcie jest liczone asynchronicznie.

Jak działają skracacze URL: mapowanie w centrum

Odejmij całą infrastrukturę, a skracacz URL okaże się magazynem klucz-wartość z doczepionym do niego handlerem przekierowania. Kluczem jest slug, czyli krótki kod po domenie. Wartością jest adres docelowy, długi URL, który wkleiłeś na początku.

Gdy tworzysz krótki link, skracacz zapisuje jeden wiersz: ten slug wskazuje na ten adres docelowy. Gdy ktoś odwiedza krótki link, skracacz odczytuje ten wiersz z powrotem i działa na jego podstawie. Tworzenie linków jest rzadkie, odczytywanie ich jest ciągłe. Pojedynczy link marketingowy może zostać zapisany raz, a potem odczytany kilkaset tysięcy razy w ciągu swojego życia. Ta przewaga odczytów nad zapisami jest najważniejszym faktem dotyczącym tego obciążenia i kształtuje każdą kolejną decyzję projektową, zwłaszcza dotyczącą pamięci podręcznej.

Samo mapowanie może nieść więcej niż tylko adres docelowy. W Elido slug może przechowywać reguły targetowania, dzięki czemu jeden krótki link kieruje do różnych adresów docelowych w zależności od kraju, urządzenia, języka czy pory. To właśnie nazywamy smart linkiem i wciąż jest to to samo wyszukiwanie, tylko z małą ewaluacją reguł po odczycie. Podstawowa relacja nigdy się nie zmienia: slug na wejściu, adres docelowy na wyjściu.

Generowanie krótkiego kodu

Jeśli slug jest kluczem, to skąd się bierze? Istnieją dwa sprawdzone podejścia i większość skracaczy używa jednego z nich albo ich połączenia.

Pierwsze to kodowanie ID z bazy danych w systemie base62. Każdy nowy link dostaje z bazy danych automatycznie zwiększającą się liczbę całkowitą jako ID. Kodujesz tę liczbę w base62, który wykorzystuje 62 bezpieczne dla adresów URL znaki: a-z, A-Z i 0-9. ID 1 staje się b, ID 125 staje się dwuznakowym kodem i tak dalej. Base62 jest gęste: trzy znaki obejmują około 238 000 linków, pięć znaków obejmuje mniej więcej 916 milionów, sześć obejmuje około 56 miliardów. Kody pozostają krótkie i, ponieważ mapują się jeden do jednego na unikalne ID, nigdy się nie zderzają. Kompromisem jest to, że sekwencyjne ID są łatwe do odgadnięcia, więc wiele systemów tasuje albo przesuwa przestrzeń ID przed zakodowaniem.

Drugie podejście to generowanie losowe. Wybierasz losowy ciąg znaków o stałej długości z tego samego alfabetu, a następnie sprawdzasz w bazie danych, czy nie jest już zajęty. Jeśli dojdzie do kolizji, generujesz kolejny. Przy rozsądnych długościach kolizje są znikomo rzadkie, więc pętla ponawiania niemal nigdy się nie uruchamia. Losowe slugi nie są enumerowalne, co jest argumentem bezpieczeństwa przemawiającym za nimi. Jeśli chcesz zamienić to w działający kod, jak zbudować skracacz URL krok po kroku pokazuje kodowanie, ścieżkę przekierowania i elementy, które ujawniają się dopiero na produkcji.

Niestandardowe slugi, te brandowane jak elido.me/spring-sale, nakładają się na dowolny z tych schematów. Użytkownik podaje ciąg znaków, a skracacz waliduje dozwolone znaki i sprawdza unikalność względem tego samego indeksu przed zapisaniem. Niezależnie od tego, czy slug jest wygenerowany, czy wybrany ręcznie, trafia w to samo miejsce: unikalną kolumnę w magazynie danych.

Gdzie mieszkają dane

Mapowanie slug-adres docelowy potrzebuje domu, który potrafi szybko i spójnie odpowiedzieć na pytanie "na co wskazuje ten slug". Jako źródło prawdy tym domem jest niemal zawsze relacyjna baza danych. Elido używa relacyjnej bazy danych, w której slug jest przechowywany jako unikalna, indeksowana kolumna, dzięki czemu wyszukiwanie to pojedynczy odczyt po kluczu, a nie przeszukiwanie całej tabeli. Baza danych przechowuje kanoniczny rekord dla każdego linku, użytkownika i przestrzeni roboczej.

Ale odpytywanie bazy danych przy każdym pojedynczym kliknięciu byłoby marnotrawstwem, biorąc pod uwagę przewagę odczytów. Wyszukanie sluga po kluczu w bazie danych trwa zwykle od jednej do trzech milisekund, co brzmi szybko, dopóki nie pomnożysz tego przez wolumen kliknięć wiralowego linku i nie przypomnisz sobie, że połączenie z bazą danych jest zasobem skończonym. Dlatego skracacze produkcyjne stawiają przed bazą danych pamięć podręczną. To właśnie w pamięci podręcznej obsługiwana jest większość odczytów; baza danych jest rozwiązaniem awaryjnym dla wszystkiego, czego pamięć podręczna jeszcze nie ma.

Elido uruchamia przed bazą danych dwupoziomową pamięć podręczną. Pierwszy poziom to wewnątrzprocesowa pamięć podręczna LRU żyjąca wewnątrz samego binarnego pliku przekierowań, która zwraca adres docelowy w kilkaset nanosekund, bez żadnego przelotu sieciowego. Drugi poziom to klaster pamięci podręcznej w pamięci operacyjnej w tym samym regionie, który odpowiada w mniej niż milisekundę. Dopiero zimne chybienie, slug, którego żaden z poziomów nie widział ostatnio, przechodzi do wywołania gRPC do naszego API, które odczytuje bazę danych. Łączny współczynnik trafień na obu poziomach pamięci podręcznej wynosi około 99,4%, więc baza danych jest odpytywana mniej więcej przy jednym żądaniu na 167. Pełny opis tego, jak zachowuje się ta pamięć podręczna, łącznie z polityką wypierania i trybami awarii, na jakie trafiliśmy, znajdziesz w naszym opisie strategii pamięci podręcznej dla przekierowań URL.

Czym naprawdę jest przekierowanie HTTP

Gdy skracacz zna już adres docelowy, musi przekazać go z powrotem przeglądarce. Robi to za pomocą przekierowania HTTP, które jest po prostu konkretnym rodzajem odpowiedzi. Zamiast zwracać treść strony z kodem 200 OK, serwer zwraca kod statusu 3xx oraz nagłówek Location wskazujący prawdziwy adres URL. Na drucie odpowiedź jest niewielka:

HTTP/1.1 302 Found
Location: https://shop.example.com/spring-collection
Content-Length: 0

Przeglądarka odczytuje kod statusu, widzi nagłówek Location i natychmiast wysyła nowe żądanie pod ten adres. Dla osoby klikającej wygląda to jak jedna nawigacja; pod spodem są to dwa żądania, a krótki link działa pośrodku jako szybkie wyszukanie w katalogu. Semantyka każdego kodu 3xx jest zdefiniowana w RFC 7231, a przewodnik Mozilli po przekierowaniach HTTP jest najbardziej przejrzystym praktycznym źródłem informacji o tym, który kod robi co.

Treść odpowiedzi jest pusta, bo nie ma nic do wyrenderowania. Cały ładunek to linia statusu i nagłówek. To częściowo tłumaczy, dlaczego przekierowania są tanie w obsłudze: nie ma szablonu, nie ma złączenia w bazie danych dla treści, nie ma znaczników. Rozwiąż slug, ustaw jeden nagłówek, wyślij.

301 kontra 302: wybór, który decyduje o Twojej analityce

To tutaj skracacze po cichu podejmują decyzję, której większość użytkowników nigdy nie widzi, a która decyduje o tym, czy ich link jest edytowalny i mierzalny. Kod statusu przekierowania to nie formalność. Dwie powszechne opcje zachowują się zupełnie inaczej.

301 Moved Permanently mówi przeglądarce oraz każdemu proxy i CDN-owi pomiędzy Tobą a serwerem, że ten krótki link zawsze będzie wskazywał to samo miejsce. Więc go zapisują w pamięci podręcznej. 301 jest agresywnie przechowywany. Przy kolejnym kliknięciu tego krótkiego linku przeglądarka odwiedzającego może rozwiązać go z pamięci podręcznej i w ogóle nie skontaktować się ze skracaczem. To świetnie skraca przelot sieciowy, ale jest katastrofą dla narzędzia do linków, bo psują się dwie rzeczy. Po pierwsze, analityka staje się ślepa: kliknięcia obsłużone z pamięci podręcznej przeglądarki nigdy nie docierają do Twojego serwera, więc nigdy nie zostają policzone. Po drugie, adres docelowy jest w praktyce zamrożony. Jeśli zmienisz, dokąd link prowadzi, każdy, kto już zapisał 301 w pamięci podręcznej, nadal trafia na stary adres, aż jego pamięć podręczna wygaśnie, a Ty nie masz nad tym kontroli.

302 Found (i jego bardziej rygorystyczny kuzyn 307 Temporary Redirect) mówi przeglądarce, że to tymczasowe: wróć i zapytaj ponownie następnym razem. Przeglądarka nie zapisuje mapowania w pamięci podręcznej, więc każde kliknięcie ponownie odpytuje krótki link u serwera. Ten dodatkowy przelot sieciowy jest właśnie tym, czego potrzebuje narzędzie do linków. Każde kliknięcie dociera do Twojej infrastruktury, więc każde kliknięcie jest policzalne, a ponieważ serwer za każdym razem rozwiązuje adres docelowy na świeżo, możesz zmienić, dokąd link prowadzi, i nowy cel zacznie obowiązywać już przy następnym kliknięciu. Kosztem jest jeden przelot sieciowy na kliknięcie, który dobrze zbudowany brzeg sieci utrzymuje w granicach pojedynczych milisekund.

Dlatego Elido domyślnie używa 302. Edytowalne adresy docelowe i dokładne dane o kliknięciach to cały sens zarządzanego linku, a 301 oddaje obie te rzeczy w zamian za optymalizację pamięci podręcznej, której zwykle wcale nie chcesz. RFC 7231 wprost mówi, że 301 jest domyślnie cache'owalny, podczas gdy 302 nie jest przechowywany, chyba że nagłówki mówią inaczej, co dokładnie odpowiada temu, czego wymagają te dwa przypadki użycia. Są wąskie sytuacje, w których przekierowanie trwałe jest właściwe, na przykład prawdziwa migracja domeny, ale dla śledzonych, edytowalnych krótkich linków właściwym domyślnym wyborem jest przekierowanie tymczasowe. Jeśli rozważasz konkretnie stronę SEO tego wyboru, czyli czy krótki link kosztuje Cię pozycję w rankingu, omawiamy to w czy skracacze URL szkodzą SEO, a wpis 301 kontra 302 waży decyzję między trwałym a tymczasowym od początku do końca.

Pamięć podręczna na brzegu sieci dla niskiego opóźnienia

Przekierowanie jest synchroniczne i blokujące. Przeglądarka odwiedzającego zatrzymuje się na krótkim linku, aż przyjdzie przekierowanie, i dopiero wtedy może zacząć wczytywać stronę, na której naprawdę zależy. Każda milisekunda spędzona na rozwiązywaniu sluga to milisekunda doliczona do czasu oczekiwania odwiedzającego. Dlatego poważne skracacze przesuwają wyszukiwanie jak najbliżej odwiedzającego.

Elido uruchamia handler przekierowania w punktach obecności na brzegu sieci w regionie UE, na wschodnim wybrzeżu USA i w Azji-Pacyfiku, kierując ruch do najbliższego z nich. Handler działa na naszej dedykowanej usłudze brzegowej, której ścieżka żądań bez alokacji pamięci utrzymuje przewidywalne opóźnienie nawet przy trwałym obciążeniu. W połączeniu z pamięcią podręczną w pamięci operacyjnej utrzymuje to przekierowania na poziomie p95 poniżej 15ms przy trafieniu w pamięci podręcznej, mierzone na POP-ie: jednocyfrowa mediana w milisekundach w regionie, rosnąca do około 14ms p95 w bardziej odległych regionach, gdzie geografia jest większa. Większość tego budżetu to fizyczny transport sieciowy, nieunikniona odległość między odwiedzającym a najbliższym POP-em, czyli część, której nie da się zoptymalizować w oprogramowaniu. Pełny budżet opóźnienia i to, jak wypada każdy region, opisaliśmy w artykule o osiąganiu p95 poniżej 15ms.

Umieszczenie wyszukiwania na brzegu sieci, zamiast na pojedynczym centralnym serwerze, to różnica między przekierowaniem, które wydaje się natychmiastowe, a takim, które dodaje zauważalne zatrzymanie. To także powód, dla którego routing anycast na brzegu sieci wygrywa przy tym obciążeniu z konfiguracją opartą tylko na DNS, co porównujemy w artykule Edge POP vs routing DNS-only. Krótko mówiąc: sieć zajmuje się geografią, a pamięć podręczna zajmuje się szybkością.

Liczenie kliknięcia bez spowalniania przekierowania

Skracacz, który tylko przekierowuje, byłby zwykłą usługą przekierowań. Tym, co czyni go narzędziem do zarządzania linkami, jest to, że liczy każde kliknięcie i mówi Ci, kto kliknął, skąd i na jakim urządzeniu. Trudną częścią jest zrobienie tego bez zmuszania odwiedzającego, by na to czekał.

Odpowiedzią jest całkowite rozdzielenie tych dwóch rzeczy. Gdy handler przekierowania rozwiąże slug, od razu wysyła odpowiedź 302. Zarejestrowanie kliknięcia dzieje się później, jako zadanie typu fire-and-forget. Handler dopisuje zdarzenie kliknięcia, slug, znacznik czasu, obcięty adres IP, hash user-agenta, do kolejki komunikatów i idzie dalej. Nie czeka na potwierdzenie zapisu. Jeśli kolejka jest chwilowo niedostępna, kliknięcie zostaje odrzucone zamiast opóźniać przekierowanie; świadomie zdecydowaliśmy, że utrata kliknięcia przy awarii infrastruktury jest do zaakceptowania, a niepowodzenie przekierowania nie.

Elido używa jako tej kolejki naszego strumienia zdarzeń. Osobny konsument, click ingester, odczytuje zdarzenia z kolejki i zapisuje je w naszym kolumnowym magazynie analitycznym, zbudowanym pod obciążenie typu dopisz-i-agreguj o dużym wolumenie, jakim jest analityka kliknięć. Przekierowanie odwiedzającego zakończyło się już milisekundy wcześniej; wiersz analityczny ląduje kilka sekund później, całkowicie poza ścieżką krytyczną. Wyjaśniamy projekt tej kolejki w ingestii kliknięć typu fire-and-forget, a dlaczego magazyn kolumnowy bije w tym zastosowaniu relacyjną bazę danych, w artykule dlaczego używamy ClickHouse do analityki kliknięć.

To rozdzielenie jest powodem, dla którego Twoja analityka może być szczegółowa, nie będąc przy tym wolna. Ścieżka przekierowania pozostaje lekka, bo żadne liczenie, ocenianie ani agregacja nie dzieje się, gdy odwiedzający czeka.

Składając to razem

Skracacz URL, od początku do końca, to krótka sekwencja. Tworzysz link, a skracacz zapisuje w swojej bazie danych mapowanie slug-adres docelowy, generując albo walidując slug jako unikalny klucz. Odwiedzający klika, żądanie trafia do najbliższego brzegowego POP-a, a handler rozwiązuje slug z pamięci podręcznej wewnątrzprocesowej, przechodząc do pamięci podręcznej w pamięci operacyjnej, a potem do bazy danych tylko przy chybieniu. Zwraca 302 z adresem docelowym w nagłówku Location, dzięki czemu kliknięcie jest policzalne, a adres docelowy pozostaje edytowalny. Następnie wysyła zdarzenie kliknięcia do kolejki, by osobny konsument je zapisał, nie zmuszając nikogo do czekania.

Każdy element z osobna jest prosty. Inżynieria tkwi w proporcjach i budżetach: obciążenie zdominowane przez odczyty, które potrzebuje pamięci podręcznej, sufit opóźnienia, który potrzebuje brzegu sieci, oraz wymóg analityczny, który musi pozostać poza ścieżką krytyczną. Jeśli chcesz budować na tym bezpośrednio, funkcja Smart Links udostępnia warstwę reguł, API i SDK pozwalają tworzyć linki z poziomu kodu, a strona rozwiązań dla deweloperów i dokumentacja architektury edge-redirect wchodzą głębiej w ruchome części. Jeśli rozważasz narzędzie, zamiast je budować, nasze artykuły czym jest skracacz URL i czy skracacze URL są bezpieczne omawiają temat od strony użytkownika, a strona z cennikiem pokazuje, gdzie kończy się darmowy plan.

Powiązane na blogu

• Osiąganie p95 < 15ms dla przekierowań z FRA, ASH i SGP
• Strategia pamięci podręcznej dla przekierowań URL: L1 LRU i L2 Redis
• Ingestia kliknięć typu 'fire-and-forget' z Redpanda
• Smart linki wyjaśnione: routing na edge bez dodatkowego serwisu
• Czy skracacze URL szkodzą SEO? Mechanika, która ma znaczenie
• 301 kontra 302: który rodzaj przekierowania powinny stosować krótkie linki
• Jak skrócić adres URL: darmowe, brandowane i zbiorcze linki
• Rodzaje przekierowań URL: 301, 302, 307, 308 i nie tylko
• Jak zbudować skracacz URL: architektura i kod
• Jak zobaczyć, dokąd prowadzi krótki adres URL, zanim klikniesz