소켓 통신 제대로 이해하기: TCP/IP 4계층을 중심으로

소켓 통신 제대로 이해하기: TCP/IP 4계층을 중심으로

2025. 4. 10. 19:25ㆍDevelopment👩🏻‍🦳/Communication

TCP/IP 계층 구조와 역할

인터넷에서 통신이 원활히 이루어지기 위해서는 각 구성 요소들이 일정한 규칙과 절차에 따라 데이터를 주고받아야 한다. 이를 위해 TCP/IP는 네 개의 계층으로 구성된 계층 구조를 따른다. 각각의 계층은 데이터가 전송되는 과정에서 수행해야 할 기능들을 분담하며, 계층 간의 명확한 역할 분담 덕분에 다양한 시스템 간의 상호 운용성이 보장된다. 이 구조는 상위 계층이 하위 계층의 동작 방식에 구애받지 않고 서비스를 사용할 수 있도록 해준다.

각 계층은 다음과 같은 역할을 수행한다.

응용 계층(Application Layer): 최상위 계층으로, 사용자에게 네트워크 서비스를 제공한다. 웹 브라우저가 사용하는 HTTP, 이메일 송수신을 위한 SMTP, FTP, DNS 등이 이 계층에 속한다. 소켓 프로그래밍에서 우리가 직접 다루게 되는 계층도 이 응용 계층이다.
전송 계층(Transport Layer): 응용 계층의 데이터를 송신 측에서는 분할하고, 수신 측에서는 재조립하며, 신뢰성 있는 데이터 전송을 보장하는 역할을 한다. 대표적인 프로토콜로는 연결 지향형의 TCP(Transmission Control Protocol)와 비연결형의 UDP(User Datagram Protocol)가 있다. TCP는 데이터 전송의 순서와 신뢰성을 보장하는 반면, UDP는 빠른 전송이 필요한 상황에서 간단하게 사용된다.
인터넷 계층(Internet Layer): 데이터를 목적지까지 전달하기 위해 주소를 부여하고, 적절한 경로를 선택하는 역할을 한다. IP(Internet Protocol)가 핵심 프로토콜이며, ICMP(Internet Control Message Protocol), ARP(Address Resolution Protocol) 등도 포함된다. IP는 데이터를 패킷이라는 단위로 나누어 전송하며, 목적지 주소를 기준으로 라우팅이 이루어진다.
네트워크 인터페이스 계층(Network Interface Layer): 실제 물리적인 네트워크와의 인터페이스를 담당한다. 이더넷, 와이파이, 광통신 등의 물리적인 연결을 통해 데이터를 송수신하며, MAC 주소 기반으로 통신이 이루어진다. 이 계층에서는 운영 체제의 드라이버나 하드웨어 장치가 주로 관여하게 된다.

이러한 구조는 OSI 7계층 모델과 유사하지만, TCP/IP는 실제 구현과 간결성을 중시하여 4계층으로 단순화되었다. 각각의 계층은 아래쪽 계층의 기능을 기반으로 동작하며, 상호 독립적으로 구현될 수 있다는 점에서 네트워크 기술의 발전과 호환성에 중요한 기반을 제공한다.

TCP/IP 프로토콜 구조를 이해하는 핵심은, 단순히 데이터를 주고받는 것이 아니라 ‘응용 프로그램 간의 통신’을 어떻게 안정적으로 수행할 것인가에 있다. 실제로 사용자가 웹사이트를 접속하거나 메일을 송수신할 때, 통신의 주체는 호스트(PC나 스마트폰)가 아니라 그 안에서 동작하는 웹 브라우저나 메일 클라이언트 같은 응용 프로그램이다. 즉, 네트워크 통신은 **"호스트 간"이 아닌 "응용 프로그램 간"**이라는 점이 TCP/IP 기반 프로그래밍에서 가장 중요한 관점이다.

이를 위해 TCP/IP 프로토콜은 운영체제 내부에 계층적으로 구성되어 있으며, 응용 프로그램은 운영체제에 내장된 이 TCP/IP 스택을 통해 통신 기능을 요청하게 된다. 이때, 운영체제는 요청된 데이터를 패킷 단위로 나누고, 수신지 주소를 붙여 전송하며, 오류가 발생하면 재전송을 수행하거나 통지하는 등의 일련의 과정을 자동으로 처리한다.

응용 프로그램이 직접 처리하지 않아도 되는 대표적인 기능은 다음과 같다:

주소 지정(Addressing): 어떤 장치(호스트)의 어떤 응용 프로그램(포트)과 통신할지를 지정한다.
오류 검출 및 복구(Error Detection & Recovery): 데이터가 손상되었는지를 확인하고, 손상 시 재전송한다.
순서 보장(Sequencing): 데이터가 원래 보낸 순서대로 도착하도록 정렬한다.
흐름 제어(Flow Control): 수신 측이 감당할 수 있는 속도로 데이터를 보내도록 제어한다.

이러한 기능 중 어느 것을 제공할지, 어느 수준까지 제공할지는 사용하는 프로토콜에 따라 다르다. 예를 들어, TCP는 신뢰성을 확보하기 위해 위의 모든 기능을 제공하지만, UDP는 최소한의 데이터 전송만을 목적으로 하므로 이 중 대부분의 기능을 제공하지 않는다. 이 차이는 소켓 프로그래밍 시점에서 프로토콜 선택의 기준이 된다.

계층별 기능 요약:

응용 계층 (Application Layer): 사용자가 직접 사용하는 소프트웨어 수준. HTTP, FTP, SMTP 등의 프로토콜이 동작한다.
전송 계층 (Transport Layer): TCP/UDP를 통해 데이터 전송의 신뢰성과 효율성을 관리한다.
인터넷 계층 (Internet Layer): IP를 통해 전송 경로를 선택하고 주소를 할당한다.
네트워크 접근 계층 (Network Access Layer): 실제 물리적인 네트워크 장치(랜카드, 와이파이 모듈 등)와의 연결을 담당한다.

이 구조 덕분에 복잡한 통신이 단순하고 일관된 방식으로 처리된다. 소켓 프로그래머는 이러한 계층 중 주로 ‘응용 계층’과 ‘전송 계층’을 다루게 되며, 나머지 계층은 운영체제가 자동으로 처리해준다. 따라서 프로그래머는 애플리케이션의 특성에 맞춰 적절한 프로토콜을 선택하고, 필요한 경우 직접 기능을 구현해야 하는 영역을 구분할 수 있어야 한다.

네트워크 접근 계층은 TCP/IP 구조의 가장 하단에 위치하며, 데이터가 실제 물리적인 통신 매체—예를 들면 이더넷 케이블, 무선 주파수, 광섬유 등—를 통해 전송되는 과정을 담당한다. 이 계층의 핵심은 두 가지로 나뉜다: 하드웨어와 드라이버. 즉, 컴퓨터 내부의 네트워크 카드와 이를 제어하는 운영체제의 장치 드라이버가 협력하여 데이터 송수신을 처리한다.

특히 이 계층에서는 IP 주소가 아닌 물리적 주소(Physical Address), 즉 MAC 주소를 사용하여 데이터를 전송한다. 이 물리적 주소는 제조 시 하드웨어에 고정되며, 이더넷 기준으로는 48비트 크기의 고유한 값이다. MAC 주소는 네트워크 상에서 장치를 구분하는 데 사용되며, 통신 과정에서 최종적으로 목적지 장치를 식별하는 데 중요한 역할을 한다.

운영체제별로 MAC 주소를 확인하는 방법은 다음과 같다:

Windows: 명령 프롬프트에서 ipconfig /all 명령을 실행하면, 연결된 모든 네트워크 인터페이스의 MAC 주소와 기타 정보를 확인할 수 있다. 예시 출력은 **08-00-27-00-00-08**처럼 표시된다.
Linux: 터미널에서 ifconfig 또는 ip a 명령을 사용하면 MAC 주소를 포함한 인터페이스 정보가 나타난다. 예시로 **ether 08:00:27:26:7e:ac**처럼 표시된다. 만약 ifconfig 명령이 없다면, Ubuntu에서는 **sudo apt install net-tools**를 통해 설치 가능하다.

이러한 물리적 주소는 로컬 네트워크 내에서만 유효하며, 외부 네트워크로 나갈 때는 IP 주소와 함께 주소 변환(Network Address Translation, NAT) 등을 거쳐 처리된다.

한편, 인터넷 계층은 네트워크 접근 계층이 보낸 데이터를 받아서 논리적 주소(IP 주소) 기반으로 **경로 설정(Routing)**을 수행한다. 여기서 중요한 역할을 하는 것이 바로 **IP(Internet Protocol)**다. IP는 전송 데이터를 ‘패킷’이라는 작은 조각으로 나누고, 이를 목적지까지 전달하기 위해 적절한 라우터를 찾아가는 일을 맡는다. 이때 사용되는 IP 주소는 MAC 주소와 달리 소프트웨어적으로 설정되며, 라우터가 경로를 설정하는 기준이 된다.

결국 네트워크 접근 계층이 "어떤 장치"에 데이터를 보낼지를 결정하고, 인터넷 계층은 "어떤 경로"로 데이터를 보낼지를 결정한다. 이러한 구조 덕분에 물리적 장치가 달라도, 통신이 가능한 유연성과 확장성이 확보된다.

인터넷 계층에서 데이터가 목적지 호스트까지 도달하는 기능을 수행했다면, 이제 전송 계층은 목적지 호스트 내에서 **정확한 응용 프로그램(프로세스)**으로 데이터를 연결해주는 역할을 수행한다. 이를 위해 사용하는 것이 바로 **포트 번호(Port Number)**다. 포트는 하나의 IP 주소 아래 여러 응용 프로그램을 구분하는 수단으로, TCP/IP 통신에서 매우 중요한 역할을 한다.

이때 사용되는 포트 번호는 16비트 정수 값이며, 이론적으로는 0부터 65535까지 존재한다. 이 중 0~1023번 포트는 **"잘 알려진 포트(Well-known Port)"**로서 HTTP(80), HTTPS(443), FTP(21), SMTP(25)처럼 특정 서비스에 할당되어 사용된다. 응용 프로그램이 네트워크 통신을 시작하면, 운영체제는 사용 가능한 포트를 할당하고 이 포트를 통해 송수신을 수행한다.

그러나 단순히 포트를 지정하는 것만으로는 통신의 신뢰성을 보장할 수 없다. 인터넷 계층의 IP는 "데이터를 최선을 다해 전달할 뿐(Best-effort)", 도착 여부나 순서, 손상 여부에 대해 확인하지 않기 때문이다. 따라서 전송 계층은 이런 불완전한 서비스를 보완하고, 응용 프로그램 간의 정확하고 신뢰할 수 있는 데이터 전송을 보장하는 메커니즘을 제공한다.

전송 계층에서 사용되는 대표적인 프로토콜은 두 가지다:

