제 24 장 그 밖의 TCP 기능과 성능

목 차 24.1 개 요 24.2 Path MTU 발견 24.3 Long Fat Pipes 24.1 개 요 24.2 Path MTU 발견 24.3 Long Fat Pipes 24.4 Window Scale Option 24.5 Time Stamp Option 24.6 PAWS(주위 순서 번호 보호) 24.7 T/TCP(트랜잭션용 new TCP 규격) 24.8 TCP 성능 24.9 요 약

TCP를 트랜잭션용으로 수정하기 위한 T/TCP new 규격 24.1 개 요(i) 고속회선에서 TCP의 한계 직면 고속회선에서 최대의 처리율을 얻기 위한 TCP 수정 방안 path MTU 발견 메커니즘 (기본 536바이트) 큰 대역폭-지연 산출을 갖는 long fat pipes의 한계 윈도우 스케일 옵션(윈도우 크기 655,535바이트 확장) 타임 스탬프(RTT측정을 보다 고속으로 실행) 주위 순서번호 보호 옵션( RFC 1323 1992 참조) TCP를 트랜잭션용으로 수정하기 위한 T/TCP new 규격 클라이언트와 서버 사이에서 교환되는 세그먼트 수 감소 3-방향 Hand-shake 4개의 세그먼트에 의한 연결 종료 불필요. Client는 서버의 응답을 “RTT + 요구처리시간” 내에 수신토록 함.

24.1 개 요(ii) 상기 옵션은 현재 존재하는 TCP와의 상호 호환성 유지가 중요함. <참조> (그림 2.5) 전형적인 MTU 구성 (TCP/IP헤더 40byte포함) 네트워크 MTU(바이트) 비 고 Hyperchannel 65,535 고속 회선 16M비트/초 토큰링(IBM) 17,914 // 4M비트/초 토큰링(IEEE 802.5) 4,464 // FDDI 4,352 // 이더넷 1,500 // IEEE 802.3/802.2 1,492 저속 회선 X.25 576 // 점-대-점 (저속 지연) 296 //(SLIP)

24.2 Path MTU 발견(i) Path MTU(maximum transmission unit) 정의 발견 메커니즘 두 호스트가 접속하고 있는 네트워크의 MTU가 아니라, 두 호스트 사이에서 패킷을 전송하는 데이터 링크상의 최소 MTU크기 발견 메커니즘 경로상의 라우터가 전송하는 IP 데이터그램의 단편화 파악(IP헤더내의 Don’t Fragment 비트를 설정함) MTU가 데이터그램 크기보다 작을 때, ICMP 프로토콜을 통한 도달 불가 에러 확인 (11.6절 참조) Traceroute를 이용한 path MTU 결정(11.7절 참조) UDP를 이용한 path MTU 발견 (11.8절 참조)

24.2 Path MTU 발견(ii) TCP의 초기 세그먼트 크기 설정 동작 연결 설정시 시작 세그먼트 크기 외부 인터페이스의 MTU 최소값 TCP가 상대방 종단으로부터 통지된 MSS를 초과하는 것을 허용하지 않음. (Default:536) 연결상의 모든 데이터그램 DF bit 설정 --> 중간 라우터 --> ICMP error(can’t fragment) --> TCP 세그먼트 사이즈 감소 후 재전송 다시 ICMP에러가 돌아오면 다음 최소 MTP가 시도됨 라우팅 경로의 동적 변화 --> path MTU 변경 RFC 1191 : 10분으로 권고 / 11.8절 Solaris 2.2 : 30초

24.2 Path MTU 발견(예제 토폴로지) slip에서 512의 MSS 선언으로 MTU를 552로 설정 SLIP링크의 MTU는256보다 큰 TCP세그먼트를 단편화 여기서 tcpdump를 시행 여기서 512바이트의 세그먼트를 단편화 MTU=1500 MTU=1500 MTU=1500 MTU=1500 SLIP SLIP slip bsdi sun netb solaris MTU=552 MTU=296 MTU=552 MTU=1500 TCP 연결 MSS=512 -> <- MSS=1460

