Lab: observe a search and a website response

Use the browser you already have

This first lab needs no Linux VM or cloud account. Use a normal browser with developer tools. Work only with your own browsing session and keep observations free of cookies, authorization headers, or personal search history. A short written record is enough; a full HAR export can contain more information than you intend to publish.

In Chrome, open Developer Tools → Network and enable Preserve log before navigating. Other browsers offer equivalent tools. You can clear only the displayed request list to make the exercise readable; do not clear all browser data. Chrome network inspection↗.

1. Separate search from navigation

Open Google's search page and type learnwithsk.dev into its search field. Submit once. Record the destination hostname for the search/results traffic. If a suitable result is shown, inspect its destination before opening it; result links can include an intermediate redirect. If it is absent, record that fact and enter https://learnwithsk.dev/ directly to continue. Do not invent a ranking or result.

Inspect the main document request to the website. Record:

A missing DNS or TLS timing segment may reflect connection reuse, caching, or unavailable instrumentation. It does not mean DNS or TLS was unnecessary for the connection.

2. Follow one additional resource

Choose one script, stylesheet, image, or font request made by the page. Use its Initiator information to see why it was requested. Compare hostname, protocol, status, and timing with the main document. Do not assume every resource shares an endpoint.

Reload once with normal caching. Compare the two observations. If you deliberately disable the browser cache for a comparison, record that setting and restore it afterwards. Browser response-wait time includes network and server/proxy work; it is not a direct measurement of origin application execution alone.

3. Optional terminal comparison

This is optional now; return after the Linux networking module if the commands are unfamiliar. From a terminal with dig and curl available, make one bounded request:

dig learnwithsk.dev A
dig learnwithsk.dev AAAA
curl --connect-timeout 5 --max-time 15 --max-redirs 5 \
  --location --silent --show-error --output /dev/null \
  --write-out 'status=%{http_code} ip=%{remote_ip} http=%{http_version} final=%{url_effective}\n' \
  https://learnwithsk.dev/

The command follows up to five redirects and reports the final transfer; inspect browser entries for the full chain. A curl transport failure has a nonzero exit status; an HTTP error response does not by itself make this invocation fail. Inspect both. Curl's build, resolver, proxy, and connection negotiation can differ from the browser. Do not disable TLS verification to force a success. curl options↗.

Packet capture and route tracing are not required. Later network diagnosis adds host-side checks. No captured request can reveal every hidden server behind a proxy.

Interpret a small observation before writing the conclusion

For example, suppose the document row shows 200, an image row shows 404, and the second document request shows a cached response. That would support three separate statements: an HTTP component served the document; the selected image URL did not return its requested resource; the browser reused or validated stored content according to the displayed cache information. It would not establish the origin's physical location or prove that all other requests succeeded. These are hypothetical observations, not results to copy.

Check your own record with three questions. Did you distinguish the search destination from the website? Did you name which request each status belongs to? Did you mark a missing timing field as unknown/reused rather than zero-cost work? If one answer is no, revisit that browser row before proceeding. A meaningful first entry can be short: one document, one asset, and a clearly stated uncertainty.

Checkpoint and handoff

Write a short “what I observed” account: search destination, website request, one asset, one cache/connection observation, and two unknowns. Add a separate conceptual packet/OSI diagram. Label inferred components instead of presenting them as measured facts.

This becomes the first evidence entry for your personal learning site. Continue to Virtualization and hypervisor types to prepare the machine that will host your own site later.

Status is documentation-reviewed; no fixed IP, route, response, or search result is promised for your run.