TCP (Transmission Control Protocol)
- 데이터 전송 순서 보장 (Sequence Control)
- 오류 검출 및 재전송 (Error Detection & Retransmission)
- 흐름 제어 (Flow Control)
- 혼잡 제어 (Congestion Control) TCP는 연결 지향(Connection-Oriented) 방식으로 작동하며, 통신을 시작하기 전에 연결을 설정(3-way handshake)해야 한다.
TCP는 신뢰성 있는 전송을 위해 다음과 같은 기능을 제공한다:
UDP (User Datagram Protocol)
UDP는 속도를 우선시하는 비연결형(Connnectionless) 프로토콜로, 위의 TCP 기능들을 대부분 생략한다. 그 대신 빠른 전송이 가능하여, 실시간 영상 스트리밍, 게임 통신, IoT 기기 제어 등에서 사용된다. 신뢰성은 낮지만 단순한 구조 덕분에 가볍고 빠르다.

즉, 전송 계층은 IP 주소와 포트 번호를 통해 **"어느 호스트의 어느 프로그램으로 데이터를 보낼 것인가"**를 결정하고, 선택한 프로토콜(TCP 또는 UDP)의 특성을 바탕으로 전송의 신뢰성과 효율성을 조정한다.

결국 응용 프로그램 입장에서 통신은 "IP + Port"의 쌍으로 표현되며, 이러한 구조가 세계 어디서든 다양한 장치 간의 안정적인 데이터 교환을 가능하게 만든다.

TCP와 UDP는 전송 계층에서 가장 핵심적인 두 프로토콜로, 네트워크 프로그램의 동작 방식에 직접적인 영향을 준다. 이 둘은 기능적 특성, 데이터 처리 방식, 통신 모델 등 여러 측면에서 큰 차이를 보이며, 어떤 프로토콜을 선택하느냐에 따라 응용 프로그램의 성능, 신뢰성, 구조가 달라진다.

TCP vs UDP 요약 정리

항목 TCP (Transmission Control Protocol) UDP (User Datagram Protocol)

통신 방식	일대일(Unicast)	일대일(Unicast), 일대다(Broadcast, Multicast)
연결 방식	연결형(Connection-oriented) – 통신 전에 연결 설정 필요 (3-way handshake)	비연결형(Connectionless) – 연결 설정 없이 데이터 송수신 가능
데이터 경계	바이트 스트림 (Byte-Stream): 데이터가 연속된 흐름으로 처리됨	데이터그램 (Datagram): 전송 단위별로 경계 구분이 명확함
신뢰성	전송 순서 보장, 오류 검출 및 재전송 등 높은 신뢰성 제공	신뢰성 없음: 데이터 손실, 순서 바뀜, 중복 가능성 존재
오버헤드	비교적 큼 (헤더 크고 처리 복잡)	작음 (구조 단순, 빠름)
사용 사례	웹(HTTP/HTTPS), 이메일(SMTP), 파일 전송(FTP) 등 신뢰성 요구	실시간 스트리밍, VoIP, 온라인 게임 등 속도 우선

⚠️ 참고: TCP라고 해서 물리적인 장애(예: 랜선 분리, 시스템 다운)를 완벽하게 막는 건 아니다. TCP가 보장하는 것은 "소프트웨어적으로 가능한 신뢰성"이다. 즉, 재전송, 순서 보정, 오류 감지 수준의 신뢰성을 의미한다.

응용 계층과의 연계

응용 계층은 전송 계층이 제공하는 기능을 바탕으로 실제 사용자 서비스를 구현한다. 예를 들어 웹 브라우저는 전송 계층의 TCP를 기반으로 HTTP 통신을 수행하고, 메신저 앱은 UDP를 기반으로 메시지를 빠르게 전송할 수 있다. 여기서 우리가 직접 소켓 프로그래밍을 한다는 것은, 응용 계층에서 전송 계층을 호출하고 통제하는 역할을 직접 구현하는 것을 의미한다.

데이터 전송 원리

통신을 위한 데이터는 단순한 메시지가 아니라, 다양한 제어 정보와 함께 구조화된 형태로 전송된다. 이 구조의 핵심은 **패킷(Packet)**이라는 단위다. 송신 측의 응용 프로그램이 전송하고자 하는 데이터는 다음의 절차를 거친다:

응용 계층에서 메시지를 생성한다.
전송 계층은 포트 번호, 오류 체크 정보 등을 담은 TCP/UDP 헤더를 붙인다.
인터넷 계층은 목적지 IP 주소 등을 담은 IP 헤더를 추가한다.
네트워크 접근 계층은 최종적으로 MAC 주소, 프레임 정보 등을 덧붙여 **프레임(Frame)**으로 완성한다.
모든 정보가 합쳐진 구조가 **패킷 = 헤더 + 데이터(페이로드)**이며, 이 구조를 따라 송수신이 이루어진다.

계층별 전송 구조 (요약)

응용 계층:         메시지
전송 계층:       TCP/UDP 헤더 + 메시지
인터넷 계층:   IP 헤더 + TCP/UDP 헤더 + 메시지
네트워크 계층: MAC 헤더 + IP + TCP/UDP + 메시지 + FCS

이러한 구조 덕분에 각 계층은 책임 분담을 통해 유연성과 확장성을 갖게 되며, 다양한 환경에서도 안정적으로 데이터 통신이 가능해진다.

패킷의 전송 구조는 TCP/IP 프로토콜의 계층적 설계 원리를 가장 직관적으로 보여주는 예시다. 송신 측의 응용 프로그램에서 생성된 데이터가 실제 물리적인 네트워크를 거쳐 수신 측의 응용 프로그램까지 도달하는 동안, 데이터는 여러 계층을 통과하면서 **헤더(Header)**와 **트레일러(Trailer)**가 덧붙고 제거되는 과정을 거친다. 이 과정을 **캡슐화(Encapsulation)**와 **역캡슐화(Decapsulation)**라고 부른다.

송신 측에서의 패킷 구성 (Encapsulation)

송신 측에서 응용 프로그램이 데이터를 생성하면, 그 데이터는 아래와 같은 과정을 거쳐 패킷이 완성된다:

[응용 계층]
 └ 데이터
    ↓
[전송 계층]
 └ TCP 헤더 + 데이터
    ↓
[인터넷 계층]
 └ IP 헤더 + TCP 헤더 + 데이터
    ↓
[네트워크 접근 계층]
 └ 이더넷 헤더 + IP 헤더 + TCP 헤더 + 데이터 + 이더넷 트레일러

TCP 헤더: 포트 번호, 시퀀스 번호, 오류 검출 등을 포함
IP 헤더: 송신지/목적지 IP 주소, TTL(Time To Live), 프로토콜 번호 등 포함
이더넷 헤더 및 트레일러: 송신/수신 MAC 주소, FCS(Frame Check Sequence) 등 포함

각 계층은 자신이 필요한 제어 정보를 헤더에 추가한 뒤 다음 계층으로 넘기며, 최종적으로 완성된 이더넷 프레임은 네트워크를 통해 전송된다.

수신 측에서의 역캡슐화 (Decapsulation)

수신 측은 반대로 패킷을 받아서 각 계층의 헤더를 하나씩 제거해가며 데이터를 전달한다:

plaintext
코드 복사
[네트워크 접근 계층]
 └ 이더넷 헤더/트레일러 제거
    ↓
[인터넷 계층]
 └ IP 헤더 제거
    ↓
[전송 계층]
 └ TCP 헤더 제거
    ↓
[응용 계층]
 └ 순수 데이터만 응용 프로그램에 전달

응용 프로그램이 신경 써야 할 부분은 오직 데이터 자체이며, 나머지 모든 캡슐화/역캡슐화 및 오류 처리, 전송 순서 보정 등은 운영체제 내부의 프로토콜 스택이 자동으로 수행한다. 이 구조 덕분에 응용 프로그래머는 통신의 복잡성을 몰라도 프로그램을 구현할 수 있는 추상화된 환경을 얻을 수 있다.

계층 간 통신의 핵심 개념: Peer-to-Peer Model

각 계층은 자신과 동일한 계층(peer) 간에만 직접적으로 논리적 통신을 수행한다고 간주한다. 예를 들어 송신 측의 TCP 계층은 수신 측의 TCP 계층에 데이터를 보낸다고 생각하며, IP 계층은 IP 계층끼리, 이더넷 계층은 이더넷 계층끼리 통신하는 형태다. 실제로는 이 모든 데이터가 하위 계층을 통해 전달되지만, 계층 설계 철학은 이러한 논리적 대응 구조를 기반으로 한다.

주의사항

동일한 이더넷 네트워크(예: 하나의 스위치에 연결된 LAN)에서만 이더넷 프레임이 직접 전달되며, 서로 다른 네트워크에 위치한 호스트 간에는 라우터를 거쳐 IP 계층 수준에서만 통신이 이루어진다. 따라서 [그림 1-6]에서는 이더넷 계층을 생략하여 단순화한 것이다.

TCP/IP 프로토콜의 데이터 전송 원리를 일반화해 보면, 각 계층은 역할에 따라 서로 다른 수준의 책임을 가지며, 계층 간 협력을 통해 종단 간(End-to-End) 통신을 실현한다. 특히, 응용 계층과 전송 계층은 송신측과 수신측 호스트에만 존재하며, 이 둘 사이에 라우터가 개입하더라도 그 계층에는 전혀 영향을 받지 않는다. 반면, 인터넷 계층과 네트워크 접근 계층은 중간 경로의 라우터에도 존재하며, 실제 패킷을 운반하고 다음 목적지로 전달하는 역할을 맡는다.

계층별 전송 흐름: 가상 연결과 실제 연결의 구분

[그림 1-7]의 구조 해석에 따라 데이터가 송신 측에서 수신 측까지 도달하는 과정은 다음과 같이 설명할 수 있다:

[송신 측 호스트]
응용 계층         → 실제 데이터 생성
전송 계층         → 포트 번호로 응용 프로그램 지정
인터넷 계층       → IP 주소로 목적지 호스트 지정
네트워크 계층     → 다음 장치의 MAC 주소로 물리적 전달

[라우터 A]
인터넷 계층       → 목적지 IP 기반 라우팅 결정
네트워크 계층     → 다음 라우터 또는 목적지 호스트의 MAC 주소로 전송

[라우터 B ...]
(반복 처리)

[수신 측 호스트]
인터넷 계층       → 최종 목적지로 패킷 도달 확인
전송 계층         → 포트 번호 기반으로 응용 프로그램 식별
응용 계층         → 데이터 수신 및 처리 완료

응용 계층과 전송 계층은 중간 라우터에 존재하지 않는다. 이 계층의 연결은 가상적인 연결이며, 실제로는 IP와 MAC 주소가 중간에서 바뀌면서 이어진다.
인터넷 계층과 네트워크 접근 계층은 각 라우터마다 존재하고, 실제 패킷의 물리적 전달을 수행한다.
패킷은 라우터를 통과할 때마다 MAC 주소가 변경되며, IP 주소는 유지된다.

