공부/Network

[Network] CH2. TCP/IP 데이터를 전기 신호로 만들어 보낸다.

persi0815 2025. 1. 14. 22:55
성공과 실패를 결정하는 1%의 네트워크 원리를 읽고 정리한 내용입니다. 

목차

  1. 소켓을 작성한다
  2. 서버에 접속한다
  3. 데이터를 송수신한다
  4. 서버에서 연결을 끊어 소켓을 말소한다
  5. IP와 이더넷의 패킷 송수신 동작
  6. UDP 프로토콜을 이용한 송수신 동작

1️⃣ 소켓을 작성한다.

전체적인 통신 구조와 프로토콜 스택의 내부

네트워크 통신이 이루어지는 과정에서 OS에 내장된 네트워크 제어용 소프트웨어(프로토콜 스택)와 네트워크용 하드웨어(LAN 어댑터) 가 중요한 역할을 한다. 사용자가 브라우저에서 요청을 보내면, 이 요청은 프로토콜 스택을 거쳐 네트워크를 통해 서버로 송출된다.

 

프로토콜 스택은 계층적으로 구성되어 있으며, 각 계층은 특정한 역할을 담당한다. 아래 그림과 같이 프로토콜 스택은 애플리케이션 계층에서 하드웨어 계층까지 여러 단계로 나뉘어 있다.

네트워크 애플리케이션은 데이터 송수신을 위해 프로토콜 스택의 상위 계층(Socket 라이브러리)을 통해 요청을 보낸다.

  • Socket 라이브러리는 애플리케이션과 네트워크 계층 간의 인터페이스 역할을 하며,
  • 내부적으로 리졸버(Resolver) 라는 DNS 서버 조회 클라이언트를 포함한다. 이 리졸버는 도메인 이름을 해당하는 IP 주소로 변환하는 역할을 한다.

이보다 더 아래의 계층은 OS 내부에 존재하며, 실제 패킷을 처리하는 역할을 수행한다.

  • TCP/UDP 계층: TCP 혹은 UDP 프로토콜을 사용하여 데이터 송수신을 수행한다.
  • IP 계층: 패킷 전송을 담당하며, 네트워크 상에서 데이터를 목적지까지 운반하는 역할을 한다.

IP 계층에는 부가적인 기능을 수행하는 두 가지 프로토콜이 존재한다.

  • ICMP(Internet Control Message Protocol): 패킷 전송 과정에서 발생하는 오류 및 제어 메시지를 통지하는 역할을 한다.
  • ARP(Address Resolution Protocol): IP 주소에 대응하는 이더넷 MAC 주소를 조회하는 기능을 수행한다.

네트워크 인터페이스 계층에서는 LAN 드라이버와 LAN 어댑터가 동작한다.

  • LAN 드라이버는 OS가 LAN 어댑터 하드웨어를 제어할 수 있도록 지원한다.
  • LAN 어댑터는 물리적인 네트워크 인터페이스로, 실제 케이블이나 무선 신호를 통해 데이터를 송수신하는 역할을 한다.

데이터 송수신의 핵심: 소켓(Socket)

프로토콜 스택은 네트워크 통신을 관리하기 위해 소켓(Socket) 이라는 개념을 사용한다.


소켓은 프로세스 간 통신을 가능하게 하는 논리적인 개체이며, 네트워크 상에서 데이터를 송수신할 때 반드시 필요하다.

프로토콜 스택은 소켓과 관련된 정보를 관리하기 위한 메모리 영역을 유지하며, 해당 영역에는 IP 주소, 포트 번호, 통신 상태 등의 정보가 기록된다.
이러한 정보를 참조하면서 프로토콜 스택은 데이터를 송수신하고, 연결을 유지 및 종료하는 등의 동작을 수행한다.

소켓의 상태와 통신 정보를 확인하는 방법으로 netstat 명령어를 사용할 수 있다.

  • netstat -ano 명령어를 실행하면 현재 통신 중인 소켓뿐만 아니라 통신이 시작되기 전/후의 소켓 정보(IP 주소, 포트 번호, 프로그램 PID, 상태 등) 를 확인할 수 있다.

