웹을 지탱하는 기술

웹이란 무엇인가?

• 웹의 용도
  • 웹 사이트 (예: 포털/쇼핑/검색 사이트 및 블로그 등등)
  • 유저 인터페이스로서의 웹 (예: 브라우저)
  • 프로그램을 위한 API로서의 웹 (예: 웹 서비스)
• 웹을 지탱하는 기술
  • HTTP, URI, HTML
  • 하이퍼미디어 - 비선형
  • 분산 시스템

웹의 역사

• 웹 이전의 인터넷
  • ARPANET
    • 미국 내 대학과 연구기관 사이를 고속 회선으로 접속
    • TCP/IP, UUCP 방식
• 웹 이전의 하이퍼미디어
  • Memex
    • 하이퍼미디어의 기원
    • 전기적으로 접속한 책과 파일을 서로 링크하고 링크를 따라서 차례로 표시하는 구상
    • 당시 하이퍼미디어라는 단어가 없었지만 후에 많은 연구자들에게 영향을 끼침
  • Xanadu
    • 고기능으로 인한 복잡성으로 개발 실패
  • HyperCard
    • 네트워크를 통해 데이터를 주고받는 기능 없었지만, ‘카드’라고 불리는 문서를 단위로 상호 링크하고, 스크립트 언어 HyperTalk에 의한 프로그램을 실행할 수 있는 말하자면, Stand-alone 방식의 웹 서비스
  • 웹 이전의 하이퍼미디어의 문제점
    • 복잡성
  • 예전 하이퍼미디어 개발자 시각으로 본 현재 웹 하이퍼미디어의 문제점
    • 단방향 링크
    • 링크 끊어질 가능성 있음
    • 버전 관리와 트랜스클루전 기능 없음
• 웹 이전의 분산 시스템
  • 웹 이전의 분산 시스템의 문제점
    • 성능열화의 문제
    • 데이터형 변환의 문제
    • 인터페이스 버전업 시 호환성 문제
    • 부하 분산의 문제
• 웹의 탄생
  • 분산정보관리 시스템(Tim Berners-Lee) -> Mosaic(NCSA)
  • 하이퍼미디어로서의 웹의 특징
    • 단방향 링크
  • 하이퍼미디어로서의 웹의 장점
    • 인터넷을 이용하기 때문에 불특정 다수의 정보를 서로 링크할 수 있음
    • 시스템을 대규모화하기 쉬움
  • 하이퍼미디어로서의 웹의 단점
    • 정보의 집중적인 관리가 어려움
    • 링크가 끊어지기 쉬움
  • 분산 시스템으로서의 웹
    • 기존 RPC는 폐쇄된 네트워크 환경에서 미리 상정한 숫자와 종류의 클라이언트를 상대로 서비스를 제공한 반면 웹에서는 통일되어 있지 않는 각 유저의 컴퓨터 환경과 다양한 브라우저를 클라이언트와 서버 간의 인터페이스를 HTTP로 고정함으로서 접근 가능
• 웹 표준화
  • 급속도로 HTTP와 URI와 HTML이 보급되어 W3C에서 표준화 작업을 함
  • REST 아키텍처 스타일 탄생
  • 다양한 하이퍼미디어 포맷의 탄생
    • HTML, microformats, RRS, Atom, XML, JSON
• 웹 API
  • SOAP과 WS와 REST

REST 웹의 아키텍처 스타일

• REST란 웹의 아키텍처 스타일(네트워크 시스템의 아키텍처 스타일)
• REST 스타일
  • 클라이언트/서버 : Request & Response
  • 스테이트리스 서버 : 클라이언트의 어플리케이션 상태를 서버에서 관리 X
  • 캐시 : 서버에서 가져온 리소스를 클라이언트에서 재활용
  • 유니폼 인터페이스 : URI에 대한 요청이 통일되고 한정적인 인터페이스
  • 계층화 시스템 : Load Balancer 또는 Proxy로 분산
  • 코드 온 디맨드 : 서버에서 클라이언트로 코드를 가져온 후 해석
• Restful이란 REST의 제약을 따르고 있고, REST다운 것을 뜻함

URI의 스펙

