웹을 지탱하는 기술

  • 18,092 views
Uploaded on

인터넷의 역사부터 웹의 탄생, HTTP 와 REST 등, 우리가 현재의 웹을 이해하는데 필요한 것들만 정리 했습니다. …

인터넷의 역사부터 웹의 탄생, HTTP 와 REST 등, 우리가 현재의 웹을 이해하는데 필요한 것들만 정리 했습니다.

현업에 개신 개발자 분들은 다들 아시는 내용이겠지만, 정작 우리 주위엔 웹을 많이들 쓰고, 관련해서 일을 하면서도 웹의 내부에 대해서는 잘 모르고 있는 사람들이 많습니다.

웹의 기반기술을 제대로 아는것이, 우리가 좀더 웹을 진지하게 접근하는 것의 시작이라고 생각합니다.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
18,092
On Slideshare
0
From Embeds
0
Number of Embeds
20

Actions

Shares
Downloads
419
Comments
2
Likes
98

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 인터넷의 탄생 #2NSFNET : 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 , HTTPTCP/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. P2PPeer-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 couk United Kingdom 정부기관 gov go fr France 비영리 공공기관 org orca Canada 네트웍 관련기관 net nede Germany 사업 biz it italy 정보 info ly Libya io Indian Ocean is Icelandto Tonga
  • 15. Web 이란 무엇인가 ?
  • 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 ProtocolURI : Uniform Resource IdentifierHTML : 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 ProtocolFTP (21) : File Transfer ProtocolTelnet (23) , SSH(22)Gopher (70)USENET , Newsgroup NNTP ( 119 , 563 ) : Network News Transfer ProtocolIRC : Internet Relay Chat 194 but de facto is 6667 , 6660~6669,7000http://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 이미지가 보이는 첫번째 브라우저
  • 23. 웹 표준의 출현
  • 24. REST 란 무엇인가 ?
  • 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.0Web
  • 28.   as
  • 29.   a
  • 30.   Platform
  • 31. Web 1.0HTML 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/3790226694Roy Fielding 의 REST 논문 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmxguru의 최근 트윗 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형식은 그대로 따르는..
  • 39. 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=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 . 은 현재 , .. 은 상위
  • 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/
  • 46. HTTP 란 무엇인가 ?
  • 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.   /
  • 50.   HTTP/1.1Host:
  • 51.   xguru.net Client HTTP/1.1
  • 52.   200
  • 53.   OK Server Date:
  • 54.   Sat,
  • 55.   08
  • 56.   Sep
  • 57.   2012
  • 58.   19:22:18
  • 59.   GMTConnection:
  • 60.   keep-alive Server:
  • 61.   Apache/2.2.2
  • 62.   (Unix)
  • 63.   mod_ssl/2.2.2
  • 64.   OpenSSL/Cache-Control:
  • 65.   max-age=0 0.9.8e-fips-rhel5
  • 66.   PHP/5.3.0User-Agent:
  • 67.   Mozilla/5.0
  • 68.   (Macintosh;
  • 69.   Intel
  • 70.   Mac
  • 71.   OS
  • 72.   X
  • 73.    X-Powered-By:
  • 74.   PHP/5.3.010_8_1)
  • 75.   AppleWebKit/537.4
  • 76.   (KHTML,
  • 77.   like
  • 78.   Gecko)
  • 79.    Content-Encoding:
  • 80.   gzipChrome/22.0.1229.26
  • 81.   Safari/537.4 Vary:
  • 82.   Accept-Encoding,CookieAccept:
  • 83.   text/html,application/xhtml+xml,application/ Expires:
  • 84.   Thu,
  • 85.   19
  • 86.   Nov
  • 87.   1981
  • 88.   08:52:00
  • 89.   GMTxml;q=0.9,*/*;q=0.8 X-Pingback:
  • 90.   http://xguru.net/xmlrpc.phpAccept-Encoding:
  • 91.   gzip,deflate,sdch메시지 구축 1.요청 Cache-Control:
  • 92.   no-store,
  • 93.   no-cache,
  • 94.   must-revalidate,
  • 95.    1.(요청을 대기)Accept-Language:
  • 96.   en-US,en;q=0.8 post-check=0,
  • 97.   pre-check=0 2.요청 메시지 송신 2.요청 메시지 수신Accept-Charset:
  • 98.   windows-949,utf-8;q=0.7,*;q=0.3 Pragma:
  • 99.   no-cache 3.(응답돌아올때까지 대기) 3.요청 메시지 해석 WP-Super-Cache:
  • 100.   Served
  • 101.   legacy
  • 102.   cache
  • 103.   file 4.응답 메시지 수신 Keep-Alive:
  • 104.   timeout=5,
  • 105.   max=100 4.적절한 애플리케이션 프로그 5.응답 메시지 해석 Connection:
  • 106.   Keep-Alive 램으로 처리를 위임 6.클라이언트의 목적을 달성하 Transfer-Encoding:
  • 107.   chunked 5.애플리케이션 프로그램으로부 기 위해 필요한 처리 Content-Type:
  • 108.   text/html;
  • 109.   charset=UTF-8 터 결과를 취득 6.응답 메시지 구축 <!DOCTYPE
  • 110.   html> 7.응답 메시지 송신 <html><head>~~~
  • 111. HTTP 메시지 : Request요청 라인 : Request 메시지의 첫번째 줄 GET
  • 112.   /test
  • 113.   HTTP/1.1 GET /test HTTP/1.1 http://example.com/test 에 대한 최소한의 요청은 Host:
  • 114.   example.com 메소드 요청
  • 115.   URI 프로토콜
  • 116.   버전 GET
  • 117.   /search?q=test&debug=true#n10
  • 118.   HTTP/1.1 복잡한 URI에도 요청라인은 동일 Host:
  • 119.   example.com:8080 절대 URI 요청의 경우 Host 헤더 생략가능 GET
  • 120.   http://example.com/test
  • 121.   HTTP/1.1두번째줄 부터는 복수개의 Header 가 이어짐 “이름: 값” 형태의 구성 ➠ Host: example.com , User-Agent: Mozilla/5.0요청메시지에도 헤더뒤에 Body 가 오는 경우가 있음 POST,PUT 같은 메소드를 통해 리소스를 작성하거나 갱신할 때
  • 122. HTTP 메시지 : ResponseStatus Line : 응답메시지의 첫줄 HTTP/1.1 HTTP/1.1
  • 123.   200
  • 124.   OK 프로토콜
  • 125.   버전 200 스테이터스
  • 126.   코드 OK 텍스트
  • 127.   구문 Content-Type:
  • 128.   text/html;
  • 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 MethodHTTP 1.1 에 정의된 메쏘드는 단 8개, 그중에서도 5~6개만 사용 Method 용도 의미GET Read 리소스 취득POST Create 서브 리소스의 작성, 리소스 데이터의 추가, 그 밖의 처리PUT Update 리소스 갱신, 리소스 작성DELETE Delete 리소스 삭제HEAD 리소스의 헤더(메타 데이터) 취득OPTIONS 리소스가 서포트하는 메소드의 취득TRACE 자기 앞으로 요청 메시지를 반환(루프 백) 시험CONNECT 프록시 동작의 터널 접속으로 변경
  • 138. HTTP : GETGET ( Read ) 지정한 URI 정보 가져오기. 브라우저의 기본 동작. 가장 이용빈도가 높음GET /list HTTP/1.1 HTTP/1.1 200 OKHost: 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 CreatedHost: example.com Content-Type: text/plain;charset=utf-8Content-Type: text/plain; charset=utf-8 Location: http://example.com/list/item5안녕하세요! 안녕하세요! 다른 메소드로는 대응할 수 없는 처리 요청하는 URI 가 매우 길어서 처리가 불가능할 경우 ( URI가 2000자가 넘거나.. ) http://example.com/search?q={엄청엄청긴 검색 문자열}POST /search HTTP/1.1Host: example.comContent-Type: application/x-www-form-urlencodedq=very+long+keyword+foo+bar+...
  • 140. HTTP : PUTPUT ( Update ) 리소스의 갱신GET /list/item5 HTTP/1.1 HTTP/1.1 200 OKHost: example.com Content-Type: text/plain; charset=utf-8 안녕하세요!PUT /list/item5 HTTP/1.1 HTTP/1.1 200 OKHost: example.com Content-Type: text/plain; charset=utf-8Content-Type: test/plain; charset=utf-8 좋은 밤이네요!좋은 밤이네요! PUT을 POST 와 마찬가지로 자료의 생성에 쓸수도 있지만, 가능하면 POST/PUT을 분리하여 Create/Update 로 쓰는것이 바람직 하다.
  • 141. HTTP : DELETE,HEAD,OPTIONSDELETE (Delete) : 리소스를 삭제DELETE /list/item2 HTTP/1.1 HTTP/1.1 200 OKHost: example.com OR HTTP/1.1 204 No ContentHEAD : 리소스의 헤더만 취득HEAD /list/item5 HTTP/1.1 HTTP/1.1 200 OKHost: example.com Content-Type: text/plain; charset=utf-8 바디가 포함되지 않아 네트워크 대역을 절약하면서 리소스의 크기 조사 및 갱신일자 취득이 가능OPTIONS : 리소스가 서포트 하는 메서드의 취득OPTIONS /list HTTP/1.1 HTTP/1.1 200 OKHost: example.com Allow: GET, HEAD, POSTOPTIONS /list/item5 HTTP/1.1 HTTP/1.1 200 OKHost: 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 헤더에 새 URI301 Moved Permanently 리소스가 새 URI로 이동했음 Location 헤더에 새 URI303 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 #1HTTP 0.9에는 헤더가 없었고,1.0때 메일스펙(RFC822)에서 형식빌려옴날짜와 시간이용하는 메시지 헤더 의미 요청과 응답 Date 메시지를 생성한 일시 If-Modified-Since 조건부 GET으로 리소스의 갱신일시를 지정할때 이용 요청 If-Unmodified-Since 조건부 PUT/DELETE로 리소스의 갱신일시 지정 Expires 응답을 캐시할수 있는 기한 응답 Last-Modified 리소스를 마지막으로 갱신한 일시 Retry-After 다시 요청을 전송할 수 있는 일시의 기준
  • 147. 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
  • 148. 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 폼 형식
  • 149. 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
  • 150. HTTP Header #5Content-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-20120307API http://www.slideshare.net/kthcorp/kthdetail-day-71api20120718SEO http://www.slideshare.net/guruguru/mobile-seo-search-engine-optimization