DHCP 깊게 알아보기

 

 

1. 원하는 IP주소 할당받기

DHCP Request Message를 자세히 보게되면 아래와 같은 [Requested IP Address]라는 항목이 존재합니다.

 

DHCP Request Option

 

DHCP Server가 할당하기를 원하는 IP주소가 아닌 다른 IP주소를 요청할 경우 어떤 응답이 올지 궁금하지 않습니까?

(크흠... 저는 궁금했습니다.)

 

 

확인해보기

위의 상황을 만들어보기 위해서 먼저 Jupyter notebook을 열었습니다.

IP주소를 일단 할당받을 이후에 새로운 IP주소를 요청하는 형태로 진행해보았습니다.

 

 

 

먼저 기존의 DHCP PACKET을 그대로 복제해서 전송해보았습니다.

 

DHCP PACKET

 

Wire Shark를 이용하여 Packet Data를 Hex Stream으로 복사한 후 해당 데이터중 dhcp의 데이터 부분만 뽑아내어 그대로 전송하였습니다.

 

여기서 특이한 부분은 UDP부분에 들어가는 CheckSum값이 틀리게 전송되고 있다는 것이었습니다.(복제되기전 패킷부터)

 

덕분에 Checksum값을 계산해주지 않고 그냥 전송할 수 있었습니다. ㅎㅎ

 

socket은 UDP이기 때문에 DGRAM으로 열어주시고, 68번 port를 Source로 67을 Destination으로 설정해주었습니다.

 

< 68번 Port로 Socket을 Bind를 해준 상태로 와이파이를 연결하면 IP주소를 받아오지 못할 수 있습니다. >

< 중간에 와이파이를 다시 잡아야할 필요가 있다면, socket close 후 진행해주세요 >

 

 

어찌되었든 패킷을 복제해서 전송해봤는데, ACK가 정상적으로 수신되는 것을 볼 수 있었습니다.

 

이제 DHCP의 메시지 중 Request IP 부분을 수정해서 다시 전송해보겠습니다.

 

IP Address 영역
Hex Data 중 IP 영역

ac(16) : 172

1e(16) : 30

01(16) : 01

23(16) : 35

 

위의 데이터의 마지막 23(16)을 64(16)으로 변경해서 전송해보겠습니다.

(64(16)은 10진수로 100입니다. 즉, 172.30.1.100 으로 요청)

 

실행결과

 

실행결과 위와같이 NAK 메시지를 수신하였습니다.

 

NAK는 'Negative ACK'를 의미합니다. 즉, 싫다는 뜻입니다. 힝...

 

NAK...

그 이후로 IP주소를 변경해가며 요청해보았지만, 전부 거절당했습니다.

 

서버측에서 DHCP Discover 단계에서 허가해준 IP주소에 한정해서 할당이 가능한듯합니다.

 

 

 

2. DHCP Discover 요청

위에서의 실패를 발판삼아 이번에는 Discover 요청부터 수행해보겠습니다.

 

마찬가지로 Discover 패킷을 복제해보았습니다. (역시나 Checksum은 맞지 않습니다.)

 

DHCP Discover

 

DHCP Discover에 대한 응답도 잘 왔습니다. (DHCP Offer)

 

다만, Discover의 경우 IP주소를 요청할 뿐 원하는 IP주소를 선택할 수 없으며, 동시에 이미 IP주소를 할당받은 상태로는 아무리해도 결과가 동일합니다.

 

고민이군요...

 

테스트하는 공간에 카페이다보니 공유기 설정창에 접속해서 만져보기가 힘드네요.

 

추후에 다른 환경에서 확인 후 이어서 포스팅 하겠습니다 ㅎㅎ

DHCP 프로토콜이란?

 

1. DHCP란?

DHCP(Dynamic Host Configuration Protocol)는 조직의 네트워크(사설망)의 호스트에게 동적으로 IP주소를 할당하는 프로토콜입니다.

쉽게 생각하면 사설 IP를 할당하는 공유기기에 PC를 연결하면 자동으로 192.168.~ 로 시작하는 IP주소를 자동으로 할당해주는 것을 생각하시면 좋습니다.

 

개인 또는 소규모 사업체에서는 위에서 언급한것과 같이 공유기를 통해 사설 IP주소를 할당하지만, 어느 정도 규모가 갖춰진 곳에서는 DHCP 서버를 운용하여 사용합니다.

 

 

 

2. DHCP의 장단점

 

DHCP의 장점

 : DHCP 이전에는 [ MAC주소 - IP주소 ]를 네트워크 관리자가 직접 맵핑하여 서버에 저장해 두고 PC가 부팅되면 해당 사항을 PC에서 BOOTP라는 프로토콜을 이용하여 알아오는 방식이었습니다.

이러한 방식은 매번 새로운 IP장비를 연결할때마다 관리자가 직접 IP주소와 MAC 주소를 맵핑시켜줘야 할 필요가 있습니다. 하지만 DHCP방식이 도입되면서는 자동으로 PC에 IP주소를 할당해주기 때문에 이러한 문제를 해결할 수 있었습니다.

 

또한 이러한 방식은 서버에서 모든 사설 IP주소를 관리하기 때문에 IP주소 충돌과 같은 문제를 예방할 수 있습니다.

 

 

DHCP의 단점

: DHCP는 서버가 자동으로 IP를 할당하기 때문에 몇가지 문제가 있습니다. 예를 들어 A라는 PC가 192.168.0.2라는 IP주소를 갖고 있다가 연결이 해제되면 해당 IP주소를 다른 B라는 PC가 할당받을 수 있습니다. 가정집과 같은 네트워크에서는 큰 문제가 없겠지만, 만약 포트포워딩으로 특별한 서비스를 제공하는 장비가 네트워크에 물려있을 경우 정전 등에 의해 공유기(DHCP 서버)가 재부팅될 때, 갑작스럽게 IP주소가 변경되어 서비스가 불통이 될 수 있습니다.

 

또한 IP주소를 기반으로한 인증방식을 갖고 있는 서비스가 사설 네트워크에 제공된다면 이것 역시도 문제를 발생시킬 수 있습니다.

 

이러한 문제들 외에도 보안과 서비스에 관련된 문제들이 있고 이러한 문제를 해결하는 여러 방식들이 존재합니다

 

 

 

3. DHCP의 원리

DHCP의 IP주소 할당방식은 'IP주소 임대'가 핵심입니다.

