[Network] TCP/IP 데이터 송신, 수신

 

2022.06.20 - [공부 기록] - [Network] 소켓 통신 방법과 순서

[Network] 소켓 통신 방법과 순서

 

IP는 패킷을 던져

패킷은 수신처를 나타내는 주소 등의 제어 정보가 들어 있는 헤더와 데이터의 두 부분으로 구성됩니다.
TCP/IP의 헤더는 MAC 헤더와 IP헤더, 그리고 패킷 (TCP 헤더, 데이터 세그먼드)으로 이루어져 있습니다.
MAC 헤더는 이더넷의 제어 정보이고 IP 헤더는 IP의 제어 정보입니다.

 

패킷을 보내면 중계 장치인 라우터는 MAC헤더에서 다음 라우터 위치(수신처의 MAC 주소)를 확인하여 허브를 거쳐 다음 라우터로 패킷을 운송합니다.

패킷을 전해 받은 라우터에서는 IP헤더에 담긴 목적지(IP 주소)에 도착할때까지 MAC주소를 다시 작성하여 반복하여 다음 라우터를 가리키게 되고 해당 패킷은 또 다시 허브를 거쳐 다음 라우터로 운송됩니다.

이 작업을 반복하다보면 어느덧 목적지에 패킷이 도착하고 이를 잘 받았다는 회신을 송신처로 회신합니다.
이처럼 송신측이 다시 수신측이 되는 일이 반복 되기 때문에 명확히 구분하기 보다는 엔드노드라고 부릅니다.
이때 이더넷의 역할은 무선 LAN, ADSL, FTTH등 IP의 의뢰를 받아 패킷을 운반할 수 있는 것이라면 무엇이든 대신 할 수 있습니다.

 

IP에서 이더넷(네트워크 하드웨어)로 전달할 때는 1과 0의 비트로 이뤄진 디지털 데이터로 변견되고 LAN 어댑터에 의해 전기나 빛의 신호 상태로 바뀌어 케이블로 송출 됩니다.
이때 사용되는 LAN 어댑터는 전원이 공급 되어 OS를 시동할 때 LAN 드라이버(소프트웨어)를 통해 초기화 작업이 수행되는데, 이 중 MAC 회로에 MAC 주소를 설정하는 것이 포인트입니다.

 

MAC(Media Access Control)은 충돌 검출, 재송신 등의 이더넷의 송수신을 제어한느 부분으로 ROM(Read Only Memory)에 MAC 주소를 저장해두고 사용합니다. 이 주소는 전 세계적으로 중복되지 않도록 관리하여 제조 단계에서 기록해두고 사용합니다. 이와 별개로 명령이나 설정 파일에서 주소를 받아 직접 설정하는 경우도 있는데, 이때는 ROM에 저장 된 주소를 무시합니다.
이 주소는 LAN 드라이버가 초기화 작업의 일환으로 인해 유효하게 되며 초기화가 끝난 이후 IP의 의뢰를 대기하는 상태가 됩니다.

---

 

LAN 드라이버는 패킷을 찌릿하게 만들어

LAN 드라이버는 IP 담당 부분에서 패킷을 받으면 그것을LAN 어댑터의 버퍼 메모리에 복사해 둡니다.
이후 패킷을 송신하도록 MAC 회로에 명령을 보내면 MAC 회로가 일을 시작하는데요.

MAC 회로는 송신 패킷을 버퍼 메모리에서 추출하고 맨 앞에 프리앰블과 스타트 프레임 딜리미터 라는 두 개의 데이터를, 맨 끝에는 프레임 체크 시퀀스(Frame Check Sequence)라는 오류 검출용 데이터를 부가합니다.
**패킷과 프레임은 동일한 개념으로 봐도 무방**

 

프리앰블은 송신하는 패킷을 읽을 때의 타이밍을 잡기 위한 것으로 보통 1010...이 반복되는 비트열이 56비트 이어졌으며 이를 신호로 바꾸면 굉장히 규칙적인 파형이 됩니다. 이후 스타트 프레임 딜리미터가 8비트 이어지는데, 끝이 11로 끝나서 파형이 좁게 변합니다. 이를 보고 패킷의 개시 위치를 판단하게 됩니다.

