• <em id="6vhwh"><rt id="6vhwh"></rt></em>

    <style id="6vhwh"></style>

    <style id="6vhwh"></style>
    1. <style id="6vhwh"></style>
        <sub id="6vhwh"><p id="6vhwh"></p></sub>
        <p id="6vhwh"></p>
          1. 国产亚洲欧洲av综合一区二区三区 ,色爱综合另类图片av,亚洲av免费成人在线,久久热在线视频精品视频,成在人线av无码免费,国产精品一区二区久久毛片,亚洲精品成人片在线观看精品字幕 ,久久亚洲精品成人av秋霞

            sockscap教程(SOCKSCAP)

            更新時間:2023-03-02 09:03:47 閱讀: 評論:0

            背景

            一般來講,國內運營商都有QoS

            百度百科:QoS ( Quality of Service,服務質量)指一個網絡能夠利用各種基礎技術,為指定的網絡通信提供更好的服務能力,是網絡的一種安全機制, 是用來解決網絡延遲和阻塞等問題的一種技術。

            說白了就是在網絡擁堵的時候運營商會直接把一些不重要的流量包丟掉,至于啥是“不重要的”就要去問運營商了(看人下菜碟)。對被 QoS的用戶來說,表現就是、網速降低、丟包、ping 值極不穩定,給錢越多的網絡質量越好,例如帶寬更高,丟包更少,延遲更低。

            當然QoS是不區分TCP和UDP的,對于UDP而言,除了常規QoS,還有更嚴格的限制甚至在某些極端情況下會屏蔽掉UDP,主要原因是UDP無連接、無狀態、支持廣播、最大努力送達等特性讓運營商控制UDP的成本太高

            來一張喜聞樂見的對比圖

            一般游戲為了保證實時性,都會采用UDP進行網絡傳輸,比如玩射擊游戲角色正在行走的時候,網絡卡了一下,但是一秒不到游戲角色已經移動到下一個位置了,這是UDP的表現,它盡最大努力送達,允許丟包;假設是TCP,網絡卡一下,你會發現游戲畫面暫停了,角色向卡幻燈片一樣的往前行走,因為TCP是面向連接的,丟包會重發,到達會確認。

            當然游戲不全是UDP,TCP甚至更上層的HTTP也有,這完全取決于游戲對延遲的要求。

            那么游戲中到底是用UDP還是TCP呢?

            如果是由客戶端間歇性的發起無狀態的查詢,并且偶爾發生延遲是可以容忍,那么使用HTTP/HTTPS吧。如果客戶端和服務器都可以獨立發包,但是偶爾發生延遲可以容忍(比如:在線的紙牌游戲,許多MMO類的游戲),那么可考慮使用TCP長連接如果客戶端和服務器都可以獨立發包,而且無法忍受延遲(比如:大多數的多人動作類游戲,一些MMO類游戲),那么考慮使用UDP

            在玩一些外服游戲(游戲服務器在國外)的時候,直連效果差,需要加一層代理也就是加速器,實現加速效果,因為游戲一般為UDP傳輸但運營商對UDP干擾嚴重,所以需要將游戲客戶端到代理服務器之間的連接做一些處理。

            UDP QoS

            下面詳細說一下針對UDP的QoS,UDP socket每次發包都換一個不同的源端口,如果一個設備瘋狂發送UDP包,將會在短時間內創造大量的五元組。傳統的狀態防火墻,狀態NAT會用一個 五元組來追蹤一條 連接 。如果連接過多,就會對這些保存狀態的設備造成很大的壓力,這種壓力主要體現在兩個方面:

            存儲壓力:設備不得不配置大量的內存來保存大量的連接。處理器壓力:設備不得不在數據包到來的時候花更多的時間來匹配到一條連接。

            由于UDP的無狀態特征,沒有任何報文指示一條連接什么時候該創建什么時候該銷毀,設備必須有能力自行老化已經創建的UDP連接,且不得不在權衡中作出抉擇:

            如果老化時間過短,將會破壞正常通信但通信頻率很低的UDP連接。如果老化時間過長,將會導致已經無效的UDP連接消耗大量的內存,這將為DDoS攻擊創造一個攻擊面。

            攻擊者只需要用不同的UDP五元組構造報文使其經過狀態設備即可,由于UDP報文沒有任何指示連接創建銷毀的控制信息,狀態設備不得不平等對待任何新來的五元組,即為它們創建連接,并且指定相同的老化時間。TCP與此完全不同,由于存在syn,fin,rst等控制信息,狀態設備便可以針對不同狀態的TCP連接指定不同的老化時間,ESTABLISHED狀態的連接顯然要比其它狀態的連接老化時間長得多。

            這導致使用TCP來實施同樣的攻擊會困難很多。為什么快速構造不同的TCP五元組達不到UDP同樣的效果?如果你只是盲目的用不同源端口發送syn,在沒有真正的對端回應的情況下,這種狀態的連接將會很快老化掉(10秒以內,甚至更短)。

            如果你構造使用不同端口的大量真正的TCP連接,那么在狀態設備受到傷害的同時,你自己也必須付出巨大的代價來維持住這些連接。你發起一個TCP連接,為了讓狀態設備保存這條連接,你自己也不得不保存這條連接,除非你通過海量的反射主機同時發起真連接,否則在單臺甚至少量的主機上,這種攻擊很難奏效。

            對于無狀態設備,我們便不必再糾結五元組連接的保持了。但是UDP短期構造海量五元組的能力仍然會影響無狀態設備包分類算法的正常運行。基于包分類算法的優先級隊列,緩存管理幾乎也是通過五元組計算來完成的,UDP的特征將會使無狀態設備對其做流量管控變得困難。其結果就是,眼睜睜任憑UDP流量擠滿各級隊列緩存卻沒有辦法將其精確識別出來,即便是BBR遇到了UDP流量,也只能自降pacing rate而興嘆。

            運營商對TCP更加友好,對UDP不友好,但卻無力深度檢測TCP連接的真實性。

            一個簡單的例子就是將正常TCP數據的protocol字段改成UDP,丟包率大大增加了,甚至根本無法通信!

            if (iph->protocol == IPPROTO_TCP) { iph->protocol = IPPROTO_UDP; ip_nd_check(iph); udph->check = 0;} el if (iph->protocol == IPPROTO_UDP) { iph->protocol = IPPROTO_TCP; ip_nd_check(iph);}加速器原理

            加速器的原理很簡單,就是UDP代理,主要難在兩點,其一是怎么處理游戲客戶端到加速器服務器之間的UDP連接,其二是怎么讓游戲客戶端去連接這個加速器(一般游戲客戶端是沒有設置代理服務器的功能的)

            處理UDP

            處理UDP有兩種思路,一種是協議套娃,將游戲的UDP包外面套一層TCP(UDP over TCP ),到了目的地再把TCP解包成UDP,最后在發送到游戲服務器,返回的數據包也做同樣處理;另外一種是偽造TCP(FakeTCP),對UDP數據包加上偽造的TCP包頭,讓其看起來像是TCP協議,欺騙運營商。

            UDP over TCP

            UDP over TCP 或者 UDP in TCP都是一回事,就是把UDP協議封裝到TCP協議里。其缺點是會影響UDP傳輸的速率和實時性,因為TCP有可靠傳輸、擁塞控制、按序到達等特性,這些特性都是會犧牲速率和實時性且無法避免掉的:

            如果網絡很好不丟包,那么UDP in TCP方案會工作得很好;如果網路稍微有一點丟包,數據包的延遲會極大得增加。 (按序到達造成的副作用)如果帶寬充足,UDP in TCP方案也會工作得很好;如果UDP數據發送的數據一但超過了TCP的帶寬,連接就會卡住一段時間,有時候會造成超過10秒的時間無法發送數據。(可靠傳輸、擁塞控制造成的副作用)

            原理如下圖所示

            常見項目:

            https://github.com/mullvad/udp-over-tcp$$R中的udp in tcp選項v2ray中的VMess協議也是支持ucp over tcpFakeTCP

            用raw socket給UDP協議直接加上偽造的TCP包頭,把UDP偽裝成TCP;本質上還是UDP,不需要經過系統的TCP協議棧,所以不會有UCP over TCP引入的問題。但是偽裝成TCP的UDP流量可以騙過運營商的防火墻,可以避免UDP斷流。這就是FakeTCP。原理如下圖

            FakeTCP跟UDP over TCP方案相比的缺點是無法穿透TCP代理(包括反向TCP代理),比如Haproxy。

            常見項目:

            udp2raw:https://github.com/wangyu-/udp2raw游戲客戶端連接加速器SSTap

            SSTap全稱SOCKSTap, 是一款使用虛擬網卡在網絡層實現的轉發工具。 SSTap能在網絡層攔截全部連接并轉發給HTTP、SOCKS4/5。 而無需對被代辦的應用程序做任何修改或設置。 它能同時轉發TCP、UDP數據包。

            SSTap會在電腦中安裝一個虛擬網卡,配合網絡規則(比如哪些IP走這個虛擬網卡,哪些不走)

            然后在配置路由表中添加如下規則(cmd中netstat -nr可查看)

            網絡目標 網絡掩碼 網關 接口 躍點數0.0.0.0 0.0.0.0 10.198.75.61 10.198.75.60 20.0.0.0 128.0.0.0 10.198.75.61 10.198.75.60 2

            10.198.75.60即為上面設置的虛擬網卡的IP,如果網絡規則設置的全局,那就是真全局(接管系統中所有程序的UDP/TCP流量),包括系統CMD命令都會被代理到,如下實測,當不開啟SStap時,百度能ping通,開啟時,全部超時(因為我的梯子屏蔽了百度)

            C:Ursxxx>ping www.baidu.com正在 Ping www.a.shifen.com [110.242.68.4] 具有 32 字節的數據:來自 110.242.68.4 的回復: 字節=32 時間=36ms TTL=53來自 110.242.68.4 的回復: 字節=32 時間=36ms TTL=53來自 110.242.68.4 的回復: 字節=32 時間=36ms TTL=53來自 110.242.68.4 的回復: 字節=32 時間=36ms TTL=53?110.242.68.4 的 Ping 統計信息: 數據包: 已發送 = 4,已接收 = 4,丟失 = 0 (0% 丟失),往返行程的估計時間(以毫秒為單位): 最短 = 36ms,最長 = 36ms,平均 = 36ms?# 開啟SStap之后ping百度C:Ursxxx>ping www.baidu.com?正在 Ping www.baidu.com [110.242.68.3] 具有 32 字節的數據:請求超時。請求超時。請求超時。請求超時。?110.242.68.3 的 Ping 統計信息: 數據包: 已發送 = 4,已接收 = 0,丟失 = 4 (100% 丟失),

            然后在2017年,作者聲稱硬盤損壞,數據丟失,現已停止開發。所以后續不會再有更新了,未來也許會不可用。但是現在(2021)依然可用

            各歷史版本收藏:https://github.com/solikethis/SSTap-backup備用鏈接: https://sabrinathings.lanzous.com/b01hin52h官網:https://www.sockscap64.com/sstap-享受游戲-使用sstap/Netch

            一款可代替SStap的開源網游加速工具,眾所周知的游戲加速工具SStap已于2017年年11月19日停止開發及維護,雖然停止了維護與開發,時至今日,其依然是一款熱門的游戲加速工具。但是由于年久失修,已經難以適應部分新出的網絡游戲,可能會被新出的游戲認定為外掛程序。

            不同于SSTap那樣需要通過添加規則來實現黑名單代理,Netch原理更類似Sockscap64,通過掃描游戲目錄獲得需要代理的進程名進行代理。與此同時Netch避免了SSTap的NAT問題,使用SSTap加速部分P2P聯機,對NAT類型有要求的游戲時,可能會因為NAT類型嚴格遇到無法加入聯機,或者其他影響游戲體驗的情況。

            項目地址:https://github.com/netchx/netch實現

            實現主要說明基于UDP over TCP的實現,主要原因為在已有nginx + websocket的環境下改動最小,不用打開額外UDP端口,因為其本質是TCP,保證現存環境的穩定性,如果引入FakeTCP,則必須打開新的UDP端口,引入新的不確定性。

            基于UDP over TCP的實現

            主要方案為nginx + tls + websocks + vmess,整個連接過程如下圖所示

            環境概述:

            服務端已配置好標準https站點(nginx接入,端口為標準443,證書正常未過期)服務端配置v2ray,使用vmess協議,其默認支持UDP over TCP方案客戶端使用v2rayN,在本地電腦打開socks代理,供瀏覽器等使用客戶端使用SStap,連接v2rayN開在本地的socks代理,在網絡層添加虛擬網卡,供所有聯網程序使用

            以下為詳細步驟

            服務端:搭建標準https站點

            買域名、買VPS這些過程就不贅述了,主要說明標準https站點的作用是防止流量特征被探測,因為對防火墻來說這就是普通的瀏覽網站的流量,我們的代理程序藏在https后也會被認為是https流量,每天從防火墻經過的https流量是海量的,所以很安全。

            站點使用nginx搭建,證書使用certbot-nginx自動添加免費證書(三個月過期一次)

            安裝過程不贅述,認證的時候使用如下命令根據提示完成域名認證即可

            /usr/bin/certbot --nginx --register-unsafely-without-email

            主要說一下nginx的配置,需要將指定路徑下的流量轉發給v2ray,此處以/ray為例,這個路徑是隨機的,保持客戶端和服務端配置一致即可

            erver { listen 443 ssl; ssl on; ssl_certificate /etc/v2ray/v2ray.crt; ssl_certificate_key /etc/v2ray/v2ray.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; rver_name mydomain.me; # 與 V2Ray 配置中的 path 保持一致 location /ray { proxy_redirect off; #假設WebSocket監聽在環回地址的10000端口上 proxy_pass http://127.0.0.1:10000; # 升級websocket proxy_http_version 1.1; proxy_t_header Upgrade $http_upgrade; proxy_t_header Connection "upgrade"; proxy_t_header Host $http_host; # Show realip in v2ray access.log proxy_t_header X-Real-IP $remote_addr; proxy_t_header X-Forwarded-For $proxy_add_x_forwarded_for; }}服務端:配置Vmess

            v2ray配置主要參考:https://toutyrater.github.io/advanced/wss_and_web.html

            下載v2ray程序后使用如下配置啟動:v2ray -config /path/to/config.json

            入站流量:即為Nginx轉發過來的流量,此時TLS證書已在Nginx卸載,得到的是明文數據,注意路徑/ray要和nginx對應出站流量:出站不設限制

            { "inbounds": [ { "port": 10000, "listen":"127.0.0.1",//只監聽 127.0.0.1,避免除本機外的機器探測到開放了 10000 端口 "protocol": "vmess", "ttings": { "clients": [ { "id": "b831381d-6324-4d53-ad4f-8cda48b30811", "alterId": 64 } ] }, "streamSettings": { "network": "ws", "wsSettings": { "path": "/ray" } } } ], "outbounds": [ { "protocol": "freedom", "ttings": {} } ]}

            此時,如果訪問https://mydomain.me/ray得到一個Bad Request說明服務端成功

            客戶端:配置v2rayNhttps://github.com/2dust/v2rayN/releas

            v2rayN是v2ray一個HUI客戶端,v2ray本身即可作為服務端也可作為客戶端,所以這這是套殼,并且這種模式下,客戶端程序會有很多,都是套殼而已,客戶端參考:https://www.v2ray.com/awesome/tools.html

            客戶端配置

            入站流量:監聽本地1080端口,所有使用該端口的流量都轉發給outbounds出站流量:以https的形式轉發給上文配置的服務端,注意路徑/ray需和上文一致

            { "inbounds": [ { "port": 10808, "listen": "127.0.0.1", "protocol": "socks", "sniffing": { "enabled": true, "destOverride": ["http", "tls"] }, "ttings": { "auth": "noauth", "udp": fal } } ], "outbounds": [ { "protocol": "vmess", "ttings": { "vnext": [ { "address": "mydomain.me", "port": 443, "urs": [ { "id": "b831381d-6324-4d53-ad4f-8cda48b30811", "alterId": 64 } ] } ] }, "streamSettings": { "network": "ws", "curity": "tls", "wsSettings": { "path": "/ray" } } } ]}

            如果手動填寫參考如下,特別需要注意紅框中的字段需要與服務端一致!

            此時,在127.0.0.1接口10808端口上已經啟動監聽,將瀏覽器代理設置成這個端口可以禾目學上網了,注意VMess協議要求客戶端和服務端的時間相差不能超過90s,如果連不上,請先檢查下時間是否一致。

            客戶端:配置SStap

            打開SStap,手動添加一個SOCKS5代理,如下圖所示

            點擊下方小齒輪設置勾選掉不轉發UDP和代理DNS服務器

            然后打開游戲,最后在進入游戲界面以后點擊鏈接,點擊右側閃電圖標測試,右側如果現實TCP和UDP通過說明連接成功(圖中接收包失敗是因為我的服務器屏蔽了百度,而SStap會用百度作為鏈接測試)

            最后如果能順利進入游戲說明加速成功!下圖右側為游戲服務器IP檢測程序輸出結果,左側為v2rayN日志,結合起來可以看出游戲服務器無論TCP協議還是UDP協議都已經被代理了!

            游戲服務器IP檢測程序:https://github.com/oooldtoy/SSTAP_ip_crawl_tool

            客戶端:SStap規則配置

            由于SStap年久失修,很多新出的游戲規則沒有,所以需要自行制作,可以通過工具:SSTAP_ip_crawl_tool,原理也很簡單,通過指定進程,然后檢測該進程的所有對外部發出的TCP和UDP連接,取出服務器IP,然后自動生成SStap規則

            項目地址:https://github.com/oooldtoy/SSTAP_ip_crawl_tool

            源碼是由python寫成,嫌麻煩可以直接使用打包好的exe版本:

            https://github.com/oooldtoy/SSTAP_ip_crawl_tool/releas/download/v4.0/ip_crawl_tool.v4.0.exe

            輸入相關信息后多玩一會兒游戲即可抓取IP

            最后生成的規則在程序所在目錄,如下生成為ItTakesTwo.exe游戲的規則,最后將規則添加到SStap即可

            #none,['ItTakesTwo.exe'],0,0,1,0,1,0,By-ip_crawl_tool239.255.255.0/24159.153.36.0/24159.153.42.0/24109.200.221.0/24109.200.215.0/24185.50.104.0/2452.88.180.0/24255.255.255.0/24參考https://www.cnblogs.com/crazytomato/p/7987332.htmlhttps://blog.csdn.net/dog250/article/details/113706995https://tachyondevel.medium.com/教程-在-windows-上使用-tun2socks-進行全局代理-aa51869dd0dhttps://toutyrater.github.io/advanced/wss_and_web.htmlhttps://github.com/oooldtoy/SSTAP_ip_crawl_tool

            發布于 11-21 17:37

            本文發布于:2023-02-28 21:02:00,感謝您對本站的認可!

            本文鏈接:http://m.newhan.cn/zhishi/a/167771902797277.html

            版權聲明:本站內容均來自互聯網,僅供演示用,請勿用于商業和其他非法用途。如果侵犯了您的權益請與我們聯系,我們將在24小時內刪除。

            本文word下載地址:sockscap教程(SOCKSCAP).doc

            本文 PDF 下載地址:sockscap教程(SOCKSCAP).pdf

            標簽:教程   sockscap   SOCKSCAP
            相關文章
            留言與評論(共有 0 條評論)
               
            驗證碼:
            Copyright ?2019-2022 Comsenz Inc.Powered by ? 實用文體寫作網旗下知識大全大全欄目是一個全百科類寶庫! 優秀范文|法律文書|專利查詢|
            主站蜘蛛池模板: 亚洲天堂av在线免费看| 国产精品久久蜜臀av| 国产精品视频白浆免费视频| 国产精品视频一区二区噜| 国产成人精品中文字幕| 精品亚洲精品日韩精品| 忘忧草在线社区www中国中文 | 中文字幕乱码熟妇五十中出| 久久午夜无码鲁丝片直播午夜精品| 亚洲人成网站18禁止大app| jk白丝喷浆| 亚洲精品美女一区二区| 成人精品自拍视频免费看| 国产精品久久久久久久9999| 国精产品一区一区三区有限| 国产精品伊人久久综合网| 久久国产精99精产国高潮| 又黄又爽又色视频| 国产精品自拍视频我看看| 性夜黄a爽影免费看| 伊人久久综在合线亚洲91| 国产乱码精品一区二三区| 扒开双腿猛进入喷水高潮叫声| 色吊丝一区二区中文字幕| 深夜在线观看免费av| 国产成人AV一区二区三区在线| 强伦姧人妻免费无码电影| 2021无码天堂在线| 日韩一区二区一卡二卡av| 狠狠色综合久久丁香婷婷| 在线a人片免费观看| 性一交一乱一乱一视频| 男人的天堂va在线无码| 毛多水多高潮高清视频| 人妻无码∧V一区二区| 欧美黑人巨大xxxxx| 日韩av综合中文字幕| 亚洲av男人电影天堂热app | 狠狠色噜噜狠狠狠狠777米奇| 国产高清在线精品一区不卡| 乱60一70归性欧老妇|