네트워크 TCP / IP

주제: tcp/ip에 대한 개론적 이야기

#프로토콜이 뭐지?
먼저 프로토콜이 무엇이가부터 말씀드리겠습니다. 프로토콜은 한글로 번역을 굳이하자면 전송규약입니다. 서로 대화를 할때의 규칙이라고 이해하시면 될것입니다. tcp/ip에대한 말은 많이 들어보았을것입니다. 윈도그에서 인터냇하려면 꼭 tcp/ip프로토콜을 설치해야했죠?왜 그랫을까요?그 많은 프로토콜이 있는데 왜 이걸 설치해야만 할까요. 그것은 인터냇이라는 커다란 네트웍에서 통용되는 프로토콜이기 때문입니다. 유닉스에서도 리눅수에서도 맥에서도 윈도그에서도 이 프로토콜은 꼭 설치되어있어야만 인터냇을 할수있으며 외부세계와 대화할수있는것입니다.즉, tcp/ip라느것은 어떠한 기계에서도..어떠한..운영체제에서도 통용되는 프로토콜이라는것입니다.

#레이어(layer)가 뭐지?
레이어란 ‘층’으로 번역이 될수있겠죠? tcp/ip는 4개의 층이있습니다.
한번 그려볼까요?^^

Application
Transport
Network
Link
Telnet, FTP, E-Mail
TCP, UDP
IP, ICMP, IGMP
Device Driver and Interface Card

왼쪽에있는것이 레이어이고 오른쪽에 각레이어당 존재하는 프로토콜입니다.
즉,tcp/ip에서 각 레이어는 자기가 할일만해서 위쪽 레이어로 패킷을 전달합니다.일종의 ‘분업’입니다. 한 레이어가 모든것을 하는게 아니고 각각의 레이어는 자기가 할것만 하면 됩니다.
오른쪽에 보시면 여러가지 프로토콜이 보이지요? 맨윗쪽에 있는것은 다 아시겠죠? 그건 어플리케이션 레이어에이쓴 프로토콜이랍니다.즉..우리가 평소에 통신을 한다는것은 밑에층에 있는레이어에는 신경쓰지 않고 맨윗쪽 레이어만을 썼다는것을 알수있을것입니다. 일바적으로 나머지 밑에있는것들은 커널이 친절하게 다 처리해줍니다.^^
하지만 밑에층도 어떻게 이뤄졌을까 궁금하죠? 하나하나 알아봅시다.

Link 이층은 일반적으로 네트워크 카드를 지칭합니다.
우리가 패킷을 받을 때 가장먼저 패킷이 거치는곳이지요.
Network 패킷의 이동에 관여합니다.
즉 패킷을 라우팅하는일이 여기서 일어납니다.
Transport 두개의 호스트간에 어플리케이션 레이어를 위한 데이터의 흐름을 제공합니다.
두개의 프로토콜이있죠?
이 두개는 매우 상이 합니다.
간단히말해서 TCP는 신뢰적인 프로토콜이고…
UDP는 비신뢰적인 프로토콜이죠.
자세한건 나중에설명합니다.
Application 우리가 평소에 쓰는 레이어죠?

오른쪽에있는..각각의 프로토콜을 알아보죠^^

TCP transmission
control
protocol 
연결지향적인 프로토콜입니다.
tcp는 연결지향적이므로 three way handshaking이라는 과정을 거쳐서 접속이 이뤄지게됩니다. 또한 흐름제어가 가능합니다.
windows사이즈에 따라서 전송을 제어할수가 있습니다.
tcp는 full-duplex입니다.
즉 어플리케이션은 어느때든지 데이터를 보내고 받을수있습니다.
UDP user datagram
protocol 
비연결지향적인 프로토콜입니다.
신뢰성이 없으므로 프로그래밍을 할때 상대편에 정확히 도착했는지를 알기 위해서는 어플리케이션에서 그작업을 해주어야합니다.
인증과정이 없으므로 tcp보다 빠른 전송을 할수있습니다.
real audio가 대표적인 케이스입니다.
ICMP internet control
message protocol
라우터와 호스트사이에서 에러와 제어정보를 제공합니다.
대표적인 어플로 ping 이있습니다.
IGMP internet group
management protocol
멀티케스팅에 사용되는 프로토콜입니다.
ARP adress
resolution protocol 
하드웨어 어드레스와 ip넘버를 매칭시켜주는 프로토콜입니다.
ip 넘버로 하드웨어 어드레스를 답합니다.
RARP reverse address
resolution protocol
arp 의 반대로 하드웨어 어드레스로 ip 넘버를 답합니다.
diskless system 에서 자신의 ip넘버를 알기위해서 사용합니다.

인터넷의 중요한 목표는 세부적인것은 숨기는것입니다.우리가 통신을 한다고 할때 국내 사이트에 접속하든 아니면 지구반대편 미국에 접속을 하든지, 어플리케이션 레이어에서는 알수도 없고 알려고하지도않고 상관하지도 않습니다. 다만 자기가 맡은 일을 묵묵히(?)할뿐이지요^^
이 세부적인 사항을 숨기는것이 인터냇을 파워풀하게 만듭니다.

# 인터냇 주소는 어떻게 매기는걸까?
인터냇에있는 각각의 컴퓨터는 유일한 자신만의 주소가 있어야만합니다.
주소는 A — E까지 class로 나누어져있습니다.
주소는 4바이트,즉 32비트로 이루어집니다.

각 클레스별로 알아보면..
class A 는          0  으로 시작하고….
class B             10
class C             110
class D             1110
class E             11110

이제 각 클레당 범위를 알아보죠.
                         범위
class A           0.0.0.0  —  127.255.255.255
class B         128.0.0.0  —  191.255.255.255
class C         192.0.0.0  —  223.255.255.255
class D         224.0.0.0  —  239.255.255.255
class E         240.0.0.0  —  247.255.255.255
(물론 특별한 의미로 쓰이는 주소도 있습니다. 그것은 다음에^^)

#켑슐화(Encapsulation)가 뭘까?
앞의 그림을 다시봅시다.

Application
Transport
Network
Link
 

우리가 패킷을 보낼때 화살표방향으로 데이터가 이동합니다.
이동을 하면서 각각의 레이어에서 자기에게 할당된일,즉  패킷앞에다가 헤더를 붙여주는겁니다.
예를들어,사용자데이터가 transport지날때 어플리 케이션데이터앞에 tcp 해더를 붙이고, network를 지날때 ip헤더를 붙이고, link로 내려갈때 ethernet 헤더를 붙이는것이지요.
이것이 캡슐화입니다.
그럼 켐슐화가 끝난 패킷의 그림을 볼까요?

Ethernet Header

IP Header

TCP Header

Application Data

Ethernet Trailer

이런상태로 패킷은 인터냇을 떠도는(?)것입니다.

참고:엄밀한 의미로 말하자면….

tcp가 ip에 보내는것은 TCP segment ip가 네트워크 인터페이스에 보내는것은
IP datagram 이더넷의 케이블을 흘러다니는 것은 frame이라 부르는것이 옳습니다.
저는 의미전달에 큰 혼란이 없다고 판단될경우에는 모두 패킷이라고 부르겠습니다. 패킷!

