প্রক্সিকমন্ডের মাধ্যমে এসএসএইচ গতির ব্যাপক উন্নতি হয়েছে - তবে কেন?

Question

টিএল; ডিআর সংস্করণ

এই এএসসিআইআই কাস্ট বা এই ভিডিওটি দেখুন - তারপরে কেন এমনটি হচ্ছে তার কোনও কারণ নিয়ে আসুন। নীচের পাঠ্যের বিবরণটি আরও প্রসঙ্গ সরবরাহ করে।

সেটআপের বিশদ

• মেশিন 1 হ'ল একটি আর্চ লিনাক্স ল্যাপটপ, যার sshউপর তৈরি হয় একটি আরম্বিয়ান-চলমান এসবিসি (একটি কমলা পিআই জিরো) এর সাথে সংযুক্ত।
• এসবিসি নিজেই ইথারনেটের মাধ্যমে ডিএসএল রাউটারের সাথে সংযুক্ত এবং এর আইপি রয়েছে 192.168.1.150
• ল্যাপটপটি ওয়াইফাইয়ের মাধ্যমে রাউটারের সাথে সংযুক্ত রয়েছে - একটি অফিসিয়াল রাস্পবেরি পিআই ওয়াইফাই ডংল ব্যবহার করে।
• আরও একটি ল্যাপটপ (মেশিন 2) ইথারনেটের মাধ্যমে ডিএসএল রাউটারের সাথে সংযুক্ত রয়েছে।

আইপিএফ 3 এর সাথে লিঙ্কটি বেঞ্চমার্কিং

যখন সঙ্গে benchmarked iperf3, ল্যাপটপ মধ্যে লিঙ্ক এবং SBC তাত্ত্বিক 56 MBits / সেকেন্ড কম - যেহেতু এই একটি খুব "ভীড় 2.4GHz" এর মধ্যে WiFi সংযোগ করা হয়, আশানুরূপ (এপার্টমেন্ট বিল্ডিং) ।

আরও সুনির্দিষ্টভাবে: iperf3 -sএসবিসিতে চলার পরে , ল্যাপটপে নিম্নলিখিত কমান্ডগুলি কার্যকর করা হয়:

# iperf3 -c 192.168.1.150
Connecting to host 192.168.1.150, port 5201
[  5] local 192.168.1.89 port 57954 connected to 192.168.1.150 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.99 MBytes  25.1 Mbits/sec    0    112 KBytes       
...
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  28.0 MBytes  23.5 Mbits/sec    5             sender
[  5]   0.00-10.00  sec  27.8 MBytes  23.4 Mbits/sec                  receiver

iperf Done.

# iperf3 -c 192.168.1.150 -R
Connecting to host 192.168.1.150, port 5201
Reverse mode, remote host 192.168.1.150 is sending
[  5] local 192.168.1.89 port 57960 connected to 192.168.1.150 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  3.43 MBytes  28.7 Mbits/sec                  
...                
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  39.2 MBytes  32.9 Mbits/sec  375             sender
[  5]   0.00-10.00  sec  37.7 MBytes  31.6 Mbits/sec                  receiver

সুতরাং মূলত, এসবিসিতে আপলোড করা প্রায় 24MBits / সেকেন্ডে পৌঁছায় এবং এ থেকে ডাউনলোড করে -R32MBits / সেকেন্ডে পৌঁছে যায়।

এসএসএইচের সাথে বেঞ্চমার্কিং

দেওয়া হয়েছে, এসএসএইচ ভাড়া কিভাবে দেখুন। ব্যবহার করার সময় এই পোস্টটিতে যে সমস্যাগুলির সৃষ্টি হয়েছিল rsyncএবং আমি borgbackupউভয়ই প্রথমে এসএসএইচকে পরিবহন স্তর হিসাবে ব্যবহার করেছিলাম তা প্রথম অভিজ্ঞতা পেয়েছি ... সুতরাং এসএসএইচ একই লিঙ্কে কীভাবে কার্য সম্পাদন করে তা দেখুন:

# cat /dev/urandom | \
    pv -ptebar | \
    ssh  root@192.168.1.150 'cat >/dev/null'
20.3MiB 0:00:52 [ 315KiB/s] [ 394KiB/s]

