Search
Duplicate

컴퓨터 네트워크/ TCP/IP

TCP/IP의 개요

(생략)

인터네트워킹(InterNetworking)

인터네트워킹 구성

초기에 인터넷이 형성된 후에 서로 떨어져 있는 각각의 수많은 네트워크들을 연결하여 하나의 네트워크로 연결하여 사용할 수 있도록 해주는 기술이 개발되었다. 인터네트워킹이라 불리는 이 기술은 서로 다른 종류의 이 기종 네트워크를 연결시키고 하나의 통신 권고 사항을 둠으로써 여러 가지 다양한 하드웨어 기술을 다룰 수 있게 해주었다.
인터넷 기술은 네트워크 하드웨어의 복잡한 부분은 감추고 컴퓨터들에게 자신이 속한 물맂거 네트워크에 관계없이 통신할 수 있는 서비스를 제공하였다.
그림 6-1은 게이트웨이나 라우터, 허브 등의 네트워크 장비들을 이용한 네트워크가 서로 인터넷이나 네트워크를 구성하여 인터네트워킹된 모습을 보여주고 있다.

인터네트워킹 장비

리피터(Repeater)

리피터는 국제표준기구인 OSI(Open Systems Interconnection) 참조 모델의 물리계층에서 동작하는 장비로서 근접한 2개 이상의 데이터 네트워크 사이에 신호를 전송한다.
데이터가 전송되는 동안 케이블에서는 신호의 손실인 감쇠(Attenuation) 현상이 일어나는데, 리피터는 감쇠되는 신호를 증폭하고 재생하여 전송한다.
또한 리피터는 연속적으로 2개 이상의 케이블에 연결함으로써 케이블의 거리 제한 사항을 극복하고 네트워크 반경을 연장하는 효과를 제공한다.

허브(Hub)

한 사무실이나 가까운 거리의 컴퓨터들을 UTP(Unshield Twisted Pair) 케이블을 사용하여 연결하기 위해 사용하는 네트워크 장비이다. 컴퓨터나 다른 네트워크와 연결하며, 신호 증폭기능을 하는 리피터의 역할도 포함한다.

브리지(Bridge)

브리지는 리피터와 달리 패킷 프레임에 대한 인지능력이 있으며 OSI의 데이터 링크 계층인 MAC(Media-Access Control)에서 동작하며, 둘 또는 그 이상의 네트워크들을 상호 연결하는데 사용한다.
브리지를 사용하는 목적은 네트워크를 확장시키고 네트워크 통신을 격리시키기 위한 것이다. 브리지는 자체 학습기능을 통하여 양쪽 세그먼트의 어드레스들을 축적하여 불필요한 데이터가 반대편 네트워크로 전송되는 것을 방지하여 네트워크 부하를 감소시키는 역할을 수행하기도 한다.
그러나 브리지는 브로드캐스트와 멀티캐스트 프레임을 그대로 전송하므로 달느 세그먼트에 불필요한 트래픽을 발생시켜 성능 저하의 요인이 되기도 한다.
또한 프레임 내부의 한 항목인 FCS(Frame Check Sequence)를 점검해 에러가 발생한 프레임은 전송하지 않으므로 에러 처리기능을 가진다.

스위치(Switch)

PC에 할당되는 대역폭을 확대시키기 위해 탄생된 장비로 허브와는 달리 LAN이 제공하는 대역폭을 PC로 고스란히 전달한다. 이더넷 스위치(Ethernet Switch)는 자신에 연결된 PC의 수에 상관없이 각각에 회선의 최대 대역폭을 제공한다.

라우터(Router)

라우터는 브리지와 달리 OSI 7 계층의 네트워크 계층에서 동작하므로 프로토콜 단위의 패킷을 관리한다. 이것은 IP 주소에 의하여 데이터의 경로를 설정하며 다중 경로일 경우에는 최적의 경로를 자동 설정하여 네트워크의 트래픽을 최소화한다.
라우터를 중간 매체로 하는 경우 송수신 장치가 설사 서로 다른 매체 액세스 방식을 사용하더라도 동일한 네트워크 계층 프로토콜을 사용한다면 상호간에 통신이 가능하다. 따라서 라우터는 브리지의 역할도 동시에 제공한다.
네트워크 프로토콜 중에는 라우팅이 불가능한 것도 있으므로 라우터에서 브리지의 기능을 제공하는 것은 트래픽 처리를 위해 중요한 기능이다. 브리지 기능을 수행하면서 브리지와 다른 점이 있다면 MAC 계층의 브로드캐스트와 멀티캐스트 프레임을 재전송하지 않는다는 점이다.
이러한 특성은 브로드캐스트와 멀티캐스트 프레임이 많은 대규모 네트워크에서 회선을 효율적으로 사용하는데 특별히 유용하다.

게이트웨이(Gateway)

서로 다른 통신규약을 사용하는 네트워크들을 상호 연결하기 위하여 자신의 통신규약을 상대방의 통신규약으로 전환해 주는 역할을 하여 서로 다른 기종의 네트워크를 연결시키는 장비이다.
OSI 참조 모델의 모든 계층을 포함하여 동작하는 네트워크 장비로서 두 개의 완전히 다른 네트워크 사이의 데이터 형식을 변환하는 기능을 수행한다.
프로토콜 구조가 다른 네트워크 환경들을 연결할 수 있는 기능을 제공할 수 있지만, 여러 계층의 프로토콜 변환기능을 수행하므로 네트워크내의 병목 현상을 일으키는 지점이 될 수 있다.
그림 6-2는 리피터, 브리지, 라우터, 게이트웨이가 OSI 7계층과 연결되는 모습을 도식화한 것이다.

TCP/IP 프로토콜 계층 구조

