체뚱로그

[컴퓨터네트워크 3기] 3주차 스터디 정리 본문

CS/JSCODE

[컴퓨터네트워크 3기] 3주차 스터디 정리

sooyeoniya 2023. 9. 24. 18:37

[목차]

더보기

신뢰적 데이터 전송의 원리

     슬라이딩 윈도우(Sliding Window)

     Go-Back-N

     Selective Repeat

TCP

     TCP란

     TCP vs UDP

     TCP 헤더 구조

      3-way handshake

     4-way handshake

     TCP 빠른 재전송

     혼잡제어(Congestion control)

     흐름제어(Flow control)

     흐름제어 VS 혼잡제어

📌신뢰적 데이터 전송의 원리

슬라이딩 윈도우(Sliding Window)

두 호스트 간의 프레임 전송을 위한 일반적인 통신 프로토콜로, 오류제어와 흐름제어 기능을 함께 지원한다. 

  1. 정보 프레임을 전송하는 송신 호스트는 보내려는 데이터뿐 아니라 프레임의 순서 번호, 오류 검출 코드 등을 프레임에 표기한 후에 정해진 순서 번호에 따라 순차적으로 송신한다.
  2. 정보 프레임을 받은 수신 호스트가 응답 프레임을 회신할 때, 일반적으로 응답 프레임의 내용에 포함되는 순서 번호는 정상적으로 수신한 프레임의 번호를 기재하는 것이 아닌, 다음에 수신하기를 기대하는 프레임 번호를 표기한다.
  3. 송신 호스트는 송신한 정보 프레임을 자신의 내부 버퍼에 유지해야 하며, 이를 송신 윈도우라 한다. 송신 윈도우에서 대기하는 정보 프레임은 송신 호스트가 수신 호스트에 프레임 전송을 완료했지만 아직 수신 호스트로부터 긍정 응답을 받지 못한 프레임이다.
  4. 수신 호스트는 수신한 정보 프레임을 보관하기 위해 내부 버퍼인 수신 윈도우를 유지할 수 있다. 수신 윈도우에는 개념적으로 수신을 기대하는 프레임의 순서 번호가 들어가기 때문에 프로토콜의 동작 방식에 따라 크기가 달라질 수 있다.
    • Go-Back-N: 수신 호스트가 항상 이전에 수신한 프레임의 바로 다음 프레임만 기다리기 때문에 수신 윈도우의 크기가 1이면 충분하다.
    • Selective Repeat: 프레임의 도착이 비순서적으로 이루어져도 처리할 수 있기 때문에 수신 윈도우의 크기가 송신 윈도우의 크기와 동일하다.

순서 번호: 정보 프레임의 내용에는 프레임별로 고유하게 부여되는 순서번호(Sequence Number)라는 일련 번호가 부여된다. 이 번호는 0부터 임의의 최댓값까지 정의되는데, 최댓값 이후에는 다시 0번으로 되돌아오는 순환 방식으로 할당된다.

*. 프로토콜 설계 시 현재 처리되고 있는 서로 다른 프레임에 같은 순서 번호를 부여하지 않도록 주의해야 한다. 이런 원칙에 위배되지 않으려면 기본적으로 순서 번호의 최댓값이 송신 윈도우의 크기보다는 커야 한다.

  • Stop-and-Wait: 슬라이딩 윈도우 프로토콜에서 가장 기본이 되는 n값(순서 번호를 위해 할당된 공간의 크기가 n비트)이 1인 경우이므로, 순서 번호는 [0, 2^n-1] = [0,1]이다.
  • 슬라이딩 윈도우 프로토콜(Sliding Window) 종류: Stop-and-Wait, Go-Back-N, Selective Repeat, Piggy Backing
  • 파이프라인 프로토콜(Pipelining) 종류: Go-Back-N, Selective Repeat

 

Go-Back-N

오류 복구 과정에서 오류가 발생한 프레임을 포함해 이후에 전송된 모든 정보 프레임을 재전송하는 방식이다.

Go-Back-N 방식은 오류가 발생한 프레임뿐 아니라, 정상적으로 수신한 프레임까지 재전송한다는 문제점이 있다. 따라서 직관적인 관점에서 보면 매우 비효율적이라 생각될 수 있으나, 송수신 호스트 사이의 전송 지연 등에 따라서는 효과적인 처리 방법이 될 수 있다.

Go-Back-N 방식

Selective Repeat

