Application Layer and HTTP

Posted on | In

[CN] Application 레이어와 HTTP 프로토콜

Principles of network applications, Web & HTTP
Reference Computer Networking A Top-Down Approach 7th-Edition

Principles of Network Applications

Application Layer는 간단하게 말해 우리가 인터넷을 통해 사용하는 모든 서비스들을 통칭한다고 볼 수 있다. 영상통화, KakaoTalk, Skype 등의 프로그램은 모두 application layer에서 동작한다. 도대체 이 구조가 어떻게 이루어져 있길래 우리가 인터넷을 통해 웹서핑을 하고 e-mail을 주고받을 수 있는 것일까?

Creating a Network App

만약 우리가 network application을 만들고 싶다면 어떻게 해야할까? 스마트폰이나 컴퓨터 등의 end system에서 network를 거쳐 통신하는 하나의 프로그램을 만드는 것과 동일하다. 한 가지 특징이 있다면 Application layer에서는 network core에서 packet을 어디로 보내야 하는지는 설계할 필요가 없다. 아래 layer에서 알아서 잘 전달할 수 있게끔 구성되어 있기 때문이다. Network를 구성하는 모든(아래) 계층의 요소를 고려할 필요가 없기 때문에, 이는 application 시장이 급속도로 발전할 수 있는 원동력이 되었다고 볼 수 있다. 이런 layer division이 없었다면.. 아마 카카오톡은 아직도 개발 중일 수도 있지 않을까.

Application Architectures

application은 크게 다음과 같이 두 가지 구조로 나눌 수 있다.

app-architectures

  • Client-Server Architecture

    1. Server (Always-on host)

      • Permanent IP address

        서비스 요청을 항시 대기중이다.

      • Data centers for scaling

        규모가 커지면 그만큼 감당해야한다.

    2. Client

      • Communicate with server

        필요할 때만 server와 통신하는 존재이다.

      • Dynamic IP address

        IP 주소는 바뀔 수 있으며, Client끼리 서로 직접적인 통신은 하지 않는다.

  • P2P(peer-to-peer) Architecture

    • No always-on server. Arbitrary end systems directly communicate

      필요한 상황에서만 end system끼리 통신한다.

    • Self scalability

      그때그때 주위 기기들이 서로 통신하기 때문에 규모가 켜저도 통신을 분산 처리, 규모에 큰 부담이 없다고 볼 수 있다.

    • Complex Management.

      관리하기는 꽤나 어렵다.