TCP/IP는 단순히 TCP와 IP만을 일컫는 말이 아니라, 여러 가지 프로토콜의 조합을 의미한다. 다만 TCP와 IP가 가장 많이 사용되며, 중요하기 때문에 그렇게 불리우는 것이다.
TCP/IP 프로토콜 계층 구조는 그림 6-3과 같이 데이터링크 계층, 네트워크 계층, 전송 계층, 응용 계층으로 구성된다.
데이터링크 계층
실제 네트워크에서 데이터를 전송하는 케이블에 프레임이라고 불리는 데이터를 송수신하는 역할을 담당한다.
네트워크 계층
주소를 관리하고 포장하고, 라우팅(Routing)을 하는 역할을 담당한다. 이 계층의 프로토콜 중 IP는 호스트들과 네트워크 상에서 주소를 관리하고, 패킷을 라우팅하는 역할을 한다.
ARP(Address Resolution Protocol)는 같은 네트워크 상에 위치한 호스트들의 하드웨어 주소(MAC Address)를 얻는데 이용되며, ICMP(Internet Control Message Protocol)는 패킷 전송에 관한 에러 메시지를 처리하는데 이용된다.
전송 계층
호스트들 간에 통신을 제공한다. 전송 계층에는 2개의 프로토콜이 있는데 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)가 그것이다.
연결 지향(Connection-oriented)이라고 하는 TCP는 일반적으로 데이터의 확실한 전송을 위해 수신측으로부터 받았다는 확인 메시지를 요구할 필요가 있을 때 사용된다. 반면 UDP는 패킷의 정확한 전달을 보장하지 않는다.
응용 계층
어플리케이션이 네트워크에 접근 가능하도록 해주는 역할을 한다.
그림 6-4, 6-5는 서브네트워크와 게이트웨이의 프로토콜 계층 관계를 나타내고 있다.
호스트 A에 있는 사용자 응용프로그램이 PDU를 호스트 B에 있는 응용 계층 프로토콜로 전송할 때 다음과 같은 기능을 수행한다.
사용자 데이터는 전송 계층 프로토콜인 TCP로 전달된다.
TCP는 몇 가지의 기능을 수행하며 역시 자신에게 전달되어 온 PDU에 세그먼트(Segment)라고 불리는 헤더를 덧붙인다.
TCP는 상위 계층으로부터 전달되어 온 PDU를 데이터로 간주한다.
TCP가 자신이 구성한 세그먼트를 네트워크 계층으로 전달한다.
IP도 데이터그램(Datagram)을 하위계층으로 전달한다.
데이터링크 계층은 다시 헤더와 트레일러(Trailer)를 덧붙인다.
데이터링크 계층에서 구성된 데이터 단위는 프레임(Frame)이라 부르며 물리 계층에 의해 네트워크로 보내진다.
위와 같이 호스트 A에서 B로 데이터가 전달되는 동안 네트워크 내부에서 어떻게 진행되는지 각 계층은 서로 투명성을 유지한다.
목적지인 호스트 B는 자신의 하부 계츠으이 트래픽을 수힌하여 호스트 A에서 진행된 과정의 역과정을 수행한다. 즉 각 계층을 거칠 때마다 헤더를 분리시킴으로써 캡슐화된 PDU를 분리시킨다.
각 계층은 헤더에서 정보를 얻어서 자신이 취해야 할 동작을 결정하며 그 기능을 수행한다.
그림 6-6은 OSI 7 계층과의 관계를 보여준다.

IP(Internet Protocol)

IP 특성

IP는 OSI 참조모델의 2계층인 네트워크 계층에 해당하고, 전송 경로의 확립이나 네트워크 주소와 호스트 주소의 정의에 의한 네트워크 논리적 관리 등을 담당한다. 모든 TCP/UDP, ICMP, IGMP 데이터는 IP 데이터그램을 사용하여 전송되며 그 특징은 다음과 같다.

비신뢰성(Unreliable)

IP 데이터그램이 목적지에 성공적으로 도달한다는 것을 보장하지 않는다는 의미이며, 최선의 서비스(Best Effort Service)만을 제공한다. 신뢰성에 대한 요구는 TCP와 같은 사우이 계층에서 제공되어야 한다.

비접속형(Connectionless)

IP가 연속되는 데이터그램에 대한 어떠한 상태 정보도 유지하지 않는다는 것을 의미한다. 이것은 IP 데이터그램이 어긋난 순서로 배달될 수 있다는 것을 의미하기도 한다.

주소 지정

각 네트워크 상에 접속해 있는 노드의 주소를 지정해주며, 이를 통하여 데이터를 전송할 목적지를 지정해 주는 역할을 한다. 보통 각 호스트마다 주어진 IP 주소를 말하며, 이 기능을 통하여 네트워크 상에 접속해 있는 각각의 노드를 식별하는 역할을 한다.

경로 설정

네트워크 계층에 속하는 IP의 주요 기능으로서 목적지의 주소를 가지고 패킷을 전송하기 위하여 최적의 경로를 설정해 주는 역할을 한다. 이것은 특정 목적지로 데이터를 전송할 때 어떤 경로를 경유하여 전송할지 결정하는 것이며, 이렇게 결정된 경로를 통하여 데이터 전송이 이루어지게 된다.

IP 헤더

그림 6-8은 IP 데이터그램의 헤더 포맷을 나타내고 있다. 일반적인 IP 헤더의 크기는 선택 사항(Option)이 사용되지 않는 경우 20바이트이다.
최상위 비트(Most Significant Bit)는 왼쪽에 0으로 표시되어 있고 최하위 비트(Least Significant Bit)는 오른쪽에 31로 표시되어 있다. 32비트 값의 4바이트는 순서대로 전송되는데, 0-7비트가 첫 번째, 그리고 8-15, 16-23, 마지막으로 24-31비트가 전송된다.
이것을 빅 엔디안(Big Endian) 바이트 순서(Byte Ordering)라고 하며 네트워크에서 전송될 때 TCP/IP에서 모든 이진수에 요구되는 바이트 순서이다. 이것을 네트워크 바이트 순서(Network Byte Order)라고 한다.
리틀 엔디안(Little Endian) 형태와 같이 이진수를 다른 형태로 저장하는 기계는 데이터 전송 전에 헤더의 값을 네트워크 바이트 순서로 바꾸어야 한다.

버전(Version)

현재 프로토콜의 버전은 4이며 따라서 때때로 IP를 IPv4라고 하기도 한다. 8장에서는 IP의 새로운 확장 버전인 IPv6에 대해 살펴볼 예정이다.

