19-TCP Interactive Data Flow

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1

Welcome to my github: https://github.com/gaoxiangnumber1

19.1 Introduction

19.2 Interactive Input

• We use Rlogin in this chapter because it always sends one character at a time from the client to the server. Telnet(Chapter 26) has an option that allows lines of input to be sent from the client to the server, which reduces the network load.
• Figure 19.1. Rlogin has the server echo the characters that the client type. This generates four segments:
  (1) the interactive keystroke from the client,
  (2) an acknowledgment of the keystroke from the server,
  (3) the echo of the keystroke from the server, and
  (4) an acknowledgment of the echo from the client.

• Delayed acknowledgments: segments 2 and 3 can be combined(the acknowledgment is sent along with the data).
• Figure 19.2 shows the flow of data when we type the five characters date\n.(We do not show the connection establishment.)

• Line 1 sends the character ‘d’ from the client to the server.
  Line 2 is the acknowledgment of this character and its echo. This is combining the middle two segments in Figure 19.1.
  Line 3 is the acknowledgment of the echoed character.
• Lines 4-6 correspond to the character a, lines 7-9 to the character t, and lines 10-12 to the character e. The delays between lines 3-4, 6-7, 9-10, and 12-13 are the human delays between typing each character.
• Lines 13-15: The newline character ‘\n’ is sent from the client to the server but two characters “\r\n” are echoed.
• Line 16 is the output of the date command from the server. The 30 bytes are “Sat Feb 6 07:52:17 MST 1993\r\n”.
  The next 7 bytes sent from server to client(line 18) are the client’s prompt on the server host “svr4 %”.
  Line 19 acknowledges these 7 bytes.

19.3 Delayed Acknowledgments

• TCP delays the ACK, hoping to have data going in the same direction as the ACK, so the ACK can be sent along with the data. This is also called having the ACK piggyback with the data. Most TCP implementations use a 200-ms delay.
  Figure 19.3 shows the time line for the exchange in Figure 19.2.

• TCP has a timer that goes off every 200 ms, but it goes off at fixed points in time, that is, every 200ms relative to when the kernel was bootstrapped. Since the data being acknowledged arrives randomly, TCP asks to be notified the next time the kernel’s 200-ms timer expires. This can be anywhere from 1 to 200 ms in the future.

19.4 Nagle Algorithm

• Nagle algorithm says that a TCP connection can have only one outstanding small segment that has not yet been acknowledged. No additional small segments can be sent until the acknowledgment is received. Small amounts of data are collected by TCP and sent in a single segment when the acknowledgment arrives.
  This algorithm is self-clocking: the faster the ACKs come back, the faster the data is sent.

• Figure 19.4 shows the time line of data flow while characters were typed quickly on the client.
• Different amounts of data are sent from left to right(1, 1, 2, 1, 2, 2, 3, 1, and 3 bytes) because the client is collecting the data to send, but doesn’t send it until the previously sent data has been acknowledged. By using Nagle algorithm, only 9 segments were used to send 16 bytes, instead of 16 segments.
• Segments 14 and 15: Segment 14 is in response to the ACK received in segment 12 since the acknowledged sequence number is 54. But before this data segment is sent by the client, segment 13 arrives from the server. Segment 15 contains the ACK of segment 13, sequence number 56. So the client is obeying the Nagle algorithm, even though we see two back-to-back data segments from the client to the server.
• The segment 12 ACK is delayed because it contains no data, the server was not able to echo the character before the delayed ACK timer expired.
• Look at the amounts of data and the sequence numbers in the final two segments. The client sends 3 bytes of data(numbered [18, 20]), then the server acknowledges these 3 bytes(ACK = 21 in the final segment) but sends back only 1 byte(number 59).
• Here the server’s TCP is acknowledging the 3 bytes of data once it has received them correctly, but it won’t have the echo of these 3 bytes ready to send back until the server sends them. TCP can acknowledge received data before the application has read and processed that data. The TCP acknowledgment just means TCP has correctly received the data.
  Another indication that the server process has not read these 3 bytes of data is that the advertised window in the final segment is 8189, not 8192.

Disabling the Nagle Algorithm

