티스토리 뷰

Develop Story/Network

오류 제어

wisecow 2017. 10. 25. 21:22

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */


# 전송 오류의 유형


 전송 프레임의 오류를 극복하고, 상위 계층에 신뢰성 있는 전송 서비스를 제공하려면 다음과 같은 기본 기능을 이용해 오류 복구 기능을 제공해야 한다.


* 수신 호스트의 응답 프레임


 송신 호스트가 전송한 데이터 프레임의 일부가 깨지는 프레임 변형 오류를 확인한 수신 호스트는 송신 호스트에게 응답 프레임을 전송해 원래의 데이터 프레임을 재전송하도록 요구할 수 있다. 수신 호스트가 전송하는 응답 프레임의 종류에는 데이터 프레임이 정상적으로 도착했을 때 회신하는 긍정 응답 프레임과 데이터 프레임이 깨졌을 때 회신하는 부정 응답 프레임이 있다.


* 송신 호스트의 타이머 기능


 송신 호스트가 전송한 데이터 프레임이 수신 호스트에게 도착하지 못하는 프레임 분실 오류가 발생하면 수신 호스트는 이 사실을 인지할 수 없다. 따라서 오류의 복구 과정이 송신 호스트의 주도로 이루어져야 한다. 송신 호스트는 데이터 프레임을 전송한 후에 일정 시간 이내에 수신 호스트로부터 긍정 응답 프레임 회신이 없으면 타임아웃(Timeout) 기능을 동작시켜 데이터 프레임을 재전송한다.


* 순서 번호 기능


 수신 호스트의 긍정 응답 프레임을 분실하면 데이터 프레임이 제대로 도착했음에도 불구하고 송신 호스트가 이를 인지할 수 없다. 따라서 송신 호스트가 타임아웃 기능에 의해 원래 데이터를 재전송함으로써 수신 호스트가 데이터 프레임을 중복 수신하는 결과를 초래한다. 이럴 때 수신 호스트가 중복 데이터 프레임을 가려내려면 각 프레임 내부에 순서 번호(Sequence Number)를 기록해야 한다.


데이터 프레임은 원래의 데이터 외에 오류 검출을 위한 정보도 함께 포함한다. 오류 검출을 위한 정보에는 수신 호스트에서 오류를 감지하는 기능만 하는 정보오류가 발생한 프레임을 복구하는 기능을 하는 정보가 있다.


오류를 감지만 하는 방법을 사용할 때는 송신 호스트의 도움을 받아 오류 복구 기능을 수행 해야 한다. 즉, 수신 호스트가 데이터 프레임을 올바로 수신하면 송신 호스트에 긍정 응답(Positive Acknowledgement) 프레임을 보냄으로써, 송수신 호스트 사이의 전송이 완결된다. 그러나 프레임 변형 오류가 발생하면 부정 응답(Negative Acknowledgement) 프레임을 회신해 송신 호스트의 재전송 기능에 따라 오류 복구 과정을 진행한다.


* 정상적인 전송


 송신 호스트가 전송한 데이터가 오류 없이 수신 호스트에게 전송된 경우다. 수신 호스트는 데이터 프레임을 제대로 수신했다는 긍정 응답 프레임을 회신함으로써 하나의 데이터 프레임에 대한 전송 과정이 완료된다.


 송신 호스트가 긍정 응답 프레임을 회신 받지 못하면 데이터 프레임에 오류가 발생했다는 의미다. 일반적으로 변형된 프레임을 수신한 호스트는 부정 응답 프레임을 전송할 수도 있지만, 프로토콜의 종류에 따라서는 부정 응답 프레임을 지원하지 않을 수도 있다.


 이때는 수신 호스트가 회신할 방법이 없으므로 송신 호스트의 타임아웃 기능에 따라 오류 복구 기능을 시작한다. 데이터 프레임은 정상적으로 전송되었지만, 수신 호스트의 긍정 응답 프레임이 송신 호스트에게 도착하지 못해도 송신 호스트의 타임아웃 기능에 따라 오류를 복구한다.


* 프레임 변형


 데이터 프레임이 수신 호스트에 도착했으나, 전송 과정에서 프레임의 내용이 변형되는 오류가 발생하는 경우다. 프레임 변형 오류를 인지한 수신 호스트는 송신 호스트에게 부정 응답 프레임을 전송함으로써, 원래의 데이터 프레임을 재전송하는 오류 복구 과정이 진행된다. 앞서 언급한 것처럼 부정 응답 프레임을 재전송하는 오류 복구 과정이 진행된다. 앞서 언급한 것처럼 부정 응답 프레임을 사용하지 않는 프로토콜 에서는 송신 호스트의 타임아웃 기능에 따라 복구 과정을 시작한다.


 한편 재전송된 데이터 프레임은 올바르게 전송될 수도 있지만, 반대로 이 과정에서 또 다시 변형 오류가 발생할 수도 있다. 또한 긍정이나 부정 응답 프레임도 전송 과정에서 변형이나 분실과 같은 오류가 발생할 수 있다. 따라서 데이터 링크 계층 프로토콜에서 다루는 전송 오류 문제의 원리는 매우 단순하지만, 프로토콜 설계시 세심한 주의가 필요하다. // 프레임 내부에 시퀀스 번호(순서 번호)를 두는 이유도 이 때문이다.