IP 주소와 포트 번호의 역할

TCP/IP 통신에서 가장 기본적인 식별자는 IP 주소와 포트 번호다. 이 두 값을 조합한 것이 곧 하나의 통신 세션을 정의한다:

IP 주소 (Internet Protocol Address)
- 호스트를 구분하는 논리적 주소
- 전 세계에서 고유함이 보장됨
- IPv4 (32비트): 147.46.114.70 형식
- IPv6 (128비트): 2001:0230:abcd:ffab:0023:eb00:ffff:1111 형식
포트 번호 (Port Number)
- 하나의 호스트 내 여러 응용 프로그램을 구분
- 16비트 크기 (0~65535)
- 예: HTTP – 80번, HTTPS – 443번, FTP – 21번
- 사용자는 일반적으로 1024 이상의 포트를 사용 (ephemeral 포트)

따라서 하나의 소켓(Socket)은 다음과 같은 구조로 통신 상대를 식별한다:

[송신 IP]:[송신 포트] ↔ [수신 IP]:[수신 포트]

이 구조는 완전히 유일한 세션을 식별하며, 하나의 호스트에서 여러 통신을 동시에 처리할 수 있도록 해준다.

예시: 실제 연결 시 세션 구성

클라이언트 (내 컴퓨터):   192.168.0.11:52345
서버 (웹 서버):          147.46.114.70:80

=> 이 쌍이 하나의 TCP 연결을 구성함

라우터는 IP 주소만을 기반으로 목적지를 판단하며, 전송 계층과 포트 정보는 전혀 관여하지 않는다. 반대로 응용 프로그램은 포트 번호를 통해 자신에게 온 데이터인지 식별하며, IP 경로에 대해서는 신경 쓰지 않는다.

포트 번호는 단순히 프로세스를 식별하는 숫자가 아니라, 통신의 종착점을 정의하는 논리적인 식별자로 보는 것이 보다 정확한 이해다. 전통적으로는 "포트 = 프로세스"라는 단순한 구조로 설명되지만, 실제 구현에서는 다음과 같은 복잡한 시나리오가 존재한다:

포트 번호와 프로세스 간의 관계

하나의 프로세스가 여러 포트를 사용할 수 있다
예: 웹 서버가 HTTP(80)와 HTTPS(443)를 동시에 서비스할 경우, 하나의 프로세스가 두 포트를 바인딩할 수 있다.
여러 프로세스가 하나의 포트를 공유할 수 있다
예: 멀티 프로세스 서버에서 동일한 포트에 대해 각 프로세스가 동시에 SO_REUSEPORT 옵션을 설정하고 바인딩하면 커널이 부하 분산하여 연결을 분배해 준다.

즉, 포트 번호는 "IP 주소 + 프로토콜 + 포트"의 조합으로 통신 세션의 종착지를 식별하며, 이는 반드시 하나의 프로세스와 일대일 대응하지 않는다.

포트 번호의 구조와 범위

TCP와 UDP는 16비트 부호 없는 정수로 포트를 표현하기 때문에 총 65,536개(0~65535)의 포트가 존재하며, 용도에 따라 다음처럼 세분화된다:

포트 번호 범위 명칭 용도 예시

0 ~ 1023	알려진 포트 (Well-known)	HTTP(80), HTTPS(443), FTP(21), SSH(22) 등 시스템 예약 포트
1024 ~ 49151	등록된 포트 (Registered)	사용자 등록 서비스용. 일반 서버 프로세스에 사용
49152 ~ 65535	동적/사설 포트 (Dynamic)	클라이언트에서 자동 할당되는 일시적 포트 (ephemeral)

✅ 서버 프로세스는 일반적으로 1024번 이상의 포트를 사용하고, 클라이언트 프로세스는 동적으로 할당된 포트를 사용한다.

공식 등록 정보는 IANA (Internet Assigned Numbers Authority)의 포트 번호 할당 문서에서 확인할 수 있다:

🔗 https://www.iana.org/assignments/port-numbers

IP 주소와 포트 번호의 결합 구조

하나의 IP 주소에 여러 포트를 할당할 수 있기 때문에, 실제 소켓 연결은 아래 구조로 정의된다:

(IP 주소, 포트 번호, 프로토콜)
예: (192.168.0.100, 8080, TCP)

이 조합을 기반으로 커널은 네트워크 트래픽을 특정 프로세스의 소켓으로 정확히 분배한다. 하나의 호스트가 여러 개의 네트워크 인터페이스(IP)를 가질 수 있기 때문에, IP 주소가 다르면 동일 포트 번호도 중복 사용 가능하다. 반대로, 동일 IP에 동일 프로토콜의 동일 포트를 중복 바인딩하는 것은 원칙적으로 금지된다(단, SO_REUSEADDR, SO_REUSEPORT 설정 시 예외 가능).

실제 예시 (그림 1-8 기반 설명)

호스트 A는 두 개의 IP 주소를 가지고 있음 (192.168.1.10, 10.0.0.10)
프로세스 1: HTTP 요청 수신 (80번 포트) → TCP 포트 80 사용
프로세스 2: 내부 관리 도구 서비스 (8080번 포트) → 동일 IP라도 다른 포트로 동시 운영 가능
프로세스 3: 비동기 통신 서버 → 하나의 프로세스가 TCP와 UDP 포트를 동시에 바인딩 가능
프로세스 4~n: 동적 포트를 사용해 클라이언트 요청을 처리하거나 외부 연결을 수립

이러한 구조는 소켓 프로그래밍에서 복잡한 서비스 구조를 설계할 수 있는 유연함을 제공하며, 다양한 멀티플렉싱 구조를 가능하게 해준다.

숫자로 이루어진 IP 주소는 네트워크 통신에서 반드시 필요한 식별자지만, 사람이 기억하고 다루기엔 번거롭다. 예를 들어 147.46.114.70 같은 주소는 한 번 보고 쉽게 기억하기 어렵기 때문에, 우리는 **www.microsoft.com**과 같은 **도메인 이름(Domain Name)**을 사용한다. 이 도메인 이름은 실제로는 단순한 **IP 주소의 별칭(Alias)**일 뿐이며, 통신을 수행할 때는 반드시 IP 주소로 변환된 후 사용된다. 이 변환 작업은 **DNS(Domain Name System)**에 의해 수행되며, 이 책에서는 이후 3장에서 자세히 설명된다.

클라이언트-서버 모델의 개념과 구조

실제 네트워크 프로그램은 대부분 **클라이언트-서버 모델(Client-Server Model)**을 기반으로 작성된다. 이 모델은 두 프로그램 간 상호작용의 형태를 구조적으로 정의하는데, 핵심 개념은 다음과 같다:

클라이언트(Client): 서비스 요청을 보내는 프로그램
서버(Server): 요청을 받고 응답을 제공하는 프로그램

이 모델은 반드시 네트워크 환경에서만 사용하는 것이 아니라, 하나의 컴퓨터 내부에서 실행되는 여러 프로세스 간에도 적용 가능하다. 단, 로컬 환경에서는 IPC (Inter-Process Communication) 기법—예: 파이프, 공유 메모리, 메시지 큐—등을 사용하고, 네트워크 환경에서는 반드시 **통신 프로토콜(예: TCP/IP)**을 기반으로 동작해야 한다.

동시 접속 모델 vs 클라이언트-서버 모델

*[그림 1-9(a)]**는 전통적인 동시 접속 모델을 보여주는데, 이 방식에서는 두 프로그램이 서로 동시에 실행되어 있어야 접속이 가능하다. 이 구조에서는 다음과 같은 문제가 발생할 수 있다:
상대가 실행되지 않았을 경우 접속 실패
타이밍 맞추기 어려움
접속 시도와 실패 반복으로 비효율

이에 반해 **[그림 1-9(b)]**와 같은 클라이언트-서버 모델에서는 이러한 문제가 자연스럽게 해결된다. 그 구조는 다음과 같다:

[서버]
- 먼저 실행
- 포트 번호를 지정하고 ‘대기 상태’로 유지 (bind → listen)
- 클라이언트가 접속할 수 있도록 열려 있음

[클라이언트]
- 나중에 실행
- 서버의 IP 주소(또는 도메인 이름)와 포트 번호를 알아야 함
- 서버로 접속 요청을 보냄 (connect)

→ 접속 성공 시 데이터 송수신 가능

서버는 클라이언트의 IP와 포트 정보를 몰라도 된다. 클라이언트가 보낸 패킷 내부에 해당 정보가 포함되어 있기 때문에, 서버는 응답을 보낼 때 이 정보를 그대로 사용하면 된다. 이 구조 덕분에, 서비스를 안정적으로 제공하는 서버와 필요할 때 접속하는 클라이언트 간의 효율적인 통신이 가능해진다.

정리: 클라이언트-서버 모델의 장점

타이밍 문제로 인한 접속 실패를 방지
다수의 클라이언트가 동시에 한 서버에 접속 가능 (멀티 스레드 또는 멀티 프로세스 구조 활용 가능)
서버는 고정된 포트를 열어두고, 클라이언트는 동적 포트를 사용하여 통신 구조를 단순화

소켓(Socket)은 네트워크 통신을 위한 표준 인터페이스로, 다양한 운영체제와 프로그래밍 언어에서 폭넓게 사용된다. 특히 BSD UNIX에서 처음 정의된 이후, 윈도우에서도 **Winsock(윈속)**이라는 이름으로 공식 지원되면서 운영체제에 상관없이 일관된 방식의 네트워크 프로그래밍이 가능해졌다.

소켓은 네트워크의 콘센트다

소켓이라는 개념을 일반 전화 시스템에 빗대어 이해하면 직관적이다:

실제 시스템 대응하는 개념

사람	응용 프로그램 (Application)
전화기	소켓 (Socket)
내선번호	포트 번호 (Port Number)
대표 전화번호	IP 주소 (IP Address)
전화망	인터넷 (Network)

그림 (a): 내가 말한 소리가 전화기를 통해 상대방에게 전달되는 것처럼소켓을 통해 전송한 데이터는 상대방 소켓을 통해 전달된다.그림 (b): 전화 연결이 되기 위해선 ‘전화기 + 대표번호 + 내선번호’가 모두 필요하듯소켓도 IP 주소 + 포트 번호를 조합해야 정확한 응용 프로그램과 연결된다.

소켓은 무엇인가?

소켓은 다음 세 가지 관점에서 이해할 수 있다:

1. 데이터 타입 (Data Type) 관점

