프로토콜 스택과 LAN 어댑터의 동작

앞서 Socket 라이브러리에서의 Socket, Connect, Write, Read, Close 동작에 대해 살펴봤다. 이러한 동작들을 뒷단에서 프로토콜 스택과 LAN 어댑터가 처리해준다. 그림으로 보면 아래와 같다.

저번엔 Socket 라이브러리까지 살펴봤으니 프로토콜 스택 내부를 살펴보도록 하자. TCP와 UDP는 용도에 따라 다르게 사용된다. TCP는 브라우저나 메일 등의 일반적인 데이터 송수신을 담당하고, UDP는 DNS 서버에 대한 조회와 같은 짧은 제어용 데이터 송수신을 담당한다. (영상 전송에도 사용된다.)

아래에 있는 IP 담당은 패킷의 송수신을 제어하는 부분이다. 내부에 있는 ARP 프로토콜은 IP 주소에 대응하는 인터넷의 MAC 주소를 조사할 때, ICMP는 패킷 운반 시 발생하는 오류 통지 및 제어용 메시지 통지에 사용된다.

IP 담당 아래의 LAN 드라이버는 LAN 어댑터를 제어하기 위함이고, LAN 어댑터는 실제 송수신 동작을 실행한다.

 

Socket

socket이 호출되면 프로토콜 스택은 소켓을 만든다. 소켓을 만든다는 것은 소켓 한 개 분량의 메모리 영역을 할당하는 것이다. 프로토콜 스택은 소켓을 만든 뒤 소켓을 식별하는 디스크립터를 애플리케이션에 반환한다.

 

Connect

이후 애플리케이션은 Connect를 호출한다. 방금 받은 디스크립터와 목적지(서버)의 IP주소 및 포트번호를 인자로 담아 넘긴다. 그러면 프로토콜 스택의 TCP 담당 부분은 목적지의 TCP 부분과 통신해 제어 정보를 주고받는다. 이 부분이 바로 자주 들어왔던 3-way-handshake가 진행되는 시점이다. 해당 과정은 아래와 같다.

이 과정을 좀 더 자세히 살펴보도록 하자. 클라이언트에서 먼저 TCP 헤더를 만든다. TCP 헤더에는 수신처와 송신처의 포트번호가 포함되어 있다. 그리고 컨트롤 비트 중 SYN의 값을 1로 만든다. 이후 IP 담당 부분이 패킷을 서버로 보내주고 서버의 TCP 담당 부분이 TCP 헤더를 조사해 목적지 포트번호에 해당하는 소켓을 찾아 필요한 정보를 기록한다.

출처: http://www.ktword.co.kr/test/view/view.php?m_temp1=1889&id=1103

Write

접속이 완료되면 Write 동작이 진행된다. 이 과정은 보낼 데이터를 프로토콜 스택에 전달하고, 프로토콜 스택이 메시지를 전달하는 과정이다. 중요한 점은 프로토콜 스택은 받은 데이터를 바로 보내는 것이 아니라 송신용 버퍼 메모리 영역에 저장했다가 보낸다는 것이다.

왜냐하면 애플리케이션에 따라 데이터 송신 의뢰를 한번에 하는 경우도 있고, 1바이트씩, 1행씩 의뢰하는 경우가 있다. 작은 패킷을 여러번 보내는 비효율적인 과정을 방지하기 위해 버퍼에 모았다가 보내는 것이다.

이때 얼만큼 모은 뒤 보낼 것인지에 대해 결정하는 과정을 더 자세히 살펴보도록 하자. 이를 이해하기 위해서는 MTU와 MSS가 무엇인지 알아야 한다.

MTU : 한 패킷으로 운반할 수 있는 디지털 데이터의 최대 길이. 이더넷에서는 보통 1500바이트.
MSS : 한 패킷으로 운반할 수 있는 데이터의 최대 길이.

출처: https://www.cisco.com/c/ko_kr/support/docs/ip/transmission-control-protocol-tcp/200932-Ethernet-MTU-and-TCP-MSS-Adjustment-Conc.html

프로토콜 스택은 MTU를 매개변수로 받는다. 여기서 TCP, IP 헤더를 제외하여 MSS 길이를 알 수 있다. 그렇기에 MSS와 최대한 비슷한 길이까지 모았다가 보내면 패킷이 너무 잘게 쪼개질 걱정이 없다.

또 다른 기준은 타이밍이다. MSS만큼 모이지 않았더라도 일정 시간 전송이 안되면 패킷을 보낸다. 이 시간은 프로토콜 스택 내부의 타이머를 이용해 측정한다.

프로토콜 스택은 MSS와 타이밍을 고려하여 패킷을 적절히 보낸다.

MSS와 타이밍, 2가지 조건을 어떻게 조합할지는 프로토콜 스택을 만드는 개발자에게 달려있다. 그렇기에 OS의 버전이나 종류에 따라 달라질 수 있다.

참고로 어플리케이션에서 데이터 송신을 의뢰할 때 버퍼에 모으지 않고 바로 보내도록 설정할 수도 있다.

하지만 일반적인 상황에서 프로토콜 스택은 데이터를 송신 버퍼에 모은다. 이후 데이터 조각들을 꺼내 송,수신처 포트 번호를 기록한 TCP헤더를 추가한 뒤 IP 담당으로 넘겨준다.

그럼 IP담당은 아래와 같은 형태의 내용물을 받게 된다. IP 담당은 거기에 MAC헤더와 IP헤더를 덧붙인다.

