SlideShare a Scribd company logo
웹을 지탱하는 기술
                                                         권정혁
                                                        @xguru
                                               http://xguru.net
                                               guru@xguru.net
 2-14 페이지는 강원대학교 문양세 교수님의 수업자료 http://j.mp/P4Zawc 를 발췌하여 정리하였습니다.
그 이후 페이지는 멘토르 출판사의 “웹을 지탱하는 기술” 책의 내용을 기반으로, 제가 첨삭하여 정리하였습니다.
인터넷 ?
정형적(formal) 정의
 TCP/IP 프로토콜을 통해 연결되어 있는 전 세계적인 네트워크

 컴퓨터 기술과 통신 기술이 기본이 되어, 각기 다른 기관에 의해 다른 목적으로 구성된 네트워크들
 이 서로 연결되어 전 세계를 묶는 하나의 거대한 네트워크로, 다양한 서비스를 제공하는 지구촌 네
 트워크

또 다른 정의
 세계 최대 컴퓨터 통신망 (interconnected network Æ Internet)

 TCP/IP 프로토콜을 사용하는 세계적 규모의 컴퓨터 통신망

 통신망 들의 통신망(network of networks)

 정보의 바다

 가상의 공간(cyber space)
인터넷의 탄생
ARPANET ( http://en.wikipedia.org/wiki/ARPANET )
  미국 국방부의 주도하에 만들어진 세계 최초의 패킷 스위칭 네트워크

  1969년에 시작, 현재의 인터넷의 원형

  발족당시 UCLA , UCSB ( 산타바바라 ) , Utah 대, SRI ( 스탠포드 연구소 )

  NCP ( Network Control Program ) 을 이용하였으나, 1983년부터 TCP/IP로 대체
인터넷의 탄생 #2
NSFNET : National Science Foundation Network
  http://en.wikipedia.org/wiki/NSFNET

  미국 국립과학재단(NSF)에서 1980년 후반부터 NSFNET을 본격적으로 보급

  1990년대 초까지 인터넷에 연결된 전 세계 컴퓨터는 NSFNET에 직/간접적으로 연결되어,
  NSFNET을 “백본”이라 부름

  1995년 NSFNET의 백본이 사라지고, 일반 회사들이 운영하는 상용 백본 등장
인터넷의 발전
1969 미 국방성 알파넷(ARPANET) 등장
1972 이메일 탄생
1974 인터넷(Internet) 용어 처음 사용
1975 TCP/IP 개발, 시운전 개시
1979 USENET 구축(net* 뉴스그룹 생성)
1982 TCP/IP 도입 ( 인터넷 개념 정립 )
1984 DNS (Domain Name System ) 제시
1986 NSFNET 구축
1991 팀 버너스 리에 의해 WWW(WorldWideWeb) 개발
1993 InterNIC, Mosaic 등장으로 WWW 사용율 급증
1994 넷스케이프 네비게이터 1.0 발표 , W3C 구성
1995 NSFNET 해체되고 ISP 등이 운용. 본격 상업화, 대중화, 정보 고속화
1996 MS Internet Explorer 발표
1998 세계 인터넷 이용자수 1억명 돌파
인터넷 관련 기구
ICANN (The Internet Corporation for Assigned Names and Number)
  ‘국제인터넷주소관리기구’
  새로운 도메인 체계의 도입, IP 주소 할당, DNS 관리 등

IETF(Internet Engineering Task Force)
  인터넷 표준안을 제정하기 위한 기술위원회

W3C(World Wide Web Consortium)
  HTML의 규격, 스타일시트(CSS), HTML5 와 같은 웹 관련 기술에 대한 표준안 제정

NIC(Network Information Center)
  국가별, 대륙별 인터넷 이용기관을 위한 주소 등록 서비스를 수행하고, 주요 정보 서비스를 제공

KRNIC(Korea Network Information Center)
  ‘한국인터넷정보센터’

  우리나라 IP 주소 할당, 도메인 네임 관련 DB 관리, 새로운 도메인 네임 도입 등을 수행
네트워크 란 ?
네트워크 개념적 정의
 네트워크는 사용자의 컴퓨터를 인터넷에 연결시켜주는 게이트(gate)와 다양한 컴퓨터들이 서로
 연결되어 정보를 주고받을 수 있는 뼈대와 같은 역할들을 수행하는것이다.

 네트워크는 통신선로에 의해 서로 연결되어 있는 일련의 정보원(노드: node)와 통신매체(링크:
 link)의 집합을 의미한다.

 네트워크는 두 대 이상의 컴퓨터를 연결하여 근거리나 원거리 통신을 제공하고 서로 연결된 요소
 들 간의 데이터를 등을 전송할 수 있도록 해준다.

“통신”의 정의
 어원은 ‘공유한다’는 의미를 갖는 라틴어 ‘communicare’ 에 있다.
 송신자와 수신자 사이에 전송 매체인 통신로를 통하여 정보를 전달하는 것 또는 그 과정으로 정의
 하며 정보를 정확하게 전달하는 것을 목적으로 한다.

 통신을 위해 필요한 요소
   대화를 나눌 수 있는 상대방 ➠ 송신자, 수신자
   정보를 전달하기 위한 매체 ➠ 공기, 전화선 등
   의사소통에 필요한 공통 언어 및 공통된 규약(프로토콜)
네트워크 프로토콜
프로토콜은 통신을 위해 사람들이 정해 놓은 규약으로 서로 다른 장치나 컴
퓨터간의 데이터 통신에 필요한 규약
대표적인 프로토콜: TCP/IP , HTTP
TCP/IP (transmission control protocol / Internet protocol)
1. TCP는 (송신하는) 데이터를 패킷으로 분해

2. IP는 패킷을 전송하는 역할을 담당 (주소 등 정보를 포함한 패킷 헤더 가짐)

3. (중간에 있는) 라우터들은 IP 헤더를 검사하여 최종 목적지까지 패킷을 전달

4. 목적지에서는 패킷이 잘 전달되었는지 검사

5. TCP에서 다시 재결합하여 원래의 데이터로 전달
네트워크 프로토콜
HTTP(hypertext transfer protocol)
  HTML 문서의 송수신을 위해 사용하는 프로토콜

  URL 지정 시, “http://”라 명시하는 것도 이 이유 때문임

  HTTP는 TCP/IP 위에서 동작하는 응용 프로토콜 임

  http://en.wikipedia.org/wiki/Http
네트워크 모델 : C/S vs. P2P
클라이언트 / 서버
 모든 자원들을 서버에서 관리하면서 클라이언트 요청에 따라 필요한 정보를 제공하는 모델

   대표적 예: 웹 서버 , FTP 서버 , 메일 서버 , 프린터 서버 등

 장점

   강력한 중앙집중식 보안 체계 관리 기능

   중앙집중식 파일 저장을 통해, 데이터 관리와 백업이 용이함

   서버의 하드웨어/소프트웨어를 공동으로 사용하기 때문에, 시간과 비용 절감

   공유된 네트워크 자원을 이용할 때 빠르고 체계적으로 제공

 단점

   고가의 전용 서버와 네트워크 운영체제가 필요

   전문적 지식을 가진 관리자가 필요
네트워크 모델 : C/S vs. P2P
Peer-to-Peer 모델 ( P2P )
  피어 투 피어 모델은 서버와 클라이언트가 별도로 존재하지 않음
  즉, 모든 컴퓨터가 서버이며 동시에 클라이언트가 될 수 있음
  서버가 별도로 없으므로 모든 사용자들은 서로의 자원 등을 네트워크를 통하여 공유.

  장점
    서버 장비나 소프트웨어에 대한 추가적 비용 부담이 없음

    시스템 설정이 용이함 , 모든 사용자가 자원의 공유를 직접 관리

    작업의 수행을 위해 다른 컴퓨터에 의존하지 않음 , 구축 비용이 저렴함

  단점
    자신의 작업과 다른 사용자의 작업을 동시에 처리함으로 부하가 발생

    많은 네트워크 접속을 야기할 수 있음

    파일/DB의 보관이 여러 컴퓨터에서 이루어져 비효율과 중복의 문제 발생

    모든 사용자가 컴퓨터를 잘 알고 있어야 하며, 관리가 어려움
IP 주소와 클래스
IP 주소 (IP address)
  통신망에 연결된 컴퓨터를 구별 할 수 있는 방법
  인터넷에 연결된 각 컴퓨터마다 고유한 번호 부여
  통신망 번호와 각 망에 연결된 컴퓨터 고유 번호 부여

IP 클래스 (IP class)
  네트워크는 크기에 따라 A, B, C, D등의 등급으로 분류되고, 이들 간 구분은 IP 주소 맨 앞자리
  octet(byte)의 상위 비트로 표현

IP 주소 형태
  IP주소는 32bit(32자리 이진수)로 되어 있으나, 일반적으로 4개의 octet(4개의 8자리 이진수)
  로 나누어 10진수로 표기한다.
도메인 네임과 네임서버
사람들이 기억하기 쉽고 사용하기 편리하기 위해 인터넷에서는 도메인네임
(Name)이라는 또 다른 주소를 제공.
도메인 네임 서버(Domain Name Server)에서 도메인 네임을 관리
컴퓨터가 속한 기관이나 국가에 따라서 계층적으로 형성
일반적으로 “컴퓨터이름.기관이름.기관종류.국가이름” 형태로 사용.
 multi.hansung.ac.kr , xguru.net

미국의 경우는 마지막에 국가가 없이 .edu , .com , .net 등을 사용
TLD : Top Level Domain
도메인       국가명            기관명      미국     그외 국가
kr        Korea         교육기관      edu     ac

 jp       Japan          사업체      com     co

uk    United Kingdom    정부기관      gov     go

 fr      France        비영리 공공기관   org     or

ca       Canada        네트웍 관련기관   net     ne

de       Germany         사업       biz

 it        italy         정보       info
 ly       Libya

 io    Indian Ocean

 is      Iceland

to        Tonga
Web 이란 무엇인가 ?
Web의 출현
웹 출현 이전에 인터넷은?
  (컴퓨터) 전문가들의 외부 컴퓨터에 접속, 정보를 공유하는 수단

  주로 telnet, ftp 등이 인터넷 서비스의 대표적 수단이었음

  일반인이 인터넷을 사용하기에는 어려움이 많았음

Tim Berners-Lee
  CERN ( 유럽 입자 물리학 연구소 ) 의 연구원

  하이퍼링크 기반의 문서 구조를 제안

    문서에서 링크를 통해 다른 링크로 연결하는 (당시에는) 혁신적 개념

  하이퍼링크를 지원하는 HTTP(hypertext transfer protocol)에 대한 RFC 제출

  하이퍼링크와 HTTP는 오늘날 웹이 있게 한 인터넷 역사에서 중요한 기술로 인정 받음

  http://en.wikipedia.org/wiki/Tim_Berners-Lee
웹이란 무엇인가 ?
Web 은 현재 모든 IT 의 주요 기반
 인터넷과 웹은 인간이 만든것 중 가장 중요한 것중 하나

다양한 웹의 용도
 웹사이트 : 포털 / SNS / 검색 / 쇼핑 ..

   서버한대부터 수천/수만대의 서버까지 구성

 유저 인터페이스로서의 웹

   스마트 TV , 프린터 냉장고

 프로그램을 위한 API 로서의 웹 ( Application Programming Interface )

   웹서비스

   Open API / Web API

   프로그램 중심의 인터페이스
웹을 지탱하는 기술
HTTP : Hyper Text Transfer Protocol
URI : Uniform Resource Identifier
HTML : Hyper Text Markup Language

                               애플리케이션 컨트롤

     HTTP는 URI로 조작대상을               HTTP         HTML 은 HTTP로
          지정한다.                                     전송된다.



              URI                                  HTML
                                HTML의 링크는 URI를
           리소스 식별자                  이용한다.        하이퍼미디어 포맷


하이퍼 미디어 : Hyper Link로 연결된 텍스트/이미지/음성/영상. 정보의 연결
분산 시스템 : 웹은 전 세계에 배치된 서버에, 전 세계의 브라우저가 접속하는 분산 시스템
What is Port ?
TCP/UDP 프로토콜이 사용하는 가상의 논리적 통신 연결부
0~65535번까지의 번호로 구별되며, IP와 함께 사용
 0~1023 : Well Known Port

 1024 ~ 49151 : Registered Port

 49152 ~ 65535 : Dynamic Port
웹 이전의 인터넷
eMail : SMTP , POP3 , IMAP , Exchange
   SMTP (25,587): Simple Mail Transfer Protocol

   POP (110,995) : Post Office Protocol

   IMAP (143,993) : Internet Message Access Protocol


FTP (21) : File Transfer Protocol
Telnet (23) , SSH(22)
Gopher (70)
USENET , Newsgroup
   NNTP ( 119 , 563 ) : Network News Transfer Protocol


IRC : Internet Relay Chat
   194 but de facto is 6667 , 6660~6669,7000



http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
웹의 탄생
1990-11-12 Tim Berners-Lee @ CERN
  인터넷 기반의 ‘분산정보관리 시스템’ 웹 제안서 작성 http://www.w3.org/Proposal

  바로 개발시작해서 크리스마스 휴가에 첫 버전의 서버와 브라우저 완성
웹의 보급 시작
1993. NCSA Mosaic
 National Center for Supercomputing Application

 이미지가 보이는 첫번째 브라우저
웹 표준의 출현
REST 란 무엇인가 ?
REST 의 탄생
REST : Representational State Transfer
  웹이 왜 이렇게 성공했는지, 어떻게 대규모의 시스템이 만들어졌는지 소프트웨어 아키텍처의 관점
  에서 분석하고 하나의 아키텍쳐 스타일로 정리 - 2000년 Roy Fielding

  Architectural Styles and the Design of Network-based Software Architectures
  http://j.mp/REST_roy

  HTTP 는 하이퍼텍스트를 전송하기 위한 프로토콜이지만, 실제로는 하이퍼텍스트 이외의 다양한
  것을 전송하고 있으며, 그것은
  리소스 상태 ( Resource State ) 의 표현 ( Presentation )
Web API 전쟁 : SOAP vs. REST
초기의 웹은 학술논문 교환 및 문서를 읽기 위한 시스템
웹의 용도가 다양화 되면서 프로그램을 이용한 자동화 처리 요구 발생
SOAP 의 탄생
 초기에는 Simple Object Access Protocol 이었지만 그냥 SOAP으로 개정

 HTTP를 트랜스포트 프로토콜로 사용. XML을 이용한 다양한 별도 프로토콜 정의

 WS-Security , WS-Transaction , WS-ReliableMessaing 등 다양한 스펙의 난립

2000~2003 년 들어 SOAP vs REST 에 관해 다양한 논쟁이 벌어짐
 Amazon 웹서비스가 SOAP/REST 둘다 제공하지만 이용비율이 20/80 이라고 발표

Web2.0 과 함께 Mashup 에 유리한 REST가 점점 더 많이 사용됨
결과적으로 API에선 REST 가 승리. SOAP 도 제한된 용도로는 계속 사용
공유
참여                                      개방
                                   집단지성
            Web 2.0
Web
 as
 a
 Platform
Web 1.0
HTML in Web Browser


   Web 2.0
 HTTP everywhere
REST, 웹의 아키텍처 스타일
REST 는 아키텍처 가 아닌 ‘아키텍처 스타일’
아키텍처 스타일은 ‘아키텍처 패턴’ 이라고도 하며, 복수의 아키텍처의 공통
된 성질,양식,규정 혹은 독특한 방식을 가리킴
 MVC (Model - View - Controller ) , Pipe and Filter , Event System 등

 시스템의 아키텍처를 결정할 때 나침반이 되는 것이 ‘아키텍처 스타일’

REST는 클라이언트/서버에서 파생되었으며, 몇가지 제약을 추가한 것


      추상화 레벨                               웹 에서의 예
 아키텍처 스타일              REST
 아키텍처                  브라우저, 서버, 프록시, HTTP, URI, HTML
 구현                    Apache, Firefox, Internet Explorer
REST 개념 : Resource
리소스 : 웹상에 존재하는 이름을 가진 모든 정보
서울의 일기예보                 http://weather.naver.com/rgn/cityWetrCity.nhn?cityRgnCd=CT001013
양념치킨 만드는 법 소개 페이지        http://xguru.net/51
청량리역의 사진                 http://www.flickr.com/photos/nala2sky/3790226694
Roy Fielding 의 REST 논문   http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
xguru의 최근 트윗             http://twitter.com/xguru

리소스는 각각 URI로 의미있는 이름을 가지며, 쉽게 접근이 가능하다.
1개의 리소스가 복수개의 URI 를 가질수 있다.
   http://weather.example.com/seoul/today

   http://weather.example.com/seoul/2012-01-01

리소스는 여러개의 형태를 가질수 있다.
   일기예보 : HTML , PDF , 이미지 등등

리소스의 상태는 시간등에 따라 표현이 변할수 있다.
REST 의 스타일 #1
클라이언트 / 서버                           Client Server, CS
                                                              클라이언트               서버

  웹은 HTTP 프로토콜을 이용하여 클라이언트와 서버가 통신
                                                           유저 인터페이스 담당        데이터 스토리지 담당

  Request / Response 모델

  클라이언트 = 멀티 플랫폼 , 서버는 = 복수서버로 증설가능




Stateless 서버              Client Stateless Server, CSS
                                                                                스테이트리스
                                                              클라이언트
                                                                                  서버
  클라이언트의 애플리케이션 상태를 서버에서 관리하지 않음
                                                                             클라이언트의 애플리케이션
                                                                              상태를 관리하지 않는다.
  서버의 구현이 간략화 됨.                                              클라이언트


  많이들 쓰는 “Cookie 를 사용한 세션관리”는 이에 위배됨                     요청마다 모든 정보를 송신한다.
REST 의 스타일 #2
캐시                 Client Cache Stateless Server, C$SS
                                                               클라이언트             스테이트리스
                                                                 ($)               서버

 한번 가져온 리소스를 클라이언트측에서 재사용                                                       캐시에 필요한 정보를
                                                               클라이언트            클라이언트에게 전달
                                                                 ($)
 통신량을 줄여서 처리시간 축소. 신뢰성 떨어질 가능성
                                                             같은 요청의 결과를 재이용




유니폼 인터페이스     Uniform Client Cache Stateless Server, UC$SS
                                                                                 스테이트리스
                                                               클라이언트
                                                                                   서버
 URI로 지정된 리소스에 대한 조작을 통일된 인터페이스로 수행
                                                                                 스테이트리스
 HTTP 1.1 은 8개의 메소드만 있음                                        클라이언트
                                                                                   서버

                                                                              모든서버가 같은 인터페이스
 아키텍처가 간결하고, 클라이언트 / 서버 구현의 중립성이 향상                                               를 채용한다.
REST 의 스타일 #3
계층화 시스템       Uniform Layered Client Cache Stateless Server, ULC$SS


 유니폼 인터페이스의 이점으로 계층화가 쉬워짐

 로드밸런서를 통한 부하분산. 프록시을 통한 액세스 제어 등이 추가되어도 클라이언트는 모르며,
 이것은 HTTP를 통일한 인터페이스로 사용했기 때문

 Layered System : 시스템을 몇개의 계층으로 분리하는 아키텍쳐 스타일


                            스테이트리스
           클라이언트
                              서버

                         인터페이스가 다른 레거시 시
                         스템에 접속할수 있게 한다.



                                                          스테이트리스
                                                            서버


           클라이언트               프록시
                                                          스테이트리스
                        시스템을 복수의 계층으로 분                     서버
                              할한다.
REST 의 스타일 #4
코드온 디맨드          Uniform Layered Code on Demand Client Cache Stateless Server, ULCODC$SS


 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍쳐 스타일

 Javascript , Flash , Java 애플릿 등

 애플리케이션 프로토콜의 가시성은 저하될수 있음

 HTML5 와 함께 Javascript 가 더욱 중요해 지고 있음

                                스테이트리스
              클라이언트
                                  서버

                             인터페이스가 다른 레거시 시
                             스템에 접속할수 있게 한다.



                                                             스테이트리스
                                                               서버


              클라이언트               프록시
                                                             스테이트리스
                                                               서버

                      서버가 제공하는 코드를 클라이언트에서 실행
REST 의 스타일 #5
클라이언트/서버 : 유저인터페이스와 처리를 분리한다.
스테이트리스 서버 : 서버측에서 애플리케이션의 상태를 가지지 않는다.
캐시 : 클라이언트와 서버의 통신회수와 양을 감소시킨다.
유니폼 인터페이스 : 인터페이스를 고정한다.
계층화 시스템 : 시스템을 계층별로 분리한다.
코드온 디맨드 : 프로그램을 클라이언트에 다운로드하여 실행한다.


이중 몇가지만 활용하여 만드는 아키텍쳐도 가능
 쿠키등을 활용하여 세션에 저장함으로써 스테이트풀 하지만 , URI형식은 그대로 따르는..
URI 란 무엇인가 ?
URI 의 스펙
URI : Uniform Resource Identifier , RFC 3986
  리소스를 통일적으로 식별하는 ID

  웹상에 존재하는 모든 리소스를 한결같은 방식으로 보여줄수 있음



URI 의 구문
  http://blog.example.com/entries/1

    URI Scheme : http

    Hostname : blog.examples.com

    Path : /entries/1

  유일한 호스트명/경로를 사용함으로써, URI 가 중복되지 않음
URI 심화
http://xguru:pass@xguru.net:8000/search?q=testdebug=true#n10
  URI Scheme : http
  구분자 - ://
  사용자정보 : id = xguru , pwd = pass
  구분자 - @
  호스트명 : xguru.net
  구분자 - :
  포트번호 : 8000

     생략시 각 URI Scheme 의 기본 값이 사용됨. http 의 기본포트번호는 80

  패스 : /search
  구분자 - ?
  쿼리 파라미터 : q=testdebug=true

  URI Fragment : #n10

절대 URI , 상대 URI
  . 은 현재 , .. 은 상위
URI와 문자
URI 에 쓸수 있는 문자
 알파벳 : A-Za-z

 숫자 : 0-9

 예약문자 : ; | / | ? | : | @ |  | = | + | $ | ,

 비예약문자 : - | _ | . | ! | ~ | * | ' | ( | )

% 인코딩
 허용하지 않는 문자들을 URI에 사용할때 인코딩 하는 방식

 http://ko.wikipedia.org/wiki/가 ➠ http://ko.wikipedia.org/wiki/%EA%B0%80

 % ➠ %25 , Space = %20 ,

URI 길이제한
 스펙상 제한은 없으나, 구현상 제한이 존재. IE는 2038 바이트 제한
URI의 설계
Cool URIs don’t change
  URI 가 바뀔경우 다시 그 자료를 찾기가 어려워진다.

  Cool URI 는 심플한 URI를 의미하기도 한다. 예 ) Apple 웹사이트

