네트워크 요약

웹페이지 구성

• 웹 페이지는 다른 웹 서버에 저장될 수 있습니다.
• HTTP는 HyperText Transfer Protocol 약자로, 웹 애플리케이션 레이어 프로토콜입니다.

웹 서버 특징

• 서버는 클라이언트로부터 TCP 커넥션을 수락하며 HTTP 메세지를 주고받습니다.
• 브라우저는 HTP 클라이언트, 웹서버는 HTTP 서버로 동작합니다.
• Stateless는 서버가 클라이언트의 과거 요청 정보를 저장하지 않는다는 의미입니다.

  Non-persistent HTTP의 특징 및 문제점
  - TCP 커넥션을 통해 여러 커넥션을 전송 가능
  - RTT(Round Trip Time)가 각 오브젝트 요청마다 2번씩 발생

HTTP 헤더와 메서드

• HTTP 요청 시 "GET"이라는 메서드와 함께 URL 및 프로토콜 버전 정보가 전송됩니다.
• POST 메서드를 사용하여 웹사이트에서 유저가 입력한 데이터를 서버로 전송할 때, 메세지 body에 데이터가 포함됩니다.
• HEAD 메서드는 HTTP 응답의 헤더 정보만을 요청합니다.
• PUT 메서드는 서버에 저장된 데이터를 변경하는데 사용됩니다.

Stateful / Statetless

• stateful: 이전 행동을 기억하고 다음 행동을 결정
• statetless: 이전 행동을 기억하지 않고 행동을 결정

쿠키와 웹 캐시

• 쿠키를 사용하면 사용자 인증 및 세션 정보 관리가 가능
• 웹 캐시는 서버를 대체하여 클라이언트 요청을 처리하는 프록시 서버입니다.

웹 캐시의 장점

• 응답 속도 상향
• 트래픽 절약 가능

Head Of Line Blocking과 TCP 커넥션

• 큰 오브젝트가 먼저 전송되면 뒤따르는 작은 오브젝트의 전송이 지연될 수 있습니다.
• 이를 해결하기 위한 방법 중 하나는 클라이언트가 오브젝트의 우선순위를 정하는 것

전자우편

구성요소

• 유저 에이전트 : 이메일을 작성, 읽기, 관리 등을 수행하는 사용자의 소프트웨어 모듈
• 메일 서버: 사용자의 이메일 박스 관리, 전송, 수진
• SMTP(Simple Mail Transfer Protocol): 메일 서버 간에 메일을 전송하기 위한 프로토콜

SMTP 작동 과정

1. Greeting : 서버와 클라이언트 간의 연결 설정
2. SMTP Transfer Message : 클라이언트가 메일 데이터를 서버에 전송
3. SMATP Closing : 데이터 전송이 완료되면 연결 종료를 위한 컨밴드 리스펀스 형태의 인터렉션

SMTP 정의

• 이메일 메세지를 전송하기 위한 프로토콜로, RFC 5321에 정의되어 있습니다.
• RFC 5321은 SMTP를 정의하고 있으며, RFC 2822는 이메일 메세지의 문법을 정의합니다.

이메일의 구조

• Header : 이메일의 제목, 발신자, 수신자 들의 정보 포함
• Body : 실제 메세지의 내용

SMTP 역할

• 송신자 메일의 전송 및 저장. 메일을 수신자의 서버에 전달하고 저장
• 메일 액세스 프로토콜: 서버에서 메세지를 가져오는 것 (IMAP, POP)

메세지 수신 프로토콜 IMAP, POP

• IMAP: 이메일 메세지를 가져오고, 필요에 따라 삭제하거나 폴더에 저장하는 등의 관리 기능을 제공합니다.
• POP: 서버에서 이메일을 가져오는 기능만 제공. 가져오면 서버에서는 메일이 삭제됩니다.

DNS(Domain Name System)

DNS

• 분산 데이터베이스 시스템
• 어플리케이션 레이어 프로토콜
• 이름을 통해 IP주소를 조회
• 로드 밸런싱 역할

