由於我是個粗人，是個菜鳥，只會講大白話，只想知道咱老百姓想聽的內容。

不知道為什麼那些網文作者都說socks代理比http代理複雜，http代理和socks代理我都做了，明顯感覺http代理比socks代理要複雜很多，因為http代理要自己解析http協議，這是我的http代理http://blog.csdn.net/laotse/archive/2010/09/24/5903651.aspx

而socks代理除了開頭那一點點外，其他就是什麼不管就轉發轉發就行了。

我做的那個http代理可謂很失敗，用著用著就cpu100%佔用了，應該就是解析http協議頭做的不好，出現死迴圈了或者別的，那麼多http頭實在不想再分析了，ccproxy我也sniffer了，結果是看到它也出現了許多錯誤的解析，ccproxy都多少年了，都解析不好，說明解析http協議確實不容易啊。

所以我很懷疑那些網文作者到底做沒做過http代理就信口開河說http代理比socks代理簡單。

socks代理裡面，有socks4 socks4a socks5，也有叫sock4 sock4a sock5的，都是一回事。

socks4 socks4a和socks5的tcp部分極其簡單。

這又出現一個怪現象了，網文中除了一個人說道udp比tcp複雜，其他的全都說udp簡單，只說tcp部分，把udp都一筆帶過了。

而我就明顯感到udp比tcp複雜很多。

socks的rfc是rfc1928和rfc1929，別看了，打個比方，某人看到一本書，當他看了目錄，準備往後翻看內容時，發現已經到底了，原來這不是“目錄”它就是內容，這就是rfc1928，話說rfc是幹什麼的啊，寫成這樣就算交活了啊，還有王法嗎，還有法律嗎。中文翻譯的就像是機器翻譯一樣，不是人類語言。所以造成網文上全都是連蒙加猜，沒有一個對的，這兩天我連續翻看那些網文，又用現成的帶socks的程式然後sniffer，算是知道了個大概，其實用程式編寫出來很簡單，關鍵就是rfc的協議說的不明不白的，所以造成本來很簡單的事情，弄得大家全都一知半解。

socks4和socks4a只代理tcp。

socks4

比如ie可以直接用socks代理，但是ie只能用sock4代理，即使我現在用最新的ie9仍然如此。比如ie要用sock4訪問百度，那麼ie就先用本地的dns把百度轉成ip比如202.108.22.5，然後向sock4伺服器傳送

04 01 00 50 CA 6C 16 05  41 64 6D 69 6E 69 73 74 72 61 74 6F 72 00

1、其中開頭04 01是固定的

2、00 50是ie要連線站點的埠號，這裡是80埠，十六進位制就是00 50

3、CA 6C 16 05就是202.108.22.5的十六進位制

4、41 64 6D 69 6E 69 73 74 72 61 74 6F 72是Administrator的acsii碼

5、最後一個00也是固定的

這就是socks4的固定格式04 01+埠2位元組+ip4位元組+id+00，其中的id，這裡是Administrator是可有也可以沒有，因為我現在win7用的賬戶是Administrator所以ie就把賬號名給發過去了，我試了一下最新的火狐4.0，他傳送MOZ，有的就直接省略掉了

04 01 00 50 CA 6C 16 05 00 所以發成這樣也行，隨便寫什麼都行，只要最後一個是0中間沒有0就行了。

如果代理伺服器允許代理，比如驗證一下那個id，比如你想只允許id是administrator後，允許代理了，就發回8個位元組

04 5A 00 50 CA 6C 16 05

看到了嗎，區別就是第二個位元組是5A而且最後沒有00，那麼就是允許代理。其實根據協議5A這裡可以換其他的反饋位元組，但是我們就不要管了，如果你做的代理程式不允許他用，那麼直接就在程式中斷開連線就行了。

如果允許連線了，然後就把客戶端的所有資料原封不動的發到遠端主機，把收到遠端主機的內容原封不動發回客戶端就行了，以下我就簡稱交換交換就行了。

socks4a

細心的人會發現一個問題，在sock4中，客戶端比如ie要用sock4代理訪問百度，ie會在本地dns解析出百度的ip202.108.22.5，而不是通過sock4代理的那個機器的dns解析的，這樣就會出現一個問題，比如你的那個機器是個受限制的網路dns不給你解析域名，只讓你以ip方式訪問網路，那麼怎麼辦呢？就沒辦法了對吧，你知道百度的ip沒用啊，網路上都以域名形式存在的，其他的你都能知道嗎對吧。那麼ie為什麼要在本地dns解析而不再sock4代理機器上解析呢？因為sock4協議就這樣的，否則就不叫sock4協議了。

