■ Web

[Web] RestFul Service에 대해서 알아보자 (4)

오늘은 NHN에서 쓴 “자바스크립트 성능이야기”란 책에서 좋은내용이 있어 발췌하여 설명하도록 한다.

먼저 중요한 것부터 짚고 넘어가자.

 

브라우저가 요청을 처리하는 순서를 이번엔 도메인 주소 입장이 아닌 브라우저 자체 프로세스를 통해 좀더 세부적으로 살펴보도록하겠다.

브라우저는 젤 처음 서비스 이동단계로 시작한다.

이부분은 우리가 브라우져를 처음 키고 접속해오는 상황을 말한 것은 아니다.

현재 어떤 페이지를 보고 있다고 가정하고, 다른 도메인을 통해 페이지를 이동한다고 했을때, 앞에서 말한 우리가 보고 있던 어떤페이지란 것을 다른 페이지로 이동하기 전에 처리하는 과정을 말한다.

beforeunload라는 이벤트 핸들러를 통해 메모리 해제와 같은 처리를 해줄 수 있다.

 

다음으로 리다이렉트 단계이다.

예를들면

http://bravo114.kr로 접속하면

http://bravo114.kr/ 이부분으로 리다이렉트 되고, 이것은 다시http://bravo114.kr/main으로 리다이렉트 되도록 구성되어있다. 여기서 http://bravo114.kr/ 이부분은 index가 생략되어있는 것이 보통이나, 요즈음의 웹서버들은 routing 개념을 사용하기 때문에 꼭 index가 생략되어있다고 볼순 없다.(물론 내부적으론 index로 처리할 수도있다.)

여기서 중요한 점은 리다이렉트의 경우 정적파일 캐시가 되지 않기 때문에 리다이렉트 되기전 페이지는 최대한 가볍게 하거나 사용을 자제하는 편이 좋다.

 

다음으로는 애플리케이션 캐시확인 단계이다.

앞서 REST를 공부할때도 보았지만 캐시 정보를 활용해서 서버부화를 줄이는 방법이 있었다.

이때 Last-Modified(서버), if-Modified-Since(브라우져) 등을 활용하거나, Expires, Cache-Control등을 활용할 수있다.

순서는 Expires로 만기날짜를 먼저 확인하고 만기가 되었다면 if-Modified-Since를 통해 현재 받아온 데이터가 클라이언트가 알고 있는 갱신날짜보다 최신인지 확인하고, (Last-Modified를 통해비교) 최신이 아니라면 서버로부터 다시 받아온다.

 

다음으로는 네트워크 통신단계이다.

이부분은 다시 세부적으로 8단계 정도로 나뉜다.

1. Blocked : 브라우져가 서버와의 통신을위해 준비하는 시간이다. (이때 host별로 병렬로 요청하는데 현재 2개의 동시요청의 개수가 가장 최적이다라는 보고가 있다.)

2. DNSLookup : 앞서 도메인을 설명할때 DNS Server에 대해 설명했다. 이때NS레코드가 DNS서버에 이미 저장되어 있다면 해당 TTL(캐시 시간)에 따라 DNS서버는 최종 보여줘야할 ip주소를 캐시한다. 바로 이부분을 체크하는 시간이다.

3. TCP(Connect) 실제 http통신을 위해 TCP연결을 하는 시간이다. (http는 TCP통신으로 구현한 프로토콜이다.)

4. Request 실제 요청하는 시간이다. 이때 CDN같은 정적파일 전용서버를 만들어 놓아서 최적화를 할수 있다. 무슨말이냐면, 매번 요청할때 실제 서버는 Cookie를 갖고 있는데, 이부분이 꽤 헤더에서 차지하는 부분이 크다보니 트래픽을 유발시킬수 있다. 따라서 CDN은 보통 Cookie를 해더에 들고있지 않는다.

5. Wait 서버로부터의 응답을 기다리는 시간이다. 서버의 속도가 가장 중요한 부분이다. 실제 Node.js나 아파치+php조합에서의 속도차이는 이부분에서 발생한다.

