19-TCP Interactive Data Flow
2016-10-09 17:44
260 查看
Please indicate the source: http://blog.csdn.net/gaoxiangnumber1
Welcome to my github: https://github.com/gaoxiangnumber1
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
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.
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.
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).
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.
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.
The first segment(8 bytes data) is sent and its ACK is waited for before sending the 12 bytes of data.
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
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.1Consider 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.
The first segment(8 bytes data) is sent and its ACK is waited for before sending the 12 bytes of data.
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
相关文章推荐
- TCP/IP 详解 卷1 ch19 TCP Interactive Data Flow
- tcp/ip学习笔记--第19章 TCP interactive data flow (交互数据流)
- TCP Flow Control and Data Transfer
- tcp/ip学习笔记--第20章 TCP Bulk data flow
- 20-TCP Bulk Data Flow
- TCP/IP 详解 卷1 ch20 TCP Bulk Data Flow
- Design issues - Sending small data segments over TCP with Winsock
- TensorFlow Data Input (Part 2): Extensions & Hacks
- Flow Control in TCP(tcp的流量控制实现)
- (电工基地笔记)Vivado 2014.2 validation fails[IP_Flow 19-3478]
- 【oracle教程】Designing ETL Data Flow Mappings【OWB 11g Release 1】
- A/V data用TCP来接收(rtp overrtsp),可以收到数据,但解析不对。
- Transition: D3 Introduction to interactive data visualization for the web
- Graphical Data Flow Modeling in SAP BW 7.3(避免传输丢失)
- Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program
- Net.TcpipHeapSize - 使用ESX NFS datastore的TCPIP堆栈内存参数推荐值
- 多进程解决datasnap支持的tcp长连接数量少的问题
- Mining Twitter Data with Python Part 7: Geolocation and Interactive Maps
- Design issues - Sending small data segments over TCP with Winsock
- 数据流程图(Data flow diagram)