Not sure why the other guys are hatin' on you :( Port forwarding is sometimes necessary for online gaming services if your router doesn't do stateful inspection properly. Stateful inspection looks at the traffic going out of the network and then automatically permits the reply traffic back in, when it would normally be blocked.
For example, let's say that you open a web browser and go to www.google.com. Your computer sends a TCP request to www.google.com:80 and google sends a response back to you on the same port your computer used to send the request (let's say 1421) so the response comes back to your router on port 1421. Normally this request would be denied since by default your router blocks all inbound traffic, but since it saw the request go out to google, it knows that it needs to let the reply through so it can get to your computer.
The problem is that not all routers know how to understand online gaming traffic. So when you go online with your PS3, the requests go out fine, but your router may receive some of the replies and discard them because it doesn't know what they are. That's why you sometimes have to forward ports. That basically takes your router out of the equation and says forward ALL packets received on these ports to my PS3.
The PS3 documentation should tell you which ports need to be forwarded, and whether they're UDP or TCP ports.
As someone else incorrectly states, web browsers do not use port 80, web SERVERS use port 80. Web browsers use random ports as their source ports and send their traffic to port 80 on the webserver.
Also, UDP is used for much more than DHCP, TFTP, etc. Virtually all streaming media such as VoIP, Skype, etc uses UDP because it can traverse the network faster due to there being no error checking. The in game VoIP is very likely UDP, while the actual game data itself (what you're doing in the game) is probably being sent via TCP.
UDP is used for time sensitive information. Think about it like this - if you're using the in game VoIP and a packet gets garbled in transit, you'll hear static in the audio stream. If they used TCP to transmit that packet, it could be resent, but since the audio plays in real-time, it's already moved on to the next packet and there is no longer a need for the garbled packet.
Let's say that someone is sending this sentence as VoIP audio and each word is a different packet:
"My dog is yellow"
So we have four packets. Now lets say that packets 1 and 2 get to your computer ok, packet 3 is lost, and packet 4 is received ok. So your computer will play "my dog yellow". Now let's say that after packet three is received as garbled data, your computer sends a retransmit request at the same time it's receiving packet 4. So now the computer will play "my dog yellow is". The packets will be out of order because the third word had to be retransmitted. Now I think you see why it's useless to retransmit part of a real-time audio stream...the message will play out of order.