Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

Port UDP 1434

Termin Definicja
Port UDP 1434

Port UDP 1434 obsługuje usługę SQL Server Browser, wskazującą klientom porty instancji nazwanych.

Port UDP 1434 – czym jest i do czego służy

Port UDP 1434 jest związany z mechanizmem SQL Server Browser, czyli usługą pomocniczą wykorzystywaną przez Microsoft SQL Server. Jego zadaniem nie jest przechowywanie danych ani obsługa typowych zapytań aplikacji. Usługa nasłuchująca na tym porcie przekazuje klientowi informacje potrzebne do odnalezienia właściwej instancji SQL Server oraz ustalenia portu TCP, na którym dana instancja przyjmuje połączenia.

Znaczenie portu UDP 1434 pojawia się przede wszystkim wtedy, gdy używana jest instancja nazwana, a nie domyślna. W połączeniu do instancji domyślnej można wskazać konkretny adres i port bez dodatkowego wyszukiwania. W przypadku instancji nazwanej aplikacja często zna tylko nazwę komputera oraz nazwę instancji. Wtedy wysyła zapytanie do SQL Server Browser za pomocą UDP 1434. Odpowiedź zawiera między innymi informacje o dostępnych instancjach, ich nazwach oraz portach komunikacyjnych.

UDP, w odróżnieniu od TCP, nie ustanawia trwałego połączenia przed wysłaniem danych. Dzięki temu krótkie zapytanie informacyjne może zostać obsłużone szybko i bez rozbudowanej procedury nawiązania sesji. Taki sposób komunikacji oznacza jednak, że nie ma automatycznego potwierdzenia dostarczenia pakietu ani ponowienia transmisji na poziomie samego protokołu. Jeżeli zapytanie zostanie zablokowane, zgubione albo skierowane do niewłaściwego urządzenia, klient może nie uzyskać informacji o porcie instancji.

UDP 1434 a port TCP instancji SQL Server

Najważniejsze jest rozróżnienie dwóch elementów: UDP 1434 służy do odnalezienia informacji, natomiast właściwa wymiana danych z SQL Server odbywa się zwykle przez TCP. Port TCP może być stały albo dynamicznie przydzielany, zależnie od konfiguracji instancji. SQL Server Browser pełni więc funkcję pośrednika informacyjnego. Nie zastępuje portu TCP i nie jest miejscem, w którym aplikacja wykonuje zapytania do bazy.

W praktyce proces może wyglądać następująco: aplikacja otrzymuje adres komputera oraz nazwę instancji, wysyła zapytanie do UDP 1434, odbiera odpowiedź z numerem portu TCP, a następnie próbuje połączyć się z właściwą usługą bazodanową. Jeżeli pierwszy etap nie działa, późniejsze reguły sieciowe mogą być poprawne, a mimo to połączenie zakończy się komunikatem o niedostępności instancji. Z tego powodu sprawdzanie wyłącznie portu TCP może nie wystarczyć do ustalenia przyczyny problemu.

Warto również pamiętać, że numer UDP 1434 nie oznacza, iż wszystkie instalacje SQL Server muszą korzystać z automatycznego wykrywania instancji. Administrator może wyłączyć usługę SQL Server Browser i skonfigurować połączenie tak, aby aplikacja korzystała bezpośrednio z określonego portu TCP. Takie rozwiązanie ogranicza zależność od zapytań rozgłoszeniowych i ułatwia tworzenie precyzyjnych reguł zapory, ale wymaga znajomości aktualnej konfiguracji.

Port UDP 1434 – typowe problemy z dostępem

Jednym z najczęstszych problemów jest blokowanie ruchu UDP 1434 przez zaporę systemową, urządzenie sieciowe albo filtr bezpieczeństwa. W takiej sytuacji klient nie otrzymuje odpowiedzi od SQL Server Browser i może zgłaszać ogólny błąd połączenia z nazwaną instancją. Sam fakt, że komputer odpowiada na polecenie ping, nie potwierdza dostępności usługi bazodanowej. Ping wykorzystuje inny protokół i może być obsługiwany niezależnie od reguł dotyczących UDP oraz TCP.

Drugą przyczyną bywa zatrzymana usługa SQL Server Browser. SQL Server może działać prawidłowo, lecz bez aktywnego mechanizmu wyszukiwania klient nie dowie się, na jakim porcie nasłuchuje nazwana instancja. Podobny skutek występuje po zmianie portu instancji bez aktualizacji reguł zapory albo po przywróceniu konfiguracji z kopii, która zawierała inne ustawienia sieciowe.