브라우저가 socket() 혹은 connect() 함수를 호출하면 발생하는 과정

브라우저가 네트워크 요청을 보낼 때, 내부적으로 Socket 라이브러리의 socket() 또는 connect() 함수를 호출한다.
이 과정에서 프로토콜 스택 내부에서는 다음과 같은 동작이 수행된다.

 

1. 소켓 생성 요청

  • 애플리케이션이 socket() 함수를 호출하면 프로토콜 스택이 새로운 소켓을 생성한다.
  • 프로토콜 스택은 소켓을 위한 메모리 영역을 확보하고, 초기 상태를 해당 영역에 기록한다.

2. 디스크립터 반환

  • 소켓이 생성되면 소켓을 식별하기 위한 디스크립터(File Descriptor)가 애플리케이션에 반환된다.
  • 애플리케이션은 이후 통신할 때 이 디스크립터를 이용해 특정 소켓을 참조하며 송수신 요청을 보낸다.

3. 소켓의 제어 정보 관리

  • 소켓에는 현재의 통신 상태, IP 주소, 포트 번호 등 통신과 관련된 모든 정보가 저장된다.
  • 프로토콜 스택은 소켓에 기록된 정보를 바탕으로 네트워크 통신을 수행한다.

이처럼 소켓은 네트워크에서 데이터를 주고받는 핵심적인 요소이며, 이를 통해 애플리케이션과 네트워크 계층이 서로 연결될 수 있다.

2️⃣ 서버에 접속한다.

소켓 연결과 TCP 3-Way Handshake

애플리케이션이 네트워크 통신을 시작하려면 소켓을 생성한 후, 서버에 연결을 요청해야 한다. 소켓이 생성되면 애플리케이션은 connect() 함수를 호출하여 프로토콜 스택에 서버 측 소켓과의 연결을 요청한다.

 

네트워크에서 "접속한다" 라는 의미는 단순히 물리적으로 연결된다는 것이 아니라, 서버의 IP 주소와 포트 번호를 클라이언트의 프로토콜 스택이 인식하고, 반대로 클라이언트의 정보도 서버 측 프로토콜 스택에 등록하는 과정을 의미한다. 이 과정에서 두 장치는 서로 통신 상대를 인지하고, 이후 데이터를 송수신할 수 있는 상태가 된다. 또한, 데이터 송수신을 원활하게 수행하기 위해서는 일정량의 메모리 공간을 버퍼로 확보해야 하며, 이러한 작업도 접속 과정에서 이루어진다.

TCP 통신에서 사용되는 제어 정보

소켓을 통해 통신이 이루어지려면 제어 정보(Control Information) 가 필요하다. 이 정보는 크게 두 가지로 나눌 수 있다.

 

1. 클라이언트와 서버가 서로 주고받는 TCP 헤더의 제어 정보

  • TCP 프로토콜에서는 접속, 데이터 송수신, 연결 종료 등의 동작을 수행할 때 제어 정보를 헤더(Header)에 포함하여 주고받는다.
  • 이러한 제어 정보는 TCP 사양으로 정의되어 있으며, 패킷의 맨 앞부분에 추가된다.

2. 프로토콜 스택 내부에서 소켓을 관리하기 위한 제어 정보

  • 프로토콜 스택은 소켓의 상태, 통신 상대의 IP 주소, 포트 번호, 데이터 송수신 진행 상황 등을 지속적으로 기록한다.
  • 애플리케이션에서 통지된 정보나 통신 중에 받은 정보도 소켓 내부에 저장되며, 이는 프로토콜 스택이 통신을 올바르게 제어하는 데 필요한 핵심 데이터가 된다.

이러한 정보들이 소켓과 프로토콜 스택 내부에 기록됨으로써, 통신 상대가 서로를 인지하고 정상적인 데이터 송수신이 가능해진다.

 

참고로, TCP 헤더의 포맷과 '헤더'가 위치한 모습은 다음과 같다. 

TCP 3-Way Handshake를 통한 연결 과정

클라이언트가 connect(<디스크립터>, <서버 IP 주소와 포트 번호>, ...) 함수를 호출하면, TCP 3-Way Handshake 과정이 시작된다.

