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을 입력한다.



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



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



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



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



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



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



  1. 각 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을 지정한다.



  1. 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



  1. 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: 상태코드에 대한 설명


  1. 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


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


  1. 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'



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



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



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



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



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



  1. 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은 사용자의 브라우징 정보를 기반으로 특정 쿠키를 설정할 수 있다.


  1. 쿠키의 역할

    • 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


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


  1. 추적 목적
    • 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'이 설정되었다.


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


  1. 쿠키를 통한 맞춤형 광고 제공
    • '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. 캐싱의 목적
    • 클라이언트 요청에 대한 응답 시간을 줄임
    • 기관의 액세스 링크에서 트래픽을 줄임
    • 컨텐츠 제공자가 더 효율적으로 컨텐츠를 제공할 수 있게함


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


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


  1. 성능
    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


  1. 성능
    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(낮은 이용률로 인해)


  1. Cost
  • 빠르지만 비싸진다.


Caching Example: Install a Web Cache



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


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


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


  1. 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>'


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

  1. 예시

    • 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를 줄이는 것을 주요 목표로 하고 있다.


  1. 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를 재전송하는 동안 객체 전송이 중단될 수 있다.


  1. 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

'학교수업 > 컴퓨터망' 카테고리의 다른 글

Chapter4: Network Layer-Data Plane  (0) 2024.07.04
Chapter3: Transport Layer-2  (0) 2024.07.04
Chapter3: Transport Layer  (0) 2024.07.03
Chapter2: Application Layer-2  (0) 2024.07.03
Chapter1: Introduction  (0) 2024.06.30

+ Recent posts

티스토리툴바