이렇게 만든 패킷을 LAN 어댑터에 전달하는 것이 IP담당 부분의 역할이다. 이 패킷은 0 1 비트가 이어진 형태인데 LAN 어댑터에서 빛이나 전기 신호로 바뀌어 케이블로 송출된다.

IP 담당부분은 MAC헤더와 IP헤더를 추가하고, LAN 어댑터에 전달한다.

IP헤더에는 송, 수신처의 IP 주소를 비롯한 여러가지 값이 담긴다. 수신처의 IP주소는 앞서 Connect과정을 통해 TCP 담당이 IP 담당에 통지해줬었다. 송신처 IP 주소는 어떤 LAN 어댑터를 이용해 패킷을 보낼지 결정하는 과정이다. 왜냐하면 IP 주소는 LAN 어댑터마다 할당되기 때문이다. 그리고 이 LAN 어댑터는 패킷을 목적지까지 최소 비용으로 보내줄 수 있는 어댑터가 선정된다. 이때 사용되는 라우팅 테이블을 살펴보도록 하자.

먼저 목적지 IP값과 Network Destination 값을 비교하며 일치하는 행을 찾는다. 일치하는 값이 여러개면 Metric(비용)이 작은 값을 선택하게 되고, 일치하는 행이 없으면 기본 게이트웨이를 통해 패킷을 송신하게 된다.

MAC헤더에는 송, 수신처의 MAC주소가 담긴다. 송신처 MAC 주소는 앞서 사용하기로 결정한 LAN 어댑터의 MAC 주소를 설정한다. 수신자 MAC 주소는 ART(Address Resolution Protocol)프로토콜을 이용ㅎ 조사한다. ARP 프로토콜은 브로드캐스트 방식을 사용하는데, 같은 네트워크에 존재하는 대상들에 대해 IP주소가 일치하는 대상이 있는지 묻는 패킷을 전달한다. 해당 IP를 가진 대상은 자신의 MAC 주소로 응답하고, 나머지는 이 요청을 무시한다.

참고로 이 값들은 ARP 캐시 가용 메모리 영역에 저장되고, 통상적으로 이 값들은 몇 분 정도가 지나면 삭제된다. 즉 특정 IP를 가진 MAC 주소를 조회할 때는 ARP 캐시에 그 값이 있는지 찾고, 없으면 ARP의 조회동작을 실행한다.

 

READ

요청을 보내면 서버로부터 응답이 돌아올 것이다. LAN 어댑터가 이 응답을 제일 먼저 마주하게 되는데, 프레임앰플, 프레임 딜리미터, FCS 등의 값을 이용해 패킷에 오류가 있는지 검증한다. (이 과정은 추후 다루도록 하겠다.) 이후 MAC 헤더의 값을 보고 수신처의 MAC 주소와 자체의 MAC 주소를 비교하고, 자신에게 오는 패킷이면 버퍼 메모리에 이를 저장한다. 이후 인터럽트를 통해 패킷을 수신했음을 알린다.

LAN 드라이버는 프로토콜 스택에 패킷을 넘긴다. 그러면 IP 담당 부분은 IP 헤더를 조사해 포맷에 문제가 있는지 확인하고 수신처 IP 주소를 확인한다. 만약 수신처 IP 주소가 자신의 주소와 다르면 오류가 발생한 것이니 ICMP(Internet Control Message Protocol)를 이용해 상대방에 오류를 통지한다.

ICMP에는 Destination Unreachable(패킷을 목적지에 전달할 수 없음), Source Quench(라우터의 중계능력 초과), Time Exceeded(IP 헤더의 TTL값 초과)와 같은 다양한 상황에 대한 메시지들이 정의되어 있다.

만약 수신처 IP 주소가 자신과 같으면 패킷을 수신한다. 이때 IP 헤더의 플래그라는 항목을 보고 수신 패킷이 분할된 것이면 IP 담당 부분 내부 메모리에 임시저장한다. 그리고 IP 헤더에 있는 ID 정보에 같은 값이 들어가있는 패킷들을 모아 프레그먼트 오프셋에 따라 분할된 패킷을 원래대로 합친다. 이를 리어셈블링이라고 한다.

리어셈블링까지 끝나면 패킷은 TCP 담당 부분으로 넘어간다. TCP 부분에서는 IP 헤더에 기록된 수신처 IP, 송신처 IP 그리고 TCP 헤더에 있는 수신처 포트, 송신처 포트를 조사해 해당하는 소켓을 찾는다. 이후 데이터를 수신 버퍼에 넣어준다. 만약 데이터 전송용 패킷이 아니라 접속, 연결 끊기 같은 제어용 패킷이라면 제어 정보를 답장으로 보내거나 접속 및 연결끊기 동작을 애플리케이션에 통지한다.

 

Close

Socket라이브러리의 Close가 호출되면 우리가 일반적으로 아는 4-way-handshake가 발생한다.

클라이언트에서 연결 끊기에 들어간다고 가정하고 살펴보도록 하자. 먼저 클라이언트쪽에서 TCP 헤더를 만들고 컨트롤 비트 중 FIN의 값을 1로 설정하여 서버로 보낸다. 서버는 FIN을 1로 설정한 패킷을 받았다는 의미에서 ACK 패킷을 반송하고, 서버 쪽에서도 Close가 호출되어 FIN을 1로 설정한 패킷을 반송한다. 그러면 클라이언트에서도 이를 받아 ACK 패킷을 반환하고, 서버가 이를 받으면 서버는 Closed 상태가 된다. 클아이언트는 몇 분 정도 TIME_WAIT 상태로 대기하다가 Closed로 전환된다. 이후 소켓을 말소한다.