Embed Size (px)
DESCRIPTION
인터넷의 역사부터 웹의 탄생, HTTP 와 REST 등, 우리가 현재의 웹을 이해하는데 필요한 것들만 정리 했습니다. 현업에 개신 개발자 분들은 다들 아시는 내용이겠지만, 정작 우리 주위엔 웹을 많이들 쓰고, 관련해서 일을 하면서도 웹의 내부에 대해서는 잘 모르고 있는 사람들이 많습니다. 웹의 기반기술을 제대로 아는것이, 우리가 좀더 웹을 진지하게 접근하는 것의 시작이라고 생각합니다.
Citation preview
웹을 지탱하는 기술
권정혁@xguru
http://[email protected]
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로 대체
인터넷의 탄생 #2NSFNET : 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. P2PPeer-to-Peer 모델 ( P2P )
피어 투 피어 모델은 서버와 클라이언트가 별도로 존재하지 않음
즉, 모든 컴퓨터가 서버이며 동시에 클라이언트가 될 수 있음
서버가 별도로 없으므로 모든 사용자들은 서로의 자원 등을 네트워크를 통하여 공유.
장점
서버 장비나 소프트웨어에 대한 추가적 비용 부담이 없음
시스템 설정이 용이함 , 모든 사용자가 자원의 공유를 직접 관리
작업의 수행을 위해 다른 컴퓨터에 의존하지 않음 , 구축 비용이 저렴함
단점
자신의 작업과 다른 사용자의 작업을 동시에 처리함으로 부하가 발생
많은 네트워크 접속을 야기할 수 있음
파일/DB의 보관이 여러 컴퓨터에서 이루어져 비효율과 중복의 문제 발생
모든 사용자가 컴퓨터를 잘 알고 있어야 하며, 관리가 어려움
IP 주소 (IP address) 통신망에 연결된 컴퓨터를 구별 할 수 있는 방법
인터넷에 연결된 각 컴퓨터마다 고유한 번호 부여
통신망 번호와 각 망에 연결된 컴퓨터 고유 번호 부여
IP 클래스 (IP class)네트워크는 크기에 따라 A, B, C, D등의 등급으로 분류되고, 이들 간 구분은 IP 주소 맨 앞자리 octet(byte)의 상위 비트로 표현
IP 주소 형태IP주소는 32bit(32자리 이진수)로 되어 있으나, 일반적으로 4개의 octet(4개의 8자리 이진수)로 나누어 10진수로 표기한다.
IP 주소와 클래스
도메인 네임과 네임서버사람들이 기억하기 쉽고 사용하기 편리하기 위해 인터넷에서는 도메인네임(Name)이라는 또 다른 주소를 제공.
도메인 네임 서버(Domain Name Server)에서 도메인 네임을 관리
컴퓨터가 속한 기관이나 국가에 따라서 계층적으로 형성
일반적으로 “컴퓨터이름.기관이름.기관종류.국가이름” 형태로 사용.multi.hansung.ac.kr , xguru.net
미국의 경우는 마지막에 국가가 없이 .edu , .com , .net 등을 사용
TLD : Top Level Domain
도메인 국가명
kr Korea
jp Japan
uk United Kingdom
fr France
ca Canada
de Germany
it italy
ly Libya
io Indian Ocean
is Iceland
to Tonga
기관명 미국 그외 국가
교육기관 edu ac
사업체 com co
정부기관 gov go
비영리 공공기관 org or
네트웍 관련기관 net ne
사업 biz
정보 info
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 ProtocolURI : Uniform Resource IdentifierHTML : Hyper Text Markup Language
하이퍼 미디어 : Hyper Link로 연결된 텍스트/이미지/음성/영상. 정보의 연결분산 시스템 : 웹은 전 세계에 배치된 서버에, 전 세계의 브라우저가 접속하는 분산 시스템
URI
HTTP
HTML
HTML 은 HTTP로 전송된다.
HTTP는 URI로 조작대상을지정한다.
HTML의 링크는 URI를이용한다.
애플리케이션 컨트롤
하이퍼미디어 포맷리소스 식별자
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 ProtocolTelnet (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.0HTML 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리소스 : 웹상에 존재하는 이름을 가진 모든 정보
리소스는 각각 URI로 의미있는 이름을 가지며, 쉽게 접근이 가능하다.
1개의 리소스가 복수개의 URI 를 가질수 있다.http://weather.example.com/seoul/today
http://weather.example.com/seoul/2012-01-01
리소스는 여러개의 형태를 가질수 있다.일기예보 : HTML , PDF , 이미지 등등
리소스의 상태는 시간등에 따라 표현이 변할수 있다.
서울의 일기예보양념치킨 만드는 법 소개 페이지청량리역의 사진Roy Fielding 의 REST 논문xguru의 최근 트윗
http://weather.naver.com/rgn/cityWetrCity.nhn?cityRgnCd=CT001013http://xguru.net/51http://www.flickr.com/photos/nala2sky/3790226694http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmhttp://twitter.com/xguru
REST 의 스타일 #1클라이언트 / 서버
웹은 HTTP 프로토콜을 이용하여 클라이언트와 서버가 통신
Request / Response 모델
클라이언트 = 멀티 플랫폼 , 서버는 = 복수서버로 증설가능
Stateless 서버클라이언트의 애플리케이션 상태를 서버에서 관리하지 않음
서버의 구현이 간략화 됨.
많이들 쓰는 “Cookie 를 사용한 세션관리”는 이에 위배됨
클라이언트 서버
유저 인터페이스 담당 데이터 스토리지 담당
클라이언트 스테이트리스서버
요청마다 모든 정보를 송신한다.
클라이언트의 애플리케이션상태를 관리하지 않는다.클라이언트
Client Server, CS
Client Stateless Server, CSS
REST 의 스타일 #2캐시
한번 가져온 리소스를 클라이언트측에서 재사용
통신량을 줄여서 처리시간 축소. 신뢰성 떨어질 가능성
유니폼 인터페이스 URI로 지정된 리소스에 대한 조작을 통일된 인터페이스로 수행
HTTP 1.1 은 8개의 메소드만 있음
아키텍처가 간결하고, 클라이언트 / 서버 구현의 중립성이 향상
클라이언트
클라이언트
스테이트리스서버
모든서버가 같은 인터페이스를 채용한다.
스테이트리스서버
Uniform Client Cache Stateless Server, UC$SS
Client Cache Stateless Server, C$SS클라이언트
($)스테이트리스
서버
같은 요청의 결과를 재이용
캐시에 필요한 정보를클라이언트에게 전달클라이언트
($)
REST 의 스타일 #3계층화 시스템
유니폼 인터페이스의 이점으로 계층화가 쉬워짐
로드밸런서를 통한 부하분산. 프록시을 통한 액세스 제어 등이 추가되어도 클라이언트는 모르며, 이것은 HTTP를 통일한 인터페이스로 사용했기 때문
Layered System : 시스템을 몇개의 계층으로 분리하는 아키텍쳐 스타일
Uniform Layered Client Cache Stateless Server, ULC$SS
클라이언트
클라이언트
스테이트리스서버
시스템을 복수의 계층으로 분할한다.
프록시
인터페이스가 다른 레거시 시스템에 접속할수 있게 한다.
스테이트리스서버
스테이트리스서버
REST 의 스타일 #4코드온 디맨드
프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍쳐 스타일
Javascript , Flash , Java 애플릿 등
애플리케이션 프로토콜의 가시성은 저하될수 있음
HTML5 와 함께 Javascript 가 더욱 중요해 지고 있음
Uniform Layered Code on Demand Client Cache Stateless Server, ULCODC$SS
클라이언트
클라이언트
스테이트리스서버
서버가 제공하는 코드를 클라이언트에서 실행
프록시
인터페이스가 다른 레거시 시스템에 접속할수 있게 한다.
스테이트리스서버
스테이트리스서버
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:[email protected]:8000/search?q=test&debug=true#n10
URI Scheme : http
사용자정보 : id = xguru , pwd = pass
호스트명 : xguru.net
포트번호 : 8000
생략시 각 URI Scheme 의 기본 값이 사용됨. http 의 기본포트번호는 80
패스 : /search
쿼리 파라미터 : q=test&debug=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://example.com/2001/05/01/press.ko
http://example.com/2001/05/01/press.en
리소스 형태 분리
http://example.com/data/myplace.html
http://example.com/data/myplace.json
http://example.com/data/myplace.txt
매트릭스 URIhttp://example.com/map/lat=35.343243;lng=139.123232
http://example.com/test/123232,testmessage
HTTP의 Content-Negotiaion 기능 활용도 가능
GET /2010/05/01/press HTTP/1.1 Host: example.com Accept-Language: ko,en-us;q=0.7,en;q=0.3
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
Connection:����������� ������������������ keep-alive
Cache-Control:����������� ������������������ max-age=0
User-Agent:����������� ������������������ Mozilla/5.0����������� ������������������ (Macintosh;����������� ������������������ Intel����������� ������������������ Mac����������� ������������������ OS����������� ������������������ X����������� ������������������
10_8_1)����������� ������������������ AppleWebKit/537.4����������� ������������������ (KHTML,����������� ������������������ like����������� ������������������ Gecko)����������� ������������������
Chrome/22.0.1229.26����������� ������������������ Safari/537.4
Accept:����������� ������������������ text/html,application/xhtml+xml,application/
xml;q=0.9,*/*;q=0.8
Accept-Encoding:����������� ������������������ gzip,deflate,sdch
Accept-Language:����������� ������������������ en-US,en;q=0.8
Accept-Charset:����������� ������������������ windows-949,utf-8;q=0.7,*;q=0.3
HTTP/1.1����������� ������������������ 200����������� ������������������ OK
Date:����������� ������������������ Sat,����������� ������������������ 08����������� ������������������ Sep����������� ������������������ 2012����������� ������������������ 19:22:18����������� ������������������ GMT
Server:����������� ������������������ Apache/2.2.2����������� ������������������ (Unix)����������� ������������������ mod_ssl/2.2.2����������� ������������������ OpenSSL/
0.9.8e-fips-rhel5����������� ������������������ PHP/5.3.0
X-Powered-By:����������� ������������������ PHP/5.3.0
Content-Encoding:����������� ������������������ gzip
Vary:����������� ������������������ Accept-Encoding,Cookie
Expires:����������� ������������������ Thu,����������� ������������������ 19����������� ������������������ Nov����������� ������������������ 1981����������� ������������������ 08:52:00����������� ������������������ GMT
X-Pingback:����������� ������������������ http://xguru.net/xmlrpc.php
Cache-Control:����������� ������������������ no-store,����������� ������������������ no-cache,����������� ������������������ must-revalidate,����������� ������������������
post-check=0,����������� ������������������ pre-check=0
Pragma:����������� ������������������ no-cache
WP-Super-Cache:����������� ������������������ Served����������� ������������������ legacy����������� ������������������ cache����������� ������������������ file
Keep-Alive:����������� ������������������ timeout=5,����������� ������������������ max=100
Connection:����������� ������������������ Keep-Alive
Transfer-Encoding:����������� ������������������ chunked
Content-Type:����������� ������������������ text/html;����������� ������������������ charset=UTF-8
<!DOCTYPE����������� ������������������ html>
<html><head>~~~
1.요청 메시지 구축2.요청 메시지 송신3.(응답돌아올때까지 대기)4.응답 메시지 수신5.응답 메시지 해석6.클라이언트의 목적을 달성하기 위해 필요한 처리
1.(요청을 대기)2.요청 메시지 수신3.요청 메시지 해석4.적절한 애플리케이션 프로그램으로 처리를 위임5.애플리케이션 프로그램으로부터 결과를 취득6.응답 메시지 구축7.응답 메시지 송신
Client Server
HTTP 메시지 : Request요청 라인 : Request 메시지의 첫번째 줄
http://example.com/test 에 대한 최소한의 요청은
복잡한 URI에도 요청라인은 동일
절대 URI 요청의 경우 Host 헤더 생략가능
두번째줄 부터는 복수개의 Header 가 이어짐“이름: 값” 형태의 구성 ➠ Host: example.com , User-Agent: Mozilla/5.0
요청메시지에도 헤더뒤에 Body 가 오는 경우가 있음POST,PUT 같은 메소드를 통해 리소스를 작성하거나 갱신할 때
GET����������� ������������������ /test����������� ������������������ HTTP/1.1Host:����������� ������������������ example.com
GET����������� ������������������ /search?q=test&debug=true#n10����������� ������������������ HTTP/1.1Host:����������� ������������������ example.com:8080
GET����������� ������������������ http://example.com/test����������� ������������������ HTTP/1.1
GET메소드
/test요청����������� ������������������ URI
HTTP/1.1프로토콜����������� ������������������ 버전
HTTP 메시지 : ResponseStatus Line : 응답메시지의 첫줄
스테이터스 코드로 결과의 상태를 표현
프로그램에서 이 코드를 통해 상태 파악
Request 와 같이 두번째줄 부터는 복수개의 Header 가 이어짐Content-Type 헤더를 통해 MIME 미디어 타입 (text/html)과 문자인코딩 타입(utf-8)을 전송
Content-Length 헤더를 통해 이어지는 Body 의 크기를 알려줌
Body 에 실제 문서데이터가 포함헤더와 바디는 빈줄 ( CRLF ) 로 구분
HTML 또는 다양한 문서형식 가능
HTTP/1.1����������� ������������������ 200����������� ������������������ OKContent-Type:����������� ������������������ text/html;����������� ������������������ charset=UTF-8Content-Length:����������� ������������������ 12342
<!doctype����������� ������������������ html5><html>...</html>
200스테이터스����������� ������������������ 코드
OK텍스트����������� ������������������ 구문
HTTP/1.1프로토콜����������� ������������������ 버전
MIME : Multipurpose Internet Mail Extension
HTTP 메시지의 구성요소
스타트 라인 ( Start Line )
헤더 ( Header )
빈줄 ( Blank Line )
바디 ( Body )
Method 공백 URL 공백 프로토콜버전 CR LF
Header Field NameHeader Field NameHeader Field Name : Value CR LF
::::::::::::::
Header Field NameHeader Field NameHeader Field Name : Value CR LF
CR LF
BodyBodyBodyBodyBodyBodyBody
Stateful / Stateless
스테이트풀한 대화는 간결함
스테이트리스한 대화는 장황함
스테이트풀한 대화에서 서버는 클라이언트의 주문내역을 기억함
스테이트리스한 대화에서 클라이언트는 매번 모든 주문을 반복함
Stateful 대화손님: 안녕하세요.점원: 어서 오세요. OO 햄버거입니다~.손님: 햄버거 세트 하나 주세요.점원: 사이드 메뉴는 무엇으로 하시겠습니까?손님: 포테이토요.점원: 음료수는 무엇으로 하시겠습니까?손님: 콜라로 주세요.점원: 50원 추가하시면 음료수를 L사이즈로 할 수 있는데 어떠신가요? 손님: 그냥 M사이즈로..점원: 추가하실 건 없으시고요?손님: 예점원: 알겠습니다.
Stateless 대화손님: 안녕하세요.점원: 어서 오세요. OO 햄버거입니다~.손님: 햄버거 세트 하나 주세요.점원: 사이드 메뉴는 무엇으로 하시겠습니까?손님: 햄버거 세트랑 포테이토 주세요.점원: 음료수는 무엇으로 하시겠습니까?손님: 햄버거 세트에 포테이토랑 콜라로 주세요.점원: 50원 추가하시면 음료수를 L사이즈로 할 수 있는데 어떠신가요? 손님: 햄버거 세트에 포테이토랑 콜라는 M사이즈로..점원: 추가하실 건 없으시고요?손님: 햄버거 세트에 포테이토랑 콜라는 M사이즈로 부탁해요. 이상. 점원: 알겠습니다
Stateful
• Session 상태 유지 필요• FTP 가 대표적인 Stateful 프로토콜 로그인에서 아웃까지 모든 상태를 서버가 관리함
Stateful 의 단점서버가 클라이언트의 상태를 기억하는것은 클라이언트 수가 늘어날수록 어려워짐
하나의 서버가 동시에 상대할수 있는 클라이언트 수에는 한계가 있음
서버가 늘어날 경우 클라이언트 별로 상대할 서버를 지정할수가 없으므로 상태 동기화가 필요
커피 추가요!
A B C D
생수 주세요! 햄버거 세트 카페오레
...
A씨는 햄버거와 포테이토고..B씨는 애플파이고..C씨는 아직 주문안함D씨는 햄버거
A씨는 햄버거와 포테이토고..B씨는 애플파이고..C씨는 아직 주문안함D씨는 햄버거
Stateless 의 장점클라이언트가 요청 메시지에 필요한 정보를 모두 포함시킴
지난 대화를 기억해 두지 않더라도 현재 상태를 바로 알수 있음
Self Descriptive Message : 클라이언트가 자신의 상태를 기억, 모든 요청을 상태와 함께 보냄
서버를 늘리기만 해도 바로 확장가능. 매번 어떤 서버로 요청을 보내도 상관없음
햄버거와포테이토에 커피!
A B C D
애플파이와생수 주세요! 햄버거 세트 햄버거와
카페오레
...
Stateless 의 단점퍼포먼스의 저하 : 매번 필요한 정보를 모두 송신하기 때문
송신할 데이터의 양이 많아진다.
사용자 인증등 서버에 부하가 걸리는 처리를 반복한다.
통신 에러에 대한 대처 필요
Stateful 대화손님: 햄버거 1개 주세요. 이상.점원: 알겠습...(소음으로 들리지 않는다.... ).손님: (확인하기 위해 다시 한 번...) 햄버거 1개 주세요. 이상. 점원: 손님께선 이미 1개 주문하셨는데, 맞으신가요?
Stateless 대화손님: 햄버거 1개 주세요. 이상.점원: 알겠습..( 소음으로 들리지 않는다....).손님: (확인하기 위해 다시 한 번..) 햄버거 1개 주세요. 이상. 점원: 알겠습니다.
HTTP MethodHTTP 1.1 에 정의된 메쏘드는 단 8개, 그중에서도 5~6개만 사용
Method 용도 의미
GET Read 리소스 취득
POST Create 서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리
PUT Update 리소스 갱신, 리소스 작성
DELETE Delete 리소스 삭제
HEAD 리소스의 헤더(메타 데이터) 취득
OPTIONS 리소스가 서포트하는 메소드의 취득
TRACE 자기 앞으로 요청 메시지를 반환(루프 백) 시험
CONNECT 프록시 동작의 터널 접속으로 변경
HTTP : GETGET ( Read )
지정한 URI 정보 가져오기.
브라우저의 기본 동작. 가장 이용빈도가 높음
GET /list HTTP/1.1Host: example.com
HTTP/1.1 200 OKContent-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" }}
HTTP : POSTPOST ( Create )
리소스의 작성 : 새로 생성된 리소스의 URI가 Location 에 리턴
다른 메소드로는 대응할 수 없는 처리
요청하는 URI 가 매우 길어서 처리가 불가능할 경우 ( URI가 2000자가 넘거나.. )
http://example.com/search?q={엄청엄청긴 검색 문자열}
POST /list HTTP/1.1Host: example.comContent-Type: text/plain; charset=utf-8
안녕하세요!
HTTP/1.1 201 CreatedContent-Type: text/plain;charset=utf-8Location: http://example.com/list/item5
안녕하세요!
POST /search HTTP/1.1Host: example.comContent-Type: application/x-www-form-urlencoded
q=very+long+keyword+foo+bar+...
HTTP : PUTPUT ( Update )
리소스의 갱신
PUT을 POST 와 마찬가지로 자료의 생성에 쓸수도 있지만, 가능하면 POST/PUT을 분리하여 Create/Update 로 쓰는것이 바람직 하다.
GET /list/item5 HTTP/1.1Host: example.com
HTTP/1.1 200 OKContent-Type: text/plain; charset=utf-8
안녕하세요!
PUT /list/item5 HTTP/1.1Host: example.comContent-Type: test/plain; charset=utf-8
좋은 밤이네요!
HTTP/1.1 200 OKContent-Type: text/plain; charset=utf-8
좋은 밤이네요!
HTTP : DELETE,HEAD,OPTIONSDELETE (Delete) : 리소스를 삭제
HEAD : 리소스의 헤더만 취득
바디가 포함되지 않아 네트워크 대역을 절약하면서 리소스의 크기 조사 및 갱신일자 취득이 가능
OPTIONS : 리소스가 서포트 하는 메서드의 취득
DELETE /list/item2 HTTP/1.1Host: example.com
HTTP/1.1 200 OK
HTTP/1.1 204 No Content
OR
HEAD /list/item5 HTTP/1.1Host: example.com
HTTP/1.1 200 OKContent-Type: text/plain; charset=utf-8
OPTIONS /list HTTP/1.1Host: example.com
HTTP/1.1 200 OKAllow: GET, HEAD, POST
OPTIONS /list/item5 HTTP/1.1Host: example.com
HTTP/1.1 200 OKAllow: GET, HEAD, PUT, DELETE
GET/POST현실적으로 가장 많이 이용되는 것은 GET/POST
HTML의 Form 에서 지정할수 있는 메서드가 오직 GET/POST 이기 때문
AJAX 에서는 XMLHTTPRequest 를 이용하여 임의의 메서드 사용가능
POST 로 PUT/DELETE 를 대신하는 방법_method 파라미터 활용
X-HTTP-Method-Override
<form target=”/list/item1” action=”POST”> <input type=”hidden” id=”_method” value=”PUT”> <textarea id=”body”> ... </textarea></form>
POST /list/item1 HTTP/1.1Host: example.comContent-Type: application/xml; charset=utf-8X-HTTP-Method-Override: PUT
<form target=”/list/item1” action=”GET”></form>
<form target=”/list/item1” action=”POST”></form>
멱등성과 안정성통신 에러에 대처하기 위한 HTTP 의 대안
멱등성 ( Idempotence ) : 어떤 조작을 몇번 반복해도 결과가 동일한 것
안전 ( Safe ) : 조작 대상의 리소스의 상태를 변화시키지 않는것
GET의 경우 리소스는 안전하지만, 서버의 로그파일에 기록되고, 히트카운터가 변경이 된다.
쇼핑몰에서 “뒤로” 버튼 눌렀을대 “다시 전송하시겠습니까?” 를 묻는것은 POST 재전송 때문
GET 의 URI 에 action=delete 와 같은 방식으로 쓰거나 하는 방식의 오용은 금물
메서드 성질
GET, HEAD 멱등이고 안전하다
PUT,DELETE 멱등이지만 안전하지 않다
POST 멱등이지도 안전하지도 않다
HTTP Status Code우린 이미 404, 500 과 같은 HTTP 상태코드를 많이 보아 왔다.
https://github.com/404 , http://huml.org/404 , http://ifolderlinks.ru/404
상태코드의 분류와 의미
코드 분류 의미
1xx 처리중 처리가 계속되고 있음. 클라이언트는 요청을 계속하거나, 서버의 지시에 따라 프로토콜 업데이트 후 재전송
2xx 성공 요청이 성공했음을 나타냄
3xx 리다이렉트 다른 리소스로의 리다이렉트. 클라이언트는 이 코드를 받았을때 응답메시지의 Location 헤더를 보고 새 리소스에 접근
4xx 클라이언트 에러 클라이언트의 요청이 에러의 원인. 클라이언트쪽에서 요청을 수정해서 재 전송해야 한다.
5xx 서버 에러 서버가 에러의 원인. 서버측에서 원인이 해결되면, 동일한 요청을 보내어 정상적인 결과를 얻을 가능성이 있다.
자주 사용되는 상태코드
하지만, 전체적으로 상태코드를 알고 정확하게 사용할 것
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 헤더에 재개시간
HTTP Header #1HTTP 0.9에는 헤더가 없었고,1.0때 메일스펙(RFC822)에서 형식빌려옴
날짜와 시간
이용하는 메시지 헤더 의미
요청과 응답 Date 메시지를 생성한 일시
요청If-Modified-Since 조건부 GET으로 리소스의 갱신일시를 지정할때 이용
요청If-Unmodified-Since 조건부 PUT/DELETE로 리소스의 갱신일시 지정
응답
Expires 응답을 캐시할수 있는 기한
응답 Last-Modified 리소스를 마지막으로 갱신한 일시응답
Retry-After 다시 요청을 전송할 수 있는 일시의 기준
HTTP Header #2MIME 미디어 타입 ( Multipurpose Internet Mail Extensions )
Content-Type : type/subtype 형태로 미디어타입을 지정하는 헤더
application/xhtml+xml;charset=utf-8 : type = application , subtype = xhtml+xml
charset 파라미터로 문자 인코딩 지정가능
타입 의미 예
text 사람이 읽고 직접 이해할수 있는 텍스트 text/plainimage 그림 데이터 image/jpegaudio 음성 데이터 audio/mpegvideo 동영상 데이터 video/mp4application 그 밖의 데이터 application/pdfmultipart 복수개의 데이터로 이루어진 복합 데이터 multipart/relatedmessage 전자메일 메시지 message/rfc822model 복수 차원으로 구성하는 모델 데이터 model/vrmlexample 예시용 example/foo-bar
HTTP Header #3MIME 주요 서브타입
타입/서브타입 의미
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 Wordapplication/vnc.ms-excel Excelapplication/pdf PDFapplication/zip ZIPapplication/x-shockwave-flash Flash 오브젝트application/x-www-form-urlencoded HTML 폼 형식
HTTP Header #4Content 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
HTTP Header #5Content-Length 와 Chunk 전송
Content-Length : 메시지에 바디가 있을경우 사이즈를 10진수 바이트로 나타냄
Content-Length: 5538
청크전송 : 사이즈를 모르는 경우 바디를 분할하여 전송가능하게 함
Transfer-Encoding: chunked
각 청크의 시작에는 청크사이즈가 16진수로 들어감, 마지막에는 반드시 길이가 0인 청크와 빈줄
POST /test HTTP/1.1Host: example.comTransfer-Encoding: chunkedContent-Type: Text/plain; charset= utf-8
10The brown fox ju
10mps quickly over
e the lazy dog.
0( 여기에도 빈줄 )
HTTP Header #6인증 ( Authentication ) : Basic 과 Digest
Basic 인증 : 사용자 이름과 패스워드에 의한 인증방식.
매 요청마다 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.1Host: example.comAuthorization: Basic XNlcjpwYXNzd29yZA==
DELETE /test HTTP/1.1Host: example.comAuthorization: Digest username="yohei", realm="example.com", nonce="1ac421d9e0a4k7q982z966p903372922", uri="/test", qop="auth", nc=00000001, cnonce="900150983cd24fb0d6963f7d28e17f72", response="0fde218e18949a550985b3a034abcbd9", opaque="92eb5ffee6ae2fec3ad71c777531578f"
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시간동안 캐시 유지
조건부 GETIf-Modified-Since - 리소스가 갱신되었다면 가져온다. 변경되지 않았다면 304 Not Modified
그외에 더 봐두면 좋은것들OAuth
http://www.slideshare.net/tebica/oauth-api-13721761
웹 기술용어http://www.slideshare.net/kthcorp/kth-1-20120307
APIhttp://www.slideshare.net/kthcorp/kthdetail-day-71api20120718
SEOhttp://www.slideshare.net/guruguru/mobile-seo-search-engine-optimization
![Google을 지탱하는 기술] 제3장](https://img.pdfslide.tips/doc/110x75/54663ca8b4af9f11108b4931/google-3-558453403d2d1.jpg)
