이더넷에서는 충돌이 발생할 수 있다. 특히 과거에 충돌이 발생하는 경우가 많았는데, 주로 다음의 Bus topology와 같이 유선 케이블을 공유하는 과정에서 발생했다고 한다.
위와 같이 하나의 회선을 여러 디바이스가 공유하는 구조라면, 송수신에 대한 제약이 생길 수 밖에 없다. 이런 상황에서 여러 디바이스가 동시에 데이터를 송신하게 되면, 물리적 신호가 겹치게 되고 이를 '충돌이 발생했다' 라고 표현한다. 따라서 위와 같은 충돌을 해결하기 위해 존재하는 이더넷 표준이 CSMA/CD이다.
다만 미리 알아두어야 할 것은, CSMA/CD는 현재보다는 과거에 주로 사용했던 기술이라는 점이다. 최근은 허브와 같은 장비들을 사용하지 않고 스위치를 주로 사용하면서 네트워크의 형태가 bus topology에서 star topology에 가까워졌고, 패킷 전송 속도가 더욱 빨라졌으므로 충돌이 발생할 염려가 거의 없다고 한다.
비슷한 충돌 제어 방식으로 CSMA/CA가 있는데, 이는 무선랜에서 주로 사용되는 표준이다. 우선 CSMA/CD를 살펴본 이후에 CSMA/CA까지 살펴보도록 하겠다.
CSMA/CD
Carrier Sensing Mulitple Access with Collision Detection
우선 동작 원리나 개념을 살펴보기에 앞서 각 낱말의 의미를 하나씩 살펴보도록 하자.
Carrier는 반송파라는 의미를 가지고 있다. 반송파는 쉽게 말해 '데이터를 송수신하기 위한 주파수'를 의미한다. 따라서 Carrier Sensing Multiple Access with Collision Detection이란, 반송파 감지, 충돌 탐지를 수행하면서 다중 접속이 가능하게 하겠다는 의미이다. 핵심은 반송파 감지와 충돌 탐지다. 관련해서 flow chart를 살펴보도록 하자.
이제 flow chart에 기반해 간단하게 흐름을 살펴보도록 하겠다.
1. 프레임 전송을 준비한다.
우선 전송하기 위한 프레임을 준비한다. 그리고 이 과정에서 '시도 횟수'를 나타내는 K를 0로 초기화해준다. 다만 0이라는 숫자에 집중하기보다는, IP 헤더의 TTL과 비슷한 '시도 횟수'라는 개념이 포함되어 있음에 집중해야 한다.
2. 반송파를 탐지하여 유휴 상태인지를 확인하고 전송한다.
'Carrier Sensing'에 해당하는 부분이다. 반송파를 탐지해서 회선이 사용중인지 아닌지를 판단한다. 어떻게 판단하는지가 궁금해서 조금 찾아보니, 유선 LAN(Ethernet)에서는 전압의 변화로 쉽게 측정할 수 있다고 한다.
다만 회선이 사용중이지 않다고 해서 항상 바로 전송하지는 않고, 사용하는 persistent method에 따라 달라지게 된다. persistent method는 단순히 말하면 회선이 비어있다고 판단된다면 언제 전송할지를 결정하는 알고리즘이다.
3. 전송 후 충돌이 발생했는지를 확인하고, 발생했다면 재전송한다.
프레임을 전송한 뒤에는 충돌이 발생했는지를 확인한다. 만약 충돌이 발생했다면 jamming signal을 전송하고 K 값을 늘리게 된다. 만약 K 값이 일정 값을 넘겼다면, Abort된다. 그렇지 않다면 back off 알고리즘에 의해 랜덤한 시간동안 대기 후 재전송을 기다린다.
여기서도 매체가 유휴 상태인지를 판단하는 방법과 동일하게 전압의 변화를 통해 충돌 검출을 쉽게 알 수 있다고 한다.
CSMA/CA
Carrier Sensing Multiple Access with Collision Avoidance
이번에는 CSMA/CA 방식을 알아보도록 하겠다. CSMA/CA 방식은 주로 무선랜에서 활용된다. CSMA/CD와는 뒷부분 (CD, CA)만 다른데, CA는 위에 작성해뒀듯이 Collision Avoidance를 의미한다.
CD 방식의 경우 충돌을 Detection 해서 재전송 및 프레임 파기 여부를 결정했으나, 무선랜 방식은 충돌 감지가 거의 불가능하다. 따라서 충돌 회피(CA) 전략을 사용하는 것이다.
충돌 감지가 불가능한 이유는 hidden node problem을 통해 알 수 있다. 위 그림에서 A 노드와 B 노드가 무선 통신을 하고 있다고 가정해보자. 이 경우, C의 탐지 범위 밖에서 A가 존재하기 때문에 C는 A의 존재를 모른다.
즉, C 입장에서 보면 A가 hidden node가 되고, A 입장에서 보면 C가 hidden node가 된다. 그렇기 때문에 송신 대상이 통신을 하고 있는지를 정확히 알기가 어렵고, 이 때문에 CD(Collision Detection)이 불가능한 것이다. 위와 같은 케이스 말고도, A와 B 사이에 장애물이 있거나 하는 등과 같이 Hidden node problem은 일상생활에서 발생할 여지가 충분하다.
따라서 CSMA/CA 방식은 RTS/CTS 방식을 통해 이 문제점을 보완한다. RTS/CTS 방식이란 송신을 원하는 주체가 Request to Send를 보내면, 수신을 하는 주체가 통신이 가능할 때에만 Clear to Send를 보내는 방식이다. 조금 더 자세한 내용은 아래 다이어그램으로 살펴본다.
우선 DIFS, SIFS에 대해 설명할 필요가 있다. DIFS, SIFS는 IFS(Inter Frame Space)의 종류로, 무선 LAN에서 프레임 간 간격을 의미한다. 이러한 IFS는 여러 무선단말에 대한 충돌 회피를 위해 사용되는 기법 중 하나이다. 다시 본론으로 돌아와서, 한 단계씩 살펴보도록 하자.
1. 반송파를 탐지하여 유휴 상태인지를 확인하고 RTS 패킷을 보낸다.
송신측은 마찬가지로 반송파를 탐지하고(Carrier Sense) Request To Send(RTS) 패킷을 수신측에 전달한다. 다만 반송파를 탐지하는 과정이 CSMA/CD 방식과는 조금 다르다.
무선 LAN에서의 반송파 탐지는 1. 물리적 감지와 2. 가상적 감지 두 가지가 동시에 이루어진다. 이는 무선이 단순히 에너지 레벨만으로는 감쇠가 크므로 충돌을 판단할 수 없기 때문이다. 물리적 감지는 RF 에너지 임계치 초과 여부 등을 검토하는 등의 작업을 의미하며, 가상적 감지는 바로 뒤에서 설명할 NAV를 통해 수행될 수 있다.
NAV(Network Allocate Vector)란, '어느 시간까지 통신할거야' 라고 하는 일종의 타이머 역할을 하는 값을 의미한다. 송신 노드는 RTS만 보내는게 아니라, NAV 값까지 보냄으로서 수신 노드에게 통신 시간을 알리게 된다.
2. 수신측은 통신이 가능하면 CTS 패킷을 보낸다.
통신이 가능하다면, 수신측은 CTS(Clear to Send) 패킷을 다시 전송하게 된다. 이 때 중요한 점은, 수신 노드가 주변 노드에게 NAV 값을 다시 전송함으로서 Hidden node 까지도 통신을 한다는 사실을 알게 된다. 따라서 앞서 설명했던 '가상적 감지'에 의해 다른 노드들은 대기한다.
3. 통신이 끝나면 ACK로 마무리한다.
통신이 끝나면, 수신 측은 ACK 패킷을 통해 주변 노드들에게 통신이 종료되었음을 알린다. 이 이후부터 다른 노드들과의 통신도 가능해지는데, 곧바로 통신하면 충돌의 위험이 있으므로 경쟁 윈도우라는 방식을 사용해 랜덤한 시간동안 대기한다.
마무리
CSMA/CD, CSMA/CA 방식을 살펴봤다. 특히 CSMA/CA 방식의 경우 여러 기법(경쟁 윈도우, RTS/CTS, IFS)이 사용되어 상당히 복잡했는데, 정리하고 보니 어느정도 큰 틀은 잡히는 것 같다.
다만 아쉬운 점은 CSMA/CA 방식에서 NAV 값 이내로 통신이 종료되지 않는 경우 등 예외적인 케이스들에 대한 내용은 작성하지 못했다는 것인데, 추후 기회가 되면 작성해보도록 하겠다.
참고 자료
http://www.ktword.co.kr/test/view/view.php?m_temp1=3961
https://www.geeksforgeeks.org/collision-detection-csmacd/
https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection
http://www.ktword.co.kr/test/view/view.php?m_temp1=2038
http://www.ktword.co.kr/test/view/view.php?no=4781
http://www.ktword.co.kr/test/view/view.php?m_temp1=2326&id=919
'네트워크' 카테고리의 다른 글
TCP Congestion Control (0) | 2024.04.08 |
---|---|
TCP flow control (3) | 2024.03.29 |
Software Defined Networking(SDN) (0) | 2024.03.23 |
Broadcast Domain & Collision Domain (2) | 2024.03.17 |
HTTP 요청 및 응답 구조 알아보기 (2) | 2023.09.04 |