আচ্ছা, এটি একটি অতীব গতি! প্রত্যাশিত লিঙ্কের গতির চেয়ে অনেক ধীর গতি ... (যদি আপনি সচেতন না হন pv -ptevar: এটি এর মধ্য দিয়ে যাওয়া ডেটার বর্তমান এবং গড় হার প্রদর্শন করে this /dev/urandomএক্ষেত্রে , আমরা দেখি যে এসএসএইচের মাধ্যমে ডেটা এসবিসিতে পাঠাচ্ছি এবং প্রেরণ করছি গড়ে ৪০০ কেবি / সেকেন্ডে পৌঁছেছে - অর্থাৎ ৩.২ এমবিটস / সেকেন্ড, প্রত্যাশিত 24 এমবিট / সেকেন্ডের চেয়ে অনেক কম চিত্র।)

আমাদের লিঙ্কটি কেন এর ক্ষমতার 13% এ চলছে?

এটা কি আমাদের /dev/urandomভুল?

# cat /dev/urandom | pv -ptebar > /dev/null
834MiB 0:00:04 [ 216MiB/s] [ 208MiB/s]

না, অবশ্যই না।

এটি সম্ভবত এসবিসি নিজেই? সম্ভবত এটি প্রক্রিয়া করতে খুব ধীর? আসুন একই এসএসএইচ কমান্ড চালানোর চেষ্টা করা যাক (যেমন এসবিসিতে ডেটা প্রেরণ করা) তবে এবার ইথারনেটের সাথে সংযুক্ত অন্য একটি মেশিন (মেশিন 2) থেকে:

# cat /dev/urandom | \
    pv -ptebar | \
    ssh  root@192.168.1.150 'cat >/dev/null'
240MiB 0:00:31 [10.7MiB/s] [7.69MiB/s] 

নাহ, এটি সূক্ষ্মভাবে কাজ করে - এসবিসি-তে এসএসএইচ ডেমন (সহজেই) এটি 11 ইমেট / সেকেন্ড (অর্থাৎ 100 এমবিটস / সেকেন্ড) পরিচালনা করতে পারে যা ইথারনেট লিঙ্কটি সরবরাহ করে।

এবং এসবিসির সিপিইউ কি এটি করার সময় লোড হয়?

নাঃ।

তাই ...

• নেটওয়ার্ক-ভিত্তিক (অনুযায়ী iperf3) আমাদের 10x গতি করতে সক্ষম হওয়া উচিত
• আমাদের সিপিইউ সহজেই বোঝা সামঞ্জস্য করতে পারে
• ... এবং আমরা অন্য কোনও ধরণের আই / ও (যেমন ড্রাইভ) জড়িত করি না।

হেক কি হচ্ছে?

নেটক্যাট এবং প্রক্সিকম্যান্ড উদ্ধার করার জন্য

আসুন আমরা পুরানো netcatসংযোগগুলি চেষ্টা করি - তারা কি আমাদের প্রত্যাশা মতো দ্রুত চালায়?

এসবিসিতে:

# nc -l -p 9988 | pv -ptebar > /dev/null

ল্যাপটপে:

# cat /dev/urandom | pv -ptebar | nc 192.168.1.150 9988
117MiB 0:00:33 [3.82MiB/s] [3.57MiB/s] 

এটি কাজ করে! এবং প্রত্যাশিতভাবে সঞ্চালিত হয় - আরও ভাল, 10x আরও ভাল - গতি।

সুতরাং যদি আমি এনসি ব্যবহারের জন্য প্রক্সিকমন্ড ব্যবহার করে এসএসএইচ চালাই তবে কী হবে?

# cat /dev/urandom | \
    pv -ptebar | \
    ssh -o "Proxycommand nc %h %p" root@192.168.1.150 'cat >/dev/null'
101MiB 0:00:30 [3.38MiB/s] [3.33MiB/s]

কাজ করে! 10x গতি।

এখন আমি কিছুটা বিভ্রান্ত হয়ে পড়েছি - "নগ্ন" ncকে হিসাবে হিসাবে ব্যবহার করার সময় Proxycommand, আপনি কি মূলত এসএসএইচ ঠিক একই জিনিসটি করছেন না? অর্থাত্ একটি সকেট তৈরি করা, এসবিসির বন্দরের সাথে সংযোগ স্থাপন করা 22, এবং তারপরে এসএসএইচ প্রোটোকলটি সরিয়ে ফেলছেন?