# Demultiplexing 이 뭐지?
이것은 위에서 보낸 패킷이 목적지에 도달했을때 행해지는것으로 캡슐화를 역으로 생각하면 됩니다.
즉 ethernet header를 풀고 , ip header를 플고, tcp헤더를 풀고, 이런식으로 다 풀면 사용자 데이터가 나오겠죠?

link에서 network로 갈때는 ethernet header의 frame type에 따라서,
network  에서 transport로 갈때는 ip header의  protocol 에따라서,
transport에서 application로갈때는 tcp나 udp의port number에따라서
demultiplexing이 이뤄집니다.

이 사실은 매우 중요하므로 꼭 암기하세요.
자세한 사항은… 다음에 알아보죠.
오늘은 워밍업이니까요…^^

# port number
텔넷은 23번포트 , 웹은 80번포트를 사용합니다.
/etc/services에보면 알려진 포트넘버가 있죠?
알려진(well-known) 포트넘버는 1과 1023 사이에있습니다.

서론적인 이야기는 여기까지 하겠습니다.
다음 강좌는 link레이어에 대한 이야기입니다.

Link Layer
링크층에 대해서 알아봅시다.
여러가지 장치(ethernet,ppp,FDDI,…..)중에서 가장 많이 접하는  이더넷에 대한것만 알아보겠습니다.

# 이더넷의 켑슐화 (Ethernet Encapsulation)
IP로부터 받은 데이터를 인터냇에 내보내기전에 이 링크층을 거쳐야만 하고, 링크층에서는 이더넷 헤더를 앞에 붙이는 작업을하게됩니다.이것이 이더넷의 켑슐화입니다.
하드웨어 주소라는것이있습니다. 이값은 6바이트,즉 48비트의 수입니다.
이값또한 ip주소처럼 전세계에서 유일합니다.
우리가 예를들어 telnet 11.22.33.44 라고 쳤을때, 실제로 인터넷상에서 11.22.33.44를 찾는것이아니고, ip주소를 하드웨어 주소로 변환한다음 이 하드웨어 주소로 목적지를 찾는것입니다.이때 하드웨어 주소와 IP주소를 변환해주는 프로토콜이 ARP와 RARP입니다.
ifconfig를 쳐보십시요.만약 랜카드가 설정되어있다면.

eth0      Link encap:Ethernet  HWaddr 00:C0:26:11:72:CB
inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
Interrupt:11 Base address:0x6100

이런식으로 나오겠죠? 여기서 위에 HWaddr이 바로 하드웨어 주소입니다.
00:C0:26:11:72:CB 이값은 전세계에서 유일합니다.이값은 우리가 임으로 바꿀
수없습니다.왜냐하면 랜카드 회사에서 고정되어 나오기 때문입니다.

자 그럼 이더넷 켑슐화를 를 좀더 자세히 알아볼까요?

Destination Addr

6

Source Addr

6

Type

2

Data

46-1500

CRC

4

 

type
0800

IP Datagram

2 46-1500
type
0806
ARP Request / Reply PAD
2 28 18
type
8035
RARP Request / Reply PAD
2 28 18

밑에있는 숫자는 바이트수입니다.
맨앞에 목적지 하드웨어 주소로 6바이트,그다음 발신지 하드웨어주소로 6바이트가 들어갑니다.
type값이 무엇이냐에 따라서 어디로 전달되는지가 달라집니다.

0800 이면 IP  로 전달되고, 0806 이면 ARP 로 전달되고, 8035 이변 RARP로 전달됩니다. (모두 16비트 수입니다.^^)

CRC 는 패킷안에 에러를 체크하기위해서 있습니다.
이더넷 프레임(ethernet frame)에는 최소값이 있습니다. 위에서 보듯이 46이죠.
ARP와 RARP request/reply는 46바이트를 채울수없으므로 데이터가 덧붙여집니다.
PAD란 덧붙여진 값을 뜻합니다.

# MTU(maximun transmision unit) 가 뭐지?
위의 그림에서 보이듯이 프레임사이즈에는 한계가  있습니다. 바로 1500byte 입니다. 링크층의 이러한 특성을 MTU라고 합니다.
IP가 보내야할 데이터그램이 있을경우,그 데이터그램이 링크층의 MTU보다 크다면 IP는 분열(fragmentation)을 수행합니다.즉,데이터그램을 작은 조각으로 나누는 것이지요.
위의 ifconfig 출력결과에도보면 3번째 줄에 MTU:1500 이 보이죠?
이값은 네트워크마다 틀립니다.
이더넷인경우는 위와같이 1500이고 PPP인 경우는 296입니다.

#Path MTU 가 뭐지?
두개의 호스트가 똑같은 네트워크(즉, 어떠한 라우터도 거치지 않고 연결될수 있는상태)에있다면 MTU값이 중요합니다. 하지만 두개의 호스트가 멀리 떨어져 있을경우 MTU값은 그리 중요하지 않습니다. 왜냐하면 제가 미국의 yahoo.com에 이더넷으로 연결한다고 가정했을때, 똑같은 네트워크(이더넷)을 통과한다는 보장이 없기때문이지요. 만약 패킷이 ppp를 만났다면 296바이트로 쪼개지는것입니다. 두개의 호스트가 멀리떨어져있을때는 가장 작은 MTU값이 중요합니다.
모든 패킷이 결국에는 이 MTU값에 따라서 잘려지기 때문이지요.
이값을 Path MTU라 부릅니다.

이것으로 링크층에 대한 이야기를 마치겠습니다.
이번이야기는 다소 지루한 이야기였던것같습니다.
다음 이야기는 IP(internet protocol)과 ARP(Address Resolution Protocol)에
대해서 알아보겠습니다.
그럼 행복하십시요.   :)

IP: Internet Protocol
안녕하세요?
이번이야기의 주제는 IP헤더에대한 설명, IP라우팅,서브넷의 구축법 입니다.
그럼 이제 하나하나 알아보죠.~

#도대체 IP가 뭐지?
IP는 비연결적(connectionless)이고, 비신뢰적(unreliable)입니다.
처음 tcp/ip를 접하시는 분들은 아마 ip가 비연결적이고 비신뢰적인 프로토콜이라고 말한다면 이상하게 생각하실지도 모르겠습니다.
비연결적이라함은 성공적인 통신에대한 어떠한 정보도 유지하지 않는다는것입니다. 각각의 패킷은 모든 다른것들에 대해서 독립적입니다.
그러므로 각각의 패킷은 서로 순서가 바뀌어서 전달될수있다는것이죠.
비신뢰적이라함은 패킷이 성공적으로 전달되었다는 어떠한 인증도 없다는것입니다.IP는 최선의 서비스를 위해 노력합니다. 무엇인가 문제가 생길경우에는 IP는 패킷의 발신지에 ICMP에러메세지를 돌려보냅니다.인증은 더높은 층(TCP….)에서 이루어집니다.