所以sock4a協議就是為了彌補這個問題的，可以讓客戶把域名發到sock4a代理機器上，用這個代理機器上的dns解析出ip，這樣就克服了客戶端不方便解析域名的情況，而且有的網站比如google在本地解析和在代理伺服器解析域名得到的ip是不一樣的，在代理伺服器解析域名得到的ip更好，一般連線速度更快也更像就是從代理伺服器發起的。

socks4a是這樣的，擷取我用flashfxp通過socks4a代理登入sourceforge的sftp

04 01 00 16 00 00 00 01  6C 61 6F 74 73 65 00 65 62 2E 73 6F 75 72 63  65 66 6F 72 67 65 2E 6E  65 74 00

1、04 01是固定的

2、00 16是埠22的十六進位制

3、00 00 00 01是原本ip地址的地方，這裡前3個位元組必須為0，最後一個必須不能為0，一般都是1

4、6C 61 6F 74 73 65是laotse的ascii，我設的flashfxp代理的命名，可以沒有，和sock4一樣

5、00 固定的，和sock4一樣，如果第四步的id沒有，這個00也不能省略

6、65 62 2E 73 6F 75 72 63 65 66 6F 72 67 65 2E 6E 65 74 就是域名web.sourceforge.net的ascii了

7、00 固定的。

這樣就可以看出，就是把sock4的ip那地方換成00 00 00 xx這樣的假ip，然後再sock4後面多了域名+00

這樣socks4a代理首先把web.sourceforge.net解析成216.34.181.70（D8 22 B5 46），並且和216.34.181.70連線上，再向客戶端傳送

04 5A 00 16 D8 22 B5 46

和sock4一樣的，依然是04 5A+埠+IP共8位元組。

然後就和sock4一樣就是轉發轉發了，如果不允許代理直接斷開就行了也不用傳送什麼反饋了。

所以明顯socks4a比socks4要好，這樣避免了本地對域名解析帶來的問題，話說如果你要上些不和諧的站呢，總是用本地dns解析那些域名……是吧。所以能用socks4a就不要用socks4，但是杯具的是ie只能用sock4，ie9也如此，火狐也是。

看到了吧socks4和socks4a就是這麼簡單，簡單的不能再簡單了。

socks5

socks5代理和socks4 socks4a比，多了一個驗證功能和udp代理的功能。

socks5的tcp代理幾乎和socks4 socks4a一樣簡單，但是udp卻比較複雜一點，但是再複雜也沒有http代理那麼複雜。

首先說驗證，不管是要代理tcp還是udp，開始驗證都是要一個tcp連線的，而且驗證過程一樣，驗證完了才分tcp和udp的實際代理過程，有好幾種驗證，別管了，其他的都用不到太小眾化了，那些協議是什麼都沒聽說過，也沒處試驗去，信我的，就記住3種就行

如果一個客戶想通過socks5代理，那麼開始他會發送以下3種內容

05 01 00 共3位元組，這種是要求匿名代理

05 01 02 共3位元組，這種是要求以使用者名稱密碼方式驗證代理

05 02 00 02 共4位元組，這種是要求以匿名或者使用者名稱密碼方式代理

如果socks5代理允許匿名那麼就返回05 00兩個位元組，如果要求驗證就返回05 02兩個位元組。

這裡匿名等一下，先說要求密碼驗證的，因為要求驗證就比匿名多了一步而已，後頭是一樣的，所以先說密碼驗證。

當上面socks5返回05 02兩個位元組後

客戶端傳送01 06 6C 61 6F  74 73 65 06 36 36 36 38 38 38

1、01固定的

2、06這一個位元組這是指明使用者名稱長度，說明後面緊跟的6個位元組就是使用者名稱

3、6C 61 6F 74 73 65這就是那6個是使用者名稱，是laotse的ascii

4、又一個06共1個位元組指明密碼長度，說明後面緊跟的6個位元組就是密碼

5、36 36 36 38 38 38就是這6個是密碼，666888的ascii。

6、假如這後面還有位元組，一律無視。