Go-Back-N의 문제점이었던 수신 호스트가 올바르게 수신한 정보 프레임도 오류로 처리해 재전송한다는 점을 해결한 방식으로, Selective Repeat은 오류가 발생한 프레임만 선택적으로 복구하는 방식이다.

Selective Repeat 방식

 

📌TCP

TCP란

TCP(Transmission Control Protocol)는 IP 프로토콜 위에서 연결형 서비스를 지원하는 전송 계층 프로토콜로, 인터넷 환경에서 기본적으로 사용한다. TCP의 주요 기능은 다음과 같다.

  • 연결형 서비스 제공
  • 전이중(Full Duplex) 방식의 양방향 가상 회선 제공
  • 신뢰성 있는 데이터 전송 보장

TCP는 데이터를 세그먼트(Segment)라는 블록 단위로 분할해 전송하며, 세그먼트를 하나의 단위로 간주하여 순서 번호를 관리하지 않는다. 대신 세그먼트에 실려 전송되는 데이터의 바이트 개수를 순서 번호에 반영한다.

 

TCP vs UDP

*. 다음 링크 참고: https://dev-cheddung.tistory.com/3

 

TCP 헤더 구조

TCP의 세그먼트는 다음과 같은 헤더 구조로 시작하고, 뒤에 전송 데이터가 붙는다. 

TCP 헤더의 최소 크기는 20바이트이고, Options(최대 40바이트)와 Padding(헤더의 크기를 4바이트 단위로 맞추려고 사용)은 생략 가능하다.

TCP 헤더 구조

 

3-way handshake

TCP를 사용하는 프로세스가 가장 먼저 실행하는 연결 설정은 3-way handshake 방식이다. 다음 그림과 같이 클라이언트가 연결 설정을 요구하고, 서버가 이를 수락하는 형식이다.

TCP 연결 설정 과정

4-way handshake

TCP에서 서버와 클라이언트의 연결을 해제(세션 종료) 하는데 필요한 방식이다.

TCP 연결 해제 과정

 

 

TCP 빠른 재전송

전송 중 세그먼트가 손실된 상황에서 Timeout까지 불필요한 긴 시간 대기를 회피할 수 있도록 한다.

3개의 중복 ACK가 도착하면 Timeout과 무관하게 누적 수신 확인한 다음 세그먼트를 재전송한다.

혼잡제어(Congestion control) 

혼잡제어란 네트워크 혼잡 현상을 방지하거나 제거하는 기능을 말한다.

 

네트워크 혼잡(Network Congestion)

  • 트래픽 증가로 인해 라우터/스위치 버퍼의 큐잉 지연시간 증가 및 오버플로우 발생(큐의 버퍼가 넘침)

TCP 혼잡 제어 원리

  • 세그먼트 전송률(Transmission rate) 축소 조정 (네트워크로 유입되는 트래픽을 감축하여 오버플로우 개선)

TCP 네트워크 혼잡 인식

  • 심각한 혼잡: Timeout 발생
  • 경미한 혼잡: 중복 ACK 발생(3 duplicate ACKs) → 빠른재전송으로 해결

TCP 혼잡 제어 기법

  • 슬로우 스타트(Slow Start)
    • 연결 시작 또는 혼잡 발생 시에 혼잡윈도우(cwnd)를 최솟값(e.g., 1 MSS)부터 전송률을 낮게 천천히 시작
    • ACK가 수신될 때마다 혼잡 윈도우를 1씩 증가
    • ACK 수신 → cwnd = cwnd + 1
    • RTT 마다 혼잡 윈도우를 2배씩 증가 (지수적 증가, exponential increase)

Slow Start 방식

  • 혼잡 회피(Congestion Avoidance)
    • 혼잡 윈도우가 임계치(ssthresh)에 도달하거나 넘어가면 선형적(linear)으로 증가하도록 증가 속도를 조정하는 알고리즘
    • RTT 마다 혼잡 윈도우를 1씩 증가(선형적 증가, linear increase)
    • ACK가 수신될 때마다 혼잡 윈도우를 (1/cwnd) 씩 증가
    • ACK 수신 → cwnd = cwnd + (1/cwnd)

Congestion Avoidance 방식
Slow Start / Congestion Avoidance 혼잡 윈도우 변화

  • 빠른 복구(Fast Recovery)
    • 3개의 중복 ACK에 의한 빠른 재전송 시에 적용: 경미한 혼잡 상황
    • 정상 ACK가 수신되어 오류 복구가 완료되면 슬로우 스타트 구간을 건너뛰고 혼잡 회피 단계로 진입
