تست رگرسیون با Siege
وقتی یک برنامه تحت وب شروع به کار میکند شاید در نگاه اول همه چیز خوب به نظر برسد اما با رشد کاربران و افزایش ترافیک، سیستم چگونه کار خواهد کرد؟اگر برنامه تحت وب را یک جعبه در نظر بگیریم،درخواست به برنامه ارسال میشود،درخواست پردازش میشود ودر نهایت پاسخی نمایش داده می شود.با ابزار siege میتوانیم regression test , load test, stress test را به خوبی انجام دهیم. فرض کنید میخواهید برنامه ی تحت وب خود را برای یک میلیون کاربر آماده کنید.برای تست این برنامه دو راه وجود دارد، راه اول این است که از یک میلیون کاربر بخواهید که برنامه ی شما را تست کنند و راه دوم شبیه سازی این تعداد کاربر است.
انواع تست کارایی
Load test: وقتی که برنامه تحت وب را برای تعداد مشخص و از قبل تعیین شدهای از درخواست ها تست میکنیم،به این نوع تست load test می گویند.
Stress test: اگر تعداد درخواست از سطح مشخص شده فراتر رود در این صورت تست را stress test می گویند.
Regression test: وقتی تغییری در نرمافزار داده می شود،چگونه بفهمیم کارایی نرمافزار کاهش نیافته است؟ برای حصول اطمینان از یکسان بودن کارایی سرور قبل و بعد از تغییر، regression test انجام می شود. اگر بخواهیم زیرساخت ها ی پروژه را تغییر دهیم دوباره به regression test نیاز خواهیم داشت. فرض کنید پروژه بر روی وب سرور Apache باشد و بخواهیم وب سرور را به Nginx تغییر دهیم. قبل از تغییر وب سرور برنامه به صورت میانگین قادر به مدیریت N در خواست در دقیقه است. از کجا معلوم که با تغییر وب سرور کارایی برنامه کاهش نیابد و همچنان N درخواست در دقیقه قابل مدیریت باشد؟
مراحل انجام یک تست موفق:
برنامه ریزی: در این مرحله باید به سؤالاتی از این قبیل پاسخ داده شود: چه چیزی باید تست شود؟ چه انتظاری از تست وجود دارد؟ ترافیک روی سرور چقدر باید باشد؟ تست بر روی کدام آدرس باید انجام شود؟ و . . .
آماده سازی: در این مرحله باید از ایزوله بودن محیط تست اطمینان حاصل شود. برای انجام تست های بعدی هم از همین محیط ایزوله استفاده میشود.
آنالیز: نتایج حاصل از تست باید مورد ارزیابی دقیق قرار گیرند.
شروع کار با Siege:
ابزاری فوقالعاده برای بنچمارک گیری و تست اپلیکیشن های تحت وب است. این ابزار کاربران همزمان را برای تست اپ های تحت وب شبیه سازی می کند.
نصب: در توزیع ابونتو ابزار siege بدین صورت نصب می شود:«البته با نصب از طریق مخازن اصلی ابونتو، جدیدترین ورژن نصب نخواهد شد»
sudo apt-get install siege
ایجاد سرور آزمایشی: برای ایجاد یک سرور آزمایشی تنها کافی است کد زیر را تایپ کنید:
python -m http.server PORT
به جای PORT باید پورت مورد نظر خود برای اجرای سرور را وارد کنید.
اصول اولیه کار با siege:
برای شروع کار دستورات زیر را در شل اجرا کنید:
siege URL
به جای URL باید آدرس مورد نظر جایگزین شود. در این صورت تست با پارامتر های پیشفرض انجام می شود. برای اتمام تست از کلید های ترکیبی CTRL+C استفاده کنید.
اولین تست:
فرض کنید سرور را بر روی پورت 8888 اجرا کردهایم. حال با استفاده از siege سرور را تست میکنیم.
siege -c 1 -r 1 http://localhost:8888/
خروجی به صورت زیر است:
** SIEGE 4.0.4
** Preparing 1 concurrent users for battle.
The server is now under siege...
Transactions: 1 hits
Availability: 100.00 %
Elapsed time: 0.00 secs
Data transferred: 0.00 MB
Response time: 0.00 secs
Transaction rate: 0.00 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.00
Successful transactions: 1
Failed transactions: 0
Longest transaction: 0.00
Shortest transaction: 0.00
آرگومان r-
تعداد تکرار تست را تعیین میکند. آرگومان c-
تعداد کاربران شبیهسازی شده را مشخص میکند. پس تعداد درخواستهای فرستاده شده به سمت سرور برابر ضرب مقدار این دو آرگومان خواهد شد.
تحلیل خروجی تست:
Transaction: برای هر کلاینت از طرف سرور یک سوکت باز می شود، درخواست مدیریت می شود، پاسخ برگشت داده میشود و درنهایت سوکت بسته می شود. این ها کارهایی است که در یک تراکنش انجام می شود. این مورد تعداد درخواستهای فرستاده شده به سمت سرور را مشخص میکند.
Availability: درصد درخواستهایی است که با موفقیت توسط سرور مدیریت شده اند.
Elapsed time: زمان انجام تست است.
Data transferred: مجموع دادههایی است که از طرف سرور به هر کاربر شبیه سازی شده ارسال شده است.
Response time: میانگین زمانی برای پاسخ به درخواست یک کاربر شبیه سازی شده است.
Transaction rate: میانگین تعداد تراکنش هایی است که سرور میتواند در یک ثانیه مدیریت کند(Transaction / Elapsed time)
Throughput: میانگین تعداد بایت هایی است که در هر ثانیه از سرور به تمام کاربران شبیه سازی شده انتقال می یابد.
Concurrency: حاصل تقسیم تعداد کل تراکنش ها به زمان کل سپری شده است(Transaction/ Elapsed time ).هر چه این عدد بزرگتر باشد،کارایی سرور کمتر است.
Successful transactions: تعداد دفعاتی که کد پاسخ(response code)برگشت داده شده از طرف سرور کوچک تر از 400 است.(تراکنش با موفقیت انجام شده باشد)
Failed transactions: تعداد دفعاتی که کد پاسخ برگشت داده شده از طرف سرور بزرگتر یا مساوی 400 باشد به علاوه تراکنش هایی که اصطلاحاً timeout می شوند.
Longest transaction: بیشترین زمانی که یک تراکنش طول کشیده است.
Shortest transaction: کمترین زمانی که یک تراکنش طول کشیده است.
سوئیچهای siege
در این قسمت سوئیچ های ابزار siege را مورد بررسی قرار خواهیم داد. با سوئیچ h- هلپ ابزار نمایش داده می شود.
siege -h
خروجی به صورت زیر خواهد بود:
Usage: siege [options]
siege [options] URL
siege -g URL
Options:
-V, --version VERSION, prints the version number.
-h, --help HELP, prints this section.
-C, --config CONFIGURATION, show the current config.
-v, --verbose VERBOSE, prints notification to screen.
-q, --quiet QUIET turns verbose off and suppresses output.
-g, --get GET, pull down HTTP headers and display the
transaction. Great for application debugging.
-p, --print PRINT, like GET only it prints the entire page.
-c, --concurrent=NUM CONCURRENT users, default is 10
-r, --reps=NUM REPS, number of times to run the test.
-t, --time=NUMm TIMED testing where "m" is modifier S, M, or H
ex: --time=1H, one hour test.
-d, --delay=NUM Time DELAY, random delay before each requst
-b, --benchmark BENCHMARK: no delays between requests.
-i, --internet INTERNET user simulation, hits URLs randomly.
-f, --file=FILE FILE, select a specific URLS FILE.
-R, --rc=FILE RC, specify an siegerc file
-l, --log[=FILE] LOG to FILE. If FILE is not specified, the
default is used: /var/log/siege.log
-m, --mark="text" MARK, mark the log file with a string.
between .001 and NUM. (NOT COUNTED IN STATS)
-H, --header="text" Add a header to request (can be many)
-A, --user-agent="text" Sets User-Agent in request
-T, --content-type="text" Sets Content-Type in request
--no-parser NO PARSER, turn off the HTML page parser
--no-follow NO FOLLOW, do not follow HTTP redirects
Copyright (C) 2017 by Jeffrey Fulmer, et al.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
اولین سوئیچ V- است. اگر ابزار با این سوئیچ اجرا شود، ورژن ابزار و کپی رایت مربوط به آن نمایش داده می شود.
siege -V
خروجی به صورت زیر خواهد بود:
SIEGE 4.0.4
Copyright (C) 2017 by Jeffrey Fulmer, et al.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.
سوئیچ بعدی C- است. این سوئیچ تنظیماتی را که ابزار با آن اجرا می شود را نمایش می دهد.
siege -C
خروجی به صورت زیر خواهد بود:
CURRENT SIEGE CONFIGURATION
Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4
Edit the resource file to change the settings.
----------------------------------------------
version: 4.0.4
verbose: false
color: true
quiet: false
debug: false
protocol: HTTP/1.1
HTML parser: enabled
get method: HEAD
connection: close
concurrent users: 25
time to run: n/a
repetitions: n/a
socket timeout: 30
cache enabled: false
accept-encoding: gzip, deflate
delay: 0.000 sec
internet simulation: false
benchmark mode: false
failures until abort: 1024
named URL: none
URLs file: /etc/siege/urls.txt
thread limit: 255
logging: false
log file: /var/log/log/siege.log
resource file: /home/reganto/.siege/siege.conf
timestamped output: false
comma separated output: false
allow redirects: true
allow zero byte data: true
allow chunked encoding: true
upload unique files: true
no-follow:
- ad.doubleclick.net
- pagead2.googlesyndication.com
- ads.pubsqrd.com
- ib.adnxs.com
سوئیچ بعدی v- است. اگر ابزار با این سوئیچ اجرا شود،ابزار اصطلاحا verbose خواهد بود. دراین حالت تمام اکشن هایی که توسط ابزار انجام می شود،در صفحه نمایش نشان داده می شود. تست سوئیچ v- را با یک کاربر شبیه سازی شده و به مدت ۵ ثانیه بر روی گوگل انجام می دهیم .
siege -c 1 -t 5S -v https://google.com/
با آرگومان t- میتوان زمان انجام تست را تعیین کرد. (S برای ثانیه، M برای دقیقه , H برای ساعت)
حتما متوجه شدهاید که از این ابزار برای حملات DOS نیز میتوان استفاده کرد پس زمان تست را افزایش ندهید.
خروجی:
** SIEGE 4.0.4
** Preparing 1 concurrent users for battle.
The server is now under siege...
HTTP/1.1 301 1.26 secs: 220 bytes ==> GET /
HTTP/1.1 200 1.11 secs: 16557 bytes ==> GET /
HTTP/1.1 200 0.65 secs: 5482 bytes ==> GET /images/branding/googlelogo/1x/googlelogo_white_background_color_272x92dp.png
HTTP/1.1 301 0.88 secs: 220 bytes ==> GET /
Lifting the server siege...
Transactions: 3 hits
Availability: 100.00 %
Elapsed time: 4.64 secs
Data transferred: 0.02 MB
Response time: 1.30 secs
Transaction rate: 0.65 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 0.84
Successful transactions: 4
Failed transactions: 0
Longest transaction: 1.26
Shortest transaction: 0.65
همانطور که میبینید خروجی به صورت verbose نمایش داده شده است.
سوئیچ بعدی q- است. این سوئیچ مخالف سوئیچ قبلی است. اگر تست با این سوئیچ انجام شود،هیچگونه خروجی ای در صفحه نمایش ظاهر نمی شود(پیام اتمام فرایند تست در خروجی نمایش داده می شود)
siege -c 1 -t 5S -q https://google.com/
خروجی به صورت زیر خواهد بود:
Lifting the server siege...
سوئیچ بعدی g- است. اگر تست با این سوئیچ اجرا شود، Request Headers و Response Headers به همراه خروجی تست نمایش داده می شوند.
siege -c 1 -r 1 -g https://google.com/
خروجی به صورت زیر خواهد بود:
HEAD / HTTP/1.0
Host: google.com
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4
Connection: close
HTTP/1.0 301 Moved Permanently
Location: https://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Wed, 18 May 2022 13:58:15 GMT
Expires: Fri, 17 Jun 2022 13:58:15 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 220
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
GET / HTTP/1.0
Host: www.google.com
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4
Connection: close
HTTP/1.0 200 OK
Date: Wed, 18 May 2022 13:58:15 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Content-Encoding: gzip
Server: gws
Content-Length: 16549
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2022-05-18-13; expires=Fri, 17-Jun-2022 13:58:15 GMT; path=/; domain=.google.com; Secure
Set-Cookie: AEC=AakniGMdinGLKkNMlyftRpRAM4cMUqgUrRD_RwKDoO-zjrnh86-IVfvrZQ; expires=Mon, 14-Nov-2022 13:58:15 GMT; path=/; domain=.google.com; Secure; HttpOnly; SameSite=lax
Set-Cookie: NID=511=iOqxShyPFsdByVNu1VRRvSkoaMtVo7rmFosEnMXXiNjV0csTcZMZasN5Ci61UHRngT75Id5lhl_XAwahXXfn9vaSnFExBF9WQDdd6V7u5jFL8uMPdjwdc4ztHk8PdERarunLE4kMNzc5ZprheXKLpTHw0xk_l8HGhmi86Exur8s; expires=Thu, 17-Nov-2022 13:58:15 GMT; path=/; domain=.google.com; HttpOnly
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
GET /images/branding/googlelogo/1x/googlelogo_white_background_color_272x92dp.png HTTP/1.0
Host: www.google.com
Cookie: 1P_JAR=2022-05-18-13;AEC=AakniGMdinGLKkNMlyftRpRAM4cMUqgUrRD_RwKDoO-zjrnh86-IVfvrZQ;NID=511=iOqxShyPFsdByVNu1VRRvSkoaMtVo7rmFosEnMXXiNjV0csTcZMZasN5Ci61UHRngT75Id5lhl_XAwahXXfn9vaSnFExBF9WQDdd6V7u5jFL8uMPdjwdc4ztHk8PdERarunLE4kMNzc5ZprheXKLpTHw0xk_l8HGhmi86Exur8s
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4
Connection: close
HTTP/1.0 200 OK
Accept-Ranges: bytes
Content-Type: image/png
Cross-Origin-Resource-Policy: cross-origin
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="static-on-bigtable"
Report-To: {"group":"static-on-bigtable","max_age":2592000,"endpoints":[{"url":"https://csp.withgoogle.com/csp/report-to/static-on-bigtable"}]}
Content-Length: 5482
Date: Wed, 18 May 2022 13:58:16 GMT
Expires: Wed, 18 May 2022 13:58:16 GMT
Cache-Control: private, max-age=31536000
Last-Modified: Tue, 22 Oct 2019 18:30:00 GMT
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 0
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Transactions: 3 hits
Availability: 100.00 %
Elapsed time: 3.83 secs
Data transferred: 0.02 MB
Response time: 1.28 secs
Transaction rate: 0.78 trans/sec
Throughput: 0.01 MB/sec
Concurrency: 1.00
Successful transactions: 3
Failed transactions: 0
Longest transaction: 2.37
Shortest transaction: 0.70
همانطور که میبینید هدرهای درخواستها و پاسخها نیز در خروجی تست وجود دارند.
سوئیچ بعدی p- است. این سوئیچ همان کار سوئیچ قبلی را انجام می دهد و علاوه بر آن محتوای html ی صفحه را نیز بر میگرداند.
siege -p -v https://google.com/
سوئیچ c- تعداد کاربران شبیه سازی شده را تعیین می کند. siege به صورت پیشفرض ۱۰ کاربر شبیهسازی شده را برای تست فراهم میکند.
مثال: تست با سه کاربر شبیهسازی شده:
siege -c 3 -v https://google.com/
سوئیچ r- نشاندهنده تعداد تکرار درخواستهای ارسالی است.
مثال: تست با یک کاربر شبیهسازی شده و با تعداد تکرار ۲:
siege -c 1 -r 2 -v https://google.com/
سوئیچ بعدی t- ، زمان انجام تست را مشخص می کند.
مثال: تست برای دو کاربر همزمان شبیهسازی شده و به مدت ۱۰ ثانیه:
siege -c 2 -t 10S -v https://google.com/
برای مشخص کردن زمان انجام تست از سه فلگ S برای ثانیه، M برای دقیقه و H برای ساعت استفاده میشود.
سوئیچ بعدی d- است که برای ایجاد یک تاخیر رندوم بین درخواست ها استفاده میشود البته می توانیم میزان تاخیر بین درخواست ها را نیز تعیین کنیم.
مثال:این تست برای ۲ کاربر همزمان شبیه سازی شده اجرا میشود هر کاربر ۳ بار درخواست را تکرار می کند و بین درخواست ها تاخیر یک ثانیه ای وجود دارد.
siege -c 2 -r 3 -d 1S -v https://google.com/
سوئیچ بعدی کاری مخالف سوئیچ تاخیر انجام میدهد. اگر ابزار با سوئیج b- اجرا شود، هیچ تاخیری بین درخواست ها اتفاق نمیافتد و درخواست ها پشت سر هم به سرور ارسال میشوند. این سوئیچ برای بنچمارک گیری استفاده میشود.
مثال: این تست برای دوکاربر همزمان شبیه سازی شده و با تعداد تکرار پنج انجام میشود. درضمن تاخیری بین درخواست ها وجود ندارد.
siege -c 2 -r 5 -b -v https://google.com/
سوئیچ بعدی i- که برای شبیه سازی یک کاربر معمولی استفاده میشود. هر کاربری که وارد یک سایت میشود با توجه به نیاز و علاقه مندی خود ممکن است بر روی لینک های مختلفی کلیک کند. سوئیچ i- این رفتار کاربران را شبیه سازی می کند. پس وقتی که تست با این سوئیچ انجام شود، آدرس های مختلفی به صورت رندوم تست می شوند.
مثال: این تست برای دو کاربر همزمان و با تعداد تکرار یک و با شبیه سازی رفتار کاربران انجام میشود.
siege -c 2 -r 1 -i -v https://google.com/
سوئیچ بعدی f- است. این سوئیچ برای تعیین مسیر فایلی که حاوی آدرس های مورد تست است، استفاده میشود. اگر فایلی با نام test.txt و محتوی دو آدرس به صورت زیر داشته باشیم،
https://reganto.github.com/
https://google.com/
در آن صورت تست به صورت زیر انجام میشود.
siege -c 2 -t 10S -v -f test.txt
تست برای دوکاربر شبیه سازی شده و در طی ۱۰ ثانیه بر روی دو آدرس موجود در فایل انجام میشود. سوئیچ بعدی R- است. این سوئیچ برای معرفی یک siegerc فایل به ابزار استفاده میشود. اینگونه فایل ها دقیقا مشابه فایل bashrc هستند و با اجرای ابزار، تنظیماتی را بر روی آن ابزار اعمال می کند. فایل siegerc پیش فرض در مسیر etc/siege/siegerc/ قرار دارد. می تونید این فایل را با یک ادیتور باز کنید و تنظیمات را تغییر دهید.(راهنمای هر دستور به صورت کامنت شده در فایل siegerc وجود دارد.) سوئیچ بعدی l- است. این سوئیچ برای معرفی یک لاگ فایل به ابزار استفاده میشود تا ابزار لاگهای خود را در آن ثبت کند. اگر فایلی تعیین نشود، لاگ ها به طور پیش فرش در var/log/siege.log/قرار می گیرند. برای معرفی یک لاگ فایل از آپشن لانگ یعنی log-- نیز میتوان استفاده کرد. به مثال زیر توجه کنید:
siege -c 2 -t 5S -v --log=siege.log https://google.com/
تنظیمات کلی ابزار در مسیر siege/siege.conf./~ قرار دارد. سوئیچ بعدی m- و نوع لانگ آن mark-- است. این سوئیچ برای نشانهگذاری در لاگ فایل استفاده میشود و لاگ های مربوط به هر کاربر را با یک رشته از هم جدا می کند. شاید یک مثال به روشن شدن موضوع کمک کند. یک سرور آزمایشی ایجاد میکنم:
python -m http.server 8001 --bind=127.0.0.1
البته می توانید تست را بر روی هر سرور دیگری نیز انجام دهید.
siege -c 2 -t 5S -v --log=siege.log --mark="aaaaa" http://localhost:8001/
بعد از انجام تست، لاگ فایل را باز کنید.
Date & Time, Trans, Elap Time, Data Trans, Resp Time, Trans Rate, Throughput, Concurrent, OKAY, Failed
2022-05-21 00:11:32, 7, 2.78, 0, 0.40, 2.52, 0.00, 1.00, 7, 0
**** aaaaa ****
2022-05-21 00:35:48, 1352, 4.40, 3, 0.01, 307.27, 0.68, 1.97, 1352, 0
همانطور که می بینید لاگ های مربوط به تست های مربوط به کاربران شبیهسازی مختلف با aaaaa از هم جدا شده اند. پس سوئیچ mark-- نقش یک delimiter«حائل» رو برای لاگ های مربوط به کاربران شبیهسازیشده مختلف در لاگ فایل ایفا میکند.
سوئیچ بعدی H- و لانگ آن یعنی header-- است. این سوئیچ برای اضافه کردن یک هدر به درخواست استفاده میشود.
siege -c 1 -t 5S -v --header="cache-control: no-cache" http://localhost:8001/
لیستی از هدرهای HTTP را میتوانید اینجا بیابید. با سوئیچ A- یا شکل لانگ آن user-agent-- می توان agent در خواست دهنده را مشخص کرد. برای مشاهدهی لیستی از agentهای معروف میتوانید به این لینک مراجعه بفرمایید.
siege -c 1 -r 1 -v -A="curl/7.68.0" http://localhost:8001/
اگر agent تعیین نشود، Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4 به صورت پیش فرض به عنوان agent ارسال می شود. یکی دیگر از هدرهایی که نوع مدیای درون بدنه درخواست را تعیین می کند، هدرcontent-type است. ابزار Siege برای این هدر یک سوئیچ مجزا با نام T- یا content-type-- در نظر گرفته است. تست باید با سوئیچ g- انجام شود تا هدر درخواست و هدر پاسخ قابل مشاهده باشد.
siege -c 1 -t 5S -g -v --header="content-type:application/json" http://localhost:8001/
خروجی تست :
HEAD / HTTP/1.0
Host: localhost:8001
Accept: /
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (pc-x86_64-linux-gnu) Siege/4.0.4
content-type: application/json
Connection: close
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.6.8
Date: Wed, 10 Jul 2019 16:34:29 GMT
Content-type: text/html; charset=utf-8
Content-Length: 418
Siege برای حملات DOS
ابزار siege برای حملات DOS نیز استفاده میشود. و اگر این حملات به صورت توزیع شده باشد، حمله اصطلاحا DDOS خواهد بود. برای جلوگیری از متهم شدن به حمله DOS تمام تست های این بخش بر روی سرور محلی انجام میشود. مانند مثال های قبل سرور محلی را با دستور زیر ایجاد می کنیم.
python -m http.server 8001 --bind=127.0.0.1
پس از اجرای سرور، تست را انجام می دهیم.
siege -c 255 -r 10 -v -b http://localhost:8001/
سوئیچ b- تاخیر بین درخواست ها را از بین میبرد و از این طریق حمله موثرتر انجام خواهد شد! البته به صورت پیش فرض تعداد کاربران شبیه سازی شدهی محدودی را می توانید استفاده کنید. این محدودیت را می تونید با باز کردن فایل کانفیگ siege یا فایل siegerc ببینید.(محدودیت در متغیر limit اعمال شده است) این نکته را هم باید مد نظر داشته باشید که سیستم برای هر درخواست کاربر شبیه سازی شده یک سوکت باز می کند.برای موثر بودن حمله مقدار سوئیچهای t- یا r- را تا حد معقولی افزایش دهید. برای جلوگیری از حملات DOS چندین راه مختلف وجود دارد.
استفاده از Siege برای ارسال دیتای POST
از این قابلیت برای تست API ها استفاده میشود ولی با وجود ابزارهای قدرتمندی مانند Postman یا cURL شاید از استفاده از Siege چندان عاقلانه به نظر نرسد.در هر حال این قابلیت در siege وجود دارد. برای ارسال دیتای پست با Siege به صورت زیر عمل می کنیم:
siege -c 1 -r 1 -v 'http://sample.com/ POST foo=bar&baz=bash'
این دستور با یک کاربر شبیه سازی شده و تعداد تکرار یک، به آدرس فرضی sample.com دیتاهای foo=bar و baz=bash را ارسال می کند.
مروری بر مهمترین کانفیگهای Siege
همانطور که قبلا اشاره شد کانفیگ ابزار در مسیر etc/siege/siegerc/
قرار دارد. البته یک کپی از تنظیمات نیز در مسیر siege/siege.cong./~
وجود دارد. توضیحات مربوط به هر کانفیگ در قسمت بالای آن کانفیگ به صورت کامنتشده قرار دارد در این قسمت چند کانفیگ مهم را مرور خواهیم کرد.
دربارهی log در ابزار قبلا توضیح دادیم. logfile
مسیر لاگهای ابزار را مشخص میکند. verbose
همان سوئیچ v- است. color
برای نمایش خروجی به صورت رنگی استفاده میشود و مقادیر آن به صورت on/off میباشد. quiet
همان سوئیچ q- است. قبلا ذکر شد که اگر ابزار با سوئیچ g- اجرا شود، هدر درخواست و پاسخ نمایش داده میشود. تنظیم gmethod
متدی را که ابزار در حالتی که با سوئیچ g- اجرا میشود را تعیین می کند. مقادیر این تنظیم GET/HEAD هستند. با متد HEAD فقط هدر درخواست و پاسخ نمایش داده میشود اما با متد GET تمام صفحهای که درخواست به آن ارسال میشود، برگشت داده میشود و این دقیقا همان کاری است که سوئیچ p- انجام میدهد. وقتی که درخواستی به یک سرور ارسال میشوداگر آپشن v- استفاده شده باشد، لاگ های ابزار در خروجی قرار می گیرند همچنین آدرسهایی که تست میشوند به صورت خلاصه شده در لاگ خروجی قرار می گیرند. با fullurl
می توانیم خروجی لاگها را به صورت کامل نمایش دهیم. مقادیر این تنظیم به صورت true/false است. protocol
پروتکل درخواست را مشخص می کند مقادیر آن می تواند HTTP/1.0 یا HTTP/1.1 باشد. در مورد HTTP/2.0 در مستندات اشارهای نشده است. concurrent
مشابه سوئیچ c- است. برای بعضی از تنظیمات، سوئیچهای متناظری نیز در نظر گرفته شده است. تنظیمهای time
و reps
و file
و dely
و internet
و benchmark
و سوئیچهای t- و r- و f- و d- و i- و b- متناظر هستند.