DNS 서비스 특징

• 성능이 중요: DNS는 인터넷의 핵심 부분이므로 서비스 중단 시 많은 애플리케이션이 작동하지 않음
• 분산된 서비스로 구성: 트래픽 부하와 중앙 집중식 구조의 취약점을 해결하기 위한 특징
  - 각 도메인을 관리하는 조직은 자신의 도메인에 대한 DNS 레코드를 직접 관리하게 됩니다. 이를 통해 중앙 관리 방식보다 훨씬 효율적으로 업데이트 및 유지 보수가 가능합니다.
  • 지역적 적용을 통해 국가, 지역 단위로 다른 정보를 제공할 수 있습니다.

DNS 서버 역할

• 실제 데이터를 관리하고 업데이트
• 루트, 탑 레벨(TLD), 2차 레벨 등의 계층 구조를 가짐

계층 구조

1. Root Level

• DNS 최상위 계층입니다.
• 전 세계에 13개의 클러스터로 존재하고 이 서버들은 TLD(Top Level Domain) 서버들에 대한 정보를 알고 있습니다.

2. TLD(Top Level Domains)

• .com, org, .net, .edu 와 국가 코드 (TLDs) 같은 .uk, .kr 등을 포함압니다.

3. Second-level Domains:

• TLD 바로 아래의 도메인을 의미합니다. (ex.google.com의 google)
• 일반적으로 조직이나 회사의 이름을 나타냅니다.

4. Subdomains:

• Second-level domain 아래의 추가적인 구조입니다.(ex.mail.google.com에서 mail 부분)
• Second-level domain 아래에 여러 서브도메인이 생성될 수 있습니다.

5. Host

• 도메인 구조 상 가장 낮은 레벨이고 엔드포인트의 IP 주소와 직접 연결됩니다.

아이칸(ICANN)의 역할

• 루트 도메인 서버를 관리
• 전세계의 중요한 13개의 루트 네임 서버를 동기화 및 관리
• 인터넷 프로토콜과 연관된 파리미터와 숫자 할당을 관리합니다.

Iterated Query 방법

1. 클라이언트 요청

• 사용자의 컴퓨터나 애플리케이션은 특정 도메인 이름의 IP 주소를 알아내기 위해 로컬 DNS 서버에 요청을 합니다.

2. 로컬DNS 서버의 처리

• 로컬 DNS 서버는 먼저 자신의 캐시에서 정보를 확인
• 캐시에 없다면 로컬DNS 서버가 루트DNS 서버에 해당 도메인 IP 요청

3. 루트 서버 응답

• 루트 서버는 특정 도메인의 IP를 알지는 못하지만 해당 도메인을 관리하는 TLD 서버의 주소를 알려줌

4. TLD 서버의 응답

• 로컬 DNS 서버가 TLD 서버에 도메인의 IP 주소 요청
• TLD 서버도 특정 도메인 IP를 알지는 못하지만 해당 도메인을 관리하는 Authoritative DNS 서버 주소를 알려줌

5. Authoritative DNS 서버 응답

• 로컬 DNS 서버가 Authoritative DNS 서버에 도메인 IP 주소 요청 후 응답을 받음

6. 클라이언트에게 응답

• 로컬 DNS 서버가 클라이언트에게 해당 IP를 전달

DNS 서버의 한계

• TTL 값의 제한으로 인해 최신정보를 가진 것은 아닐 수 있습니다.
• DNS 정보의 정확성을 100% 보장하지 않습니다.

리소스 레코드

• DNS 데이터베이스에 지정된 항목
• 타입 A 레코드는 호스트 이름을 IP 주소와 매핑

DNS 보안

• DNS 중요한 정보를 제공하므로 보안이 상당히 중요합니다.
• DNS 쿼리의 위변조를 방지하기 위한 매커니즘이 필요

애플리케이션 레이어 P2P

P2P(Peer-to-Peer) 아키텍쳐 특징

