| [<--Prev] [Next-->] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [Printable Version] [Daryl's ColdFusion Primer] [About Daryl] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Daryl uses Mozy for his online backups. |
Every TCP (or UDP) communication has a source port and destination port number in the TCP (or UDP) header. Every TCP/IP communication can be uniquely identified as [Source IP]:[Source Port] <---> [Dest. IP]:[Dest Port]. This is how a Web browser can load several images at once and keep track of which packet is for which image. The source port is different for each TCP image-download connection, though the destination port is 80 in each case. For example:
| Source IP | Source Port | Dest IP | Dest Port | Notes |
| 192.168.1.1 | 1025 | 10.101.10.1 | 80 | index.html |
| 192.168.1.1 | 1026 | 10.101.10.1 | 80 | logo.gif |
| 192.168.1.1 | 1027 | 10.101.10.1 | 80 | backgrnd.gif |
Note that each file getting downloaded has a different source port number; this is how the communications are differentiated (this packet is part of logo.gif, this packet is part of index.html, etc). Now, let's assume that index.html is finished, but the graphics are loading slowly. While the user is waiting, he/she decides to open a telnet session to rs.internic.net. The table of open sessions would look like this:
| Source IP | Source Port | Dest IP | Dest Port | Notes |
| 192.168.1.1 | 1026 | 10.101.10.1 | 80 | logo.gif |
| 192.168.1.1 | 1027 | 10.101.10.1 | 80 | backgrnd.gif |
| 192.168.1.1 | 1028 | 198.41.0.9 | 23 | telnet rs.internic.net |
Now, I could go into exhaustive detail on how a TCP connection is set up and torn down, flow is controlled, and dropped packets are resent. Instead, I'll just say that TCP connections are set up and torn down, and there is flow control and automatic dropped packet redelivery. TCP is like certified mail; if no return receipt is gotten, the packet is resent (I'm oversimplifying but it's close enough.) TCP is used for "reliable" communications, where all data must get through, and must get there in the correct order.
A UDP packet, on the other hand, is more like junk mail. No effort is expended to make sure it arrives at the destination, or that all packets arrived that were sent. UDP is generally used for real-time applications like Internet radio and online gaming, where dropped packets need not be resent, and would probably be old if they were. UDP is also used when upper-layer protocols do their own flow control and data stream checking and correcting, as is the case in NCP/IP (Netware/IP) and SMB/IP (Microsoft Networking).
Web, Telnet, Mail, and other servers "listen" for new communications at "well-known" TCP port numbers. A short list:
| Service | "Well-Known" Port Number |
| FTP | 21&20 (don't ask) |
| Telnet | 23 |
| SMTP Mail | 25 |
| HTTP (Web) | 80 |
| POP3 Mail | 110 |
| News | 119 |
| IRC | 6667 |
| QuakeWorld :-) | 27500 |
Publicly available services are generally always reached by connecting to their well-known port numbers.
A more complete list of assigned Well-Known Ports can be found at
http://www.isi.edu/in-notes/iana/assignments/port-numbers
A list of common vulnerabilities by port can be found at
http://www.networkice.com/advice/Exploits/Ports/.
Incidentally, the maintainers of this list produce a "personal firewall"
product for Windows systems called BlackICE Defender
http://www.networkice.com/html/blackice_defender.html that I use
and recommend highly for servers. For personal use, look at ZoneAlarm
(http://www.zonealarm.com/), which
is effective bidirectionally, but requires too much user intervention to be
used for servers in a lights-out environment. And you can't beat the price. :-)
(Thanks to B.B. for noticing the broken links and suggesting these new ones..!)
Next: Network Address Translation (NAT)