ফলাফল গতির মধ্যে এই বিশাল পার্থক্য কেন?

পিএস এটি একাডেমিক অনুশীলন ছিল না - এর কারণে আমার borgব্যাকআপটি 10 ​​গুণ দ্রুত গতিতে চলে। আমি কেন জানি না :-)

সম্পাদনা : প্রক্রিয়াটির একটি "ভিডিও" এখানে যুক্ত করা হয়েছে । Ifconfig এর আউটপুট থেকে প্রেরিত প্যাকেটগুলি গণনা করা, এটি পরিষ্কার যে উভয় পরীক্ষায় আমরা 40MB ডেটা প্রেরণ করছি, প্রায় 30 কে প্যাকেটে সেগুলি প্রেরণ করছি - যখন না ব্যবহার করছেন তখন খুব ধীর ProxyCommand।

Comments

বাফার উপলব্ধ? আমি মনে করব ncলাইন বাফারিং ব্যবহার করে, যেখানে sshকোনও বাফারিং নেই। সুতরাং (বা যদি তাই হয়) ssh ট্র্যাফিকের সাথে আরও বেশি প্যাকেট জড়িত।

— র‌্যাল্ফ রনকুইস্ট

আমি কোনও বিশেষজ্ঞ নই তবে আমি মনে করি কমলা 0 সিপিইউ দ্বারা নিয়ন্ত্রিত কেবল একটি ইউএসবি বাস রয়েছে, নেটওয়ার্কটি সেই ইউএসবি বাসের মধ্য দিয়ে যায়, সিপিইউকে সফটওয়্যারটির মাধ্যমে এলোমেলো সংখ্যা তৈরি করতে হয় (সেই ধরণের আর্কিটেকচারের কোনও চিপ নেই যিনি সেই মাধ্যমে করেন) হার্ডওয়্যার) এবং একই সাথে সেখানে চলছে ssh সাইফার এবং সম্ভবত ssh সংক্ষেপন। আমি এগুলি সব যাচাই করিনি তাই এটি সম্ভব যে আমি কিছু ভুল বলছি।

— ডি'আরসি নাদের 13

@ ডি'আরসিএনডার: না, আমি ভয় করি যে আপনি এটি ভুল করে ফেলেছেন। ট্যাবে / ডেভ / ইউরেনডম ল্যাপটপে ঘটে (x86) - এবং আমি মেশিন 2 থেকে এসবিসি-তে কথা বলার মধ্য দিয়ে একই পরীক্ষা করেছি, শীর্ষ গতিতে পৌঁছেছি (100MBits / সেকেন্ড), এবং এভাবে প্রমাণ করে যে ট্রাফিকের সাথে মোকাবিলা করার ক্ষেত্রে এসবিসির কোনও সমস্যা নেই। সমস্যাটি তখনই উদ্ভূত হয় যখন এসএসএইচটি ল্যাপটপ থেকে ব্যবহৃত হয় - এবং যখন আমি এসএসএইচ আহ্বান (আবার ল্যাপটপের দিকে) নেটক্যাট ব্যবহার করার জন্য পরিবর্তন করি - তখনও ডেভ / ইউরানডম করে এবং সমস্ত ডেটা পাইপিং করে - সমস্যাটি অদৃশ্য হয়ে যায়। এবং বিটিডাব্লু, একক ইউএসবি বাস রাস্পবেরি পিআইয়ের সমস্যা - কমলা পিআই নয়।

— ttsiodras

আমি আপনাকে সাহায্য না করলে আমি দুঃখিত। এবং স্পষ্টির জন্য আপনাকে ধন্যবাদ।

— ডি'আরসি নাদের 14

@ রালফ্রানকুইস্ট: এই খরগোশের ছিদ্রটি আমাকে নীচে নেমে আসল ব্যবহারের ক্ষেত্রে আরএসসিএনসি এবং বার্গব্যাকআপের উপরে জিনিসকে সমর্থন করছিল। অনেক সরঞ্জাম এসএসএইচকে পরিবহণ ব্যবস্থা হিসাবে ব্যবহার করে - এবং আমার ক্ষেত্রে এটির কারণে ক্ষতিগ্রস্থ হয়েছিল। আমি যদি যা অভিজ্ঞতা অর্জন করতে পারি, প্রকৃতপক্ষে "স্ট্যান্ডার্ড" এসএসএইচ আচরণ হয়, তবে আমি আশা করব যে নেট ব্যায়াম প্রক্সিকমন্ডের মাধ্যমে এসএসএইচ স্প্যান করার জন্য সমস্ত ব্যাকআপ সরঞ্জামগুলিতে টানুন অনুরোধগুলি জমা দেওয়ার সাথে সাথে সমস্ত গ্রহে তাত্ক্ষণিকভাবে ব্যাকআপগুলি ত্বরান্বিত করবে! আমি বিশ্বাস করতে পারি না যে আমি এ জাতীয় "বিশাল" আবিষ্কার করেছি :-) এখানে অন্য কিছু অবশ্যই ঘটবে।