這時socks5代理就驗證了使用者名稱laotse密碼666888對不對啊，如果不對直接關閉連線就可不用反饋了。

如果這個使用者名稱和密碼通過了，可以進行代理，那麼就傳送01 00給客戶端。那麼下面就和匿名是一樣的了，匿名就是省略了這一步而已。

這時無論匿名或者通過了密碼驗證的客戶端向socks5傳送下列三種方式

先說tcp的

第一種

05 01 00 03 13 77  65 62 2E 73 6F 75 72 63  65 66 6F 72 67 65 2E 6E  65 74 00 16

1、05固定

2、01說明是tcp

3、00固定

4、03說明後面跟著的是域名而不是ip地址，由socks5伺服器進行dns解析

5、13前面指明瞭是域名，那麼0x13（19位元組）是域名字元長度

6、77 65 62 2E 73 6F 75 72 63 65 66 6F 72 67 65 2E 6E 65 74 就這19個是域名web.sourceforge.net的ascii。

7、00 16埠，即為22埠。

第二種

05 01 00 01 CA 6C 16 05 00 50

1、05固定

2、01說明tcp

3、00固定

4、01說明是ip地址

5、CA 6C 16 05就是202.108.22.5了，百度ip

6、00 50埠，即為80埠

看到了嗎，tcp的可以本地解析出ip來，只讓socks5代理去連，也可以發過域名去讓socks5去用它的dns去解析ip再連線

這時代理伺服器收到了上面的請求後，如果是域名的，先解析出ip來連線，如果直接是ip的就用一個tcp連線去連線那個ip和埠，如果和遠端主機連線成功了，就向客戶傳送什麼呢

05 00 00 01 C0 A8  00 08 16 CE共10個位元組

無論上面兩種哪一種都是這樣

1、05 00 00 01固定的

2、後面8個位元組可以全是00，也可以傳送socks5伺服器連線遠端主機用到的ip地址和埠，比如這裡C0 A8 00 08，就是192.168.0.8，這是我socks5伺服器的ip地址，16 CE即5838埠，即是socks5伺服器用5838埠去連線百度的80埠。也可以05 00 00 01 00 00 00 00 00 00，只告知客戶連線成功不告訴他細節，但是0不要省略。

後面就是在客戶和遠端主機之間轉發轉發啊的，是不是很容易啊，比http代理簡單太多了。

然後說udp的，udp的要複雜不少。首先要說下原理，udp和tcp不一樣，不是一個連線中一口氣下來的，上面說了不管tcp還是udp上面的那個tcp協商部分都是一樣的，而且如果是udp的話會佔用socks5代理一個tcp連線一個udp。

第三種udp的

客戶端如qq傳送（仍在剛才的tcp中傳送）

05 03 00 01 00  00 00 00 E5 F0

1、05固定

2、03說明是要代理udp

3、00固定

4、01固定，只能制定後面跟著的是ip地址

5、00 00 00 00這裡可以由客戶端如qq傳送客戶的ip，也可全是0，因為這個ip地址沒用。

6、E5 F0最重要的一條，客戶端比如qq，向socks5代理說明它預備開放的udp埠，這裡是58864。

那麼socks5怎麼回答呢？如果不同意代理直接關閉連線就可以了不用反饋了。如果同意的話，socks5要這麼做，首先準備一個ip和一個udp埠，比如我用192.168.0.8這個ip上開放58865udp埠給客戶轉發用。然後返回

05 00 00 01 C0 A8  00 08 E5 F1

1、05 00 00 01固定

2、C0 A8 00 08預備開放udp埠開放給客戶的ip，這裡是192.168.0.8，如果多ip機器，那麼返回下面開放udp埠繫結的那個ip。

3、E5 F1返回給客戶說明預備開放哪個埠，這裡是58865。

好了tcp協商部分完成了，注意這個tcp連線一定不要關閉，要一直開著，雖然再也不會發送和接受資料了，但是要一直開著，如果這個連線一關，那麼客戶就認為連線被斷開了，因為這就是socks5協議，所以說socsk5轉發udp不但要佔用一個udp還要佔用一個tcp連線。麻煩吧。