3-Way Handshake는 TCP 연결을 설정하기 위해 클라이언트와 서버가 총 3개의 패킷을 교환하는 과정을 의미한다.

 

1. 클라이언트 → 서버 : SYN 패킷 전송 (연결 요청)

  • 클라이언트의 프로토콜 스택이 TCP 헤더를 생성하고, 송신처와 수신처의 포트 번호를 헤더에 기록하여 소켓을 지정한다.
  • SYN(Synchronize) 비트를 1로 설정하여, 연결을 요청하는 패킷을 만든다.
  • 해당 패킷을 IP 계층으로 전달하여 네트워크를 통해 서버로 전송한다.

2. 서버 → 클라이언트 : SYN-ACK 패킷 전송 (연결 수락)

  • 서버가 클라이언트로부터 도착한 패킷을 수신하면, IP 계층을 통해 TCP 계층으로 전달된다.
  • TCP 계층에서는 헤더를 분석하여 수신처 포트 번호를 기반으로 적절한 소켓을 찾아낸다.
  • 해당 소켓에 연결 정보를 기록하며, 현재 접속 요청이 진행 중인 상태임을 나타낸다.
  • 서버는 SYN 비트와 ACK(Acknowledgment) 비트를 1로 설정한 응답 패킷을 생성한다.
  • 이 패킷을 다시 클라이언트로 전송하여, 접속 요청을 수락했음을 알린다.

3. 클라이언트 → 서버 : ACK 패킷 전송 (연결 완료)

  • 클라이언트가 서버로부터 SYN-ACK 패킷을 받으면, 접속이 성공했음을 확인하기 위해 ACK 비트를 1로 설정한 패킷을 서버로 전송한다.
  • 서버가 ACK 패킷을 수신하면, 서로 간의 연결이 성공적으로 완료된다.

이 과정을 마치면 클라이언트와 서버 간의 TCP 연결(Connection)이 완전히 설정되며, 이후 데이터 송수신이 가능해진다. 이 연결은 close()가 호출될 때까지 유지된다.

3️⃣ 데이터를 송수신한다.

TCP 데이터 송수신 과정과 흐름 제어

connect()를 호출하여 서버와의 연결이 완료되면, 애플리케이션은 이제 데이터를 송수신할 수 있는 상태가 된다. TCP는 데이터를 전송할 때 MTU(Maximum Transmission Unit) 단위로 나누어 송신하며, write()를 호출하면 애플리케이션에서 송신할 데이터를 프로토콜 스택에 전달하게 된다.

 

데이터 송신 과정과 MSS 단위 전송

애플리케이션이 write()를 통해 데이터를 보내면, 프로토콜 스택은 받은 데이터를 송신 버퍼(Send Buffer)에 저장한다. 이때 프로토콜 스택은 데이터의 내용을 직접 해석하지 않으며, 단순히 송신 버퍼에 저장한 후, 다음 데이터가 도착하기를 기다린다.

이렇게 기다리는 이유는 한 번에 전송할 수 있는 데이터 크기가 MTU(Maximum Transmission Unit)로 제한되기 때문이다.

  • MTU는 이더넷 환경에서는 일반적으로 1500바이트로 설정된다.
  • 하지만 MTU에는 TCP/IP 헤더도 포함되므로, 실제 데이터(payload) 크기는 MSS(Maximum Segment Size) 로 결정된다.

송신할 데이터가 MSS보다 크다면, TCP는 데이터를 MSS 크기에 맞게 분할하여 전송한다.

  • 송신 버퍼에 저장된 데이터가 MSS 크기를 초과하면, 추가 데이터를 기다리지 않고 즉시 분할하여 전송한다.
  • 각 데이터 조각에는 TCP 헤더와 IP 헤더가 추가되며, 이를 통해 패킷이 구성된다.

하지만 애플리케이션의 송신 속도가 느릴 경우, MSS 크기만큼 데이터를 모으는 데 시간이 걸릴 수 있다.
이를 방지하기 위해 프로토콜 스택 내부의 타이머가 일정 시간 이상 경과하면, MSS가 다 차지 않았더라도 패킷을 전송하도록 한다.
이러한 방식으로 네트워크 효율성과 송신 지연 문제를 절충하여 최적의 송신 타이밍을 조정한다.