하지만 이후 패킷의 데이터를 읽게 될때가 문제입니다. 패킷 역시 전기 신호로 변환 된 0 또는 1의 비트 값이기 때문에 데이터에 따라 비트가 0이 반복 되거나 1이 반복 되면 어디까지가 데이터의 경계인지 구분 하기 어렵습니다.
때문에 클록 신호를 별도로 보내는 방법을 사용했지만 거리 등의 문제로 신호가 틀어질 수 있어 클록 신호와 데이터를 합성해서 전송 한 후 클록 신호를 이용하여 본래 데이터를 추출해 내는 방법을 사용하게 됩니다.

이러한 클록 신호의 타이밍을 잡기 위한 목적의 신호가 바로 프리앰블이며 패킷의 끝에 부가하는 FCS는 32비트의 비트열로 패킷의 맨 앞부터 맨 뒤까지를 특정한 계산식에 의해 계산하여 잡음 등의 영향으로 값이 1비트라도 달라졌는지를 검출하게 됩니다.

이러한 3가지 값을 부가하면 케이블에 송출할 패킷 준비가 모두 끝납니다.
이제 허브를 사용하여 신호를 송신하게 됩니다.

 

 

---

허브는 중이병

허브를 사용하여 송신을 할 때는 리피터 허브를 사용한 반이중 모드와 스위칭 허브를 사용한 전이중 모드 두 가지 방식이 있습니다.
반이중 모드는 특정 시점에 송,수신 중 한쪽만 가능하고, 전이중 모드는 동시에 병행 할 수 있으며 3장에서 자세히 설명합니다.

 

반이중 모드는 먼저 케이블에 다른 기기가 송신한 신호가 흐르고 있는지 조사하고 이미 점유되었다면 해당 신호가 끝날 때 까지 기다립니다.신호가 흐르고 있지 않거나, 흐르고 있던 신호가 끝나면 송신을 시작하는데, mac 회로가 프리앰블의 맨 앞부터 1비트씩 차레로 전기 신호로 변환하고 MAC회로가 송신한 신호의 형식을 실제로 케이블에 송출하기 위한 변환 회로인 PHY(MAU)로 보냅니다.
이때 디지털 데이터를 전기 신호로 변환하는 속도가 전송 속도이며 1초 동안 10메가비트를 변환하여 보내는 속도가 10Mbps(Megabit per second)라는 전송률이 됩니다.

 

이더넷이라는 통식 방식은 사양에서 기기끼리의 케이블 거리를 100M 이내로 정하기 때문에 좀처럼 오류가 발생하지 않기도 하고 오류가 발생하더라도 프로토콜 스택의 TCP에서 검출하기 때문에 별도로 수신 여부를 확인하지 않습니다.

 

수신 신호선으로 신호가 들어오지 않음을 확인하면 송신을 시작하는데 간혹 미약한 확률로 동시에 송신 동작에 들어갈 경우 수신 신호선으로 신호가 들어와 충돌이 발생하게 됩니다.
이 경우 반이중 모드는 동시 사용이 어렵기 때문에 신호가 뒤섞이게 되고 이 상황을 재밍 신호라는 특수한 신호를 잠시 흘려 주변 기기에 알리면서 모든 송신 도작을 멈춥니다.

잠깐의 대기 시간 후 다시 송신을 시작하는데 MAC 주소를 바탕으로 난수를 생성하여 대기시간을 계산하기 때문에 재 충돌이 발생하지는 않습니다.
충돌이 발생할때마다 대기시간을 2배로 늘리고 열번째까지 다시 보내도 해결되지 않으면 오류로 판단하게 됩니다.

 

조립은 분해의 역순

