[혼공네트]4주차_Chap04 정리

임지·2025년 7월 26일
0

혼공네트

목록 보기
4/7

1. 전송 계층

전송 계층은 신뢰할 수 있는 연결형 통신이 가능한 프로토콜(TCP)를 제공하며, 포트를 통해 응용 계층의 특정 애플리케이션을 식별한다.

1-1. 신뢰성 있는 통신 & 연결형 통신

1) IP의 한계

  • 비신뢰성
    : 최선형 전달, 수신지까지 제대로 전송되었다는 보장 X
  • 비연결형
    : 사전 연결 수립 과정 X

2) TCP

  • IP의 한계를 보완
    : 신뢰성 있는 통신 (재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어)
    : 연결형 통신 (연결 수립 과정 O)

3) 비신뢰성 & 비연결성의 필요

  • 실시간성 필요
    : 패킷 손실을 감수하더라도 빠른 전송이 필요할 수 O
    : 동영상 스트리밍 등

  • IP의 성능
    : IP 통신의 경우 매 통신마다 신뢰성을 점검하고 연결을 수립하는 과정이 비효율적

⭐ 1-2. 포트

1) 포트

  • 특정 애플리케이션을 식별할 수 있는 정보
  • 패킷이 특정 애플리케이션에 도달하게 하기 위함
  • 특정 애플리케이션은 응용 계층의 프로세스를 의미

2) 포트 번호에 따른 분류

포트 종류포트 번호 범위
잘 알려진 포트0 ~ 1023
등록된 포트1024 ~ 49151
동적 포트49152 ~ 65535
  • 잘 알려진 포트 (well known port)
    : 시스템 포트
    : 범용적으로 사용되는 애플리케이션 프로토콜이 사용
    : 서버로 동작하는 프로그램이 해당 포트로 동작됨

  • 등록된 포트 (registered port)
    : 애플리케이션 프로토콜에 할당하기 위함
    : 큰 기업의 제품이나 오픈 소스 등
    : 서버로 동작하는 프로그램이 해당 포트로 동작됨

  • 동적 포트 (dynamic port)
    : 사설 포트, 임시 포트
    : 특별히 관리 X 자유롭게 사용 가능
    : 클라이언트로 동작하는 프로그램이 해당 포트로 동작됨

3) IP 주소와 포트 번호

  • 특정 호스트에서 실행 중인 특정 애플리케이션을 식별하기 위함
  • IP 주소:포트 번호의 형식으로 표현
    : ex) 192.168.0.15:8000

1-3. 포트 기반 NET (NAPT)

1) 기존 NET의 문제

  • 기존 NET 테이블은 공인 IP 주소와 사설 IP 주소를 일대일 대응
    - 비교적 적은 공인 IP, 비교적 다수의 사설 IP
    : 모든 IP 주소를 일대일 매칭하는 것은 불가능

2) 포트 기반 NET (NAPT)

  • 같은 공인 IP 주소를 공유하는 서로 다른 사설 IP 주소를 식별하기 위해 사용
  • NAT 테이블에 포트 번호도 함께 기술
네트워크 외부네트워크 내부
1.2.3.4:6200192.168.0.5:1025
1.2.3.4:6201192.168.0.6:1026
  • 같은 1.2.3.4라는 공인 IP 주소여도, 포트번호 6200, 6201 이냐에 따라 사설 IP 주소를 구분지을 수 있다.

  • 따라서, 공인 IP 주소와 사설 IP 주소를 1:N으로 관리할 수 있다.

2. TCP

TCP 프로토콜은 호스트 간 사전 연결을 수립하여 연결형 통신을 가능하게 한다.

2-1. TCP 세그먼트 구조


사진 출처 : https://www.geeksforgeeks.org/computer-networks/services-and-segment-structure-in-tcp/

1) 송/수신지 포트 번호 (16비트)

2) 순서 번호 (32비트)

  • 올바른 송수신 순서를 보장하기 위함
  • 세그먼트 데이터의 첫 바이트에 부여
  • 초기 순서 번호 + 송신한 바이트 수(MSS 크기)

3) 확인 응답 번호 (32비트)

  • 순서 번호에 대한 응답
  • 다음으로 수신하기를 기대하는 순서 번호 값
  • 일반적으로 수신한 순서 번호 + 1

4) 제어 비트 (8비트)

  • ACK : 세그먼트의 승인을 나타내기 위함 (특정 세그먼트에 대한 응답 시 사용)
  • SYN : 연결 수립 (TCP 연결 시작 시 사용)
  • FIN : 연결 종료

⭐ 2-2. TCP 연결 수립

사진 출처 : https://afteracademy.com/blog/what-is-a-tcp-3-way-handshake-process

1) 쓰리 웨이 핸드셰이크 과정

