Networking Fundamentals and Protocols Questions

Direct answer
A port is a 16-bit number identifying an endpoint on a host; a socket is the (IP address, port, protocol) combination that uniquely names one endpoint; and a connection (the 4-tuple, or 5-tuple if you count the protocol) is the full pairing of BOTH endpoints' sockets, source IP, source port, destination IP, destination port. Many clients can share the same server port because what actually distinguishes their traffic is the FULL 4-tuple, not the destination port alone.

Structured elaboration
Port ranges are conventionally split three ways: well-known ports (0-1023, traditionally requiring elevated privilege to bind on Unix-like systems, and reserved by convention for standard services like 443 for HTTPS), registered ports (1024-49151, registered with IANA for specific applications but not privileged), and ephemeral (or dynamic/private) ports (49152-65535 by IANA convention, though many OSes use a wider practical range), which the OS assigns automatically to the CLIENT side of an outgoing connection.

A server listening on port 443 can serve thousands of simultaneous clients because the SERVER's port (443) is only ONE piece of what identifies each connection; every incoming connection also carries a distinct client IP and, typically, a distinct client-side ephemeral port, so the full 4-tuple (client IP, client port, server IP, server port) is what the OS actually uses to demultiplex incoming packets to the right connection, even though the server-side half of that tuple (server IP and port) is identical across all of them.

