•  untoreh-light

TCSplitter

Isang lagusan upang paghiwalayin ang koneksyon sa TCP o UDP sa maraming koneksyon sa TCP

Layunin

Kailan mo nais na hatiin ang isang koneksyon sa TCP sa maraming mga? Kadalasan gumagamit ka ng a lagusan upang makamit ang eksaktong kabaligtaran . Ang aking kaso sa paggamit ay pag-iwas sa mga limitasyon ng bandwidth sa isang mobile network, kaya't isinagawa ang mga pagsubok sa isang sim card na wala nang natitirang data sa plano nito[1].

Paano ito gumagana

Ang lagusan ay nakasulat sa golang dahil ito ay sapat na mabilis, at karaniwang ginagamit para sa tooling sa network. Ang kliyente ay halos hindi magagamit dahil ang karamihan sa mga pagpipilian ay muling binago habang sinubukan ko ang iba't ibang mga pamamaraan.

Sa una ay may mga "fling" at "lassos", upang hatiin ang bilang ng mga koneksyon para sa papalabas (flinged) at papasok (lassoed), ngunit ito ay isang hindi kinakailangang abstraction dahil mas mahusay na i-tag ang mga packet sa kanilang patutunguhan, bagaman ang pangunahing hangarin ay upang mag-alok ng iba't ibang mga limitasyon sa rate para sa mga papalabas at papasok na koneksyon, kaya't ang isang mas mataas na antas ng paghihiwalay sa pagitan ng pataas / pababa ay tila praktikal.

Kailangang pasimulan ng kliyente ang lahat ng mga koneksyon dahil ipinapalagay namin na ang server ay hindi maaaring buksan ang mga papalabas na koneksyon. Kapag nakatanggap ang mga kliyente ng isang koneksyon mula sa isang application ng gumagamit, itinatakda nito ang kinakailangang pool ng mga koneksyon sa server, at kung anong data ang natatanggap nito, hinahati ito sa mga nakatuon na koneksyon, ayon sa isang tinukoy na limitasyon ng gumagamit.

Pagkatapos ay ipinadala ang mga packet sa server, na kung saan ay kailangang buuin muli ang mga ito sa tamang pagkakasunud-sunod, dahil ang iba't ibang mga koneksyon sa TCP ay maaaring tapusin ang stream ng data sa anumang oras (ang ipinadala na order ay hindi iginagalang, dahil sa pagruruta ), at pagkatapos ay ipinasa sa pagtanggap ng app.

Ang mga koneksyon ay sarado at ang mga bago ay bubuksan bilang na-configure na limitasyon ng data sa bawat koneksyon naabot, katulad sa kung paano mga shadowsockproxy ng data ng lagusan sa iba't ibang mga stream na may layunin na masking ang pag-uugali ng mga stream ng data, maliban sa ginagawa ng aming tunnel nang madalas hangga't maaari.

Bakit ito gumagana

Ang hangarin dito ay upang makontrol kung gaano karaming data ang dapat hawakan ng bawat koneksyon. Para sa aming mga layunin, ito ay hindi kailanman lampas ay karaniwang ay ang MTU laki ng bintana. Maaari mong isipin ang MTU bilang itaas na hangganan ng isang piraso ng data na pumasa sa buong network, at ito ang aming target dahil nais naming laktawan ang mga limitasyon ng rate ng bandwidth ng isang gated network. Upang limitahan kung magkano ang data na maaaring dumaan sa isang kliyente, kailangan mo bilangin ito, di ba Kung ang iyong lohika ay gumagana sa isang bagay tulad ng ado-while

Kung gayon kailangan mo kahit na tumanggap ng apacket . Hindi ako sigurado kung ito ang totoong nangyayari, o ang dahilan na gumana ang aking lagusan ay isa pa. Marahil posible na suriin kahit ang unang packet, ngunit mula sa isang pananaw sa disenyo, nangangahulugan ito na kailangan mong suriin bawat solong koneksyon, na kung saan ay gawing mahina ang system sa pag-atake ng DOS, at oo ang aking lagusan ay madaling magamit bilang isang mahusay na tool ng DOS / Stress, dahil maaari mong hatiin ang data sa napakaliit na mga packet (na nangangahulugang ang mga koneksyon sa TCP ay magkakaroon ng isang mataas na presyon ng recycle. ) at magkaroon ng isang pool ng mga koneksyon hangga't gusto mo.

