Practical guide to content delivery networks 1-7

3. UNDERSTANDING TCP/IP

 기술적인 세부 사항을 이해하는 능력은 TCP/IP 프로토콜 스위트를 이해하는 것을 필요로 합니다. 이 장에서는 응용 프로그램의 식별과 IP 데이터그램의 전달을 관리하는 필드에 중점을 두고 TCP/IP 프로토콜 스위트를 간략하게 검토할 것입니다.

3.1 The TCP/IP Protocol Suite

 TCP/IP 프로토콜 스위트는 1970년대와 1980년대 초에 고등 연구 계획국(ARPA)의 연구에서 시작되었습니다. 이 기간 동안 컴퓨터를 상호 연결하려는 노력의 일환으로 일련의 프로토콜이 개발되었고, 이는 현대의 TCP/IP 프로토콜 스위트로 발전하게 되었습니다.

Figure 3.1 Major components of the TCP/IP protocol suite

 

3.1.1 Protocol Suite Components 그림 3.1은 TCP/IP 프로토콜 스위트의 주요 구성 요소와 국제 표준화 기구(ISO) 개방형 시스템 상호 연결(OSI) 참조 모델과의 관계를 보여줍니다. 그림 3.1을 살펴보면, TCP/IP 프로토콜 스위트는 물리 계층과 데이터 링크 계층을 명시하지 않는다는 점을 알 수 있습니다. 대신, 프로토콜 스위트는 주소 결정 프로토콜(ARP)을 사용하여, ARP 메시지를 전송하고 응답할 수 있는 모든 데이터 링크 계층 위에서 작동할 수 있도록 합니다. 이를 통해 TCP/IP 프로토콜 스위트는 이더넷, 패스트 이더넷, 기가비트 이더넷, 토큰 링(Local Area Networks, LAN)과 상호 운용할 수 있습니다.

 

 그림 3.1에 나타난 TCP/IP 프로토콜 스위트와 OSI 참조 모델 간의 관계를 살펴볼 때, 몇 가지 추가로 주목할 사항이 있습니다. 첫째, 프로토콜 스위트에서 응용 프로그램은 5계층에서 전송되지만, 이는 OSI 참조 모델의 5, 6, 7 계층에 해당합니다. 둘째, 응용 프로그램은 일반적으로 두 가지 전송 프로토콜 중 하나인 TCP 또는 UDP에 의해 전송됩니다. 이 장에서 더 자세히 설명하겠지만, TCP는 연결 지향적이고 신뢰할 수 있는 전송 기능을 제공하는 반면, UDP는 최선의 노력 방식으로 비신뢰적 전송을 제공합니다. TCP 및 UDP에 의해 전송되는 응용 프로그램은 각각의 전송 계층 헤더에 있는 목적지 포트 필드를 통해 식별됩니다. TCP가 사용될 때, TCP 헤더와 응용 프로그램 데이터는 “TCP Segment”라고 불리며, 반면에 UDP가 전송 계층으로 사용될 때, UDP 헤더와 응용 프로그램 데이터는 “UDP Datagram”이라고 불립니다. IP 데이터그램은 TCP 세그먼트 또는 UDP 데이터그램에 IP 헤더를 접두사로 추가하여 형성됩니다. IP 헤더에는 출발지와 목적지 주소 필드가 포함되어 있어, 라우팅은 IP 헤더 필드를 통해 이루어집니다. 다양한 응용 프로그램은 TCP 또는 UDP 헤더 내의 포트 번호를 사용하여 식별되며, 이를 통해 예를 들어 하나의 목적지 서버(예: 기업 서버)가 웹, 이메일, 파일 전송 지원을 제공할 수 있게 됩니다. 프로토콜 스위트에 대해 더 깊이 탐구하면, 특정 장치로 향하는 응용 프로그램을 정의하기 위해 IP 주소와 TCP 및 UDP 포트 번호가 어떻게 사용되는지가 더 명확해질 것입니다.

 

3.1.2 Physical and Data-Link Layers 물리 계층은 네트워크에 연결하는 데 필요한 전기적 및 기계적 구성 요소를 나타냅니다. 반면, 데이터 링크 계층은 네트워크에서 흐르는 데이터 패킷으로 정보를 그룹화하는 프로토콜을 사용합니다. 데이터 링크는 2계층 프로토콜을 사용하므로, 출발지와 목적지 주소는 매체 접근 제어(MAC) 주소로 표시됩니다.

 

