出自： http://blogs.msdn.com/b/apgcdsd/archive/2012/02/24/ms-sql-server-tcp-ip.aspx

TCP/IP的基本工作原理這里就不浪費口水了。現在這網絡年代，誰不知道TCP/IP啊。不要跟我抬杠說你偏就沒聽說過TCP/IP阿，真是這樣那你得自己去補補課了。

?

TCP/IP協議有兩個基本的東西，一個是IP地址， 另一個是端口號。 在SQL Server?上使用TCP/IP協議是非常簡單的。首先要對SQL Server所在機器的網卡配置好TCP/IP協議并得到一個IP地址（通過靜態指定分配或從DHCP服務器動態獲得都行），接下來就需要通過SQL Server提供的工具做服務器端設置。

?

一、Microsoft SQL Server?上的TCP/IP協議

在運行SQL Server 2000的服務器上，運行服務器端網絡配置工具（運行svrnetcn.exe即可調出）配置SQL Server?監聽TCP/IP協議即可，如圖所示：

?

?

在運行Microsoft SQL Server 2005/2008?上的服務器上，配置TCP/IP協議需要在SQL Server配置管理器(Configuration Manager)工具下的Network Configuration下面。下面是這個工具的截屏。

?

其實，不論是SQL Server 2000還是SQL Server 2005/2008,配置的結果都是存放在注冊表HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.<InstanceID>\MSSQLServer\SuperSocketNetLib下面的各個項目里。不用管理界面，直接修改注冊表也能達到一樣的目的。

（要注意，如果你的機器上只有SQL Server 2000的默認實例，那么注冊表所在位置會稍有不同，它是HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib.）

?

配置好網絡協議以后，需要重新啟動SQL Server服務，讓修改生效。啟動后，需要檢查SQL Server的errorlog，確認這些協議都已經被正常開啟。

Shared Memory正常啟動，可以看到如下信息。

2009-04-12 10:04:27.92 Server?????? Server local connection provider ?is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].

Named Pipe正常啟動，可以看到如下信息。

2009-04-12 10:04:27.92 Server?????? Server named pipe provider ?is ready to accept connection on [ \\.\pipe\sql\query ].

TCP/IP正常啟動，可以看到SQL Server實例正在偵聽的IP地址和Port號。例如：

2009-04-12 10:04:27.92 Server????? Server is listening on [ 'any' <ipv4> 1433].

--偵聽服務器上所有IP地址上的1433端口。

?

或者：

2008-06-12 15:01:58.150 Server?????? Server is listening on [ 172.30.30.80 <ipv4> 1433].

--只偵聽指定的IP地址上（172.30.30.80）的1433端口。

?

這里也順便回答一個小問題。 有些朋友問， 如果機器的IP地址改變，對SQL Server有沒有影響， 需要作什么動作等。答案很簡單， 重新啟動SQL Server?服務就可以了。?SQL Server?會自動監聽機器的新IP地址，無需重新安裝或配置SQL Server。

?

二、Microsoft SQL Server 2000?監聽的TCP/IP端口號

?

現在談談一個重要的配置即端口號。在服務器端網絡配置工具中或者在配置管理器中選中TCP/IP協議，點擊Properties按鈕，就可以查看SQL Server偵聽的端口號：

?

（ SQL Server 2000服務器端網絡配置工具 ）

?

（SQL Server 2005/2008配置管理器）

?

?

這里顯示的就是SQL Server監聽的?TCP/IP?端口。默認值為?1433。SQL Server服務器將在該端口上監聽并接受客戶端的TCP/IP socket連接請求。你可以改變這個默認值為別的端口號，只要該端口沒有被系統或別的應用程序占用即可。一般說來高于5000以上的端口號碼都可以隨意使用，或者使用小于1024的操作系統或其他應用程序不使用的空閑端口。為什么不用1024至5000之間的端口呢？?因為缺省情況下操作系統會把這個范圍內的端口分配給服務或應用程序使用。為了避免潛在的端口沖突所以使用5000以上或1024以下的值。實際上不論那個范圍，只需要是空閑的沒使用的端口都可以。微軟有一篇很好的技術文檔詳細討論了Windows系統使用一些端口號，文檔連接如下：

