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

115 ../../protocols/tcp.rst:336 • ../../protocols/tcp.rst:349
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 100 msec 8/10000 · 8
116 ../../protocols/tcp.rst:336
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 5.24 Mbps 9/10000 · 9
117 ../../protocols/tcp.rst:337 • ../../protocols/tcp.rst:350
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 500 msec 8/10000 · 8
118 ../../protocols/tcp.rst:337
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 1.05 Mbps 9/10000 · 9
119 ../../protocols/tcp.rst:340
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 >> 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. 1023/10000 · 1023
120 ../../protocols/tcp.rst:342
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 : 234/10000 · 234
121 ../../protocols/tcp.rst:347
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 8590 Gbps 9/10000 · 9
122 ../../protocols/tcp.rst:348
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 859 Gbps 8/10000 · 8
123 ../../protocols/tcp.rst:349
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 86 Gbps 7/10000 · 7
124 ../../protocols/tcp.rst:350
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 17 Gbps 7/10000 · 7
125 ../../protocols/tcp.rst:357
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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]_. 368/10000 · 368
126 ../../protocols/tcp.rst:362
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP's retransmission timeout 28/10000 · 28
127 ../../protocols/tcp.rst:364
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 467/10000 · 467
128 ../../protocols/tcp.rst:366
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 373/10000 · 373
129 ../../protocols/tcp.rst:372
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Evolution of the round-trip-time between two hosts 50/10000 · 50
130 ../../protocols/tcp.rst:375
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 301/10000 · 301
131 ../../protocols/tcp.rst:381
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How to measure the round-trip-time ? 36/10000 · 36
132 ../../protocols/tcp.rst:388
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 514/10000 · 514
133 ../../protocols/tcp.rst:394
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 736/10000 · 736
134 ../../protocols/tcp.rst:400
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Disambiguating round-trip-time measurements with the :rfc:`1323` timestamp option 81/10000 · 81