특정 장비에 특정 IP주소를 일정 기간동안 빌려주는 방식이고, 해당 시간이 끝나면 다시 서버가 회수합니다.

이 과정에서 장비와 서버는 [IP주소 임대 요청], [임대기간 연장], [IP주소 사전 반납], [재연결 요청] 등의 통신을 수행합니다.

 

 

4. DHCP PACKET

DHCP는 Client는 UDP 68번, Server는 UDP 67번을 사용합니다.

 

 

1) DHCP DISCOVER ( Client -> Server )

 

 

DHCP Discover
DHCP Discover

DHCP Discover Message는 위와같이 네트워크 전체에 '브로드캐스팅'되는 것을 볼 수 있습니다.

 

Client가 Server에 전송하는 Packet으로 Client는 자신의 MAC 주소를 네트워크에 브로드캐스팅합니다.

 

브로드캐스팅된 해당 패킷을 DHCP 서버가 확인하면 'DHCP 서버의 IP주소'와 'DHCP 서버가 할당할 수 있는 IP주소'를 해당 장비에게 전달합니다. (DHCP OFFER)

 

 

2) DHCP OFFER ( Server-> Client )

 

DHCP Offer
DHCP Offer

 

위에서 보면 [172.30.1.254 = 공유기(DHCP 서버)]가 [172.30.1.35 = Client에게 할당하려는 IP주소]에게 DHCP Offer Message를 전송하는 것을 볼 수 있습니다.

 

특이한 것은 DHCP Server가 목적지로 하는 172.30.1.35는 아직 Client의 IP주소가 아니라는 것입니다. 때문에 Client 측에서는 해당 패킷을 수신하면 이더넷(Layer 2) 계층에서는 자신의 MAC 주소를 목적지로 하기 때문에 상위계층(Layer 3, Network)으로 올려 보내지만 해당 Layer에서는 자신을 목적지로 한 IP주소가 아니라고 생각합니다. 해당 장비가 Routing 기능이 활성화되어있다면 어떻게 될지 궁금하네요.

 

어찌 되었든 해당 DHCP Offer Message를 좀 더 보겠습니다.

 

DHCP의 메시지 영역을 보면 아래와 같은 내용이 있습니다.

 

DHCP Offer

해당 내용은 현재 IP주소를 할당하려는 DHCP 서버가 Client에게 할당하려는 IP주소와 네트워크의 정보들을 공지한 것입니다.

 

해당 내용을 참고하여 Client는 해당 IP주소를 사용할 것인지를 판단하고, 해당 IP주소를 할당받기를 원한다면 DHCP 서버에게 DHCP REQUEST Message를 전달합니다.

 

 

3) DHCP REQUEST ( Client -> Server )

 

DHCP Request
DHCP Request

 

DHCP Request는 DHCP Server가 알려준 IP주소와 네트워크 정보를 잘 수신하였고, 해당 IP주소를 할당받겠다는 응답을 전달하는 역할을 수행합니다.

 

위에 보시면 아직 송신지 주소는 0.0.0.0인 상태이며, DHCP Server의 IP주소로 내용을 전달하는 것이 아니라 브로드캐스팅을 수행하는 것을 볼 수 있습니다. 즉, 아직 Client는 IP주소를 할당받지 않은 상태임을 말합니다.

 

서버는 Client의 DHCP Request Message를 수신하면, 해당 내용을 확인했으며 IP주소를 사용해도 좋다는 응답(DHCP ACK)을 보냅니다.

 

 

 

4) DHCP ACK ( Server -> Client )

 

DHCP Ack
DHCP Ack

 

DHCP Ack Message를 수신한 Client는 이제부터 해당 IP주소를 사용하여 네트워크에 패킷을 전송할 수 있습니다.

 

즉, 이 시점부터 IP임대가 시작되는 것입니다. (172.30.1.35 가 저의 IP주소가 되었습니다.)

 

DHCP ACK 패킷을 좀 더 보겠습니다.

 

DHCP Option

DHCP의 Option을 보면 위와 같이 IP주소의 임대 기간이 나와있습니다.

 

해당 DHCP Server는 정확하게 1시간을 임대기간으로 할당하는 것을 볼 수 있습니다.

 

만약 1시간 동안 PC에서 IP 주소 임대 연장에 관련한 요청이 없다면 해당 IP주소는 1시간 후 회수됩니다.

 

그럼 이제 임대연장에 대해 보겠습니다.

 

 

 

5) DHCP IP 임대기간 연장

 

DHCP에서 IP주소의 임대기간을 연장할 때에는 앞서 사용한 DHCP Request Message를 사용합니다.

 

DHCP Request & Ack

위에 패킷을 보게 되면 [172.30.1.35]라는 제가 위에서 할당받았던 IP주소를 사용하여 DHCP 서버(172.30.1.254)에 DHCP Request 메시지를 보내는 것을 볼 수 있습니다.

 

앞서 0.0.0.0으로 브로드캐스팅했던 것과 큰 차이가 있습니다.

 

패킷의 Option 부분에도 큰 차이가 있습니다.

 

DHCP Request ( Client -> Server )

클라이언트가 보낸 메시지에는 위와 같은 내용이 있습니다.

 

즉, IP주소의 임대기간을 90일로 변경해달라는 내용입니다. 기존에 1시간을 할당받았던 것을 생각해보면 너무 파격적이네요.

 

그리고 응답(DHCP Ack)을 보겠습니다.

 

DHCP Ack ( Server -> Client )

응답을 보게 되면 Client의 90일은 할당해주지 않았지만, 위와 같이 1시간으로 임대기간을 변경해 준 것을 볼 수 있습니다.

 

기존에 1시간을 받았다가 30분 정도가 지나 30분이 남았던 임대기간을 1시간으로 재조정한 것입니다.

 

 

 

5. 다음 이야기

이번에 알아본 DHCP의 네 가지 [Discover, Offer, Request, Ack]이외에도 몇 가지 Message들이 존재합니다.

 

물론 위의 네 가지가 가장 압도적인 비율을 차지합니다만, 다음 페이지에서는 위 네가지 이외의 메시지들과 Client 측에서 DHCP Server를 귀찮게 하는 몇 가지 것들을 알아보겠습니다.

 

1. 패킷이란? (Packet)

패킷 또는 패켓이라고도 부르는 이것은 데이터의 전송단위입니다.

 

OSI 7계층 중 3층인 [Network Layer]에 속하는 패킷.

 

이 패킷에 대해서 다뤄보겠습니다.

 