#IP헤더는 어떻게 생겼을까? :)
0       3 4      8 9             15 16                                  31
┌────┬───┬────────┬──────────────────┐
│        │header│                │                                    │
│ version│length│ type of service│    total length                    │
├────┴───┴────────┼───┬──────────────┤
│                                  │      │                            │
│     identification               │flags │      fragment offset       │
├────────┬────────┼───┴──────────────┤
│                │                │                                    │
│ time to live   │    protocol    │          header checksum           │
├────────┴────────┴──────────────────┤
│                                                                        │
│                            source Ip address                           │
├────────────────────────────────────┤
│                                                                        │
│                            destination IP address                      │
├────────────────────────────────────┤
│                                                                        │
│                       ip option (if any)                               │

└────────────────────────────────────┘

이렇게 생겼습니다.^^
처음 보시는분은 무척 복잡하다는걸 느낄수있을것입니다.
맨윗줄의 숫자는 비트수입니다. 각줄당 32비트,즉 4바이트씩 끊어서 보기좋게 그린것이지요. 즉 처음 0비트에서 3비트까지가 version이고 다음 4비트에서 8비트까지가 header length등등 이런식으로 나갑니다. IP옵션이 없을경우 IP헤더의 길이는 총20바이트입니다.(5줄이니까 4*5=20 )
그럼 이제 각 필드에대한 설명을 합니다.

<version>
IP의 버전이 들어갑니다. 현제 IP버전은 4입니다. 그래서 IPV4라고도 부르지요
IPV6도있습니다. IPV6는 현제 실제로 쓰이고 있지는 않지만 머지 않아서 IPV4를 대체할것입니다.

<header length>
헤더의 길이가 들어갑니다. 옵션이 없다고 했을때 헤더는 20바이트입니다.
헤더의 길이는 4비트입니다. 들어가는 숫자는( 헤더의 바이트수 / 4 )입니다.
즉 20 바이트라면 20 / 4 = 5 죠? 그래서 5가 들어가는것입니다.
헤더길이 필드가 4비트이기 때문에 헤더는 60바이트를 넘을수없습니다.
(잘계산해보세요 ^^)

<type of services>
실제로 현제 쓰이는 것은  4비트입니다.
각 비트는 하나씩만 켜져야 됩니다. 2개가 켜질수는없습니다.
minimize delay / maximize throughout / maximize reliability / minimize monetary cost
이렇게 4가지의 비트가 있습니다.
예를 들어 텔넷 같은 경우에는 minimize delay가 켜져야겠죠?왜냐하면 우리가 타이핑할때 상호대화적인 통신이 이뤄져야 되기때문입니다. 만약 우리가 ls를 쳤는데 한1분뒤에나 결과가 나온다면 무척 열받겠죠?
하지만 FTp같은 경우에는 maximize throughout 비트가 켜집니다.1메가 데이터 전송을 해야하는데 1바이트마다 패킷이 하나씩 전송된다면? 어떨까요? 네트워크 과부하가 걸리겠죠..?
하지만…오늘날에는 대부분의 tcp/ip장비에서 이 tos를 지원하지 않는다네요.–
(The TOS feature is not supported by most TCP/IP implementation today)

<total length>
헤더를 포함한 전체적인 길이입니다. 이길이와 헤더길이를 비교해서 데이터가 어디서 시작하는지 알수있겠죠?
8비트이기때문에 65535까지 들어갈수있습니다.

<identification>
이값은 각각의 패킷을 구별하게합니다. 즉,패킷이 잘려져서 목적지에 패킷이 도달했을때, 그 패킷들을 재조합 할때 쓰이죠

flag와 fragment offset은  fragmentation을 다룰때설명드리겠습니다.

<time to live>
이값은 각각의 라우터를 지날때마다 1씩 감소합니다. 만약 0에 도달하면 패킷을 없애버리고, 발신지에 icmp메세지를 보냅니다. 즉, 패킷이 영원히 인터냇상을 떠도는것을 방지합니다.

<protocol>
이값은 저번 이야기에서 말씀드렸죠? 즉 어느 상위 레이어(층)으로 갈지를 결정하는것입니다.
tcp ? udp? ….

<header checksum>
이값은 패킷이 아무이상없이 목적지에 도달했는지를 검증합니다. 즉 중간에 패킷이 잘리거나, 데이터가 변조 된것은 거부해버리는것이지요.

모든 IP는 32비트 발신지 주소, 32비트 목적지 주소를 갖습니다.

옵션은 옵션입니다.(^^)
옵션은 여러가지 용도로 쓰입니다. 이것도 다음에 설명드리죠.

이상으로 IP헤더에 대한 간단한 설명을 살펴보았습니다.

# IP 라우팅이 뭐지?
라우팅은 길찾기 입니다. 내가 보낸 패킷이 정확히 목적지에 도달하게 하는것입니다.
자 그럼 그림으로 알아보죠.(IP는 설명을 쉽게하기위해서 조작된것임)

                (4.4.4.4) X    ─────────────┐
                                                         │
                                                   (INTERNET)
                                                         │
                                                         │
                      ┌────────────── C(3.3.3.3)
                      │
            ┌────┴───────┐
            │                        │
         A(1.1.1.1)               B(2.2.2.2)

이런 네트웍에서 A라는 호스트가 4.4.4.4에 가고자 한다면 어떻게할까요?
A라는 호스트는 자신의 라우팅 테이블을 봅니다. 그리고 자신의 라우팅 테이블에 4.4.4.4 라는 호스트는 없는것을 확인하고 C라는 디폴트 라우터로 패킷을 보내야 합니다. 이때 앞에서 잠깐언급했지만, ARP프로토콜을 이용해서 4.4.4.4라는 IP값에대한 하드웨어 주소를 알아냅니다.
이제 패킷을 보냅니다. 이때의 패킷은 어떤 모양일까요?

┌────┬─────┬───────┐
│        │          │              │
│ link   │ IP       │              │
│ header │ header   │              │
└────┴─────┴───────┘
  link header 에서 목적지는  3.3.3.3의 하드웨어주소
  IP header   에서 목적지는  4.4.4.4
이렇게 됩니다.
라우팅을 하는동안 IP header의 목적지주소는 바뀌지 않습니다.!
(사실,바뀔수는 있습니다. 이것은 다음에….)
바뀌는것은 link header의 목적지 하드웨어 주소입니다.
C에서도 똑같은 과정이 반복됩니다.
IP 헤더의 목적지 주소는 바뀌지 않고, link header의 목적지 주소만 디폴트 경로의 하드웨어 주소가 들어가지요.
이렇게 계속하다보면… X(4.4.4.4.)에 도달할수있겠죠?

# 서브넷은 어떻게 구성하지?(Subnet Addressing)
서브넷을 구축하는 이유는 A 클래스의경우 2^24 -2 개나 호스트를 연결할 수 잇고 B의 경우도 보면 2^16-2개나 호스트를 연결할수있기때문입니다. 이많은 호스트들을 한 내트워크에 연결하는 관리자는 없을것입니다.
서브넷이란 배정받은 주소를 쪼게서 쓰는것입니다.외부세계에서는 서브넷을 알수가 없겠죠.

