패킷사이즈가 MTU 1500 바이트를 넘는 경우는 ?

저번 포스팅에서 MTU 에 대해서 설명을 드렸습니다. 그런데 가끔 패킷 덤프를 하다보면 MTU 이상의 패킷 사이즈를 보는 경우가 있습니다. 이건 무엇이지 하고 의아해할 수 있는 것이죠. 이를 설명드리기 위해 패킷 전송과 관련한 이야기를 조금 더 해볼께요.

10G 네트워크 링크를 사용하는 경우 1500 바이트 MTU 로 계산하면 대략 초당 800,000 가까이 됩니다. 이것은 결국 패킷처리를 위해 CPU 오버헤드를 가져올 수 있게 됩니다. 이런 오버헤드를 줄이기 위해 MTU 를 늘리면 될것 같습니다. 자 점보프레임인 9000 바이트로 늘리면 한번에 더 큰 패킷을 처리할 수 있습니다. 그런데 문제는 인터넷에 연결되어 있는 모든 구간이 이 MTU 값을 사용하지 않는다는데 있습니다. 보통의 경우는 1500 바이트 이내일 것이죠. 내부 네트워크라면 모르지만 인터넷 구간에서는 현실적으로 사용이 힘들어집니다.

그래서 네트워크 어뎁터에서 채용하기 시작한 것이 TCP 세그먼테이션 오프로드 기능입니다. TSO 로도 불리기도 하죠. TSO 호환 가능 어뎁터는 커널상에서 아웃바운드 데이터에 대해 보다 큰 패킷데이터를 처리할 수 있습니다. 즉, 밖으로 패킷을 보낼때 데이터를 재-세그먼트 하여 작게 보내게 된다는 것이죠. 이것은 호스트 컴퓨터의 CPU 자원 사용면에서도 효율적이게 됩니다. TSO 외 GSO(Generic segmentation offload)도 있습니다. GSO 는 TCP 에만 한정을 두지 않는다는 장점이 있지만 데이터 전송에서만 동작하고 받는쪽에서는 동작하지 않습니다. 이 부분에 대한 솔루션 형태의 하나로 LRO(Large Receive Offload) 가 있습니다. 들어오는 패킷에 대해 한번에 Merge 를 하게 되는 것입니다. 리눅스 기반의 10G 드라이버들이 이 LRO 를 넓게 채용하고 있기도 합니다.

이전 포스팅에서도 이 오프로드에 대해서 언급한 적이 있는데 좀더 궁금하신 분들은 다음 글을 참고하시기 바랍니다.

TOE(TCP offload engine)란 무엇인가?

자, 오프로드를 언급했는데 바로 오늘 제가 여러분들에게 설명드릴 MTU 이상의 크기가 이것과 연관되어 있습니다. 다음과 같이 ethtool 을 통해 네트워크 인터페이스의 정보를 확인해 보겠습니다.


# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

generic-receive-offload 가 on 되어 있는 것이 보입니다. 오프로드 기능이 동작하여 패킷을 덤프할 시에 패킷의 사이즈가 다르게 보였던 것입니다. 아래 그림을 한번 보시죠.

GRO 기능이 On 되어 있는 경우는 그림과 같이 패킷 사이즈가 2762, 4017, 3538 과 같이 MTU 값 이상으로 크게 나타납니다.

[그림] GRO 기능 On

그러나 gro 기능을 off 하고 패킷 캡쳐를 다시 해보면 패킷 데이터 전송크기가  1414로 동일하게 나타납니다.


# ethtool -K eth0 gro off
# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

[그림] GRO 기능 off

네트워크 어뎁터에서 처리해 주었기 때문에, 패킷 캡쳐 프로그램에서는 크기가 큰 패킷 사이즈를 볼 수 있었던 것입니다.

MTU 보다 패킷 크기가 크게 나왔던 이유가 바로 오프로드 기능이 있었던 것이었죠.
좀더 많은 내용은 다음 '참고'를 확인해 보세요.

[참고]

1. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html
2. Ethtool 을 통해 네트워크 카드(NIC) 정보 확인 또는 설정하기
http://www.packetinside.com/2012/04/ethtool-nic.html
3. 윈도우에서 네트워크 드라이버 설정 정보 보기 (TOE, 점보프레임등 확인)
http://www.packetinside.com/2012/05/toe.html
4. 패킷 전송 크기를 지정하는 MTU(Maximum Transmission Unit)를 알아봅시다!
http://www.packetinside.com/2013/02/mtumaximum-transmission-unit.html