단계호스트 A 상태호스트 B 상태전송된 세그먼트
시작 전CLOSEDLISTEN
1단계SYN-SENTLISTENSYN이 1인 세그먼트 (A -> B)
2단계SYN-SENTSYN-RECEIVEDSYN, ACK가 1인 세그먼트 (B -> A)
3단계ESTABLISHEDSYN-RECEIVEDACK가 1인 세그먼트 (A -> B)
연결 수립ESTABLISTEDESTABLISTED
  • 3번의 세그먼트를 주고받는다고 해서 쓰리 웨이 핸드셰이크라고 한다.

2) 연결 수립 과정 관련 단어

  • 액티브 오픈
    : 처음 연결을 시작하는 호스트의 연결 수립 과정
    : 클라이언트가 SYN 세그먼트를 보내는 시점부터

  • 패시브 오픈
    : 연결 시작 요청을 받은 뒤 연결을 수립하는 과정
    : 서버가 클라이언트의 SYN 세그먼트를 받고, SYNACK 비트를 1로 설정한 세그먼트를 보내는 시점부터

⭐ 2-3. TCP 연결 종료


사진 출처 : https://www.geeksforgeeks.org/computer-networks/tcp-connection-termination/

1) 포 웨이 핸드셰이크 과정

단계호스트 A 상태호스트 B 상태전송된 세그먼트
시작 전ESTABLISHEDESTABLISHED
1단계FIN-WAIT-1ESTABLISHEDFIN이 1인 세그먼트 (A -> B)
2단계FIN-WAIT-2CLOSE-WAITACK가 1인 세그먼트 (B -> A)
3단계FIN-WAIT-2LAST-ACKFIN이 1인 세그먼트 (B -> A)
4단계TIME-WAITLAST-ACKACK가 1인 세그먼트 (A -> B)
연결 종료CLOSEDCLOSED
  • 과정 2와 3 사이에 사용했던 자원 등을 정리한다.
  • TIME-WAIT은 마지막 ACK 세그먼트가 올바르게 전송되지 않았을 가능성 때문에, 바로 종료하지 않고 기다린다.

2) 연결 종료 과정 관련 단어

  • 액티브 클로즈
    : 연결을 종료하려는 호스트의 연결 종료 과정
    : 특정 호스트가 FIN 세그먼트를 보내는 시점부터

  • 패시브 클로즈
    : 연결 종료 요청을 받은 뒤 연결을 종료하는 과정
    : 연결을 종료하려는 호스트의 FIN 세그먼트를 받고, ACK 세그먼트를 보내는 시점부터

3. TCP 오류 제어 : 재전송 기법

TCP는 잘못된 세그먼트를 재전송하는 방법으로 오류를 제어한다.

3-1. 오류 검출

1) 중복된 ACK 세그먼트를 수신

  • 수신 호스트 측에서 송신 호스트가 보낸 특정 세그먼트를 받지 못한 경우, 다음 세그먼트를 전달해달라는 세그먼트를 여러 번 받게 된다.
  • 즉, 다음 순서 번호를 담은 ACK 세그먼트를 여러 번 받게 된다.

2) 타임아웃

  • RTT
    : 메세지를 전송한 뒤, 그에 대한 답변을 받는데까지 걸리는 시간
  • 재전송 타이머가 끝났을 때, 즉 지정된 RTT 타임을 넘겼을 때

3) 빠른 재전송

  • 타임 아웃이 발생하지 않더라도, 3번의 중복 세그먼트를 받은 경우 빠르게 해당 세그먼트를 전송하는 방법
  • 재전송을 빠르게 진행할 수 있다.

3-2. Stop-and-wait ARQ

  • 제대로 전달했음을 확인하기 전까지는, 새로운 메세지를 보내지 않는다.
  • 메세지를 하나씩 주고 받는 알고리즘
  • 높은 신뢰성, 낮은 효율
  • 최근에는 잘 사용하지 않는 방법

3-3. Go-Back-N ARQ

  • 파이프라이닝 기법 사용
  • 한 번에 여러 세그먼트를 전송하고, 세그먼트에 문제가 생기면 해당 세그먼트부터 모두 재전송
  • 오류 세그먼트 이후 세그먼트에 대해 받은 확인 응답 세그먼트는 폐기한다.
  • 누적 확인 응답

3-4. Selective Repeat ARQ

  • 파이프라이닝 기법 사용
  • 한 번에 여러 세그먼트를 전송하고, 세그먼트에 문제가 생기면 해당 세그먼트만 재전송
  • 개별 확인 응답
  • 오늘날 대부분의 호스트가 사용하는 알고리즘
  • TCP 세그먼트 헤더 옵션 필드의 SACK 허용 필드

4. TCP 흐름 제어

TCP는 슬라이딩 윈도우를 사용해, 송신 호스트가 수신 호스트의 처리 속도를 고려해 송수신 속도를 균일하게 유지하도록 한다.

  • 윈도우
    : 수신 호스트가 한 번에 처리할 수 있는 세그먼트의 양

  • Go-Back-N ARQ와 Selective Repeat ARQ의 경우, 슬라이딩 윈도우를 사용


