Unit:1
1.1 Introduction to Network Programming
1.1.1 OSI Model
A common way to describe the layers in a network is to use the
International Organization for Standardization (ISO) Open Systems
Interconnection (OSI) model for computer communications. This is a
seven-layer model.
We consider the bottom two layers of the OSI model as the device driver
and networking hardware that are supplied with the system.
The network layer is handled by the IPv4 and IPv6 protocols.
The transport layers that we can choose from are TCP and UDP. We show a
gap between TCP and UDP to indicate that it is possible for an application to
bypass the transport layer and use IPv4 or IPv6 directly. This is called a
raw socket.
The upper three layers of the OSI model are combined into a single layer
called the application.
This is the Web client (browser), Telnet client, Web server, FTP server, or
whatever application we are using.
With the Internet protocols, there is rarely any distinction between the upper
three layers of the OSI model.
The upper three layers handle all the details of the application (FTP,
Telnet, or HTTP, for example) and know little about the communication
details.
The lower four layers know little about the application, but handle all the
communication details: sending data, waiting for acknowledgments,
sequencing data that arrives out of order, calculating and verifying
checksums, and so on.
The upper three layers often form what is called a user process while the
lower four layers are normally provided as part of the operating system
(OS) kernel.
Unix provides this separation between the user process and the kernel, as do
many other contemporary operating systems.
Therefore, the interface between layers 4 and 5 is the natural place to build
the API.
1.1.2 Transmission Control Protocol (TCP)
TCP provides connections between clients and servers.
A TCP client establishes a connection with a given server, exchanges data
with that server across the connection, and then terminates the connection.
TCP also provides reliability.
When TCP sends data to the other end, it requires an acknowledgment in
return.
If an acknowledgment is not received, TCP automatically retransmits
the data and waits a longer amount of time.
After some number of retransmissions, TCP will give up, with the total
amount of time spent trying to send data typically between 4 and 10
minutes (depending on the implementation).
TCP does not guarantee that the data will be received by the other
endpoint, as this is impossible.
It delivers data to the other endpoint if possible, and notifies the user
(by giving up on retransmissions and breaking the connection) if it is
not possible.
Therefore, TCP cannot be described as a 100% reliable protocol; it
provides reliable delivery of data or reliable notification of failure.
TCP contains algorithms to estimate the round-trip time (RTT) between a
client and server dynamically so that it knows how long to wait for an
acknowledgment.
For example, the RTT on a LAN can be milliseconds while across a
WAN, it can be seconds.
Furthermore, TCP continuously estimates the RTT of a given connection,
because the RTT is affected by variations in the network traffic.
TCP also sequences the data by associating a sequence number with every byte
that it sends.
For example, assume an application writes 2,048 bytes to a TCP
socket, causing TCP to send two segments, the first containing the
data with sequence numbers 1–1,024 and the second containing the
data with sequence numbers 1,025–2,048. (A segment is the unit of
data that TCP passes to IP.)
If the segments arrive out of order, the receiving TCP will reorder the
two segments based on their sequence numbers before passing the
data to the receiving application.
If TCP receives duplicate data from its peer (say the peer thought a
segment was lost and retransmitted it, when it wasn't really lost, the
network was just overloaded), it can detect that the data has been
duplicated (from the sequence numbers), and discard the duplicate
data.
TCP provides flow control.
TCP always tells its peer exactly how many bytes of data it is willing to
accept from the peer at any one time. This is called the advertised
window.
At any time, the window is the amount of room currently available in
the receive buffer, guaranteeing that the sender cannot overflow the
receive buffer.
The window changes dynamically over time: As data is received from
the sender, the window size decreases, but as the receiving application
reads data from the buffer, the window size increases.
It is possible for the window to reach 0: when TCP's receive buffer for
a socket is full and it must wait for the application to read data from
the buffer before it can take any more data from the peer.
Finally, a TCP connection is full-duplex.
This means that an application can send and receive data in both
directions on a given connection at any time.
This means that TCP must keep track of state information such as
sequence numbers and window sizes for each direction of data flow:
sending and receiving.
After a full-duplex connection is established, it can be turned into a
simplex connection if desired.
1.1.3 User Datagram Protocol (UDP)
UDP is a simple transport-layer protocol. It is described in RFC 768 [Postel
1980].
The application writes a message to a UDP socket, which is then
encapsulated in a UDP datagram, which is then further encapsulated as
an IP datagram, which is then sent to its destination.
There is no guarantee that a UDP datagram will ever reach its final
destination, that order will be preserved across the network, or that
datagrams arrive only once.
The problem that we encounter with network programming using UDP is its
lack of reliability.
If a datagram reaches its final destination but the checksum detects
an error, or if the datagram is dropped in the network, it is not
delivered to the UDP socket and is not automatically retransmitted.
If we want to be certain that a datagram reaches its destination, we
can build lots of features into our application: acknowledgments from
the other end, timeouts, retransmissions, and the like.
Each UDP datagram has a length.
The length of a datagram is passed to the receiving application along with the
data.
We also say that UDP provides a connectionless service, as there need not
be any long-term relationship between a UDP client and server.
For example, a UDP client can create a socket and send a datagram to
a given server and then immediately send another datagram on the
same socket to a different server.
Similarly, a UDP server can receive several datagrams on a single UDP
socket, each from a different client.
UDP provides no flow control.
It is easy for a fast UDP sender to transmit datagrams at a rate that
the UDP receiver cannot keep up with
UDP can be full-duplex.
1.1.4 TCP Connection Establishment and Termination
A. TCP State Transition Diagram
The operation of TCP with regard to connection establishment and
connection termination can be specified with a state transition diagram. We
show this in below figure.
There are 11 different states defined for a connection and the rules of TCP
dictate the transitions from one state to another, based on the current state
and the segment received in that state.
For example, if an application performs an active open in the CLOSED
state, TCP sends a SYN and the new state is SYN_SENT.
If TCP next receives a SYN with an ACK, it sends an ACK and the new
state is ESTABLISHED. This final state is where most data transfer
occurs.
The two arrows leading from the ESTABLISHED state deal with the
termination of a connection.
If an application calls close before receiving a FIN (an active close), the
transition is to the FIN_WAIT_1 state.
But if an application receives a FIN while in the ESTABLISHED state
(a passive close), the transition is to the CLOSE_WAIT state.
We denote the normal client transitions with a darker solid line and
the normal server transitions with a darker dashed line.
A simultaneous open: when both ends send SYNs at about the same
time and the SYNs cross in the network) and a simultaneous close
(when both ends send FINs at the same time).
One reason for showing the state transition diagram is to show the 11
TCP states with their names.
These states are displayed by netstat, which is a useful tool when
debugging client/server applications.
B. TCP State Transition Diagram
TCP is a connection oriented protocol and every connection oriented protocol
needs to establish connection in order to reserve resources at both the
communicating ends.
To establish a connection, TCP uses a three-way handshake.
Three-Way Handshake: The following scenario occurs when a TCP connection
is established:
The server must be prepared to accept an incoming connection. This
is normally done by calling socket, bind, and listen and is called a
passive open.
The client issues an active open by calling connect. This causes the
client TCP to send a "synchronize" (SYN) segment, which tells the
server the client's initial sequence number for the data that the client
will send on the connection. Normally, there is no data sent with the
SYN; it just contains an IP header, a TCP header, and possible TCP
options (which we will talk about shortly).
The server must acknowledge (ACK) the client's SYN and the server
must also send its own SYN containing the initial sequence number
for the data that the server will send on the connection. The server
sends its SYN and the ACK of the client's SYN in a single segment.
The client must acknowledge the server's SYN.
The minimum number of packets required for this exchange is three; hence,
this is called TCP's three-way handshake.
We show the client's initial sequence number as J and the server's initial
sequence number as K.
The acknowledgment number in an ACK is the next expected sequence
number for the end sending the ACK.
Since a SYN occupies one byte of the sequence number space, the
acknowledgment number in the ACK of each SYN is the initial sequence
number plus one.
Similarly, the ACK of each FIN is the sequence number of the FIN plus one.
C. TCP Connection Termination
While it takes three segments to establish a connection, it takes four to
terminate a connection.
One application calls close first, and we say that this end performs the
active close. This end's TCP sends a FIN segment, which means it is
finished sending data.
The other end that receives the FIN performs the passive close. The
received FIN is acknowledged by TCP. The receipt of the FIN is also
passed to the application as an end-of-file (after any data that may
have already been queued for the application to receive), since the
receipt of the FIN means the application will not receive any additional
data on the connection.
Sometime later, the application that received the end-of-file will close
its socket. This causes its TCP to send a FIN.
The TCP on the system that receives this final FIN (the end that did
the active close) acknowledges the FIN.
Since a FIN and an ACK are required in each direction, four segments are
normally required.
We use the qualifier "normally" because in some scenarios, the FIN in Step 1 is
sent with data.
Also, the segments in Steps 2 and 3 are both from the end performing the
passive close and could be combined into one segment.
A FIN occupies one byte of sequence number space just like a SYN.
Therefore, the ACK of each FIN is the sequence number of the FIN plus one.
Between Steps 2 and 3 it is possible for data to flow from the end doing the
passive close to the end doing the active close. This is called a half-close.
The sending of each FIN occurs when a socket is closed. We indicated that
the application calls close for this to happen, but realize that when a Unix
process terminates, either voluntarily (calling exit or having the main
function return) or involuntarily (receiving a signal that terminates the
process), all open descriptors are closed, which will also cause a FIN to be
sent on any TCP connection that is still open.
Although we show the client performing the active close, either end—the
client or the server—can perform the active close.
Often the client performs the active close, but with some protocols (notably
HTTP/1.0), the server performs the active close.
1.1.5 Buffer Sizes and Limitations
Certain limits affect the size of IP datagrams. We first describe these limits
and then tie them all together with regard to how they affect the data an
application can transmit.
The maximum size of an IPv4 datagram is 65,535 bytes, including the
IPv4 header. This is because of the 16-bit total length field.
The maximum size of an IPv6 datagram is 65,575 bytes, including the
40-byte IPv6 header. This is because of the 16-bit payload length field.
Notice that the IPv6 payload length field does not include the
size of the IPv6 header, while the IPv4 total length field does
include the header size.
IPv6 has a jumbo payload option, which extends the payload
length field to 32 bits, but this option is supported only on
datalinks with a maximum transmission unit (MTU) that
exceeds 65,535.
Many networks have an MTU which can be dictated by the hardware.
For example, the Ethernet MTU is 1,500 bytes. Other datalinks,
such as point-to-point links using the Point-to-Point Protocol
(PPP), have a configurable MTU.
Older SLIP links often used an MTU of 1,006 or 296 bytes. The
minimum link MTU for IPv4 is 68 bytes.
This permits a maximum-sized IPv4 header (20 bytes of fixed
header, 30 bytes of options) and minimum-sized fragment the
fragment offset is in units of 8 bytes).
The minimum link MTU for IPv6 is 1,280 bytes. IPv6 can run
over links with a smaller MTU, but requires link-specific
fragmentation and reassembly to make the link appear to have
an MTU of at least 1,280 bytes.
The smallest MTU in the path between two hosts is called the path MTU.
Today, the Ethernet MTU of 1,500 bytes is often the path MTU.
The path MTU need not be the same in both directions between
any two hosts because routing in the Internet is often
asymmetric [Paxson 1996].
That is, the route from A to B can differ from the route from B to
A.
When an IP datagram is to be sent out an interface, if the size of the
datagram exceeds the link MTU, fragmentation is performed by both
IPv4 and IPv6.
The fragments are not normally reassembled until they reach
the final destination.
IPv4 hosts perform fragmentation on datagrams that they
generate and IPv4 routers perform fragmentation on datagrams
that they forward.
But with IPv6, only hosts perform fragmentation on datagrams
that they generate; IPv6 routers do not fragment datagrams
that they are forwarding.
IPv4 and IPv6 define a minimum reassembly buffer size, the minimum
datagram size that we are guaranteed any implementation must
support.
For IPv4, this is 576 bytes.
IPv6 raises this to 1,500 bytes.
TCP has a maximum segment size (MSS) that announces to the peer
TCP the maximum amount of TCP data that the peer can send per
segment.
SCTP keeps a fragmentation point based on the smallest path MTU
found to all the peer's addresses.
This smallest MTU size is used to split large user messages into
smaller pieces that can be sent in one IP datagram.
The SCTP_MAXSEG socket option can influence this value,
allowing the user to request a smaller fragmentation point.
1.1.6 Standard Internet Services
Below figure lists several standard services that are provided by most
implementations of TCP/IP. Notice that all are provided using both TCP and UDP and
the port number is the same for both protocols.
Figure: Standard TCP/IP services provided by most implementations.
In these two examples, we type the name of the host and the name of the service
(daytime and echo). These service names are mapped into the port numbes
Notice that when we connect to the daytime server, the server performs the active
close, while with the echo server, the client performs the active close. Recall from
Figure 2.4 that the end performing the active close is the end that goes through the
TIME_WAIT state.
These "simple services" are often disabled by default on modern systems due to
denial-of-service and other resource utilization attacks against them.
1.1.7 Protocol Usage by Common Internet Applications
Below summarizes the protocol usage of various common Internet applications.
Figure: Protocol usage of various common Internet applications.
The first two applications, ping and traceroute, are diagnostic applications that use
ICMP. traceroute builds its own UDP packets to send and reads ICMP replies.
The three popular routing protocols demonstrate the variety of transport protocols
used by routing protocols. OSPF uses IP directly, employing a raw socket, while RIP
uses UDP and BGP uses TCP.
The next five are UDP-based applications, followed by seven TCP applications and
four that use both UDP and TCP. The final five are IP telephony applications that use
SCTP exclusively or optionally UDP, TCP, or SCTP.
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner
Scanned by CamScanner