📬 ISN 168: Różnice w obsłudze STP pomiędzy Cisco i Juniper

Narzędzie do testowania HTTP/3

Zaprojektowane i opracowane przez inżynierów Cloudflare, h3i jest darmowym, open-sourcowym narzędziem w postaci biblioteki i aplikacji konsolowej służącym do kompleksowego testowania implementacji protokołu HTTP/3 działającego w oparciu o QUIC. Narzędzie pozwala na śledzenie, analizę i generowanie specjalnie spreparowanych pakietów HTTP/3, które mogą nie być zgodne z obowiązującymi standardami. Dzięki temu możliwe jest dokładne sprawdzenie, jak dana implementacja radzi sobie z obsługą niepoprawnych lub złośliwych żądań.

Aby w pełni zrozumieć możliwości h3i, przyjrzyjmy się przykładowemu scenariuszowi jego wykorzystania. Powiedzmy, że chcemy sprawdzić, jak określona implementacja HTTP/3 radzi sobie z obsługą żądań, w których podana długość treści (Content-Length) różni się od faktycznej długości przesłanych danych. Zgodnie ze specyfikacją RFC 9114, takie żądania powinny być traktowane jako niepoprawne i odrzucane.

Za pomocą biblioteki h3i możemy łatwo przygotować kod, który wygeneruje żądanie testowe z niepoprawną długością treści i wyśle je do docelowego serwera. Oto jak może wyglądać taki przykładowy kod w Rust:

let config = Config::new()
    .with_host_port("cloudflare-quic.com".to_string())
    .with_idle_timeout(2000)
    .build()
    .unwrap();

let headers = vec![
    Header::new(b":method", b"POST"),
    Header::new(b":scheme", b"https"),
    Header::new(b":authority", b"cloudflare-quic.com"),
    Header::new(b":path", b"/"),
    Header::new(b"content-length", b"5"), // Deklarujemy długość 5 bajtów
];

let header_block = encode_header_block(&headers).unwrap();

let actions = vec![
    Action::SendHeadersFrame {
        stream_id: STREAM_ID,
        fin_stream: false,
        headers,
        frame: Frame::Headers { header_block },
    },
    Action::SendFrame {
        stream_id: STREAM_ID,
        fin_stream: true,
        frame: Frame::Data {
            payload: b"test".to_vec(), // Ale wysyłamy tylko 4 bajty
        },
    },
    // Kod oczekiwania na odpowiedź i zamknięcia połączenia
];

let summary = sync_client::connect(config, &actions).expect("connection failed");

W powyższym przykładzie generujemy nieprawidłowe żądanie, w którym deklarujemy długość treści równą 5 bajtom, ale faktycznie przesyłamy tylko 4 bajty danych. Następnie oczekujemy, że prawidłowo zaimplementowany serwer HTTP/3 odrzuci takie żądanie i odpowie kodem błędu 400 Bad Request.

Migracja z Poetry do uv

Współczesne projekty programistyczne coraz częściej opierają się na wykorzystaniu menadżerów pakietów, które znacznie upraszczają proces zarządzania zależnościami i budowania aplikacji. W ekosystemie Pythona dwa popularne narzędzia tego typu to Poetry i uv. Choć oba pełnią podobną rolę, różnią się formatem plików konfiguracyjnych. Jeśli chcesz przenieść swój projekt z Poetry na uv, proces ręcznej konwersji pliku pyproject.toml może być żmudny i podatny na błędy. Na szczęście istnieje skrypt, który zautomatyzuje to zadanie.

Convert_poetry2uv.py to skrypt Pythona stworzony z myślą o łatwej konwersji pliku pyproject.toml używanego przez Poetry do formatu akceptowanego przez uv. Po jego uruchomieniu, wygenerowany zostanie nowy plik pyproject.toml, gotowy do użycia z uv.

Skrypt dostępny jest jako niezależny pakiet na PyPI, więc instalacja jest bardzo prosta:

pip install convert-poetry2uv

Następnie możesz uruchomić go z linii poleceń, podając ścieżkę do pliku pyproject.toml:

convert_poetry2uv <ścieżka_do_pliku>

💡

Zastosowanie flagi -n spowoduje wygenerowanie pliku tymczasowego zamiast nadpisywania oryginalnego pliku.

Skrypt wykonuje dwie główne operacje podczas konwersji:

Zastępuje definicję systemu budowania z Poetry na Hatchling.
Usuwa opcjonalne grupy zależności, scalając je z główną grupą dev.

Ponadto wynik konwersji może nieznacznie różnić się od pierwotnej struktury pliku, więc zalecane jest skorzystanie z narzędzia "Even Better TOML" w VSCode, aby ręcznie dostosować formatowanie.

Historia portu SSH

Tatu Ylonen napisał początkową wersję SSH (Secure Shell) wiosną 1995 roku. W tamtym okresie telnet i FTP były powszechnie używane. SSH zostało zaprojektowane, aby zastąpić zarówno telnet (port 23), jak i FTP (port 21). Port 22 był dostępny i znajdował się pomiędzy portami telnetu a FTP, co wydawało się korzystne. Ylonen uznał, że przydzielenie tego portu mogłoby dodać wiarygodności jego nowemu protokołowi.

W tamtych czasach przydzielanie portów było stosunkowo proste. Porty były przydzielane przez IANA (Internet Assigned Numbers Authority). W tym okresie zajmowali się tym Jon Postel i Joyce K. Reynolds.

Przed ogłoszeniem SSH w lipcu 1995 roku, Tatu wysłał e-mail do IANA z prośbą o przydzielenie portu:

From: Tatu Ylonen <ylo@cs.hut.fi>
To: Internet Assigned Numbers Authority <iana@isi.edu>
Subject: request for port number

Prosił o zarejestrowanie portu dla swojego oprogramowania, które miało być rozprowadzane darmowo w Internecie. Wskazał, że używa portu 22 w wersji beta.

Następnego dnia Ylonen otrzymał e-mail od Joyce K. Reynolds:

Tatu,
We have assigned port number 22 to ssh, with you as the point of contact.
Joyce

Port SSH został przydzielony!

Nowa alternatywa dla Postmana

https://www.usebruno.com/

Bruno to nowoczesna aplikacja do testowania API, stanowiąca alternatywę dla Postmana. Ponieważ Bruno działa całkowicie offline (nie potrzebujesz konta ani połączenia z chmurą), synchronizacja kolekcji została przeniesiona do GIT-a.

Różnice w obsłudze STP pomiędzy Cisco i Juniper

Przeczytaj całą historię

Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.

Subskrybuj

Masz już konto? Zaloguj się