네트워크 애플리케이션의 원리
네트워크 애플리케이션 개발의 중심은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것
Ex)
웹 애플리케이션 : 사용자의 호스트(데스크톱, 태블릿, 스마트폰)에서 실행되는 브라우저 프로그램 <-> 웹서버 호스트에서 실행되는 웹 서버 프로그램
P2P 파일 공유 시스템 : 파일 공유에 참여하는 각 호스트에 있는 프로그램이 각 종단 시스템
새로운 애플리케이션 개발을 위해 여러 종단 시스템에서 실행되는 소프트웨어를 작성해야하지만, 라우터나 링크 계층 스위치와 같이 네트워크 코어 장비에서 실행되는 소프트웨어를 작성할 필요는 없다.
네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않는 대신, 네트워크 계층 및 그 하위 계층에서 기능한다.
종단 시스템에만 애플리케이션 소프트웨어가 존재한다는 설계가 인터넷 애플리케이션의 빠른 발전의 원동력
네트워크 애플리케이션 구조
애플리케이션 구조
애플리케이션 개발자에 의해 설계되고 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시
애플리케이션 개발자는 클라이언트-서버 구조 혹은 p2p 구조 중의 하나로 작성
1. 클라이언트-서버 구조
서버 : 항상 켜져 있는 호스트. 이 서비스는 클라이언트라는 다른 많은 호스트의 요청을 받는다.
웹 서버가 클라이언트 호스트로부터 객체 요청을 받으면 웹 서버는 클라이언트 호스트로 요청된 객체를 보내어 응답한다.
하나의 서버가 클라이언트로부터의 모든 요청을 처리한다면 서버가 제대로 작동하지 못할 수 있기 때문에 많은 호스트를 갖춘 데이터 센터가 사용된다.
2. P2P 구조 (Peer To Peer)
P2P 구조에서 애플리케이션은 피어(peer) 라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 한다. 피어는 사용자들이 제어하는 데스크톱과 랩톱이다. 특정 서버를 통하지 않고 통신하므로 peer to peer (p2p)라고 한다.
특징
- 자가 확장성 : 각 피어들은 파일을 다른 피어들에게 분배함으로써 서비스 능력을 추가한다.
- 비용 효율적 : 상당한 서버 기반구조와 서버 대역폭을 요구하지 않는다.
- 고도의 분산 구조 특성으로 인해 보안, 성능 그리고 신뢰성의 문제가 생길 수 있다.
프로세스
프로세스 : 종단 시스템에서 실행되는 프로그램
프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.
클라이언트와 서버 프로세스
네트워크 어플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.
예를 들어, 웹 애플리케이션은 클라이언트 브라우저 프로세스와 웹 서버 프로세스간의 메시지를 교환한다.
두 프로세스 간의 통신 세션에서 통신을 초기화하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.
소켓
프로세스는 소켓을 통해 네트워크로 메시지를 주고 받는다. 프로세스는 집이고 소켓은 출입구로 비유할 수 있다.
프로세스가 메시지를 다른 호스트의 프로세스로 보내고 싶을 때, 출입구(소켓)으로 메시지를 밀어낸다. 메시지가 다른 호스트에 도착하면 마찬가지로 출입구(소켓)을 거쳐 수신 프로세스에 닿고 처리된다.
그림에서 보이듯이 소켓은 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스다.
애플리케이션 계층 프로토콜
애플리케이션 계층 프로토콜의 정의
- 교환 메시지 타입(예: 요청 메시지와 응답 메시지)
- 여러 메시지 타입의 문법(예: 메시지 내부의 필드와 필드 간의 구별 방법)
- 필드의 의미, 즉 필드에 있는 정보의 의미
- 언제, 어떻게 프로세스가 이 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
HTTP 프로토콜
HTTP 프로토콜 : 웹의 애플리케이션 계층 프로토콜이다. HTTP는 메시지의 구조 및 클라이언트와 서버의 메시지 교환 방식을 정의하고 있다.
특징
클라이언트 서버 구조- 클라이언트가 서버에 요청(request)을 보내면, 서버는 그에 대한 응답(response)를 생성한다.
Connectionless 프로토콜- 클라이언트가 서버에 요청(request)을 했을 때, 요청에 맞는 응답(response)을 보낸 후 연결을 끊는다.
Stateless 프로토콜- 서버와의 연결이 끊어지면, 서버가 클라이언트의 상태 정보를 가지지 않는 처리 방식이다. 클라리언트가 요청할 때 필요한 데이터를 담아서 전송해야 한다.
- 항상 같은 서버를 유지하지 않아도 되어서, 서버 확장성이 높다.
쿠키와 세션
쿠키와 세션의 사용 목적 : HTTP 프로토콜은 무상태이기 때문에 사용자의 상태 정보를 갖고 있지 않지만 서버가 사용자를 제한하거나 사용자에 따라 컨텐츠를 제공하기 위해 사용자를 확인할 필요가 있다. Stateless의 상황 속에서 사용자의 상태 정보를 유지할 필요가 있는 경우 쿠키와 세션을 사용해서 정보를 저장한다.
쿠키
HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우,그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다. HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.
브라우저와 서버 간의 쿠키 동작 순서
아마존 사이트를 방문한 예제를 들겠다.
- 하니가 처음으로 아마존 닷컴에 방문했다.
- 아마존 닷컴의 아마존 웹 서버는 하니의 요청이 들어올 때 유일한 식별번호를 만든다.
- 생성된 유일한 식별번호로 인덱스되는 백엔드 DB 안에 엔트리를 만든다.
- 하니의 요청에 대한 응답 메시지를 보낼 때, 헤더 파일에 식별 번호를 담고 있는
Set-cookie:가 포함된다. - 하니가 아마존과의 연결을 끊고 다음에 다시 접속을 하더라도 브라우저가 쿠키 정보를 함께 전달하게 된다.
- 아마존은 요청으로 들어온 메시지 헤더 파일에 쿠키 정보를 통해 하니의 기록을 추적하고 식별할 수 있게 된다.
쿠키는 일정 기간 동안 유지되게 생성할 수 있다.
세션
일정 시간동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 일정하게 유지시키는 기술이다. 여기서 일정 시간은 방문자가 웹 브라우저를 통해웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.
- 사용자에 대한 정보를 서버에 두기 때문에, 사용자가 많아질수록 서버 메모리 많이 차지
- 보안 면에서 쿠키보다 우수
- 쿠키는 클라이언트 측에서 쉽게 탈취 가능
- 쿠키는 클라이언트 측에서 변경이 가능한 반면, 세션은 서버에서만 변경 가능
- 세션ID값 탈취는 적극적인 해킹공격으로 쿠키보다 어려움
브라우저와 서버 간의 세션 동작 순서
- 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
- 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
- session-id가 존재하지 않는다면, 서버는 session-id를 생성해 클라이언트에게 돌려준다.
- 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다. 쿠키 이름 : JSESSIONID
- 클라이언트는 재접속 시, 이 쿠키(JSESSIONID)를 이용하여 session-id 값을 서버에 전달
쿠키와 세션의 차이
| 쿠키(Cookie) | 세션(Session) | |
|---|---|---|
| 저장 위치 | 클라이언트(=사용자PC) | 웹 서버 |
| 저장 형식 | text | Object |
| 만료 시점 | 쿠키 저장시 설정(브라우저가 종료되도, 만료시점이 지나지 않으면 자동삭제되지 않음) | 브라우저 종료시 삭제 (기간 지정 가능) |
| 사용하는 자원 | 클라이언트 리소스 | 웹 서버 리소스 |
| 용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096byte) | 서버가 허용하는 한 용량 제한 없음 |
| 속보 | 클라이언트에 저장되어 서버에 요청시 빠름 | 정보가 서버에 저장되어 있어 서버 처리가 필요해 쿠키보다 느림 |
| 보안 | 클라이언트에 저장되므로 취약 | Session ID만 저장하고, 이 값에 따라 서버에서 처리하므로 비교적 보안성 좋음 |
