'ARP'에 해당되는 글 2건

  1. 2008.01.06 ARP(Address Resulution Protocol)
  2. 2007.10.12 TCP / IP & UTP

ARP(Address Resulution Protocol)

컴퓨터 네트워킹에서 ARP 는 host 의 hardware address를 host 의 network 의 layer만 알때 찾는 방법의 표준이다.

ARP 는 IP 나 Ethernet 하나만의 통신규약이 아니다 ; 그것은 많은 다른 network 계층의 프로토콜 주소를 hardware address 로 변환시켜 준다. ARP 는 주로 IP 주소와 Ethernet 의 MAC address 를 변환시켜 주는데 쓰인다. ARP 는 Token Ring, FDDI 나 IEEE 802.11이나 ATM 등의 LAN 기술을 넘어서는 IP 를 위해서 쓰이기도 한다

ARP 는 다음과 같은 두 host 의 communication 에 사용된다.

1. 두 host 가 같은 네트워크에 있고 하나가 다른것에게 packet 을 보내기를 원한다.
2. 두 host 가 다른 네트워크에 있고 다른 host 에게 연결되기 위하여 gateway나 router 를 사용한다.
3. 하나의 router 가 다른 router 를 거쳐 넘어 있는 host 에게 packet을 보내기 위해서 사용한다.
4. router 가 같은 네트워크에 있는 한 host 가 다른 host 에게 packet 을 보낼 때 사용한다.

첫번째 경우는 같은 망에 구성되어 있을 때 일어나고, 나머지 경우는 주로 3 hop 이상 떨어져 있을 때 일어난다.

ARP 는 RFC826에 정의되었고, 지금은 인터넷 표준, STD 37 이다.


프레임의 구조는
http://en.wikipedia.org/wiki/Address_Resolution_Protocol#Packet_structure
에서 표를 참조하면 되겠다.


  - from Wikipedia.org