24.2 Path MTU 발견 (tcpdump 출력) solaris % sock -i -n1 -w512 slip discard 1 0.0 solaris.33016 > slip.discard: S 1171660288:117166028(0) win 8760 <mss 1460 (DF) 2 0.101597(0.1016) slip.discard > solaris.33016: S 137984001:137984001(0) ack 1171660289 win 4096 <mss 512> 3 0.630609(0.5290) solaris.33016 > slip.discard: P 1:513(512) ack 1 win 9216 (DF) 4 0.634433(0.0038) bsdi> solaris: icmp: slip unreachable - need to frag, mtu = 296 (DF) 5 0.660331(0.0259) solaris.33016 > slip.discard: F 513:513(0) ack 1 win 9216 (DF) 6 0.752664(0.0923) slip.discard > solaris.33016: .ack 1 win 4096 7 1.110342(0.3577) solaris.33016 > slip.discard: P 1:257 (256) ack l win 9216 (DF) 8 1.439330(0.3290) slip.discard > solaris. 33016: .ack 1 win 9216 (DF) 9 1.770154(0.3308) solaris.33016 > slip.discard: FP 257:513(256) 10 2.095987(0.3258) slip.discard > solaris.33016: . Ack 514 win 3840 11 2.138193(0.0422) slip.discard > solaris.33016: F 1:1(0) ack 514 win 4096 12 2.310103(0.1719) solaris.33016 > slip.discard: . Ack 2 win 9216 (DF) 512바이트 세그먼트 송부 시작 SYN의 ACK 결합 ICMP에러 생성 에러보고 전에 FIN이 전송됨 SLIP는513번호를 기대하지 않음. 예상한 순서번호 1로 응답. 256바이트로 나누어 재전송 DF비트 설정으로 전송

처리능력 큰 패킷인가 작은 패킷인가? 일반정의: 작은 패킷을 많이 보내는 것 보다 큰 패킷을 적게 보내는 것이 비용이 적게들기 때문에 큰 패킷이 좋다고 말함. (단, 단편화하지 않을 정도) ==> 측정결과 계속적인 연구가 여러 형태의 네트워크에서 필요함 감소 요소 네트워크(패킷 헤더 오버헤드) 라우터(라우팅 결정) 호스트(프로토콜 처리와 장치 인터럽트) 기본 문제 라우터가 store-and-forward 장치임.

T1 이용한 큰 패킷 전송 결과(i) R1 R2 R3 R4 time 0 time 1 time 2 time 3 time 4 21.4ms 4096바이트 4096바이트 4096바이트 4096바이트 4096바이트 4096바이트 T1: 1,544,000bps, 4096바이트 X 2패킷 TCP/IP헤더 : 40byte (4096+40bytes) X 8bits/byte = 21.4ms/hop 1,544,000bits/sec 8192byte/85.6ms 소요(패킷의 수와 홉의 수를 더한 것에서 하나를 뺀 것) idle time : 42.8 ms(각 링크의 휴지 시간) 라우터에서의 처리시간은 고려하지 않음

T1 이용한 작은패킷 전송 결과(ii) R1 R2 R3 R4 T1:1,544,000bps, 512바이트 X 16패킷 time 0 time 1 ... Time 14 time 15 time 16 time 17 time 18 time 0 time 1 time 2 time 3 time 4 … time 17 time 18 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 512바이트 T1:1,544,000bps, 512바이트 X 16패킷 TCP/IP헤더 : 40byte (512+40bytes) X 8bits/byte = 2.9ms/hop 1,544,000bits/sec 8192byte/52.2ms 소요(패킷의 수와 홉의 수를 더한 것에서 하나를 뺀 것) idle time : 5.8 ms(각 링크의 휴지 시간) ACK가 돌아오는 시간, 연결설정/종료시간, 다른 트래픽과 링크를 공유하는 시간 무시

24.3 Long Fat Pipes(i) 정의 LFN(Long Fat Network)에서 동작하는 TCP 연결. 연결 용량--> 대역폭 지연 산출(bandwidth-delay product), 종단 포인트들 사이의 파이프 크기 용량(비트) = 대역폭(비트/초) X 왕복시간(초) Long Fat Network : 큰 대역폭 지연 한계 보유 네트워크 (그림 20.11 참조): 파이프를 수평방향으로(보다 큰 RTT) 확장 (그림 20.12 참조): 파이프를 수직방향으로(더 큰 대역폭) 확장 두 방향 모두 확장 가능

여러 네트워크에서 대역폭 지연 산출 고속에서 대역폭 지연 산출로 TCP의 한계 직면 네트워크 대역폭 왕복시간 대역폭 지연 산출 네트워크 대역폭 왕복시간 대역폭 지연 산출 (비트/초) (ms) (바이트) 이더넷 LAN 10,000,000 3 3,750 T1회선, 대륙횡단 1,544,000 60 11,580 T1회선, 위성 1,544,000 500 95,500 T3회선, 대륙횡단 45,000,000 60 337,500 기가비트, 대륙횡단 1,000,000,000 60 7,500,000 고속에서 대역폭 지연 산출로 TCP의 한계 직면

