2. cnp3-ebook
3. protocols/tcp
4. English
5. Zen

29 ../../protocols/tcp.rst:57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `TCP Header Length` (THL) or `Data Offset` field is a four bits field that indicates the size of the TCP header in 32 bit words. The maximum size of the TCP header is thus 64 bytes. 185/10000 · 185
30 ../../protocols/tcp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Optional header extension` is used to add optional information to the TCP header. Thanks to this header extension, it is possible to add new fields to the TCP header that were not planned in the original specification. This allowed TCP to evolve since the early eighties. The details of the TCP header extension are explained in sections :ref:`TCPOpen` and :ref:`TCPReliable`. 381/10000 · 381
31 ../../protocols/tcp.rst:99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The rest of this section is organized as follows. We first explain the establishment and the release of a TCP connection, then we discuss the mechanisms that are used by TCP to provide a reliable bytestream service. We end the section with a discussion of network congestion and explain the mechanisms that TCP uses to avoid congestion collapse. 345/10000 · 345
32 ../../protocols/tcp.rst:107
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connection establishment 28/10000 · 28
33 ../../protocols/tcp.rst:111
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A TCP connection is established by using a three-way handshake. The connection establishment phase uses the `sequence number`, the `acknowledgment number` and the `SYN` flag. When a TCP connection is established, the two communicating hosts negotiate the initial sequence number to be used in both directions of the connection. For this, each TCP entity maintains a 32 bits counter, which is supposed to be incremented by one at least every 4 microseconds and after each connection establishment [#ftcpclock]_. When a client host wants to open a TCP connection with a server host, it creates a TCP segment with : 612/10000 · 612
34 ../../protocols/tcp.rst:113 • ../../protocols/tcp.rst:118
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `SYN` flag set 18/10000 · 18
35 ../../protocols/tcp.rst:114
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `sequence number` set to the current value of the 32 bits counter of the client host's TCP entity 101/10000 · 101
36 ../../protocols/tcp.rst:116
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Upon reception of this segment (which is often called a `SYN segment`), the server host replies with a segment containing : 123/10000 · 123
37 ../../protocols/tcp.rst:119
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `sequence number` set to the current value of the 32 bits counter of the server host's TCP entity 101/10000 · 101
38 ../../protocols/tcp.rst:120 • ../../protocols/tcp.rst:126
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `ACK` flag set 18/10000 · 18
39 ../../protocols/tcp.rst:121
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `acknowledgment number` set to the `sequence number` of the received `SYN` segment incremented by 1 :math:`\pmod{2^{32}}`. When a TCP entity sends a segment having `x+1` as acknowledgment number, this indicates that it has received all data up to and including sequence number `x` and that it is expecting data having sequence number `x+1`. As the `SYN` flag was set in a segment having sequence number `x`, this implies that setting the `SYN` flag in a segment consumes one sequence number. 495/10000 · 495
40 ../../protocols/tcp.rst:124
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This segment is often called a `SYN+ACK` segment. The acknowledgment confirms to the client that the server has correctly received the `SYN` segment. The `sequence number` of the `SYN+ACK` segment is used by the server host to verify that the `client` has received the segment. Upon reception of the `SYN+ACK` segment, the client host replies with a segment containing : 370/10000 · 370
41 ../../protocols/tcp.rst:127
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}` 129/10000 · 129
42 ../../protocols/tcp.rst:129
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, the TCP connection is open and both the client and the server are allowed to send TCP segments containing data. This is illustrated in the figure below. 167/10000 · 167
43 ../../protocols/tcp.rst:135
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Establishment of a TCP connection 33/10000 · 33
44 ../../protocols/tcp.rst:137
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the figure above, the connection is considered to be established by the client once it has received the `SYN+ACK` segment, while the server considers the connection to be established upon reception of the `ACK` segment. The first data segment sent by the client (server) has its `sequence number` set to `x+1` (resp. `y+1`). 327/10000 · 327
45 ../../protocols/tcp.rst:141
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Computing TCP's initial sequence number 39/10000 · 39
46 ../../protocols/tcp.rst:143
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the original TCP specification :rfc:`793`, each TCP entity maintained a clock to compute the initial sequence number (:term:`ISN`) placed in the `SYN` and `SYN+ACK` segments. This made the ISN predictable and caused a security issue. The typical security problem was the following. Consider a server that trusts a host based on its IP address and allows the system administrator to log in from this host without giving a password [#frlogin]_. Consider now an attacker who knows this particular configuration and is able to send IP packets having the client's address as source. He can send fake TCP segments to the server, but does not receive the server's answers. If he can predict the `ISN` that is chosen by the server, he can send a fake `SYN` segment and shortly after the fake `ACK` segment confirming the reception of the `SYN+ACK` segment sent by the server. Once the TCP connection is open, he can use it to send any command to the server. To counter this attack, current TCP implementations add randomness to the `ISN`. One of the solutions, proposed in :rfc:`1948` is to compute the `ISN` as :: 1109/10000 · 1109
47 ../../protocols/tcp.rst:147
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — where `M` is the current value of the TCP clock and `H` is a cryptographic hash function. `localhost` and `remotehost` (resp. `localport` and `remoteport` ) are the IP addresses (port numbers) of the local and remote host and `secret` is a random number only known by the server. This method allows the server to use different ISNs for different clients at the same time. `Measurements <http://lcamtuf.coredump.cx/newtcp/>`_ performed with the first implementations of this technique showed that it was difficult to implement it correctly, but today's TCP implementation now generate good ISNs. 594/10000 · 594
48 ../../protocols/tcp.rst:151
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A server could, of course, refuse to open a TCP connection upon reception of a `SYN` segment. This refusal may be due to various reasons. There may be no server process that is listening on the destination port of the `SYN` segment. The server could always refuse connection establishments from this particular client (e.g. due to security reasons) or the server may not have enough resources to accept a new TCP connection at that time. In this case, the server would reply with a TCP segment having its `RST` flag set and containing the `sequence number` of the received `SYN` segment incremented by one as its `acknowledgment number`. This is illustrated in the figure below. We discuss the other usages of the TCP `RST` flag later (see :ref:`TCPRelease`). 759/10000 · 759