• 클라이언트 서버와 달리 p2p 아키텍쳐에서는 임의의 노드들이 서로 직접 통신을 할 수 있는 특징을 가지고 있습니다.
• p2p 아키텍쳐는 self scalable 합니다.
• p2p 아키텍쳐는 관리 수준이 클라이언트-서버 구조에 비해 복잡합니다.

추가 내용

• 분산성:
  중앙 집중화된 서버에 의존하지 않고 모든 피어가 리소스와 콘텐츠를 공유하며 네트워크를 지원합니다.
• 자기 조직화:
  피어들은 동적으로 네트워크에 참여하거나 나갈 수 있습니다. 이런 변화에 자동으로 적응하여 리소스를 조절하고 재구성합니다.
• 동등성:
  모든 피어는 네트워크 내에서 동등한 역할을 합니다. 특정 피어의 우선순위가 없습니다.
• 확장성:
  새로운 피어가 네트워크에 추가될 때마다 네트워크의 총 리소스와 용량이 증가합니다. 많은 수의 사용자를 쉽게 처리할 수 있습니다.
• 내성:
  중앙 서버가 없기 때문에 특정 노드의 실패에 큰 영향이 없습니다.

File Distribution

• 네트워크의 모든 피어들 간에 파일 및 데이터를 직접 공유하는 방식입니다.

특징

1. 효율적인 대역폭 활용
   파일을 다운로드 할 때 여러 피어로부터 동시에 다양한 파일 조각을 받을 수 있습니다. 이로 인해 사용 가능한 대역폭이 최대한 활용되고 다운로드 속도가 빨라집니다.
2. 내성
   한 피어가 중단되거나 네트워크에서 떠나도 다른 피어들로부터 해당 파일의 조각을 계속 다운로드 받을 수 있습니다.
3. 확장성
   파일을 요청하는 사용자 수가 늘어나도 각 사용자가 파일의 일부를 이미 다운로드 받았다면 그들 또한 파일의 소스가 될 수 있기 때문에 네트워크의 부하는 크게 증가하지 않습니다.
4. 동적 어댑테이션
   피어들이 동적으로 네트워크에 참여하거나 떠날 수 있습니다.파일 배포에 유연한 대응이 가능합니다.
5. 리소스 공유
   각 피어는 자신의 저장 공간, 처리 능력, 대역폭을 네트워크와 공유하게 되어 중앙 서버의 부담이 크게 감소합니다.
6. 비용 절감
   전통적인 파일 배포 방식에서는 고성능의 중앙 서버 및 대량의 대역폭이 필요하지만 p2p 방식에서는 이런 비용이 크게 감소됩니다.

인덱스

P2P 시스템에서 사용자들은 직접 파일을 공유합니다. 이 때, 특정 파일이나 리소스가 어디에 위치하고 있는지, 어느 피어가 그 리소스를 가지고 있는지 알아야 합니다. 이러한 정보를 제공하는 것이 인덱스입니다.

인덱스
파일의 위치를 가리키는 포인터나 레퍼런스

임의적인 피어 선택

P2P 네트워크에서는 항상 최고의 성능을 가진 피어(전송속도가 가장 높은) 피어를 선택하는게 아니라 랜덤한 피어를 선택하기도 합니다.

• 네트워크 부하 분산
• 모든 피어가 활성화되어 참여 가능
• 시스템의 견고성, 확장성 향상

청크 전송

• 청크: 큰 데이터나 파일을 관리하기 쉬운 작은 조각으로 나눈 단위
• 청크를 전송하는 방식으로 동시에 여러 청크를 받아 파일 전송 속도를 높일 수 있습니다.
• 선택된 피어는 해당 청크를요청하는 피어에게 청크를 전송합니다.

인덱스와 위치 공유

사용자가 p2p 시스템에 참여하거나 인스턴스 메시징 애플리케이션과 같은 특정 p2p 애플리케이션을 실행하면 해당 사용자의 위치나 상태 정보가 인덱스로 변환되어 다른 피어들에게 공유됩니다.

중앙 집중형 디렉토리 서비스 방식