24.3 LFP의 문제점 분석 Q. TCP 윈도우 크기는 TCP 헤더의 16비트로 65,535바이트로 제한. A. 옵션으로 32비트 헤더사용이 가능 1,073,725,440바이트 (24.5절 참조) Q. LFN에서의 패킷 손실은 처리율 감소 ? A1. 타임스탬프 옵션으로 재전송 및 고속 복구 알고리즘 필요, 여러 번의 왕복시간 소요. A2. SACK(selective acknowledgement)는 윈도우내의 멀티드롭 패킷을 처리하기 위한 방법(RFC 1072/1323(제외) 참조) Q. LFN을 동작시키기 위해 보다 좋은 RTT 측정이 요구됨. A1. 옵션으로 모든 세그먼트의 RTT 측정 (24.5절 참조 ) Q1. TCP는 32비트의 순서번호가 연결 종료 후에 지연된 세그먼트로 다시 나타나는 것을 어떻게 방지하는가? 즉, 순서번호의 주기가 MSL보다 작게 될 정도로 네트워크의 전송속도가 빠른 것에서 발생(기가비트 네트워크)? A1. IP 헤더내의 TTL필드는 임의의 IP 데이터그램의 상한 값을 255초로 설정(18.6절 MSL(2분)권고, 구현 값은 30초 참조), TCP의 순서번호 공간이 유한 4,294,967,296바이트 전송 후 재사용. A2. TCP 타임스탬프 옵션을 사용하는 PAWS(순서번호의 반복 방지) 알고리즘 (24.5절 참조 )

(그림 24.6) 30ms 대기시간을 갖는 네트워크로 1M바이트 파일 전송) 24.3 LFP의 기가비트 네트워크 남아있는 994,210 바이트 파일 전송 파이프에 있는 5,790바이트 1,544,000비트/초 대기시간 30ms 8ms 1기가비트/초 1,000,000 바이트 (그림 24.6) 30ms 대기시간을 갖는 네트워크로 1M바이트 파일 전송) T1: 1,000,000/5790*0.03+0.03(Latency) = 5.211sec T3:T1의 29배 BW --> 총 시간은 T1의 25배 1Gigabit : 8,000,000/1,000,000,000+0.03(Latency) = 0.038sec 2Gigabit : 2배 BW --> 총 시간의 10% 감소 기가비트 네트워크에서는 BW가 아니라 Latency에 의해 제한을 받는다. 대기시간은 빛의 속도에서도 발생하기 때문에 감소되지 않는다.

24.4 윈도우 스케일 옵션(i) (그림17.2) TCP 헤더 (그림18.20) TCP 옵션 15 16 31 31 옵션의 끝 16 발신지 포트번호 16 목적지 포트번호 Kind=0 32 순서 번호 1byte 동작 없음 Kind=1 32 확인 응답 번호 20바이트 1 16 윈도우 크기 4 헤더 길이 6 예약됨 최대 세그먼트 크기 Kind=2 len=4 MSS 16 긴급 포인트 16 TCP 검사합 1 1 2 옵션 (만약 있다면) ... 윈도우 스케일 크기 쉬프트 카운트 Kind=3 Len=3 1 1 1 데이터 (만약 있다면) ... 타임 스탬프 Kind=8 Len=10 타임스탬프 값 타임스탬프 에코 1 1 4 4byte (그림17.2) TCP 헤더 (그림18.20) TCP 옵션

24.4 윈도우 스케일 옵션(ii) 예) TCP가 Window scale 계산 TCP 윈도우 크기는 TCP 헤더의 16비트 65,535바이트로 제한 --> 32비트 확장 (그림 18.20) 1바이트 쉬프트 카운트는(0-14) 최대값 1,073,725,440바이트(65535 X 214) 이러한 옵션은 SYN에서 나타남. --> 연결 설정 시 고려 능동적 Open을 하는 종단은 SYN에 선택사양을 보내지만 수동적 종단은 수신된 SYN이 선택사양을 지정할 경우만 선택사양을 보냄.(스케일 값은 양방향이 서로 다름) 수신버퍼 크기를 기반으로 시프트 카운트는 TCP에 의해 자동적으로 선택(20.4절 참조) 예) TCP가 Window scale 계산 vangogh % sock –V –R128000 bsdi.tuc.noao.edu echo SO_RCVBUF = 128000 수신버퍼를 128000byte로 한다. Connected on 128.32.130.2.4107 to 140.252.13.35.7 TCP_MAXSEG = 512 Hello, world ^D vangogh % sock –V –R220000 bsdi.tuc.noao.edu echo SO_RCVBUF = 220000 수신버퍼를 220000byte로 한다. Connected on 128.32.130.2.4108 to 140.252.13.35.7 bye, bye