3.1.2.1 MAC Addressing MAC 주소는 48비트 또는 6바이트 길이로, 공급업체 코드와 이 코드에 대응하는 식별자로 나뉩니다. IEEE는 공급업체 코드를 할당하고, 공급업체 또는 제조업체는 할당된 공급업체 코드를 사용하여 각 LAN 어댑터의 읽기 전용 메모리(ROM)에 고유한 48비트 주소를 기록합니다. 이 과정에서 각 어댑터는 식별자 번호가 서로 다릅니다. 공급업체가 LAN 어댑터 마케팅에 성공하면, IEEE에 추가 공급업체 코드를 요청하고 앞서 설명한 과정을 반복합니다. MAC 주소를 사용하면 LAN 내에서 중복 주소가 발생하지 않지만, 네트워크 식별자가 없으면 로컬 영역 네트워크(LAN) 간의 연결이 어렵습니다. 즉, LAN 식별자가 없으면 2계층 프레임의 목적지 LAN을 확인하기 어려워집니다. 실제로 LAN 간의 데이터 라우팅 방식은 원래 48비트 MAC 주소를 사용하여 프레임이 브리지를 넘을지 여부를 결정하는 2계층 기술인 브리징에 기반했습니다. 초기 브리지는 서로 가까운 곳에 위치한 LAN을 상호 연결했기 때문에, 다른 도시에 있거나 동일한 도시 내 다른 위치에 있는 LAN을 연결하는 것이 어려웠습니다. 이러한 제한을 극복하기 위해, TCP/IP와 같은 네트워크 계층에서 작동하는 네트워크 프로토콜은 각 네트워크에 고유한 네트워크 주소를 할당할 수 있게 하여, 각 패킷에 포함된 목적지 네트워크 주소를 기반으로 네트워크 간의 데이터를 라우팅할 수 있게 했습니다. TCP/IP 프로토콜 스위트에서 네트워크 계층을 논의하기 전에, 네트워크 계층과 데이터 링크 계층 간의 “다리” 역할을 하는 ARP의 사용에 대해 설명할 필요가 있으며, 이것이 그림 3.1에서 ARP의 위치를 설명하는 이유입니다. ARP에 대해 논의하기 전에, TCP/IP 프로토콜 스위트에서 3계층 주소 지정에 관한 몇 가지 사항을 다루어야 합니다.

 

3.1.2.2 Layer 3 Addressing 오늘날 두 가지 버전의 인터넷 프로토콜(IP)이 사용되고 있으며, 이를 IPv4와 IPv6라고 합니다. IPv4는 32비트 주소 체계를 사용하고, IPv6는 128비트 주소를 사용합니다. 현재 약 99%의 조직이 IPv4를 사용하고 있으므로, 이 섹션에서는 IPv4에서 사용하는 32비트 주소 체계에 중점을 둘 것입니다.

Figure 32 IP address classes

 

 IPv4에서는 Class A부터 Class E까지 다섯 가지 주소 클래스가 있으며, 이 중 처음 세 가지 주소 클래스는 네트워크와 호스트 부분으로 구분됩니다(그림 3.2 참고).

 

 Class A 주소는 매우 큰 조직에 할당되었습니다. 그림 3.2를 살펴보면, 32비트 주소의 네 개의 8비트 바이트 중 하나는 네트워크를 나타내는 데 사용되고, 나머지 세 개의 바이트는 네트워크의 호스트를 식별하는 데 사용된다는 것을 알 수 있습니다. 일반적으로 8비트 바이트는 256개의 고유한 주소를 제공하지만, IPv4에서는 첫 번째 비트를 이진 1로 설정하여 Class A 주소를 식별하므로, 주소에서 사용할 수 있는 고유 비트 수가 7개로 줄어듭니다. 따라서 최대 128개의 Class A 주소만 존재할 수 있습니다. Class A 주소 중 하나는 루프백 주소로 사용되며, IP 주소 0.0.0.0은 기본 네트워크에 사용되므로, 사용 가능한 Class A 주소 수는 126개로 줄어듭니다. Class A 네트워크 주소의 세 바이트가 각 호스트를 식별하는 데 사용되기 때문에, 각 Class A 네트워크는 2³² - 2, 즉 16,777,214개의 고유한 호스트를 지원할 수 있습니다. 여기서 2를 빼는 이유는 모든 0의 호스트 주소는 네트워크(“이 네트워크”)를 나타내며, 모든 1의 호스트 주소는 네트워크 브로드캐스트 주소를 나타내기 때문입니다.

 

 그림 3.2로 다시 돌아가 보면, Class B 주소는 네트워크를 식별하는 데 사용되는 바이트 수를 두 개로 확장하여, 네트워크에서 호스트를 식별하는 데 사용되는 바이트 수가 두 개가 됩니다. 32비트 주소에서 처음 두 비트는 Class B 주소를 식별하는 데 사용되므로, 네트워크를 식별하는 데 14비트가 사용되어 2¹⁴(16,384)개의 고유 네트워크를 식별할 수 있습니다. 따라서 Class A 주소보다 훨씬 많은 Class B 주소를 사용할 수 있습니다. 각 Class B 네트워크는 네트워크에서 호스트 주소를 정의하는 데 두 바이트를 사용하므로, 각 Class B 네트워크는 2¹⁶ - 2, 즉 65,534개의 가능한 호스트를 가질 수 있습니다. Class B 주소는 일반적으로 대형 조직에 할당되었습니다.

 

 세 번째로 네트워크와 호스트 부분으로 나뉘는 IPv4 주소는 Class C 주소입니다. Class C 주소는 세 개의 바이트를 사용하여 네트워크 부분을 정의하고, 나머지 하나의 바이트는 네트워크에서 호스트를 식별하는 데 사용됩니다. Class C 주소는 또한 첫 번째 바이트의 처음 세 비트를 사용하여 Class C 주소로 식별됩니다. 따라서 2²¹(2,097,152)개의 고유한 Class C 네트워크 주소가 있습니다.

 

 Class C 네트워크 주소는 가장 많이 사용되는 IP 주소로, 일반적으로 소규모에서 중간 규모의 조직에 할당됩니다. 그러나 네트워크에서 호스트를 정의하는 데 사용할 수 있는 바이트가 하나뿐이므로, Class C 주소는 가장 적은 수의 네트워크 호스트를 지원합니다. Class C 네트워크의 고유 호스트 수는 2⁸ - 2, 즉 254로 제한됩니다. 이전 계산에서 2를 빼는 이유는 Class A와 Class B 주소와 마찬가지로, 두 개의 Class C 주소가 특별한 의미를 가지며 네트워크에서 특정 호스트를 식별하는 데 사용되지 않기 때문입니다. 이 주소들은 0과 255입니다. 호스트 주소 0은 “이 네트워크”를 나타내는 데 사용되며, 호스트 주소 255는 네트워크의 브로드캐스트 주소를 나타냅니다. 따라서 이 두 주소를 호스트 주소로 사용할 수 없기 때문에, Class C 네트워크에서는 254개의 호스트만 고유 주소를 가질 수 있습니다.

 

 Class A, B, C가 가장 일반적으로 사용되는 IPv4 주소이지만, 두 가지 추가 주소 클래스인 Class D와 Class E도 잠시 언급할 가치가 있습니다. Class D 주소는 멀티캐스트 작업에 사용되며, Class E 주소는 실험을 위해 예약되어 있습니다.