(http://en.wikipedia.org/wiki/Address_Resolution_Protocol)

////////////////////////////////////////////////////////////////////////
역시 위키 직역.

By Yoons...

'Study.. > Net..' 카테고리의 다른 글

RFID  (0) 2008.06.03
NIC center  (0) 2008.01.31
Network Bridge Vs Router  (0) 2008.01.06
TCP-friendly rate control(TFRC)  (0) 2008.01.06
TCP / IP & UTP  (0) 2007.10.12
Posted by Yoons...
,

TCP / IP & UTP

Study../Net.. 2007. 10. 12. 21:07
TCP/IP 핵심 프로토콜

사용자의 네트워크 운영체제에 설치되어 있는 TCP/IP 프로토콜 컴퍼넌트는 TCP/IP 핵심 프로토콜이라고 불리는 일련의 상호 연결된 프로토콜들입니다. TCP/IP 프로토콜에 속하는 모든 애플리케이션과 다른 프로토콜들은 IP, ARP, ICMP, IGMP, TCP, UDP와 같은 기본 서비스에 의존하고 있습니다.

IP

IP는 비연결 지향, 신뢰할 수 없는 데이터그램 프로토콜로 호스트간에 어드레싱과 패킷 라우팅을 담당합니다. 비연결 지향이라는 것은 데이터를 교환하기 이전에 세션이 확립되지 않음을 뜻합니다. 신뢰할 수 없다는 것은 데이터의 전달이 100% 보장되지 않는다는 의미입니다. IP는 언제나 패킷을 전달하기 위한 최고의 노력을 합니다. 그러나, IP 패킷은 전송 중에 손실될 수도 있고, 패킷의 순서가 틀리게 전달되거나, 혹은 중첩되어 전달되거나 지연되어 질 수 있습니다. IP는 이러한 형태의 오류는 수정하지 않습니다. 패킷 전송에 대한 확인 및 손실된 패킷에 대한 복구 등은 이 보다 상위 계층 프로토콜(TCP와 같은)이 책임져야 할 동작입니다. IP는 RFC 791에 정의되어 있습니다. IP 패킷은 IP 헤더와 IP 페이로드(payload)로 이루어져 있습니다. 표 3은 IP 헤더의 핵심 부분을 설명하고 있습니다.

An IP packet consists of an IP header and an IP payload. 표 3 describes the key fields in the IP header.

표 3   IP 헤더의 주요 필드

IP 헤더 필드 기능
Source IP Address IP 데이터그램이 보내진 원본 IP 주소를 나타냅니다.
Destination IP Address IP 데이터그램의 최종 목적지 IP 주소를 나타냅니다.
Identification 특정 IP 데이터그램을 확인하기 위해 사용됩니다. 또한, IP 데이터그램이 분할된 경우 전채 데이터그램을 확인하기 위해 사용됩니다.
Protocol 목적 호스트에 있는 IP에게 패킷을 TCP, UDP, ICMP, 혹은 다른 프로토콜로 전달해야 하는지를 알려줍니다.
Checksum P 헤더 정보의 오류를 확인하기 위해 사용되는 간단한 수학적 계산 값.
Time to Live (TTL) I 데이터그램이 라우터에 의해 버려지기 전까지 최대 이동할 수 있는 네트워크의 개수를 나타냅니다. TTL은 보내는 측 호스트에 의해 지정되며 패킷이 끝없이 IP 인터네트워크에서 돌아다니는 수 없게 합니다. IP 패킷을 포워딩(Forwarding)하게 되면, 라우터는 TTL 값을 적어도 1만큼 감소시키기 됩니다.

분할과 재조합

만일 라우터가 전달 받은 IP 패킷의 크기가 패킷을 전달할 네트워크에 너무 크다면, IP는 원본 패킷을 네트워크에 적합하게 작은 패킷들로 분할합니다. 분할된 패킷들이 최종 목적지에 도달하게 되면, 목적 호스트에 있는 IP는 분할된 패킷들을 원본 패킷으로 재조합 합니다. 이러한 과정을 분할(Fragmentation)과 재조합(Reassembly)이라고 합니다. 분할은 이더넷, 토큰링과 같은 네트워크 기술들이 섞여 있는 환경에서도 발생할 수 있습니다.

분할과 재조합 과정은 다음과 같이 처리됩니다.

  1. IP 패킷을 소스에서 받으면 Identification 필드에 유일한 값을 지정합니다.
  2. 라우터에 IP 패킷이 전달되면 IP 라우터는 패킷을 전달할 네트워크의 MTU(maximum transmission unit) 값이 전달 받은 IP 패킷의 크기보다 작은지 확인합니다.
  3. IP는 원본 IP 페이로드를 다음 네트워크에 맞게 분할합니다. 각 분할된 패킷은 자신만의 IP 헤더를 가지고 보내집니다. 이 헤더에는 다음과 같은 정보를 가지고 있습니다.
    • 원본 Identification 필드 값, 이 값을 이용하여 하나로 재조합 되어야 할 모든 분할 패킷을 구분할 수 있습니다.
    • More Fragments Flag 는 다른 분할 패킷이 다음에 있는지 여부를 나타냅니다. More Fragments Flag은 마지막 분할 패킷에는 설정되지 않습니다. 다음 분할 패킷이 없기 때문입니다.
    • Fragment Offset 필드는 원본 IP 페이로드에서 분할 패킷의 상대적 위치를 나타냅니다.
  4. 원격지에 있는 호스트의 IP가 분할 패킷들을 받으면, Identification 필드를 이용하여 동일한 원본 패킷에 속함을 확인합니다. Fragment Offset을 이용하여 분할된 패킷들을 원본 IP 페이로드로 재조합 합니다.

ARP

IP 패킷이 이더넷이나 토큰링과 값이 공유 억세스, 브로드캐스트 기반의 네트워크 기술로 전달된다면, IP 주소에 해당하는 MAC(Media Access Control) 주소를 반드시 알아야 합니다. ARP는 IP 주소를 그에 해당하는 MAC 주소로 변환하기 위해 MAC-레벨 브로드캐스트를 사용합니다. ARP는 RFC 826에 정의되어 있습니다.

ARP에 대한 좀 더 자세한 정보는 이 문서 후반부에 있는 "물리적 주소 분석" 부분을 참고하기 바랍니다.

ICMP

ICMP(Internet Control Message Protocol)은 문제를 해결하는 기능과 전달할 수 없는 패킷에 대한 에러 정보를 알리기 위해 사용됩니다. 예를 들어, IP가 어떤 패킷을 목적 호스트로 전달할 수 없다면, ICMP는 "Destination Unreachable" 메시지를 소스 호스트로 보냅니다. 표 4 는 대표적인 ICMP 메시지들을 보여 주고 있습니다.

표 4   대표적인 ICMP 메시지

ICMP 메시지 기능
Echo Request 원하는 호스트로의 IP 연결을 확인하기 위해 사용되는 간단한 문제 해결 메시지.
Echo Reply ICMP Echo Request에 대한 응답 메시지.
Redirect 데이터를 보내는 호스트에게 목적 IP 주소에 대한 좀 더 적합한 경로가 있음을 알리기 위해 라우터가 보내는 메시지.
Source Quench 데이터를 보내는 호스트에게 IP 데이터그램이 라우터의 집중 현상에 의해 손실되고 있음을 알리기 위해 라우터가 보내는 메시지. 그러면, 데이터를 보내는 호스트는 전송률을 낮추게 됩니다. Source Quench는 ICMP에서 선택적 메시지이고 대부분 구현되지 않습니다.
Destination Unreachable 라우터나 목적 호스트에 의해 보내지며 데이터그램이 전달되지 못한다는 것을 데이터를 보내는 호스트에 알려줍니다.

ICMP Echo Request 메시지를 보내고 Windows NT 기반의 컴퓨터에서 응답에 대한 통계치를 보고 위해서는 Windows NT 명령 창에서 ping 유틸리티를 사용하면 됩니다.

Destination Unreachable ICMP 메시지는 몇 가지 종류가 정의되어 있습니다. 표 5는 가장 대표적인 ICMP Destination Unreachable 메시지에 대해 설명하고 있습니다.

표 5   대표적인 ICMP Destination Unreachable 메시지

Destination Unreachable Message 설명
Network Unreachable 목적 네트워크에 대한 경로를 찾지 못하면 IP 라우터에 의해 보내지는 메시지.
Host Unreachable 목적 네트워크에서 목적 호스트를 찾지 못하면 IP 라우터에 의해 보내지는 메시지. 이 메시지는 연결 지향 네트워크 기술(WAN-연결)에서만 사용됩니다. 비연결 지향 네트워크 기술(이더넷이나 토큰링 같은)에서 IP 라우터는 이 메시지를 보내지 않습니다.
Protocol Unreachable IP 헤더의 Protocol 필드가 현재 로드되어 있는 IP 클라이언트 프로토콜과 맞지 않을 때 목적 IP 노드에 의해 보내지는 메시지.
Port Unreachable UDP 헤더에 있는 Destination Port가 그 포트를 사용하는 프로세스와 맞지 않을 때 IP 노드에 의해 보내지는 메시지.
Fragmentation Needed and DF Set 분할이 반드시 필요하나 소스 노드에서 IP헤더의 DF(Don't Fragment) 플래그를 설정하여 분할할 수 없는 경우 IP 라우터에 의해 보내지는 메시지.

ICMP는 IP를 신뢰할 수 있는 프로토콜로 만들지는 못합니다. ICMP는 에러에 대한 상태를 알려주고 특정 상태에 대해 피드백을 제공합니다. ICMP 메시지는 확인되지 않은 IP 데이터그램으로 전달되며 그 메시지 역시 신뢰할 수 없습니다. ICMP는 RFC 792에 정의되어 있습니다.

IGMP

IGMP(Internet Group Management Protocol)은 IP 멀티캐스트 그룹에서 호스트 멤버십을 관리하는 프로토콜입니다. IP 멀티캐스트 그룹(호스트 그룹이라고도 함) 은 특정 멀티캐스트 IP 주소로 전달되는 IP 트래픽을 감시하는 호스트들의 집합입니다. 멀티캐스트 IP 트래픽은 하나의 MAC 주소로 보내지지만 여러 개의 IP 호스트에 의해 처리됩니다. 지정된 호스트가 특정 IP 멀티캐스트 주소를 감시하고 그 IP 주소로 오는 모든 패킷을 받습니다. IP 멀티캐스팅은 다음과 같은 추가적인 사항이 있습니다.

  • 호스트 그룹 멤버십은 동적(dynamic)입니다. 호스트는 어느 때나 그룹에 추가되거나 삭제될 수 있습니다.
  • 호스트 그룹의 크기에는 제한이 없습니다.
  • 호스트 그룹의 멤버는 IP 라우터를 여러 네트워크로 확장할 수 있습니다. 이렇게 하기 위해서는 IP 라우터에서 IP 멀티캐스트 기능을 제공해야 하며 호스트들이 자신의 그룹 멤버십을 지역 라우터에 등록할 수 있어야 합니다. 호스트 등록은 IGMP를 이용해 이루어집니다.
  • 호스트는 적합한 호스트 그룹에 속하지 않고도 IP 멀티캐스트 주소로 트래픽을 보낼 수 있습니다.

호스트가 IP 멀티캐스트를 받기 위해서는 애플리케이션이 IP에게 특정 IP 멀티캐스트 주소 목적지에 대한 멀티캐스트를 받을 것이라고 알려주어야 합니다. 만일 네트워크 기술이 하드웨어 기반의 멀티캐스트를 지원한다면 네트워크 인터페이스에게 특정 멀티캐스트 주소를 향한 패킷은 무시할 것을 요구하게 됩니다. 이더넷의 경우 네트워크 인터페이스 카드를 프로그램하여 원하는 IP 멀티캐스트에 적합한 멀티캐스트 MAC 주소로 응답하도록 할 수 있습니다.

호스트는 다음 중 하나의 IP 멀티캐스트 레벨을 지원합니다.

  • 레벨 0
  • IP 멀티캐스트 트래픽을 보내거나 받는 것을 지원하지 않습니다.
  • 레벨 1
  • IP 멀티캐스트 트래픽을 보내는 것은 지원하나 받는 것은 지원하지 않습니다.
  • 레벨 2

IP 멀티캐스트 트래픽을 보내고 받는 것을 지원합니다. Windows NT TCP/IP 는 레벨 2 IP 멀티캐스팅을 지원합니다.

IGMP는 호스트 그룹 정보를 등록하는 프로토콜입니다. IGMP는 레벨 2 IP 멀티캐스팅을 지원하는 모든 호스트에 필요합니다. IGMP 패킷은 IP 헤더를 사용하여 보내집니다.

IGMP 메시지는 다음과 같은 두 가지 형태를 가집니다.

  1. 하나의 호스트가 호스트 그룹에 동참할 때, IGMP 호스트 멤버십 리포트 메시지를 모든 호스트(all-host) IP 멀티캐스트 주소(224.0.0.1)나 원하는 멀티캐스트 주소로 보냅니다. IP 멀티캐스트 주소를 참조하여 특정 호스트 그룹에 호스트의 멤버십을 선언하게 됩니다.
  2. 라우터가 특정 호스트 그룹에 대한 멤버를 확인하기 위해서 IGMP 호스트 멤버십 쿼리(query) 메시지를 모든 호스트(all-host) IP 멀티캐스트 주소로 보냅니다. 만일, 아무런 응답이 없다면 라우터는 네트워크의 특정 그룹에 아무런 멤버가 없다고 가정하고 그룹 네트워크 정보를 다른 라우터로 전달하는 과정을 중단하게 됩니다.

IP 멀티캐스트를 인터네트워크를 넘는 다른 라우터로 확장하기 위해서는 멀티캐스트 라우팅 프로토콜이 사용됩니다. 이 프로토콜은 호스트 그룹 정보를 전달하게 되는데, 이렇게 하여 멀티캐스팅 포워딩을 지원하는 모든 라우터들은 특정 네트워크에 있는 호스트 그룹들이 어떤 멤버들을 포함하고 있는지 알게 됩니다.

TCP

TCP는 신뢰할 수 있고, 연결 지향의 전달 서비스입니다. 데이터는 세그먼트(Segment) 단위로 전송 됩니다. 연결 지향(Connection-oriented)이란 호스트가 데이터를 교환하기 이전에 연결이 반드시 이루어져야 함을 뜻합니다. 전송되는 모든 세그먼트에 순번을 지정하여 신뢰성을 확신할 수 있게 됩니다. 다른 호스트에 의해 데이터가 받아졌는지를 조사하기 위해 확인 방법(acknowledgment )이 사용됩니다. 각 세그먼트에 대해 전달 받은 호스트는 반드시 ACK(acknowledgment)를 정해진 시간 안에 리턴 해야 합니다. 만일 ACK를 받지 못하면, 데이터는 다시 전송됩니다. TCP에 대한 정의는 RFC 793에 정의 되어 있습니다.

TCP는 바이트-스트림 통신(byte-stream communications)을 사용합니다. 바이트-스트림 통신에서는 TCP 세그먼트의 데이터가 필드나 레코드 경계가 없는 바이트 열로 취급됩니다. 표 6은 TCP 헤더의 주요 필드에 대해 설명하고 있습니다.

표 6   TCP 헤더의 주요 필드

필드 기능
Source Port 데이터를 보내는 호스트의 TCP 포트.
Destination Port 데이터를 받는 호스트의 TCP 포트.
Sequence Number TCP 세그먼트에 있는 데이터의 첫번째 바이트에 대한 순번.
Acknowledgment Number 바이트에 대한 순번, 데이터를 보내는 측은 연결된 다른 측 호스트에서 이 값을 전달 받을 것을 기대합니다.
Window TCP 세그먼트를 보내는 호스트의 현재 TCP 버퍼 크기.
TCP Checksum TCP 데이터와 TCP 헤더의 정확성 확인

TCP 포트

TCP 포트는 TCP 세그먼트를 전달하기 위한 특정 지점을 제공합니다. 포트 번호 1024 이하는 잘 알려진(well-known) 포트로서 IANA(Internet Assigned Numbers Authority)에 의해 지정됩니다. 표 7은 잘 알려진 TCP 포트에 대한 리스트입니다.

표 7   잘 알려진 TCP 포트

TCP 포트 번호 설명
20 FTP (데이터 채널)
21 FTP (컨트롤 채널)
23 Telnet
80 WWW에 의해 사용되는 HTTP(HyperText Transfer Protocol)
139 NetBIOS 세션 서비스

TCP 포트에 대한 완전한 리스트는 RFC 1700에 정의되어 있습니다.

TCP의 세가지 핸드쉐이크(Handshake) 방법

TCP 연결은 세가지 방법의 핸드쉐이크에 위해 초기화됩니다. 세가지 방법의 핸드쉐이크의 목적은 순번을 동기화하고 연결의 양측에서 순번을 확인하고 TCP 윈도우의 크기를 교환하고 최대 세그먼트 크기와 같은 기타 TCP 옵션을 교환하는 것입니다. 다음은 이 과정에 대한 전반적으로 설명하고 있습니다.

  1. 클라이언트는 TCP 세그먼트에 연결을 위한 초기 순번과 서버로부터 전송 받을 세그먼트를 저장하기 위한 클라이언트측 버퍼크기를 나타내는 윈도우 크기를 저장하여 보냅니다.
  2. 서버는 자신이 선택한 초기 순번, 클라이언트의 순번에 대한 확인, 클라이언트로 전달 받을 세그먼트를 저장할 버퍼의 크기를 나타내는 윈도우 크기들을 TCP 세그먼트에 담아 전달합니다.
  3. 클라이언트는 서버의 순번을 확인하는 정보를 TCP 세그먼트로 서버에 전달합니다.

TCP는 연결을 종료하는 과정 역시 이와 비슷한 과정을 거칩니다. 이 과정을 통해 양 측의 호스트는 전송을 마치고 모든 데이터를 받았다는 것을 확인하게 됩니다.

UDP

UDP는 신뢰할 수 없는 비연결 지향 데이터그램 서비스를 제공합니다. 데이터는 메시지 형태로 전달되며 전달하기 위한 최대한의 노력을 다합니다. 즉, UDP는 데이터그램의 전송을 100% 보장하지 않으며, 전송된 패킷의 순서가 정확하다는 것을 보장하지 못한다는 것입니다. UDP는 손실된 데이터를 재전송을 통해 복구하지 않습니다. UDP는 RFC 768에 정의되어 있습니다.

UDP는 데이터 전달을 확인할 필요가 없거나 한번에 작은 양의 데이터를 전송하는 애플리케이션에 주로 사용됩니다. NetBIOS 네임 서비스, NetBIOS 데이터그램 서비스, SNMP(Simple Network Management Protocol)등이 UDP를 사용하는 서비스, 애플리케이션의 대표적인 예입니다. 표 8은 UDP 헤더의 주요 필드에 대해 설명하고 있습니다.

표 8   UDP 헤더의 주요 필드

필드 기능
Source Port 데이터를 보내는 호스트의 UDP 포트.
Destination Port 데이터를 받는 호스트의 UDP 포트.
UDP Checksum UDP 헤더와 UDP 데이터의 정확성 체크.
Acknowledgment Number 바이트의 순번, 데이터를 보내는 측은 연결된 다른 측 호스트에서 이 값을 전달 받을 것을 기대합니다.

UDP 포트

UDP를 사용하기 위해서 애플리케이션은 반드시 IP 주소와 UDP 포트를 제공해야 합니다. 포트는 전송하는 메시지를 위한 지점을 제공합니다. 포트는 다 채널의 메시지 큐의 기능을 하게 됩니다. 즉, 포트를 이용하여 여러 메시지를 동시에 전달 받을 수 있습니다. 각 포트는 유일한 수치 값으로 구분되어 집니다. UDP 포트와 TCP 포트는 서로 같은 수치를 사용하는 경우도 있지만 서로 완전히 다른 것이라는 점에 주의하기 바랍니다. 표 9는 잘 알려진 UDP 포트들의 목록입니다.

표 9   잘 알려진 UDP 포트

UDP 포트 번호 설명
53 DNS(Domain Name System) 네임 권리
69 TFTP(Trivial File Transfer Protocol)
137 NetBIOS 네임 서비스
138 NetBIOS 데이터그램 서비스
161 SNMP(Simple Network Management Protocol)

UDP 포트의 완전한 리스트는 RFC 1700에 정의되어 있습니다


출처 : http://www.it-sesang.com (시스코네트워크교육센터)

Posted by Yoons...
,