IP delivers data between host computers; TCP & UDP deliver data between applications.
| Protocol | Port Number |
| Echo Protocol | 7 |
| Daytime Protocol | 13 |
| File Transfer Protocol | 21 |
| Telnet Protocol | 23 |
| Simple Mail Transfer Protocol | 25 |
| Time Protocol | 37 |
| Whois Protocol | 43 |
| Trivial File Transfer Protocol | 69 |
| Finger Protocol | 79 |
IP is, metaphorically, a mail truck and TCP is a postal worker. IP gets the mail into the right post office; then UDP sorts it out to ports. Applications have to check their boxes to see if any mail arrived.
TCP, being connection-oriented, is more like telephone communication. Each application protocol is assigned its own port for incoming traffic. If this is a well-known port (analogous to a company's main telephone number) the app can switch out to a spare port to free up the WUP for other traffic.
When your application sends a message, its port number is automatically attached so that the other party can reply. So you don't need to know your own port number; but you do need to notice the "caller ID" of the one who called you.
You can request a fixed port number to be used by a server app you're building, so that others will know where to call you.
| bit 0 ..... to bit 15 | bit 16 to bit 31 |
| UDP Source Port | UDP Destination Port |
| UDP Message Length | UDP Checksum |
| UDP data area begins here ....... |
The length field describes the entire datagram including the header. The checksum (which is optional) includes the header and the data.
Acknowledgements are used by TCP. Each time transmitting end of a connection sends a message, it starts a timer. If the timer expires before ACK comes, the message is automatically re-transmitted. But it would be inefficient to transmit one message, wait for ACK, then transmit another. Instead, TCP uses a sliding window - i. e. a range of message numbers. It might be working on messages 2,3,4,5,6,7,8,9 of a group, all at once. By the time message 9 is transmitted, it's time for ACK 2 to come back.
The actual width of the window is adapted ("negotiated") to net conditions along the particular virtual circuit being used. High congestion leads to smaller windows (because less speed is possible, old messages get stale when only a few have been transmitted.) Actual windows are several thousand bytes wide.
TCP Segments (messages) have a complex header structure. Use this diagram to visualize the TCP segment's structure.
| bit 0 ..... to bit 15 | bit 16 to bit 31 |
| 16-bit Source Port | 16-bit Destination Port |
| 32 bit Sequence Number | ----- continues ----- |
| 32 bit Acknowledgement Nr. | ----- continues ----- |
| Header Length (4), Flags (5) | 16-bit Window Size |
| 16-bit TCP Checksum | 16-bit Urgent Pointer |
| Options if any, and padding. | ----- continues ----- |
| Optional Data begins here | ----- continues ----- |
The eight flag bits are named URG (urgent); ACK (acknowledgement, PSH (please send data now), RST (reset), SYN (synchronize), FIN (finished).
The most obvious thing not itemized here is the LENGTH field. How much data? To be seen later ...
To start a TCP connection, your program (A) sends a request for TCP connection to your host computer's transport layer - which sends a TCP message with the SYN flag set. This message includes a 32 bit sequence number; receiving TCP module (B) stores this for future use. Then B sends back to A, a segment with ACK flag set and an acknowledgement number. A, in turn, stores this one for later use.
Analogy: A says to B: "I'm gonna send you a bunch of Fed Ex packages with sequentially numbered airbills. The first airbill number will be 345 677 891." B replies: "OK, and I'll send you receipts. Here's the first one. In its Ack Nr. field, we put 345 667 892." These "acknowledgement numbers" tell the sender what is the NEXT Fed ex airbill number (seq nr) it expects to receive.
B sets the ACK flag to mark the Ack number as the important part of this message. When doing this, B sets the SYNchronization flag also. This flag means "we're starting a new relationship here; if you're gonna send me data, I probably will want to send you some, too."
Acknowledging the Acknowledgement. Now A has requested and received synchronization from B, but A still must say "OK, we're in business - i. e. officially establishing the connection.
So, A sends back a segment with its Ack number field set to the Seq. Nr. from B, plus one - that is, 1002. No SYN flags are set this time. Summary:
This is the "Three-way handshake" of TCP.
Sequence Numbers begin at an arbitrary value (to increase their usefulness as identifiers. They then increment by the number of bytes in the data; so that they look like "bookmarks" reporting where, in the total data stream, the first byte of this segment's data is located. (But that's not seq. nr=0 or 1; it's whatever the initial value was.)
With 32 bit numbers, we can exchange around 4 gigabytes before we wrap around, and even then it's no problem. You're unlikely to have 4 gb of data in the pipe at the same time so that confusion would result.
QUESTION: Would TCP normally use the same packets to flow data B to A, and to acknowledge data going A to B? More likely it would use separate packets for ACK purposes, methinks. I need to ask someone.
Closing a Connection: Half-Close and Full-Close. You can close one direction of a connection (A no longer sends to B) but B may still send to A. The FINished flag from A to B just means that A is finished sending. Acknowledging that message only means that B "understands" the half close.
The first end to initiate a close is doing an active close. If the plan is for the other end to then close too, it is said to be doing a passive close.
URGent flag: process this data before any other data.
PSH means PUSH: this tells the TCP module to immediately send this data to the destination application, rather than buffering it until some buffer size is reached. This is used by Telnet for instance, to assure character by-character echo on the screen.
RST means RESET: Sent when TCP detects a problem with a connection. Most applications will terminate when they get RST, but you could design a recovery scheme built around this flag.
FINish means that the sender is done sending. This only closes data flow in one direction.
TCP Checksum is, obviously, appended by TCP sender and checked by the receiver. UDP does not require a checksum but TCP does.
Urgent Pointer is a controversial critter; supposedly it specifies an address in the TCP data area. However, since it is unclear how to use this pointer you should only use it if you are in complete control of both ends of the communication.
Options is inadequately explained in the text. we won't study it now.
The answer is back in Chapter 4, in the section on Fragmentation which we did not summarize. So we'll summarize it NOW, beginning on page 94: "Understanding Fragmentation."
Fragmentation as seen by TCP. TCP doesn't see fragmentation. Simple, eh? IP reassembles a "very large packet" as though it had never been fragmented, for presentaton to TCP. Thus, the data length field in the IP packet reports the information needed by TCP and its application user. So segments are effectively limited to 2**16 bytes in length.
Fragmentation as handled by IP. To perform this magic,
IP uses
three fields: Identification (16 bits), Flags (3 bits) and Fragment
Offset (13 bits.) The three flags are "Do not Fragment", "x" and "More
Fragments".
Assume that a datagram is 4096 bytes long but the MTU (Maximum Transfer Unit) is 1024 bytes. IP will break the data portion of the packet into smaller pieces called fragments, in multiples of 8 bytes. The first packet is transmitted with its MORE FRAGMENTS flag set. The receiver starts a reassembly timer. If this timer expires before the whole mess arrives, the receiver discards all the pieces and does not process the datagram.
As the receiver reassembles fragments, IP uses the Source Address and Identification fields to put 'em together. When the host receives a fragment with the More Fragments flag turned off, it can calculate the length of the original datagram.
Each fragment is using its Fragment Offset field to describe its starting point measured from the beginning of the original packet. Thus, like rebuilding a jigsaw puzzle, the receiver can tell when it has received all the fragments.
2. Is the entire three-way handshake really necessary if you are only going to transmit data in one direction? (It may be inherent to TCP; we're just talking conceptually here.) Why or why not?
3. What do you expect a "Push" to actually be doing in software? That is, how can a service routine such as TCP (inside a tool such as WinSock) actually get an application program to do something like pick up incoming data?