중앙 집중형 디렉토리 방식은 파일 공유 시스템 구조 중 하나입니다. 중앙 서버나 특정 노드가 모든 파일의 위치 정보나 메타데이터를 관리하게 됩니다.

법률적 문제

중앙 집중형 구조는 불법적인 내용이나 저작권을 침해하는 파일의 공유가 일어날 때, 중앙 서버나 디렉토리가 법적 책임을 질 수 있다는 문제가 있습니다.

쿼리 플러딩 방법

쿼리 플러딩 방법은 중앙 서버의 개념을 완전히 배제한 완전 분산형 파일 공유 방식입니다.

플러딩: 사용자가 파일을 검색/요청 할 때, 해당 쿼리를 네트워크의 모든 노드에게 전송.

-> 각 노드는 받은 쿼리를 처리하여 결과를 사용자에게 반환

이 방법은 한 지점에서의 실패가 전체 시스템의 작동에 큰 영향을 미치지 않고 법적 책임도 분산됩니다.
하지만 당연히 네트워크 트래픽이 많이 발생하게 되므로 효율성이 떨어집니다.

소켓 프로그래밍

소켓 프로그래밍의 목적

• 소켓 프로그래밍은 네트워크 상에서 두 컴퓨터 간의 통신을 가능하게 하는 프로그래밍 방식입니다.
• 클라이언트와 서버 사이에 데이터/메세지를 실기간으로 주고받을 수 있는 통신 메커니즘을 제공하는 것
• 웹 브라우징, 이메일, 파일 전송 등 모두 소켓 프로그래밍의 원리를 기반으로 작동합니다.
• 클라이언트-서버 패러다임을 기반으로 합니다. 클라이언트와 서버 사이에 소켓 연결이 성립되면 양 쪽 모두 데이터를 전송하거나 수신할 수 있습니다.

소켓의 개념

• 애플리케이션 프로세스 간 통신 메커니즘을 제공하는 인터페이스

소켓API와 TCP엔진

• 애플리케이션 프로세스는 OS가 제공하는 TCP 엔진을 활용하기 위해 소켓API or 소켓 인터페이스를 사용합니다.
• 소켓 API:
  애플리케이션 개발자가 네트워크와의 상호 작용을 위한 함수나 메서드 집합을 제공. 이를 통해 데이터를 송수신하는 네트워킹 작업이 가능합니다.
  • socket(), bind(), listen(), accept() 등의 함수
• 소켓 인터페이스:
  애플리케이션 프로세스와 OS의 네트워크 스택 간의 연결 또는 인터페이스를 의미합니다. 소켓API가 실제 함수, 메서드의 집합을 의미하는 반면에 소켓 인터페이스는 통신 애플리케이션과 OS간의 통신 연결을 나타내는 개념입니다.
  • 소켓API, 소켓 인터페이스가 혼용되어 사용되는 경우도 종종 있습니다.

서버 소켓 프로그래밍

1. 서버 프로세스 시작

• 서버 프로세스는 클라이언트의 접속 요청을 받을 준비를 먼저 해야합니다.

2. 웰컵 소켓 생성

• 서버는 클라이언트의 접속 요청을 수락할 수 있는 소켓인 '웰컴 소켓'을 생성합니다.
• 클라이언트의 초기 접속 요청을 수신하는 역할을 합니다.

3. 클라이언트의 접속 시도

• 클라이언트는 서버에 접속을 시도합니다.

4. TCP 커넥션 생성

• 클라이언트의 TCP는 서버의 TCP와 연결을 형성합니다.

5. 통신용 소켓 생성

• 연결 성립 후, 서버는 실제 데이터 통신을 위해 새로운 소켓을 생성합니다.
• 서버는 웰컴 소켓, 커넥션 소켓 2개의 소켓을 가지게 됩니다.
• 웰컴 소켓은 계속해서 새로운 클라이언트의 접속 요청을 대기하고 통신용 소켓은 클라이언트와의 데이터 통신을 처리합니다.