소켓은 프로그래밍적으로 **파일 디스크립터(file descriptor)**처럼 다룰 수 있는 **정수형 핸들(handle)**이다.
소켓 생성 함수(socket())를 호출하면, 운영체제는 이를 관리하는 번호를 할당한다.
이는 마치 파일을 열면 파일 핸들을 얻는 것처럼, 소켓도 리소스를 다루는 식별자로서의 역할을 한다.

2. 통신 종단점 (Communication Endpoint) 관점

소켓은 네트워크 통신에서 **한쪽 끝(End Point)**을 나타낸다.
하나의 소켓은 IP 주소와 포트 번호를 가지고 있으며, 상대방의 소켓과 연결되어야 데이터 송수신이 가능하다.
이때 사용되는 프로토콜은 TCP 또는 UDP 등 전송 계층의 방식에 따라 달라진다.

3. 프로그래밍 인터페이스 (API) 관점

소켓은 운영체제가 제공하는 표준 함수 세트를 통해 제어된다.
주요 함수에는 socket(), bind(), connect(), listen(), accept(), send(), recv() 등이 있다.
이 함수들을 통해 소켓의 생성, 연결, 데이터 송수신까지 일련의 통신 절차를 제어할 수 있다.

소켓이 필요한 이유

하드웨어 신호, 장치 드라이버, 프로토콜 스택 등 네트워크 통신의 모든 내부 메커니즘을 개발자가 직접 다룰 필요는 없다. 마치 전자기기를 벽면의 전원 소켓에 꽂기만 하면 전기를 사용할 수 있듯, 소켓은 복잡한 네트워크 계층을 추상화한 접근점을 제공한다. 덕분에 프로그래머는 내부 구조를 몰라도 네트워크 통신을 구현할 수 있다.

정리

소켓은 **IP 주소 + 포트 번호 + 프로토콜(TCP/UDP)**을 기반으로 통신 종단점을 정의
소켓 프로그래밍은 클라이언트-서버 모델을 기반으로 구현
Winsock은 윈도우에서 소켓을 지원하기 위한 API 집합

앞으로 소켓을 사용하여 클라이언트가 데이터를 보내고, 서버가 수신하며 다시 응답을 주고받는 다양한 예제를 통해 이 추상 개념이 구체화될 것이다.

소켓(Socket)은 네트워크 프로그래밍에서 **핸들(handle)**이나 **파일 디스크립터(file descriptor)**처럼 리소스를 식별하고 제어하는 추상적인 데이터 타입이다. 이 개념을 이해하기 쉽게 설명하면, 소켓은 통신용 "파일"과 같고, 그 파일을 통해 데이터를 읽고 쓸 수 있다는 점에서 파일 입출력과 매우 유사한 구조를 갖는다.

📞 전화 통신 vs 소켓 통신 (그림 1-10 해석)

(a) 전화기 구조

사람 → 응용 프로그램
전화기 → 소켓
전화망 → 인터넷

내가 전화기에 대고 말하면, 상대방의 전화기로 음성이 전달되듯

응용 프로그램이 소켓을 통해 데이터를 보내면, 상대방 소켓으로 그 데이터가 전송된다.

(b) 상세 매핑

대표 전화번호 → IP 주소 (주소의 범위를 결정)
내선 번호 → 포트 번호 (동일 호스트 내 특정 응용 프로그램 식별)
전화기 → 소켓 (전화망을 통해 연결된 입출력 장치)

따라서 소켓은 IP 주소 + 포트 번호 + 프로토콜 정보를 포함하여

네트워크 통신의 종단점(endpoint) 역할을 수행한다.

📁 소켓 = 통신 가능한 파일 핸들

소켓은 데이터 타입 관점에서 보면 "파일 핸들"이나 "디스크립터"와 동일한 패턴으로 동작한다.

(a) 리눅스 파일 입출력 예시

int fd = open("myfile.txt", O_RDONLY); // 파일 열기
read(fd, buf, size);                   // 읽기
write(fd, buf, size);                  // 쓰기

(b) 윈도우 소켓 통신 예시

SOCKET sock = socket(AF_INET, SOCK_STREAM, 0); // 소켓 생성
recv(sock, buf, size, 0);                       // 데이터 수신
send(sock, buf, size, 0);                       // 데이터 송신

→ 모양이 거의 동일하며, 소켓도 일종의 입출력 스트림으로 다룰 수 있음을 보여준다.

✅ 리눅스 vs 윈도우의 차이점

항목 리눅스 윈도우

소켓 타입	int (파일 디스크립터와 동일)	SOCKET (별도 정의된 타입)
함수 호환성	read() / write()도 사용 가능	recv() / send()만 사용
입출력 통합 처리	select, epoll 등으로 파일/소켓 통합 관리	Winsock 전용 API 필요
예외 처리	errno 기반	WSAGetLastError() 기반

리눅스는 소켓을 파일처럼 취급하기 때문에 코드 재사용성이나 추상화에 유리반면 윈도우는 별도 API 구조로 분리되어 있어 Winsock 초기화와 종료 코드 필요

정리: 소켓의 핵심 개념 요약

소켓은 네트워크 통신을 위한 논리적 입출력 장치
IP 주소와 포트 번호로 네트워크상의 상대를 지정
함수 호출만으로 복잡한 통신을 추상화
리눅스에선 파일 디스크립터, 윈도우에선 전용 SOCKET 타입 사용

이후 학습에서는 이 소켓을 중심으로 서버-클라이언트 구조를 구축하고, 데이터를 송수신하는 예제를 다루게 된다.

소켓을 이용한 통신에서 핵심은 **서로 연결된 두 통신 종단점(Communication End-Point)**을 정의하고, 이를 통해 응용 프로그램 간에 데이터를 주고받는 구조를 구현하는 것이다. 통신을 성립시키기 위해 필요한 요소들은 다음과 같으며, 이 정보는 모두 운영체제가 소켓 내부에서 관리한다.

✅ 통신에 필요한 기본 요소 5가지

사용할 프로토콜
- TCP/IP (신뢰성 있는 연결형 통신)
- UDP/IP (빠른 전송이 가능한 비연결형 통신)
송신측 IP 주소
- 보통 자동으로 설정되지만, 명시적으로 바인딩할 수도 있음
- ex: 192.168.0.11
송신측 포트 번호
- 클라이언트는 일반적으로 운영체제가 동적으로 할당 (ephemeral port)
- 서버는 고정 포트를 사용하여 외부 연결을 대기
수신측 IP 주소
- 서버의 고정된 주소 또는 도메인 이름이 DNS를 통해 IP로 해석됨
수신측 포트 번호
- 서비스의 종류에 따라 정해진 값 사용 (ex: HTTP: 80, FTP: 21, 사용자 정의 포트도 가능)

응용 프로그램은 이러한 정보에 직접 접근하지 않아도 되고, 소켓을 통해 이를 추상적으로 다룰 수 있다. 이 덕분에 복잡한 네트워크 제어 없이도 통신 프로그램을 구현할 수 있게 된다.

📌 통신 종단점 (Endpoint)으로서의 소켓

[그림 1-12]는 클라이언트와 서버가 각각 소켓을 통해 통신하는 상황을 시각적으로 설명한다:

[클라이언트]
send(sock, buf, size)

소켓 A
- IP: 147.46.114.70
- 포트: 12023

[인터넷]
TCP/IP 프로토콜

소켓 B
- IP: 61.72.244.22
- 포트: 9001

[서버]
recv(sock, buf, size)

클라이언트는 자신의 소켓이 서버와 연결되어 있다고 믿고 send() 호출
서버는 자신의 소켓이 클라이언트와 연결되어 있다고 믿고 recv() 호출
실제로는 운영체제가 TCP/IP를 이용해 양쪽 소켓 간 데이터를 중계해준다

소켓은 실제 네트워크 장비가 아니라, 운영체제 안에 존재하는 논리적인 연결점이며,통신에 필요한 모든 정보(IP, 포트, 상태 등)를 이 소켓이 포함하고 있다.

💡 참고: 실제 연결 쌍 예시

클라이언트 소켓:
IP: 147.46.114.70
Port: 12023

서버 소켓:
IP: 61.72.244.22
Port: 9001

통신 식별자:
[147.46.114.70:12023] <-> [61.72.244.22:9001]

이러한 쌍은 TCP 연결이 유지되는 동안 유일하게 존재하며,

운영체제는 이 조합을 기준으로 클라이언트와 서버 간의 데이터 흐름을 추적하고 관리한다.

정리

소켓은 통신의 논리적 출발점이자 도착점
send()와 recv() 호출만으로 실제 통신이 이루어진다고 믿고 프로그래밍하면 됨
운영체제는 통신에 필요한 모든 정보(IP, 포트, 프로토콜)를 내부적으로 소켓에 저장하고 처리
소켓은 추상적이지만 실제 데이터는 물리 네트워크를 통해 오간다

소켓은 TCP/IP 프로토콜 스택에서 응용 계층과 전송 계층 사이에 위치하는 네트워크 프로그래밍 인터페이스이다. 다시 말해, 소켓은 통신을 위한 '창구' 역할을 할 뿐, 통신 자체의 주체는 아니다. 따라서 응용 프로그램이 데이터를 주고받기 위해 반드시 양쪽 모두가 소켓을 사용할 필요는 없다. 단지 동일한 프로토콜(TCP, UDP 등)을 사용하고, 정해진 형식과 절차에 따라 데이터를 송수신하기만 하면 된다.

🔌 소켓은 "접근 창구"일 뿐이다

[그림 1-13]을 통해 이해할 수 있는 핵심 구조는 다음과 같다:

응용 계층
 └ 응용 프로그램 (Web, FTP, Chat, 등)

  ↓ (API 호출)

소켓 인터페이스
 └ send(), recv(), connect(), bind() 등

  ↓

전송 계층
 └ TCP (신뢰성), UDP (속도 우선)

  ↓

인터넷 계층
 └ IP, ICMP, IGMP

소켓은 응용 프로그램이 TCP 또는 UDP 프로토콜을 사용할 수 있도록 API 형태로 제공되는 접점이다.즉, 소켓은 전송 계층(TCP/UDP) 위에 있고, 응용 계층(Web, Mail, Chat 등) 아래에 위치한다.

🎯 핵심 개념 요약

소켓은 데이터 자체를 전송하는 것이 아니라, 전송 계층 프로토콜에 접근하기 위한 인터페이스
응용 프로그램은 소켓을 통해 TCP나 UDP를 사용하며, 이와 별도로 IP 주소, 포트, 데이터 포맷 등을 지정
통신 상대방이 소켓이 아닌 다른 방식으로 TCP/IP 통신을 구현해도 상호 통신은 가능하다 (단, 프로토콜 포맷은 동일해야 함)

🧭 예외적 접근: 전송 계층 생략

전송 계층을 건너뛰고 **인터넷 계층(IP 계층)**을 직접 제어하는 방법도 존재한다. 예를 들어:

