TCP 오프로드 엔진

TCP 오프로드 엔진(, TOE)는 일부 네트워크 인터페이스 컨트롤러(NIC)에서 전체 TCP/IP 스택의 처리를 네트워크 컨트롤러로 오프로드하는 데 사용되는 기술이다. 이는 주로 기가비트 이더넷이나 10기가비트 이더넷과 같이 네트워크 스택의 처리 오버헤드가 상당해지는 고속 네트워크 인터페이스에서 사용된다. TOE는 iSCSI 및 네트워크 파일 시스템(NFS)과 같은 인터넷 프로토콜(IP) 스토리지 프로토콜과 관련된 오버헤드를 줄이는 방법으로 자주 사용된다.

 목적 
본래 TCP는 초기 다이얼 업 모뎀과 같은 신뢰할 수 없는 저속 네트워크를 위해 설계되었으나, 인터넷 백본 전송 속도(광반송파, 기가비트 이더넷, 10기가비트 이더넷 링크 사용)의 성장과 더 빠르고 신뢰할 수 있는 접속 메커니즘(DSL, 케이블 모뎀 등)의 등장으로 인해, 오늘날 데이터 센터 및 데스크톱 개인용 컴퓨터 환경에서 1Gbps 이상의 속도로 자주 사용된다. 이러한 속도에서 호스트 시스템의 소프트웨어 TCP 구현은 상당한 컴퓨팅 성능을 요구한다. 2000년대 초반에 풀듀플렉스(전이중) 기가비트 TCP 통신은 2.4 GHz 펜티엄 4 프로세서 자원의 80% 이상을 소비할 수 있었으며, 그 결과 시스템에서 실행되는 애플리케이션에 할당할 처리 리소스가 거의 남지 않게 되었다.

TCP는 연결 지향 프로토콜로서 복잡성과 처리 오버헤드를 가중시킨다. 이러한 측면에는 다음과 같이 포함된다.
 "3방향 핸드셰이크"(SYN; SYN-ACK; ACK)를 사용한 연결 설정.
 상대방이 수신한 패킷에 대한 확인 응답(ACK)으로, 엔드포인트 간의 메시지 흐름과 프로토콜 부하를 증가시킨다.
 체크섬 및 시퀀스 번호 계산 - 일반 목적의 CPU가 수행하기에 부담이 된다.
 패킷 확인 응답 및 혼잡 제어를 위한 슬라이딩 윈도우 계산.
 연결 종료.

이러한 기능의 일부 또는 전부를 전용 하드웨어인 TCP 오프로드 엔진으로 옮기면 시스템의 메인 CPU가 다른 작업을 수행할 수 있도록 여유를 줄 수 있다.

 확보되는 CPU 사이클 
일반적으로 받아들여지는 경험칙에 따르면, 의 TCP/IP 데이터를 송수신하는 데 1Hz의 CPU 처리가 필요하다. 예를 들어,  ()의 네트워크 트래픽은 5 GHz의 CPU 처리를 필요로 한다. 이는 2.5 GHz 멀티 코어 프로세서의 코어 2개 전체가  TCP/IP 트래픽 처리에 매달려야 함을 의미한다. 이더넷(이 예에서는 10GE)은 양방향이므로 를 송수신하는 것이 가능하며(총 처리량 ),  규칙을 적용하면 이는 2.5 GHz 코어 8개와 맞먹는다.

TCP/IP 오프로드를 통해 TCP/IP 처리에 사용되던 많은 CPU 사이클이 확보되며, 이는 CPU(주로 서버 CPU)가 파일 시스템 처리(파일 서버에서)나 인덱싱(백업 미디어 서버에서)과 같은 다른 작업을 수행하는 데 사용될 수 있다. 즉, TCP/IP 오프로드 기능이 있는 서버는 오프로드 NIC가 없는 서버보다 더 많은 서버 업무를 수행할 수 있다.

 PCI 트래픽 감소 
TOE가 해결할 수 있는 프로토콜 오버헤드 외에도, 대다수의 호스트 기반(서버 및 PC) 엔드포인트에 영향을 미치는 구조적 문제를 해결할 수 있다.
많은 구형 엔드포인트 호스트는 PCI 버스 기반으로, 이는 서버 및 PC에 네트워크 인터페이스와 같은 특정 주변 기기를 추가하기 위한 표준 인터페이스를 제공한다.
PCI는 메인 메모리에서 PCI 버스를 거쳐 네트워크 인터페이스 IC로 작은 데이터 버스트를 전송하는 데 비효율적이지만, 데이터 버스트 크기가 커질수록 효율성이 향상된다. TCP 프로토콜 내에서는 다량의 작은 패킷(예: 확인 응답)이 생성되며, 이러한 패킷들이 일반적으로 호스트 CPU에서 생성되어 PCI 버스를 거쳐 네트워크 물리 인터페이스로 전송되기 때문에 호스트 컴퓨터의 I/O 처리량에 영향을 미친다.