이제 IPv4 주소의 다섯 가지 유형을 이해했으니, 네트워크 주소가 MAC 주소로 변환되는 방식에 대해 알아보겠습니다. 이 변환은 앞서 언급했듯이 주소 결정 프로토콜(ARP) 을 사용하여 수행됩니다.

 

 3.1.2.3 ARP 라우터가 특정 네트워크와 그 네트워크의 호스트로 주소가 지정된 IPv4 패킷을 수신할 때, 목적지 주소는 32비트 주소로 지정됩니다. 그러나 로컬 네트워크에서 데이터 전송은 2계층의 MAC 주소를 기반으로 이루어집니다. 즉, 라우터가 수신한 32비트 3계층 IP 주소는 패킷이 2계층 프로토콜에 의해 전달되기 위해 48비트 MAC 주소로 변환되어야 합니다.

 

 라우터가 3계층 패킷을 수신하면 먼저 캐시 메모리를 확인하여 이전에 주소 변환이 발생했는지 확인합니다. 만약 이전에 주소 변환이 발생했다면, 라우터는 학습된 2계층 MAC 주소를 프레임의 목적지 주소로 사용하여 3계층 패킷을 전달하기 위한 2계층 프레임을 형성합니다. 이전에 주소 변환이 발생하지 않았다면, 라우터는 ARP를 사용하여 3계층 목적지 주소와 연결된 2계층 주소를 결정하는 메커니즘을 사용합니다. 이 과정에서 라우터는 필요한 IP 주소를 나타내는 ARP 패킷을 생성하고, ARP 패킷은 네트워크의 모든 호스트에 2계층 브로드캐스트로 전송됩니다. 지정된 IP 주소로 구성된 호스트는 브로드캐스트에 자신의 MAC 주소로 응답합니다. 따라서 라우터는 ARP를 사용하여 2계층 네트워크에서 3계층 주소가 지정된 패킷을 정확한 목적지로 전달하는 데 필요한 MAC 주소를 학습하게 됩니다.

 

 ARP를 사용하여 3계층 주소로 지정된 패킷을 2계층 네트워크에서 전달하는 방법을 이해한 후에는 TCP/IP 프로토콜 스위트의 상위 계층으로 주의를 돌릴 수 있습니다.

 

3.1.3 The Network Layer 인터넷 프로토콜(IP)은 IP 데이터그램을 출발지 네트워크에서 목적지 네트워크로 라우팅할 수 있도록 하는 네트워크 계층 프로토콜을 나타냅니다. 그림 3.3은 IP 헤더와 TCP/IP 프로토콜 스위트에서 일반적으로 사용되는 두 가지 전송 계층 헤더(TCP 및 UDP)의 관계를 보여주며, IP 데이터그램이 형성되는 과정을 설명합니다. 응용 프로그램 데이터는 IP 헤더가 접두사로 추가되기 전에 먼저 TCP 또는 UDP 헤더가 접두사로 추가됩니다.

 

 IP 헤더는 특정 필드로 세분화된 20바이트의 정보를 포함합니다. IP 헤더에는 헤더를 선택적으로 확장할 수 있는 옵션이 있으며, 선택적인 바이트를 추가하여 헤더를 확장할 수 있지만, 이 확장은 거의 사용되지 않습니다.

 

Figure 3.3 Forming and IP datagram.

 

3.1.3.1 IP Header 그림 3.4의 상단 부분은 IPv4 헤더 내의 필드를 나타내고 있으며, 하단 부분은 각 IPv4 헤더 필드에 대한 간단한 설명을 제공합니다. 콘텐츠 전송의 관점에서 중요한 필드는 TTL(Time to Live) 필드와 프로토콜 필드, 그리고 32비트 출발지 IP 주소 및 32비트 목적지 IP 주소 필드입니다.

 