Problemy mogą być też związane z błędnym adresem, nieprawidłową nazwą instancji, rozwiązywaniem nazwy komputera lub działaniem kilku kart sieciowych. W środowisku z więcej niż jedną instancją odpowiedź usługi musi prawidłowo wskazywać żądany identyfikator. Jeżeli nazwa została wpisana z literówką, klient może wysłać zapytanie do działającego urządzenia, ale nie odnaleźć oczekiwanej instancji.

Nie należy też zakładać, że otwarcie UDP 1434 rozwiąże każdy problem. Wymagany jest jeszcze dostęp do portu TCP przypisanego do konkretnej instancji. Jeżeli UDP działa, lecz TCP jest zablokowany, etap wykrywania może zakończyć się powodzeniem, a właściwa sesja nadal nie zostanie ustanowiona. Diagnoza powinna zatem obejmować oba etapy oraz sprawdzenie, czy wskazany port odpowiada usłudze, która powinna na nim nasłuchiwać.

Jak sprawdzać UDP 1434 w praktyce

Sprawdzanie należy rozpocząć od ustalenia, czy używana jest instancja domyślna, czy nazwana. Następnie warto zweryfikować stan SQL Server Browser, konfigurację protokołów sieciowych oraz przypisanie portu TCP do danej instancji. Informacje te można odczytać w narzędziach konfiguracyjnych SQL Server, w dziennikach usługi oraz w ustawieniach zapory.

Przydatne jest przeprowadzenie testu z tego samego komputera i tej samej sieci, z której korzysta aplikacja. Test wykonany lokalnie na komputerze z bazą może dać inny rezultat niż próba przeprowadzona z oddzielnej stacji roboczej. Należy zwrócić uwagę na profil sieci, reguły zapory przychodzącej i wychodzącej, adres interfejsu oraz ewentualne filtrowanie na routerze. W sieci z segmentacją ruch UDP może być dozwolony w jednym kierunku, a blokowany w innym.

Do weryfikacji można wykorzystać narzędzia systemowe, polecenia diagnostyczne oraz programy przeznaczone do obsługi SQL Server. Istotne jest interpretowanie wyniku w kontekście całego procesu, ponieważ wiele popularnych testów portów lepiej radzi sobie z TCP niż z krótkimi zapytaniami UDP. Brak jednoznacznej odpowiedzi nie zawsze oznacza awarię usługi, ale powinien skłonić do sprawdzenia zapory i konfiguracji.

Bezpieczniej jest dopuścić wyłącznie wymagany ruch pomiędzy określonymi adresami i stosować konkretny port TCP dla instancji, jeżeli pozwala na to sposób wdrożenia. Otwieranie szerokiego zakresu portów utrudnia kontrolę i zwiększa powierzchnię komunikacji. Przed zmianą reguł należy zachować istniejącą konfigurację, zanotować zakres modyfikacji i sprawdzić, czy zmiana nie wpływa na inne aplikacje korzystające z bazy.

Kiedy zgłosić problem z portem UDP 1434 do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy aplikacja przestaje odnajdywać nazwaną instancję po zmianie routera, zapory, adresacji sieciowej albo aktualizacji systemu. Warto przekazać nazwę instancji, adres komputera, treść komunikatu, informację o tym, czy problem dotyczy wszystkich stanowisk, oraz moment pojawienia się usterki. Takie dane skracają czas rozpoznania i pomagają odróżnić błąd konfiguracji od problemu z działaniem usługi.

Pomoc techniczna może objąć sprawdzenie ustawień SQL Server Browser, reguł zapory, portów instancji, rozwiązywania nazw oraz komunikacji między urządzeniami. W razie potrzeby można również zweryfikować dzienniki systemowe i aplikacyjne, aby ustalić, czy zapytanie do UDP 1434 dociera do właściwego komputera i czy usługa zwraca oczekiwane informacje.

W takich sprawach wsparcie oferuje Warszawskie Pogotowie Komputerowe 24/7, zajmujące się diagnozowaniem problemów z konfiguracją komputerów i sieci. Przed przekazaniem urządzenia dobrze przygotować opis objawów oraz dane dotyczące ostatnich zmian, ponieważ ułatwia to odtworzenie warunków, w których pojawia się błąd.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę