본문 바로가기

개발👩‍💻/네트워크

14-3:Network Layer:Link Layer

728x90

LAN

- Addressing, ARP

- Ethernet

- switches

 

LAN: Local Area Network

MAC address

링크 계층에서 사용하고 있는 맥어드레스

 

네트워크 계층에서 사용하고 있는 ip 주소를 통해서 인터페이스에 대한 네트워크 계층 주소를 할당했었다.

네트워크 계층에서 포워딩을 할때 사용했다. 

이것과 비교했을 때 mac주소는 프레임을 링크계층에서 하나의 인터페이스에서 물리적으로 연결된 다른 인터페이스로 전달할 때 사용한다.

같은 서버넷 안에서 IP 주솔 활용하는 것처럼  맥어드레스를 활용해서 같은 서브넷 안에서는 메시지를 서로 교환을 할 수 있다. 이때 사용하는 것이 맥 어드레스이고, 48비트짜리 맥어드레스를 사용한다.

NIC카드 포트에 각각 인터페이스에 맥어드레스가 애초에 할당이 되어 나온다. 16진수로 보통 표기한다.

 

문자 하나에 4비트니까 총 12개의 문자로 표현한다.

1A-2F-BB-78-09-AD

 

맥 어드레스 같은경우 각각의 인터페이스에 할당이 된다. 

인터페이스 마다 Ip만 달리는 것이 아니라 맥어드레스와 ip조합으로 할당이 된다.

그래서 각각의 인터페이스는 48비트 맥어드레스와 32비트 ip가 할당이 된다.

 

기본적으로 맥어드레스는 IEEE에서 관리한다.

NIC 만들어 판매하는 곳에서 맥 주소를 구매해서 할당하여 판매를 한다. 맥어드레스는 기본적으로 NIC 카드의 고유의 맥어드레스가 할당되어 판매된다.

 

맥어드레스는 하나의 주민번호, IP를 우편 번호로 비유할 수 있다.

 

그리고 맥 어드레스 같은 경우 IP와 는 다르게 IP는 서브넷과 직접적 관련이 있다. 한서브넷에서 다른 서브으로 옮기면 IP 주소 자체가 변경이 됐다. 하지만 맥 어드레스는 그럴 필요없이 얘는 한번할당되면 변경되지 않는다. 물론 강제로 바꿀 수는 있는데 정상적인 방법은 아니다. 한번 할당된 맥어드레스를 가지고 다른 곳으로 옮겨가면 맥어드레는 그대로, ip주소만 할당받아사용하게 된다.

 

ARP: aadress resolution protocol

맥 어드레스는 어떻게 알 수 있을까

포워딩 테이블 처럼 ARP 테이블이라는 것을 유지한다. 

그래서 IP와 MAC 주소의 매핑을 기록을 해 놓는다.

IP 주소와 MAC 주소를 연결하여 IP 로 보내려면 그 MAC 주소로 보내면 된다는 것을 알 수 있다.

TTL이 있어서 특정 시간이 지나면 주소 매핑을 자동적으로 삭제하도록 세팅한다.

 

ARP 

A가 B한테 데이터그램을 전송하려고한다하자

B의 MAC 어드레스를 A가 최초에는 가지고 있지않다.

A는 B의 MAC어드레스를 찾기위해서 ARP 프로토콜을 사용하게된다.

ARP쿼리를 한다. B의 아이피주소는 이미 알고 있고, 

이때 데스티네이션 맥어드레스를 브로드케스트한다.

그리고 해당 아이피를 가지고 있는 호스트의 응답을 기다리고

목적지는 이를 받고 정보를 넣어서 A한테 알려주게 된다.

이렇게 ARP 응답을보내고 그때 맥어드레스를 알려주게된다.

B로 전송을 하려할 때도 아까는 같은 서브넷에있었는데 다른 서브넷에 있을 때도 비슷하게 동작한다.

a가 만약에 B의 아이피주소는 알고있다고 가정했을 때 A는 퍼스트 홉 라우터를 R의 맥어드레스를어떻게 알 수 있을가

A가 IP데이터그램을 만들것이다.

퍼스트홉 라우터는 BGP 프로토콜을 통해 알수 있고

맥어드레스도 ARP를 통해서 알 수 있다.

그리고 이것을 이더넷 계층으로 보내서 맥어드레서 를 넣을 것이다.

중간에 있는 라우터에 대한 맥 목적지를 넣고, 

라우터의 맥 데스티네이션, 넥스트 홉에 보낼 것이다.

A가 R로 보낼 것이고 R은 그것을 받아 다시 데이터그램을 지우고 실제로 어디로 가야하는 패킷인지 확인한다. 까보면 원래 데스티네이션이 어디였는지 알고 다시 캡슐화를 해서 어떤 맥어드레스로 전달해야하는지 알고 있을 것이다.

B에 해당하는 맥어드레스를 가지고 링크레이어 프레임을 만들고 전송해서 B가 받고 까보면 IP데이터그램이 도착을 할 것이다.

 

이런식으로 ARP가 동작한다.

 

Ethernet