3.1.3.1.1 TTL Field TTL(Time to Live) 필드는 IP 패킷이 폐기되기 전에 통과할 수 있는 홉(hop)의 수를 나타냅니다. 이 필드의 목적은 목적지를 찾지 못할 경우 패킷이 인터넷을 계속해서 떠돌아다니지 않도록 보장하는 것입니다. 무한한 경로 탐색을 방지하기 위해 라우터는 TTL 필드 값을 감소시키며, 그 결과가 0이 되면 패킷을 폐기합니다. 콘텐츠 전송 네트워킹 환경에서는 웹 서버 데이터를 요청자에게 더 가까운 곳으로 이동시키는 것이 일반적이기 때문에 TTL 필드 값이 0에 도달하여 패킷이 폐기되는 상황을 방지할 수 있습니다.

 

3.1.3.1.2 Protocol Field 프로토콜 필드는 8비트 길이로, IP 데이터그램 내에서 운반되는 전송 패킷의 유형을 나타냅니다. 프로토콜 필드는 8비트 길이이므로 최대 256개의 프로토콜을 정의할 수 있습니다. 가장 널리 사용되는 프로토콜 중 일부는 인터넷 제어 메시지 프로토콜(ICMP, 1번), 전송 제어 프로토콜(TCP, IP 프로토콜 필드에서 6번으로 정의됨), 사용자 데이터그램 프로토콜(UDP, IPv4 헤더의 프로토콜 필드에서 17번으로 정의됨)입니다. 따라서 IPv4 프로토콜 필드 값은 데이터를 전송하는 상위 계층 프로토콜을 정의합니다. 이 장의 후반부에서 TCP와 UDP 헤더 모두 전송 계층에서 운반되는 응용 프로그램을 정의하는 포트 필드를 포함하고 있음을 다룰 것입니다.

 

Figure 3.4 The IPv4 header.

 

3.1.3.1.3 Source and Destination Address Fields IPv4 헤더에서 콘텐츠 전송과 관련하여 중요한 나머지 두 개의 필드는 출발지와 목적지 IP 주소입니다. 각 주소는 32비트 길이로, 출발지 주소는 패킷의 발신자를 나타내며, 목적지 주소는 패킷의 최종 수신자를 나타냅니다.

 

 이 장에서 앞서 설명한 바와 같이, IPv4에서는 A부터 E까지 다섯 가지 주소 클래스가 있습니다. 인터넷에서 발생하는 데이터 트래픽의 대부분은 클래스 A, B, C 주소를 사용하며, 클래스 D는 멀티캐스트 전송에 사용되고, 클래스 E는 실험용으로 예약되어 있습니다. 클래스 A, B, C 주소와 관련해서는, 각 클래스의 목적지 주소가 네트워크 부분과 호스트 부분으로 나뉩니다. 따라서 이러한 주소를 사용하면 패킷이 향하는 네트워크와 그 네트워크에서 패킷이 향하는 호스트를 나타낼 수 있습니다.

 

 이제 출발지와 목적지 IPv4 주소가 정보를 전달하는 방식을 대략적으로 이해했으니, 프로토콜 스위트에서 한 단계 위로 올라가 TCP와 UDP가 어떻게 전송되는 응용 프로그램을 나타내는지 살펴보겠습니다. 또한, 두 전송 계층 프로토콜 간의 주요 차이점도 살펴볼 것입니다.

 

3.1.4 The Transport Layer TCP/IP 프로토콜 스위트에서 전송 계층은 ISO 참조 모델의 4계층과 동일합니다. IPv4 헤더의 프로토콜 필드는 최대 256개의 상위 계층 프로토콜을 정의할 수 있지만, 프로토콜 스위트에서 일반적으로 사용되는 두 가지 전송 계층 프로토콜은 전송 제어 프로토콜(TCP)과 사용자 데이터그램 프로토콜(UDP)입니다.

 

 3.1.4.1 TCP 전송 제어 프로토콜(TCP)은 신뢰할 수 있고 연결 지향적인 프로토콜을 나타냅니다. TCP는 오류 감지 및 수정 기능을 포함하고 있기 때문에 신뢰성을 확보합니다. 또한, 수신자가 데이터를 실제로 교환하기 전에 자신의 존재를 알려야 하는 삼중 핸드셰이크 방식의 연결 지향적인 방법을 지원합니다. 그림 3.5는 TCP 헤더의 형식을 보여줍니다. 콘텐츠 전송 관점에서 중요한 것은 출발지 및 목적지 포트이며, 이들의 값은 전송 중인 응용 프로그램을 식별합니다. 출발지 및 목적지 포트 필드는 각각 16비트 길이입니다. 이 포트들의 사용에 대해 논의하기 전에, TCP 헤더 내의 다른 필드들에 대해 간단히 언급할 필요가 있습니다. 따라서 TCP가 신뢰할 수 있고 연결 지향적인 4계층 프로토콜로 간주되는 이유를 이해하기 위해 몇 가지 필드를 빠르게 검토하겠습니다.

 