이더넷상의 프로토콜 오버헤드는 얼마나 될까?

네트워크 상에서의 프로토콜 오버헤드에 대한 글이 있어서 소개해 본다. 우리가 사용하고 있는 이더넷과 프로토콜 스택상에서 얼마나 빨리 전송할 수 있을지, 얼마나 많은 대역폭을 사용하는지 가늠해 볼 수 있다. 다음은 프로토콜 오버헤드를 이더넷, 기가비트 이더넷, ATM, POS 등으로 나누어 소개한 자료이다.

주소 : http://sd.wareonearth.com/~phil/net/overhead/

예를 들어 이더넷의 프레임 포맷을 살펴보면,

• 6 바이트 목적지 주소
• 6 바이트 출발지 주소
• 필요시 이용되는 4바이트의 802.1q VLAN 태그 (옵션)
• 2 바이트 길이/타입
• 46-1500 바이트 데이터 (페이로드)
• 4 바이트 CRC

로 구성되어 있다. 이더넷의 오버헤드 요소를 살펴보면 ,

  12 gap + 8 preamble + 14 header + 4 trailer = 38 bytes/packet w/o 802.1q
  12 gap + 8 preamble + 18 header + 4 trailer = 42 bytes/packet with 802.1q

로 된다. VLAN 태그가 없이도 38 바이트 사용하는 경우 42 바이트가 된다. 이더넷 페이로드를 포함한 데이터 비율은 다음과 같이 된다:

  1500/(38+1500) = 97.5293 %   w/o 802.1q tags
  1500/(42+1500) = 97.2763 %   with 802.1q tags

1) 이더넷상의 TCP 전송

 헤더 압축은 없다고 가정
 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 TCP 헤더 20 바이트 추가
 TCP 타임스탬프 옵션 값 12 바이트 추가
 이더넷을 통한 최대 TCP 페이로드 데이터 전송률은 다음과 같다:

  (1500-40)/(38+1500) = 94.9285 %  IPv4, minimal headers
  (1500-52)/(38+1500) = 94.1482 %  IPv4, TCP timestamps
  (1500-52)/(42+1500) = 93.9040 %  802.1q, IPv4, TCP timestamps
  (1500-60)/(38+1500) = 93.6281 %  IPv6, minimal headers
  (1500-72)/(38+1500) = 92.8479 %  IPv6, TCP timestamps
  (1500-72)/(42+1500) = 92.6070 %  802.1q, IPv6, ICP timestamps

2) 이더넷상의 UDP 전송

 IPv4 헤더에 20 바이트 또는 IPv6 헤더에 40 바이트 추가
 UDP 헤더 8바이트 추가
 이더넷을 통한 최대 UDP 페이로드 데이터 전송률은 다음과 같다:

  (1500-28)/(38+1500) = 95.7087 %  IPv4
  (1500-28)/(42+1500) = 95.4604 %  802.1q, IPv4
  (1500-48)/(38+1500) = 94.4083 %  IPv6
  (1500-48)/(42+1500) = 94.1634 %  802.1q, IPv6

이렇게 소개하고 있다. 이외 기가비트 이더넷은 점보 프레임을 사용하는 경우 최대 전송은 990.042 Mbps 이며, 점보 프레임 없이는 941.482 Mpbs 이다. 이론적으로만 보면 점보 프레임을 사용하는 경우가 전송률 면에서 더 유리하다. 점보프레임은 얼마전 블로그에서 소개한 적이 있으니 참고해 보길 바란다.

프로토콜 오버헤드를 참고 삼아 알아두면 좋을것 같다.

[참고]
1. Protocol Overhead
http://sd.wareonearth.com/~phil/net/overhead/
2. 점보프레임(Jumbo Frame)으로 전송속도 높이기
http://www.packetinside.com/2012/03/jumbo-frame.html

점보프레임(Jumbo Frame)으로 전송속도 높이기

점보프레임(Jumbo Frame)을 소개해 볼까 한다. 기본적으로 우리가 지금 사용하는 MTU(Maximum Transmission Unit) 값은 1500 바이트이다. 실제 전송시에는 여기에 프레임 헤더를 붙이면 18 바이트가 추가되어 기본적으로는 1518 바이트가 된다. 점보프레임은 이름에서 느껴지는 것과 같이 프레임 크기를 크게 늘려주는 것이다. 점보프레임은 9000 바이트까지 MTU 를 확장시켜 준다. 처음 이더넷 프레임으로 1500 바이트가 사용된 것은 과거 낮은 통신속도와 비교적 높게 발생되었던 에러 비율 때문에 그런것이다. 즉, 데이터를 전송하다가 에러가 발생되면 단지 1500 바이트 부분만 에러를 정정하여 재 전송하면 되는 것이었다.

