kcptube
Release 20241201
คลิกที่นี่เพื่อดูเวอร์ชันภาษาอังกฤษ
ใครก็ตามที่เคยใช้บรอดแบนด์ภายในบ้านจากผู้ให้บริการหลักสามรายและต้องการการเชื่อมต่อโครงข่ายบรอดแบนด์ภายในบ้านมักจะพบว่า UDP ถูกจำกัดความเร็วอยู่เสมอ เพื่อหลีกเลี่ยง QoS ของโอเปอเรเตอร์หลักสามรายสำหรับ UDP ฉันจึงสร้างเครื่องมืออื่นที่เรียกว่า UDP Hop หลักการคือสร้างการเชื่อมต่อใหม่เป็นประจำ (เปลี่ยนหมายเลขพอร์ตและเชื่อมต่อกับที่อยู่ใหม่)
อย่างไรก็ตาม UDP Hop รองรับเฉพาะการส่งต่อการรับส่งข้อมูล UDP เท่านั้น เพื่อให้สามารถใช้ UDP เพื่อส่งต่อการรับส่งข้อมูล TCP จึงมี KCP Tube การส่งสัญญาณซ้ำที่เชื่อถือได้ของ KCP ถูกนำมาใช้เพื่อให้แน่ใจว่าแพ็กเก็ต TCP ที่ส่งต่อจะไม่สูญหาย
อีกเหตุผลหนึ่งในการสร้าง KCP Tube ก็คือเครื่องมือการส่งต่อ KCP อื่นๆ สามารถส่งต่อการรับส่งข้อมูล TCP เท่านั้น แต่ฉันจำเป็นต้องใช้ KCP เพื่อส่งต่อการรับส่งข้อมูล UDP เพื่อความสะดวกในการเล่นเกมเป็นหลัก
แน่นอนว่า udphop และ kcptube เกิดขึ้นในเวลาเดียวกัน ดังนั้นเพื่อความสะดวก ขั้นแรกเราจึงตั้งค่า KCP Tube และตั้งค่าเฟรมเวิร์ก จากนั้นจึงตัดออกเป็น UDP Hop ตาม KCP Tube จากนั้นย้อนกลับรวมรหัสแพตช์ UDP Hop กลับไปที่ KCP Tube
เพื่ออำนวยความสะดวกแก่ผู้ใช้บรอดแบนด์ Full Cone NAT ในบ้าน KCP Tube สามารถใช้ STUN เพื่อเจาะรูเมื่อทำงานในโหมดเซิร์ฟเวอร์พื้นฐาน และรองรับทั้ง IPv4 และ IPv6
เช่นเดียวกับวัตถุประสงค์ของ KCP เป้าหมายหลักของ KCP Tube คือการลดเวลาแฝง แทนที่จะสนับสนุนการส่งข้อมูลปริมาณข้อมูลขนาดใหญ่มาก มันสามารถส่งทราฟฟิกขนาดใหญ่มากได้หรือไม่? ได้ แต่ผลกระทบอาจไม่ดีเท่ากับเครื่องมือส่งต่อ TCP-KCP ที่มีอยู่
ปัจจุบันรองรับ 3 โหมด:
โปรดทราบ ว่าเวลาของไคลเอนต์และเวลาของเซิร์ฟเวอร์จะต้องซิงโครไนซ์ และความต่างของเวลาต้องไม่เกิน 255 วินาที
กรุณาไปที่หน้าวิกิหรือไปที่หน้าเอกสารประกอบ
หากคุณต้องการตัวสร้างโปรไฟล์ ไปที่นี่: KCPTube Generator
kcptube config.conf
ตัวอย่างโหมดไคลเอนต์:
mode=client
kcp=regular3
inbound_bandwidth=500M
outbound_bandwidth=50M
listen_port=59000
destination_port=3000
destination_address=123.45.67.89
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
ตัวอย่างโหมดเซิร์ฟเวอร์:
mode=server
kcp=regular3
inbound_bandwidth=1G
outbound_bandwidth=1G
listen_port=3000
destination_port=59000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
stun_server=stun.qq.com
log_path=./
หมายเหตุ: เมื่อเชื่อมต่อเป็นครั้งแรก เซิร์ฟเวอร์จะแจ้งให้ไคลเอ็นต์ทราบถึงช่วงพอร์ต ดังนั้น listen_port ในโหมดไคลเอ็นต์ไม่จำเป็นต้องเท่ากับ destination_port ในโหมดเซิร์ฟเวอร์ แต่พอร์ตทั้งสองด้านอาจไม่สอดคล้องกัน ช่วงหมายเลขพอร์ตที่เขียนโดยไคลเอ็นต์ไม่สามารถเกินขอบเขตของเซิร์ฟเวอร์เพื่อป้องกันไม่ให้ไคลเอ็นต์เลือกพอร์ตที่ไม่ถูกต้องและไม่สามารถเชื่อมต่อได้
หากคุณต้องการระบุการ์ดเครือข่ายการฟัง ให้ระบุที่อยู่ IP ของการ์ดเครือข่ายและเพิ่มหนึ่งบรรทัด
listen_on=192.168.1.1
หากคุณต้องการฟังหลายพอร์ตและการ์ดเครือข่ายหลายใบ ให้แยกไฟล์การกำหนดค่าหลายไฟล์
kcptube config1.conf config2.conf
หากคุณต้องการทดสอบว่าการเชื่อมต่อราบรื่นหรือไม่ก่อนทำการเชื่อมต่อ คุณสามารถเพิ่มตัวเลือก --try ได้
kcptube --try config1.conf
หรือ
kcptube config1.conf --try
ใช้ตัวเลือก --check-config เพื่อตรวจสอบว่าไฟล์การกำหนดค่าถูกต้อง:
kcptube --check-config config1.conf
หรือ
kcptube config1.conf --check-config
ตัวอย่างโหมดไคลเอนต์:
mode=client
kcp=regular3
inbound_bandwidth=500M
outbound_bandwidth=50M
listen_port=6000
destination_port=3000-4000
destination_address=123.45.67.89
dport_refresh=600
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
ตัวอย่างโหมดเซิร์ฟเวอร์:
mode=server
kcp=regular3
inbound_bandwidth=1G
outbound_bandwidth=1G
listen_port=3000-4000
destination_port=6000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
ตัวอย่างโหมดไคลเอนต์:
mode=client
kcp=manual
kcp_mtu=1400
kcp_sndwnd=512
kcp_rcvwnd=2048
kcp_nodelay=1
kcp_interval=10
kcp_resend=2
kcp_nc=true
udp_timeout=300
listen_port=6000
destination_port=3000-4000
destination_address=123.45.67.89
dport_refresh=600
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
ตัวอย่างโหมดเซิร์ฟเวอร์:
mode=server
kcp=manual
kcp_mtu=1400
kcp_sndwnd=512
kcp_rcvwnd=2048
kcp_nodelay=1
kcp_interval=10
kcp_resend=2
kcp_nc=true
udp_timeout=300
listen_port=3000-4000
destination_port=6000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
| ชื่อ | ค่าที่กำหนดได้ | ที่จำเป็น | หมายเหตุ |
|---|---|---|---|
| โหมด | ลูกค้า เซิร์ฟเวอร์ รีเลย์ | ใช่ | โหนดรีเลย์เซิร์ฟเวอร์ไคลเอ็นต์ |
| Listen_on | ชื่อโดเมนหรือที่อยู่ IP | เลขที่ | สามารถกรอกได้เฉพาะชื่อโดเมนหรือที่อยู่ IP เท่านั้น โปรดคั่นที่อยู่หลายแห่งด้วยเครื่องหมายจุลภาค |
| Listen_port | 1-65535 | ใช่ | เมื่อทำงานเป็นเซิร์ฟเวอร์ คุณสามารถระบุช่วงพอร์ตได้ |
| ปลายทาง_พอร์ต | 1-65535 | ใช่ | สามารถระบุช่วงพอร์ตได้เมื่อทำงานเป็นไคลเอนต์ โปรดคั่นที่อยู่หลายแห่งด้วยเครื่องหมายจุลภาค |
| ปลายทาง_ที่อยู่ | ที่อยู่ IP ชื่อโดเมน | ใช่ | ไม่จำเป็นต้องมีวงเล็บเหลี่ยมเมื่อกรอกที่อยู่ IPv6 |
| dport_refresh | 0 - 32767 | เลขที่ | มีหน่วยเป็น "วินาที" หากเว้นว่างไว้ ระบบจะใช้ค่าเริ่มต้น 60 วินาที 1 ถึง 20 คำนวณเป็น 20 วินาที และมากกว่า 32767 คำนวณเป็น 32767 วินาที ตั้งค่าเป็น 0 เพื่อปิดใช้งาน |
| การเข้ารหัส_อัลกอริทึม | AES-GCM AES-OCB ช่า20 เอ็กซ์ชาชา20 ไม่มี | เลขที่ | AES-256-GCM-AEAD AES-256-OCB-AEAD ชาช่า20-โพลี1305 XChaCha20-Poly1305 ไม่มีการเข้ารหัส |
| การเข้ารหัส_รหัสผ่าน | ตัวละครใดก็ได้ | ขึ้นอยู่กับสถานการณ์ | จำเป็นเมื่อตั้งค่าการเข้ารหัส_อัลกอริทึมและไม่ใช่ไม่มีเลย |
| udp_timeout | 0 - 65535 | เลขที่ | มีหน่วยเป็น "วินาที" ค่าเริ่มต้นคือ 180 วินาที หากตั้งค่าเป็น 0 ตัวเลือกนี้จะแสดงถึงการตั้งค่าการหมดเวลาระหว่างแอปพลิเคชัน UDP ↔ kcptube |
| ให้_มีชีวิตอยู่ | 0 - 65535 | เลขที่ | มีหน่วยเป็น "วินาที" ค่าเริ่มต้นคือ 0 ซึ่งเทียบเท่ากับการปิดใช้งาน Keep Alive ตัวเลือกนี้อ้างถึง Keep Alive ระหว่างปลาย KCP สองอัน สามารถเปิดใช้งานฝ่ายเดียวเพื่อตรวจสอบว่าช่องหยุดตอบสนองหรือไม่ หากไม่มีการตอบสนองหลังจากผ่านไป 30 วินาที ช่องจะถูกปิด |
| mux_tunnels | 0 - 65535 | เลขที่ | ค่าเริ่มต้นคือ 0 ซึ่งเทียบเท่ากับการไม่ใช้ช่องสัญญาณมัลติเพล็กซ์ ตัวเลือกนี้อ้างอิงถึงจำนวนช่องสัญญาณมัลติเพล็กซ์ระหว่างปลาย KCP ทั้งสองตัวเลือกนี้เปิดใช้งานเฉพาะในฝั่งไคลเอ็นต์เท่านั้น |
| stun_server | ที่อยู่เซิร์ฟเวอร์ STUN | เลขที่ | ไม่สามารถใช้งานได้เมื่อ Listen_port อยู่ในโหมดช่วงพอร์ต |
| log_path | ไดเร็กทอรีสำหรับจัดเก็บ Log | เลขที่ | ไม่สามารถชี้ไปที่ไฟล์ได้ |
| ส.ค | uint8:uint8 | เลขที่ | รูปแบบคือ fec=D:R เช่น สามารถกรอก fec=20:3 ได้หมายเหตุ: ค่ารวมสูงสุดของ D + R คือ 255 และต้องไม่เกินจำนวนนี้ ค่า 0 ที่ด้านใดด้านหนึ่งของเครื่องหมายทวิภาคแสดงว่าไม่มีการใช้ตัวเลือก การตั้งค่าจะต้องเหมือนกันทั้งสองด้าน สำหรับรายละเอียด โปรดดูคู่มือการใช้งาน FEC |
| mtu | จำนวนเต็มบวก | เลขที่ | ค่า MTU ของเครือข่ายปัจจุบัน ใช้ในการคำนวณ kcp_mtu โดยอัตโนมัติ |
| kcp_mtu | จำนวนเต็มบวก | เลขที่ | ค่าเริ่มต้นคือ 1440 ค่าที่กำหนดโดยการเรียก ikcp_setmtu() คือความยาวของเนื้อหาข้อมูลในแพ็กเก็ต UDP |
| เคซีพี | คู่มือ เร็ว1-6 ปกติ1-5 | ใช่ | ตั้งค่าความเร็วปกติที่รวดเร็วด้วยตนเอง (เลขท้ายยิ่งเลขน้อยความเร็วยิ่งเร็ว) |
| kcp_sndwnd | จำนวนเต็มบวก | เลขที่ | ค่าเริ่มต้นจะแสดงอยู่ในตารางด้านล่างและสามารถแทนที่ทีละรายการได้ |
| kcp_rcvwnd | จำนวนเต็มบวก | เลขที่ | ค่าเริ่มต้นจะแสดงอยู่ในตารางด้านล่างและสามารถแทนที่ทีละรายการได้ |
| kcp_nodelay | จำนวนเต็มบวก | ขึ้นอยู่กับสถานการณ์ | จำเป็นเมื่อ kcp=manual ค่าเริ่มต้นจะแสดงในตารางด้านล่าง |
| kcp_ช่วง | จำนวนเต็มบวก | ขึ้นอยู่กับสถานการณ์ | จำเป็นเมื่อ kcp=manual ค่าเริ่มต้นจะแสดงในตารางด้านล่าง |
| kcp_ส่งอีกครั้ง | จำนวนเต็มบวก | ขึ้นอยู่กับสถานการณ์ | จำเป็นเมื่อ kcp=manual ค่าเริ่มต้นจะแสดงในตารางด้านล่าง |
| kcp_nc | ใช่ จริง 1 เลขที่ เท็จ 0 | ขึ้นอยู่กับสถานการณ์ | จำเป็นเมื่อ kcp=manual ค่าเริ่มต้นจะแสดงในตารางด้านล่าง |
| ขาออก_แบนด์วิธ | จำนวนเต็มบวก | เลขที่ | แบนด์วิดท์ขาออก ใช้เพื่ออัพเดตค่าของ kcp_sndwnd แบบไดนามิกในระหว่างกระบวนการสื่อสาร |
| ขาเข้า_แบนด์วิธ | จำนวนเต็มบวก | เลขที่ | แบนด์วิดท์ขาเข้า ใช้เพื่ออัพเดตค่าของ kcp_rcvwnd แบบไดนามิกในระหว่างกระบวนการสื่อสาร |
| ipv4_only | ใช่ จริง 1 เลขที่ เท็จ 0 | เลขที่ | หาก IPv6 ถูกปิดใช้งานบนระบบ ต้องเปิดใช้งานตัวเลือกนี้และตั้งค่าเป็นใช่หรือจริงหรือ 1 |
| ipv6_only | ใช่ จริง 1 เลขที่ เท็จ 0 | เลขที่ | ละเว้นที่อยู่ IPv4 |
| ระเบิด | ใช่ จริง 1 เลขที่ เท็จ 0 | เลขที่ | พยายามละเว้นการตั้งค่าการควบคุมโฟลว์ KCP และส่งต่อแพ็กเก็ตโดยเร็วที่สุด อาจทำให้เกิดภาระมากเกินไป |
| [ผู้ฟัง] | ไม่มี | ใช่ (โหมดรีเลย์เท่านั้น) | ป้ายกำกับของโหมดรีเลย์ ใช้เพื่อระบุ KCP ในโหมดการฟัง การตั้งค่าป้ายกำกับนี้บ่งบอกถึงข้อมูลการโต้ตอบกับไคลเอนต์ |
| [ผู้ส่ง] | ไม่มี | ใช่ (โหมดรีเลย์เท่านั้น) | ป้ายกำกับของโหมดรีเลย์ ใช้เพื่อระบุ KCP ของโหมดการถ่ายโอน การตั้งค่าป้ายกำกับนี้บ่งชี้ถึงข้อมูลการโต้ตอบกับเซิร์ฟเวอร์ |
| [กำหนดเอง_อินพุต] | ไม่มี | เลขที่ | ป้ายกำกับของโหมดการแมปแบบกำหนดเอง สำหรับการใช้งาน โปรดดูวิธีใช้การแมปแบบกำหนดเอง |
| [กำหนดเอง_อินพุต_tcp] | ไม่มี | เลขที่ | ป้ายกำกับของโหมดการแมปแบบกำหนดเอง สำหรับการใช้งาน โปรดดูวิธีใช้การแมปแบบกำหนดเอง |
| [กำหนดเอง_อินพุต_udp] | ไม่มี | เลขที่ | ป้ายกำกับของโหมดการแมปแบบกำหนดเอง สำหรับการใช้งาน โปรดดูวิธีใช้การแมปแบบกำหนดเอง |
ในนั้น encryption_algorithm และ encryption_password จะต้องสอดคล้องกันที่ปลายทั้งสองด้านของการสื่อสาร
| ชื่อ | ค่าที่กำหนดได้ | ที่จำเป็น | หมายเหตุ |
|---|---|---|---|
| fib_ingress | 0 - 65535 | เลขที่ | FIB ใช้โดยการเชื่อมต่อขาเข้า |
| fib_egress | 0 - 65535 | เลขที่ | FIB ใช้สำหรับการเชื่อมต่อขาออก |
ส่วนต่อท้ายที่ใช้ได้: K/M/G
ส่วนต่อท้ายคำนึงถึงตัวพิมพ์เล็กและใหญ่ ตัวพิมพ์ใหญ่คำนวณเป็นไบนารี่ (1024) และตัวพิมพ์เล็กคำนวณเป็นทศนิยม (1,000)
กรอก 1,000 เพื่อระบุว่าแบนด์วิธคือ 1,000 bps
กรอก 100k ระบุว่าแบนด์วิธคือ 100 kbps (100,000 bps)
กรอก 100K ระบุว่าแบนด์วิธเป็น 100 Kbps (102400 bps)
กรอก 100M ระบุว่าแบนด์วิธคือ 100 Mbps (102400 Kbps)
กรอก 1G ระบุว่าแบนด์วิธเป็น 1 Gbps (1024 Mbps)
โปรดทราบว่ามันคือ bps (บิตต่อวินาที) ไม่ใช่ Bps (ไบต์ต่อวินาที)
ควรจำไว้ว่าค่าแบนด์วิดท์ที่กรอกไม่ควรเกินแบนด์วิดท์จริงเพื่อหลีกเลี่ยงความแออัดในหน้าต่างการส่ง
หมายเหตุสำคัญ :
KCPTube จะคำนวณและตั้งค่าขนาดหน้าต่างการส่ง KCP ประมาณ 5 วินาทีหลังจากสร้างลิงก์ KCP ขึ้นอยู่กับค่าความล่าช้าของแพ็กเก็ตการจับมือและค่าของ outbound_bandwidth และ inbound_bandwidth ภายในระยะเวลาหนึ่งหลังจากการตั้งค่าเสร็จสิ้น มีโอกาสสูงที่การรับส่งข้อมูลจะผันผวนอย่างมาก หรือแม้แต่การรับส่งข้อมูลอาจลดลงเหลือ 0 ทันที และจะใช้เวลาหลายวินาทีในการกู้คืน
| โหมดด่วน | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_ช่วง | kcp_ส่งอีกครั้ง | kcp_nc |
|---|---|---|---|---|---|---|
| รวดเร็ว1 | 2048 | 2048 | 1 | 1 | 2 | 1 |
| เร็ว2 | 2048 | 2048 | 2 | 1 | 2 | 1 |
| รวดเร็ว3 | 2048 | 2048 | 1 | 1 | 3 | 1 |
| รวดเร็ว4 | 2048 | 2048 | 2 | 1 | 3 | 1 |
| รวดเร็ว5 | 2048 | 2048 | 1 | 1 | 4 | 1 |
| รวดเร็ว6 | 2048 | 2048 | 2 | 1 | 4 | 1 |
| โหมดความเร็วปกติ | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_ช่วง | kcp_ส่งอีกครั้ง | kcp_nc |
|---|---|---|---|---|---|---|
| ปกติ1 | 1,024 | 1,024 | 1 | 1 | 5 | 1 |
| ปกติ2 | 1,024 | 1,024 | 2 | 1 | 5 | 1 |
| ปกติ3 | 1,024 | 1,024 | 0 | 1 | 2 | 1 |
| ปกติ4 | 1,024 | 1,024 | 0 | 15 | 2 | 1 |
| ปกติ5 | 1,024 | 1,024 | 0 | 30 | 2 | 1 |
ในหมู่พวกเขา ยิ่งอัตราการสูญเสียแพ็กเก็ตสูง (สูงกว่า 10%) ยิ่งมีข้อได้เปรียบที่ kcp_nodelay=1 มีมากกว่า kcp_nodelay=2 เมื่ออัตราการสูญเสียแพ็กเก็ตไม่สูงมากนัก kcp_nodelay=2 จะทำให้การหน่วงเวลา jitter ราบรื่นขึ้น
สำหรับสภาพแวดล้อมที่สูญเสียแพ็กเก็ตต่ำ แต่ละโหมดจะเหมาะสำหรับการใช้งาน ข้อแตกต่างเพียงอย่างเดียวอยู่ที่ว่ามีการใช้ทราฟฟิกที่สิ้นเปลืองมากหรือน้อย และขีดจำกัดบนของความเร็วสูงสุดจะแตกต่างกัน ในหมู่พวกเขา Regular3 ไม่เสียทราฟฟิกมากนัก
ขอแนะนำให้เปิดใช้งานการตั้งค่า blast=1 ในเวลาเดียวกัน
สำหรับสภาพแวดล้อมที่มีการสูญเสียแพ็กเก็ตสูง ให้พิจารณาการซ้อนทับการตั้งค่า FEC สำหรับรายละเอียด โปรดดูคู่มือการใช้งาน FEC
สำหรับรายละเอียดเพิ่มเติม ดูรายการพารามิเตอร์
หลังจากได้รับที่อยู่ IP และพอร์ตที่เจาะรูเป็นครั้งแรก และหลังจากเปลี่ยนที่อยู่ IP และพอร์ตที่เจาะรูแล้ว ไฟล์ ip_address.txt จะถูกสร้างขึ้นในไดเร็กทอรี Log (เขียนทับหากมีอยู่) และ IP ที่อยู่และพอร์ตจะถูกเขียนลงไป
ที่อยู่การเจาะรูที่ได้รับจะแสดงในคอนโซลพร้อมกัน
log_path= ต้องชี้ไปที่ไดเร็กทอรี ไม่ใช่ตัวไฟล์เอง
หากคุณไม่จำเป็นต้องเขียนลงในไฟล์บันทึก ให้ลบบรรทัด log_path
เซิร์ฟเวอร์ STUN ทั่วไปที่พบจาก NatTypeTeste:
พบเซิร์ฟเวอร์ STUN จาก Natter:
เซิร์ฟเวอร์ STUN อื่นๆ: public-stun-list.txt
เพื่อความสะดวกในการใช้งาน มีการจัดเตรียมไฟล์ปฏิบัติการแบบไบนารีสำหรับหลายแพลตฟอร์ม:
ไบนารีที่คอมไพล์แล้วทั้งหมดจะถูกคอมไพล์แบบคงที่ โดยทั่วไปเวอร์ชันของ Linux จะถูกคอมไพล์แบบคงที่ ยกเว้น libc ดังนั้นจึงมีการเตรียมสองเวอร์ชัน หนึ่งเวอร์ชันสำหรับ glibc (2.31) และอีกเวอร์ชันสำหรับ musl
สำหรับสภาพแวดล้อม Linux อิมเมจ Docker ก็มีให้เช่นกัน (ปัจจุบันคือ x64 เท่านั้น) ดาวน์โหลด kcptube_docker_image.zip และขยายขนาด จากนั้นใช้ docker load -i kcptube_docker.tar เพื่อนำเข้า
หลังจากนำเข้าแล้ว วิธีการใช้งานคือ:
docker run -v /path/to/config_file.conf:/config_file.conf kcptube config_file.conf
ตัวอย่างเช่น:
docker run -v /home/someone/config1.conf:/config1.conf kcptube config1.conf
ผู้ใช้ FreeBSD สามารถคัดลอกไฟล์ไบนารีที่ดาวน์โหลดไปยัง /usr/local/bin/ จากนั้นเรียกใช้คำสั่ง
chmod +x /usr/local/bin/kcptube
ไฟล์บริการที่เกี่ยวข้องได้ถูกจัดเตรียมไว้ในไดเร็กทอรี service ของโปรเจ็กต์นี้
/usr/local/etc/rc.d/chmod +x /usr/local/etc/rc.d/kcptube/usr/local/etc/kcptube/config.conf/usr/local/etc/kcptube/config.confkcptube_enable="YES" ไปที่ /etc/rc.conf สุดท้ายให้รัน service kcptube start เพื่อเริ่มบริการ
คอมไพเลอร์ต้องรองรับ C++20
ไลบรารี่ที่ต้องพึ่งพา:
โปรดใช้ vcpkg เพื่อติดตั้งแพ็คเกจการพึ่งพา asio และ botan ล่วงหน้า คำสั่งมีดังนี้:
vcpkg install asio:x64-windows asio:x64-windows-static
vcpkg install botan:x64-windows botan:x64-windows-static
(หากคุณต้องการ ARM หรือเวอร์ชัน 32 บิต x86 โปรดปรับตัวเลือกด้วยตนเอง)
จากนั้นใช้ Visual Studio เพื่อเปิด slnkcptube.sln และคอมไพล์ด้วยตนเอง
ในทำนองเดียวกัน โปรดติดตั้งการขึ้นต่อกัน asio และ botan3 ก่อน นอกจากนี้ จำเป็นต้องมี cmake คุณสามารถติดตั้งด้วย pkg ของระบบเองได้:
pkg install asio botan3 cmake
จากนั้นสร้างในไดเร็กทอรี build
mkdir build
cd build
cmake ..
make
ขั้นตอนจะคล้ายกับ FreeBSD สำหรับ NetBSD โปรดใช้ pkgin เพื่อติดตั้งการอ้างอิงและ cmake:
pkgin install asio
pkgin install cmake
OpenBSD โปรดใช้ pkg_add เพื่อติดตั้งการอ้างอิงสองรายการข้างต้น DragonflyBSD โปรดใช้ pkg การใช้งานเหมือนกับ FreeBSD
เนื่องจาก botan-3 ไม่ได้รวมอยู่ในระบบ BSD เหล่านี้ คุณต้องคอมไพล์ botan-3 ด้วยตัวเอง
สำหรับขั้นตอนการสร้างที่เหลือ โปรดดู FreeBSD ด้านบน
โปรดทราบว่าเนื่องจาก BSD เหล่านี้มาพร้อมกับเวอร์ชันคอมไพเลอร์ที่ต่ำกว่า โปรดติดตั้ง GCC เวอร์ชันที่สูงกว่าไว้ล่วงหน้า
ขั้นตอนจะคล้ายกับ FreeBSD โปรดใช้ตัวจัดการแพ็คเกจที่มาพร้อมกับการแจกจ่ายเพื่อติดตั้ง asio, botan3 และ cmake
apk add asio botan3-libs cmake
จากนั้นสร้างในไดเร็กทอรี build
mkdir build
cd build
cmake ..
make
มีสองวิธี
แบบฝึกหัดที่ 1
คอมไพล์ตามกระบวนการปกติ ลบไฟล์ไบนารี kcptube ที่เพิ่งสร้างขึ้น และรันคำสั่ง
make VERBOSE=1
จากนั้นแยกคำสั่งลิงก์ C++ สุดท้ายออกจากเนื้อหาเอาต์พุต และเปลี่ยน -lbotan-3 ที่อยู่ตรงกลางเป็น พาธเต็ม ของ libbotan-3.a เช่น /usr/lib/x86_64-linux-gnu/libbotan-3.a .
แบบฝึกหัดที่ 2
เปิด src/CMakeLists.txt และเปลี่ยน target_link_libraries(${PROJECT_NAME} PRIVATE botan-3) เป็น target_link_libraries(${PROJECT_NAME} PRIVATE botan-3 -static)
จากนั้นก็คอมไพล์ตามปกติ โปรดทราบว่าหากระบบใช้ glibc ระบบจะคอมไพล์แบบคงที่พร้อมกับ glibc และคำเตือนเกี่ยวกับ getaddrinfo จะปรากฏขึ้น
ฉันไม่มีคอมพิวเตอร์ Apple ดังนั้นโปรดแก้ไขขั้นตอนทั้งหมดด้วยตัวเอง
การเพิ่มแคชการรับสามารถปรับปรุงประสิทธิภาพการส่งผ่าน UDP ได้
คุณสามารถใช้คำสั่ง sysctl kern.ipc.maxsockbuf เพื่อดูขนาดแคช หากจำเป็นต้องปรับเปลี่ยน ให้รันคำสั่ง (เปลี่ยนตัวเลขเป็นค่าที่ต้องการ):
sysctl -w kern.ipc.maxsockbuf=33554434
หรือเขียนใน /etc/sysctl.conf
kern.ipc.maxsockbuf=33554434
คุณสามารถใช้คำสั่ง sysctl net.inet.udp.recvspace เพื่อตรวจสอบขนาดบัฟเฟอร์การรับ หากจำเป็นต้องปรับเปลี่ยน ให้รันคำสั่ง (เปลี่ยนตัวเลขเป็นค่าที่ต้องการ):
sysctl -w net.inet.udp.recvspace=33554434
หรือเขียนใน /etc/sysctl.conf
net.inet.udp.recvspace=33554434
หากจำเป็น คุณสามารถปรับค่าของ net.inet.udp.sendspace ได้พร้อมกัน นี่คือการตั้งค่าการส่งแคช
สำหรับแคชที่ได้รับ คุณสามารถใช้คำสั่ง sysctl net.core.rmem_max และ sysctl net.core.rmem_default เพื่อดูขนาดแคชที่ได้รับ
หากจำเป็นต้องปรับเปลี่ยน ให้รันคำสั่ง (เปลี่ยนตัวเลขเป็นค่าที่ต้องการ):
sysctl -w net.core.rmem_max=33554434
sysctl -w net.core.rmem_default=33554434
หรือเขียนใน /etc/sysctl.conf
net.core.rmem_max=33554434
net.core.rmem_default=33554434
หากจำเป็นคุณสามารถปรับค่าของ net.core.wmem_max และ net.core.wmem_default พร้อมกันได้ นี่คือการตั้งค่าการส่งแคช
เนื่องจาก kcptube ใช้ IPv6 single stack ภายใน + เปิดที่อยู่ที่แมป IPv4 (IPv4 ที่แมป IPv6) เพื่อใช้ทั้งเครือข่าย IPv4 และ IPv6 โปรดตรวจสอบให้แน่ใจว่าค่าของตัวเลือก v6only เป็น 0
ภายใต้สถานการณ์ปกติ ไม่จำเป็นต้องตั้งค่าเพิ่มเติม FreeBSD, Linux และ Windows ล้วนอนุญาตให้แมปที่อยู่ IPv4 กับ IPv6 ตามค่าเริ่มต้น
หากระบบไม่รองรับ IPv6 หรือ IPv6 ถูกปิดใช้งาน โปรดตั้งค่า ipv4_only=true ในไฟล์การกำหนดค่า เพื่อให้ kcptube กลับไปใช้โหมด IPv4 single-stack
ใช้คำสั่ง
sysctl -w net.inet6.ip6.v6only=0
หลังจากตั้งค่าแล้ว โหมดสแต็กเดี่ยว + ที่อยู่ที่แมปสามารถฟังสแต็กคู่ได้
อย่างไรก็ตาม เนื่องจากไม่ทราบสาเหตุ ที่อยู่ที่แมป IPv4 อาจไม่สามารถเชื่อมต่อได้
เนื่องจาก OpenBSD บล็อกที่อยู่การแมป IPv4 อย่างสมบูรณ์ หากคุณใช้สแต็กคู่บนแพลตฟอร์ม OpenBSD คุณจะต้องบันทึกไฟล์การกำหนดค่าสองไฟล์ โดยหนึ่งในนั้นเปิดใช้งาน ipv4_only=1 จากนั้นโหลดไฟล์การกำหนดค่าทั้งสองไฟล์พร้อมกันเมื่อใช้ kcptube
ในกรณีส่วนใหญ่ พรอมต์นี้จะพบเฉพาะบนฝั่งเซิร์ฟเวอร์ ไม่ใช่ฝั่งไคลเอ็นต์
หากพบสิ่งนี้บนไคลเอนต์จริง ๆ โปรดตรวจสอบว่าค่าของ mux_tunnels สูงเกินไปหรือไม่ (โปรดอ้างอิงถึงย่อหน้า "Multiplexing (mux_tunnels=N)" ในระหว่างทาง)
ภายใต้สถานการณ์ปกติ ระบบ BSD ส่วนใหญ่จะไม่พบสิ่งเหล่านี้ มีเพียง GhostBSD ที่จะอัปเดตในช่วงครึ่งหลังของปี 2023 เท่านั้นที่จะพบกับปรากฏการณ์นี้
นี่เป็นเพราะ GhostBSD เพิ่มบรรทัดนี้ใน /etc/sysctl.conf :
kern.maxfiles=100000
บรรทัดนี้ลดขีดจำกัดบนให้ต่ำกว่าค่าที่สอดคล้องกันใน vanilla FreeBSD มาก
วิธีแก้ไขก็ง่าย เพียงลบบรรทัดนี้ออก คุณยังสามารถแสดงความคิดเห็นได้
คุณยังสามารถใช้คำสั่ง sysctl kern.maxfiles=300000 เพื่อแก้ไขค่าขีดจำกัดบนชั่วคราวได้
เนื่องจากจำนวนไฟล์ที่เปิดในระบบ Linux ถูกจำกัดไว้ที่ 1,024 ไฟล์ จึงมักประสบปัญหานี้
วิธีแก้ปัญหาชั่วคราว:
ulimit -n เพื่อดูค่าเอาต์พุตulimit -n 300000 วิธีแก้ปัญหาถาวร:
แก้ไข /etc/security/limits.conf และเพิ่มที่ส่วนท้าย
* hard nofile 300000
* soft nofile 300000
root hard nofile 300000
root soft nofile 300000
เนื่องจากข้อมูล TCP จำเป็นต้องได้รับการส่งข้อมูล จึงไม่สามารถละเลยการตรวจสอบข้อมูลได้ เช่นเดียวกับ TCP เอง
ไม่ว่าจะเข้ารหัสหรือไม่ก็ตาม kcptube จะลด MTU ลง 2 ไบต์และผนวกข้อมูล 2 ไบต์
หากมีการใช้ตัวเลือกการเข้ารหัส ข้อมูล 2 ไบต์ที่ต่อท้ายจะเป็น IV ที่สร้างขึ้นชั่วคราว
หากคุณเลือกที่จะไม่ใช้ฟังก์ชันการเข้ารหัส ข้อมูล 2 ไบต์ที่ต่อท้ายจะเป็นโค้ดตรวจสอบ ซึ่งเป็น XOR ของบิตสูงและต่ำของ CRC32
ควรจำไว้ว่าการใช้รหัสตรวจสอบยังคงไม่สามารถป้องกันข้อผิดพลาดของเนื้อหาได้ 100% และ TCP ก็เช่นเดียวกัน หากคุณต้องการความแม่นยำจริงๆ ให้เปิดใช้งานตัวเลือกการเข้ารหัส
แม้ว่า KCP Tube จะมีฟังก์ชัน "มัลติเพล็กซ์" แต่ก็ไม่ได้เปิดอยู่ตามค่าเริ่มต้น หากไม่มีคุณสมบัตินี้ สำหรับทุกการเชื่อมต่อขาเข้าที่ยอมรับ การเชื่อมต่อขาออกที่สอดคล้องกันจะถูกสร้างขึ้น
เหตุผลก็คือเพื่อหลีกเลี่ยง QoS ของผู้ปฏิบัติงาน ในสถานะมัลติเพล็กซ์ เมื่อหมายเลขพอร์ตที่แน่นอนคือ QoS เซสชันอื่นๆ ที่ใช้หมายเลขพอร์ตเดียวกันร่วมกันจะถูกบล็อกในเวลาเดียวกันจนกว่าหมายเลขพอร์ตจะเปลี่ยนไป
การเชื่อมต่อเป็นอิสระจากกัน แม้ว่าหมายเลขพอร์ตที่แน่นอนจะเป็น QoS เฉพาะเซสชันนี้เท่านั้นที่จะได้รับผลกระทบ และเซสชันอื่นๆ จะไม่ได้รับผลกระทบ
เว้นแต่โปรแกรมที่โฮสต์จะสร้างการเชื่อมต่ออิสระจำนวนมาก ในกรณีนี้ KCP Tube จะสร้างช่อง KCP จำนวนมาก ซึ่งจะใช้ทรัพยากร CPU มากขึ้นในระหว่างกระบวนการสื่อสาร
หากคุณต้องการใช้ฟังก์ชัน "มัลติเพล็กซ์" จริงๆ คุณสามารถอ้างอิงตามหมวดหมู่ต่อไปนี้:
สถานการณ์สมมติที่เหมาะสมสำหรับการใช้ "มัลติเพล็กซ์":
สถานการณ์สมมติที่ไม่จำเป็นต้องใช้ "มัลติเพล็กซ์":
เมื่อเปิดใช้งาน "มัลติเพล็กซ์" KCPTube จะสร้างลิงก์ N ไว้ล่วงหน้า และการเชื่อมต่อใหม่ขาเข้าทั้งหมดจะส่งข้อมูลจากลิงก์ที่มีอยู่ แทนที่จะสร้างลิงก์ใหม่แยกกัน ในขณะนี้ เวลาหมดเวลาของช่อง KCP คือ 30 วินาที
โดยทั่วไป การตั้งค่า `mux_tunnels เป็น 3 ~ 10 ก็เพียงพอแล้ว และไม่จำเป็นต้องตั้งค่าสูงเกินไป
เพื่อลดเวลาในการตอบสนอง kcptube จะเปิดใช้งานตัวเลือก TCP_NODELAY สำหรับบางสถานการณ์แอปพลิเคชันการรับส่งข้อมูลขนาดใหญ่ จำนวนการส่งข้อมูล TCP อาจลดลง
จาก KCP ดั้งเดิม มีการแก้ไขดังต่อไปนี้:
flush() ดั้งเดิมถ่ายโอนข้อมูลที่จะส่งไปยังคิวการส่ง จากนั้นจึงทำซ้ำสามสิ่ง ได้แก่ "การส่งแพ็กเก็ตข้อมูลใหม่" "การส่งแพ็กเก็ตข้อมูลอีกครั้ง" และ "การส่งแพ็กเก็ต ACK" ในรอบเดียวกัน เวอร์ชันที่แก้ไขจะทำ "การส่งแพ็กเก็ตข้อมูลใหม่" และ "การส่งแพ็กเก็ต ACK" ก่อน จากนั้น "ถ่ายโอนข้อมูลที่จะส่งไปยังคิวการส่ง" และส่งในระหว่างช่วงการถ่ายโอนcheck() จะข้ามคิวการส่งอีกครั้งทุกครั้งเพื่อค้นหาการประทับเวลาการส่งสัญญาณซ้ำของจุดที่ถึง เวอร์ชันที่แก้ไขจะกลายเป็น: อ่านการประทับเวลาแรกจากตารางการแมปที่เรียงลำดับ ขจัดขั้นตอนการค้นหานอกจากนี้เวอร์ชันดั้งเดิมยังมี "ข้อบกพร่อง" และ kcptube ก็จะมีข้อบกพร่องเช่นกัน ตัวอย่างเช่น:
kcptube จึงจัดทำแผนการกันสะเทือนที่ชัดเจนยิ่งขึ้น สำหรับข้อมูล TCP เมื่อถึงขีดจำกัดการรับ (คิวเต็ม) การรับข้อมูล TCP จะถูกระงับจนกว่าจะมีพื้นที่ว่างแล้วจึงดำเนินการต่อ สำหรับข้อมูล UDP แพ็กเก็ตจะหายไปโดยตรงเมื่อถึงขีดจำกัดการรับ
ข้อจำกัดนี้โดยพื้นฐานแล้วจะไม่มีผลกระทบต่อสถานการณ์การใช้งานแอปพลิเคชันที่มีปริมาณการส่งข้อมูลไม่มาก
เธรดพูลที่ใช้โดย kcptube มาจาก BS::thread_pool โดยมีการแก้ไขบางอย่างสำหรับการเข้ารหัสแบบขนานและการประมวลผลการถอดรหัสระหว่างการเชื่อมต่อหลาย ๆ อัน
โค้ดนี้เขียนแบบไม่เป็นทางการมาก และฉันก็เขียนมันทุกที่ที่คิด ดังนั้นเลย์เอาต์จึงทำให้เกิดความสับสน พูดให้ถูกคือมันสับสนมาก
โค้ดบางบรรทัดยาวพอๆ กับเสาไม้ไผ่ สาเหตุหลักมาจากฉันขี้เกียจเกินกว่าจะเปลี่ยนบรรทัดเพื่อตามกระแสความคิดเมื่อเขียน ท้ายที่สุดแล้ว ฉันไม่ได้ใช้ vim/emacs เมื่อฉันใช้ IDE ขนาดข้อความที่ตั้งไว้ในพื้นที่โค้ดของ IDE จะแตกต่างจากขนาดข้อความในพื้นที่อื่นๆ และแม้แต่แบบอักษรก็ยังแตกต่างกัน ซึ่งช่วยฉันบรรเทาปัญหาความสับสนได้
ส่วนความรู้สึกของผู้อ่าน...คงจะไม่มีความสุขอย่างแน่นอน มันไม่ใช่กงการของฉัน ปล่อยมันไว้คนเดียว