패킷읜 헤더와 데이터, 그리고 트레일러(꼬리)로 구성되어있습니다.

[ Packet = Header + Data + Tail ]

 

트레일러 부분은 주로 애러검출에 사용되며, 생략되는 경우도 많이 존재합니다.

 

 

패킷의 구성을 살펴보겠습니다.

 

패킷의 구성

 

  • Version : 일반적인 IP주소를 사용할 경우 '4', IPv6를 사용하면 '6'이됩니다.
  • Length : (데이터 제외)헤더의 길이를 의미합니다. 32bit = 4byte이며, 해더의 길이는 위 그림의 세로측에 해당합니다. 따라서 최소 헤더길이는 5(4Byte * 5 = 20Byte)가 되며, Options에따라 그 길이가 더 커질 수 있습니다.
  • Type of Service : IPv6에서는 Traffic Class라고 부르는데, 서비스 유형 또는 혼잡알림을 의미합니다.
  • Total Length : 헤더와 데이터를 포함한 전체 크기입니다. 길이가 아닌 크기라고 하는 이유는 Byte 단위로 적혀있기 때문입니다.
  • Identification : 전송 패킷이 어떤 데이터의 조각인지 구분할 수 있도록 식별하기 위한 식별자입니다.
  • Flags : 데이터를 다수의 패킷으로 나누는 것을 Fragmentation(단편화)라고 합니다. 단편화를 지원하기 위해서 패킷은 현재 전송되는 패킷이 단편화가 되어있는지, 되어있다면 현재 패킷이 단편화된 패킷의 마지막 패킷인지를 알려줘야하기때문에 이 Flags를 통해 이를 표시해줍니다.
  • Fragment Offset : 패킷이 조각나기전 데이터의 어느 위치에 존재하는지를 알려줍니다.
  • Time to Live : 패킷이 경로를 찾지못해 무한하게 네트워크 망에서 떠돌아다는 것을 방지하기 위해 네트워크상 라우터를 통과할 때마다 1씩 줄어들어 0이되면 해당 패킷은 폐기되도록 하는 장치입니다.
  • Protocol : 어떤 프로토콜을 사용하는지 표시합니다. (ICMP : 1, IGMP : 2, TCP : 6, UDP : 17 등...)
  • Header Checksum : 패킷이 전송되는 과정에서 오류가 있는지 파악하기 위한 오류 검출 장치입니다. 간단히 설명하면, 송신측에서 패킷의 헤더의 모든 bit값을 특정한 방식으로 더해 Header Checksum에 입력해 전송하면, 수신측은 이를 역으로 풀어 동일한 결과가 나오는지 확인하는 방식입니다.
  • Source Address : 송신자의 IP주소입니다.
  • Destination Address : 목적지의 IP주소입니다.
  • Options : 패킷이 너무 커서 추가적인 단편화가 요구될 경우 라우터에의해 수행할 것인지와 같은 특징을 적게됩니다.
  • Data : 상위 프로토콜의 정보를 담고있는 부분으로, 전송할 데이터에 해당하는 부분입니다.

* IPv6 패킷은 다음에 다루겠습니다.

 

 

2. 오류제어방식 - 트레일러(Tail)

패킷의 꼬리에 해당하는 트레일러 또는 Tail이라고 부르는 녀석은 주로 오류검출코드에 의해 사용되는 영역입니다.

 

특히 그중에서도 대표적인 녀석이 'CRC(cyclic redundancy check)'라는 녀석입니다. 이녀석 하나만 다뤄도 할말이 많은 녀석이죠.

 

오류제어 방식에는 크게 두가지 방식이 있습니다.

  • FEC(Froward Error Correction : 순방향 오류 제어) : 송신측에서 오류확인을 위한 추가적인 정보를 패킷에 붙여 전송하는 방식
  • ARQ(Automatic Repeat reQuest : 후방오류정정) : 수신측에서 오류(에러)가 발생한것 같다고 판단하면 송신측에 재전송을 요청하여 확인하는 방식

 

 

위와같은 두가지 방식이 있으며 FEC는 FEC와 BEC로 나눠볼 수 있습니다.

  • FEC(전진에러수정) : 송신자가 제공한 정보를 사용하여 오류를 직접 수정하는 방식
  • BEC(후진에러수정) : 송신자가 제공한 정보로는 오류를 검출만 가능하여 송신자에게 재전송을 요청

 

이렇게 나눠보면 왜 굳이...? 라는 생각을 하실 수 있습니다.

 

FEC와 ARQ는 기능적으로 큰 차이가 있습니다. FEC는 수신과 동시에 에러를 확인하는반면, ARQ는 에러가 발생하면 그때 에러를 처리하는 형태입니다. 따라서 에러가 빈번하고 할 경우 FEC방식으로 그때그때 에러를 처리해서 상위 프로토콜로 넘기는게 좋지만, 안정적인 네트워크라면 에러가 적을테고, 굳이 매번 에러를 검출하여 자원(:에러검출을 위해 사용되는 시간과 성능등)을 낭비할 필요가 없겠죠.

 

또한 FEC와 BEC를 보게되면, FEC의 경우 굳이 재전송을 안해도 된다는 이득이 있기는 하지만, 수신측에서 에러를 수정하기 위해서는 그만큼 더 많은 정보를 전송할 필요가 생깁니다. 이또한 어떤 네트워크에서 어떤 서비스를 하느냐에 따라서 FEC가 좋을지 BEC가 좋을지 달라질 수 있습니다.

 

 

오류검출과 수정에는 여러 기법들이 존재하는데 이부분은 다음 페이지에서 다루겠습니다.

 

1. 회선교환 (Circuit Switching) 방식

회선교환 방식은 회선 독점을 통한 통신방식이라고 볼 수 있습니다.

 

아래와 같은 간단한 네트워크망이 존재한다고 가정하겠습니다.(실제로는 대부분 전화망에서 사용하기 때문에 구성이 조금 다릅니다.)

 

(PC와 교환기로 이루어진 네트워크망입니다.)

(교환기는 단순히 전용선을 할당하는 장비라고 생각하셔도 무관합니다.)

 

 

네트워크망 예시

회선교환 방식의 가장 큰 특징은 [전용선 할당]에 있습니다.

 

예를들어 전송할 데이터가 있다고 하면 아래와 같이 전송을 위한 전용선을 할당하고 해당 선로로 모든 데이터를 전송합니다.

 

회선교환 방식