210.94.165.0을 나눠보죠!
그것은 몇개의 서브넷으로 나눌것인지에 따라서 달라집니다.
만약에 4개의 서브넷으로 나눈다고 한다면 2비트가 필요하겠죠? ( 2*2=4 )
서브넷을 보면
210.94.165.0
210.94.165.64
210.94.165.128
210.94.165.192
이렇게 4개로 나울수있습니다^^
서브넷 메스크는?  210.94.165.192 가 되겠죠?
(1111111.11111111.11111111.11000000)

4개로 서브넷을 나눈다면 각 서브넷당 몇개의 호스트가 연결이 가능할까요?
6비트가 호스트에 할당되므로 2^6=64 입니다.
하지만 6비트가 전부0인것은 네트워크주소이고, 전부 1인것은 브로드케스트주소이지요? 그래서 64-2가 됩니다.
각 서브넷당 62개의 호스트를 가질수있는것이지요.

이것으로  IP에대한 이야기를 마치겠습니다.
소개식으로 설명한 부분들은 뒷부분에서 좀더 자세히 설명할 기회가있을것입니다
강좌내용중 이해안가는 부분있으면 질문해주세요.
제가 아는거면 답변해드릴께여. :)
오늘은 숙제를 내드리겠습니다.
숙제검사도 할거니까(?) 숙제다해오시기바립니다.^^ 히히
그럼 다음시간에 뵙죠.

<숙제>
1.오늘은 서브넷4개를 나눌때를 예로 들었습니다.
그렇다면 서브넷을 8개로 나눌려면, 각각의 서브넷주소는?(8개)
서브넷 매스크는?
각 서브넷당 몇개의 호스트가 연결가능할까요?
(8개를 나눌때 서브넷id를 어떻게 배정하든지 상관은 없습니다….)

2. IP헤더의 길이가 60바이트를 넘을수없다고했습니다.
   왜 그럴까요?

ARP AND RARP
ARP 와 RARP 에대해서 알아보겠습니다. 앞에서 잠깐 언급했듯이 ARP(Address Resolustion Progocol)는 32비트 인터넷주소를 48비트 하드웨어주소로 변환하고, RARP(reverse Addres Resolusion Progocol)는 그 역입니다.

                    32-bit internet address

                        ↓           ↑

                    48-bit Ethernet address

┌────┬────┬───┬───────────┬───┐
│        │        │      │                      │      │
│  dest  │ source │ type │ ARP request/reply    │ PAD  │
│address │address │ 0806 │                      │      │
└────┴────┴───┴───────────┴───┘
     6         6        2            28                  18

어디서 많이 본그림이죠? 두번쩨 강좌 켑슐화부분에서 나왓었죠.
여기서 ARP request/reply부분을 자세히 그려보죠.

┌──┬──┬──┬──┬─┬────┬───┬────┬───┐
│hard│prot│hard│prot│  │ sender │sender│target  │target│
│type│type│size│size│op│ethernet│ipaddr│ethernet│ipaddr│
│    │    │    │    │  │  addr  │      │  addr  │      │
└──┴──┴──┴──┴─┴────┴───┴────┴───┘
   2      2     1    1    2       6       4        6         4
<hard type>
하드웨어 주소의 타입을 말합니다. 이더넷의 경우 이값은 1입니다.

<prot type>
맵핑된 프로토콜주소의 타입을 표시합니다.
(type of protocol address being mapped)
IP 주소의 경우 이값은 0x0800입니다.

<hard size , prot size >
하드웨어 주소와 프로토콜주소(IP주소)의 바이트 크기입니다. ARP request or reply인경우 이값은 각각 6과 4이죠.

<op>
1인경우는 arp request
2인경우는 arp reply
3인경우는 rarp request
4인경우는 rarp reply를 뜻합니다.
이것은 frame type이 arp request 일때와 arp reply일때 같기 때문에,
그것을 구분하기 위해서 필요합니다.

그다은 발신지 하드웨어주소,목적지 ip 주소, 목적지 하드웨어주소,목적지 ip 주소  가 들어가죠.

[!!] arp request가 보내질때 목적지 하드웨어 주소를 제외한 모든 필드가 채워져서 보내집니다. 보내질때는 브로드캐스트로 보내집니다.
이 패킷을 받은 곳에서는 아직 비어있는 하드웨어 주소를 채우고, 발신지와 목적지의 주소들을 바꾸고, op필드를 2로 세팅하여 보냅니다.

arp 캐시(cache)가있어서 현제의 하드웨어 주소와 ip주소를 저장해둡니다.

그럼..실제로 어떻게 쓰이는지 알아보죠.
다음은 192.168.0.1에서 192.168.0.2로 텔넷을 실행했을때의 상황을 보여줍니다.
———————————————————————–
[root@super /root]# arp -a
[root@super /root]#
//arp -a 는 arp 케시(cache)를 보여좁니다.현제 아무것도 없죠?
//이때 telnet 192.168.0.1을 실행시키면 아래와같은 tcpdump결과가 나옵니다.

[root@super /root]# tcpdump -i eth0
tcpdump: listening on eth0
18:30:28.357656 arp who-has 192.168.0.2 tell 192.168.0.1
18:30:28.357656 arp reply 192.168.0.2 is-at 0:0:1c:2:51:2b
18:30:28.357656 192.168.0.1.1114 > 192.168.0.2.telnet: S 2440910836:2440910836
(0) win 512 <mss 1460>
//tcpdump는 패킷을 잡아서 보여줍니다.
// 먼저 192.168.0.2에대한 하드웨어 주소를 모르기때문에 arp를 이용해서
//알아보고있죠?
//하드웨어 주소를 알고난 후에야 실제로 패킷을  보내고있습니다.(3번째줄)

[root@super /root]# arp -a
? (192.168.0.2) at 00:00:1C:02:51:2B [ether] on eth0
[root@super /root]#
//그다음 arp 캐시를 보면 192.168.0.2의 하드웨어 주소가 적혀있죠?
—————————————————————————

#이제 RARP를 알아보겠습니다.
RARP는 ARP와 거의 유사합니다.
보내지는 패킷의 모양도 위에서 보여준 arp것과 거의 같습니다.
다른점만적어보면 frame type이 0x8035
            op      이 rarp request 일때 3,
            op      이 rarp reply   일때 4라는것입니다.
arp와 같이 rarp도 브로드캐스트 됩니다.
rarp가 쓰이는 용도는 디스크없는(diskless)컴퓨터가 자신의 IP주소를 얻기위해서 사용합니다. 하지만 요즘 하드디스크가 엄청싸져서…과연 디스크 없이 운영되는 컴퓨터는 거의 없을것입니다.
이것으로 ARP,RARP를 살펴보았습니다.

이제, 어제내준 숙제를 한번 풀여보죠!
먼저 219.94.165.을  8개의 서브넷으로 나눌려면, 3비트가 필요하겠죠?
8개의 네트워크 주소는
210.94.165.0
210.94.165.32
210.94.165.64
210.94.165.96
210.94.165.128
210.94.165.160
210.94.165.192
210.94.165.224
가 되겠죠.

