Jeśli ciąg połączenia określa Trusted_Connection=true
z trybem uwierzytelniania SQL Server, wpłynie to na wydajność mojej aplikacji internetowej?Podczas korzystania z Trusted_Connection = true i uwierzytelniania SQL Server, czy to wpłynie na wydajność?
Odpowiedz
Nie 100% pewien, co masz na myśli:
Trusted_Connection=True;
JEST użyciu poświadczeń systemu Windows i jest w 100% równoważne:
Integrated Security=SSPI;
lub
Integrated Security=true;
Jeśli nie chcesz korzystać z kompleksowych zabezpieczeń/zaufanego połączenia, trzeba podać identyfikator użytkownika i hasło wyraźnie w ciągu połączenia (i opuścić żadnego odniesienia do Trusted_Connection
lub Integrated Security
)
server=yourservername;database=yourdatabase;user id=YourUser;pwd=TopSecret
Tylko w tym przypadku , używany jest tryb uwierzytelniania SQL Server.
Jeśli którykolwiek z tych dwóch ustawień jest obecny (Trusted_Connection=true
lub Integrated Security=true/SSPI
), wówczas poświadczenia systemu Windows bieżącego użytkownika są wykorzystywane do uwierzytelniania przed SQL Server i dowolne ustawienie user iD=
będą ignorowane i nie używany.
Dla odniesienia zobacz Connection Strings site dla SQL Server 2005 z dużą ilością próbek i objaśnień.
Korzystanie z uwierzytelniania systemu Windows jest preferowanym i zalecanym sposobem działania, ale może to spowodować niewielkie opóźnienie, ponieważ SQL Server będzie musiał uwierzytelnić twoje poświadczenia w Active Directory (zazwyczaj). Nie mam pojęcia, jak duże może być to opóźnienie i nie znalazłem żadnych odniesień do tego.
Reasumując:
Jeśli podasz albo Trusted_Connection=True;
lub Integrated Security=SSPI;
lub Integrated Security=true;
w ciągu połączenia
==>WTEDY (i tylko wtedy) masz Windows Authentication wydarzenie. Każde ustawienie user id=
w ciągu połączenia zostanie zignorowane.
Jeśli ty NIE określić jeden z tych ustawień,
==> następnie NIE się dzieje uwierzytelnianie systemu Windows (tryb uwierzytelniania SQL zostaną wykorzystane)
Prawdopodobnie wystąpią pewne koszty związane z wydajnością podczas tworzenia połączenia, ale ponieważ połączenia są łączone, są tworzone tylko raz, a następnie ponownie wykorzystywane, więc nie ma to znaczenia dla Twojej aplikacji. Ale jak zwykle: zmierzyć.
UPDATE:
Istnieją dwa tryby uwierzytelniania:
- tryb Windows Authentication (odpowiadające zaufanego połączenia). Klienci muszą być członkami domeny.
- Tryb uwierzytelniania serwera SQL. Klienci wysyłają nazwy użytkownika/hasła przy każdym połączeniu
Masz na myśli, że kiedy po raz pierwszy nawiążesz połączenie z serwerem SQL, pojawią się dodatkowe koszty związane z wydajnością? I dlaczego? (Moje wcześniejsze zrozumienie oznacza, że zaufane połączenie poprawi wydajność, ponieważ jest "zaufane" - może zaoszczędzić czas, pomijając niektóre koszty uwierzytelnienia). Popraw mnie, jeśli się mylę. – George2
Tak, ale aby stać się "zaufanym", trzeba wykonać kilka wymian między klientem a serwerem. Ustanowienie uścisku dłoni SSP będzie wolniejsze niż pojedyncza obiecająca nazwa użytkownika/hasło. –
Istnieje również dodatkowa opłata za pobieranie usługi Active Directory. –
Podczas korzystania z zaufanych połączeń nazwa użytkownika i hasło są IGNOROWANE, ponieważ serwer SQL używa uwierzytelniania systemu Windows.
Czy masz na myśli, że jeśli używam uwierzytelniania SQL Server innego niż uwierzytelnianie systemu Windows, nie mogę używać Trusted_Connection = true? – George2
Jeśli korzystasz z zaufanego połączenia, serwer Sql nie dba o identyfikator użytkownika i hasło podane w ciągu połączenia. Sql Server używa poświadczeń bieżącego procesu. Jeśli chcesz używać uwierzytelniania serwera Sql, musisz usunąć zaufane połączenie ze swojego ciągu połączenia – Tror
Dzięki! Jeśli nie korzystam z aktywnego środowiska katalogowego, czy można użyć Trusted_connection = true? – George2
Jeśli aplikacja internetowa jest skonfigurowana do podszywania się pod klienta, użycie zaufanego połączenia może mieć negatywny wpływ na wydajność. Dzieje się tak, ponieważ każdy klient musi korzystać z innej puli połączeń (z poświadczeniami klienta).
Większość aplikacji internetowych nie korzysta z podszywania się/delegowania, a tym samym nie ma tego problemu.
Aby uzyskać więcej informacji, patrz this MSDN article.
Czy masz na myśli to, że jeśli używam uwierzytelniania SQL Server innego niż uwierzytelnianie systemu Windows, nie mogę używać Trusted_Connection = true? – George2
Przepraszam, mam na myśli, jeśli chcę używać Trusted_connection = true, to muszę użyć trybu uwierzytelniania systemu Windows? Czy mogę używać trybu uwierzytelniania SQL Server z Trusted_connection = true? – George2
Marc, chcę potwierdzić, że 1. jeśli używam trybu uwierzytelniania SQL Server, nie mogę używać Trusted_connection = true, 2. jeśli korzystam z trybu uwierzytelniania systemu Windows, mogę wybrać opcję użycia Trusted_connection = true albo nie? – George2