At the same time the server obtains its own sequence number y, inserts it in the header, and also sets the SYN flag in order to establish a connection in the opposite direction.. The TCP
Trang 1Figure 7.3
TCP connection establishment
As mentioned before, TCP generates pseudo-random sequence numbers by means of a 32-bit software counter that resets at boot-up and then increments every 4 microseconds The host establishing the connection reads a value ‘x’ from the counter where x can vary between 0 and 232 –1) and inserts it in the sequence number field It then sets the SYN flag = 1 and transmits the header (no data yet) to the appropriate IP address and port number Assuming that the chosen sequence number was 132, this action would then be abbreviated as SYN 132
The receiving host (e.g the server) acknowledges this by incrementing the received sequence number by one, and sending it back to the originator as an acknowledgment number It also sets the ACK flag = 1 to indicate that this is an acknowledgment This results in an ACK 133 The first byte expected would therefore be numbered 133 At the same time the server obtains its own sequence number (y), inserts it in the header, and also sets the SYN flag in order to establish a connection in the opposite direction The header is then sent off to the originator (the client), conveying the message e.g SYN 567 The composite ‘message’ contained within the header would thus be ACK 133, SYN 567 The originator receives this, notes that its own request for a connection has been complied with, and also acknowledges the other node’s request with an ACK 568 Two-way communication is now established
An existing connection can be terminated in several ways
Firstly, one of the hosts can request to close the connection by setting the FIN flag The other host can acknowledge this with an ACK, but does not have to close immediately as
Trang 2it may need to transmit more data This is known as a half-close When the second host is also ready to close, it will send a FIN that is acknowledged with an ACK The resulting situation is known as a full close
Secondly, either of the nodes can terminate its connection with the issue of RST, resulting in the other node also relinquishing its connection and (although not necessarily) responding with an ACK
Both situations are depicted in Figure 7.4
Figure 7.4
Closing a connection
TCP normally breaks the data stream into what it regards are appropriately sized segments, based on some definition of efficiency However, this may not be swift enough for an interactive keyboard application Hence the push instruction (PSH bit in the code field) used by the application program forces delivery of bytes currently in the stream and the data will be immediately delivered to the process at the receiving end
Both the transmitting and receiving nodes need to agree on the maximum size segments they will transfer This is specified in the options field
On the one hand TCP ‘prefers’ IP not to perform any fragmentation as this leads to a reduction in transmission speed due to the fragmentation process, and a higher probability
of loss of a packet and the resultant retransmission of the entire packet
On the other hand, there is an improvement in overall efficiency if the data packets are not too small and a maximum segment size is selected that fills the physical packets that are transmitted across the network The current specification recommends a maximum segment size of 536 (this is the 576 byte default size of an X.25 frame minus 20 bytes each for the IP and TCP headers) If the size is not correctly specified, for example too
Trang 3small, the framing bytes (headers etc) consume most of the packet size resulting in considerable overhead Refer to RFC 879 for a detailed discussion on this issue
The TCP Frame consists of a header plus data and is structured as follows:
Figure 7.5
TCP frame format
The various fields within the header are as follows:
Source port: 16 bits
The source port number
Destination port: 16 bits
The destination port number
Sequence number: 32 bits
The sequence number of the first data byte in the current segment, except when the SYN flag is set If the SYN flag is set, a connection is still being established and the sequence number in the header is the initial sequence number (ISN) The first subsequent data byte is ISN+1
Refer to the discussion on sequence numbers
Acknowledgment number: 32 bits
If the ACK flag is set, this field contains the value of the next sequence number the sender of this message is expecting to receive Once a connection is established this is always sent
Trang 4Refer to the discussion on acknowledgment numbers
Data offset: 4 bits
The number of 32 bit words in the TCP header (Similar to IHL in the IP header.) This indicates where the data begins The TCP header (even one including options) is always
an integral number of 32 bits long
Reserved: 6 bits
Reserved for future use Must be zero
Control bits (flags): 6 bits
(From left to right)
URG: Urgent pointer field significant
ACK: Acknowledgment field significant
PSH: Push function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Checksum: 16 bits
The checksum field is the 16-bit one’s complement of the one’s complement sum of all 16-bit words in the header and text If a segment contains an odd number of header and text octets to be check-summed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes The pad is not transmitted as part of the segment While computing the checksum, the checksum field itself is replaced with zeros
This is known as the standard Internet checksum, and is the same as the one used for the IP header
The checksum also covers a 96-bit ‘pseudo header’ conceptually appended to the TCP header This pseudo header contains the source IP address, the destination IP address, the protocol number (06), and TCP length It must be emphasized that this pseudo header is only used for computation purposes and is NOT transmitted This gives TCP protection against misrouted segments
Figure 7.6
Pseudo TCP header format
Window: 16 bits
The number of data octets beginning with the one indicated in the acknowledgement field, which the sender of this segment is willing or able to accept
Refer to the discussion on sliding windows
Urgent pointer: Urgent data is placed in the beginning of a frame, and the urgent
pointer points at the last byte of urgent data (relative to the sequence number i.e the number of the first byte in the frame) This field is only being interpreted in segments with the URG control bit set
Options: Options may occupy space at the end of the TCP header and are a multiple of
8 bits in length All options are included in the checksum
Trang 57.2 UDP (user datagram protocol)
The second protocol that occupies the host-to-host layer is UDP As in the case of TCP, it makes use of the underlying IP protocol to deliver its datagrams
UDP is a ‘connectionless’ or non-connection-oriented protocol and does not require a connection to be established between two machines prior to data transmission It is therefore said to be an ‘unreliable’ protocol – the word ‘unreliable’ used here as opposed
to ‘reliable’ in the case of TCP
As in the case of TCP, packets are still delivered to sockets or ports However, no connection is established beforehand and therefore UDP cannot guarantee that packets are retransmitted if faulty, received in the correct sequence, or even received at all In view
of this, one might doubt the desirability of such an unreliable protocol There are, however, some good reasons for its existence
Sending a UDP datagram involves very little overhead in that there are no synchronization parameters, no priority options, no sequence numbers, no retransmit timers, no delayed acknowledgement timers, and no retransmission of packets The header is small; the protocol is quick, and streamlined functionally The only major drawback is that delivery is not guaranteed UDP is therefore used for communications that involve broadcasts, for general network announcements, or for real-time data A particularly good application is with streaming video and streaming audio where low transmission overheads are a prerequisite, and where retransmission of lost packets is not only unnecessary but also definitely undesirable
The format of the UDP frame and the interpretation of its fields are described RFC 768 The frame consists of a header plus data and contains the following fields:
Figure 7.7
UDP frame format
Source port: 16 bits
This is an optional field When meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information If not used, a value of zero is inserted
Destination port: 16 bits
As for source port
Message length: 16 bits
This is the length in bytes of this datagram including the header and the data (This means the minimum value of the length is eight.)