클라이언트 소켓 프로그래밍

1. 클라이언트 소켓 생성

• 클라이언트는 서버와의 통신을 위해 소켓을 생성합니다.
• 이 소켓은 서버와 데이터를 주고받을 수 있는 엔드포인트입니다.

2. TCP 연결

• 서버의 웰컴 소켓과 TCP 핸드쉐이킹을 통해 서버 통신 가능한 환경을 구성합니다.

3. 데이터의 송수신

• 핸드쉐이킹 이후 서버의 커넥션 소켓을 통해 송수신을 합니다

서버 소켓

• 서버 소켓은 서버가 클라이언트의 연결 요청을 기다리는 역할을 하는 소켓입니다.
• 서버가 시작되면 해당 서버의 IP 주소와 포트 번호에 바인드되는 서버 소켓을 생성합니다.
• TCP를 사용하는 경우에는 연결 절차가 필요하지만 UDP를 사용하는 경우에는 연결 설정 없이 바로 데이터를 주고받을 수 있습니다.

Transport Layer

Transport Layer

목적

• end-to-end 통신 서비스를 제공합니다. 즉, 특정 호스트의 한 프로세스에서 다른 호스트의 특정 프로세스로 데이터를 안전하게 전송하는 역할을 합니다.

기능

• 세션 관리:
  트랜스포트 계층은 두 프로세스 간의 세션을 설정, 유지, 종료합니다.
• 흐름 제어:
  데이터의 전송 속도나 순서를 관리하여 통신이 원활하게 이뤄지도록 합니다.
• 오류 제어:
  전송된 데이터의 오류를 검출하고 필요한 경우 재전송합니다.
• 다중화:
  여러 응용 프로그램이 네트워크 서비스를 동시에 사용할 수 있게 합니다.

Network Layer

목적

• 데이터 패킷을 출발지 호스트에서 목적지 호스트로 전송하는 것
• 전송 경로나 중간에 위치하는 라우터를 통한 전송을 관리

기능

• 라우팅:
  데이터 패킷을 목적지까지 가장 효율적인 경로로 전송합니다.
• 주소 지정:
  각 호스트와 라우터에 IP주소를 할당하여 통신이 가능하게 합니다.
• 패킷 분할 및 조립:
  큰 데이터를 여러 패킷으로 분할하여 전송하고 목적지에서 이를 다시 조립합니다.

TCP (Transmission Control Protocol) 특징

• Reliable:
  • 데이터 전송의 신뢰성을 보장합니다.
  • 패킷이 손실, 중복, 오류가 발생하면 재전송을 통해 복구합니다.
• In-Ordered Delevery:
  • 데이터 패킷을 순서대로 전송하며, 수신측에서는 도착한 패킷의 순서를 확인하여 원래의 순서대로 재배열합니다.
• 혼잡 제어 및 흐름 제어:
  • 네트워크의 혼잡 상황을 감지하고 혼잡을 피하기 위해 데이터 전송 속도를 조정합니다.
  • 수신자의 처리 능력에 맞게 데이터의 전송 속도를 조절하는 흐름 제어 기능도 제공합니다.
• 커넥션 셋업:
  • 송신자와 수신자 간에 연결 설정 과정을 거치는 연결 지향적인 프로토콜입니다.
• 딜레이 보장 없음:
  • 데이터의 순서나 신뢰성을 보장하지만 특정 딜레이에 대한 보장은 제공하지 않습니다.

UDP(User Datagram Protocol) 특징

• Unreliable:
  • 데이터 전송의 신뢰성을 보장하지 않습니다.
  • 데이터 패킷의 손실이나 오류에 대해 복구하지 않습니다.
• Unordered Delivery:
  • 데이터 패킷의 순서를 보장하지 않습니다.순서대로 도착하지 않을 수 있습니다.

애플리케이션 멀티플렉싱

• 여러 애플리케이션 혹은 프로세스가 하나의 통신 리소스를 공유하도록 해주는 기법
• 효율적인 네트워크 리소스 사용과 고성능 통신이 가능