ICMP (Internet Control Message Protocol): ping, traceroute 명령에 사용
IGMP (Internet Group Management Protocol): 멀티캐스트 그룹 관리에 사용

이러한 방식은 일반적인 소켓 API가 아닌 **Raw Socket (원시 소켓)**을 통해 구현된다. 그러나 다음과 같은 한계가 있다:

구현 난이도 높음
관리자 권한 필요
실전에서 사용하는 경우는 드묾 (보안 솔루션, 라우팅 제어, 트래픽 분석 등 특수 목적)

📌 결론

소켓은 TCP/IP 통신의 “출입문”에 해당하며, 데이터 송수신이 아닌 접속, 바인딩, 송수신 요청 등을 위한 인터페이스
프로토콜에 따른 동작 방식은 내부적으로 TCP/UDP가 처리하고,
개발자는 소켓 함수를 통해 추상적으로 제어하면 됨

소켓은 네트워크 프로그래밍에서 매우 중요한 요소이며, **윈도우 소켓(Winsock)**과 리눅스 소켓은 공통된 구조를 기반으로 하면서도 각 운영체제의 특성에 따라 일부 차이를 보인다. 이 절에서는 특히 윈도우 소켓의 특징을 중심으로 구조를 설명하고, 리눅스와의 비교를 통해 개발자가 실무에서 어떤 점을 주의해야 하는지 정리해본다.

✅ 1. 소켓의 특징 (윈도우 기준)

📌 공통 기반: BSD UNIX 유닉스 소켓 모델

윈도우 소켓은 BSD UNIX 소켓 인터페이스에 기반
따라서 소스 코드 수준에서는 리눅스와 비교적 호환성이 높음
socket(), bind(), connect(), send(), recv() 등 기본 함수는 동일

📌 주요 차이점: 윈도우만의 구조와 요구사항

DLL 기반 인터페이스
- 윈도우 소켓은 대부분의 기능을 **DLL (Dynamic-Link Library)**로 제공
- 따라서 초기화(WSAStartup)와 종료(WSACleanup) 작업이 필수
- 리눅스에서는 이런 작업이 전혀 필요 없음
메시지 기반 GUI 구조
- 윈도우는 GUI 프로그램이 많은 환경을 고려하여,
- 비동기 통신을 메시지와 연계하는 함수들(ex: WSAAsyncSelect())을 제공
- 이는 윈도우 메시지 큐와 소켓 이벤트를 연결해 GUI가 멈추지 않고 동작할 수 있도록 한다
멀티스레드 지원 고려
- 윈도우는 운영체제 수준에서 멀티스레드 환경을 강력히 지원
- 따라서 소켓도 스레드 간 동기화 문제를 피할 수 있도록 별도의 보호 구조 필요
- WSA_FLAG_OVERLAPPED, CreateThread() 기반의 비동기 처리 구조 등이 사용됨
윈속 버전 의존성
- 윈도우는 버전에 따라 지원하는 Winsock 버전이 다르며, 개발자는 이를 고려해야 한다
- 예시:윈도우 버전 지원 Winsock 버전
  
  Windows 95 1.1 (업그레이드로 2.2 가능)
  
  Windows 98 이후 기본적으로 2.2 지원
- 리눅스(또는 유닉스)에는 버전 개념이 없으며, 시스템 호출만으로 바로 소켓 사용 가능

⚖️ 정리: 리눅스 소켓과 윈도우 소켓의 비교 요약

항목 리눅스 소켓 윈도우 소켓 (Winsock)

초기화 / 종료	필요 없음	WSAStartup(), WSACleanup() 필요
타입	int (파일 디스크립터)	SOCKET (별도 타입)
비동기 방식	select(), poll(), epoll() 등	WSAAsyncSelect(), WSAEventSelect() 등
멀티스레드	OS에서 기본 지원	스레드 안정성을 위한 추가 고려 필요
API 구조	시스템 콜에 가까움	DLL 기반의 API 함수 구조
버전 개념	없음	Winsock 1.1 / 2.2 구분됨

🧭 실무 팁

크로스 플랫폼 개발 시에는 #ifdef WIN32 등의 조건문을 사용하여 초기화 코드와 타입을 분리 설계
비동기 소켓 구현 시, 리눅스는 epoll, 윈도우는 WSAEventSelect 또는 IOCP 모델을 활용
콘솔 애플리케이션이 아닌 GUI 기반 앱을 만드는 경우, 윈도우 메시지 기반 소켓 이벤트 처리 방식을 고려해야 함

윈속(Winsock)은 Windows 환경에서 네트워크 프로그래밍을 위한 대표적인 인터페이스로, 초기 1.x 버전은 UNIX 소켓과의 호환성을 고려해 TCP/IP 중심의 구조로 설계되었고, 2.x 버전부터는 다양한 프로토콜을 포괄할 수 있도록 확장되었다. 이러한 발전 덕분에 윈도우 소켓은 오늘날 Bluetooth, IPv6 등 복합적인 네트워크 환경에서도 강력한 유연성을 제공한다.

✅ 윈도우 & 리눅스 공통 지원 프로토콜 (Windows 10 기준)

IPv4: 인터넷의 기본 주소 체계 (윈도우 95 이상)
IPv6: 확장된 주소 공간 및 향상된 기능 제공 (윈도우 XP SP1 이상)
Bluetooth: 근거리 무선 통신 (윈도우 XP SP2 이상)
IrDA (적외선 통신): 단거리 적외선 기반 데이터 전송 (윈도우 98 이상)

단, 최신 환경에서는 Bluetooth나 IrDA는 특수 목적 외에는 거의 사용되지 않으며, 주로 IPv4/IPv6 기반 TCP/IP 소켓이 실무의 중심이다.

🧩 소켓 프로그래밍의 장점

높은 이식성 (Cross-Platform Compatibility)
- 리눅스와 윈도우 모두 소켓 API 구조가 유사
- 대부분의 소스 코드를 플랫폼 간 쉽게 재사용 가능
범용성
- TCP/IP 뿐만 아니라 Bluetooth, IPv6 등 다양한 프로토콜을 동일한 소켓 API로 지원
- 프로토콜 변경 시 코드 수정 최소화 가능
저수준 접근 (Low-Level Control)
- 패킷 전송/수신 타이밍, 버퍼 크기, 오류 제어 등을 정밀하게 제어 가능
- 고성능 서버나 네트워크 툴 개발에 유리
응용 확장성
- 소켓 기반 위에 HTTP, FTP, MQTT 등 고수준 프로토콜을 직접 구현할 수 있음
- 필요한 기능만 구현하고 최적화할 수 있어 경량 시스템이나 커스터마이징에 유리

⚠️ 소켓 프로그래밍의 단점

응용 계층 프로토콜 직접 설계 필요
- 데이터의 구조, 순서, 흐름 제어, 예외 처리 등 모든 요소를 개발자가 직접 정의
- 예를 들어 “로그인 정보 → 결과 → 대기 → 수신” 등의 흐름을 직접 코딩해야 함
이기종 호스트 간 호환성 문제
- 서로 다른 바이트 순서(Byte Order) 사용 (리틀엔디안 vs 빅엔디안)
- 데이터 처리 단위(32비트, 64비트) 차이로 인해 전송 시 변환이 필요함
- 해결 방법: htonl(), ntohl(), memcpy() 등을 통한 명시적 정규화
프로토콜 변경 시 구조 전체 수정 필요
- 하나의 전송 흐름이나 메시지 포맷이 변경되면, 서버-클라이언트 코드 모두 수정 필요

예시: 설계 부담이 큰 경우

[보안 메시지 통신 요구 발생] → 기존 평문 전송 소켓 구조 파괴됨
→ 암호화/복호화 로직 추가 필요
→ 전송 실패 시 재시도 구조도 수정 필요
→ 코드 유지보수 복잡성 증가

이처럼 응용 프로토콜을 직접 구현하는 자유로움은 동시에 위험을 수반하며,

실제 제품 수준의 시스템에서는 이 점이 설계와 디버깅의 가장 큰 난관이 되기도 한다.

정리

장점 단점

다양한 플랫폼 및 프로토콜 지원	프로토콜 구조 직접 설계 필요
코드 재사용 및 이식 용이	데이터 호환성 수동 처리
고성능 최적화 가능	구조 변경 시 전면 재작업 필요
확장성 높음	설계 복잡성 증가

**윈도우 소켓 구조(Windows Socket Architecture)**는 다양한 버전과 프로토콜을 하나의 통일된 구조로 연결해주는 계층 기반 설계로, 개발자가 복잡한 프로토콜의 내부를 신경 쓰지 않고도 간단한 API 호출만으로 통신 기능을 사용할 수 있게 한다.

✅ 윈도우 소켓 구조 핵심 이해 (그림 1-14 기준)

[응용 프로그램]
    ↓
WSOCK32.DLL   ← (윈속 1.x API)
    ↓              ↘
   WS2_32.DLL      → MSWSOCK.DLL (확장 기능)
    ↓
[하부 프로토콜] → TCP/IP, Bluetooth, IrDA

📌 DLL 구성 요소 설명

1. WSOCK32.DLL

윈속 1.x 애플리케이션에서 사용
내부적으로 **WS2_32.DLL**을 호출하여 기능을 위임
레거시 시스템과의 호환성 유지용 (예: 오래된 네트워크 게임이나 도구)

2. WS2_32.DLL

윈속 2.x의 중심 DLL이자 표준 소켓 API 제공자
TCP, UDP, Bluetooth, IrDA 등 다양한 프로토콜 스택과 연결하는 중개자 역할
거의 모든 현대 윈도우 네트워크 프로그램은 이 DLL에 직접 연결됨

3. MSWSOCK.DLL

Microsoft에서 윈속 표준 외에 제공하는 확장 기능 집합
예: IOCP (입출력 완료 포트), 고급 비동기 처리, QoS(서비스 품질) 관련 기능
고성능 서버 프로그래밍이나 특수 목적의 커널-레벨 네트워크 처리에 활용됨

🧠 자동 프로토콜 연결 방식

응용 프로그램이 소켓을 생성할 때 AF_INET 또는 AF_BTH, SOCK_STREAM 등→ WS2_32.DLL이 자동으로 해당 프로토콜 드라이버(TCP/IP, Bluetooth 등)와 연결
→ 개발자는 실제 구현체에 신경 쓰지 않고 추상적으로 사용할 수 있음
사용하려는 프로토콜의 속성을 전달하면

💡 64비트 환경에서의 DLL 처리

64비트 윈도우는 32비트용과 64비트용 DLL을 분리해서 제공
- WS2_32.DLL (32bit) → SysWOW64\\
- WS2_32.DLL (64bit) → System32\\
운영체제는 응용 프로그램이 32비트인지 64비트인지 자동 판단하여
올바른 DLL을 로딩하므로 별도 설정 없이도 호환 가능

🎯 실무 적용 포인트

상황 처리 방식