세브넷 메스크는 255.255.255.224(11111111.11111111.11111111.11100000)가 되고, 각 서브넷당 30( 2^5 – 2 )개의 호스트가 연결할수있겠죠?
(서브넷에대한 자세한것은 /usr/doc/HOWTO/translations/ko/mini/IP-Subnetworking을 참고하세요)

다음문제는 ip해더가 60바이트를 넘을수없는이유였죠?
ip헤더의 길이를 나타내는필드는 4비트입니다.
실제 바이트수 / 4 가 여기에 들어간다고했죠?
그렇다면  4비트가 표현할수있는최고의수는 15입니다.( 8+4+2+1 )
그러므로 15 * 4 = 60 이죠?

이것으로 오늘이야기를 마칩니다.
어떠한 피드백도 환영합니다.
내일 이시간까지 안녕히계십시요 :)

 

ICMP( Internet Control Message Protocol) and   Ping Programing

오늘은 ICMP와  ping 프로그램에 대해서 알아보겠습니다.
icmp는 말그대로 제어메세지를 교환하는 프로토콜입니다. 즉,에러메세지나 현제
의 상태를 나타내는 메세지들을 보내지요.

아래 그림은 ICMP 메세지가 IP에의해 켑슐화 되는그림입니다.
<=============== IP datagram ================>
┌───────┬──────────────┐
│              │                            │
│   IP         │   ICMP message             │
│ header       │                            │
└───────┴──────────────┘
   20byte

그럼 ICMP message가 어떻게 생겼는지 알아보죠.
┌───────┬────────┬────────────────┐
│              │                │                                │
│ 8bit- type   │ 8bit-  code    │    16bit- checksum             │
├───────┴────────┴────────────────┤
│                                                                  │
│             여기 적히는것은 type와 code에 따라서 달라짐          │
│                                                                  │
└─────────────────────────────────┘

type 와 code는 매우 많습니다. /usr/include/linux/icmp.h 에 있는값들이 전부 들어갈수있습니다. type이라는것은 메세지의 형태를 말하며,code 라는것은 좀더 type을 세분화 시키는것입니다.
몇개만 예를들어서 알아보겠습니다…

type      code             설명                       query       error
  0        0              echo reply(ping reply)        *
  3        3              port unreachable                          *
  3        1              host unreachable                          *
  .        .                  .
  8        0              echo request(ping request)    *
  .        .                  .
  13       0              timestamp request             *
  14       0              timestamp reply               *
  .        .                   .
  17       0              address mask request          *
  18       0              address mask reply            *

등등 여러가지가 있습니다. 우리가 ping을할때 type 8  code 0으로 패킷이 나가고, type 0 code 0 으로 목적지 호스트에서 우리 호스트로 패킷을 보내는것입니다.
또한 우리가 존재하지 않는 포트에 패킷을  보냈을때는 type 3 code 3 으로 그러한 포트가 이호스트에 존재하지 않는다는것을 발신지 호스트에 보내는것입니다.
다른것들도 다 이와 비슷합니다.똑같은 type3이지만 code가 1인가,3인가에 따라서 메세지가 틀려짐을 확인할수 있을것입니다.
맨 오늘쪽에 query와 error는 이메세지가 query(질문?)메세지인지 error메세지인지를 나타냅니다.예를들어 ping프로그램이 보내는 echo request ,echo reply는 상대방 호스트가 살아있는지에 대한 질문하는 메세지죠?하지만 port unreachable 이나 host unreachable는 포트,호스트를 찾을수없다는 에러를 나타내는 메세지입니다.

icmp에러 메세지는 아래와 같은 경우 생성되지 않습니다.
1. icmp에러메세지에 대한 응답으로
2. 브로드케스트나 멀티케스트주소로 보내지는 패킷에 대한 응답으로

icmp에러메세제에 대한 응답으로 icmp에러메세지가 생성될때는 어느것이 잘못되었는지에 대한것이 불분명하게되기때문입니다.
브로드캐스트나 멀티캐스트에 대한 icmp에러메세지가 보내질수있다면, 수많은 패킷들이 한번에 방출되어 네트워크 과부하가 걸릴수있습니다.

이제 실제적으로 쓰이는 몇가지 예를 알아보겠습니다.

##
## icmp timestamp request and reply
##
timestamp request는 현제 시간을 다른 시스템에 묻는것입니다. 응답으로 오는것은 자정으로부터의 밀리세컨드(miliseconds)입니다.
기준시간은 Coordinated Universal Time(UTC)입니다.
이메세지의 장점이라면 miniseconds로 시간을 알수있다는것이며, 단점이라면 자정으로부터의 시간이 응답되므로, 현제 오늘이 며칠인지 알아아만 한다는것입니다…
다음은 이메세지가 보내지는 형식입니다.
0                7  8            15  16                               31
┌────────┬───────┬─────────────────┐
│                                                               
  type(13 or 14)  code (0)                  checksum           
────────┴───────┼─────────────────┤
                                                                 
      identifier                         sequence number         
────────────────┴─────────────────┤
                                                                   
                      originate timestamp                          
──────────────────────────────────┤
                                                                   
                       receive timestamp                           
──────────────────────────────────┤
                                                                   
                       transmit timestamp                          
└──────────────────────────────────┘

request를 보낼때는 originate timestamp를 채워서 보내게 됩니다.받는쪽에서는
받은시간을 receive timestamp에 채우고 보내는 시간을 transmit timestamp에
채워서 reply를 보내는것입니다.그러나 대부분의 컴퓨터가 receive timestamp와
transmit timestamp는 같습니다.

도표로서 3가지 시간을 알아보면,
originate              received    tranmit
        request                         reply                
============================> ================================>
                                                             
<────────────── RTT ────────────────>

( RTT란 round trip time으로 패킷을 보낼때와 되돌아올때의 시간간격입니다.)

##
## 이제 Ping 프로그램을 알아보죠.
##

0              7  8             15  16                               31
┌───────┬────────┬─────────────────┐
│              │                                                 
type( 0 or 8 )  code (0)                   checksum            
───────┴────────┼─────────────────┤
                                                                 
      identifier                        sequence number          
────────────────┴─────────────────┤
                                                                   
                         optional data                             
                                                                   
└──────────────────────────────────┘

다음은 192.168.0.1에서 192.168.0.2로 ping을 실행한 출력결과입니다.

[root@super /root]# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=32 time=2.2 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=32 time=1.1 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=32 time=1.1 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=32 time=1.1 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=32 time=1.0 ms
64 bytes from 192.168.0.2: icmp_seq=5 ttl=32 time=1.0 ms

— 192.168.0.2 ping statistics —
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 1.0/1.2/2.2 ms

icmp_seq 이값이 1씩 증가함을 알수있습니다. 이값은 위의 메세지 형태에서 sequence number를 뜻합니다.
ping 프로그램은 RTT를 계산할수있습니다. ping이 패킷을 보낼때 optional data 부분에 현제시간을 넣어서 패킷을 보냅니다.상대방에서 패킷이 되돌아오면 현재시간에서 optional data에 적힌 시간을 빼줌으로서 RTT를 계산할수있는것입니다.
위의 출력결과에서 맨 오른쪽에 보이는 time이 RTT를 뜻합니다.
ping을 실행시키면,전시간에 telnet을 실행시켰던것처럼 ARP테이블이 갱신 됩니다.