?

Microsoft Windows?服務器系統的端口要求

http://support.microsoft.com/?id=832017

?

或許你會問，有沒有方法查看SQL Server?監聽的端口啊？有的，可以使用netstat命令。?在DOS窗口下運行?“netstat -an”命令即可列出系統所有使用中的端口號，當然SQL Server?監聽的端口也在其中了。下面是從“netstat -an”命令的輸出中摘取的有關SQL Server的端口號部分：

?

Active Connections

? Proto? Local Address????????? Foreign Address??????? State

? TCP??? 0.0.0.0:1433?????????? 0.0.0.0:0????????????? LISTENING

? TCP??? 169.254.173.244:1433?? 169.254.173.244:3952?? ESTABLISHED

UDP??? 0.0.0.0:1434?????????? *:*

?

上面列出的1434端口是比較有趣的一個端口，詳見后面的內容。

?

SQL Server支持一臺機器安裝多套實例，即默認實例和命名實例。對于默認實例，缺省偵聽的IP端口是1433。如果你把默認實例的監聽端口改為非1433端口，?那么客戶端就有可能連接不上SQL server默認實例。?這個時候必須使用客戶端網絡工具指定SQL Server?偵聽的IP端口或創建一個指定IP端口的SQL Server別名。關于客戶端網絡工具在下面會具體講。

?

三、TCP/IP靜態端口，動態端口，SQL Server Browser和UDP 1434端口的概念

?

首先討論1434?端口。1434端口是用來干嗎的呢？