변하지 않는 URI 만들기
  프로그래밍 언어 의존적인 확장자와 경로를 포함하지 않는다.

    http://example.com/cgi-bin/login.pl , http://example.com/servlet/LoginServlet

  메서드명과 세션ID를 포함하지 않는다.

    http://example.com/Login.do?action=showPage , http://example.com/home.jsp?
    jsessionid=12345678

  URI는 리소스를 표현하는 명사로 한다.

    http://example.com/sample/people/show/123 = http://example.com/sample/people/123
URI설계의 테크닉
확장자로 표현(Presentation)을 지정한다.
 다국어 지원                                       HTTP의 Content-Negotiaion 기능 활용도 가능

   http://example.com/2001/05/01/press.ko     GET /2010/05/01/press HTTP/1.1
                                              Host: example.com
   http://example.com/2001/05/01/press.en     Accept-Language: ko,en-us;q=0.7,en;q=0.3
 리소스 형태 분리

   http://example.com/data/myplace.html
   http://example.com/data/myplace.json
   http://example.com/data/myplace.txt

매트릭스 URI
 http://example.com/map/lat=35.343243;lng=139.123232

 http://example.com/test/123232,testmessage
URI 는 중요하다
URI 는 리소스의 이름이다.
URI 는 수명이 길다.
URI 는 브라우저가 어드레스 란에 표시한다.