6. Response 응답메세지를 받는 시간이다. 이때 서버와 클라이언트간 통신은 데이터를 일정부분으로 잘라 분할해서 전송한다. 분할전송을 통해 모든 데이터를 받게 되는 시간이 Response에 걸리는 시간이다. 따라서 Gzip등으로 압축해서 용량을 줄인다. (혹은 코드를 minify한다.)

7. TTFB 서버가 Response시에 받을 데이터중 가장 처음 데이터 바이트 정보를 받아 브라우져에 보내는데 걸리는 시간이다. 안드로이드와 같은 모바일 디바이스로 통신할때 파일을 나누어서 보낸다. 그때 처음으로 write하고 처음으로 보낸 바이트를 클라이언트가 받아 처리하는 시간이다.

8. Cache Read 사용자 PC로부터 캐시된 데이터를 읽어오는 시간이다. 위에 설명한 캐시 확인단계에서 캐시가 되어있다고 설정되어있으면 캐시된 데이터를 불러오고 그렇지 않으면 윗단계에서 통신을 수행하여 데이터를 받아온다.

이상 8가지 단계가 네트워크를 처리하는 단계이다.

 

다음으로는 실제 브라우져가 데이터를 처리하는 단계이다.

이부분은 브라우져가 받아온 데이터의 MIME타입을 확인하여 해당 타입에 맞게 파싱후 렌더링하는 과정이다.

대표적으로 HTML,JS,CSS등이 파싱의 대상이다.

 

이상으로 대략적인 브라우져의 수행 단계를 살펴보았는데 대략적으로 정리하면

서비스이동단계 – 리다이렉트단계 – 캐시확인단계 – 네트워크통신단계 – 브라우저 데이터 처리단계 로 나눠진다.

이중 네트워크 통신단계는 8가지로 이루어져있다.

Standard
■ Web

[Web] RestFul Service에 대해서 알아보자 (3)

이번에는 웹브라우져 주소창에 http://m.naver.com 이라는 주소를 입력한 후 엔터를 쳤을 때의 절차를 설명해 보겠다.

이번포스팅은 짧고 굵을 것이다.

일단 http://m.naver.com을 입력하면 해당 도메인을 거꾸로 읽는다. 즉 .com을 먼저 읽어 해당 도메인은 com도메인이란 것을 안다. 이밖에도 .kr(한국),  .cn(중국) 등 국가별 도메인이 있을수 있다.

kr 도메인은   .  .  .

앞서 설명하길 도메인은 뒤에서부터 읽는다고 했다. 즉 젤뒤에 가장 큰 범주인 kr이란 국가를 식별할수 있는 도메인이 나오는 것이다.

 

이제 실질적으로 통신되는 절차를 일련의 path라고 하고, 이 path를 따라가보자.

도메인을 입력하고 엔터를 치는순간 Root DNS에 질의를 보낸다. 이때 A.ROOT-SERVERS.NET부터 M.ROOT-SERVERS.NET까지 총 13개의 루트DNS서버가 있다. 현재 엔터를 친 컴퓨터와 가장 가까운 ROOT서버로 질의를 보낸다. (ROOT서버도 그냥 일련의 서버컴퓨터이다.)

이후 오른쪽부터 .(마침표) 단위로 짤라서 (거꾸로 읽어서) 각각 net, com, co.kr등을 담당하는 DNS서버를 찾아간다. 그럼 해당 DNS서버엔m.naver.com에서 naver.com의 ip주소 혹은 또다른 도메인이 k-v형태로 저장되어있다.

naver.com이란 key에 해당하는 ip 혹은 도메인을 지칭하는 value를 통해 다시한번 질의한다.

 

복잡할것없다. 루트DNS에서 해당 도메인별 DNS를통해가고 그곳에 저장된 해당 도메인의 서버컴퓨터로 또한번 질의를 보내는 것이다. (이부분도 2가지 방식이 존재한다. 일단 자세한건 생략한다.)

해당 서버컴퓨터는 이제 해당 도메인의 실제ip를 알고있다. 그리고 최종적으로 이 ip주소로 브라우져가 페이지를 여는 것이다.

 