구버전 프로그램 유지	WSOCK32.DLL 사용 (자동적으로 WS2_32.DLL 호출)
최신 API 또는 고성능 서버 구현	WS2_32.DLL 직접 호출 + 필요시 MSWSOCK.DLL 병행 사용
고급 비동기 처리	WSAEventSelect, WSAAsyncSelect, IOCP 사용 시 내부적으로 MSWSOCK.DLL 연동
Bluetooth/IrDA 통신	동일 소켓 인터페이스로 AF_BTH, AF_IRDA 사용 가능, 단 일부 프로토콜은 추가 라이브러리 필요

정리

윈속은 여러 버전의 API, 확장 기능, 다양한 프로토콜을 하나의 일관된 구조로 통합
소켓 생성 함수 한 줄이면, 내부적으로 수많은 연결을 자동 수행
**WS2_32.DLL**은 윈도우 네트워크 API의 실질적 핵심

이제부터 본격적인 소켓 프로그래밍의 세계로 들어간다. 이번 섹션은 윈도우 환경에서 TCP 서버 소켓 프로그램을 직접 작성하고 테스트하는 실습이다. 목표는 간단하다: 클라이언트가 전송한 데이터를 서버에서 받아 화면에 출력하는 기본 TCP 서버를 구현하고 텔넷으로 테스트해보는 것이다.

✅ 실습 목적 요약

TCP 기반의 서버 프로그램을 Visual Studio에서 작성
클라이언트의 메시지를 수신하고, 서버 콘솔에 그대로 출력
*텔넷(telnet)**을 클라이언트로 사용하여 테스트 가능
실습을 통해 Winsock 초기화, 소켓 생성, 바인딩, 리슨, 수신 흐름을 익힘

🧪 실습 환경 준비: Visual Studio 프로젝트 생성

① Visual Studio에서 새 프로젝트 만들기

메뉴 선택:
파일(File) → 새로 만들기(New) → 프로젝트(Project)
프로젝트 유형 선택:
- 검색창에 “콘솔” 입력
- 템플릿 목록에서 → Windows 데스크톱 마법사 선택
- [다음] 클릭

② 새 프로젝트 설정

이름(Name): Server
위치(Location): 원하는 경로 설정
솔루션 디렉터리 만들기: 체크 해제 가능 (개인 취향)
[만들기] 클릭

③ 프로젝트 옵션 설정 (윈도우 데스크톱 마법사)

응용 프로그램 종류: 콘솔 응용 프로그램
추가 옵션:
- 빈 프로젝트 선택 ✅
- 미리 컴파일된 헤더 비활성화 (선택 사항)

또는 이미 제공된 예제를 활용하려면:파일 → 열기 → 프로젝트/솔루션...Chapter01\Server\Server.sln 선택하여 열기

📁 결과 구조 예시

ProjectFolder/
│
├── Server.cpp         ← 여기에 코드 작성
├── Server.vcxproj     ← 프로젝트 설정 파일
└── Server.sln         ← 솔루션 파일

💬 다음 단계

이제 프로젝트 구조가 준비되었으므로, 다음 단계에서는 **Server.cpp**에 TCP 서버 소켓 코드를 직접 작성하게 된다. Winsock 초기화부터 socket(), bind(), listen(), accept() 그리고 **recv()**까지의 전형적인 구조를 실습하면서 기초적인 TCP 서버의 흐름과 코드 패턴을 몸에 익히는 것이 핵심이다.

이 단계에서는 Visual Studio 환경에서 실제로 "Server"라는 이름의 TCP 소켓 프로젝트를 구성하는 과정을 세부적으로 설정하고 있다. 이 설정은 실습의 기반을 다지는 중요한 부분이며, 특히 빈 프로젝트로 구성해야 예제 코드와의 충돌 없이 직접 작성한 소켓 코드를 온전히 반영할 수 있다.

✅ 실습 1-1: 소켓 서버 프로젝트 생성 절차 요약

① 프로젝트 이름 및 위치 지정

프로젝트 이름(Project Name): Server
위치(Location): 예를 들어 **C:\\Test**와 같이 실습용 폴더 지정
[솔루션 및 프로젝트를 같은 디렉터리에 배치] 체크
→ 이 설정은 프로젝트와 솔루션이 하나의 폴더 안에 깔끔하게 정리되도록 해줌
[만들기] 클릭

C:\\Test\\Server\\
├── Server.sln
├── Server.vcxproj
└── (코드 파일은 나중에 생성)

② 프로젝트 옵션 구성

애플리케이션 종류:
콘솔 애플리케이션 (.exe) → 터미널 기반 TCP 서버 실습에 적합
빈 프로젝트 (Empty Project): ✅ 체크
→ 자동 생성되는 **main()**이나 기타 예제 코드 없이 완전히 비어 있는 프로젝트로 시작 가능
미리 컴파일된 헤더 (Precompiled Header): 체크 해제 권장
→ pch.h, stdafx.h 등이 자동 생성되지 않아 코드 작성이 단순해짐

✅ 팁: 처음부터 빈 프로젝트로 시작하면 예제 코드 붙여넣기나 파일 연결이 쉬워지고,예제와 동일한 환경을 유지할 수 있음

🎯 이후 단계 안내

이제 프로젝트가 준비되었으니, 다음 단계는 다음과 같다:

Server.cpp 소스 파일 추가
- 프로젝트 > 추가 > 새 항목 > C++ 파일(.cpp) → 이름: Server.cpp
TCP 소켓 코드 입력
- **WSAStartup()**부터 socket(), bind(), listen(), accept() 등을 단계별로 구현
빌드 & 실행
- Ctrl + F5 또는 시작 버튼 클릭
클라이언트 접속 테스트
- Windows 명령 프롬프트에서 telnet 127.0.0.1 [서버 포트] 입력

📌 마무리 구조

C:\\Test\\Server\\
├── Server.sln               → 솔루션 파일
├── Server.vcxproj           → 프로젝트 파일
├── Server.cpp               → TCP 서버 소스 코드
└── (Debug/Release 폴더)     → 실행 파일 등

이제 소켓 서버 프로그램을 실제로 작성하고 실행할 준비가 완료되었다. 이 단계에서는 Visual Studio에서 소스 파일(Server.cpp)을 추가하고, 예제 코드를 붙여 넣은 뒤 프로그램을 빌드 및 실행한다. 또한, 소켓 통신을 위한 필수 라이브러리(ws2_32.lib) 링크 방법까지 포함되어 있어 실습 과정의 완결성이 확보된다.

✅ 실습 1-2: 소스 파일 추가 및 실행 절차 요약

① Server.cpp 소스 파일 추가

솔루션 탐색기에서 '소스 파일' 폴더 우클릭
→ [추가] → [새 항목...]
[새 항목 추가] 대화상자
- 항목 유형: C++ 파일 (.cpp)
- 이름: Server
- 경로는 기본값 (C:\\Test\\Server) 그대로
- [추가] 클릭
빈 파일이 열리면, Chapter01\\Server\\Server.cpp 예제 코드를 그대로 붙여 넣는다.

② 소켓 라이브러리 연결 방법

윈도우에서 소켓 프로그래밍을 할 경우, 필수적으로 ws2_32.lib 라이브러리를 링크해야 한다. 이 책에서는 코드 내부에 직접 링크 명령을 명시하는 방식을 사용한다:

#pragma comment(lib, "ws2_32")

이렇게 하면 Visual Studio의 프로젝트 속성에서 따로 수동으로 입력하지 않아도 자동으로 링크된다.

③ 프로그램 빌드 및 실행

빌드
- 메뉴: [빌드] → [솔루션 빌드] 또는 Ctrl + Shift + B
실행 (디버깅 없이 시작)
- 메뉴: [디버그] → [디버깅하지 않고 시작] 또는 Ctrl + F5
방화벽 경고 발생 시
- "Windows 보안 경고" 창이 나타날 수 있음
- 반드시 **[액세스 허용]**을 눌러야 클라이언트의 접속이 허용됨
- 특히 같은 PC에서 텔넷 테스트할 경우, 허용하지 않으면 접속이 차단됨

📌 경로 예시

C:\\Test\\Server\\
├── Server.cpp         ← 작성한 TCP 서버 코드
├── Server.vcxproj     ← Visual Studio 프로젝트
├── Server.sln         ← 솔루션 파일
└── Debug\\Server.exe   ← 빌드된 실행 파일

🧠 실무 팁

방화벽 허용 후 재시작 필요할 수도 있음 (특히 관리자 권한 없이 실행 시)
Debug 폴더 외에도 Release로 빌드해보며 실행 속도 차이도 비교 가능
이후 telnet 127.0.0.1 9000 (예: 서버 포트가 9000일 경우)으로 접속 테스트

정리

소스 파일 추가 → 코드 붙여넣기 → 빌드 → 실행 → 방화벽 허용 → 테스트
**#pragma comment(lib, "ws2_32")**는 소켓 프로젝트의 필수 요소
Visual Studio 환경에서는 GUI로도 프로젝트 관리가 용이

이 단계에서는 작성한 TCP 서버 프로그램이 실제로 잘 작동하는지 텔넷 클라이언트를 통해 통신 테스트를 진행한다. 이를 통해 TCP 서버가 정상적으로 클라이언트를 받아들이고, 메시지를 수신한 뒤 출력하는지 실시간으로 검증할 수 있다. 텔넷은 간단하지만 매우 강력한 네트워크 테스트 도구다.

✅ 실습 1-3: 텔넷 클라이언트를 이용한 TCP 서버 테스트

🖥️ ① 텔넷 클라이언트 실행

명령 프롬프트(cmd) 실행
아래 명령어 입력:

telnet 127.0.0.1 9000

**127.0.0.1**은 IPv4 루프백 주소, 동일 PC에서 서버 테스트 시 사용
**9000**은 서버가 바인딩한 포트 번호 (코드 내에서 설정한 값)

🔁 IPv6 환경이라면 telnet ::1 9000 도 가능

📤 ② 데이터 입력 및 서버 응답 확인

텔넷 창에서는 입력한 글자가 보이지 않는다 (기본 설정)
하지만, 서버 콘솔에서는 다음과 같이 입력한 내용이 실시간으로 출력된다:

[TCP 서버] 클라이언트 접속: IP 주소=127.0.0.1, 포트 번호=14209
안녕하세요.
반가워요.

클라이언트(텔넷)에서 입력한 모든 메시지가 서버 프로그램의 콘솔에 출력됨

🧨 ③ 클라이언트 종료 방법

텔넷 클라이언트에서 Ctrl + ] 입력 → Microsoft Telnet> 프롬프트 진입
그 후 quit 명령 입력 → 연결 종료

Microsoft Telnet> quit

서버 측에는 다음과 같은 메시지가 표시된다:

csharp
코드 복사
[TCP 서버] 클라이언트 종료: IP 주소=127.0.0.1, 포트 번호=14209

