•  cahya untoreh

TCSplitter

Trowongan kanggo pamisah sambungan TCP utawa UDP ing pirang-pirang sambungan TCP

Gol

Kapan sampeyan pengin misahake siji sambungan TCP dadi pirang-pirang sambungan? Biasane sampeyan nggunakake a trowongan kanggo nggayuh kosok baline . Kasus panggunaanku yaiku ngatasi watesan bandwidth ing jaringan seluler, mula tes ditindakake nganggo kertu sim lan ora ana data sing isih ana ing rencana kasebut[1].

Kerjane kepiye

Ing trowongan ditulis ing golang amarga cukup cepet, lan umume digunakake kanggo perkakas jaringan. Klien meh ora bisa digunakake amarga pilihan sing paling akeh diolah maneh nalika nyoba macem-macem cara.

Wiwitane ana "fling" lan "lassos", kanggo misahake sawetara koneksi kanggo metu (flinged) lan mlebu (lassoed), nanging iki minangka abstraksi sing ora perlu amarga luwih becik menehi tag paket karo tujuane, sanajan tujuan utamane yaiku kanggo nawakake watesan tarif sing beda kanggo sambungan sing metu lan mlebu, mula pamisahan tingkat sing luwih dhuwur ing antarane munggah / mudhun katon praktis.

Klien kudu nggawe kabeh sambungan amarga kita nganggep manawa server ora bisa mbukak koneksi metu. Nalika klien nampa sambungan saka aplikasi pangguna, nyiyapake sambungan sambungan sing dibutuhake karo server, lan data apa wae sing ditampa, dipisahake ing antarane koneksi khusus, miturut watesan sing ditemtokake pangguna.

Paket kasebut banjur dikirim menyang server, sing kudu mbentuk maneh dadi urutan sing bener, amarga macem-macem sambungan TCP bisa ngrampungake aliran data kapan wae (pesen sing dikirim ora dihormati, amarga nuntun ), banjur diterusake menyang aplikasi sing nampa.

Sambungan ditutup lan sing anyar dibukak nalika watesan data sing dikonfigurasi saben sambungan wis tekan, padha karo kepiye bayangan bayangandata trowongan proxy ngliwati macem-macem aliran kanthi tujuan masking prilaku stream data, kajaba manawa terowongan kita nindakake sing paling asring.

Kok kerjane

Tujuane ing kene yaiku kanggo ngontrol pira data sing kudu ditrapake. Kanggo tujuan kita, ora bakal ngluwihi biasane yaiku MTU ukuran jendhela. Sampeyan bisa nganggep MTU minangka wates ndhuwur data sing liwat jaringan, lan target kita amarga kita pengin ngliwati watesan tingkat bandwidth jaringan gerbang. Kanggo matesi data sing bisa dilalui klien, sampeyan kudu ngetung iku, bener Yen logika sampeyan bisa digunakake kaya ado-while

Banjur sampeyan kudu paling ora nampa apacket . Aku ora yakin apa iki sing sejatine kedadeyan, utawa sebabe trowonganku bisa digunakake. Mungkin sampeyan bisa mriksa kabeh paket sing pisanan, nanging saka perspektif desain, tegese sampeyan kudu mriksa saben sambungan tunggal, sing bakal nggawe sistem dadi luwih lemah tumrap serangan DOS, lan ya trowonganku bisa digunakake kanthi gampang minangka alat DOS / Stress sing efisien, amarga sampeyan bisa mbagi data menyang paket sing cilik banget (sing tegese koneksi TCP bakal duwe tekanan daur ulang sing dhuwur ) lan duwe blumbang koneksi kaya sing dikarepake.

Tes liwat macem-macem port uga nuduhake yen bisa rampung sawetara port, lan watesan kasebut terus beda ing antarane port, kanthi443 menehi salah sawijining windows sing luwih dhuwur, sekitar20kb , ngiro-iro amargaTLS salaman mbutuhake luwih akeh data, lan watesan tingkat kasebut bakal ganti adhedhasar dina[2].

Asile

Aku nyoba mbusak kode kanthi ngarep-arep bisa nambah output data. Kanthi nggunakake perpustakaan coding erasure lan enc / dekoding data kasebut dhewe, lan uga overlay KCP protokol liwat protokol pamisahku. Nyoba KCP bisa uga katon minangka cara mundur, amarga duwe latensi sing luwih apik kanggo throughput sing luwih murah, nanging asumsi awal yaiku yen bottleneck saya ana ing sambungan mudhun transmisi pertengahan, sing bakal nyebabake akeh paket rusak, mula aku bisa entuk luwih dhuwur throughput karo koreksi kesalahan.

Pranyata mung wates-wates babagan koneksi TCP sing bisa dikirim klien liwat jaringan, dadi mung perlindungan DOS sing ora bisa daklakoni. Sawise X jumlah koneksiSYN upaya mandheg nampa sing dijalukACK , ngisi backlog lan pungkasane nggawe kios trowongan. Nyoba lan nyoba nuduhake manawa ana kemungkinan ing antarane4-8[3] sambungan mbukak kapan wae, lan kanthi MTU saka500-1000 byte sampeyan bisa tetep paling ora stream tetep128kbps , yen stream pancet dudu sarat, sampeyan bisa entuk kacepetan sing luwih dhuwur sajrone wektu sing luwih cekak bledosan akeh sambungan sing dikarepake.

Bentenipun, a (true)DNS trowongan meh ora bisa meksa56kbps lan bisa cepet dibukak amarga aku ngira jumlah panjaluk DNS sing luwih curiga banjur panjaluk TCP. Kita kudu nemtokake manawa atrue Terowongan DNS encode (metu) data liwat subdomain lan decode (mlebu) data palsu sing ditampa kanthi takon data DNS, dene kadang-kadang terowongan DNS bisa dianggep minangka sambungan UDP mentah liwat port DNS, sing bisa uga sawetara kepungkur, server DNS diidini lan diterusake kanthi bener.

Kesimpulan

Aku ora yakin yen wis entuk target sarana wicaksana, amarga mbukak trowongan sing kaya ngono bisa nggawe sampeyan telpon cukup panas, lan mbuwang akeh batere, nanging yen dadi sambungan serep bisa ngamanake ... yen aku pancen repot nggawe cukup stabil :)

[1]biasane yen kertu SIM ora duwe data maneh kanggo browsing web, panjaluk web pangalihan menyang gateway njupuk (supaya sampeyan tuku data liyane)
[2]rencana data seluler bisa nyedhiyakake sambungan sing luwih apik sajrone wengi
[3]Nomer iki, sing sejajar karo jumlah inti umum, bisa uga ngakibatake sampeyan manawa kernel mbatesi koneksi, skenario koneksi mbukak trowongan mesthi ora umum, nanging tombol linux tuning ora nate menehi asil sing luwih apik ing pungkasane.

Tag Pos: