DHCP 깊게 알아보기

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

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

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

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

확인해보기

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

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

먼저 기존의 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 부분을 수정해서 다시 전송해보겠습니다.

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'를 의미합니다. 즉, 싫다는 뜻입니다. 힝...

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

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

2. DHCP Discover 요청

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

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

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

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

고민이군요...

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

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

DHCP 프로토콜이란?

1. DHCP란?

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

예를들어 본다면, 쉽게 생각하여 IP를 할당하는 공유기에 PC를 연결하면 자동으로 192.168.~ 로 시작하는 IP주소를 자동으로 할당해주는 것과 같습니다.

개인 또는 소규모 사업체의 경우 위와같은 공유기 등을 이용하여 사설IP를 할당받아 사용하거나, 각 호스트별로 IP를 관리자가 직접 할당하지만, 호스트가 네트워크 케이블을 연결함과 동시에 자동으로 IP를 할당받아 통신이 될 필요가 있으면서 연결된 호스트 IP를 정해진 규칙에 맞에 관리할 필요가 있다면 DHCP를 선택하는 방법이 좋습니다.

2. DHCP의 장단점

DHCP의 장점

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

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

또한 DHCP는 서버에서 모든 사설 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 Message는 위와같이 네트워크 전체에 '브로드캐스팅'되는 것을 볼 수 있습니다.

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

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

2) DHCP OFFER ( Server-> Client )

위에서 보면 [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의 메시지 영역을 보면 아래와 같은 내용이 있습니다.

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

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

3) DHCP REQUEST ( Client -> Server )

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 Message를 수신한 Client는 이제부터 해당 IP주소를 사용하여 네트워크에 패킷을 전송할 수 있습니다.

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

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

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

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

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

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

5) DHCP IP 임대기간 연장

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

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

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

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

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

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

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

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

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

5. 다음 이야기

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

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

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

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

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

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

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

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

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

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

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

2. 회선교환의 특징

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

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

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

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

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

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

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

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

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

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

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

4. 패킷교환의 특징

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

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

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

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

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

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

0. 네트워크는?

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

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

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

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

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

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

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

1. 거리 기반 네트워크

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

2. 데이터 전송 방식

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

단방향 통신 (Simplex)	일방적으로 'A->B' 의 통신방 가능한 전송방식
반이중 통신 (Half Duplex)	서로 데이터를 전송할 수 있지만, 하나의 회선을 사용하기 때문에 동시에 전송은 불가능 (ex, 무전기)
전이중 통신 (Full Duplex)	서로 언제나 필요한 데이터를 동시에 송수신 할 수 있는 전송 (ex, 전화)

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

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

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

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

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

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

계층형 (Tree)		장점  *. 네트워크 관리가 쉽고, 새로운 장치를 추가하기 쉬움  * 네트워크의 신뢰도가 높음   단점  * 트래픽 집중에 따른 속도 저하현상(병목현상)이 발생하기 쉬움  * 상위 노드 고장시 상위 네트워크와의 통신이 불가능
버스형 (Bus)		장점  * 설치비용이 적고, 신뢰성 우수  * 구조 간단  * 새로운 노드 추가가 쉬움   단점  * 네트워크 병목현상 발생이 쉬움  * 장애 발생시 전체 네트워크 마비   특징  * 회선의 양 종단에는 터미네이터(Terminator)가 존재하여 신호의 반사를 차단합니다.
성형 (Star)		장점  * 고속 네트워크에 적합  * 노드 추가가 쉬움  * 개별 링크 장애시에도 네트워크에 영향이 없음   단점  * 중앙 노드 장애시 전체 네트워크 불통  * 노드 증가에 따라 네트워크의 복잡도가 증가함
링형 (Ring)		장점  * 저렴한 네트워크 구성이 가능  * 충돌현상이 발생하지 않음   단점  * 네트워크의 구성을 변경하기 힘듬  * 링크 장애시 전체 네트워크 불통   특징  * Token Passing기법을 사용한다.
망형 (Mesh)		장점  * 완벽하게 이중화 되어있으므로 장애에 강함  * 많은양의 데이터 처리에도 문제없음   단점  * 구축과 운영 비용이 매우 고가

1. DNS Query Message

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

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

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

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

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

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

2. Query Flag

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

• 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

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

4. Response Flag

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

• 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 통신과정을 그려보면 아래와 같습니다.

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

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

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

2. HTTP Connect - 연결과정

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

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

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

내 PC : Youngui-MacBook-Pro

통계청 : 125.60.43.187

처음 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 - 연결종료

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

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

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

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

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 패킷확인

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

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

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

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

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

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

패킷정보(총 144byte)

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

Ethernet 계층 (MAC프레임)

• 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)

• 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)

• 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)

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

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

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

끝?

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

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

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

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

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