네트워크 인터페이스에 위치한 TOE 솔루션은 CPU 호스트로부터 PCI 버스 반대편에 위치하므로 이러한 I/O 효율성 문제를 해결할 수 있다. TCP 연결을 통해 전송될 데이터가 CPU에서 TOE로 PCI 버스를 통해 큰 데이터 버스트 크기로 전송될 수 있으며, 작은 TCP 패킷들이 PCI 버스를 가로지를 필요가 없기 때문이다.

 역사 
이 기술의 초기 특허 중 하나인 UDP 오프로드에 관한 특허는 1990년 초 오스펙스 시스템즈(Auspex Systems)에 부여되었다United States Patent: 5355453 "Parallel I/O network file server architecture category". 오스펙스의 설립자인 래리 부셔(Larry Boucher)와 다수의 엔지니어들은 1997년 알라크리텍(Alacritech)을 설립하여 네트워크 스택 오프로드 개념을 TCP로 확장하고 이를 전용 실리콘으로 구현하고자 했다. 그들은 1999년 초에 최초의 병렬 스택 풀 오프로드 네트워크 카드를 선보였다. 이 회사의 SLIC(Session Layer Interface Card)는 현재 TOE 제품군의 전신이다. 알라크리텍은 TCP/IP 오프로드 분야에서 다수의 특허를 보유하고 있다United States Patent: 6247060 "Passing a Communication Block from Host to a Local Device such that a message is processed on the Device".

2002년경 iSCSI와 같은 TCP 기반 스토리지의 등장으로 관심이 고조되자, "닷컴 버블 말기에 설립된 최소 12개의 신생 기업들이 스토리지 프로토콜 및 애플리케이션용 범용 반도체 가속기 시장의 기회를 쫓고 있으며, 대여섯 개의 기존 벤더 및 사내 ASIC 설계팀과 경쟁하고 있다"고 언급되기도 했다"Newcomers spin storage network silicon ", Rick Merritt,
10/21/2002, EE Times.

2005년에 마이크로소프트는 알라크리텍의 특허 기반을 라이선스하고, 알라크리텍과 협력하여 'TCP 굴뚝 오프로드'(TCP chimney offload)로 알려진 부분 TCP 오프로드 아키텍처를 만들었다. TCP 굴뚝 오프로드는 알라크리텍의 "통신 블록 전달 특허"를 핵심으로 한다. 동시에 브로드컴 또한 TCP 굴뚝 오프로드 칩을 제작하기 위한 라이선스를 취득했다.

 유형 
TCP 스택을 완전히 TOE로 교체하는 대신, 운영 체제의 TCP 스택과 협력하여 일부 작업을 오프로드하는 대안적인 기술들이 있다. TCP 체크섬 오프로드 및 대량 세그먼트 오프로드는 오늘날 대부분의 이더넷 NIC에서 지원된다. 대량 수신 오프로드 및 TCP 확인 응답 오프로드와 같은 최신 기술은 이미 일부 하이엔드 이더넷 하드웨어에 구현되어 있지만, 순수하게 소프트웨어로 구현되더라도 효과적이다.

 병렬 스택 풀 오프로드 
병렬 스택 풀 오프로드(Parallel-stack full offload)라는 이름은 두 개의 병렬 TCP/IP 스택이라는 개념에서 유래했다. 첫 번째는 호스트 OS에 포함된 메인 호스트 스택이다. 두 번째 또는 "병렬 스택"은 "뱀파이어 탭"(vampire tap)을 사용하여 응용 계층과 전송 계층 (TCP) 사이에 연결된다. 뱀파이어 탭은 애플리케이션의 TCP 연결 요청을 가로채며, TCP 연결 관리 및 TCP 데이터 전송을 담당한다. 다음 섹션에 나오는 많은 비판은 이러한 유형의 TCP 오프로드와 관련이 있다.

 HBA 풀 오프로드 
HBA(호스트 버스 어댑터) 풀 오프로드는 iSCSI 호스트 어댑터에서 볼 수 있는데, 이는 호스트 시스템에는 디스크 컨트롤러로 인식되면서 (TCP/IP를 통해) iSCSI 스토리지 장치에 연결된다. 이러한 유형의 TCP 오프로드는 TCP/IP 처리뿐만 아니라 iSCSI 이니시에이터(initiator) 기능도 오프로드한다. HBA가 호스트에게 디스크 컨트롤러로 보이기 때문에, 이는 iSCSI 장치에만 사용될 수 있으며 일반적인 TCP/IP 오프로드에는 적합하지 않다.

 TCP 굴뚝 부분 오프로드 
