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

94 ../../protocols/tcp.rst:270
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `sending buffer` : a buffer used to store all unacknowledged data 65/10000 · 65
95 ../../protocols/tcp.rst:271
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `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 260/10000 · 260
96 ../../protocols/tcp.rst:274
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 175/10000 · 175
97 ../../protocols/tcp.rst:276
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 868/10000 · 868
98 ../../protocols/tcp.rst:278
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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`. 778/10000 · 778
99 ../../protocols/tcp.rst:281
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Segment transmission strategies 31/10000 · 31
100 ../../protocols/tcp.rst:289
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 848/10000 · 848
101 ../../protocols/tcp.rst:291
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 421/10000 · 421
102 ../../protocols/tcp.rst:303
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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. 182/10000 · 182
103 ../../protocols/tcp.rst:307
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 : 379/10000 · 379
104 ../../protocols/tcp.rst:309
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 194/10000 · 194
105 ../../protocols/tcp.rst:310
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 220/10000 · 220
106 ../../protocols/tcp.rst:315
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Recent measurements <http://www.caida.org/research/traffic-analysis/pkt_size_distribution/graphs.xml>`_ 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]_. 380/10000 · 380
107 ../../protocols/tcp.rst:322
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TCP windows 11/10000 · 11
108 ../../protocols/tcp.rst:329
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 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 679/10000 · 679
109 ../../protocols/tcp.rst:332 • ../../protocols/tcp.rst:345
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — RTT 3/10000 · 3
110 ../../protocols/tcp.rst:332 • ../../protocols/tcp.rst:345
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Maximum Throughput 18/10000 · 18
111 ../../protocols/tcp.rst:334 • ../../protocols/tcp.rst:347
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 1 msec 6/10000 · 6
112 ../../protocols/tcp.rst:334
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 524 Mbps 8/10000 · 8
113 ../../protocols/tcp.rst:335 • ../../protocols/tcp.rst:348
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 10 msec 7/10000 · 7