I’m fairly confident everyone has used a speedtest site. They are handy and provide a pretty good idea of performance to your computer. Some of the more popular sites that I have used is www.speedtest.net and www.fast.com
In spite of their convenience, there are always caveats and general things to keep in mind when using these sites. External internet connection and related equipment as well as internet variables will affect your overall performance. For example, you might have a weak Wi-Fi signal or busy router that would impact your performance numbers.
QUIC is one of those networking technologies that can look complicated until you understand the problem it is trying to solve. Officially defined by RFC 9000, QUIC is a secure transport protocol that runs over UDP rather than TCP. That may sound like a small implementation detail, but it represents a major change in how modern Internet applications handle reliability, encryption, congestion control, and multiple data streams. QUIC was developed with the modern web in mind, and its design eventually became the foundation for HTTP/3.
One of the things that makes QUIC interesting to network engineers is that it takes functionality traditionally associated with TCP and moves much of it into the QUIC protocol itself. QUIC provides reliable delivery, flow control, congestion control, packet numbering, and loss recovery while using UDP as its underlying transport. It also integrates TLS 1.3 into the connection process, rather than treating encryption as something layered separately on top of the transport. The result is a transport protocol that can evolve without requiring changes to TCP or the underlying IP infrastructure.
Performance is another major reason QUIC attracted so much attention. A traditional HTTPS connection involves TCP connection establishment followed by TLS negotiation, while QUIC combines transport and cryptographic negotiation to reduce connection setup overhead. QUIC also supports multiple independent streams inside a single connection. If one stream experiences packet loss, data on other streams does not have to wait in the same way it can with TCP's single ordered byte stream. For applications such as web pages that load many objects simultaneously, this can make a noticeable difference in responsiveness.
Another feature worth watching is connection migration. A QUIC connection is not tied as tightly to a particular network path as a traditional TCP connection. QUIC connection identifiers allow a connection to survive certain changes in network addressing, such as a mobile device moving from Wi-Fi to cellular service. That is particularly useful today because users routinely move between networks while applications remain connected. For network troubleshooters, however, QUIC also changes the way traffic is analyzed: instead of looking for familiar TCP handshakes and retransmissions, engineers increasingly need to understand UDP-based QUIC traffic and its encrypted packet structure.
The arrival of RFC 9000 was therefore much more than another Internet standards milestone. It marked the point where QUIC became a standardized transport protocol capable of supporting the next generation of Internet applications. HTTP/3 subsequently defined how HTTP semantics operate over QUIC, taking advantage of its stream multiplexing, flow control, security, and lower-latency connection establishment. For network engineers, developers, and security professionals, understanding QUIC is becoming increasingly important because troubleshooting modern web traffic increasingly means understanding what is happening inside UDP-based transport rather than relying exclusively on traditional TCP analysis.
This means that every packet head, network engineer, developer, and security professional should get a handle on how QUIC works. Let's take a look at an intro to QUIC in this video.
RFC 9000, “QUIC: A UDP-Based Multiplexed and Secure Transport,” defines the core specification for QUIC, the modern transport protocol that underpins HTTP/3. One of its biggest highlights is that QUIC moves many functions traditionally associated with TCP into the protocol itself, while running over UDP. This gives QUIC much more flexibility without requiring changes to the underlying IP network. QUIC also integrates TLS 1.3 into the connection process, providing encryption and authentication as a fundamental part of establishing a connection rather than treating security as an optional add-on.
One of the most important benefits is reduced connection setup time. Traditional TCP connections require a handshake, followed by a separate TLS handshake before application data can be exchanged. QUIC combines these processes, allowing secure connections to be established with fewer round trips. QUIC also supports connection migration, meaning a connection can continue even when the client's network changes—for example, moving from Wi-Fi to a cellular connection. That is particularly useful for smartphones, laptops, and other mobile devices where network connectivity can change frequently.
RFC 9000 also addresses a long-standing TCP problem called head-of-line blocking. QUIC supports multiple independent streams within a single connection, so if packets belonging to one stream are delayed or lost, other streams can continue processing their data. This can make applications more responsive, especially when transferring multiple objects simultaneously. QUIC also provides mechanisms for acknowledgments, retransmissions, congestion control, flow control, and packet numbering, giving implementations the tools they need to efficiently manage network traffic while avoiding congestion.
From a network-engineering perspective, RFC 9000 is significant because it effectively creates a highly capable transport protocol without requiring a new IP protocol number. Because QUIC uses UDP, it can be deployed across existing Internet infrastructure while allowing protocol developers to evolve transport behavior much more rapidly than TCP. The combination of built-in TLS security, faster connection establishment, multiplexed streams, connection migration, and improved behavior on unreliable networks makes QUIC particularly well suited to today's Internet. For network administrators and troubleshooting teams, understanding RFC 9000 is increasingly important because QUIC traffic is becoming a major part of everyday web traffic, particularly through HTTP/3.
When troubleshooting it is quite common to get the mac address of the host, server or network equipment for a variety of reasons.
For example, many syslog messages or logs may refer to mac addresses depending on what the error is. If you are working from the switch, you more than likely need to know the mac address if you need to figure out which port the target is for your monitor or span command. And of course if you are using a protocol analyzer, you should always capture with a mac address, when possible.
Upon reading the title of this book, you might be tempted to judge it as too technical or perhaps too arcane to be of interest. If so, you would be missing out on a compelling narrative about an exceptional man and his lifelong quest to do something great. Chasing the Ghost – Nobelist Fred Reines and the Neutrino by Leonard A. Cole has just enough physics to interest and motivate the reader, while keeping the focus on the trials and triumphs in Fred Reines unique life. As Fred’s younger cousin, author Cole supplements his family knowledge of the early years with interviews of many prominent and influential physicists who knew Fred personally.
Our world is essentially made of four elementary particles - up and down quarks, electrons, and neutrinos. The latter is the ghost being chased, a particle that passes through the earth as if it were not even there and is extremely difficult (some physicists thought impossible) to detect. A thousand trillion neutrinos pass harmlessly through your body every second, and many of these were created shortly after the universe was born. Fred Reines called them “the most tiny quantity of reality ever imagined by a human being.” With that brief introduction to the neutrino, you cannot help but want to know more about the man who devoted the bulk of his professional life to finding and studying them.
After capturing your data, you end up with a trace file. This next step is just as important as capturing the data since you can’t properly analyze or come to meaningful conclusions if you’re not sure where, when and how the data was captured.
This is where Wireshark’s “Capture File Properties” feature comes in. I use this to make notes about the capture such as: and time markers for events, physical location, vlan, contact info if other people were involved and other documents that might have diagrams, config or other info.
.png "Baselining Documentation - Next Step")