Ang pagsubok sa iba`t ibang mga port ay ipinakita din na posible lamang itong matapos ang ilan port, at na ang hangganan ay patuloy na naiiba sa pagitan ng mga port, na may443 pagbibigay ng isa sa mga mas mataas na bintana, sa paligid20kb , hinuhulaan dahilTLS ang mga handshake ay nangangailangan ng mas maraming data, at ang mga rate-limit na ito ay magbabago batay sa oras ng araw[2].

Mga Resulta

Sinubukan kong burahin ang pag-coding sa pag-asa ng pagtaas ng throughput ng data. Sa pamamagitan ng paggamit ng isang erasure coding library at pag-enc / decoding ng mismong data, at sa pamamagitan din ng pag-overlay ng KCP protocol sa paglipas ng aking hating protocol. Ang pagsubok sa KCP ay maaaring isang paurong na diskarte, dahil nakikipagpalitan ito ng mas mahusay na latency para sa mas mababang throughput, ngunit ang aking paunang palagay ay ang aking bottleneck ay sa mga koneksyon ay bumagsak sa kalagitnaan ng paghahatid, na maaaring maging sanhi ng maraming mga nasirang packet, kaya maaaring nakamit ko ang isang mas mataas throughput na may pagwawasto ng error.

Ito ay naging isang rate-limit lamang sa kung gaano karaming mga koneksyon sa TCP ang maaaring ipadala ng isang client sa network, kaya isang proteksyon lamang sa DOS na wala akong magawa. Pagkatapos ng X halaga ng mga koneksyon anumangSYN pagtatangka ihinto ang pagtanggap ng kanilang nararapatACK , pinupunan ang backlog at kalaunan ay ginagawang tunnel stall. Ipinakita ang pagsubok at error na posible sa pagitan4-8[3] bukas ang mga koneksyon sa anumang naibigay na oras, at may isang MTU ng500-1000 bytes maaari mong panatilihin ang isang matatag na stream sa paligid ng hindi bababa sa128kbps , kung ang isang pare-pareho na stream ay hindi isang kinakailangan, maaari kang makamit ang mas mataas na bilis sa isang mas maikling panahon sa pamamagitan ng pumutok maraming mga koneksyon ayon sa demand.

Sa kaibahan, isang (totoo)DNS bahagya maaaring itulak56kbps at maaaring mabilis na ma-throttled dahil sa palagay ko ang isang mataas na bilang ng mga kahilingan sa DNS ay mukhang mas kahina-hinala pagkatapos ng mga kahilingan sa TCP. Kailangan nating tukuyin iyon atrue Ang DNS tunnel encode (papalabas) na data sa mga bogus subdomain at decode (papasok) na data na natanggap sa pamamagitan ng pag-query ng mga tala ng DNS, samantalang minsan ang isang DNS tunnel ay maiisip na isang raw na koneksyon sa UDP sa DNS port, na marahil ay minsan, mga DNS server pinapayagan at naipasa nang tama.

Konklusyon

Hindi ako sigurado naabot ko ang aking layunin kagamitan matalino, dahil ang pagpapatakbo ng ganoong uri ng lagusan ay maaaring gawing mainit ang iyong telepono, at mag-aaksaya ng maraming baterya, ngunit ang pagkakaroon nito bilang isang backup na koneksyon ay maaaring maging panatag.

[1]kadalasan kapag ang isang sim card ay wala nang data upang mag-browse sa web, humihiling ang web ng pag-redirect sa capture gateway (upang sabihin sa iyo na bumili ng higit pang data)
[2]ang mga plano ng mobile data ay maaaring magbigay ng isang mas mahusay na koneksyon sa mga oras ng gabi
[3]Ang numerong ito, na medyo nakahanay sa karaniwang mga bilang ng pangunahing, ay maaaring magbuod sa iyo upang maghinala na ang kernel ay naglilimita sa mga koneksyon kahit papaano, ang senaryo ng binuksan na mga koneksyon ng aming lagusan ay tiyak na hindi pangkaraniwang, ngunit ang pag-tune ng mga linux knobs ay hindi kailanman nagbigay ng mas mahusay na mga resulta sa aking wakas.

Mag-post ng Mga Tag: