Ports and Protocols

Design and Planning

Initial setup in packet tracer

PC1 pinging PC2

Ping operates at the network layer and uses the ICMP, not TCP or UDP. Because ping does not use TCP, a successful ping shows that a device is reachable and responding to ICMP requests, it does not prove TCP reliability or confirm that TCP-based services are functioning correctly. The key difference between TCP and UDP is that TCP is connection-oriented and ensures reliable data delivery. On the other hand, while UDP is connectionless and sends data without guaranteeing delivery. This makes TCP more reliable but slower, while UDP is faster and more efficient but less relaible.

---

Observing TCP Behavior

Before the data is sent:

The six steps described represent the TCP three-way handshake and acknowledgment process. In the first step, the flag appears as PC1 initiates the connection, and in the second step, both flags appear as PC2 responds and acknowledges the request. The final step includes the flag from PC1, confirming the response. The connection is considered established, completing the three-way handshake and allowing data transfer to begin.

Acknowledgement and Ordering

Packet Location	Acknowlagement Number
PC 1	0
Switch	0
PC2	1
Switch	1
PC1	1

ICMP vs TCP vs UDP

Note: IP exists on layer 3 of the OSI model. TCP and UDP exist on layer 4 of the OSI model. ICMP does not exist on the OSI model.

A ping operates on layer 3, the network layer. It uses ICMP to send requests and replies between devices. It does not use TCP or UDP. Instead, it relies on the ICMP. A successful ping does not prove TCP reliability, since TCP includes sequencing, acknowledgments, and retransmission as well.

Observing TCP Behavior

Investigation 1 — Connection Establishment

Before any data is sent, three steps occur. First, a packet is sent from PC1 with the SYN flag. Next, PC2 responds with a packet containing both SYN and ACK flags. Finally, PC1 sends back a packet with the ACK flag. The connection is confirmed as established when this final ACK is sent.

Investigation 2 — Acknowledgment and Ordering

Step	Sequence Number	Acknowkedgement Number
PC1	0	0
Switch	0	0
PC2	0	0

Investigation 3 — Header Fields and Error Detection

Checksum: 0x0000

Header Length: 20 bytes

The checksum is used to detect errors in the TCP header and data during transmission. If the checksum fails, the receiver will not accept the data. Instead, the data is discarded, and the sender will retransmit the missing data after not receiving an acknowledgment.

---

Tecnical Development

TCP vs UDP — Comparing Transmission Types Predict Before Testing

TCP is connection-oriented because it establishes a connection using a handshake and maintains it with acknowledgments and sequencing. UDP is connectionless because it sends data without setting up a connection or tracking delivery. If UDP data never arrives, nothing happens automatically since there is no acknowledgment. TCP consumes more overhead because it requires connection setup, acknowledgments, and error-checking.

View Listening TCP Ports

• Status: UNCONN means that the status is unconnected

Live TCP vs UDP Experiment

Terminal A:

Terminal C:

Terminal B:

Terminal C:

The LISTEN state is shown in the ss -tln output where port 5000 appears with the state LISTEN, meaning it is waiting for a connection. The ESTAB state is shown in the ss -tn output, where both 127.0.0.1:5000 and the port are connected, indicating an active session. The change between ss -tln and ss -tn is that the first shows a listening socket with no connection, while the second shows an actual established connection between two endpoints. This proves TCP is connection-oriented because it requires a connection to be established before data can be exchanged.

After ending the session and running ss -tn again there was nothing to read:

---

Layers 5-7

The command uses HTTP/1.1 protocol identified by the header. It runs TCP at the transport layer to ensure data arrives reliably and in the correct order. While the network moves the data, the application layer is responsible for interpreting specific status codes like “200 OK,” serving as the final translator for the software.

Switching to https introduces HTTP/2 and the TLS protocol. Since HTTP is naturally plain-text, encryption must occur at a higher “presentation” sub-layer to secure the data before it hits the wire. The TLS handshake seen in the output establishes trust, a mandatory step that must finish before any actual application data can be safely sent.

The ss -tn command monitors the transport layer. This indicates the current attempt at a TCP three-way handshake. The application or the OS decides when to end this session, but the underlying TCP layer remains indifferent to the data.

Protocol	Layer	Purpose
HTTP	Application Layer	Transfers web pages and resources between a web server and a browser.
HTTPS	Application Layer	Secure version of HTTP that encrypts web traffic using TLS to protect data.
TLS	Transport/Security Layer	Encrypts data to provide secure communication over a network.
DNS	Application Layer	Translates domain names (like example.com) into IP addresses used by computers.
TCP	Transport Layer	Provides reliable, ordered, and error-checked delivery of data between devices.

---

Layer 4 (Transport) is insufficient because it only ensures TCP reliability—the technical delivery of packets—without understanding what the data is or if it is secure. In contrast, Layer 5 (Session) manages the communication state, determining when a dialogue begins and ends beyond the simple packet-level handshake. Layer 6 (Presentation) handles formatting and the TLS handshake observed in the OpenSSL output; this is where TLS encryption occurs to transform plain text into a secure format that TCP then carries. Finally, Layer 7 (Application) governs behavior by interpreting specific instructions, such as the “301 Moved Permanently” status seen in the curl command. This modularity allows the network to reliably move data (Layer 4) while the upper layers ensure it is private (Layer 6) and meaningful to the user (Layer 7).

---

No connectivity issues:

1. What changed at the application layer?
2. What changed at the transport layer?
3. What port numbers are involved?
4. What additional protocol appears between HTTP and TCP?
5. Is TLS replacing TCP — or operating above it? Your explanation must trace: Application → Encryption → Transport → IP

1. What port does DNS typically use?
2. Does it usually use TCP or UDP?
3. Why does DNS not require guaranteed delivery in most cases?
4. When might DNS switch to TCP?

1. What port is SSH using?
2. What transport protocol is underneath it?
3. Is this connection encrypted?
4. What evidence supports your answer?
5. Which OSI layers are involved in this remote session?

1. What protocol does SCP rely on?
2. Does SCP require TCP?
3. Is the file encrypted?
4. What would happen if TCP reliability were removed?
5. Which layers are involved in this transfer? Map the stack explicitly.