위 그림과 같이 송수신을 연결하는 전용선을 설정하고 전송을 하는게 핵심입니다.

 

개념을 이해하셨다면 특징에 대해 말해보겠습니다.

 

 

 

2. 회선교환의 특징

  • 회선교환은 통신 회선을 설정하여 데이터를 교환하는 방식
  • 회선 교환방식으로 음성 전화 시스템에 사용됨
  • 송신자의 모든 데이터는 동일한 경로로 전송됨
  • 안정적인 통신이 가능함
  • Point-To-Point 방식으로 연결됨
  • 통신중 중간경로에 문제가 발생할 경우 전체 연결이 끊어짐 (새로운 경로를 통한 새로운 회선할당 필요)

 

장점

 - 대용량 + 고속 데이터 처리에 우수

 - 고정적인 대역폭을 사용

 - 연속적인 데이터 처리에 우수

단점

 - 회선 이용 효율이 떯어짐 (대역폭 낭비)

 - 통신과정에서 회선문제시 회선할당부터 다시해야함

 - 통신비용이 고가임

 

 

 

3. 패킷교환 (Packet Switching) 방식

회선교환 방식과 비교된다면, 대충 눈치채셨을 수 있습니다. 패킷교환은 회선교환과 다르게 [전용선]의 개념이 없습니다.

 

패킷교환은 전송하려는 데이터를 패킷이라는 단위로 나눠 네트워크망으로 뿌려주게됩니다.

 

이때 패킷에는 해당 데이터가 어떤 데이터의 몇번째 데이터인지의 정보와 최종 목적지에 대한 정보가 들어있습니다.

 

위의 정보를 라우터가 보고 패킷을 최적경로를 향해 전달하게 됩니다. 이때 최적경로는 단순하게 거리만을 계산하는 것이아니라, 망의 혼잡도(대역폭 사용율), 연결상태, 기타 설정등에 따라 그때그때 변경될 수 있기 때문에 경로는 수시로 변경될 수 있습니다.

 

따라서 특정한 데이터가 100개의 패킷으로 분해되어 전송된다면, 100개의 패킷들은 라우터에의해 서로다른 경로로 전송될 수 있고, 최종적으로 목적지에 100개의 패킷이 전달되면 패킷의 순서를 통해 다시 원래의 데이터로 합쳐지는 방식입니다.

 

 

(PC와 라우터로 이루어진 네트워크 망입니다.)

(라우터는 데이터의 최적경로를 파악하고 결정하여 송신하는 장비로 일단은 공유기의 상위호환 정도로 생각하셔도 괜찮습니다.)

 

패킷교환 방식

위의 그림과 같이 3개의 패킷이 [왼쪽]에서 [오른쪽]으로 전송될 때, 각각의 패킷은 서로 다른 경로로 전송될 수 있습니다.

 

또한 이러한 특성 때문에 전송되는 패킷은 순서와 다르게 수신될 수 있습니다.

 

 

 

4. 패킷교환의 특징

  • 전송되는 패킷은 여러 경로를 이용가능(패킷별로 최적의 경로 선택)
  • 송신 패킷의 순서와, 수신 패킷의 순서가 다를 수 있음
  • 전송 속도 및 흐름 제어가 가능
  • 에러 탐지가 가능(패킷정보를 통해)
  • 일반적인 인터넷 망에서 사용됨

 

장점

 - 회선의 이용률이 높음

 - 애러 및 장애에 강함 : 라우터 고장시 다른 경로를 즉각적으로 이용, 애러에 대해 특정 패킷만 재전송 가능

 - 인터넷 뿐만 아닌 다양한 통신망에서 사용가능(전화도 가능)

단점

 - 경로 탐색과정에서 지연이 발생됨

 - 전송량 증가에 따라 지연율이 급격하게 상승

 - 패킷헤더 추가로 인한 오버헤드 발생이 가능함

 

 

 

 

5. 가상회선(Virtual Circuit) 기술

가상회선 기술은 위의 패킷교환방식의 네트워크에서 회선교환과 같은 통신을 만들어주는 기술입니다.

 

패킷단위로 데이터를 전송하지만, 사전에 논리적으로 구성된 특정한 경로로 데이터를 전송하게 됨으로 모든 패킷은 동일한 경로를 통해 데이터가 전송됩니다.

 

수신측은 위의 특징 때문에 순차적으로 패킷을 수신할 수 있습니다.

 

다만 전송을 수행하기 전에 앞서 언급한것처럼, 경로를 결정해야하고 이를 위해 몇가지 특수한 패킷들을 네트워크에 전송할 필요가 있어 처음 연결에 약간의 시간이 필요하며, 또한 경로만 일정할 뿐, 전용회선이 아니기 때문에 설정한 경로를 통해 다른 노드에 의해 대량의 데이터가 유입될 경우 네트워크 지연이 발생할 수 있습니다.

  1. S Kim 2020.07.04 05:57

    네트워크 문외한인데 네트워크 기초를 익혀야 할 일이 있는데 이렇게 잘 정리해주셔서 감사합니다 ㅠㅠ 혹시 초보자가 보기 좋은 개념 정리서 같은 게 있을지요?

    • 뒹굴뒹굴 YoungQ 2020.07.24 09:53 신고

      네트워크에 대한 가벼운 이해정도를 목표로 하신다면, 책보다는 그냥 잘 정리된 블로그를 찾아보시는게 좋다고 생각됩니다.
      만약 전공자 과정을 희망하신다면, 아래 책으로 시작하시는 것을 추천드립니다.

      TCP/IP 프로토콜
      Behrouz A. Forouzan 저

      국내 번역도 나름 잘 번역되어 있기 때문에 번역으로 보시는 것을 추천드립니다.

0. 네트워크는?

네트워크(Network)의 어원은 Net+work로 '그물을 짜는 일'에서 나왔다고 합니다.

네트워크는 의미있는 정보인 데이터를 전송하는 복잡한 그물이라고 볼 수도 있겠네요.

 

하지만, 만약 누군가에게 네트워크의 정의에 대해 말해줄 일이 생긴다면 아래처럼 말할꺼 같습니다.

 

네트워크란 두 개 이상의 노드가 서로의 자원을 고유할 수 있는 데이터 통신 환경.

 

뭔가 유식해보이는 느낌을 주니까요.ㅎㅎ

 

 