Figure 3.5 The TCP header

 3.1.4.1.1 Sequence Number 시퀀스 번호 필드는 32비트 길이입니다. 이 필드는 TCP 세그먼트의 첫 번째 바이트의 시퀀스 번호를 포함하며, SYN 비트(플래그 필드에 있음)가 설정되지 않은 경우 그렇습니다. 만약 SYN 비트가 설정된 경우, 시퀀스 번호는 초기 시퀀스 번호(ISN)가 되며, 첫 번째 데이터 바이트는 ISN + 1이 됩니다.

 

3.1.4.1.2 Acknowledgment Number Field 확인 번호 필드는 32비트 길이입니다. ACK 제어 비트(플래그 필드에 있음)가 설정된 경우, 확인 번호 필드는 TCP 세그먼트를 보낸 송신자가 다음에 수신하기를 기대하는 시퀀스 번호를 포함합니다. 연결이 설정된 후에는 항상 다음 시퀀스 번호가 확인 번호 필드에 나타납니다. 따라서 시퀀스 번호와 확인 번호 필드는 수신자가 세그먼트를 올바른 순서로 수신하도록 보장하는 방법을 제공할 뿐만 아니라, 세그먼트가 손실되었는지 여부를 확인할 수 있는 메커니즘도 제공합니다.

 

3.1.4.1.3 Window Field 윈도우 필드는 16비트 길이입니다. 이 필드는 확인 필드에 표시된 데이터 바이트부터 세그먼트의 송신자가 수신할 준비가 된 데이터 바이트의 수를 나타냅니다. 따라서 윈도우 필드의 항목은 흐름 제어 메커니즘으로 볼 수 있습니다. 작은 값은 세그먼트당 데이터 전송을 줄이고, 큰 값은 세그먼트당 전송되는 데이터 양을 늘립니다.

 

3.1.4.1.4 Checksum Field 체크섬 필드는 윈도우 필드와 필드 길이가 동일하게 16비트입니다. 체크섬 필드는 TCP 헤더와 텍스트 내의 모든 16비트 단어의 1의 보수 합에 대한 1의 보수를 포함합니다. 만약 TCP 세그먼트가 홀수 개의 바이트를 포함하는 경우, 체크섬을 위해 0으로 패딩된 추가 바이트가 추가되어 16비트 단어가 형성되지만, 이 패딩된 바이트는 TCP 세그먼트의 일부로 전송되지 않습니다. 체크섬은 TCP 헤더 앞에 개념적으로 추가되는 96비트 가상 헤더도 포함합니다. 이 가상 헤더는 출발지 및 목적지 주소 필드, 프로토콜 필드, 그리고 TCP 길이 필드로 구성됩니다. 이러한 필드를 포함한 체크섬의 목적은 잘못된 경로로 전송된 세그먼트에 대한 보호를 제공하여, 이 전송 프로토콜의 신뢰성을 향상시키는 것입니다.

 

 이제 TCP에 대한 개요를 이해했으니, TCP/IP 프로토콜 스위트의 두 번째로 널리 사용되는 전송 프로토콜인 사용자 데이터그램 프로토콜(UDP) 에 대해 살펴보겠습니다.

 

3.1.4.2 UDP 사용자 데이터그램 프로토콜(UDP)은 신뢰할 수 없는 최선의 노력 방식의 전송 프로토콜을 나타냅니다. TCP와 달리, 데이터 전송 전에 수신자가 존재하는지 확인하는 연결 설정이 필요하지 않습니다. 따라서 UDP는 응용 프로그램이 일정 시간 동안 응답이 없으면 세션을 종료할지 여부를 결정해야 합니다. 그림 3.6은 UDP 헤더의 필드를 보여줍니다. TCP와 UDP 헤더 모두 16비트의 출발지 및 목적지 포트를 포함하지만, UDP 헤더는 TCP 헤더에 비해 간소화되어 있습니다. UDP 헤더는 흐름 제어 기능이 없으며, 오류 감지 기능도 제한적입니다.

 

3.1.4.2.1 Length Field 그림 3.6에 나타난 UDP 헤더에서 길이 필드는 16비트로 구성되며, UDP 데이터그램의 헤더와 데이터를 포함한 바이트 길이를 나타냅니다.

 

3.1.4.2.2 Checksum FieldChecksum은 1의 보수 합의 1의 보수로, IP 헤더의 가상 헤더, UDP 헤더, 그리고 데이터(필요한 경우 0으로 패딩된 바이트)를 포함합니다. TCP 헤더의 Checksum과 유사하게, UDP 헤더 Checksum은 잘못된 경로로 전송된 데이터그램에 대한 보호 기능을 제공합니다. 그러나 TCP와 달리, UDP에는 전송된 데이터에 대한 오류 감지 메커니즘이 없으며, 오류 감지와 수정 작업은 응용 프로그램이 담당해야 합니다.

Source Port	Desination Port
Length	Checksum

 

3.1.4.3 Port Meanings 이전의 TCP와 UDP 헤더 분석에서 두 전송 계층 프로토콜 모두 16비트의 출발지 및 목적지 필드를 가지고 있음을 확인했습니다. 이 필드들은 각 프로토콜에서 동일한 방식으로 작동하므로, 두 프로토콜의 포트 필드를 하나의 개체로 다루겠습니다.

 