주요 개념

• 다중 애플리케이션 공유:
  하나의 서버에서 여러 애플리케이션/서비스가 동시에 실행될 때, 이러한 각 애플리케이션들은 서로 다른 포트 번호를 사용하여 네트워크 연결을 수립하고 통신할 수 있습니다.
• 포트 번호와 소켓:
  애플리케이션들은 각기 다른 포트 번호를 통해 통신하게 됩니다.특정 애플리케이션을 식별하는데 사용됩니다.
• 데이터의 분리 및 결합:
  멀티플렉싱을 통해 서버는 여러 애플리케이션으로 분리하여 데이터를 전달합니다.
• Transport Layer 역할:
  네트워크 계층의 일부인 Transport 계층은 애플리케이션 멀티플렉싱 역할을 가지고 있습니다.

UDP 소켓 통신

UDP 소켓

• UDP는 연결을 설정하지 않고 데이터를 전송하므로 연결 과정이 없습니다.

Source/Destination Port Number

• 송신/수신 측의 포트번호입니다. 별도의 설정이 없다면 OS에서 임시 포트 번호를 자동으로 할당합니다.
• 임시 포트를 'ephemeral port'라고도 합니다

Datagram

• UDP에서의 패킷을 데이터그램이라 부릅니다.
• 목적지 IP와 포트번호, 소스의 IP와 포트 번호 등을 포함하고 있습니다.

UDP

UDP

• 'User Datagram Protocol'의 약자로, 인터넷 프로토콜 중 하나입니다.
• UDP는 IP프로토콜에 추가적인 기능을 거의 포함하지 않습니다. 복잡한 기능이 없는 간단한 프로토콜입니다.
• Best-Effort Protocol: '최선을 다해 보내지만 성공을 보장하지 않는다'는 의미로 사용됩니다. 데이터 전송을 보장하지 않기 때문에 손실이 날 수 있는 상황을 표현합니다.
• TCP에 비해 성능 저하가 없으며 혼자한 상황에서도 프로토콜 작업에 집중합니다.

장점

• 데이터 손실에 내성이 있고 빠른 전송이 필요한 작업에 매우 유리합니다.
• 주로 스트리밍 멀티미디어 애플리케이션에 사용됩니다.

특징

• 데이터 손실:
  UDP는 데이터 손실에 크게 신경쓰지 않기 떄문에 데이터 손실이 허용되는 애플리케이션에 사용됩니다.
  • DNS, SNMP 등 서비스
• 연결 설정 불필요:
  TCP의 핸드쉐이킹 과정같은 설정이 없습니다. 이로 인해 연결 설정에 의한 지연 시간을 줄일 수 있습니다.
• 간단한 프로토콜:
  IP계층에 특별한 기능을 추가하지 않기에 세그먼트가 잃어버려질 수 있고 순서가 바뀔 수 있습니다.

헤더 구조:

• Source Port (16 bits):
  • 이 필드는 메시지를 송신하는 프로세스의 포트 번호를 나타냅니다.
  • 애플리케이션은 이 포트 번호를 사용하여 송신자를 식별하게 됩니다.
• Destination Port (16 bits):
  • 이 필드는 메시지를 수신할 프로세스의 포트 번호를 나타냅니다.
  • 대상 애플리케이션에 메시지를 올바르게 전달하기 위해 사용됩니다.
• Length (16 bits):
  • UDP 헤더 및 데이터의 전체 길이를 바이트 단위로 나타냅니다.
  • 이 필드는 헤더의 길이 (8 바이트)와 실제 데이터의 길이를 합한 값입니다.
• Checksum (16 bits):
  • UDP 헤더와 데이터의 무결성을 확인하기 위해 사용되는 값입니다.
  • 송신 시에는 UDP 헤더와 데이터를 기반으로 계산된 값을 이 필드에 삽입하며, 수신 시에는 이 값을 사용하여 데이터의 무결성을 검사합니다.
  • 페이로드 데이터와 헤더, 그리고 가상 헤더 (발신자와 수신자의 IP 주소, 프로토콜 값, UDP 길이 등을 포함하는 헤더)를 사용하여 계산됩니다.
  • 체크섬은 선택 사항이며, 0으로 설정될 수도 있습니다. 이 경우, 수신 측은 체크섬 검증을 수행하지 않습니다.