24.4 윈도우 스케일 옵션(tcpdump 예) 1. 0.0 vangogh.4107 > bsdi.echo: S 462402561:462402561(0) win 65535 <mss 512,nop,wscale 1,nop,nop,timestamp 995351 0> 2. 0.003078 ( 0.0031) bsdi.echo > vangogh.4107: S 177032705:177032705(0) ack 462402562 win 4096 <mss 512> 3. 0.300255 ( 0.2972) vangogh.4107 > bsdi.echo: . ack 1 win 65535 4. 16.920087 (16.6198) vangogh.4107 > bsdi.echo: p 1:14(13) ack 1 win 65535 5. 16.923063 ( 0.0030) bsdi.echo > vangogh.4107: p 1:14(13) ack 14 win 4096 6. 17.220114 ( 0.2971) vangogh.4107 > bsdi.echo: . ack 14 win 65535 7. 26.640335 ( 9.4202) vangogh.4107 > bsdi.echo: F 14:14(0) ack 14 win 65535 8. 26.642688 ( 0.0024) bsdi.echo > vangogh.4107: . ack 15 win 4096 9. 26.643964 ( 0.0013) bsdi.echo > vangogh.4107: F 14:14(0) ack 15 win 4096 10. 26.880274 ( 0.2363) vangogh.4107 > bsdi.echo: . ack 15 win 65535 11. 44.400239 (17.5200) vangogh.4108 > bsdi.echo: S 468226561:468226561(0) win 65535 <mss 512,nop,wscale 2,nop,nop,timestamp 995440 0> 12. 44.403358 ( 0.0031) bsdi.echo > vangogh.4108: S 468226561:468226561 (0) ack 468226562 win 4096 <mss 512> 13. 44.700027 ( 0.2967) vangogh.4108 > bsdi.echo: . ack 1 win 65535 윈도우 광고 시프트 카운 1 옵션 지정 수신버퍼크기 128,000미만 윈도우 광고 시프트 카운 2 옵션 지정 수신버퍼 220,000보다 큰 262140(65535 X 22)윈도우 통지 주) MSS옵션은 512로 설정, 다음 NOP, 윈두우 크기,옵션을 4바이트 경계로 채우기 위한 것, 바이트 타임스탬프 옵션전에 2개의 NOP위치 12바이트가 되어 두개의 4바이트 타임 스탬프가 4바이트 경계에 위치.

24.5 타임 스탬프 옵션(i) 송신자가 각 세그먼트에 타임스탬프 값을 유지토록 한다. 수신자는 송신자가 수신된 ACK에 대한 RTT를 계산하도록 하면서 확인응답에 이 값을 반영. 현재 구현은 윈도우마다 RTT측정(1/8개 세그먼트 OK) 100개 세그먼트/윈도우 -->부정확한 RTT유발 보다 나은 RTT계산법 요구…허용 수신측이 이전 세그먼트를 수신하고, 이를 기존의 데이터 세그먼트의 일부로 판단하는 것을 피하도록 제공.

24.5 타임 스탬프 옵션(ii) 수신측은 송신측(32비트 값)이 보낸 timestamp를 응답 필드 값으로 에코.(20~30바이트 증가, 두 호스트간 Clock 동기 불필요) RFC 1323 : timestamp --> 1ms와 1초 사이 예) 500ms 18쪽의 세그먼트 1과 11에서 timestamp 차이(44.4초) 상세 내용은 RFC 1323(3.1절) 참조

