The translation has come to an end.
Exit Zen
83
../../protocols/tcp.rst:259
English
the local IP address
0/200 · 20
84
../../protocols/tcp.rst:260
English
the remote IP address
0/210 · 21
85
../../protocols/tcp.rst:261
English
the local TCP port number
0/250 · 25
86
../../protocols/tcp.rst:262
English
the remote TCP port number
0/260 · 26
87
../../protocols/tcp.rst:263
English
the current state of the TCP FSM
0/320 · 32
88
../../protocols/tcp.rst:264
English
the `maximum segment size` (MSS)
0/320 · 32
89
../../protocols/tcp.rst:265
English
`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)
0/1460 · 146
90
../../protocols/tcp.rst:266
English
`snd.una` : the earliest sequence number that has been sent but has not yet been acknowledged
0/930 · 93
91
../../protocols/tcp.rst:267
English
`snd.wnd` : the current size of the sending window (in bytes)
0/610 · 61
92
../../protocols/tcp.rst:268
English
`rcv.nxt` : the sequence number of the next byte that is expected to be received from the remote host
0/1010 · 101
93
../../protocols/tcp.rst:269
English
`rcv.wnd` : the current size of the receive window advertised by the remote host
0/800 · 80
94
../../protocols/tcp.rst:270
English
`sending buffer` : a buffer used to store all unacknowledged data
0/650 · 65
95
../../protocols/tcp.rst:271
English
`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
0/2600 · 260
96
../../protocols/tcp.rst:274
English
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.
0/1750 · 175
97
../../protocols/tcp.rst:276
English
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.
0/8680 · 868
98
../../protocols/tcp.rst:278
English
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`.
0/7780 · 778
99
../../protocols/tcp.rst:281
English
Segment transmission strategies
0/310 · 31
100
../../protocols/tcp.rst:289
English
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.
0/8480 · 848
101
../../protocols/tcp.rst:291
English
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.
0/4210 · 421
102
../../protocols/tcp.rst:303
English
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.
0/1820 · 182