소강좌제목 : 컴퓨터 네트웍 프로그래밍 다음강좌: 제2장 UNIX BSD 소켓 시스템 콜
제1장 네트웍 프로그래밍의 이해
1장에서는 네트웍 프로그래밍의 일반적인 특징을 소개한다. 먼저 1.1절에서는 네트웍 프로그래밍의 계층별 종류와 각각의 특징을 소개한다. 1.2절에서 소켓 (socket) 인터페이스를 지원하는 대표적인 통신 프로토콜인 TCP/IP(Transmission Control Protocol/Internet Protocol)에 대하여 설명하고 1.3절에서는 클라이언트-서버 통신 모델에 대하여 설명한다.
1.1 네트웍 프로그래밍의 분류
▶ 네트웍 프로그램 작성에는 여러 가지의 레벨이 있을 수 있는데, 통신 장비(device)를 직접 구동하는 디바이스 드라이버형 프로그램, TCP와 같은 트랜스포트 계층의 인터페이스를 이용하는 소켓 프로그래밍, 그리고 응용 계층을 이용하는 응용 계층 프로그램등 크게 세 가지로 구분할 수 있다.
▶ 예를들어 LAN에서 인터넷을 사용하는 경우에 이들의 관계를 그림 1-1에 나타냈다.
그림 1-1 네트웍 프로그래밍의 계층별 분류
1.1.1 응용 계층 프로그래밍
▶ 응용 계층 프로그래밍은 컴퓨터 시스템이 지원하는 네트웍 유틸리티나 응용 프로그램을 활용하는 방식으로, 가장 상위 계층의 프로그래밍 인터페이스를 제공한다.
▶ 응용 계층을 이용한 프로그래밍은 원격 작업을 편리하게 처리하기에는 적합하나 네트웍의 하위 계층의 동작을 구체적으로 제어할 수 없다는 단점이 있다.
▶ 웹(web)에서 사용되고 있는 http(hypertext transfer protocol)를 이용하는 HTML(Hyper Text Markup Language) 문서 작성도 여기에 해당한다.
1.1.2 트랜스포트 계층 프로그래밍
▶ 트랜스포트 계층을 이용하는 것으로서 호스트 종점간의 연결을 직접 관리하고 패킷 단위의 데이터 송수신을 구체적으로 제어할 수 있다.
▶ 트랜스포트 계층 프로그래밍의 대표적인 것이 소켓(Socket) API(Application Program Interface)를 이용하는 것이다.
▶ 소켓 API의 종류는 운영체제에 따라 UNIX BSD(Berkeley Software Distribution) socket(1982년), 윈도우 소켓(Winsock, 1992년) 등이 있다.
▶ 소켓 인터페이스는 UNIX BSD에서 처음으로 보급되기 시작하였으나 현재는 컴퓨터 기종 및 운영체제에 무관하게 대부분의 컴퓨터에서 지원되고 있으며 특히 TCP/IP를 제공하는 컴퓨터에서는 기본적으로 지원되고 있다.
1.1.3 디바이스 드라이버 계층 프로그래밍
▶ 디바이스 드라이버 계층 프로그래밍은 OSI(Open System Interconnection)의 계층 2 이하의 인터페이스, 즉 링크 계층이나 하드웨어 디바이스를 구동하여 프레임 단위의 데이터 송수신을 직접 다루는 프로그래밍을 말한다.
▶ 드라이버 계층 프로그래밍을 위한 대표적인 API는 LAN에서 MAC(Medium Access Control) 프레임 단위의 송수신을 다루는 API로 FTP사의 패킷 드라이버(Packet Driver), 마이크로소프트사의 NDIS(Network Driver Interface Specification), 노벨사의 ODI(Open Data Interface) 등이 있다.
▶ 이러한 API들을 사용하면 LAN의 종류(즉, MAC 프로토콜 종류)와 LAN 카드 제조회사에 무관하게 드라이버 계층의 네트웍 프로그램을 작성할 수 있다.
▶ 드라이버 계층의 프로그래밍은 프레임의 구체적인 송수신을 제어하거나 네트웍의 상태를 모니터링하는 경우, 또는 TCP/IP가 아닌 임의의 '사용자 정의'의 상위 프로토콜을 지원해야 하는 경우 등에 사용된다.
▶ 그러나 이 방식은 프레임을 전송 또는 수신하는 단순한 기능만 제공하므로 흐름제어, 오류제어, IP 주소 관리와 같은 기능은 사용자가 별도로 구현하여야 한다.
▶ 세 가지 종류의 네트웍 프로그래밍의 특징을 표 1-1에 비교하였다.
계 층
종 류
특 징
응용계층
http, ftp, mail,rsh, rcp, RPC - 이미 작성된 유틸리티나 응용 프로그램을 활용 - 효율은 떨어질 수 있으나 프로그램 작성, 변경, 운영이 쉬움.
트랜스 포트 계층
socket, Winsock,TLI - 패킷 단위의 데이터 송수신을 처리함. - 인터넷(TCP/IP) 프로그램에서 가장 많이 사용됨.
- 소켓 API가 운영체제마다 유사하여 프로그램 호환성이 좋음.
디바이스 드라이버 계층
Packet Driver,NDIS, ODI - LAN에서 MAC 프레임 단위의 전송을 처리함. - 다양한 MAC 프로토콜에서 사용할 수 있음.
- 흐름제어, 오류제어 등은 사용자가 작성해야 함
표 1-1 네트웍 프로그래밍의 계층별 분류와 특징
1.2 TCP/IP 프로토콜
1.2.1 개요
▶ 최초의 패킷 데이터 통신망은 미국의 국방성에서 1968년에 구축한 ARPANET이라고 할 수 있다.
▶ ARPANET을 구축하여 실제로 여러 컴퓨터들을 연결하는 데 있어 가장 큰 문제가 된 것은, 여러가지 서브네트웍(LAN, 패킷교환망, 위성망 등)을 통과하여 종점 호스트들을 상호 연결하기 위한 트랜스포트 계층 프로토콜이 당시에는 표준화되어 있지 않았다는 것이다.
▶ ARPANET에서 임의의 서브네트웍을 통해 접속된 장비들의 종점간 연결과 라우팅을 제공하기 위하여 미국 국방성에서 제정한 프로토콜이 TCP/IP 프로토콜이다.
▶ TCP/IP 프로토콜을 구성하는 주요 두 프로토콜은 IP와 TCP이다.
▶ TCP/IP 프로토콜이라고 하면 TCP와 IP 두 프로토콜만을 지칭하는 것이 아니라 UDP(User Datagram Protocol), ICMP(Internet Control Message Protocol), ARP(Address Resolution Protocol), RARP(Reverse ARP) 등 관련된 프로토콜을 통칭하는 것이다.
▶ 1993년 이후에는 TCP/IP에 기반한 WWW(World Wide Web) 서비스가 폭발적으로 확산되면서 TCP/IP는 이제 컴퓨터 통신망의 실질적인 표준이 되어 있다.
▶ TCP/IP 프로토콜은 네트웍액세스 계층, 인터넷 계층, 트랜스포트 계층, 응용 계층의 4개의 계층으로 구성되어 있다.
▶ TCP/IP를 OSI 7-계층과 비교하면 그림 1-2와 같고, TCP/IP 각 계층의 내부 프로토콜은 그림 1-3에 나타냈다.
그림 1-2 TCP/IP와 OSI 7 계층 프로토콜 구조의 비교
▶ 네트웍 액세스 계층은 IP 패킷의 물리적인 전달을 담당하는 서브네트웍 기능을 제공하며 dial-up 회선, LAN, X.25 패킷망 등이 여기에 해당된다.
▶ 인터넷 계층은 비연결형 서비스 즉, 데이터그램 방식으로 호스트 사이에 IP 패킷을 전달하는 기능과 라우팅 등을 수행한다.
▶ 트랜스포트 계층은 호스트 사이의 종점간 연결을 제공하고 종점간의 데이터 전달을 처리한다.
▶ 트랜스포트 프로토콜에는 TCP와 UDP 두 개의 프로토콜이 있다.
그림1-3 TCP/IP 내부의 계층별 프로토콜
▶ TCP는 신뢰성 있는, 즉 재전송에 의한 오류제어와 흐름제어를 하는 스트림(stream) 형태의 연결형 서비스를 제공한다.
▶ UDP는 재전송이나 흐름제어가 없는 비연결형 서비스를 제공한다.
▶ 응용 계층은 TCP/IP 프로토콜을 이용하는 응용 서비스로서 TCP 또는 UDP가 지원하는 응용으로 각각 구분할 수 있다.
▶ 표 1-2에 TCP 또는 UDP 그리고 TCP와 UDP 두 가지 모두가 지원하는 대표적인 응용 계층 서비스를 나타냈다 (/etc/services).
트랜스포트 프로토콜 응용 계층 서비스
TCP
- File Transfer Protocol(FTP) - TELNET
- Simple Mail Transfer Protocol (SMTP)
- Hyper Text Transport Protocol (HTTP)
UDP
- Network File System(NFS) - Trivial FTP(TFTP)
TCP, UDP (모두 지원)
- Echo - Daytime
- Time
표 1-2 TCP와 UDP가 지원하는 응용 계층 서비스
1.2.2 네트웍 액세스 계층
▶ 네트웍 액세스 계층으로는 dial-up회선, LAN, X.25 패킷망, 위선통신 회선 등 모든 종류의 서브네트웍이 사용될 수 있다.
▶ CSMA/CD(Carrier Sense Multiple Access/Collision Detection) MAC 프로토콜을 사용하는 이더넷은 Xerox사에서 처음 제안하였으며 Xerox, Intel, Digital (DIX) 3사가 1978년 공동 표준으로 채택하였다.
▶ 한편 1980년대 초 미국 전기·전자공학회, IEEE(Institute of Electrical and Electronics Engineering)에서 이더넷 프로토콜을 약간 변형하여 IEEE 802.3 MAC 표준을 정하였다.
▶ Preamble(8바이트)은 수신측에서 동기를 맞추기 위한 준비 신호이며 1과 0의 반복으로 되어 있다.
▶ Preamble의 끝을 알리기 위하여 Preamble의 8번째 바이트는 10101011으로 되어 있다.
▶ DA와 SA는 각각 6바이트로 된 수신지 및 송신지의 MAC 주소인데 MAC 주소는 범세계적으로 유일하게(unique) 지정되는, 일종의 물리적인 고유번호라 할 수 있다
▶ 그림 1-4에서 Type 필드는 상위 계층의 프로토콜을 구분한다. 예를들어 Type이 0x0800이면 상위 계층이 IP 프로토콜이고, 0x0806이면 ARP 프로토콜임을 나타낸다.
그림 1-4 이더넷 프레임 구조
▶ 그림 1-5의 MAC 주소에서 처음의 두 비트는 항상 0이고, 그 다음 22비트는 IEEE에서 기관(예: LAN 카드 제조 회사)별로 할당한 주소이며, 뒤의 24비트는 LAN 카드마다 유일하게 생산자가 부여하는 번호이다.
그림 1-5 MAC 주소 구조(48비트)
▶ Info는 상위 계층의 사용자 정보를 말한다(예: IP 패킷).
▶ 이더넷 MAC 프레임에서 Type 필드를 사용하여 상위 계층 프로토콜을 바로 구분할 수 있는 것과 달리, IEEE 802.3 MAC 표준에서는 이 필드를 Type 대신 Info의 크기를 나타내는 Length 필드로 사용하고 있다.
▶ IEEE 802.3에서는 상위 계층에 전달할 프로토콜을 구분하기 위하여 Info 필드에 실려 있는 LLC(Logical Link Control) 프레임 헤더 중 일부 필드를 사용하고 있다.
1.2.3 인터넷 계층
▶ 인터넷 계층은 인터넷 프로토콜(IP: Internet Protocol)을 처리하는 계층이다.
▶ 인터넷 계층은 서브네트웍에 무관하게 데이터그램 패킷을 임의의 호스트 사이에 주고받기 위한 프로토콜로 OSI의 네트웍 계층에 해당하는 기능을 수행한다.
▶ 패킷교환 표준인 X.25 프로토콜과 IP 프로토콜의 가장 큰 차이점은, X.25는 연결형 서비스(가상회선)와 비연결형 서비스(데이터그램)를 모두 지원하지만 IP는 비연결형 서비스만 지원한다는 것이다.
▶ 모든 IP 패킷은 송신지와 수신지의 주소로서, 각각 32 비트의 IP 주소를 항상 포함하고 있어야 하며 전송 효율이 그만큼 떨어지게 된다.
▶ 인터넷 계층 프로토콜의 핵심은 바로 이 32비트의 IP 주소(이를 인터넷 주소라고도 한다)의 사용인데, IP 주소는 인터넷에 접속된 모든 호스트에 대하여 전세계적으로 유일하게 배정되는 주소이다.
(1) IP 주소(IP address)
▶ 인터넷(Internet)을 달리 표현하면 "IP 프로토콜을 사용하는 모든 장비(라우터 및 호스트)들의 집합"이라고도 할 수 있다.
▶ 32비트의 IP 주소를 보기 쉽게 표시하기 위하여, 네 바이트 단위로 나누고 이를 10진수로 표시하는 dotted decimal 표현 방식이 널리 사용되고 있다.
▶ 예를들면 32비트 IP 주소 10000001 00001010 0000110 0000111를 dotted decimal IP 주소로 표현하면 129.10.6.7이 된다.
▶ IP 주소는 네트웍을 구분하기 위한 netid 필드와 한 네트웍내에서 호스트를 구분하기 위한 hostid 필드 두 부분으로 구성된다.
그림 1-6 IP 주소의 종류
▶ 각 필드에서 사용하는 비트 수의 크기에 따라 그림 1-6과 같이 네 가지 클래스로 구분된다.
1) 클래스 A 주소 : 첫번째 바이트의 첫 비트가 0
첫 바이트의 나머지 7비트가 netid이고, 뒤의 세 바이트가 hostid이며 한 네트웍이 약 224대의 호스트를 수용할 수 있다.
2) 클래스 B 주소 : 첫번째 바이트의 처음 두 비트가 10
첫번째 바이트의 나머지 6비트와 두번째 바이트가netid이고 뒤의 두 바이트가 hostid이며 한 네트웍이 약 216대의 호스트를 수용할 수 있다.
3) 클래스 C 주소 : 첫번째 바이트의 처음 세 비트가 110
세번째 바이트까지가 netid이고 마지막 한 바이트가hostid이며 한 네트웍이 254대까지 수용한다
4) 클래스 D 주소 : 첫번째 바이트의 처음 네 비트가 1110
멀티캐스트 주소로 사용된다. 목적지 주소가 D 클래스인 패킷은 멀티캐스트 그룹에 연결된 모든 장비로 전달된다.
▶ IP 주소 체계의 가장 큰 문제점은 IP 주소가 netid와 hostid 두 부분으로 구성되어 있다는 것이다. 즉, 어떤 컴퓨터가 다른 네트웍으로 이동하면 netid 부분이 새로 접속된 네트웍의 netid로 달라지고 따라서 이 컴퓨터의 IP 주소가 달라지게 된다.
▶ 노트북 컴퓨터나 휴대형 정보기기 등에서 인터넷 접속시 걸림돌이 되고 있는데 이를 해결하기 위하여 모빌 인터넷 프로토콜(mobile IP)이 제안되었다.
▶ IP 프로토콜 버전 6(IPv6)에서는 모빌 인터넷 기능이 표준안에 포함되어 있다.
(2) 서브네팅(subnetting)
▶ 인터넷에 가입하려면 반드시 인터넷 주소(IP 주소)를 먼저 배정받아야 한다.
▶ 전세계적으로 유일한 IP 주소를 할당받기 위해 IP 주소 중 네트웍 어드레스(netid)는 NIC(Internet Network Information Center) 또는 국내 대행기관(한국전산원 등)에서 받아야 한다.
▶ IP 주소의 수는 한정되어 있으므로 어떤 기관에서 배정받은 하나의 네트웍 주소(A, B 또는 C타입)를 다시 여러 개의 작은 네트웍으로 나누어 사용하는 방안이 경우에 따라 필요하며 이를 서브네팅(subnetting)이라 한다
▶ 4바이트 IP 주소 중에 netid 부분을 구분하기 위한 mask를 subnet mask라고 한다.
▶ 클래스 A 망을 위한 디폴트 subnet mask는 255.0.0.0이고 클래스 B의 망은 255.255.0.0, 클래스 C의 망은 255.255. 255.0이 된다.
▶ 서브네팅의 예로서 클래스 C 주소에서 hostid로 8비트가 아닌 6비트만 사용하고 netid로 24비트가 아닌 26비트를 사용하는 경우 subnet mask는 255.255.255.192가 된다(그림 1-7 참조).
▶ 그런데 netid로 2비트를 추가로 사용함으로써 모두 4개의 서브네트웍이 생겨야 하나 실제로는 이 두 비트의 패턴이 모두 1 또는 모두 0인 경우(즉, 11과 00)를 허용하지 않는다. 따라서 두 비트를 netid로 추가로 사용하여도 모두 두 개의 서브네트웍만 만들 수 있다.
▶ 만약 3비트를 서브네트웍을 만드는 데 사용하였다면 모두 8개의 서브네트 주소 가운데 111과 000인 경우를 제외하고 6개의 서브네트웍을 사용할 수 있게 된다.
그림 1-7 2비트를 서브네팅 주소로 사용한 경우의 subnet mask
▶ 한편 호스트 주소(hostid) 중에서 모두 1인 것은 방송용으로, 모두 0인 것은 자신의 주소(loopback)용으로 지정되어 있으므로 이 두 개의 주소는 특정 호스트에 배정할 수 없다.
▶ 표 1-3에 보인 바와 같이 서브네팅을 하면 배정 가능한 총 IP 주소 수가 줄어드는 것을 알 수 있다.
▶ 그러나 서브네팅이 필요한 이유는 큰 규모의 네트웍을 작은 규모의 LAN으로 나누어 주소 관리와 라우팅을 편하게 하기 위해서이다.
구 분
서브네팅 주소로 사용한 비트 수
(나누지 않음)
2비트 사용
3비트 사용
Subnet mask 255.255.255.0
255.255.255.192
255.255.255.224
서브네트웍 수 1
4-2 = 2
8-2 = 6
각 서브네트웍내의 호스트 수 256-2 = 254
64-2 = 62
32-2 = 30
배정 가능한 총 IP 주소 수 254
2×62 = 124
6×30 = 180
표 1-3 클래스 C IP 주소에서 2비트 또는 3비트를 사용하여 서브네팅을 하였을 때의 결과 비교
(3) IP 패킷 구조
▶ IP 패킷의 구조는 그림 1-8과 같으며 헤더의 각 필드의 기능을 표 1-4에 정리하였다.
그림 1-8 IP 패킷 구조
필 드 명
길이
(비트)
기 능
Ver (Version) 4
IP 버전 값을 표시(현재는 4임) IHL 4
4바이트 단위로 헤더 길이를 표시(최소값은 5) Service Type 8
서비스 클래스 지정(보통 0으로 지정) Total Length 16
IP 패킷 크기(바이트 단위이며 최대값은 65535) Identification 16
데이터그램을 유일하게 구분할 필요가 있을 때 사용하는 일련번호 Flags 3
첫번째 비트 : More 비트(0: 마지막 패킷, 1: 연속되는 패킷) 두번째 비트 : 세분화 금지 플래그(0: 세분화 가능)
세번째 비트 : 미사용
Fragment Offset 13
전체 메시지 중 이 패킷의 위치를 표시(8 바이트 단위) TTL (Time to Live) 8
패킷이 통신망내에서 계속 돌아다니는 것을 방지하기 위하여 사용되며 보통 hop counter 값을 사용한다. 노드를 지나갈 때마다 TTL값이 1씩 감소하고 이것이 0이 되는 노드에서 이 패킷을 제거한다. Protocol 8
데이터를 전달할 상위 계층 프로토콜을 지정 (1: ICMP, 6: TCP, 17:UDP) Header Checksum 16
헤더 부분의 오류 검출 Source IP Address 32
송신지 IP 주소 Destination IP Address 32
수신지 IP 주소 IP Options 가변
옵션 선택(보통 사용하지 않는다) Padding 가변
32비트 단위로 패킷의 길이를 맞춤(보통 사용하지 않는다) 표 1-4 IP 패킷 헤더의 기능
(4) 인터넷 계층의 동작
1) 데이터 전송
▶ 인터넷 계층의 주요기능은 상위 트랜스포트 계층으로부터 받은 데이터에 IP 패킷 헤더를 붙여 IP 패킷을 만들고 이를 전송하는 것이다.
▶ 상위 계층으로부터 받은 데이터의 크기가 IP 패킷의 최대 데이터 영역 크기보다 큰 경우에는 이를 여러 개의 IP 패킷으로 분해하여 전달하며 나누어진 각 IP 패킷의 More 비트를 1로 세트하여 이들이 논리적으로 연결된 것임을 표시하고 마지막 패킷의 More 비트는 0으로 한다.
2) ICMP(Internet Control Message Protocol)
▶ 인터넷 계층 프로토콜 중 ICMP는 호스트 또는 라우터 사이에 오류 정보, 제어 메시지를 전달하는 데 사용되며 주로 IP가 이용하지만 ping이나 traceroute 같은 응용 프로그램이 직접 사용하는 경우도 있다.
3) ARP(Address Resolution Protocol)
▶ 인터넷에 연결되는 모든 호스트는 네트웍 계층 주소에 해당하는 32비트의 IP 주소를 가지고 있다.
▶ 한편 이 장비가 LAN에 접속되어 있는 경우 LAN 카드에는 MAC 프레임을 상호 교환하는 데 필요한 48비트의 MAC 주소를 가지고 있게 되며 LAN내에서 장비간에 물리적으로 프레임을 전달하는 데에는 이 MAC 주소가 사용된다.
▶ 전달된 MAC 프레임내의 IP 패킷을 대상으로 인터넷 계층의 기능(비연결형 데이터그램 전달 서비스, 라우팅 등)을 처리하기 위하여 IP 주소가 사용된다.
▶ LAN에서 어떤 컴퓨터에 IP 패킷을 물리적으로 전달하기 위하여는 먼저 그 장비의 MAC 주소를 알아야 하는데 어떤 장비의 IP 주소를 가지고 그 장비의 MAC 주소를 알아내기 위한 절차(프로토콜)를 ARP(Address Resolution Protocol)라 한다.
▶ ARP의 동작 순서는 다음과 같으며 그림 1-9에 이를 나타냈다.
① 예를들어 telnet cc.kangwon.ac.kr라는 명령을 내리면, 응용 프로그램 telnet은 먼저 cc.kangwon.ac.kr 컴퓨터의 IP 주소가 192.203.144.11인 것을 찾는다.
② telnet은 위에서 알아낸 IP 주소를 TCP에게 알려주고 이곳으로 접속을 하도록 요구한다.
③ IP 계층은 목적지의 netid인 kangwon.ac.kr이 자신의 netid와 같은지를 비교하여 목적지가 같은 LAN내에 있으면 LAN을 통하여 바로 telnet 서비스 요구를 전송하도록 한다. 이때 목적지의 MAC 주소를 알아내기 위하여 ARP를 구동한다(목적지가 다른 망에 있는 경우에 대하여는 1.2.5절에서 설명한다).
④ARP에서는 목적지 장비의 MAC 주소를 찾기 위하여 ARP request 패킷을 LAN내의 모든 장비에게 방송한다.
⑤ 목적지 컴퓨터(cc.kangwon.ac.kr)만 ARP request에 응답을 하며 이때 자신의 MAC 주소를 알려온다.
⑥ 이 MAC 주소를 사용하여 telnet 서비스에 필요한 데이터들을 목적지(cc)로 전송한다.
그림 1-9 ARP의 동작 순서
▶ 동일한 목적지 호스트에 IP 패킷을 연속하여 보낼 때 매번 ARP를 사용하면 ARP를 처리하기 위한 패킷들을 자주 전송하게 되어 대역 이용률이 떨어진다. 이와같이 매번 ARP request 패킷을 방송하지 않도록 하기 위하여, ARP로 얻은 최근의 정보를 캐시에 기록해 두는 것이 효율적이다.
▶ 멀리 떨어져 있는 목적지 호스트를 대신하여 중간에 있는 라우터가 ARP에 응답할 수 있다면 동작 시간을 단축할 수가 있는데 이때 목적지를 대신하여 ARP 요구자에게 응답하는 중간의 라우터를 Proxy ARP라 한다.
4) RARP
▶ARP의 역과정, 즉 48비트 MAC 주소로부터 그 장비의 32비트 IP 주소를 알아내는 과정을 RARP(Reverse ARP)라 한다.
(5) SLIP과 PPP
▶ dial-up 회선이나 전용회선과 같은 직렬(serial)회선을 통하여 IP 패킷을 전송하기 위하여 SLIP(Serial Line IP)과 PPP (Point-to-Point Protocol)가 정의되었다.
1) SLIP
▶ SLIP은 비동기(asynchronous) 회선을 통하여 IP 패킷을 전송하기 위해 1988년에 제안되었다.
▶ 비동기 전송 회선이 바이트 단위의 전송을 제공하므로 SLIP도 한 바이트씩 데이터를 분할하여 전송하고 수신측에서는 이를 IP 패킷으로 재구성하여야 한다.
▶ SLIP은 IP 데이터그램의 시작과 끝을 표시하는 SLIP END(0xC0)문자를 사용한다(그림 1-10참조).
그림 1-10 SLiP의 프레임 구조
▶ 이와같은 방법에서는 IP 패킷내에 우연히 SLIP END와 같은 비트패턴이 발생하는 경우 데이터가 중간에서 끊어지는 오동작이 발생할 수가 있다.
▶ 이를 해결하기 위하여 SLIP ESC 문자 0xDB를 사용하여 IP 패킷 내에서 0xC0문자가 발생하면 이를 0xDBDC로 대치하여 전송한다.
▶ 한편 IP 패킷 중에 SLIP ESC 문자 0xDB가 나타날 수도 있으므로, IP 패킷 내용 중에 0xDB가 발생하면 이를 0xDBDD로 바꾸어 전송한다.
▶ SLIP은 제안된 초기에는 많은 관심을 끌었으나 다음과 같은 단점 때문에 널리 사용되지 않고 있다.
▶ 첫째, SLIP을 사용하려면 상대방의 IP 주소를 반드시 미리 알고 있어야 하고 둘째로 SLIP은 이더넷과 달리 Type 필드를 제공하지 않는다. 즉, SLIP은 IP 패킷을 전송하는 것 이외의 다른 프로토콜을 지원하는 것이 불가능하다. 셋째로 SLIP은 에러 검출 또는 회복기능을 제공하지 않는다.
2) PPP(Point-to-Point) 프로토콜
▶ PPP는 SLIP의 단점을 보완한 프로토콜로서 1992년에 제안되었으며 IP 패킷의 전송뿐 아니라 여러 프로토콜을 하나의 링크를 통하여 지원할 수 있다.
▶ SLIP이 비동기 전송 채널만을 지원하는 것과 달리 PPP는 비동기전송과 동기전송(Byte-oriented 또는 Bit-orient ed) 회선에서 모두 사용할 수 있으며 매체의 전송속도에 무관하게 동작한다.
▶ 저속의 dial-up 회선 뿐만아니라 고속 전용회선(56kbps∼ 45Mbps)에서 사용할 수 있도록 설계되었다.
▶ PPP는 이더넷과 같은 LAN을 중간에 경유하는 종점간의 일대일 접속 프로토콜로도 사용될 수 있다.
▶ PPP 프로토콜은 OSI 링크 계층 표준으로 제안된 HDLC (High-level Data Link Control)에서 변형된 형태라고 할 수 있는데 HDLC의 헤더의 크기를 줄이고 데이터를 압축함으로써 전송 효율을 더 높였다는 것이 특징이다.
▶ PPP 프레임에서도 HDLC에서와 같이 0x7E를 프레임의 시작과 끝을 표시하는 플래그로 사용한다(그림 1-11 참조).
그림 1-11 PPP 프레임 구조
▶ PPP 프레임의 Address와 Control은 각각 0xFF와 0x03으로 고정되어 있고 Protocol 필드는 프레임이 전달하는 정보의 종류를 구분하는 데 사용된다.
▶ 예를들어 Protocol 필드가 0x0021이면 IP 패킷을, 0x002B이면 IPX 패킷을 가리킨다.
1.2.4 트랜스포트 계층
(1) 연결형과 비연결형 서비스
▶ 연결형 서비스란 일단 상대방과 연결을 설정하고 이 연결을 이용해 데이터를 주고받은 후 연결을 해제하는 세 단계의 절차를 거치는 서비스로 X.25의 가상회선 패킷 교환 서비스, 전화와 같은 회선교환 서비스, 그리고 TCP는 연결형 서비스이다.
▶ 연결형 서비스에서는 연속된 흐름(stream)의 데이터 송수신이 가능하며 큰 파일 전송시에도 데이터가 중간에 끊어지는 것에 대하여 사용자가 신경쓸 필요가 없다.
▶ 연결형 서비스는 한 번에 많은 양의 데이터를 전송할 때나 신뢰성 있는 연결이 필요할 때, 또는 데이터의 순서 보장이 필요할 때 사용된다.
▶ 비연결형 서비스란 연결을 설정하고 해제하는 절차 없이 바로 데이터를 주고받는 방식으로 데이터그램 서비스라고도 한다
▶ 비연결형 서비스는 데이터그램의 손실 확인이나 순서유지를 보장해 주지 않기 때문에 (상위의) 응용 프로그램에서 필요하면 이를 처리해야 한다. 그러나 프로토콜 헤더 처리에 필요한 오버헤드(연결설정 지연 등)가 연결형 서비스보다 적어 간단한 패킷을 주고받는 경우에 유리하다.
▶ 비연결형 서비스에는 이더넷 등의 프로LAN, X.25의 데이터그램 서비스, IP 패킷 전송, UDP 토콜 등이 해당된다.
(2) 트랜스포트 프로토콜
▶ TCP/IP의 트랜스포트 계층에는 연결형(Connection Oriented) 서비스를 제공하는 TCP 프로토콜과 비연결형(Connectionless) 서비스를 제공하는 UDP 프로토콜이 있다.
▶ 연결형 서비스인 TCP는 트랜스포트 계층에서 종점간의 연결 개설, 오류 발생시 데이터 재전송, 패킷 전달순서 확인, 중복 패킷 제거, 흐름제어, 네트웍 오동작시 보고 등을 제공하는 서비스이다.
▶ 비연결형 서비스인 UDP는 위의 연결형 서비스를 제공하지 않고 단순히 패킷을 하나씩 목적지 주소로 전송만 한다. 따라서 UDP를 안정적으로 사용하려면 응용 프로그램에서 데이터의 분실, 흐름제어, 오류 등을 처리하여야 한다
▶ 안정적인 데이터 전달을 필요로 하는 응용 프로그램은 대부분 TCP를 사용하고 있고 어떤 응용 프로그램은 UDP를 사용해야만 하는 경우도 있는데 이러한 경우는 다음과 같다.
- 응용 프로그램이 UDP만을 사용하도록 작성되어 있는 경우
- 패킷을 방송(broadcast) 또는 멀티캐스트 해야 하는 경우
- TCP 처리 오버헤드 때문에 TCP로 처리할 시간이 없는 경우(실시간 서비스 등)
(3) TCP
▶ TCP는 신뢰성 있는 종점간 데이터 전달을 책임지며 스트림(stream)형의 서비스를 제공함으로써 상위 계층의 통신 엔티티 사이에 투명한(transparent) 데이터 전달 환경을 제공한다고 한다.
▶ TCP의 프로토콜 데이터 단위(Protocol Data Unit: PDU)의 구조는 그림 1-12와 같으며 TCP 헤더 각 필드의 기능을 표 1-5에 정리하였다.
그림 1-12 TCP 프로토콜 데이터 단위 (PDU)
필 드 명
길이
(비트)
기 능
Source Port 16
송신측의 응용 프로세스를 구분하는 포트번호 Destination Port 16
수신측의 응용 프로세스를 구분하는 포트번호 Sequence Number 32
송신된 데이터의 순서번호(바이트 단위) Ack Number 32
수신된 데이터 바이트 수 + 1(아래의 ACK=1일 때 의미가 있음) Header Length 4
헤더크기(4바이트 단위)로 보통 5가 된다 Code
Bits
SYN
1
연결 요청시 사용되며 Sequence Number가 초기값임을 알린다. ACK
1
Ack용 데이터임을 표시(이때 Ack Number 값이 유효하다) URG
1
긴급 데이터임을 표시(이때 Urgent Pointer 값이 유효하다) FIN
1
접속을 종료하는 데 사용 RST
1
접속을 리셋하는 데 사용 Window 16
흐름제어용 윈도우 크기(바이트 단위) Checksum 16
TCP PDU 전체와 IP계층의 헤더 중 후반부 12바이트(송수신지 IP 주소 등)에 대한 오류 검출코드 Urgent Pointer 16
긴급 데이터가 들어 있는 위치를 표시 표 1-5 TCP 헤더의 각 필드의 기능
▶ TCP에서는 종점 장비간의 연결 설정을 위하여 three- way handshake를 사용한다.
▶ OSI 표준의 패킷 교환망(X.25)의 네트웍 계층에서는 two-way handshake를 사용하는데 이들의 차이는 다음과 같다.
- Two-way handshake : 연결 접속요구에 대하여 상대방이 응답을 하면(즉, 제어정보가 두 방향으로 갔다 오면) 연결이 이루어진다.
- Three-way handshake : 연결 접속요구(Request For Connect : RFC)에 대하여 상대방도 이를 확인하면서 다시 연결 접속요구(RFC)를 하고 이에 대해 처음의 연결 요구측에서 ACK를 보내야 연결이 되는 것으로 이중으로 연결절차를 확인한다. 트랜스포트 계층에서 three- way handshake를 사용하는 이유는 중간의 서브네트웍의 종류에 무관하게 종점간의 안정적인 연결을 확인하기 위해서이다(예를들면 연결요구 패킷의 손실 등).
▶ TCP는 한번의 명령으로 보낼 수 있는 데이터의 크기가 제한되지 않으므로 임의의 길이의 큰 파일을 전송할 수 있다(UDP에서는 한 번에 전송할 데이터가 UDP 최대 데이터그램 크기보다 크면 뒷 부분이 전송되지 않는다).
▶ TCP에서는 흐름제어를 패킷 단위가 아니라 데이터 분량(바이트 단위)으로 수행한다.
▶ 송신측은 상대방이 최근에 보내온 TCP 헤더의 Window 값(표 1-5참조)을 읽어 바이트 단위인 Window 크기(이를 credit 값이라 한다.) 내에서만 TCP 데이터를 전송할 수 있다.
▶ 상대방 즉, 수신측은 자신의 데이터 처리 능력과 네트웍 사정에 따라 Window 값을 바꿈으로써 흐름제어를 할 수 있다.
(4) UDP
▶ UDP(User Datagram Protocol)의 오버헤드는 TCP 보다 작다.
▶ 송신지 및 목적지의 포트번호(16비트), 데이터그램 길이(16비트), Checksum 그리고 사용자 데이터로 구성된다(그림 1-13 참조).
그림 1-13 UDP 프로토콜 데이터 단위
▶ UDP는 신뢰할 수 있는 종점간 데이터 송수신을 보장하지 않으므로 파일 전송, 메일 서비스 등에는 적합하지 않다.
▶ 도메인 네임(domain name) 서비스나, time 서비스와 같이 한 패킷의 송수신으로 어떤 서비스가 이루어지는 경우에 많이 사용된다.
▶ LAN과 같이 전송 오류가 거의 없고 패킷의 전달 순서가 바뀌지 않는 환경에서는 TCP보다 처리 속도가 빠른 UDP가 유리할 수 있다.
▶ LAN에서 제공되는 NFS(Network File System)는 UDP를 사용한다.
1.2.5 네임 서비스
▶ TCP/IP 사용자 또는 프로그래머가 목적지 호스트의 IP 주소를 항상 기억하고 있기는 어려우므로 실제로 호스트마다 영문 이름을 부여하여 사용한다.
▶ 영문 이름을 도메인 네임이라 하고 이에 관한 서비스를 네임 서비스라 한다.
▶ 예를들어 mail hjkim@cc.kangwon.ac.kr이라는 명령문을 입력하면 호스트에서는 먼저 목적지 호스트 cc.kangwon. ac.kr의 IP 주소 192.203.144.11을 찾아내야 하는데 이 과정(또는 이의 역과정)을 네임 서비스라고 한다.
(1) Domain Name System
▶ 인터넷 주소를 편리하게 관리하기 위하여 네트웍 단위로 또는 논리적인 컴퓨터 그룹 단위로 도메인 네임을 계층화시켜(hierarchical) 체계화한 것을 DNS(Domain Name System)라고 한다.
▶ 아래의 인터넷 주소에서 도메인 이름은 kangwon.ac.kr이며 주소 각 부분의 의미는 다음과 같다.
- 영문 인터넷 주소 : hjkim@cc.kangwon.ac.kr
- hjkim : 호스트 cc에 있는 사용자 계정 이름
- cc : 호스트 이름
- kangwon: 강원대학교를 나타내는 도메인 이름
- ac : 교육망을 나타내는 도메인 이름
- kr : 한국을 나타내는 도메인 이름
(2) Hosts 테이블
▶ 네임 서비스를 제공하는 가장 기본적인 방법은 hosts 테이블에 통신할 대상이 될 수 있는 각 호스트의 도메인 네임과 IP 주소의 관계를 아래와 같이 기록하여 두는 방법이다.
# /etc/hosts # Internet host table
#
#
# IP 주소 도메인 네임 별명
127.0.0.1 localhost
203.252.65.3 vcn loghost
192.203.144.11 cc.kangwon.ac.kr cc
192.203.144.15 bbs.kangwon.ac.kr bbs
:
▶ 위에서 127.0.0.1은 loopback 주소 즉, 목적지가 같은 컴퓨터내에 있을 때 사용하는 주소이며 loghost란 현재 사용중인 컴퓨터를 말한다.
▶ hosts 테이블을 사용하여 네임 서비스를 제공하는 방법은 관리할 주소의 규모가 작을 때는 가능하나 통신 가능한 모든 도메인 이름을 hosts 테이블에 수용하기란 불가능하다.
▶ 따라서 대부분의 인터넷 장비는 다음에 설명할 DNS 서버를 통하여 네임 서비스를 이용하고 있다.
▶ 그러나 DNS 서버가 고장났을 때 중요한 호스트들에 접속하기 위해서, 그리고 자주 접속되는 호스트들의 IP 주소를 빨리 찾기 위하여 DNS 서버와 병행하여 hosts 테이블을 사용하는 것도 필요하다.
(3) DNS 서버
▶ 네임 서비스를 위하여 hosts 테이블과 같은 평면적 데이터베이스를 쓰는 방식은 이름의 중복, 테이블 크기의 증가 등 여러 가지 문제점이 발생하게 된다.
▶ 이를 해결하기 위하여 DNS 서버를 사용하는데 DNS 서버란 DNS 서비스를 전담하여 제공하는 서버를 말한다.
▶ 하나의 DNS 서버가 전세계에 있는 모든 호스트의 정보를 가지고 있기란 불가능하므로 DNS 서버는 계층적으로 서비스를 제공하여야 한다.
▶ 예를들어 hosts 테이블에 없는 네임을 처리하려면 이를 디폴트로 문의할 DNS 서버를 지정해 둔다.
▶ 이 디폴트 DNS 서버에서 처리되지 못하는 네임은 한 단계 상위의 도메인 네임들을 처리할 수 있는 다른 DNS 서버에게 문의한다.
(4) 서비스 파일
▶ 한 호스트내에서는, 특히 UNIX 서버에서는 여러 개의 프로세스가 동시에 수행되고 있을 수 있으므로 TCP/IP는 이들을 구별하기 위해 포트번호를 사용한다.
▶ IP 프로토콜이 네트웍으로부터 수신한 패킷을 전달할 상위 응용 프로세스를 구분하기 위하여 포트번호를 사용하는 것이다.
▶ 포트번호에는 미리 정해진 것들도 있고 응용 프로그램에서 임의로 정해서 사용하는 것도 있다.
▶ telnet이나 ftp 같은 널리 쓰이는 응용 프로그램에는 포트번호가 미리 지정되어 있으며 이런 것을 well-known 포트라고 한다.
▶ well-known 포트 번호는 1024번 이하가 배정되며 사용자가 응용 프로그램에서 임의로 포트를 정의하여 사용하는 경우에는 1025번 이상의 포트번호를 사용하여 well-known 포트 번호와 중복되지 않도록 하여야 한다.
▶ TCP/IP를 지원하는 어떤 호스트의 well-known 포트번호가 정의되어 있는 파일을 서비스 파일이라고 한다.
▶ 예를들어 저자가 사용중인 UNIX 호스트의 서비스 파일/etc/services의 일부분을 아래에 보였다.
# # Network services, Internet style
#
# 서비스명 포트번호/프로토콜 별명
#
echo 7/tcp
echo 7/udp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
:
:
▶ 예를들어 smtp 25/tcp mail 라인의 의미는, smtp(simple mail transfer protocol) 서비스는 25번 포트번호를 사용하고 tcp 프로토콜로 구현되어 있으며 smtp 서비스의 별명으로 mail을 사용할 수 있다는 것을 나타낸다.
1.3 클라이언트-서버 통신 모델
1.3.1 개요
▶ 대부분의 컴퓨터 네트웍 프로그램은 클라이언트-서버 모델로 구현되는데 서비스를 제공하는 장비를 서버라 하고 서비스를 받는 장비를 클라이언트라 한다.
▶ 컴퓨터 네트웍의 역할은 네트웍에 접속된 임의의 클라이언트가 임의의 서버와 연결될 수 있도록 하는 것이다.
1-14 컴퓨터 네트웍과 클라이언트-서버 통신 모델
▶ 일반적으로 네트웍 서비스를 받기 위하여 클라이언트가 통신을 시작한다.
▶ 클라이언트는 서버에 접속을 시도하고 그 연결 결과를 기다린다든가(연결형 서비스의 경우), 어떤 서비스를 요구하고 응답을 기다린다.
▶ 클라이언트의 이와같은 요구(request)에 대하여 서버는 응답(response)을 보내는 방식으로 동작이 이루어진다.
▶ 서버는 파일 시스템, 통신 포트 등의 자원을 관리하기 위하여 root 권한을 갖는 경우가 많으므로 클라이언트가 서버 프로그램을 통하여 서버의 자원을 임의로 액세스하지 못하도록 주의하여 서버 프로그램을 구현하여야 한다.
▶ 예를들면 접속된 클라이언트가 서비스를 제공할 대상인지 확인하기 위하여 클라이언트의 id를 검사하거나(authentication), 서버의 정보의 유출, 변경 등을 확인하거나(security), 여러 클라이언트에게 서비스를 동시에 제공하는 기능(concurrency) 등이 필요할 수 있으며 따라서 클라이언트보다 구현이 복잡하다.
1.3.2 서버의 구현 기술
▶ 클라이언트-서버 통신 프로그램을 작성하려면 서버를 어떠한 방식으로 구현할지를 먼저 정해야 한다.
▶ 클라이언트는 서버의 구현 형태에 따라서 단순히 서비스를 요청하는 것이므로 우선 서버의 구현 방식을 정하는 것이 중요하다.
▶ 서버의 구현기술 종류로 연결형과 비연결형 서버, state- less와 stateful 서버, iterative와 concurrent 서버에 대하여 각각의 구현 방법과 특징을 설명하겠다.
(1) 연결형과 비연결형 서버
▶ 클라이언트와 서버의 통신에서 사용할 트랜스포트 계층 프로토콜의 종류(즉, TCP 또는 UDP)에 따라 연결형 서버와 비연결형 서버로 나눌 수 있다.
▶ 연결형 서버는 스트림형 트랜스포트 프로토콜(TCP)을 사용하며 데이터의 안정적인 전달(전송 순서 유지, 재전송 제공 등)을 보장하는 서버이다.
▶ 연결형 서버의 단점은 모든 클라이언트와의 접속마다 소켓을 각각 개설하고 있어야 한다는 것이다(소켓에 관하여는 2.1절에서 설명함).
▶ 한 컴퓨터에서 동시에 열 수 있는 파일 수가 제한되듯이 소켓을 많이 개설하면 시스템 자원을 많이 사용하게 된다.
▶ 서버에서 소켓을 개설하는 것이 계속 누적되면 서버가 메모리 사용의 증가로 동작을 정지할 수도 있으므로 이를 주의하여야 한다.
▶ 비연결형 서버는 비연결형 트랜스포트 프로토콜(UDP)을 사용하는 서버로 네트웍이 안정적인 데이터의 전달을 책임지지 못하기 때문에 응용 프로그램이 필요하면 이를 보상해 주어야 한다.
▶ 비연결형 서버의 장점은 하나의 소켓을 통하여 다수의 클라이언트에게 서비스를 제공할 수 있으므로 자원(소켓, 메모리)을 절약할 수 있다는 것이다.
▶ TCP는 일대일 접속만 지원하므로 방송형 또는 멀티캐스팅을 필요로 하는 응용 프로그램에서는 비연결형(UDP) 서버를 이용하는 것이 편리하다.
▶ 연결형과 비연결형 서버의 특징을 표 1-6에 비교하였다.
서버의 종류 특 징 연결형 서버 - TCP 프로토콜 사용 - 데이터의 안정적인 전달을 보장함.
- 각 클라이언트마다 연결을 설정하여야 함.
- 클라이언트 수가 늘면 서버에 부담이 클 수 있음.
비연결형 서버 - UDP 프로토콜 사용 - 메시지를 한 번만 보내면 되는 간단한 서비스에 적합
- 클라이언트마다 연결을 설정할 필요가 없으므로
서버의 부담이 적음(메모리 사용 등).
- 방송형, 멀티캐스팅형 서비스에 적합
표 1-6 연결형과 비연결형 서버의 특징 비교
(2) Stateful과 Stateless 서버
▶ 서버가 클라이언트와의 통신 상태(state)를 계속 추적하며 이 상태 정보를 서비스 제공에 이용하는 서버를 stateful 서버라고 한다.
▶ 상태란 과거의 동작(데이터 송수신 및 처리) 결과라고 할 수 있는데 서버의 현재 상태에 따라서 클라이언트로부터의 요구(request)마다 취하는 응답(response)이 달라질 수 있다.
▶ 상태 정보를 사용하면 현재의 상태에 따라 약속된 명령에 대하여 신속히 응답할 수 있게 되며, 클라이언트와 주고 받을 메시지의 크기를 줄일 수 있다.
▶ 예를들어 서버가 현재 파일을 열고(open) 일정 크기로 데이터를 읽거나 지울 수 있는 상태에 있다고 하자.
클라이언트가 '0'이라는 명령(request)을 보내면 100바이트를 서버가 읽어 클라이언트로 보내고 '1'이라는 request를 보내면 100바이트를 파일에서 지우도록 약속되어 있다면, 클라이언트는 request로 사용하는 메시지의 크기를 한 비트로 작게 할 수 있으며 서버도 약속된 명령을 신속히 처리할 수 있다.
▶ stateful 서버를 사용하는 경우 현재의 상태 정보가 잘못되어 있거나 request에서 비트 오류가 발생하면 오동작을 할 가능성이 높다는 단점이 있다.
▶ 통신의 동작 상태를 정의하지 않고 항상 클라이언트로부터의 독립적인 request에 의해 서비스를 제공하는 서버를 stateless 서버라고 한다.
▶ 즉 stateless 서버는 클라이언트로부터 새로 도착한 명령문(request)에만 의존하여 서비스를 제공한다.
▶ stateless 서버를 사용하는 장점은 틀린 상태 정보를 사용할 가능성을 없앰으로써 서버가 안정적으로 동작한다는 것이다.
▶ 상태 정보는 과거의 정보이므로 클라이언트가 이전에 보낸 메시지에서 오류가 발생했으면 틀린 상태로 가 있을 수 있기 때문이다.
▶클라이언트가 stateless 서버로 보내는 request는 서버가 동작하기에 필요한 모든 정보를 가지고 있어야 하므로 메시지의 길이가 stateful 서버의 경우보다 길어질 수 있다.
▶ 네트웍이 안정적인(즉, 오류 및 순서 바뀜이 적은) 경우에는 stateful 서버를 사용하는 것이 유리하다.
▶ 인터넷의 환경은 패킷의 복사, 분실, 오류, 지연, 순서 바뀜 등이 발생할 가능성이 크므로 안정적이라고 할 수 없다.
▶ stateful 서버를 사용하는 경우는 네트웍 또는 서버가 reset되었을 때 모든 상태 정보도 reset되어야 하고 모든 동작이 reset된다는 단점이 있다.
▶ 오동작을 최소화하는 범위에서 상태 정보를 적절히 이용하는 프로그래밍 기술이 필요하다.
(3) Iterative와 Concurrent 서버
▶ Iterative 서버는 클라이언트의 서비스 요구를 순서대로 처리해 주는 서버이다.
▶ 클라이언트로부터의 각 request를 충분히 짧은 시간 동안에 처리할 수 있어 다른 클라이언트들이 기다리는 시간이 거의 없거나 별로 문제가 되지 않는 경우에 사용할 수 있다.
▶ Iterative 서버는 프로그램 구현이 다음에 설명할 con- current 서버보다 비교적 간단하다.
▶ Concurrent 서버는 여러 클라이언트가 요구하는 서비스를 동시에(concurrently) 제공할 수 있는 서버를 말한다.
▶ Concurrent 서버는 동시에 여러 클라이언트들에게 서비스를 제공하기 위하여 새로운 클라이언트가 접속될 때마다 이 클라이언트가 요구하는 서비스를 처리할 프로세스를 계속 만들어야 한다.
▶ 이 방법은 클라이언트 수가 늘어남에 따라 프로세스 수도 계속 늘어나게 되므로 다수의(예를들면 수백개) 클라이언트가 접속될 수 있는 서비스에서는 사용할 수 없다.
▶새로운 클라이언트들이 새로 접속되어도 이를 처리할 프로세스를 계속 생성하지 않고, 마치 운영체제가 여러 작업을 스케줄링하듯이 하나의 프로세스가 모든 서비스를 동시에(concurrently) 처리하는 방법이 널리 사용된다.
▶ 이러한 방식으로 구현되는 서버를 apparent concurrent 서버라고 하며 이에 대하여는 4.2절에서 설명하겠다.
서버의 종류
특 징
Iterative 서버
- 하나의 프로세스가 모든 클라이언트의 서비스를 처리 - 각 서비스의 처리 시간이 짧을 때 사용
- 서버 프로그램 구현이 단순
Concurrent 서버
- 서버 프로그램 구현이 다소 복잡 - 각 클라이언트에 대해 프로세스가 하나씩 생성됨.
- 각 서비스 처리 시간이 불규칙적이거나 길 때 필요
표 1-7 Iterative와 Concurrent 서버의 특징 비교
소강좌제목 : 컴퓨터 네트웍 프로그래밍 다음강좌: 제2장 UNIX BSD 소켓 시스템 콜
'UNIX_LINUX_C_C++' 카테고리의 다른 글
| [펌] 제3장 클라이언트-서버 토크 프로그램 (0) | 2011.10.14 |
|---|---|
| [펌] 제4장 UNIX 소켓 응용 프로그래밍 (0) | 2011.10.14 |
| [펌] 제2장 UNIX BSD 소켓 시스템 콜 (0) | 2011.10.14 |
| [펌] Unix C 로 코딩할때 필요한 기본적인것들 - 목차[5장까지] (0) | 2011.10.14 |
| [unix c/c++] undefined reference to `xxxxxx` (0) | 2011.09.07 |