빠른 복구(Fast Recovery) 알고리즘 과정
1. 임계치를 현재 혼잡 윈도우의 1/2로 설정 (ssthresh = cwnd / 2)
2. 손실된 세그먼트 재전송
3. 혼잡 윈도우를 임계치 + 3으로 설정 (cwnd / ssthresh + 3)
4. 여전히 중복 ACK를 수신하면 (cwnd = cwnd + 1)   →  새로운 세그먼트 추가 전송 가능
5. 정상 ACK를 수신하면 (cwnd = ssthresh)   → 혼잡 회피 단계로 진입 (오류 복구 완료)

 

빠른 복구 예제 과정

빠른 복구 예제 과정
1. 혼잡 윈도우가 6인 상태에서 3번째 중복 ACK를 수신한 후에 송신자는 임계치를 현재 혼잡 윈도우의 1 / 2로 설정 (6 / 2 = 3)
2. 손실 패킷 (pkt5) 재전송
3.  혼잡 윈도우를 임계치 + 3 (3 + 3 = 6)으로 설정
4. 2개의 중복 ACK 추가 수신으로 혼잡 윈도우는 8로 증가 (6 + 2 = 8)
5. 현재 5 ~ 10까지 6개의 패킷만 전송했으므로 2개의 패킷 추가로 전송 가능 (pkt 11, pkt 12)
6. 새로운 ACK11을 수신하면 빠른 복구(Fask Recovery)를 종료
7. 혼잡윈도우는 임계치로 설정한 다음 (ssthresh = 3), 혼잡 회피 단계로 진입

빠른 복구 예제 혼잡 윈도우 변화

 

 

TCP 혼잡 제어 알고리즘

  • TCP Tahoe
    • 혼잡 인식: Timeout, 3개 중복 ACK
TCP Tahoe 알고리즘
1. 임계치를 현재 혼잡 윈도우의 1 / 2로 설정 (ssthresh = cwnd / 2)
2. 슬로우 스타트(Slow Start) 개시
3. 혼잡 윈도우가 임계치에 도달하거나 넘어가면 혼잡 회피(Congestion Avoidance) 수행

TCP Tahoe 예제

 

  • TCP Reno
    • 혼잡 인식: Timeout, 3개 중복 ACK
TCP Reno 알고리즘
1. Timeout 발생 시 Tahoe 버전과 동일하게 동작 (심각한 혼잡)
2. 3개의 중복 ACK 발생 시 빠른 회복(Fask Recovery) 알고리즘 적용 (경미한 혼잡)

 

TCP Tahoe와 Reno 비교
TCP Reno 예제

 

  • AIMD(Additive Increase Multiplicative Decrease)
    • AIMD는 혼잡이 없을 때 혼잡창의 선형 증가와 혼잡이 감지될 때 지수 감소를 결합한 것이다.

AIMD(Additive Increase Multiplicative Decrease)

 

 

혼잡제어를 위한 TCP 전송률 제어

  • 마지막송신바이트번호 – 마지막수신확인바이트번호 ≤ min(수신윈도우, 혼잡윈도우)
  • LastByteSent – LastByteAcked ≤ min(rwnd, cwnd)

 

흐름제어(Flow control)

흐름제어란 송신 TCP가 지나치게 많은 데이터를 한꺼번에 송신함으로써 수신 TCP의 버퍼가 넘쳐(Overflow) 데이터 손실이 발생하는 문제를 방지하는 메카니즘이다.

수신 TCP는 자신의 수신 버퍼 내의 여유 공간의 크기를 송신 TCP에게 통지하고, 송신 TCP는 통지된 여유 공간의 크기보다 적은 양의 데이터를 송신해야 한다.(수신자는 ACK를 통해 송신자에게 수신 윈도우의 크기를 알려줌)

흐름 제어 시각화

흐름제어를 위한 TCP 전송률 제어

  • 마지막으로 송신한 바이트 번호와 ACK 세그먼트를 통해 마지막으로 수신 확인된 바이트 번호의 차이가 항상 수신 윈도우보다 작게 유지해야 한다.
  • 마지막송신바이트번호 – 마지막수신확인바이트번호 ≤ 수신윈도우
  • LastByteSent – LastByteAcked ≤ rwnd

수신 윈도우 0 (rwnd = 0)

  • 송신 TCP는 더 이상 데이터를 전송하지 않고 수신 TCP로부터 변경된 수신 윈도우가 도착하길 기다린다.
  • 수신 TCP는 송신 TCP로 전송할 ACK가 없어서 수신 윈도우 변화를 통보하지 못한다.
  • Deadlock 상태 진입한다.