• URI는 Uniform Resource Identifier의 약자
• URI의 구문
  • URI Scheme : HTTP
  • host name : www.example.com (일의성이여야함)
  • path : /entries/1
• URI 지정 방법
  • 절대 URI - 모든 전체 경로를 다 기술한 URI 표현 (예: http://www.example.com/entries/1)
  • 상대 URI - 전체 경로 중 Base URI로부터 상대적 경로 표현 (예: /entries/1)
  • Base URI - HTML 문서 내 Head 요소 안에 Base 요소에 표시
• URI의 길이는 스펙으로는 제한이 없지만 구현상 제한

URI 설계

• Cool URI
  • 의존적인 확장자 포함 X (*.pl, *.jsp, *.php 등등)
  • 의존적인 경로 포함 X (Servlet 등등)
  • 메서드명 & 세션ID 포함 X
  • 명사로 리소스 표현
• Content Negotiation
• 매트릭스 URI

HTTP

• REST의 중요 특성을 갖고 있는 프로토콜
• HTTP는 TCP/IP를 기반으로 함
• 계층형 프로토콜
  • 애플리케이션 계층 (HTTP, NTP, SSH, SMTP, DNS)
  • 트랜스포트 계층 (UDP, TCP)
  • 인터넷 계층 (IP; Packet)
  • 네트워크 인터페이스 계층 (이더넷)
• HTTP 버전은 0.9/1.0/1.1/2.0
• HTTP는 동기형 프로토콜
• 클라이언트에서 일어나는 일
  • 요청 메시지 구축
  • 요청 메시지 송신
  • 응답이 돌아올 때까지 대기
  • 응답 메시지 수신
  • 응답 메시지 해석
  • 클라이언트의 목적을 달성하기 위해 필요한 처리
• 서버에서 일어나는 일
  • 요청을 대기
  • 요청 메시지 수신
  • 요청 메시지 해석
  • 적절한 어플리케이션 프로그램 처리 위임
  • 어플리케이션 프로그램으로부터 결과 취득
  • 응답 메시지 구축
  • 응답 메시지 송신
• HTTP 메시지 구성
  • 요청 메시지
    • 요청라인 (메서드, 요청 URI, 프로토콜 버전)
    • 헤더 (메타 데이터)
    • 바디
  • 응답 메시지
    • 스테이트스 라인 (프로토콜 버전, Status Code, Text)
    • 헤더
    • 바디
• HTTP는 스테이트리스한 프로토콜 (클라이언트 어플리케이션 상태 보존 X)
  • 어플리케이션 상태의 다른 이름 : Session State
  • 스테이트풀한 프로토콜 : FTP
    • 스테이트풀의 결점
      • 접속 클라이언트가 많아질수록 저장하고 있는 데이터가 많아지기 때문에 프로그램이 무거워짐
      • 확장이 어려움
    • 스테이트리스의 이점
      • 확장 용이
    • 스테이트리스의 결점
      • 퍼포먼스의 저하
      • 통신 에러에 대한 대처

HTTP 메서드

• 메서드 종류 (GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT)
• 조건부 요청
• 멱등성과 안전성

Status Code

• 1xx : 처리중
• 2xx : 성공
• 3xx : 리다이렉트
• 4xx : 클라이언트 에러
• 5xx : 서버 에러

HTTP Header

• Date & Expires
• MIME media type
  • Content-Type
  • charset
• Content-Language
• Content Negotiation
  • Accept
  • Accept-Charset
  • Accept-Language
• Content-Length & chuncked
• WWW-Authenticate
  • Basic 인증
  • Digest 인증
• cache
  • Pragma
  • Expires
  • Cache Control
• etc….

읽기 전용 웹 설계

• OOL -> OOD 설계 -> Use Case/ 클래스 구조 결정
• RDBMS -> ERD
• ROA
  1. 웹 서비스 제공 데이터 특정
  2. 데이터를 리소스로 나누기
  3. 리소스에 URI 부여
  4. 리소스의 표현 설계
  5. 리소스끼리 연결
  6. 표준 코스 검토
  7. 에러 검토

쓰기 가능 웹 설계

• 트랜잭션
• 베타제어

리소스 설계

• 정보 아키텍처