Let's use a concrete HTTP example.
Let's say you are listening to an HTTP conversation between a client and server. When the client (in this case, cURL) sends to the server (in this case, localhost):
GET /index.html HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-cygwin) libcurl/7.24.0 OpenSSL/0.9.8t zlib/1.2.5 libidn/1.22 libssh2/1.3.0
This is sent down through the network stack before going out onto the wire. As you know, this isn't sent through in raw form. It has to be converted into the TCP/IP network protocol. That is, each piece of application data will be chopped into the appropriate number of IP packets, encapsulated with some TCP control information and sent to the destination. What you are seeing in the Wireshark UI are each of those TCP/IP packets. Wireshark decodes each packet with the appropriate protocol flags and options. Each packet further has a small piece of the HTTP application data.
So each TCP/IP packet will generally be broken into a stack that reads:
+ Ethernet II
+ Internet Protocol Version ...
+ Transmission Control Protocol ...
+ Hypertext Transfer Protocol
Each of those lines in Wireshark can open up to reveal the various flags, options and specific framing data associated with it. You can read about how Ethernet frames, IP packets (v4), and TCP packets are constructed in a variety of places online.
But the real interesting part from an application specific side is the HTTP payload. If you expand that section, you'll see parts of the data that was sent and/or received. You may not see the whole thing, because TCP packets can only contain so much data.
The beauty of Wireshark, in my opinion, is to be able to reconstruct the conversation in a more human readable format. If you locate the initial
GET request from the client and right-click on it, you'll see an option to "Follow TCP Stream". This option will not only filter the network conversation to the appropriate packets, but will also generate nicely formatted human-readable text.
All of the other packets are completely dependent on what is going on in the network. They could be DNS requests/responses, TCP SYN/ACKs, network infrastructure traffic, broadcast packets, etc. You can quickly figure out what to ignore based on the "protocol" column as well as from the source and destination.