TCP의 신뢰성 보장: 데이터 확인 및 재전송

TCP는 데이터가 올바르게 도착했는지 확인하는 신뢰성 보장 기능을 제공한다.

  • 데이터를 전송할 때 각 패킷에는 "시퀀스 번호(Sequence Number)"가 부여된다.
  • 수신 측에서는 수신된 데이터의 크기를 계산하여 어디까지 데이터를 받았는지 확인하고,
  • 이를 ACK(Acknowledgment) 번호에 기록하여 송신 측에 알려준다.
  • 송신 측은 ACK 번호를 통해 수신된 데이터 범위를 확인하고, 손실된 패킷이 있는 경우 재전송을 수행한다.

이 과정에서 SYN(Sequence Number) 값은 난수를 기반으로 설정된다.

  • 악의적인 공격을 방지하기 위해 시퀀스 번호의 초기값은 무작위로 결정되며,
  • 클라이언트와 서버는 TCP Handshake 과정에서 SYN 패킷을 통해 서로의 초기값을 교환한다.
  • 이후 데이터 송수신 시, 상대가 보낸 SYN 값을 기반으로 ACK 값을 계산하여 응답한다.

 

이전에 접속 동작 부분에서 SYN이라는 제어 비트를 1로 하여 서버에 보내는 부분이 있었는데, 그때 시퀸스 번호에도 초기값을 설정하게 되어있다.

TCP의 오류 검출과 회복 처리

TCP는 데이터 전송 중 오류가 발생할 경우 자동으로 이를 감지하고 재전송을 수행한다.

  • 송신한 데이터의 ACK 응답이 일정 시간 내에 도착하지 않으면, 패킷이 손실되었다고 판단하고 재전송을 수행한다.
  • 하지만 무조건 빠르게 재전송하면 네트워크 혼잡이 발생할 수 있기 때문에, TCP는 "타임아웃 값"을 동적으로 조절한다.
  • 네트워크가 혼잡할 경우 타임아웃 값을 늘리고, 응답 속도가 빠르면 타임아웃 값을 줄이는 방식으로 최적의 재전송 타이밍을 조정한다.

그러나 서버가 다운되거나, 특정 패킷이 지속적으로 손실될 경우, TCP는 재전송을 여러 번 시도한 후에도 응답이 없으면 송신을 중단하고 애플리케이션에 오류를 통지한다.

 

윈도우 제어(Window Control)와 흐름 제어

데이터를 송신한 후, 단순히 ACK 응답을 기다리는 방식은 네트워크 효율을 저하시킨다.이를 해결하기 위해 TCP는 윈도우 제어(Window Control) 기법을 사용한다.

 

윈도우 제어는 여러 개의 패킷을 연속해서 전송할 수 있도록 허용하는 기법이다.

  • 즉, 하나의 패킷을 보낸 후 ACK을 기다리는 것이 아니라, 일정 개수의 패킷을 연속적으로 전송하는 방식이다.
  • 이를 통해 ACK을 기다리는 동안 발생하는 대기 시간을 줄여 네트워크 성능을 최적화할 수 있다.

그러나, 송신 속도가 너무 빠르면 수신 측에서 데이터를 처리하지 못하는 경우가 발생할 수 있다.
이를 방지하기 위해 수신 측에서는 송신 측에게 현재 수신 가능한 데이터 크기를 통지한다.

  • 송신 측은 수신 버퍼의 여유 공간을 확인하여 송신 속도를 조절하며,
  • 수신 가능한 데이터의 최대 크기를 "윈도우 크기(Window Size)" 라고 한다.

수신 측은 수신된 데이터를 애플리케이션에 전달한 후, 버퍼에 여유 공간이 생기면 윈도우 크기를 갱신하여 송신 측에 전달한다.
이를 통해 송신 속도와 수신 속도를 동적으로 조절하며, 네트워크 혼잡을 방지할 수 있다.

 

