Dostałem code review aplikacji client-server, o której sporo już pisałem.
Jeden z pierwszych projektów… sporo refaktoryzacji, zmian, dodatków – myślałem, że jest gotowa… i już zacierałem ręce na kolejny projekt, ale…
…okazało się, że komunikacja sieciowa ma poważną dziurę… 🤦♂️
🎯 Wyzwanie:
Problem? recv(1024). Ta jedna linijka oznaczała, że serwer odbierał maksymalnie 1024 bajty. Jeśli JSON był dłuższy – reszta leciała w kosmos.
A send() po drugiej stronie? Nie gwarantuje wysłania wszystkiego – może wysłać tylko część i powiedzieć „dobra, mamy to”.
Efekt? Przy krótkich wiadomościach wszystko działało. Przy dłuższych… były po prostu ucięte.
Bonus? Brak limitu rozmiaru = ktoś mógłby wysłać 100MB JSONa i położyć serwer. Klasyczny atak DDoS. 🧨
🛣️ Droga:
Rozwiązanie: length-prefix protocol.
Zanim wyślesz wiadomość, najpierw wysyłasz jej długość, dzięki czemu odbiorca wie dokładnie ile danych ma odebrać.
I tu wchodzi struct – moduł Pythona do pakowania danych w format binarny.
struct.pack(’>I’, len(message)) – pakuje długość wiadomości do 4 bajtów.
struct.unpack(’>I’, header) – odpakowuje te 4 bajty z powrotem na liczbę.
Do tego sendall() zamiast send(), co gwarantuje wysłanie wszystkiego albo pokazuje błąd. Nie ma opcji pogubienia danych.
A limit rozmiaru? W tym wypadku MAX_MESSAGE_SIZE = 3MB. Cokolwiek większego = odrzucone. DDoS zażegnany.
✅ Wynik:
Kilkadziesiąt linijek kodu, a komunikacja jest teraz zabezpieczona. Duże wiadomości przechodzą w całości, serwer jest chroniony przed wielkimi payloadami, a ja mam w plecaku kolejne narzędzie…
Morał? „Działa” to nie to samo co „działa dobrze”. Czasem potrzeba drugiej pary oczu, żeby zobaczyć dziury, których sam nie widzisz siedząc w tym kodzie sporo czasu.
A u Was często się zdarza, gdy code review pokazało coś, czego kompletnie nie zauważyliście, a wydaje się oczywiste? 👇
#Python #Sockets #Backend #CodeReview #Networking #Programowanie #NaukaProgramowania #DDoS #Security
