[링크계층] 무선이동 네트워크

18

https://broship.tistory.com/196

 

- wireless: 선이 없는, 무선

- mobile: 이동가능한

- 유선과 무선의 MAC 프로토콜은 다르다.

- 유선은 링크라는 매체를 공유해서 사용, 무선은 공기라는 매체를 공유해서 사용함

- 무선일 경우 내 컴퓨터에서 google 서버로 통신이 갈때 전체가 무선이 아닌 한 홉만 무선임

- 유선은 안정적인 케이블로 연결되어 있어 외부의 노이즈로부터 보호됨 그래서 연결 거리에 큰 영향을 받지 않음

- 무선은 거리에 큰 영향을 받음

 

wireless - wifi

다 무선이지 않다 첫 홉만 무선이고 나머지는 유선

 

 

우리가 보는 90% 이상이 infrastructure가 있으면서 single hop이다

 

 

그래프y, x축 =  시그널 크기, 거리 (거리가 멀어지면 시크널 크기가 줄어든다)

 

 

Hidden terminal problem

- A, B, C가 각각 80미터 거리에 있고, 각 데이터 전송 반경이 100미터일때, A와 B, B와 C는 서로 데이터 전송이 가능하지만 A 와 C는 데이터 전송이 불가능함

- 그래서 A와 B가 데이터 통신중일때 C가 CSMA방식을 사용해서 carrier sence를 하려고 해도 A가 보내는 데이터를 알아차릴 수 없음

 

- 그리고 자기 자신이 전송을 시작하면 그게 너무 커서 남이 하는 전송을 감지하지 못함 ( collision detection이 안 됌)

- 그래서 무선환경에서는 기존 방식인 CSMA/CD 방식을 사용하지 못함

 

 

Wi-Fi (IEEE 802.11)

 

 

 

- Wi-Fi는 Wireless Fidelity의 약자로 무선이지만 유선과 같은 성능을 내겠다는 뜻

- 공유기 하나당 하나의 AP를 가지고 있고 유선으로 스위치 혹은 라우터에 연결되어 있음

 

노트북을 열었을 때 주변의 bss에 연결이 될건데, 어떤방식으로 연결하나?Passive scanning

- 모든 AP들은 주기적으로 beacon frame에 자기 자신의 AP를 브로드케스트함

- 호스트들은 그 정보를 가지고 와이파이 목록을 띄울 수 있음

- 호스트는 가만히 있고 beacon을 ap들이 보내준다

 

 

 

 

CSMA/CA

- 와이파이는 어떤 MAC 프로토콜을 사용하나?

무선와이파이에서 csma/cd를 사용할 수 있을까?

충돌을 감지 못 하니까 사용할 수 없다

 

유선인터넷에서는 충돌이 안 날 때까지 전송하면 되니까 ack가 있을 필요가 없다

하지만 무선인터넷에서는 충돌을 감지 할 수 없으니까 ack가 필요하다

 

하지만 tcp의 ack와 다르다

tcp는 end to end 피드백이지만

무선 ack는 링크레이어 ack이다.

 

 

- A와 C가 각각 AP와 80m 거리에 있고 각 활동 범위가 100m 일경우

- A와 AP가 통신중일때 C가 다른 통신이 이루어지고 있는지 들으려고 할때 들을 수 없음

- C가 다른 데이터 통신이 없는 줄 알고 데이터를 전송하면 충돌이 발생함

- 유선일 경우 모든 매체를 공유하기 때문에 충돌 감지가 되었지만 무선일 경우 A가 보내는 데이터를 C는 들을수가 없기 때문에 충돌을 감지 못함

- 그래서 무선일때는 AP가 ACK를 보내서 충돌을 감지함(TCP의 ACK와는 다름)

 

 

 

 

- 우선 DIFS 만큼의 시간을 기다린 후 다른 데이터 전송이 없으면 그때 전송 시작

- AP는 데이터를 받고 SIFS만큼의 시간을 기다린 후 잘 받았다는 신호인 ACK를 보냄

- 센더는 데이터를 보낸 후 ACK를 받았을 때만 데이터 전송이 완벽하게 이루어졌다라고 판단하고 다음 데이터 준비

- ACK가 오지 않을 경우 충돌이 발생했다고 판단해서 랜덤한 시간 이후에 재전송

 

 

 

 

a,b가 서로 ap한테 보낼게 있어서 rts를 보냄