ACK 응답과 윈도우 크기의 효율적인 관리

송신된 데이터가 수신 측에 도착하면, 수신 측은 ACK 응답을 통해 정상 수신 여부를 즉시 알린다.

  • 그러나 ACK 패킷을 개별적으로 전송하면 네트워크 트래픽이 증가할 수 있다.
  • 이를 방지하기 위해 여러 개의 ACK 응답을 하나로 묶어 보내거나, 마지막 ACK 패킷만 전송하는 방식으로 최적화할 수 있다.

마찬가지로, 윈도우 크기 정보를 매번 개별적으로 전송하면 불필요한 네트워크 부하가 발생할 수 있다.

  • 윈도우 크기 정보는 수신된 데이터를 애플리케이션에 전달한 후 갱신되므로, 일정 간격으로 업데이트하여 송신 측에 전달한다.

이러한 방식으로 TCP는 네트워크 성능을 최적화하면서도 안정적인 데이터 전송을 보장할 수 있다.

4️⃣ 서버에서 연결을 끊어 소켓을 말소한다.

HTTP/1.0의 경우, 애플리케이션이 송신해야 할 데이터를 모두 전송 완료했다고 판단하면, 연결을 종료하는 과정을 거친다.
이때 송신을 완료한 측이 먼저 연결 종료 단계로 들어가며, 여기서는 서버가 송신 측이라고 가정하여 설명하겠다.

 

TCP 연결 종료 과정 (4-Way Handshake)

TCP에서는 신뢰성 있는 연결 종료를 위해 4단계의 핸드셰이크(4-Way Handshake) 절차를 따른다.

 

1. 서버가 close() 호출 (연결 종료 요청)

  • 서버 애플리케이션이 close()를 호출하여 연결 종료를 요청한다.
  • 서버의 프로토콜 스택은 TCP 헤더를 생성하고, FIN(Finish) 비트를 1로 설정하여 연결 종료 요청을 나타낸다.
  • 이 패킷에는 현재 시퀀스 번호(Sequence Number)가 포함된다.

2. FIN 패킷 전송 → 클라이언트가 수신

  • 서버는 IP 계층에 FIN 패킷 송신을 의뢰하고,
  • 클라이언트가 이 패킷을 수신하면, 클라이언트의 프로토콜 스택은 "서버가 연결 종료를 요청했다" 는 정보를 소켓에 기록한다.

3. 클라이언트가 ACK 응답 전송

  • 클라이언트는 FIN 패킷을 수신한 후, 이에 대한 응답으로 ACK 패킷을 서버에 반송한다.
  • ACK 패킷에는 ACK 비트가 1로 설정되어 있으며, 서버가 보낸 FIN 패킷을 정상적으로 받았음을 의미한다.

4. 클라이언트가 close() 호출 → 서버가 최종 ACK 응답

  • 이후 클라이언트 애플리케이션도 close()를 호출하여 데이터 송수신 동작을 종료한다.
  • 클라이언트 프로토콜 스택은 FIN 비트를 1로 설정한 FIN 패킷을 서버로 전송한다.
  • 서버가 이를 수신한 후, ACK 패킷을 클라이언트로 다시 보내면 연결 종료 과정이 완료된다.

소켓 말소 전에 잠시 대기하는 이유

소켓이 말소되면 소켓에 기록된 제어 정보(IP 주소, 포트 번호, 통신 상태 등)가 모두 삭제된다.
이때, 특정 상황에서 잘못된 패킷이 다시 수신되면 연결 종료 과정에 문제가 발생할 수 있다.

예를 들어,

  • 새로운 소켓이 동일한 포트 번호를 할당받았을 경우,
  • 이전 연결에서의 FIN 패킷이 네트워크에서 지연되었다가 다시 도착하면,
  • 새로운 연결이 예기치 않은 FIN 패킷을 받아 잘못된 연결 종료 처리를 할 가능성이 있다.

이러한 오동작을 방지하기 위해 TCP는 연결 종료 후 일정 시간 동안 소켓을 유지하는 "TIME_WAIT" 상태를 유지한다.

  • 이 기간 동안 서버는 FIN 패킷이 다시 전송되지 않는지 확인하고,
  • 일정 시간이 지나면 소켓을 완전히 말소한다.