검색엔진이 중요하게 보는 데이터이다 ( Search Engine Optimization )


탁월한 URI 구성 예제는 apple.com 을 참고하자
 http://www.apple.com/iphone/features/
 http://www.apple.com/ipad/specs/
 http://www.apple.com/macbook-pro/performance/
 http://www.apple.com/support/iphone/syncing/
HTTP 란 무엇인가 ?
HTTP 의 역사
HTTP 0.9 - HTTP의 탄생
 팀 버너스리가 최초에 웹을 발명했을때 사용하던 프로토콜

 현재의 HTTP와 다르게 헤더가 없으며, GET 메소드만 있음. 현재 사용되지 않음

HTTP 1.0 - HTTP 최초의 표준화
 IETF 에서 표준화하여 1993년에 Draft 공개후, 1996년에 최종 버전(RFC 1945) 공개

 헤더의 도입, GET 이외의 메서드 추가

HTTP 1.1 - HTTP의 완성
 1997년 RFC 2068 에서 개정하여 1999년 RFC 2616 발행. 현재의 1.1 스펙

 채널전송, Accept 헤더에 의한 컨텐츠 네고시에이션, 캐쉬 컨트롤, Keep-Alive 등 추가

SPDY - 좀더 빠른 웹을 위한 실험적인 프로토콜
 구글이 제안하는 HTTP 프로토콜의 개선안. SSL/헤더압축/다중스트림/요청우선순위..
HTTP 기본
              클라이언트가 서버에 접속하여 Request 를 보내고 Response 를 받음
              동기형 프로토콜 : 서버에서 응답올때까지 대기
GET
 /
 HTTP/1.1
Host:
 xguru.net
                                                                                                                                                                                                               Client                                                                        HTTP/1.1
 200
 OK                                                                                        Server
                                                                                                                                                                                                                                                                                             Date:
 Sat,
 08
 Sep
 2012
 19:22:18
 GMT
Connection:
 keep-alive                                                                                                                                                                                                                                      Server:
 Apache/2.2.2
 (Unix)
 mod_ssl/2.2.2
 OpenSSL/
Cache-Control:
 max-age=0                                                                                                                                                                                                                                    0.9.8e-fips-rhel5
 PHP/5.3.0
User-Agent:
 Mozilla/5.0
 (Macintosh;
 Intel

More Related Content

What's hot

TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
Takuto Wada
 
縦スクロールEPUBの現状
縦スクロールEPUBの現状縦スクロールEPUBの現状
縦スクロールEPUBの現状
Katsuhiro OGATA
 
SQLチューニング入門 入門編
SQLチューニング入門 入門編SQLチューニング入門 入門編
SQLチューニング入門 入門編Miki Shimogai
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
増田 亨
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
 
ブラック企業から学ぶMVCモデル
ブラック企業から学ぶMVCモデルブラック企業から学ぶMVCモデル
ブラック企業から学ぶMVCモデル
Yuta Hiroto
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
増田 亨
 
漫談重構
漫談重構漫談重構
漫談重構
teddysoft
 
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
iPride Co., Ltd.
 
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of ChatbotsユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
Yoshiki Hayama
 
Atomic Architecture
Atomic ArchitectureAtomic Architecture
Atomic Architecture
Yoshitaka Kawashima
 
よろしい、ならばMicro-ORMだ
よろしい、ならばMicro-ORMだよろしい、ならばMicro-ORMだ
よろしい、ならばMicro-ORMだ
Narami Kiyokura
 
PostgreSQLアンチパターン
PostgreSQLアンチパターンPostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
 
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考えるソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
増田 亨
 
Creator Economy x Crypto => Web3.0
Creator Economy x Crypto => Web3.0Creator Economy x Crypto => Web3.0
Creator Economy x Crypto => Web3.0
Taiki Narita
 
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
Takuya Sato
 
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Miki Shimogai
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
Kohei Tokunaga
 
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
NVIDIA Japan
 
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
NTT DATA Technology & Innovation
 

What's hot (20)

TDD のこころ @ OSH2014
TDD のこころ @ OSH2014TDD のこころ @ OSH2014
TDD のこころ @ OSH2014
 
縦スクロールEPUBの現状
縦スクロールEPUBの現状縦スクロールEPUBの現状
縦スクロールEPUBの現状
 
SQLチューニング入門 入門編
SQLチューニング入門 入門編SQLチューニング入門 入門編
SQLチューニング入門 入門編
 
ドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDDドメイン駆動設計 の 実践 Part3 DDD
ドメイン駆動設計 の 実践 Part3 DDD
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
 
ブラック企業から学ぶMVCモデル
ブラック企業から学ぶMVCモデルブラック企業から学ぶMVCモデル
ブラック企業から学ぶMVCモデル
 
ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説ドメイン駆動設計サンプルコードの徹底解説
ドメイン駆動設計サンプルコードの徹底解説
 
漫談重構
漫談重構漫談重構
漫談重構
 
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
ファイルやディレクトリに「別名」を付ける機能について 〜ハードリンクからシンボリックリンクまで〜
 
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of ChatbotsユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
ユーザーにうれしいチャットボットのUX 7原則 - 7 Principles to Design UX of Chatbots
 
Atomic Architecture
Atomic ArchitectureAtomic Architecture
Atomic Architecture
 
よろしい、ならばMicro-ORMだ
よろしい、ならばMicro-ORMだよろしい、ならばMicro-ORMだ
よろしい、ならばMicro-ORMだ
 
PostgreSQLアンチパターン
PostgreSQLアンチパターンPostgreSQLアンチパターン
PostgreSQLアンチパターン
 
ソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考えるソフトウェア設計の学び方を考える
ソフトウェア設計の学び方を考える
 
Creator Economy x Crypto => Web3.0
Creator Economy x Crypto => Web3.0Creator Economy x Crypto => Web3.0
Creator Economy x Crypto => Web3.0
 
設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外設計と実装で 抑えておきたい サービスクラスと例外
設計と実装で 抑えておきたい サービスクラスと例外
 
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
 
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰するOCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
 
Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報Magnum IO GPUDirect Storage 最新情報
Magnum IO GPUDirect Storage 最新情報
 
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
バイトコードって言葉をよく目にするけど一体何なんだろう?(JJUG CCC 2022 Spring 発表資料)
 

Similar to 웹을 지탱하는 기술

Basic of web ref.웹을지탱하는기술_01
Basic of web ref.웹을지탱하는기술_01Basic of web ref.웹을지탱하는기술_01
Basic of web ref.웹을지탱하는기술_01
SangHun Lee
 
Web Development (Basic)
Web Development (Basic)Web Development (Basic)
Web Development (Basic)
Philippe Lee
 
Future Web and WoT(Web of Things)
Future Web and WoT(Web of Things)Future Web and WoT(Web of Things)
Future Web and WoT(Web of Things)
Jonathan Jeon
 
WoO 2012-Web 서비스 기술
WoO 2012-Web 서비스 기술WoO 2012-Web 서비스 기술
WoO 2012-Web 서비스 기술
Changhwan Yi
 
Web 2.0과 도서관 활용사례
Web 2.0과 도서관 활용사례Web 2.0과 도서관 활용사례
Web 2.0과 도서관 활용사례
구중억 (한국기초과학지원연구원)
 
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
Sanghun Yun
 
유로피아나(Europeana) 개론
유로피아나(Europeana) 개론유로피아나(Europeana) 개론
유로피아나(Europeana) 개론
Baro Kim
 
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
dgmit2009
 
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
JinuNoh
 
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
NAVER D2
 
HTML5 융합 기술 표준화 동향
HTML5 융합 기술 표준화 동향HTML5 융합 기술 표준화 동향
HTML5 융합 기술 표준화 동향
Jonathan Jeon
 
Trends on Standardizations of HTML5 based Web Platform Technology
Trends on Standardizations of HTML5 based Web Platform TechnologyTrends on Standardizations of HTML5 based Web Platform Technology
Trends on Standardizations of HTML5 based Web Platform Technology
Jonathan Jeon
 
HTTP 완벽가이드 : 1-1 http 개관
 HTTP 완벽가이드 : 1-1 http 개관 HTTP 완벽가이드 : 1-1 http 개관
HTTP 완벽가이드 : 1-1 http 개관
ssuser491981
 
인터넷 서비스의 종류
인터넷 서비스의 종류인터넷 서비스의 종류
인터넷 서비스의 종류Chulgyu Shin
 
Interface and Protocol
Interface and ProtocolInterface and Protocol
Interface and Protocol
Wonjun Hwang
 
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]Ch01 네트워크와+소켓+프로그래밍+[호환+모드]
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]지환 김
 
