Connecting over TCP starts with a SYN packet sent by the client to the server to initiate the handshake and synchronize sequence numbers. This first SYN signals the intent to open a connection and establishes the initial sequence number space for both sides. The server then replies with a SYN-ACK to acknowledge and provide its own sequence number, and finally the client sends an ACK to finish establishing the connection. Fin is used to close connections, and a plain ACK isn’t enough to start a connection, so the initial packet must be the SYN.

IPv4 addresses are four numbers, called octets, separated by dots. In many networks the first three octets specify the network, and the last octet identifies the specific device on that network (when the common subnet mask 255.255.255.0 is used). So for 93.184.216.34, the network part is 93.184.216 and the device on that network is the final octet, 34. The middle octets aren’t the device; they’re part of the network address.

Public-key cryptography works by letting anyone encrypt data with a public key, but only the owner of the matching private key can decrypt it. The website publishes its public key so clients can encrypt messages that only the website can read using its private key. This keeps information private as it travels over the network. So the public key’s purpose is to let clients encrypt messages sent to the website. The other options don’t fit: decrypting requires the private key, not the public; public keys aren’t stored in a password vault; and color schemes have nothing to do with secure communication.

Think about what TCP headers actually carry. The information in a TCP segment is mainly about managing the connection: source and destination ports, sequence and acknowledgment numbers, flags, window size, checksum, and options. The actual addresses (To and From) live in the IP header, not in the TCP header, though you still use them to route the packet across networks. The size of the data is not stored as a separate “message size” field in the TCP header; you determine it from the header lengths and how much data follows. Encryption type, on the other hand, isn’t something TCP specifies. Encryption is applied by higher-layer protocols (like TLS) or by the application, so the TCP metadata itself doesn’t include any encryption details. That’s why encryption type is not typically included in TCP packet metadata.