TCP Tips and Tricks - SLOW APPLICATIONS? // Wireshark TCP/IP Analysis
Vložit
- čas přidán 11. 06. 2024
- What TCP symptoms can we look for when troubleshooting slow applications? Let's find out!
Like/Share/Subscribe for more Wireshark content!
// WIRESHARK TRAINING - Udemy//
▶Getting Started with Wireshark - bit.ly/udemywireshark
// WIRESHARK TRAINING - Pluralsight//
Check out the free 10-day trial of my hands-on courses on Pluralsight:
▶TCP Fundamentals with Wireshark - www.bit.ly/wiresharktcp
▶Identify Cyber Attacks with Wireshark - www.bit.ly/wiresharkhunt
▶TCP Deep Dive with Wireshark - bit.ly/virtualwireshark
//LIVE TRAINING COURSE//
▶TCP/IP Deep Dive Analysis with Wireshark - bit.ly/virtualwireshark
-------------- Trace File Analysis Services//Private Training ----------------------
Got packet problems that you need help digging into? Want to schedule a private training for your team?
www.packetpioneer.com/contact
Some people really have a knack for distilling difficult topics and teaching them to people...you are one of these people. I love the way you explain things and how you go into visual details. It really helps those of us whom are a bit thick-headed to "get it" finally. THANK YOU!! Hope you keep doing these videos coming as there are so many videos out there, but yours are really thorough and you make extremely difficult subjects much more mentally attainable...it makes the learning much more enjoyable and less of a challenge.
Thank you Hang for the feedback. I'll do my best to keep them coming!
You prolly dont care at all but does any of you know a method to get back into an instagram account?
I somehow forgot my login password. I appreciate any help you can give me
@Jude Gary Instablaster ;)
@Zion Erick I really appreciate your reply. I got to the site thru google and im waiting for the hacking stuff now.
Takes quite some time so I will get back to you later when my account password hopefully is recovered.
@Zion Erick it did the trick and I finally got access to my account again. I am so happy:D
Thank you so much, you saved my ass !
Finally some one who gets it!
I used to spend so much time at one place big on finger-pointing trying to get someone to run a trace. They always wanted to claim it wasn't their issue but no one wanted to prove it wasn't their issue because it might prove it actually was their issue.
People who point fingers don't care about about finding solutions they care about avoiding blame.
This is absolutely the best TCP analysis I've found on You-Tube! Thank you sir!!!
Normally I can't watch such long talks that teach stuff this one kept me hooked
Thanks for the comment - glad you enjoyed it!
Thanks Chris. It was really helpful. Had a great insight into TCP protocol functioning.
Seriously i cant rave enough about how well you explain this! Thank you!
I love your videos, your explanations are as clear as cristal, hope you make more videos about troublshouting and how to read tracefiles and determine the problem source. Thanks Chris.
This helped me understand Wireshark and packet analysis (for TCP, anyway) better than anything else I've read or watched. Many thanks for providing this!
Chris, You are awesome. Your communication style is superb. thanks for the vids.
Chris - this was a revelation to me and helped me analyze some very puzzling captures. Thanks for the excellent presentation and for making it available. Your presentation and explanations are extremely lucid, clear and vivid.
Really Great Lesson. Thank you very much
This is awesome video... Thank you for taking time and presenting us
Great video, keep up the good work!
it's great video to understand the packet and troubleshoot the live network issues.
Thanks for teaching us :) :)
Awesome Video Chris! as always
clearly explained, thanks for the session
thanks Chris. This was a very helpful video.
Excellent video and i like to view your videos more!
Outstanding explanation. This will help me no end . Thank you.
Thank you very much for this video.. Really needed this one..!
this turorial is very helpful, net work analyze is a very difficult and skillful job. very appreciate
excellent video on differentiating network packet drop and application performance. this is often a bone of contention between network and application teams. I took one of my traces from a customer site and used your tutorial to drill down what the issue is.
Amazing info has been shared in this Video.
Great job Chris.
Excellent session.
Awesome video!
Awesome! Thanks chris
So excellent. Thank you!
Thank you, very informative video.
Thanks man... Good tut.
Great video!
You explain very well!
Thanks Chris !
great video!!!
Priyavrat
This is great, thanks
wonderfull video . many thanks
Thanks for commenting!
Thank you. This was an excellent video!
Thanks for watching Philip!
you're doing great job chris
Thanks for taking the time to give positive feedback. I really appreciate it!
Thank you for this very insightful analysis of packet captures!
Happy to help! Stay close to the channel for more content.
Chris.. I have no word to tell you how much amazing you are ! ;) super excellent tutorial :) Thank you very much :)
Thanks for watching Suraj!
I am fan of this guy ❤
thanks for the great explanation.
Glad it was helpful!
Thanks for the video =)
Purchased a Wireshark course on Udemy but it is rather high level. These deep dive videos really compliment that course well. Bravo!
Hi Emir. Was the wireshark course from udemy worth it and what’s the name of the course?
Technology stuff explained in pure conversational language, making us understand the concept underneath and retain for long. Thanks much for creating this wealth of information!
Ram thank you!
Nice explanation --and learn lot of basic troubleshooting on tcp concept
Thanks for the comment Rohith!
This is best TCP packets analysis. Mind blowing video . It's really helpful for me.
Glad it helped you!
Just Love ur videos. Amazing content TQSM
Thanks Harsha! I will keep making them.
This video just earned you a new subscriber 🎉
Great! Welcome to the channel - Kick back, relax, and enjoy the content!
Great stuff ! You are really a reference. One thing I noticed is that students confuse Wireshark's labels: "TCP Out-Of-Order" or "TCP Retransmission" as TCP properties!
These labels are only Wireshark best guesses, not something written in the Packet itself.
Thanks Bruno! I appreciate the comment.
Chris this is the best analysis on packet thanks for this
Thank you! 🙏
Hello Chris - I love to watch and take away from your great video sessions. Question: How we can confirm that, the IP Sec related ports are opened in a remote ISP if we have a host attached to that particular ISP.
Amazing 👌
Chris, funny I am sysadmin and learning a lot from your training, really valuable to also understand when the problems are on our side. i am currently troubleshooting an issue of slowness and retransmission and one thing i noticed is TCP segment len 524 for entries showing that data sent PHS-ACK, is that so small that may be a factor? thanks a lot.
excellent
nice one
thank you
Excellent Explaination of the Transport layer stuff and how it works. It is very usefull to finding out the reason why the network is slow and aslo can provide suggetion to the Developer or the Network Engineer to rectify the issue.
Thanks Mahesh! I appreciate the comment.
At the 1:00 how can we tell it was a single threaded TCP between Client - Server? Multi-thread would have shown the same Source & Destination IP pairs.
Would the indicator be based on different ports used?
Best TCP analysis.
Thanks for the comment Huzaifa!
Hey Chris, thanks for the wonderful video.. I liked it. But, I wasn't quite happy with TCP window full conditions explained. I doubt u covered the zero window conditions.. Also on the window update capture, I could see a syn=1 and ack=1 in middle of the flow at a window update. How could this be possible???
Impressive!
Thanks Malak. I hope it helps!
Hi Chris, could you supply a valid link to download the trace files ? Regards
your Videos/other training material has inspired me to take for exam(WCNA) and I have passed it. I saw this video 3 times for now.. to become good with concepts. Thank you for all your efforts in preparing this video..
Awesome! Congrats on passing the WCNA. That is a huge accomplishment and I am honored to have helped at least in a small way. Keep on learning and capturing.
thanks for the good explanation . I have a question regarding to previous packet has not captured , in that case how I can tell the dropped the packet was sent from the sender or from the server side ? and the one just i received it later it is the retransmit one or the continuation ?
Hello Nanis - Wireshark determines that a packet has been lost by looking at the gap in the sequence numbers. So if you see this warning, it means the previous packet in this direction was lost. So it depends on which direction the traffic is flowing. Also, consider where you are capturing. If you are capturing at the client end, most likely you will see this warning for packets that are coming from the server.
Another possibility is that the packet was lost by the capture method (overprovisioned SPAN, exceeding the capture potential of the laptop or device doing the capture) so be careful when troubleshooting these warnings as they simply may indicate that the capture device simply missed a packet.
You rock!!!
Your courses should be on something where we could buy just a single course. Plural sight is a overkill :) Great video, the shortcuts especially were so helpful!
Nice feedback Patgame - thank you. You could always just join Pluralsight for a month and watch them all for $29! But who knows, maybe i can get some other projects in the bag too.
www.bit.ly/wiresharktcp
@@ChrisGreer Thanks, Chris. You make a point on the monthly sub. Do you cover various congestion avoidance algorithms (read, reno/bic/cubic) and so on in your courses? I cannot seem to ascertain from the list of topics on PluSig
@@patgame Yes! - I have a new course on Pluralsight that will come out in the next few weeks that covers the congestion control mechanism, and looks into CUBIC vs NewReno. It doesn't do a deep dive into each flavor, but it does cover how each one makes a decision of when to go into congestion avoidance and fast recovery. It is called Mastering TCP Analysis with Wireshark
Chris Greer great stuff. Will definitely sign up then. See you there :)
is a : 0.000408000 seconds response time considered fast
where i can get the pcap files used in this demo ?
hey! i think i missed it but did you ever explain what a TCP ACK packet represented? or at least point me to the time you started talking about it? thanks!
ack for acknowledge
supper helpful
Just saw your video, and compared to others out there yours really explained to me how to really use Wire Shark. Thank you.
Thank you but . My understanding at 25:00 is that Wireshark just captures the packets. If they are tcp packet is for dup or missing ....it all coming from client. Wireshark doesn't make requests to server. It simply captures. The size of your laptop you use for your Wireshark will not make dup or missing packets. Maybe I'm wrong but I'm almost sure about this .
Wow :) Beautiful explanation..
I have a doubt regarding Window Full feature of Wireshark. In your capture, the segment from server in which we see "Window Full", that packet has 1460bytes of data. When the server knows that receiver's buffer is full, why is it sending more data? Or, does Window Full mean that receiver's buffer will be full after this segment?
You said that it's common to see Window Full and then some packet loss. Do you mean to see that server/host will burst traffic up to Window size and 'packets from this burst' may be dropped by network? Can you also confirm that it's not necessary that every time we see Window Full network will drop packets?
Could you please explain more about this?
Thank you very much :)
Yes - I have the exact same question. The explanation for Window-Full was a bit unclear in the lecture. He mentioned that Server has sent so much data to Client that the Window Size has become Full. Whose Window Size? Also, why is the Server sending more data when the Window Size limits are clearly mentioned in the TCP Conversation?
Thanks Chris. I have a doubt about TCP OUT of order packets . what is that for?
Out of orders mean that a packet arrived out of sequence. It can happen because a packet takes a different path than others behind it and it took longer to arrive, or more often, Wireshark can perceive retransmissions as arriving out of order. Great idea for a video!
Hey, i recently (lost the actual icident) had a complaint , and it really happened, on l2 segment one server was scp ing a file from other server. They were connected to same switch !!no hw issues. I saw about a half packets coming as normal, and then the receiver of file (initiated the conn) started getting dupe acks. What happens is transfer stalls at zero, but the receiver working properly, acked all seq in time , but sender's packets were missing,so rcvr sent ack for retrans. Btw, sacks and scaling were off..so i just saw delays from sender of file getting double time delay (every time double until 120 sec). What can that be guys, really curious, not a champ at wireshark yet :( crazy stuff
Only captured on source the receiver which is src, though. Might be just performance rlated on other end. Hard to tell, cuz im network guy, and they say server is green...
Chris I am starting a job soon and will be using wireshark for first time. Where is the best place to learn for beginners? Books, videos, etc...
Hey Shawn - that's great! Welcome to the world of Wireshark. For sure check out the videos here on my channel for tips and tricks. For some more in-depth, personalized training, let me know if you are interested in a class. For books, check out Practical Packet Analysis by Chris Sanders. Awesome read. Hope this helps!
can't thank enough
Hi Chris. Trying to wrap my head around the TTL part of the video... I have two devices on the same subnet 10.106.63. And the trace is telling me that .48 which is the client has a TTL of 255 but when looking at an ACK of the packet the server part which is .11 its telling me a TTL of 128. Now one device is connected over wifi and the other over a cable... there is a VLAN setup with devices in between that I have no view of... my question is... isn't the client supposed to decrement the 255 value to at least 254 if there is one hop? There is only one set of ports open and I am monitoring on the server side. Thank for your help.
Hello Malcolm - if the two devices are on the same subnet and packets do not need to be routed then the TTL will not be decremented between the two. Traffic in both directions will stay at 255 and 128 respectively. A Wifi access point and an ethernet switch are not routers, generally speaking, so they will not decrement the TTL. Hope this helps!
@@ChrisGreer Yes this helps tremendously. So with with network equipment not behaving as routers in the general sense, it also implies that windowing will not be modified between the 2 devices and that window size is purely between the endpoints?
When a network capture is analyzed using Wireshark, 39% of the total traffic is RST packets. What could be the reason?
The connection is trying to connect to a TCP port and the port is not open
The connection is trying to connect to a UDP port and the port is not open
The 3 way handshake is unsuccessful and there are multiple retransmissions and failures
The TCP port at the source is a wrong port
Please give me answer in above 4 option
I have some issues running which is having a slowness while accessing the citrix application not able to figure out where the problem is, could you please help
Sure - I'd be happy to. Please send me a contact request through www.packetpioneer.com/contact
Thanks!
Hi Chris, Just one question. If we increase the bandwidth of a dedicate link, the Windows Size initial negotiation could increase?
Not necessarily. The window size is set by the operating system kernel, or by the application using that kernel. So it is independent of the network. Increasing the bandwidth may cause the TCP stack to dynamically increase the window size over time as more data moves, however that would be determined by the OS.
@@ChrisGreer I have an issue that after I change the network layer from IP MPLS network to a WDM OTN network using the same servers and with the same link capacity. The windows scaling increase drastically, having transfer rates from 4 MB/s up to 90 MB/s. This is why my question. The only difference is the iRTT time. With a 20ms difference between the two network layers. WDM OTN shows the best performance. I'm trying to find how to explain or justify this behavior. What else would you consider to check?
hey Chris, i have a strange packet behavior that repeats again and again. An app sends some data to my client , then retransmission of this packet goes for some reason and then my client ack. after this i get an unusual several seconds delay (between client ack and sending start) and client start sending data to server. This situation repeats again and again. What problem should i look for? You told about such situations on server side but what is it when delay is on client side ? By the way your courses on PluralS are great, enjoying every of it, thank you! )
Hey! Can you share the pcap? If so… pop it over to me… packetpioneer@gmail.com
@@ChrisGreer thank you very much ) sure ill send it
More often the Reps on the other end says 'The system is slow today' not necessarily blaming the network.
In this video the details of creating a button for "Slow HTTP" has a mistake: if we enter "http.time > 1", it creates an error condition for an inappropriate argument and my Wireshark panel goes out of control. I had to go to the process manager and kill the Wireshark process. After doing that and restarting Wireshark, I needed to correct the button filter to read: "http.time > 1.0" because http.time is a floating point number and not an integer which the first filter spec was looking for. That's my two cents.
Hmm interesting. Literally never seen that one. What version of WS are you running?
37:03 Please try to avoid pauses like this. For a moment I thought that my computer had frozen.
I realize that this is an old video, but I would like to comment on how well I could read things. There were times when I could not read a line in the top pane because the colors of the background and the text clashed.
where can I find the PCAP file for this tutorial ?
Hello Hamzeh, here is a link to one of them -
www.cloudshark.org/captures/b28b2cfec7ea
I do share the trace file for several of my videos but I didn't do so for all the traces on this one. Thanks!
@chris please provide these captures please
I don’t provide the pcaps on this one. Some of them are long gone…
Not clear about previous segment not captured
Hi,
Could you please suggest how to identify unicast storm. Not able to find any video
DRSInfocom Online firewall training sure, that is a great idea for a video. I will be in my studio soon recording some new content!
@@ChrisGreer thanks a lot Chris. The way you teach is awesome. That's the reason for request. 😊
22:30
I worked at two call centers and I can tell you factually that they *do not* want you to admit that anything is wrong with their systems or computers it's the "other network/s" they're trying to connect to that is slow. They basically wanted us to say "Our network our servers our computers are fine It's the other end that is slow"
And depending on your coach they'll have an excuse for everything
credit cards taking too long? must be a lot of people buying right now. Man Mastercard servers are busy today.
@@sleekthegeek6669 Wow really? I guess it doesn't surprise me. Thanks for the comment.
blaming the network has been a thing since the 90s. The vendor blame game is popular, too.
See 19:00-23:30
B 29:15
System Administrations get bashed by management and users when the problem lies with developers and network administrator.
8:48 I heard "..it will show us Tupacs" .... I was quite confused
:-) Funny!
@@ChrisGreer By the way, excellent video! I'm not an IT professional, only an enthusiast learning the ropes about how network communications work: so I don't troubleshoot often (my peak performance is turning off and back on the router), but seeing the different pieces "in action" with software like Wireshark helps to grasp the theoretical concepts.
Aside from general tips about Wireshark (like conversation filters, buttons and others), I found that considering the layers stack from the perspective of the transport layer is very insightful and something I never thought about: either I focus on the lower part (physical, link, network) or the upper part (application, since session and presentation for me are still a mistery).
I still have to digest the video, but it seems I have learned a valuable lession: since the transport layer is "in the middle", it points to the direction to follow when trying to understand what went bad.
Thanks for the upload, I'm really glad I resisted the first "ugh! 1 hour of technical explanations on topics I barely understand? No thanks" impression , you are a great teacher!
I'm here to proof that it is not network issue its application team issue 😁
I need the app can somebody help me
u mean the wireshark software?
They use the term in a less pedantic more general way, that's all.
Not going to the main topic. .