[네트워크] 애플리케이션 계층

애플리케이션 구조

• 애플리케이션 구조는 크게 클라이언트-서버 구조와 P2P 구조로 나뉜다.

클라이언트-서버 구조

• 웹 서버가 클라이언트 호스트로부터 객체를 요청받으면, 웹 서버는 클라이언트 호스트로 요청된 객체를 보내 응답한다.
• 클라이언트-서버 구조에서 클라이언트끼리 서로 직접적으로 통신하지 않는다.
• 서버는 잘 알려진 주소(well-known address)라는 고정 IP 주소를 갖는다.
• 한 대의 서버로는 수많은 클라이언트 호스트를 대응할 수 없으니, 여러 호스트를 갖춘 데이터 센터(data center)가 사용된다.

P2P 구조

• P2P 구조에서는 피어(peer)라 불리는 연결된 호스트 쌍이 서로 직접 통신하도록 한다.
• 피어는 서비스 제공자(service provider)가 소유하지 않고, 사용자들이 제어하는 데스크톱 및 랩톱이다.
• 서버를 통하지 않고, 피어끼리 통신하므로, 피어-투-피어(peer-to-peer, P2P) 라 한다.

클라이언트와 서버 프로세스

• 두 프로세스 간의 통신 세션에서 통신을 초기화하는 프로세스를 클라이언트 프로세스라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버 프로세스라고 한다.
• 웹에서 브라우저는 클라이언트 프로세스이고, 웹 서버는 서버 프로세스다.
• P2P에서 파일을 내려받는 피어는 클라이언트이고, 파일을 올리는 피어는 서버다.

프로세스와 컴퓨터 네트워크 사이의 인터페이스

• 프로세스는 소켓(socket)을 통해 네트워크로 메세지를 보내고 받는다.
• 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다. 또한, 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API(Application Programming Interface)라고도 한다.

신뢰적 데이터 전송

• 신뢰적 데이터 전송은 프로토콜을 통해 데이터가 송신측에서 수신측으로 정상 도착을 보장한다는 것을 의미한다.
• 신뢰적 데이터 전송은 트랜스포트 계층 프로토콜에서 쓰인다. 트랜스포트 계층 프로토콜이 신뢰적 데이터 전송을 보장한다면, 송신 프로세스는 데이터를 소켓으로 보내고 나면, 그 데이터가 오류 없이 수신 프로세스에 잘 도착할 것이라고 믿는다.
• 만약 신뢰적 데이터 전송을 보장하지 않는다면, 데이터는 수신 프로세스에 아예 도착조차 하지 않을 수 있다. 손실 허용 애플리케이션(loss-tolerant application)은 어느 정도의 데이터 손실을 허용하는 애플리케이션을 말한다.

애플리케이션 계층 프로토콜

• HTTP, FTP, SMTP 등이 존재한다.

HTTP

• HTTP는 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언트로 웹 페이지를 어떻게 응답(전송)하는지를 정의한다.
• 사용자가 웹 페이지를 요청할 때, 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메세지를 서버로 보낸다.
• 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메세지를 클라이언트로 보낸다.
• HTTP는 TCP를 트랜스포트 프로토콜로 사용한다.
• HTTP 프로토콜은 비상태 프로토콜(stateless protocol)이라고 한다. 즉, 서버는 클라이언트에 대한 정보를 유지하지 않는다. 따라서, 만약 클라이언트가 같은 객체를 몇 초 뒤에 다시 요청하더라도, 이미 보냈다는 알림 대신 같은 객체를 다시 한 번 보내준다.

비지속 연결과 지속 연결

• 비지속 연결(non-persistent connection)은 모든 요구와 응답이 분리된 여러 TCP 연결 상에서 오가는 방식을 말한다.
• 지속 연결(persistent connection)은 모든 요구와 응답이 하나의 TCP 연결 상에서 오가는 방식을 말한다.
• 비지속 연결 HTTP
  • 각 TCP 연결은 하나의 요청 메세지와 응답 메세지만을 전송한다. 따라서, 만약 클라이언트가 10개의 HTTP 객체를 요구한다면, 10번의 TCP 연결이 성립된다.
  • 비지속 연결은 다음 두 가지 단점이 존재한다.
    1. 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
    2. 각 요청 객체는 2RTT(round-trip time, 패킷이 서버를 들러 다시 클라이언트로 돌아오는 데에 걸리는 시간)이 소요된다.