그렇다면 위에 DNS서버에 cafe24.com 도메인의 value인 ip혹은 도메인이 저장되어있다고 하는데 이것은 어떻게 저장된 것일까?

그것은 registrar라는 업체가 하는 역할이다. cafe24.com, hosting.kr 등등이 국내 레지스트라 업체이다. 이곳에선 NS레코드를 설정할수 있는데. 해당 NS레코드가 바로 우리가 위에서 말한 DNS서버의 k-v를 입력한 것이다.

 

최종적으로 ip를 반환한 서버컴퓨터는 해당 ip를 A레코드라는 것을 통해 저장한다. 즉 A-RECORD 설정을 한다는 의미는 최종 서버의 실제 ip를 호스팅하는 업체의 서버컴퓨터에 설장한다는 의미이다.

위에서 한가지 의문사항이 들었을 수도 있다.

 

그것은 m.naver.com 에서 naver.com의 도메인으로만 질의를 했다는 것이다. m은 과연 어디로 간것일까?

m은 서브도메인이라고 불리운다. 이것은 A레코드가 설정된 컴퓨터에서 A레코드와 함께 설정한다. (서버OS에 각각 설정할수 있도록 해놓았음.)

이말은 즉 A레코드를 서브도메인 별로 여러개 설정이 가능하단 의미이며, 서브도메인에 따라 다른 ip를 각각 가져올수 있다는 의미이다.

m.naver.com 이것은 naver.com의 서브도메인이며 naver.com(보통 서브도메인이 없을 경우 www 서브도메인과 같은 도메인으로 리다이렉트하거나  www없이 그냥 사용한다.) 과 m.naver.com는 서로다른 ip를 가진 도메인이다.

 

추가적으로 MX레코드는 메일서버를 의미, A레코드는 IPv4짜리 서버를 의미, AAA레코드는 IPv6짜리 서버를 의미한다. 이밖에도 다양한 레코드가 있다.

말이 어려울수도 있는데 차근차근 다시한번 읽어보면 이해될 것이다.

Standard
■ Web

[Web] RestFul Service에 대해서 알아보자 (2)

지난 시간에는 웹서비스의 의미와 리소스에 대해서 알아보았다.

이번에는 지난 시간보다 아주 살짝 깊이 들어가볼 것이다.

먼저 크게 두가지를 이해하고 시작하자.

 

1. 네트워크 통신이란 것은 하드웨어적인 부분을 제외하면 다음과같다.

“우리끼리 통신하려면 약속이 필요하니까 앞으로 무조건 이러한 약속(프로토콜)으로 구현하자!”

 

2. 우리가 사용하는 MMORPG게임처럼 웹브라우져도 하나의 어플리케이션이다.

“우리 브라우져의 역할은 서버로부터 받아온 데이터를 파싱해서(읽어서) 사용자들에게 보여주고 상호작용하게 해주자!”

 

1번에 대한 부분은 앞시간에 다룬 내용이다.

그럼 오늘은 2번부분에 대해서 알아보겠다.

 

브라우져의 관점으로 설명할텐데, 그렇다면 브라우져는 어떻게 각기 서로 다른 서버로부터 일정하게 화면에 출력해 주는 역할을

수행할까?

 

다음과같은 기본적인 약속 혹은 프로토콜이라 부르는 규약이 있다. 참고로 http통신한다고 할때, http가 프로토콜이다.

우린 http프로토콜에 대해서 알아볼 것이다. (http의 맨뒤가 protocol자체를 의미하지만 억양상 http프로토콜이라 하겠다.)

 

40

 

이것은 trello 라는 웹서비스를 크롬 개발자 툴로 연 상태이다.

 

우선 path, method, type 이 세가지를 보자.

path는 요청주소이다. 즉 리소스이다. 해당 리소스에 요청한다는 의미이다. 어떻게 어떤원리로 요청하는지는 마크업언어인 TAG내에서 <form> 태그를 구현하면 브라우져가 알아서 요청해준다. 즉 비프로그래머가 이해하기엔 “프로그래머가 <form>태그에 관한 부분을 타이핑하고 저장해 놓으면 된다.” 라고 이해해도 무방하다. 또한 ajax를 활용하여 비동기로 요청이 가능하다.