上面那個tcp不要關，下面就是客戶和socks5的2個udp埠之間進行資料交換了，這裡udp麻煩的一方面又體現出來了，它就是無連線的，它不像tcp那樣因為tcp協議部分就保證了資料的可靠性，這麼說吧比如tcp連線qq傳送abcdef，這些資料太大了一次傳送不完，那麼就會分片，那麼socks5可能會收到ab第二次c第三次def這樣的，雖然不知道能一次收多少，但是隻要連起來還是abcdef的順序，而且不會出現資料丟失而傳送方不知道的情況。udp就不一樣，可能第一次就接到了def，第二次才接到a，bc可能直接就丟了還不知道，所以要保證udp資料的完整，不能靠udp協議這一層了，得自己手動指定，那麼在socks5裡就有一個udp分包的概念，就是在頭幾個位元組指定這是1號包還是2號包，socks5程式必須自己弄個排序，比如第一次接到標記為3號的包，那麼先存起來等著1號2號來了把3號放後面再發，所以說是很麻煩的，而且rfc也說了應用程式儘量不要弄這種分包，而且rfc說了，socks5程式可以選擇拒絕這種分包方式接到後直接丟棄而不通知客戶端，所以既然那麼麻煩，咱也不用去實現這用不大上的功能，因為即使你這socks5程式實現了，對於應用程式比如qq來說還是不可靠的，而使用udp的應用程式在它應用程式本身就有個完整性和排序的功能，比如丟包了，qq之間自己就知道了，qq之間自己會去想辦法重發還是排序的什麼的，所以我們就不用去管分包了，讓應用程式自己去解決吧，我們只實現轉發不分包的那種就行了。

 既然只實現不分包的，那麼格式就固定了

客戶端qq的58864udp埠向socks5的58865udp埠傳送什麼呢，仍然是ip+埠或者域名+埠方式

00 00 00 01 70 5F F0 3C  1F 40 +實體資料          

比如這個，00 00 00 01開頭，那麼後面4個就是ip地址70 5F F0 3C即112.95.240.60，1F 40 即埠8000，後面的全都是實體資料了。那麼socks5伺服器就用58865udp埠向qq的伺服器112.95.240.60的8000埠傳送後面的實體資料而不要傳送前面那些封裝內容，那麼會受到qq伺服器返回58865udp埠的資料，返回的都是實體資料，因為代理嘛，就像是socks5那臺機器在用qq一樣，所以收到的資料沒有前面的封裝都是實體資料。那麼socks5就要返回給客戶端，還不能直接返回，得包裝一下

00 00 00 01 70 5F F0 3C  1F 40 +收到遠端主機返回的資料

把這個返回給客戶端的58864udp埠

是不是前面包裝內容都是一樣的啊，是一樣的，因為客戶端已經指明瞭ip，所以肯定是一樣的。

還一種是這樣域名的，qq的58864udp埠傳送給socks5的58865udp埠
00 00 00 03 12 67 72 6F  75 70 63 6C 69 65 6E 74  2E 71 71 2E 63 6F 6D 23  29+實體資料

00 00 00 03開頭說明後面跟的是域名，緊跟著的12說明後面0x12(十進位制18)位元組就是域名，解出來就是groupclient.qq.com

後面23 29即埠9001。那麼socks5伺服器就要先把groupclient.qq.com的ip給dns出來58.251.62.164（3A FB 3E A4 ），用58865up埠向58.251.62.164的9001udp傳送後面的實體資料，返回來後和上面一樣向客戶qq的58864udp傳送

00 00 00 01 3A FB 3E A4 23 29 +收到遠端主機返回的資料，03變01了，直接就ip+埠了

大家注意到了沒，客戶和socks5tcp協商後，socks5開放的udp埠，既和客戶開放的udp埠聯絡，也和需要連線的遠端主機之間聯絡，都用一個埠所以有點亂，這樣就得判斷了，如果發現像這個埠如58864udp傳送資料的ip和udp埠，是之前協商的那個，就說明是客戶的資料，這時就要把客戶要傳送的遠端主機的ip和埠記錄下來，比如上例的58.251.62.164的9001udp埠，如果發現是從58.251.62.164的9001udp傳送過來的資料，那麼說明是遠端主機發回的，那麼需要轉發給協商好的客戶，還有一種情況，既不是客戶也不在遠端主機列表中的機器發過來的資料，就要丟棄，而且比如說客戶發過來一條資料是要傳送給遠端A的a埠，那麼傳送出去接收到返回給客戶，客戶又繼續發過來一條，這次要發給遠端B的b埠，那麼就要發出去接收返回給客戶，那麼這時遠端主機就要有個列表了，現在有2條記錄，只要接收到的udp在這2條中，就要轉發給客戶，如果客戶又要發給C的c，那麼列表就3條記錄了，那麼可能4條5條。