본론으로 들어와서 네트워크는 크게 유선과 무선으로 나눠볼 수 있다고 생각합니다. 무선네트워크라하면 LTE, WiFi 같은 녀석들이 있을 것이고, 유선이라고 한다면 PC와 셋톱박스의 연결되는 인터넷이 대표적이겠죠.

 

앞으로 이러한 네트워크 환경을 구성하는 다양한 프로토콜과 이론들에 대하여 알아보도록 하겠습니다. 먼저 간단한 이론부터 시작하겠습니다.

 

1. 거리 기반 네트워크

종류 범위 특성
PAN (Personal Area Network) 약 5m 전후의 인접 통신 초 인접지역 통신으로 일반적으로 무선의 WPAN이 주
LAN (Local Area Network) 근거리 네트워크로 사무실과 같은 소규모 공간 내의 고속 통신회선 WAN보다 빠른 통신 속도, 단일 기관 소유의 네트워크, Peer-to-Peer 형태가 주
MAN (Metropolitan Area Network) LAN과 WAN의 중간형태 광케이블, 동축케이블을 통한 전송, DQDB 프로토콜
WAN (Wide Area Network) 광대역 네트워크망으로 유관한 LAN간의 연결 목적지를 결정하는 경로 탐색 알고리즘이 중요

 

* DQDB (Distributed Queue Dual Bus) : IEEE 802.6 표준 MAN 프로토콜, 이중 버스형태에 분산 큐를 통한 큐잉방식을 통한 전송방식.

 

 

 

2. 데이터 전송 방식

유무선 통신방식은 크게 3가지 형태로 나눌 수 있습니다.

 

단방향 통신 (Simplex)

일방적으로 'A->B' 의 통신방 가능한 전송방식

Simplex
반이중 통신 (Half Duplex)

서로 데이터를 전송할 수 있지만, 하나의 회선을 사용하기 때문에 동시에 전송은 불가능 (ex, 무전기)

Half Duplex
전이중 통신 (Full Duplex)

서로 언제나 필요한 데이터를 동시에 송수신 할 수 있는 전송 (ex, 전화)

Full Duplex 

 

 

3. 네트워크 토폴로지 (Network Topology)

네트워크 토폴로지는 물리적으로 연결된 형태에 따른 분류라고 볼 수 있으며, 다르게 말해 통신망의 구조에 따른 분류라고도 볼 수 있습니다.

 

크게 '링크'와 '노드'라는 요소로 이루어져있습니다.

 

링크(=회선) : 두 노드를 연결하는 선으로 PC에 연결되는 인터넷선(랜선)을 생각하면 이해하기 좋습니다.

노드 : 뒤에서 다루겠지만, 네트워크의 데이터를 송수신하고, 이 데이터를 처리하는 장치를 말합니다. 대표적으로 PC(단말노드)와 라우터가 있습니다.

 

 

네트워크 토폴로지에 의한 분류는 크게 5가지로 나눌 수 있습니다.

 

계층형 (Tree)

장점

 *. 네트워크 관리가 쉽고, 새로운 장치를 추가하기 쉬움

 * 네트워크의 신뢰도가 높음

 

단점

 * 트래픽 집중에 따른 속도 저하현상(병목현상)이 발생하기 쉬움

 * 상위 노드 고장시 상위 네트워크와의 통신이 불가능

버스형 (Bus)

장점

 * 설치비용이 적고, 신뢰성 우수

 * 구조 간단

 * 새로운 노드 추가가 쉬움

 

단점

 * 네트워크 병목현상 발생이 쉬움

 * 장애 발생시 전체 네트워크 마비

 

특징

 * 회선의 양 종단에는 터미네이터(Terminator)가 존재하여 신호의 반사를 차단합니다.

성형 (Star)

장점

 * 고속 네트워크에 적합

 * 노드 추가가 쉬움

 * 개별 링크 장애시에도 네트워크에 영향이 없음

 

단점

 * 중앙 노드 장애시 전체 네트워크 불통

 * 노드 증가에 따라 네트워크의 복잡도가 증가함

링형 (Ring)

장점

 * 저렴한 네트워크 구성이 가능

 * 충돌현상이 발생하지 않음

 

단점

 * 네트워크의 구성을 변경하기 힘듬

 * 링크 장애시 전체 네트워크 불통

 

특징

 * Token Passing기법을 사용한다.

망형 (Mesh)

장점

 * 완벽하게 이중화 되어있으므로 장애에 강함

 * 많은양의 데이터 처리에도 문제없음

 

단점

 * 구축과 운영 비용이 매우 고가 

1. DNS Query Message

DNS는 UDP 53번 포트를 사용합니다.

 

DNS Packet

Google.com에 접속했을 때 위와같은 DNS query와 DNS response가 전송되는 것을 볼 수 있습니다.

 

먼저 DNS Query Message를 확인해보면 아래와 같은 것을 볼 수 있습니다.

 

DNS Query Message

위의 붉게 표시한 부분이 DNS Header에 해당하는 부분입니다.

 

DNS message Header는 기본적으로 [트랜잭션 ID, flag, Question count, Answer count, Name server count, Additional Recode count]를 갖고 있습니다.

 

현재 해당 Packet의 DNS Message 는 아래와 같습니다.

 

Transaction ID = 0b 8e

Flags = 0100

Questions = 1

Answer = 0

Authority RRs = 0

Additional RRS = 0

Queries = www.google.com

 

 

2. Query Flag

트랜잭션 ID는 매 Query에 대한 식별 ID이며, Flags 0x0100은 아래와 같이 맵핑됩니다.

QR

Opcode

AA

TC

RD

RA

000

rCode

0

0000

0

0

1

0

000

0000

 

  • OR 0 : 이 메시지가 Query 라는 의미
  • Opcode 0000 : 표준 질의 또는 표준 질의에 대한 응답
  • AA 0 : 네임서버 권한이 인정 X
  • TC 0 : 응답메시지가 512 바이트 이하
  • RD 1 : 응답 형태가 Recursive인지 Iterative인지 정해주는 것으로 여기서 1은 Recursive 응답을 요구한다는 의미
  • RA 0 : 네임서버가 Recursive 질의가 가능한지 나타내며
  • rCode : 0 = No Error (1 = Format Error, 2 = ServFail, 3 = DNS존재 X)

 

3. DNS Response Message

DNS Response Message

 

마찬가지로 해당 패킷의 Response Message는 아래와 같은 내용을 갖고있습니다.

Transaction ID = 0b 8e

Flags = 81 80

Questions = 1

Answer = 6

Authority RRs = 4

Additional RRS = 8

