Technical definition
The OSI Application layer is layer 7 of the OSI reference model. It provides application processes with access to communication services and defines the application-level protocols used by communicating application entities.
In plain English: Gives applications access to network services: asking for a web page, looking up a name, sending an email.
What this layer does
A network service needs rules for requests and replies. HTTP defines how a browser requests a page and how the server replies. DNS defines how to ask for the address of a name.
These are application-layer protocols. Your browser uses those protocols; a browser window, a document editor or every other piece of software is not automatically a layer 7 protocol.
Application means the network service and its messages, not everything the user sees on the screen.
Follow one request from PC-1
PC-1 is a user's computer opening a page on the lab web server. Its IPv4 address is 192.168.1.20/24 and its gateway is R1 at 192.168.1.1. The server is on another subnet, at 203.0.113.20/24, with gateway 203.0.113.1. The /24 means that the first 24 bits identify each subnet. R1 joins the two subnets.
The task is to open https://lab.routelearn.test/guides. The browser needs the server's IP address before it can connect. A separate DNS (Domain Name System) server at 192.168.1.53 answers the name query. Here, HTTPS carries HTTP (Hypertext Transfer Protocol) messages inside TLS (Transport Layer Security). The name and addresses are lab examples, not a public website to try.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Read the connections: SW1 uses Gi0/1 for PC-1, Gi0/2 for the DNS server and Gi0/3 for R1. The DNS query stays inside LAN A. Traffic to the web server crosses R1 because the destination is in LAN B. The web server's return gateway is 203.0.113.1. SW1 has no application-service IP in this example because it is forwarding Ethernet frames.
Follow the messages, not just the cables
The next figure is a message sequence. Read from top to bottom. Each vertical line belongs to one host, and each arrow is a request or reply. These arrows show logical communication between applications; they do not replace the physical path above.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Steps 1 and 2: an A record maps a name to an IPv4 address. The DNS reply gives the browser an address to contact; it does not contain the requested web page. Source port 53000 is an example client port, while 53 identifies the DNS service in this exchange. DNS can also use TCP; UDP is the choice illustrated here.
Steps 3 and 4: after establishing the TCP connection and TLS protection, the browser requests the /guides resource. The Host field identifies the requested website. The web server returns a status and the page content. The HTTP text is shown for teaching; on the network this HTTPS exchange is protected by TLS.
A DNS answer, a working TCP connection and an HTTP response are three different pieces of evidence. If the server replies 404 Not Found instead of 200 OK, the request reached an HTTP service, but that resource was not found. Check the requested path and server configuration rather than assuming that DNS or the cable has failed.
In this request: The browser asks for /guides from lab.routelearn.test. DNS supplies an address; HTTP identifies the requested resource and the server's response.
The interface labels identify the ends of the cables: Eth0 is the example Ethernet interface on each host, while Gi0/0 and Gi0/1 are R1's two Gigabit Ethernet interfaces. Actual device names vary. An IP address identifies an interface; TCP port 443 identifies the HTTPS service endpoint. It is not a physical socket on the router.
Where it fits in the other model
The four-layer TCP/IP model groups these responsibilities into its Application layer. This is a functional comparison, not a requirement for a separate header at every OSI layer.
The trade-off is between a more detailed vocabulary and a simpler description of deployed protocols. OSI names seven responsibilities; the four-layer TCP/IP model groups some of them together. Neither view requires a separate header for every named responsibility.
When it does not work
If a name lookup fails, first check the exact name and the DNS server being used. If the TCP connection succeeds but the web server returns HTTP 404, the server answered but did not find the requested resource. Replacing a cable is unlikely to fix that response. Match the symptom to the service rather than calling every failed website a network outage.
Try a practical check
Use PowerShell on Windows for this observation exercise. These commands inspect your own connection or request a public example service; they do not configure R1 or contact the documentation server in the figure.
Resolve-DnsName example.comOn Windows PowerShell, this asks the configured DNS service for records about example.com, a real example domain rather than the diagram's lab server. Read the Name, Type and IPAddress fields. A DNS reply shows that this particular query completed; it does not prove that a web page or a mail service works. Your answer addresses may change.
Your task: identify one useful field in the result, state what it shows, then name something it cannot prove. If the command is unavailable or a request is blocked, record that limitation rather than treating it as proof of a failed layer.
Check your understanding
The web server returns HTTP 404 for one page. What does this tell you?