RDT(Reliable Data Transfer)

RDT Protocol

• Transport 계층에서 동작.
• 신뢰적인 서비스를 제공하기 위해 디자인됨.
• Unreliable Network Layer 위에서도 안정적인 데이터 전송을 보장.

RDT 원리

• 안전하고 신뢰성있게 데이터를 전송하는 원리
• sending 프로세스와 receiving 프로세스 사이에서 이뤄집니다.
• 두 프로세스는 직접 연결되지 않고 네트워크를 통해 연결됩니다.

프로토콜 동작

• rdt_send: 애플리케이션 레이어에서 트랜스포트 레이어로 데이터를 보냅니다.
• udt_send: 트랜스포트 레이어에서 네트워크 레이어로 데이터를 보냅니다.
• rdt_receive: 수신된 데이터를 트랜스포트 레이어에서 애플리케이션 레이어로 전달합니다.
• sender와 receiver는 서로의 상태를 직접 알 수 없으므로, 메시지 교환을 통해 상태를 확인합니다.

프로토콜의 복잡성

• 네트워크 채널의 특성에 따라 데이터 전송의 복잡성이 달라질 수 있습니다.
  • 예를 들면 데이터가 손실되거나, 오류가 발생하거나, 순서가 바뀔 경우의 처리가 필요합니다.

패킷의 에러 찾는법

1.UDT(Unreliable Data Transfer) Send

• 패킷이 생성되면 udt의 send 기능을 사용하여 패킷을 전송

  UDT
  기본적인 데이터 전송을 담당하며 RDT 매커니즘의 일부입니다.

2. Deliver Data

• 패킷에서 원본 데이터만 추출하며, 이 데이터는 애플리케이션에서 원래 보냈던 데이터입니다.

3. 네트워크 상황

• 네트워크에서 비트 에러나 패킷 손실이 발생하지 않았다면 수정 필요X

• checksum을 이용하여 비트 에러 감지

  CheckSum
  데이터의 각 비트를 더하거나 다른 방법으로 하나의 값을 생성하여 원본데이터에 포함시키는 값으로, 수신자가 수신받은 데이터의 checksum을 계산하여 동일한지 확인하는 방법

  • 단, 단순히 전체 값을 더하기 때문에 순서 오류나 그 이상의 복잡한 에러는 감지하기가 힘듭니다.

  비트 에러
  말 그대로 비트 값 0, 1이 원래 값과 반대로 되는 에러입니다.

4. Acknowledgement

• Checksum을 통해 에러가 확인되면 'Acknowledgement'를 보내어 에러 발생을 알립니다.

RDT 2.0

udt send와 underliable channel

• rdt 2.0 에서는 데이터가 'udt sned'라는 함수를 통해 underliable 채널을 통해 전송됩니다.

Acknowledgement(ACK) 대기 상태

• 데이터를 전송한 후 송신자는 수신자로부터 응답을 기다리게 됩니다. 응답은 ACK 또는 NACK (Negative ACK) 상태로 오게 됩니다.

응답 대기

• 송신자는 ACK(or NACK) 메세지가 올 때 까지 대기 상태로 남아있습니다.

리시버의 동작

• 수신자 측에서는 데이터를 정상적으로 수신하면 해당 데이터를 상위 계층의 애플리케이션에 전달하게 됩니다. 이후 수신 성공 여부에 따라 ACK 또는 NACK를 반환하게 됩니다.
  NACK를 전송하게 되면 송신자에게 데이터 재전송을 요청하게 됩니다.

rdt 2.1

rdt 2.1 ACK 처리