헤더 길이(Header Length)

선택사항(Option)을 포함한 헤더의 길이를 나타낸다. 이것은 4비트의 필드이기 때문에 헤더를 60바이트로 제한한다. 4(32비트)바이트를 기준으로 하기 때문에 헤더의 옵션 필드가 없을 경우, 즉 헤더가 20바이트일 경우에 5의 값이 들어간다.

Type-Of-Service(TOS)

3비트의 우선권(Precedence) 필드와 4비트의 TOS 필드, 그리고 값이 0인 사용되지 않는 1비트로 구성된다.
4비트의 TOS는 최소 지연, 최대 처리량, 최대 신뢰성, 최소 비용을 나타내는 필드로 구성되며, 이러한 4비트 중에서 단지 1비트만 설정될 수 있다. 4비트 모두 0이라면 일반적인 서비스를 의미한다.
그림 6-9는 다양한 어플리케이션에서 TOS 필드의 추천 값을 보여주고 있다.
Telnet 또는 Rlogin과 같은 대화형 로그인 어플리케이션은 적은 양의 데이터 전송을 대화형으로 사용하기 때문에 최소 지연을 필요로 한다. 한편 FTP에 의한 파일 전송은 최대 처리량을 요구한다. 네트워크 관리(SNMP)와 라우팅 프로토콜을 위해서 최대 신뢰성이 지정된다.

전체 길이(Total Length)

IP 데이터그램의 전체 길이를 바이트로 나타낸다. 이 필드는 16비트이므로 IP 데이터그램의 최대 크기는 65,535바이트이다.

식별자(Identification)

호스트가 보낸 각 데이터그램을 유일하게 식별한다. 단편화가 이루어질 때 플래그(flags) 필드와 단편화 옵셋(Fragmentation Offset) 필드가 사용된다. 분할된 패킷들은 동일한 식별자 값을 갖는다.

플래그

플래그는 세 개의 비트로 구성되어 있는데, 첫 번째 비트로 예약되어 있으며, 두 번째 비트는 단편화 금지(Don’t fragment) 비트이다. 이 비트가 1로 설정되어 있으면, 데이터그램을 단편화할 수 없다.
만약 데이터그램을 쪼개야 하는 네트워크를 지날 때 이 비트가 설정되어 있다면 데이터그램을 폐기시키고, 송신측 호스트에 ICMP 에러 메시지를 보내준다.
세 번째 비트는 More Fragment bit라고 한다. 이 값이 1이면 이 데이터그램이 마지막이 아니고, 뒤에 단편화된 데이터그램이 더 있음을 나타낸다.

단편화 옵셋

13비트로 구성되어 있으며, 단편화된 조각들을 하나의 데이터그램으로 합칠 때, 전체 데이터그램에서의 상대적인 위치를 나타낸다. 패킷이 모든 타입의 네트워크 상에서 전달될 수 있도록 IP는 반드시 데이터그램의 크기를 각 네트워크에 따라 적절히 조절하 룻 있어야 한다.
그림 6-10은 단편화가 이루어질 때 데이터 부분이 나누어지는 과정을 도식화한 것이다.

Time-To-Live(TTL)

데이터그램이 경유할 수 있는 라우터의 수(Hop Count)에 대한 상한을 설정한다. 즉 데이터그램의 생존 시간을 제한하는 것이다.
이 필드는 송신지에서 초기화되고, 각 라우터를 지날 때마다 라우터에 의해 1씩 감소된다. 이 필드가 0에 도달하면 그 데이터그램은 버려지고, 송신자는 ICMP 메시지를 받게 된다. 이것은 패킷의 무한 루프(loop)를 방지하기 위한 기능이다.

프로토콜(Protocol)

데이터그램의 상위 프로토콜 중 어느 것이 사용되는지를 나타내 주는 필드이다. 가장 많이 사용되는 TCP 프로토콜을 나타내는 값은 6이며, UDP 프로토콜을 나타내는 값은 17이다.

헤더 체크섬(Header Checksum)

이 필드는 IP 헤더에 대해서만 계산된다. 헤더 다음에 따라오는 어떤 데이터도 체크섬 하지 않는다. ICMP, IGMP, UDP, TCP는 모두 헤더와 데이터 전부를 포함하는 체크섬을 헤더 안에 가지고 있다.
내보내는 데이터그램에 대한 IP 체크섬을 계산하기 위해 먼저 체크섬 필드의 값은 0으로 설정된다. 그리고 헤더에 대한 16비트의 1의 보수의 합이 계산된 후에 이 16비트의 1의 보수의 합이 체크섬 필드에 저장된다.
IP 데이터그램이 수신되었을 때 16비트 1의 보수의 합이 계산되는데, 수신지의 계산된 체크섬은 송신지에서 저장한 체크섬을 가지고 있기 때문에 헤더 안에 아무것도 수저오디지 않았다면, 수신지의 체크섬이 모두 비트 1일 것이다.
결과가 모두 1이 아니면(체크섬 에러), IP는 수신된 데이터그램을 버리고 아무런 에러 메시지도 생성하지 않는다. 따라서 상위 계층에서 재전송에 대한 처리를 해줘야 한다.

IP 주소

모든 네트워크 장비들은 각각 고유한 주소를 가지는데 이를 IP 주소라고 한다. 전화기마다 고유의 전화번호가 할당되듯이, 네트워크에 등록된 컴퓨터들도 식별할 수 있는 고유의 번호가 부여된다.
32비트의 IP 주소를 보기 쉽게 표시하기 위하여, 네 바이트 단위로 나누고 이를 10진수로 표시하는 Dotted Decimal 표현 방식이 널리 사용되고 있다.
IP 주소는 네트워크를 구분하기 위한 네트워크 식별자(Netid) 필드와 한 네트워크 내에서 호스트를 구분하기 위한 호스트 식별자(Hostid) 필드의 두 부분으로 구성되며, 각 필드에서 사용되는 비트 수의 크기에 따라 그림 6-11과 같이 네 개의 클래스로 구분된다.