3.1.4.3.1 Destination Port 목적지 포트는 IP 데이터그램을 생성한 발신자가 제공하는 논리적 연결의 유형을 나타냅니다. 여기서 “논리적 연결”이라는 용어는 TCP 세그먼트에 의해 전송되는 응용 프로그램 또는 서비스를 의미하며, 이는 목적지 포트 필드의 포트 번호로 식별됩니다.

 

3.1.4.3.2 Source Port 출발지 포트는 보통 발신자가 0으로 설정합니다. 그러나 의미가 있을 경우, 0이 아닌 값이 할당되면 이는 발신 프로세스의 포트를 나타내며, 응답이 전송되어야 할 포트를 나타냅니다. 각 필드의 값은 포트 번호이므로, 그 범위에 대해 논의하는 것이 중요합니다.

 

3.1.4.3.3 Port Numbers Ranges 각 16비트 목적지 포트와 출발지 포트 필드는 0에서 65,535까지의 숫자를 전송할 수 있어 총 65,536개의 고유한 포트 번호를 제공합니다. 포트 번호는 세 가지 범위로 나뉘며, 이를 Well-Known Ports(잘 알려진 포트), Registered Ports(등록된 포트), 그리고 Dynamic and/or Private Ports(동적 및/또는 개인 포트)라고 합니다. Well-Known Ports는 0부터 1,023까지의 첫 번째 1,024개 포트 번호를 포함하고 있습니다. Registered Ports는 1,024부터 49,151까지의 포트 번호이며, Dynamic and/or Private Ports는 49,152부터 65,535까지의 포트 번호입니다.

 

Table 3.1. Common Well-Known Port Numbers

PORT NUMBER	DESCRIPTION
17	Quote of the Day
20	File Transfer Protocol—Data
21	File Transfer Protocol—Control
23	Telnet
25	Simple Mail Transfer Protocol
43	Whois
53	Domain Name Server

 Well-Known Port numbers는 인터넷 할당 번호 관리 기관(IANA)에 의해 할당되며, 시스템 프로세스 또는 프로그램이 응용 프로그램이나 서비스를 식별하는 데 사용됩니다. Table 3.1에는 더 자주 사용되는 Well-Known Port 번호 중 일부가 나와 있습니다. 이 포트 번호들은 TCP와 UDP 모두에서 사용될 수 있지만, 일반적으로 하나의 프로토콜에서만 사용됩니다. 예를 들어, 파일 전송 프로토콜(FTP)은 신뢰할 수 있는 연결 지향 프로세스로, TCP를 사용하여 전송됩니다. 반면, 간단한 네트워크 관리 프로토콜(SNMP)은 UDP로 최선의 노력 방식으로 전송됩니다. 그러나 VoIP(Voice over IP)와 같은 일부 응용 프로그램은 TCP와 UDP를 조합하여 사용합니다. 예를 들어, 전화번호를 다이얼할 때는 다이얼된 숫자가 신뢰할 수 있는 프로토콜인 TCP로 전송됩니다. 그러나 연결이 설정된 후에는 디지털 음성이 UDP를 통해 전송됩니다. 그 이유는 실시간 음성의 경우 비트 오류가 발생했을 때 재전송할 수 없기 때문입니다. 따라서 응용 프로그램은 오류가 발생한 패킷을 버리거나 UDP 패킷을 통해 전송된 짧은 음성 구간을 복원할 때 오류를 무시합니다.

 

  이제 TCP/IP 전송 계층의 작동 및 활용 방식을 이해했으니, 이번 장을 마무리하며 도메인 네임 시스템(DNS)으로 주의를 돌리겠습니다. 이를 통해 DNS가 어떻게 작동하는지 살펴보고, 이름 해상 과정이 어떻게 이루어지는지 이해하며, DNS가 로드 밸런싱을 지원하는 메커니즘으로 어떻게 사용될 수 있는지에 대한 지식을 얻을 것입니다. 로드 밸런싱은 이 책에서 나중에 더 자세히 다룰 주제입니다.

 

3.2 The Domain Name System 웹 브라우저에 URL을 입력하거나 이메일 메시지를 보낼 때, 도메인 이름을 사용하는 경우가 많습니다. 예를 들어, URL http://www.popcorn.com에는 도메인 이름 popcorn.com이 포함되어 있습니다. 마찬가지로, 이메일 주소 beverly@popcorn.com에도 동일한 도메인 이름이 포함되어 있습니다.

 