• 2.0 버전에서는 ACK, NACK 중복, 손실 문제가 있었습니다.
• 이로 인해 패킷을 중복으로 받을 때 처리방식에 대한 문제가 생겼습니다.
• rdt2.1에서는 이런 문제를 해결하기 위해 'garbled ACK' 처리방식을 도입합니다.

udt send data

• 2.1버전에서는 데이터 전송 요청을 받으면 패킷을 생성합니다.
• chacksum만 포함되었던 이전 버전과 달리 순서 번호도 포함됩니다.
• 이 패킷을 udt send를 통해 네트워크 레이어로 전송합니다.

ACK(or NACK) 대기

• 수신자는 받은 데이터 패킷을 검사하고 checksum을 포함한 ACK 패킷을 생성하여 송신자에게 전송합니다.
• 데이터 패킷의 순서 번호를 기반으로 다음 패킷을 대기합니다.
• 패킷 에러가 발생하며 NACK 메세지를 전송합니다.
• 순서가 맞지 않는 패킷이 도착하여 해당 패킷에 대한 ACK는 전송하지만 패킷 순서 번호는 대기 상태를 유지합니다.

RDT 3.0

• 손상되지 않은 채널과 패킷이 손실될 수 있는 채널에 대응할 수 있습니다.
• 타임아웃 매커니즘이 도입되어 ACK/NACK가 일정 시간 내에 도착하지 않으면 패킷을 재전송합니다.

송신자 동작

• 애플리케이션에서 데이터를 받아 패킷을 생성하고 UDT로 전송합니다.
• 전송 후 타이머를 시작하여 ACK/NACK를 기다립니다.
• ACK가 도착하면 타이머를 정지하고 다음 패킷을 전송합니다.
• NACK나 타임아웃이 발생하면 패킷을 재전송하고 타이머를 다시 시작합니다.

수신자 동작

• 패킷을 UDT로부터 수신합니다.
• 패킷 손상이 없고 올바른 순서라면 애플리케이션에 데이터를 전달하고 ACK를 전송합니다.
• 손상 또는 잘못된 순서를 수신하면 NACK를 전송합니다.

문제점

• 네트워크 상황에 따라 불필요한 재전송이 발생할 수 있습니다.
• 타이머 설정에 따라 성능이 크게 영향을 받습니다.

파이프라이닝

• rdt3.0 버전에서는 패킷을 하나씩 전송하고 기다리는 방식이라 rtt가 자주 발생하여 시간이 오래 걸립니다.
• 파이프라이닝은 패킷을 연속적으로 전송하고 패킷들의 응답(ACK/NACK)을 동시에 기다립니다.

장점

• 대역폭 활용: 여러 패킷을 전송함으로써 대역폭을 효율적으로 활용합니다.
• 지연 시간 최소화: 여러 패킷의 응답을 동시에 기다리기 때문에 한 패킷의 지연시간에 의존하지 않습니다.

문제점 및 도전 과제

• 복잡한 오류 관리:
  여러 패킷을 동시에 관리해야 하기 때문에 손실이나 손상에 대한 처리가 복잡해질 수 있습니다.
• 버퍼 관리:
  수신측에서 올바른 순서로 패킷을 재구성하기 위한 버퍼 관리가 필요합니다. 순서 보장이 없기에 재구성 로직이 필요합니다.
• 타임아웃 관리:
  여러 패킷의 응답을 동시에 기다리는 동안, 어떤 패킷의 타임아웃을 어떻게 관리할지 결정해야 합니다.

Go-Back N(GBN) Protocol

• 여러 패킷을 연속적으로 전송하고 첫 번째 손실된 패킷부터 모든 패킷을 재전송하는 방식입니다.
• 구현이 간단하지만 네트워크 효율성이 떨어집니다.

Selcective Repeat(SR) Protocol

• 손실된 패킷만 재전송합니다.
• 수신자는 각 패킷의 상태를 개별적으로 관리하며, 송신자는 각 패킷에 대한 ACK를 개별적으로 기다립니다.
• 네트워크 효율성은 높지만 구현이 복잡합니다.