AssemblyFileVersion:1.9.0.0
2014年5月19日更新1.9.0.0版http://download.csdn.net/detail/laotse/7369863
修正了因多網卡、多虛擬網卡、同網卡綁定多ip、網關等複雜網絡結構導致無法使用winpcap模式的問題
增加了調用winpcap發送數據包功能，這樣的話win7 win8 win8.1 xp vista這些桌面版操作系統也可以syn掃描了
並且默認首先使用winpcap發送，如果沒安裝winpcap再轉rawsocket方式，推薦之前破解xp-syn的人也裝winpcap然後用winpcap來發送吧。
因爲有個Socket.IOControl的關係，所以必須以管理員方式運行，否則系統就會不讓操作而報錯。
順便說句如果想學習c#如何用winpcap發送的請看這貼 http://blog.csdn.net/laotse/article/details/16983287 本程序就是這麼發送的，而監聽用的還是socket，因爲.net自帶的socket相比於用winpcap監聽實在省心太多了。
感謝qq3671朋友提供了timeBeginPeriod(1)使得thread.sleep精度突破15毫秒限制的方法，但是我實際測試後發現，只能到1毫秒將近2毫秒的精度，這樣即使用了這個方法，每秒也就只有500個左右，量是太少了點，於是決定還是不改了，關於timeBeginPeriod(1)詳情，請看http://blog.csdn.net/laotse/article/details/14093869
修正了掃描大量ip後程序崩潰的bug。
加入了一個驗證，可以防止掃描中的虛假結果。
另外1.6版及之前版本掃着掃着會崩潰的問題，現已查明是.net本身的一個bug，就是說如果.net的console程序console.writeline或者console.write的量超過2G字節就會使整個程序崩潰，streamwrite也有這個問題，大家可以看看我剛轉載的這篇文章http://blog.csdn.net/laotse/article/details/8172632，也可以去百度谷歌下“InternalEncoderBestFitFallback streamwriter”，日的微軟社區一管理員都說是.net的問題，反饋m$也不解決。
今後將加入winpcap方式，這樣掃描就不限於部分系統了。
使用方法
前言：本程序下面介紹的所有按步驟輸入的都可以作爲參數，所以下面評論的喜歡批處理的同志也可以按批處理來
規則 SharpTcpScanner.exe 地址集 端口集 阻塞值
比如 C:\SharpTcpScanner.exe -hun:hun.txt 1433 36
或者 C:\SharpTcpScanner.exe 192.168.0.1 1-65535 0
等等
1、輸入地址集
總體要求輸入的爲以英文逗號分隔的ip和ip段
可以 192.168.0.1
可以 192.168.0.1,192.168.0.2,192.168.0.3
可以 192.168.0.1-192.168.0.10
可以 192.168.0.1-192.168.0.10,192.168.0.20-192.168.0.30
也可以ip和ip段的混合
可以 192.168.0.1,192.168.0.2-192.168.0.10,192.168.0.20,192.168.0.30-192.168.0.40
如果ip和ip段的混合太多了沒法手動輸入，舉個例子，我用最新的純真ip庫把整個南朝鮮的ip段都整合到了一起是這個樣子的。
這就沒法手動輸入了，怎麼辦？
新建一個叫hun.txt的utf8編碼的文本文檔，把這些ip段的混合放進去保存在本程序同目錄下。
然後在輸入地址集的地方輸入-hun:hun.txt，這樣程序就把這個ip段導入了，代替了手動輸入。下面有評論說批處理什麼的，本程序不需要批處理，任何功能程序中本來就有，像這樣子不比你的批處理好多了？
還有一種情況，我已經掃描了一大堆的1433如圖
現在我想直接掃描這個列表中的ip的3389端口
怎麼導入呢？把:1433替換掉？然後用逗號，然後變成一行？NO！
只需要-in:scanReport.txt，這樣子程序就會把這裏面的ip給導入了，即使是後面有漢字什麼的也沒關係，只要文本中有標準ipv4地址，就會被導入（正則匹配的），前提是這個txt要utf8最好。然後就可以在第二步輸入3389去這些ip的3389端口啦。
第二步輸入端口集
可以 80
可以 80-90
可以 80,81,82
可以 80-90,100-110
也可以是端口和端口段的集合 80,81-90,100,1430-1450
這樣第一步中輸入的每一個ip都會掃描第二步中輸入的每一個端口。
但是建議只在單個或幾個ip下使用多端口，經典用法是掃描一個ip的1-65535，看看開放了哪些端口。
但是如果第一步ip很多，你第二步端口也多個的話，這樣結果就混雜在了一起，很不容易分辨啊，你可以試試，所以說大量ip還是單掃一個端口爲好。
第三步阻塞
有人說你這個掃描器不如哪個哪個快，我大笑，這人不懂，syn掃描程序想讓他快太容易了，難的是怎麼讓他慢下來，因爲網絡設備處理能力遠低於cpu製造syn封包的速度。
即使在人人百兆帶寬的南朝鮮服務器肉雞上，都沒法敞開了去掃，表面看每秒幾萬，那是程序！那是cpu製造的個數！cpu製造出來封包但網絡設備發不出去都給丟棄了，把網關給堵了，給炸掉線了，有毛用？
記住一點，當你在用syn掃描時，等於別人在對你的網關進行synflood攻擊。
發送速度多少纔是合理的？
比如網關每秒可以發送100個syn接受100個，那麼syn發送速度每秒95個最好！以此推論。
還有就是不要以爲同樣是100兆帶寬，爲什麼這個就可以很快的掃，那個就沒結果？
還是網絡設備！如果這個電腦雖然是100兆帶寬，但是他的網關是個家用小路由器，那麼他帶寬就算1G你都不能掃，因爲小路由器處理不過來，你隨便一掃就把他路由器給搞死機了。（路由器往往等於arm處理器+linux的小計算機）
只有他網關的網絡設備能夠處理大量syn封包才行。
阻塞值就是爲這個來的，目的就是在大量沒法無限制的發送syn封包掃描的情況下，通過降低發送速度來進而把本來不可以syn掃描的環境變成可以syn掃描。
阻塞設多少合適這個完全沒法由程序來判斷，因爲即使在pc上好多時候你都不知道給你提供網絡連接的是什麼設備。比如在南朝鮮肉雞上，網關是什麼設備？如果是192.168.0.1或者192.168.1.1這種，幾乎確定是個小路由器，一般都是南朝鮮國產iptime牌的，可以ie直接192.168.0.1，他們一般都不設密碼可以進去改。如果網關是個公網ip，那是什麼設備？不知道，只知道肯定是個交換機或者路由器。
所以就得手動實驗。如何確定？
舉個例子，一臺機器，我用他掃整個南朝鮮ip段的1433，第一次阻塞我設的10，掃描後得到了6萬結果。
第二次還掃這個段1433，阻塞值我設的20，得到11萬結果。第三次還掃這個段1433，阻塞我設的30，得到了12萬左右。
那麼就可以確定30保守了，因爲用30和20的結果基本一樣，發送速度低於了網絡設備處理速度，需要加速。
而10就屬於發送過快，網絡設備發不出、收不到一些封包，所以得到結果少，你可以試試用5得到的結果會更少甚至直接扎掉線。
最後這樣試驗了幾次，發現這個機器和網絡環境阻塞用22比較合適，因爲低於22結果少，高於22的話掃描結果和22幾乎一樣但是掃描速度慢。
於是找到了22這個速度和結果的平衡點，那麼以後在掃描的話不用考慮一律輸入22就對了。
總之阻塞越大，掃描越慢，掃描結果越多越準確。
反之阻塞越小，掃描越快，掃描結果越少，越會漏掉。
但是話說回來了，瘦死的駱駝比馬大，syn掃描即使再慢也比tcp快，我還做了一個tcpscanner進行標準tcp掃描，並且模擬半連接加入連接超時優化到最優啦，同樣是掃整個南朝鮮1433，直接開1024線程，結果好幾天才掃完，但是syn我把阻塞設到了36，也不過6、7個小時就完了。所以說能syn的還是要syn，tcp怎麼折騰都是沒法掃巨量的。
順便說下南朝鮮ip總共有IP地址：112258818個，這是2012年11月10日純真ip庫的結果。
純真ip合併程序請看此貼 http://blog.csdn.net/laotse/article/details/24787719
現在大家知道阻塞和降速的意義了，但是爲什麼我說難就難在如何降速呢。
這就是勞什子的windows不是實時系統計時器不精確的問題了
比如說System.Threading.Thread.Sleep(1);意思就是線程休息1毫秒對吧。不對！他休息了15毫秒。windows計時器精度底線就是15毫秒。這樣通過計時器每隔一段時間發送一個syn的想法就不能用了，因爲這樣最快15毫秒才能發一個，一秒才發66個，這種速度是絕對不能接受的。15毫秒這個界限直到我現在用的win8.1 x64依然如此，你可以試試，無論.net哪個timer都這樣，因爲win api就這樣。
Thread.Sleep(new TimeSpan(9999)); 0.9999毫秒，不起作用，相當於沒這句
Thread.Sleep(new TimeSpan(10000)); 整1毫秒，按15毫秒來。
就差一個timespan，結果就是天壤之別。
這個問題是操作系統決定的，沒法逾越。
於是就只有靠歪門邪道來降低處理速度了，那就是加入空循環，讓cpu進行大量無效運算拖慢cpu，於是cpu處理髮送syn就變慢了，發送速度就降下來了，但是這樣致使cpu一個核一直100%，所以說syn掃描想快容易想慢難，在windows下想快於15毫秒貌似也只能用這種野蠻的方式了，他們也都是這麼做的。