3.2.1 Need for Address Resolution 도메인 이름은 기억하기 쉽지만, 라우터, 게이트웨이, 컴퓨터는 주소 지정에 도메인 이름을 사용하지 않습니다. 대신, 컴퓨팅 장치들은 점으로 구분된 10진수 숫자로 구성된 IPv4 주소를 사용하여 설정됩니다. 이 점으로 구분된 10진수 주소는 이진수로 변환되어, 컴퓨팅 장치의 실제 주소를 나타냅니다.

 

 많은 책에서 컴퓨팅 장치에 IPv4 주소가 할당된다고 언급하지만, 실제로는 이러한 주소가 장치의 인터페이스에 할당됩니다. 이것이 라우터와 네트워크 서버가 여러 네트워크 연결을 가지는 경우, 각 인터페이스에서 고유한 출발지 주소로 패킷을 전송할 수 있으며, 특정 인터페이스와 일치하는 명확한 목적지 주소로 패킷을 수신할 수 있는 이유입니다. IPv4의 Class A, B, C 주소는 네트워크 주소와 호스트 주소를 모두 나타내므로, 이러한 주소는 라우팅 목적을 위한 네트워크와 네트워크 내 특정 장치를 모두 식별합니다.

 

 컴퓨팅 장치가 IPv4 주소를 사용한다는 것은 도메인 이름을 IP 주소로 변환하는 번역 장치가 필요하다는 것을 의미합니다. 이 번역 또는 해상 서비스는 도메인 네임 서비스(DNS) 라고 하며, 이번 섹션에서 다룰 주제입니다.

 

3.2.2 Domain Name Servers 도메인 이름을 IP 주소로 변환하는 데 사용되는 컴퓨터는 도메인 네임 서버라고 합니다. 여러 도메인 네임 서버는 IP 주소와 도메인 이름을 포함하는 데이터베이스를 유지하여, 도메인 이름을 IP 주소로 해석하거나 변환할 수 있게 합니다. 일부 회사는 로컬 영역 네트워크(LAN)에서 자체 도메인 네임 서버를 운영하며, 다른 조직은 인터넷 서비스 제공자(ISP)가 운영하는 DNS에 의존합니다.

 

 브라우저 사용자가 이전에 찾지 못한 IPv4 주소를 포함한 URL을 입력하면, 조직의 LAN에 있는 로컬 DNS는 ISP의 DNS에 쿼리를 전송하여 더 높은 수준에서 해석이 이루어졌는지 확인합니다. 마찬가지로, 조직이 ISP의 DNS 서비스를 사용하고 쿼리가 해석되지 않으면, 해당 DNS는 쿼리를 더 높은 권한의 서버로 전달합니다. 최고 권한은 최상위 도메인(Top-Level Domain) 이라고 합니다.

 

Table 3.2 Top-level Domains

Domain	Description
.aero	Aviation
.biz	Business organizations
.com	Commercial
.coop	Cooperative organizations
.edu	Educational
.gov	Government
.info	Information
.int	International organizations
.mil	U.S. Department of Defense
.museum	Museums
.name	Personal
.net	Networks
.org	Organizations

 

3.2.3 Top-Level Domain 각 도메인 이름은 점(.)으로 구분된 일련의 문자열로 구성됩니다. 도메인 이름의 가장 왼쪽 문자열은 호스트(예: www 또는 ftp)를 나타내고, 가장 오른쪽 문자열은 최상위 도메인(예: gov 또는 com)을 나타냅니다.

 

 인터넷이 처음 설립되었을 때는 소수의 최상위 도메인만 존재했습니다. 이 최상위 도메인에는 .com(상업), .edu(교육), .gov(정부), .mil(미국 국방부), .net(네트워크), .org(조직) 등이 포함되었습니다. 그 이후로 도메인 이름 등록 기관이 상당히 확장되었으며, 최상위 도메인 이름 서버의 수도 증가했습니다. Table 3.2에는 국가별로 정의된 도메인을 제외한 현재 정의된 도메인 이름 등록 기관들이 나와 있습니다. 국가별 도메인과 관련하여 현재는 .ar(아르헨티나), .il(이스라엘), .uk(영국) 등 100개 이상의 두 자리 도메인 등록 기관이 존재합니다. IANA는 도메인 이름 접미사를 정의할 책임이 있습니다.

 

 각 최상위 도메인 내에는 수천에서 수백만 개의 2차 도메인이 존재할 수 있습니다. 예를 들어, .com 최상위 도메인에는 Microsoft, Google, Yahoo와 수백만 개의 다른 항목이 포함될 수 있습니다. 모든 .com 최상위 도메인은 고유해야 하지만, 도메인 간에는 중복이 있을 수 있습니다. 예를 들어, lexus.com과 lexus.biz는 두 개의 다른 도메인을 나타냅니다. 도메인에 ftp.popcorn.com 또는 www.popcorn.com과 같이 단어를 접두사로 붙이면 해당 도메인의 특정 호스트 컴퓨터 이름을 얻을 수 있습니다. 이 컴퓨터는 DNS(Domain Name Service)를 통해 결정된 IP 주소를 갖습니다.

 

 3.2.4 DNS Operation 브라우저에 도메인 이름 형식의 URL을 입력하면 해당 이름이 IP 주소로 변환되어야 합니다. 이 주소는 브라우저가 해당 주소로 할당된 컴퓨터에서 웹 페이지를 요청하는 데 사용됩니다. 이 주소를 얻기 위해 브라우저는 도메인 이름 서버의 기능을 사용해야 합니다. 따라서 브라우저는 이름 서버에 접근하는 방법을 알고 있어야 합니다.

 