• 지속 연결 HTTP
  • HTTP 프로토콜은 비지속 연결 방식의 단점으로 인해, 1.1 버전부터는 지속 연결을 지원한다.
  • HTTP 1.1 지속 연결 방식은 하나의 TCP 연결로 연결이 끊길 때까지 패킷들을 주고 받는다. HTTP 프로토콜이 일정 기간(timeout)동안 사용되지 않은 연결은 닫는다.

쿠키(Cookie)

• HTTP 프로토콜은 비상태 프로토콜(서버는 클라이언트에 대한 정보를 유지하지 않음)이라고 위에서 정리했다. 하지만, 서버가 사용자 접속을 제한하거나, 사용자 별로 컨텐츠를 별도로 제공하기를 원하는 경우에는 사용자를 확인해야 한다. 이 목적으로 쿠키를 사용한다.
• 쿠키는 사용자를 식별할 수 있도록 도와준다.

웹 캐시(Web cache)

• 웹 캐시는 웹 서버의 원본 데이터의 복사본을 저장하는 서버를 말한다. 프록시 서버라고도 한다.
• 웹 캐시를 이용하는 객체 요청은 다음과 같이 이뤄진다.
  1. 브라우저가 객체를 요구하면, 브라우저는 먼저 웹 캐시에 TCP 연결을 설정하고 HTTP 요청을 보낸다.
  2. 웹 캐시는 원본 객체의 사본이 자신한테 저장되어 있는지 확인한다.
     1. 있으면 복사본을 응답 메세지에 담아 클라이언트로 전달한다.
     2. 없으면 웹 캐시는 원본 객체를 갖는 서버에 TCP 연결을 설정하고 HTTP 요청을 보낸다. 이 때, 응답으로 온 데이터를 복사해 자신의 디스크에 저장해두고, 이 복사본을 응답 메세지에 담아 클라이언트로 전달한다.
• 위 과정에서 웹 캐시는 서버이자 클라이언트의 역할을 둘 다 수행하게 된다.
• 웹 캐싱의 장점은 다음과 같다.
  1. 클라이언트 요청에 대한 응답 시간을 줄일 수 있다.
  2. 웹 트래픽을 대폭 줄일 수 있다.

조건부 GET

• 위 웹 캐싱을 이용해 클라이언트는 복사본을 받는다. 이 때, 이 복사본은 최신 데이터가 반영되지 않았을 수도 있다. 다시 말해, 원본 서버의 데이터는 바꼈지만, 웹 캐시가 이를 반영하지 못한 상황이 발생할 수 있다.
• 위 상황을 방지하기 위해 조건부 GET을 사용한다.
• 조건부 GET은 HTTP 요청 메세지에 If-modified-since 헤더를 추가함으로써 수행된다. 서버는 이 날짜와 서버의 데이터 변경 날짜를 비교해, 같다면 요청 메세지 바디에 빈 개체를, 다르다면 새로 변경된 데이터를 담아서 응답한다.

SMTP

• SMTP(Simple Mail Transfer Protocol)은 인터넷에서 이메일을 보내기 위해 사용되는 프로토콜이다.
• SMTP는 송신자의 메일 서버에서 수신자의 메일 서버로 메세지를 전송한다.
• SMTP는 HTTP보다 훨씬 오래 되었다. 낡은 특성을 갖는 오래된 기술이다.
• 메세지는 송신자와 수신자의 사이가 멀다 해도 다른 메일 서버를 경유해서 가지 않는다. 둘 사이의 직접적인 연결만으로 메세지가 송신된다.

HTTP와 SMTP 비교

특징

• HTTP는 웹 서버로부터 웹 사용자로 파일을 전송한다.
• SMTP는 하나의 메일 서버로부터 다른 메일 서버로 파일을 전송한다.

