신뢰적 데이터 전송의 원리
슬라이딩 윈도우란?
정지-대기 기법의 비효율성을 개선한 기법
수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK)없이 전송할 수 있게 하여 흐름을 동적으로 조절하는 제어 알고리즘 이다.
오류 제어와 흐름 제어를 함께 지원한다.
최대 윈도우의 사이즈 만큼 전송할 수 있다.
기본 절차
1. 송신측은 프레임을 순서 번호에 따라 순차적으로 전송한다.
2. 수신측이 송신측에 전송하는 순서 번호는 정상적으로 수신한 번호가 아닌, 다음에 수신하기를 기대하는 번호이다.
- ACK4: 4번을 받을 차례이다 라는 뜻
3. 송신측은 전송은 되었지만, ACK를 받지 못한 프레임들을 버퍼에 쌓아둠
4. 수신측은 프로토콜의 동작 방식에 따라 크기가 다름
- 선택적 재전송(Selective Repeat): 수신측과 송신측의 윈도우 크기가 같음
- Go-back N: 크기가 1임(정상적으로 들어온 프레임만 받아서 처리)
흐름제어
순서 번호
- 프레임 별로 부여되는 일련 번호
- 0부터 임의의 최댓값까지 순환 방식으로 사용
- 일반적으로 순서 번호의 최댓값이 송신 윈도우 크기보다 커야함
- 프레임에서 순서 번호의 공간 크기 = n 비트: 순서 번호의 범위는 0 ~ 2^ - 1
윈도우 크기
- ACK를 받지 않고도 연속으로 전송할 수 있는 프레임의 최대 개수
- 윈도우 사이즈 3
- ACK를 받지 않고도 최대 윈도우 사이즈 만큼 보낼 수 있음
(a) 0,1,2 보낸 후 대기
(b) ack 1로 받음(그림 틀림) / 윈도우 바뀜(1,2,3) / 3번 보낼 수 있는 상태
(c) 3 보냄
(d) ACK 2 받음 (그림 틀림) / 윈도우 바뀜 (2,3,4) / 4번 보낼 수 있는 상태
(e) 4 보냄
(f) ACK 3, ACK 4 받음 (그림 틀림) / 윈도우 바뀜 (4,5,6) / 5번, 6번 보낼 수 있는 상태
연속형 전송
정지-대기 프로토콜은 송신 윈도우 크기가 1
- 프레임 전송시간이 오래 걸리는 경우 전송 효율이 극단적으로 떨어짐
연속형 전송(Pipelining)
ACK를 받지 않고 여러 프레임을 연속적으로 전송
전송 오류 발생 가능성이 적은 환경에서는 상당히 효율적
오류 발생이 가능하므로 해결 방안 필요
Go-back N
오류가 발생한 프레임을 포함해 이후에 전송된 모든 프레임을 재전송
Selective Repeat
오류가 발생한 프레임만 선택적으로 복구하는 방식
부정 응답 프레임(NCK)을 사용해 오류가 발생한 정보 프레임을 처리하는 경우
원하는 데이터만 송신을 요청함
문제가 발생한 프레임들만 다시 보내는 방식
TCP
TCP
Transmission Control Protocol
신뢰성있는 데이터 통신을 가능하게 해주는 프로토콜
3 way handshake로 커넥션 연결
데이터의 순차전송 보장
Flow Control(흐름 제어)
- 송수신자 간의 데이터 처리 속도 차이
- 수신자가 처리할 수 있는 데이터량을 초과 방지(데이터 누락 방지)
Congestion Control(혼잡 제어)
- 송신자 측에서 보내도 네트워크 문제가 발생하여 수신측에서 못받을 수 있음
- 네트워크의 데이터 속도 처리
Error Detection(오류 감지)
- 체크섬 확인
단점
전송의 신뢰성은 보장하지만, 매번 커넥션을 연결해야해서 느리다.
패킷을 조금만 손실해도 재전송
데이터 단위는 세그먼트 단위
TCP Header + Data
| 이름 | 설명 |
| Source port | 송신 포트번호 |
| Destionation port | 수신 포트 번호 |
| Sequence Number | TCP 세그먼트 안의 데이터 송신 바이트 위치 |
| Acknowledgment Number | 수신자의 다음 데이터 바이트 순서번호 |
| Data Offset | TCP 헤더의 길이 |
| Reserved | 예약되어 있는 필드 |
| TCP Flags | 별도 설명 |
| Window Size | 수신측이 받을 수 있는 데이터 사이즈 |
| Checksum | TCP 헤더 데이터를 포함한 세그먼트 전체 계산 값 |
| Urgent pointer | 긴급히 처리해야 하는 데이터 바이트 위치 |
| TCP Options | 연결이 구성되는 동안의 최대 세그먼트 크기 옵션 |
TCP Flags
TCP 연결 제어 및 데이터 관리
| 이름 | 설명 |
| URG(Urgent) | 특정(긴급) 상황 시, 특정 데이터를 읽기 원하는 경우 사용 |
| ACK(Acknowledgment) | 요청에 대한 확인 응답 시 사용 |
| PSH(Push) | 네트워크에서 버퍼링 우회와 데이터 즉시 통과 시 사용 |
| RST(Reset) | TCP 연결 중 특이사항이 발생하여 강제 종료 시 사용 |
| SYN(Synchronize) | 클라이언트, 서버의 일련번호(동기화)를 확인시 사용 |
| FIN(TCP 연결 종료 시 사용) | TCP 연결 종료 시 사용 |
3 way handshake
서버와 클라이언트가 데이터 송수신을 하기 전에 맺는 커넥션 과정
1. SYN 비트를 1로 설정해 패킷 송신
- 시퀀스 번호, 최대 세그먼트 크기, 윈도우 사이즈와 같은 정보가 포함되어 있다.
2. SYN. ACK 비트를 1로 설정해 패킷 송신
- 클라이언트에서 받은 시퀀스 번호보다 1큰 ACK를 클라이언트로 보낸다.
- 송신자가 다음에 보낼 시퀀스 값
- 서버는 임의로 시퀀스 번호를 생성하여 SYN을 보낸다
- 서버는 흐름제어를 위해 서버의 버퍼 용량과 윈도우 사이즈를 클라이언트로 보낸다.
3. ACK 비트를 1로 설정해 패킷 송신
- 서버에서 보낸 SYN 시퀀스 번호보다 1큰 ACK 숫자를 서버에 전송
4 way handshake
커넥션을 종료하는 과정
1. 데이터를 전부 송신한 Client가 FIN 송신
2. 서버가 ACK 송신
3. 서버에서 남은 패킷 송신(일정 시간 대기)
4. 서버가 FIN 송신
5. 클라이언트가 ACK 송신
클라이언트에서 ACK를 송신하고 TIME-WAIT 상태로 변하는데 이는 의도치않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지하기 위해 변경 되는 것인데, 만약 에러로 인해 종료가 지연되다가 타임이 초과되면 CLOSED 상태로 변경된다.
Congestion control
혼잡방지는 데이터 전송량을 조절하여 네트워크가 혼잡해지지 않게 조절하는 것을 말한다.
예를 들어 데이터 전송량이 과다한 것을 감지하여 패킷을 적게 보내 혼잡 붕괴 현상이 일어나는 것을 막는다.
네트워크 상황 확인하는 방법
Network-assisted congestion control
네트워크에서 직접 데이터를 전송
라우터에서 큐 상황을 데이터로 보내어 엔드 시스템은 해당 정보를 받아서 데이터 전송량을 제어하는 방식
라우터에서 부담이 크다는 문제가 있어서 사실상 적용하기 어려운 방식
End-end congestion control
클라이언트, 서버 같은 엔드 시스템이 네트워크 상황을 유추해서 제어한다
ACK 피드백에 돌아오는 데 걸리는 시간인 RTT(Round trip time)이 예상보다 짧다면 네트워크 상황이 좋은 것이고,
RTT가 길거나 아예 유실이 일어나버렸다면 네트워크 상황이 좋지 않다.
네트워크 상황을 확이낳여 Send 버퍼에서 윈도우 사이즈를 적당히 정하여 속도를 조절할 수 있다.
TCP 혼잡제어
AIMD(Additive Increase / Multicative Decrease) 라고도 부른다.
3단계로 구성된다.
처음에는 아주 느린 속도로 시작해서 네트워크 병목 현상이 일어날 때까지 계속해서 속도를 올려가는 식으로 전개된다.
1. Slow Start: 작은 값부터 시작
- 처음에는 병목 현상이 일어나는 대역폭을 알수 없다.
- 아주 작은 값 부터 시작해서 전송속도를 증가시킨다
- 지수배로 증가시킨다(1, 2, 4, 8, 16)
- 윈도우 사이즈를 증가시키는 거다
2.. Additive increate: 천천히 속도를 높임
- 네트워크에는 임계점(Threshold)이 존재해서 그 이상 데이터를 전송할 때는 주의해야 한다.
- Slow start 과정에서 임계점에 도닳하면 천천히 속도를 높인다.
- 16,17,18과 같은식으로 선형적으로 전송량을 늘린다.
3. Multiplicative decreate: 병목 현상이 발생하면 절반으로 줄인다.
- 네트워크 상황이 안 좋으면 패킷 유실이 발생한다
- 패킷 유실이 발생하면 전송량을 1/2배로 줄인다.
- 한번에 확 줄이는 이유는 네트워크 공유자원이므로 패킷 하나 두개를 줄이는 것으로는 혼잡 상태를 해소하기 어렵ㄱ 때문이다.
- 윈도우 사이즈를 줄인 다음에는 다시 2번 단계로 돌아가서 전송량을 늘린다.
혼잡 제어에서는 MSS(Max segment Size) 단위를 사용한다.TCP 세그먼트 하나가 가질 수 있는 최대 데이터 크기(Byte)를 나타낸다.
MSS는 IPv4 기준 약 500Byte이다.
전송량 증가 -> 선형 증가 -> 반토막 -> 전송량 증가 ... 를 반복해서 그래프는 톱날 모양으로 속도가 변한다.
네트워크 임계 지점에서 전송하는 속도만큼 계속 전송하는 것이 가장 좋지만, 임계 지점은 매번 바뀌므로 불가능하다.
TCP Tahoe vs TCP Reno
TCP Tahoe
최초의 TCP 혼잡 제어 알고리즘
Slow Start로 시작해서 임계점을 넘으면 선형적으로 증가한다.
패킷 유실이 발생하면 윈도우 사이즈가 무조건 1 MSS로 감소한다.
초기 상태로 돌아와 다시 slow start부터 시작한다.
임계점은 유실이 발생했을 때의 절반이 된다.
무조건 1 MSS로 다시 되돌아가므로 다시 원상태의 속도로 돌아올 때까지 시간이 많이 걸린다.
이를 개선한 것이 TCP Reno 이다.
TCP Reno
패킷 유실은 두가지 상황으로 나눌 수 있다.
1. 타임아웃 발생
- ACK 응답을 받지 못해 타임아웃이 발생하는 케이스
- 타임아웃이 발생할 정도라면 데이터 전송이 원활하게 이루어지지 않는 환경이므로, 네트워크 상태가 많이 안 좋은 셈이다.
2. 3 dup ack
- 복제된 ACK가 세 번 도달하는 것을 3 duplicate ack라 한다.
- 빠른 재전송(Fast retransmit)에 의해 패킷 유실을 감지하는 케이스
- 해당 패킷만 문제가 있고 네트워크 상태는 정상이다.
타임아웃 같이 네트워크 상황이 나쁘지 않다면 데이터 전송량을 1 MSS까지 감소시킬 이유가 있겠는가?
없다!!
TCP Reno는 아래와 같이 행동한다
- 패킷 유실 판별 조건에 따라 다르게 행동- 3 dup ack -. 네트워크 상황이 좋으므로 사이즈를 절반으로 줄인다- timout -> 기존과 동일하게 사이즈를 1 MSS로 내린다.- 임계점은 Tahoe와 동일하게 직전에 패킷 유실이 발생한 사이즈의 절반으로 줄인다.
Flow control
수신 측이 송신측보다 데이터 처리 속도가 빠르면 문제가 없지만, 송신 측의 속도가 빠를 경우 문제가 생긴다.
수신 측에서 제한된 저장 용량을 초과한 이후에 도착하는 패킷은 손실될 수 있으며, 만약 손실된다면 불필요한 추가 패킷 전송이 발생하게 된다.
흐름제어란 송신측과 수신측의 TCP 버퍼 크기 차이로 인해 생기는 데이터 처리 속도 차이를 해결하기 위한 기법이다.
대표적으로 Stop and Wait과 Sliding Window 기법이 있다.
Stop and Wait은 전송한 패킷에 대해 확인 응답(ACK)을 받으면 다음 패킷을 전송하는 제어 기법이다.
Sliding Window는 수신 측에서 설정한 윈도우 크기만큼 송신 측에서 확인 응답(ACK) 없이 패킷을 전송할 수 있게 하는 방식이다.
※ TCP 버퍼란
송신 측은 버퍼에 TCP 세그먼트를 보관한 후 순차적으로 전송하고, 수신 측은 도착한 TCP 세그먼트를 애플리케이션이 읽을때까지 버퍼에 보관한다.
참고
http://www.kocw.net/home/cview.do?mty=p&kemId=1428811
https://dataonair.or.kr/db-tech-reference/d-lounge/technical-data/?mod=document&uid=235942
https://www.youtube.com/watch?v=ikDVGYp5dhg
https://www.scaler.com/topics/computer-network/tcp-3-way-handshake/
https://jeongkyun-it.tistory.com/180
https://dev-nicitis.tistory.com/31
https://steady-coding.tistory.com/507
'외부활동 > CS 면접 끝장내기 - 컴퓨터 네트워크 2기' 카테고리의 다른 글
| 컴퓨터 네트워크 5주차 스터디 정리 (2) | 2023.08.20 |
|---|---|
| 컴퓨터 네트워크 4주차 스터디 정리 (0) | 2023.08.13 |
| 컴퓨터 네트워크 2주차 스터디 정리 (0) | 2023.07.30 |
| 컴퓨터 네트워크 1주차 스터디 정리 (0) | 2023.07.23 |
댓글