— ttsiodras

Answer 1

মন্তব্যগুলিতে ধারণাগুলি জমা দেওয়া লোকগুলিকে অনেক ধন্যবাদ। আমি তাদের সকলের মধ্য দিয়ে গেলাম:

Tcpdump সহ প্যাকেট রেকর্ডিং এবং ওয়্যারশার্কে সামগ্রীর তুলনা করা

# tcpdump -i wlan0 -w good.ssh & \
     cat signature | ssh -o "ProxyCommand nc %h %p" \
        root@192.168.1.150 'cat | md5sum' ; \
     killall tcpdump
# tcpdump -i wlan0 -w bad.ssh & \
     cat signature | ssh root@192.168.1.150 'cat | md5sum' ; \
     killall tcpdump

রেকর্ড করা প্যাকেটগুলির মধ্যে কোনও গুরুত্বের কোনও পার্থক্য ছিল না।

ট্র্যাফিক গঠনের জন্য চেক করা হচ্ছে

এ সম্পর্কে কোনও ধারণা ছিল না - তবে "টিসি" ম্যানপেজটি দেখার পরে, আমি এটি যাচাই করতে সক্ষম হয়েছি

• tc filter show কিছুই না
• tc class show কিছুই না
• tc qdisc show

... এগুলি ফেরত দেয়:

qdisc noqueue 0: dev lo root refcnt 2
qdisc noqueue 0: dev docker0 root refcnt 2
qdisc fq_codel 0: dev wlan0 root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn 

... যা "ssh" এবং "NC" এর মধ্যে পার্থক্য বলে মনে হয় না - আসলে, আমি নিশ্চিতও না যে ট্র্যাফিকের আকার দেওয়ার প্রক্রিয়া স্তরটিতে কাজ করতে পারে কিনা (আমি আশা করি এটি ঠিকানা / পোর্ট / পার্থক্য নিয়ে কাজ করবে) আইপি শিরোনামে পরিষেবা ক্ষেত্র)।

আর্ক লিনাক্স এসএসএইচ ক্লায়েন্টের সম্ভাব্য "চতুরতা" এড়ানোর জন্য ডেবিয়ান ক্রুট

না, একই ফলাফল।

অবশেষে - নাগলে

প্রেরকের মধ্যে একটি স্ট্রেস সম্পাদন করা হচ্ছে ...

pv data | strace -T -ttt -f ssh 192.168.1.150 'cat | md5sum' 2>bad.log

... এবং সকেটে ঠিক কী ঘটে যা ডেটা জুড়ে প্রেরণ করে, আমি প্রকৃত ট্রান্সমিশন শুরু হওয়ার আগে এই "সেটআপ" লক্ষ্য করেছি:

1522665534.007805 getsockopt(3, SOL_TCP, TCP_NODELAY, [0], [4]) = 0 <0.000025>
1522665534.007899 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000021>

এটি নাগলের অ্যালগরিদম অক্ষম করতে এসএসএইচ সকেট সেট আপ করে। আপনি গুগল করতে পারেন এবং এ সম্পর্কে সমস্ত কিছু পড়তে পারেন - তবে এর অর্থ হ'ল এসএসএইচ ব্যান্ডউইথের তুলনায় প্রতিক্রিয়াটিকে অগ্রাধিকার দিচ্ছে - এটি কর্নেলকে এই সকেটে লিখিত কিছু অবিলম্বে সঞ্চারিত করার নির্দেশ দেয় এবং দূরবর্তী থেকে স্বীকৃতির জন্য অপেক্ষা করতে "বিলম্ব" না করে নির্দেশ দেয়।