이 과정을 통해 TCP는 데이터 손실 및 잘못된 연결 종료 문제를 방지하고, 안전한 네트워크 운영을 보장한다.

5️⃣ IP와 이더넷의 패킷 송수신 동작

TCP는 네트워크를 통해 데이터를 송수신하기 위해 IP 담당 부분에 패킷 송신을 의뢰한다. IP 담당 부분은 패킷을 목적지까지 전달하기 위해 IP 헤더를 생성하고, 네트워크 경로를 따라 패킷을 올바르게 전송할 수 있도록 라우팅 테이블을 활용한다.

 

그러나, 네트워크 상에서 패킷이 실제로 전달되려면 이더넷(Ethernet) 계층을 거쳐야 한다. 이 과정에서 MAC 헤더를 추가하고, 네트워크 장치(스위치, 라우터)를 통해 패킷을 전달하는 방식이 사용된다.

 

IP 패킷의 생성 및 전송 과정

패킷은 헤더(Header)와 데이터(Data)로 구성되며, 목적지까지 정확하게 전달하기 위해 송수신과 관련된 데이터를 헤더에 추가한다.

패킷이 목적지까지 도달하는 과정에서, 라우터(Router)와 스위치(Switch) 같은 중계 장치를 여러 번 거치게 된다.

  • 라우터는 패킷의 IP 헤더를 확인하여 다음 라우터로 전달하고,
  • 스위치는 서브넷 내에서 MAC 헤더를 기반으로 목적지 장치로 패킷을 운반한다.

이 과정이 반복되면서 패킷은 최종적으로 수신처에 도착하게 된다.

IP 주소를 기반으로 패킷을 전달하는 방식

IP 담당 부분이 패킷을 송신할 때, 헤더에 송신처와 수신처 IP 주소를 기록한다.

  • 수신처 IP: 애플리케이션에서 제공한 상대 장치의 IP 주소
  • 송신처 IP: 데이터를 전송하는 LAN 어댑터에 할당된 IP 주소

패킷을 전달할 때, IP 담당 부분은 라우팅 테이블(Routing Table)을 참조한다. 우선, Netmask를 사용해 수신처 IP 주소와 송신처 네트워크의 네트워크 ID가 동일한지 확인한다.

  • 같은 네트워크(서브넷) 안에 있다면?
    • 패킷을 직접 수신처 IP가 있는 기기로 전송할 수 있다.
  • 다른 네트워크라면?
    • 게이트웨이(Gateway, 다음 라우터)로 패킷을 전달하여 목적지 네트워크로 이동시킨다.
  • 라우팅 테이블에 수신처와 일치하는 경로가 없다면?
    • 기본 게이트웨이(Default Gateway)를 통해 패킷을 전달한다.

IP 헤더 생성 후, MAC 헤더 추가

IP 담당 부분에서 패킷의 수신처 IP 주소를 통해 목적지를 결정했지만, 이더넷(Ethernet)에서는 IP 주소가 아닌 MAC 주소를 사용하여 데이터를 전달한다. 따라서, IP 헤더 앞에 MAC 헤더를 추가해야 한다. MAC 헤더에는 최종 수신처의 MAC 주소가 아니라, 다음 목적지(라우터 또는 네트워크 장치)의 MAC 주소가 기록된다.

  • 송신처 MAC 주소: 현재 데이터를 송신하는 LAN 어댑터의 MAC 주소
  • 수신처 MAC 주소: 데이터를 전달받을 네트워크 장치(라우터, 스위치 등)의 MAC 주소

이 정보를 기반으로 네트워크 장치(스위치, 라우터)가 패킷을 올바른 경로로 전달할 수 있게 된다.

MAC 주소를 찾기 위한 ARP(Address Resolution Protocol) 사용

