Linux Slow Start : IP 경로 변경은 초기 창에 영향을 미치지 않습니다


10

아래 그림과 같이 내 컴퓨터의 tcp 초기 창을 10으로 변경했습니다.

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

tcp_slow_start_after_idle아래와 같이 변경 되었습니다

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

ip 라우트 쇼 확인은 아래와 같습니다.

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

이제 웹 사이트에서 tcpdump를 수행 할 때 WIN / MSS가 4남아있는 초기 창에서 변경 사항이 표시되지 않는 것 같습니다 . 5840 / 1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

웹 페이지에 대한 컬 히트는 약 30KB 의 데이터를 요청했습니다 .

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

내 접근 방식에서 무엇이 잘못 될 수 있습니까?

핵심

[user~]$ uname -r
3.0.4x86_64-linode21

업데이트로 google.com을 시도한 결과는 다음과 같습니다.

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

보시다시피 WIN / MSS는 14600 / 1460 = 10 입니다.

curl을 통해 서버 시스템 자체에서 내 사이트를 공격하려고 시도한 결과는 다음과 같습니다.

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

이 경우 WIN / MSS는 32792 / 16396 = 2 입니다.


만약 당신이 리눅스 머신에서 이것을 쳤다면, 당신은 3.0에 있어야하고, 소스 / 태그를 파헤쳐 서 변경을 설명한 정확한 3 버전을 확인합니다
Sam Saffron

@QuintinPar 테스트 시스템에서 나가는 연결로 tcpdump 출력을 추가 할 수 있습니까?
kupson

@ kupson 나는 질문을 업데이트했습니다
Quintin Par

내가 아는 한 들어오는 연결에서 초기 창에 영향을 줄 수 없습니다 . Google에 연결하면 IW가 10으로 설정되었음을 알 수 있습니다. 루프백 인터페이스는 큰 MTU에서 매우 특별합니다. 커널 소스의 초기 창에 약간의 캡이있을 수 있습니다.
kupson

명심하십시오, 2 가지가 IW를 결정할 것입니다. 클라이언트는 최대 초기 정체 창 및 서버 IW. 더 작은 승리. 두 대의 컴퓨터에서 테스트를 실행하면 서버에 기본적으로 IW가 3.0으로 설정되어 있어야하며 XP / Vista / Win7 클라이언트는 IW를 제한하지 않으므로 테스트에 적합한 클라이언트를 만듭니다. 3.0 Linux 클라이언트도 작동하지만 별도의 시스템이어야합니다.
Sam Saffron

답변:


9

TCP가 어떻게 작동하는지 오해하고 있다고 생각합니다.

전송 된 각 패킷은 항상 수신기 창 (일명 RWIN) 및 선택적인 스케일링 계수를 알립니다 ( RFC 1323 참조).

보낸 사람은 RWIN에 지정된 양 보다 많은 양의 데이터를 승인하지 않고 보낼 수 없습니다 . 정체 창에 따라 보낸 사람이 RWIN을 채우도록 결정할 수 있습니다.

따라서 TCP 패킷에 공개되는 두 가지 정보 비트가 있습니다. 서버의 RWIN 및 클라이언트의 RWIN 이 두 그림은 혼잡 창의 최대 크기가 양쪽 끝에있을 수있는 크기를 나타냅니다.

파일 업로드에 대한 성능을 최적화하려고 할 때 서버의 RWIN이 흥미 롭습니다.

다운로드 속도를 결정하려고 할 때 클라이언트의 RWIN이 흥미 롭습니다.

이 숫자들 중 어느 쪽도 다른 쪽 끝에 정체 창을 공개하지 않습니다 .

내가 64K의 RWIN이있는 경우 SO, 서버의 혼잡 윈도우가 될 수 있습니다 모든 번호가 64K보다.

실제 혼잡 윈도우를 결정하는 유일한 방법은 패킷을 계산하는 것입니다.

내가 아는 경우 :

  1. 내 왕복 시간 (RTT)은 ~ 200ms입니다.
  2. 방금 100k의 리소스를 요청했습니다.
  3. 64k의 RWIN이 있습니다.