Processes Communicating

  • Process: Program running within a host.

    컴퓨터 한 대에서 자기들끼리 통신하는 것은 Inter-process communication이라 한다. 별도의 Network가 필요 없고 OS에서 담당하게 된다.

    • Client Process: Server에게 요청함으로써 통신을 개시함
    • Server Process: Service 제공을 위해 client request를 계속 기다리고 있음
    • P2P 구조에서는 end systems사이에서 client, server processes가 동시에 활용될 수 있다.

  • Sockets

    message, information을 보내기 위한 ‘문’의 개념으로 이해하면 된다.

    sockets

    드라마 ‘도깨비’에는 공유가 문을 열고 가고 싶은 곳으로 어디든 다니는 장면이 나온다. 아마 공유 자기 자신도 그 통로가 어떻게 설계되는지, 내부 구성을 모를 거다. 공유는 application layer니까! 목적지까지 어떻게 가는지는 알 수 없지만 아래 계층에서 알아서 수행해주니까, 어찌 됐던 도깨비는 자기가 가고 싶은 곳으로 가기만 하면 된다.

  • Address Processes

    그렇다면 목적지는 어떻게 정하는 것일까?

    Messages를 받기 위해 process는 identifier가 필요하다. 이 identifier는 IP와 Port numbers를 포함한다. 일반적으로 알려진 protocols의 경우, Port number가 정해져 있다.

    • HTTP server: 80 (http:// ~ port num 80번으로 요청)
    • Mail server: 25

  • Appication Layer Protocol defines

    Application 레이어에서 주로 하는 일은 아래와 같다.

    • Types of messages exchanged. 메시지가 어떤 type인지
    • Message syntax. 메시지가 어떤 구조인지
    • Message semantics. 메시지가 어떤 의미인지
    • Rules for when/how processes send & respond to messages. 어떤 방식으로 송수신하는지
    • Open protocols. 전 세계에서 사용할 수 있게끔 표준화
    • Proprietary protocols. Skype, KakaoTalk 등은 protocol이 온전히 공개된 것은 아님

  • Transport Service needed for an Application

    Application을 사용할 때 요구되는 조건들은 아래와 같다.

    • Data Integrity. 데이터가 무결한가?

      압축 파일 등, 몇몇 앱들은 error가 있으면 안된다. 반면 통화 등 지연시간이 더 중요한 App에서는 데이터가 어느 정도 손실되어도 괜찮다고 본다.

    • Timing. 지연 시간

      전화, 게임 등이 있다. 총 게임을 하는데 총을 쐈더니 총알이 1초 뒤에 나간다고 하면 상상만 해도 끔찍하다.

    • Throughput. 전송률

      동영상 등의 대용량 message를 처리하는 과정에서 중요하다.

    • Security 보안

      보안은 항상 중요한 요소이다.

      application data loss throughput time sensitive?
      File transfer/download no loss elastic no
      E-mail no loss elastic no
      Web documents no loss elastic no
      Real-time audio/video loss-tolerant aud: 5Kbps-1Mbps
      vid: 10Kbps-5Mbps      		 yes, 10’s msec
      Streaming audio/video loss-tolerant aud: 5Kbps-1Mbps
      vid: 10Kbps-5Mbps      		 yes, few secs
      Interactive games loss-tolerant Kbps+ yes, 10’s msec
      Text messaging no loss elastic yes and no

      Application에 따라 요구하는 조건들이 이렇게 다르다.

  • TCP, UDP

    TCP는 신뢰도 높은 전송, UDP는 약간 loss가 생겨도 빨리 가야 하는 경우에 사용한다. 자세한 내용은 추후 다룰 예정이다.

    어플리케이션 레이어에서 프로토콜을 만들어 전송할 때 트랜스포트에서 어떤 서비스를 가지고 어떤 프로토콜을 선택하느냐를 결정하는 것이 중요하다.

    application app-layer protocol transport protocol
    (underlying)
    E-mail SMTP [RFC 2821] TCP
    Remote terminal access Telnet [RFC 854] TCP
    Web HTTP [RFC 2616] TCP
    File transfer FTP [RFC 959] TCP
    Streaming Multimedia HTTP, RTP [RFC 1889] TCP or UDP
    Internet telephony SIP, RTP, proprietary TCP or UDP

Web and HTTP

HTTP는 HyperText Transfer Protocol의 약자로, Internet에서 주로 사용하는 protocol이며 여기에 암호화 기술을 적용한 것이 HTTPS이다.

Overview

  • Web page는 객체들(objects)로 구성되어 있다.

    HTML, JPEG, Java applet, Audio file, JavaScript, …

  • 기본적으로 어떤 문서를 보여줄거냐 하는 HTML file이 있고, 이 안에 포함된 referenced objects로 구성된다.

  • Client/Server model이다.

    Client browser에서 요청하면 web server에서 해당 객체를 제공한다. 이때 HTTP protocol이 사용된다. (request-response)

  • 웹서핑을 할 때는 일반적으로 TCP를 사용한다.

  • HTTP is “STATELESS”

    어떤 정보를 요청한 clients의 상태를 저장하고 있지는 않는다. 요청하면 요청한 대로 응답한다.

HTTP Connections

  • non-persistent HTTP

    • 한 개의 object를 보낼 때 매번 TCP connection을 만들었다가 닫았다가 함

      여러 객체를 받으려면 여러 연결을 결어야 한다. 딱 봐도 비효율적이다.

    • Client가 TCP connection request → Server acception

    • Client가 request message → Server response

    • Server close

    • 2RTT(per object) + File transmission time

      RTT란 Round Trip Time의 약자로, packet이 client에서 server를 거쳐 다시 돌아오는 왕복 시간이다.

    • OS overhead

      연결 상태를 운영체제에서 계속 관리해줘야 한다.

  • persistent HTTP

    • 한 번 connection을 만들어 놓으면 지속적으로 유지함

      기본적으로 사용하는 연결 방식이다.

    • 1RTT

HTTP Request Message

HTTP message에는 Request, Response의 두 가지 종류가 있다. HTTP request message는 ASCII로 인코딩 된 text 정보로 구성된다.

http-request

  • Uploading form input

    • Post method

      Web page에 입력 form이 있을 때 해당 form에 대한 정보를 보내줄게 ! write의 느낌이다.

    • URL method

      Get method 사용, URL field에 내가 원하는 정보를 넣을게 ! read의 느낌이다.

  • Method types (HTTP/1.0)

    • GET

    • POST

    • HEAD

      get처럼 request를 보내지만, server에서 어떤 object를 보내지는 않음. debugging 시 많이 사용한다고 한다.

    • PUT (HTTP/1.1)

      file upload

    • DELETE (HTTP/1.1)

      file delete

HTTP Response Message

Request를 받은 Server는 해당 요청에 대한 response를 보내준다.

  • Status Code

    Response message의 가장 첫 줄에 나타난다.

    • 200 OK
    • 301 Moved Permanently
    • 400 Bad Request
    • 404 Not Found 페이지를 찾을 수 없습니다…
    • 505 HTTP Version Not Supported

User-Server state: Cookies

앞서 설명한대로, HTTP는 stateless protocol이다. 그럼에도 불구하고 user의 활동, 상태를 저장해야 할 때가 있다. 예를 들어 온라인 쇼핑이나 장바구니, 자동 로그인, 사용자 추천 정보 제공 등이다. Cookie는 다음과 같이 사용된다.

  • Cookie header line of HTTP response message
  • Cookie header line in next HTTP response message
  • Cookie file kept on user’s host, managed by user’s browser
  • Back-end database at Web site

cookies

쿠키는 개발자 모드에서도 확인할 수 있다. 편리한 측면도 있는 반면에 privacy에 굉장히 민감하다고 할 수 있다. 그래서 외국 사이트에서는 대부분 cookies permission이 pop up된다고 한다.

다음 포스팅에서는 e-mail, DNS, P2P와 관련한 내용을 다뤄볼 예정이다.

Hits