윈도우 Probe 세그먼트

  • 수신 윈도우가 0일 때 송신 TCP가 수신 TCP에게 주기적으로 전송하는 1 바이트 세그먼트를 말한다.
  • 수신 TCP는 Probe 세그먼트에 대한 ACK를 통해 최신 수신윈도우 정보(여유 공간 확인용)를 송신 TCP에게 제공

흐름제어 VS 혼잡제어

흐름제어 혼잡제어
송신측과 수신측 사이의 전송 속도를 다룸 호스트와 라우터를 포함한 보다 넓은 관점에서의 전송 문제를 다룸

 

 

https://copycode.tistory.com/74

https://product.kyobobook.co.kr/detail/S000001743587

https://bangu4.tistory.com/74

https://sh-safer.tistory.com/146

https://youtu.be/ggYSlpjaUDY?si=JwxKIiAoUB4rurGM 

https://youtu.be/R2dWNQTABcI?si=yGGpALaaNhb2TIh- 

https://seongonion.tistory.com/74

https://jungwoong.tistory.com/11

https://jungwoong.tistory.com/22

https://movefast.tistory.com/36

https://gyoogle.dev/blog/computer-science/network/%ED%9D%90%EB%A6%84%EC%A0%9C%EC%96%B4%20&%20%ED%98%BC%EC%9E%A1%EC%A0%9C%EC%96%B4.html

 

 

TCP/IP (흐름제어/혼잡제어) | 👨🏻‍💻 Tech Interview

최종 수정 : 12/17/2022, 7:23:59 AM

gyoogle.dev

 

6. Fast Retransmit and Flow Control - 빠른 재전송과 흐름 제어

▶ Fast Retransmit (빠른 재전송) - 재전송 타이머 값이 종종 상대적으로 길어지므로, 손실된 패킷의 재전송 전에 지연시간이 커진다. - 위의 상항을 해결하고자 중복 ACKs를 통해 손실된 세그먼트를

movefast.tistory.com

 

[TCP] 연결 종료 과정

TCP 연결 수립과 마찬가지로 TCP 연결 종료 시에도 다양한 상태를 거치는 과정이 필요합니다. 연결 종료는 연결 수립보다 복잡한데 그 이유는 두 장비 모두 데이터를 주고받는 도중에 연결을 끊기

jungwoong.tistory.com

 

[TCP] 연결 수립 과정 2

이전글 : [TCP] 연결수립 과정 TCP의 연결 준비 연결의 식별자 TCP는 많은 연결을 동시에 처리할 수 있어야 합니다. 각 연결을 유일 하도로 식별하기 위해서 연결이 이루어지는 두 장비의 소켓 식별

jungwoong.tistory.com

 

[네트워크] TCP 3-way & 4-way handshake란?

TCP란 연결 지향형 프로토콜로, 연속성 있는 데이터 패킷을 주고 받을 때 사용한다. TCP 특징 전송되는 데이터의 신뢰성 보장 (흐름 제어, 혼잡 제어, 오류 제어) 파일전송에 주로 사용 가상 회선을

seongonion.tistory.com

 

[TCP] 4-way Handshake란? / 와이어샤크, tcpdump 확인

4-way Handshake란? TCP/IP 네트워크 환경에서 서버와 클라이언트를 연결을 해제(세션 종료)하는데 필요한 프로세스입니다. TCP FLAG FLAG 설명 SYN(연결 요청 플래그) - TCP에서 세션을 성립할 때 가장먼저

sh-safer.tistory.com

 

[네트워크] 3-way / 4-way Handshake 란?

1. TCP 3-way Handshake 란? TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 three-way handshake를 사용한다. TCP 3 Way Handshake는 TCP/IP프로토콜을 이용해서 통신을 하는 응용프로그램이 데이터

bangu4.tistory.com

 

데이터 통신과 컴퓨터 네트워크 | 박기현 - 교보문고

데이터 통신과 컴퓨터 네트워크 |

product.kyobobook.co.kr

 

컴퓨터 네트워크 17장 - 슬라이딩 윈도우 프로토콜 -

컴퓨터 네트워크 17장- 슬라이딩 윈도우 프로토콜 - 슬라이딩 윈도우 프로토콜은 두 호스트 간 데이터 전송을 위한 일반적인 통신 프로토콜로 오류 제어와 흐름 제어를 함께 지원한다. 슬라이딩

copycode.tistory.com

Comments