* 프레임 분실


 데이터 링크 계층의 주요 기능 중 하나는 프레임을 전송한 송신 호스트가 동작하는 타임아웃 기능이다. 송신 호스트가 전송한 데이터 프레임이 전송 과정에서 사라지는 프레임 분실 오류를 생각해보자. 수신 호스트는 송신 호스트로부터 어떠한 데이터 프레임도 전달 받지 못했기 때문에 긍정 응답이나 부정 응답 프레임을 회신할 수 없다. 결과적으로 송신 호스트도 응답 프레임을 회신받을 수 없어 응답 프레임을 무작정 기다려야 한다.


 수신 호스트는 데이터 프레임의 분실 여부를 인지할 수 없으므로 오류 복구는 송신 호스트 주도로 타임아웃(Timeout)기능에 따라 처리된다. 즉, 송신 호스트는 데이터 프레임을 전송한 후에 특정 시간까지 수신 호스트의 긍정 응답 프레임이 도착하지 않으면 타임아웃 기능에 따라 원래의 프레임을 스스로 재전송한다.



# 순서(Sequence) 번호


 데이터 링크 계층의 오류 복구 기능이 수행되는 과정에서 동일한 데이터 프레임이 수신 호스트에 중복해 도착할 수 있다. 따라서 오류 없이 수신된 중복 데이터의 문제에 대비해야 한다. 중복 데이터 처리는 프레임 내부에 각 프레임의 고유 번호인 순서 번호(Sequence Number)를 기록하여 해결한다.


* 순서 번호의 필요성


 올바르게 수신한 데이터 프레임에 대한 긍정 응답 프레임이 사라지는 오류가 발생하면 송신 호스트의 타임아웃 기능에 따라 재전송 과정이 진행된다. 재전송된 데이터 프레임이 제대로 수신되면 수신 호스트 입장에서는 동일한 프레임을 중복해 수신하는 결과를 초래한다.


 송신 호스트 입장에서 보면 자신이 동일한 데이터 프레임을 두 번 전송했는지, 아니면 서로 다른 두 개의 데이터 프레임을 연속 전송했는지 구분할 수 있다. 그러나 수신 호스트는 두 경우를 구분할 방법이 없다. 따라서 수신 호스트가 두 경우를 구분할 수 있도록 데이터 프레임별로 고우의 순서 번호를 표기하는 방식이 필요하다. // 데이터 전송이 모두 성공한다고 가정하면, 순서 번호가 따로 필요 없겠지만 실패할 확률은 엄연히 존재하기 때문에 이것에 대한 대비책으로서 순서 번호가 필요한 것이다. 좀 더 풀어 설명해보면, 수신한 데이터 프레임의 시퀀스 번호가 1이었고, 다음에 온 데이터 프레임 시퀀스 번호도 1이라면 이는 중복을 의미한다. 바로 이 원리로 수신 호스트는 데이터의 중복 여부를 파악할 수 있다.



# 흐름 제어


 오류 제어와 함께 데이터 링크 계층에서 제공하는 주요 기능은 전송 데이터의 속도 조절이다. 송신 호스트는 수신 호스트가 감당할 수 있을 정도의 전송 속도를 유지하면서 데이터 프레임을 전송해야 하는데, 이러한 기능을 흐름 제어(Flow Control)라 한다. 흐름 제어는 송신 호스트가 수신 호스트보다 아주 빨리 데이터를 전송하는 경우에 필요하다.


 흐름 제어 기능을 제공하지 않으면 수신 호스트는 자신에게 도착한 데이터 프레임을 내부 버퍼에 보관할 여유를 갖지 못한다. 따라서 전송 매체를 통해 올바르게 도착한 데이터가 분실되는 결과를 초래할 수 있다. 흐름 제어 기능의 부재에 따른 프레임 분실은 앞서 설명한 전송 오류의 프레임 분실과 동일한 결과를 가져오기 때문에 이것도 데이터를 재전송하는 방법으로 복구해야 한다.


 흐름 제어의 기본 원리는수신 호스트가 다음에 수신할 프레임의 전송 시점을 송신 호스트에 통지하는 방식이다. 가장 많이 사용하는 흐름 제어 프로토콜의 예는 슬라이딩 윈도우 프로토콜이다.

  


댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday