On Thu, 3 Jan 2002, Peter Jay Salzman wrote: > web and ssh work fine just opening up 80/tcp and 22/tcp. what exactly > are the udp ports used for? is there any reason to open them up?
Since others have answered the question specific to these services, I won't go there much*, but instead try to explain the general case for other people. (I am guessing that Peter and those that answered already know the general case described below.) *(Brief: I was told UDP port 22 was used by an ancient copy of PC AnyWhere, and some web servers that did audio/video streaming would have it use UDP port 80 in older copies of RealServer and just not use TCP for real at all- they over-rode the defaults for port use on the server.) A tcp packet: http://mike.passwall.com/networking/tcppacket.html has enough header information to allow for creation of reliable sessions http://mike.passwall.com/networking/netmodels/tcpip5layermodel.html This means that you can be certain that packet's payloadare disassembled in the same order they were assembled, and the payload of the (tcp) packets sent are not damaged in transit. Very useful for things like ssh, telnet and web data. (You don't want characters transposed? OK, then use TCP or make an application layer thing-a-ma-bob that deals with errors/corrections (NFS). A UDP packet: http://mike.passwall.com/networking/udppacket.html lacks the header information to deal with reliable sessions. UDP packets may be received in the wrong order. No attempt is ever guaranteed for replacement of a bad UDP packet with invalid data with a good UDP packet with good data. When the UDP packet arrives that has a bad payload/broken, it can just be dropped and we proceed on with the data lost forever**. **(Of course this is not always the case) Both TCP and UDP packets are usually the payload of an IP packet: http://mike.passwall.com/networking/ippacket.html Why would you want to use UDP if it is unreliable and packets may come in in the wrong order? With TCP, a missed packet in a stream means that all "good packets" received after the bad packet must wait until the "bad packet" is retransmitted before the other "good packet's" payload (after the bad one in sequence) may have their payloads passed onto the application(s) that asked for them. This is good for telnet (no re-ordering of payload data in a stream.) However, imagine you are listening to a radio broadcast. If you receive a bad packet in the middle of a broadcast, you do not want to have the broadcast STOP while your system waits for the bad data to be retransmitted. Instead, just a bit of "static" or a gap in the broadcast may be what you want. (It is especially bad with things like music. You can bump along with the beat even when there is occasional dead air, but having the beat stop and then restart is a little uncomfortable.) When you actually start getting the good data, you hear more of the broadcast. Interruptions do not cause you to get "behind" but instead allow you to keep listening and move ahead. Looking at the UDP packet vs a TCP packet, you can see that a TCP packet has at least 20 bytes for header data (not counting options and extras) while the UDP has at least 8 bytes of overhead. The overhead incurred by the header for TCP (information used to help ensure a reliable connection mostly) is over 2x that of UDP. However, since UDP does not require a session (the Whole, SYN, ACK, etc) a host need not use a valid IP address when manufacturing a UDP packet and sending it on its way. OTOH, a TCP packet requires some exchange in an initial setup between two machines "talking" to each other with each one using a sequence number that must be part of the ACK for the other party's response. Without actually seeing the returning packet, you would need to guess the number (not as hard on some systems as you might think). UDP is not considered very secure. NFS has used UDP for a long while. This helps for effective throughput (smaller header) at the cost of the application layer doing the error-control/repair *and* a greater lack of security in having no guarantee that the packet received was really from the IP address the packet claims it is from. If you do not need a UDP service or can choose between TCP vs UDP, TCP can offer more security. -ME (I get paid by word when I post to this group, right? ;-) -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z? ------END GEEK CODE BLOCK------ decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