Class A: 첫 번째 바이트의 첫 비트가 0으로 시작

첫 바이트의 나머지 7비트가 네트워크 식별자이고, 뒤의 세 바이트가 호스트 식별자이며, 한 네트워크에 24비트의 호스트 식별자를 가질 수 있으므로, 약 224대의 호스트를 수용할 수 있다.

Class B: 첫 번째 바이트의 처음 두 비트가 10으로 시작

첫 번째 바이트의 나머지 6비트와 두 번째 바이트가 네트워크 식별자이고, 뒤의 두 바이트가 호스트 식별자이며, 한 네트워크에 약 216대의 호스트를 수용할 수 있다.

Class C: 첫 번째 바이트의 처음 세 비트가 110으로 시작

세 번째 바이트까지가 네트워크 식별자이고, 마지막 한 바이트가 호스트 식별자이며, 한 네트워크에 254대까지 수용할 수 있다.

Class D: 첫 번째 바이트의 처음 네 비트가 1110으로 시작

이 클래스는 멀티캐스트 주소로 사용된다. 목적지 주소가 D클래스인 패킷은 멀티캐스트 그룹에 연결된 모든 장비로 전달된다.
패킷은 전송하기 위한 목적지 대상에 따라 다음과 같이 구분된다.
유니 캐스트(Unicast)
보내는 패킷의 헤더에서 목적지가 하나의 호스트를 가리키는 경우의 IP 주소 타입이다.
멀티 캐스트(Multicast)
보내는 패킷의 헤더에서 목적지가 호스트들의 집합으로 이루어진 경우이다. 멀티캐스트를 사용하기 위해서는 먼저 네트워크 장비들이 표준안으로 정의된 멀티캐스트 주소를 인식하고 지원할 수 있어야 하며, 원하는 그룹 주소를 이용하여 그룹에 가입되어 있어야 한다.
브로드 캐스트(Broadcast)
주어진 네트워크의 모든 호스트에게 보내는 경우이며, 주소는 호스트 식별자에 255를 붙여서 사용한다.
각 클래스별 IP 주소의 범위와 주소의 수는 아래 표와 같다. 127로 시작하는 주소는 자기 자신을 가리키는 Loopback 주소로 사요오디기 때문에 Class A에서 127번으로 시작하는 주소는 제외되었다.
Class
주소 범위
주소 형태
가용 호스트 수
A
1~126
N.H.H.H
16,777,214
102.25.14.210
B
128~191
N.N.H.H
65,534
129.23.25.145
C
192~223
N.N.N.H
254
203.252.53.46
D
224~239
multicast ID
230.27.144.13

라우팅(Routing)

라우팅은 IP의 여러 가지 기능 중 가장 중요한 기능 중의 하나이다. 하나의 물리적인 네트워크 안에 있는 호스트들 사이에서의 IP 데이터그램 전송은 라우터를 사용하지 않고 직접 수행된다.
송신 호스트는 물리적 프레임 내에 데이터그램을 캡슐화시키고 ARP를 이용하여 목적지 IP 주소를 물리적 하드웨어 주소와 대응시킨 후에 목적지로 프레임을 직접 전송한다.
각각의 라우터는 라우팅 테이블을 가지고 있어서 이 테이블 안의 정보를 가지고 데이터그램 전송을 하게 된다.
특별한 IP주소
네트워크
호스트
송신
수신
네트워크 주소
Specific
0
X
X
직접 브로드캐스트 주소
N/W
All 1s
X
O
제한적 브로드캐스트 주소
All 1s
All 1s
X
O
네트워크의 자신 호스트
All 0s
All 0s
X
O
네트워크의 한 호스트
All 0s
Specific
O
X
루프백 주소
127
Any
X
O

서브넷팅(Subnetting)

IP 주소의 수가 한정되어 있으므로, 각 기관에서는 배정받은 하나의 네트워크 주소(Class A, B, C)를 다시 여러 개의 작은 네트워크로 나누어 사용하는 방법이 사용된다. 이때 주어진 네트워크 주소를 나누어 사용하는 것을 서브넷팅(Subnetting)이라고 한다.
4바이트 IP 주소 중에 네트워크 식별자 부분을 구분하기 위한 Mask를 서브넷 마스크(Subnet Mask)라고 하는데, Class A를 위한 디폴트 서브넷 마스크는 255.0.0.0 이고 Class B는 255.255.0.0이며 Class C의 경우는 255.255.255.0이 된다.
그림 6-12는 서브넷팅의 예를 나타낸다. 한 개의 Class A 주소를 나누어 사용하기 위하여 호스트 식별자로 8비트가 아닌 6비트만 사용하고, 네트워크 식별자로 24비트가 아닌 26비트를 사용하면, 이때의 서브넷 마스크는 255.255.255.192가 된다.
한편 호스트 주소(Hostid) 중에서 각 비트가 모두 1인 것은 방송용(Broadcast) 용으로 사용되며, 모두 0인 것은 자신을 나타내는 주소(Loopback)용으로 지정되어 있으므로, 이 두 개의 주소는 특정 호스트에 배정할 수 없다.

슈퍼넷팅(Supernetting)

인터넷이 매년 폭발적인 성장을 거듭하자 1992년에 이르면서 인터넷 라우팅 시스템의 확장성에 관한 심각한 염려가 IETF에서 제기되었다. 급격한 확장으로 인해 다음과 같은 문제가 대두된 것이다.
Class A와 Class B 네트워크 주소 공간의 고갈
Class C 주소가 할당 되면서 인터넷 라우팅 테이블 규모의 증대
32비트 IPv4 주소의 궁극적인 고갈
이전까지의 인터넷 성장 속도에 비추어서 위의 첫 번째와 두 번째 항은 곧 심각한 문제를 유발할 것으로 판단한 IETF는 ‘슈퍼넷팅(Supernetting)’ 또는 ‘CIDR(Classless Inter-Domain Routing)’이라는 새로운 개념을 도입하고, 1993년 9월에 이를 표준화하였다.
세번째 항에 대한 해결책으로는 128비트 주소 공간을 사용하는 IPv6가 사용될 예정이나, IPv4에서 IPv6로 전환하는데는 여러 사항들이 선행되어 해결되어야 하므로 그때까지 과도기적으로 슈퍼넷팅을 사용하려고 하였다.