만약 브라우져가 아닌 모바일에서는 각각 플랫폼에 맞는 형식으로 구현이 되어있다.

다음으로 method이다. 이부분은 동사를 의미한다. 즉 all.js라는 자바스크립트 파일을 GET 한단것은 해당 자바스크립트파일을 얻어와서 브라우져가 이용한다는 의미이다.

이밖에도 POST, PUT, DELETE 라는 REST서비스의 주요 메소드가 있다.

각각 역할에 대해서 알아보면

POST : 신규 리소스 작성 (단 서버측에서 리소스명을 정한다.)

PUT : 신규 리소스 작성 (단 클라이언트가 정한다.), 리소스의 수정

DELETE : 리소스의 삭제

GET : 리소스의 획득

 

이렇게 정리해놓으면 된다.

대체 저 method를 어떻게 정하는 것이냐 라고 비개발자가 물어보면 이렇게 표현할 수있다.

“그냥 <form method=”GET” …..> 이렇게 정해놓고 저장해 놓으면 됨.”

 

앞서 리소스는 명사라고 했다.

그럼 저 리소스명과 메소드가 합쳐져서 프로그램을 개발하는 근간이 된다는 말이 될것이다.

연습을 몇개 해보겠다.

 

중고 자동차 업체가 있다. 도메인은 존나싸닷컴이다.

http://www.jonnassa.com/

 

리소스를 정의해보자.

1. 신규 중고 자동차가 들어왔다. 종류는 소형차이며 이름은 abangte이다.

2. 곧이어 바로 신규 중고 자동차가 또들어왔다 종류는 또한 소형차이며 이름은 mybmw이다.

3. 소비자가 회원가입을 한다. 회원가입에 필요한 리소스를 모두 정의해보자.

4. 소비자가 mybmw를 키워드 검색한다.

5. 소비자가 mybmw를 구매한다.

6. abangte의 연식이 잘못되었다. 관리자는 연식을 수정한다. (2013년도로)

7. 회원이 구매하고 바로 서비스를 탈퇴한다.

 

일련의 저러한 절차를 리소스명과 메소드로 구성하면 api를 만든다고 할수 있다.

위에 절차를 모두 만들어보았으면 조금더 디테일하게 들어가보자.

 

그렇다면 브라우져가 해당 리소스를 통해 통신을 할텐데, 성공, 실패는 어떻게 구분할까?

그건 서버에서 처리한다. 즉 서버측 언어에서 디비 검색을 해보고 디비가 없다면 그 유명한 404라는

status code라고 하는 부분을 작성하고 보내준다.

 

trello를 보면 status란에 200이란 숫자가 보일것이다. 저것이 바로 성공이란 것을 의미한다.

이부분을 처음 접해봐서 어려울것 같으면 단 몇개만 외워보자.

200 : 성공

201 : 생성

204 : 성공했는데 보낼게 없음.

301 : 리다이렉트

400 : 사용자 요청에러

404 : 데이터없음

500 : 서버 맛감

 

더 자세한 것은 아래링크를 참조하면된다.

https://support.google.com/webmasters/answer/40132?hl=ko

Standard
■ Web

[Web] RestFul Service에 대해서 알아보자 (1)

rest service에 관한 첫번째 포스팅이다.

의미가 와닿지 않아도 이해만 하면된다.

서버를 구현해봐야 “이런 허접한 내용이였어?” 라고 이해할것이다.

 

[웹서비스의 의미]

먼저 “웹서비스를 구축한다.” 라고 하는 것은 http기반 protocol을 활용하여 network 통신을 구현하는 것을 의미한다.

여기서 http 기반 통신구현은 근래에 restFul 서비스라고 불리운다.

그렇다면 restFul 서비스를 http를 통해서 과연 어떻게 구현하느냐가 문제가 된다.