3.2.5 Configuring Your Computer 컴퓨터의 TCP/IP 소프트웨어를 설치할 때 가장 먼저 수행해야 할 작업 중 하나는 네트워크 설정을 구성하는 것입니다. 이때 컴퓨터의 IP 주소, 서브넷 마스크, 기본 게이트웨이, 도메인 이름을 IP 주소로 변환할 때 사용할 이름 서버의 주소를 설정하게 됩니다.

 

 그림 3.7은 Microsoft Windows 2000 인터넷 프로토콜(TCP/IP) 속성 대화 상자를 보여줍니다. “다음 IP 주소 사용” 버튼을 선택하면 IP 주소, 서브넷 마스크, 기본 게이트웨이, 그리고 최대 두 개의 DNS 서버 주소를 지정할 수 있습니다. 그러나 조직에서 동적 호스트 구성 프로토콜(DHCP)을 사용하는 경우, “자동으로 IP 주소 받기” 버튼을 선택하면 호스트가 네트워크에 연결될 때 DNS 주소가 IP 주소, 서브넷 마스크, 게이트웨이 주소와 함께 DHCP 서버로부터 호스트에 전송됩니다.

 

 Windows 환경에서 DNS 및 기타 주소 정보를 얻기 위한 도구를 사용할 수 있습니다. Windows 95 또는 Windows 98과 같은 구버전의 Windows를 사용하는 경우, Winipcfg.exe를 통해 현재의 IP 주소 할당을 확인할 수 있습니다. Windows 2000 또는 Windows XP를 사용하는 경우, 명령 프롬프트에서 IPConfig를 사용할 수 있습니다.

 

 그림 3.8의 상단은 IPConfig 프로그램을 옵션 없이 사용한 예시를 보여줍니다. 이 방식으로 프로그램을 사용하면 연결별 DNS 접미사, IP 주소, 서브넷 마스크, 기본 게이트웨이 주소가 반환됩니다. 그 후, IPConfig 프로그램을 “all” 옵션을 포함하여 다시 실행하면, 컴퓨터 구성에 대한 추가 정보, DHCP 및 DNS 서버 주소, DHCP 임대 정보 등이 제공됩니다.

 

 컴퓨터가 도메인 이름 서버의 IP 주소를 알게 되면, 해당 서버에 도메인 이름을 IP 주소로 변환해 달라고 요청할 수 있습니다. 예를 들어, 이름 서버가 이전에 www.popcorn.com 도메인 이름에 대한 IP 주소를 요청받았다면, 서버는 캐시 메모리에서 해당 IP 주소를 가져와 이를 요청하는 컴퓨터에 반환할 수 있습니다. 만약 이름 서버가 해당 해상 정보에 대한 사전 지식이 없다면, 루트 이름 서버와 연결을 시도합니다.

 

Figure 3.8 Using IPConfig to obtain about the network settings associanated with a computer

 

3.2.6 Root Name Servers 현재 전 세계에 13개의 루트 네임 서버가 존재하며, 대부분은 미국에 위치해 있고, 일부는 일본과 런던에 위치해 있습니다. 각 루트 서버는 동일한 방식으로 작동하며, 특정 쿼리에 대한 최상위 도메인의 네임 서버 주소를 반환합니다. 즉, 각 루트 서버는 특정 최상위 도메인을 지원하는 모든 네임 서버의 IP 주소를 알고 있습니다. 예를 들어, 브라우저가 www.popcorn.com URL에 접속했는데 로컬 네임 서버가 해당 호스트와 도메인의 IP 주소를 이전에 해결하지 않았다면, 로컬 네임 서버는 루트 네임 서버 중 하나에 연락합니다. 루트 네임 서버가 해당 호스트와 도메인 이름을 이전에 해결하지 않았다면, 루트 서버는 도메인의 IP 주소(이 예에서는 .com 도메인의 네임 서버)를 반환하여 로컬 네임 서버가 해당 서버에 접속할 수 있게 합니다.

 

 루트 서버는 A에서 M까지로 레이블이 지정되며, 각 네임 서버는 특수 레코드 형식으로 다른 루트 서버들의 이름과 IP 주소를 포함한 파일을 가지고 있습니다. 각 루트 서버는 또한 다양한 최상위 도메인을 지원하는 네임 서버의 IP 주소를 가지고 있습니다. 따라서 로컬 도메인 서버에서 처리할 수 없는 해상 요청은 해당하는 루트 서버로 전달되며, 루트 서버는 최상위 도메인의 IP 주소를 로컬 DNS로 반환합니다. 그 후, 로컬 네임 서버는 .com, .edu 또는 .gov와 같은 최상위 도메인 네임 서버에 쿼리를 전송하여 호스트 주소 해상을 요청하는 도메인의 네임 서버 IP 주소를 요청합니다. 최상위 도메인 네임 서버는 해당 도메인에 대한 모든 도메인 서버의 항목을 가지고 있으므로, 요청된 도메인을 처리하는 네임 서버의 IP 주소를 반환합니다. 로컬 네임 서버는 그 IP 주소를 사용해 www.popcorn.com과 같은 호스트와 도메인 이름을 해결할 수 있도록 직접 해당 네임 서버에 연락하며, 해당 네임 서버는 IP 주소를 로컬 네임 서버에 반환합니다. 그 후 로컬 네임 서버는 이를 브라우저에 반환하고, 브라우저는 www.popcorn.com 서버에 접속해 웹 페이지를 가져옵니다.