사설 네트워크(Private Network)를 위한 주소 할당

RFC-1918 문서에서 사설 네트워크에서 인터넷과의 연동을 위한 사설 IP 주소 범위를 권고하고 있다.
현재 IP 주소의 부족 현상으로 인해 사설 네트워크를 가지고 있는 기업의 모든 네트워크 자원에 IP를 할당하기가 어렵기 때문에 사설 IP를 사용하게 되는데, 외부의 공인 IP 네트워크와 접속할 때 문제가 발생하지 않도록 하기 위해 이러한 권고안이 나온 것이다.
이러한 사설 주소를 사용할 떄에 공인 주소와 사설 주소 사이의 호스트와 네트워크를 접속하기 위해서는 NAT(Network Address Translation) 기능의 제공이 반드시 필요하다.

미니강의| NAT(Network Address Translation)

NAT는 외부 네트워크에 알려지는 공인 IP 주소와는 다른, 사설 IP를 사용하는 내부 네트워크에서 IP 주소를 변환하여 주는 것을 말한다.
일반적으로 한 회사는 자신의 내부 네트워크 주소를 하나 또는 그 이상의 공인 IP 주소로 매핑한다. 그리고 들어오는 패킷들 상의 공인 IP 주소를 다시 내부 네트워크에서 사용하는 사설 IP 주소로 변환한다.
이렇게 함으로써 나가거나 들어오는 각 요구들은 주소 변환과정을 반드시 거쳐야 하기 때문에 보안문제를 확실하게 하는데 도움이 되며, 또한 요구를 제한하거나 인증하고 이전의 요구와 일치시키는 기회를 제공한다.
NAT는 또한 회사에서 필요한 공인 IP 주소의 수를 보존하며, 회사가 외부 네트워크와의 통신에서 단 하나의 공인 IP 주소를 사용할 수 있게도 한다.

사설 주소 영역

IANA(Internet Assigned Numbers Authority)는 사설 인터넷을 위하여 아래 표와 같은 3가지의 IP 주소 블럭을 할당하여 놓고 있다.
IP 주소 블록
주소 범위
24비트 블록
10.0.0.0 - 10.255.255.255
20비트 블록
172.16.0.0 - 172.31.255.255
16비트 블록
192.168.0.0 - 192.168.255.255
24비트 블록은 하나의 Class A의 네트워크만을 갖는데 비해 20비트 블록은 16개의 연속적인 Class B 네트워크를, 16비트 블록은 256개의 연속적인 Class C의 네트워크만을 가진다.
여기서 지정한 주소영역을 벗어난 IP 주소를 사용하기로 결정한 기업은 인터넷에 접속할 수가 없다. 이러한 사설 주소 영역 안의 주소는 공인 인터넷상에서는 존재하지 않으므로 외부 네트워크와 접속이 용이하다.
인터넷으로 나가기 위한 IP 주소가 필요한 경우에는 반드시 인터넷 등록 업체로부터 공인 받은 IP를 사용하여야 한다.
지정된 사설 주소 영역을 사용할 경우 외부 네트워크와의 접속은 내부 라우터 등에서 그 기업에 할당된 공인 IP 주소로의 변환 기능을 통하여 가능하며 지정된 사설 주소 영역은 외부 공인 IP 네트워크에서는 존재하지 않으므로 네트워크 계층의 연결성을 확보할 수 있다.
만일 지정된 사설 주소 영역을 벗어날 경우는 사설 주소와 외부 공인 IP 네트워크의 주소 영역이 서로 간에 겹치게 되어 네트워크 계층의 연결성 확보는 어렵다. 즉 내부 호스트들은 기업 외부의 어떠한 호스트들과도 IP 연결성을 가질 수 없지만, 게이트웨이의 중재로 인하여 외부 서비스로의 접근은 할 수 있다.
게이트웨이는 공인 IP 주소를 확보하여야 하며 외부 네트워크가 접속하게 된다. 내부 네트워크의 호스트는 게이트웨이와 접속하여 어플리케이션 계층의 서비스를 받게 되며, 게이트웨이는 내부 네트워크 호스트를 대신하여 외부 네트워크와 네트워크 계층의 접속성을 확보한 다음 해당 어플리케이션에 대한 중재를 하게 된다.
예컨대 어느 기관에서 10.22.11.0부터 10.22.22.0까지의 비공인 주소를 할당 받았을 때, 공인된 인터넷 주소가 아니므로 외부로의 접속은 원칙적으로 불가능하지만, 게이트웨이를 거쳐서 외부의 네트워크에 접근이 가능해진다.
현재 널리 보급된 ADSL 같은 초고속망의 경우에도 모든 가입자에게 공인 IP를 할당하는 것이 아니라 동적으로 IP 주소를 할당해준다.
이는 IP 주소의 수요상 모든 고객에게 할당할 수 있는 주소공간이 부족한 것도 이유가 되겠지만, 동시에 모든 고객이 인터넷을 사용하지는 않으므로 어느 정도 가용 IP 주소를 할당해 놓고 필요한 고객에게 NAT를 거쳐서 IP를 할당해 주는 것이다.

UDP(User Datagram Protocol)

UDP 특성

UDP는 IP와 마찬가지로 신뢰성을 제공하지 않는다. UDP는 응용계층에 의하여 요청되는 데이터그램을 하위 IP 계층에 보낼 떄 사용하는 것으로, 그 데이터그램이 목적지에 제대로 도착하는지에 대한 신뢰가 보장되지 않는다.
하지만 UDP는 다음과 같은 특징을 가지고 있어서 TCP와 함께 널리 쓰이고 있다.

비연결형(Connectionless)

TCP는 데이터를 전송하기 전에 연결 설정을 맺는 반면, UDP는 연결설정 없이 데이터를 전송한다. 따라서 연결 설정을 위한 지연 시간이 걸리지 않으므로 DNS와 같은 서비스에서는 UDP를 사용함으로써 빠른 서비스를 제공한다.