이더넷 같은 경우 유선랜 테크놀로지 중 가장 많이 사용되는 프로토콜이다.

높은 성능을 제공한다.

 

이더넷 같은 경우 예전 방식에서는 버스를 사용해서 연결되어 있는 모든 애들이 서로 공유를 했다. 콜리젼 도메인이라고 하는데 동시에 무엇을 보내려고하면 충동이 일어난다.

 

요즘에 사용하는 방식은 스위치 방식이다. 스위치 방식에서는 각각의 노드들이 서로한테 직접 전송을 할 수 있고 서로 전송할 때 충돌이 발생하지는 않는다.

 

이더넷은 따로 커넷견을 맫지 않는 커넥션리스이다.

기본적으로 이것은 유선이기 때문에 신뢰성있게 전달하지 않는다.

이제 기본적으로 유선이다 보니 애초에 에러가 발생할 확률은 낮다.

그래서 ack, nak은 존재하지 않는다.

이더넷에서 사용하는 것은 CSMA/CD 방식이고 바이너리 백오프 방식을 사용한다.

 

이더넷 표준에는 많은 것들이 있다.

각각 다른 성능에 대해 다른 표준들이 존재하고

어떤 물리 매체를 사용하냐에 따라 여러가지 표준이존재한다.

 

Ethernet switch

이더넷 스위치는 라우터와 스위치의 다른점에서 봤다 싶이 라우터는 네트워크 레이어에서 동작하고 스위치같은 경우 링크 계층에서 동작한다.

비슷한 측면은있다. 스위치도 스토어 앤 포워드, 저장하고 전송하는 방식이다. 이더넷 프래임을 저장하고 전송한다.

 

어떤 맥어드레스에 대한 프레임이 들어오면 어디로, 어떤 링크로 전달할지 판단해서 프래임을 적절하게 전달을 해준다.

스위치에서 알아서 해주기 때문에 스위치의 존재를 호스트는 알필요 없이 동작한다.

이더넷 스위치에 랜선을 꼽기만하면 설정 따로 필요없이 동작한다.

 

Switch: muliple simultaneous transmission

스위치 같은 경우 기본적으로 각각이 직접적으로 커넥션이 이뤄진다.

이 가운데 있는 스위치 하나가 패킷을 버퍼링하는 역할을 같이 해준다.

 

기본적으로는 풀 듀플렉스 방식이고 양방향으로 전송할 수 있고, 각각의 링크는 별도의 콜리젼 도메인을 가진다.

 

A->A' 보낼 때, B->B' 이런건문제없는데,

A->C' 이런식으로 한다면 링크가 공유되고 있기 때문에 동시에 보내면 충돌이 발생할 수 있다.

 

스위치 같은 경우 설정할 필요가 없다고 했는데 스위치는 A'가 인터페이스 4를 통해서 접근할 수 있다는 것을 어떻게 알 수 있을까. 이것도 ARP처럼 스위치 테이블을 가지고 있다.

그래서 호스트의 맥어드레스랑 인터페이스를 연결해준다.

라우팅 테이블과 비슷하다.

 

어덯게 동작하는지 보면

소스와 목적지가 A->A'로 보내려고 하는 상황이라고 하면 스위치가 스위치 테이블을 가지고 있다. A->A' 보내려고 하는 것을 스위치로 보내면 받은 스위치는 어디서 부터 온것인지는 알수있다. 1번 인터페이스를 통해 프래임을보낸 것을 알 수 있다.

맥 어드레스 A는 인터페이스 1로 보내면 된다는 것을 알 수 있고, 이를 스위치 테이블에 저장한다.

스위치에 프레임이 도착하면 나한테 보낸 링크의 맥어드레스와 인터페이스를 기록한다.

그리고 만약에 내 스위치 테이블에 내가 보내려는 목적지의 맥어드레스와 인터페이스 넘버가 저장되어있다면 거기로 보내면 된다.

정보가 없다고 한다면 flood를 한다. 모든 인터페이스한테 보내는데 나한테 요청한 애는 제외하고 보낸다. 

그래서 아까와 똑 같은 상황에서 A가 보냈다면 그부분을 기록하고, 플루드를 한다. A'가 응답할 수 있도록, A'가 자신의 정보를 알려주면 그것을 기록해서 A'로 가려면 인터페이스 4로 가야함을 기옥한다. 스위치는 A, A'의 경로를 이렇게 알 수 있게 된다. 원하는상황에 따라 링크를 사용해서 전송을 할 수 있게 된다.

 

여러개가 있어도 똑같은 방식으로 동작한다.

 

SWITCH VS ROUTER

스위치랑 라우터 둘다 저장하고 포워딩하는 방식으로 동작한다는 공통점이 있다. 라우터는 네트워크 스위치는 링크에서 동작한다.

둘다 테이블을 사용한다.

 


간단한 시나리오를 가지고 네트워크 어떻게 동작하는지보자

랩탑을 가지고 유선랜을 사용하여 학교 네트워크에 접근한다고 하자.

goole.com에 대해서 요청을 보내고 결과를 받는 시나리오를 보자

위 그림과같이 구성이 되어있다고 하자.