TCP 굴뚝 오프로드(TCP chimney partial offload)는 병렬 스택 풀 오프로드의 주요 보안 비판을 해결한다. 부분 오프로드에서는 메인 시스템 스택이 호스트에 대한 모든 연결을 제어한다. 로컬 호스트(주로 서버)와 외부 호스트(주로 클라이언트) 사이에 연결이 설정된 후, 연결과 그 상태가 TCP 오프로드 엔진으로 전달된다. 데이터 송수신의 과중한 작업은 오프로드 장치에 의해 처리된다. 거의 모든 TCP 오프로드 엔진은 호스트 CPU의 개입 없이 데이터 전송을 수행하기 위해 일종의 TCP/IP 하드웨어 구현을 사용한다. 연결이 닫히면 연결 상태는 오프로드 엔진에서 메인 시스템 스택으로 반환된다. TCP 연결의 제어권을 유지함으로써 메인 시스템 스택은 연결 보안을 구현하고 제어할 수 있다.

 TCP 세그먼테이션 오프로드 
TCP 세그먼테이션 오프로드(TSO)는 TCP 세그먼트 작업을 네트워크 인터페이스 컨트롤러로 오프로드할 수 있다https://docs.kernel.org/networking/segmentation-offloads.html.

 대량 수신 오프로드 
대량 수신 오프로드(Large receive offload, LRO)는 중앙 처리 장치(CPU) 오버헤드를 줄임으로써 고대역폭 네트워크 연결의 인바운드 처리량을 늘리는 기술이다. 이는 단일 스트림에서 들어오는 여러 개의 패킷을 상위 네트워킹 스택으로 전달하기 전에 더 큰 버퍼로 합치는 방식으로 작동하며, 이를 통해 처리해야 하는 패킷 수를 줄인다. 리눅스 구현에서는 일반적으로 인터럽트 횟수를 줄이기 위해 New API(NAPI)와 결합하여 LRO를 사용한다.

벤치마크에 따르면, 이 기술을 순수하게 소프트웨어로만 구현하더라도 네트워크 성능을 크게 향상시킬 수 있다. 2007년 4월 기준, 리눅스 커널은 소프트웨어 방식으로만 TCP용 LRO를 지원한다. FreeBSD 8은 이를 지원하는 어댑터에서 하드웨어 방식의 LRO를 지원한다

LRO는 엔드 투 엔드 원칙을 깨뜨리고 성능에 심각한 영향을 줄 수 있으므로, 라우터 역할을 하는 장비에서는 작동해서는 안 된다

 일반 수신 오프로드 
일반 수신 오프로드(Generic receive offload, GRO)는 TCP/IPv4에 국한되지 않고 LRO에서 발생하는 문제점이 없는 일반화된 LRO를 소프트웨어로 구현한 것이다

 대량 송신 오프로드 
컴퓨터 망에서 대량 송신 오프로드(Large send offload, LSO)는 CPU 오버헤드를 줄임으로써 고대역폭 네트워크 연결의 이그레스(송신) 처리량을 늘리는 기술이다. 이는 다중 패킷 버퍼를 네트워크 인터페이스 컨트롤러(NIC)로 전달하여 작동한다. 그런 다음 NIC는 이 버퍼를 별개의 패킷으로 나눈다. 이 기술은 TCP에 적용될 때 TCP 세그먼테이션 오프로드(TCP segmentation offload, TSO) 또는 일반 세그먼테이션 오프로드(generic segmentation offload, GSO)라고도 불린다. LSO와 LRO는 서로 독립적이며, 하나를 사용한다고 해서 다른 하나를 반드시 사용해야 하는 것은 아니다.

시스템이 컴퓨터 네트워크를 통해 대량의 데이터를 보낼 때, 데이터 뭉치는 먼저 송신지와 수신지 컴퓨터 사이의 라우터 및 스위치와 같은 모든 네트워크 요소를 통과할 수 있는 더 작은 세그먼트로 나뉘어야 한다. 이 과정을 세그먼테이션이라고 한다. 종종 호스트 컴퓨터의 TCP 프로토콜이 이 세그먼테이션을 수행한다. 이 작업을 NIC로 오프로드하는 것을 TCP 세그먼테이션 오프로드(TSO)라고 한다.