24.6 PAWS(주위 순서번호 보호) Protection Against Wrapped Sequence numbers : 하나의 연결 내에서 동작하기 위해 정의된다. 각 TCP는 각 host로부터의 어떤 연결이든지 마지막 timestamp(ts)를 기억해야 한다 시간 송신된 송신순서 송신 바이트 번호 # 타임스탬프 수 신 A 0G:1G 0G:1G 1 OK B 1G:2G 1G:2G 2 OK이지만, 1세그먼트의 손실과 재전송 C 2G:3G 2G:3G 3 OK D 3G:4G 3G:4G 4 OK E 4G:5G 0G:1G 5 OK F 5G:6G 1G:2G 6 OK이지만, 재전송된 세그먼트가 다시 나타남. (그림 24.8) 6개의 1G바이트 윈도우에서 6G 바이트 전송 32비트 순서번호가 D와 E시간에 겹침, B시간에 한개의 세그먼트의 손실과 재전송 가정. F시에 다시 나타남. 세그먼트가 분식되고 다시 나타나는 사이의 시차는 MSL보다 적다고 가정.(TTL에의해 폐기) 이 문제는 고속 연결에서 순서번호가 겹치는 경우를 가정한 것임. 수신자는 F에서 다시 나타나는 세그먼트의 ts가 2이면, 최근의 유효한 5/6 ts보다 적으므로 PAWS 알고리즘을 적용하여 폐기한다. 그림 24.8에서 타임스탬프 사용으로 문제 예방을 확인함.

24.7 T/TCP(트랜잭션용 TCP확장) <현재 상태> TCP는가상 회선 서비스 제공 (Rlogin, FTP서비스) 설정, 데이터 전송, 종료의 3단계 트랜잭션 서비스(TCP/다수, UDP/보통 제공됨.) 보통의 구현은 UDP 응용 : TCP오버헤드, 동적인 타임 아웃과 재전송, 혼잡 회피 등은 연구 구현. <해결책 > 트랜잭션을 효과적으로 처리하는 트랜스포트 계층을 제공하는 것. 3-방향 핸드쉐이크를 피하는 것 --> 가속화된 개방(accelerated open) TIME-WAIT 상태를 단축

24.7 T/TCP의 장점 T/TCP의 특징 VMTP(Versatile Message Transaction Protocol) 기존의 프로토콜에 대해 최소한의 변화 기존의 구현에 대해 역행적으로 호환성을 허락 VMTP(Versatile Message Transaction Protocol) IP를 사용한 완벽한 트랜스포트 계층 VTMP는 에러 탐지, 재전송, duplicate압축을 제공, 또한 멀티캐스트 통신을 지원함.

24.8 TCP의 성능(i) 10Mbps 이더넷에서 TCP의 이론적 최대 Throughput 필 드 데이터 ACK 바이트 수 바이트 수 이더넷 preamble 8 8 이더넷 목적지 주소 6 6 이더넷 발신지 주소 6 6 이더넷 유형 필드 2 2 IP 헤더 20 20 TCP헤더 20 20 사용자 데이터 1460 0 패드(이더넷 최소 길이까지) 0 6 이더넷 CRC 4 4 패킷간의 간격(9.6microsec) 12 12 합 계 1538 84

24.8 TCP의 성능(ii) 가장 느린 링크의 속도보다 더 빠르게 수행하지 마라. 가장 느린 호스트의 메모리 대역폭보다 더 빠르게 수행하지 마라 수신측에 의해 제공되고 왕복시간으로 나뉘어진 윈도우 크기보다 더 빨리 수행하지 마라. 프로토콜 성능 문제는 본래의 프로토콜 한계보다 구현 부족이다.

24.9 요 약 5가지 TCP의 새로운 특징 트랜잭션을 위한 T/TCP, 3개의 세그먼트 사용 완료 path MTU 발견:세그먼트와 MTU, 단편화의 활용 윈도우 스케일 옵션 : 16비트에서 32비트 확장(1G바이트) 타임스탬프 : RTT 측정으로 더 많은 세그먼트의 조합 지원 PAWS: MSL의 지원은 고속 연결시 필수 --> 고속 광통신 활용. 트랜잭션을 위한 T/TCP, 3개의 세그먼트 사용 완료 TCP의 고속처리에 대한 부정확한 논의에서, 새로운 기능을 이용한 TCP의 성능 한계는 최대 1Giga 바이트 윈도우와 광속도로 파악.(Partridge & Pink1993)

TCP/IP 프로토콜 그룹의 각 계층에 위치한 여러 가지 프로토콜 사용자 프로세스 응용 TCP 세그먼트 = TCP헤더 + TCP데이터 (MSS 광고) TCP UDP 트랜스포트 IP 데이터 그램 = IP헤더 + TCP 세그먼트 (단편화) ICMP IP IGMP 네트워크 패킷 # IP 데이터 그램 ARP 하드웨어 인터페이스 RARP 링크 (MTU: Maximum Transmission Unit) 전송매체