이상태에서 웹페이지를 요청을 하게 되면 

 

최초의 연결을 하면 ip 주소를 DHCP 프로토콜을 사용해서 ip를 할당받을 수 있었다. IP는 내부에서 사용하는 ip이다.

DHCP같은 경우 UDP 프랜스포트 계층을사용해서 DHCP 메시지를 사용한다. 이 요청을 UDP로 캡슐화를 해서보낸다. 그러면 DHCP 같은 경우 브로드 캐스트를 하기 때문에 어떤 주소를 알 필요가 없다. 아무것도 몰라도 연결되어 있는 애들한테 보낸다. 나와 같은 네트워크에있는 DHCP 역할을 하는 라우터(서버)가 응답을 할 것이다.

 

그러면 해당 DHCP 메시지를 전달받고 이것을 봤을 때 어디서 DHCP요청을했는지 알수있다.

서버는 DHCP 메시지를 만들어서 다시 전달을 한다. 클라이언트가 사용할 수 있는 IP 주소와 첫번째 홈라우터에 대한 IP주소 그리고 DNS 서버에 대한 IP주소와 이름을 같이 전달을 해준다.

 

학생노트북에서는 그것을 받아 IP를 할당받을 수 있다. 

 

받기위해서는 DHCP ACK 응답으로 최종적으로 받게된다.

이과정을 거치면 클라이언트는 ip주소와 dns 서버와 이름과주소, 첫 홉 라우터에 대한 ip주소도 알 수 있다. DHCP 를 통해서

 

그 다음에 해야할 것은 웹페이지를 요청을 하려면 HTTP 리퀘스트를 보낼 것이다. 이것은 어플리케이션계층 프로토콜이었는데,

이를 통해서 웹페이지를 받아오는데, WWW.GOOLE.COM IP주소가 필요하다.. 이를 알기위해 DNS 프로토콜을 사용한다. 이것도 어플리케이션계층 프로토콜이었다. 근데 문제가 DNS쿼리를 만들기는 할텐데 만들고 UDP 의 캡슐활 하고 아이피, 이더넷까지 캡슐화 했는데 이것을 라우터에 보내려고하다보니 라우터에대한 맥어드레스가 존재하지 않는 것이다.

그러면 라우터의 아이피 주소만 가지고 있고 실제 맥어드레스는 가지고 있지 않은 상황이다.

이것을 알기위해 ARP 프로토콜을 사용한다 ARP 쿼리를 브로드캐스트를 통해 날리고, 그 중 해당되는 애가 응답을 줄 것이다. 자신의 IP주소에 대한 쿼리가 왔으니 맥 어드레스를 리턴을 해준다. 이것을 다시 클라이언트에한테 전달을해주고 라우터에 대한 맥어드레스를 알았으니 정상적으로 DNS 메시지를 보낼 수 있게 된다.

 

그러면 DNS 메시지가 라우터로 전송이 되었고 라우터가 DNS 서버에 대한 IP주소는 이미 알고 있으니, 라우터가 포워딩을 잘해서 전달을 하면 BGP 프로토콜, OSPF 프로토콜을 통해서 전달한다. 다른 AS간의 그리고 AS 내부안에서의 라우팅이 설정이 되어 보내려는 패킷을 원하는 IP 주소까지 전달이 된다.

 

결과적으로는 DNS 서버에 잘 도착할 것이고, DNS 서버에서 이것을 까보고 원하는 www.google.com  에대한 IP주소를 리턴을 해줄 것이다.

 

그러면 이제 구글 웹서버의 ㅇIP주소를 알게되었고, HTTP 메시지를 보내게 되는데 커넥션이 맺어지지않았으니 커넥션을 맺어준다. TCP 소캣을 만들고 3way handshake할건데 처음에는 syn세그먼트를 보내야할 것이다.

그리고 웹서버에서는 이것을 확인을하고 synack를 답변할 것이다. 

그렇게 되면 tcp 커넥션이 연결이 된 것이고

tcp ack를 다시한번 보내게 된다. 실제로 보낼 때 따로 보내는 것이 아니라 이번에 보내렬는 것이랑 piggybacking, 얹혀서 보낸다. 그래서 http 리퀘스트를 보낼 때 ack가 함께 보내진다.

 

그러면 3way handshake 완성

 

이렇게 웹서버에 도착하게되고 리퀘스트가, 웹서버는 그것보고 리플라이 하게되고, 웹페이지를 포함한 답장을 해준다. 클라이언트한테 도착할것이고 웹페이지가 화면에 뜰것이다.

 

이렇게해서 매일 같이 하는 일이지만 내부적으로 많은 일들이 이뤄짐을 알 수 있다.

반응형

'개발👩‍💻 > 네트워크' 카테고리의 다른 글

14-2:Network Layer:Link Layer  (0) 2021.06.04
14-1:Network Layer:Link Layer  (0) 2021.06.04
13-2:Network Layer: control plane  (1) 2021.06.03
13-1:Network Layer: control plane  (0) 2021.06.03
12-2:Network Layer: control plane  (0) 2021.06.03