Queries = www.google.com

Answers = 

www.google.com addr 108.177.97.104

www.google.com addr 108.177.97.105

www.google.com addr 108.177.97.147

www.google.com addr 108.177.97.99

www.google.com addr 108.177.97.103

www.google.com addr 108.177.97.106

Authoritative Nameservers =

google.com ns ns4.Google.com

google.com ns ns1.Google.com

google.com ns ns2.Google.com

google.com ns ns3.Google.com

Additional records =

ns1.google.com addr 216.239.32.10

ns2.google.com addr 216.239.34.10

ns3.google.com addr 216.239.36.10

ns4.google.com addr 216.239.38.10

ns1.google.com addr 2001:4860:4802:32::a

ns2.google.com addr 2001:4860:4802:34::a

ns3.google.com addr 2001:4860:4802:36::a

ns4.google.com addr 2001:4860:4802:38::a

 

 

4. Response Flag

이 Packet의 Transaction ID는 Query의 Transaction ID와 동일하며, Flags는 아래와 같이 매핑됩니다.

QR

Opcode

AA

TC

RD

RA

000

rCode

1

0000

0

0

1

1

000

0000

 

  • OR 1 : 이 메시지가 response 라는 의미
  • Opcode 0000 : 표준 질의 또는 표준 질의에 대한 응답
  • AA 0 : 네임서버 권한이 인정 X
  • TC 0 : 응답메시지가 512 바이트 이하
  • RD 1 : 응답 형태가 Recursive인지 Iterative인지 정해주는 것으로 여기서 1은 Recursive 응답을 요구한다는 의미
  • RA 1 : 네임서버가 Recursive 질의가 가능한지 나타내며
  • rCode : 0 = No Error (1 = Format Error, 2 = ServFail, 3 = DNS존재 X) 

이 응답 메시지로부터 client는 www.google.com이라는 사이트의 address와 Google.com의 네임서버를 얻어올 수 있습니다.

0. 시작하기

  • 와이어샤크 프로그램을 통한 HTTP Handshake 과정을 다룹니다.
  • 와이어샤크 프로그램에 대한 설명은 제외합니다.
  • 맥(OSX)환경에서 실습 및 작성되었습니다.

1. TCP 통신 과정

 

기본적인 TCP 통신과정을 그려보면 아래와 같습니다.

 

TCP 통신

[연결] - [데이터 통신] - [종료] 의 3단계로 진행되며 이제부터는 HTTP 통신을 예제로하여 해당 과정을 살펴보겠습니다.

 

그전에 앞서 각 과정에서 전송되는 패킷의 구조와 Flag들이 의미하는 것은 아래와 같습니다.

 

출처 : http://www.ktword.co.kr/abbr_view.php?m_temp1=2437

 

  • URG(긴급 데이터 표시) : 상위계층에서 긴급데이터임을 표시한 패킷으로 전송시 우선적으로 전송됨
  • ACK(응답확인) : 패킷을 정상적으로 수신했다는 것을 알리기위한 패킷
  • PSH(즉시 확인 요청) : 해당 표시가된 패킷은 수신한 경우 버퍼가 차는 것을 기다리지 않고 즉시 상위계층으로 전달
  • RST(연결 초기화 요청) : TCP 연결상 문제가 발생시 현재 연결을 끊고 다시 연결할 것을 요청함
  • SYN(회선 연결 요청) : TCP 연결을 요청하는 패킷이며, 현재 자신의 준비상태를 상대방에게 전달
  • FIN(회선 연결 종료) : 모든 데이터 전송이 완료되었음으로 연결을 종료할 것을 알림

 

 

2. HTTP Connect - 연결과정

 

연결과정

HTTP 는 TCP 80번 포트를 이용합니다. (HTTPS 는 443번)

 