비상태정보(Non-State)

TCP는 종단 시스템에서 연결에 대한 상태정보를 유지한다. 이 연결 상태에는 송수신의 버퍼, 혼잡제어 인자(Parameter), 순서번호와 확인번호 인자를 포함한다. 반면 UDP는 연결 정보나 여러 가지 인자에 대한 상태 정보를 저장하지 않는다.

경량의 오버헤드(Small Overhead)

TCP 세그먼트의 헤더는 20바이트인 반면, UDP는 8바이트의 크기를 가진다.

비정규적인 송신률(Unregulated Send Rate)

TCP에서 사용하는 혼잡제어 매커니즘은 송신측에서 보내는 데이터의 양에 제한을 준다. 따라서 일부 패킷의 손실이 생기더라도 최소 전송률을 요구하는 실시간 전송의 경우 UDP를 사용하는 것이 원하는 서비스를 제공할 수 있게 한다.

최선형 서비스(Best Effort)

TCP와 같이 수신측에서 응답을 기다리지 않고 바로 바로 원하는 서비스를 제공해 준다. 따라서 패킷 손실이 유발될 가능성도 있으나 서비스의 지연 없이 최선의 서비스를 제공할 수 있다.

UDP 헤더

그림 6-13은 UDP 헤더의 필드를 보여준다. 포트 넘버와 길이, 검사합의 구성으로 간단히 이루어져 있으며, 8바이트의 헤더 길이를 갖는다.

포트번호(Port Number)

송신 프로세스와 수신 프로세스를 구분해 준다. IP로부터 들어오는 데이터를 수신하기 위하여 목적지 포트 번호를 사용한다. TCP 포트 번호는 UDP 포트 번호와 서로 독립적이다.

UDP 길이(UDP Length)

UDP 헤더와 데이터의 바이트 길이를 합친 값이다. 이 필드의 최소 값은 8바이트이다.

UDP 체크섬(UDP Checksum)

IP 헤더 안의 체크섬은 IP 헤더만을 포함하는 것에 반해, UDP 체크섬은 UDP 헤더와 UDP 데이터를 모두 포함한다.
TCP에서는 강제적으로 체크섬을 수행하는 반면, UDP는 체크섬을 선택적으로 수행한다.

TCP(Transmission Control Protocol)

TCP 특성

TCP는 트랜스포트 계층의 프로토콜로서 IP가 제공하는 서비스를 기본적으로 이용하며, 네트워크 상에서 확실한 데이터의 전송을 보장하므로 데이터의 신뢰성이 보장된다.
또한 전송에 에러가 발생한 경우 자동으로 데이터를 재전송하므로 TCP를 사용하는 상위 계층은 수신측에서의 정상적인 데이터 수신에 대해 별도의 처리를 해 줄 필요가 없다.
TCP는 다음과 같은 특성을 가진다.

접속형(Connection-Oriented)

TCP를 사용하는 두 어플리케이션(보통 클라이언트와 서버)이 데이터를 서로 교환하기 전에 TCP 접속을 성립해야 함을 의미한다.

신뢰성(Reliability)

TCP는 전송한 데이터가 수신측에 올바르게 도착했는지를 확인하여 신뢰성 있는 통신을 수행한다. 다음은 TCP에서 신뢰성을 주는 전송 과정을 나타낸 것이다.
응용 데이터는 전송하기 위한 최적의 크기로 나누어진다. 이때 TCP에 의해 IP로 전달되는 단위는 세그먼트라고 불린다.
TCP가 세그먼트를 보낼 때 타이머를 유지하고, 수신측으로부터 세그먼트에 대한 응답인 승인을 기다린다. 만약 승인이 시간 내에 수신되지 않으면 세그먼트는 재전송 된다.
TCP가 접속의 수신측으로부터 데이터를 받으면 확인응답(Ack)을 보낸다.
TCP는 전송 중에 데이터의 변화를 발견하기 위해 헤더와 데이터에 체크섬을 유지한다. 만약 세그먼트가 잘못된 체크섬을 가지고 도착하면 TCP는 이 세그먼트를 버리고, 받은 것에 대한 확인응답을 보내지 않는다. 따라서 송신측에서는 타임 아웃되고, 재전송이 이루어진다.
TCP 세그먼트는 IP 데이터그램으로 전송되고, IP 데이터그램은 순서에 관계없이 전송 될 수 있기 때문에 TCP 세그먼트도 순서에 관계없이 도착될 수 있다. 수신하는 TCP는 전송된 데이터를 다시 순서대로 하고, 어플리케이션에 정확한 순서로 받은 데이터를 보낸다.

흐름 제어(Flow Control)

각 TCP 접속의 중단은 일정 크기의 버퍼 공간을 갖고 있다. 흐름 제어는 송신하는 TCP가 수신측이 갖고 있는 버퍼의 크기만큼 데이터를 보내도록 제어하여 처리 속도가 느린 수신측 호스트의 버퍼 크기를 넘치게 하는 것을 방지한다.

혼잡 제어(Congestion Control)

네트워크 내에 존재하는 패킷의 수가 과도하게 증가되는 현상을 혼잡(Congestion)이라고 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡 제어(Congestion Control)라고 한다.
컴퓨터 네트워크에 혼잡이 발생하면 네트워크 전체의 속도는 급격히 감소하게 되므로 혼잡이 발생하지 않도록 막는 것이 중요하다. 특히 네트워크 내의 특정 지역에서 국부적으로 혼잡이 발생하여도 혼잡 현상의 특성상 그 주위로 계속해서 확산될 가능성이 높다.
흐름제어는 송신자와 수신자 사이의 점대점 전송 속도를 다루는데 반해, 혼잡제어는 보다 넓은 관점에서 호스트와 라우터를 포함한 서브 넷에서의 전송 능력에 대한 문제를 다룬다. 이 두 방법의 고려 범위는 그림 6-14와 같다.
TCP에서는 혼잡을 회피하기 위한 방법으로 Slow-Start 알고리즘을 사용한다.

미니강의| Slow-Start Algorithm