~ 200ms 이내에 1452 바이트 길이의 서버에서 2 개의 패킷을 다시 가져 오면 서버의 정체 창이 4356보다 작을 수 있습니다. 더 큰 경우 3 개의 패킷이 전송됩니다. IW가 10으로 설정되면 200ms 마크 주위에 10 개의 패킷 버스트가 나타납니다.

IW를 변경하고 변경 사항이 적용되었는지 확인 하려면 서버의 정체 창 크기를 추정하기 위해 패킷계산해야 합니다.

SYN, SYN-ACK, ACK 직후의 대화를보고 혼잡 창이 이미 커져있는 대화의 중간을 보지 않도록해야합니다.


1
정체 창과 tcp 창의 차이점은 TCP / IP의 20.6 (느린 시작)에 설명되어 있습니다. "느린 시작 은 발신자의 TCP에 다른 창 을 추가합니다 . 20.7에는 대량 전송 중 재생시이를 보여주는 시퀀스 다이어그램이 있습니다.
Kyle Brandt

7

서버 크기는 서버 초기화 창 크기 또는 클라이언트 RWIN 중 더 작은 것입니다. 5840은 Linux 2.6의 기본 RWIN이므로 클라이언트가 제한 요인 인 것 같습니다.

창 상자에서 사용해보십시오. Windows XP의 RWIN은 64k, 최신 버전 8k입니다.

출처 : http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (흥미로운 부분은 비디오 아래에 있습니다)

편집 : 답변을 확장하여 명확하게 만듭니다.

  • TCP 핸드 셰이크에서 클라이언트는 최대 허용 창 크기를 전송하는 SYN 패킷을 서버로 보냅니다. (tcpdump 출력에서 ​​알 수 있듯이 이들은 5840 바이트입니다)
  • 서버는 이제 SYN ACK 및 동의하려는 창 크기로 응답합니다. 이 창 크기는 클라이언트가 제안한 것보다 작을 수 있으며 크지 않을 수 있습니다. 서버 구성 방법에 관계없이 해당 클라이언트의 서버 크기는 5840 바이트보다 클 수 없습니다.
  • 고객은 ACK를 반환하고 행복하게 데이터를 교환합니다.

Edit2 : 질문에 추가 된 tcpdumps는 서버가 Google에 연결하고 클라이언트 역할을 수행함을 보여줍니다.


초기 창 (SYN 패킷에서 제 안됨)은 5840입니다. 첫 번째 패킷이며 보내는 기계는 현재 수신자에 대해 아무것도 모릅니다 ( "ip route flush cache"로 테스트했습니다).
kupson

17.255.209.0은 서버 서브넷입니까? 보고있는 패킷은 FROM 21.101.151.198.45873 TO 17.255.209.19.http입니다. tcpdump 출력에 대한 전문가는 없지만 다음과 같이 읽습니다. Hello Server, 나는 당신의 클라이언트이며 5840 바이트 창을 좋아합니다. :) 다음 패킷은 ACK로 응답하는 서버이고, 5840은 훌륭합니다. :)
누군가

강조하기 위해, 당신이 이것을 잘못 생각했다고 생각합니다. 첫 번째 발신기는 서버가 아닌 연결을 여는 클라이언트입니다. 5840 바이트 창을 제공하는 클라이언트입니다. 서버는 더 큰 창 크기를 제안 할 수 없으며 더 작은 창 크기 만 제안합니다.
누군가

1
나는이 질문의 최초 저자가 아니다. 내 테스트 환경에서 비슷한 결과로 테스트했으며 변경할 수 없습니다. 초기 혼잡 창 크기 (initcwnd)는 다른 쪽 연결과 관련이 없습니다.
kupson

설정을 모르겠습니다. 원래 포스터는 서버에서 초기 창 크기를 늘리더라도 테스트 연결의 창 크기가 5840 바이트 인 이유를 물었습니다. 답은 : 그가 테스트 한 클라이언트는 더 큰 창 크기를 허용하지 않기 때문입니다. 다른 설정이나 일반적인 개념의 다른 문제 / 버그에 대해서는 언급 할 수 없습니다.
누군가
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.