Learning bite
IP addresses, ports, and sockets
Locate a listener and distinguish host addressing from service addressing.
On this page
An address gets you to a host; a port identifies an endpoint
IP carries packets between network interfaces. TCP and UDP add port numbers so different programs can communicate through those interfaces. A socket is an operating-system communication endpoint. A TCP connection is distinguished by protocol plus both source/destination addresses and ports; many clients can reach the same server port using different source endpoints.
The browser journey introduced TCP's SYN → SYN-ACK → ACK handshake. TCP provides an ordered byte stream and recovery from loss; UDP sends datagrams without providing those guarantees itself. Applications can build reliability over UDP, as QUIC does for HTTP/3. “UDP is always unreliable application behavior” would therefore be too broad.
Read a subnet and route
CIDR writes an address with a prefix length. In 192.168.50.20/24, the first 24 bits identify the subnet. In the usual IPv4 /24 example, the network is 192.168.50.0, the broadcast address is .255, and conventional host addresses run from .1 through .254. A longer prefix leaves fewer addresses: /25 divides that /24 into two blocks, .0–.127 and .128–.255. Special prefixes such as /31 have different host-use rules.
The private IPv4 ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Private does not mean encrypted or automatically isolated. A route says which next hop/interface to use for a matching destination; more specific matching prefixes normally win over a default route. Overlapping VPN/lab subnets can therefore send traffic to an unintended interface.
Inside Linux, inspect rather than change your configuration:
ip -brief address
ip route
ss -lnt
ss -lnu
ip -brief address shows interface state and assigned prefixes. ip route displays routes; a row beginning default via identifies a default next hop when present. ss -lnt lists listening TCP sockets numerically; ss -lnu shows UDP sockets, whose lifecycle is different. Some environments expose routes unlike an ordinary full VM, so record what you actually see.
Read the listener address
An illustrative TCP row is:
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.1:8765 0.0.0.0:*
The important field for this question is Local Address:Port. This process accepts connections to IPv4 loopback port 8765 inside this network namespace. It does not directly listen on the machine's external interface. The peer wildcard on a listening socket means no connected peer is selected yet; it does not turn the local binding into an external one.
0.0.0.0:8765 as the local address would mean all local IPv4 interfaces. Clients use a reachable actual address, not 0.0.0.0 as their destination. IPv6 loopback is ::1; a wildcard IPv6 listener's treatment of IPv4 depends on system/socket configuration. ss -lntp can add process information, subject to permissions.
Use connection states as clues
LISTEN means a TCP socket is waiting for connections. ESTAB means a connection is established. TIME-WAIT after closure can be normal TCP behavior, not a stuck service. A pending SYN-SENT indicates an attempt awaiting a suitable response, but does not itself identify where traffic is lost.
The path also has a maximum packet size, MTU. A tunnel can reduce it; a connection that handles small messages but stalls on larger data may need path-MTU investigation. Do not change interface MTUs merely because a web page is slow; that is an advanced hypothesis requiring evidence.
Practice: choose an existing listener, record its local address/port, and identify its owner if permitted. Predict reachability from Linux loopback and from the Mac separately. OrbStack integrations may forward traffic, so distinguish a forwarded host connection from direct interface reachability. Verify only a service you intend to access.
Does successful ping prove HTTPS works? No: ICMP replies do not establish TCP, certificate validation, or HTTP behavior. Would changing DNS fix a process listening on the wrong port? No: DNS and listener configuration answer different questions. Next, inspect the name lookup itself.
Sources
Primary references: Linux ss↗; IP routing↗.
Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.