看出來了吧，socks5代理udp比起tcp來是很麻煩很麻煩的，不但要佔用一個tcp一直維持連線，而且還要手動搞這種列表，但是話說回來了，雖然麻煩，但是比起編寫http代理去解析http還是要容易多了。

socks5還有一種bind的tcp方式，說是ftp協議中有一種主動模式是一個tcp連上ftp伺服器的21後，經過協商，伺服器的某埠會反向主動連線客戶端的某埠，很早以前好像見過，現在這種模式基本沒用，ftp伺服器和主機協商有什麼用啊，現在的機器要麼是在防火牆後，要麼是在區域網中，ftp伺服器反向連線怎麼能連上客戶呢是吧，所以現在的ftp幾乎都用的是客戶主動連線ftp伺服器的被動模式，socks5的bind就適用於那種老的主動模式，用處很小很小，所以咱不去考慮。

 ie9只能用sock4，4a和5不行

火狐4可以用sock4, 4a不行，可以用sock5，但是是個半殘，不支援使用者名稱和密碼驗證，而且sock5中我上面說了可以發域名過去讓sock5代理去dns解析，但是火狐4卻非要在本地解析域名，只用sock5的ip模式，無法達到徹底隱藏的目的，話說如果你想上某些不和諧站，如果被人發現你老是在本地dns解析那些域名……是吧。rfc管這叫dns洩露。

轉發轉發，怎麼實現客戶和遠端主機之間的轉發呢？

超時怎麼做啊？

我覺得，無論4 4a 還是5，對於tcp的代理，如果發現無論遠端還是客戶只要5分鐘內沒有資料傳輸，就把遠端和客戶的這2條tcp連線斷開就行了，對於5的udp也是，如果發現udp埠5分鐘都沒有客戶的udp資料包發過來，就把這個udp埠關閉，把那個和客戶維持的tcp斷開。而不論4 4a 還是5，只要客戶主動斷開，那麼就把為這個客戶開的一切資源全都關閉掉。不用擔心，一般程式都會定時傳送維持性連線資訊的，不會在那連著不收不發就那麼耗著不管了的，所以5分鐘都沒資料，就可以認為已經斷開了，就關閉就行。

這個問題很嚴重，如果不做好不一會就會把伺服器的埠全部佔滿，親身體會，其實早斷開了，但就是不釋放，好幾天都顯示ESTABLISHED，等到4294967295秒後才會自動關閉，所以這個問題要慎重，保守一點好。

socks代理仍然是明文，就開頭幾個位元組後面全是明文，並不能真正達到隱藏的目的。而且socks代理不支援加密連線。所以我是這樣做的。 肉雞讀取到網路上的某個固定網站上面的某個ip，就連線到我了，是以rsa+aes加密連線的，所以在我的某埠和我的肉雞某埠之間建立了一條加密隧道，ie等程式通過這個加密隧道來到肉雞上面，連線到那裡的socks代理伺服器，通過socks代理連線網路伺服器。這樣連線過程是絕對安全的，而且當初我編寫反向連線伺服器中的aes設的加密位數和金鑰初始化向量都是用最大號的最變態的那種。以前我是把http代理放肉雞上通過這個加密隧道上網，但是由於http代理只能http協議瀏覽網頁用，而且我一開始說了，那個http代理我做的比較失敗，經常不明原因就死迴圈了。現在好了，全都能用了， 應用程式願sock4就sock4，願sock5就sock5，各取所需，多執行緒同時連線，互不干擾，而且全都是通過反連過來的加密隧道，而且這種不用分析tcp之上高層協議只轉發的速度快，不會因為解析協議的邏輯錯誤而出現死迴圈的情況，試了兩天很好，cpu佔用率基本為0左右，記憶體16兆左右。

對了忘記說明重要的一點了，以上我只是用qq舉例說明代理udp的過程，我是不用qq的，有的同志看到我的文章後和我發郵件聯絡就一句話“希望交流某某某 qq:xxxxxx"，我是不用qq的，qq我一年也開不了2、3次，只是我在做這個socks程式，才開了開qq進行測試用的，我聊天都是泡論壇。有想交流的，要麼發郵件，最好能光臨我的網站發帖。