이것으로 오늘이야기를 마치겠습니다.
다음에는 traceroute program 과 IP routing 에대해서 알아보겠습니다.

Traceroute Program   ,   IP Routing

오늘은 패킷이 가는길을 보여주는  traceroute 프로그램과, IP 라우팅에 대해서 알아보겠습니다.

##   Traceroute Program
traceroute 는 과연 내가 보낸패킷이 어떤 경로를 거쳐서 목적지에 도달하는가?에대한 해답을 제시합니다.이프로그램은 icmp와 ip 헤더의 TTL필드를 사용합니다.내가 보내는 패킷이 매번마다 똑같은 경로를 거쳐서 목적지에 도달하는것은 아니지만, 대부분의 경우 똑같은 경로를 거쳐서 이동합니다.
라우터가 TTL값이 0이나 1인 패킷을 받으면,  이패킷을 다른곳으로 전달시키지않고 패킷을 만든 발신지에 “time exceeded”라는 icmp메세지를 보냅니다.이 프로그램의 아이디어는 여기서 출발하는것입니다.
만약 ttl을 1로 세팅한후 패킷을 보내면 첫번째 라우터로부터 time exceeded라는 icmp메세지를 받을것이고, 이것으로서 패킷이 가는 첫번째 경로를 구할수있는 것입니다. ttl을 2로 세팅한후 보내면 두번째 라우터에서 “time exceeded” 메세지를 보낼것이고,……..이런식으로 경로를 구할수있는것입니다.
그리고, 목적지에 도달했다면, 목적지 호스트는 “port unreachable”메세지를 발신지 호스트에 보냅니다.그러므로 패킷을 보낼때 포트번호는 잘쓰지않는 번호를 택하게 됩니다. 30000보다 큰수를 사용합니다.
실제로 traceroute 출력 결과를 보면서 설명하겠습니다.

svr4 % traceroute slip
traceroute to slip (140.252.13.65), 30 hops max, 40 byte packets
1  bsdi (140.252.13.35)  20ms  10ms  10ms
2  slip (140.252.13.65)  120ms 120ms  120ms

svr4에서 slip로 가는 경로를 구하기 위한 것입니다.
두번째 줄에서 40byte packets은 20바이트 ip헤더,8byte udp헤더 , 12byte user data 입니다. user data에는 매번 패킷을 보낼때마다 증가하는 sequence number와 나가는 ttl값에대한 복사,패킷이 보내진 시간을 기록합니다.
세번째줄에서 첫번째 경로로 bsdi를 거치고있죠.
매번마다 3개의 패킷을 보냅니다.  20ms 10ms 10ms 에서 왜 첫번째가 더 시간이 오래 걸렸을까요? 왜냐하면 arp테이블정보가 없기 때문에 그정보를 얻기위해서 arp request를 보냈기 때문입니다. 이시간은 발신지에서 패킷을 되돌리는 라우터까지의 RTT입니다. 그러므로 bsdi에서 slip까지의 RTT를 구하고싶다면…
120ms – 10ms = 110ms 이렇게 나옵니다.

이제 icmp time exceeded message를 알아보겠습니다.
code의 값에 따라서 두가지가 있습니다.
code가 0일때는 “time exceeded”이고 code가 1일때는 “time exceeded during reassembly”입니다. code가 1일때는 잘려진 패킷을 재조합하는시간이 초과했을때 발생합니다.  code가 1일때는 뒤에 잘려진( fragmaented datagram)패킷을 설명할때 자세히 알아볼기회가 있을겁니다.

다음은 icmp time exceeded message 형식입니다.
0              7  8             15 16                               31
┌───────┬────────┬────────────────┒
│              │                │                                ┃
│  type(11)    │  code ( 0 or 1)│           checksum             ┃
├───────┴────────┴────────────────┨
│                                                                  ┃
│                       unused (must be 0)                         ┃
├─────────────────────────────────┨
│                                                                  ┃
│       IP header(including optings) +                             ┃
│                     first 8byte of original IP datagram data     ┃
│                                                                  ┃
┕━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

tracerotue 에 관하여 몇가지 알아두어야할 사항이있습니다.
첫째, 똑같은 경로를 통해서 전달된다는 보장은 없습니다.
둘째, icmp에러메세지가 udp패킷이 가는길과 똑같은 길을 간다는 보장도 없습니다.그러므로 RTT를 계산할때 잘못될수도 있다는것입니다. 즉 udp패킷이 목적지 호스트에 가는시간이 1초였고 icmp에러메세지가 되돌아오는시간이 3초였다면 RTT는 4초가 되죠.
세째, 되돌아오는 icmp에러메세지는 udp패킷이 도착한 인터패이스라는것입니다.
설명을 부가하자면…
       network1                                          network2
=====================                             ======================
            │                                            │
            │if1                                         │if4
      ┌──┴───┐                              ┌──┴───┐
      │            │ if2                      if3 │            │
      │  router 1  ├───────────────┤  router 2  │
      │            │                              │            │
      └──────┘                              └──────┘

network1에있는 호스트중하나가 network2에있는 호스트중하나에 traceroute할때는 if1 , if3의 경로를 얻게되고….
network2에있는 호스트중하나가 network1에있는 호스트중하나에 traceroute를 하면 if4 , if2 의 경로를 얻게됩니다.
그러므로 ip주소로보다  name으로 출력된것을보면  알아보기 쉽습니다.

## IP Routing
라우팅은 ip의 가장 중요한 기능중 하나입니다. 이것은  패킷이 정확하게 목적지에 도달할수있게 하는 기능입니다.
다음은 ip가 라우팅 테이블에서 찾을때 수행하는 순서입니다.
1. 호스트주소를 찾습니다.
2. 네트워크주소를 찾습니다.
3 디폴트 란(default entry)을 찾습니다.
즉 제일먼저 호스트부터 보고,네트워크,디폴트,이런순서로 찾습니다.

라우팅 테이블을 만드는 방법을 잠깐언급하겠습니다.
먼저 호스트를 추가할때는 host라는 키워드를 사용합니다.
   예)  route add -host 192.168.1.2
네트워크를 추가할때는 net이라는 키워드를 사용합니다.
   예)  route add -net 192.168.1.0
디폴트 를 설정하려면…
   예) route add default gw 192.168.1.7
마지막으로 경로를 지우려면 del을 사용합니다.
   예) route del 192.168.1.2

라우팅 테이블에서 플레그들을 살펴보죠.
5개의 플레그가 있습니다.

U 경로가 사용중이라는 표시입니다.
G 경로가 게이트웨이라는것입니다. 이 플레그가 없으면 목적지가 직접적으로 연결되었음을 뜻합니다.
H 경로가  호스트라는것입니다. 이 플레그가 없으면 그 길은 네트워크라는것입니다
D 경로가  리다이렉트에 의해서 만들어졌음을 뜻합니다.
M 경로가  리다이렉트에 의해서 수정되었음을 뜻합니다.

