HamsterReserved 3922b17067 chore: deliver UDP packets from same connection in receiving order (#1540)
All UDP packets are queued into a single channel, and multiple
workers are launched to poll the channel in current design.

This introduces a problem where UDP packets from a single connection
are delivered to different workers, thus forwarded in a random order
if workers are on different CPU cores. Though UDP peers normally
have their own logic to handle out-of-order packets, this behavior will
inevitably cause significant variance in delay and harm connection quality.
Furthermore, this out-of-order behavior is noticeable even if the underlying
transport could provide guaranteed orderly delivery -  this is unacceptable.

This commit takes the idea of RSS in terms of NICs: it creates a distinct
queue for each worker, hashes incoming packets, and distribute the packet
to a worker by hash result. The tuple (SrcIP, SrcPort, DstIP, DstPort, Proto)
is used for hashing (Proto is always UDP so it's dropped from final
implementation), thus packets from the same connection can be sent to
the same worker, keeping the receiving order. Different connections can be
hashed to different workers to maintain performance.

Performance for single UDP connection is not affected, as there is already
a lock in natTable that prevents multiple packets being processed in different
workers, limiting single connection forwarding performance to 1 worker.
The only performance penalty is the hashing code, which should be neglectable
given the footprint of en/decryption work.

Co-authored-by: Hamster Tian <haotia@gmail.com>
2024-09-25 21:28:30 +08:00
2024-08-31 23:38:31 +08:00
2023-11-03 21:58:21 +08:00
2023-11-03 21:58:21 +08:00
2024-09-22 13:57:57 +08:00
2024-08-16 14:15:36 +08:00
2023-01-14 18:10:22 +08:00
2023-11-03 21:58:21 +08:00
2022-04-28 14:18:54 +08:00
2024-07-31 13:04:30 +08:00
2022-12-15 13:25:18 +08:00
2023-11-03 21:58:21 +08:00
2024-09-24 13:25:13 +08:00
2024-09-24 13:25:13 +08:00
2019-10-18 11:12:35 +08:00
2024-09-09 16:08:48 +08:00
2024-08-16 14:15:36 +08:00
2021-12-09 17:54:53 +08:00
2024-05-04 18:41:08 +08:00

Meta Kennel
Meta Kernel

Another Mihomo Kernel.

Features

  • Local HTTP/HTTPS/SOCKS server with authentication support
  • VMess, VLESS, Shadowsocks, Trojan, Snell, TUIC, Hysteria protocol support
  • Built-in DNS server that aims to minimize DNS pollution attack impact, supports DoH/DoT upstream and fake IP.
  • Rules based off domains, GEOIP, IPCIDR or Process to forward packets to different nodes
  • Remote groups allow users to implement powerful rules. Supports automatic fallback, load balancing or auto select node based off latency
  • Remote providers, allowing users to get node lists remotely instead of hard-coding in config
  • Netfilter TCP redirecting. Deploy Mihomo on your Internet gateway with iptables.
  • Comprehensive HTTP RESTful API controller

Dashboard

A web dashboard with first-class support for this project has been created; it can be checked out at metacubexd.

Configration example

Configuration example is located at /docs/config.yaml.

Docs

Documentation can be found in mihomo Docs.

For development

Requirements: Go 1.20 or newer

Build mihomo:

git clone https://github.com/MetaCubeX/mihomo.git
cd mihomo && go mod download
go build

Set go proxy if a connection to GitHub is not possible:

go env -w GOPROXY=https://goproxy.io,direct

Build with gvisor tun stack:

go build -tags with_gvisor

IPTABLES configuration

Work on Linux OS which supported iptables

# Enable the TPROXY listener
tproxy-port: 9898

iptables:
  enable: true # default is false
  inbound-interface: eth0 # detect the inbound interface, default is 'lo'

Debugging

Check wiki to get an instruction on using debug API.

Credits

License

This software is released under the GPL-3.0 license.

Description
A simple Python Pydantic model for Honkai: Star Rail parsed data from the Mihomo API.
Readme MIT 51 MiB
Languages
Python 100%