서버는 클라이언트의 종료를 감지하고, 연결 종료 시점에 IP와 포트 정보로 로그 출력함

⚠️ 주의사항: 텔넷 기능 활성화

윈도우 7/8.1/10/11은 텔넷 클라이언트가 기본적으로 비활성화되어 있다. 다음 절차로 활성화해야 사용 가능:

시작 메뉴에서 control 검색 → 제어판(Control Panel) 실행
[프로그램] → [Windows 기능 켜기/끄기]
텔넷 클라이언트 항목 체크 → [확인]
기능이 추가되면 telnet 명령이 정상 작동

🛠️ 또는 명령어로 활성화 가능:

dism /online /Enable-Feature /FeatureName:TelnetClient

✅ 테스트 구조 요약

[클라이언트] ← telnet 127.0.0.1 9000
   ⇅
[서버 콘솔]
 - 클라이언트 접속 IP/포트 출력
 - 수신 데이터 출력
 - 클라이언트 종료 시 로그 출력

정리

텔넷은 가장 기본적인 TCP 테스트 도구
입력한 데이터는 서버 콘솔에 출력됨 (텔넷 자체에는 표시 안 됨)
서버가 제대로 동작하는지 확인하는 간단하면서 강력한 방법
클라이언트 종료 및 서버 로그 확인으로 양방향 통신 흐름 전체를 점검 가능

이제는 윈도우에 이어 리눅스 환경에서 TCP 서버 소켓 프로그램을 빌드하고 테스트하는 실습 단계다. 리눅스에서는 Visual Studio 같은 통합 개발 환경 없이도 g++, make, telnet 만으로 간단하게 네트워크 프로그램을 구현하고 테스트할 수 있다.

✅ 실습 1-2: 리눅스에서 TCP 서버 소켓 프로그램 테스트하기

🧰 ① 컴파일러 및 Make 설치 확인

리눅스에서는 다음 두 도구가 반드시 필요하다:

g++: C++ 컴파일러
make: 자동 빌드 도구 (Makefile 기반)

터미널에서 아래 명령으로 설치 여부 확인:

g++ --version
make --version

설치 안 되어 있으면 Ubuntu 기준 아래 명령으로 설치:

sudo apt update
sudo apt install g++ make

📁 ② 예제 코드 위치로 이동하고 빌드

본문의 예제 코드가 들어 있는 경로로 이동:

cd ~/Source/Linux/Chapter01

**Makefile**이 있는 디렉토리에서 빌드:

make

출력 예시:

g++ --Wall Server.cpp -lpthread -o Server

**lpthread**는 멀티스레드 기능을 위한 링커 옵션
결과 파일 **./Server**가 생성됨

▶️ ③ 서버 프로그램 실행

./Server

이제 서버는 9000번 포트에서 클라이언트 접속을 기다림

(이 포트는 코드 내에서 bind() 시 설정된 값)

💬 ④ 클라이언트 접속 (텔넷 사용)

다른 터미널을 열고 텔넷으로 서버에 접속:

telnet ::1 9000

**::1**은 IPv6 루프백 주소 (같은 컴퓨터 내에서 테스트할 때 사용)
IPv4라면 **127.0.0.1**로 접속 가능

입력 예시:

Hello.
Nice to meet you.

서버 콘솔에는 다음과 같은 로그가 출력됨:

[TCP 서버] 클라이언트 접속: IP 주소=::1, 포트 번호=XXXXX
Hello.
Nice to meet you.
[TCP 서버] 클라이언트 종료: IP 주소=::1, 포트 번호=XXXXX

🧨 클라이언트 종료 방법

텔넷 환경에서는 Ctrl + ] 입력 후, 아래처럼 종료:

telnet> quit

⚠️ 유의사항

한글 입력 시 출력이 깨질 수 있음→ 테스트는 영문으로 진행 권장
→ UTF-8 인코딩 문제 또는 서버 코드 상 char 처리 방식 차이 때문
서버를 외부에서 접속 테스트하려면:
- 방화벽에서 포트 허용 필요
- ::1 대신 실제 IP 주소 사용

📌 테스트 흐름 요약

[터미널 1] → ./Server           ← 서버 실행
[터미널 2] → telnet ::1 9000    ← 클라이언트 접속
  ↳ 텍스트 입력 → 서버에 출력
  ↳ Ctrl + ] → quit → 종료

이제부터는 **코딩 스타일(Coding Style)**에 대한 가이드라인이다. 실무에서는 **정확한 구현 못지않게 코드의 "가독성과 유지보수성"**이 중요하며, 특히 C/C++에서는 스타일에 따라 개발 효율과 협업 수준이 극명하게 갈릴 수 있다. 본문에서 사용하는 예제는 다음과 같은 현대적이고 실용적인 코딩 스타일을 지향한다.

✅ 주요 코딩 스타일 특징 요약

① 필요한 곳에서 바로 변수 선언

전통적인 C 스타일에서는 변수 선언을 함수 맨 앞에서 몰아서 처리했지만,

현대적인 C++ 스타일에서는 사용할 위치에서 바로 선언한다.


for (int i = 0; i < 100; i++) {
    // 변수 i는 이 범위 안에서만 사용됨 → 코드 흐름 명확
}

✅ 장점:변수 범위(Scope)가 명확해져 버그 발생률 감소타입 추적을 위해 코드 상단으로 다시 올라갈 필요 없음순차적 코드 읽기가 쉬움 → 특히 디버깅이나 코드 리뷰 시 유리

② 한 줄 오류 처리 패턴

코드가 복잡해지지 않도록, 오류가 발생했을 때 한 줄로 처리하는 스타일을 채택:

if (listen_sock == INVALID_SOCKET) err_quit("socket()");
if (retval == SOCKET_ERROR) err_quit("bind()");

✅ 장점:오류 처리 로직이 핵심 코드 흐름을 방해하지 않음에러 메시지와 조건이 시각적으로 밀접하게 배치의도 명확, 간결, 가독성 향상

③ 명확한 함수 단위 병렬 처리

멀티스레드 실행 구조도 깔끔하게 표현:

HANDLE hThread[2];
hThread[0] = CreateThread(NULL, 0, TCPServer4, NULL, 0, NULL);
hThread[1] = CreateThread(NULL, 0, TCPServer6, NULL, 0, NULL);
WaitForMultipleObjects(2, hThread, TRUE, INFINITE);

각 스레드는 명시적인 이름을 가진 함수(TCPServer4, TCPServer6)를 실행
명확한 스레드 분리와 처리 순서, 직관적으로 드러남

✍️ 스타일 철학: 간결하지만 명확하게

변수는 "필요할 때 선언"
조건문/함수 호출은 "한 줄로 요약"
코드보다 로직에 집중할 수 있는 환경 만들기

이러한 스타일은 초보자에게도 가독성이 높고,

팀 프로젝트에서도 일관성 있게 유지되기 때문에 권장할 만하다.

예시 코드 단편 비교

❌ 전통적 스타일

int retval;
SOCKET s;
s = socket(...);
if (s == INVALID_SOCKET) {
    printf("socket error\\n");
    exit(1);
}

✅ 본문 스타일

SOCKET s = socket(...);
if (s == INVALID_SOCKET) err_quit("socket()");

📌 정리

항목 설명 장점

지역 선언	변수는 사용할 시점에 선언	가독성, 디버깅 용이
한 줄 처리	오류 체크 + 메시지 출력	간결함, 로직 흐름 유지
스레드 명시 처리	함수 단위로 스레드 할당	병렬처리 구조 명확

지금까지 학습한 Chapter 01의 핵심 내용을 요약하면, 네트워크 프로그래밍의 전체 구조와 흐름이 뼈대처럼 정리된다. 아래 내용은 본격적인 소켓 코드 구현 전에 반드시 이해하고 있어야 하는 기초 개념 요약 정리이며, 각 계층 및 주소 개념이 어떻게 맞물리는지를 명확히 보여준다.

📌 Chapter 01 요약: 네트워크와 소켓 프로그래밍 핵심 정리

✅ 01. 인터넷 통신 개체

통신 주체는 두 가지로 구분됨:
- 호스트(Host): 최종 사용자 프로그램을 수행 (PC, 서버, 스마트폰 등)
- 라우터(Router): 데이터 전달 중계 (경로 결정)

✅ 02. TCP/IP 프로토콜 구조

계층 역할 주소 체계

네트워크 접근 계층	실제 물리 네트워크 상의 송수신 처리, 물리적 주소(MAC) 사용	MAC 주소
인터넷 계층	데이터 라우팅, 목적지 결정, IP 주소 사용	IP 주소
전송 계층	최종 통신 대상 식별, 신뢰성 확보, 포트 번호 사용	포트 번호
응용 계층	사용자 프로그램, 프로토콜 집합(HTTP, FTP 등) 포함	없음 (논리 계층)

✅ 03. TCP vs UDP 차이점

항목 TCP UDP

연결 여부	연결형 (Connection-Oriented)	비연결형 (Connectionless)
신뢰성	보장됨 (재전송, 순서 보장)	신뢰성 없음 (재전송 없음)
데이터 단위	바이트 스트림 (연결된 흐름)	데이터그램 (단위별 전송)
통신 방식	일대일 통신	일대일, 일대다 통신도 가능
대표 사용처	HTTP, FTP, 이메일 등	VoIP, 스트리밍, DNS 등

✅ 04. IP 주소 (인터넷 계층)

네트워크 상에서 개체를 유일하게 식별
버전 구분:
- IPv4: 32비트 (예: 192.168.0.1)
- IPv6: 128비트 (예: 2001:0db8::1)
주의: 물리적 주소(MAC)와 다름

✅ 05. 포트 번호 (전송 계층)

통신의 종착점 = 응용 프로그램 단위 식별
16비트 정수 (0 ~ 65535)
- 0~1023: 예약된 포트 (Well-known)
- 1024~49151: 등록 포트 (Registered)
- 49152~65535: 동적/사설 포트 (Dynamic)

✅ 06. 루프백 주소 (Loopback Address)

자기 자신에게 보내는 네트워크 주소
테스트용으로 매우 유용함

버전 주소 형태 별칭

IPv4	127.0.0.1	localhost
IPv6	::1	(동일 역할)

🧭 전체 네트워크 흐름 요약

[응용 프로그램]
    ↓
[소켓 인터페이스]
    ↓
[TCP/UDP (전송 계층)] ← 포트 번호 사용
    ↓
[IP (인터넷 계층)]     ← IP 주소 사용
    ↓
[이더넷 (접근 계층)]    ← MAC 주소 사용

이 파트는 Chapter 01 전체의 마지막 요약 단계로, 클라이언트-서버 모델 구조, 소켓의 개념, 운영체제별 소켓 응용 구조 차이까지 정리된다. 이 정리는 이후 소켓 프로그래밍을 실제로 설계하고 구현할 때의 사고 뼈대가 된다. 핵심 포인트를 빠짐없이 재구성해서 아래와 같이 요약할 수 있다.

