Exit Zen
7
../../protocols/tcp.rst:19
English
remote computer access : :term:`telnet`, :term:`ssh`, :term:`X11`, :term:`VNC`, ...
0/830 · 83
8
../../protocols/tcp.rst:20
English
non-interactive multimedia applications (flash, ...)
0/520 · 52
9
../../protocols/tcp.rst:22
English
On the global Internet, most of the applications used in the wide area rely on TCP. Many studies [#ftcpusage]_ have reported that TCP was responsible for more than 90% of the data exchanged in the global Internet.
0/2130 · 213
10
../../protocols/tcp.rst:26
English
To provide this service, TCP relies on a simple segment format that is shown in the figure below. Each TCP segment contains a header described below and, optionally, a payload. The default length of the TCP header is twenty bytes, but some TCP headers contain options.
0/2680 · 268
11
../../protocols/tcp.rst:32
English
TCP header format
0/170 · 17
12
../../protocols/tcp.rst:35
English
A TCP header contains the following fields :
0/440 · 44
13
../../protocols/tcp.rst:37
English
the `source and destination ports`. The source and destination ports play an important role in TCP, as they allow the identification of the connection to which a TCP segment belongs. When a client opens a TCP connection, it typically selects an ephemeral TCP port number as its source port and contacts the server by using the server's port number. All the segments that are sent by the client on this connection have the same source and destination ports. The server sends segments that contain as source (resp. destination) port, the destination (resp. source) port of the segments sent by the client (see figure :ref:`fig-tcpports`). A TCP connection is always identified by four pieces of information :
0/7060 · 706
14
../../protocols/tcp.rst:39
English
the address of the client
0/250 · 25
15
../../protocols/tcp.rst:40
English
the address of the server
0/250 · 25
16
../../protocols/tcp.rst:41
English
the port chosen by the client
0/290 · 29
17
../../protocols/tcp.rst:42
English
the port chosen by the server
0/290 · 29
18
../../protocols/tcp.rst:44
English
the `sequence number` (32 bits), `acknowledgment number` (32 bits) and `window` (16 bits) fields are used to provide a reliable data transfer, using a window-based protocol. In a TCP bytestream, each byte of the stream consumes one sequence number. Their usage is described in more detail in section :ref:`TCPReliable`
0/3180 · 318
19
../../protocols/tcp.rst:45
English
the `Urgent pointer` is used to indicate that some data should be considered as urgent in a TCP bytestream. However, it is rarely used in practice and will not be described here. Additional details about the utilization of this pointer may be found in :rfc:`793`, :rfc:`1122` or [Stevens1994]_
0/2930 · 293
20
../../protocols/tcp.rst:46
English
the flags field contains a set of bit flags that indicate how a segment should be interpreted by the TCP entity receiving it :
0/1260 · 126
21
../../protocols/tcp.rst:48
English
the `SYN` flag is used during connection establishment
0/540 · 54
22
../../protocols/tcp.rst:49
English
the `FIN` flag is used during connection release
0/480 · 48
23
../../protocols/tcp.rst:50
English
the `RST` is used in case of problems or when an invalid segment has been received
0/820 · 82
24
../../protocols/tcp.rst:51
English
when the `ACK` flag is set, it indicates that the `acknowledgment` field contains a valid number. Otherwise, the content of the `acknowledgment` field must be ignored by the receiver
0/1820 · 182
25
../../protocols/tcp.rst:52
English
the `URG` flag is used together with the `Urgent pointer`
0/570 · 57
26
../../protocols/tcp.rst:53
English
the `PSH` flag is used as a notification from the sender to indicate to the receiver that it should pass all the data it has received to the receiving process. However, in practice TCP implementations do not allow TCP users to indicate when the `PSH` flag should be set.
0/2700 · 270