다음은 포워드(forward) 에대해서 알아보겟습니다.
포워드는 내가 받은 패킷을 다른경로를 통해서 다시 내보낼수있느냐 하는것입니다.  기본적으로 현제 리눅스는 그것을 불가능하게 하였습니다. 리눅스에서 이것을 가능하게하려면 커널컴파일을 다시해야합니다.
이 포워드라는 기능으로 호스트를 라우터처럼 쓸수있는것입니다.

이제 icmp 리다이렉트에대해서 알아보겠습니다.
이것은 라우팅 테이블에 있는 경로보다 더 좋은 경로가 있을경우에 기존의 경로를 바꾸는것입니다.

           ┌───────────  host
          A│                         ↑
           │C┌───────────┘
     ======│=│===================================================
           │ │ ┌─────────┐
           ↓ │ │B                 ↓
           router1                 router 2

A. host 가 패킷을 router1으로 보낸다고 가정합니다.
   rotuer1은 그패킷을받고 그의 라우팅 테이블을 살펴본결과 router2가 보내야할 경로로 결정을합니다.
B. router1 이  router2에 패킷을 보낼때 router1은 지금 보내는 인터페이스가 패킷이 들어 올때와 같은 경로라는것을 감지합니다.
C. 그러므로 router1은 host에 다음에 보내 는 패킷은 날거치지말고 router2로 곧바로 보내라는 icmp 리다이랙트 메세지를 보냅니다.

icmp리다이렉트로 만들어진 경로에는 route의 플레그란에보면 D가
세팅되어있습니다.

다음은 icmp리다이렉트 메세지의 형식입니다..
0             7  8             15 16                                31
┌───────┬────────┬────────────────┐
│                                                             
  type(5)     code ( 0 – 3)            checksum             
├───────┴────────┴────────────────┤
                                                                 
              사용해야하는 라우터 ip주소                         
─────────────────────────────────┤
                                                                 
       IP header(including optings) +                            
                     first 8byte of original IP datagram data    
                                                                 
└─────────────────────────────────┘

code 값에 따라서 4가지의 리다이렉트 메세지가 잇습니다.

Code 설명
0 네트워크 리다이렉트
1 호스트 리다이렉트
2 Type of Service와 네트워크 리다이렉트
3 Type of Service와 호스트 리타이렉트

리다이렉트는 호스트가 아닌 라우터에서만 만들어집니다.

Dynamic Routing Protocols ,   UDP: User Datagram Protocol
## Dynamic Routing Protocols
저번이야기는 고정된 라우팅(static routing)이었습니다.인터페이스가 설정될때 기본으로 라우팅 테이블이 만들어지고, route명령어로 추가,삭제할수있었으며 icmp 리다이렉트로 잘못된경로가 쓰일경우 수정할수있었습니다.  이것은 작은 규모의 네트워크에 잘 작동합니다.
이번이야기는 라우터들이 서로 통신하기위해서 사용하는 다이나믹 라우팅 프로토콜입니다.주로 RIP(routing information protocol)에대해서 알아보겠습니다.
다이나믹 라우팅은 커널이 ip층에서하는 라우팅 방법을 바꾸지는 않습니다.
여전히 커널은 호스트,네트워크,디폴트 순으로 라우팅을 합니다.이것은 “라우팅 메커니즘”이라고 부릅니다. 달라지는것은 라우팅 데몬에의해서 경로가 동적으로 추가,또는 삭제된다는것입니다.

라우팅데몬이란 근접한 라우터들과 라우팅 정보를 교환하는일을 하는 데몬입니다.
routed 와 gated가있습니다.routed는 RIP만을 지원하는데 반하여, gated는 그밖에 OSPF,EGP,BGP를 지원합니다..

다음은 RIP가 켑술화되는것이고요…
|<—————– IP datagram ——————->

            |<——— UDP datagram ————–>

┌─────┬───┬──────────────┐
│     IP   │ UDP  │                            │
│   header │header│    RIP message             │
└─────┴───┴──────────────┘
   20byte     8byte

다음은 위에서 RIP message 부분만 떼어낸것입니다.
0              7  8             15 16                               31
┌───────┬────────┬────────────────┐
│ command(1-6) │ version(1)     │         (must be zero)         │
├───────┴────────┼────────────────┤
│ address family(2)              │        (must be zero)          │
├────────────────┴────────────────┤
│                     32-bit IP address                            │
├─────────────────────────────────┤
│                    (must be zero)                                │
├─────────────────────────────────┤
│                     (must be zero)                               │
├─────────────────────────────────┤
│                    metric(1-16)                                  │
├─────────────────────────────────┤
│                                                                  │
│(위의 20바이트와 똑같은 형식으로 25개의 경로까지 설정가능합니다.) │
│                                                                  │
└─────────────────────────────────┘
<command>
1     request
2     reply
3,4   현제 쓰이지 않습니다.
5     poll
6     poll-entry

request는 다른 시스템에 라우팅테이블 전체 혹은 일부를 보내달라는 요청이며, reply는 그요청에 따라서 보내는자의 라우팅 테이블입니다.

<version>
버전을 뜻하며, 보통1입니다.

<address family>
ip주소일경우는 항상2입니다.

<metric>
메트릭이란 홉 카운트(hop count)입니다.곧설명합니다.

이제,routed 의 작동에대해서 알아보죠.
/etc/services에 보면
route       520/udp     router routed 라인이있죠.
이와같이 520번 포트를 사용합니다.

*초기화(initialization)
데몬이 시작할때 모든 인터페이스를 감지하고, 각각의 인터페이스에 라우터의 모든 라우팅 테이블을 요구하는 request패킷을 보냅니다.
request패킷은 command가 1  , address family가 0,metric이 16으로 세팅되어서 방출됩니다.이것은 모든 라우팅 테이블을 요구하는 특별한 request입니다.

*요구를 받음.(request received)
위에서처럼 모든 라우팅 테이블을 요구하면, request를 받은 라우터는 자신의 모든 라우팅 테이블 정보를 보냅니다.
그렇지않고 특정한 주소에대한 request를 보내올때는 특정한 주소에 대한 처리만을 합니다. :
만약 우리가 그 주소에대한 경로를 갖고있다면 우리의 값으로 metric을 정합니다. 그렇지 않으면 metric을 16으로 정합니다. (16은 우리가 그 목적지에대한 경로
를 갖고있지 않다는것입니다.)
응답이 리턴됩니다.

*응답을 받음(response received)
응답은 라우팅테이블을 존재하는것을 지워버릴수도있고,없는것을 만들수도있고, 이미 있는 경로를 수정할수도있습니다.

*규칙적인 라우팅 업데이트
20초마다 모든 라우팅 테이블경로가 근접한 라우터에 보내집니다.

*재빠른 업데이트(triggered)
이것은 metric이 바뀔때마다 발생합니다.

이제 위에서 많이 언급한 Metrics에 대해서 알아보죠.
메트릭이란 좀전에 언급햇듯이 홉 카운트입니다.
              140.252.1.0         140.252.2.0
  =====================            =========
   │               │              │
   │               R2              R3
   │               │              │ 140.252.3.0
   │        =====================================
   │               │
   │               R1
   R10              │       140.252.4.0
   │      =============================
   │                       │
   │                       R4
   │                       │               140.252.5.0