모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개
Hyogi Jung
 
NAT and Hole Punching_SYS4U I&C
NAT and Hole Punching_SYS4U I&CNAT and Hole Punching_SYS4U I&C
NAT and Hole Punching_SYS4U I&Csys4u
 
UI/UX Technology Trends on the Next Generation Web
UI/UX Technology Trends on the Next Generation WebUI/UX Technology Trends on the Next Generation Web
UI/UX Technology Trends on the Next Generation Web
Jonathan Jeon
 
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
ninefactory
 

Similar to 웹을 지탱하는 기술 (20)

Basic of web ref.웹을지탱하는기술_01
Basic of web ref.웹을지탱하는기술_01Basic of web ref.웹을지탱하는기술_01
Basic of web ref.웹을지탱하는기술_01
 
Web Development (Basic)
Web Development (Basic)Web Development (Basic)
Web Development (Basic)
 
Future Web and WoT(Web of Things)
Future Web and WoT(Web of Things)Future Web and WoT(Web of Things)
Future Web and WoT(Web of Things)
 
WoO 2012-Web 서비스 기술
WoO 2012-Web 서비스 기술WoO 2012-Web 서비스 기술
WoO 2012-Web 서비스 기술
 
Web 2.0과 도서관 활용사례
Web 2.0과 도서관 활용사례Web 2.0과 도서관 활용사례
Web 2.0과 도서관 활용사례
 
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
[15.09.17] 인터넷과 웹의 역사 그리고 현재의 트렌드
 
유로피아나(Europeana) 개론
유로피아나(Europeana) 개론유로피아나(Europeana) 개론
유로피아나(Europeana) 개론
 
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
DGMIT 제3회 R&D 컨퍼런스 r&d1 team : HTTP 프로토콜 개요
 
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
[HTTP 101] 웹 개발자라면 반드시 알아야하는 HTTP의 기초
 
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
 
HTML5 융합 기술 표준화 동향
HTML5 융합 기술 표준화 동향HTML5 융합 기술 표준화 동향
HTML5 융합 기술 표준화 동향
 
Trends on Standardizations of HTML5 based Web Platform Technology
Trends on Standardizations of HTML5 based Web Platform TechnologyTrends on Standardizations of HTML5 based Web Platform Technology
Trends on Standardizations of HTML5 based Web Platform Technology
 
HTTP 완벽가이드 : 1-1 http 개관
 HTTP 완벽가이드 : 1-1 http 개관 HTTP 완벽가이드 : 1-1 http 개관
HTTP 완벽가이드 : 1-1 http 개관
 
인터넷 서비스의 종류
인터넷 서비스의 종류인터넷 서비스의 종류
인터넷 서비스의 종류
 
Interface and Protocol
Interface and ProtocolInterface and Protocol
Interface and Protocol
 
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]Ch01 네트워크와+소켓+프로그래밍+[호환+모드]
Ch01 네트워크와+소켓+프로그래밍+[호환+모드]
 
모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개모바일 메신저 아키텍쳐 소개
모바일 메신저 아키텍쳐 소개
 
NAT and Hole Punching_SYS4U I&C
NAT and Hole Punching_SYS4U I&CNAT and Hole Punching_SYS4U I&C
NAT and Hole Punching_SYS4U I&C
 
UI/UX Technology Trends on the Next Generation Web
UI/UX Technology Trends on the Next Generation WebUI/UX Technology Trends on the Next Generation Web
UI/UX Technology Trends on the Next Generation Web
 
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
CMS를 활용한 도서관웹사이트 발전방향 _ ㈜나인팩토리인터랙티브
 

More from 정혁 권

린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
정혁 권
 
User stories
User storiesUser stories
User stories
정혁 권
 
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
정혁 권
 
Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )
정혁 권
 
2011 Mobile & Web technologies
2011 Mobile & Web technologies2011 Mobile & Web technologies
2011 Mobile & Web technologies
정혁 권
 
2011 The Year of Web apps
2011 The Year of Web apps2011 The Year of Web apps
2011 The Year of Web apps
정혁 권
 
HTML5 on mobile
HTML5 on mobileHTML5 on mobile
HTML5 on mobile
정혁 권
 
HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기
정혁 권
 
Twitter Api Mashup
Twitter Api MashupTwitter Api Mashup
Twitter Api Mashup
정혁 권
 
IT in Contact Center industry
IT in Contact Center industryIT in Contact Center industry
IT in Contact Center industry
정혁 권
 

More from 정혁 권 (10)

린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
린분석 with 레진코믹스 ( Lean Analytics with Lezhin Comics )
 
User stories
User storiesUser stories
User stories
 
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
모바일 콘텐츠 서비스와 콘텐츠 유료화 전략
 
Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )Mobile 시대의 SEO ( Search Engine Optimization )
Mobile 시대의 SEO ( Search Engine Optimization )
 
2011 Mobile & Web technologies
2011 Mobile & Web technologies2011 Mobile & Web technologies
2011 Mobile & Web technologies
 
2011 The Year of Web apps
2011 The Year of Web apps2011 The Year of Web apps
2011 The Year of Web apps
 
HTML5 on mobile
HTML5 on mobileHTML5 on mobile
HTML5 on mobile
 
HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기HTML5 로 iPhone App 만들기
HTML5 로 iPhone App 만들기
 
Twitter Api Mashup
Twitter Api MashupTwitter Api Mashup
Twitter Api Mashup
 
IT in Contact Center industry
IT in Contact Center industryIT in Contact Center industry
IT in Contact Center industry
 