패킷을 송신할 때, 수신처 MAC 주소를 알아야 한다. 하지만, 네트워크에서는 IP 주소만으로는 MAC 주소를 직접 알 수 없기 때문에, ARP 프로토콜을 사용하여 MAC 주소를 조회한다.

  1. ARP 캐시(ARP Cache) 확인
    • 먼저, 이전에 조회한 MAC 주소가 저장되어 있는지 확인한다.
    • ARP 캐시는 IP 주소에 대응하는 MAC 주소를 저장하는 메모리 영역으로, 일정 시간이 지나면 갱신된다.
  2. ARP 요청(Request) 전송
    • ARP 캐시에 값이 없으면, 네트워크에 ARP 요청(브로드캐스트)을 전송하여 상대 MAC 주소를 조회한다.
    • 해당 IP를 가진 장치는 자신의 MAC 주소를 포함한 ARP 응답(Reply)을 반환한다.
  3. MAC 주소 저장 후, 패킷 전송
    • 응답을 받은 MAC 주소를 ARP 캐시에 저장하여 이후 재사용한다.
    • 조회된 MAC 주소를 기반으로 패킷의 MAC 헤더를 생성한 후, 데이터 프레임을 전송한다.

이처럼 라우터는 IP 헤더를 통해 다음 라우터를 파악하고, 서브넷 안의 스위치는 MAC 헤더를 통해 목적지 MAC 주소를 확인한 뒤 해당 MAC 주소가 연결된 포트를 찾아 데이터를 전달한다. 라우터는 다음 홉 라우터의 IP 주소를 확인한 후, ARP(Address Resolution Protocol)를 사용해 해당 IP 주소에 해당하는 MAC 주소를 찾아낸다. 찾아낸 MAC 주소를 기반으로 데이터 프레임의 MAC 헤더를 작성하고, 스위치가 패킷을 로컬 네트워크(서브넷) 내에서 목적지 장치로 전달하게 되는 것이다.

  • 이더넷 부분은 무선 LAN, ADSL, FTTH 등 IP의 의뢰를 받아 패킷을 운반할 수 있는 것이면 무엇이든지 이더넷 대신 사용할 수 있다.
  • LAN 어댑터에 건네줄때의 패킷의 모습은 비트들로 이루어진 디지털 데이터인데, 이것이 LAN 어댑터에 의해 전기나 빛의 신호 상태로 바뀌어 케이블에 송출되고, 중계장치에 도착하게 되는 것이다.

이더넷이란? 

이더넷(Ethernet)은 저비용으로 다수의 컴퓨터가 자유롭게 통신할 수 있도록 고안된 네트워크 기술이다.
네트워크 상에서 특정 기기만 패킷을 수신할 수 있도록 하기 위해 MAC 헤더를 사용하며, 스위치(Switch)는 MAC 주소 테이블을 참조하여 패킷을 적절한 포트로만 전달한다.

 

이더넷에서는 다양한 네트워크 장비(유선 LAN, 무선 LAN, 광섬유 등)를 활용하여 패킷을 전송할 수 있다. 패킷이 네트워크를 통해 이동할 때, LAN 어댑터는 디지털 데이터를 전기 신호나 광 신호로 변환하여 송출한다. 이 신호는 케이블을 통해 네트워크 장치로 전달되며, 최종 목적지에서 다시 디지털 데이터로 변환된다. 이더넷은 여러 장치가 동시에 통신할 수 있도록 설계되어 있으며, 효율적인 네트워크 트래픽 관리를 위해 스위치를 활용한다.

  • 스위치는 MAC 주소 기반으로 패킷을 특정 포트로만 전달하여 불필요한 네트워크 트래픽을 줄인다.
  • 네트워크 환경에 따라 유선 LAN(이더넷), 무선 LAN(Wi-Fi), 광섬유(Fiber) 등 다양한 방식으로 데이터를 송신할 수 있다.

6️⃣ UDP 프로토콜을 이용한 송수신 동작

TCP는 데이터를 신뢰성 있게 전달하기 위해 복잡한 과정을 거친다.

  • 데이터가 제대로 도착했는지 확인해야 하며,
  • 도착이 확인되지 않으면 재전송하고,
  • 어디까지 수신되었는지 추적하여 중복 전송을 방지해야 한다.