먼저 restFul의 더욱 상세한 의미를 살펴보자.

일단 REST의 의미를 보면, “웹의 아키텍쳐 스타일이다.” 라고 정의된다.

아키텍쳐 스타일이란 어려운 말이 아니고, 그냥 클라이언트/서버, P2P등 서버를 구현하는 방식/형태를 의미한다. (아키텍쳐 패턴이라고도 불리며, 이는 디자인 패턴과는 다르다. 디자인 패턴은 코드의 클래스등의 패턴을 의미한다.)

REST가 아키텍쳐 스타일이라면 클라이언트/서버 모델처럼 뭔가 구현 방식 및 형태를 정의할수 있어야 한다. 그럼 한번 정의해보자.

1. Client/Server : 클라이언트와 서버가 나누어져 있고 서버에서 내려준 것을 클라이언트가 받아 처리하고 다시 요청하는 형태.

2. Stateless Server : 서버는 상태를 저장하지 않는다. (예외적으로 세션이 있다.)

3. Cache (클라이언트에서 한번 받아오면 다시 요청하지 않고 해당 리소스를 사용.)

4. Uniform Interface (POST, DELETE, PUT, GET 위 4가지 메소드를 주요 메소드로 활용. OPTION,HEAD등 총 8개의 메소드가 있으나 사용을 많이 안함.)

5. Layer System (프록시 서버, 로드밸런서 등을 활용함.)

6. Code on Demand (js, css 파일등을 서버로부터 받아 클라이언트에서 코드 자체를사용한다.)

위에 언급한 6가지의 아키텍쳐 스타일을 하나로 합쳐서 필딩이란 사람이 그냥 REST라고 이름붙인 스타일을 만들고 해당 6가지 스타일을 반영하여 서비스를 구현한 것을 “restFul한 서비스다.” 라고 하는 것이다.

이밖에도 웹서비스를 restFul한 서비스가 아닌 SOAP등의 방식으로도 구현이 가능하다.

 

 

[리소스의 의미]

웹서비스를 구축할때의 리소스는 특별한 것이 아닌 단순히 “URI(Uniform Resource Indicator)로 표현이 가능한 모든것” 이라고 정의할 수 있다.

http://naver.com 으로 접속하면 네이버 메인 화면이 나온다. 이것은 네이버 메인화면을 가르키는 리소스(naver.com)이라고 할수 있다.

네이버 사전에서 happy를 검색하면

http://dic.naver.com/search.nhn?dicQuery=happy&x=0&y=0&query=happy&target=dic&ie=utf8&query_utf=&isOnlyViewEE=

다음과 같은 경로가 나온다.

뭔가 복잡해 보인다. 하지만 결론은 단순하다.

http://dic.naver.com/search.nhn 이라는 리소스 (네이버 사전 검색 리소스를 의미) 에서 dicQuery에 happy가 들어있다. 뒤에 뭔가 많이 나오는데 이것들을 query라고 부르며 단순히 “네이버사전검색” 리소스의 상세 정보를 나타내준다.

그렇다면 해당 리소스는 어떤 원리에 의해서 정할수 있을까?

간단한 원칙들이 존재한다.

1. 프로그래밍언어에 의존적인 확장자 피하기. (jsp, php 등)

2. 구현의 의존적인 경로명 피하기. (servlet, nodejs, express 등)

3. 메서드명 피하기.

4. 세션ID포함하지 않기.

5. 명사로 구현하기.

 

다른거 다까먹어도 좋다. 이것만 기억하자.

리소스명은 명사가 깔끔하며, 동사의 역할은 위에서 언급했던 POST,PUT,DELETE,GET등의 메소드로 대체한다. (자세한건 이후에 설명)

예를 들어보겠다.

시계 쇼핑몰에서 로렉스 시계중 메탈 시계를 의미하는 리소스를 만들어보자.

http://시계쇼핑몰/메탈/로렉스s (맨뒤에 s는 복수형을 의미)

과제 : 상대경로, 절대경로, url의 길이제한, url스키마, %인코딩에 대해서 설명해보자.

Standard