LAN 어댑터에서 패킷을 전기 신호로 변환하여 송출하는건 위의 설명으로 끝입니다.
반대로 이를 수신할 때의 경우를 설명하자면, 송출의 반대의 순서로 수신을 합니다.
리피터 허브를 이용한 반이중 동작의 이더넷에서는 특정한 리피터 허브 1대가 송신한 신호가 리피터 허브에 접속된 케이블 전체에 브로드 캐스팅이 됩니다. 때문에 모든 허브는 수신 신호선으로 이 신호를 전부 받아들이게 됩니다.

프리앰블을 지나 타이밍을 계산하여 스타트 프레임 딜리미터가 나오면 그 다음 비트부터 디지털 데이터로 변환합니다.
이 동작은 PHY(MAU)에서 공통 신호로 변환한 뒤 MAC 회로에 보내고 MAC 회로는 신호를 맨 앞부터 차레대로 디지털 데이터로 변환하여 수신 버퍼 메모리에 저장하고 FCS를 검사합니다. 여기서 FCS를 검사한다는 것은 패킷의 첫 비트부터 마지막 비트까지 계산식에 적용하여 FCS 값을 산출하고 이를 FCS와 일치하는지를 판단하는 것으로, 만일 일치하지 않다면 오류 패킷으로 간주하여 폐기합니다.

 

FCS에 문제가 없으면 MAC 헤더의 수신처 MAC 주소를 조사하여 자체 MAC 주소와 같은지 비교하여 자신에게 송신 된 것이 아니라면 즉시 폐기하고 맞다면 버퍼 메모리에 저장하고 패킷 수신 여부를 통지합니다.
통지 동작은 인터럽트라는 구조를 사용하는데 이는 CPU의 점유를 잠시 방해하는 방식입니다.

 

구체적으로는 LAN 어댑터가 확장 버스 슬롯 부분에 있는 인터럽트용 신호선에 신호를 보내는데, 이 신호선은 인터럽트 컨트롤러를 통해 CPU에 연결 되어 있습니다. CPU에 신호가 도착하면 CPU는 실행 중인 동작을 잠시 멈추고 OS 내부의 인터럽트 처리용 프로그램으로 전환하는데, 이 떄 LAN 드라이버가 호출되어 LAN 어댑터를 제어하면서 송,수신 동작을 실행하게 됩니다.

 

인터럽트에 의해 LAN 드라이버가 동작하여 LAN 어댑터의 버퍼 메모리에서 수신한 패킷을 추출하면LAN 드라이버는 MAC 헤더의 타입 필드 값으로부터 프로토콜을 판별하고 해당하는 프로토콜 스택에 패킷을 건내줍니다.
이 패킷은 외부 서버 또는 내부 애플리케이션 등 어디서든 올 수 있습니다.

 

패킷을 받은 TCP/IP의 프로토콜 스택은 IP 담당 부분에서 IP 헤더를 조하하여 포맷에 문제가 없는지 확인하고 수신처 IP주소가 LAN 어댑터에 할당된 주소와 일치하면 패킷을 수신합니다.
만에 하나 일치하지 않으면 오류가 있는 것으로 IP 담당부분은 ICMP 메시지를 사용하여 통신 상대에게 오류를 통지하도록 되어있습니다.

 

수신처 IP 주소가 일치하다면 패킷을 수신하는데, 이때 IP 헤더의 플래그 항목을 확인해 패킷이 IP 프로토콜의 fragmentation(조각 나누기) 기능을 통해 나누어진 데이터인지를 확인합니다.
만일 분할 된 패킷이라면 IP 내부 메모리에 임시 보관하고 분할 된 데이터의 ID 정보 값이 동일한 패킷들이 도착하기를 기다립니다.
ID 정보 값 외에도 fragment offset이란 항목에는 패킷이 원래 패킷의 어느 위치에 있었는지를 나타내는 정보가 들어 있습니다.이러한 정보들을 바탕으로 분할된 패킷이 모두 도작하기를 기다렸다가 reassembling(재조립)을 하게 됩니다. 재조립을 마치면 IP 담당 부분의 역할은 끝이 납니다.

 

