Изпечатай

[abadon]

Здравейте,

Има ли начин как да измеря латенцията на специфична услуга. Примерно имам сървър на които работи услуга на някакъв порт, като всичкия друг трафик до този сървър е забранен.

Ако пробвам с telnet така:

Abadon:~$ telnet 194.8.15.167 10443
Trying 194.8.15.167...
Connected to 194.8.15.167.
Escape character is '^]'.
quit
PConnection closed by foreign host.
Abadon:~$

се закачам без проблеми. Обаче как да измеря каква ми е реалната латенция?

Пробвах така:

httping -g http://194.8.15.167:10443

или така

httping -g https://194.8.15.167:10443

Обаче не става нищо.

Идеята ми е да разбера какво е реалното време за което услугата ми отговаря, тъй като ping-а дори и да е пуснат не е точен метод за измерване на подобна латенция.

[BRADATA]

man time

hint:
time wget http://www.linux-bg.org

[abadon]

Това с wget е идейно, макар че не мисля, че измерва напълно адекватно. Тествах към няколко сървъра и към единия дава това:

time wget http://194.8.15.167:10443
--2015-09-29 15:50:26--  http://194.8.15.167:10443/
Свързване към 194.8.15.167:10443... успешно свързване.
HTTP изпратено искане, чакам отговор... 200 No headers, assuming HTTP/0.9
Дължина: неопределен
Saving to: ‘index.html.2’

index.html.2                                     [ <=>                                                                                          ]       7  --.-KB/s   in 0s     

2015-09-29 15:50:26 (602 KB/s) - ‘index.html.2’ запазен [7]


real    0m0.404s
user    0m0.000s
sys     0m0.004s

а към друг въобще не може да се свърже:

time wget http://95.138.142.172:443
--2015-09-29 15:51:16--  http://95.138.142.172:443/
Свързване към 95.138.142.172:443... успешно свързване.
HTTP изпратено искане, чакам отговор... Грешка при четене (Едностранно прекъсване на връзката от отсрещната страна) в заглавките.
Продължавам.

--2015-09-29 15:51:17--  (опит: 2)  http://95.138.142.172:443/
Свързване към 95.138.142.172:443... успешно свързване.
HTTP изпратено искане, чакам отговор... Грешка при четене (Едностранно прекъсване на връзката от отсрещната страна) в заглавките.
Продължавам.

^C

real    0m2.274s
user    0m0.005s
sys     0m0.000s

А аз имам telnet и към двата.

Също така сравних резултата от time wget към стандартен web сървър с резултата към същия уеб сървър но измерен с httping и разликата във времената е 3-4 пъти.

Също така може би е добра идея да споделя, че услугите които тествам не са уеб сървъри официално, макар че имам съмнение че работят по подобен на web начин.

[k0tka]

Опитай с cURL: https://josephscott.org/archives/2011/10/timing-details-with-curl/

[BRADATA]

Единствения коректен начин е да имаш сорса на официален клиент на тази услуга, да го редактираш да маркира timestamp когато стартира и когато спре и да направи просто изваждане на двете числа. Всичко друго е спекулация

[daniel_vulchev]

абе и на ръка може горе доло да сметнеш в логовете ако може да се запише нещо време на заявка за сесията към телнет и времето са свързване да се види минус времето за което пътува сигнала до машината 

[abadon]

Единствения коректен начин е да имаш сорса на официален клиент на тази услуга, да го редактираш да маркира timestamp когато стартира и когато спре и да направи просто изваждане на двете числа. Всичко друго е спекулация

Съгласен съм с теб, но за съжаление нямам source-а на клиента, тъй като той е със затворен код

Намерих някакво приложение tcpping

Като ping-вам с него въпросните сървъри на определен порт ми връща резултати, но дали са коректни?

[gat3way]

Няма как да се отговори на този въпрос, защото не е много ясно какво имаш предвид "латентност".

В общи линии, времето изминало за обслужването на заявката (response time) включва латентността (latency) и времето за обслужване от страна на сървъра (processing time). От прочетеното, имам усещането че те интересува времето за обслужване на заявката, а не латентността. Между тези две неща има огромна разлика, защото играят съвсем различни фактори и съответно начините да ги измериш са доста различни.

