多年沒寫過批處理了，來新公司的第一個case卻是需要寫一個bat腳本，批量更新采集agent的配置文件，其中就涉及到遠程IP的端口檢測。
本以為會和Linux一樣可以簡單判斷：
結果發現Windows下面telnet退出并沒有執行結果的返回值：
一、借助工具
于是我優先開啟懶人法則，找其他替代工具。果然，在Windows老娘家找到了：
Portqry：https://support.microsoft.com/en-us/kb/310099/zh-cn
確實可以使用，不過檢測速度不敢恭維，通與不通都很慢！鑒于手頭沒有更好的解決辦法，就先試試看，貼一下我寫的Portqry相關demo：
::使用微軟官方工具【PortQry】進行檢測的代碼：@echo off & setlocal enabledelayedexpansionrem 要檢測的IP和端口set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'set serverport='9922'rem 模塊化調用call :check::****其他代碼略****:checkrem ※探測端口模塊--PortQry方案※for /f "tokens=1,* delims=," %%i in ("!server_ip!") do ( echo 正在檢測 %%i 的 !serverport! 端口... rem 這是關鍵的檢測代碼： "!tools_dir!/PortQry.exe" -n %%i -p tcp -e !serverport! | find "LISTENIN" >nul && ( echo 【成功】：可以連接到 %%i:!serverport! ) || ( echo 【失敗】：無法連通 %%i:!serverport! ) echo= set server_ip=%%j goto check)goto :eof ::*******其他代碼略******** Ps：check是一個被call調用的模塊，里面的一些變量就不做介紹了。
于是興沖沖的封裝成exe，給IDC（server2003系統）執行，結果第一臺就悲劇了！遠程桌面直接斷開了：
然后再也連不上了，要他們去機房看了下，結果告訴我系統沒了！！？？太震精了有木有？一個簡單的文本操作腳本，居然把系統干掉了么？而且腳本中都不存在任何刪除命令。。。
要那邊提供了一下啟動錯誤信息，原來是系統引導壞了：
個人分析了一下，應該是Portqry這個工具導致系統藍屏關機，進而導致引導損壞！
尼瑪，娘家人介紹時說好的“性格”良好呢？
唉，看來這個工具是不敢使用了，俗話說林子大了什么系統都有嘞！
二、另辟蹊徑
既然工具不敢用了，還是繼續折騰代碼吧！周末睡覺前突然靈感一閃，想起了tasklist判斷窗口名稱這個“失傳絕技”，于是把剛關閉的本子又打開，終于在GF的不斷抱怨之下搞定了這個問題。
①、窗口判斷
思路比較簡單：使用start命令在新窗口執行telnet -e 和 exit命令，如果端口暢通，那么新開的窗口將會立即關閉，而不通的窗口則會保持近半分鐘左右，且窗口名稱類似 telnet 192.168.1.1，這半分鐘時間足夠腳本來判斷通還是不通了。
于是將上面check部分修改如下：
::使用telnet命令檢測的代碼@echo off & setlocal enabledelayedexpansionrem 要檢測的IP和端口set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'set serverport='9922'rem 模塊化調用call :check_port::****其他代碼略****:check_portrem ※探測端口模塊--telnet方案※for /f "tokens=1,* delims=," %%i in ("!server_ip!") do ( echo [No.!check_num!]:正在檢測 %%i 的 !serverport! 端口... rem 新窗口打開telnet，如果端口暢通會立即退出，腳本會在3秒后查看telnet窗口是否退出，如果沒有退出表示端口不通！ start /min cmd.exe /k "echo q|telnet -e 'q' %%i !serverport! & exit" ping -n 3 127.1>nul rem 查找窗口名為“Telnet ${ip}”的cmd窗口，如果存在則表示此IP不通 tasklist /fi "windowtitle eq Telnet %%i" | find "cmd.exe" >nul && ( echo 【失敗】：無法連通 %%i:!serverport! ) || ( echo 【成功】：可以連接到 %%i:!serverport! ) echo= set server_ip=%%j goto check_port)goto :eof::其他代碼略...這樣就解決了Windows下telnet探測遠程端口的問題了，而且檢測速度比微軟哪個portqry快多了，果然思路比技術更重要，只要有想法，任何技術都不應該成為瓶頸！
②、進程判斷【最新補充】
當使用窗口判斷的方案下發各大機房實施的時候，又一個問題出現了！窗口判斷在某些版本的Windows下是行不通的，比如英文版下的命令提示符窗口名稱和中文版的就不一樣，所以這個方案也是不完善的！
于是，繼續抓耳撓腮，想出了第二個方案：通過判斷telnet進程數量來判斷網絡是否暢通。
方案思路：
示例代碼：
::使用telnet命令檢測的代碼@echo off & setlocal enabledelayedexpansionrem 要檢測的IP和端口set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'set serverport='9922'::****其他代碼略****rem 剛開始先計算telnet.exe的進程數量，避免腳本執行之前就已經存在telnet.execall :telnet_num confrem 模塊化調用call :check_port:check_portset /a check_num+=1rem ※探測端口模塊※for /f "tokens=1,* delims=," %%i in ("!server_ip!") do ( echo [No.!check_num!]:正在檢測 %%i 的 !serverport! 端口... ::call :set_iPSec %%i rem 使用telnet組合命令進行測試，如果端口暢通會立即退出，腳本會在3秒后查看telnet窗口是否退出，如果沒有退出表示端口不通！ start /min cmd.exe /k "echo q|telnet -e 'q' %%i !serverport! & exit" echo= set server_ip=%%j set total_num=!check_num! goto check_port)ping -n 3 127.1>nul#再次計算telnet進程數量，而且已經排除執行之前就有的telnet數量call :telnet_numecho 可用數量為：!telnet_num!goto :eof:telnet_numrem 檢測telnet進程數量，已排除腳本之前存在telnetset conf=0for /f "delims=*" %%i in ('tasklist ^| findstr "telnet.exe"') do ( if "%1"=="conf" ( set /a conf+=1 ) else ( set /a telnet_num+=1 ) )set /a telnet_num=!telnet_num!-!conf!goto :eof 很明顯，這樣就可以知道我測試了所有IP當中有幾個是不通的了。遺憾的是無法知道是哪個IP不通。不過在手頭的這個case當中是不需要具體不通的IP的，只要知道通的IP是否達標就行。
好了，終于把這個問題給解決了。顯然，任何時候都需要給出多個方案，而不是自滿于一個方案。否則出問題就會焦頭爛額了。當然，再次說明了想法比技術更重要。
新聞熱點
疑難解答