하지만 각 프레임은 네트워크 하드웨어와 소프트웨어적으로 프로세싱하는 것이 필요하다. 만약 프레임 사이즈가 커진다면 시스템에서 전송하기 위해 사용되는 처리 CPU 가 더 줄어든다. 그러므로 9000 바이트 이상으로 커진다면 데이터를 자르는 기준이 적어지므로 더욱 빠른 속도로 전달될 수 있는 것이다. 한번에 1500 바이트가 아닌 9000 바이트를 전송하기 때문이다.

그렇지만, 요새 하드웨어 성능은 워낙 좋아졌기 때문에 점보프레임으로 인한 성능 향상은 그리 크지는 않을 수 있다. 점보프레임이 2000년대 초 소개되었을 당시는 어느 정도 효과를 볼 수 있었을지 몰라도 빠르게 발전하는 하드웨어 속도에 비하면 프레임을 나누기 위한 CPU 사용은 적기 때문이다. 그래도 모든 사람이 좋은 하드웨어를 사용하는 것은 아니기 때문에 어느정도 효과는 있을 수 있다. 경험상 10-20% 정도의 향상을 얘기하는 경우가 많다.

점보프레임을 사용하기 위해서는 스위치, NIC 카드등에서 지원해야 하며, 요즘 사용되는 장비들은 대부분 지원한다. 다음 그림은 점보프레임이 설정된 패킷을 덤프한 것으로 데이터 크기가 8920 바이트나 되는 것을 확인할 수 있다.

시스템상에서의 설정은 MTU 값을 변경해 주는 것으로 간단하다. 다음과 같이 확인해 볼 수 있는데, 다음과 같이 설정전에는 MTU 가 1500 인 것을 볼 수 있다. (리눅스의 경우 커널 2.6.17 이상이면 지원된다)

# ip route get 111.6.0.25
111.6.0.25 dev bond1  src 111.6.0.30
    cache  mtu 1500 advmss 1460 hoplimit 64

ifconfig 로도 확인해 볼 수 있다.

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:78501442 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29641408 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:34935770805 (32.5 GiB)  TX bytes:25180384472 (23.4 GiB)
          Interrupt:48 Memory:d6000000-d6012800

해당 인터페이스의 MTU 를 다음과 같이 설정해 준다.

# ifconfig eth6 mtu 9000
# ifconfig eth6

eth6      Link encap:Ethernet  HWaddr [삭제]
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:2892 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2728 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:256450 (250.4 KiB)  TX bytes:2785780 (2.6 MiB)
          Interrupt:32 Memory:d8000000-d8012800

다시 ip 명령어로 확인해 보면 9000 바이트임을 확인할 수 있다.

# ip route get 111.6.0.25
111.6.0.25 dev bond1  src 111.6.0.30
    cache  mtu 9000 advmss 8960 hoplimit 64

tcpdump 로 트래픽을 캡쳐할 때도 캡쳐 크기를 늘려줘야 되므로 -s 로 9000 바이트를 지정해 주어야 한다.

# tcpdump -i bond1 -s 9000 -n -w jumbo.pcap
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 9000 bytes

다음은 tshark 로 프레임 크기를 살펴본 것으로, 1500 바이트 이상의 크기가 많이 보이는 것을 확인 할 수 있다.

# tshark -i bond1 -e frame.len -Tfields
9014
9014
66
9014
9014
66
9014
430
66
114
4210
66
114
9014
7550
66
114
114
66
4210
9014
66
9014
9014
66
6038
114
9014
^C1947 packets captured

자동으로 설정하기 위해서는  /etc/network/interfaces 에서 MTU=9000 으로 지정해 주면 된다. 그리고 재시작 해 주면 된다.

# /etc/init.d/networking restart

위 경우는 우분투, 데비안의 경우고 CentOS, 레드햇 계열은

# vi /etc/sysconfig/network-script/ifcfg-eth0

를 수정해 주면 된다.

참고로 호환성에 문제가 있을 수 있으므로 상황에 따라 판단하여 사용해야 한다.

[참고]
1. 위키피디아 점보프레임
http://en.wikipedia.org/wiki/Jumbo_frame