Transport Layer: overview

our goal

• transport layer의 service들의 principle을 이해하는 것
  1. multiplexing, demultiplexing
  2. reliable data transfer
  3. flow control
  4. congesion control
• internet transport layer protocol를 배우기
  1. UDP: 비연결 전송
  2. TCP: 연결지향, 신뢰성있는 전송
  3. TCP congestion control

Transport Layer: roadmap

1. Transport-layer service
2. multiplexing and demultiplexing
3. connectionless trasnport : UDP
4. principles of reliable data transfer
5. connection-oriented trasport : TCP
6. Principle of congestion control
7. TCP congestion control
8. Evolution of Transport-layer functionality

Transport services and protocols

1. Logical Communication
   • 전송 계층은 서로 다른 호스트에서 실행되는 어플리케이션 프로세스 간의 논리적 통신(logical communication)을 제공한다.
   • e.g. 모바일 네트워크, 홈 네트워크, 기업 네트워크, 지역 ISP, 국가 또는 글로벌 ISP, 데이터 센터 네트워크, 컨텐츠 제공자 네트워크 등을 포함한다.

2. Transport Protocol Actions in End Systems
   • 송신 측(sender)
     • 어플리케이션 메시지를 새그먼트(segment) 로 분할하고 이를 네트워크 계층으로 전달한다.
   • 수신 측(receiver)
     • segment를 재조립하여 메시지를 만들고 이를 어플리케이션 계층으로 전달한다.

3. Available Trasnport Protocols
   • 인터넷 어플리케이션에 사용 가능한 두 가지 전송 프로토콜은 TCP와 UDP이다.
   • TCP(Trasnport Control Protocol)
     • 연결 지향적이고 신뢰성 있는 전송을 제공
   • UDP(Transport Datagram Protocol)
     • 비연결형 전송을 제공, 신뢰성은 낮음

Trasnport vs Network Layer Services and Protocols

• household 비유
  • Ann의 house의 12명의 애들이 Bill의 house의 12명의 애들에게 편지를 쓰려고 한다.
    • hosts = houses
    • process = kids
    • app message = letters in envelopes

• Network Layer: host 간의 데이터 전송을 책임진다.

• Transport Layer: process 사이의 데이터 전송을 관리하고 제어한다.

Transport Layer Actions

송신자(Sender)

1. application layer의 message를 전달받음
   • 송신자는 응용 계층에서 메시지를 전달 받는다.

2. segment header의 field 값을 결정
   • 메시지를 세그먼트로 분할할 때 세그먼트 헤더에 들어갈 값을 결정한다. 이는 각 세그먼트를 올바르게 전달하고 재조립하기 위해 필요하다.

3. segment를 생성
   • application meesage를 segment로 만든다. segment는 데이터와 segment 헤더로 구성된다.

4. segment를 IP 계층으로 전달
   • 생성된 segment를 네트워크 계층(IP)으로 전달하여 실제 네트워크를 통해 전송된다.

Transport Layer Actions

수신자(Receiver)

1. segment를 IP로 부터 받음
   • 수신자는 network layer(IP)으로부터 segment를 전달받는다.

2. 헤더 값을 확인(checks header value)
   • 세그먼트의 헤더 값을 확인하여 데이터의 무결성을 검증하고, 세그먼트가 올바르게 도착했는지 확인

3. 어플리케이션 계층 메시지를 추출(extract application-layer message)
   • 세그먼트에서 application-layer message를 추출한다. 즉, 데이터 부분을 꺼낸다.

4. socket을 통해 application으로 메시지를 전달(demultiplexes message up to application via socket)
   • 소켓을 통해 추출된 메시지를 어플리케이션 계층으로 전달. 이 과정은 여러 어플리케이션 프로세스가 하나의 네트워크 연결을 공유할 때, 각 메시지를 올바른 프로세스에 전달하기 위해 수행

Two Principle Internet Transport Protocols

1. TCP(Transmission Control Protocol)
   • Reliable, in-order delivery(신뢰할 수 있는 순서대로의 전달)
     • 데이터를 신뢰성 있게, 순서대로 전달한다.
   • Congestion control(혼잡 제어)
     • 네트워크 혼잡을 방지하기 위해 데이터 전송 속도를 조절한다
   • Flow Control(흐름 제어)
     • 송신자와 수신자 간의 데이터 전송 속도를 조절하여 수신자가 과부하되지 않도록 한다.
   • Connection Setup(연결 설정)
     • 데이터를 전송하기 전에 송신자와 수신자 간에 연결을 설정한다.

2. UDP(User Datagram Protocol)
   • Unreliable, unordered delivery(신뢰할 수 없는, 순서가 없는 전달)
     • 데이터를 신뢰성 없이, 순서에 상관없이 전달
   • No-frills extension of "best-effort" IP("최선 노력" IP의 단순한 확장)
     • IP 프로토콜의 "최선 노력" 서비스를 그대로 사용하며 추가적인 기능이 없다.

3. Services not available(제공되지 않는 서비스)
   • Delay guarantees(지연 보상)
     • 전송 지연을 보장하지 않는다.
   • Bandwidth guarantees(대역폭 보장)
     • 대역폭을 보장하지 않는다.

Multiplexing and demultiplexing

• 클라이언트
  • 여러 어플리케이션(e.g. Skype, Netflix, Firefox)이 실행되고 있다.
  • 전송 계층에서 응용 계층으로 HTTP 메시지가 전달된다.

• HTTP 서버
  • Apache HTTP 서버가 실행 중이다.
  • 서버는 HTTP 메시지를 송신하고 있다.

• 네트워크
  • 클라이언트와 서버 간의 네트워크 연결을 통해 데이터가 전달된다.

• HTTP 서버
  • 서버는 네트워크 계층을 통해 전달된 HTTP 메시지를 송선힌다.
  • 메시지는 전송 계층으로 전달되어 header를 포함한 HTTP 메시지가 된다.

• HTTP 서버
  • 전송 계층에서 네트워크 계층으로 전달될 때 H_n가 추가된다.

• 네트워크: 클라이언트와 서버 간의 네트워크 연결을 통해 데이터가 전달된다.

• 다수의 클라이언트
  • 두 개의 클라이언트(client1, client2)가 서버에 연결되어 있다.
  • 각 클라이언트는 어플리케이션 계층을 통해 HTTP 메시지를 서버로 전송한다.

Multiplexing/demultiplexing

1. Multiplexing at Sender(송신 측 다중화)

   1. 여러 소켓에서 데이터 처리(handle data from multiple sockets)

      • 송신 측에서는 여러 어플리케이션 프로세스에서 전송되는 데이터를 처리한다.
      • 각 프로세스는 독립적인 소켓을 통해 데이터를 전송한다.

      
      
      

   2. transport 헤더 추가(add trasnport header)

      • 각 소켓에서 온 데이터에 전송 헤더를 추가한다.
      • 이 헤더 정보는 나중에 demultiplexing 과정에서 사용된다.

      
      
      

   3. 과정 요약

      • 송신 측 다중화는 여러 소켓으로부터 데이터를 수집하고, 각 데이터에 전송 헤더를 추가하여 하나의 네트워크 스트림을 결합한다.

      
      
      
      
      
      

2. Demultiplexing at Receiver(수신 측 역다중화)

   1. 헤더 정보 사용(use header info)

      • 수신 측에서는 각 세그먼트의 헤더 정보를 사용하여 데이터의 출처를 식별한다.

      
      
      

   2. 올바른 소켓으로 세그먼트 전달(deliver received segments to correct socket)

      • 헤더 정보를 기반으로 각 세그먼트를 올바른 소켓으로 전달한다.
      • 각 소켓은 해당 소켓에 연결된 어플리케이션 프로세스로 데이터를 전달한다.

      
      
      

   3. 과정 요약:

      • 수신 측 역다중화는 수신된 데이터 세그먼트의 헤더 정보를 분석하여 이를 올바른 소켓으로 전달한다. 이를 통해 데이터를 원래의 어플리케이션 프로세스로 정확하게 전달할 수 있다.

• 네트워크 계층 모델
  • 클라이언트
    • 여러 어플리케이션 프로세스(P1, P3)에서 데이터를 전송한다.
    • 전송 계층에서 각 데이터에 헤더를 추가하고 네트워크 계층으로 보낸다.
  • 서버
    • 네트워크 계층을 통해 수신된 데이터를 전송 계층에서 처리한다.
    • 전송 계층 헤더를 분석하여 각 데이터 세그먼트를 올바른 어플리케이션 프로세스(P2, P4)로 전달한다.

How demultiplexing works

• 네트워크 계층의 패킷을 "데이터그램"
• 전송 계층의 패킷을 "세그먼트"

1. 호스트가 IP 데이터그램을 수신(host receives IP datagram)
   • 호스트는 네트워크를 통해 IP 데이터그램을 수신한다.
   • 각 데이터그램(네트워크)에는 출발지 IP 주소와 목적지 IP 주소가 포함되어 있다.
   • 각 데이터그램은 하나의 전송 계층 세그먼트를 포함한다.
   • 각 세그먼트(전송)에는 출발지 포트 번호와 목적지 포트 번호가 포함되어 있다.

2. IP 주소 및 포트 번호 사용(uses IP address & port numbers)
   • 호스트는 수신한 세그먼트(전송 계층)를 적절한 소켓으로 전달하기 위해 IP주소와 포트 번호를 사용한다.
   • 이 정보를 바탕으로 세그먼트를 올바른 어플리케이션 프로세스로 전달한다.

TCP/UDP 세그먼트 포맷

• Source port # (출발지 포트 번호)
  • 세그먼트가 발송된 출발지 포트를 나타냄
  • 32비트 크기
• Destination port # (목적지 포트 번호)
  • 세그먼트가 도착해야 할 목적지 포트를 나타냄
  • 32비트 크기
• Other header fields(기타 헤더 필드)
  • 세그먼트의 다른 헤더 정보를 포함
• Application data(어플리케이션 데이터, payload)
  • 실제로 전달되는 데이터
  • 어플리케이션 계층에서 보내는 payload이다.

Connectionless demultiplexing

Connectionless Demultiplexing(비연결형 역다중화)

