|How It Works||Performance|
|Port Assignments||TCP/IP vs UDP|
|TCP Segment Header for Client to Server Packet|
|Field||Size in bits||Purpose|
|total length||16||Not in the TCP header, but rather in the basic IP header. It is the total size of the IP header, TCP segment header plus the data payload measured in 8-bit chunks (aka bytes or octets). The means the maximum size of a packet including data is 64K. This means the payload of data is at most 65,495 bytes.|
|source IP||32||Not in the TCP header, but rather in the basic IP header. Who sent the packet. When it finally arrives at its destination the receiver will know who it was from.|
|destination IP||32||Not in the TCP header, but rather in the basic IP header. Where the packet is going. On each leg of its journey the routing computer uses this to get the packet a little closer to its final destination.|
|source port||16||A free port on the client’s machine where the server should send all responses. There will be a different port for every new session, even to the same port on the server. So in theory a caller could have up to 65535 sessions going at once on just one of the server’s ports. From the point of view of the server, the source port is effectively a session number.|
|destination port||16||Which program on the server this should be directed to. All clients in the world will be sending to this same port for this program. The program sorts out the sessions by looking at the source-IP and source-port.|
|sequence number||32||The offset in the continuous stream where data in this packet belongs. Think of it as the offset in a virtual file at the receiver’s end where to plop this chunk.|
|acknowledgement number||32||The offset in the continuous stream up to which data has been received successfully. A few packets may have been received successfully past an unreceived hole, but they don’t count. This lets the other end know what has been received successfully so far.|
|hlen||4||size of packet header measured in 32-bit chunks.|
|window||16||0 means, I am not prepared to receive any more packets for a while. N means I have sufficient buffers so that I am prepared to receive data in the stream up to offset acknowledgement number + n. I don’t know what the units of measure are. If bytes, that means the sliding window can be only 64K.|
|checksum||16||This is computed as the 16-bit one’s complement of the one’s complement sum of a pseudo header of information from the IP header, the TCP header and the data, padded as needed with zero bytes at the end to make a multiple of two bytes.|
|other stuff||28||Miscellaneous fields.|
Everything is in big endian byte order.
The sender and receiver send data packets to each other. TCP/IP is a moving window protocol like the old Kermit protocol of BBS (Bulletin Board System) days, but with a variable size window. The receiver ACKs the offset where in the byte stream it has so for received successfully. It never sends NAKs. For flow control, each end avoids being overwhelmed with window advertising, i.e. telling the sender how much free buffer space it still has for receiving packets. When it wants to stop the flow it says 0 space. When it wants to start the flow again it advertises a non-zero value.
It is a symmetrical peer to peer protocol. Either client or server could initiate the connection and both uses identical protocols to send, receive, handle flow control, disconnect etc. It is an elegant protocol, about as simple as a protocol could be, yet with plenty of room for intelligent optimisation within the framework.
How does TCP/IP keep track of many users coming in on the same port, much less the same user opening many sessions on the same port? In each TCP packet header are four numbers:
|TCP/IP Segment Header|
|source IP||32 bits||IP header|
|source port||16 bits||TCP header|
|destination IP||32 bits||IP header|
|destination port||16 bits||TCP header|
Any packet coming in can be identified with whom it is from (source IP), port they want to talk to (destination port) and which session on that port this packet is pertinent to (source port). The source port has to be unique to the source IP, but that same number might be reused on another connection with a different source IP.
Wireshark, formerly known as Ethereal, is a utility to let you snoop on TCP/IP traffic in and out of your machine.
Firewalls control traffic and an out of your LAN by examining the source and destination ports in each TCP/IP segment header going through and also the source and destination IP s.
In Windows you can find out who is using which ports this way:
REM find out who is using which TCP/IP sockets netstat -o rem you might get a result like this: rem Proto Local Address Foreign Address State PID rem TCP 192.168.0.101:49181 126.96.36.199:http ESTABLISHED 4908 Rem you can then get more information about what that PID means TaskList /oAlso try SysInternals TCPView for a more details look at what is going on your machine with TCP/IP and UDP (User Datagram Protocol).
As an application programmer, you may be concerned with other timeouts:
Since TCP/IP sends no packets except when there is traffic, without Socket.setKeepAlive( true ), it has no way of noticing a disconnect until you start trying to send (or to a certain extent receive) traffic again. Java has the Socket.setKeepAlive( true ) method to ask TCP/IP to handle heartbeat probing without any data packets or application programming. Unfortunately, you can’t tell it how frequently to send the heartbeat probes. If the other end does not respond in time, you will get a socket exception on your pending read. Heartbeat packets in both directions let the other end know you are still there. A heartbeat packet is just an ordinary TCP/IP ACK packet without any piggybacking data.
When the applications are idling, your applications could periodically send tiny heartbeat messages to each other. The receiver could just ignore them. However, they force the TCP/IP protocol to check if the other end is still alive. These are not part of the TCP/IP protocol. You would have to build them into your application protocols. They act as are-you-still-alive? messages. I have found Java’s connection continuity testing to be less that 100% reliable. My bullet-proof technique to detect disconnect is to have the server send an application-level heartbeat packet if it has not sent some packet in the last 30 seconds. It has to send some message every 30 seconds, not necessarily a dummy heartbeat packet. The heartbeat packets thus only appear when the server is idling. Otherwise normal traffic acts as the heartbeat. The Applet detects the lack of traffic on disconnect and automatically restarts the connection. The downside is your applications have to be aware of these heartbeats and they have to fit into whatever other protocol you are using, unlike relying on TCP/IP level heartbeats.
However, it is simpler to use the built-in Socket.setKeepAlive( true ) method to ask TCP/IP to handle the heartbeat probing without any data packets or application programming. Each end with nothing to say just periodically sends an empty data packet with its current sequence, acknowledgement and window numbers.
The advantage of application level heartbeats is they let you know the applications at both ends are alive, not just the communications software.
You can tell which TCP/IP sessions your machine has active by typing: netstat -an.
By analogy, TCP/IP is like a bucket brigade to put out a fire, where a Datagram is like a bucket brigade with only one bucket. TCP/IP delivers packets in a pipeline. TCP/IP does not wait for a packet to be delivered before sending the next. UDP usually sends only one packet at a time.
What is important for performance with TCP/IP doing a long file download is how many bytes per second come through the spigot. If would not matter if each individual packet took 60 seconds to wend its way through the packet net. Thus the number of hops is not critical. What is critical is the bottleneck hop. (which varies since packets don’t take the precise same route). The response time of the server is not critical either, so long as it can keep the pipeline filled. Speeding up hops other than the bottleneck hop won’t help matters. The bottleneck will usually be the last hop to the client’s router or the first hop from the server’s router. The performance of TCP/IP as like a freeway limited by the most constricted spot where there is an accident or narrow bridge. The speed of cars through that constriction determines how many cars per hours can pass.
In contrast, for a Datagram, what counts is the round trip time for one packet to make it to the server and for a response to be formulated and a packet send back. Thus every hop is critical and the number of hops are critical.
If you were using TCP/IP to deliver sporadic packets over a socket, you are effectively using it like a Datagram. In that case, as with datagrams, every hop is critical.
If you were using Datagrams in a streaming video protocol where you had a pipeline of packets, you are effectively using the net like a non-error-correcting TCP/IP. In that case, as in TCP/IP, only the bottleneck hop is critical.
Both TCP/IP and Datagrams underneath both use the IP protocol to deliver individual packets. TCP/IP just adds a formal layer stream, keeping many packets in flow at once and arranging for redelivery of failed packets.
You use UDP instead of TCP/IP when:
|recommend book⇒Internetworking with TCP/IP Vol.1: Principles, Protocols and Architecture, fourth edition|
|by||Douglas E. Comer||978-0-13-470188-2||paperback|
|How IP, UDP and TCP/IP protocols work. How the domain name to IP translation DNS information in propagated.|
|Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.|
This page is posted
Optional Replicator mirror
Your face IP:[188.8.131.52]
You are visitor number|