예를 들어, 64 KiB (65,536 바이트) 크기의 데이터 단위는 일반적으로 NIC를 거쳐 네트워크로 전송되기 전에 각각 1460 바이트 크기의 세그먼트 45개로 나뉜다. 지능형 NIC를 사용하면 호스트 CPU는 한 번의 전송 요청으로 64 KiB 데이터를 NIC에 넘길 수 있고, NIC는 그 데이터를 1460 바이트의 작은 세그먼트로 나누고, 호스트의 TCP/IP 스택에서 제공한 템플릿에 따라 각 세그먼트에 TCP, IP 및 데이터 링크 계층 프로토콜 헤더를 추가한 뒤 결과 프레임을 네트워크로 전송한다. 이는 CPU가 수행하는 작업을 대폭 줄여준다. 2014년 현재 시중에 출시된 많은 새로운 NIC들은 TSO를 지원한다.

일부 네트워크 카드는 TSO를 매우 일반적인 방식으로 구현하여 다른 전송 계층 프로토콜의 단편화 오프로드에 사용하거나, UDP와 같이 자체적으로 단편화를 지원하지 않는 프로토콜에 대해 IP 단편화를 수행하는 데 사용할 수도 있다.

 UDP 단편화 오프로드 
UDP 단편화 오프로드(UFO)는 UDP 데이터그램 작업을 네트워크 인터페이스 컨트롤러로 오프로드할 수 있다https://docs.kernel.org/networking/segmentation-offloads.html.

 리눅스에서의 지원 
FreeBSD와 같은 다른 운영 체제와 달리, 리눅스 커널은 TOE에 대한 지원을 포함하지 않는다(다른 유형의 네트워크 오프로드와 혼동해서는 안 된다)"Linux and TCP offload engines",  August 22, 2005, LWN.net. 첼시오(Chelsio)나 큐로직(QLogic)과 같은 하드웨어 제조업체에서 TOE 지원을 추가하는 패치를 제공하기도 하지만, 리눅스 커널 개발자들은 다음과 같은 몇 가지 이유로 이 기술에 반대하고 있다..
 보안: TOE는 하드웨어로 구현되므로, 특정 TOE 구현에서 발견된 보안 취약점을 해결하려면 단순히 소프트웨어가 아니라 TOE 펌웨어에 패치를 적용해야 한다. 이는 TOE를 사용하지 않는 운영 체제의 잘 검증된 TCP/IP 스택과 비교할 때, 이 하드웨어의 생소함과 벤더별 고유성으로 인해 더욱 복잡해진다.
 하드웨어의 제한: 연결이 TOE 칩에서 버퍼링되고 처리되기 때문에, 운영 체제가 사용할 수 있는 넉넉한 CPU 및 메모리에 비해 리소스 고갈이 더 쉽게 발생할 수 있다.
 복잡성: TOE는 커널이 항상 모든 리소스에 접근할 수 있다는 가정을 깨뜨린다. 예를 들어 열린 연결에서 사용되는 메모리 상세 정보 등은 TOE 사용 시 확인할 수 없다. 또한 TOE를 제대로 지원하려면 네트워킹 스택을 대대적으로 수정해야 하며, 그렇게 하더라도 QoS나 패킷 필터링 같은 기능이 작동하지 않을 수 있다.
 독점성: TOE는 하드웨어 벤더마다 다르게 구현된다. 이는 앞서 언급한 복잡성과 보안 문제를 감수하고도 다양한 TOE 구현을 처리하기 위해 더 많은 코드를 다시 작성해야 함을 의미한다. 더욱이 TOE 펌웨어는 소스가 공개되지 않아 쉽게 수정할 수 없다.
 노후화: 시스템 하드웨어가 급격히 발전하여 TOE 성능 수준을 따라잡고 결국 추월하기 때문에 각 TOE NIC의 유용 수명은 제한적이다.

 공급업체 
현재 TOE 기술에 대한 대부분의 작업은 브로드컴, 첼시오 커뮤니케이션즈, 에뮬렉스, 멜라녹스 테크놀로지스, 큐로직과 같은 10기가비트 이더넷 인터페이스 카드 제조업체들에 의해 이루어지고 있다.

 같이 보기 
 확장 가능한 네트워킹 팩
 I/O 가속 기술 (I/OAT)
 에너지 효율 이더넷 (EEE)
 자율 주변 장치 작동 (Autonomous peripheral operation)

 각주 

 외부 링크 
 기사: TCP Offload to the Rescue - Andy Currid 저, ACM Queue 제공
 Patent Application 20040042487 


 Windows Network Task Offload
 GSO in Linux
 Brief Description of LSO in Linux
 Case Studies of Performance issues with LSO and Traffic Shaping (Linux)
 FreeBSD 7.0 new features, brief discussion on TSO support 

분류:네트워크 하드웨어
분류:전송 제어 프로토콜