송신측에서 Cwnd(Congestion Window)를 사용하여 연결초기에는 Cwnd=1로 설정하고, 수신측으로부터 Ack를 받기 전에는 오직 한 개의 패킷만 송신 가능하다.
이후 전송한 패킷에 대해 Ack를 받으면 Cwnd 값을 2로 증가시킨다(즉, RTT(Round Trip Time)마다 증가) 링크의 전송 속도가 포화될 때까지 Cwnd 값이 2, 4, 8, ...로 증가하며, 재전송이 발생되면 Cwnd=Cwnd/2의 값으로 조정하여 Congestion Avoidance Algorithm을 수행한다.

TCP 헤더

포트번호(Port Number)

TCP 세그먼트는 송신하고 수신하는 응용을 구분하기 위해 이것을 사용한다. IP 주소와 포트번호의 조합을 소켓(Socket)이라고 한다.
소켓은 통신 프로세스의 종단점을 식별하는 것으로 UNIX의 파일 접근 절차와 유사하다. 통신 프로세스의 포트번호와 호스트의 IP 주소를 하나로 묶어서 일컫는 말이다.

순서번호(Sequence Number)

송신측의 TCP로부터 수신측의 TCP로 가는 데이터 스트림의 바이트를 구분하기 위해 사용되는 순서번호이다. 32비트의 부호 없는 번호로서 0부터 232-1을 초과하면 다시 0으로 돌아간다.

확인응답번호(Acknowledgement Number)

수신한 마지막 바이트의 순서번호에 1을 더한 값이다. 이 필드와 Ack 플래그는 항상 설정된다.

헤더 길이(Header Length)

32비트 워드 단위로서 헤더의 길이를 지정한다. 이 필드는 옵션(option) 필드가 가변길이를 가지기 때문에 정확한 길이를 알기 위하여 필요하다. 4비트로 이루어져 있으므로 헤더의 최대 길이는 60바이트로 제한되어 있다.

6개의 플래그 비트

플래그 비트는 URG, ACK, PSH, RST, SYN, FIN의 6비트로 이루어지며 각각은 아래 표와 같은 의미를 갖고 있다.
플래그
의미
URG
긴급 포인터(urgent pointer)가 유효함
ACK
확인응답번호(acknowledgement number)가 유효함
PSH
데이터를 가능한 빨리 응용계츠응로 보내야 함. 즉 수신 후에 버퍼가 다 찰때까지 기다리지 않고 받는대로 응용 계층으로 올린다.
RST
연결을 재설정
SYN
연결을 초기화하기 위해 순서번호(sequence number)를 동기화
FIN
송신측이 데이터 전송을 종료함

체크섬(Checksum)

TCP 헤더와 TCP 데이터에 대한 체크섬을 수행한다. 필수 필드로써 송신측에서 계산하여 저장된 값을 수신측에서 검사하여 에러를 검출하기 위한 필드이다.

긴급 포인터(Urgent Pointer)

URG 플래그가 설정되어 있을 때만 유효한 값을 가진다. 송신측에서 데이터를 긴급히 보낼 때 사용되는 방법이다.

응용 프로토콜

TCP/IP는 궁극적으로 상위 계층의 여러 프로토콜을 사용하여 서비스를 제공하는 다양한 응용 계층의 프로토콜을 지원하기 위한 것이다.
TCP/IP에는 보편적으로 많이 사용하는 DNS(Domain Name System), TELNET, FTP, SMTP(Simple Mail Transfer Protocol) 등의 프로토콜이 있다.

DNS(Domain Name System)

DNS는 호스트의 이름과 IP 주소를 매핑하여 주는 거대한 분산 네이밍 시스템이다.
인터넷에서 사용되는 IP와 IP의 상위에서 동작하는 익스플로러와 같은 응용 프로그램들은 203.252.53.46과 같은 IP 주소만을 인식하는데, 이러한 주소는 사람은 기억하기 어렵기 때문에 인터넷의 도입 시절인 ARPANET 시절부터 IP Address를 구분이 손쉬운 이름으로 명명하여 사용하고자 하는 노력이 시도되었고, 많은 시행착오를 거치면서 지금의 DNS 메커니즘으로 발전하였다.
ARPANET 시절에는 호스트의 수가 많지 않았기에 NIC(Network Information Center)로부터 일정 주기마다 호스트 명단 파일(HOSTS.TXT)을 받아 /etc/hosts에 저장하여 사용하였었다.
그러나 점차 인터넷의 규모와 호스트 수가 증가함에 따라 새로운 이름 명명 체제의 필요성이 대두되었고, 1983년 Paul Mockapetris가 RFC882, RFC883(현재는 RFC1034로 대체됨)에 새로운 명명 체제에 대한 구현을 공식 발표하며, 크게 네임스페이스의 계층 구조, 분산 데이터베이스, E-mail 라우팅 개선을 주안점으로 DNS가 탄생하였다.

DNS 이름체계

ARPANET의 중앙 관리 체제에서는 하나의 파일로 모든 호스트들을 관리하였지만, DNS에서는 이것을 각 도메인별로 트리화하여 그림 6-16과 같은 형태로 관리한다.
위의 그림에서 보듯이 디렉터리 구조와 유사함을 알 수 있는데, Root Domain은 Top Level 도메인에 관한 정보를, Top Level 도메인은 그 하위 도메인에 관한 정보를 유지/관리하는 구조를 취한다.
이러한 정보의 계층구조로 인하여 정보는 각 도메인의 네임서버(Name Server)로 분산, 관리된다.

도메인 네임 변환

