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

161 ../../protocols/tcp.rst:531
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A SACK option contains one or more blocks. A block corresponds to all the sequence numbers between the `left edge` and the `right edge` of the block. The two edges of the block are encoded as 32 bit numbers (the same size as the TCP sequence number) in an SACK option. As the SACK option contains one byte to encode its type and one byte for its length, a SACK option containing `b` blocks is encoded as a sequence of :math:`2+8 \times b` bytes. In practice, the size of the SACK option can be problematic as the optional TCP header extension cannot be longer than 40 bytes. As the SACK option is usually combined with the :rfc:`1323` timestamp extension, this implies that a TCP segment cannot usually contain more than three SACK blocks. This limitation implies that a TCP receiver cannot always place in the SACK option that it sends, information about all the received blocks. 880/10000 · 880
162 ../../protocols/tcp.rst:533
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To deal with the limited size of the SACK option, a TCP receiver currently having more than 3 blocks inside its receiving buffer must select the blocks to place in the SACK option. A good heuristic is to put in the SACK option the blocks that have most recently changed, as the sender is likely to be already aware of the older blocks. 335/10000 · 335
163 ../../protocols/tcp.rst:535
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a sender receives a SACK option indicating a new block and thus a new possible segment loss, it usually does not retransmit the missing segments immediately. To deal with reordering, a TCP sender can use a heuristic similar to `fast retransmit` by retransmitting a gap only once it has received three SACK options indicating this gap. It should be noted that the SACK option does not supersede the `acknowledgment number` of the TCP header. A TCP sender can only remove data from its sending buffer once they have been acknowledged by TCP's cumulative acknowledgments. This design was chosen for two reasons. First, it allows the receiver to discard parts of its receiving buffer when it is running out of memory without loosing data. Second, as the SACK option is not transmitted reliably, the cumulative acknowledgments are still required to deal with losses of `ACK` segments carrying only SACK information. Thus, the SACK option only serves as a hint to allow the sender to optimize its retransmissions. 1012/10000 · 1012
164 ../../protocols/tcp.rst:537
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As explained earlier, the TCP Timestamp option :rfc:`1323` prevents ambiguities while collecting round-trip-time measurements. It plays another very important role in today's high-bandwidth networks. Since TCP uses 32 bits long sequence numbers, the sequence numbers wrap after the transmission of 4 GBytes of data. With 10 Gbps and soon 100 Gbps interfaces, TCP only needs to transmit during a few seconds before reusing the same sequence number. Given that the Maximum Segment Lifetime is still 2 minutes, several packets, belonging to the same TCP connection could use the same sequence number. If one of these packets is severely delayed through the network, it could reappear at the same time as a packet with the same TCP sequence number. To prevent this problem, most modern TCP implementations associate a TCP timestamp option to each segment on transmission. When a TCP stack receives a TCP segment, it checks that its TCP timestamp is valid and if not the segment is discarded :rfc:`7323`. 999/10000 · 999
165 ../../protocols/tcp.rst:544
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP connection release 22/10000 · 22
166 ../../protocols/tcp.rst:548
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP, like most connection-oriented transport protocols, supports two types of connection releases : 99/10000 · 99
167 ../../protocols/tcp.rst:550
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — graceful connection release, where each TCP user can release its own direction of data transfer after having transmitted all data 129/10000 · 129
168 ../../protocols/tcp.rst:551
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — abrupt connection release, where either one user closes both directions of data transfer or one TCP entity is forced to close the connection (e.g., because the remote host does not reply anymore or due to lack of resources) 223/10000 · 223
169 ../../protocols/tcp.rst:555
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The abrupt connection release mechanism is very simple and relies on a single segment having the `RST` bit set. A TCP segment containing the `RST` bit can be sent for the following reasons : 190/10000 · 190
170 ../../protocols/tcp.rst:557
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a non-`SYN` segment was received for a non-existing TCP connection :rfc:`793` 77/10000 · 77
171 ../../protocols/tcp.rst:558
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — by extension, some implementations respond with an `RST` segment to a segment that is received on an existing connection but with an invalid header :rfc:`3360`. This causes the corresponding connection to be closed and has caused security attacks :rfc:`4953` 258/10000 · 258
172 ../../protocols/tcp.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — by extension, some implementations send an `RST` segment when they need to close an existing TCP connection (e.g., because there are not enough resources to support this connection or because the remote host is considered to be unreachable). Measurements have shown that this usage of TCP `RST` is widespread [AW05]_ 316/10000 · 316
173 ../../protocols/tcp.rst:561
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When an `RST` segment is sent by a TCP entity, it should contain the current value of the `sequence number` for the connection (or 0 if it does not belong to any existing connection) and the `acknowledgment number` should be set to the next expected in-sequence `sequence number` on this connection. 299/10000 · 299
174 ../../protocols/tcp.rst:563
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP `RST` wars 14/10000 · 14
175 ../../protocols/tcp.rst:567
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The designers of TCP implementations should ensure that two TCP entities never enter a TCP `RST` war where host `A` is sending a `RST` segment in response to a previous `RST` segment that was sent by host `B` in response to a TCP `RST` segment sent by host `A` ... To avoid such an infinite exchange of `RST` segments that do not carry data, a TCP entity is *never* allowed to send a `RST` segment in response to another `RST` segment. 435/10000 · 435
176 ../../protocols/tcp.rst:570
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The normal way of terminating a TCP connection is by using the graceful TCP connection release. This mechanism uses the `FIN` flag of the TCP header and allows each host to release its own direction of data transfer. As for the `SYN` flag, the utilization of the `FIN` flag in the TCP header consumes one sequence number. The figure :ref:`fig-tcprelease` shows the part of the TCP FSM used when a TCP connection is released. 424/10000 · 424
177 ../../protocols/tcp.rst:603
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Starting from the `Established` state, there are two main paths through this FSM. 81/10000 · 81
178 ../../protocols/tcp.rst:605
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first path is when the host receives a segment with sequence number `x` and the `FIN` flag set. The utilization of the `FIN` flag indicates that the byte before `sequence number` `x` was the last byte of the byte stream sent by the remote host. Once all of the data has been delivered to the user, the TCP entity sends an `ACK` segment whose `ack` field is set to :math:`(x+1) \pmod{2^{32}}` to acknowledge the `FIN` segment. The `FIN` segment is subject to the same retransmission mechanisms as a normal TCP segment. In particular, its transmission is protected by the retransmission timer. At this point, the TCP connection enters the `CLOSE\_WAIT` state. In this state, the host can still send data to the remote host. Once all its data have been sent, it sends a `FIN` segment and enter the `LAST\_ACK` state. In this state, the TCP entity waits for the acknowledgment of its `FIN` segment. It may still retransmit unacknowledged data segments, e.g., if the retransmission timer expires. Upon reception of the acknowledgment for the `FIN` segment, the TCP connection is completely closed and its :term:`TCB` can be discarded. 1133/10000 · 1133
179 ../../protocols/tcp.rst:607
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second path is when the host has transmitted all data. Assume that the last transmitted sequence number is `z`. Then, the host sends a `FIN` segment with sequence number :math:`(z+1) \pmod{2^{32}}` and enters the `FIN_WAIT1` state. In this state, it can retransmit unacknowledged segments but cannot send new data segments. It waits for an acknowledgment of its `FIN` segment (i.e. sequence number :math:`(z+1) \pmod{2^{32}}`), but may receive a `FIN` segment sent by the remote host. In the first case, the TCP connection enters the `FIN\_WAIT2` state. In this state, new data segments from the remote host are still accepted until the reception of the `FIN` segment. The acknowledgment for this `FIN` segment is sent once all data received before the `FIN` segment have been delivered to the user and the connection enters the `TIME\_WAIT` state. In the second case, a `FIN` segment is received and the connection enters the `Closing` state once all data received from the remote host have been delivered to the user. In this state, no new data segments can be sent and the host waits for an acknowledgment of its `FIN` segment before entering the `TIME\_WAIT` state. 1174/10000 · 1174
180 ../../protocols/tcp.rst:609
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `TIME\_WAIT` state is different from the other states of the TCP FSM. A TCP entity enters this state after having sent the last `ACK` segment on a TCP connection. This segment indicates to the remote host that all the data that it has sent have been correctly received and that it can safely release the TCP connection and discard the corresponding :term:`TCB`. After having sent the last `ACK` segment, a TCP connection enters the `TIME\_WAIT` and remains in this state for :math:`2*MSL` seconds. During this period, the TCB of the connection is maintained. This ensures that the TCP entity that sent the last `ACK` maintains enough state to be able to retransmit this segment if this `ACK` segment is lost and the remote host retransmits its last `FIN` segment or another one. The delay of :math:`2*MSL` seconds ensures that any duplicate segments on the connection would be handled correctly without causing the transmission of an `RST` segment. Without the `TIME\_WAIT` state and the :math:`2*MSL` seconds delay, the connection release would not be graceful when the last `ACK` segment is lost. 1102/10000 · 1102