조립을 마친 패킷을 TCP 담당 부분으로 넘기면 IP 헤더에 기록된 수신처 IP 주소와 송신처 IP 주소, TCP 헤더에 기록된 수신처 포트 번호 및 송신처 포트 번호의 네 가지 항목을 조사하여 목적지 소켓을 찾습니다.
일치하는 소켓을 찾아내면 프로토콜 스택에 통신 진행 상태가 기록되어 있기 때문에 해당 상황에 따라 적절한 동작을 실행합니다.

예를 들어 애플리케이션의 데이터를 넣은 패킷이 있다면 수신 확인 패킷을 반송 한 후 데이터를 수신 버퍼에 저장하고 애플리케이션이 가지러 오기를 기다릴 것이고, 접속이나 연결 끊기 단계의 제어용 애플리케이션이라면 응답의 제어용 패킷을 반송하거나 접속 및 연결 끊기 동작의 상황을 애플리케이션에 통지하게 됩니다.

TCP 담당 부분이 IP 헤더의 내용을 조사한 다는 것이 월권 같아 보일 수 있지만, 사실은 네트워크에도 융통성이란게 있는 겁니다.

 

---

 

Route Table

1. Network Destination 목적지 (왼쪽에서부터 규칙에 따라 일치하는 행 찾음)
2. Interface LAN 어댑터 등의 네트워크용 인터페이스, 인터페이스에서 패킷을 송신하면 상대에 전해줄 수 있다는 의미
3. Gateway 다음 라우터의 IP 주소로 패킷을 전달 받는 대상
4. 목적지와 넷마스크가 0.0.0.0으로 된 첫번째 행, 다른 일차하는 곳이 없으면 해당 (기본 게이트웨이)
5. 프로토콜 번호 TCP 06(16진법), UDP 17(16진법0111.) 등으로 지정

 

ARP(Address Resolution Protocal)

이더넷에 연결 된 모든 노드에 목적지 IP 주소를 브로드 캐스팅하여 일치하는 라우터의 MAC 주소를 회신 받아 ARP 캐시에 저장해 둡니다.
그리고 이 캐시는 통상 몇 분 정도 경과되면 무조건 삭제합니다.

 

UDP (User Datagram Protocal)

패킷이 한 개만 있을 정도로 데이터 길이가 짧으면 어느 부분에서 사라졌는지 걱정 할 필요가 없습니다.
그냥 전체를 다시 보내도 낭비가 아니기 때문이죠.
또 이와 같은 경우 보통은 데이터를 보내면 회신이 오기 때문에 이것으로 수신 확인 응답을 대체하면 수신 확인 응답 패킷도 필요하지 않습니다.

 

DNS 서버 조회 등 제어용으로 실행하는 정보 교환은 위에서 설명한 것 처럼 한 개의 패킷으로 끝나는 경우가 많으므로 TCP가 아닌 UDP를 사용합니다.

UDP에는 TCP와 같은 수신 확인이나 윈도우가 없어서 데이터 송,수신 작업 전에 제어 정보를 주고 받거나 접속 또는 연결 끊기와 같은 단계가 없습니다.

단지 애플리케이션으로부터 송신할 데이터를 받으면 UDP 헤더를 부가하고 IP에 의뢰하여 송신하면 그만입니다.

수신 또한 IP 헤더에 기록 된 수신처 IP 주소와 송신처 IP 주소, 그리고 UDP 헤더에 기록되어 있는 수신처 포트 번호와 송신처 포트 번호의 네 항목과 소켓에 기록된 정보를 결합하여 데이터를 건네줄 대상 애플리케이션을 판단하고 건네주면 그만입니다.

만약 오류가 발생하여 패킷이 없어져도 따로 처리하지 않습니다. 오류가 발생하여 수신 확인 회답이 오지 않으면 데이터를 한번 더 보내면 그만이기 때문입니다.

이와 같은 특성 때문에 음성이나 영상 데이터를 보낼 때도 UDP를 사용합니다.
음성이나 영상 데이터는 결정된 시간 안에 데이터를 건네주어야 하기 때문에 데이터의 무결성보다 재생 타이밍에 맞게 도착하는 것이 더 중요하기 때문입니다.