통신을 위한 TCP/IP 패킷엔 도메인 이름을 위한 공간이 없다. 따라서 도메인 이름에 대한 IP 변환작업(Resolving)을 선행하게 되는데, 그림 6-17은 이러한 변환 과정을 보여준다.
1.
Client 상의 응용이 ‘www.skku.ac.kr’에 접속하기 위해 자신의 Local Name Server에 질의한다.
2.
Local NS는 먼저 자신의 캐쉬에 자료가 있는지 확인한 후 발견되지 않을 시 Root NS에 질의를 던진다.
3.
NS도 ‘www.skku.ac.kr’의 자료를 갖고 있지 않으므로, kr 도메인을 관리하는 NS를 참고하라는 답변을 보내준다.
4.
Local NS는 다시 kr NS에 질의를 던지고, kr NS는 다시 ac.kr의 NS를 일러준다. (루트와 kr 도메인은 Root NS에서 같이 관리되기 때문에 실제로 본 과정은 일어나지 않고 (2)번에서 바로 ac.kr의 NS를 참고하라는 답변이 나온다)
5.
Local NS는 ac.kr NS에 질의하고 마찬가지로 skku.ac.kr NS를 참고하라는 답변을 보낸다.
6.
Local NS는 다시 skku.ac.kr NS에 질의한다. skku.ac.kr NS는 서브도메인에 대한 자료를 관리하는 실제 NS이므로 ‘www.skku.ac.kr’에 대한 IP 주소인 203.252.32.4를 반환한다.
7.
마지막으로 Local NS는 Client에 결과를 전송한다.

TELNET

TELNET은 특정 지역의 사용자가 지역적으로 떨어진, 다른 곳에 위치한 컴퓨터를 온라인으로 연결 및 연동하여 사용하는 서비스를 말한다. 일단 원격 시스템에 연결되면 이용자는 마치 하드웨어적으로 직접 연결된 단말기에서처럼 연결한 원격 컴퓨터를 사용할 수 있다.
이것을 이용하여 원격지의 시스템에 접속하여 정보를 조회하고, 데이터베이스, 파일 등에 접속하여 서비스를 제공받을 수 있다. TELNET의 특징을 간략히 정리하면 다음과 같다.
원격으로 특정 컴퓨터 기기에 접속할 수 있도록 하는 프로토콜
특정지역의 사용자가 다른 곳에 위치한 컴퓨터를 온라인으로 연결하여 사용하는 서비스
네트워크를 통한 원격 로그인 또는 가상 터미널 기능을 제공하기 위한 프로토콜
TELNET은 인터넷에서 제공하는 웹 서비스처럼 일반에게 공개하는 서비스가 아니므로 접속하려는 호스트에 사용자 또는 관리자 계정을 갖고 있어야만 한다.
TELNET은 클라이언트-서버의 모형을 갖는다. 그림 6-18은 TELNET 클라이언트-서버의 전형적인 구조를 보여준다.
TELNET 클라이언트는 터미널의 사용자와 TCP/IP 프로토콜을 중개한다. 일반적으로 사용자가 입력하는 것은 TCP 연결을 통하여 보내지고 그 연결을 통하여 수신된 것이 상대방의 터미널에 출력된다.
TELNET 서버는 보통 (특히, 유닉스 시스템에서는) 의사-터미널 장치(Pseudo-Terminal)를 다룬다. 이것은 서버에 로그인 쉘을 가동시키며, 로그인 쉘에 의해 프로그램이 가동되고 터미널 장치에게 대화를 하게 만든다. 스크린 에디터 같은 일부 응용 프로그램은 터미널 장치에게 대화하는 것으로 가정한다.
하나의 TCP 연결이 사용된다. TELNET 클라이언트가 TELNET 서버와 대화를 해야 할 때 연결 사이에 사용자 데이터에 대한 명령을 나타내는 방법이 필요하다.
서버에 접속해야 할 때는 시스템의 계정을 가지고 있어야 한다.

FTP(File Transfer Protocol)

일반적으로 많이 사요오디는 응용 프로토콜의 하나로서, 파일 전송을 위한 인터넷 표준이다. FTP가 제공하는 파일 전송은 한 시스템에서 다른 시스템으로 파일을 복사해 준다.
FTP를 사용하기 위해서는 서버에 로그인할 수 있는 계정이 필요하거나 anonymous FTP를 허용하는 서버에 로그인 하는 것이 필요하다.
TELNET과 마찬가지로 FTP는 서로 다른 운영 체제, 파일 구조, 문자 집합을 사용하는 호스트들 사이에서 작동할 수 있도록 설계되었다.
FTP의 특징을 정리하면 다음과 같다.
파일 전송은 FTP 접근을 허용하는 컴퓨터에 사용자 계정이 등록된 사람들만 가능하다.
인터넷을 통하여 서로가 필요한 파일을 공유하고 교환하기 위하여 누구라도 접속할 수 있는 익명의 계정(anonymous)을 이용하여 파일을 전송할 수 있는 방법이 있다.
Anonymous FTP 접속은 계정과 암호(password)가 필요 없고 anonymous 라는 계정을 사용한다.
동시에 접속할 수 있는 최대 인원수가 제한될 수 있다.
그림 6-19는 클라이언트와 서버 간의 두 개의 연결 구성을 나타내고 있으며, 대화식 사용자가 제어 연결을 통해 교환되는 명령과 응답을 직접 처리하지는 않는다는 것을 보여준다. 즉 FTP에서는 제어용 접속을 위해서 포트번호 21로 접속하며, 접속이 이루어진 후에 데이터의 전송은 포트번호 20으로 연결이 이루어진다.

SMTP(Simple Mail Transfer Protocol)

SMTP는 RFC 821에 명시되어 있는 인터넷 전자 우편을 위한 프로토콜이다. SMTP는 TCP 포트 25번을 사용하며, TCP/IP 프로토콜 중에서 많이 사용되는 응용 프로토콜의 하나이다. SMTP는 인터넷을 통하여 전자메일(E-Mail)을 보낼 때 사용된다. E-Mail의 동작원리는 다음과 같다.
1.
송신자가 보낸 편지가 일단 송신자 측의 전자우편을 관리하는 메일서버에 전달한다.
2.
메일 서버는 수신자의 전자우편 주소를 분석해서 최단 경로를 찾아 근접한 메일 서버에게 편지를 전달한다.
3.
최종 수신자 측의 메일 서버에 도착하기까지 연속적으로 전달하는 중계 작업이 계속된다.
SMTP는 위와 같은 동작을 지원하기 위한 프로토콜이며, 서로 근접한 메일 서버 간에 전자 우편을 중계해 가는 방법은 저장 후 전송(Store-and-Forward)이다.