사진 출처 : https://dev.to/mwong068/sliding-window-technique-in-ruby-3og4

  • 특정 세그먼트에 대한 확인 응답을 받으면, 윈도우를 한 칸씩 이동한 뒤 송신할/수신할 세그먼트에 대한 정보를 주고받는다.

  • TCP 헤더의 윈도우 필드에 수신 윈도우의 크기를 명시하고, 확인 응답 번호 값을 통해 슬라이딩 윈도우를 이동시킨다.

5. TCP 혼잡 제어

TCP 프로토콜에서 송신 호스트는, 네트워크 혼잡도를 판단해 유동적으로 전송량을 조절한다.

  • 혼잡 윈도우
    : 송신 호스트가 혼잡 없이 전송할 수 있을 법한 데이터 양

  • 혼잡 윈도우의 적당한 크기를 구하기 위해 혼잡 제어 알고리즘 사용

5-1. 느린 시작 알고리즘

  • 혼잡 윈도우를 1부터 시작해, 문제 없이 수신된 ACK 세그먼트 1개당 1씩 증가시킨다.
    : RTT마다 혼잡 윈도우가 지수적으로 증가
    : 초기 전송 속도 확보

  • 혼잡 윈도우를 증가시키다 보면, 혼잡이 감지될 수 있다.

상황 분류해결 방법
타임 아웃혼잡 윈도우 = 1, 느린 시작 임계치 = 이전의 절반, 느린시작 재개
혼잡 윈도우 >= 느린 시작 임계치느린 시작 종료, 혼잡 회피
3번의 중복 ACK 세그먼트빠른 재전송 후, 빠른 회복

5-2. 혼잡 회피 알고리즘

  • RTT마다 혼잡 윈도우를 1MSS만큼 증가
    : 선형적으로 혼잡 윈도우 크기 증가
    : 이전에 느린 시작 임계치를 한 번 넘긴 적 있으므로, 천천히 크기를 증가시킨다.
상황 분류해결 방법
타임 아웃혼잡 윈도우 = 1, 느린 시작 임계치 = 이전의 절반, 느린시작 재개
3번의 중복 ACK 세그먼트혼잡 윈도우&느린 시작 임계치 = 이전의 절반, 빠른 회복

5-3. 빠른 회복 알고리즘

  • 느린 시작을 건너 뛰고, 혼잡 회피를 수행
  • 빠르게 전송률을 회복하기 위함
상황 분류해결 방법
타임 아웃혼잡 윈도우 = 1, 느린 시작 임계치 = 이전의 절반, 느린시작 재개

5-4. 느린 시작 알고리즘 그래프

  • 혼잡 윈도우 크기와 느린 시작 임계치가 유동적으로 변화하는 것을 확인할 수 있다.

그래프 설명

  1. 앞서 느린 시작 알고리즘을 ssthresh1까지 수행하다가, ssthresh1을 넘어선 직후 혼잡 회피 알고리즘을 수행한다.
  2. 혼잡 회피 알고리즘을 진행하다가, 3번의 중복 ACK 세그먼트를 받아 빠른 회복 알고리즘을 수행한다. 이때, 임계치와 혼잡 윈도우를 대략 절반 정도로 떨어뜨린다.
  3. 빠른 회복 알고리즘을 수행하던 와중 타임 아웃이 발생해, 윈도우를 1로 떨어뜨리고 임계치를 절반으로 떨어뜨린 뒤 다시 느린 시작 알고리즘을 재개한다.

6. UDP 간단 정리

6-1. UDP

  • 비연결형 통신
  • 신뢰할 수 없는 프로토콜
  • 스테이스리스 프로토콜
  • IP 프로토콜을 감싸는 껍데기같은 역할

6-2. UDP 데이터그램 구조

사진 출처 : https://www.geeksforgeeks.org/computer-networks/user-datagram-protocol-udp/

1) 송/수신지 포트 번호 (16비트)

2) 길이 (16비트)

  • 헤더를 포함한 UDP 데이터그램의 바이트

3) 체크섬 (16비트)

  • 오류 검출을 위한 필드

연습 문제 풀이

기본 문제 풀이

  • 206p 1번
    IP와 연관된 통신 특성으로 알맞은 단어 : 비신뢰성. 비연결형

  • 225p 2번
    TCP의 쓰리 웨이 핸드셰이크 과정 중, 괄호 안에 들어갈 말 : ACK

추가 문제 풀이

  • 작업 관리자에서 프로세스별 PID 확인

작업관리자의 프로세스 창에 들어가면, 각 프로세스의 PID를 확인할 수 있다.

디스코드 앱 하위 프로세스들의 PID는 7144, 11036 ... 17660이고, 캡처 툴의 PID는 21160이다. (나머지 앱은 설명 생략)

0개의 댓글