공통점

• 둘다 지속 연결 방식을 사용한다. (HTTP는 1.1 이후부터 지속연결!)

차이점

1. pull vs. push
   • HTTP 프로토콜은 풀(pull) 프로토콜이다. 서버에 데이터를 올려 두면, 사용자는 가져오기(pull) 위해 HTTP를 사용한다.
   • SMTP 프로토콜은 푸시(push) 프로토콜이다. 송신 메일 서버가 메세지를 수신 메일 서버로 보낸다(push).
2. 데이터 포맷
   • SMTP는 각 메세지가 7비트 ASCII 포맷이어야 하는 반면, HTTP는 이런 제약이 없다.
3. 객체를 다루는 법
   • HTTP는 여러 객체를 하나의 메세지에 캡슐화를 통해 담아 보내는 반면, SMTP는 하나의 객체를 하나의 메세지로 보낸다.

메일 접속 프로토콜

• SMTP는 푸시 프로토콜로, 서버로부터 자신의 로컬 PC로 메세지를 전송하는 풀 작업은 하지 못한다. 이에 따라 메일 접속 프로토콜이 탄생했다.
• 메일 접속 프로토콜은 수신자의 메일 서버로부터 자신의 사용자 에이전트(user agent)로 메일을 전송하는 데에 사용되며, POP3과 IMAP 프로토콜이 존재한다.
• POP3(Post Office Protocol Version 3)
  • 메일을 내려 받게 되면, 서버에서는 해당 이메일이 지워진다.
• IMAP(Internet Mail Access Protocol)
  • 중앙 서버에서 동기화가 이뤄진다. 따라서 모든 장치에서 동일한 이메일 폴더를 확인할 수 있다.

DNS(Domain Name System)

• DNS는 호스트 네임을 IP 주소로 변경해준다.
• 클라이언트가 호스트 네임으로 서버에 요청을 보내면 아래와 같은 과정을 거친다.
  1. 브라우저는 호스트 네임을 DNS 클라이언트 측에 넘긴다.
  2. DNS 클라이언트는 DNS 서버로 호스트 네임을 포함하는 질의를 보낸다.
  3. DNS 클라이언트는 호스트 네임에 매칭되는 IP 주소를 DNS 서버로부터 받는다.
  4. 브라우저가 IP 주소로 HTTP 서버에 TCP 연결을 시도한다.
• DNS 유형
  • 루트 DNS 서버
  • 최상위 레벨 도메인 서버(top-level domain, TLD)
  • 로컬 DNS 서버 : 요청 호스트에게 IP를 제공하는 서버
  • 책임 DNS 서버 : 질의 호스트 네임을 관리하는 서버

• 호스트 네임 질의는 다음과 같이 이루어진다.

  

  1. 먼저 호스트네임을 포함해 로컬 DNS 서버에 질의를 보낸다.
  2. 로컬 DNS 서버는 받은 질의를 루트 DNS 서버에 질의를 전달한다.
  3. 루트 DNS 서버는 상위 레벨 도메인에 맞는 TLD 서버의 IP 주소 리스트를 로컬 DNS로 전달한다.
  4. 로컬 DNS 서버는 질의 메세지를 TLD DNS 서버로 보낸다.
  5. TLD DNS 서버는 책임 DNS 서버의 IP 주소를 응답한다.
  6. 마지막으로, 로컬 DNS 서버는 질의 메세지를 책임 DNS 서버로 보낸다.
  7. 책임 DNS 서버는 질의 호스트 네임에 매핑되는IP 주소를 응답한다.

DNS 캐싱

• DNS는 지연 성능 향상과 네트워크의 DNS 메세지 수를 줄이기 위해 캐싱을 사용한다.

• 아래 사진에서 로컬 DNS 서버는 루트 DNS 서버, TLD DNS 서버, 책임 DNS 서버로부터 응답으로 받은 IP 주소를 저장할 수 있다. 이후 같은 로컬 DNS 서버로의 호스트 네임 질의는 또 다른 질의를 요구하지 않으며, 캐싱된 IP 주소를 곧장 요청 호스트에게 전달해준다.