Например ако искаш да изгледаш един филм, можеш да го свалиш през бавна dialup връзка, можеш да пратиш и пощенски гълъб и да ти го върнат по пощенски гълъб под формата на флаш памет, привързана към него. Да предположим че разстоянието и останалите неща са подбрани така че свалянето на няколко гигабайта през бавния dialup отнема точно толкова време, колкото да прелетят гълъбите с флашките, да речем общо 10 дни. Крайното време докато ти се достави филма (response time-а) е едно и също - 10 дни. Латентността е безкрайно различна - при dialup връзката е в порядъка на милисекунди до секунди, при варианта с гълъбите е няколко дни - докато гълъба прелети разстоянието.

Нещата не са много съпоставими разбира се, защото през dialup връзката използваш IP протокола и филмът е "опакован" в милиони IP пакети, а максималния капацитет на връзката е ограничен - в случаят с гълъбите нямаш ограничение на максималния капацитет, целият филм се праща наведнъж.

Сега представи си че изменяме сценария - от същото място искаме субтитри за филма, които са само няколко килобайта. С модема ги източваме за секунди. С гълъбите отнема.....отново 10 дни. Та максималният капацитет на връзката при варианта с гълъбите може да е неограничен, но виждаме как това в случая не е особено голямо предимство.


Абсолютно същото е и примерно със заявките към уеб сървърите. Има мрежова латентност - тя зависи от връзката ти, от рутерите по пътя - брой/натоварване, от преносната среда и т.н. Това време варира, но за удобство можем да приемем че е относително константно. Това време лесно можем да измерим просто с ping (макар че това може да е лъжливо ако има някъде приоритизация на трафици). Има и време за което уеб сървъра обслужва заявката - това варира ужасно много в зависимост от самата заявка, натоварването на сървъра и 500 други фактора. То се измерва по-сложно и обикновено резултатите се усредняват, а обектите, които се достъпват се подбират така че да покриват определени сценарии. Вариант да се мери това е httperf примерно.

[abadon]

gat3way след твойте обяснения вече ми стана по ясно, че не съм си формулирал въпроса правилно. Точно така искам да измеря response time-а

httperf го мери по-правилно сравнение с всички тулове които тествах до момента.

След твойте разяснения пуснах wireshark за да видя какви пакети минават и какво точно се случва.

tcpping и curlt

Мерят времето от изпращане на SYN до получаване на SYN, ACK

При httperf се мери времето от изпращане на SYN до получаване на RST на кънекцията от сървъра.

Това пак не е най-точния response time, тъй като пакетите на httperf не мога да кажа дали пораждат същата обработка (най-вероятно не), като пакетите на оригиналния клиент, но все пак са някаква интеракция на по-висок level от tcp/ip стека.

По-точно от това едва ли има накъде с general tools. От тук нататък специлизиран софтуер за конкретния сървис.

[gat3way]

Строго погледнато, латентността е два пъти по-ниска, времето за SYN пакета и SYNACK отговора включва два пъти мрежовата латентност. Това което вадят ping, tcping и подобни e RTT (round-trip time), латентността е грубо RTT/2.

Response time-а по дефиниция не включва времето за обработване на резултата от страна на клиента (примерно визуализирането на документа от браузъра). Ако трябва да се включи и това като фактор, сметките ще станат ужасно сложни.

Между другото, латентността далеч не е толкова константна, тя си варира във времето и ако наистина искаш да имаш по-добра идея, най-добре направи много замервания и ги усредни. Самият TCP протокол апропо прави нещо подобно, TCP стека на практика пази усреднена RTT стойност, която съответно играе после в сметките които си прави за разни таймаути за ретрансмитване на пакети, в случай че не е получено потвърждение, така TCP връзката донякъде се "нагажда" динамично спрямо латентността на мрежата.  Понякога латентността може да варира драматично и TCP да не може да насмогне - което обикновено се изразява в гадно деградиране на TCP връзката и странното наблюдение че ако я прекратиш и отвориш нова, скоростта е по-висока...поне за известно време.