<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="425ac15ce0399d17" weblate-flags="read-only">
        <source>The Transmission Control Protocol</source>
        <target state="translated">The Transmission Control Protocol</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">9</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e3bc6c847e9b5990" weblate-flags="read-only">
        <source>The Transmission Control Protocol (TCP) was initially defined in :rfc:`793`. Several parts of the protocol have been improved since the publication of the original protocol specification [#ftcpspecs]_. However, the basics of the protocol remain and an implementation that only supports :rfc:`793` should inter-operate with today's implementation.</source>
        <target state="translated">The Transmission Control Protocol (TCP) was initially defined in :rfc:`793`. Several parts of the protocol have been improved since the publication of the original protocol specification [#ftcpspecs]_. However, the basics of the protocol remain and an implementation that only supports :rfc:`793` should inter-operate with today's implementation.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">12</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="98c9e10e449792dc" weblate-flags="read-only">
        <source>TCP provides a reliable bytestream, connection-oriented transport service on top of the unreliable connectionless network service provided by :term:`IP`. TCP is used by a large number of applications, including :</source>
        <target state="translated">TCP provides a reliable bytestream, connection-oriented transport service on top of the unreliable connectionless network service provided by :term:`IP`. TCP is used by a large number of applications, including :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">14</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5e1ff2ea6e76359a" weblate-flags="read-only">
        <source>Email (:term:`SMTP`, :term:`POP`, :term:`IMAP`)</source>
        <target state="translated">Email (:term:`SMTP`, :term:`POP`, :term:`IMAP`)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">16</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e69a2a552aac699c" weblate-flags="read-only">
        <source>World wide web ( :term:`HTTP`, ...)</source>
        <target state="translated">World wide web ( :term:`HTTP`, ...)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">17</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bfab45ea39a14579" weblate-flags="read-only">
        <source>Most file transfer protocols ( :term:`ftp`, peer-to-peer file sharing applications , ...)</source>
        <target state="translated">Most file transfer protocols ( :term:`ftp`, peer-to-peer file sharing applications , ...)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">18</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="226b3ca2bbb4e6d6" weblate-flags="read-only">
        <source>remote computer access : :term:`telnet`, :term:`ssh`, :term:`X11`, :term:`VNC`, ...</source>
        <target state="translated">remote computer access : :term:`telnet`, :term:`ssh`, :term:`X11`, :term:`VNC`, ...</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">19</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0b1997f320dccf2d" weblate-flags="read-only">
        <source>non-interactive multimedia applications (flash, ...)</source>
        <target state="translated">non-interactive multimedia applications (flash, ...)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">20</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7bb7737c3d285eb8" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">22</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d54aa7d091e5bcb3" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">26</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1701a4faf8c617c6" weblate-flags="read-only">
        <source>TCP header format</source>
        <target state="translated">TCP header format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">32</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6f9408cc5390f6b8" weblate-flags="read-only">
        <source>A TCP header contains the following fields :</source>
        <target state="translated">A TCP header contains the following fields :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">35</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6d50ec6430546cf1" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">37</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="890925d0e12bdf97" weblate-flags="read-only">
        <source>the address of the client</source>
        <target state="translated">the address of the client</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">39</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="06a84d7b15129235" weblate-flags="read-only">
        <source>the address of the server</source>
        <target state="translated">the address of the server</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">40</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="de5c745afd4fd32d" weblate-flags="read-only">
        <source>the port chosen by the client</source>
        <target state="translated">the port chosen by the client</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">41</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70cf2502d3b76ce9" weblate-flags="read-only">
        <source>the port chosen by the server</source>
        <target state="translated">the port chosen by the server</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">42</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dd54fbc3d3c09b64" weblate-flags="read-only">
        <source>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`</source>
        <target state="translated">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`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">44</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="929ed16084f53fb3" weblate-flags="read-only">
        <source>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]_</source>
        <target state="translated">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]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">45</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="864e01a218929d12" weblate-flags="read-only">
        <source>the flags field contains a set of bit flags that indicate how a segment should be interpreted by the TCP entity receiving it :</source>
        <target state="translated">the flags field contains a set of bit flags that indicate how a segment should be interpreted by the TCP entity receiving it :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">46</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8b0f4d8f65a75f3d" weblate-flags="read-only">
        <source>the `SYN` flag is used during connection establishment</source>
        <target state="translated">the `SYN` flag is used during connection establishment</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">48</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eb92a13288368fd1" weblate-flags="read-only">
        <source>the `FIN` flag is used during connection release</source>
        <target state="translated">the `FIN` flag is used during connection release</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">49</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="30853f7599f0db88" weblate-flags="read-only">
        <source>the `RST` is used in case of problems or when an invalid segment has been received</source>
        <target state="translated">the `RST` is used in case of problems or when an invalid segment has been received</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">50</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dca5c74e7c7c558d" weblate-flags="read-only">
        <source>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</source>
        <target state="translated">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</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">51</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4fe45bb8c810bbea" weblate-flags="read-only">
        <source>the `URG` flag is used together with the `Urgent pointer`</source>
        <target state="translated">the `URG` flag is used together with the `Urgent pointer`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f303c43067eb91d2" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">53</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ab3a29e097441e43" weblate-flags="read-only">
        <source>the `checksum` field contains the value of the Internet checksum computed over the entire TCP segment and a pseudo-header as with UDP</source>
        <target state="translated">the `checksum` field contains the value of the Internet checksum computed over the entire TCP segment and a pseudo-header as with UDP</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">55</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f2742df49814ce40" weblate-flags="read-only">
        <source>the `Reserved` field was initially reserved for future utilization. It is now used by :rfc:`3168`.</source>
        <target state="translated">the `Reserved` field was initially reserved for future utilization. It is now used by :rfc:`3168`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">56</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d257d71da97cb875" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">57</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="da347b988e7faa07" weblate-flags="read-only">
        <source>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`.</source>
        <target state="translated">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`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">58</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ca96506eae8869ae" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">99</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="97a307d7136d5b55" weblate-flags="read-only">
        <source>TCP connection establishment</source>
        <target state="translated">TCP connection establishment</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">107</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1a6cc2429d550b89" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">111</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2f354dea3104a285" weblate-flags="read-only">
        <source>the `SYN` flag set</source>
        <target state="translated">the `SYN` flag set</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">113</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">118</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b4864f698dc5d870" weblate-flags="read-only">
        <source>the `sequence number` set to the current value of the 32 bits counter of the client host's TCP entity</source>
        <target state="translated">the `sequence number` set to the current value of the 32 bits counter of the client host's TCP entity</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">114</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9439ac4d17e099c7" weblate-flags="read-only">
        <source>Upon reception of this segment (which is often called a `SYN segment`), the server host replies with a segment containing :</source>
        <target state="translated">Upon reception of this segment (which is often called a `SYN segment`), the server host replies with a segment containing :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">116</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="92e3729bc115f8ac" weblate-flags="read-only">
        <source>the `sequence number` set to the current value of the 32 bits counter of the server host's TCP entity</source>
        <target state="translated">the `sequence number` set to the current value of the 32 bits counter of the server host's TCP entity</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">119</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4ae7539c62bbba3a" weblate-flags="read-only">
        <source>the `ACK` flag set</source>
        <target state="translated">the `ACK` flag set</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">126</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f3bd4307ef6d025c" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">121</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="330ca397d68ff09a" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">124</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c6882aef33ce6daa" weblate-flags="read-only">
        <source>the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}`</source>
        <target state="translated">the `acknowledgment number` set to the `sequence number` of the received `SYN+ACK` segment incremented by 1 :math:`\pmod{2^{32}}`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">127</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="792d1dc736d0e4c2" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">129</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8709395b5c2c8d48" weblate-flags="read-only">
        <source>Establishment of a TCP connection</source>
        <target state="translated">Establishment of a TCP connection</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">135</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="095252e63e8a6f5d" weblate-flags="read-only">
        <source>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`).</source>
        <target state="translated">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`).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">137</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d2e8dcea2eed7cc0" weblate-flags="read-only">
        <source>Computing TCP's initial sequence number</source>
        <target state="translated">Computing TCP's initial sequence number</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">141</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d2da3b2954f06ec7" weblate-flags="read-only">
        <source>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 ::</source>
        <target state="translated">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 ::</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">143</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="15009a0113aa8c1e" weblate-flags="read-only">
        <source>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 &lt;http://lcamtuf.coredump.cx/newtcp/&gt;`_ 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.</source>
        <target state="translated">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 &lt;http://lcamtuf.coredump.cx/newtcp/&gt;`_ 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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">147</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b3266d51c68d2320" weblate-flags="read-only">
        <source>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`).</source>
        <target state="translated">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`).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">151</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3c98663a9780d8f7" weblate-flags="read-only">
        <source>TCP connection establishment rejected by peer</source>
        <target state="translated">TCP connection establishment rejected by peer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">157</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8142729682e9099f" weblate-flags="read-only">
        <source>TCP connection establishment can be described as the four state Finite State Machine shown below. In this FSM, `!X` (resp. `?Y`) indicates the transmission of segment `X` (resp. reception of segment `Y`) during the corresponding transition. `Init` is the initial state.</source>
        <target state="translated">TCP connection establishment can be described as the four state Finite State Machine shown below. In this FSM, `!X` (resp. `?Y`) indicates the transmission of segment `X` (resp. reception of segment `Y`) during the corresponding transition. `Init` is the initial state.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">159</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="631e380640803b28" weblate-flags="read-only">
        <source>A client host starts in the `Init` state. It then sends a `SYN` segment and enters the `SYN Sent` state where it waits for a `SYN+ACK` segment. Then, it replies with an `ACK` segment and enters the `Established` state where data can be exchanged. On the other hand, a server host starts in the `Init` state. When a server process starts to listen to a destination port, the underlying TCP entity creates a TCP control block and a queue to process incoming `SYN` segments. Upon reception of a `SYN` segment, the server's TCP entity replies with a `SYN+ACK` and enters the `SYN RCVD` state. It remains in this state until it receives an `ACK` segment that acknowledges its `SYN+ACK` segment, with this it then enters the `Established` state.</source>
        <target state="translated">A client host starts in the `Init` state. It then sends a `SYN` segment and enters the `SYN Sent` state where it waits for a `SYN+ACK` segment. Then, it replies with an `ACK` segment and enters the `Established` state where data can be exchanged. On the other hand, a server host starts in the `Init` state. When a server process starts to listen to a destination port, the underlying TCP entity creates a TCP control block and a queue to process incoming `SYN` segments. Upon reception of a `SYN` segment, the server's TCP entity replies with a `SYN+ACK` and enters the `SYN RCVD` state. It remains in this state until it receives an `ACK` segment that acknowledges its `SYN+ACK` segment, with this it then enters the `Established` state.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">177</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="543c209cff0c4a01" weblate-flags="read-only">
        <source>Apart from these two paths in the TCP connection establishment FSM, there is a third path that corresponds to the case when both the client and the server send a `SYN` segment to open a TCP connection [#ftcpboth]_. In this case, the client and the server send a `SYN` segment and enter the `SYN Sent` state. Upon reception of the `SYN` segment sent by the other host, they reply by sending a `SYN+ACK` segment and enter the `SYN RCVD` state. The `SYN+ACK` that arrives from the other host allows it to transition to the `Established` state. The figure below illustrates such a simultaneous establishment of a TCP connection.</source>
        <target state="translated">Apart from these two paths in the TCP connection establishment FSM, there is a third path that corresponds to the case when both the client and the server send a `SYN` segment to open a TCP connection [#ftcpboth]_. In this case, the client and the server send a `SYN` segment and enter the `SYN Sent` state. Upon reception of the `SYN` segment sent by the other host, they reply by sending a `SYN+ACK` segment and enter the `SYN RCVD` state. The `SYN+ACK` that arrives from the other host allows it to transition to the `Established` state. The figure below illustrates such a simultaneous establishment of a TCP connection.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">179</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c81fef7d03e42154" weblate-flags="read-only">
        <source>Simultaneous establishment of a TCP connection</source>
        <target state="translated">Simultaneous establishment of a TCP connection</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">185</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e45c5f4214488d92" weblate-flags="read-only">
        <source>Denial of Service attacks</source>
        <target state="translated">Denial of Service attacks</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">None</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3447fba5bccea567" weblate-flags="read-only">
        <source>When a TCP entity opens a TCP connection, it creates a Transmission Control Block (:term:`TCB`). The TCB contains the entire state that is maintained by the TCP entity for each TCP connection. During connection establishment, the TCB contains the local IP address, the remote IP address, the local port number, the remote port number, the current local sequence number and the last sequence number received from the remote entity. Until the mid 1990s, TCP implementations had a limit on the number of TCP connections that could be in the `SYN RCVD` state at a given time. Many implementations set this limit to about 100 TCBs. This limit was considered sufficient even for heavily load http servers given the small delay between the reception of a `SYN` segment and the reception of the `ACK` segment that terminates the establishment of the TCP connection. When the limit of 100 TCBs in the `SYN Rcvd` state is reached, the TCP entity discards all received TCP `SYN` segments that do not correspond to an existing TCB.</source>
        <target state="translated">When a TCP entity opens a TCP connection, it creates a Transmission Control Block (:term:`TCB`). The TCB contains the entire state that is maintained by the TCP entity for each TCP connection. During connection establishment, the TCB contains the local IP address, the remote IP address, the local port number, the remote port number, the current local sequence number and the last sequence number received from the remote entity. Until the mid 1990s, TCP implementations had a limit on the number of TCP connections that could be in the `SYN RCVD` state at a given time. Many implementations set this limit to about 100 TCBs. This limit was considered sufficient even for heavily load http servers given the small delay between the reception of a `SYN` segment and the reception of the `ACK` segment that terminates the establishment of the TCP connection. When the limit of 100 TCBs in the `SYN Rcvd` state is reached, the TCP entity discards all received TCP `SYN` segments that do not correspond to an existing TCB.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">192</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f351b8971fd73ffc" weblate-flags="read-only">
        <source>This limit of 100 TCBs in the `SYN Rcvd` state was chosen to protect the TCP entity from the risk of overloading its memory with too many TCBs in the `SYN Rcvd` state. However, it was also the reason for a new type of Denial of Service (DoS) attack :rfc:`4987`. A DoS attack is defined as an attack where an attacker can render a resource unavailable in the network. For example, an attacker may cause a DoS attack on a 2 Mbps link used by a company by sending more than 2 Mbps of packets through this link. In this case, the DoS attack was more subtle. As a TCP entity discards all received `SYN` segments as soon as it has 100 TCBs in the `SYN Rcvd` state, an attacker simply had to send a few 100 `SYN` segments every second to a server and never reply to the received `SYN+ACK` segments. To avoid being caught, attackers were of course sending these `SYN` segments with a different address than their own IP address [#fspoofing]_. On most TCP implementations, once a TCB entered the `SYN Rcvd` state, it remained in this state for several seconds, waiting for a retransmission of the initial `SYN` segment. This attack was later called a `SYN flood` attack and the servers of the ISP named panix were among the first to `be affected &lt;http://memex.org/meme2-12.html&gt;`_ by this attack.</source>
        <target state="translated">This limit of 100 TCBs in the `SYN Rcvd` state was chosen to protect the TCP entity from the risk of overloading its memory with too many TCBs in the `SYN Rcvd` state. However, it was also the reason for a new type of Denial of Service (DoS) attack :rfc:`4987`. A DoS attack is defined as an attack where an attacker can render a resource unavailable in the network. For example, an attacker may cause a DoS attack on a 2 Mbps link used by a company by sending more than 2 Mbps of packets through this link. In this case, the DoS attack was more subtle. As a TCP entity discards all received `SYN` segments as soon as it has 100 TCBs in the `SYN Rcvd` state, an attacker simply had to send a few 100 `SYN` segments every second to a server and never reply to the received `SYN+ACK` segments. To avoid being caught, attackers were of course sending these `SYN` segments with a different address than their own IP address [#fspoofing]_. On most TCP implementations, once a TCB entered the `SYN Rcvd` state, it remained in this state for several seconds, waiting for a retransmission of the initial `SYN` segment. This attack was later called a `SYN flood` attack and the servers of the ISP named panix were among the first to `be affected &lt;http://memex.org/meme2-12.html&gt;`_ by this attack.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">194</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="14a3398be10d7863" weblate-flags="read-only">
        <source>To avoid the `SYN flood` attacks, recent TCP implementations no longer enter the `SYN Rcvd` state upon reception of a `SYN segment`. Instead, they reply directly with a `SYN+ACK` segment and wait until the reception of a valid `ACK`. This implementation trick is only possible if the TCP implementation is able to verify that the received `ACK` segment acknowledges the `SYN+ACK` segment sent earlier without storing the initial sequence number of this `SYN+ACK` segment in a TCB. The solution to solve this problem, which is known as `SYN cookies &lt;http://cr.yp.to/syncookies.html&gt;`_ is to compute the 32 bits of the `ISN` as follows :</source>
        <target state="translated">To avoid the `SYN flood` attacks, recent TCP implementations no longer enter the `SYN Rcvd` state upon reception of a `SYN segment`. Instead, they reply directly with a `SYN+ACK` segment and wait until the reception of a valid `ACK`. This implementation trick is only possible if the TCP implementation is able to verify that the received `ACK` segment acknowledges the `SYN+ACK` segment sent earlier without storing the initial sequence number of this `SYN+ACK` segment in a TCB. The solution to solve this problem, which is known as `SYN cookies &lt;http://cr.yp.to/syncookies.html&gt;`_ is to compute the 32 bits of the `ISN` as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">200</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c986e888f04d55d8" weblate-flags="read-only">
        <source>the high order bits contain the low order bits of a counter that is incremented slowly</source>
        <target state="translated">the high order bits contain the low order bits of a counter that is incremented slowly</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">202</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c45665396c054fca" weblate-flags="read-only">
        <source>the low order bits contain a hash value computed over the local and remote IP addresses and ports and a random secret only known to the server</source>
        <target state="translated">the low order bits contain a hash value computed over the local and remote IP addresses and ports and a random secret only known to the server</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">203</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8842e821a748b83e" weblate-flags="read-only">
        <source>The advantage of the `SYN cookies`_ is that by using them, the server does not need to create a :term:`TCB` upon reception of the `SYN` segment and can still check the returned `ACK` segment by recomputing the `SYN cookie`. The main disadvantage is that they are not fully compatible with the TCP options. This is why they are not enabled by default on a typical system.</source>
        <target state="translated">The advantage of the `SYN cookies`_ is that by using them, the server does not need to create a :term:`TCB` upon reception of the `SYN` segment and can still check the returned `ACK` segment by recomputing the `SYN cookie`. The main disadvantage is that they are not fully compatible with the TCP options. This is why they are not enabled by default on a typical system.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">205</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0b2735754798d05a" weblate-flags="read-only">
        <source>Retransmitting the first `SYN` segment</source>
        <target state="translated">Retransmitting the first `SYN` segment</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">None</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1ce909a4b8d4df8a" weblate-flags="read-only">
        <source>As IP provides an unreliable connectionless service, the `SYN` and `SYN+ACK` segments sent to open a TCP connection could be lost. Current TCP implementations start a retransmission timer when they send the first `SYN` segment. This timer is often set to three seconds for the first retransmission and then doubles after each retransmission :rfc:`2988`. TCP implementations also enforce a maximum number of retransmissions for the initial `SYN` segment.</source>
        <target state="translated">As IP provides an unreliable connectionless service, the `SYN` and `SYN+ACK` segments sent to open a TCP connection could be lost. Current TCP implementations start a retransmission timer when they send the first `SYN` segment. This timer is often set to three seconds for the first retransmission and then doubles after each retransmission :rfc:`2988`. TCP implementations also enforce a maximum number of retransmissions for the initial `SYN` segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">210</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="af065642c604908f" weblate-flags="read-only">
        <source>As explained earlier, TCP segments may contain an optional header extension. In the `SYN` and `SYN+ACK` segments, these options are used to negotiate some parameters and the utilization of extensions to the basic TCP specification.</source>
        <target state="translated">As explained earlier, TCP segments may contain an optional header extension. In the `SYN` and `SYN+ACK` segments, these options are used to negotiate some parameters and the utilization of extensions to the basic TCP specification.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">215</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e44f48aab99e954b" weblate-flags="read-only">
        <source>The first parameter which is negotiated during the establishment of a TCP connection is the Maximum Segment Size (:term:`MSS`). The MSS is the size of the largest segment that a TCP entity is able to process. According to :rfc:`879`, all TCP implementations must be able to receive TCP segments containing 536 bytes of payload. However, most TCP implementations are able to process larger segments. Such TCP implementations use the TCP MSS Option in the `SYN`/`SYN+ACK` segment to indicate the largest segment they are able to process. The MSS value indicates the maximum size of the payload of the TCP segments. The client (resp. server) stores in its :term:`TCB` the MSS value announced by the server (resp. the client).</source>
        <target state="translated">The first parameter which is negotiated during the establishment of a TCP connection is the Maximum Segment Size (:term:`MSS`). The MSS is the size of the largest segment that a TCP entity is able to process. According to :rfc:`879`, all TCP implementations must be able to receive TCP segments containing 536 bytes of payload. However, most TCP implementations are able to process larger segments. Such TCP implementations use the TCP MSS Option in the `SYN`/`SYN+ACK` segment to indicate the largest segment they are able to process. The MSS value indicates the maximum size of the payload of the TCP segments. The client (resp. server) stores in its :term:`TCB` the MSS value announced by the server (resp. the client).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">219</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="059ef018274295e7" weblate-flags="read-only">
        <source>Another utilization of TCP options during connection establishment is to enable TCP extensions. For example, consider :rfc:`1323` (which is discussed in :ref:`TCPReliable`). :rfc:`1323` defines TCP extensions to support timestamps and larger windows. If the client supports :rfc:`1323`, it adds a :rfc:`1323` option to its `SYN` segment. If the server understands this :rfc:`1323` option and wishes to use it, it replies with a :rfc:`1323` option in the `SYN+ACK` segment and the extension defined in :rfc:`1323` is used throughout the TCP connection. Otherwise, if the server's `SYN+ACK` does not contain the :rfc:`1323` option, the client is not allowed to use this extension and the corresponding TCP header options throughout the TCP connection. TCP's option mechanism is flexible and it allows the extension of TCP while maintaining compatibility with older implementations.</source>
        <target state="translated">Another utilization of TCP options during connection establishment is to enable TCP extensions. For example, consider :rfc:`1323` (which is discussed in :ref:`TCPReliable`). :rfc:`1323` defines TCP extensions to support timestamps and larger windows. If the client supports :rfc:`1323`, it adds a :rfc:`1323` option to its `SYN` segment. If the server understands this :rfc:`1323` option and wishes to use it, it replies with a :rfc:`1323` option in the `SYN+ACK` segment and the extension defined in :rfc:`1323` is used throughout the TCP connection. Otherwise, if the server's `SYN+ACK` does not contain the :rfc:`1323` option, the client is not allowed to use this extension and the corresponding TCP header options throughout the TCP connection. TCP's option mechanism is flexible and it allows the extension of TCP while maintaining compatibility with older implementations.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">221</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="45c28ede80f06fba" weblate-flags="read-only">
        <source>The TCP options are encoded by using a Type Length Value format where :</source>
        <target state="translated">The TCP options are encoded by using a Type Length Value format where :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">223</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66461f077c64140a" weblate-flags="read-only">
        <source>the first byte indicates the `type` of the option.</source>
        <target state="translated">the first byte indicates the `type` of the option.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">225</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6043509733bf6c2e" weblate-flags="read-only">
        <source>the second byte indicates the total length of the option (including the first two bytes) in bytes</source>
        <target state="translated">the second byte indicates the total length of the option (including the first two bytes) in bytes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">226</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b27f1ff997e49b67" weblate-flags="read-only">
        <source>the last bytes are specific for each type of option</source>
        <target state="translated">the last bytes are specific for each type of option</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">227</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d9ed25d80165e545" weblate-flags="read-only">
        <source>:rfc:`793` defines the Maximum Segment Size (MSS) TCP option that must be understood by all TCP implementations. This option (type 2) has a length of 4 bytes and contains a 16 bits word that indicates the MSS supported by the sender of the `SYN` segment. The MSS option can only be used in TCP segments having the `SYN` flag set.</source>
        <target state="translated">:rfc:`793` defines the Maximum Segment Size (MSS) TCP option that must be understood by all TCP implementations. This option (type 2) has a length of 4 bytes and contains a 16 bits word that indicates the MSS supported by the sender of the `SYN` segment. The MSS option can only be used in TCP segments having the `SYN` flag set.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">229</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bf3a4c42d8396aec" weblate-flags="read-only">
        <source>:rfc:`793` also defines two special options that must be supported by all TCP implementations. The first option is `End of option`. It is encoded as a single byte having value `0x00` and can be used to ensure that the TCP header extension ends on a 32 bits boundary. The `No-Operation` option, encoded as a single byte having value `0x01`, can be used when the TCP header extension contains several TCP options that should be aligned on 32 bit boundaries. All other options [#ftcpoptions]_ are encoded using the TLV format.</source>
        <target state="translated">:rfc:`793` also defines two special options that must be supported by all TCP implementations. The first option is `End of option`. It is encoded as a single byte having value `0x00` and can be used to ensure that the TCP header extension ends on a 32 bits boundary. The `No-Operation` option, encoded as a single byte having value `0x01`, can be used when the TCP header extension contains several TCP options that should be aligned on 32 bit boundaries. All other options [#ftcpoptions]_ are encoded using the TLV format.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">231</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="73c736455d73c973" weblate-flags="read-only">
        <source>The robustness principle</source>
        <target state="translated">The robustness principle</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">233</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="119ac0ee94569dff" weblate-flags="read-only">
        <source>The handling of the TCP options by TCP implementations is one of the many applications of the `robustness principle` which is usually attributed to `Jon Postel`_ and is often quoted as `"Be liberal in what you accept, and conservative in what you send"` :rfc:`1122`.</source>
        <target state="translated">The handling of the TCP options by TCP implementations is one of the many applications of the `robustness principle` which is usually attributed to `Jon Postel`_ and is often quoted as `"Be liberal in what you accept, and conservative in what you send"` :rfc:`1122`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">235</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96a868a72f20994a" weblate-flags="read-only">
        <source>Concerning the TCP options, the robustness principle implies that a TCP implementation should be able to accept TCP options that it does not understand, in particular in received `SYN` segments, and that it should be able to parse any received segment without crashing, even if the segment contains an unknown TCP option. Furthermore, a server should not send in the `SYN+ACK` segment or later, options that have not been proposed by the client in the `SYN` segment.</source>
        <target state="translated">Concerning the TCP options, the robustness principle implies that a TCP implementation should be able to accept TCP options that it does not understand, in particular in received `SYN` segments, and that it should be able to parse any received segment without crashing, even if the segment contains an unknown TCP option. Furthermore, a server should not send in the `SYN+ACK` segment or later, options that have not been proposed by the client in the `SYN` segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">237</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eae964ba454090c9" weblate-flags="read-only">
        <source>TCP reliable data transfer</source>
        <target state="translated">TCP reliable data transfer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">243</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2d6e40dc067016cb" weblate-flags="read-only">
        <source>The original TCP data transfer mechanisms were defined in :rfc:`793`. Based on the experience of using TCP on the growing global Internet, this part of the TCP specification has been updated and improved several times, always while preserving the backward compatibility with older TCP implementations. In this section, we review the main data transfer mechanisms used by TCP.</source>
        <target state="translated">The original TCP data transfer mechanisms were defined in :rfc:`793`. Based on the experience of using TCP on the growing global Internet, this part of the TCP specification has been updated and improved several times, always while preserving the backward compatibility with older TCP implementations. In this section, we review the main data transfer mechanisms used by TCP.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">245</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70ded71b42406fe9" weblate-flags="read-only">
        <source>TCP is a window-based transport protocol that provides a bi-directional byte stream service. This has several implications on the fields of the TCP header and the mechanisms used by TCP. The three fields of the TCP header are :</source>
        <target state="translated">TCP is a window-based transport protocol that provides a bi-directional byte stream service. This has several implications on the fields of the TCP header and the mechanisms used by TCP. The three fields of the TCP header are :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">247</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ad5eb9411ed6e6ff" weblate-flags="read-only">
        <source>`sequence number`. TCP uses a 32 bits sequence number. The `sequence number` placed in the header of a TCP segment containing data is the sequence number of the first byte of the payload of the TCP segment.</source>
        <target state="translated">`sequence number`. TCP uses a 32 bits sequence number. The `sequence number` placed in the header of a TCP segment containing data is the sequence number of the first byte of the payload of the TCP segment.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">249</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="59f42f81e3f2cc9e" weblate-flags="read-only">
        <source>`acknowledgment number`. TCP uses cumulative positive acknowledgments. Each TCP segment contains the `sequence number` of the next byte that the sender of the acknowledgment expects to receive from the remote host. In theory, the `acknowledgment number` is only valid if the `ACK` flag of the TCP header is set. In practice, almost all [#fackflag]_ TCP segments have their `ACK` flag set.</source>
        <target state="translated">`acknowledgment number`. TCP uses cumulative positive acknowledgments. Each TCP segment contains the `sequence number` of the next byte that the sender of the acknowledgment expects to receive from the remote host. In theory, the `acknowledgment number` is only valid if the `ACK` flag of the TCP header is set. In practice, almost all [#fackflag]_ TCP segments have their `ACK` flag set.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">250</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a9c736c021bc5290" weblate-flags="read-only">
        <source>`window`. a TCP receiver uses this 16 bits field to indicate the current size of its receive window expressed in bytes.</source>
        <target state="translated">`window`. a TCP receiver uses this 16 bits field to indicate the current size of its receive window expressed in bytes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">251</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bd09f9c65578ee37" weblate-flags="read-only">
        <source>The Transmission Control Block</source>
        <target state="translated">The Transmission Control Block</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">255</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="138ad6fb8399a0af" weblate-flags="read-only">
        <source>For each established TCP connection, a TCP implementation must maintain a Transmission Control Block (:term:`TCB`). A TCB contains all the information required to send and receive segments on this connection :rfc:`793`. This includes [#ftcpurgent]_ :</source>
        <target state="translated">For each established TCP connection, a TCP implementation must maintain a Transmission Control Block (:term:`TCB`). A TCB contains all the information required to send and receive segments on this connection :rfc:`793`. This includes [#ftcpurgent]_ :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">257</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b33dab6e254cddd3" weblate-flags="read-only">
        <source>the local IP address</source>
        <target state="translated">the local IP address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">259</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ba85bfaf6db1d9f1" weblate-flags="read-only">
        <source>the remote IP address</source>
        <target state="translated">the remote IP address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">260</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cac8c7efe32669c2" weblate-flags="read-only">
        <source>the local TCP port number</source>
        <target state="translated">the local TCP port number</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="922d619f3f2d3de3" weblate-flags="read-only">
        <source>the remote TCP port number</source>
        <target state="translated">the remote TCP port number</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">262</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c04c0b91dac9f5e2" weblate-flags="read-only">
        <source>the current state of the TCP FSM</source>
        <target state="translated">the current state of the TCP FSM</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">263</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="87ca6057ec3eecf2" weblate-flags="read-only">
        <source>the `maximum segment size` (MSS)</source>
        <target state="translated">the `maximum segment size` (MSS)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">264</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a8fc23091bdbe2e5" weblate-flags="read-only">
        <source>`snd.nxt` : the sequence number of the next byte in the byte stream (the first byte of a new data segment that you send uses this sequence number)</source>
        <target state="translated">`snd.nxt` : the sequence number of the next byte in the byte stream (the first byte of a new data segment that you send uses this sequence number)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">265</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="787d6e8c3d597e34" weblate-flags="read-only">
        <source>`snd.una` : the earliest sequence number that has been sent but has not yet been acknowledged</source>
        <target state="translated">`snd.una` : the earliest sequence number that has been sent but has not yet been acknowledged</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">266</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b0ec531cc4f9e13d" weblate-flags="read-only">
        <source>`snd.wnd` : the current size of the sending window (in bytes)</source>
        <target state="translated">`snd.wnd` : the current size of the sending window (in bytes)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">267</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d97c7fcfc18f0b71" weblate-flags="read-only">
        <source>`rcv.nxt` : the sequence number of the next byte that is expected to be received from the remote host</source>
        <target state="translated">`rcv.nxt` : the sequence number of the next byte that is expected to be received from the remote host</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">268</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ceb0649ae15efc6e" weblate-flags="read-only">
        <source>`rcv.wnd` : the current size of the receive window advertised by the remote host</source>
        <target state="translated">`rcv.wnd` : the current size of the receive window advertised by the remote host</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">269</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="863445979e944c9c" weblate-flags="read-only">
        <source>`sending buffer` : a buffer used to store all unacknowledged data</source>
        <target state="translated">`sending buffer` : a buffer used to store all unacknowledged data</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">270</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e09e656af0c3a346" weblate-flags="read-only">
        <source>`receiving buffer` : a buffer to store all data received from the remote host that has not yet been delivered to the user. Data may be stored in the `receiving buffer` because either it was not received in sequence or because the user is too slow to process it</source>
        <target state="translated">`receiving buffer` : a buffer to store all data received from the remote host that has not yet been delivered to the user. Data may be stored in the `receiving buffer` because either it was not received in sequence or because the user is too slow to process it</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">271</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="473e8355f5a3f44e" weblate-flags="read-only">
        <source>The original TCP specification can be summarized as a transport protocol that provides a byte stream service and uses `go-back-n` with a `selective-repeat` reception strategy.</source>
        <target state="translated">The original TCP specification can be summarized as a transport protocol that provides a byte stream service and uses `go-back-n` with a `selective-repeat` reception strategy.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">274</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a05a0aa7f446e873" weblate-flags="read-only">
        <source>To send new data on an established connection, a TCP entity performs the following operations on the corresponding TCB. It first checks that the `sending buffer` does not contain more data than the receive window advertised by the remote host (`rcv.wnd`). If the window is not full, up to `MSS` bytes of data are placed in the payload of a TCP segment. The `sequence number` of this segment is the sequence number of the first byte of the payload. It is set to the first available sequence number : `snd.nxt` and `snd.nxt` is incremented by the length of the payload of the TCP segment. The `acknowledgment number` of this segment is set to the current value of `rcv.nxt` and the `window` field of the TCP segment is computed based on the current occupancy of the `receiving buffer`. The data is kept in the `sending buffer` in case it needs to be retransmitted later.</source>
        <target state="translated">To send new data on an established connection, a TCP entity performs the following operations on the corresponding TCB. It first checks that the `sending buffer` does not contain more data than the receive window advertised by the remote host (`rcv.wnd`). If the window is not full, up to `MSS` bytes of data are placed in the payload of a TCP segment. The `sequence number` of this segment is the sequence number of the first byte of the payload. It is set to the first available sequence number : `snd.nxt` and `snd.nxt` is incremented by the length of the payload of the TCP segment. The `acknowledgment number` of this segment is set to the current value of `rcv.nxt` and the `window` field of the TCP segment is computed based on the current occupancy of the `receiving buffer`. The data is kept in the `sending buffer` in case it needs to be retransmitted later.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">276</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9b13bd435be5489a" weblate-flags="read-only">
        <source>When a TCP segment with the `ACK` flag set is received, the following operations are performed. `rcv.wnd` is set to the value of the `window` field of the received segment. The `acknowledgment number` is compared to `snd.una`. The newly acknowledged data is removed from the `sending buffer` and `snd.una` is updated. If the TCP segment contained data, the `sequence number` is compared to `rcv.nxt`. If they are equal, the segment was received in sequence and the data can be delivered to the user and `rcv.nxt` is updated. The contents of the `receiving buffer` is checked to see whether other data already present in this buffer can be delivered in sequence to the user. If so, `rcv.nxt` is updated again. Otherwise, the segment's payload is placed in the `receiving buffer`.</source>
        <target state="translated">When a TCP segment with the `ACK` flag set is received, the following operations are performed. `rcv.wnd` is set to the value of the `window` field of the received segment. The `acknowledgment number` is compared to `snd.una`. The newly acknowledged data is removed from the `sending buffer` and `snd.una` is updated. If the TCP segment contained data, the `sequence number` is compared to `rcv.nxt`. If they are equal, the segment was received in sequence and the data can be delivered to the user and `rcv.nxt` is updated. The contents of the `receiving buffer` is checked to see whether other data already present in this buffer can be delivered in sequence to the user. If so, `rcv.nxt` is updated again. Otherwise, the segment's payload is placed in the `receiving buffer`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">278</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9780eb96c07fe01d" weblate-flags="read-only">
        <source>Segment transmission strategies</source>
        <target state="translated">Segment transmission strategies</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">281</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3840fbd2839f06e5" weblate-flags="read-only">
        <source>In a transport protocol such as TCP that offers a bytestream, a practical issue that was left as an implementation choice in :rfc:`793` is to decide when a new TCP segment containing data must be sent. There are two simple and extreme implementation choices. The first implementation choice is to send a TCP segment as soon as the user has requested the transmission of some data. This allows TCP to provide a low delay service. However, if the user is sending data one byte at a time, TCP would place each user byte in a segment containing 20 bytes of TCP header [#fnagleip]_. This is a huge overhead that is not acceptable in wide area networks. A second simple solution would be to only transmit a new TCP segment once the user has produced MSS bytes of data. This solution reduces the overhead, but at the cost of a potentially very high delay.</source>
        <target state="translated">In a transport protocol such as TCP that offers a bytestream, a practical issue that was left as an implementation choice in :rfc:`793` is to decide when a new TCP segment containing data must be sent. There are two simple and extreme implementation choices. The first implementation choice is to send a TCP segment as soon as the user has requested the transmission of some data. This allows TCP to provide a low delay service. However, if the user is sending data one byte at a time, TCP would place each user byte in a segment containing 20 bytes of TCP header [#fnagleip]_. This is a huge overhead that is not acceptable in wide area networks. A second simple solution would be to only transmit a new TCP segment once the user has produced MSS bytes of data. This solution reduces the overhead, but at the cost of a potentially very high delay.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">289</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6006cfe92c9a7930" weblate-flags="read-only">
        <source>An elegant solution to this problem was proposed by John Nagle in :rfc:`896`. John Nagle observed that the overhead caused by the TCP header was a problem in wide area connections, but less in local area connections where the available bandwidth is usually higher. He proposed the following rules to decide to send a new data segment when a new data has been produced by the user or a new `ack` segment has been received.</source>
        <target state="translated">An elegant solution to this problem was proposed by John Nagle in :rfc:`896`. John Nagle observed that the overhead caused by the TCP header was a problem in wide area connections, but less in local area connections where the available bandwidth is usually higher. He proposed the following rules to decide to send a new data segment when a new data has been produced by the user or a new `ack` segment has been received.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">291</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5a8dbeffaea248bf" weblate-flags="read-only">
        <source>The first rule ensures that a TCP connection used for bulk data transfer always sends full TCP segments. The second rule sends one partially filled TCP segment every round-trip-time.</source>
        <target state="translated">The first rule ensures that a TCP connection used for bulk data transfer always sends full TCP segments. The second rule sends one partially filled TCP segment every round-trip-time.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">303</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="69b95e6b2b3bd40d" weblate-flags="read-only">
        <source>This algorithm, called the Nagle algorithm, takes a few lines of code in all TCP implementations. These lines of code have a huge impact on the packets that are exchanged in TCP/IP networks. Researchers have analyzed the distribution of the packet sizes by capturing and analyzing all the packets passing through a given link. These studies have shown several important results :</source>
        <target state="translated">This algorithm, called the Nagle algorithm, takes a few lines of code in all TCP implementations. These lines of code have a huge impact on the packets that are exchanged in TCP/IP networks. Researchers have analyzed the distribution of the packet sizes by capturing and analyzing all the packets passing through a given link. These studies have shown several important results :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">307</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2da016e1f6dc55a7" weblate-flags="read-only">
        <source>in TCP/IP networks, a large fraction of the packets are TCP segments that contain only an acknowledgment. These packets usually account for 40-50% of the packets passing through the studied link</source>
        <target state="translated">in TCP/IP networks, a large fraction of the packets are TCP segments that contain only an acknowledgment. These packets usually account for 40-50% of the packets passing through the studied link</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">309</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ff846832fb243764" weblate-flags="read-only">
        <source>in TCP/IP networks, most of the bytes are exchanged in long packets, usually packets containing about 1440 bytes of payload which is the default MSS for hosts attached to an Ethernet network, the most popular type of LAN</source>
        <target state="translated">in TCP/IP networks, most of the bytes are exchanged in long packets, usually packets containing about 1440 bytes of payload which is the default MSS for hosts attached to an Ethernet network, the most popular type of LAN</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">310</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7562b36d7467220f" weblate-flags="read-only">
        <source>`Recent measurements &lt;http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml&gt;`_ indicate that these packet size distributions are still valid in today's Internet, although the packet distribution tends to become bi-modal with small packets corresponding to TCP pure acknowledgments and large 1440-bytes packets carrying most of the user data [SMASU2012]_.</source>
        <target state="translated">`Recent measurements &lt;http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml&gt;`_ indicate that these packet size distributions are still valid in today's Internet, although the packet distribution tends to become bi-modal with small packets corresponding to TCP pure acknowledgments and large 1440-bytes packets carrying most of the user data [SMASU2012]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">315</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c34fba189a7132ec" weblate-flags="read-only">
        <source>TCP windows</source>
        <target state="translated">TCP windows</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">322</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="95707cf18f9a16ff" weblate-flags="read-only">
        <source>From a performance point of view, one of the main limitations of the original TCP specification is the 16 bits `window` field in the TCP header. As this field indicates the current size of the receive window in bytes, it limits the TCP receive window at 65535 bytes. This limitation was not a severe problem when TCP was designed since at that time high-speed wide area networks offered a maximum bandwidth of 56 kbps. However, in today's network, this limitation is not acceptable anymore. The table below provides the rough [#faveragebandwidth]_ maximum throughput that can be achieved by a TCP connection with a 64 KBytes window in function of the connection's round-trip-time</source>
        <target state="translated">From a performance point of view, one of the main limitations of the original TCP specification is the 16 bits `window` field in the TCP header. As this field indicates the current size of the receive window in bytes, it limits the TCP receive window at 65535 bytes. This limitation was not a severe problem when TCP was designed since at that time high-speed wide area networks offered a maximum bandwidth of 56 kbps. However, in today's network, this limitation is not acceptable anymore. The table below provides the rough [#faveragebandwidth]_ maximum throughput that can be achieved by a TCP connection with a 64 KBytes window in function of the connection's round-trip-time</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">329</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6e054b751a31190e" weblate-flags="read-only">
        <source>RTT</source>
        <target state="translated">RTT</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">332</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">345</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3a208a6c246efa32" weblate-flags="read-only">
        <source>Maximum Throughput</source>
        <target state="translated">Maximum Throughput</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">332</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">345</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="79ff4012f7887d0c" weblate-flags="read-only">
        <source>1 msec</source>
        <target state="translated">1 msec</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">334</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">347</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0e1bc37dcca48976" weblate-flags="read-only">
        <source>524 Mbps</source>
        <target state="translated">524 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">334</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b504ede3cf2ddf45" weblate-flags="read-only">
        <source>10 msec</source>
        <target state="translated">10 msec</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">348</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="306edb475e5a2704" weblate-flags="read-only">
        <source>52.4 Mbps</source>
        <target state="translated">52.4 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9f1ab83c4900c768" weblate-flags="read-only">
        <source>100 msec</source>
        <target state="translated">100 msec</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">336</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">349</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="20f97ea58a6dfb73" weblate-flags="read-only">
        <source>5.24 Mbps</source>
        <target state="translated">5.24 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">336</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9ef76e9c59d0d20e" weblate-flags="read-only">
        <source>500 msec</source>
        <target state="translated">500 msec</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">350</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9e381c7e631fb6ee" weblate-flags="read-only">
        <source>1.05 Mbps</source>
        <target state="translated">1.05 Mbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9a9c56d8259dad23" weblate-flags="read-only">
        <source>To solve this problem, a backward compatible extension that allows TCP to use larger receive windows was proposed in :rfc:`1323`. Today, most TCP implementations support this option. The basic idea is that instead of storing `snd.wnd` and `rcv.wnd` as 16 bits integers in the :term:`TCB`, they should be stored as 32 bits integers. As the TCP segment header only contains 16 bits to place the window field, it is impossible to copy the value of `snd.wnd` in each sent TCP segment. Instead the header contains `snd.wnd &gt;&gt; S` where `S` is the scaling factor ( :math:`0 \le S \le 14`) negotiated during connection establishment. The client adds its proposed scaling factor as a TCP option in the `SYN` segment. If the server supports :rfc:`1323`, it places in the `SYN+ACK` segment the scaling factor that it uses when advertising its own receive window. The local and remote scaling factors are included in the :term:`TCB`. If the server does not support :rfc:`1323`, it ignores the received option and no scaling is applied.</source>
        <target state="translated">To solve this problem, a backward compatible extension that allows TCP to use larger receive windows was proposed in :rfc:`1323`. Today, most TCP implementations support this option. The basic idea is that instead of storing `snd.wnd` and `rcv.wnd` as 16 bits integers in the :term:`TCB`, they should be stored as 32 bits integers. As the TCP segment header only contains 16 bits to place the window field, it is impossible to copy the value of `snd.wnd` in each sent TCP segment. Instead the header contains `snd.wnd &gt;&gt; S` where `S` is the scaling factor ( :math:`0 \le S \le 14`) negotiated during connection establishment. The client adds its proposed scaling factor as a TCP option in the `SYN` segment. If the server supports :rfc:`1323`, it places in the `SYN+ACK` segment the scaling factor that it uses when advertising its own receive window. The local and remote scaling factors are included in the :term:`TCB`. If the server does not support :rfc:`1323`, it ignores the received option and no scaling is applied.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">340</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e1da2a7aa5722716" weblate-flags="read-only">
        <source>By using the window scaling extensions defined in :rfc:`1323`, TCP implementations can use a receive buffer of up to 1 GByte. With such a receive buffer, the maximum throughput that can be achieved by a single TCP connection becomes :</source>
        <target state="translated">By using the window scaling extensions defined in :rfc:`1323`, TCP implementations can use a receive buffer of up to 1 GByte. With such a receive buffer, the maximum throughput that can be achieved by a single TCP connection becomes :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">342</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e171a939880ec11e" weblate-flags="read-only">
        <source>8590 Gbps</source>
        <target state="translated">8590 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">347</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="37805595ada3ea95" weblate-flags="read-only">
        <source>859 Gbps</source>
        <target state="translated">859 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">348</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="324d7fc35c0914e7" weblate-flags="read-only">
        <source>86 Gbps</source>
        <target state="translated">86 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">349</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7016f85344f958d3" weblate-flags="read-only">
        <source>17 Gbps</source>
        <target state="translated">17 Gbps</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">350</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c21cf1cf96d81921" weblate-flags="read-only">
        <source>These throughputs are acceptable in today's networks. However, there are already servers having 10 Gbps interfaces... Early TCP implementations had fixed receiving and sending buffers [#ftcphosts]_. Today's high performance implementations are able to automatically adjust the size of the sending and receiving buffer to better support high bandwidth flows [SMM1998]_.</source>
        <target state="translated">These throughputs are acceptable in today's networks. However, there are already servers having 10 Gbps interfaces... Early TCP implementations had fixed receiving and sending buffers [#ftcphosts]_. Today's high performance implementations are able to automatically adjust the size of the sending and receiving buffer to better support high bandwidth flows [SMM1998]_.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">357</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2828bf5c65ab6657" weblate-flags="read-only">
        <source>TCP's retransmission timeout</source>
        <target state="translated">TCP's retransmission timeout</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">362</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="517be3cbad5d5593" weblate-flags="read-only">
        <source>In a go-back-n transport protocol such as TCP, the retransmission timeout must be correctly set in order to achieve good performance. On one hand, if the retransmission timeout expires too early, then bandwidth is wasted by retransmitting segments that have already been correctly received. On the other hand, if the retransmission timeout expires too late, then bandwidth is wasted because the sender is idle waiting for the expiration of its retransmission timeout.</source>
        <target state="translated">In a go-back-n transport protocol such as TCP, the retransmission timeout must be correctly set in order to achieve good performance. On one hand, if the retransmission timeout expires too early, then bandwidth is wasted by retransmitting segments that have already been correctly received. On the other hand, if the retransmission timeout expires too late, then bandwidth is wasted because the sender is idle waiting for the expiration of its retransmission timeout.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">364</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="65d191909fec9ba3" weblate-flags="read-only">
        <source>A good setting of the retransmission timeout clearly depends on an accurate estimation of the round-trip-time of each TCP connection. The round-trip-time differs between TCP connections, but may also change during the lifetime of a single connection. For example, the figure below shows the evolution of the round-trip-time  between two hosts during a period of 45 seconds.</source>
        <target state="translated">A good setting of the retransmission timeout clearly depends on an accurate estimation of the round-trip-time of each TCP connection. The round-trip-time differs between TCP connections, but may also change during the lifetime of a single connection. For example, the figure below shows the evolution of the round-trip-time  between two hosts during a period of 45 seconds.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">366</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b8188172ab4ffe74" weblate-flags="read-only">
        <source>Evolution of the round-trip-time between two hosts</source>
        <target state="translated">Evolution of the round-trip-time between two hosts</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">372</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4e83549e8eaee104" weblate-flags="read-only">
        <source>The easiest solution to measure the round-trip-time on a TCP connection is to measure the delay between the transmission of a data segment and the reception of a corresponding acknowledgment [#frttmes]_. As illustrated in the figure below, this measurement works well when there are no segment losses.</source>
        <target state="translated">The easiest solution to measure the round-trip-time on a TCP connection is to measure the delay between the transmission of a data segment and the reception of a corresponding acknowledgment [#frttmes]_. As illustrated in the figure below, this measurement works well when there are no segment losses.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">375</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b5e6ad630ee1e890" weblate-flags="read-only">
        <source>How to measure the round-trip-time ?</source>
        <target state="translated">How to measure the round-trip-time ?</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">381</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2d3aa34abed4ffd" weblate-flags="read-only">
        <source>However, when a data segment is lost, as illustrated in the bottom part of the figure, the measurement is ambiguous as the sender cannot determine whether the received acknowledgment was triggered by the first transmission of segment `123` or its retransmission. Using incorrect round-trip-time estimations could lead to incorrect values of the retransmission timeout. For this reason, Phil Karn and Craig Partridge proposed, in [KP91]_, to ignore the round-trip-time measurements performed during retransmissions.</source>
        <target state="translated">However, when a data segment is lost, as illustrated in the bottom part of the figure, the measurement is ambiguous as the sender cannot determine whether the received acknowledgment was triggered by the first transmission of segment `123` or its retransmission. Using incorrect round-trip-time estimations could lead to incorrect values of the retransmission timeout. For this reason, Phil Karn and Craig Partridge proposed, in [KP91]_, to ignore the round-trip-time measurements performed during retransmissions.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">388</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6993cf0462da4076" weblate-flags="read-only">
        <source>To avoid this ambiguity in the estimation of the round-trip-time when segments are retransmitted, recent TCP implementations rely on the `timestamp option` defined in :rfc:`1323`. This option allows a TCP sender to place two 32 bit timestamps in each TCP segment that it sends. The first timestamp, TS Value (`TSval`) is chosen by the sender of the segment. It could for example be the current value of its real-time clock [#ftimestamp]_. The second value, TS Echo Reply (`TSecr`), is the last `TSval` that was received from the remote host and stored in the :term:`TCB`. The figure below shows how the utilization of this timestamp option allows for the disambiguation of the round-trip-time measurement when there are retransmissions.</source>
        <target state="translated">To avoid this ambiguity in the estimation of the round-trip-time when segments are retransmitted, recent TCP implementations rely on the `timestamp option` defined in :rfc:`1323`. This option allows a TCP sender to place two 32 bit timestamps in each TCP segment that it sends. The first timestamp, TS Value (`TSval`) is chosen by the sender of the segment. It could for example be the current value of its real-time clock [#ftimestamp]_. The second value, TS Echo Reply (`TSecr`), is the last `TSval` that was received from the remote host and stored in the :term:`TCB`. The figure below shows how the utilization of this timestamp option allows for the disambiguation of the round-trip-time measurement when there are retransmissions.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">394</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bdc23fc454ab5375" weblate-flags="read-only">
        <source>Disambiguating round-trip-time measurements with the :rfc:`1323` timestamp option</source>
        <target state="translated">Disambiguating round-trip-time measurements with the :rfc:`1323` timestamp option</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">400</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="859e734a5f6aa843" weblate-flags="read-only">
        <source>Once the round-trip-time measurements have been collected for a given TCP connection, the TCP entity must compute the retransmission timeout. As the round-trip-time measurements may change during the lifetime of a connection, the retransmission timeout may also change. At the beginning of a connection [#ftcbtouch]_, the TCP entity that sends a `SYN` segment does not know the round-trip-time to reach the remote host and the initial retransmission timeout is usually set to 3 seconds :rfc:`2988`.</source>
        <target state="translated">Once the round-trip-time measurements have been collected for a given TCP connection, the TCP entity must compute the retransmission timeout. As the round-trip-time measurements may change during the lifetime of a connection, the retransmission timeout may also change. At the beginning of a connection [#ftcbtouch]_, the TCP entity that sends a `SYN` segment does not know the round-trip-time to reach the remote host and the initial retransmission timeout is usually set to 3 seconds :rfc:`2988`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">402</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2951d92d4dfd4679" weblate-flags="read-only">
        <source>The original TCP specification proposed in :rfc:`793` to include two additional variables in the TCB :</source>
        <target state="translated">The original TCP specification proposed in :rfc:`793` to include two additional variables in the TCB :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">404</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="eec7a7c9334c65d8" weblate-flags="read-only">
        <source>`srtt` : the smoothed round-trip-time computed as :math:`srtt=(\alpha \times srtt)+( (1-\alpha) \times rtt)` where :math:`rtt` is the round-trip-time measured according to the above procedure and :math:`\alpha` a smoothing factor (e.g. 0.8 or 0.9)</source>
        <target state="translated">`srtt` : the smoothed round-trip-time computed as :math:`srtt=(\alpha \times srtt)+( (1-\alpha) \times rtt)` where :math:`rtt` is the round-trip-time measured according to the above procedure and :math:`\alpha` a smoothing factor (e.g. 0.8 or 0.9)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">406</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b99ad78f91551199" weblate-flags="read-only">
        <source>`rto` : the retransmission timeout is computed as :math:`rto=\min(60,max(1,\beta \times srtt))` where :math:`\beta` is used to take into account the delay variance (value : 1.3 to 2.0). The `60` and `1` constants are used to ensure that the `rto` is not larger than one minute nor smaller than 1 second.</source>
        <target state="translated">`rto` : the retransmission timeout is computed as :math:`rto=\min(60,max(1,\beta \times srtt))` where :math:`\beta` is used to take into account the delay variance (value : 1.3 to 2.0). The `60` and `1` constants are used to ensure that the `rto` is not larger than one minute nor smaller than 1 second.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">407</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05f8e1ad05eab761" weblate-flags="read-only">
        <source>However, in practice, this computation for the retransmission timeout did not work well. The main problem was that the computed `rto` did not correctly take into account the variations in the measured round-trip-time. `Van Jacobson` proposed in his seminal paper [Jacobson1988]_ an improved algorithm to compute the `rto` and implemented it in the BSD Unix distribution. This algorithm is now part of the TCP standard :rfc:`2988`.</source>
        <target state="translated">However, in practice, this computation for the retransmission timeout did not work well. The main problem was that the computed `rto` did not correctly take into account the variations in the measured round-trip-time. `Van Jacobson` proposed in his seminal paper [Jacobson1988]_ an improved algorithm to compute the `rto` and implemented it in the BSD Unix distribution. This algorithm is now part of the TCP standard :rfc:`2988`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">409</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c2ac551c08366505" weblate-flags="read-only">
        <source>Jacobson's algorithm uses two state variables, `srtt` the smoothed `rtt` and `rttvar` the estimation of the variance of the `rtt` and two parameters : :math:`\alpha` and :math:`\beta`. When a TCP connection starts, the first `rto` is set to `3` seconds. When a first estimation of the `rtt` is available, the `srtt`, `rttvar` and `rto` are computed as follows :</source>
        <target state="translated">Jacobson's algorithm uses two state variables, `srtt` the smoothed `rtt` and `rttvar` the estimation of the variance of the `rtt` and two parameters : :math:`\alpha` and :math:`\beta`. When a TCP connection starts, the first `rto` is set to `3` seconds. When a first estimation of the `rtt` is available, the `srtt`, `rttvar` and `rto` are computed as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">411</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8ccb469e8423e43c" weblate-flags="read-only">
        <source>Then, when other rtt measurements are collected, `srtt` and `rttvar` are updated as follows :</source>
        <target state="translated">Then, when other rtt measurements are collected, `srtt` and `rttvar` are updated as follows :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">424</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="781fd6f5064ddee0" weblate-flags="read-only">
        <source>:math:`rttvar=(1-\beta) \times rttvar + \beta \times |srtt - rtt|`</source>
        <target state="translated">:math:`rttvar=(1-\beta) \times rttvar + \beta \times |srtt - rtt|`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">426</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a5d2de1e3450ea4b" weblate-flags="read-only">
        <source>:math:`srtt=(1-\alpha) \times srtt + \alpha \times rtt`</source>
        <target state="translated">:math:`srtt=(1-\alpha) \times srtt + \alpha \times rtt`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">428</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6855a9eb1e1ef90e" weblate-flags="read-only">
        <source>:math:`rto=srtt + 4 \times rttvar`</source>
        <target state="translated">:math:`rto=srtt + 4 \times rttvar`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">430</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="22cae9d03a1bc79a" weblate-flags="read-only">
        <source>The proposed values for the parameters are :math:`\alpha=\frac{1}{8}` and :math:`\beta=\frac{1}{4}`. This allows a TCP implementation, implemented in the kernel, to perform the `rtt` computation by using shift operations instead of the more costly floating point operations [Jacobson1988]_. The figure below illustrates the computation of the `rto` upon `rtt` changes.</source>
        <target state="translated">The proposed values for the parameters are :math:`\alpha=\frac{1}{8}` and :math:`\beta=\frac{1}{4}`. This allows a TCP implementation, implemented in the kernel, to perform the `rtt` computation by using shift operations instead of the more costly floating point operations [Jacobson1988]_. The figure below illustrates the computation of the `rto` upon `rtt` changes.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">432</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="57ca5ec0916337b6" weblate-flags="read-only">
        <source>Example computation of the `rto`</source>
        <target state="translated">Example computation of the `rto`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">439</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a22f54fd47e6787c" weblate-flags="read-only">
        <source>Advanced retransmission strategies</source>
        <target state="translated">Advanced retransmission strategies</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">443</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="70605e256ebf2236" weblate-flags="read-only">
        <source>The default go-back-n retransmission strategy was defined in :rfc:`793`. When the retransmission timer expires, TCP retransmits the first unacknowledged segment (i.e. the one having sequence number `snd.una`). After each expiration of the retransmission timeout, :rfc:`2988` recommends to double the value of the retransmission timeout. This is called an `exponential backoff`. This doubling of the retransmission timeout after a retransmission was included in TCP to deal with issues such as network/receiver overload and incorrect initial estimations of the retransmission timeout. If the same segment is retransmitted several times, the retransmission timeout is doubled after every retransmission until it reaches a configured maximum. :rfc:`2988` suggests a maximum retransmission timeout of at least 60 seconds. Once the retransmission timeout reaches this configured maximum, the remote host is considered to be unreachable and the TCP connection is closed.</source>
        <target state="translated">The default go-back-n retransmission strategy was defined in :rfc:`793`. When the retransmission timer expires, TCP retransmits the first unacknowledged segment (i.e. the one having sequence number `snd.una`). After each expiration of the retransmission timeout, :rfc:`2988` recommends to double the value of the retransmission timeout. This is called an `exponential backoff`. This doubling of the retransmission timeout after a retransmission was included in TCP to deal with issues such as network/receiver overload and incorrect initial estimations of the retransmission timeout. If the same segment is retransmitted several times, the retransmission timeout is doubled after every retransmission until it reaches a configured maximum. :rfc:`2988` suggests a maximum retransmission timeout of at least 60 seconds. Once the retransmission timeout reaches this configured maximum, the remote host is considered to be unreachable and the TCP connection is closed.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">447</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="deb11f30a0b2eb23" weblate-flags="read-only">
        <source>This retransmission strategy has been refined based on the experience of using TCP on the Internet. The first refinement was a clarification of the strategy used to send acknowledgments. As TCP uses piggybacking, the easiest and less costly method to send acknowledgments is to place them in the data segments sent in the other direction. However, few application layer protocols exchange data in both directions at the same time and thus this method rarely works. For an application that is sending data segments in one direction only, the remote TCP entity returns empty TCP segments whose only useful information is their acknowledgment number. This may cause a large overhead in wide area network if a pure `ACK` segment is sent in response to each received data segment. Most TCP implementations use a `delayed acknowledgment` strategy. This strategy ensures that piggybacking is used whenever possible, otherwise pure `ACK` segments are sent for every second received data segments when there are no losses. When there are losses or reordering, `ACK` segments are more important for the sender and they are sent immediately :rfc:`813` :rfc:`1122`. This strategy relies on a new timer with a short delay (e.g. 50 milliseconds) and one additional flag in the TCB. It can be implemented as follows.</source>
        <target state="translated">This retransmission strategy has been refined based on the experience of using TCP on the Internet. The first refinement was a clarification of the strategy used to send acknowledgments. As TCP uses piggybacking, the easiest and less costly method to send acknowledgments is to place them in the data segments sent in the other direction. However, few application layer protocols exchange data in both directions at the same time and thus this method rarely works. For an application that is sending data segments in one direction only, the remote TCP entity returns empty TCP segments whose only useful information is their acknowledgment number. This may cause a large overhead in wide area network if a pure `ACK` segment is sent in response to each received data segment. Most TCP implementations use a `delayed acknowledgment` strategy. This strategy ensures that piggybacking is used whenever possible, otherwise pure `ACK` segments are sent for every second received data segments when there are no losses. When there are losses or reordering, `ACK` segments are more important for the sender and they are sent immediately :rfc:`813` :rfc:`1122`. This strategy relies on a new timer with a short delay (e.g. 50 milliseconds) and one additional flag in the TCB. It can be implemented as follows.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">452</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="55104c1181af29af" weblate-flags="read-only">
        <source>Due to this delayed acknowledgment strategy, during a bulk transfer, a TCP implementation usually acknowledges every second TCP segment received.</source>
        <target state="translated">Due to this delayed acknowledgment strategy, during a bulk transfer, a TCP implementation usually acknowledges every second TCP segment received.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">480</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="453b4ceaf4e5dca3" weblate-flags="read-only">
        <source>The default go-back-n retransmission strategy used by TCP has the advantage of being simple to implement, in particular on the receiver side, but when there are losses, a go-back-n strategy provides a lower performance than a selective repeat strategy. The TCP developers have designed several extensions to TCP to allow it to use a selective repeat strategy while maintaining backward compatibility with older TCP implementations. These TCP extensions assume that the receiver is able to buffer the segments that it receives out-of-sequence.</source>
        <target state="translated">The default go-back-n retransmission strategy used by TCP has the advantage of being simple to implement, in particular on the receiver side, but when there are losses, a go-back-n strategy provides a lower performance than a selective repeat strategy. The TCP developers have designed several extensions to TCP to allow it to use a selective repeat strategy while maintaining backward compatibility with older TCP implementations. These TCP extensions assume that the receiver is able to buffer the segments that it receives out-of-sequence.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">482</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dffc4c24beb55c71" weblate-flags="read-only">
        <source>The first extension that was proposed is the fast retransmit heuristic. This extension can be implemented on TCP senders and thus does not require any change to the protocol. It only assumes that the TCP receiver is able to buffer out-of-sequence segments.</source>
        <target state="translated">The first extension that was proposed is the fast retransmit heuristic. This extension can be implemented on TCP senders and thus does not require any change to the protocol. It only assumes that the TCP receiver is able to buffer out-of-sequence segments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">486</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="37a13d93ec2462ac" weblate-flags="read-only">
        <source>From a performance point of view, one issue with TCP's `retransmission timeout` is that when there are isolated segment losses, the TCP sender often remains idle waiting for the expiration of its retransmission timeouts. Such isolated losses are frequent in the global Internet [Paxson99]_.  A heuristic to deal with isolated losses without waiting for the expiration of the retransmission timeout has been included in many TCP implementations since the early 1990s. To understand this heuristic, let us consider the figure below that shows the segments exchanged over a TCP connection when an isolated segment is lost.</source>
        <target state="translated">From a performance point of view, one issue with TCP's `retransmission timeout` is that when there are isolated segment losses, the TCP sender often remains idle waiting for the expiration of its retransmission timeouts. Such isolated losses are frequent in the global Internet [Paxson99]_.  A heuristic to deal with isolated losses without waiting for the expiration of the retransmission timeout has been included in many TCP implementations since the early 1990s. To understand this heuristic, let us consider the figure below that shows the segments exchanged over a TCP connection when an isolated segment is lost.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">488</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b450c856a3b0b77a" weblate-flags="read-only">
        <source>Detecting isolated segment losses</source>
        <target state="translated">Detecting isolated segment losses</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">494</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="743143277ccf03f4" weblate-flags="read-only">
        <source>As shown above, when an isolated segment is lost the sender receives several `duplicate acknowledgments` since the TCP receiver immediately sends a pure acknowledgment when it receives an out-of-sequence segment. A duplicate acknowledgment is an acknowledgment that contains the same `acknowledgment number` as a previous segment. A single duplicate acknowledgment does not necessarily imply that a segment was lost, as a simple reordering of the segments may cause duplicate acknowledgments as well. Measurements  [Paxson99]_ have shown that segment reordering is frequent in the Internet. Based on these observations, the `fast retransmit` heuristic has been included in most TCP implementations. It can be implemented as follows.</source>
        <target state="translated">As shown above, when an isolated segment is lost the sender receives several `duplicate acknowledgments` since the TCP receiver immediately sends a pure acknowledgment when it receives an out-of-sequence segment. A duplicate acknowledgment is an acknowledgment that contains the same `acknowledgment number` as a previous segment. A single duplicate acknowledgment does not necessarily imply that a segment was lost, as a simple reordering of the segments may cause duplicate acknowledgments as well. Measurements  [Paxson99]_ have shown that segment reordering is frequent in the Internet. Based on these observations, the `fast retransmit` heuristic has been included in most TCP implementations. It can be implemented as follows.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">496</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="54ad6ff1cbbc9c01" weblate-flags="read-only">
        <source>This heuristic requires an additional variable in the TCB (`dupacks`). Most implementations set the default number of duplicate acknowledgments that trigger a retransmission to 3. It is now part of the standard TCP specification :rfc:`2581`. The `fast retransmit` heuristic improves the TCP performance provided that isolated segments are lost and the current window is large enough to allow the sender to send three duplicate acknowledgments.</source>
        <target state="translated">This heuristic requires an additional variable in the TCB (`dupacks`). Most implementations set the default number of duplicate acknowledgments that trigger a retransmission to 3. It is now part of the standard TCP specification :rfc:`2581`. The `fast retransmit` heuristic improves the TCP performance provided that isolated segments are lost and the current window is large enough to allow the sender to send three duplicate acknowledgments.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">510</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f6200b933c2c1f4e" weblate-flags="read-only">
        <source>The figure below illustrates the operation of the `fast retransmit` heuristic.</source>
        <target state="translated">The figure below illustrates the operation of the `fast retransmit` heuristic.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">512</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5c769729a6b17d64" weblate-flags="read-only">
        <source>TCP fast retransmit heuristics</source>
        <target state="translated">TCP fast retransmit heuristics</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">518</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0a284a9f2c6dc2be" weblate-flags="read-only">
        <source>When losses are not isolated or when the windows are small, the performance of the `fast retransmit` heuristic decreases. In such environments, it is necessary to allow a TCP sender to use a selective repeat strategy instead of the default go-back-n strategy. Implementing selective-repeat requires a change to the TCP protocol as the receiver needs to be able to inform the sender of the out-of-order segments that it has already received. This can be done by using the Selective Acknowledgments (SACK) option defined in :rfc:`2018`. This TCP option is negotiated during the establishment of a TCP connection. If both TCP hosts support the option, SACK blocks can be attached by the receiver to the segments that it sends. SACK blocks allow a TCP receiver to indicate the blocks of data that it has received correctly but out of sequence. The figure below illustrates the utilization of the SACK blocks.</source>
        <target state="translated">When losses are not isolated or when the windows are small, the performance of the `fast retransmit` heuristic decreases. In such environments, it is necessary to allow a TCP sender to use a selective repeat strategy instead of the default go-back-n strategy. Implementing selective-repeat requires a change to the TCP protocol as the receiver needs to be able to inform the sender of the out-of-order segments that it has already received. This can be done by using the Selective Acknowledgments (SACK) option defined in :rfc:`2018`. This TCP option is negotiated during the establishment of a TCP connection. If both TCP hosts support the option, SACK blocks can be attached by the receiver to the segments that it sends. SACK blocks allow a TCP receiver to indicate the blocks of data that it has received correctly but out of sequence. The figure below illustrates the utilization of the SACK blocks.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">523</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="45757a01cb3a5c2b" weblate-flags="read-only">
        <source>TCP selective acknowledgments</source>
        <target state="translated">TCP selective acknowledgments</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">529</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f46787eb3a3487c3" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">531</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1aa2cceab2674577" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">533</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ba5c67e6f341fc56" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">535</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6f608f344e735cac" weblate-flags="read-only">
        <source>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`.</source>
        <target state="translated">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`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">537</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0f2d5b5d475c3afb" weblate-flags="read-only">
        <source>TCP connection release</source>
        <target state="translated">TCP connection release</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">544</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fe9029e1bb0fd80f" weblate-flags="read-only">
        <source>TCP, like most connection-oriented transport protocols, supports two types of connection releases :</source>
        <target state="translated">TCP, like most connection-oriented transport protocols, supports two types of connection releases :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">548</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c524fb26e31086ef" weblate-flags="read-only">
        <source>graceful connection release, where each TCP user can release its own direction of data transfer after having transmitted all data</source>
        <target state="translated">graceful connection release, where each TCP user can release its own direction of data transfer after having transmitted all data</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">550</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a77a5aff238913f" weblate-flags="read-only">
        <source>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)</source>
        <target state="translated">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)</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">551</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d54d629bf1afcd50" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">555</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c5458a26da1ed3bc" weblate-flags="read-only">
        <source>a non-`SYN` segment was received for a non-existing TCP connection :rfc:`793`</source>
        <target state="translated">a non-`SYN` segment was received for a non-existing TCP connection :rfc:`793`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">557</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="2b9a003bf50c55ac" weblate-flags="read-only">
        <source>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`</source>
        <target state="translated">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`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">558</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="64f425c4699b17e5" weblate-flags="read-only">
        <source>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]_</source>
        <target state="translated">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]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">559</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cae66f29037fa092" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">561</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="468e22b67f520cec" weblate-flags="read-only">
        <source>TCP `RST` wars</source>
        <target state="translated">TCP `RST` wars</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">563</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a34f35f8d7047e97" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">567</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1037fa191a5ee52d" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">570</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9cccd4c7bc1f4844" weblate-flags="read-only">
        <source>Starting from the `Established` state, there are two main paths through this FSM.</source>
        <target state="translated">Starting from the `Established` state, there are two main paths through this FSM.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">603</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4acbfb8c54e7520a" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">605</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1464fb29d6e59ce2" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">607</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="cefa3f2b52ffd80e" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">609</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="d84ca4caa552896c" weblate-flags="read-only">
        <source>TIME\_WAIT on busy TCP servers</source>
        <target state="translated">TIME\_WAIT on busy TCP servers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">611</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f12a34113b6b16dd" weblate-flags="read-only">
        <source>The :math:`2*MSL` seconds delay in the `TIME\_WAIT` state is an important operational problem on servers having thousands of simultaneously opened TCP connections [FTY99]_. Consider for example a busy web server that processes 10.000 TCP connections every second. If each of these connections remains in the `TIME\_WAIT` state for 4 minutes, this implies that the server would have to maintain more than 2 million TCBs at any time. For this reason, some TCP implementations prefer to perform an abrupt connection release by sending a `RST` segment to close the connection [AW05]_ and immediately discard the corresponding :term:`TCB`. However, if the `RST` segment is lost, the remote host continues to maintain a :term:`TCB` for a connection that no longer exists. This optimization reduces the number of TCBs maintained by the host sending the `RST` segment but at the potential cost of increased processing on the remote host when the `RST` segment is lost.</source>
        <target state="translated">The :math:`2*MSL` seconds delay in the `TIME\_WAIT` state is an important operational problem on servers having thousands of simultaneously opened TCP connections [FTY99]_. Consider for example a busy web server that processes 10.000 TCP connections every second. If each of these connections remains in the `TIME\_WAIT` state for 4 minutes, this implies that the server would have to maintain more than 2 million TCBs at any time. For this reason, some TCP implementations prefer to perform an abrupt connection release by sending a `RST` segment to close the connection [AW05]_ and immediately discard the corresponding :term:`TCB`. However, if the `RST` segment is lost, the remote host continues to maintain a :term:`TCB` for a connection that no longer exists. This optimization reduces the number of TCBs maintained by the host sending the `RST` segment but at the potential cost of increased processing on the remote host when the `RST` segment is lost.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">613</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">620</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="08b3788e273aea0b" weblate-flags="read-only">
        <source>A detailed presentation of all standardization documents concerning TCP may be found in :rfc:`4614`</source>
        <target state="translated">A detailed presentation of all standardization documents concerning TCP may be found in :rfc:`4614`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">621</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="665c09bbb7791b52" weblate-flags="read-only">
        <source>Several researchers have analyzed the utilization of TCP and UDP in the global Internet. Most of these studies have been performed by collecting all the packets transmitted over a given link during a period of a few hours or days and then analyzing their headers to infer the transport protocol used, the type of application, ... Recent studies include http://www.caida.org/research/traffic-analysis/tcpudpratio/, https://research.sprintlabs.com/packstat/packetoverview.php or http://www.nanog.org/meetings/nanog43/presentations/Labovitz_internetstats_N43.pdf</source>
        <target state="translated">Several researchers have analyzed the utilization of TCP and UDP in the global Internet. Most of these studies have been performed by collecting all the packets transmitted over a given link during a period of a few hours or days and then analyzing their headers to infer the transport protocol used, the type of application, ... Recent studies include http://www.caida.org/research/traffic-analysis/tcpudpratio/, https://research.sprintlabs.com/packstat/packetoverview.php or http://www.nanog.org/meetings/nanog43/presentations/Labovitz_internetstats_N43.pdf</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">623</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e8a05a5edd70d95f" weblate-flags="read-only">
        <source>This 32 bits counter was specified in :rfc:`793`. A 32 bits counter that is incremented every 4 microseconds wraps in about 4.5 hours. This period is much larger than the Maximum Segment Lifetime that is fixed at 2 minutes in the Internet (:rfc:`791`, :rfc:`1122`).</source>
        <target state="translated">This 32 bits counter was specified in :rfc:`793`. A 32 bits counter that is incremented every 4 microseconds wraps in about 4.5 hours. This period is much larger than the Maximum Segment Lifetime that is fixed at 2 minutes in the Internet (:rfc:`791`, :rfc:`1122`).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">625</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5896b40b67ab9fc8" weblate-flags="read-only">
        <source>On many departmental networks containing Unix workstations, it was common to allow users on one of the hosts to use ``rlogin`` :rfc:`1258`  to run commands on any of the workstations of the network without giving any password. In this case, the remote workstation "authenticated" the client host based on its IP address. This was a bad practice from a security viewpoint.</source>
        <target state="translated">On many departmental networks containing Unix workstations, it was common to allow users on one of the hosts to use ``rlogin`` :rfc:`1258`  to run commands on any of the workstations of the network without giving any password. In this case, the remote workstation "authenticated" the client host based on its IP address. This was a bad practice from a security viewpoint.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">627</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="894b1402f47f5e6c" weblate-flags="read-only">
        <source>Of course, such a simultaneous TCP establishment can only occur if the source port chosen by the client is equal to the destination port chosen by the server. This may happen when a host can serve both as a client as a server or in peer-to-peer applications when the communicating hosts do not use ephemeral port numbers.</source>
        <target state="translated">Of course, such a simultaneous TCP establishment can only occur if the source port chosen by the client is equal to the destination port chosen by the server. This may happen when a host can serve both as a client as a server or in peer-to-peer applications when the communicating hosts do not use ephemeral port numbers.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">634</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f6898e65cff308cd" weblate-flags="read-only">
        <source>Sending a packet with a different source IP address than the address allocated to the host is called sending a :term:`spoofed packet`.</source>
        <target state="translated">Sending a packet with a different source IP address than the address allocated to the host is called sending a :term:`spoofed packet`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">636</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="637bebe8c1496841" weblate-flags="read-only">
        <source>The full list of all TCP options may be found at http://www.iana.org/assignments/tcp-parameters/</source>
        <target state="translated">The full list of all TCP options may be found at http://www.iana.org/assignments/tcp-parameters/</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">638</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="df8e8f4b91ef60ee" weblate-flags="read-only">
        <source>In practice, only the `SYN` segment do not have their `ACK` flag set.</source>
        <target state="translated">In practice, only the `SYN` segment do not have their `ACK` flag set.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">640</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ec4581e0ae89d681" weblate-flags="read-only">
        <source>A complete TCP implementation contains additional information in its TCB, notably to support the `urgent` pointer. However, this part of TCP is not discussed in this book. Refer to :rfc:`793` and :rfc:`2140` for more details about the TCB.</source>
        <target state="translated">A complete TCP implementation contains additional information in its TCB, notably to support the `urgent` pointer. However, this part of TCP is not discussed in this book. Refer to :rfc:`793` and :rfc:`2140` for more details about the TCB.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">642</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8d69afd597461467" weblate-flags="read-only">
        <source>This TCP segment is then placed in an IP header. We describe IPv6 in the next chapter. The minimum size of the IPv6 (resp. IPv4) header is 40 bytes (resp. 20 bytes).</source>
        <target state="translated">This TCP segment is then placed in an IP header. We describe IPv6 in the next chapter. The minimum size of the IPv6 (resp. IPv4) header is 40 bytes (resp. 20 bytes).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">646</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6c2d565811ad6d79" weblate-flags="read-only">
        <source>A precise estimation of the maximum bandwidth that can be achieved by a TCP connection should take into account the overhead of the TCP and IP headers as well.</source>
        <target state="translated">A precise estimation of the maximum bandwidth that can be achieved by a TCP connection should take into account the overhead of the TCP and IP headers as well.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">649</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bf756f049d8dd09d" weblate-flags="read-only">
        <source>See http://fasterdata.es.net/tuning.html for more information on how to tune a TCP implementation</source>
        <target state="translated">See http://fasterdata.es.net/tuning.html for more information on how to tune a TCP implementation</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">651</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8189fac32f673c44" weblate-flags="read-only">
        <source>In theory, a TCP implementation could store the timestamp of each data segment transmitted and compute a new estimate for the round-trip-time upon reception of the corresponding acknowledgment. However, using such frequent measurements introduces a lot of noise in practice and many implementations still measure the round-trip-time once per round-trip-time by recording the transmission time of one segment at a time :rfc:`2988`</source>
        <target state="translated">In theory, a TCP implementation could store the timestamp of each data segment transmitted and compute a new estimate for the round-trip-time upon reception of the corresponding acknowledgment. However, using such frequent measurements introduces a lot of noise in practice and many implementations still measure the round-trip-time once per round-trip-time by recording the transmission time of one segment at a time :rfc:`2988`</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">653</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="708cb4661cf560ba" weblate-flags="read-only">
        <source>Some security experts have raised concerns that using the real-time clock to set the `TSval` in the timestamp option can leak information such as the system's up-time. Solutions proposed to solve this problem may be found in [CNPI09]_</source>
        <target state="translated">Some security experts have raised concerns that using the real-time clock to set the `TSval` in the timestamp option can leak information such as the system's up-time. Solutions proposed to solve this problem may be found in [CNPI09]_</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">655</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fa50f50ccc47e25b" weblate-flags="read-only">
        <source>As a TCP client often establishes several parallel or successive connections with the same server, :rfc:`2140` has proposed to reuse for a new connection some information that was collected in the TCB of a previous connection, such as the measured rtt. However, this solution has not been widely implemented.</source>
        <target state="translated">As a TCP client often establishes several parallel or successive connections with the same server, :rfc:`2140` has proposed to reuse for a new connection some information that was collected in the TCB of a previous connection, such as the measured rtt. However, this solution has not been widely implemented.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../protocols/tcp.rst</context>
          <context context-type="linenumber">657</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
