tcp 흐름 제어의 실례: 데이터를 보낼 수 없습니다!

아날로그 테스트 프로그램은 클라이언트에서 서버에 데이터를 보내고 서버가 데이터를 받는 것을 인공적으로 제어한다.클라이언트가 일부 데이터를 보낸 후에 다시 보낼 수 없습니다. 서버는 매번 1K를 받기 시작합니다.상리적으로 추정하면 서버가 1K를 받은 후에 클라이언트는 데이터를 계속 발송할 수 있어야 하지만 실측 관찰을 통해 클라이언트는 데이터를 발송할 수 없고 서버가 일정한 데이터량을 받은 후에야 클라이언트가 계속 발송할 수 있다.
tcp 패키지는 다음과 같습니다.

11:42:40.217984 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613366 1816613366>
0x0000: 4500 0034 5e08 4000 4006 deb9 7f00 0001 E..4^.@.@.......
0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.
0x0020: 8010 0000 3a7f 0000 0101 080a 6c47 51f6 ....:.......lGQ.
0x0030: 6c47 51f6 lGQ.
11:42:40.425034 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816613573 1816613366>
0x0000: 4500 0034 7f94 4000 4006 bd2d 7f00 0001 E..4..@[email protected]....
0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..
0x0020: 8010 0101 38b0 0000 0101 080a 6c47 52c5 ....8.......lGR.
0x0030: 6c47 51f6 lGQ.
11:42:40.425047 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613573 1816613366>
0x0000: 4500 0034 5e09 4000 4006 deb8 7f00 0001 E..4^.@.@.......
0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.
0x0020: 8010 0000 39b0 0000 0101 080a 6c47 52c5 ....9.......lGR.
0x0030: 6c47 51f6 lGQ.
11:42:40.838967 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816613987 1816613573>
0x0000: 4500 0034 7f95 4000 4006 bd2c 7f00 0001 E..4..@.@..,....
0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..
0x0020: 8010 0101 3643 0000 0101 080a 6c47 5463 ....6C......lGTc
0x0030: 6c47 52c5 lGR.
11:42:40.838983 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613987 1816613366>
0x0000: 4500 0034 5e0a 4000 4006 deb7 7f00 0001 E..4^.@.@.......
0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.
0x0020: 8010 0000 3812 0000 0101 080a 6c47 5463 ....8.......lGTc
0x0030: 6c47 51f6 lGQ.
11:42:41.666922 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816614815 1816613987>
0x0000: 4500 0034 7f96 4000 4006 bd2b 7f00 0001 E..4..@.@..+....
0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..
0x0020: 8010 0101 3169 0000 0101 080a 6c47 579f ....1i......lGW.
0x0030: 6c47 5463 lGTc
11:42:41.666939 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816614815 1816613366>
0x0000: 4500 0034 5e0b 4000 4006 deb6 7f00 0001 E..4^.@.@.......
0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.
0x0020: 8010 0000 34d6 0000 0101 080a 6c47 579f ....4.......lGW.
0x0030: 6c47 51f6 lGQ.
11:42:43.322908 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816616471 1816614815>
0x0000: 4500 0034 7f97 4000 4006 bd2a 7f00 0001 E..4..@.@..*....
0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..
0x0020: 8010 0101 27b5 0000 0101 080a 6c47 5e17 ....'.......lG^.
0x0030: 6c47 579f lGW.
11:42:43.322921 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816616471 1816613366>
0x0000: 4500 0034 5e0c 4000 4006 deb5 7f00 0001 E..4^.@.@.......
0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.
0x0020: 8010 0000 2e5e 0000 0101 080a 6c47 5e17 .....^......lG^.
0x0030: 6c47 51f6 lGQ.
11:42:46.634889 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816619783 1816616471>
0x0000: 4500 0034 7f98 4000 4006 bd29 7f00 0001 E..4..@.@..)....
0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..
0x0020: 8010 0101 144d 0000 0101 080a 6c47 6b07 .....M......lGk.
0x0030: 6c47 5e17 lG^.

서버에서 대량의ack65665win0의 가방을 되돌려 주는 것을 볼 수 있습니다.관련 자료를 조회한 결과 이 문제 현상은 tcp 흐름 제어와 관련이 있음을 발견했다. 관련 내용이 너무 많기 때문에 여기서 관건점만 정리한다. 1)ack65665win0의 win0은 서버가 클라이언트에게 알려준다. 나의 tcp 슬라이더가 가득 차서 공간이 없다. 클라이언트가 이런 패키지를 받은 후에 데이터 발송을 중단한다.2) 왜 서버가 일부 데이터를 받은 후 tcp 슬라이더가 가득 찬 상태가 아니며,ack65665win0으로 계속 되돌아갑니까?이것은 tcp의 프로토콜에 규정된 것입니다. 슬라이더가 가득 차면 다시 빨리 채워지지 않도록 슬라이더 공간이 버퍼 사이즈의 일반 또는 MSS 크기에 도달할 때만 클라이언트에게 계속 발송할 수 있음을 알려 줍니다. 즉, ack 패키지에서 win이 0이 아니라는 것입니다.자세한 내용은 다음과 같습니다.
To avoid SWS, we simply make the rule that the receiver may not update its advertised receive window in such a way that this leaves too little usable window space on the part of the sender. In other words, we restrict the receiver from moving the right edge of the window by too small an amount. The usual minimum that the edge may be moved is either the value of theMSS parameter, or one-half the buffer size, whichever is less.
Linux는 MSS와 같아야 합니다.
이 문제의 처리 과정에서 많은 tcp 프로토콜에 대한 지식이 언급되었다. 예를 들어 MSS, SWS(Slide window system), SWS(Silly window syndrome), tcp 캐시,ack 메커니즘 등이다. 관심 있는 학생들은 찾아볼 수 있다.전체 설명은 다음 링크를 참조하십시오.http://www.tcpipguide.com/free/t_TCPWindowManagementIssues.htm