테스트할 사이트는 통계청 사이트(http://kostat.go.kr)입니다. 통계청 사이트가 https를 사용하지 않고 있어서 선정했습니다.

 

아래는 통계청 사이트에 접속할때 교환되는 패킷 내용입니다.

 

Packet Chapture 시작부분

내 PC : Youngui-MacBook-Pro

통계청 : 125.60.43.187

 

 

3 Way Handshake

처음 3줄을 보면 위와깉이 SYN, SYN ACK, ACK가 전송되는 것을 볼 수 있습니다.

 

연결과정은 위와같은 3개의 패킷이 핵심입니다.

 

  • SYN (클라이언트 -> 서버) : 클라이언트가 서버에 TCP연결을 요청합니다. 이때 자신의 연결준비 상태를 함께 전송합니다.
  • SYN + ACK (서버 -> 클라이언트) : 서버가 클라이언트의 연결 요청에 응답(ACK)하며, 자신의 연결 준비상태를 알립니다.(SYN)
  • ACK (클라이언트 -> 서버) : 클라이언트가 서버의 연결준비 상태(SYN)를 포함한 패킷을 잘 수신했다고 알립니다.(ACK)

위의 단계를 3 Way-Handshake라고 부릅니다. 정상적으로 완료가 될 경우 이후부터 데이터 전송이 가능합니다.

 

 

 

3. HTTP Data Transmission - 데이터 통신

데이터 통신

여기서는 HTTP 프로토콜을 이용하여 TCP 전송에 대해서 다루기 때문에 전송되는 데이터는 [HTTP 프로토콜]에서 사용하는 메서드와 해당 메서스에 대한 응답등이 해당됩니다.

 

 

데이터 전송

위의 3개의 패킷은 TCP Connect 이후 최초의 데이터 패킷입니다. 각 패킷은 아래와 같은 역할을 합니다.

 

  • HTTP (클라이언트 -> 서버) : 기본 url(kostat.go.kr) /(최상위) 위치에 대한 html파일을 요청합니다. 즉, kostat.go.kr에 접속했을때 최초로 보여줄 html파일에 대한 정보를 서버에 요청하는 과정입니다.
  • HTTP 200 OK (서버 -> 클라이언트) : 200번 응답은 정상적으로 요청한 내용을 전송했다는 의미이며, 위에서 요청한 kostat.go.kr/ 에 접속시 보여줄 html파일을 전송했다는 의미입니다.
  • ACK (클라이언트 -> 서버) : 서버가 클라이언트에게 전송한 html파일을 정상적으로 수신했다는 ACK응답입니다.

 

데이터 통신과정에서 발생하는 대부분의 통신내용은 위와같은 방식을 갖고있습니다.

 

물론 데이터의 크기가 MTU(최대전송단우) 이상일 경우 단편화(Fragmentation)를 통해서 데이터를 조각내서 정송하게 됩니다.

 

아래는 단편화된 패킷의 예제입니다.

단편화 예제

kostat.go.kr/protal/kor_nw/1/1/index.board?bmode=read&Seq=376435 에 대한 GET요청에 대해서 서버는 응답을 여러개로 나눠서 보내는 것을 볼 수 있습니다.

 

이에따라 클라이언트도 여러개의 ACK를 생성해 전송하게 됩니다. (PDU = 프로토콜 데이터 유닛)

 

여기서 전송되는 데이터의 최대크기가 1514 Byte인 것을 볼 수 있습니다. 이를통해 1514 Byte가 일반적인 이더넷 패킷의 MTU가 된다는 것을 알 수 있습니다.

 

 

 

 

4. HTTP Disconnect - 연결종료

 

 

4 Way-HandShake

위와같은 전송이 TCP의 연결종료에 해당합니다.

 

하지만, 항상 위와같은 상태는 아닐 수 있습니다. FIN메시지는 데이터 전송이 완료되었다고 서버가 판단하고 먼저 보낼 수도 있습니다.

 

연결종료

 

  • FIN + ACK (클라이언트 -> 서버) : 이전에 서버로부터 받은 데이터를 잘 수신하였으며(ACK), 모든 데이터 전송이 끝났음으로 연결종료를 요청합니다.(FIN)
  • FIN + ACK (서버 -> 클라이언트) : 서버가 정상적으로 FIN 메시지를 수신하였으며(ACK), 서버는 더 이상 처리할 데이터가 없음으로 마찬가지로 즉시 FIN메시지를 전송합니다.(만약 더 통신할 데이터가 있을 경우 ACK만 전송할 후 데이터 교환 후 FIN 메시지를 보냅니다.)
  • ACK (클라이언트 -> 서버) : 서버의 FIN 메시지를 정상적으로 수신했음을 알립니다.

 

위의 모든 과정이 끝나면 서버와 클라이언트 모두 연결을 위해 할당했던 리소스를 회수합니다.

  1. 뒹굴뒹굴 YoungQ 2019.07.24 15:52 신고

    중간에 Source Port가 변경되는 부분은 이미지가 깨져서 와이어샤크로 다시 캡처하다보니 발생한 문제로 모두 동일한 Port라고 봐도 무관합니다.

  2. 2020.07.15 20:51

    비밀댓글입니다

Python으로 WOL 매직패킷 전송하기

사실 별거 없다... 파이썬 socket통신을 이용하면 될 뿐이기에...

 

1. WOL 패킷 생성코드

import socket, struct

def WOL(macAddr):
    sep = macAddr[2]
    macAddr = macAddr.replace(sep,'')
        
    data = b'FFFFFFFFFFFF' + (macAddr * 16).encode()
    send_data = b''
    
    for i in range(0, len(data), 2):
        send_data += struct.pack('B', int(data[i: i + 2], 16))
    
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
    sock.sendto(send_data, ('192.168.35.255',9))
    
WOL('11:22:33:44:55:66')

코드 설명

 > sep = macAddr[2]
 > macAddr = macAddr.replace(sep,'')

 : MAC주소에서 ':' 을 제거합니다.

 

 > data = b'FFFFFFFFFFFF' + (macAddr * 16).encode()
 > send_data = b''

 : data는 WOL 패킷에 전송할 데이터이며, send_data는 실제 전송을 위해서 인코딩된 값이 들어갑니다.

 

 > for i in range(0, len(data), 2):
 >     send_data += struct.pack('B', int(data[i: i + 2], 16))

 : struct.pack(format, value) 함수는 value에 해당하는 값을 원하는 포맷으로 반환합니다.

 : 'B'는 unsigned char형태를 의미합니다. 와이어샤크에서 봤었듯이 전송할 데이터가 FF FF FF 와 같이 2byte 단위 데이터이기 때문에 2byte씩 끊어서 unsigned char형태로 변환해주는 작업을 해주었습니다.

 : 포맷형식을 변환하여 사용도 가능하지만, 예를들어 unsigned int를 사용할 경우 8byte의 반환값을 갖기 때문에 range(0, len(data), 8)로 설정해줘야하며, 이 경우 전체 데이터의 길이가 8로 나누어 떯어지지 않으면 별도의 처리를 해야하는 문제가 있습니다.

 

 > sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

 : socket을 정의합니다. 전송할 WOL패킷은, UDP를 사용하기 때문에 SOCK_DGRAM을 사용합니다.

 

> sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)

 : socket의 옵션을 설정합니다. 망내에 Broadcasting 시킬 예정이기에 위와같이 설정해야합니다.

   (아래와같이 망주소를 알 경우 안써도 되는거 같습니다.)

 

 > sock.sendto(send_data, ('192.168.35.255',9))

 : 변환된 데이터를 원하는 망(192.168.35.255)에 9번 포트로 전송합니다.

 

전송결과

와이어 샤크 화면

위에 보이

는것처럼, 전송결과 WOL프로토콜로 인식되는 패킷을 송신하는 것을 볼 수 있었습니다.

패킷의 전송내용도 기존에 어플을 이용해서 보냈던것과 거의 큰 차이가 없습니다.

 

차이는 ID, Checksum, 그리고 flags에서 보이는데, ID는 패킷마다 독립적으로 부여되는 값이기에 다른것이 정상이며, Checksum 역시 패킷의 값에 의존하기 때문에 달라질 수 있습니다. (기능적 문제 X)

 

Flags에서 차이가 있었는데, 확인하보니 Don't Fragment에 대한 부분이 채크가 안된것을 볼 수 있었습니다.

 

하지만, 전송하는 데이터의 크기가 144byte기 때문에 정상적인 망에서 해당 패킷이 Fragment(단편화)가 될 일이 없음으로 전혀 문제가 없습니다.

 

이상입니다~

 

끝 ㅎㅎ

 

궁금한것 댓글로 주세요~

와이어샤크 + WOL + python

실제 구현에 관련된 코드는 2부에 있습니다.

1부에서는 와이어샤크로 WOL패킷을 확인하고 간단한 이론을 보겠습니다.

 

WOL

WOL은 전원이 종료된 컴퓨터의 랜카드에 특별한 패킷을 송신함으로써 PC를 켜주는 기능을 의미합니다.

