انقر هنا للحصول على النسخة الإنجليزية
أي شخص يستخدم النطاق العريض المنزلي من المشغلين الثلاثة الرئيسيين ويحتاج إلى اتصال بيني للنطاق العريض المنزلي سيواجه دائمًا أن UDP محدود السرعة. من أجل تجنب جودة الخدمة للمشغلين الثلاثة الرئيسيين لـ UDP، قمت بإنشاء أداة أخرى تسمى UDP Hop. المبدأ هو إنشاء اتصالات جديدة بانتظام (تغيير أرقام المنافذ والاتصال بالعناوين الجديدة).
ومع ذلك، يدعم UDP Hop فقط إعادة توجيه حركة مرور UDP. لتتمكن من استخدام UDP لإعادة توجيه حركة مرور TCP، يوجد أنبوب KCP. يتم استخدام إعادة الإرسال الموثوق به لـ KCP لضمان عدم فقدان حزم TCP المعاد توجيهها.
سبب آخر لإنشاء KCP Tube هو أن أدوات إعادة توجيه KCP الأخرى يمكنها فقط إعادة توجيه حركة مرور TCP، ولكنني بحاجة إلى استخدام KCP لإعادة توجيه حركة مرور UDP. بشكل أساسي من أجل راحة ممارسة الألعاب.
وبطبيعة الحال، تم تصميم udphop وkcptube في نفس الوقت. لذلك، من أجل الراحة، قمنا أولاً بإعداد أنبوب KCP وإعداد الإطار، ثم قمنا بتقطيعه إلى UDP Hop بناءً على أنبوب KCP. ثم قم بدمج رمز تصحيح UDP Hop بشكل عكسي في أنبوب KCP.
من أجل تسهيل استخدام 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
اسم | قيمة قابلة للتسوية | مطلوب | ملاحظة |
---|---|---|---|
وضع | عميل الخادم تتابع | نعم | عقدة ترحيل خادم العميل |
استمع_ون | اسم المجال أو عنوان IP | لا | يمكن ملء اسم المجال أو عنوان IP فقط. يرجى فصل العناوين المتعددة بفواصل |
learn_port | 1-65535 | نعم | عند التشغيل كخادم، يمكنك تحديد نطاق المنفذ |
Destination_port | 1-65535 | نعم | يمكن تحديد نطاقات المنافذ عند التشغيل كعميل. يرجى فصل العناوين المتعددة بفواصل |
Destination_address | عنوان IP، اسم المجال | نعم | ليست هناك حاجة إلى أقواس مربعة عند ملء عنوان IPv6 |
dport_refresh | 0 - 32767 | لا | الوحدة هي "الثانية". إذا تركت فارغة، سيتم استخدام القيمة الافتراضية وهي 60 ثانية. يتم حساب 1 إلى 20 كـ 20 ثانية، ويتم حساب أكبر من 32767 كـ 32767 ثانية. اضبط على 0 للتعطيل. |
خوارزمية التشفير | الخدمات المعمارية والهندسية-جي سي إم AES-OCB chacha20 xchacha20 لا أحد | لا | AES-256-GCM-AEAD AES-256-OCB-AEAD ChaCha20-Poly1305 XChaCha20-Poly1305 لا يوجد تشفير |
تشفير_كلمة المرور | أي شخصية | يعتمد على الوضع | مطلوب عند تعيين خوارزمية التشفير وليس لا شيء |
udp_timeout | 0 - 65535 | لا | الوحدة هي "الثانية". القيمة الافتراضية هي 180 ثانية، إذا تم ضبطها على 0، فسيتم استخدام القيمة الافتراضية. يمثل هذا الخيار إعداد المهلة بين تطبيق UDP ↔ kcptube |
keep_alive | 0 - 65535 | لا | الوحدة هي "الثانية". القيمة الافتراضية هي 0، وهو ما يعادل تعطيل Keep Alive. يشير هذا الخيار إلى Keep Alive بين طرفي KCP يمكن تمكينه من جانب واحد لاكتشاف ما إذا كانت القناة تتوقف عن الاستجابة. إذا لم يكن هناك استجابة بعد 30 ثانية، سيتم إغلاق القناة. |
mux_tunnels | 0 - 65535 | لا | القيمة الافتراضية هي 0، وهو ما يعادل عدم استخدام قنوات تعدد الإرسال. يشير هذا الخيار إلى عدد قنوات تعدد الإرسال بين طرفي KCP. يتم تمكين هذا الخيار فقط على جانب العميل. |
stun_server | عنوان خادم STUN | لا | لا يمكن استخدامه عندما يكون list_port في وضع نطاق المنفذ |
log_path | دليل لتخزين السجل | لا | لا يمكن الإشارة إلى الملف نفسه |
براز | uint8:uint8 | لا | التنسيق هو fec=D:R ، على سبيل المثال، يمكن ملء fec=20:3 .ملحوظة: الحد الأقصى لقيمة D + R هو 255 ولا يمكن أن يتجاوز هذا الرقم. تشير قيمة 0 على جانبي النقطتين إلى عدم استخدام الخيار. يجب أن تكون الإعدادات هي نفسها على كلا الطرفين. للحصول على التفاصيل، يرجى الرجوع إلى دليل استخدام FEC. |
mtu | عدد صحيح موجب | لا | قيمة MTU الحالية للشبكة، تُستخدم لحساب kcp_mtu تلقائيًا |
kcp_mtu | عدد صحيح موجب | لا | القيمة الافتراضية هي 1440. القيمة التي تم تعيينها عن طريق استدعاء ikcp_setmtu() هي طول محتوى البيانات في حزمة UDP. |
kcp | يدوي سريع1-6 منتظم1-5 | نعم | ضبط السرعة العادية يدويًا (الرقم في النهاية: كلما كان الرقم أصغر، زادت السرعة) |
kcp_sndwnd | عدد صحيح موجب | لا | القيم الافتراضية موضحة في الجدول أدناه ويمكن تجاوزها بشكل فردي. |
kcp_rcvwnd | عدد صحيح موجب | لا | القيم الافتراضية موضحة في الجدول أدناه ويمكن تجاوزها بشكل فردي. |
kcp_nodelay | عدد صحيح موجب | يعتمد على الوضع | تكون القيمة الافتراضية مطلوبة عندما يكون kcp=manual، وتظهر في الجدول أدناه |
kcp_interval | عدد صحيح موجب | يعتمد على الوضع | تكون القيمة الافتراضية مطلوبة عندما يكون kcp=manual، وتظهر في الجدول أدناه |
kcp_resend | عدد صحيح موجب | يعتمد على الوضع | تكون القيمة الافتراضية مطلوبة عندما يكون kcp=manual، وتظهر في الجدول أدناه |
kcp_nc | نعم حقيقي 1 لا خطأ شنيع 0 | يعتمد على الوضع | تكون القيمة الافتراضية مطلوبة عندما يكون kcp=manual، وتظهر في الجدول أدناه |
outbound_bandwidth | عدد صحيح موجب | لا | النطاق الترددي الصادر، يُستخدم لتحديث قيمة kcp_sndwnd ديناميكيًا أثناء عملية الاتصال |
inbound_bandwidth | عدد صحيح موجب | لا | النطاق الترددي الوارد، يُستخدم لتحديث قيمة kcp_rcvwnd ديناميكيًا أثناء عملية الاتصال |
ipv4_only | نعم حقيقي 1 لا خطأ شنيع 0 | لا | إذا تم تعطيل IPv6 على النظام، فيجب تمكين هذا الخيار وتعيينه على نعم أو صحيح أو 1 |
ipv6_only | نعم حقيقي 1 لا خطأ شنيع 0 | لا | تجاهل عناوين IPv4 |
انفجار | نعم حقيقي 1 لا خطأ شنيع 0 | لا | حاول تجاهل إعدادات التحكم في تدفق KCP وإعادة توجيه الحزم في أسرع وقت ممكن. قد يسبب الحمل الزائد |
[المستمع] | لا يوجد | نعم (وضع التتابع فقط) | تشير تسمية وضع الترحيل المستخدمة لتحديد KCP في وضع الاستماع إلى أن تعيين هذه التسمية يشير إلى بيانات التفاعل مع العميل. |
[وكيل الشحن] | لا يوجد | نعم (وضع التتابع فقط) | تشير تسمية وضع الترحيل المستخدمة لتحديد KCP لوضع النقل إلى بيانات التفاعل مع الخادم. |
[custom_input] | لا يوجد | لا | تسمية وضع التعيين المخصص للاستخدام، يرجى الرجوع إلى كيفية استخدام التعيين المخصص. |
[custom_input_tcp] | لا يوجد | لا | تسمية وضع التعيين المخصص للاستخدام، يرجى الرجوع إلى كيفية استخدام التعيين المخصص. |
[custom_input_udp] | لا يوجد | لا | تسمية وضع التعيين المخصص للاستخدام، يرجى الرجوع إلى كيفية استخدام التعيين المخصص. |
من بينها، يجب أن تكون encryption_algorithm
وكلمة encryption_password
متسقتين عند طرفي الاتصال.
اسم | قيمة قابلة للتسوية | مطلوب | ملاحظة |
---|---|---|---|
fib_inggress | 0 - 65535 | لا | FIB المستخدمة من قبل الاتصالات الواردة |
fib_egress | 0 - 65535 | لا | FIB يستخدم للاتصالات الصادرة |
اللواحق المتوفرة: K/M/G
اللاحقة حساسة لحالة الأحرف، ويتم حساب الأحرف الكبيرة على أنها ثنائية (1024)، ويتم حساب الأحرف الصغيرة على أنها عشرية (1000).
املأ 1000، مما يشير إلى أن عرض النطاق الترددي هو 1000 بت في الثانية
املأ 100 كيلو، مما يشير إلى أن عرض النطاق الترددي هو 100 كيلوبت في الثانية (100000 بت في الثانية)
املأ 100 كيلو بايت، مما يشير إلى أن عرض النطاق الترددي هو 100 كيلوبت في الثانية (102400 بت في الثانية)
املأ 100M، مما يشير إلى أن عرض النطاق الترددي هو 100 ميجابت في الثانية (102400 كيلوبت في الثانية)
املأ 1G، مما يشير إلى أن عرض النطاق الترددي هو 1 جيجابت في الثانية (1024 ميجابت في الثانية)
لاحظ أنها بت (بت في الثانية)، وليس بت في الثانية (بايت في الثانية).
تجدر الإشارة إلى أن قيمة النطاق الترددي المملوءة يجب ألا تتجاوز عرض النطاق الترددي الفعلي لتجنب الازدحام في نافذة الإرسال.
ملاحظة هامة :
سيقوم KCPTube بحساب وتعيين حجم نافذة إرسال KCP بعد حوالي 5 ثوانٍ من إنشاء رابط KCP، بناءً على قيمة التأخير لحزمة المصافحة وقيم عرض النطاق الترددي الصادر وعرض النطاق الترددي الوارد. في غضون فترة من الوقت بعد اكتمال الإعداد، هناك احتمال كبير أن تتقلب حركة المرور بشكل كبير، أو حتى قد تنخفض حركة المرور فجأة إلى 0، وسوف يستغرق الأمر عدة ثوانٍ للتعافي.
الوضع السريع | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_interval | kcp_resend | kcp_nc |
---|---|---|---|---|---|---|
سريع1 | 2048 | 2048 | 1 | 1 | 2 | 1 |
fast2 | 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_interval | kcp_resend | kcp_nc |
---|---|---|---|---|---|---|
منتظم1 | 1024 | 1024 | 1 | 1 | 5 | 1 |
منتظم2 | 1024 | 1024 | 2 | 1 | 5 | 1 |
منتظم3 | 1024 | 1024 | 0 | 1 | 2 | 1 |
منتظم4 | 1024 | 1024 | 0 | 15 | 2 | 1 |
منتظم5 | 1024 | 1024 | 0 | 30 | 2 | 1 |
من بينها، كلما ارتفع معدل فقدان الحزمة (أعلى من 10%)، زادت الميزة التي يتمتع بها kcp_nodelay=1 على kcp_nodelay=2. عندما لا يكون معدل فقدان الحزمة مرتفعًا بشكل خاص، فإن kcp_nodelay=2 يمكن أن يجعل ارتعاش التأخير أكثر سلاسة.
بالنسبة لبيئات فقدان الحزمة المنخفضة، يكون كل وضع مناسبًا للاستخدام، ويكمن الاختلاف الوحيد في ما إذا كان يتم استخدام حركة مرور مهدرة أكثر أو أقل، ويختلف الحد الأعلى للسرعة القصوى. من بينها، Regular3 لا يضيع الكثير من حركة المرور.
يوصى بتمكين إعداد blast=1
في نفس الوقت.
بالنسبة لبيئات فقدان الحزم العالية، فكر في تراكب إعداد FEC. للحصول على التفاصيل، يرجى الرجوع إلى دليل استخدام FEC.
لمزيد من التفاصيل، راجع قائمة المعلمات.
بعد الحصول على عنوان IP والمنفذ المثقوب لأول مرة، وبعد تغيير عنوان IP والمنفذ المثقوب، سيتم إنشاء ملف ip_address.txt في دليل السجل (الكتابة فوقه إذا كان موجودًا)، و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.conf
kcptube_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
ثم قم بالبناء في دليل البناء
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 أعلاه.
لاحظ أنه بما أن BSDs هذه تأتي مع إصدارات أقل للمترجم، يرجى تثبيت إصدار أعلى من GB مقدمًا.
الخطوات مشابهة لـ FreeBSD، يرجى استخدام مدير الحزم الذي يأتي مع التوزيع لتثبيت asio وbotan3 وcmake.
apk add asio botan3-libs cmake
ثم قم بالبناء في دليل البناء
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 الفردي داخليًا + يقوم بتشغيل عنوان IPv4 المعين (IPv4 المعين IPv6) لاستخدام كل من شبكات IPv4 وIPv6، يرجى التأكد من أن قيمة الخيار v6only هي 0.
في الظروف العادية، لا يلزم وجود إعدادات إضافية، حيث تسمح أنظمة FreeBSD وLinux وWindows بتعيين عناوين IPv4 إلى IPv6 بشكل افتراضي.
إذا كان النظام لا يدعم IPv6، أو تم تعطيل IPv6، فيرجى تعيين ipv4_only=true في ملف التكوين، بحيث يعود kcptube إلى استخدام وضع IPv4 الفردي المكدس.
استخدم الأمر
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 يقتصر على 1024، فمن السهل مواجهة هذه المشكلة.
الحل المؤقت:
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 يحتوي على وظيفة "تعدد الإرسال"، إلا أنه لا يتم فتحه بشكل نشط بشكل افتراضي. بدون هذه الميزة، يتم إنشاء اتصال صادر مقابل لكل اتصال وارد يتم قبوله.
والسبب هو تجنب جودة الخدمة الخاصة بالمشغل. في حالة تعدد الإرسال، بمجرد أن يكون رقم منفذ معين هو جودة الخدمة، سيتم حظر الجلسات الأخرى التي تشترك في نفس رقم المنفذ في نفس الوقت حتى يتم تغيير رقم المنفذ.
الاتصالات مستقلة عن بعضها البعض، حتى لو كان رقم منفذ معين هو جودة الخدمة، فستتأثر هذه الجلسة فقط ولن تتأثر الجلسات الأخرى.
ما لم يقم البرنامج المستضاف بإنشاء عدد كبير من الاتصالات المستقلة. في هذه الحالة، سيقوم أنبوب KCP بإنشاء عدد كبير من قنوات KCP، والتي ستستهلك المزيد من موارد وحدة المعالجة المركزية أثناء عملية الاتصال.
إذا كنت تريد حقًا استخدام وظيفة "تعدد الإرسال"، فيمكنك الرجوع إلى الفئات التالية:
السيناريوهات المناسبة لاستخدام "تعدد الإرسال":
السيناريوهات التي لا يكون فيها "تعدد الإرسال" ضروريًا:
عند تمكين "تعدد الإرسال"، سيقوم 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 عن حجم النص في المناطق الأخرى، وحتى الخطوط مختلفة، مما يساعدني في تخفيف مشكلة الارتباك.
أما بالنسبة لمشاعر القراء... فبالتأكيد لن يكونوا سعداء. هذا ليس من شأني، اتركه وشأنه.