📌 Chapter 01 핵심 요약 (계속)

✅ 07. 클라이언트-서버 모델

네트워크 프로그램은 일반적으로 클라이언트-서버 모델 기반
역할 구분:
- 클라이언트(Client): 서비스 요청자
- 서버(Server): 서비스 제공자

[클라이언트] → 요청 (Request)
[서버]       ← 응답 (Response)

특징:
- 서버는 항상 대기 상태, 클라이언트는 필요 시 연결
- 서버는 클라이언트의 IP/포트 정보를 이용해 응답 가능
- 동시 접속 허용 구조(멀티스레드, select 등) 필요

✅ 08. 소켓의 개념

소켓은 두 가지 측면에서 정의할 수 있다:

관점 설명

통신 종단점	데이터를 주고받는 시작과 끝 지점 (End-point)
프로그래밍 인터페이스	TCP/UDP에 접근하기 위한 API 구조

내부적으로는 소켓이 IP 주소 + 포트 번호 + 프로토콜 정보를 보유
응용 프로그램은 소켓을 통해 하위 계층(IP, MAC, 라우팅 등)을 직접 다룰 필요 없이 간접적으로 통신

✅ 09. 운영체제별 소켓 응용 구조

OS 링크 방식 및 구조

Windows	WS2_32.DLL 사용 (Winsock 2.x) → 반드시 WS2_32.LIB 링크 필요
Linux	별도 라이브러리 필요 없음 (socket()은 시스템 콜)

// Windows 코드 예시
#pragma comment(lib, "ws2_32")

WSAStartup(...);
SOCKET s = socket(AF_INET, SOCK_STREAM, 0);

// Linux 코드 예시
int s = socket(AF_INET, SOCK_STREAM, 0);

윈도우는 소켓 사용 전 초기화/정리 작업 필수
리눅스는 단순하게 시스템 호출 형태로 소켓 사용 가능

📚 전체 흐름 요약 다이어그램

[클라이언트 프로그램]
  ↓ (소켓 생성)
[클라이언트 소켓]  ←→  [서버 소켓]
                       ↑
                  [서버 프로그램]

양측 소켓은 TCP/UDP를 통해 연결되며,
실제 데이터는 IP와 MAC 주소 기반으로 전송됨

마무리 포인트

개념 핵심 키워드 역할

클라이언트-서버	요청, 응답	구조 설계 기반
소켓	종단점, 인터페이스	프로그래밍 접점
운영체제	WS2_32 vs 시스템 콜	플랫폼 차이 인식

아래는 연습문제 07~09에 대한 기술적이고 실무 중심의 해설이다. 각 문항은 단순 암기보다 원리 이해 및 실무 활용 가능성에 중점을 두고 풀이되었다.

✅ 07. 다음의 TCP/IP와 연관된 프로토콜의 역할과 특징을 기술하시오.

🔹 ARP (Address Resolution Protocol)

역할: IP 주소에 해당하는 MAC 주소(물리 주소)를 찾기 위한 프로토콜
계층: 네트워크 접근 계층과 인터넷 계층 사이의 브릿지 역할
작동 방식:
1. IP 주소만 알고 있을 때 ARP 요청 브로드캐스트 전송
2. 해당 IP를 가진 장비가 MAC 주소와 함께 ARP 응답 전송
특징:
- LAN 내 통신에서만 사용 (라우터를 넘지 않음)
- 캐시 유지 (ARP 캐시), 보안상 위조(ARP Spoofing)에 취약

🔹 ICMP (Internet Control Message Protocol)

역할: 네트워크 상태 알림 및 오류 메시지 전송
계층: 인터넷 계층 (IP와 함께 동작)
사용 예시:
- ping: 목적지까지 연결 가능 여부 확인 (ICMP Echo Request/Reply)
- tracert(Windows), traceroute(Linux): 경로 추적
특징:
- 신뢰성 없는 정보 전달 (TCP처럼 재전송 없음)
- 보안상 공격 대상이 되기도 함 (ex. Ping of Death)

🔹 IGMP (Internet Group Management Protocol)

역할: 멀티캐스트 그룹 관리 프로토콜
계층: 인터넷 계층
사용 예시:
- 한 송신자가 다수 수신자에게 동일한 데이터를 보낼 때 (예: 스트리밍)
- 호스트가 특정 멀티캐스트 그룹에 가입하거나 탈퇴
특징:
- IPv4 전용 (IPv6에서는 MLD로 대체)
- 라우터는 IGMP 정보를 바탕으로 멀티캐스트 트래픽 전달 결정

✅ 08. 텔넷 프로토콜의 문제점을 보안(Security) 관점에서 설명하시오.

🔒 텔넷의 보안 문제점

모든 데이터가 평문(Plain Text) 전송
- 사용자 ID, 비밀번호, 명령어, 응답 결과가 암호화되지 않음
- 네트워크 상에서 **스니핑(sniffing)**에 매우 취약
MITM(중간자 공격)에 노출
- 클라이언트와 서버 사이 통신을 가로채어 명령어 조작 가능
접속 인증 체계가 약함
- 대부분 기본 인증만 제공, 추가 인증 수단 없음 (예: 2FA, 공개키 없음)
대체 기술: SSH
- 암호화된 터미널 접속 프로토콜
- 대칭키/비대칭키 기반, 다양한 인증 방식, 세션 보호 가능

📌 결론: 텔넷은 테스트용으로만 사용하고, 실운영 환경에서는 사용하지 않는 것이 원칙이다.

✅ 09. 윈도우 또는 리눅스에서 daytime 서버(포트 13)를 활성화하는 절차를 설명하시오.

🖥️ Windows에서 daytime 서버 활성화 (예: Windows 10/11)

Telnet Server, Simple TCP/IP 서비스 설치
- 제어판 > [프로그램 및 기능] > [Windows 기능 켜기/끄기]
- "Simple TCP/IP Services (i.e. echo, daytime etc)" 체크
- 확인 → 설치 완료 후 재부팅
Windows Defender 방화벽 설정
- 포트 13 허용 규칙 추가 또는 daytime 앱 예외 설정
서비스 상태 확인
- 명령 프롬프트에서 테스트:
- bash 코드 복사 telnet 127.0.0.1 13

🐧 Linux (inetd 또는 xinetd 사용 시)

inetd 또는 xinetd 설치
bash 코드 복사 sudo apt install inetutils-inetd

/etc/inetd.conf에 설정 추가

daytime stream tcp nowait root internal
daytime dgram udp wait root internal

또는 /etc/xinetd.d/daytime 생성
서비스 재시작
bash 코드 복사 sudo service inetd restart
테스트
bash 코드 복사 telnet 127.0.0.1 13 또는 telnet ::1 13

✅ daytime 서버는 클라이언트가 접속하면 날짜+시간을 전송한 뒤 바로 연결 종료한다.

🔚 전체 정리표

번호 항목 핵심 포인트

07	ARP/ICMP/IGMP	주소 해석, 오류 알림, 멀티캐스트
08	텔넷 보안 문제	암호화 없음, 스니핑/MITM 취약
09	Daytime 서버	포트 13, 재부팅 후 동작, telnet 테스트 가능

아래는 연습문제 01~06에 대한 전문적인 해설이다. 각 문항은 이론+실습+실무 응용을 조합하여 구성했으며, TCP/IP 기반 네트워크 프로그래밍의 기초 이론을 견고하게 다질 수 있는 내용이다.

✅ 01. 이더넷의 48비트 물리 주소 구조와 내 PC의 MAC 주소 분석

📌 이더넷 48비트 주소(MAC 주소) 구조

총 48비트 (6바이트) = OO:OO:OO:UU:UU:UU
- OUI(Organizationally Unique Identifier): 앞의 3바이트 → 제조사 식별
- NIC Specific: 뒤의 3바이트 → 제조사 고유 일련번호

구분 비트 수 설명

OUI	24비트	제조사 ID (예: Intel, Realtek)
NIC	24비트	장치 고유 번호

📌 MAC 주소 확인

Windows:
ipconfig /all
Linux/macOS:
ifconfig 또는 ip link

예시:

물리적 주소(MAC) = 08-00-27-4A-BC-D1
→ OUI = 08-00-27 (VirtualBox)

✅ 02. OSI 7계층과 TCP/IP 비교

OSI 계층 역할 설명 TCP/IP 계층 대응

7. 응용계층 (Application)	사용자 인터페이스 제공	응용 계층
6. 표현계층 (Presentation)	인코딩/암호화	포함되지 않음 (응용에 포함)
5. 세션계층 (Session)	연결/세션 관리	포함되지 않음 (응용에 포함)
4. 전송계층 (Transport)	포트/신뢰성 전송	전송 계층 (TCP, UDP)
3. 네트워크계층 (Network)	IP 주소/라우팅	인터넷 계층 (IP)
2. 데이터링크계층 (Data Link)	MAC 주소/프레임	네트워크 접근 계층
1. 물리계층 (Physical)	전기/광 신호 전송	네트워크 접근 계층

✅ TCP/IP는 4계층 모델로 OSI 7계층을 통합적으로 다룸

✅ 03. 네트워크 장치 기능

장치 기능

리피터 (Repeater)	신호를 단순 증폭하여 전송 거리 연장
브리지 (Bridge)	MAC 주소 기반으로 트래픽 분할
허브 (Hub)	단순 신호 분배기, 모든 포트로 트래픽 전파
라우터 (Router)	서로 다른 네트워크(IP) 간 데이터 라우팅
IP 공유기 (Sharing Device)	NAT 기능 포함, 내부 네트워크와 외부 인터넷 중계

✅ 리피터/허브는 1~2계층, 브리지는 2계층, 라우터는 3계층 장비

✅ 04. RFC란 무엇이며 주요 프로토콜 RFC 번호

🔍 RFC (Request for Comments)

인터넷 기술의 공식 표준 문서
IETF에서 관리, 공개적으로 열람 가능

🌐 공식 사이트

https://www.rfc-editor.org/

주요 RFC 번호

프로토콜 RFC 번호

IPv4	RFC 791
IPv6	RFC 8200
TCP	RFC 793
UDP	RFC 768
HTTP/1.1	RFC 2616
HTTP/2	RFC 7540

✅ 05. IPv4 주소의 구조 및 종류

📌 비트 구조

총 32비트 = 네트워크 주소 + 호스트 주소
기본 4옥텟 형태 (192.168.0.1)

📌 용도별 분류

유형 역할

유니캐스트	특정 한 대상에게만 전송 (일대일)
멀티캐스트	특정 그룹에 속한 다수에게 전송
브로드캐스트	같은 네트워크 내 모든 장치에 전송

✅ 06. IPv6 주소의 구조 및 종류