Worked example
Two different clients, 203.0.113.5 and 203.0.113.9, can both have simultaneous connections to a web server at 198.51.100.1:443. Client A's connection might use ephemeral port 51000 and client B's might use 51000 too (a coincidence, since each client picks its own ephemeral ports independently), yet the server has no trouble distinguishing them, because the full 4-tuples are different: (203.0.113.5, 51000, 198.51.100.1, 443) versus (203.0.113.9, 51000, 198.51.100.1, 443). If client A instead opens a SECOND connection to the same server, its OS will typically pick a DIFFERENT ephemeral port for that second connection (since a client can't have two identical 4-tuples open at once to the same destination), giving something like (203.0.113.5, 51001, 198.51.100.1, 443).

Trade-offs & pitfalls
NAT changes what a receiver actually observes on the wire: a device behind a NAT gateway sharing one public IP will have its ephemeral port REWRITTEN by the NAT device (Port Address Translation) so that multiple internal hosts sharing the same public IP can still be distinguished by the server, meaning the source port a server sees is often not the port the ORIGINAL client actually used, a common source of confusion when correlating server-side logs against client-side application behavior.

Direct answer
An ICMP Type 3 Code 4 message ("Fragmentation Needed and Don't Fragment was Set") is a router along the path telling the sender its packet was too large for the next hop's MTU (Maximum Transmission Unit, here 1400 bytes) and, because the Don't Fragment (DF) bit was set, the router dropped it rather than fragmenting it, expecting the sender to resend at a smaller size. Path MTU Discovery commonly fails in production because something along the path (often a firewall with an overly broad "block all ICMP" rule) discards that very ICMP message before it reaches the sender, so the sender never learns to shrink its packets and its large packets just keep silently disappearing.

Structured elaboration
The DF bit tells every router along the path "do not fragment this packet under any circumstances, if it doesn't fit, drop it and tell me why." Path MTU Discovery relies entirely on that "tell me why" part actually reaching the sender: the sender starts by assuming its LOCAL interface's MTU is usable end-to-end, sends with DF set, and if a router along the path can't forward it at that size, the router sends back exactly this ICMP message, reporting the smaller MTU it needs (1400 bytes here). The sender is then supposed to shrink its packet size to that reported value and retry.

The reason PMTUD commonly fails in production: many firewalls and security appliances, misconfigured to block ALL ICMP as a blanket "security" measure, silently discard the "Fragmentation Needed" message on its way back to the sender. The sender then never learns it needs to shrink its packets, keeps sending at the original (too-large) size with DF still set, and those packets keep getting silently dropped at the same router, forever, with no error ever surfacing to the sender, the classic "large transfers hang, small transfers succeed" symptom (small packets happen to fit under the constrained MTU and sail through fine, while anything larger vanishes without explanation).

Worked example
To reconstruct what happened from the capture: the fragmented IPv4 packets observed likely represent an EARLIER part of the same flow that happened to still get through (perhaps fragmented by an intermediate device before DF took full effect, or from a portion of traffic that didn't have DF set), while the ICMP message with next-hop MTU 1400 is the router's report on a LATER, DF-set packet it could not forward. To fix this for BOTH TCP and UDP traffic: for TCP, the most common resilient fix is MSS clamping on a network device at the edge (rewriting the TCP Maximum Segment Size option in SYN packets passing through, so TCP negotiates a small-enough segment size up front and the oversized-packet problem never occurs at all, PMTUD independent); for UDP, since there's no equivalent MSS negotiation, the application itself must either send appropriately small datagrams from the start or correctly handle PMTUD feedback (which requires NOT blocking the relevant ICMP messages on the path, the actual root-cause fix). In both cases, the truly correct long-term fix is ensuring ICMP "Fragmentation Needed"/"Packet Too Big" messages are explicitly PERMITTED through every firewall along the path, rather than working around their absence.

Trade-offs & pitfalls
MSS clamping is a pragmatic, widely-used workaround specifically because it doesn't depend on ICMP getting through at all, but it only helps TCP; it does nothing for UDP traffic hitting the exact same oversized-packet problem, which is why "block all ICMP" as a firewall policy is a genuinely bad default rather than a harmless-looking hardening step, it breaks a real, load-bearing part of how IP networking is supposed to self-correct.

Direct answer
When packets are genuinely just arriving out of order (not lost), TCP has built-in tolerance thresholds so it doesn't mistake brief reordering for loss and trigger an unnecessary fast retransmit; PAWS (Protect Against Wrapped Sequence numbers) is a related but distinct mechanism that uses timestamps to detect and discard old, delayed duplicate segments from earlier in a long-running high-speed connection.

Structured elaboration
Modern TCP stacks track how far "out of order" a segment can arrive (measured in either packet count or time) before treating it as evidence of real loss rather than harmless reordering; Linux, for instance, exposes tunables around reordering tolerance that adapt based on the connection's OWN observed reordering history, rather than using one fixed global threshold for every connection. A connection on a path known to reorder packets occasionally (some multi-path or load-balanced routes do this by design) can raise its own tolerance so ordinary reordering doesn't repeatedly trigger unnecessary fast retransmits.

PAWS solves a different, narrower problem specific to very fast connections: on a high-bandwidth link, the 32-bit TCP sequence number space can actually WRAP AROUND within the lifetime of a single connection (send enough gigabytes fast enough and you'll reuse sequence numbers that were valid earlier in the SAME connection). PAWS uses the TCP timestamp option, present on nearly every modern connection, to disambiguate: if a segment arrives whose sequence number would otherwise look valid but whose timestamp is clearly older than the most recent one seen, it's recognized as a stale duplicate from earlier in the connection (possibly delayed en route) and discarded, rather than being misinterpreted as new data that happens to reuse an old sequence number.

Worked example
On a path prone to reordering (say, traffic load-balanced per-packet, not per-flow, across multiple physical links with slightly different latencies), segments can regularly arrive a few positions out of order without any data actually being lost. If TCP's reordering tolerance is too strict, this triggers spurious fast retransmits and duplicate-ACK-driven congestion-window reductions on a connection that never actually experienced loss, hurting throughput for no real reason. An application-level (rather than pure TCP-level) fallback in genuinely reordering-prone environments is to add its OWN sequencing at the application layer, buffering and reassembling out-of-order application messages itself, so the transport layer's retransmission machinery isn't repeatedly triggered by ordinary path-level reordering it can't avoid.

Trade-offs & pitfalls
Raising reordering tolerance too aggressively to avoid spurious retransmits comes at a real cost: on a connection that IS actually experiencing loss (not reordering), a higher tolerance delays how quickly that genuine loss gets detected and retransmitted, directly trading recovery latency for false-positive avoidance. There's no free lunch here; the right tolerance setting depends on knowing, for a specific path, whether reordering or loss is the dominant failure mode.

Direct answer
Selective Acknowledgment (SACK) lets a receiver tell the sender exactly which non-contiguous blocks of data it has ALREADY received, so after a loss the sender only has to retransmit the specific missing segment(s), not everything that came after it.

Structured elaboration
Without SACK, TCP uses cumulative acknowledgment: an ACK only confirms "I have received everything up through this byte, contiguously." If segment 3 of a 10-segment flight is lost but segments 4 through 10 all arrive fine, the receiver can only ACK up through the end of segment 2, it has no way to tell the sender "I actually already have 4 through 10, I'm just missing 3." A sender using only cumulative ACKs, upon detecting the loss, may end up retransmitting segments 3 through 10 (everything the receiver hasn't cumulatively acknowledged), even though 4 through 10 were never actually lost.

With SACK enabled (negotiated via a permitted option in the handshake, then carried on subsequent ACKs), the receiver's ACK can include SACK blocks, explicit ranges of sequence numbers it holds that are NOT contiguous with the main acknowledged run, in the example above, a SACK block spanning segments 4 through 10. Now the sender knows precisely that only segment 3 needs retransmitting.

Worked example
Say a sender has segments with sequence ranges [1000-1500), [1500-2000), [2000-2500), ... up to [4500-5000), and segment [2000-2500) is lost in transit while everything else arrives. Without SACK: the receiver's ACKs stay pinned at ack=2000 (the last contiguous byte received) even as segments up through 5000 keep arriving; the sender, upon detecting the loss (via duplicate ACKs all saying ack=2000), knows only that SOMETHING after 2000 needs resending and, in older/naive implementations, could resend everything from 2000 onward. With SACK: the same duplicate ACKs at ack=2000 now also carry a SACK block like sack=2500-5000, telling the sender explicitly that only the single segment [2000-2500) is actually missing, so it retransmits exactly that one segment and nothing else.

Trade-offs & pitfalls
SACK is most valuable on connections with a large amount of data in flight (a large window relative to segment size) and where losses are isolated rather than in a solid burst, since that's exactly the scenario where "retransmit everything after the gap" wastes the most bandwidth compared to "retransmit only the gap." On a connection with a tiny window, or where an entire flight is lost at once (nothing left to selectively acknowledge), SACK provides little advantage.

Direct answer
When a client keeps retransmitting its SYN and never sends the final ACK (while the server's SYN-ACK is only retransmitted once before the connection times out), the most likely causes are that the client's connect timeout hasn't fired yet, that something between the two hosts is dropping the ACK specifically (an asymmetric path or a stateful device confused about direction), or that the client-side application itself never actually attempted the ACK due to a bug. A different failure shape, the server sends SYN-ACK and the client immediately sends RST, points to a different family of causes entirely: the client rejecting the connection outright.

Structured elaboration
For the "client retransmits SYN, no final ACK" pattern, work through causes in order of likelihood:

1. Asymmetric routing dropping only the return-to-forward-direction ACK path. If the SYN-ACK reaches the client (we know it does, since the client keeps retransmitting new SYNs rather than giving up, meaning it IS getting a response of some kind) but the client's ACK can't get back to the server along some other path, a stateful firewall or NAT device on that asymmetric path may be dropping the ACK because it doesn't recognize the connection's state in that direction.
2. A middlebox is rewriting or dropping specific TCP options in the SYN-ACK that the client's stack doesn't handle gracefully, causing it to silently discard the SYN-ACK and retry instead of ACKing it.
3. Client-side firewall or security policy is specifically blocking outbound ACKs to that destination while permitting the outbound SYNs, an unusual but real misconfiguration.
4. MTU (Maximum Transmission Unit)-related silent packet loss on the SYN-ACK's return path if it happens to be an unusually large segment (rare for a SYN-ACK specifically, since it typically carries little payload, but worth ruling out if other symptoms point that way).

For the different shape (SYN-ACK followed by an IMMEDIATE client RST): this usually means the client-side application decided, upon establishing the connection, that it doesn't actually want it, for example an application-level timeout that already expired while the handshake was in flight, a client-side connection pool that raced two connection attempts and is aborting the loser, or a security tool on the client actively resetting connections that don't match an expected certificate or policy.

Worked example
To distinguish these hypotheses in practice, compare timestamps and evidence on BOTH ends: if the server's capture shows the SYN-ACK leaving on time but the client's capture never shows it arriving, the problem is in the path (asymmetric routing, a device eating it). If the client's capture shows the SYN-ACK arriving cleanly but no ACK is ever generated by the client's own stack, the bug is on the client host itself (application logic, local firewall) rather than the network path.

Trade-offs & pitfalls
A common mistake is assuming a stuck handshake is always a network problem; a client-side timeout race (the application gives up right as the handshake completes) produces an outwardly identical-looking symptom to a network drop and is only distinguishable by comparing what each side's own capture actually shows, not by reasoning about the network path alone.