동시에 보내서 충돌함

a, b둘다 cts를 못 받음 => 충돌이 났음을 인지함

둘 다 random backoff를 해서 다시 rts를 보냄

 

 

- 유선일 경우 충돌이 일어나면 바로 멈출 수 있었음

- 하지만 무선은 오로지 ACK로만 판단하기 때문에 한번 데이터를 전송하면 중간에 멈추지 않음 (따라서 무선인 경우 충돌이 발생하면 유선보다 피해가 큼)

- 그래서 데이터 전송하기 전 RTS (ready to send)라는 작은 데이터를 전송해 전송중인 다른 데이터가 있는지 확인함

- AP가 RTS를 받으면 그 데이터를 전송해도 좋다는 CTS (clear to send)를 보냄

- CTS를 받지 못하면 충돌이 났다는걸 인지하고 random backoff 해서 재전송함

- RTS, CTS에는 얼마만큼의 데이터를 얼마의 시간동안 보내겠다는 정보가 담겨있음

- 각 RTS, CTS를 받을 수 있는 반경의 인터페이스들은 그 정보를 받고 그 기간동안엔 데이터를 전송하지 않음

 

- A가 RTS를 보낸 후, AP가 보낸 CTS와 B가 보낸 RTS가 우연찮게 겹쳤을때

- A반경에 있는 인터페이스들은 A가 데이터 전송을 할것이란걸 알고 있음

- B반경은 CTS와 RTS가 겹쳐서 노이즈가됨, B반경에 있는 인터페이스들은 노이즈만 들음

- A는 데이터 전송을 시작, 그 후에 B반경에 있는 어떤 인터페이스가 작은 RTS 하나만 던져도 데이터 충돌이 발생함

- A는 ACK를 못받았으니 그때부터 다시 RTS 보내기 시작, 이런식으로 인터페이스끼리 무한 경쟁

- 그래서 무선은 사람이 적을땐 데이터 전송이 원활하지만 사람이 많아지면 충돌-재전송을 계속 반복하여 속도가 느려짐

 

- ACK를 못받으면 무조건 재전송함, 하지만 이렇게 ACK 받을때 까지 재전송을 하면 과부하가 걸릴 수 있음

- 그래서 최대 7번까지만 데이터를 전송하도록 규정해놓음

- 7번 전송해도 안되면 해당 프레임을 포기하고 다음 프레임 전송

- 이게 전송계층에서 다뤘던 데이터 유실이다, TCP 프로토콜이 처리해줌 

 

 

보통 무선 wifi의 형태는 AP(Access point)를 통해서 네트워크에 접근한다

AP1은 채널3, AP2는 채널4를 사용하면 서로 겹치지가 않아서 충돌이 없다

만약 같은 채널을 사용하면 간섭이 일어나는데

csma ca + rts, cts를 사용하여 해결한다 (경쟁해서 이긴사람이 전송할때 다른사람은 조용하다)

=> 사람이 많아질 수록 충돌과 backoff가 많이 일어난다.

 

 

wifi 에서 사용하는 데이터 frame

 

- 무선 인터넷 프레임의 헤더에는 address 필드가 4개나 있음(address4는 안 씀)

address1: 데이터를 받을 AP의 MAC 주소

address2: 데이터를 전송하는 host의 MAC 주소

address3: 데이터를 받을 라우터의 MAC 주소

 

밑의 그림에서 AP의 특징

- AP는 한쪽은 무선(와이파이), 한쪽은 유선(이더넷) 데이터를 받을떄랑 전송할때랑 프레임 헤더가 바뀜

- AP는 링크 계층까지만 지원하는 기기(link layer device), host 입장에서 AP가 보이지만 라우터 입장에서는 AP가 보이지 않음(스위치 같은 개념)

- AP는 host의 프레임을 받아서 자기 자신 AP 주소(address1)를 빼고 dest 주소를 라우터의 주소(address3)으로, source 주소를 host의 주소(address2)로 설정 후 프레임을 전달함

h1이 라우터를 통해 패킷을 보냄

 

- 왜 굳이 주소를 3개씩이나 해서 보낼까?
- address3이 없을 경우, AP는 링크 계층까지만 존재하기 때문에 해당 프레임을 열고 IP 패킷을 봐도 목적지 IP 주소로 가기 위해 보내야할 다음 라우터의 MAC 주소를 알 수가 없음 그래서 어디로 보내야 할지 알지 못함