• 소켓 생성 시(When creating socket)
  • 호스트 로컬 포트 번호 지정(specify host-local port #)
    • 소켓을 생성할 때 호스트 로컬 포트 번호를 지정해야 한다.
    • 예제 코드: 'DatagramSocket mySocket1 = new DatagramSocket(12534);'

• UDP 소켓에 데이터그램 전송 시(When Creating Datagram to send into UDP socket)
  • 목적지 IP 주소 지정(specify destination IP address)
    • 데이터를 전송할 목적지 IP 주소를 지정해야 한다.
  • 목적지 포트 번호 지정(specify destination port #)
    • 데이터를 전송할 목적지 포트 번호를 지정해야 한다.

• 수신 측에서의 처리(When receiving host receives UDP segment)
  • 세그먼트의 목적지 포트 번호 확인(checks destination port # in segment)
    • 수신 측에서는 세그먼트의 목적지 포트 번호를 확인한다.
  • 해당 포트 번호의 소켓으로 UDP 세그먼트 전달(directs UDP segment to socket with that port #)
    • 확인된 포트 번호를 기반으로 해당 소켓으로 UDP 세그먼트를 전달

• 추가 설명
  • 같은 목적지 포트 번호, 다른 출발지 IP 주소/포트 번호(IP/UDP datagrams with same dest, port #, but different source IP address and/or source port numbers)
    • 동일한 목적지 포트 번호를 가진 IP/UDP 데이터그램은 출발지 IP 주소나 출발지 포트번호가 다르더라도 수신 측에서는 동일한 소켓으로 전달된다.

Connectionless demultiplexing: an example

Connection-oriented demultiplexing

TCP 소켓 식별(TCP socket identified by 4-tuple)

1. 출발지 IP 주소(source IP address)
2. 출발지 포트 번호(source port number)
3. 목적지 IP 주소(destination IP address)
4. 목적지 포트 번호(destination port number)

역다중화 과정(demux: receiver uses all four values(4-tuple) to direct segment to appropriate socket)

• 수신자는 이 네 가지 값(4-tuple)을 사용하여 수신된 세그먼트를 적절한 소켓으로 전달한다.

서버에서의 다중 TCP 소켓 지원(server may support many simultaneous TCP sockets)

• 서버는 동시에 여러 TCP 소켓을 지원할 수 있다.
• 각 소켓은 고유한 4-tuple로 식별된다.
• 각 소켓은 서로 다른 클라이언트와의 연결에 대응한다.

Connection-oriented demultiplexing: example

서로 다른 소켓으로 전달: 동일 서버의 동일한 포트(80) 로 데이터가 전달되지만, 출발지 IP주소와 포트 번호가 다르기 때문에 각 세그먼트는 서로 다른 소켓으로 전달된다.

port number는 기본적으로 네트워크 통신에서 데이터가 어떤 어플리케이션으로 전달되어야 하는지를 식별하는 데 사용된다

그러나 실제로는 출발지 IP 주소와 출발지 포트 번호도 함께 고려하여 데이터를 적절한 소켓으로 라우팅한다. 이를 TCP/IP 프로토콜에서는 4-tuple이라고 부른다.

Summary

• Multiplexng, demultiplexing: datagram의 header field value와 segment 기반
• UDP: 오직 destination port number만을 사용해 demultiplexing
• TCP: 4-tuple을 사용해 demultiplexing한다.(source and destination IP address와 port number)
• Multiplexing, demultiplexing은 all layer에서 일어난다.

Connectionless transport: UDP

UDP: User Datagram Protocol

특성(Characteristics)

• "no frills", "bare bones" internet transport protocol
  • 추가 기능 없이 기본적인 인터넷 전송 프로토콜이다.
• 'best effort' server, UDP segments may be:
  • lost:
    • UDP 세그먼트는 손실될 수 있다.
  • delivered out-of-order to app
    • 세그먼트가 어플리케이션에 순서가 바뀌어 도착할 수 있다.
• connectionless
  • no handshaking between UDP sender, receiver
    • 송신자와 수신자 간의 핸드셰이킹(handshaking)이 없다.
  • each UDP segment handled independently of others
    • 각 UDP 세그먼트는 다른 세그먼트와 독립적으로 처리된다.
      
      

왜 UDP를 사용하는가?

• 장점(Advantages)
  • no connection establishment(which can add RTT delay)
    • 연걸 설정이 없으므로 RTT(Round-Trip Time) 지연이 추가되지 않는다.
  • simple: no connection state at sender, receiver
    • 송신자와 수신자에서 연결 상태를 유지하지 않기에 간단하다.
  • small header size:
    • 헤더 크기가 작다.
  • no congetion control
    • UDP는 원하는 만큼 빠르게 데이터를 전송할 수 있다.
    • 혼잡 상황에서도 동작할 수 있다.

UDP: User Datagram Protocol

UDP 사용 사례(UDP uses)

• Streaming multimedia apps(loss tolerant, rate sensitvie)
• DNS(Domain Name System)
• SNMP(Simple Network Management Protocol)
• HTTP/3

UDP 위에서 신뢰할 수 있는 전송이 필요한 경우(if reliable transfer needed over UDP, e.g. HTTP/3)

• add needed reliability at application layer
  • 신뢰성이 필요한 경우 어플리케이션 계층에서 필요한 신뢰성을 추가한다.
  • e.g. 패킷 손실 복구, 패킷 재전송 등의 메커니즘을 어플리케이션 계층에서 구현한다.
• add congestion control at application layer
  • congestion control이 필요한 경우 어플리케이션 계층에서 혼잡 제어 메커니즘을 추가한다.
  • e.g. 전송 속도 조절, 패킷 손실에 따른 대처 등을 어플리케이션 계층에서 관리한다.

UDP: User Datagram Protocol

• User Datagram Protocol(UDP)

  • 패킷 교환 방식의 컴퓨터 통신을 위해 설계된 데이터그램 모드를 제공한다.
  • 인터넷 프로토콜(IP)을 기반 프로토콜을 사용한다고 가정하자.
    
    

• 목적

  • UDP는 최소한의 프로토콜 메커니즘으로 어플리케이션 프로그램이 다른 프로그램으로 메시지를 보내기 위한 절차를 제공한다.
  • 이 프로토콜은 트랜잭션 지향(각 데이터그램이 독립적으로 처리된다는 것을 의미)이며, 데이터의 전달 및 중복 보호가 보장되지 않는다.
  • 순차적이고 신뢰할 수 있는 데이터 전송이 필요한 어플리케이션은 TCP(Transmission Control Protocol)을 사용해야 한다.

• Format

  1. Source Port(출발지 포트)

     • 데이터그램을 보낸 출발지 포트 번호를 나타낸다.
     • 16bit

  2. Destination Port(목적지 포트)

     • 데이터그램을 받을 목적지 포트 번호를 나타낸다.
     • 16bit

  3. Length(길이)

     • UDP 헤더와 데이터의 총 길이를 나타낸다.
     • 16bit

  4. Checksum(체크섬)

     • 데이터그램의 무결성을 확인하기 위한 체크섬 값
     • 16bit

  5. Data

     • 전송할 실제 데이터
     • 길이는 UDP 헤더의 길이 필드에 의해 결정된다.

UDP: Transport Layer Actions

UDP sender actions

1. 응용 계층의 메시지 전달
   • UDP 송신자는 응용 계층에서 전달된 SNMP 메시지를 받는다.
     
2. UDP segment header field 값 결정
   • UDP 송신자는 UDP 세그먼트의 헤더 필드 값을 결정한다. 이는 출발지 포트 번호, 목적지 포트 번호, 길이, 체크섬 등을 포함한다.
     
3. UDP 세그먼트 생성
   • UDP 송신자는 SNMP 메시지를 포함하여 UDP 세그먼트를 생성한다. 이 세그먼트는 헤더와 데이터로 구성된다.
     
4. 세그먼트를 IP 계층으로 전달
   • 생성된 UDP 세그먼트는 네트워크 계층(IP)으로 전달되어 전송된다.

UDP receiver actions

1. IP 계층에서 세그먼트를 수신
   • UDP 수신자는 네트워크 계층(IP)으로부터 UDP segment를 수신한다.
     
2. UDP 체크섬 헤더 값을 확인
   • UDP 수신자는 세그먼트의 체크섬 헤더 값을 확인하여 데이터의 무결성을 검증
     
3. 응용 계층 메시지를 추출
   • UDP 수신자는 세그먼트의 응용 계층 메시지(SNMP 메시지)를 추출한다.
     
4. 메시지를 소켓을 통해 어플리케이션으로 전달(demultiplexes message up to application via socket)
   • 추출된 메시지를 소켓을 통해 어플리케이션 계층으로 전달

UDP segment header

1. 출발지 포트 번호(Source Port Number)
   • 위치: UDP segment의 첫 번째 16비트
   • 역할: 송신자의 포트 번호를 나타낸다. 수신자가 응답을 보낼 때 사용된다.
     
2. 목적지 포트 번호(Destination Port Number)
   • 위치: UDP segment의 두 번째 16비트
   • 역할: 수신자의 포트 번호를 나타낸다. 이 포트 번호를 사용하여 데이터가 올바른 어플리케이션으로 전달된다.
     
3. 길이(Length)
   • 위치: UDP segment의 세 번째 !6비트
   • 역할: UDP segment의 전체 길이를 나타낸다. 여기에는 헤더와 데이터(payload)가 모두 포함된다. 길이는 바이트 단위로 표시된다.
     
4. 체크섬(Checksum)
   • 위치: UDP segment의 네 번째 16비트
   • 역할: 데이터의 무결성을 확인하기 위한 값이다. 송신자는 세그먼트를 생성할 때 체크섬을 계산하고, 수신자는 이름 검증하여 데이터가 손상되지 않았는지 확인한다.
     
5. application data, payload
   • 위치: UDP 헤더 다음에 위치
   • 역할: application layer에서 전송된 실제 데이터이다. UDP는 데이터의 구조나 내용에 대해 신경 쓰지 않으며, 단순히 전송 역할을 수행한다.

UDP checksum

Goal: 전송된 segment의 error(i.e. flipped bits) 감지

Sender(송신자 측)

1. UDP 세그먼트 내용 처리(treat contents of UDP segment)
   • UDP 세그먼트의 모든 내용을 16비트 정수의 연속으로 취급한다. 여기에는 UDP 헤더 필드와 IP 주소도 포함된다.

2. 체크섬 계산(checksum)

   • 세그먼트 내용의 합계를 계산한다. 이 때 1의 보수 합(one's complement sum)을 사용한다.
     

3. 체크섬 필드에 값 넣기(checksum value put into UDP checksum field)

   • 계산된 체크섬 값을 UDP 체크섬 필드에 넣는다.
     
     

Receiver(수신자 측)

1. 수신된 세그먼트의 체크섬 계산(compute checksum of received segment)
   • 수신자는 수신된 세그먼트의 내용을 이용해 체크섬을 다시 계산한다.

2. 계산된 체크섬과 필드 값 비교(check if computed checksum equals checksum field value)
   • 계산된 체크섬이 UDP 세그먼트의 체크섬 필드 값과 동일한지 확인한다.
     • 동일하지 않음(Not equal): 오류가 감지된다.
     • 동일함(Equal): 오류가 감지되지 않음. 그러나 오류가 없다는 보장은 아니다.

Internet Checksum: an example

wraparound: 최상위 비트(carryout)가 발생한 경우 이를 하위 비트에 더해준다.
checksum: 합계의 1의 보수를 계산한다.

Internet checksum: weak protecton

전달된 값이 에러로 인해 변경되었지만, 이는 checksum에서 감지하지 못한다.

Summary: UDP

• "No frills" 프로토콜
  • 세그먼트가 손실되거나 순서가 바뀌어 전달될 수 있음
    • UDP는 신뢰성 있는 전송을 보장하지 않으므로, 데이터그램이 손실되거나 순서가 바뀌어 도착할 수 있다.
  • send and hope for the best
    • UDP는 데이터를 전송하기 위해 연결을 설정하지 않으며, 데이터를 최선의 노력으로 전송한다. 즉, 송신 후 수신 여부를 확인하지 않는다.

• UDP의 장점
  • no setup/handshaking needed
    • 연결을 설정하는 과정이 없으므로, 추가적인 왕복 시간 지연(RTT)이 발생하지 않는다.
  • 네트워크 서비스가 손상되었을 때도 동작 가능
    • 네트워크 혼잡이나 손상이 발생해도 UDP는 계속해서 데이터를 전송할 수 있다.
  • 신뢰성 향상에 도움(helps with reliability)
    • UDP는 체크섬을 사용하여 데이터 무결성을 확인하고, 기본적인 오류 검출을 제공한다.

• 어플리케이션 계층에서 UDP 위에 추가 기능 구축(build additional functionality on top of UDP in application layer)
  • e.g. HTTP/3와 같은 프로토콜은 UDP 위에 추가적인 기능을 구축하여, 신뢰성 있는 데이터 전송 및 혼잡 제어를 응용 계층에서 구현할 수 있다.

Principles of reliable data transfer

주요 구성 요소 1. 송신 프로세스(Sending Process) - 어플리케이션 데이터가 생성된다. - 데이터를 신뢰할 수 있는 데이터 전송 프로토콜의 송신 측에 전달한다.
2. 신뢰할 수 있는 데이터 전송 프로토콜의 송신 측(Sender-side of Reliable Data Transfer Protocol) - 데이터의 무결성과 전달을 보장하기 위한 메커니즘을 포함한다. - 데이터가 손실, 손상 또는 재정렬될 수 있는 신뢰할 수 없는 채널을 통해 전송된다.
3. 신뢰할 수 없는 채널(Unreliable Channel) - 데이터가 손실되거나, 손상되거나, 재정렬될 수 있는 전송 매체이다 - 신뢰할 수 있는 데이터 전송 프로토콜은 이러한 불확실성을 극복하기 위한 기능을 제공한다.

4. 신뢰할 수 있는 데이터 전송 프로토콜의 수신 측(Receiver-side of Reliable Data Transfer Protocol)
   • 수신된 데이터의 무결성을 확인하고, 손상된 데이터를 감지하여 필요한 경우 재전송을 요청한다
   • 데이터를 수신 프로세스에 전달한다.

5. 수신 프로세스(Receiving Process) - 수신된 데이터를 어플리케이션 계층에서 처리한다.

요약

• 신뢰할 수 있는 데이터 전송 프로토콜(Reliable data transfer protocol)은 데이터 전송 중 발생할 수 있는 다양한 문제를 해결하기 위한 메커니즘을 제공한다.
• 송신 측은 데이터 검증 및 재전송 요청 처리 등의 기능을 통해 데이터의 무결성을 보장한다.
• 수신 측은 수신된 데이터의 무결성을 확인하고, 필요한 경우 재전송을 요청한다
• 신뢰할 수 없는 채널을 통해 데이터가 전송되더라도, 이러한 프로토콜을 통해 신뢰할 수 있는 데이터 전송을 구현할 수 있다.

송신자와 수신자는 서로의 상태를 알지 못함(Sender, receiver do not know the 'state' of each other)
- 송신자와 수신자는 메시지가 성공적으로 수신되었는지 여부를 알지 못한다.
- e.g. 송신자는 메시지가 수신자에게 도착했는지, 수신자는 메시지를 송신자가 보냈는지 모른다.

메시지를 통해 상태를 통신해야 함(unless communicated via a message)
- 송신자와 수신자는 메시지를 통해서만 서로의 상태를 알 수 있다.
- 즉, 수신자는 확인 응답(ACK) 메시지를 송신자에게 보내 메시지를 성공적으로 수신했음을 알릴 수 있다.

Reliable data transfer protocol(rdt) : interfaces

송신 측(Sender Side)

1. rdt_send()
   • 역할: 응용 계층에서 데이터를 받아 수신자의 상위 계층으로 전달하기 위해 호출된다.
   • 설명: 송신 프로세스에서 데이터를 받아 rdt protocol의 송신측 구현으로 전달한다.

2. udt_send()
   • 역할: 신뢰할 수 없는 채널을 통해 패킷을 전송하기 위해 rdt에 의해 호출된다.
   • 설명: 신뢰할 수 없는 채널을 통해 수신자에게 패킷을 전송한다.

수신 측(Receiver Side)

1. rdt_rcv()
   • 역할: 신뢰할 수 없는 채널을 통해 패킷이 수신 측에 도착하면 호출된다.
   • 설명: 패킷이 수신자 측에 도착할 때마다 rdt protocol의 수신 측 구현으로 전달된다.

2. deliver_data()
   • 역할: 데이터를 상위 계층으로 전달하기 위해 rdt에 의해 호출된다.
   • 설명: rdt protocol의 수신 측 구현에서 데이터를 수신 프로세스로 전달한다.

사진 설명

1. Sending Process(송신 프로세스)
   • 응용 계층에서 data를 생성
   • rdt_send()를 호출하여 data를 신뢰할 수 있는 데이터 전송 프로토콜의 송신 측 구현으로 전달한다.

2. Sender-side Implementation(송신 측 구현)
   • rdt_send()에서 받은 데이터를 udt_send()를 호출하여 신뢰할 수 없는 채널을 통해 packet으로 전송

3. Unreliable Channel(신뢰할 수 없는 채널)
   • 데이터를 패킷으로 전송
   • 패킷은 수신 측으로 전달됨

4. Receiver-side Implementation(수신 측 구현)
   • rdt_rcv()가 호출되어 신뢰할 수 없는 채널을 통해 도착한 패킷을 처리한다.
   • 패킷에서 데이터를 추출하여 deliver_data()를 호출하여 데이터를 수신 프로세스에 전달한다.

5. Receiving Process(수신 프로세스)
   • deliver_data()를 통해 전달된 데이터를 상위 계층에서 처리

Reliable data transfer: getting started

1. 점진적으로 송신자와 수신자 측 개발(incrementally develop sender, receiver sides of RDT)

   • 신뢰할 수 있는 데이터 전송 프로토콜(RDT)의 송신자와 수신자 측을 점진적으로 개발
   • 각 단계에서 프로토콜의 복잡성을 증가시켜 나간다.
     
     

2. 단방향 데이터 전송만 고려(consider only unidirectional data transfer)

   • 여기서는 단방향 데이터 전송만을 고려
   • 하지만, 제어 정보는 양방향으로 흐른다. 즉, 데이터는 한 방향으로만 흐르지만, 확인 응답(ACK)이나 재전송 요청 등의 제어 정보는 반대 방향으로도 전송된다.

3. 유한 상태 기계(FSM) 사용(use finite state machines to specify sender, receiver)
   • 송신자와 수신자를 정의하기 위해 유한 상태 기계를 사용한다.
   • 각 상태는 다음 상태로의 전이를 일으키는 이벤트와 상태 전이 시 수행되는 동작을 포함한다.

rdt1.0: reliable transfer over a reliable channel

• 기본 가정(Underlying Assumptions
  • 완벽히 신뢰할 수 있는 채널(underlying channel perfectly reliable)
    • 비트 오류 없음(no bit errors): 데이터 전송 중에 비트 오류가 발생하지 않는다.
    • 패킷 손실 없음(no loss of packets): 데이터 전송 중에 패킷 손실이 발생하지 않는다.

• 송신자와 수신자를 위한 별도의 FSM(Separate FSMs for sender and receiver)

  • 송신자(Sender)
    • 동작:
      1. 상위 계층에서 데이터 전송 요청이 있을 때까지 대기한다.('Wait for call from above')
      2. 'rdt_send(data)' 함수가 호출되면 데이터를 패킷으로 만든다('packet = make_pkt(data)')
      3. 패킷을 신뢰할 수 있는 채널을 통해 전송한다.('udt_send(packet)')
  • 수신자(Receiver)
    • 동작:
      1. 하위 계층에서 패킷이 도착할 때까지 대기한다.('Wait for call from below')
      2. 'rdt_rcv(packet)' 함수가 호출되면 패킷에서 데이터를 추출한다.('extract(packet, data)')
      3. 추출한 데이터를 상위 계층으로 전달한다. ('deliver_data(data)')
         
         
         
         
         

  rdt 2.0 : channel with bit errors

  채널에서 패킷 내의 비트가 변경될 수 있다. 즉, 데이터 전송 중에 비트 오류가 발생할 수 있다.

  • checksum(e.g. Internet checksum)이 bit error를 detect할 수 있다.

Q. error를 어떻게 복구할 것인가?

• ACKs(Acknowledgements): 수신자는 송신자에게 패킷이 정상적으로 수신되었음을 명시적으로 알린다.
• NAKs(Negative Acknowledgements): 수신자는 송신자에게 패킷에 오류가 있음을 명시적으로 알린다.
• Retransmission: 송신자는 NACK를 수신하면 패킷을 재전송한다.

Stop-and-Wait 프로토콜

• 송신자는 한 번에 하나의 패킷을 전송하고, 수신자로부터 응답을 기다린다
• 수신자가 ACK를 보내면 다음 패킷을 전송한다.
• 수신자가 NAK를 보내면 송신자는 동일한 패킷을 재전송한다.

rdt2.0: FSM specifications

상태(State)

1. Wait for call from above(상위 계층으로부터 호출 대기)
   • 송신자는 상위 계층(응용 계층)에서 데이터 전송 요청이 있을 때까지 대기한다.
2. Wait for ACK or NAK
   • 송신자는 데이터를 전송한 후, 수신자로부터 ACK(확인 응답) 또는 NAK(부정 응답)를 기다린다.

상태 전이(State Transition)

1. Wait for call from above -> Wait for ACK or NAK
   • 조건: 상위 계층에서 데이터 전송 요청이 있을 때('rdt_send(data)')
   • 동작:
     • 데이터와 체크섬을 포함하는 패킷을 생성('snkpkt = make_pkt(data, checksum)')
     • 생성된 패킷을 신뢰할 수 없는 채널을 통해 전송('udt_send(snkpkt)')
2. Wait for ACK or NAK -> Wait for call from above
   • 조건: 수신된 패킷이 ACK인 경우('rdt_rcv(rcvpkt) && isACK(rcvpkt)')
   • 동작:
     • ACK를 받으면 송신자는 상위 계층에서 다음 데이터 전송 요청을 기다린다.
3. Wait for ACK or NAK -> Wait for ACK or NAK
   • 조건: 수신된 패킷이 NAK인 경우('rdt_rcv(rcvpkt) && isNAK(rcvpkt)')
   • 동작:
     • NAK를 받으면 송신자는 이전에 전송한 패킷을 다시 전송한다. ('udt_send(snkpkt)')

Note

• "state"의 수신자는 송신자가 알 수 없다. 즉, 수신자가 메시지를 제대로 받았는지 여부를 송신자가 알 수 없다.
• 이는 수신자가 송신자에게 ACK 또는 NAK를 통해 명시적으로 알려주지 않으면 송신자가 알 수 없음을 의미한다.
• 이러한 이유로, 송신자가 수신자 간의 통신을 관리하는 프로토콜이 필요하다.

rdt2.0: operation with no erros

수신자(Receiver) FSM가 추가됬다.

1. 상태: Wait for call from below(하위 계층으로부터 호출 대기)
   • 동작: 하위 계층에서 패킷이 도착할 때까지 대기한다.
   • 이벤트: 'rdt_rcv(rcvpkt) && corrupt(rcvpkt)
     • 작업: 수신된 패킷에 오류가 있는 경우, NAK를 전송한다.('udt_send(NAK)')
     • 전이: 상태는 "Wait for call from below"로 유지
   • 이벤트: rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
     • 작업: 수신된 패킷에 오류가 없는 경우, 데이터를 추출하고('extrack(rcvpkt, data)'), 상위 계층으로 전달한다.('deliver_data(data)'). 그리고 ACK를 전송한다.('udt_send(ACK)')
     • 전이: 상태를 'Wait for call from below'

rdt2.0 has a fatal flaw

What happens if ACK/NAK corrupted?

• 송신자가 수신자의 상태를 알 수 없음
  • ACK 또는 NAK가 손상된 경우, 송신자는 수신자가 패킷을 올바르게 수신했는지 여부를 알 수 없다.
• 단순 재전송 불가능
  • 송신자가 패킷을 단순히 재전송할 수 없다. 이는 중복 패킷이 발생할 수 있기 때문이다.
  • 중복 패킷은 수신자가 동일한 데이터를 여러 번 수신하게 할 수 있다.

Handling Duplicates

• 손상된 ACK/NAK에 대한 재전송(sender retransmits current pkt if ACK/NAK corrupted)
  • 송신자가 ACK 또는 NAK가 손상된 경우, 현재 패킷을 재전송한다.
• 순서 번호 추가(sender adds sequence number to each pkt)
  • 송신자는 각 패킷에 순서 번호를 추가하여 중복을 식별할 수 있게 한다.
  • 순서 번호를 통해 수신자는 중복 패킷을 감지하고 무시할 수 있다.
• 수신자가 중복 패킷을 버림(receiver discards (doesn't deliver up) duplicate pkt)
  • 수신자는 중복 패킷을 식별하여 이를 상위 계층으로 전달하지 않고 버린다.

Stop-and-Wait 프로토콜

• 송신자는 한 번에 하나의 패킷을 전송하고, 수신자의 응답(ACK, NAK)을 기다린다
  • 이는 데이터 전송의 신뢰성을 보장하기 위한 기본적인 흐름 제어 방식이다..

rdt2.1: Sender, Handling garbled ACK/NAKs

순서 번호 0,1을 통해 중복 패킷을 식별하고 처리

상태(state)

1. Wait for call 0 from above
   • 동작: 상위 계층에서 데이터 전송 요청이 있을 때까지 대기한다.
   • 이벤트: 'rdt_send(data)'
     • 작업: 순서 번호 0과 데이터를 포함하는 패킷을 생성('sndpkt = make_pkt(0, data, checksum)')하고 전송('udt_send(sndpkt)')
     • 전이: 상태가 'Wait for ACK or NAK 0'로 전이된다

2. Wait for ACK or NAK 0
   • 동작: 패킷 전송 후, 수신자로부터 ACK 또는 NAK를 기다린다.
   • 이벤트: 'rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || isNAK(rcvpkt))'
     • 작업: 수신된 패킷이 손상되었거나 NAK인 경우, 현재 패킷을 다시 전송('udt_send(sndpkt)')
     • 전이: 상태는 'Wait for ACK or NAK 0'로 유지된다.
   • 이벤트 'rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
     • 작업: 수신된 패킷이 손상되지 않았고 ACK인 경우, 다음 데이터 전송 요청을 기다린다.
     • 전이: 상태는 'Wait for call 1 from above'로 전이된다.

3. Wait for call 1 from above
   • 동작: 상위 계층에서 데이터 전송 요청이 있을 때까지 대기한다.
   • 이벤트: 'rdt_send(data)'
     • 작업: 순서 번호 1과 데이터를 포함하는 패킷을 생성('sndpkt = make_pkt(1, data, checksum)')하고 전송('udt_send(sndpkt)')
     • 전이: 상태가 'Wait for ACK or NAK 1'로 전이된다.

4. Wait for ACK or NAK 1
   • 동작: 패킷 전송 후, 수신자로부터 ACK 또는 NAK를 기다린다.
   • 이벤트: 'rdt_rcv(rcvpkt) && (corrupt(rcvpkt) || isNAK(rcvpkt))
     • 작업: 수신된 패킷이 손상되었거나 NAK인 경우, 현재 패킷을 다시 전송('udt_send(sndpkt)')
     • 전이: 상태는 "Wait for ACK or NAK 1"로 유지
   • 이벤트: 'rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)
     • 작업: 수신된 패킷이 손상되지 않았고 ACK인 경우, 다음 데이터 전송 요청을 기다림
     • 전이: 상태가 "Wait for call 0 from above"로 전이된다.

rdt2.1 : receiver, handling garbled ACK/NAKs

상태(state)

1. Wait for 0 from below
   • 동작: 하위 계층에서 순서 번호 0의 패킷이 도착할 때까지 대기
   • 이벤트: 'rdt_rcv(rcvpkt) && corrupt(rcvpkt)
     • 작업: 수신된 패킷이 손상된 경우, NAK 패킷을 생성('sndpkt = make_pkt(NAK, chksum)')하고 전송('udt_send(sndpkt)')
     • 전이: 상태는 "Wait for 0 from below"로 유지된다.
   • 이벤트: 'rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt)'
     • 작업: 수신된 패킷이 손상되지 않았고 순서 번호 0인 경우, 데이터를 추출('extrack(rcvpkt, data)')하여 상위 계층으로 전달('deliver_data(data)')한다. ACK 패킷을 생성('snkpkt = make_pkt(ACK, chksum)')하고 전송('udt_send(sndpkt)')
     • 전이: 상태가 'Wait for 1 from below'로 전이된다.

2. Wait for 1 from below
   • 동작: 하위 계층에서 순서 번호 1의 패킷이 도착할 때까지 대기한다.
   • 이벤트: 'rdt_rcv(rcvpkt) && corrupt(rcvpkt)'
     • 작업: 수신된 패킷이 손상된 경우, NAK 패킷을 생성('sndpkt = make_pkt(NAK, chksum)')하고 전송('udt_send(sndpkt)')
     • 전이: 상태는 "Wait for 1 from below"로 유지된다.
   • 이벤트: 'rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)'
     • 작업: 수신된 패킷이 손상되지 않았고 순서 번호 1인 경우, 데이터를 추출('extrack(rcvpkt, data)')하여 상위 계층으로 전달('deliver_data(data)')한다.
     • 작업: ACK 패킷을 생성('sndpkt = make_pkt(ACK, chksum)')하고 전송('udt_send(sndpkt)').
     • 전이: 상태가 "Wait for 0 from below"로 전이된다.

rdt2.1: discussion

송신자(Sender)

1. 순서 번호 추가(seq # added to pkt)
   • 각 패킷에 순서 번호가 추가된다. 이 번호는 송신자가 보낸 패킷이 중복되었는지 여부를 확인하는 데 사용된다.

2. 두 개의 순서 번호(0,1)로 충분(two seq. #s (0,1) will suffice, why?
   • 송신자는 두 개의 순서 번호(0과 1)만 사용해도 된다. 이는 송신자가 한 번에 하나의 패킷만 전송하고, 다음 패킷을 전송하기 전에 이전 패킷에 대한 확인 응답을 기다리기 때문이다.
   • 각 패킷은 번갈아 가며 0 또는 1의 순서 번호를 가지므로 중복을 쉽게 식별할 수 있다.

3. 수신된 ACK/NAK의 손상 여부 확인(must check if received ACK/NAK corrupted)
   • 송신자는 수신된 ACK 또는 NAK가 손상되었는지 확인해야 한다. 손상된 경우에는 패킷을 재전송 해야한다.

4. 두 배 많은 상태(twice as many states)
   • 프로토콜은 두 배 많은 상태를 필요로 한다. 이는 송신자가 "기대하는" 패킷이 순서 번호 0인지 1인지 기억해야 하기 때문이다.

수신자(Receiver)

1. 중복 패킷 여부 확인(must check if received packet is duplicate)
   • 수신자는 수신된 패킷이 중복된 패킷인지 확인해야 한다.
   • 상태는 기대하는 패킷의 순서 번호가 0인지 1인지 나타낸다.

2. 수신자는 마지막 ACK/NAK가 송신자에게 올바르게 수신되었는지 알 수 없음(note : receiver can not know if its last ACK/NAK received OK at sender)
   • 수신자는 마지막으로 보낸 ACK 또는 NAK가 송신자에게 올바르게 도착했는지 알 수 없다.
   • 이는 수신자가 항상 ACK 또는 NAK를 송신자에게 보내는 이유 중 하나이다.

rdt2.2: a NAK-free protocol

1. rdt2.1과 동일한 기능(same functionality as rdt2.1, using ACKs only)
   • rdt2.2는 rdt2.1과 동일한 기능을 수행하지만, NAK를 사용하지 않고 ACK만을 사용한다.

2. NAK 대신 ACK 사용(instead of NAK, receiver sends ACK for last pkt received OK)
   • 수신자는 NAK 대신, 마지막으로 올바르게 수신된 패킷에 대한 ACK를 보낸다.
   • 수신자는 ACK에 확인하는 패킷의 순서 번호를 명시적으로 포함시켜야 한다.

3. 중복된 ACK에 대한 처리(duplicate ACK at sender results in same action as NAK)
   • 송신자는 중복된 ACK를 수신하면, NAK를 수신한 것과 동일하게 현재 패킷을 재전송한다.
   • 이는 중복된 ACK가 수신자가 이전에 수신한 패킷이 손상되었음을 나타낼 수 있기 때문이다.

4. TCP의 NAK-free 접근 방식
   • TCP는 이러한 접근 방식을 사용하여 NAK를 사용하지 않는다.
   • TCP는 ACK만을 사용하여 신뢰할 수 있는 데이터 전송을 보장한다.

rdt3.0 : channels with errors and loss

새로운 채널 가정(New Channel Assumption)

• 기본 가정: 채널에서 데이터 패킷과 ACK(확인 응답) 패킷이 손실될 수 있다.
  • 오류 및 손실 가능: 기존의 비트 오류뿐만 아니라 패킷 자체가 손실될 수 있다.
  • 체크섬, 순서 번호, ACK, 재전송: 이러한 메커니즘은 도움을 줄 수 있지만, 충분하지 않다.
    • 체크섬: 비트 오류를 감지
    • 순서 번호: 패킷의 순서를 관리하여 중복을 방지
    • ACK: 수신자가 패킷을 정상적으로 수신했음을 송신자에게 알린다.
    • 재전송: 손실된 패킷을 다시 전송한다.

질문

• Q. 사람들은 대화 중에 송신자와 수신자 간의 단어가 손실되는 경우를 어떻게 처리합니까?

접근 방식:

• 송신자가 합리적인 시간 동안 ACK를 기다림(sender waits "reasonable" amount of time for ACK)
• 해당 시간 내에 ACK를 받지 못하면 재전송(retransmits if no ACK received in this time)

패킷이 지연된 경우(if pkt(or ACK) just delayed(not lost))

• 재전송된 패킷이 중복될 수 있음(retransmission will be duplicate, but seq #s already handles this!)
• 수신자가 ACK가 확인하는 패킷의 순서 번호를 명시해야 함(receiver must specify seq # of packet being ACKed)

타이머 사용(use countdown timer to interrupt after "reasonable" amount of time)

• 타이머를 사용하여 설정된 시간이 지나면 인터럽트 발생(timeout)
  • 송신자는 카운트다운 타이머를 사용하여 설정된 시간 동안 ACK를 기다리고, 그 시간이 지나면 타임아웃이 발생하여 패킷을 재전송한다.

rdt3.0 sender

rdt3.0 in action

Performance of rdt3.0 (Stop-and-Wait)

활용도(Utilization)

• U_sender: 송신자의 활용도는 송신자가 데이터를 전송하는 데 바쁜 시간의 비율을 나타낸다.

예제(Example)

• 1 Gbps 링크(1 Gbps link):

  • 링크 속도: 1 Gbps(기가비트/초)
    

• 15 ms 전파 지연(15 ms prop.delay)

  • 전파 지연: 15ms(밀리초)
    

• 8000 비트 패킷(8000 bit packet)
  • 패킷 크기: 8000 bit

전송 시간 계산(Time to Transmit Packet into Channel)

• 전송 시간(D_trans)
  • 전송 시간은 패킷을 채널에 전송하는 데 걸리는 시간이다.
  • 계산식: D_trans = L / R
    • L : 패킷 크기(8000bit)
    • R : 링크 속도(1 Gbps = 10^9 bits/sec)
  • 계산: D_trans = 8000bits / 10^9 bits/ sec = 8microseconds
    • 따라서, 패킷을 채널에 전송하는 데 걸리는 시간은 8 마이크로초이다.

rdt3.0: stop-and-wait operation

• rdt 3.0 프로토콜은 성능은 좋지 않음(rdt 3.0 protocol performance stinks)
  • 이 계산 결과는 송신자의 활용도가 매우 낮음을 보여준다.
  • 송신자가 실제로 데이터를 전송하는 데 바쁜 시간은 전체 시간의 극히 일부분이다.
• 프로토콜이 채널의 성능을 제한함(protocol limits performance of underlying infrastructrue(channel))
  • rdt3.0의 stop-and-wait 방식은 채널의 높은 대역폭을 효과적으로 사용하지 못한다.

rdt3.0: pipelined protocols operation

파이프라인 처리(pipelining)

• 정의: 송신자는 ACK를 기다리지 않고 여러 개의 "비행 중인(in-flight)" 패킷을 전송할 수 있다. 즉, 아직 확인되지 않은 여러 패킷을 한 번에 전송하는 것 이다.

파이프라인 처리를 위한 요구 사항

1. 순서 번호의 범위를 증가시켜야 함(Range of Sequence Numbers Must Be Increased)
   • 여러 패킷을 동시에 전송할 때, 각 패킷을 식별하기 위해 더 큰 범위의 순서 번호가 필요하다.
2. 송신자와 수신자에서의 버퍼링(Buffering at Sender and/or Receiver)
   • 송신자와 수신자는 아직 확인되지 않은 패킷들을 저장하기 위해 버퍼를 사용해야 한다.

Go-Back-N: sender

Go-Back-N 프로토콜: 송신자가 일정 크기의 창을 통해 여러 패킷을 전송할 수 있도록 하며, ACK를 받지 못한 패킷이 있을 경우 해당 패킷과 이후의 패킷을 모두 재전송한다.

기본 개념

• Window: 송신자는 N개의 연속적으로 전송되었지만 ACK를 받지 못한 패킷을 허용한다.
• k-bit sequence number: 패킷 헤더에 포함된 k-bit sequence number를 사용하여 패킷을 식별한다.

Window 메커니즘 설명

• send_base: 송신 창의 시작 지점, 이 지점 이전의 패킷은 이미 ACK를 받았다.
• nextseqnum: 다음으로 전송할 패킷의 순서 번호이다.
• window size N: 창의 크기는 N

누적 ACK(Cumulative ACK)

• ACK(n): n번까지의 모든 패킷에 대해 ACK를 받았음을 의미한다.
• ACK(n)을 수신한 경우: 송신자는 창을 n+1부터 시작하도록 앞으로 이동한다.

타이머와 재전송(Timer and Retransmission)

• 타이머: 비행 중인 가장 오래된 패킷에 대해 타이머를 설정하고, 타임아웃이 발생하면 해당 패킷과 이후의 패킷을 모두 재전송한다.
• timeout(n): n번 패킷과 그 이후의 모든 패킷을 재전송한다.

Go-Back-N: receiver

기본 개념

• ACK-only: 수신자는 지금까지 올바르게 수신된 패킷에 대해 가장 높은 순서 번호(in-order) 와 함께 ACK를 보낸다.
• 순서가 맞지 않는 패킷 수신 시: 수신자는 해당 패킷을 버리거나 버퍼링할 수 있으며, 이는 구현에 따라 달라진다.

수신자 동작

1. 올바르게 수신된 패킷에 대해 ACK 전송
   • 수신자는 지금까지 올바르게 수신된 패킷에 대해 가장 높은 순서 번호와 함께 ACK를 보낸다.
   • 이는 중복된 ACK를 생성할 수 있다.
   • 수신자는 'rcv_base' 만 기억하면 된다.

2. 순서가 맞지 않는 패킷 수신 시
   • 수신자는 순서가 맞지 않는 패킷을 수신하면 이를 버리거나 버퍼링할 수 있다.
   • 패킷을 버리는 경우(버퍼에 넣지 않음), 수신자는 가장 높은 순서 번호의 패킷에 대해 다시 ACK를 보낸다.

수신자 창의 상태

• 녹색: 수신하고 ACK를 보낸 패킷이다.
• 분홍색: 수신했지만 ACK를 보내지 않은 순서가 맞지 않는 패킷이다.
• 흰색: 아직 수신하지 않은 패킷이다.

Selective repeat

선택적 반복 프로토콜에 대한 설명이다. 이 프로토콜은 Go-Back-N 프로토콜의 단점을 보완하기 위해 만들었다.

1. 수신자 동작
   • 수신자는 올바르게 수신된 각 패킷을 개별적(individually) 으로 확인한다.
   • 필요한 경우, 상위 계층으로 순서대로 전달하기 위해 패킷을 버퍼링한다.

2. 송신자 동작
   • 송신자는 ACK를 받지 못한 패킷에 대해 개별적으로 타임아웃하고 재전송한다.
   • 송신자는 ACK를 받지 못한 각 패킷에 대해 타이머를 유지한다.

3. 송신 창
   • 송신자는 N개의 연속적인 순서 번호를 가진 패킷을 전송할 수 있다.
   • 이는 송신된 패킷 중 ACK를 받지 못한 패킷의 순서 번호를 제한한다.

주요 요소 설명 1. send_base - 송신 창(window)의 시작 부분을 나타낸다. 이 지점은 ACK를 받지 않은 가장 오래된 패킷의 순서 번호를 가리킨다.
2. nextseqnum - 송신자가 다음에 보낼 패킷의 순서 번호를 나타낸다. 이 지점부터 오른쪽으로 있는 패킷들은 아직 전송되지 않은 패킷이다.
3. Window Size - 송신 창의 크기를 나타낸다. 송신자는 동시에 N개의 패킷을 전송할 수 있다.

Selective Repeat: Sender and Receiver

송신자 측

1. 상위 계층에서 데이터 수신
   • 응용 계층에서 데이터를 보내려고 할 때, 송신자는 다음 사용할 수 있는 시퀀스 번호가 송신 창 내에 있는지 확인한다. 시퀀스 번호가 창 내에 있다면 송신자는 패킷을 생성하고 보낸다.

2. 타임아웃(timeout(n))
   • 패킷 n의 타이머가 만료되면 해당 패킷의 ACK(승인 응답)를 제시간에 받지 못했다는 의미이다. 송신자는 패킷 'n'을 재전송하고 해당 패킷의 타이머를 다시 시작한다.

3. ACK(n)이 [sendbase, sendbase + N] 내에 있음
   • 송신자가 현재 창 내에서 패킷 'n'에 대한 ACK를 받으면 해당 패킷을 받은 것으로 표시한다. 'n'이 가장 작은 미승인 패킷이라면 송신자는 창의 시작점을 다음 미승인 시퀀스 번호로 이동시킨다.

수신자 측

1. packet n in [rcvbase, rcvbase + N - 1]
   • send ACK(n)
   • out-of-order: buffer
   • in-order: 수신자는 해당 패킷을 응용 계층에 전달하고 버퍼에 저장된 순서대로 패킷을 전달하며, 수신 창을 다음 수신되지 않은 패킷으로 이동시킨다.

2. packet n in [rcvbase - N, rcvbase - 1]
   • 수신자가 이미 승인된 시퀀스 번호 범위 내에 있는 패킷 n을 받으면 해당 패킷에 대한 ACK를 다시 송신자에게 보낸다.

3. otherwise: ignore

Selective Repeat in action

Selective repeat: a dilemma

문제 상황 b

1. 송신 측: 패킷 전송 중 pkt0에 문제가 발생하여 재전송함
   
2. 수신 측: 순서가 맞지 않는 패킷을 받으면 버퍼링하고, 순서가 맞는 패킷을 확인 응답함
   • 예: pkt0 (0), ptk1 (1), pkt2 (2)가 전송되었을 때 pkt0이 손실되고 재전송됨
     
3. 문제 발생: 재전송된 pkt0이 수신될 때 수신 측이 이를 새 패킷으로 오인하고 다시 받아들이게 됨
   • 이는 시퀀스 번호의 크기와 윈도우 크기 사이의 관계로 인해 발생

핵심 이슈

• 시퀀스 번호의 크기와 윈도우 크기 사이의 관계
  • 시퀀스 번호 공간이 충분히 크지 않으면 재전송된 패킷이 중복으로 인식될 수 있다.
  • 이 문제를 해결하려면 시퀀스 번호 공간이 윈도우 크기보다 적어도 두 배는 커야 한다.
    
    
    

해결 방법

• 시퀀스 번호의 크기를 늘리기: 이를 통해 패킷의 중복 문제를 방지할 수 있다.
• 윈도우 크기 조절: 윈도우 크기를 시퀀스 번호 공간에 맞춰 조정하여 중복 패킷이 발생하지 않도록 한다.

SMTP: closing observations

SMTP: 주요 특징 및 마무리 설명

• Persistent Connections
  • SMTP는 지속적인 연결을 사용한다.
• Message Format
  • Message(헤더 및 본문)는 7 bit ASCII 형식이어야 한다.
  • Message 끝은 CRLF.CRLF로 구분한다.

HTTP와의 비교

• HTTP와 SMTP의 차이점
  • HTTP: 'pull' 프로토콜. client가 server에서 데이터를 요청하여 가져온다.
  • SMTP: 'push' 프로토콜. server가 client로 데이터를 보낸다.
  • 둘 다 ASCII command/response interaction 및 status code를 사용한다.
• 객체 전송 방식
  • HTTP: 각 object는 자체 response message에 encapsulate 된다.
  • SMTP: 여러 object는 multipart message로 전송된다.

Mail message format

1. SMTP(Simple Mail Transfer Protocol): 이메일 메시지를 교환하기 위한 프로토콜로, RFC 531에 정의되어 있다. HTTP와 유사하게 동작한다.
2. RFC 822: 이메일 메시지의 문법을 정의한다. HTML과 비슷하게 메시지의 형식을 규정한다.
3. 헤더 라인(Header Lines):
   • To : 수신자.
   • From : 발신자
   • Subject : 주제
   • 이 라인들은 이메일 메시지 본문 내에서 SMTP MAIL FROM:, RCPT TO: 명령과 구분된다.
4. 본문(Body): 메시지 본문은 ASCII 문자로만 구성된다.

Mail Access Protocols

이메일 접근 프로토콜

• SMTP: e-mail message를 receiver's server로 전달하고 저장하는 역할을 한다.
• mail access protocol: 서버에서 이메일을 검색하는 역할을 한다.

1. IMAP(Internet Mail Access Protocol)
   • RFC 3501에 정의되어 있다.
   • 메시지는 서버에 저장되며, IMAP은 저장된 메시지의 검색, 삭제, 폴더 관리 기능을 제공한다.
2. HTTP
   • Gmail, Hotmail, Yahoo! Mail 등은 웹 기반 인터페이스를 제공한다.
   • 이메일을 전송하기 위해 SMTP를 사용하며, IMAP(또는 POP)을 사용하여 이메일 메시지를 검색한다.

The Domain Name System DNS

DNS: Domain Name System

1. 식별자(Identifiers)
   • 사람들은 여러 가지 식별자를 가지고 있다. 예를 들어 SSN, 이름, Passport 등이 있다.
   • internet host와 router도 IP 주소(32bit)와 name(e.g. cs.umass.edu)을 가지고 있다.

2. DNS의 역할
   • IP address와 name 간의 매핑을 처리한다.
   • 이 매핑을 통해 사람이 이해하기 쉬운 이름을 IP 주소로 변환하고 그 반대의 경우도 처리할 수 있다.

3. 분산 데이터베이스(Distributed DataBase)
   • DNS는 많은 name server로 구성된 계층적(hierarchy) 분산 데이터베이스이다.
   • application layer protocol로 구현되어 있으며, host와 name server 간의 통신을 통해 이름을 resolve하고 주소를 변환한다.

4. 인터넷의 핵심 기능
   • DNS는 인터넷의 핵심 기능 중 하나로, application layer protocol로 구현되어 있다.
   • 네트워크의 'edge'에 복잡성이 존재한다.

DNS: services, structure

DNS Service

1. 호스트 이름을 IP 주소로 변환

   • DNS는 도메인 이름을 IP 주소로 변환하는 서비스이다.
   • e.g. www.google.com을 172.217.164.110으로 변환

2. 호스트 별칭(host aliasing)

   • 여러 별칭을 사용할 수 있다.
   • e.g. www.ibm.com와 같은 별칭을 사용하여 더 긴 공식 이름을 대신할 수 있다.

3. 메일 서버 별칭(host aliasing)

   • DNS는 메일 서버의 별칭도 제공한다.

4. 부하 분산(load distribution)

   • 여러 IP 주소가 하나의 도메인 이름에 대응할 수 있다.
   • 복제된 웹 서버를 사용하여 부하를 분산한다.

5. Q. 왜 DNS를 중앙 집중화를 피하는가?

   • 단일 장애 지점(single point of failure)
     • 중앙 집중화된 DNS 서버가 장애를 겪으면 전체 시스템이 영향을 받게 된다.
   • 트래픽 볼륨(traffic volume)
     • 중앙 집중화된 서버는 모든 DNS 쿼리를 처리해야 하기에 트래픽이 집중되고 서버 과부하가 발생할 수 있다.
   • 멀리 떨어진 중앙 집중형 데이터베이스(distant centralized database)
     • 중앙 집중화된 데이터베이스는 지리적으로 멀리 떨어진 사용자에게 지연 시간을 증가시킬 수 있다.
     • 분산형 구조는 더 가까운 서버에서 쿼리를 처리할 수 있어 성능이 향상된다.
   • 유지보수(maintenance)
   • 스케일링 문제를 해결하기 위해
     • e.g. Comcast의 DNS 서버는 하루에 600억 개의 DNS 쿼리를 처리한다.

6. 분산 데이터베이스

   • DNS는 분산 계층 구조로 구성된다.
   • 여러 이름 서버가 계층적으로 배치되어 있다.

Thinking about the DNS

1. 거대한 분산 데이터베이스(Humongous distributed database)
   • 약 10억 개의 간단한 레코드가 포함되어 있다.
2. 수많은 쿼리 처리(Handles many trillions of queries/day)
   • 읽기 작업이 쓰기 작업보다 훨씬 많다.
   • 성능이 중요하다. 거의 모든 인터넷 거래는 DNS와 상호작용하며, 밀리초 단위의 응답 시간이 중요하다.
3. 조직적으로, 물리적을 분산화됨(Organizationally, Physically decentralized)
   • 수백만 개의 조직이 각자의 레코드를 관리한다.
4. 탄탄함(Bulletproof)
   • 신뢰성과 보안이 뛰어나다.

DNS: a distributed, hierarchical database

1. 루트 DNS 서버(Root DNS Servers)
   • 최상위에 위치하며, .com, .org, .edu 등의 최상위 도메인(TLD) 서버로 쿼리를 전달한다.

2. 최상위 도메인(TLD) 서버(Top-Level Domain Server)
   • 각 TLD에 대한 정보를 가지고 있으며, 특정 TLD에 속한 권한 있는 DNS 서버로 쿼리를 전달한다.
   • e.g. .com, .org, .edu 등

3. 권한 있는 DNS 서버(Authoritative DNS Servers)
   • 특정 도메인 이름에 대한 최종 IP 주소 정보를 가지고 있다.
   • e.g. amazon.com, pbs.org, nyu.edu 등의 서버

4. 예
   • 클라이언트가 www.amazon.com의 IP 주소로 요청하는 과정
   1. client가 root server에 query를 보낸다.
   2. root server가 .com TLD server 주소를 client에게 전달한다.
   3. client는 .com TLD server에 query를 보낸다.
   4. .com TLD server가 amazon.com Authoritative DNS server 주소를 client에게 전달한다.
   5. client가 amazon.com Authoritative DNS server에 qeury를 보낸다.
   6. amamzon.com Authoritative DNS server는 www.amazon.com의 IP 주소를 client에게 전달한다.
   7. client는 IP 주소를 받는다.

DNS: root name servers

1. 역할
   • 루트 네임 서버는 도메인 이름을 해결하지 못하는 경우 마지막으로 연결할 수 있는 공식적인 연락처이다.
   • 인터넷 기능에서 매우 중요한 역할을 한다. 인터넷은 루트 네임 서버 없이는 제대로 작동할 수 없다.

2. DNSSEC
   • DNSSEC는 보안을 제공하며, 인증과 메시지 무결성을 보장한다.

3. ICANN
   • 인터넷 할당 번호 관리 기관(Internet Corporation for Assigned Names and Numbers)이 root DNS domain을 관리한다.

4. 전 세계에 분포된 루트 네임 서버
   • 전 세계에 13개의 논리적 루트 네임 서버가 있으며, 각 서버는 여러 번 복제되어 있다. 미국에만 약 200개의 서버가 존재한다.
   • 지도에는 루트 네임 서버의 분포가 시각적으로 표시되어 있다.

Top-Level Domain, and Authoritative Servers

1. Top-Level Domain(TLD) Server
   • .com, .org, .net, .edu, .aero, .jobs,. museums와 같은 최상위 도메인 및 국가 도메인(e.g. .cn, .uk, .fr, .ca, .jp)을 담당한다.
   • Network Solutions: .com 및 .net TLD의 권한 있는 레지스트리
     • Educause: .edu TLD의 권한 있는 레지스트리

2. Authoritative DNS Servers(권한 있는 DNS 서버)
   • organization 자체 DNS 서버로서, 조직의 네임드 host에 대한 host name을 IP 주소로 매핑하는 기능을 제공한다.
   • organization이나 서비스 제공자가 maintaine 할 수 있다.

Local DNS name servers

1. host가 DNS query를 만들 때
   • Local DNS server로 query를 보낸다.
   • Local DNS server는 name-address translation pair의 Local cache에서 response를 반환하거나(가능한 경우), DNS hierarchy 구조로 request을 전달하여 해결한다.

2. Local DNS 서버의 역할
   • local cache에서 최근의 name-address translation pair을 반환할 수 있다.(다만, 이 정보가 오래되었을 수도 있다)
   • 계층 구조로 request을 전달하여 해결한다.
   • ISP마다 Local DNS name server를 가지고 있으며, 이를 찾는 방법은 다음과 같다.
     • MacOS: scutil --dns
     • Windows: ipconfig /all

3. 계층 구조에서의 위치
   • local DNS 서버는 엄격하게 말하면 계층 구조에 속하지 않는다.

DNS name resolution: iterated query

DNS 이름 해석:반복 쿼리

1. 예시 시나리오:
   • host가 반복 쿼리
     • enginerring.nyu.edu의 host가 gaia.cs.umass.edu의 IP 주소를 요청할 때

2. iterated query:
   • Client가 request을 보낸 server는 요청된 이름을 모를 경우, 다음으로 문의할 server의 이름을 응답을 보낸다.
   • "이 이름은 모른다. 그러니까 이 서버에 물어봐라"

DNS name resolution: recurisve query

1. 예시 시나리오:
   • host가 반복 쿼리
     • enginerring.nyu.edu의 host가 gaia.cs.umass.edu의 IP 주소를 요청할 때

2. Recursive query:
   • 요청한 이름의 해석을 담당하는 name server가 최종 응답을 찾기 위해 다른 name server와 통신한다.
   • 계층 구조 상위 레벨에서 큰 부하가 발생할 수 있다.
     • 모든 recursive query에 대해 상위 계층 DNS server들은 여러 번의 쿼리와 응답을 처리해야한다.

Caching, Updating DNS Records

1. DNS 캐싱(DNS Caching)
   • name server가 mapping을 학습하면, 이를 Cache에 저장한다.
   • Cache 항목은 일정 시간이 지나면 만료(TTL)된다.
   • TLD server는 일반적으로 local name server에 Cache되므로 root name server는 자주 방문되지 않는다.

2. Cache된 항목의 한계
   • 캐시된 항목이 오래(Out-Of-Date) 되었을 수 있다.(최선을 다한 이름-주소 변환)
   • host의 IP 주소가 변경되면, 모든 TTL이 만료될 때까지 인터넷 전역에서 알지 못할 수 있다.

3. 업데이트 및 알림 메커니즘
   • IETF 표준으로 제안된 업데이트/알림 메커니즘이 있다.(RFC 2136)

주요 요점

• DNS 캐싱은 성능 향상과 트래픽 감소에 도움이 되지만, 캐시된 데이터가 만료되기 전까지 최신 정보가 아닐 수 있다.
• TTL(Time To Live)은 캐시 항목이 유효한 기간을 정의한다.
• 업데이트 매커니즘은 DNS 레코드가 변경될 때 네트워크 전역에 알리기 위한 표준이다.

DNS records

DNS Record는 DNS 서버가 해당 패킷을 받았을 때 어떤식으로 처리할지를 나타내는 지침을 말한다.
간단히 말하면 DNS 상에서 도메인에 관한 설정을 하기 위해 사용되는 일련의 설정 문자라고 보면 된다.
DNS Record에서는 서버가 요청에 응답하는 방법에 대한 다양한 구문과 명령이 포함되어 있다.

DNS Record를 공부해야 하는 이유는 만일 개인 도메인을 구입하기 위해 도메인 업체 사이트에 접속해서 도메인과 내 서버 IP와 연결하려면 해당 정보가 필요하기 때문이다.

이 밖에 실 서비스의 도메인을 관리하기 위해서는 레코드의 각 특징에 대해 알아둘 필요가 있다.

DNS는 resource records(RR)를 저장하는 distributed database이다. 각 RR은 네 가지 필드로 구성된다.

1. 형식(RR Format)
   • (name, value, type, ttl) 로 구성된다.

2. DNS Recode의 종류
   • Type = A:: DNS에 저장되는 정보의 타입으로 도메인 주소와 서버의 IP 주소가 직접 매핑시키는 방법이다. 도메인 tistroy.com을 예로 들면, A record는 '티스토리 도메인은 IP 주소 121.53.105.234에 연결되어 있다.라고 말하는 역할을 한다고 보면 된다
     • A 레코드는 반드시 domain과 IP 간의 일대일 매칭이 될 필요는 없다.
     • 도메인 매핑 설정에 따라서 일대다/다대일이 될 수 있다.
     • 이름(name): 호스트 이름
     • 값(value): IP 주소
   • Type = NS(Name Server): NS 레코드는 네임 서버 레코드로 도메인에 대한 네임서버의 권한을 누가 관리하고 있는지 알려주는 레코드이다. 쉽게 말해, example.co.kr 이라는 도메인을 cafe24 업체에서 구입해서 사용하고 있다고 하면, example.co.kr 도메인을 관리하는 네임서버는 당연히 cafe24가 되게 된다.
     • 이름(name): 도메인 이름(e.g. foo.com)
     • 값(value): 해당 도메인의 권한 있는 name server의 host 이름
   • Type = CNAME(Canonical Name record):: CName 레코드는 도메인 별명 레코드라고 부르며, 도메인 주소를 또 다른 도메인 주소로 이중 매핑시키는 형태의 DNS 레코드 타입이다. 쉽게 말하면 도메인 주소로 연결한 부분에 다시 한번 도메인 주소로 연결하는 방식이다.
     • 예를 들어 daum.net 도메인이 있다고 했을 때, 이 도메인의 CNAME을 daum2.net으로 정해, 브라우저에 daum2.net을 입력하면 daum.net로 접근되는 형식이다.
     • 이름(name): 별칭 이름(www.ibm.com)
       • 값(value): 실제 이름(servereast.backup2.ibm.com)
         

         

   • Type = MX(Mail Exchanger):: MX 레코드는 메일 서버 레코드이며, 해당 도메인과 연동되어 있는 메일서버를 확인하는 데 사용하는 레코드이다. 즉, MX 레코드가 해당 도메인에 설정되어 있어야, 해당 도메인을 이메일 주소로 사용할 수 있다는 뜻이다.
     • 이름(name): 메일 서버와 연결된 도메인 이름
     • 값(value): 메일 서버의 이름

3. 예

    Type = A:
        name: www.example.com
        value: 192.0.2.1
   
    Type = NS:
        name: example.com
        value: ns1.example.com
   
    Type = CNAME:
        name: www.example.com
        value: servereast.backup2.example.com
   
    Type = MX:
        name: example.com
        value: mail.example.com

DNS protocol messages

DNS의 query와 reply message, 둘 다 같은 format을 가진다.

1. 메시지 헤더
   • 식별자: response와 request를 일치시키기 위해 사용되는 16bit 숫자
   • 플래그: 여러 플래그가 포함되어 있다.
     • query 또는 response flag
     • recursion 요청 플래그
     • recursion 사용 가능 플래그
     • authoritative(권위 있는) reply 플래그

2. questions(질문) 수: 포함된 질문 수
   • quesition section: host name, type filed 등을 포함
3. answer(응답) 수: 포함된 응답 리소스 레코드(RR)의 수
   • answer section: query에 대한 리소스 레코드가 포함
4. authority(권위) RR 수: 권위 서버에 대한 리소스 레코드의 수
   • authority section: authority server에 대한 리소스 레코드
5. additional RR 수: 추가 정보 섹션의 리소스 레코드 수
   • addtional info section: 아마 쓰일 수 있는 "helpful"한 additional info
6. 참조: RR(Resource Records)는 query에 대한 응답으로 제공되는 정보이다. 이름, 값, 타입, TTL field를 포함한다.

Inserting records into DNS

1. 도메인 이름 등록
   • "Network Utopia"라는 새로운 스타트업의 도메인 이름 networkuptopia.com을 DNS registrar(등록 기관)(e.g. Network Solutions)에 등록한다.
   • 권위 있는 이름 서버(기본 및 보조)의 이름과 IP 주소를 제공한다.

2. 등록기관의 역할
   • 등록기관은 .com 최상위 도메인(TLD) 서버에 NS 및 A 레코드를 삽입한다.
   • e.g.
     • NS Record: (networkutopia.com, dns1.networkutopia.com, NS)
     • A Record: (dns1.networkutopia.com, 212.212.212.1, A)

3. authoritative server 생성
   • local에 IP 주소 212.212.212.1을 가진 권위 있는 서버를 생성한다.
   • www.networkutopia.com에 대한 A 레코드를 생성한다.
   • networkutopia.com에 대한 MX 레코드를 생성한다.

이 과정은 도메인 이름을 DNS에 등록하고, 도메인 이름에 대한 다양한 유형의 레코드를 설정하는 전형적인 절차를 설명한다. 이를 통해 도메인 이름이 인터넷 상에서 인식되고, 이메일 및 웹 트래픽이 해당 도메인으로 올바르게 라우팅될 수 있게 한다.

DNS Security

DDoS 공격(DDoS attack)

• 루트 서버에 트래픽 폭탄(bombard root servers with traffic)

  • not successful to date: 지금까지 로트 서버에 대한 DDoS 공격이 성공하지 못했다.
  • traffic filtering: 트래픽 필터링을 통해 비정상적인 트래픽을 차단한다.
  • 로컬 DNS 서버가 TLD 서버의 IP를 캐시하여 루트 서버 우회 가능: 로컬 DNS 서버가 최상위 도메인(TLD) 서버의 IP 주소를 캐시함으로써, 루트 서버를 우회하여 직접 TLD 서버에 접근할 수 있다.

• TLD 서버에 트래픽 폭탄(bombard TLD Servers)

  • potentially more dangerous: TLD 서버에 대한 공격은 잠재적으로 더 큰 위험을 초래할 수 있다.

리다이렉트 공격(Redirect attack)

• 중간자 공격(man-in-middle):
  • DNS 쿼리를 가로챔(intercept DNS queries): 중간자 공격자는 DNS 쿼리를 가로채고 변조된 응답을 보낼 수 있다.
• DNS 중독(DNS poisoning):
  • 가짜 응답을 DNS 서버에 보내서 캐시하게 함: 공격자는 DNS 서버에 가짜 응답을 보내 이를 캐시하게 함으로써, 사용자가 잘못된 IP 주소로 리다이렉트 되게 할 수 있습니다.

DDoS에 DNS 악용(Exploit DNS for DDoS)

• 위조된 소스 주소로 쿼리 보내기(send queires with spoofed source address)
  • 타켓 IP 주소를 위조하여 쿼리를 보냄으로써, 대량의 응답 트래픽이 타켓 서버로 보내져 DDoS 공격을 유발할 수 있다.
• 증폭 필요(requires amplification):
  • 작은 쿼리로 큰 응답을 유발하는 증폭 기법을 사용하여 공격의 효과를 극대화할 수 있다.

DNSSEC(DNS Security Extensions)

• DNSSEC는 DNS에 대한 인증 및 무결성을 제공하여 DNS 중독과 같은 공격을 방지하는 데 사용된다.
• RFC 4033은 DNSSEC의 표준을 정의

P2P application

Peer-to-peer(P2P) architecture

• 항상 켜져 있는 서버가 없음: P2P 아키텍처는 항샹 켜져 있는 중앙 서버가 필요하지 않는다.
• 임의의 종단 시스템 간 직접 통신: 임의의 종단 시스템(peer)이 서로 직접 통신한다.
• peer 간 service 요청 및 제공: peer는 다른 peer로부터 서비스를 요청하여, 다른 peer에게 서비스를 제공한다. 이를 통해 자체 확장성이 이루어진다.
  • 새로운 peer가 추가될 때마다 새로운 서비스 용량과 새로운 서비스 요구가 발생한다.
    • 간헐적 연결 및 IP 주소 변경: peer는 간헐적으로 연결되며 IP주소가 변경될 수 있다.
  • 이러한 특성으로 인해 관리가 복잡해진다.

예시

• 파일 공유: BitTorrent와 같은 파일 공유 서비스
• 스트리밍: KanKan과 같은 스트리밍 서비스
• VoIP: Skype와 같은 인터넷 전화 서비스

File distribution: client-server vs P2P

Q. 'F' 크기의 파일을 하나의 서버에서 N개의 peer에게 배포하는 데 얼마나 시간이 걸리는가?

옵션1: 단일, 큰 "mega-server"를 사용하는 경우 => 이 솔루션은 확장되지 않음
- 단일 장애 지점(single point of failture): 서버가 다운되면 전체 시스템이 작동하지 않음
- 네트워크 혼잡 지점(point of network congestion): 많은 사용자가 한 서버에 접속하면 혼잡이 발생함
- 원거리 클라이언트에게 긴 경로(long path to distant client): 서버와 클라이언트 간의 거리가 멀면 전송 시간이 길어짐
- 출발지 링크를 통해 여러 비디오 복사본 전송(multiple copies of video sent over outgoing link): 서버는 여러 클라이언트에게 각각의 비디오 복사본을 전송해야함

파일 배포의 두 가지 방식 비교

• 클라이언트-서버 모델: 중앙 서버가 모든 파일을 클라이언트에게 전송
• P2P 모델: 파일을 받은 클라이언트가 다른 클라이언트에게 파일을 전송하여 분산 처리

주요 요소
- 서버 업로드 용량(us): 서버가 데이터를 업로드 할 수 있는 속도
- peer 다운로드 용량(di): 각 피어가 데이터를 다운로드할 수 있는 속도
- peer 업로드 용량(ui): 각 피어가 데이터를 업로드할 수 있는 속도
네트워크
- network with abundant bandwidth: 네트워크 자체는 대역폭이 충분하여 병목 현상이 발생하지 않음을 가정

File distribution time: client-server

client-server model에서 파일을 배포하는 데 걸리는 시간을 설명한다. 주어진 파일 크기 F를 N명의 client에게 배포하는 상황을 다루고 있다.

서버 전송(server transmission)

• 순차적으로 N개의 파일 복사본 전송
  • 서버는 각 클라이언트에게 파일을 업로드 해야한다.
  • 하나의 복사본을 전송하는 데 걸리는 시간: F/u_s
  • N개의 복사본을 전송하는 데 걸리는 총 시간: NF/u_s

클라이언트 전송(client transmission)

• 각 클라이언트는 파일 복사본을 다운로드해야 함
  • 최소 클라이언트 다운로드 속도: d_min
  • 클라이언트가 파일을 다운로드하는 데 걸리는 최소 기간: F / d_min

파일 배포 시간 공식(File Distribution Time Formula)

• 클라이언트-서버 접근 방식을 사용하여 N명의 클라이언트에게 F 크기 파일을 배포하는데 걸리는 시간

D_c-s >= max(NF/u_s , F/d_min)

• NF/u_s: 서버가 N명의 클라이언트에게 파일을 전송하는 데 걸리는 시간
• F/d_min: 각 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간

결론

• client-server 모델에서 파일 배포 시간은 N의 크기에 선형적으로 증가한다.
• 즉, client의 수가 증가할수록 서버가 각 클라이언트에게 파일을 전송하는 데 걸리는 시간이 선형적으로 증가한다.

File distribution time: P2P

P2P(Peer-to-Peer) 모델에서 파일을 배포하는 데 걸리는 시간을 설명한다. 주어진 파일 크기 F를 N명의 클라이언트에게 배포하는 상황을 다루고 있다.

서버 전송(server transmission)

• 최소 하나의 복사본 업로드 필요
  • 서버는 최소한 하나의 파일 복사본을 업로드해야 한다.
  • 하나의 복사본을 전송하는 데 걸리는 시간: F/u_s

클라이언트 다운로드(client download)

• 각 클라이언트는 파일 복사본을 다운로드해야함
  • 최소 클라이언트 다운로드 속도: d_min
  • 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간: F/d_min

클라이언트 업로드(clients upload)

• 클라이언트는 총 NF 비트를 다운로드 해야함
  • 최대 업로드 속도(최대 다운로드 속도를 제한하는 속도): u_s + ∑u_i

파일 배포 시간 공식(File Distribution Time Formula)

• P2P 접근 방식을 사용하여 N명의 클라이언트에게 파일 F를 배포하는 데 걸리는 시간
  

  

  • F/u_s: 서버가 하나의 파일 복사본을 업로드하는 데 걸리는 시간
  • F/d_min: 각 클라이언트가 파일을 다운로드하는 데 걸리는 최소 시간
  • NF/u_s+∑u_i: 모든 클라이언트가 파일의 총 NF 비트를 다운로드하는 데 걸리는 시간

결론(Conclusion)

• P2P 모델에서 파일 배포 시간은 N의 크기에 선형적으로 증가한다.
• 하지만, P2P 모델에서는 새로운 peer가 추가될 때마다 추가적인 서비스 용량을 제공하기에, 서비스 용량도 선형적으로 증가한다.

Client-server vs P2P: example

축:

• X축: 파일을 받는 클라이언트의 수
• Y축: 최소 배포 시간

조건:

• 클라이언트 업로드 속도(u): 일정
• 파일 크기(F) / 업로드 속도(u) = 1시간: 파일을 업로드하는 데 걸리는 시간
• 서버 업로드 속도(u_s) = 10u: 서버의 업로드 속도는 클라이언트 업로드 속도의 10배
• 최소 클라이언트 다운로드 속도(d_min) >= 서버 업로드 속도(u_s): 최소한 서버의 업로드 속도만큼의 다운로드 속도를 가져야함

위의 그래프는 P2P 모델이 클라이언트-서버 모델보다 파일 배포에 있어 더 효율적임을 시각적으로 보여준다. 특히 클라이언트가 많아질수록 P2P 모델의 장점이 더 두드러진다. P2P 모델에서는 클라이언트들이 서로 파일을 공유하므로, 네트워크 자원의 활용도가 높아지고 배포 시간이 단축된다.

P2P모델이 클라이언트-서버 모델보다 파일 배포에 더 효율적인 이유는 다음과 같다.

• 분산된 자원 활용: C-S는 모든 파일이 중앙 서버에서 client로 전송된다. 이는 서버의 업로드 대역폭에 큰 부담을 준다. 허나 P2P에서는 파일을 다운로드한 클라이언트들이 다시 다른 클라이언트들에게 파일을 전송하기에 서버의 부담이 크게 줄고, 네트워크 총 업로드 대역폭이 증가한다.
  
  
• 확장성: C-S는 클라이언트 수가 증가함에 따라 서버의 부담이 선형적으로 증가한다. 많은 클라이언트들이 동시에 파일을 요청하면 서버가 병목현상을 겪게 된다. P2P에서는 새로운 클라이언트가 추가될 때마다 그 클라이언트가 다른 클라이언트들에게 파일을 공유하므로, 네트워크의 자원이 자연스럽게 확장된다. 결과적으로 클라이언트 수가 증가해도 배포 효율성이 유지된다.
  
  
• 병목 현상 감소: C-S에서는 중앙 서버가 모든 클라이언트들에게 파일을 전송하므로, 서버의 업로드 용량이 병목 현상이 될 수 있다. P2P에서는 여러 클라이언트가 동시에 파일을 공유하므로, 병목 현상이 분산되고 완화된다. 네트워크 전체의 자원을 더 효과적으로 활용할 수 있다.
  
  
• 낮은 비용: C-S에서는 고성능 서버와 대역폭이 필요하며 많은 비용이 들 수 있다. P2P에서는 각 클라이언트가 자원을 공유하기에 서버의 필요성이 줄어들고, 비용이 절감된다.
  
  
• 호율적인 대역폭 사용: C-S에서는 서버와 클라이언트 간의 대역폭만 사용된다. P2P에서는 클라이언트 간에도 직접 파일을 전송하므로, 네트워크의 대역폭을 더 효율적으로 사용할 수 있다.

P2P file distribution: BitTorrent

파일 분할

• 파일은 256KB chunck로 분할됨: 큰 파일은 더 작은 256KB 단위의 청크로 나뉜다. 이 파일의 조각은 더 쉽게 공유하고 다운로드할 수 있도록 한다.

peer 간 chunck 전송

• 토랜트 내의 peer들은 파일 청크를 송수신함: 각 pear는 파일의 일부 peer를 다른 peer들과 교환한다.

트래커(tracker)

• 트래커의 역할: tracker는 torrent에 참여하는 peer들을 추적한다. tracker는 각 peer가 가지고 있는 file chunck 정보를 관리하고, 새로운 피어가 네트워크에 참여할 때 다른 peer들의 리스트를 제공한다
  • 트래커는 중앙 서버 역할을 하지만 파일 데이터를 직접 전송하지 않는다. 대신, peer들이 서로를 찾고 연결할 수 있도록 돕는다.

토렌트(torrent)

• 토렌트의 정의: 토렌트는 파일 청크를 교환하는 peer들의 그룹이다. 이 그룹 내에서 각 peer는 파일 chunck를 다운로드하고 업로드 한다.

예시

• Alice가 네트워크에 참여하는 과정
  • Alice가 토렌트에 도착한다.
  • Alice는 트래커로부터 peer들의 리스트를 얻는다.
  • Alice는 토랜트 내의 peer들과 file chunck를 교환하기 시작한다.

P2P file distribution: BitTorrent

• peer joining torrent(피어가 토렌트에 참여하는 과정)
  • 청크가 없음(has no chuncks): 새로운 peer는 처음에는 file chunck를 하나도 가지고 있지 않는다.
  • 다른 peer들로부터 청크를 축적(will accumulate them over time from other peers): 시간이 지나면서 다른 peer들로부터 file chunck를 다운로드 받아 축적하게 된다.
  • 트래커에 등록하여 피어 목록을 얻음(registers with tracker to get list of peers) : tracker에 등록하여 peer list를 얻음: tracker에 등록하여 이웃 피어들의 목록을 얻는다.
  • 이웃 peer들과 연결(connects to subset of peers 'neightbors'): peer 목록에서 일부 peer들과 연결

• while downloading(다운로드 중)
  • 업로드(uploads chuncks to other peers): 다운로드하는 동안, 피어는 자신이 다운로드한 파일 청크를 다른 피어들에게 업로드한다.

• peer may change peers(피어 변경)
  • 청크를 교환하는 피어를 변경할 수 있음(with whom it exchanges chuncks): peer는 청크를 교환하는 다른 피어들을 변경할 수 있다.
    
    

• churn(혼잡)
  • 피어는 왔다가 사라질 수 있음(peers may come and go): 피어들은 네트워크에 참여하거나 떠날 수 있음

• once peer has entire file(파일 전체를 받은 후)
  • 이기적으로 떠날 수 있음(selfishly leave): peer가 파일 전체를 다운로드한 후에 네트워크를 떠날 수 있다.
  • 이타적으로 남아있을 수 있음(altruishtically remain in torrent): pper는 이타적으로 네트워크에 남아 다른 peer들에게 파일을 계속 업로드할 수도 있다.

BitTorrent:requesting, sending file chuncks

Requesting chuncks(파일 청크 요청)

• 다양한 peer가 서로 다른 file chunck를 가짐
  • 각 peer는 서로 다른 file chunck의 하위 집합을 가지고 있다.

• 주기적으로 peer들에게 file chunck 목록을 요청
  • Alice는 주기적으로 각 peer에게 그들이 가지고 있는 file chunck 목록을 요청한다.

• 부족한 청크를 요청. 드문 청크를 우선 요청
  • Alice는 자신이 가지고 있지 않은 부족한 청크를 요청한다.
  • 이 때, 드문 청크를 우선적으로 요청한다. 이는 네트워크 전체의 균형을 맞추고 모든 청크가 고르게 배포되도록 돕는다.

sending chuncks: tit-for-tat(파일 청크 전송: 티트포텟)

• 최고 속도로 청크를 보내주는 four peer에게 chunck 전송:
  • Alice는 현재 자신에게 가장 높은 속도로 chunck를 보내주는 네 pear에게 chunck를 전송
  • 이 외의 peer들은 Alice에게 청크를 받지 못한다. 이를 choking이라고 한다.

• 매 10초마다 상위 네 피어 재평가
  • Alice는 매 10초마다 상위 네 피어를 재평가하여 변경할 수 있다.

• 매 30초마다 무작위로 새로운 피어를 선택하여 chunck 전송 시작
  • Alice는 매 30초마다 무작위로 새로운 피어를 선택하여 청크 전송을 시작한다.
  • 이를 optimistically unchoke라고 하며, 선택된 새로운 피어는 상위 네 피어에 합류할 가능성이 있다.

BitTorrent: tit-for-tat

1. Alice가 Bob을 optimistically unchoke한다.
2. Alice가 Bob의 상위 4대 공급자 중 하나가 됨(Alice becomes one of Bob's top-four providers)
3. Bob이 Alice의 상위 4대 공급자 중 하나가 됨(Bob becomes one of Alice's top-four providers)

효과

• 높은 업로드 속도(higher upload rate)
  • peer들은 더 나은 거래 파트너를 찾기 위해 노력하며, 이를 통해 file을 더 빨리 받을 수있다.
  • Alice와 Bob은 서로에게 높은 업로드 속도로 청크를 전송함으로써 파일 전송 속도를 극대화한다.

Video Streaming and content distribution networks

Video Streaming and CDNs:context(Content Delivery Network)

• 비디오 스트리밍 트래픽(stream video traffic)
  • 인터넷 대역폭의 주요 소비자(major consumer of internet bandwidth)
    • Netflix, youtube, amazon prime 등의 스트리밍 서비스는 2020년 residential ISP traffic의 80%를 차지한다.
    • 이는 비디오 스트리밍이 인터넷 트래픽의 큰 부분을 차지하고 있음을 보여준다.

• 도전 과제(Challenges)

  1. 규모(Scale)

     • 약 10억 명의 사용자에게 도달하려면 어떻게 해야 하는가?
     • 단일 mega-video server는 작동하지 않는다.
     • 이유: 단일 서버는 많은 사용자를 동시에 처리할 수 없기에 네트워크 병목 현상이 발생할 수 있다.

  2. 이질성(heterogeneity)

     • 사용자들의 다양한 능력(e.g. 유선 대 모바일, 대역폭 풍부 대 대역폭 부족)을 처리해야한다.
     • 각 사용자는 서로 다른 네트워크 환경과 장치를 사용하고 있기에, 이를 고려한 전송 방법이 필요하다.

• 해결책(solution)
  • 분산된 어플리케이션 레벨 인프라(distributed, application-level infrastructure)
    • 문제 해결을 위해서는 분산된 인프라가 필요하다.
    • CDN은 이러한 분산된 인프라의 좋은 예시로, 여러 서버에 컨텐츠를 분산시켜 사용자에게 가까운 위체에서 컨텐츠를 제공함으로써 대역폭 사용을 최적화하고, 사용자 경험을 향상시킨다.

Multimedia: video

• 비디오의 기본 개념

  • 비디오(video): 일정한 속도로 연속적인 이미지가 표시되는 시퀀스이다.
    • e.g. 1초에 24장의 이미지가 표시된다.
  • 디지털 이미지(digital image): 픽셀 배열로 구성된다.
    • 각 픽셀은 bit로 표현된다.
      
      
      
      
      
      

• Coding

  • 코딩의 목적: 이미지 내의, 이미지 간의 중복성을 사용하여 이미지 인코딩에 사용되는 비트 수를 줄인다.
    • 공간적 중복성(spatial redundancy): 이미지 내의 중복성
    • 시간적 중복성(temporal redundancy): 한 이미지에서 다음 이미지로의 중복성

• 시간 코딩(temporal conding) 예제
  • 시간적 코딩의 예(temporal coding example)
    • i + 1 프레임에서 완전한 프레임을 보내는 대신, i 프레임과 차이점만 전송한다.
    • 예를 들어, 연속된 이미지 프레임 간의 차이점만 전송하여 데이터 양을 줄인다
  • 프레임 예시(Frame Example)
    • 프레임 i와 프레임 i + 1
      • 프레임 i: 원본 이미지
      • 프레임 i + 1: 이전 프레임과의 차이점만 인코딩된 이미지.

• 비디오 인코딩 방식

  1. CBR(Constant Bit Rate)

     • 고정 비트율(constant bit rate): 비디오 인코딩 속도가 고정되어 있다.
     • 특징: 특정한 비트율로 인코딩하여 예측가능한 네트워크 대역폭 사용과 일정한 품질을 제공한다.

     
     
     

2. **VBR(Varaible Bit Rate)**
    - **가변 비트율(variable bit rate)**: 비디오 인코딩 속도가 공간적, 시간적 코딩 변화량에 따라 달라진다.
    - 특징: 인코딩 비트율이 변화하여 복잡한 장면에서는 높은 비트율을 사용하고, 단순한 장면에서는 낮은 비트율을 사용하여 효율성을 높인다.

<br><br>


- **예제**
    - MPEG(Moving Picture Experts Group) 1(CD-ROM): 1.5 Mbps의 비트율을 사용
    - MPEG 2(DVD): 3-6 Mbps의 비트율을 사용
    - MPEG 4(인터넷 사용): 64 Kbps에서 12 Mbps까지 다양한 비트율을 사용하며, 인터넷 스트리밍에 자주 사용된다.

Streaming stored video

• 간단한 시나리오(Simple Scenario)
  • 비디오 서버(video server): 저장된 비디오 파일이 있는 서버
  • 인터넷(internet): 비디오 서버와 클라이언트 간의 네트워크 경로
  • 클라이언트(client): 비디오를 스트리밍하여 재생하는 장치

• 주요 과제(Main Challenge)

  1. 서버-클라이언트 대역폭 변동(server-to-client bandwidth will vary)

     • 시간에 따라 네트워크 혼잡 수준이 변함에 따라 서버에서 클라이언트로의 대역폭이 변동한다.
     • 혼잡은 여러 위치에서 발생할 수 있다.
       • 가정 내(in house): 가정 내 네트워크 환경의 변동
       • 접속 네트워크(in access network): 인터넷 서비스 제공자(ISP)와의 접속 경로에서 발생하는 혼잡
       • 네트워크 코어(in network core): 인터넷 백본 네트워크에서 발생하는 혼잡
       • 비디오(at video server): 서버 자체의 대역폭 및 성능 문제
         
         
         
         
         
         

  2. 패킷 손실 및 지연(pacekt loss and delay)

     • 네트워크 혼잡으로 인한 패킷 손실 및 지여는 비디오 재생의 지연을 초래하거나 비디오 품질 저하를 초래한다.
     • 패킷 손실(packet loss): 데이터 패킷이 전송 도중 손실되는 현상. 비디오 스트리밍 시, 손실된 패킷은 재생 품질을 저하시킬 수 있다.
     • 지연(delay): 데이터 패킷이 목적지에 도달하는 데 걸리는 시간이 지연되는 현상. 이는 비디오 재생의 끊김을 유발할 수 있다.

<br><br>
<br><br>

아래의 그림은 저장된 비디오를 스트리밍하는 과정을 시각적으로 설명한다. 주요 단계와 관련된 네트워크 지연 및 데이터 전송을 보여준다.

주요단계

1. 비디오 녹화(video recorded)
   • 비디오가 초당 30 frame의 속도로 녹화된다.
   • 그래프의 왼쪽에서 계단 모양의 선이 비디오가 시간에 따라 기록되는 누적 데이터를 나타낸다.

2. 비디오 전송(video sent)
   • 녹화된 비디오 데이터가 서버에서 클라이언트로 전송된다.
   • network delay가 존재하며, 이는 고정된 값으로 가정한다.
   • 그래프에서 빨간색 선은 서버가 클라이언트로 비디오 데이터를 전송하는 속도를 나타낸다.

3. 비디오 수신 및 재생(video received, played out at client)
   • client는 네트워크 지연 후 비디오 데이터를 수신하고 재생한다.
   • client는 초당 30 frame의 속도로 비디오를 재생한다.
   • 그래프에서 파란색 선은 client가 비디오 데이터를 수신하고 재생하는 과정을 나타낸다.

• 스트리밍 동작(Streaming Operation)
  • 스트리밍 중(streaming): 이 시점에서 클라이언트는 비디오의 초반 부분을 재생하고 있으며, 서버는 여전히 비디오의 후반 부분을 전송하고 있다.
    • 클라이언트는 버퍼링을 통해 초반 데이터를 미리 받아 두고, 이후 데이터를 계속해서 받아 재생한다.

Streaming stored video: challenges

저장된 비디오를 스트리밍하는 과정에서 직면하는 주요 도전 과제를 설명한다.

1. 지속적인 재생 제약(Continuous Playout Constraint)

   • 재생 시작 후 원래 타이밍과 일치해야 함

     • 클라이언트가 재생을 시작하면, 재생은 원래 타이밍과 일치해야 한다.
     • 이는 사용자가 비디오를 시청할 때 끊김 없이 자연스럽게 재생되도록 하는 것을 의미한다.

     
     
     

   • network delay의 변동성(Jitter)

     • 네트워크 지연은 변동될 수 있다. 이를 Jitter라고 한다.
     • 이러한 변동성을 맞추기 위해 client-side buffer가 필요하다.
     • 클라이언트 측 버퍼는 데이터의 변동성을 흡수하여, 일정한 재생을 유지하도록 도와준다.

2. 기타 도전 과제(Other Challenge)
   • 클라이언트 상호작용(Client Interactivity)
     • 사용자는 비디오를 일시정지(Pause), 빨리 감기(Fast-forward), 되감기(Rewind), 특정 부분으로 이동(Jump throught video)할 수 있어야 한다.
       
       
       
   • 비디오 패킷 손실 및 재전송(Video Packets MayBe Lost, Retransmitted)

Streaming stored video: playout buffering

아래의 그림은 저장된 비디오 스트리밍 과정에서 재생 버퍼링이 어떻게 작동하는지를 시각적으로 설명한다. 네트워크 지연과 지터(Jitter, 지연 변동)를 보상하기 위해 클라이언트 측 버퍼링과 재생 지연을 사용하는 방법을 보여준다.

1. 비디오 전송(video transmission)
   • 고정 비트율 비디오 전송(constant bit rate video transmission)
     • 서버는 고정 비트율로 비디오 데이터를 전송한다.
     • 그래프에서 빨간색 계단선으로 나타낸다.

2. 네트워크 지연(Network Delay)
   • 변동 네트워크 지연(variable network delay)
     • 네트워크 지연은 일정하지 않고 변동될 수 있다.
     • 그래프에서 네트워크 지연으로 인해 클라이언트가 데이터를 수신하는 속도가 변동하는 것을 보여준다.

3. 비디오 수신 및 버퍼링(Video Reception and Buffering)
   • 클라이언트 비디오 수신(client video recpetion)
     • 클라이언트는 서버로부터 비디오 데이터를 수신한다.
     • 그래프에서 검은색 계단선으로 나타낸다.
   • 버퍼링된 비디오(buffered video)
     • 클라이언트는 수신된 비디오 데이터를 재생하기 전에 버퍼링한다.
     • 버퍼링된 데이터는 지연 변동을 흡수하여 일정한 재생을 보장한다.

4. 비디오 재생(Video Playout)
   • 고정 비트율 비디오 재생(constant bit rate video playout at client)
     • 클라이언트는 버퍼링된 데이터를 일정한 비트율로 재생한다.
     • 그래프에서 파란색 계단선으로 나타낸다.

• 재생 지연(Playout Delay)

  • 클라이언트 재생 지연(client playout delay)

    • 클라이언트는 네트워크 지연과 지터를 보상하기 위해 재생을 약간 지연시킨다.
    • 이는 클라이언트 측 버퍼링이 필요한 이유 중 하나이다.

Streaming multimedia: DASH

DASH(Dynamic, Adaptive Steaming over HTTP) 프로토콜을 사용한 멀티미디어 스트리밍의 개념과 작동 방식을 설명한다.

• DASH란 무엇인가?
  • DASH는 Dynamic, Adaptive, Streaming over HTTP의 약자로, HTTP를 통한 동적 적응 스트리밍을 의미한다.
    • Dynamic: 네트워크 상태에 따라 스트리밍 비트레이트를 동적으로 조정
    • Adaptive: 클라이언트의 네트워크 상황에 맞추어 최적의 비디오 품질을 제공
    • Streaming over HTTP: HTTP 프로토콜을 사용하여 비디오 스트리밍을 수행

• 서버(Server)
  • 비디오 파일을 여러 청크로 나눔(divides video file into multiple chuncks)
  • 각 청크는 각각 다른 속도로 인코딩되고 저장된다.(each chunck stored, encoded at different rates)
  • 매니페스트 파일 제공(manifest file)
    • 매니페스트 파일은 각 청크에 대한 URL을 제공한다.
    • 클라이언트는 이 매니페스트 파일을 사용하여 필요한 청크를 요청한다.

• 클라이언트(Client)
  • 주기적으로 서버-클라이언트 대역폭 측정(periodically measures server-to-client bandwidth)
  • 매니페스트 파일을 참조하여 한 번에 하나의 청크 요청(consulting manifest, requests one chunk at a time)
    • 현재 대역폭에 따라 최대 코딩 비트레이트 선택(choose maximum coding rate sustainable given current bandwidth)
    • 다른 시간대에 다른 코딩 비트레이트 선택 가능(can choose different coding rates at different points in time)

• Intelligence at Client: client는 다음을 결정한다.

  1. 청크를 언제 요청할지 결정(when to request chunk)

     • 클라이언트는 버퍼가 고갈되거나 넘치지 않도록 적절한 시점에 청크를 요청해야한다.
     • 버퍼 고갈(buffer starvation): 버퍼에 충분한 데이터가 없어서 재생이 중단되는 상황
     • 버퍼 오버플로우(buffer overflow): 버퍼에 너무 많은 데이터가 쌓여서 새로운 데이터를 저장할 공간이 없는 상황
       
       
       
       
       
       

  2. 어떤 인코딩 버퍼 레이트를 요청할지 결정(what encoding rate to request)

     • 클라이언트는 현재 사용 가능한 대역폭에 따라 더 높은 품질의 비디오를 요청할 수 있다.
     • 더 높은 대역폭이 사용 가능할 때 더 높은 품질 요청(higher quality when more bandwidth available): 클라이언트는 더 많은 대역폭이 사용 가능할 때 더 높은 인코딩 비트 레이트를 선택하여 더 좋은 품질의 비디오를 스트리밍할 수 있다.

     
     
     
     
     
     

  3. 어디서 청크를 요청할지 결정(where to request chunk)

     • 클라이언트는 자신과 "가까운" URL 서버 또는 높은 가용 대역폭을 가진 서버에서 청크를 요청할 수 있다.
     • 가까운 서버(close to client): 클라이언트와 물리적으로 가까운 서버는 일반적으로 더 짧은 응답 시간을 가진다.
     • 높은 가용 대역폭(high available bandwidth): 클라이언트는 현재 높은 대역폭을 제공할 수 있는 서버를 선택할 수 있다.

• 스트리밍 비디오의 구성요소(Streaming Video = Encoding + DASH + Playout Buffering)
  • 인코딩(Encoding): 비디오를 다양한 비트 레이트로 인코딩하여 여러 청크로 나눈다.
  • DASH: 클라이언트가 네트워크 상태에 따라 적응적으로 청크를 요청하는 프로토콜
  • 재생 버퍼링(Playout Buffering): 네트워크 지연과 지터를 보상하기 위해 클라이언트 측에서 버퍼링을 사용하여 일정한 재생을 유지한다.

Content distribution networks(CDNs)

도전 과제(Challenge): 수백만 개의 비디오 중에서 선택된 콘텐츠를 수십만 명의 동시 사용자에게 어떻게 스트리밍할 것인가?

1. 단일, Large "Mega-Server": 해결책 안됨
   • 단일 장애 지점(Single Point of Failure)
   • 네트워크 혼잡 지점(Point of Network Congestion)
   • 먼 거리의 클라이언트까지 긴 경로(Long Path to Distant Clients)
   • 나가는 링크로 비디오의 여러 복사본 전송(Multiple Copies of Video Sent Over Outgoing Link)
     • 동일한 비디오의 여러 복사본을 여러 사용자에게 동시에 전송해야 하므로, 서버의 업로드 대역폭이 크게 소모된다.

2. 지리적으로 분산된 여러 사이트에 여러 복사본 저장 및 제공(Store/Serve Multiple Copies of Videos at Multiple Geographically Distributed Sites, CDN)
   • CDN(Content Distribution Network): 비디오 컨텐츠의 여러 복사본을 다양한 지리적 위치에 분산하고 저장하고 제공하는 네트워크
   1. Enter Deep: access network 깊숙이 CDN 서버를 배치
      • 사용자에게 더 가까운 위치에 CDN 서버를 배치하여 네트워크 지연을 줄인다.
      • e.g. Akamai는 2015년 기준으로 120개국 이상에 240,000대의 서버를 배치했다.
   2. Bring Home: access network 근처(그러나 내부는 아닌)에 큰 cluster 배치
      • Limelight와 같은 회사는 더 적은 수(수십 개)의 큰 클러스터를 배치하여 관리한다.
      • 이러한 클러스터는 접속 네트워크 근처에 위치하여 접근성을 높인다.

CDN의 작동 방식(How CDNs Work)

1. 컨텐츠 저장(Content Storage)
   • CDN 노드에 컨텐츠 복사본 저장(stores copies of content at CDN nodes)
     • 예를 들어, Netflix는 MadMen의 복사본을 여러 CDN 노드에 저장한다.
     • 이러한 방식으로 컨텐츠가 여러 위치에 분산되어 저장된다.

2. 구독자의 요청(Subscriber Request)
   • 구독자가 CDN으로부터 컨텐츠 요청(subscriber requests content from CDN)
     • 구독자가 content를 요청하면, CDN은 구독자를 가까운 복사본으로 안내한다.
     • 구독자가 가까운 CDN 노드에서 컨텐츠를 가져온다.

3. 네트워크 경로 혼자 시 대체 복사본 선택(Altername Copy Selection)
   • 네트워크 경로가 혼잡한 경우 다른 복사본 선택(may choose different copy if network path congested)
     • 네트워크 경로가 혼잡할 경우, CDN은 구독자가 다른 경로의 다른 복사본으로 선택하도록 안내할 수 있다.
     • 이를 통해 네트워크 혼잡을 피하고 더 빠르게 컨텐츠를 제공할 수 있다.
       

       

CDNs와 OTT(Over the Top)

1. OTT란 무엇인가?
   • OTT(Over the Top): 인터넷을 통해 제공되는 컨텐츠 서비스를 의미한다. 예를 들어, Netflix와 같은 서비스가 이에 해당합니다.
     • 인터넷 호스트 간 통신 서비스(Internet host-host communication as a service): OTT 서비스는 인터넷을 통해 호스트 간의 통신을 서비스로 제공한다.

2. CDN의 역할(Role of CDN)
   • CDN 노드에 컨텐츠 복사본 저장(Stores copies of content at CDN nodes)
     • e.g. Netfilx는 "MadMen"의 복사본을 여러 CDN 노드에 저장한다.
     • 여러 위치에 컨텐츠를 저장하여 사용자에게 더 가까운 곳에서 컨텐츠를 제공할 수 있다.

3. OTT 도전 과제(OTT Challenges): 혼잡한 인터넷 대처(Coping with a Congested Internet)
   • 어떤 CDN 노드에서 컨텐츠를 가져올 것인가?(From which CDN node to retrieve content?)
     • 사용자 요청 시, 최적의 CDN 노드를 선택하여 컨텐츠를 가져와야 한다.
   • 혼잡 시 시청자의 행동(Viewer behavior in presence of congestion)
     • 네트워크가 혼잡할 때, 시청자가 어떻게 행동할 것인지 예측해고 대처해야한다.
   • 어떤 컨텐츠를 어떤 CDN 노드에 배치할 것인가?
     • 효율적인 컨텐츠 전송을 위해 각 CDN 노드에 어떤 컨텐츠를 배치할지 결정해야 한다.
       

       

CDN content access: a closer look

절차(Procedure)

1. Bob이 비디오 URL을 받음(클라이언트 요청)
   • Bob은 netcinema.com 웹 페이지에서 비디오 URL(http://netcinema.com/6Y7B23V)을 받는다.

2. Bob의 local DNS server를 통해 URL을 확인(DNS 확인)
   • Bob의 local DNS 서버에 http://netcinema.com/6Y7B23V의 DNS 요청을 보낸다.

3. netcinema의 DNS가 CNAME을 반환(CNAME 반환)
   • netcinema의 권한 있는 DNS 서버가 CNAME(http://KingCDN.com/NetC6y&B23V)을 반환한다.
   • CNAME은 해당 컨텐츠가 kingCDN에 저장되어 있음을 나타낸다.

4. kingCDN의 권한 있는 DNS 서버로 요청 전달(request forwarded to KingCDN's authoritative DNS)
   • Bob의 Local DNS 서버는 KingCDN의 권한 있는 DNS 서버로 요청을 전달한다.

5. KingCDN 서버의 IP 주소 반환(최종 IP 주소 확인,returns IP address of KingCDN server)
   • KingCDN의 권한 있는 DNS 서버가 KingCDN 서버의 IP 주소를 반환한다.

6. kingCDN 서버에서 비디오 요청(컨텐츠 스트리밍, request video from KingCDN server)
   • Bob은 KingCDN 서버로부터 HTTP를 통해 비디오를 요청하고 스트리밍을 시작한다.

Case study: Netflix

1. Netflix 계정 관리(Bob manages Netflix account)
   • Bob은 Netflix 등록 및 계정 서버를 통해 자신의 계정을 관리한다.

2. Netflix 비디오 탐색(Bob browses Netflix video)
   • Bob은 Netflix 웹사이트나 앱을 통해 원하는 비디오를 탐색한다.

3. 매니페스트 파일 요청 및 반환(Manifest file, requested returned for specific video)
   • Bob이 특정 비디오를 선택하면, 매니페스트 파일 요청되는 반환된다.
   • 매니페스트 파일에는 비디오의 여러 버전에 대한 정보와 해당 파일들이 저장된 위치(CDN 서버)가 포함되어 있다.

4. DASH 서버 선택 및 스트리밍 시작(DASH server selected, contacted, streaming begins)
   • DASH 서버가 선택되고 연결되며, 스트리밍이 시작된다
   • Bob의 기기는 네트워크 상태에 따라 최적의 비디오 품질을 선택하여 스트리밍을 시작한다.
     
     
     

• Amazon 클라우드(Amazon cloud)
  • 비디오의 여러 버전이 Amazon 클라우드에 업로드되고, 이 버전들이 CDN 서버에 복사된다.
• CDN servers
  • 여러 CDN 서버에 비디오 복사본이 저장되어 있어, 사용자에게 가장 가까운 서버에서 비디오를 제공할 수 있다.
  • 이를 통해 네트워크 지연을 최소화하고 스트리밍 성능을 최적화한다.

Socket programming with UDP and TCP

Socket programming

• 목표: 소켓을 사용하여 통신하는 클라이언트/서버 어플리케이션을 구축하는 방법을 배우는 것
• Socket: 어플리케이션 프로세스와 end-end trasport protocol 사이의 문 역할

Socket Programming

두 가지 소켓 유형(Two Socket Types)

1. UDP(User Datagram Protocol)
   • 특징: 신뢰할 수 없는 데이터그램 전송
   • 설명: 데이터그램을 전송할 때 신뢰성, 순서 보장 및 흐름 제어가 제공되지 않는다. 즉, 데이터가 손실되거나 순서가 뒤바뀔 수 있다
   • 용도: 실시간 어플리케이션(e.g. 비디오 스트리밍, 온라인 게임)에서 주로 사용된다.

2. TCP(Transmission Control Protocol)
   • 특징: 신뢰할 수 있는 바이트 스트림 지향 전송(reliable, byte stream-oriented)
   • 설명: 데이터 전송의 신뢰성, 순서 보장 및 흐름 제어를 제공한다. 데이터가 올바른 순서로 도착하고 손실되지 않도록 보장
   • 용도: 파일 전송, 이메일, 웹 브라우징 등에서 주로 사용된다.

어플리케이션 예제(Application Example)

1. 클라이언트가 키보드로부터 데이터 읽기: 클라이언트는 키보드에서 문자열 데이터를 읽어 서버로 전송한다.

2. 서버가 데이터를 수신하고 대문자로 변환: 서버는 클라이언트로부터 데이터를 수신한 후, 해당 문자열을 대문자로 변환

3. 서버가 수정된 데이터를 클라이언트로 전송: 서버는 수정된 데이터를 클라이언트로 다시 전송한다.

4. 클라이언트가 수정된 데이터를 수신하고 화면에 표시: 클라이언트는 수정된 데이터를 수신하여 화면에 표시

Socket programming with UDP

Features of UDP

1. 연결 없음(No Connection)
   • 클라이언트와 서버 간의 "연결"이 없음(No "connection" between client & server)
     • 데이터 전송 전에 연결을 설정하지 않는다.
     • handshaking 과정이 없다. : 데이터를 전송하기 전에 연결을 설정하거나 확인하는 과정이 없다.

2. 데이터 전송 방법(Data Transmission Method)
   • Sender
     • 각 패킷에 명시적으로 IP 목적지 주소와 포트 번호를 첨부한다.
     • IP 목적지 주소와 포트 번호 첨부
   • Receiver
     • 수신한 패킷에서 보낸 쪽의 IP 주소와 포트 번호를 추출한다.

3. 데이터 전송의 신뢰성(Reliability of Data Transmission)
   • 전송된 데이터는 손실되거나 순서가 뒤바뀔 수 있다.
     • 데이터가 전송되는 동안 손실되거나 순서가 뒤바뀔 수 있다.
     • UDP는 신뢰성, 순서 보장, 흐름 제어 등의 기능을 제공하지 않는다.

어플리케이션 관점(Application Viewpoint)

• UDP는 신뢰할 수 없는 데이터그램 전송을 제공(UDP provides unreliable transfer of groups of bytes "datagrams")
  • UDP는 클라이언트와 서버 간에 바이트 그룹("datagram")을 신뢰할 수 없는 방식을 전송
  • 데이터가 손실되거나 순서가 뒤바뀔 수 있지만, 이로 인해 실시간 애플리케이션에서는 높은 성능을 제공할 수 있다.

Client/Server Socket interaction: UDP

서버 측 과정(Server Side Process)

1. 소켓 생성(Create Socket)
   • 서버 소켓 생성: 'serverSocket = socket(AF_INET, SOCK_DGRAM)'
     • AF_INET: IPv4 인터넷 프로토콜 사용
     • SOCK_DGRAM: 데이터그램 소켓(UDP)을 사용
       
       
2. 데이터그램 수신(Read Datagram)
   • 데이터그램을 서버 소켓에서 읽기:'read datagram from serverSocket'
     • 클라이언트가 보낸 데이터그램을 수신한다.

3. **응답 작성 및 전송(Write Reply)** - 클라이언트 주소와 포트 번호를 지정하여 응답 작성: 'write reply to **serverSocket** specifying client address, port number' - 클라이언트로 응답을 전송한다.

클라이언트 측 과정(Client Side Process)

1. 소켓 생성(Create Socket)

   • 클라이언트 소켓 생성: clientSocket = socket(AF_INET, SOCK_DGRAM)
     • AF_INET: IPv4 인터넷 프로토콜 사용
     • SOCK_DGRAM: 데이터그램 소켓(UDP)을 사용
       
       

2. 데이터그램 생성 및 전송(Create and Send Datagram)

   • 서버 IP와 포트 번호로 데이터그램 생성 후 전송: 'Create Datagram with server IP and prot=x; send datagram via clientSocket'
     • 서버의 IP 주소와 포트 번호를 지정하여 데이터그램을 생성하고 전송
       
       

3. 데이터그램 수신(Read Datagram)

   • 클라이언트 소켓에서 데이터그램 읽기: 'Read Datagram from clientSocket'
     • 서버가 보낸 응답 데이터그램을 수신
       
       

4. 소켓 닫기(Close Socket)

   • 클라이언트 소켓 닫기: 'close clientSocket'
     • 데이터 통신이 완료되면 클라이언트 소켓을 닫는다.

Example App: UDP Client

Python UDP 클라이언트(Python UDP Client): Python을 사용하여 UDP 클라이언트를 구현하는 예제

1. 소켓 라이브러리 포함(Include Python's socket library)
   • 'from socket import *': python의 소켓 라이브러리를 포함

2. 서버 이름 및 포트 번호 설정(Set Server Name and Port Number)
   • 'serverName = hostname' : 서버의 호스트 이름을 설정
   • 'serverPort = 12000' : 서버의 포트 번호를 설정

3. UDP 소켓 생성(Create UDP Socket)
   • 'clientSocket = socket(AF_INET, SOCK_DGRAM)'
     • AF_INET: IPv4 인터넷 프로토콜을 사용
     • SOCK_DGRAM: UDP 소켓을 사용한다.

4. 사용자 입력 받기(Get User Keyboard Input)
   • 'message = raw_input('Input lowercase sentence:')
     • 사용자로부터 소문장 문장을 입력받습니다.

5. 서버 이름과 포트를 메시지에 첨부하여 소켓에 전송(Attach Server Name and Port to Message and Send into Socket)

   • 'clientSocket.sendto(message.encdoe(), (serverName, serverPort))'
     • 메시지를 UTF-8로 인코딩하고, 서버 이름과 포트 번호를 지정하여 소켓을 통해 전송
       

6. 소켓에서 응답 문자 읽기(Read Reply Characters from Socket into String)

   • 'modifiedMessage, serverAddress = clientSocket.recvfrom(2048)':
     • 서버로부터 수신된 응답 메시지를 읽고, 서버 주소를 받습니다.
     • 2048은 버퍼 크기를 의미한다.

7. 수신된 문자열 출력 및 소켓 닫기(Print Out Received String and Close Socket)
   • 'print modifiedMessage.decode()'
     • 수신된 메시지를 UTF-8로 디코딩하여 출력한다.
   • clientSocket.close()
     • 클라이언트 소켓을 닫는다.

Example App: UDP Server

Python UDP Server

1. 소켓 라이브러리 포함(Include Python's Socket Library)
   • 'from socket import *': Python의 소켓 라이브러리를 포함한다.

2. 서버 포트 번호 설정(Set Server Port Number)
   • 'serverPort = 12000' : 서버가 사용할 포트 번호를 설정한다.

3. **UDP 소켓 생성(Create UDP Socket)** - 'serverSocket = socket(AF_INET, SOCK_DGRAM)' - 'AF_INET': IPv4 인터넷 프로토콜을 사용한다. - 'SOCK_DGRAM': UDP 소켓을 사용한다.

4. 소켓을 로컬 포트 번호에 바인딩(Bind Socket to Local Port Number)
   • 'serverSocket.bind(("", serverPort))'
     • 서버 소켓을 로컬 포트 번호(12000)에 바인딩한다.
     • 빈 문자열 '""'은 모든 네트워크 인터페이스에서 수신을 허용한다.

5. 서버 준비 상태 출력(Print Server Ready Message)
   • 'print("the server is ready to receive")'
     • 서버가 준비되었음을 알리는 메시지를 출력

6. 무한 루프를 실행(Loop Forever)
   • while True:
     • 서버는 무한 루프를 실행해서 계속해서 클라이언트의 요청을 처리한다.

7. UDP 소켓에서 메시지를 읽고 클라이언트 주소 얻기(Read from UDP Socket into Message, Getting Client's Address)
   • 'message, clientAddress = serverSocket.recvfrom(2048)'
     • 클라이언트로부터 메시지를 수신하고, 클라이언트의 주소(IP와 포트 번호)를 얻는다.
     • 2048은 버퍼의 크기를 의미

8. 메시지를 대문자로 변환(Convert Message to Uppercase)
   • modifiedMessage = message.decode().upper()
     • 수신된 메시지를 UTF-8로 디코딩하고, 대문자로 변환

9. 변환된 메시지를 클라이언트로 전송(Send Uppercase String Back to Client)
   • 'serverSocket.sendto(modifiedMessage.encode(), clientAddress)'
     • 변환된 메시지를 UTF-8로 인코딩하여 클라이언트의 주소로 전송

Socket Programming with TCP

Client Must Contact Server(클라이언트가 서버에 연락해야함)

1. Server Process Must First Be Running(서버 프로세스가 먼저 실행 중이어야 함)
   • 서버는 클라이언트의 연결 요청을 수락할 준비가 되어 있어야 한다.
2. Server Must Have Created Socket That Welcomes Client's Contact(서버가 클라이언트의 연락을 환영하는 소켓을 생성해야 함)
   • 서버는 클라이언트의 요청을 수락할 수 있는 소켓을 생성해야 한다.

Client Contacts Server By(클라이언트가 서버에 연락하는 방법)

1. Creating TCP Socket(TCP 소켓 생성)
   • 클라이언트는 서버 프로세스의 IP 주소와 포트 번호를 지정하여 TCP 소켓을 생성
2. When Client Creates Socket(클라이언트가 소켓을 생성할 때)
   • 클라이언트의 TCP는 서버의 TCP와 연결을 설정한다.

When Contacted by Client(서버가 클라이언트로부터 연락을 받으면)

1. Server TCP Creates New Socket for Server Process to Communicate with Taht Particular Client(서버 TCP는 특정 클라이언트와 통신하기 위해 새로운 소켓을 생성함)
   • 서버는 여러 클라이언트와 동시에 통신할 수 있도록 새로운 소켓을 생성
   • Allows Server to Talk with Multiple Client(여러 클라이언트와 통신 가능)
   • Source Port Numbers Used to Distinguish Clients(소스 포트 번호를 사용하여 클라이언트를 구분)
     • 각 클라이언트는 고유한 소스 포트 번호를 사용하여 구분된다.

어플리케이션 관점(Application Viewpoint)

• TCP Provides Reliable, In-Order Byte-Stream Transfer(TCP는 신뢰할 수 있는 순차적 바이트 스트림 전송을 제공함)
  • TCP는 클라이언트와 서버 간에 신뢰할 수 있고 순서가 보장된 바이트 스트림 전송을 제공
  • 파이프 역할(Pipe): TCP 연결은 클라이언트와 서버 간의 파이프 역할을 한다.

Client/Server Socket Interaction: TCP

서버 측 과정

1. 소켓 생성(Create Socket)
   • 'serverSocket = socket()'
     • 서버는 수신 요청을 위해 포트 번호 'x'에 소켓을 생성
       
       
2. 수신 연결 요청 대기(Wait for Incoming Connection Request)
   • 'connectionSocket = serverSocket.accept()`
     • 서버는 클라이언트로부터 연결 요청을 기다린다.
     • 연결 요청이 오면, accept() method를 통해 새로운 소켓 'connectionSocket'을 생성하여 클라이언트와 통신을 시작
       
       
3. 요청 읽기(Read Request)
   • 'read request from connectionSocket'
     • 클라이언트로부터 요청을 'connectionSocket'을 통해 읽는다.
       
       
4. 응답 작성 및 전송(Write Reply)
   • 'write reply to connectionSocket'
     • 클라이언트에게 응답을 작성하여 connectionSocket을 통해 전송한다.
       
       
5. 연결 소켓 닫기(Close Connection Socket)
   • 'close connectionSocket'
     • 통신이 끝나면 connectionSocket을 닫는다.
       
       
       

클라이언트 측 과정(Client Side Process)

1. 소켓 생성 및 연결(Create Socket and Connect)
   • clientSocket = socket()
     • 클라이언트는 서버의 호스트 ID와 포트 번호 'x'에 연결하기 위해 소켓을 생성
   • connect to hostid, port=x
     • 생성된 소켓을 서버의 호스트 ID와 포트 번호에 연결한다.
       
       
2. 요청 전송(Send Request)
   • send request using clientSocket
     • 클라이언트는 clientSocket을 사용하여 서버에 요청을 전송한다.
       
       
3. 응답 수신(Read Reply)
   • read reply from clientSocket
     • 서버로부터 응답을 clientSocket을 통해 수신한다.
       
       
4. 클라이언트 소켓 닫기(Close Client Socket)
   • close clientSocket
     • 통신이 끝나면 clientSocket을 닫는다.

Example app: TCP client

1. 소켓 라이브러리 포함
   • from socket import *
     • Python의 소켓 라이브러리를 포함한다.
       
       
2. 서버 이름 및 포트 번호 설정
   • serverName = 'servername'
     • 서버의 호스트 이름을 설정
   • serverPort = 12000
     • 서버의 포트 번호를 설정
       
       
3. TCP 소켓 생성
   • clientSocket = socket(AF_INET, SOCK_STREAM)
     • AF_INET: IPv4 인터넷 프로토콜을 사용
     • SOCK_STREAM: TCP 소켓을 사용한다.
       
       
4. 서버에 연결
   • clientSocket.connect((serverName, serverPort))
     • 서버의 호스트 이름과 포트번호를 지정하여 TCP 연결을 설정한다.
       
       
5. 사용자 입력 받기
   • sentence = raw_input('Input lowercase sentence')
     • 사용자로부터 소문자 문장을 입력받는다.
       
       
6. 메시지 전송
   • clientSocket.send(sentence.encode())
     • 입력된 문장을 UTF-8로 인코딩하여 서버로 전송한다.
       
       
7. 응답 수신
   • modifiedSentence = clientSocket.recv(1024)
     • 서버로부터 응답을 수신합니다.
     • 1024는 버퍼 크기를 의미한다.
       
       
8. 응답 출력 및 소켓 닫기
   • print('From Server: ', modifiedSentence.decode())
     • 서버로부터 수신한 응답을 UTF-8로 디코딩하여 출력합니다.
   • clientSocket.close()
     • 클라이언트 소켓을 닫는다.

Example app: TCP server

• serverSocket.bind(('', serverPort))
  • 서버 소켓을 지정된 포트 번호에 바인딩한다.
  • 빈 문자열 '""'은 모든 네트워크 인터페이스에서 수신을 허용한다.
    
    
• serverSocket.listen(1)
  • 서버는 들어오는 연결 요청을 대기한다.
  • '1'은 대기열의 최대 연결 수를 설정한다.

Chapter 2: Summary

important Themes

1. 중앙 집중식 vs 분산형
   • 중앙 집중식: 하나의 중앙 서버가 모든 클라이언트 요청을 처리
   • 분산형: 여러 서버가 요청을 분산 처리
2. 무상태 vs 상태 유지
   • 무상태: 각 요청이 독립적이며, 서버는 이전 요청의 상태를 유지하지 않음
   • 상태 유지: 서버가 이전 요청의 상태를 유지하여 연속적인 요청을 처리
3. 확장성
   • 시스템이 증가하는 요청을 처리할 수 있는 능력
   • 시스템의 성능을 저하시키지 않으면서 더 많은 클라이언트와 데이터를 처리할 수 있어야 함
4. 신뢰성 vs 비신뢰성 메시지 전송
   • 신뢰성: 데이터가 손실되지 않고, 순서대로 정확하게 전달됨
   • 비신뢰성: 데이터 손실 가능성, 순서 보장 없음
5. 네트워크 엣지의 복잡성
   • 네트워크 말단 장치들이 더 많은 처리와 기능을 수행하게 되는 경향

Application layer: overview

• Network Application의 Principle
• Web and HTTP
• E-mail, SMTP, IMAP
• The Domain Name System: DNS
• P2P Application
• Video Streaming, Content distribution networks
• UDP와 TCP를 활용한 Socket Programming

Our Goal

1. application-layer protocol의 개념적 및 구현 측면

   • transport-layer service model
   • client-server paradigm
   • peer-to-peer paradigm

2. 유명한 application-layer protocol을 이해

   • HTTP
   • SMTP, IMAP
   • DNS

3. programming network applications

   • socket API

Some network Apps

• social networking
• Web
• Text Messaging
• E-mail
• Multi-user Network Games
• Streaming Stored Video(YouTube, Hulu, Netflix)
• P2P file sharing
• void over IP(e.g. Skype)
• Real-time video Conferencing
• Internet Search
• Remote Login
  ...

Creating a network app

1. Network Application Program의 원칙
   • Network Application Program은 서로 다른 end system에서 실행되는 프로그램으로 구성된다.
   • 이러한 program은 network를 통해 통신하며, 예를 들어 web server software가 browser software와 통신하는 방식이다.
   • network core device에 대한 software를 작성할 필요가 없으며, network core device는 사용자 응용 프로그램을 실행하지 않는다.
   • end system의 application은 빠른 app development, propagation을 허용한다.

Client-Server Program

Server

• server는 항상 켜져 있는 host로, permanent IP address를 가진다. 종종 data center에서 확장을 위해 사용된다.

Client

• server와 통신을 시도한다.
• 간헐적으로(intermittently)으로 연결될 수 도 있고, 동적(dynamic)인 IP 주소를 가질 수 있다.
• client는 서로 직접 통신하지 않는다.
• e.g. HTTP, IMAP, FTP

Peer-peer architecture

• 항상 켜져 있는 server가 없으며, 임의의 end system이 직접 통신을 한다.

• peer는 다른 peer에게 service를 요청하고, 다른 peer에게 service를 제공한다.

  • self scalability(셀프 확장성): 새로운 peer가 새로운 service 용량과 수요를 가져오므로 자체 확장성이 있다.

• peer는 간헐적으로 연결되며 IP 주소가 변경될 수 있다.

• e.g. P2P file sharing

Processes Communicating

Process

• Process: host 내에서 실행되는 program이다.
• 동일한 Host 내에서 두 Process가 통신할 때는 OS에서 정의한 Inter-Process Communication을 사용한다.
• 다른 Host에 있는 Process들은 Message를 교환함으로써 통신한다.
• P2P architecture를 가진 application은 client process와 server process를 가진다.
  • Client와 Server
    • Client Process: 통신을 시작하는 process이다.
    • Server Process: client로부터 통신 요청을 기다리는 process이다.

Sockets

소켓의 개념

• socket은 process가 network를 통해 meesage를 보내고 받을 수 있도록 하는 통신 종점이다.
• socket은 문(door)와 유사하게, process가 message를 socket을 통해 밖으로 내보내면, 네트워크의 다른 쪽에 있는 socket으로 전달된다.

소켓의 동작 방식

• sending process는 message를 socket을 통해 내보내고, transport infrastructure를 통해 receiving process의 socket에 전달한다.
• 각 통신에는 두 개의 소켓이 관여한다. 하나는 송신 측에 있고, 다른 하나는 수신 측에 있다.

• 프로세스와 소켓: 네트워크 응용 프로그램에서 각 프로세스는 자신만의 소켓을 가지고 있으며, 이 소켓을 통해 다른 프로세스와 통신한다.

• transport infrastructrue: 메시지는 sending process에서 receiving process로 이동하는 동안 네트워크의 transport infrastructure(e.g. internet)를 통과한다. sending process는 이 transport infrastructure를 통해 message가 올바른 receiving process에게 전달되기를 기대한다.

• 두 개의 소켓: 통신에는 항상 두 개의 소켓이 관여한다. 하나는 송신 프로세스의 소켓이고, 다른 하나는 수신 프로세스의 소켓이다. 이러한 방식으로 프로세스 간의 메시지 교환이 이루어진다.

Addressing Processes

process identifier

• message를 받기 위해, process는 고유한 identifier를 가져야한다.
• host device는 고유한 32bit IP address를 가진다.

IP address와 port number

• IP address만으로는 host 내의 특정 process를 식별하기에 충분치 않다.
• identifier는 IP address와 host의 process와 연관된 port number를 포함해야 한다.

즉, identifier는 IP address와 host에서의 process와 연관된 port number를 반드시 포함해야 한다.

예시 포트 번호

• HTTP server: port number 80
• mail server: port number 25

message 전송 예시

• HTTP 메시지를 특정 웹 서버(e.g. gaia.cs.umass.edu)로 보내기 위해서는 IP 주소와 포트 번호가 필요하다.
• e.g. IP 주소 128.119.245.12, 포트번호 80

An Application-Layer Protocol Defines

응용 계층 프로토콜이 정의하는 다양한 요소들을 설명한다.
응용 계층 프로토콜이 네트워크 통신에서 어떤 역할을 하고, 어떻게 정의되는지를 설명한다.
각 프로토콜은 메시지의 유형, 구문, 의미, 그리고 교환 규칙을 명확히 하여, 서로 다른 시스템 간의 통신을 원활하게 한다.
또한 오픈 프로토콜과 독점 프로토콜의 차이점도 강조하고 있다.

• Types of Message Exchanged(메시지 유형)

  • e.g. request, response와 같은 다양한 유형의 메시지들을 정의한다.

• Message Syntax(메시지 구문)

  • 메시지 내의 필드가 무엇인지, 그리고 필드가 어떻게 구분되는지를 정의한다.

• Message Semantics(메시지 의문)

  • 각 필드에 담긴 정보의 의미를 정의한다.

• Rules for Message Exchange(메시지 교환 규칙)

  • process가 언제, 어떻게 메시지를 보내고 응답하는지에 대한 규칙을 정의한다.

• Open Protocols(오픈 프로토콜)

  • RFC(인터넷 표준 문서)에 정의되어 있으며, 모든 사람이 접근할 수 있다.
  • 이러한 protocol은 상호운용성(interoperability)을 제공한다.
  • e.g. HTTP, SMTP

• Proprietary Protocols(독점 프로토콜)

  • 특정 기업이나 조직에 의해 소유되며, 일반적으로 공개되지 않는다.
  • e.g. Skype

What Transport Service Does an App Need?

어플리케이션이 네트워크를 통해 데이터를 전송할 때 필요로 하는 다양한 서비스 요구사항을 설명한다.

• Data Integrity(데이터 무결성)
  • 일부 어플리케이션(e.g. 파일 전송, 웹 트랜잭션)은 100% 신뢰할 수 있는 데이터 전송이 필요하다.
  • 다른 어플리케이션(e.g. 오디오)은 일부 손실을 허용할 수 있다.

• Timing(타이밍)
  • 인터넷 전화, 대화형 게임 등 일부 어플리케이션은 낮은 지연 시간(low delay)이 필요하다.

• ThroughtPut(처리량)
  • 네트워크를 통해 전송되는 데이터의 양을 시간 단위로 측정한 것이다. 이는 네트워크 성능의 중요한 지표 중 하나로, 특정 기간 동안 성공적으로 전송된 데이터의 양을 나타낸다.
  • 멀티미디어와 같은 일부 어플리케이션은 '효과적'이기 위해 최소한의 처리량이 필요하다.
  • 다른 어플리케이션("elastic apps")은 가능한 모든 처리량을 활용할 수 있다.
    • elastic apps: 네트워크 환경의 변화에 유연하게 대응하여 사용자가 최적의 경험을 할 수 있도록 설계된 어플리케이션을 의미한다. 이러한 어플리케이션은 네트워크 자원을 효율적으로 사용하고, 변동하는 네트워크 조건에 적응함으로써 안정적인 서비스를 제공한다.
    • 예를 들어, 웹 브라우징, 비디어 스트리밍, 파일 다운로드가 있다.

• Security(보안)
  • 암호화, 데이터 무결성 등 보안 기능이 필요하다.

Trasnport Service Requirements: Common Apps

Internet Transport Protocols Services

• TCP Service
  • Reliable Transport(신뢰할 수 있는 전송)
    • TCP는 송신, 수신 프로세스 간의 데이터 전송을 신뢰할 수 있게 만든다.
  • Flow Control(흐름 제어)
    • 송신자가 수신자를 압도하지 않도록 한다.
    • 송신자가 수신자의 처리 능력을 초과하지 않도록 조절하는 메커니즘이다.
    • 이는 데이터 전송 속도를 조절하여 수신자가 데이터 패킷을 처리할 수 있는 시간을 확보해 주는 역할을 한다.
  • Congestion Control(혼잡 제어)
    • 네트워크가 혼잡할 때 송신자를 조절한다.
    • 네트워크 내의 데이터 전송량이 과도해져서 네트워크 성능이 저하되지 않도록 조절하는 메커니즘이다.
  • Connection-Oriented(연결 지향)
    • 클라이언트와 서버 프로세스 간의 설정이 필요하다.
  • 제공하지 않는 기능
    • 타이밍, 최소 처리량 보장(minimum throughtput guarantee), 보안을 제공하지 않는다.

• UDP Service
  • Unreliable Data Transfer(신뢰할 수 없는 데이터 전송)
    • 송신 프로세스와 수신 프로세스 간의 데이터 전송을 신뢰 할 수 없다.
  • 제공하지 않는 기능
    • 신뢰성, 흐름 제어, 혼잡 제어. 타이밍, 처리량 보장, 보안, 연결 설정을 제공하지 않는다.
  • Q. 왜 UDP를 사용하는가?
    • 특정 상황에서 UDP가 TCP보다 더 적합한 경우가 있기 때문이다.

Internet Transport Protocols Services

Securing TCP

기본(Vanilla) TCP & UDP Sockets

• 암호화 없음(encryption): 기본 TCP 및 UDP 소켓은 데이터를 암호화하지 않는다.
• 평문(ClearText) 비밀번호: 평문(ClearText) 비밀번호가 소켓을 통해 전송되며, 인터넷을 통해 평문으로 전달된다.

TLS(Transport Layer Security, 전송 계층 보안)

• 암호화된 TCP 연결: TLS은 TCP 연결을 암호화하여 데이터의 기밀성을 보장한다.
• 데이터 무결성(data integrity): TLS는 데이터 무결성을 제공하여 데이터가 전송 중에 변경되지 않았음을 보장한다.
• End-Point Authentication(종단 인증): TLS은 통신하는 양쪽 종단의 신원을 확인한다.

TLS의 구현

• Application Layer에서 구현
  • TLS는 application layer에서 구현되며, 응용 프로그램은 TLS 라이브러리를 사용해 TCP를 통해 보안 통신을 수행한다.
• TLS Socket API
  • 평문 데이터(ClearText)가 socket을 통해 입력되면, TLS는 이를 암호화하여 인터넷을 통해 암호화된 상태로 전송한다.

Web and HTTP

• 웹 페이지는 여러 개의 Object로 구성된다. 각 Object는 다른 웹 서버에 저장될 수 있다.
• Object는 HTML 파일, JPEG image, Java applet, audio file 등 다양한 유형이 될 수 있다.
• 웹 피이지는 base HTML file로 구성되며, 이 HTML 파일은 여러 referenced objects를 포함한다. 각 객체는 URL을 통해 접근할 수 있다.

HTTP overview

HTTP: HyperText Transfer Protocol

• Web's application layer protocol

• client/server model
  • Client: HTTP 클라이언트는 웹 브라우저이다. 이는 HTTP Protocol을 사용하여 웹 object를 request하고 receive하여, 이를 "display"한다.
  • Server: HTTP 서버는 request에 response하여 HTTP Protocol을 사용하여 web object를 보낸다.

• HTTP uses TCP

  • Client가 TCP 연결을 시작한다.

    • 클라이언트 소프트웨어(e.g. web browser)는 TCP socket을 생성한다.
    • 소켓은 네트워크 통신의 종점(endpoint) 역할을 하며, 네트워크를 통해 데이터를 송수신하는 interface를 제공한다.
    • 클라이언트는 연결할 서버의 IP 주소와 포트 번호를 통해 TCP 연결을 한다.(HTTP 서비스의 기본 포트는 80)

  • Server는 Client로 부터 TCP connection을 수락한다.

    • Server는 Client의 TCP connection 요청을 받아들인다.

  • HTTP Message 교환

    • 웹 브라우저(HTTP Client)와 웹 서버(HTTP Server) 간에 HTTP Message가 교환된다.

  • TCP 연결 종료

    • HTTP message 교환 후, TCP connection은 닫힌다.

• HTTP is "stateless"

  • 서버는 이전 클라이언트 요청에 대한 정보를 유지하지 않는다.

    • HTTP는 상태를 유지하지 않는 프로토콜이기에, 서버는 이전 클라이언트 요청에 대한 정보를 기억하지 않는다.

  • 상태(state)를 유지하는 프로토콜의 복잡성

    • 상태(state)를 유지하는 프로토콜은 복잡하다.
    • 과거의 history(state)를 유지해야 하고, 서버나 클라이언트가 충돌(crash)하면 그들의 "state"가 일치하지 않을 수 있으며 이를 조정해야한다.

HTTP connections: two types

HTTP 연결의 두 가지 주요 유형인 non-persistent와 persistent

Non-Persistent HTTP(비지속성 HTTP)

• 과정:
  1. 클라이언트는 서버와 TCP 연결을 연다.
  2. 단 하나의 객체가 TCP 연결을 통해 전송된다.
  3. TCP 연결이 닫힌다.
• 특징:
  • 여러 객체를 다운로드하려면 여러 TCP 연결이 필요하다
  • 각 객체마다 새로운 TCP 연결을 설정해야 하므로 오버헤드가 증가한다.

Persistent HTTP(지속성 HTTP)

• 과정
  1. 클라이언트는 서버와 TCP 연결을 연다.
  2. 단일 TCP 연결을 통해 여러 객체를 전송할 수 있다.
  3. 모든 객체가 전송된 후에 TCP 연결이 닫힌다.
• 특징
  • 하나의 TCP 연결로 여러 객체를 전송할 수 있어 오버헤드가 줄어든다.
  • TCP 연결을 반복해서 열고 닫는 시간을 절약할 수 있다.

Non-persistent HTTP: example

User enters URL: www.someSchool.edu/someDepartment/home.index (containing text, references to 10 jpeg images)

1. 사용자가 URL을 입력한다.
   • e.g. www.someSchool.edu/someDepartment/home.index

2. HTTP 클라이언트가 TCP 연결을 시작한다.
   • HTTP 클라이언트는 www.someSchool.edu의 HTTP 서버 프로세스(포트 80)로 TCP 연결을 시작한다.
   • 클라이언트는 TCP 소켓을 생성하여 서버의 포트 80에 연결 요청을 보낸다.

3. 서버가 TCP 연결을 수락한다.
   • www.someSchool.edu의 HTTP 서버는 포트 80에서 TCP 연결 요청을 수락한다.
   • server는 client에 연결이 수락되었음을 알린다.

4. HTTP request message 전송
   • HTTP 클라이언트는 TCP connection socket을 통해 URL을 포함한 HTTP request message를 전송한다.
   • message는 클라이언트가 someDepartment/home.index 객체를 요청하고 있음을 나타낸다.

5. HTTP 요청 메시지 수신
   • HTTP 서버는 request message를 receive하고, 요청된 객체를 포함한 HTTP response message를 작성하여 자신의 소켓을 통해 보낸다.

6. TCP 연결 종료
   • HTTP 서버는 응답 메시지를 보낸 후 TCP 연결을 닫는다.

7. HTTP response message receive
   • HTTP client는 HTML 파일을 포함한 response message를 수신하고, 이를 표시한다.
   • HTML 파일을 파싱하면서, 클라이언트는 10개의 참조된 JPEG 객체를 찾는다.

8. 각 JPEG Object에 대한 반복 과정
   • Client는 10개의 JPEG 객체 각각에 대해 앞에서 설명한 1-5단계를 반복한다.
   • 각 객체마다 새로운 TCP 연결이 설정되고, 객체가 전송된 후 연결이 종료된다.

Non-Persistent HTTP: Response Time

RTT(Round-Trip Time)

• 정의: clinet에서 server로 작은 패킷이 이동하고, 다시 서버에서 클라이언트로 돌아오는 데 걸리는 시간

HTTP Response Time

• Non-Persistent HTTP의 경우, 각 object에 대한 response time은 다음과 같이 구성된다.

1. TCP 연결 초기화: TCP 연결을 설정하는 데 하나의 RTT가 필요하다.
2. HTTP 요청 및 첫 번째 응답 바이트 수신: HTTP request를 보내고, 첫 번째 몇 바이트의 HTTP response을 받는 데 하나의 RTT가 필요하다.
3. 객체/파일 전송 시간: 객체나 파일을 전송하는 데 필요한 시간이다. 나머지 객체를 수신하는 데 추가 시간이 걸린다.

이를 통해 Non-Persistent의 response Time은 다음과 같이 계산된다.

Non-persistent HTTP response time = 2 * RTT + file transmission time

Persistent HTTP(HTTP 1.1)

Non-Persistent의 문제점

1. 2개의 RTT 필요
   • 각 객체마다 2개의 RTT(Round-Trip Time)가 필요하다. 첫 번째의 RTT는 TCP 연결을 설정하는데, 두 번째는 HTTP 요청을 보내고 응답을 받는 데 사용된다.
2. 운영체제 오버헤드
   • 각 TCP 연결을 설정하고 해제하는 과정에서 운영체제의 오버헤드가 발생한다.
3. 병렬 연결
   • 많은 웹 브라우저는 여러 개의 참조 객체를 병렬로 가져오기 위해 여러 개의 TCP 연결을 동시에 연다. 이는 네트워크 리소스를 많이 사용하게 된다.

Persistent HTTP

1. 연결 유지

   • 서버는 응답을 보낸 후 TCP 연결을 유지한다. 이를 통해 동일한 클라이언트와 서버 간의 후속 HTTP message는 기존의 열린 연결을 통해 전송된다.

2. 참조된 객체 요청

   • 클라이언트는 referenced object를 마주할 때마다 즉시 요청을 보낼 수 있다. 이는 HTTP 요청을 발견하는 즉시서버에 요청할 수 있게 하여 대기시간을 줄인다.

3. RTT 감소

   • 모든 referenced object에 대해 단일 RTT가 필요하다. 이는 Non-Persistent에 비해 응답 시간을 절반으로 줄일 수 있다.

HTTP request message

• HTTP message에는 두 타입이 존재한다. request, response
• HTTP reqeust message
  • ASCII(human-readable format)

'\r\n'은 carriage return, line feed를 나타내며, 줄의 끝을 표시한다.

• carriage return(\r, CR) : 텍스트의 줄을 끝내고 커서를 현재 줄의 처음으로 이동시키는 역할
• line feed(\n, LF) : 텍스트의 줄을 끝내고 커서를 다음 줄로 이동시키는 역할

1. Request Line
   • 요청 라인은 다음과 같은 형식으로 구성된다. "method URL version"
   • e.g. GET /index.html HTTP/1.1
   • method: 클라이언트가 수행하고자 하는 동작을 지정한다. 일반적으로 사용되는 method에는 'GET', "POST', 'HEAD' 등이 있다.
   • URL: 요청하는 resource의 path를 지정한다.
   • version: 사용 중인 HTTP의 version을 지정한다.

2. Header Lines
   • 요청에 대한 추가적인 정보를 제공한다.
   • 각 헤더 라인은 'header filed name: value'의 형식으로 구성된다.

     Host: www-net.cs.umass.edu
     User-Agent: Firefox/3.6.10
     Accept: text/html,application/xhtml+xml
     Accept-Language: en-us,en;q=0.5
     Accept-Encoding: gzip,deflate
     Accept-Charset: ISO-8859-1,utf-8;q=0.7
     Keep-Alive: 115
     Connection: keep-alive

3. Blank Line
   • header section의 끝을 나타낸다.
   • 빈 줄 이후에는 실제 데이터(entitiy body)가 올 수 있다. GET 요청의 경우 entity body가 없다.

     GET /index.html HTTP/1.1\r\n
     Host: www-net.cs.umass.edu\r\n
     User-Agent: Firefox/3.6.10\r\n
     Accept: text/html,application/xhtml+xml\r\n
     Accept-Language: en-us,en;q=0.5\r\n
     Accept-Encoding: gzip,deflate\r\n
     Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
     Keep-Alive: 115\r\n
     Connection: keep-alive\r\n
     \r\n

HTTP Request Message: General Format

Other HTTP request message

HTTP Request message: web server에 특정 resource를 요청하는 클라이언트(e.g. web browser)에 의해 생성된다. 이 message는 ASCII 텍스트 형식으로 작성되어 사람이 읽을 수 있다.

POST method

• 사용 사례: 웹 페이지에서 사용자 입력을 서버로 전송할 때 사용된다.

• 동작 방식: 사용자 입력 데이터를 HTTP POST 요청 메시지의 entity body에 포함시켜 서버로 보낸다.

• e.g.

    POST /path/to/resource HTTP/1.1
    Host: www.example.com
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 27
  
    field1=value1&field2=value2

GET method(for sending data to server)

• 사용 사례: 사용자 데이터를 URL 필드로 포함시켜 서버로 전송할 때 사용된다.
• 동작 방식: 데이터는 URL의 Query String에 포함된다.
• e.g.

    GET /animalsearch?monkeys&banana HTTP/1.1
    Host: www.somesite.com

HEAD method

• 사용 사례: 특정 URL에 대한 header만 요청만 할 때 사용된다.
• 동작 방식: 서버는 지정된 URL에 대해 HTTP GET 요청을 했을 때 반환될 header만을 응답한다.
• e.g.

    HEAD /index.html HTTP/1.1
    Host: www.example.com

PUT method

• 사용 사례: 서버에 새 파일을 업로드하거나 기존 파일을 대체할 때 사용된다.

• 동작 방식: 지정된 URL에 있는 파일을 POST 요청 메시지의 entity 본문 내용으로 완전히 대체한다.

• e.g.

    PUT /newfile.txt HTTP/1.1
    Host: www.example.com
    Content-Type: text/plain
    Content-Length: 11
  
    Hello world

HTTP response message

HTTP response message의 구성

1. Status Line
   • 형식: HTTP-version statusCode statusPhrase
   • e.g. HTTP/1.1 200 OK
   • HTTP-version: 사용된 HTTP의 version
   • statusCode: 요청의 처리 결과를 나타내는 3자리 숫자
   • statusPhrase: 상태코드에 대한 설명

2. Header Lines
   • response에 대한 추가적인 정보를 제공
   • 각 헤더 라인은 'header field name : value' 형식으로 구성
   • e.g.

       Date: Sun, 26 Sep 2010 20:09:20 GMT
       Server: Apache/2.0.52 (CentOS)
       Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT
       ETag: "17dc6-a5c-bf716880"
       Accept-Ranges: bytes
       Content-Length: 2652
       Keep-Alive: timeout=10, max=100
       Connection: Keep-Alive
       Content-Type: text/html; charset=ISO-8859-1

3. Blank Line
   • header section의 끝을 나타냄

4. Data
   • 요청된 객체의 실제 데이터가 포함된다. e.g. 요청된 HTML 파일의 내용

HTTP response status codes

• status code는 response message의 첫 번째 줄에 나타난다.
  • e.g. HTTP/1.1 200 OK

1. 200 OK
   • 의미: 요청이 성공적으로 처리되었으며, 요청된 객체가 메시지에 포함된다.
   • 예시: 클라이언트가 웹 페이지를 요청했을 때, 서버가 해당 페이지를 성공적으로 찾고 반환할 때 사용된다.
2. 301 Moved Permanently
   • 의미: 요청된 객체가 영구적으로 다른 위치로 이동되었다. 새 위치는 응답 메시지를 Location header field에 지정된다.
   • 예시: 특정 URL의 컨텐츠가 다른 URL로 영구적으로 이동된 경우 사용된다.
3. 400 Bad Request
   • 의미: 서버가 요청 메시지를 이해할 수 없다. 이는 요청 메시지가 잘못되었을 때 발생한다.
   • 예시: 클라이언트가 잘못된 형식의 요청을 보낼 때 사용된다.
4. 404 Not Found
   • 의미: 요청된 문서를 서버에서 찾을 수 없다.
   • 예시: 클라이언트가 존재하지 않는 페이지를 요청했을 때 사용된다.
5. 505 HTTP Version Not Supported
   • 의미: 서버가 요청 메시지에서 사용된 HTTP 버전을 지원하지 않는다.
   • 예시: 클라이언트가 서버가 지원하지 않는 버전의 HTTP를 사용하여 요청을 보냈을 때 사용된다.

Trying out HTTP(client side) for yourself

HTTP 클라이언트 측 직접 실행

1. Telnet을 사용하여 웹 서버에 연결하기

   • telnet을 사용하여 HTTP 서버의 기본 포트(80)로 TCP 연결을 연다.
   • e.g. telnet gaia.cs.umass.edu 80
     • 이는 gaia.cs.umass.edu 서버의 80번 포트에 TCP 연결을 연다.

2. GET HTTP 요청 입력

   • telnet 연결이 성공하면, GET 요청을 입력할 수 있다.
   • e.g.

       GET /kurose_ross/interactive/index.php HTTP/1.1
       Host: gaia.cs.umass.edu

   • 'Host' header는 요청하는 host의 이름을 지정한다. HTTP/1.1에서는 필수이다.
   • 요청을 보낸 후, carriage return과 line-feed를 두 번 입력하여 request를 완료한다.

3. HTTP 응답 메시지 확인

   • server는 요청에 대한 응답 메시지를 반환한다.

   • 응답 메시지는 상태 라인, 헤더 라인, 그리고 선택적으로 데이터 본문으로 구성된다.

     HTTP/1.1 200 OK
     Date: Mon, 27 Jul 2009 12:28:53 GMT
     Server: Apache/2.2.14 (Win32)
     Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
     Content-Length: 88
     Content-Type: text/html
     Connection: Closed
     
     <html>
     <body>
     <h1>It works!</h1>
     </body>
     </html>

Maintaining User/Server State: Cookies

Recall :HTTP GET/response interaction is stateless. 그렇기에 서버는 각각의 HTTP 요청이 독립적인 것으로 간주한다.
이를 해결하기 위해 Cookie가 등장했다.

HTTP의 Stateless의 특성

1. 상태 비유지(Stateless)

   • HTTP 요청/응답 상호작용은 독립적(independent)이다. 각 요청은 독립적으로 처리되며, 이전 요청이나 이후 요청의 상태를 추적하지 않는다.
   • e.g. 클라이언트가 서버에 HTTP GET 요청을 보내고 서버가 응답을 반환하면, 이 요청과 응답의 상태는 다른 요청/응답에 영향을 주지 않는다.

2. 다단계 교환(multi-step exchange) 없음

   • HTTP는 다단계 교환(multi-step exchange)의 개념이 없다. 즉, 웹 '트랜잭션'을 완료하기 위해 여러 HTTP 메세지를 주고받는 과정에서 "state"를 추적하지 않는다.
   • 클라이언트와 서버는 다단계 교환의 상태를 추적할 필요가 없으며 각 HTTP 요청은 독립적이다.

3. 복구(recover) 필요 없음

   • 부분적으로 완료된 트랜잭션이 완전히 완료되지 않은 경우에도 클라이언트와 서버는 이를 '복구'할 필요가 없다.
   • 이는 요청이 실패하거나 중단될 때 시스템의 복잡성을 줄이는 데 도움이 된다.

a stateful protocol

• 상태를 유지하는 protocol에서는 클라이언트와 서버는 연속적인 요청과 응답의 상태를 추적한다.

• 예를 들어, DB transaction에서는 다음과 같은 상태 유지 특성이 필요하다.

• 상태 유지(Stateful)

  • client가 두 가지 변경 사항을 X에 적용하려고 시도한다고 가정해보자. Stateful protocol에서는 이러한 변경 사항이 모두 적용되거나 전혀 적용되지 않아야 한다.
  • 이는 부분적으로 적용된 변경 사항이 시스템 일관성을 해치지 않도록 보장한다.

• 예상 시나리오

  • 클라이언트가 X를 X'로, 그리고 X'를 X''로 두 단계로 X라는 state를 변경하려고 한다.
  • 이러한 변경은 연속적인 단계로 이루어져야 하며, 상태가 연속적으로 유지되어야 한다.
  • Q. 만일 t' 시점에서 네트워크 연결이 중단되거나 클라이언트가 충돌(crash)하면 어떻게 되는가?
    • 클라이언트가 첫 번째 변경을 완료하고 두 번째 변경을 시작하려는 순간(t')에 중단되면, X' 상태가 완료되지 않거나 불완전한 상태로 남게된다.

• 상태 유지의 필요성

  • 클라이언트는 두 단계의 변경이 모두 완료되거나 전혀 완료되지 않아야 한다. 이는 트랜잭션의 원자성을 보장한다.

Cookie의 역할

• 상태 유지: HTTP는 기본적으로 상태를 유지하지 않는 프로토콜이다. 즉, 서버는 클라이언트의 이전 요청을 기억하지 않는다. 쿠키는 이 문제를 해결하기 위해 사용되며, 서버와 클라이언트간의 상태를 유지하는 데 도움을 준다.
• 사용자 식별: 쿠키는 사용자를 식별하는 데 사용된다. 이를 통해 사용자의 세션을 유지하고 맞춤형 경험을 제공할 수 있다.

Cookie의 구성 요소

1. 쿠키 헤더 라인(HTTP response message)
   • 서버는 HTTP response message의 'Set-Cookie' header를 통해 클라이언트에 쿠키를 설정한다.
   • e.g. 'Set-Cookie: sessionID=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT; Path=/; Domain=.example.com'

2. 쿠키 헤더 라인(next HTTP request message)
   • 클라이언트는 이후의 HTTP request message에 'Cookie' header를 포함시켜 서버에 쿠키를 보낸다.
   • e.g. 'Cookie: sessionID=abc123'

3. Cookie file(클라이언트 측)
   • client의 browser는 server로부터 받은 Cookei를 local file에 저장한다.
   • 이는 브라우저가 관리하며, 각 쿠키는 도메인, 경로, 만료 시간 등의 속성을 가진다.

4. backend database(서버 측)
   • server는 각 클라이언트에 대한 상태 정보를 백엔드 데이터베이스에 저장한다.
   • 쿠키는 클라이언트를 식별하는 키 역할을 한다.

Example

1. Susan은 노트북의 browser로 특정한 e-commerce site에 처음으로 방문한다.
2. 첫 번째 HTTP request가 site에 도착하면, site는 unique ID(Cookie)를 생성하고, 이를 백엔드 데이터베이스에 저장한다.
3. 서버는 'Set-Cookie' header를 통해 클라이언트에 쿠키를 설정한다.
4. Susan이 동일한 site를 다시 방문하면, browser는 cookie를 포함한 HTTP request을 서버에 보낸다.
5. Server는 Cookie ID를 통해 사용자를 식별하고, 백엔드 데이터베이스에서 해당 사용자 정보를 검색한다.
6. 이를 통해 Server는 사용자가 이전에 방문했던 정보를 바탕으로 맞춤형 서비스를 제공할 수 있다.

HTTP cookies: comments

쿠키의 주요 용도

1. Authorization(인증)
   • 사용자가 웹사이트에 로그인하면, 서버는 사용자를 식별하기 위해 쿠키를 설정한다. 이후 요청마다 클라이언트는 쿠키를 서버에 전송하여 사용자를 인증한다.

2. Shopoing Carts(쇼핑 카드)
   • 사용자가 온라인 쇼핑몰에서 아이템을 장바구니에 추가할 때, 쿠키를 사용하여 아이템 목록을 저장한다. 이를 통해 사용자가 다른 페이지로 이동하거나 브라우저를 닫았다가 다시 열어도 장바구니의 상태를 유지할 수 있다.

3. Recommendations(추천 시스템)
   • 웹사이트는 사용자의 방문 기록과 활동을 추적하여 개인화된 추천 컨텐츠를 제공한다. 이는 쿠키를 통해 사용자의 선호도와 관심사를 저장하고 분석하여 가능해진다.

4. User Session State(사용자 세션 상태)
   • web mail 등과 같은 어플리케이션에서 사용자의 세션 상태를 유지하는데 사용된다. 쿠키를 통해 사용자의 세션이 지속되어, 로그인 상태가 유지되고, 작업이 중단되지 않는다.

Challenge: How to keep state

• protocol endpoint에서의 상태유지: 송신자와 수신자가 여러 트랜잭션 동안 상태 정보를 유지하는 것을 의미한다. 이는 네트워크 통신의 일관성을 보장하고, 각 트랜잭션이 이전 트랜잭션의 문맥을 인식할 수 있도록 한다.
• Cookie를 사용한 상태 유지: Cookie는 HTTP 메시지를 통해 상태 정보를 전달하고 유지하는 데 사용된다.

Cookie and Privacy

• 쿠키는 웹사이트가 사용자의 활동을 추적하고 많은 정보를 수집할 수 있게 한다.
• e.g. 쿠키를 사용하면 웹사이트는 사용자가 방문한 페이지, 클릭한 링크, 검색한 내용 등을 기록할 수 있다.
• 이는 사용자 경험을 개선하는 데 도움이 되지만, 사용자 privacy를 침해할 수 있는 문제점도 있다.

Example: displaying a NY Times Web page

NY Times(뉴욕 타임즈) 웹 페이지 표시

1. 사용자가 nytimes.com에 HTTP GET request를 보낸다.
2. server는 HTTP 응답으로 HTML 파일을 보낸다.
3. HTTP 파일은 AdX.com과 같은 광고 서버로부터 광고를 가져오는 링크를 포함한다.
4. 브라우저는 광고 서버에 HTTP GET 요청을 보낸다.
5. 광고 서버는 광고 데이터를 반환한다.
6. 브라우저는 웹 페이지와 광고를 조합하여 사용자에게 표시한다.

Example: tracking a user's browsing behavior

주요 요소

1. nytimes.com(sports): 사용자가 방문한 웹사이트
2. AdX.com: 광고 서버, 사용자가 직접 방문하지 않았지만, 광고를 제공하는 제 3자 서버
3. 사용자의 브라우저: nytimes.com을 방문하는 클라이언트
4. Cookie(쿠키): 웹사이트가 사용자 브라우저에 저장하는 작은 데이터 파일. 여기서 두 가지 유형의 쿠키가 사용된다.
   • First-Party 쿠키: 사용자가 방문한 웹사이트(nytimes.com)가 설정한 쿠키
   • Third-Party 쿠키: 사용자가 직접 방문하지 않은 제 3자 웹사이트(AdX.com)가 설정한 쿠키

단계별 과정

1. HTTP GET 요청(nytimes.com)

   • 사용자가 nytimes.com의 스포츠 페이지를 방문
   • 브라우저가 nytimes.com 서버에 HTTP GET 요청을 보냄

2. HTTP 응답(Set-cookie: 1634)

   • nytimes.com 서버는 HTTP 응답과 함께 첫 번째 쿠키(1634)를 설정
   • 이 쿠키는 nytimes.com이 설정한 first-party 쿠키이다.

3. 광고 요청(HTTP GET, Referrer: NY Times Sports)

   • nytimes.com 페이지에 포함된 광고를 로드하기 위해 브라우저가 AdX.com 서버에 HTTP GET 요청을 보낸다.
   • 이 request에는 참조 정보(Referrer)로 NY Times Sports 페이지가 포함된다.

4. HTTP 응답(Set-Cookie: 7493)

   • AdX.com 서버는 HTTP 응답과 함께 두 번째 쿠키(7493)를 설정한다.
   • 이 쿠키는 AdX.com이 설정한 third-party 쿠키이다.

Example: tracking a user's browsing behavior

쿠키와 사용자 추적

1. 예시 시나리오
   • 세 개의 웹 사이트가 등장한다. nytimes.com, AdX.com, 그리고 socks.com.
   • 사용자가 nytimes.com을 방문
     • 사용자가 nytimes.com에 접속하면, 이 웹 사이트는 AdX.com과 같은 광고 제공자의 컨텐츠나 광고를 포함할 수 있다.
     • 이 상호작용 동안 쿠키가 설정된다. 예를 들어 AdX.com은 사용자의 브라우징 정보를 기반으로 특정 쿠키를 설정할 수 있다.

2. 쿠키의 역할

   • First-party Cookie

     • 사용자가 직접 방문한 웹사이트(nytimes.com)에서 설정된다.
     • e.g. nytimes.com에서 설정된 쿠키 1634: sports, 2/15/22

   • Third-party Cookie

     • 사용자가 직접 방문하지 않은 제3의 웹사이트('AdX.com')에서 설정된다.
     • e.g. AdX.com에서 설정된 쿠키 7493: NY Times Sports, 2/15/22

3. 다른 웹사이트 방문
   • 사용자가 'socks.com'을 방문하면, 이 사이트의 요청이 'AdX.com'으로 전달되고, 쿠키 정보가 포함된다. (Referrer: socks.com, cookie: 7493)
   • 응답: AdX.com은 socks.com에서의 활동을 추적하고 관련 쿠키 정보를 업데이트한다.(Set cookie:7493)

4. 추적 목적
   • AdX.com은 사용자가 여러 사이트에서 방문한 정보를 추적한다.
   • 이를 통해 사용자의 브라우징 기록을 기반으로 타켓 광고를 제공할 수 있다.

Cookies: tracking a user's browsing behavior(one day later)

1. 이전 방문 기록
   • 사용자가 'nytimes.com'을 방문했고, 이 때 'AdX.com'의 Cookie ID '1634'을 설정했다.
   • 이후 사용자가 'socks.com'을 방문하면서 'AdX.com'의 Cookie ID '7493'이 설정되었다.

2. 하루 후, 사용자가 nytimes.com 다시 방문
   • 이번에는 'nytimes.com'의 '예술 섹션(arts)'을 방문한다.
   • 웹 브라우저는 이전에 설정된 쿠키들을 포함하여 HTTP request를 보낸다. 즉, 'nytimes.com'과 'AdX.com' 모두 이전에 설정된 쿠키들을 사용하여 사용자를 인식한다.

3. 쿠키를 통한 맞춤형 광고 제공
   • 'AdX.com'은 사용자가 'socks.com'에서 설정된 쿠키를 통해 사용자가 이전에 'socks.com'을 방문했음을 알고 있다.
   • 그 결과, 'nytimes.com'의 예술 섹션을 볼 때 'socks.com'과 관련된 광고가 표시된다.

Web Caches(Proxy Servers)

proxy servers(웹 캐시) 는 웹 브라우저와 원본 서버 사이에 위치하여 웹 요청을 처리하는 중간 서버이다.
proxy server의 목표는 client request를 original server가 관여하지 않고 수행하는 것이다.
이는 응답 시간을 줄이고, 네트워크 트래픽을 줄이며, 서버 부하를 줄이는 데 도움을 준다.

웹 캐시(proxy server)

1. 웹 캐시 설정

   • 사용자가 브라우저를 구성하여 웹 캐시를 사용하도록 설정한다.
   • 이 설정 후 브라우저는 모든 HTTP 요청을 웹 캐시로 보낸다.

2. 캐시에 객체가 있는 경우

   • 요청한 객체가 캐시에 이미 저장되어 있으면, 캐시는 해당 객체를 클라이언트에게 반환한다.
   • 이 과정에서 원본 서버와의 통신이 필요하지 않다.

3. 캐시에 객체가 없는 경우

   • 요청한 객체가 캐시에 없으면, 캐시는 원본 서버에 요청을 보낸다.
   • 원본 서버로부터 객체를 수신한 후, 캐시는 해당 객체를 저장한 다음 클라이언트에게 반환한다.

Cookies: Tracking a User's Browsing Behavior

쿠키의 용도

1. First Party Cookies(첫 번째 쿠키)

   • 사용자가 방문한 웹사이트에서 직접 설정한 쿠키
   • 특정 웹사이트에서 사용자의 행동을 추적하는 데 사용됨

2. Third Party Cookies(세 번째 쿠키)

   • 사용자가 방문하지 않은 다른 웹사이트에서 설정한 쿠키
   • 여러 웹사이트에 걸쳐 사용자의 행동을 추적할 수 있다.
   • e.g. 광고 네트워크가 여러 웹사이트에 걸쳐 사용자의 행동을 추적하여 맞춤형 광고를 제공한다.

추적 방법

• 추적이 사용자가 모르는 사이에 이루어질 수 있다.
  • e.g. 광고가 표시되는 대신 보이지 않는 링크를 통해 HTTP 요청이 전송될 수 있다.

브라우저별 쿠키 추적 방지

• Firefox와 Safari: 기본적으로 세 번째 쿠키를 통한 추적을 방지한다.
• Chrome: 2023년부터 세 번째 쿠키를 통한 추적을 방지한다.

GDPR(EU General Data Protection Regulation) and Cookies

• GDPR은 유렵 연합(EU)의 개인정보 보호규정으로, 2018년 5월 25일부터 발효되었다. 이 규정은 개인의 개인정보 보호를 강화하고, 데이터 처리 및 이동을 규제하는 것을 목적으로 한다.
• 쿠키와 GDPR
  • 쿠키는 웹사이트가 사용자의 브라우저에 저장하는 작은 데이터 파일로, 사용자 식별 및 활동 추적에 사용된다.
  • GDPR에 따르면, 쿠키가 개인을 식별할 수 있는 정보를 포함할 경우 이는 개인 데이터로 간주된다.

Web caches(proxy servers)

Web caches의 역할

1. 클라이언트와 서버 역할

   • web cache는 클라이언트와 서버로 모두 작동한다.
   • client 역할: 원본 서버에 대한 요청을 보낸다.
   • server 역할: 원래 요청한 클라이언트에게 응답을 제공한다.

2. 설치 위치

   • web cache는 주로 ISP에 의해 설치된다.
   • 이는 대학, 회사, 가정용 ISP 등 다양한 환경에서 사용된다.

Web cache의 목적

1. 응답 시간 단축: web cache는 클라이언트에 더 가까이 위치하기에 요청에 대한 응답 시간이 줄어든다.
2. 네트워크 트래픽 감소: 웹 캐시는 원본 서버로 가는 트래픽을 줄여, 네트워크의 부하를 감소시킨다.
3. 인터넷 상의 웹 캐시 밀도:
   • 인터넷은 여러 웹 캐시로 밀집되어 있다.
   • 이를 통해 소규모 컨텐츠 제공자도 효율적으로 컨텐츠를 전달할 수 있다.

Caching Example

이는 original server, public internet, 기관 네트워크 간의 상호작용을 다루며, 캐시를 이용한 웹 객체의 요청과 전송 과정을 설명한다.

1. 캐싱의 목적
   • 클라이언트 요청에 대한 응답 시간을 줄임
   • 기관의 액세스 링크에서 트래픽을 줄임
   • 컨텐츠 제공자가 더 효율적으로 컨텐츠를 제공할 수 있게함

2. 캐싱의 문제점
   • 1.54Mbps의 access link가 높은 이용률(0.97)로 인해 병목 현상이 발생한다. 이는 대기 시간이 길어짐을 의미한다.

3. 예시 시나리오
   • access link 속도: 1.54Mbps
   • 기관 라우터에서 서버까지의 RTT: 2초
   • web object의 크기: 100k bit
   • 브라우저에서 원본 서버로의 평균 요청 속도: 15/sec
   • 브라우저로의 평균 데이터 전송 속도: 1.50Mbps

4. 성능
   1. LAN 이용률: 매우 낮음(0.0015). LAN은 고속(1 Gbps)이지만, 대부분의 트래픽이 access link에서 병목되기에 실제 사용량은 매우 적다.
   2. access link 이용률: 매우 높음(0.97). 이는 트래픽이 access link에서 병목되고 있다는 것을 의미한다.
   3. 종단 간 지연
      • internet delay, access link delay, LAN delay을 모두 고려한 종단 간 지연이 발생
      • end-to-end delay = internet delay + access link delay + LAN delay = 2 sec + minutes(높은 이용률로 인해) + usecs(낮은 이용률로 인해)

Caching Example: Buy a Faster Access Link

성능을 높이기 위해 더 빠른 엑세스 링크를 구입한다. 이는 caching 대신 network의 performance를 향상시키기 위한 또 다른 접근 방식이다.

성능 개선

1. 예시 시나리오
   • access link 속도: 1.54Mbps -> 154Mbps
   • 기관 라우터에서 서버까지의 RTT: 2초
   • web object의 크기: 100k bit
   • 브라우저에서 원본 서버로의 평균 요청 속도: 15/sec
   • 브라우저로의 평균 데이터 전송 속도: 1.50Mbps

2. 성능
   1. LAN 이용률: 매우 낮음(0.0015). LAN은 고속(1 Gbps)이지만, 대부분의 트래픽이 access link에서 병목되기에 실제 사용량은 매우 적다.
   2. access link 이용률: 빠른 링크를 구입함으로써 낮아짐(0.97 -> 0.0097)
   3. 종단 간 지연
      • internet delay, access link delay, LAN delay을 모두 고려한 종단 간 지연이 발생
      • end-to-end delay = internet delay + access link delay + LAN delay = 2 sec + msec(높은 이용률로 인해) + usecs(낮은 이용률로 인해)

3. Cost

• 빠르지만 비싸진다.

Caching Example: Install a Web Cache

1. Cost : Web Cache가 훨신 싸다. 더 빠른 access link(e.g. 154 Mbps link)를 구입하는 것보다 cache 설치가 비용이 저렴하며, 종단 간 지연 시간도 낮출 수 있다.

2. 시나리오
   • access link rate: 1.54 Mbps
   • RTT: 기관 라우터에서 서버까지의 왕복 시간 2초
   • web object 크기: 100k
   • 평균 요청 속도: 초당 15회
   • 평균 데이터 전송 속도: 1.50 Mbps

3. 캐시 히트율 가정
   • 캐시 히트율: 0.4(즉, 40%의 요청이 캐시에서 처리됨)

4. access link 이용률과 delay time 계산
   1. access link 사용: 60%의 요청이 access link를 통해 원본 서버에 도달
      • data 전송 속도: 0.6 * 1.50 Mbps = 0.9 Mbps
      • 이용률: 0.9 / 1.54 = 0.58 (이전의 0.97에서 크게 감소)
   2. 종단 간 지연 시간
      • cache에서 처리되는 요청: 매우 낮은 지연(마이크로초 단위)
      • 원본 서버에서 처리되는 요청: 2.01초(internet delay + access link delay + LAN delay)
      • 평균 지연 시간 = 0.6 * (delay from origin servers) + 0.4 * (delay when satisfied at cache) = 0.6 * 2.01초 + 0.4 *(마이크로초) ≈1.2초

Conditional GET

조건부 GET의 목적

• object transmission delay 방지: cache된 version이 최신이면 object를 다시 전송하지 않음으로써 전송 지연을 방지한다.
• 링크 이용률 감소: 불필요한 데이터 전송을 줄여 네트워크 링크의 이용률을 낮춘다.

1. Cache의 역할
   • client가 HTTP 요청을 보낼 때, 캐시된 객체의 날짜를 'If-Modified-Since' header에 포함시킨다.
   • e.g. 'If-Modified-Since: <date>'

2. Server의 역할
   • Server는 Client가 보낸 요청을 확인하고, 캐시된 객체가 최신 버전이면 객체를 전송하지 않고 'HTTP/1.0 304 Not Modified' 응답을 보낸다.
   • 최신 버전이 아니면 객체를 전송하고 'HTTP/1.0 200 OK' 응답을 보낸다.

3. 예시

   • HTTP 요청 메시지

       GET /index.html HTTP/1.1
       Host: www.example.com
       If-Modified-Since: Wed, 21 Oct 2020 07:28:00 GMT

   • HTTP 응답 메시지(객체가 수정되지 않은 경우)

       HTTP/1.0 304 Not Modified

   • HTTP 응답 메시지(객체가 수정된 경우)

       HTTP/1.0 200 OK
       Content-Type: text/html
       Content-Length: 1234
     
       (객체 데이터)

HTTP/2

1. HTTP/2의 주요 목표 : HTTP/2는 다중 객체 HTTP request의 delay를 줄이는 것을 주요 목표로 하고 있다.

2. HTTP/1.1의 문제점:
   • 단일 TCP 연결에서 다중 GET request의 pipelining: HTTP/1.1에서는 여러 GET 요청을 단일 TCP 연결에서 pipeLining할 수 있다.
   • 서버의 순차 응답: 서버는 FCFS(First-Come-First_Served) 방식으로 GET 요청에 순차적으로 응답한다.
   • HOL 블로킹(Head-of-Line Blocking): FCFS으로 인해, 작은 객체가 큰 객체 뒤에 대기해야 하는 경우가 발생한다.
   • 손실 복구 문제: 손실된 TCP segment를 재전송하는 동안 객체 전송이 중단될 수 있다.

3. HTTP/2의 주요 특징
   1. 변경되지 않은 method, status code, 대부분의 header field: HTTP/1.1과 동일한 method, status code 및 대부분의 header field를 사용한다.
   2. client지정 Priority에 따른 전송: 전송 순서는 클라이언트가 지정한 priority에 따라 결정된다.(not necessarily FCFS)
   3. 미요청 object의 push: server는 client가 요청하지 않은 객체를 푸시할 수 있다.
   4. 프레임으로 객체 분할 및 전송: 객체를 frames으로 분할하고, HOL blocking을 완화하기 위해 frame 전송을 스케줄링한다.

HTTP/2: mitigationg HOL blocking

HTTP 1.1 : client가 1개의 큰 object를 request한다.(e.g. video file, and 3 smaller objects)
아래의 그림에서는 O1 뒤에 O2, O3, O4가 뒤따른다.

HTTP/2: object가 frame으로 나뉜다. frame의 전송은 interleaved하다.

HTTP/2 to HTTP/3

HTTP/2의 한계

• 단일 TCP 연결 사용: HTTP/2는 단일 TCP 연결을 사용하여 여러 객체를 전송한다. 이로 인해 패킷 손실 시 모든 객체 전송이 지연될 수 있다.
  • 패킷 손실이 발생하면 TCP 세크먼트 재전송이 필요하며 객체 전송이 지연된다.
• 다중 TCP 연결 열기: 이러한 문제를 완화하기 위해 브라우저는 여러 개의 병렬 TCP 연결을 열어 전송을 시도한다. 이는 전체적인 처리량을 증가시키기 위한 방법이다.
• 보안 문제: 기본 TCP 연결을 통한 보안이 부족하다.

HTTP/3의 주요 목표

• UDP 기반 전송: HTTP/3는 UDP를 사용하여 객체를 전송한다. 이는 패킷 손실 시 개별 객체의 오류 및 혼잡 제어를 가능하게 한다.
  • UDP를 사용함으로써 패킷 손실이 발생해도 다른 객체의 전송이 지연되지 않는다.
• 더 나은 보안: HTTP/3는 향상된 보안 기능을 제공한다.
  • 각 객체에 대한 개별적인 오류 및 혼잡 제어가 가능하여 전체 전송 성능을 취적화한다.

E-mail, SMTP, IMAP

E-mail

E-mail의 주요 구성 요소

• User Agent(사용자 에이전트): 이메일을 작성, 수정, 읽기 위한 클라이언트 소프트웨어이다.
  • e.g. Outlook, Gmail
    
    

• Mail Server(메일 서버): 이메일을 저장하고 전송하는 서버이다. SMTP(Simple Mail Transfer Protocol)를 사용하여 다른 메일 서버와 통신한다.

  
  
  

• SMTP(Simple Mail Transfer Protocol): 이메일 전송을 위한 프로토콜이다. 클라이언트가 메일 서버에 메일을 보내고, 메일 서버 간에 메일을 전송하는 데 사용된다.

E-mail:mail servers

mail servers

• mailbox: 사용자에게 도착한 이메일 메시지를 저장하는 장소이다. 각 사용자는 자신의 메일박스를 가지고 있으며, 이 메일박스에는 수신된 메시지가 저장된다.
• message queue: 발신 대기 중인 이메일 메시지를 저장하는 큐이다. 메일 서버는 이 메시지 큐에 저장된 메시지를 다른 메일 서버로 전송된다.
• SMTP Protocol: 메일 서버 간에 이메일 메시지를 전송하는 프로토콜이다. Simple Mail Transfer Protocol(SMTP)는 이메일을 보내고 받기 위해 사용된다.
  • 클라이언트: 이메일을 보내는 메일 서버
  • 서버: 이메일을 받는 메일 서버

Scenario: Alice sends e-mail to Bob

1. Alice가 사용자 에이전트(User Agents)를 사용하여 이메일을 작성한다.

   • 이메일 메시지를 작성하여 bob@someschool.edu로 보낸다.
   • Alice의 User Agents는 이메일 메시지를 Alice의 메일 서버로 보낸다.

2. SMTP(Simple Mail Transfer Protocol)

   • SMTP의 client 측은 Bob의 mail server와 TCP connection을 연다.
   • TCP connection을 통해 SMTP client는 Alice의 메시지를 Bob의 메일 서버로 전송한다.

3. Bob의 메일 서버에 도착

   • Bob의 메일 서버는 메시지를 수신하고 Bob의 mailbox에 저장한다.

4. Bob이 이메일을 확인

   • Bob은 자신의 사용자 에이전트를 사용하여 메일 서버에서 메시지를 읽는다.

E-mail: the RFC(5321)

SMTP Protocol의 사용

• TCP를 사용하여 이메일 메시지를 신뢰성 있게 전송: 클라이언트(연결을 시작하는 메일 서버)에서 서버(수신하는 메일 서버)로 TCP 연결을 통해 메시지를 보낸다. PORT 25를 사용한다.
• 직접 전송: 보내는 서버(클라이언트처럼 동작)가 받는 서버로 직접 전송한다.

이메일 전송의 세 단계

1. handshaking(greeting): 초기 연결 설정 및 인사 메시지 교환
   • 클라이언트가 서버에 TCP 연결을 연다
     • 클라이언트가 서버의 SMTP 포트(보통 25)로 TCP 연결을 연다.
     • 이 과정에서 클라이언트는 서버의 IP 주소와 포트 번호를 알고 있어야 한다.
   • 서버가 연결 요청을 수락한다.
     • 서버는 클라이언트의 연결 요청을 수락하고 초기 환영 메시지를 보낸다.
     • 이 메시지는 보통 "220" 응답 코드와 함께 서버의 도메인 이름을 포함한다.
     • e.g. 220 smtp.example.com ESMTP Postifx
   • 클라이언트가 HELO 명령을 보낸다.
     • 클라이언트는 서버에게 자신의 도메인 이름을 알리기 위해 HELO 명령을 보낸다.
     • e.g. HELO client.example.com
   • 서버가 응답한다
     • 서버는 클라이언트의 HELO 명령에 응답하여 인사말과 함께 응답한다.
     • e.g. 250 Hello client.example.com, pleased to meet you
2. trasfer of messages(메시지 전송): 이메일 메시지의 실제 전송
3. closure(연결 종료): 메시지 전송 후 연결을 종료합니다.

명령/응답 상호작용

• commands: ASCII text
• response: status code and phrase

message는 반드시 7-bits ASCI이다.

Sample SMTP interaction