반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- programmers
- 취준
- Pro-Con
- LeetCode
- python3
- git
- Github
- 알고리즘
- SRE
- C++
- 백트래킹
- 알고리즘 종류 정리
- 제노블레이드 2
- ASF-110
- baekjoon
- 백준
- GitHub Desktop
- 프로콘 갈림현상
- 프로콘
- 리트코드
- 자소서
- Algorithmus
- Ultimate Search
- 프로그래머스
- algorithm
- 코딩테스트
- DP
- 격리수준
- Python
- 네이버 검색 시스템
Archives
- Today
- Total
산타는 없다
흐름 제어, 오류 제어, 혼잡 제어 본문
반응형
흐름 제어
송신측(전송량)과 수신측(처리량)의 데이터 처리 속도 차이를 해결하기 위한 기법
수신측의 처리속도가 더 빠르다면 문제가 없지만
송신측의 데이터 전송 속도가 더 빠르다면 수신측의 큐를 넘어서 손실될 수 있기 때문에
송신측의 패킷 전송량을 제어하게 된다.
- Stop and Wait(정지 - 대기)
- 매번 전송한 패킷에 대한 확인 응답을 받아야 다음 패킷을 전송할 수 있다.
- 매우 안정적이지만 속도가 너무 느리다
- Sliding Window
- 윈도우 : 송신, 수신 스테이션 양쪽에서 만들어진 버퍼의 크기
- 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인 응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 기법이다.
- 0, 1, 2, 3, 4, 5, 6, 7.... 프레임을 전송하는 상황이고 윈도우의 크기가 7라면
0, 1, 2, 3, 4, 5, 6 프레임은 수신측의 응답 없이 전송을 하게되고, 전송 중간에 수신측에서 처리한 프레임(0, 1)에 대해 응답이 오면 응답온 크기만틈 윈도우 우측 경계를 확장한다. 즉, 2, 3, 4, 5, 6, 7, 0 프레임이 윈도우에 있게된다.
오류 제어
오류 검출과 재전송을 포함한다.
ARQ(Automatic Repeat Request) 기법을 사용해 프레임이 손상되었거나 손실되었을 경우, 재전송을 통해 오류를 복구한다.
ARQ 기법은 흐름 제어 기법과 관련되어 있다.
- Stop and Wait ARQ
- 흐름제어의 Stop and Wait와 유사하지만 수신측에서 수신된 프레임의 에러 유무 판단에 따라 Ack or Nak를 보낸다.
- 식별을 위해 데이터 프레임과 Ack 프레임은 각각 0, 1 번호를 번갈아가면 부여한다.
- Nak를 받은 송신측은 데이터를 재전송한다.
- 송신측이 전송을 한 후 일정 시간을 두고 타임아웃이 되면, 송신측은 데이터를 재전송한다
(Ack가 분실되었을 경우)
- Go - Back - n ARQ (슬라이딩 윈도우)
- 슬라이딩 윈도우에서 전송된 프레임이 손상되거나 분실된 경우 또는 Ack 패킷의 손실로 타임아웃이 발생한 경우, 마지막으로 확인된 프레임 이후로 모든 프레임을 재전송한다.
- 슬라이딩 윈도우는 연속적인 프레임 전송 기법으로 전송된 모든 프레임의 복사본을 가지고 있어야하며, ACK와 NAK 모두 각각 구별해야 한다.
- ACK : 전달받은 받은 프레임을 포함한 다음 프레임을 전송
- NAK : 손상된 프레임 자체 번호를 반환. 전달 받은 번호를 포함한 이후의 모든 데이터를 재전송한다.
- SR(Selective-Reject) ARQ
- GBn ARQ의 확인된 마지막 프레임 이후의 모든 프레임을 재전송하는 단점을 보완한 기법
- 손상된, 손실된 프레임만 재전송한다.
- 때문에 별도의 데이터 재정렬을 수행해야 하며, 별도의 버퍼를 필요로 한다.
- 수신측에 버퍼를 두어 받은 데이터의 정렬이 필요하다.
혼잡 제어
송신측의 데이터 전달과 네트워크 데이터 처리 속도를 해결하기 위한 기법
- 흐름 제어는 송신측과 수신특의 처리 속도를 해결
한 라우터에게 데이터가 몰려 모든 데이터를 처리할 수 없는 경우, 호스트들은 재전송을 하게 되고 결국 혼잡만 가중시켜 오버플로우나 데이터 실이 발생한다.
이러한 네트워크의 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송 속도를 제어하는 것이 혼잡제어의 개념
- AIMD(Additive Increase Multicative Decrease)
- 합 증가 / 곱 감소 알고리즘이라고 한다.
- 처음에 패킷 하나를 보내는 것으로 시작하여 전송한 패킷이 문제 없이 도착한다면 Window Size를 1씩 증가시키며 전송하는 방법이다. 만약, 패킷 전송을 실패하거나 Time_Out이 발생하면 Window Size를 절반으로 감소시킨다.
- 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만, 시간이 지나면 평형 상태로 수렴하게 되는 특징이 있어 공평하다고 볼 수 있다
- 문제점은 초기 네트워크의 높은 대역폭을 사용하지 못하고 네트워크가 혼잡해지는 상황을 미리 감지하지 못하여 혼잡해지고 나서야 대역폭을 줄이는 방식이다.
- Slow Start
- AIMD가 네트워크의 수용량 주변에서는 효율적으로 동작하지만, 처음에 전송 속도를 올리는 데 너무 길다는 단점을 보안한 방식이다.
- 처음에는 패킷은 하나씩 보내는 것으로 시작하다가 문제가 없어 다음 패킷을 보낼 땐 각각의 ACK 패킷마다 Window Size를 1씩늘려 결국 Window Size를 2배씩 늘린다.
- 그러다 혼잡 현상이 발생하면 Window Size를 1로 떨어뜨린다.
- 처음엔 혼잡 현상이 발생한 구간이 없어 2배씩 늘리지만 한번 발생하고 난 후 부터는 혼잡 현상이 발생한 구간을 기억해 해당 Window Size의 절반까지는 2배씩 늘리다가 그 이후부터는 1씩 증가시킨다.
- 혼잡 현상이 발생한 구간의 Window Size 절반의 값을 임계값(threshold)라고 한다.
- 전송되는 데이터의 크기가 임계 값에 도달하면 혼잡 회피 단계로 넘어간다.
- [혼잡 회피(Congestion Avoidence)]
- 윈도우의 크기가 임계 값에 도달한 이후에는 데이터의 손실이 발생할 확률이 높아진다.
- 따라서 이를 회피하기 위해 윈도우 크기를 선형적으로 1씩 증가시키는 방법이다.
- 수신측으로부터 일정 시간동안 ACK를 수신하지 못하는 경우
- 타임 아웃의 발생 : 네트워크 혼잡이 발생했다고 인식.
- 혼잡상태로 인식된 경우
- 윈도우의 크기를 즉, 세그먼트의 수를 1로 감소시킨다.
- 동시에 임계값을 패킷 손실이 발생했을 때의 윈도우 크기의 절반으로 줄인다.
- [빠른 회복(Fast Recovery)]
- 혼잡한 상태가 되면 Window Size를 1로 줄이지 않고 절반으로 줄이고 선형 증가시키는 방법
- 빠른 회복 정책까지 적용하면 혼잡 상황을 한번 겪고나서는 순수한 AIMD 방식으로 동작하게 된다.
- [빠른 재전송(Fast Retransmit)]
- 수신측에서 패킷을 받을 때 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보낸다. 단, 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK 패킷에 실어서 보낸다. 따라서 중간에 패킷 하나가 손실되면 송신측에서는 순번이 중복된 ACK 패킷을 받게 된다. 이것을 감지하면 문제가 되는 순번의 패킷을 재전송할 수 있다.
- 빠른 재전송은 중복된 순번의 패킷을 3개 (3 ACK) 받으면 재전송한다. 그리고 이러한 현상이 일어나는 것은 약간의 혼잡이 발생한 것으로 간주하여 Window Size를 전바으로 줄인다.
출처
github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/TCP.md
반응형
'Computer Science > 네트워크' 카테고리의 다른 글
쿠키와 세션 (0) | 2021.04.14 |
---|---|
웹 브라우저에 주소(www.naver.com 등) 입력하여 접속하기까지 과정 (0) | 2021.03.26 |
Comments