- address1이 없을 경우, AP 자체를 찾지 못함

- 그래서 무선 헤더에는 주소 3개가 다 있어야함

 

- 데이터를 받을 때도 이더넷 프레임을 와이파이 프레임으로 바꿔줘야됨

- 라우터가 source는 자기 자신, 목적지는 host 주소로 보내면, AP가 중간에 받아서

address1: 데이터를 받을 host의 MAC주소

address2: 데이터를 보내는 AP의 MAC주소

address3: 데이터를 보낸 라우터의 MAC주소

이렇게 프레임을 바꾼후 전송함

 

- 결국은 AP가 링크계층 디바이스라서 링크 계층까지만 존재해서 주소 하나를 더 추가해서 라우터의 정보를 담아 주는 것임

 

각각 주소 구하는 방법

- 보낼때 address2는 자기 자신이라 쉽게 알수 있음

- address1(AP의 MAC주소)는 AP가 주기적으로 전송하는 beacon 메시지로 알수 있음

- address3(라우터 MAC주소)은 DHCP를 통해 얻은 라우터의 IP 주소로 ARP 프로토콜을 사용해 구함

 

19

 

무선일때 DHCP 동작 과정

- 프레임에 AP, host, 브로드케스트를 담고 IP 패킷에는 sour는 비워두고 dest는 브로드케스트로 보냄

- dest는 브로드케스트, sour는 host인 이더넷 프레임으로 바꿔서 전달

- DHCP 포트가 열려있는 DHCP 서버만 받아서 다시 브로드케스트로 생성된 ip 주소 전달

- 이때 ip 패킷의 dest이 브로드케스트면 프레임의 desc도 브로드케스트임, MAC 주소를 아는 방법은 가지고 있는 ip 주소를 ARP 테이블에 매칭해서 알아내기 때문

- DHCP 포트가 열려있고, 트랜잭션 id 가 동일한 host만 받아서 ip 주소를 생성함

- 사실 DHCP 과정에서 AP의 ARP 테이블에 라우터의 MAC 주소가 등록되기 때문에 다시 또 ARP 리퀘스트를 보낼 필요는 없음

 

 

AP는 공유기인가?

- 큰 회사일 경우 하나의 라우터에 여러 AP를 연결해서 사용함

- 하지만 집에서 흔히 볼수있는 공유기는 AP 역할과 라우터 역할을 모두 담당함

- 지금까지는 하나의 라우터에 여러 AP를 연결한 경우를 살펴본 것임, 집에서는 AP와 라우터가 바로 붙어있어서 AP에서 라우터까지 전달되는 과정이 생략되었다고 보면 됨

 

 

 

 

- 인터넷 사용 중 이동을 해서 AP가 바뀔때

- TCP 커넥션은 본인src IP, src port, 목적지dest IP, dest port가 바뀌지 않으면 연결이 유지됨

- 다른건 바뀔리 없고 내 IP만 안 바뀌면 연결 안끊김

- AP만 바꼈을 뿐 같은 서브넷 안에 있기 때문에 IP가 바뀌지 않음

 

유튜브가 나에게 데이터를 전송할때 내가 동일한 서브넷에서 이동하면

- 라우터는 내가 이동을 하는줄 모름, 똑같이 src에는 라우터 주소 dest에는 내 주소를 적어서 프레임을 보냄

- 스위치는 그 프레임을 받아서 스위치 테이블을 참고해서 데이터를 보냄, 이때 이 스위치 테이블만 바꿔주면 됨 (라우터 입장에서 스위치는 없음)

- 이동을 해서 AP가 바뀔때 더미 프레임을 하나 보내서 나와 라우터 사이에 연결된 스위치들의 스위치 테이블 정보를 갱신함

 

정리

커넥션을 유지하려면 (TCP 커넥션)

src ip, src port, dest ip, dest port가 유지되야하나다.

 

AP가 변경되는 경우에 커넥션이 유지되는가?

src ip가 변하지 않으면 유지된다

같은 서브넷을 공유하면 ip가 바뀌지 않는다 = tcp커넥션이 유지된다

 

트래픽 방향을 바꾸기 위해서는 스위치 안의 테이블만 바꾸면 되는데

self learning을 통해 스위치테이블을 갱신한다.

=> 클라이언트는 새로 이동한 후 gateway 라우터를 향해서 더미프레임을 보내면 스위치 테이블이 알아서 갱신된다.