Network Libraries

à 
communiquer. Dans la boîte de dialogue
Network Libraries, définissez la
Network Library que SQL Server utilisera
pour communiquer avec les
clients.

Dans SQL Server 6.5, seuls Named
Pipes et Multi-Protocol permettent
l’authentification Windows ; toutes les
autres Network Libraries ne permettent
que l’authentification SQL Server.
Donc, pour SQL Server 6.5, le type de
logins que vous voulez supporter est
un facteur de choix déterminant de la
Network Library. De plus, comme seul
Multi-Protocol permet le cryptage des
données, vous devez choisir cette
Network Library si vous voulez que SQL Server 6.5 supporte le cryptage
des données. Dans SQL Server 7.0,
toutes les Network Libraries supportent
l’authentification Windows, donc
vous aurez davantage de souplesse à 
cet égard, mais Multi-Protocol reste le
seul protocole permettant le cryptage
des données.

Dans SQL Server 2000, vous pouvez
forcer le cryptage en utilisant SSL
(Secure Sockets Layer) avec toutes les
Network Libraries par l’intermédiaire
du SQL Server Network Utility et du
SQL Server Client Network Utility,
donc le cryptage ne détermine pas la
Network Library. De plus, dans SQL
Server 2000, Multi-Protocol ne supporte
pas le schéma de noms d’instances
SERVERNAME\INSTANCENAME,
donc Multi-Protocol ne
constitue pas un bon choix quand il
existe des instances nommées. La
Network Library utilisée le plus couramment
dans SQL Server 2000 est
probablement TCP/IP Sockets. Elle
donne de bonnes performances, permet
l’authentification Windows, et
vous pouvez imposer le cryptage SSL si
nécessaire.

La plupart de ceux qui utilisent les
anciennes releases de SQL Server savent
que le port TCP/IP par défaut de
SQL Server est le port 1433. Quand on
l’utilise, les connexions client n’ont pas
à  fournir le numéro du port séparément
du nom du serveur ou de
l’adresse IP. Toutefois, SQL Server 2000
supporte des instances multiples qui
ne peuvent pas toutes utiliser le même
numéro de port. Donc, quand vous
installez une instance nommée, le programme
d’installation suggère 0
comme numéro de port. Cela signifie
que quand SQL Server démarre pour la
première fois, il choisit un numéro de
port libre et le garde de façon permanente
ou jusqu’à  ce que vous le changiez
manuellement plus tard. D’où la
question : comment les connexions
client peuvent-elles continuer à  se référer
à  SQL Server en fournissant son
nom/nom d’instance+IP seul sans spécifier
un numéro de port ? Un service d’écoute dans SQL Server 2000 écoute
sur le port 1433 les requêtes de clients
désirant se connecter à  SQL Server,
puis redirige la requête vers l’instance
appropriée en examinant le nom d’instance
dans la requête et en le faisant
correspondre au numéro de port de
l’instance.