我們都知道?SQL Server?支持多個實例，缺省的?SQL Server?實例使用默認的1433端口。對于其余的命名實例(Named Instance），每次啟動所綁定的端口號可能都不一樣。讓每個用戶都去記住SQL的端口號是不可能的。一個數據庫普通用戶只會知道數據庫服務器的名字和實例名。那么怎么根據服務器名和實例名找到相應的端口號呢？SQL Server 2000的時代，產品組開發了一套SQL Server?解析協議?(SSRP)，用于偵聽?UDP 1434?端口。當?SQL Server 2000?客戶端?Net-Library?連接到?SQL Server 2000?實例時，僅需要運行該實例的計算機所在的網絡名和該實例名（如MYSQLSrv\inst1）。當應用程序請求連接SQL Server服務器時，客戶端網絡庫發送一個網絡包到SQL Server?服務器的1434端口。所有運行?SQL Server 2000?實例的計算機都監聽此端口。服務器收到查詢網絡包時將返回一個包含服務器上運行的所有實例監聽信息的數據包。對于每個實例，該數據包報告該實例正在監聽的服務器?Net-Library?和具體網絡地址。客戶端應用程序根據返回的網絡地址進行連接。 舉個具體的例子，對于命名實例，該返回的網絡包中包含了SQL Server?服務器正在監聽的TCP/IP端口，客戶端應用程序得到端口號后才能和SQL Server?建立連接。

?

這個設計理念本身是挺好的。但是在2003年，一個叫Slammer的病毒利用SSRP功能組件里的一個bug，誘導SQL Server服務在UDP端口發出大量網絡包，從而導致了網絡阻塞，并且使數據庫服務癱瘓的嚴重后果。這個病毒是和SQL Server相關的迄今為止危害最大的病毒。為了避免這類悲劇事件再次發生，SQL Server 2005?引入了?SQL Server Browser?服務來替換原有的機制。

?

SQL Server browser用?SQL Server?解析協議?(SSRP)?偵聽?UDP?端口，并接受未經身份驗證的請求。為了防止惡意用戶利用這個服務攻擊SQL Server服務器，SQL Server?瀏覽器可以設置在低特權用戶的安全上下文中運行，將受到惡意攻擊的幾率降到最低。可以將一個新建用戶加入SQLServerXXXXSQLBrowser$這個本地組里。并且需要通過使用?SQL Server?配置管理器更改登錄帳戶。SQL Server?瀏覽器的最小用戶權限如下：

• 拒絕通過網絡訪問該計算機
• 拒絕本地登錄
• 拒絕以批處理作業登錄
• 拒絕通過“終端服務”登錄
• 作為服務登錄
• 讀取和寫入與網絡通信（端口和管道）相關的?SQL Server?注冊表項

通過這樣的設計，可以隔離惡意網絡攻擊對SQL Server服務本身的影響，并且通過限制SQL Browser登錄用戶權限的方法，限制了萬一SQL Browser受到攻擊，對整個服務器的影響。

啟動SQL Server Browser后，它將啟動并使用?UDP 1434?端口。SQL Server?瀏覽器將讀取注冊表（所有HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib下的記錄），識別計算機上的所有?SQL Server?實例，并注明它們使用的端口和命名管道。當一臺服務器具有兩個或多個網卡時，SQL Server?瀏覽器會為?SQL Server?返回其遇到的第一個已啟用的端口。

當?SQL Server?客戶端請求?SQL Server?資源時，客戶端數據驅動程序將使用?1434?端口向服務器發送一條?UDP?消息。SQL Server?瀏覽器將會應請求實例的?TCP/IP?端口或命名管道名稱。然后，客戶端數據驅動程序將使用所需實例的端口或命名管道向服務器發送請求來完成連接。

當?SQL Server Browser?服務不運行時，如果您提供了正確的端口號或命名管道，仍可以連接到?SQL Server。如果?SQL Server?的默認實例在?1433?端口上運行，則可以使用?TCP/IP?連接到此默認實例。

但是，如果?SQL Server Browser?服務未運行，則以下連接無效：

• 在未完全指定所有參數（例如?TCP/IP?端口或命名管道）的情況下，組件嘗試連接到命名實例。
• 生成或傳遞其他組件隨后要用來進行重新連接的服務器/實例信息的組件。
• 未提供端口號或管道就連接到命名實例。
• 在未使用?TCP/IP 1433?端口的情況下，將?DAC?連接到命名實例或默認實例。
• 枚舉?SQL Server Management Studio、企業管理器或查詢分析器中的服務器。

如果應用程序通過網絡訪問?SQL Server，若要停止或禁用?SQL Server Browser?服務，必須為每個實例分配一個特定端口號，并在客戶端應用程序代碼中指定該端口號。但此方法存在如下問題：

• 必須更新和維護客戶端應用程序代碼才能確保它連接到正確的端口。
• 如果服務器上的其他服務或應用程序占用了您為每個實例選擇的端口，則會導致?SQL Server?實例不可用。

?

所以SQL Browser這個服務做的事情雖然很簡單，但對正常的客戶端連接非常重要。如果某些客戶端連不上SQL Server，報告“SQL Server doesn't exist or access denied”，可以嘗試指定端口，看看能不能連上。如果這樣能夠連上，一般是因為UDP 1434在網絡上被禁用了，需要在防火墻或者網關上打開這個端口。

?

SQL Browser本身很少出現問題。不過由于其設計比較簡單，一共只有4個線程在接受SSRP的包（2個給IPv4，2個給IPv6）。因此一旦這些線程都因為異常而終止的話，可能會出現SQL Browser服務運行正常但是連接命名實例有問題的情況。這個時候你會在Windows的事件日志里看到以下錯誤：

The SQLBrowser processing of requests against a particular IP address has encountered a critical error. Processing of requests on this address has been?halted ?(event ID 14)

微軟已經有發布了一個補丁程序來解決這個問題，參見：

http://support.microsoft.com/kb/2526552

?

另外需要注意的是SQL Browser啟動賬號要有?讀取和寫入與網絡通信（端口和管道）相關的?SQL Server?注冊表項（HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\MSSQLServer\SuperSocketNetLib）的權力。如果注冊表讀不到，SQL Browser不會報錯，但是就不告訴客戶端想要的port和pipe的信息，也會導致客戶端連不上。

?

再來討論靜態端口。本文一開頭提及如何修改SQL Server?監聽的端口。 如果你配置的端口是非0值那么就是靜態端口了。也即是我們指定了一個靜態的端口號，SQL Server?將在該端口上監聽。這對于默認實例和命名實例都是一樣的。只是對于默認實例，如果端口不是1433，那么得在客戶端使用網絡配置工具指定缺省連接端口或創建SQL別名來進行連接。而對于命名實例則不一樣。你可以指定任意端口值。只要SQL Server?在該端口進行監聽，那么客戶端就能夠通過1434端口查詢出該命名實例的端口值而進行連接。

?

另外，萬一指定的端口已經被占用時，SQL Server?又會怎么辦呢？ 對于默認實例，SQL Server?干脆就放棄監聽TCP/IP協議并在日志中記錄“不能監聽TCP端口”類似的信息。而對于命名實例則聰明一些。SQL Server?命名實例會自動選擇下一個空閑的端口來監聽。

?

如果把SQL Server?監聽的端口設為0又會如何？這個問題比較有趣。事實是，當設為0時，無論是默認實例還是命名實例，SQL server?都理解為需要動態配置監聽的端口。動態配置的意思是，它們都會自動選擇一個系統空閑的端口進行監聽。但記住，對于默認實例，如果選擇的端口不是1433的話，嘿嘿，你得需要在客戶端使用cliconfg.exe工具配置缺省連接端口或使用別名了。

?

動態配置端口是否意味著SQL Server?每次重新啟動后都會隨機選擇一個未用端口呢？這倒不是的。 當重新啟動后，SQL Server?將設法偵聽之前使用的端口。如果?SQL Server?不能綁定到該端口，那么會動態地綁定到另一個空閑端口。

?

四。客戶端的TCP/IP協議配置

?

大多數情況下在客戶端你不需要進行配置，因為TCP/IP協議默認是啟用的。和命名管道一樣，可以使用客戶端網絡實用工具進行配置TCP/IP協議。客戶端應用程序都是通過加載SQL Server的數據驅動控件做SQL Server連接的。現在客戶端數據驅動庫主要有2種：

?

1．MDAC (Microsoft?數據訪問組件)

運行cliconfg.exe或從開始-->程序-->Microsoft SQL Server -->客戶端網絡實用工具即可調出。

?

客戶端網絡實用工具中左邊是禁用的協議，右邊的是啟用的協議。如果右邊沒有TCP/IP協議，則點擊Enable按鈕啟用它。 選中TCP/IP后點擊屬性（Properties）按鈕即可查看客戶端連接的缺省的TCP/IP端口。缺省情況下1433（參考圖4）。如果服務器默認實例（不是命名實例）監聽的端口不是1433，那么你需要在這里把default port作相應的改變。當然你可以像在命名管道篇中介紹的那樣創建服務器別名特別指定服務器的端口也可以。對于命名實例， 客戶端網絡庫會利用UDP 1434端口查詢服務器命名實例的監聽協議信息。

?

?

可以在客戶端配置SQL Server別名，以明確指定連接到SQL Server所使用的協議。注意在別名中可以指定端口，也可以使用動態查詢端口功能。

?

?

當默認實例被配置為偵聽一個非1433端口我們就可以通過配置默認端口或者別名來讓客戶端程序找到默認實例。

?

配置的信息保存在注冊表里，HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib子目錄下面。也可以直接改值，一樣能達到效果。

?

2. SQL Server Native Client

在一臺沒有安裝過SQL Server 2005或者2008的機器上，缺省不會安裝SQL Server Native Client。在安裝?SQL Server 2008?或?SQL Server?客戶端工具時，將同時安裝?Microsoft SQL Server Native Client 10.0。如果計算機上還安裝了?SQL Server Native Client?的?SQL Server 2005?版本，則?SQL Server Native Client 10.0?將與早期版本Microsoft SQL Server Native Client 9.0并行安裝。

如果安裝有SQL Server?客戶端工具，我們可以通過SQL Server Configuration Manager來配置客戶端網絡協議。配置的方法和MDAC類似。

?

圖?5 - 5

如果沒有安裝這個工具，可能就需要直接修改注冊表了。Microsoft SQL Server Native Client 9.0的信息存放在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI9.0下面，Microsoft SQL Server Native Client 10.0的信息存放在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI10.0下面。

?

?

五。?TCP/IP連接問題的解決步驟

?

步驟1:?驗證SQL Server?是否真的監聽了TCP/IP協議

?

為了驗證SQL Server?確實監聽了TCP/IP協議，可以打開SQL Server Query Analyzer?（查詢分析器），然后運行如下命令：

?

exec master..xp_readerrorlog

?

在結果欄，如果看到類似如下一行則表明SQL Server已經監聽了TCP/IP：

?

?

2000-08-31 21:47:01.52 server??? SQL server listening on 169.254.173.244: 1433.

2000-08-31 21:47:01.52 server??? SQL server listening on 127.0.0.1: 1433.

2000-08-31 21:47:01.53 server??? SQL server listening on TCP, Shared Memory.

?

如果發現SQL Server?沒有監聽TCP/IP協議，請使用服務器端網絡配置工具（運行svrnetcn.exe即可調出）確認是否配置好SQL Server?監聽TCP/IP協議。

?

步驟2:?驗證服務器監聽的TCP/IP端口和客戶端配置的缺省值或別名中指定的值一致。

?

使用客戶端網絡實用工具檢查客戶端的連接協議配置，確保客戶端啟用了TCP/IP。當然，客戶端連接的缺省端口需要和SQL服務器監聽的一致。另外，如果有別名，需要仔細查看其指定的端口是否正確。如果客戶端的別名設置錯誤，也會引起連接問題。

?

步驟3:檢查網絡連通性。

?

要確保不但能夠ping通?SQL Server服務器的IP地址，也能夠ping?通SQL Server服務器的名稱。如果ping?服務器名字有問題， 說明DNS或WINS服務器配置有問題， 可以在HOSTS文件（HOSTS?文件在system32\drivers\etc目錄下）中手工加入IP地址和服務器對如下：

?

169.254.173.244? MySQLserver

?

如果連ping IP?地址都有問題， 那么得好好檢查網絡的配置包括硬件的連接。 在服務器上和客戶端都使用 “ipconfig/all”命令檢查服務器和客戶端是否在同樣的網絡上。

?

步驟4：使用TELNET命令檢查SQL?監聽的端口。

?

要驗證SQL Server?監聽的端口， 可以使用TELNET命令。假設SQL Server的IP地址是192.168.1.1，端口是1234， 那么可以運行如下命令：

?

TELNET 192.168.1.1 1234

?

如果TELNET成功，那么結果將是一個只有光標在閃的黑色屏幕。如果不成功， 那么你會得到出錯的信息。需要根據這些出錯信息繼續排查問題。

?

步驟?5：檢查登錄用戶的SQL Server訪問權限。

?

和命名管道一樣，需要確保客戶端登錄（login）帳號有權限訪問SQL Server。有關這方面內容請參考命名管道篇。

?

需要注意的是，如果你使用Windows?系統帳號而不是SQL Server?本身的login， 那么和命名管道一樣，你需要有訪問服務器資源的權限。如果該Windows系統帳號不能通過Windows的認證，自然不能訪問SQL server.?如果懷疑是Windows系統帳號的權限問題，可以使用SQL Server?的login?如sa嘗試登錄。

SQL Server 連接問題－TCP/IP