-
8/2/2019 IITA-0773-025
1/15
- 1 -
TP HTTP
* , ,
TCP FTP HTTP ATM
. Ka
3 ETRI CRL . FTP TCP
1Mbyte , 3Mbps .
TCP
, . TCP
TCP
. HTTP
, WWW HTTP 1.0 1.1
, . HTTP 1.0
TCP .
HTTP 1.1 Pipelining
. HTTP Pipelining
. HTTP 1.1 pipeling
.
TCP, , FTP, HTTP
Experiment results and analysis of FTP and HTTPtransmission
oversatellite network
Dong Joon Choi*
Seung Nam Choi Nae Soo Kim
ETRI
161 Kajong-Dong Yusong-Gu Taejeon, 305-350
TEL: 82-42-860-6477
E-Mail : [email protected]
-
8/2/2019 IITA-0773-025
2/15
- 2 -
AbstractIn this paper, we present and analyze the results of two
typical TCP applications -
FTP and HTTP - over ATM based satellite network. The
transmission of FTP and
HTTP was done via Ka band KOREASAT-3. In FTP experiment, we
measured the
throughput varying TCP window size. The maximum throughput of
file transfer was
about 3 Mbps when the TCP socket size was 1Mbytes. When the TCP
socket size
is more than 1 Mbytes, the throughput was degraded. In the case
of
memory-to-memory transfer over satellite channel, the throughput
mainly depends
on the TCP window. But when TCP buffer size was increased to
improve TCP
throughput in satellite network, the TCP application that needs
access to other
media such as FTP was affected by other various factors. In HTTP
experiment, we
measure the throughput of HTTP version 1.0 and 1.1 under
satellite network
condition. In HTTP 1.0, the web browser can open several TCP
connections
simultaneously to access the objects linked in web pages. But
HTTP 1.1 does not
permit the multiple TCP connection in a time. HTTP version 1.1
supports the
pipeline option. In the experiment, we measure the throughput of
HTTP with
various options in satellite network condition and analyzed the
internal behaviors.
HTTP 1.1 with pipelining option provided the best performance of
all HTTP version
and options.
key words TCP, Satellite, FTP, HTTP
1. IntroductionThere have been several efforts to develop
satellite communication core
technologies for next generation network and experiments to
measure the
performance and to demonstrate an appropriate application have
been done. As a
part of the efforts, domestic and international satellite
communication experiments
have been done. As a international experiments, Korea-Japan High
Data Rate
satellite communication experiment was started in 2000. The
first phase experiment
of the Joint Korea-Japan HDR satellite communication was
successfully completedby ETRI and CRL in Dec 2000. The second phase
experiment has done in March
2002. As an item of the second phase experiment, file transfer
and web page
access over 155Mbps satellite network have done.
In this paper, we present and analyze the results of two typical
TCP applications -
FTP and HTTP - over ATM based satellite network. First of all,
we describe
network configuration of the experiment in chapter 2. In chapter
3 and 4, we
describe a mechanism briefly and then present the result of the
experiment of the
two TCP applications.
-
8/2/2019 IITA-0773-025
3/15
- 3 -
2. Network ConfigurationFigure 1 shows the configurations of
Korea-Japan high-speed satellite ATM
network. In the joint experiment, the two ground stations with
7m antenna in ETRI,
Korea and 5m antenna in CRL, Japan were installed respectively.
The main
specifications of the Korea-Japan 155Mbps satellite ATM link are
as follows;
- Satellite: Koreasat-3
- Frequency band: Uplink : 27.5 ~ 31 , Downlink 17.7 ~ 21.2
- Max. TWTA power: 125W
- Normal EIRP (Koreasat-3): 71 W
- G/T (45 EL): 32 /K (min)
- TC-8PSK modulation/demodulation
- Coding: K=7, 7/8 Convolutional RS code
- Bit rate: 155.52Mbps
- Allocated Bandwidth: 80 two channels
The FTP and HTTP server was installed at laboratory of CRL using
a PC with
Linux system. The server was connected ATM network directly. In
ETRI, two client
PCs were installed using a Window 2000 and a Linux respectively.
They were
connected to PC router that had two network interfaces, ATM and
gigabit Ethernet.
A gigabit subnet and a server were interconnected through ATM
based satellite
network.
Figure 1 Network Configuration
-
8/2/2019 IITA-0773-025
4/15
- 4 -
3. FTP over OC-3 satellite linkFTP (File Transfer Protocol) is
the simplest and most secure way to exchange files
over the Internet. It is the protocol, or set of rules, which
enables files to be
transferred between computers. FTP works on the client/server
principle. A client
program enables the user to interact with a server in order to
access information
and services on the server computer. However FTP differs from
another TCP
applications in that it uses two TCP connections to transfer a
file. [1] One is
control connection, which is established in the normal
client-server fashion. The
server does a passive open on the port for FTP (21) and waits
for a client
connection. The client does active open to TCP port 21 to
establish the control
connection. The FTP commands from client to server and the
replies are
transferred using the control connection. Therefore the service
type of TCP
connection for FTP control commands is interactive and should be
configured to
minimize the transfer delay. A data connection is created each
time a file is
transferred between server and client. When the file transfer is
finished, the data
connection is released. Therefore the TCP connection for data
transfer should be
tuned to maximize throughput. Figure 1 shows the connections of
FTP and
processes of client and server.
Figure 2 Processes involved in file transfer [1]
-
8/2/2019 IITA-0773-025
5/15
- 5 -
In the FTP experiment, we measured the throughput for the data
connection of FTP
on the ATM based satellite network. There are many FTP server
and client
programs but for the experiment on long delay network such as
GEO satellite
network, it should support TCP socket buffer control. In the FTP
experiment, we
used NCFTP 3.0 as FTP client program and WUFTPD 2.6.1 for FTP
server
program. In the case of wuftpd, FTP server program, the maximum
TCP window
size of data connection is set to the value of operating system.
The FTP client
program, ncftp, supports the command that change the TCP window
size. For
comparison, we measured the FTP throughput in 155Mbps link
without satellite
delay and got the throughput of 118.32Mbps when the TCP socket
size is set to
64Kbytes. The throughput is 87.5% of theoretical throughput and
nearly the same
throughout to the prior TCP experiment results -
memory-to-memory TCP
throughput without satellite delay. When the file size is about
92.1Mbytes, wemeasured the file transfer throughput changing TCP
socket buffer size on GEO
satellite network. Figure 2 shows the result of file transfer
throughput.
Figure 3 FTP throughput over the 155Mbps satellite networkThere
are two graphs - one is the result in the laboratory using
satellite channel
simulator and the other is the result measured using Ka band
KOREASAT. The
throughput was very poor compared with the result of
memory-to-memory TCP
transmission throughput.[3] And the throughput was about 2Mbps
even though the
TCP socket buffer was increased more than 1Mbytes. In the case
of FTP, there are
many factors that result in less than desirable throughput; CPU
utilization, DISK I/O
and internal memory allocation for the network drivers and disk
drivers etc. The
network performance parameters of current operation system were
tuned without
considering large TCP socket buffer. That is, the increase of
TCP socket buffer
results in burst traffic not only the network but also internal
data path; for example
from network driver to disk.
-
8/2/2019 IITA-0773-025
6/15
- 6 -
As a result, it needs more system resources in each stage of
data transfer. Figure
2 and Figure 3 show TCP time sequence and TCP congestion window
graph when
TCP socket buffer size is 1Mbytes. During about 38 seconds the
file transfer was
normal. But after that time there were some data losses and
retransmission due to
data losses. Furthermore current TCP recognize the data losses
as network
congestion condition. We know that in Figure 4 TCP congestion
mechanism reduced
the TCP congestion window size to about half when there were
many data losses
and in Figure 3 there were another "slow start" after 38
seconds. As a result the
overall throughput was degraded severely. Therefore for the
normal operation of
file transfer with large TCP socket buffer in satellite network,
other system
parameters and resources (e.g. memory allocation for DISK IO and
network driver
interrupt) should be tuned.
Figure 4 TCP time sequence graph for data connection when TCP
buffer size is 1Mbytes
Figure 5 TCP congestion window graph for data connection when
TCP buffer sizeis 1Mbytes
-
8/2/2019 IITA-0773-025
7/15
- 7 -
4. HTTP over OC-3 satellite linkThere are several versions and
variations of HTTP used in server and clients on
the today's Internet. Of them, we consider the four type of
HTTP.
(1) HTTP 1.0 with non-persistent connectionsIn HTTP 1.0, to
browser a complete web page several TCP connections are
established to retrieve HTTP objects linked in a base web page
(HTML pages,
images etc.) This method of retrieving objects needs a number of
short TCP
connections on server and client. Figure 6 shows the
interactions between HTTP
1.0 client and server when a based page includes 3 inline
objects. First the base
HTML document is transferred via a TCP connection (Figure 6
(a)). After transfer
of the base document, the TCP connection is closed and three new
TCP
connections are established simultaneously for the parallel
download of three
objects linked (Figure 6 (b), (c), (d)). This has been shown to
be inefficient because
many TCP connections cause much traffic and also are burden to
server and client.
Figure 6 HTTP 1.0 - Non-persistent Connections(2) HTTP 1.0 with
persistent connectionsSome browsers and servers using HTTP 1.0
support "Keep-alive" option to
overcome the inefficiency described above. The method uses one
TCP connection
to carry multiple HTTP request. However many browsers using HTTP
1.0 with
keep-alive option establish multiple TCP connections. Figure 7
shows the operation
of HTTP connection with "Keep-alive" option. Through TCP
connection (a), base
document and one of 3 inline objects are transferred. Other two
objects are
transferred via 2 new TCP connections.
-
8/2/2019 IITA-0773-025
8/15
- 8 -
Figure 7 HTTP/1.0 - Persistent Connections(3) HTTP 1.1 without
pipeliningThe "Keep-Alive" extension, a form of persistent
connection, was formally defined
in HTTP 1.1.[5] Persistent connections allow multiple request
and responses can
be contained in a single TCP connection and HTTP 1.1 does not
use multiple TCP
connections. It has been shown that the performance of HTTP with
persistent
connections could be improved by avoiding multiple TCP
connection setup and
slow-start mechanism.[6] Figure 8 shows the mechanism of HTTP
1.1 which uses
persistent connection. One object is transferred after previous
transfer is finished.
In the case of a base HTML document and three inline objects, it
takes 4 RTT
times without pipelining.
Figure 8 HTTP 1.1 without pipelining(4) HTTP 1.1 with
pipeliningHTTP 1.1 with pipelining allows multiple requests to be
sent without waiting for a
response. The pipelining can be used to avoid many round trip
delays and improve
performance because this mechanism eliminates the empty time
between
consecutive object retrievals.
-
8/2/2019 IITA-0773-025
9/15
- 9 -
Figure 9 HTTP 1.1 with pipeliningFigure 9 shows the interactions
between server and client using HTTP 1.1 with
pipelining. A base document and three objects are transferred
through single TCP
connection. However before a complete transfer of an object,
transfer of other
objects can start.
The main goal of the HTTP experiment was to measure the
performance of WWW
page retrieval over satellite network using a number of types of
HTTP protocol.
That is, we tested HTTP 1.0 and HTTP 1.1 with various
configurations. For the
HTTP experiment, we used apache 1.3.12 as web server on Linux
system and set
TCP window size to 10Mbytes. And to investigate the internal
operation and the
performance of HTTP 1.0 and HTTP 1.1 with various options
supported, we used
three web browsers - Netscape 4.77 linux version for HTTP 1.0,
W3C's Webbot
5.2.8 for HTTP 1.1 and MS's Internet Explore 6.0 for HTTP 1.0
and HTTP 1.1.
Only MS Internet Explore 6.0 was run on MS window 2000 operating
system. When
web pages were retrieved by the client's request, all packets
that transferred were
captured at client side using tcpdump(or windump) and
post-processed using
tcptrace's HTTP module. Five typical web pages were used in the
HTTP
experiment and described in Table 1.
Table 1. Detail of pages
-
8/2/2019 IITA-0773-025
10/15
- 1 0 -
In Table 2, we summarized the results and performance of HTTP
transfer over the
satellite network for the five pages. In HTTP 1.1, only one TCP
connection is
permitted. Therefore when we used webbot, only one TCP
connections was
established. When Netscape was used, the number of TCP
connections
corresponding to the number of elements linked in primary web
page was
established. In the case of HTTP 1.0, each TCP connection is
independent of other
TCP connections. That is, each TCP connections undergo slow
start and congestion
avoidance mechanism. We know in Table 2 that when HTTP 1.0 was
used, more
packets were generated to transfer web page and linked elements.
The total
response time was smaller than HTTP 1.1 without pipelining
option. This means
that in long delay network if there is no network congestion,
the simultaneous
multiple TCP connection may be more effective than a single
connection. Especially
when the size of the elements is small, the data transfer using
multiple TCPconnection is more effective. However there are many
negative aspect (e.g.
burdens to server and network congestion due to more packets) of
using multiple
concurrent connections. When we measured the overall response
time and
transmission throughput for the 3 types of HTTP, HTTP 1.1 with
pipeline option
provided the best performance of all the HTTP versions in
long-delay satellite
network.
When the request for a web page is made, the browser issues an
HTTP GET
command for the base HTML document. One RTT later, the first
base document
data will be received. Then the browser issues further GET
commands for each
element linked in the base document. With pipelining option of
HTTP 1.1, these
GET commands can be generated as soon as the reference is
received by the
browser without waiting for the current data transfer from the
server to be
completed. In the case of HTTP 1.0 multiple TCP connections are
established for
the transfer of each elements. In figure 9, we show the sequence
of element
retrieval request and transfer for RBLAB page that consists of 7
elements. In figure
9, element 1 of (b), (c) means the time for whole transfer of
base page and
elements linked. Other numbers mean the time for the transfer of
each element.
Element 2 is the first document from web server at a request by
browser and its
transfer is same regardless of HTTP version or options. However
the following
elements have different transfer start and time depending on
HTTP version and
options. In the case of HTTP 1.0 (figure 9 (a)), when the base
documents were
received, the browser requested multiple GET for the elements
linked in base page.
Therefore a number of TCP connections were established using
3-way handshaking
and the connection request for each element were different. In
figure 9 (a), 4 TCP
connections were established first and some time later other 3
TCP connections
were established. When the RBLAB page was browsed by webbot with
pipelining
option, the transfer of the following elements started as soon
as base element was
received. Without pipelining option, when the transfer of one
element was
-
8/2/2019 IITA-0773-025
11/15
- 1 1 -
completed, the transfer of other elements started. In any case
of HTTP 1.1, only
one TCP connection is established. Hence there is one slow
start. Especially when
the pipelining option is used, several elements are transferred
as if one bulk data is
transferred.
-
8/2/2019 IITA-0773-025
12/15
- 1 2 -
Many experiment results show that bulk data transfer have good
performance in
LFN such as GEO satellite network. Therefore the HTTP 1.1 with
pipelining option
provides the best performance of all HTTP version and
options.
(a) HTTP 1.0 (netscape)
(b) HTTP 1.1 with pipelining (webbot)
-
8/2/2019 IITA-0773-025
13/15
- 1 3 -
(c) HTTP 1.1 with pipeliningFigure 10 RBLAB web page and its
elements transfer sequence graph
5. ConclusionIn this paper, we present and analyze the results
of two typical TCP applications -
FTP and HTTP - over ATM based satellite network.
In FTP experiment, we measured the throughput varying TCP window
size. The
maximum throughput of file transfer was about 3 Mbps when the
TCP socket size
was 1 Mbytes. When the TCP socket size is more than 1 Mbytes,
the throughputwas degraded. In the case of memory-to-memory
transfer over satellite channel,
the throughput mainly depends on the TCP window. But when TCP
buffer size was
increased to improve TCP throughput in satellite network, the
TCP application that
needs access to other media such as FTP was affected by other
various factors.
(DISK IO, system memory allocations etc.)
In HTTP 1.0, the web browser can open several TCP connections
simultaneously to
access the objects linked in web pages. But HTTP 1.1 does not
permit the multiple
TCP connection in a time. In the experiment, we measure the
throughput of two
versions of HTTP with various options in satellite network
condition and analyzed
the internal behaviors. As a result, HTTP 1.1 with pipelining
option provided the
best performance of all HTTP version and options.
The applications and operating systems used in today's Internet
are developed and
tuned with the assumption that they could be used in terrestrial
network. Therefore
for the satellite network to be used practically, the effects
due to long delay should
be investigated and tuned carefully at application-level as well
as transport level.
-
8/2/2019 IITA-0773-025
14/15
- 1 4 -
6. References[1] W. R. Stevens, TCP/IP Illustrated, Vol. 1.,
Addison-Wesley, 1996
[2] David E. Brooks, "ACTS 118 Final Report High Speed TCP
Interoperability
Testing", NASA/TM 1999-209272, 1999.
[3] D. J. Choi, N. S. Kim, "Performance measure and analysis of
large TCP window
effect in broadband network including GEO satellite network",
HSNMC02, 2002.
[4] Hans Kruse, "Experimentation and modeling of HTTP over
satellite channel"
International Journal of Satellite Communication
[5] R. Fielding, Hypertext Transfer protocol - HTTP/1.1, Jan.
1997. RFC 2068
[6] John Heidemann. Performance Interaction between P-HTTP and
TCP
Implementations. Computer Communication Review, 27(2) April
1997.
[7] http://www.w3.org/Protocols/HTTP/Performance
-
8/2/2019 IITA-0773-025
15/15
- 1 5 -
Table 2 HTTP transfer performance on satellite network