이러한 과정은 신뢰성을 보장하지만, 처리 과정이 많아 속도가 느려지는 단점이 있다.
만약 데이터의 신뢰성보다 빠른 전송이 중요하다면, 이러한 복잡한 절차를 단순화할 수 있을까?

UDP: 단순하고 빠른 전송 방식

UDP(User Datagram Protocol)는 TCP와 달리 데이터의 신뢰성을 보장하는 추가적인 과정 없이 단순히 데이터를 송신하는 방식을 사용한다.

  • 송신 측은 데이터를 한 번에 전송하고,
  • 수신 측은 데이터를 받기만 하면 된다.
  • 데이터가 손실되었는지 확인하는 절차가 없으며,
  • 패킷이 유실되었을 경우 전체 데이터를 다시 보내면 된다.

이 방식은 TCP보다 훨씬 간단하며, 속도가 중요한 서비스에서 효과적이다.

UDP는 어떻게 동작하는가?

UDP에서는 TCP처럼 수신 확인(ACK)이나 연결 설정(3-Way Handshake)이 필요 없다. 그저 애플리케이션에서 데이터를 받아 UDP 헤더를 추가한 뒤, IP 계층에 의뢰하여 바로 전송하면 된다. 데이터를 수신할 때도 IP 헤더에 포함된 송신처/수신처 IP 주소와 포트 번호만 있으면 된다. 즉, 연결 과정 없이 한 번의 데이터 전송만으로 통신이 완료된다.

 

하지만, 이러한 단순한 방식은 패킷이 손실될 경우 전체 데이터를 다시 전송해야 한다는 단점이 있다. 그럼에도 불구하고, 패킷의 개수가 적거나, 일부 데이터 손실이 문제가 되지 않는 경우라면 UDP가 매우 효율적이다.

UDP가 사용되는 대표적인 사례

1. DNS(Domain Name System) 조회

웹사이트 접속 시, 사용자는 도메인(예: www.example.com)을 입력하지만, 실제 통신은 해당 도메인에 매칭되는 IP 주소를 기반으로 이루어진다. 이때 DNS 서버에 IP 주소를 요청하는 과정에서 UDP를 사용한다.

  • DNS 요청 패킷은 매우 작고,
  • 패킷이 손실되더라도 한 번 더 요청하면 되기 때문에,
  • TCP보다 빠른 UDP가 더 적합하다.

2. 실시간 음성 및 영상 데이터 전송 (VoIP, 스트리밍, 온라인 게임)

오디오와 비디오 데이터는 지연(Latency) 없이 빠르게 전달되는 것이 중요하다.


만약 TCP를 사용하면,

  • 패킷이 유실될 경우 재전송을 기다려야 하며,
  • 그동안 영상이나 음성이 끊기거나 지연될 수 있다.

UDP를 사용하면,

  • 패킷이 손실되더라도 데이터를 다시 요청하지 않고 계속 전송할 수 있어,
  • 끊김 없이 부드러운 스트리밍이 가능하다.

이 때문에 VoIP(인터넷 전화), 온라인 게임, 실시간 스트리밍 서비스에서는 UDP가 필수적으로 사용된다.

TCP vs UDP: 언제 어떤 프로토콜을 사용할까?

신뢰성 높음 (데이터 손실 없음) 낮음 (데이터 손실 가능)
속도 상대적으로 느림 매우 빠름
연결 설정 필요 (3-Way Handshake) 불필요 (바로 전송)
재전송 자동 재전송 없음 (필요 시 전체 재전송)
패킷 흐름 제어 있음 없음
사용 예시 웹 브라우징, 파일 전송, 이메일 DNS 조회, 스트리밍, 온라인 게임

참고자료

https://product.kyobobook.co.kr/detail/S000000559964

 

1%의 네트워크 원리 | Tsutomu Tone - 교보문고

1%의 네트워크 원리 | 성공과 실패를 결정하는 1%의 네트워크 원리 (2nd Edition(개정1판 10쇄))이 책만큼 네트워크의 구조와 작동 원리에 대해 체계적으로 설명한 책은 없다! 이 책은 네트워크 기술을

product.kyobobook.co.kr