msgid "" msgstr "" "Project-Id-Version: French (cnp3-ebook)\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2026-04-19 09:14+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: French \n" "Language: fr\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=n > 1;\n" "X-Generator: Weblate 5.14.3\n" #: ../../exercises/tcp-2.rst:8 msgid "A closer look at TCP" msgstr "" #: ../../exercises/tcp-2.rst:10 msgid "" "In this series of exercises, you will explore in more details the operation " "of TCP and its congestion control scheme. TCP is a very important protocol " "in today's Internet since most applications use it to exchange data. We " "first look at TCP in more details by injecting segments in the Linux TCP " "stack and analyze how the stack reacts. Then we study the TCP congestion " "control scheme." msgstr "" #: ../../exercises/tcp-2.rst:14 msgid "Injecting segments in the Linux TCP stack" msgstr "" #: ../../exercises/tcp-2.rst:16 msgid "" "Packet capture tools like tcpdump_ and Wireshark_ are very useful to observe " "the segments that transport protocols exchange. TCP is a complex protocol " "that has evolved a lot since its first specification :rfc:`793`. TCP " "includes a large number of heuristics that influence the reaction of a TCP " "implementation to various types of events. A TCP implementation interacts " "with the application through the ``socket`` API." msgstr "" #: ../../exercises/tcp-2.rst:18 msgid "" "packetdrill_ is a TCP test suite that was designed to develop unit tests to " "verify the correct operation of a TCP implementation. A more detailed " "description of packetdrill_ may be found in [CCB+2013]_. packetdrill_ uses a " "syntax which is a mix between the C language and the tcpdump_ syntax. To " "understand the operation of packetdrill_, we first discuss several examples. " "The TCP implementation in the Linux kernel supports all the recent TCP " "extensions to improve its performance. For pedagogical reasons, we disable " "[#fsysctl]_ most of these extensions to use a simple TCP stack. packetdrill_ " "can be easily installed on recent Linux kernels [#finstall]_." msgstr "" #: ../../exercises/tcp-2.rst:20 msgid "" "Let us start with a very simple example that uses packetdrill_ to open a TCP " "connection on a server running on the Linux kernel. A packetdrill_ script is " "a sequence of lines that are executed one after the other. There are three " "main types of lines in a packetdrill_ script." msgstr "" #: ../../exercises/tcp-2.rst:22 msgid "packetdrill_ executes a system call and verifies its return value" msgstr "" #: ../../exercises/tcp-2.rst:23 msgid "" "packetdrill_ injects [#ftcpdump_pdrill]_ a packet in the instrumented Linux " "kernel as if it were received from the network" msgstr "" #: ../../exercises/tcp-2.rst:24 msgid "" "packetdrill_ compares a packet transmitted by the instrumented Linux kernel " "with the packet that the script expects" msgstr "" #: ../../exercises/tcp-2.rst:26 msgid "" "For our first packetdrill_ script, we aim at reproducing the simple " "connection shown in the figure below." msgstr "" #: ../../exercises/tcp-2.rst:57 msgid "" "Let us start with the execution of a system call. A simple example is shown " "below." msgstr "" #: ../../exercises/tcp-2.rst:63 msgid "" "The ``0`` indicates that the system call must be issued immediately. " "packetdrill_ then executes the system call and verifies that it returns " "``3```. If yes, the processing continues. Otherwise the script stops and " "indicates an error." msgstr "" #: ../../exercises/tcp-2.rst:65 msgid "" "For this first example, we program packetdrill_ to inject the segments that " "a client would send. The first step is thus to prepare a :manpage:`socket` " "that can be used to accept this connection. This socket can be created by " "using the four system calls below." msgstr "" #: ../../exercises/tcp-2.rst:80 msgid "" "At this point, the socket is ready to accept incoming TCP connections. " "packetdrill_ needs to inject a TCP segment in the instrumented Linux stack. " "This can be done with the line below." msgstr "" #: ../../exercises/tcp-2.rst:86 msgid "" "Each line of a packetdrill_ script starts with a `timing` parameter that " "indicates at what time the event specified on this line should happen. " "packetdrill_ supports absolute and relative timings. An absolute timing is " "simply a number that indicates the delay in seconds between the start of the " "script and the event. A relative timing is indicated by using ``+`` " "followed by a number. This number is then the delay in seconds between the " "previous event and the current line. Additional information may be found in " "[CCB+2013]_." msgstr "" #: ../../exercises/tcp-2.rst:88 msgid "" "The description of TCP packets in packetdrill_ uses a syntax that is very " "close to the tcpdump_ one. The ``+0`` timing indicates that the line is " "executed immediately after the previous event. The ``<`` sign indicates that " "packetdrill_ injects a TCP segment and the ``S`` character indicates that " "the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence " "numbers that are relative to initial sequence number. The three numbers that " "follow are the sequence number of the first byte of the payload of the " "segment (``0``), the sequence number of the last byte of the payload of the " "segment (``0`` after the semi-column) and the length of the payload " "(``0`` between brackets) of the ``SYN`` segment. This segment does not " "contain a valid acknowledgment but advertises a window of 1000 bytes. All " "``SYN`` segments must also include the ``MSS`` option. In this case, we set " "the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the " "reply sent by the instrumented Linux kernel." msgstr "" #: ../../exercises/tcp-2.rst:95 msgid "" "This TCP segment is sent immediately by the stack. The ``SYN`` flag is set " "and the dot next to the ``S`` character indicates that the ACK flag is also " "set. The SYN+ACK segment does not contain any data but its acknowledgment " "number is set to 1 (relative to the initial sequence number). For outgoing " "packets, packetdrill_ does not verify the value of the advertised window. In " "this line, it also accepts any TCP options (``<...>``)." msgstr "" #: ../../exercises/tcp-2.rst:98 msgid "" "The third segment of the three-way handshake is sent by packetdrill_ after a " "delay of 0.1 seconds. The connection is now established and the accept " "system call will succeed." msgstr "" #: ../../exercises/tcp-2.rst:105 msgid "" "The :manpage:`accept` system call returns a new file descriptor, in this " "case value ``4``. At this point, packetdrill_ can write data on the socket " "or inject packets." msgstr "" #: ../../exercises/tcp-2.rst:113 msgid "" "packetdrill_ writes 10 bytes of data through the :manpage:`write` system " "call. The stack immediately sends these 10 bytes inside a segment whose " "``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` " "and ends at sequence number ``10``. packetdrill_ replies by injecting an " "acknowledgment for the entire data after 100 milliseconds." msgstr "" #: ../../exercises/tcp-2.rst:115 msgid "" "packetdrill_ can also inject data that will be read by the stack as shown by " "the lines below." msgstr "" #: ../../exercises/tcp-2.rst:123 msgid "" "In the example above, packetdrill_ injects a segment containing two bytes. " "This segment is acknowledged and after that the :manpage:`read` system call " "succeeds and reads the available data with a buffer of 1000 bytes. It " "returns the amount of read bytes, i.e. ``2``." msgstr "" #: ../../exercises/tcp-2.rst:125 msgid "" "We can now close the connection gracefully. Let us first issue inject a " "segment with the ``FIN`` flag set." msgstr "" #: ../../exercises/tcp-2.rst:133 msgid "" "packetdrill_ injects the ``FIN`` segment and the instrumented kernel returns " "an acknowledgment. If packetdrill_ issues the :manpage:`close` system call, " "the kernel will send a ``FIN`` segment to terminate the connection. " "packetdrill_ injects an acknowledgment to confirm the end of the connection." msgstr "" #: ../../exercises/tcp-2.rst:142 msgid "" "The complete packetdrill_ script is available from :download:`/exercises/" "packetdrill_scripts/connect.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:145 msgid "" "Another interesting features of packetdrill_ is that it is possible to " "inspect the state maintained by the Linux kernel for the underlying " "connection using the ``TCP_INFO`` socket option. This makes it possible to " "retrieve the value of some variables of the TCP control block." msgstr "" #: ../../exercises/tcp-2.rst:147 msgid "" "Let us first explore how a TCP connection can be established. In the " "previous script, we have injected the segments that a client would send to a " "server. We can also use the Linux stack as a client and inject the segments " "that a server would return. Such a client process would first create its " ":manpage:`socket`` and then issue the :manpage:`connect` system call. At " "this point, the stack sends a ``SYN`` segment. To simplify the scripts, we " "have configured the stack to use a ``MSS`` of 1000 bytes and disabled the " "TCP extensions (the details of this configuration may be found at the " "beginning of the script). The server replies with a ``SYN+ACK`` and the " "stack sends acknowledges it to finish the three-way-handshake." msgstr "" #: ../../exercises/tcp-2.rst:165 msgid "" "The ``tcpi_state`` variable used in this script is returned by ``TCP_INFO`` " "[#ftcpinfo]_. It tracks the state of the TCP connection according to TCP's " "finite state machine [#fstates]_. This script is available from :download:`/" "exercises/packetdrill_scripts/client.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:167 msgid "" "Another example is the simultaneous establishment of a TCP connection. The " "TCP stack sends a ``SYN`` and receives a ``SYN`` in response instead of a " "``SYN+ACK``. It then acknowledges the received ``SYN`` and retransmits its " "own ``SYN``. The connection becomes established upon reception of the fourth " "segment. This script is available from :download:`/exercises/" "packetdrill_scripts/dual.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:191 msgid "" "Another usage of packetdrill_ is to explore how a TCP connection ends. The " "scripts below show how a TCP stack closes a TCP connection. The first " "example shows a local host that connects to a remote host and then closes " "the connection. The remote host acknowledges the ``FIN`` and later closes " "its direction of data transfer. This script is available from :download:`/" "exercises/packetdrill_scripts/local-close.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:213 msgid "" "As for the establishment of a connection, it is also possible for the two " "communicating hosts to close the connection at the same time. This is shown " "in the example below where the remote host sends its own ``FIN`` when " "acknowledging the first one. This script is available from :download:`/" "exercises/packetdrill_scripts/local-close2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:234 msgid "" "A third scenario for the termination of a TCP connection is that the remote " "hosts sends its ``FIN`` first. This script is available from :download:`/" "exercises/packetdrill_scripts/remote-close.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:259 msgid "" "Another very interesting utilization of packetdrill_ is to explore how a TCP " "stack reacts to acknowledgments that would correspond to lost or reordered " "segments. For this analysis, we configure a very large initial congestion " "window to ensure that the connection does not start with a slow-start." msgstr "" #: ../../exercises/tcp-2.rst:261 msgid "" "Let us first use packetdrill_ to explore the evolution of the TCP " "retransmission timeout. The value of this timeout is set based on the " "measured round-trip-time and its variance. When the retransmission timer " "expires, TCP doubles the retransmission timer. This exponential backoff " "mechanism is important to ensure that TCP slowdowns during very severe " "congestion periods. We use the ``tcpi_rto`` variable from ``TCP_INFO`` to " "track the evolution of the retransmission timer. This script is available " "from :download:`/exercises/packetdrill_scripts/rto.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:293 msgid "" "We can use a similar code to demonstrate that the TCP stack performs a fast " "retransmit after having received three duplicate acknowledgments. This " "script is available from :download:`/exercises/packetdrill_scripts/frr.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:326 msgid "" "A TCP stack uses both the fast retransmit technique and retransmission " "timers. A retransmission timer can fire after a fast retransmit when several " "segments are lost. The example below shows a loss of two consecutive " "segments. This script is available from :download:`/exercises/" "packetdrill_scripts/frr-rto.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:364 msgid "" "More complex scenarios can be written. The script below demonstrates how the " "TCP stack behaves when three segments are lost. This script is available " "from :download:`/exercises/packetdrill_scripts/frr-rto2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:411 msgid "" "The examples above have demonstrated how TCP retransmits lost segments. " "However, they did not consider the interactions with the congestion control " "scheme since the use a large initial congestion window. We now set the " "initial congestion window to two MSS-sized segments and use the " "``tcpi_snd_cwnd`` and ``tcpi_snd_ssthresh`` variables from ``TCP_INFO`` to " "explore the evolution of the TCP congestion control scheme. Our first script " "looks at the evolution of the congestion window during a slow-start when " "there are no losses. This script is available from :download:`/exercises/" "packetdrill_scripts/slow-start.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:459 msgid "" "Some TCP clients use delayed acknowledgments and send a TCP acknowledgment " "after after second in-sequence segment. This behavior is illustrated in the " "script below. This script is available from :download:`/exercises/" "packetdrill_scripts/slow-start-delayed.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:502 msgid "" "We can now explore how TCP's retransmission techniques interact with the " "congestion control scheme. The Linux TCP code that combines these two " "techniques contains several heuristics to improve their performance. We " "start with a transfer of 8KBytes where the penultimate segment is not " "received by the remote host. In this case, TCP does not receive enough " "acknowledgments to trigger the fast retransmit and it must wait for the " "expiration of the retransmission timer. This script is available from " ":download:`/exercises/packetdrill_scripts/slow-start-rto2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:546 msgid "" "Another interesting scenario is when the loss happens early in the data " "transfer. This is shown in the script below where the second segment is " "lost. We observe that by triggering transmissions of unacknowledged data, " "the :rfc:`3042` rule speeds up the recovery since a fast retransmit happens. " "This script is available from :download:`/exercises/packetdrill_scripts/slow-" "start-frr2.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:593 msgid "" "Our last scenario is when the first segment sent is lost. In this case, two " "round-trip-times are required to retransmit the missing segment and recover " "from the loss. This script is available from :download:`/exercises/" "packetdrill_scripts/slow-start-frr3.pkt`." msgstr "" #: ../../exercises/tcp-2.rst:637 msgid "Open questions" msgstr "" #: ../../exercises/tcp-2.rst:639 msgid "" "Unless otherwise noted, we assume for the questions in this section that the " "following conditions hold." msgstr "" #: ../../exercises/tcp-2.rst:641 msgid "the sender/receiver performs a single :manpage:`send(3)` of `x` bytes" msgstr "" #: ../../exercises/tcp-2.rst:642 msgid "" "the round-trip-time is fixed and does not change during the lifetime of the " "TCP connection. We assume a fixed value of 100 milliseconds for the round-" "trip-time and a fixed value of 200 milliseconds for the retransmission timer." msgstr "" #: ../../exercises/tcp-2.rst:643 msgid "" "the delay required to transmit a single TCP segment containing MSS bytes is " "small and set to 1 milliseconds, independently of the MSS size" msgstr "" #: ../../exercises/tcp-2.rst:644 msgid "the transmission delay for a TCP acknowledgment is negligible" msgstr "" #: ../../exercises/tcp-2.rst:645 msgid "the initial value of the congestion window is one MSS-sized segment" msgstr "" #: ../../exercises/tcp-2.rst:646 msgid "" "the value of the duplicate acknowledgment threshold is fixed and set to 3" msgstr "" #: ../../exercises/tcp-2.rst:647 msgid "TCP always acknowledges each received segment" msgstr "" #: ../../exercises/tcp-2.rst:649 msgid "" "To understand the operation of the TCP congestion control, it is often " "useful to write time-sequence diagrams for different scenarios. The example " "below shows the operation of the TCP congestion control scheme in a very " "simple scenario. The initial congestion window (``cwnd``) is set to 1000 " "bytes and the receive window (``rwin``) advertised by the receiver " "(supposed constant for the entire connection) is set to 2000 bytes. The slow-" "start threshold (``ssthresh``) is set to 64000 bytes." msgstr "" #: ../../exercises/tcp-2.rst:684 msgid "" "Can you explain why the sender only sends one segment first and then two " "successive segments (the delay between the two segments on the figure is due " "to graphical reasons) ?" msgstr "" #: ../../exercises/tcp-2.rst:686 msgid "" "Can you explain why the congestion window is increased after the reception " "of the first acknowledgment ?" msgstr "" #: ../../exercises/tcp-2.rst:688 msgid "" "How long does it take for the sender to deliver 3 KBytes to the receiver ?" msgstr "" #: ../../exercises/tcp-2.rst:691 msgid "" "Same question as above but now with a small variation. Recent TCP " "implementations use a large initial value for the congestion window. Draw " "the time-sequence diagram that corresponds to an initial value of 10000 " "bytes for this congestion window." msgstr "" #: ../../exercises/tcp-2.rst:715 msgid "" "Same question as the first one, but consider that the MSS on the sender is " "set to 500 bytes. How does this modification affect the entire delay ?" msgstr "" #: ../../exercises/tcp-2.rst:738 msgid "" "Assuming that there are no losses and that there is no congestion in the " "network. If the sender writes `x` bytes on a newly established TCP " "connection, derive a formula that computes the minimum time required to " "deliver all these `x` bytes to the receiver. For the derivation of this " "formula, assume that `x` is a multiple of the maximum segment size and that " "the receive window and the slow-start threshold are larger than `x`." msgstr "" #: ../../exercises/tcp-2.rst:740 msgid "" "In question 1, we assumed that the receiver acknowledged every segment " "received from the sender. In practice, many deployed TCP implementations use " "delayed acknowledgments. Assuming a delayed acknowledgment timer of 50 " "milliseconds, modify the time-sequence diagram below to reflect the impact " "of these delayed acknowledgment. Does their usage decreases or increased the " "transmission delay ?" msgstr "" #: ../../exercises/tcp-2.rst:775 msgid "" "Let us now explore the impact of congestion on the slow-start and congestion " "avoidance mechanisms. Consider the scenario below. For graphical reasons, it " "is not possible anymore to show information about the segments on the graph, " "but you can easily infer them." msgstr "" #: ../../exercises/tcp-2.rst:832 msgid "" "Redraw the same figure assuming that the second segment that was delivered " "by the sender in the figure experienced congestion. In a network that uses " "Explicit Congestion Notification, this segment would be marked by routers " "and the receiver would return the congestion mark in the corresponding " "acknowledgment." msgstr "" #: ../../exercises/tcp-2.rst:834 msgid "" "Same question, but assume now that the fourth segment delivered by the " "sender experienced congestion (but was not discarded)." msgstr "" #: ../../exercises/tcp-2.rst:837 msgid "" "A TCP connection has been active for some time and has reached a congestion " "window of 4000 bytes. Four segments are sent, but the second " "(shown in red in the figure) is corrupted. Complete the time-sequence " "diagram." msgstr "" #: ../../exercises/tcp-2.rst:876 msgid "" "On Linux, most of the parameters to tune the TCP stack are accessible via " ":manpage:`sysctl`. These parameters are briefly described in https://" "github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt " "and in the :manpage:`tcp` manpage. Each script sets some of these " "configuration variables." msgstr "" #: ../../exercises/tcp-2.rst:883 msgid "" "packetdrill_ requires root privileges since it inject raw IP packets. The " "easiest way to install it is to use a virtualbox image with a Linux kernel " "4.x or 5.x. You can clone its git repository from https://github.com/google/" "packetdrill and follow the instructions in https://github.com/google/" "packetdrill/tree/master/gtests/net/packetdrill. The packetdrill_ scripts " "used in this section are available from https://github.com/cnp3/ebook/tree/" "master/exercises/packetdrill_scripts" msgstr "" #: ../../exercises/tcp-2.rst:885 msgid "" "By default, packetdrill_ uses port 8080 when creating TCP segments. You can " "thus capture the packets injected by packetdrill_ and the responses from the " "stack by using ``tcpdump -i any -n port 8080``" msgstr "" #: ../../exercises/tcp-2.rst:887 msgid "" "The `Push` flag is one of the TCP flags defined in :rfc:`793`. TCP stacks " "usually set this flag when transmitting a segment that empties the send " "buffer. This is the reason why we observe this push flag in our example." msgstr "" #: ../../exercises/tcp-2.rst:889 msgid "" "The variables that are included in TCP_INFO are defined in https://" "github.com/torvalds/linux/blob/master/include/uapi/linux/tcp.h" msgstr "" #: ../../exercises/tcp-2.rst:891 msgid "" "These states are defined in https://github.com/torvalds/linux/blob/master/" "include/net/tcp_states.h" msgstr ""