WOL을 수행하기 위해서는 기본적으로 PC의 랜카드가 컴퓨터 종료 후에도 WOL 패킷(매직패킷)을 수신할 수 있는 상태여야합니다.(이부분은 여기서 다루지 않겠습니다.)

 

Wireshark

와이어샤크는 네트워크 패킷을 분석하는 가장 대중적인 툴입니다.

간편하게 현재 랜카드가 송신/수신한 모든 패킷들을 확인 할 수 있으며, 해당 패킷의 정보를 쉽게 확인할 수 있도록 간편한 인터페이스를 제공합니다.

 

WOL 패킷확인

Wake On Lan 어플

 

 

 WOL 패킷 확인을 위해서 해당 패킷을 전송하는 어플 [Wake On Lan]을 사용했습니다.

 

 

 

 

왼쪽에 보이는 것처럼 [wol test]라고 [11:22:33:44:55:66]이라는 맥주소를 갖고있는 컴퓨터에 WOL 패킷을 전송하도록 해주었습니다.

 

이때 와이어샤크로 감자하는 PC와 해당 스마트폰은 동일한 네트워크망에 접속되어있어야합니다.(공유기 종류 무관)

 

 

 

 

 

 

 

 

 

 

 

 

 

와이어 샤크 패킷수신화면

WOL이 사용하는 udp 9번 포트를 필터링한 결과 3개의 패킷이 전송된 것을 볼 수 있었습니다.

(맥주소는 굳이 가려봤습니다.)

 

한번에 어플이 3개의 패킷을 송신하는 것을 볼 수 있었습니다.

 

 

패킷정보(총 144byte)

와이어샤크 수신 패킷

와이어샤크 화면 하단에 표시된 내용을 순서대로 말씀드리겠습니다.

 

 

Ethernet 계층 (MAC프레임)

Ethernet (Data Link) Layer
이미지 출처 : 정보통신기술용어해설

  • DA(Dst Mac Address) = 'ff ff ff ff ff ff'
  • SA(Src Mac Address) = '50 77 05 -- -- --' 
  • Ethertype(Ethernet Protocol Type) = '08 00' (IPv4)

참고) 이더넷 타입표

  • Data = Layer3 이상부분

 

 

 

Network 계층 (IP Header)

Network Layer
이미지 출처 : 정보통신기술용어해설

  • Verson = '4'
    • IPv4
  • Header Length = '5'
    • Header Length는 위 IP헤더에서 한 줄을 의미합니다.
    • 즉 5x4byte = 20byte로 IP헤더의 최소길이를 의미합니다.
  • Type of Service = '00'
    • 미할당 영역으로 추가기능을 위한 공간입니다.
  •  Total Length = '00 82'
    • 8x16+2 = 130byte
    • 즉, IP Packet = Header(20byte) + Data(110byte) 로 이루어집니다.
  • Identification = '29 22'
    • Packet에 부여되는 식별자(오류제어등에 사용됨)
  • Flags + Fragment offset
    • Flags는 3bit 공간에 각 자리수가 특정의미를 갖음
    • [ Reserved bit | Don't Fragment | More Fragments | 
    • 40 = 010 = Don't Fragment
    • offset은 단편화가 된 경우 패킷의 순서를 확인하는 용도로 사용됨
  • TTL(Time to Live) = '40'
    • 패킷이 통과할 수 있는 노드의 수를 의미합니다.
    • 노드를 통과할 때 마다 1씩 감소하며 0이되면 전송실패와 함께, ICMP 메시지를 전송합니다.
  • Protocol type = '11'
    • 프로토콜 맵팽은 아래와 같습니다.
    • ICMP = 1 | IGMP = 2 | TCP = 6 | EGP = 8 | UDP = 17 | OSPF = 89 등...
    • 11 = 10진수로 17(즉, UDP를 의미)
  • Header Checksum = '48 69'
    • Checksum은 오류검출용 코드입니다.
  • Src IP Addr = 'c9 a8 23 90' (192.168.35.144)
  • Dst IP Addr = 'c0 a8 23 ff' (192.168.35.255)
    • WOL 기능은 목적지 주소를 망주소로 전송합니다.

 

 

 

Transport (UDP Datagram)

Transport Layer (UDP Datagram)
이미지 출처 : 정보통신기술용어해설

  • Src Port = 'eb e5' (60389)
  • Dst Port = '00 09' (9)
    • WOL은 수신 Port로 7 또는 9를 사용합니다.
  • Length = '00 6e' (110)
    • 위어서 언급한 것처럼, IP Packet에서 Data영역이었던 UDP부분이 110Byte임을 볼 수 있습니다.
  • Checksum = 'ad 79'
    • 수신측 오류확인을 위해 사용합니다.

 

 

 

Application (WOL Data)

Application Layer (WOL Data)

WOL은 특별한 데이터를 넘겨줍니다.

UDP Data로 들어온 WOL 정보

'FF FF FF FF FF FF' Broadcast MAC 주소와 목적지의 MAC 주소의 조합으로 이루어집니다.

 

위와 같이 하나의 'Broadcast' + 16개(또는 20개)의 '목적지 MAC 주소'로 이루어집니다.

 

 

 

 

끝?

 

다음 게시물은 위의 패킷을 생성하는 파이썬 코드를 보겠습니다. 이상입니다.

[네트워크 이론] 회선교환 방식과 패킷교환 방식

1. Circuit Switched Network (회선교환방식)

 - 하나의 전용 회선을 할당받아 데이터를 통신하는 방식
 - 전용 회선을 할당받기 위한 Set-Up 절차를 수행이 필요하다.
 - 전용 회선을 사용하기 때문에 다른 패킷에 의한 진연이 없다.
 - 주로 과거 전화망에서 사용했다.
 - FDM과 TDM방식 등이 존재한다.
 - 모든 회선이 사용중이면 새로운 연결(Set-up)을 만들 수 없다. (= 이용자 수 제한)

2. Packet Switched Network (패킷교환방식)

 - Sotre and Forward 방식으로, 패킷들이 라우터의 큐에 저장되어있다가 한번에 전송되는 방식을 사용한다.
 - 패킷은 라우터의 경로탐색 알고리즘에 의해서 경로가 결정된다.
 - 전송지연, 큐잉지연 등의 지연이 발생한다.
 - 라우터의 큐가 넘칠 경우 패킷이 버려지는 형상(패킷 오버플로우)이 발생할 수 있다.

 - 회선의 사용자가 많아질수록 속도 저하가 발생할 수 있다.


+ Recent posts