• The sockets API uses the TCP_NODELAY socket option to disable the Nagle algorithm.
• We establish an Rlogin connection from slip to vangogh. We then type Fl, which generates 3 bytes: an escape(ESC), a left bracket([), and an M. We then type F2, which generates another 3 bytes. Figure 19.5 shows the tcpdump output.

• Figure 19.6 shows the time line for this exchange. At the bottom of this figure we show the 6 bytes going from the client to the server with their sequence numbers, and the 8 bytes of echo being returned.

• When the first byte of input is read by the rlogin client and written to TCP, it is sent as segment 1. Its echo is returned in segment 2, and only then are the next 2 bytes sent(segment 3). The echo of the second 2 bytes is received in segment 4 and acknowledged in segment 5.
• The echo of the first byte occupies 2 bytes(segment 2) because the ASCII escape character is echoed as 2 bytes(a caret and a left bracket). The next 2 bytes of input, a left bracket and an M, are echoed as themselves.
• The same exchange occurs when F2 is typed(segments 6-10). The time difference between segments 5 and 10(slip sending the acknowledgment of the echo) is a multiple of 200 ms, since both ACKs are delayed.
• We repeat this example with the Nagle algorithm turned off. Figure 19.7 shows the tcpdump output.

• Segments 1, 2 and 3 are sent when they’re ready since the Nagle algorithm has been disabled.
• Segment 4 contains byte 5 from the server with an ACK 4. The client immediately responds with an ACK 2(it is not delayed) since it wasn’t expecting byte 5 to arrive.
• A data segment was lost(a dashed line in Figure 19.8). The next byte expecting is 2, as announced by segment 5(Whenever TCP receives out-of-order data beyond the next expected sequence number, it responds with an acknowledgment specifying the sequence number of the next byte it expects to receive.)
• Since the missing segment contained bytes 2, 3, and 4, it means the server must have received segment 2, so the missing segment must have specified an ACK 3(the sequence number of the next byte the server is expecting to receive.)
• Segment 6 is the retransmission that contains data from the missing segment and segment 4. This is called re-packetization(Section 21.11).
• For F2: The 3 bytes is sent as three individual segments(8, 9, and 10). The server echoes the byte in segment 8 first(segment 11), and then echoes the bytes in segments 9 and 10(segment 12).

19.5 Window Size Advertisements

• Figure 19.4: slip advertises a window of 4096 bytes and vangogh advertises a window of 8192 bytes. Most segments contain one of these two values.
  Segment 5 advertises a window of 4095 bytes that means there is 1 byte in the TCP buffer for the application(Rlogin client) to read.
• The server advertises a window of 8192 bytes because the server’s TCP has nothing to send until the Rlogin server reads the received data and echoes it. The data from the server is sent after the Rlogin server has read its input from the client.
• The client TCP often has data to send when the ACK arrives, since it’s buffering the received characters just waiting for the ACK. When the client TCP sends the buffered data, the Rlogin client has not had a chance to read the data received from the server, so the client’s advertised window is less than 4096.

19.6 Summary

Exercise 19.1

Consider a TCP client application that writes a small application header(8 bytes) followed by a small request(12 bytes). It then waits for a reply from the server. What happens if the request is sent using two writes(8 bytes, then 12 bytes) versus a single write of 20 bytes?

• Two writes followed by a read cause a delay because the Nagle algorithm may be invoked.
  
  1. The first segment(8 bytes data) is sent and its ACK is waited for before sending the 12 bytes of data.
  2. If the server implements delayed ACKs, there can be a delay of up to 200 ms(plus the RTT) before this ACK is received.

Exercise 19.2

In Figure 19.4 we are running tcpdump on the router sun. This means the data in the arrows from the right to the left still have to go through bsdi, and the data in the arrows from the left to the right have already come through bsdi. When we see a segment going to slip, followed by a segment coming from slip, the time differences between the two are: 34.8, 26.7, 30.1, 28.1, 29.9, and 35.3 ms. Given that there are two links between sun and slip(an Ethernet and a 9600 bits/sec CSLIP link), do these time differences make sense?(Hint: Reread Section 2.10.)

• Omit.

Exercise 19.3

Compare the time required to send a special function key and have it acknowledged using the Nagle algorithm(Figure 19.6) and with the algorithm disabled(Figure 19.8).

• Figure 19.6: the time difference between segments 6 and 9 is 533 ms.
  Figure 19.8: the time difference between segments 8 and 12 is 272 ms.

Please indicate the source: http://blog.csdn.net/gaoxiangnumber1

Welcome to my github: https://github.com/gaoxiangnumber1