এর সাধারণ অর্থ, এর অর্থ কী এটির ডিফল্ট কনফিগারেশনে, এসএসএইচটি ডেটা জুড়ে পরিবহন করার পক্ষে ভাল উপায় নয় - যখন ব্যবহৃত লিঙ্কটি ধীর হয় না (যা অনেকগুলি ওয়াইফাই লিঙ্কের ক্ষেত্রে হয়)। যদি আমরা বাতাসের উপরে প্যাকেটগুলি প্রেরণ করি যা "বেশিরভাগ শিরোলেখ" হয় তবে ব্যান্ডউইথ নষ্ট হয়!

এটি প্রকৃতই অপরাধী প্রমাণ করার জন্য, আমি এই নির্দিষ্ট সিস্টেলটি "ড্রপ" করতে এলডিপ্রেলএড ব্যবহার করেছি:

$ cat force_nagle.c

#include <stdio.h>
#include <dlfcn.h>
#include <netinet/in.h>
#include <netinet/tcp.h>
#include <sys/socket.h>

int (*osetsockopt) (int socket, int level, int option_name,
           const void *option_value, socklen_t option_len) = NULL;

int setsockopt(int socket, int level, int option_name,
           const void *option_value, socklen_t option_len)
{
    int ret;
    if (!osetsockopt) {
        osetsockopt = dlsym(RTLD_NEXT, "setsockopt");
    }

    if (option_name == TCP_NODELAY) {
        puts("No, Mr Nagle stays.");
        return 0;
    }
    ret = osetsockopt(socket, level, option_name, option_value, option_len);
    return ret;
}

$ gcc -fPIC -D_GNU_SOURCE -shared -o force_nagle.so force_nagle.c -ldl

$ pv /dev/shm/data | LD_PRELOAD=./force_nagle.so ssh root@192.168.1.150 'cat >/dev/null'
No, Mr Nagle stays.
No, Mr Nagle stays.
 100MiB 0:00:29 [3.38MiB/s] [3.38MiB/s] [================================>] 100%   

সেখানে - নিখুঁত গতি (ভাল, ঠিক আইপিএফ 3 এর মতো দ্রুত)।

গল্পের মনোবল

কখনও হাল ছাড়বেন না :-)

এবং যদি আপনি এসএসএইচের মাধ্যমে তাদের ডেটা পরিবহনের মতো সরঞ্জামগুলি ব্যবহার করেন rsyncবা borgbackupআপনার লিঙ্কটি ধীর গতির হয়, তবে এসএসএইচকে নাগলে (উপরে বর্ণিত হিসাবে) অক্ষম করা থেকে বিরত করার চেষ্টা করুন - বা ProxyCommandএসএসএইচটিকে সংযোগ স্থাপনের জন্য ব্যবহার করার চেষ্টা করুন nc। এটি আপনার $ হোম / .ssh / কনফিগারেশনে স্বয়ংক্রিয় করা যেতে পারে:

$ cat .ssh/config
...
Host orangepi
    Hostname 192.168.1.150
    User root
    Port 22
    # Compression no
    # Cipher None
    ProxyCommand nc %h %p
...

... যাতে ভবিষ্যতে "কমলাপি" ব্যবহার করে ssh / rsync / borgbackup এ টার্গেট হোস্ট হিসাবে ncসংযুক্ত হওয়ার জন্য আর ব্যবহার করা হবে (এবং তাই নাগলে একা ছেড়ে যান)।

Comments

ধন্যবাদ, আপনি আমার জীবন বাঁচিয়েছেন! এটি নিয়ন্ত্রণ করার জন্য কেন সেটিংস নেই কেন তা বুঝতে আপনি ssh লোকদের সাথে যোগাযোগের চেষ্টা করেছেন?

— স্ট্যাটিক_আর্টি

আমি খুশি যে আমার অনুসন্ধানগুলি আপনাকেও সহায়তা করেছে! এসএসএইচ লোকদের সাথে যোগাযোগ করার জন্য, আমি চেষ্টা করেছি, হ্যাঁ - তবে শেষ পর্যন্ত কিছুই ঘটেনি: bugzilla.mindrot.org/show_bug.cgi?id=2848

— ttsiodras

নিজেকে বাগে যুক্ত করেছেন। কে জানে, শেষ পর্যন্ত কিছু হতে পারে! দুর্দান্ত তদন্ত, যে কোনও ক্ষেত্রে।

— স্থিতিশীল_আরটি