웹을 지탱하는 기술

  • 1. 웹을 지탱하는 기술 권정혁 @xguru http://xguru.net guru@xguru.net 2-14 페이지는 강원대학교 문양세 교수님의 수업자료 http://j.mp/P4Zawc 를 발췌하여 정리하였습니다. 그 이후 페이지는 멘토르 출판사의 “웹을 지탱하는 기술” 책의 내용을 기반으로, 제가 첨삭하여 정리하였습니다.
  • 2. 인터넷 ? 정형적(formal) 정의 TCP/IP 프로토콜을 통해 연결되어 있는 전 세계적인 네트워크 컴퓨터 기술과 통신 기술이 기본이 되어, 각기 다른 기관에 의해 다른 목적으로 구성된 네트워크들 이 서로 연결되어 전 세계를 묶는 하나의 거대한 네트워크로, 다양한 서비스를 제공하는 지구촌 네 트워크 또 다른 정의 세계 최대 컴퓨터 통신망 (interconnected network Æ Internet) TCP/IP 프로토콜을 사용하는 세계적 규모의 컴퓨터 통신망 통신망 들의 통신망(network of networks) 정보의 바다 가상의 공간(cyber space)
  • 3. 인터넷의 탄생 ARPANET ( http://en.wikipedia.org/wiki/ARPANET ) 미국 국방부의 주도하에 만들어진 세계 최초의 패킷 스위칭 네트워크 1969년에 시작, 현재의 인터넷의 원형 발족당시 UCLA , UCSB ( 산타바바라 ) , Utah 대, SRI ( 스탠포드 연구소 ) NCP ( Network Control Program ) 을 이용하였으나, 1983년부터 TCP/IP로 대체
  • 4. 인터넷의 탄생 #2 NSFNET : National Science Foundation Network http://en.wikipedia.org/wiki/NSFNET 미국 국립과학재단(NSF)에서 1980년 후반부터 NSFNET을 본격적으로 보급 1990년대 초까지 인터넷에 연결된 전 세계 컴퓨터는 NSFNET에 직/간접적으로 연결되어, NSFNET을 “백본”이라 부름 1995년 NSFNET의 백본이 사라지고, 일반 회사들이 운영하는 상용 백본 등장
  • 5. 인터넷의 발전 1969 미 국방성 알파넷(ARPANET) 등장 1972 이메일 탄생 1974 인터넷(Internet) 용어 처음 사용 1975 TCP/IP 개발, 시운전 개시 1979 USENET 구축(net* 뉴스그룹 생성) 1982 TCP/IP 도입 ( 인터넷 개념 정립 ) 1984 DNS (Domain Name System ) 제시 1986 NSFNET 구축 1991 팀 버너스 리에 의해 WWW(WorldWideWeb) 개발 1993 InterNIC, Mosaic 등장으로 WWW 사용율 급증 1994 넷스케이프 네비게이터 1.0 발표 , W3C 구성 1995 NSFNET 해체되고 ISP 등이 운용. 본격 상업화, 대중화, 정보 고속화 1996 MS Internet Explorer 발표 1998 세계 인터넷 이용자수 1억명 돌파
  • 6. 인터넷 관련 기구 ICANN (The Internet Corporation for Assigned Names and Number) ‘국제인터넷주소관리기구’ 새로운 도메인 체계의 도입, IP 주소 할당, DNS 관리 등 IETF(Internet Engineering Task Force) 인터넷 표준안을 제정하기 위한 기술위원회 W3C(World Wide Web Consortium) HTML의 규격, 스타일시트(CSS), HTML5 와 같은 웹 관련 기술에 대한 표준안 제정 NIC(Network Information Center) 국가별, 대륙별 인터넷 이용기관을 위한 주소 등록 서비스를 수행하고, 주요 정보 서비스를 제공 KRNIC(Korea Network Information Center) ‘한국인터넷정보센터’ 우리나라 IP 주소 할당, 도메인 네임 관련 DB 관리, 새로운 도메인 네임 도입 등을 수행
  • 7. 네트워크 란 ? 네트워크 개념적 정의 네트워크는 사용자의 컴퓨터를 인터넷에 연결시켜주는 게이트(gate)와 다양한 컴퓨터들이 서로 연결되어 정보를 주고받을 수 있는 뼈대와 같은 역할들을 수행하는것이다. 네트워크는 통신선로에 의해 서로 연결되어 있는 일련의 정보원(노드: node)와 통신매체(링크: link)의 집합을 의미한다. 네트워크는 두 대 이상의 컴퓨터를 연결하여 근거리나 원거리 통신을 제공하고 서로 연결된 요소 들 간의 데이터를 등을 전송할 수 있도록 해준다. “통신”의 정의 어원은 ‘공유한다’는 의미를 갖는 라틴어 ‘communicare’ 에 있다. 송신자와 수신자 사이에 전송 매체인 통신로를 통하여 정보를 전달하는 것 또는 그 과정으로 정의 하며 정보를 정확하게 전달하는 것을 목적으로 한다. 통신을 위해 필요한 요소 대화를 나눌 수 있는 상대방 ➠ 송신자, 수신자 정보를 전달하기 위한 매체 ➠ 공기, 전화선 등 의사소통에 필요한 공통 언어 및 공통된 규약(프로토콜)
  • 8. 네트워크 프로토콜 프로토콜은 통신을 위해 사람들이 정해 놓은 규약으로 서로 다른 장치나 컴 퓨터간의 데이터 통신에 필요한 규약 대표적인 프로토콜: TCP/IP , HTTP TCP/IP (transmission control protocol / Internet protocol) 1. TCP는 (송신하는) 데이터를 패킷으로 분해 2. IP는 패킷을 전송하는 역할을 담당 (주소 등 정보를 포함한 패킷 헤더 가짐) 3. (중간에 있는) 라우터들은 IP 헤더를 검사하여 최종 목적지까지 패킷을 전달 4. 목적지에서는 패킷이 잘 전달되었는지 검사 5. TCP에서 다시 재결합하여 원래의 데이터로 전달
  • 9. 네트워크 프로토콜 HTTP(hypertext transfer protocol) HTML 문서의 송수신을 위해 사용하는 프로토콜 URL 지정 시, “http://”라 명시하는 것도 이 이유 때문임 HTTP는 TCP/IP 위에서 동작하는 응용 프로토콜 임 http://en.wikipedia.org/wiki/Http
  • 10. 네트워크 모델 : C/S vs. P2P 클라이언트 / 서버 모든 자원들을 서버에서 관리하면서 클라이언트 요청에 따라 필요한 정보를 제공하는 모델 대표적 예: 웹 서버 , FTP 서버 , 메일 서버 , 프린터 서버 등 장점 강력한 중앙집중식 보안 체계 관리 기능 중앙집중식 파일 저장을 통해, 데이터 관리와 백업이 용이함 서버의 하드웨어/소프트웨어를 공동으로 사용하기 때문에, 시간과 비용 절감 공유된 네트워크 자원을 이용할 때 빠르고 체계적으로 제공 단점 고가의 전용 서버와 네트워크 운영체제가 필요 전문적 지식을 가진 관리자가 필요
  • 11. 네트워크 모델 : C/S vs. P2P Peer-to-Peer 모델 ( P2P ) 피어 투 피어 모델은 서버와 클라이언트가 별도로 존재하지 않음 즉, 모든 컴퓨터가 서버이며 동시에 클라이언트가 될 수 있음 서버가 별도로 없으므로 모든 사용자들은 서로의 자원 등을 네트워크를 통하여 공유. 장점 서버 장비나 소프트웨어에 대한 추가적 비용 부담이 없음 시스템 설정이 용이함 , 모든 사용자가 자원의 공유를 직접 관리 작업의 수행을 위해 다른 컴퓨터에 의존하지 않음 , 구축 비용이 저렴함 단점 자신의 작업과 다른 사용자의 작업을 동시에 처리함으로 부하가 발생 많은 네트워크 접속을 야기할 수 있음 파일/DB의 보관이 여러 컴퓨터에서 이루어져 비효율과 중복의 문제 발생 모든 사용자가 컴퓨터를 잘 알고 있어야 하며, 관리가 어려움
  • 12. IP 주소와 클래스 IP 주소 (IP address) 통신망에 연결된 컴퓨터를 구별 할 수 있는 방법 인터넷에 연결된 각 컴퓨터마다 고유한 번호 부여 통신망 번호와 각 망에 연결된 컴퓨터 고유 번호 부여 IP 클래스 (IP class) 네트워크는 크기에 따라 A, B, C, D등의 등급으로 분류되고, 이들 간 구분은 IP 주소 맨 앞자리 octet(byte)의 상위 비트로 표현 IP 주소 형태 IP주소는 32bit(32자리 이진수)로 되어 있으나, 일반적으로 4개의 octet(4개의 8자리 이진수) 로 나누어 10진수로 표기한다.
  • 13. 도메인 네임과 네임서버 사람들이 기억하기 쉽고 사용하기 편리하기 위해 인터넷에서는 도메인네임 (Name)이라는 또 다른 주소를 제공. 도메인 네임 서버(Domain Name Server)에서 도메인 네임을 관리 컴퓨터가 속한 기관이나 국가에 따라서 계층적으로 형성 일반적으로 “컴퓨터이름.기관이름.기관종류.국가이름” 형태로 사용. multi.hansung.ac.kr , xguru.net 미국의 경우는 마지막에 국가가 없이 .edu , .com , .net 등을 사용
  • 14. TLD : Top Level Domain 도메인 국가명 기관명 미국 그외 국가 kr Korea 교육기관 edu ac jp Japan 사업체 com co uk United Kingdom 정부기관 gov go fr France 비영리 공공기관 org or ca Canada 네트웍 관련기관 net ne de Germany 사업 biz it italy 정보 info ly Libya io Indian Ocean is Iceland to Tonga
  • 16. Web의 출현 웹 출현 이전에 인터넷은? (컴퓨터) 전문가들의 외부 컴퓨터에 접속, 정보를 공유하는 수단 주로 telnet, ftp 등이 인터넷 서비스의 대표적 수단이었음 일반인이 인터넷을 사용하기에는 어려움이 많았음 Tim Berners-Lee CERN ( 유럽 입자 물리학 연구소 ) 의 연구원 하이퍼링크 기반의 문서 구조를 제안 문서에서 링크를 통해 다른 링크로 연결하는 (당시에는) 혁신적 개념 하이퍼링크를 지원하는 HTTP(hypertext transfer protocol)에 대한 RFC 제출 하이퍼링크와 HTTP는 오늘날 웹이 있게 한 인터넷 역사에서 중요한 기술로 인정 받음 http://en.wikipedia.org/wiki/Tim_Berners-Lee
  • 17. 웹이란 무엇인가 ? Web 은 현재 모든 IT 의 주요 기반 인터넷과 웹은 인간이 만든것 중 가장 중요한 것중 하나 다양한 웹의 용도 웹사이트 : 포털 / SNS / 검색 / 쇼핑 .. 서버한대부터 수천/수만대의 서버까지 구성 유저 인터페이스로서의 웹 스마트 TV , 프린터 냉장고 프로그램을 위한 API 로서의 웹 ( Application Programming Interface ) 웹서비스 Open API / Web API 프로그램 중심의 인터페이스
  • 18. 웹을 지탱하는 기술 HTTP : Hyper Text Transfer Protocol URI : Uniform Resource Identifier HTML : Hyper Text Markup Language 애플리케이션 컨트롤 HTTP는 URI로 조작대상을 HTTP HTML 은 HTTP로 지정한다. 전송된다. URI HTML HTML의 링크는 URI를 리소스 식별자 이용한다. 하이퍼미디어 포맷 하이퍼 미디어 : Hyper Link로 연결된 텍스트/이미지/음성/영상. 정보의 연결 분산 시스템 : 웹은 전 세계에 배치된 서버에, 전 세계의 브라우저가 접속하는 분산 시스템
  • 19. What is Port ? TCP/UDP 프로토콜이 사용하는 가상의 논리적 통신 연결부 0~65535번까지의 번호로 구별되며, IP와 함께 사용 0~1023 : Well Known Port 1024 ~ 49151 : Registered Port 49152 ~ 65535 : Dynamic Port
  • 20. 웹 이전의 인터넷 eMail : SMTP , POP3 , IMAP , Exchange SMTP (25,587): Simple Mail Transfer Protocol POP (110,995) : Post Office Protocol IMAP (143,993) : Internet Message Access Protocol FTP (21) : File Transfer Protocol Telnet (23) , SSH(22) Gopher (70) USENET , Newsgroup NNTP ( 119 , 563 ) : Network News Transfer Protocol IRC : Internet Relay Chat 194 but de facto is 6667 , 6660~6669,7000 http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
  • 21. 웹의 탄생 1990-11-12 Tim Berners-Lee @ CERN 인터넷 기반의 ‘분산정보관리 시스템’ 웹 제안서 작성 http://www.w3.org/Proposal 바로 개발시작해서 크리스마스 휴가에 첫 버전의 서버와 브라우저 완성
  • 22. 웹의 보급 시작 1993. NCSA Mosaic National Center for Supercomputing Application 이미지가 보이는 첫번째 브라우저
  • 25. REST 의 탄생 REST : Representational State Transfer 웹이 왜 이렇게 성공했는지, 어떻게 대규모의 시스템이 만들어졌는지 소프트웨어 아키텍처의 관점 에서 분석하고 하나의 아키텍쳐 스타일로 정리 - 2000년 Roy Fielding Architectural Styles and the Design of Network-based Software Architectures http://j.mp/REST_roy HTTP 는 하이퍼텍스트를 전송하기 위한 프로토콜이지만, 실제로는 하이퍼텍스트 이외의 다양한 것을 전송하고 있으며, 그것은 리소스 상태 ( Resource State ) 의 표현 ( Presentation )
  • 26. Web API 전쟁 : SOAP vs. REST 초기의 웹은 학술논문 교환 및 문서를 읽기 위한 시스템 웹의 용도가 다양화 되면서 프로그램을 이용한 자동화 처리 요구 발생 SOAP 의 탄생 초기에는 Simple Object Access Protocol 이었지만 그냥 SOAP으로 개정 HTTP를 트랜스포트 프로토콜로 사용. XML을 이용한 다양한 별도 프로토콜 정의 WS-Security , WS-Transaction , WS-ReliableMessaing 등 다양한 스펙의 난립 2000~2003 년 들어 SOAP vs REST 에 관해 다양한 논쟁이 벌어짐 Amazon 웹서비스가 SOAP/REST 둘다 제공하지만 이용비율이 20/80 이라고 발표 Web2.0 과 함께 Mashup 에 유리한 REST가 점점 더 많이 사용됨 결과적으로 API에선 REST 가 승리. SOAP 도 제한된 용도로는 계속 사용
  • 27. 공유 참여 개방 집단지성 Web 2.0 Web
  • 28.  as
  • 29.  a
  • 31. Web 1.0 HTML in Web Browser Web 2.0 HTTP everywhere
  • 32. REST, 웹의 아키텍처 스타일 REST 는 아키텍처 가 아닌 ‘아키텍처 스타일’ 아키텍처 스타일은 ‘아키텍처 패턴’ 이라고도 하며, 복수의 아키텍처의 공통 된 성질,양식,규정 혹은 독특한 방식을 가리킴 MVC (Model - View - Controller ) , Pipe and Filter , Event System 등 시스템의 아키텍처를 결정할 때 나침반이 되는 것이 ‘아키텍처 스타일’ REST는 클라이언트/서버에서 파생되었으며, 몇가지 제약을 추가한 것 추상화 레벨 웹 에서의 예 아키텍처 스타일 REST 아키텍처 브라우저, 서버, 프록시, HTTP, URI, HTML 구현 Apache, Firefox, Internet Explorer
  • 33. REST 개념 : Resource 리소스 : 웹상에 존재하는 이름을 가진 모든 정보 서울의 일기예보 http://weather.naver.com/rgn/cityWetrCity.nhn?cityRgnCd=CT001013 양념치킨 만드는 법 소개 페이지 http://xguru.net/51 청량리역의 사진 http://www.flickr.com/photos/nala2sky/3790226694 Roy Fielding 의 REST 논문 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm xguru의 최근 트윗 http://twitter.com/xguru 리소스는 각각 URI로 의미있는 이름을 가지며, 쉽게 접근이 가능하다. 1개의 리소스가 복수개의 URI 를 가질수 있다. http://weather.example.com/seoul/today http://weather.example.com/seoul/2012-01-01 리소스는 여러개의 형태를 가질수 있다. 일기예보 : HTML , PDF , 이미지 등등 리소스의 상태는 시간등에 따라 표현이 변할수 있다.
  • 34. REST 의 스타일 #1 클라이언트 / 서버 Client Server, CS 클라이언트 서버 웹은 HTTP 프로토콜을 이용하여 클라이언트와 서버가 통신 유저 인터페이스 담당 데이터 스토리지 담당 Request / Response 모델 클라이언트 = 멀티 플랫폼 , 서버는 = 복수서버로 증설가능 Stateless 서버 Client Stateless Server, CSS 스테이트리스 클라이언트 서버 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않음 클라이언트의 애플리케이션 상태를 관리하지 않는다. 서버의 구현이 간략화 됨. 클라이언트 많이들 쓰는 “Cookie 를 사용한 세션관리”는 이에 위배됨 요청마다 모든 정보를 송신한다.
  • 35. REST 의 스타일 #2 캐시 Client Cache Stateless Server, C$SS 클라이언트 스테이트리스 ($) 서버 한번 가져온 리소스를 클라이언트측에서 재사용 캐시에 필요한 정보를 클라이언트 클라이언트에게 전달 ($) 통신량을 줄여서 처리시간 축소. 신뢰성 떨어질 가능성 같은 요청의 결과를 재이용 유니폼 인터페이스 Uniform Client Cache Stateless Server, UC$SS 스테이트리스 클라이언트 서버 URI로 지정된 리소스에 대한 조작을 통일된 인터페이스로 수행 스테이트리스 HTTP 1.1 은 8개의 메소드만 있음 클라이언트 서버 모든서버가 같은 인터페이스 아키텍처가 간결하고, 클라이언트 / 서버 구현의 중립성이 향상 를 채용한다.
  • 36. REST 의 스타일 #3 계층화 시스템 Uniform Layered Client Cache Stateless Server, ULC$SS 유니폼 인터페이스의 이점으로 계층화가 쉬워짐 로드밸런서를 통한 부하분산. 프록시을 통한 액세스 제어 등이 추가되어도 클라이언트는 모르며, 이것은 HTTP를 통일한 인터페이스로 사용했기 때문 Layered System : 시스템을 몇개의 계층으로 분리하는 아키텍쳐 스타일 스테이트리스 클라이언트 서버 인터페이스가 다른 레거시 시 스템에 접속할수 있게 한다. 스테이트리스 서버 클라이언트 프록시 스테이트리스 시스템을 복수의 계층으로 분 서버 할한다.
  • 37. REST 의 스타일 #4 코드온 디맨드 Uniform Layered Code on Demand Client Cache Stateless Server, ULCODC$SS 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍쳐 스타일 Javascript , Flash , Java 애플릿 등 애플리케이션 프로토콜의 가시성은 저하될수 있음 HTML5 와 함께 Javascript 가 더욱 중요해 지고 있음 스테이트리스 클라이언트 서버 인터페이스가 다른 레거시 시 스템에 접속할수 있게 한다. 스테이트리스 서버 클라이언트 프록시 스테이트리스 서버 서버가 제공하는 코드를 클라이언트에서 실행
  • 38. REST 의 스타일 #5 클라이언트/서버 : 유저인터페이스와 처리를 분리한다. 스테이트리스 서버 : 서버측에서 애플리케이션의 상태를 가지지 않는다. 캐시 : 클라이언트와 서버의 통신회수와 양을 감소시킨다. 유니폼 인터페이스 : 인터페이스를 고정한다. 계층화 시스템 : 시스템을 계층별로 분리한다. 코드온 디맨드 : 프로그램을 클라이언트에 다운로드하여 실행한다. 이중 몇가지만 활용하여 만드는 아키텍쳐도 가능 쿠키등을 활용하여 세션에 저장함으로써 스테이트풀 하지만 , URI형식은 그대로 따르는..
  • 40. URI 의 스펙 URI : Uniform Resource Identifier , RFC 3986 리소스를 통일적으로 식별하는 ID 웹상에 존재하는 모든 리소스를 한결같은 방식으로 보여줄수 있음 URI 의 구문 http://blog.example.com/entries/1 URI Scheme : http Hostname : blog.examples.com Path : /entries/1 유일한 호스트명/경로를 사용함으로써, URI 가 중복되지 않음
  • 41. URI 심화 http://xguru:pass@xguru.net:8000/search?q=testdebug=true#n10 URI Scheme : http 구분자 - :// 사용자정보 : id = xguru , pwd = pass 구분자 - @ 호스트명 : xguru.net 구분자 - : 포트번호 : 8000 생략시 각 URI Scheme 의 기본 값이 사용됨. http 의 기본포트번호는 80 패스 : /search 구분자 - ? 쿼리 파라미터 : q=testdebug=true URI Fragment : #n10 절대 URI , 상대 URI . 은 현재 , .. 은 상위
  • 42. URI와 문자 URI 에 쓸수 있는 문자 알파벳 : A-Za-z 숫자 : 0-9 예약문자 : ; | / | ? | : | @ | | = | + | $ | , 비예약문자 : - | _ | . | ! | ~ | * | ' | ( | ) % 인코딩 허용하지 않는 문자들을 URI에 사용할때 인코딩 하는 방식 http://ko.wikipedia.org/wiki/가 ➠ http://ko.wikipedia.org/wiki/%EA%B0%80 % ➠ %25 , Space = %20 , URI 길이제한 스펙상 제한은 없으나, 구현상 제한이 존재. IE는 2038 바이트 제한
  • 43. URI의 설계 Cool URIs don’t change URI 가 바뀔경우 다시 그 자료를 찾기가 어려워진다. Cool URI 는 심플한 URI를 의미하기도 한다. 예 ) Apple 웹사이트 변하지 않는 URI 만들기 프로그래밍 언어 의존적인 확장자와 경로를 포함하지 않는다. http://example.com/cgi-bin/login.pl , http://example.com/servlet/LoginServlet 메서드명과 세션ID를 포함하지 않는다. http://example.com/Login.do?action=showPage , http://example.com/home.jsp? jsessionid=12345678 URI는 리소스를 표현하는 명사로 한다. http://example.com/sample/people/show/123 = http://example.com/sample/people/123
  • 44. URI설계의 테크닉 확장자로 표현(Presentation)을 지정한다. 다국어 지원 HTTP의 Content-Negotiaion 기능 활용도 가능 http://example.com/2001/05/01/press.ko GET /2010/05/01/press HTTP/1.1 Host: example.com http://example.com/2001/05/01/press.en Accept-Language: ko,en-us;q=0.7,en;q=0.3 리소스 형태 분리 http://example.com/data/myplace.html http://example.com/data/myplace.json http://example.com/data/myplace.txt 매트릭스 URI http://example.com/map/lat=35.343243;lng=139.123232 http://example.com/test/123232,testmessage
  • 45. URI 는 중요하다 URI 는 리소스의 이름이다. URI 는 수명이 길다. URI 는 브라우저가 어드레스 란에 표시한다. 검색엔진이 중요하게 보는 데이터이다 ( Search Engine Optimization ) 탁월한 URI 구성 예제는 apple.com 을 참고하자 http://www.apple.com/iphone/features/ http://www.apple.com/ipad/specs/ http://www.apple.com/macbook-pro/performance/ http://www.apple.com/support/iphone/syncing/
  • 47. HTTP 의 역사 HTTP 0.9 - HTTP의 탄생 팀 버너스리가 최초에 웹을 발명했을때 사용하던 프로토콜 현재의 HTTP와 다르게 헤더가 없으며, GET 메소드만 있음. 현재 사용되지 않음 HTTP 1.0 - HTTP 최초의 표준화 IETF 에서 표준화하여 1993년에 Draft 공개후, 1996년에 최종 버전(RFC 1945) 공개 헤더의 도입, GET 이외의 메서드 추가 HTTP 1.1 - HTTP의 완성 1997년 RFC 2068 에서 개정하여 1999년 RFC 2616 발행. 현재의 1.1 스펙 채널전송, Accept 헤더에 의한 컨텐츠 네고시에이션, 캐쉬 컨트롤, Keep-Alive 등 추가 SPDY - 좀더 빠른 웹을 위한 실험적인 프로토콜 구글이 제안하는 HTTP 프로토콜의 개선안. SSL/헤더압축/다중스트림/요청우선순위..
  • 48. HTTP 기본 클라이언트가 서버에 접속하여 Request 를 보내고 Response 를 받음 동기형 프로토콜 : 서버에서 응답올때까지 대기 GET
  • 49.  /
  • 51.  xguru.net Client HTTP/1.1
  • 52.  200
  • 53.  OK Server Date:
  • 55.  08
  • 56.  Sep
  • 60.  keep-alive Server:
  • 65.  max-age=0 0.9.8e-fips-rhel5
  • 70.  Mac
  • 71.  OS
  • 72.  X
  • 73.   X-Powered-By:
  • 79.   Content-Encoding:
  • 81.  Safari/537.4 Vary:
  • 85.  19
  • 86.  Nov
  • 91.  gzip,deflate,sdch메시지 구축 1.요청 Cache-Control:
  • 95.   1.(요청을 대기) Accept-Language:
  • 96.  en-US,en;q=0.8 post-check=0,
  • 97.  pre-check=0 2.요청 메시지 송신 2.요청 메시지 수신 Accept-Charset:
  • 99.  no-cache 3.(응답돌아올때까지 대기) 3.요청 메시지 해석 WP-Super-Cache:
  • 103.  file 4.응답 메시지 수신 Keep-Alive:
  • 105.  max=100 4.적절한 애플리케이션 프로그 5.응답 메시지 해석 Connection:
  • 106.  Keep-Alive 램으로 처리를 위임 6.클라이언트의 목적을 달성하 Transfer-Encoding:
  • 107.  chunked 5.애플리케이션 프로그램으로부 기 위해 필요한 처리 Content-Type:
  • 109.  charset=UTF-8 터 결과를 취득 6.응답 메시지 구축 !DOCTYPE
  • 110.  html 7.응답 메시지 송신 htmlhead~~~
  • 111. HTTP 메시지 : Request 요청 라인 : Request 메시지의 첫번째 줄 GET
  • 113.  HTTP/1.1 GET /test HTTP/1.1 http://example.com/test 에 대한 최소한의 요청은 Host:
  • 114.  example.com 메소드 요청
  • 115.  URI 프로토콜
  • 116.  버전 GET
  • 118.  HTTP/1.1 복잡한 URI에도 요청라인은 동일 Host:
  • 119.  example.com:8080 절대 URI 요청의 경우 Host 헤더 생략가능 GET
  • 121.  HTTP/1.1 두번째줄 부터는 복수개의 Header 가 이어짐 “이름: 값” 형태의 구성 ➠ Host: example.com , User-Agent: Mozilla/5.0 요청메시지에도 헤더뒤에 Body 가 오는 경우가 있음 POST,PUT 같은 메소드를 통해 리소스를 작성하거나 갱신할 때
  • 122. HTTP 메시지 : Response Status Line : 응답메시지의 첫줄 HTTP/1.1 HTTP/1.1
  • 123.  200
  • 124.  OK 프로토콜
  • 125.  버전 200 스테이터스
  • 126.  코드 OK 텍스트
  • 127.  구문 Content-Type:
  • 129.  charset=UTF-8 Content-Length:
  • 130.  12342 스테이터스 코드로 결과의 상태를 표현 !doctype
  • 131.  html5 html 프로그램에서 이 코드를 통해 상태 파악 ... /html Request 와 같이 두번째줄 부터는 복수개의 Header 가 이어짐 Content-Type 헤더를 통해 MIME 미디어 타입 (text/html)과 문자인코딩 타입(utf-8)을 전송 Content-Length 헤더를 통해 이어지는 Body 의 크기를 알려줌 Body 에 실제 문서데이터가 포함 헤더와 바디는 빈줄 ( CRLF ) 로 구분 HTML 또는 다양한 문서형식 가능 MIME : Multipurpose Internet Mail Extension
  • 132. HTTP 메시지의 구성요소 스타트 라인 ( Start Line ) Method 공백 URL 공백 프로토콜버전 CR LF Header Field Name : Value CR LF : 헤더 ( Header ) : Header Field Name : Value CR LF 빈줄 ( Blank Line ) CR LF 바디 ( Body ) Body
  • 133. Stateful / Stateless Stateful 대화 Stateless 대화 손님: 안녕하세요. 손님: 안녕하세요. 점원: 어서 오세요. OO 햄버거입니다~. 점원: 어서 오세요. OO 햄버거입니다~. 손님: 햄버거 세트 하나 주세요. 손님: 햄버거 세트 하나 주세요. 점원: 사이드 메뉴는 무엇으로 하시겠습니까? 점원: 사이드 메뉴는 무엇으로 하시겠습니까? 손님: 포테이토요. 손님: 햄버거 세트랑 포테이토 주세요. 점원: 음료수는 무엇으로 하시겠습니까? 점원: 음료수는 무엇으로 하시겠습니까? 손님: 콜라로 주세요. 손님: 햄버거 세트에 포테이토랑 콜라로 주세요. 점원: 50원 추가하시면 음료수를 L사이즈로 할 수 있는데 어떠신가요? 점원: 50원 추가하시면 음료수를 L사이즈로 할 수 있는데 어떠신가요? 손님: 그냥 M사이즈로.. 손님: 햄버거 세트에 포테이토랑 콜라는 M사이즈로.. 점원: 추가하실 건 없으시고요? 점원: 추가하실 건 없으시고요? 손님: 예 손님: 햄버거 세트에 포테이토랑 콜라는 M사이즈로 부탁해요. 이상. 점원: 알겠습니다. 점원: 알겠습니다 스테이트풀한 대화는 간결함 Stateful 스테이트리스한 대화는 장황함 • Session 상태 유지 필요 스테이트풀한 대화에서 서버는 클라이언트의 주문내역을 기억함 • FTP 가 대표적인 Stateful 프로토콜 로그인에서 아웃까지 모든 상태를 서버가 관리함 스테이트리스한 대화에서 클라이언트는 매번 모든 주문을 반복함
  • 134. Stateful 의 단점 서버가 클라이언트의 상태를 기억하는것은 클라이언트 수가 늘어날수록 어려워짐 하나의 서버가 동시에 상대할수 있는 클라이언트 수에는 한계가 있음 서버가 늘어날 경우 클라이언트 별로 상대할 서버를 지정할수가 없으므로 상태 동기화가 필요 A씨는 햄버거와 포테이토고.. A씨는 햄버거와 포테이토고.. B씨는 애플파이고.. B씨는 애플파이고.. C씨는 아직 주문안함 C씨는 아직 주문안함 D씨는 햄버거 D씨는 햄버거 A B C D ... 커피 추가요! 생수 주세요! 햄버거 세트 카페오레
  • 135. Stateless 의 장점 클라이언트가 요청 메시지에 필요한 정보를 모두 포함시킴 지난 대화를 기억해 두지 않더라도 현재 상태를 바로 알수 있음 Self Descriptive Message : 클라이언트가 자신의 상태를 기억, 모든 요청을 상태와 함께 보냄 서버를 늘리기만 해도 바로 확장가능. 매번 어떤 서버로 요청을 보내도 상관없음 A B C D ... 햄버거와 애플파이와 햄버거와 햄버거 세트 포테이토에 커피! 생수 주세요! 카페오레
  • 136. Stateless 의 단점 퍼포먼스의 저하 : 매번 필요한 정보를 모두 송신하기 때문 송신할 데이터의 양이 많아진다. 사용자 인증등 서버에 부하가 걸리는 처리를 반복한다. 통신 에러에 대한 대처 필요 Stateful 대화 Stateless 대화 손님: 햄버거 1개 주세요. 이상. 손님: 햄버거 1개 주세요. 이상. 점원: 알겠습...(소음으로 들리지 않는다.... ). 점원: 알겠습..( 소음으로 들리지 않는다....). 손님: (확인하기 위해 다시 한 번...) 햄버거 1개 주세요. 이상. 손님: (확인하기 위해 다시 한 번..) 햄버거 1개 주세요. 이상. 점원: 손님께선 이미 1개 주문하셨는데, 맞으신가요? 점원: 알겠습니다.
  • 137. HTTP Method HTTP 1.1 에 정의된 메쏘드는 단 8개, 그중에서도 5~6개만 사용 Method 용도 의미 GET Read 리소스 취득 POST Create 서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리 PUT Update 리소스 갱신, 리소스 작성 DELETE Delete 리소스 삭제 HEAD 리소스의 헤더(메타 데이터) 취득 OPTIONS 리소스가 서포트하는 메소드의 취득 TRACE 자기 앞으로 요청 메시지를 반환(루프 백) 시험 CONNECT 프록시 동작의 터널 접속으로 변경
  • 138. HTTP : GET GET ( Read ) 지정한 URI 정보 가져오기. 브라우저의 기본 동작. 가장 이용빈도가 높음 GET /list HTTP/1.1 HTTP/1.1 200 OK Host: example.com Content-Type: application/json { {uri: http://example.jp/list/item1 } , {uri: http://example.jp/list/item2 } , {uri: http://example.jp/list/item3 } , {uri: http://example.jp/list/item4 } }
  • 139. HTTP : POST POST ( Create ) 리소스의 작성 : 새로 생성된 리소스의 URI가 Location 에 리턴 POST /list HTTP/1.1 HTTP/1.1 201 Created Host: example.com Content-Type: text/plain;charset=utf-8 Content-Type: text/plain; charset=utf-8 Location: http://example.com/list/item5 안녕하세요! 안녕하세요! 다른 메소드로는 대응할 수 없는 처리 요청하는 URI 가 매우 길어서 처리가 불가능할 경우 ( URI가 2000자가 넘거나.. ) http://example.com/search?q={엄청엄청긴 검색 문자열} POST /search HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded q=very+long+keyword+foo+bar+...
  • 140. HTTP : PUT PUT ( Update ) 리소스의 갱신 GET /list/item5 HTTP/1.1 HTTP/1.1 200 OK Host: example.com Content-Type: text/plain; charset=utf-8 안녕하세요! PUT /list/item5 HTTP/1.1 HTTP/1.1 200 OK Host: example.com Content-Type: text/plain; charset=utf-8 Content-Type: test/plain; charset=utf-8 좋은 밤이네요! 좋은 밤이네요! PUT을 POST 와 마찬가지로 자료의 생성에 쓸수도 있지만, 가능하면 POST/PUT을 분리하여 Create/Update 로 쓰는것이 바람직 하다.
  • 141. HTTP : DELETE,HEAD,OPTIONS DELETE (Delete) : 리소스를 삭제 DELETE /list/item2 HTTP/1.1 HTTP/1.1 200 OK Host: example.com OR HTTP/1.1 204 No Content HEAD : 리소스의 헤더만 취득 HEAD /list/item5 HTTP/1.1 HTTP/1.1 200 OK Host: example.com Content-Type: text/plain; charset=utf-8 바디가 포함되지 않아 네트워크 대역을 절약하면서 리소스의 크기 조사 및 갱신일자 취득이 가능 OPTIONS : 리소스가 서포트 하는 메서드의 취득 OPTIONS /list HTTP/1.1 HTTP/1.1 200 OK Host: example.com Allow: GET, HEAD, POST OPTIONS /list/item5 HTTP/1.1 HTTP/1.1 200 OK Host: example.com Allow: GET, HEAD, PUT, DELETE
  • 142. GET/POST 현실적으로 가장 많이 이용되는 것은 GET/POST HTML의 Form 에서 지정할수 있는 메서드가 오직 GET/POST 이기 때문 form target=”/list/item1” action=”GET” form target=”/list/item1” action=”POST” /form /form AJAX 에서는 XMLHTTPRequest 를 이용하여 임의의 메서드 사용가능 POST 로 PUT/DELETE 를 대신하는 방법 _method 파라미터 활용 form target=”/list/item1” action=”POST” input type=”hidden” id=”_method” value=”PUT” textarea id=”body” ... /textarea /form X-HTTP-Method-Override POST /list/item1 HTTP/1.1 Host: example.com Content-Type: application/xml; charset=utf-8 X-HTTP-Method-Override: PUT
  • 143. 멱등성과 안정성 통신 에러에 대처하기 위한 HTTP 의 대안 멱등성 ( Idempotence ) : 어떤 조작을 몇번 반복해도 결과가 동일한 것 안전 ( Safe ) : 조작 대상의 리소스의 상태를 변화시키지 않는것 메서드 성질 GET, HEAD 멱등이고 안전하다 PUT,DELETE 멱등이지만 안전하지 않다 POST 멱등이지도 안전하지도 않다 GET의 경우 리소스는 안전하지만, 서버의 로그파일에 기록되고, 히트카운터가 변경이 된다. 쇼핑몰에서 “뒤로” 버튼 눌렀을대 “다시 전송하시겠습니까?” 를 묻는것은 POST 재전송 때문 GET 의 URI 에 action=delete 와 같은 방식으로 쓰거나 하는 방식의 오용은 금물
  • 144. HTTP Status Code 우린 이미 404, 500 과 같은 HTTP 상태코드를 많이 보아 왔다. https://github.com/404 , http://huml.org/404 , http://ifolderlinks.ru/404 상태코드의 분류와 의미 코드 분류 의미 처리가 계속되고 있음. 클라이언트는 요청을 계속하거나, 서버 1xx 처리중 의 지시에 따라 프로토콜 업데이트 후 재전송 2xx 성공 요청이 성공했음을 나타냄 다른 리소스로의 리다이렉트. 클라이언트는 이 코드를 받았을 3xx 리다이렉트 때 응답메시지의 Location 헤더를 보고 새 리소스에 접근 클라이언트의 요청이 에러의 원인. 클라이언트쪽에서 요청을 4xx 클라이언트 에러 수정해서 재 전송해야 한다. 서버가 에러의 원인. 서버측에서 원인이 해결되면, 동일한 요 5xx 서버 에러 청을 보내어 정상적인 결과를 얻을 가능성이 있다.
  • 145. 자주 사용되는 상태코드 200 OK 요청성공 201 Created 리소스 작성 성공 Location 헤더에 새 URI 301 Moved Permanently 리소스가 새 URI로 이동했음 Location 헤더에 새 URI 303 See Other 다른 URI 참조 400 Bad Request 요청 구문이나 파라미터에 오류 401 Unauthorized 접근 권한 없음, 인증실패 WWW-Authenticate 헤더 404 Not Found 리소스 없음 500 Internal Server Error 서버 내부 에러 503 Service Unavailable 서버가 점검등으로 일시적 정지 Retry-After 헤더에 재개시간 하지만, 전체적으로 상태코드를 알고 정확하게 사용할 것
  • 146. HTTP Header #1 HTTP 0.9에는 헤더가 없었고,1.0때 메일스펙(RFC822)에서 형식빌려옴 날짜와 시간 이용하는 메시지 헤더 의미 요청과 응답 Date 메시지를 생성한 일시 If-Modified-Since 조건부 GET으로 리소스의 갱신일시를 지정할때 이용 요청 If-Unmodified-Since 조건부 PUT/DELETE로 리소스의 갱신일시 지정 Expires 응답을 캐시할수 있는 기한 응답 Last-Modified 리소스를 마지막으로 갱신한 일시 Retry-After 다시 요청을 전송할 수 있는 일시의 기준
  • 147. HTTP Header #2 MIME 미디어 타입 ( Multipurpose Internet Mail Extensions ) Content-Type : type/subtype 형태로 미디어타입을 지정하는 헤더 application/xhtml+xml;charset=utf-8 : type = application , subtype = xhtml+xml charset 파라미터로 문자 인코딩 지정가능 타입 의미 예 text 사람이 읽고 직접 이해할수 있는 텍스트 text/plain image 그림 데이터 image/jpeg audio 음성 데이터 audio/mpeg video 동영상 데이터 video/mp4 application 그 밖의 데이터 application/pdf multipart 복수개의 데이터로 이루어진 복합 데이터 multipart/related message 전자메일 메시지 message/rfc822 model 복수 차원으로 구성하는 모델 데이터 model/vrml example 예시용 example/foo-bar
  • 148. HTTP Header #3 MIME 주요 서브타입 타입/서브타입 의미 text/plain 플레인 텍스트 text/csv CSV 형식 텍스트 ( Comma Separated Values ) text/css CSS 형식의 스타일시트 text/html HTML 문서 text/xml XML 문서(비추천) image/jpeg JPEG 이미지 image/png PNG 이미지 application/xml XML 문서 application/xhtml+xml XHTML 문서 application/javascript Javascript 파일 application/json JSON 문서 ( Javascript Object Notation ) application/msword Word application/vnc.ms-excel Excel application/pdf PDF application/zip ZIP application/x-shockwave-flash Flash 오브젝트 application/x-www-form-urlencoded HTML 폼 형식
  • 149. HTTP Header #4 Content Negotiation : 내용 교섭 Accept - 클라이언트가 자신이 처리할수 있는 미디어 타입을 전달 Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8 qvalue 는 0~1 의 값을 가지며, 디폴트 값은 1 서버가 해당 포맷들중에 대응가능한게 없다면 406 Not Acceptable 코드를 리턴 Accept-Charset - 클라이언트가 자신이 처리할수 있는 문자 인코딩을 전달 Accept-Charset: EUC-KR;utf-8;q=0.7,*/*;q=0.7 Accept-Language - 처리할수 있는 언어를 전달 Accept-Language: ko, en-us;q=0.7, en;q=0.3
  • 150. HTTP Header #5 Content-Length 와 Chunk 전송 Content-Length : 메시지에 바디가 있을경우 사이즈를 10진수 바이트로 나타냄 Content-Length: 5538 청크전송 : 사이즈를 모르는 경우 바디를 분할하여 전송가능하게 함 Transfer-Encoding: chunked 각 청크의 시작에는 청크사이즈가 16진수로 들어감, 마지막에는 반드시 길이가 0인 청크와 빈줄 POST /test HTTP/1.1 Host: example.com Transfer-Encoding: chunked Content-Type: Text/plain; charset= utf-8 10 The brown fox ju 10 mps quickly over e the lazy dog. 0 ( 여기에도 빈줄 )
  • 151. HTTP Header #6 인증 ( Authentication ) : Basic 과 Digest Basic 인증 : 사용자 이름과 패스워드에 의한 인증방식. DELETE /test HTTP/1.1 Host: example.com Authorization: Basic XNlcjpwYXNzd29yZA== 매 요청마다 Authorization 헤더에 넣어 전송 ID:PWD 형태로 연결하고 Base64 인코딩한 문자열 ( 간단히 디코딩 가능 ) 누구나 쉽게 볼수 있으므로 HTTPS 통신을 통해 암호화 필요 Digest 인증 : 해시값을 이용한 인증방식 Digest 값 생성 : 서버가 보낸 nonce ( number used once ) , qop ( quality of protection ) 값을 사용 1. 유저이름,realm,패스워드를 : 로 연결하여 MD5 해시값을 구한다. 2. 메서드와 URI 패스를 : 로 연결하고 MD5 해시값을 구한다. 3. 1과 서버로 부터 얻은 nonce , 클라이언트가 nonce 보낸 횟수, 클라이언트가 생성한 nonce, qop , 2의값을 : 로 연결하여 MD5 해 시값을 구하여 보낸다. DELETE /test HTTP/1.1 Host: example.com Authorization: Digest username=yohei, realm=example.com, nonce=1ac421d9e0a4k7q982z966p903372922, uri=/test, qop=auth, nc=00000001, cnonce=900150983cd24fb0d6963f7d28e17f72, response=0fde218e18949a550985b3a034abcbd9, opaque=92eb5ffee6ae2fec3ad71c777531578f
  • 152. HTTP Header #7 캐시 - 서버로부터 가져온 리소스를 로컬 스토리지에 저장하여 재사용 하는것 Pragma - 현재 리소스는 캐시 하지 않도록 한다. Pragma: no-cache Expires - 캐시의 유효기한을 지정한다. Expires: Thu, 11 Sep 2012 16:00:00 GMT Cache-Control - Pragma/Expires 보다 상세한 캐시방법을 지정한다. ( Pragma/Expires대체가능 ) max-age:86400 - 상대적 표현으로 캐시저장기간 지정. 24시간동안 캐시 유지 조건부 GET If-Modified-Since - 리소스가 갱신되었다면 가져온다. 변경되지 않았다면 304 Not Modified
  • 153. 그외에 더 봐두면 좋은것들 OAuth http://www.slideshare.net/tebica/oauth-api-13721761 웹 기술용어 http://www.slideshare.net/kthcorp/kth-1-20120307 API http://www.slideshare.net/kthcorp/kthdetail-day-71api20120718 SEO http://www.slideshare.net/guruguru/mobile-seo-search-engine-optimization