=========================================================
   │         │          │            │
*******       R5          R6            R7
*LINUX*       │          │            │
*******     ========    =========      ===========
          140.252.6.0     140.252.7.0     140.252.8.0

위의 그림을 예를들어설명하겠습니다.위에서 언급했듯이 20초마다 브로드케스트
를 이용하여 규칙적인 라우팅 업에이트가 이루어집니다.
이때 LINUX라는 호스트에서 tcpdump해보면,
R5는   140.252.6.0 metric 1,
R6는   140.252.7.0 metric 1,
R7는   140.252.8.0 metric 1 를 각각 브로드케스트합니다.

R4는
140.252.1.0       metric 3
140.252.2.0       metric 3
140.252.3.0       metric 2
140.252.4.0       metric 1
를 브로드케스트합니다.

R10은
140.252.1.0 metric 1을 브로드케스트하겠죠.

설명을 좀 복잡하게 한것같은데요,결론은 간단합니다.
즉 중간에 라우터가 몇개가 있느냐, 그갯수입니다.
만약 LINUX박스가 R4로부터 140.252.1.0 metric 3를 받고, R10으로부터 140.252.1.0 metric1을 받았다면,리눅스 박스는 후자를 경로로 선택합니다. 왜냐하면 metric이 작기때문입니다.

RIP에서 metric은 15까지 사용할수있습니다. 16은 모든 라우팅테이블을 보내라는 특별한 의미로 쓰입니다.

##
## UDP : User Datagram Protocol
##
UDP는 간단한 트랜스포트 층의 프로토콜입니다. UDP는 신뢰성은없습니다.즉,내가 보낸 패킷이 정확히 목적지에 도달했다는 확인을 할수없다는것입니다.
다음은 ip층에서 udp데이터그램이 캡술화되는그림입니다.

│<──────── IP datagram ─────────>

            <───── UDP datagram  ─────>

┌─────┬───┬──────────────┐
     IP   UDP                             
   header header    UDP data               
└─────┴───┴──────────────┘
   20byte     8byte

다음은 udp헤더 그림입니다.

0                               15 16                               31
┌────────────────┬────────────────┐
                                                               
16-bit source port number      16-bit destination port number
────────────────┼────────────────
                                                               
    16-bit UDP length               16-bit UDP checksum        
────────────────┴────────────────┤
                                                                 
                    data(if any)                                 
                                                                 
└─────────────────────────────────┘
<port number>
이것은 트랜스포트중에서 어플리케이션층으로 넘어갈때 필요한것입니다.
이 포트넘버는 UDP와 TCP가 독립적입니다. 즉 똑같은 포트넘버를 따로 사용할수있다는것입니다.

<UDP length>
헤더를 포함한 길이를 뜻합니다. 길이의 최소값은 8byte입니다. 즉 데이터없는 패킷을 보낼수있다는것입니다.

<udp checksum>
udp에서 체크섬은 옵션입니다. 만약 전달된 패킷의 처크섬이 0이라면 이것은 체크섬 계산을 하지 않았다는것입니다.또한 만약,계산한값이 0이라면 65535로 대체합니다.(65535는 모든16비트가 1일때의 값입니다.)옵션이지만 계산해야합니다.
체크섬 루틴은 RAW socket프로그래밍에서 설명했으므로 생략합니다.
ip에도 체크섬이 있었습니다. udp나 tcp도 거의 비슷하지만 몇가지 다른점이있습니다. 첫째 udp는 홀수가 될수있다는것입니다.(홀수가 되면 안되기에 raw socket프로그래밍에서 만약 홀수이면 1바이트를 덧붙이라는 코드가있었죠?)
둘째, udp와 tcp는 12바이트의 가짜 헤더(pseudo header)를 채크섬을 계산할때 만들어야한다는것입니다.
다음은 체크섬을 계산하기위한 것입니다.
0                               15 16                               31
┌─────────────────────────────────┐ ┯
│                                                                  │ │
│             32-bit source IP address                             │ │
├─────────────────────────────────┤ udp
│                                                                  │pseudo
│             32-bit destination IP address                        │header
├──────┬─────────┬────────────────┤ │
│            │                  │                                │ │
│  zero      │8-bit protocol(17)│  16-bit UDP length             │ │
├──────┴─────────┼────────────────┤ ┿
│                                │                                │ │
│   16-bit source port number    │  16-bit destination port number│ udp
├────────────────┼────────────────┤header
│                                │                                │ │
│      16-bit UDP length         │    16-bit UDP checksum         │ │
├────────────────┴────────────────┤ ┷
│                                                                  │
│                         data                                     │
│                                                                  │
└─────────────────────────────────┘

udp패킷을 받은쪽에서는 체크섬을보고 만약 값이 틀리면 어떠한 에러메세지도 없이 그냥 거부해버립니다.(silently discard)

이제 첫번째 이야기에서 미뤄왔던 IP fragmentation(분열)을 알아보겠습니다.
IP층은 링크층에 IP데이터그램을 보내기전에  링크층에 MTU(maximum transmision unit)을 물어봅니다.IP데이터그램이 MTU보다 클경우 fragmentation을 하게됩니다.
IP 헤더의 flags는 DF(don’t fragment),MF(more gragment)가있습니다. 말그대로 df이면 절대로 자르지 말라는것이고 mf이면 더 자를수있다는것입니다.fragment는 패킷이 목적지에 가는동안 여러번 일어날수있습니다.
IP헤더의 fragment offset은 처음부터 얼마나 떨어져있는지를 나타냅니다.이걸 알아야만이 패킷을 재조합할수있겠죠?
MTU는 전에 말했듯이 이더넷의경우 1500입니다.즉,1500이 넘을경우 fragment가 발생합니다.여기서 ip헤더가 20바이트 udp헤더가8바이트이므로, 데이터가 1473이상일경우(1473부터)  fragment가 일어납니다.
그럼 이제 그림으로 자세히 알아보죠.

     │───────── IP datagram  ──────────│
     ┌─────┬───┬────────────────┐
     │   IP     │ UDP  │   UDP data (1473 byte)         │
     │  header  │header│                                │
     └─────┴───┴────────────────┘
         20         8

위에서 udp데이터가 1473으로 1472보다 1이 많죠? 그리므로 아래와같이 패킷이 잘려지게됩니다. 즉, 데이터가 1472인것을 하나만들고 나머지를 하나더 만들고있죠
두번째 패킷에는 udp헤더가 없습니다.

┌─────┬───┬───────────┐      ┌─────┬────┐
│  IP      │ UDP  │                      │      │ IP       │        │
│ header   │header│                      │      │ header   │        │
└─────┴───┴───────────┘      └─────┴────┘
   20         8           1472                           20           1

여기서 첫번째 패킷은 fragment offset이 0이고, 두번째 패킷에서의 fragment offset은 1480이 됩니다.

ps.용어상의 혼돈을 줄이고자,또한 적당한 우리말을 찾지 못해서, 불가피하게 영어를 많이 쓰게 되는군여^^

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중