서버 이론 뿌시기 - URI와 웹브라우저 요청 흐름

자 바로 전 게시글에서 웹 통신에 관해 공부해봤다.

 

다음은 URI다.

 

응?? URI??

URL은 아는데 URI는 또 뭐야??

 

별차이 없다. 그냥 URL의 큰 범위라고 생각하면 된다.

 

URI(Uniform Resource Indentifier)란?

즉 통합 자원 식별자라는 의미로 인터넷에서 우리가 원하는 자원을 찾기 위한 식별자를 의미한다.

 

URI는 URL과 URN으로 이루어졌고 여기서 URL이 나오게 된거다.

URL은 다 잘 알듯이 리소스의 위치를 말한다.

URN은 리소스의 이름을 부여한 것이다.

URN으로 리소스를 찾는 방법이 보편화 되지 않아서

그냥 URI를 URL로 혼용해서 쓰겠다.

 

https://www.google.com/search?q=hello&hl=ko

 

위와 같은 URL은 많이 봤을거다.

근데 정확하게 위의 URL이 무엇을 의미하는지 고민해 본적이 있나??

 

일단 나는 없다.

그러나 서버 이론을 뿌셔야 하는 사람은 정확히 알아야한다.

 

위 URL는 다음과 같이 구성 되어 있다.

• scheme://[userinfo@]host[:port][/path][?query][#frament]
• https://www.google.com/search?q=hello&hl=ko 

흠... 아직은 잘모르겠는 용어가 너무 많다.

하나하나 뜯어보면서 이게 뭔지 한번 이해해보자.

 

scheme?

scheme이란 패킷을 어떤 프로토콜을 써서 사용할 것 인가 이다.

 

위에서는 https가 scheme으로 사용되는데

일단은 그냥 http 프로토콜을 사용한다 라고 생각하고 넘어가자

 

host?

호스트는 도메인이다.

IP주소가 와도 되는데 직전 게시글에서 도메인 네임(DNS)을 주로 사용한다고 했던게 기억 나길 바란다.

 

port?

port 역시 지난번 게시글에서 설명했었다.

어떤 어플리케이션을 사용할 것 인지 알려주기 위해 사용하는 것이다.

 

path?

path는 어떤 리소스를 받을 것인지 구분하기 위해 사용하는 것이다.

 

그냥 간단하게

C://user/바탕화면

이런 느낌으로 디렉토리에 접근하는 방식과 같다고 생각하면 된다.

 

query?

key=value형태로 되어있고

query parameter, query string으로 불린다.

• https://www.google.com/search?q=hello&hl=ko 

구글 서버에서 search라는 장소로 요청을 보내고

q=hello&hl=ko로 데이터를 줬을때 알맞은 리소스를 찾아달라는 요청과 같은 의미이다.

 

fragment?

같은 페이지에서 화면의 위치를 설정하는 것을 말한다.

fragment로 설정할 수 있다.

 

이야 드디어 용어 설명이 끝났다.

 

이제 제대로 웹 브라우저의 요청 흐름에 관해 생각해보자

웹 브라우저의 요청 흐름

• https://www.google.com/search?q=hello&hl=ko 

자 다음과 같은 URL로 웹 브라우저에 요청을 보냈다.

 

그럼 응답 데이터를 받기 위한 과정은 아래와 같게 흘러간다.

 

요청 메세지의 흐름

1. 웹 브라우저는 먼저 https를 보고 http메세지를 생성한다.
2. 이후 IP가 무엇인지 DNS에 묻고
3. HTTP메세지를 다시 요청하게 된다.

위 3가지 과정은 다음과 같이 이루어 진다.

 

패킷을 생성할때 IP와 PORT를 기록하고 HTTP요청 메세지를 감싸서 생성하게 된다.

 

응답 패킷 역시 위와 같고 html을 꺼내 렌더링하면 위 검색 링크가 화면에 뜨게 된다.

 

 

http(hyper text transfer protocol)란?

그렇다면 도대체 http란 무엇일까??

 

http는 인터넷 통신에서 가장 많이 사용되는 프로토콜이라고 생각하면 된다.

 

HTTP에 담을 수 있는 데이터는 아래와 같다.

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML
• 서버 간 데이터 전송
• 모든 형태의 데이터 전송

이렇게 모든 형식의 데이터를 http에 담아서 전송한다고 생각하면 된다.

 

그러면 HTTP에는 어떠한 특징이 잇을까?

HTTP의 특징은 다음과 같다.

• 클라이언트 서버 구조
• 무상태 프로토콜, 비연결성
• HTTP 메세지
• 단순하고 확장 가능함

이렇게 보면 무슨 말인지 잘 이해가 안되니 하나씩 뜯어서 봐보자.

 

클라이언트 서버 구조란?

Request Response 구조를 가졌고

클라이언트가 서버에 요청을 보내면 응답을 대기하고

서버가 요청에 대한 결과를 응답한다.

 

어?? 어디서 봤는데?

서버 첫 게시글의 웹 통신의 가장 기초적인 단계에서 설명했던 것이다.

 

즉, 요청을 보낸 곳은 클라이언트

요청을 받는 곳은 서버라고 생각하면 된다.

 

그래서 서버는 계속해서 서버인 것이 아니라 클라이언트가 될 수가 있다.

 

무상태 프로토콜이란?

서버가 클라이언트의 상태를 보존하지 않는다.

장점: 확장성이 높다.

단점: 클라이언트가 추가로 데이터를 전송해야 한다.

 

예시를 들어서 설명해 보겠다.

 

내가 장을 보러 갔다고 생각해 보자

나는 감자 2개를 살거다.

감자를 고르고 점원에게 결제를 하러 갔다.

 

이때 stateful한 점원이라면

다음과 같이 응답할 것이다.

고객: 감자 1개 얼마에요?
점원: 1천원이요.


고객: 2개 구매할게요
점원: 총 2천원 입니다. 신용카드와 현금중 무엇을 선택 하실 건가요?


고객: 신용카드요
점원: 2천원 결제 됐어요.

 

음.. 그냥 마트 직원인데요?

그렇다 일반적인 상태를 stateful이라고 한다.

 

그런데 stateless한 점원이라면 어떨까?

고객: 감자 1개 얼마에요?
점원: 1천원이요.


고객: 2개 구매할게요
점원: 무엇을 두개 구매할 것인가요?


고객: 신용카드요
점원: 무슨 제품을 몇개를 신용 카드로 구매하실 건가요?

 

위처럼 stateless한 상황이 발생하면 직원은 매우 당황할 것이다.

 

따라서 stateless상태에는 아래와 같이 요청을 보내야 한다.

고객: 감자 1개 얼마에요?
점원: 1천원이요.


고객: 감자 2개 구매할게요
점원: 총 2천원 입니다. 신용카드와 현금중 무엇을 선택 하실 건가요?


고객: 감자 2개를 신용카드로 구매할게요.
점원: 2천원 결제 됐어요.

 

아니 그럼 귀찮게 계속 써줘야 함??

언뜻 보기에는 불편할 수도 있다. 그런데 다 이유가 있다.

 

상태를 계속 유지하려면 점원이 일단 바뀌면 안된다.

새로 바뀐 점원에게 인수인계를 하나하나 해줘야 한다는 단점이 있다.

 

그런데? 무상태라면?

갑자기 고객이 증가하면 점원을 많이 투입시키면 된다.

 

무상태 프로토콜 덕분에

응답 서버를 쉽게 바꿀 수 있다는 장점이 있고

무한한 서버 증설이 가능하다는 이점이 나타나게 된다.

위와 같이 중계서버를 둬서 하나랑 연결하고 있다가

해당 서버가 닫히면 다른 서버랑 연결하는 방식으로 요청과 응답이 가능해지게 된다.

 

그런데 모든 것을 무상태로 할 수 있을까??

 

겠냐?

 

이 티스토리만 하더라도 로그인을 해야만 자신만의 글을 쓸 수 있다.

이런 로그인 상태가 유지가 되려면 http 무상태 프로토콜을 상태 유지 시켜야한다.

 

이건 스프링을 배우면서 차차 알아보자.

 

HTTP 메세지

코딩을 하면서 어플리케이션을 작성해 본 적이 있을거다.

 

그런데 과연 우리가 직접적으로 다루는 부분이 TCP/IP 계층일까?

 

아니다.

우리가 직접적으로 코딩하고 다루는 부분은 HTTP 메세지가 된다.

 

그러면 HTTP메세지는 어떤 형태로 구성되어 있을까??

 

한번 자세히 뜯어 보도록 하자. 

HTTP 메세지는 위처럼

요청 메세지와 응답 메세지의 2가지 형탤를 하고 있다.

 

딱 한번 봤을 때 이게 뭔지 하나도 모르겠는 것들이 즐비한다.

 

그럼 하나씩 뜯어 보자

 

HTTP 메세지는 다음과 같이 구성되어 있다.

1. 시작라인
2. header
3. 공백 라인 (header와 body의 구분자)
4. body

시작라인 부터 body까지 하나씩 알아보도록 하자

 

시작라인? 

요청 메세지

요청 메세지의 시작 라인은 다음과 같이 구성되어 있다.

 

시작 라인의 처음에 오는 녀석은

요청 메서드이다.

 

요청 메서드는 게시판 주요기능은 CRUD와 같은 역할을 하는데

POST == Create

READ == Get

PUT == Update

DELETE == Delete

이렇게 4가지로 구성 되어 있다.

 

위 4가지 메서드를 통해 서버가 어떤 동작을 할지 지정해 준다.

 

요청 메서드 다음에 나오는건 Path와 query이다.

Path와 query를 통해 서버의 어느 위치에서 리소스를 요청할 것인지 결정한다.

 

시작 라인 마지막에 오는 건 HTTP 버전이다.

 

응답 메세지

응답 메세지의 시작 라인은 모두 같고 200, 400, 500등의 응답 상태를 알려주는 status-line이 추가로 있다.

 

HTTP 헤더?

HTTP 헤더는 시작 라인 밑에 온다.

 

헤더에는 요청할때의 호스트를 적기도 하고

요청 받는 리소스의 타입과 길이를 적기도 한다.

 

헤더의 용도는 메세지 전송에 필요한 부가 정보를 담기도 한다.

 

HTTP 바디?

실제 데이터를 전송하는 공간으로

 

헤더 밑 공백라인을 한칸 두고 그 밑에는 body가 오게 된다.

 

서버가 리소스를 직접 담아서 옮기는데

 

예를 들면 서버에게 google페이지를 요청하면

서버가 구글 페이지의 html을 body부분에 담아서 응답 메세지로 전송하게 된다.

그러면 클라이언트는 해당 페이지를 볼 수 있개 되는 것이다.

 

 

 

이렇듯 HTTP는 단순하고 확장 가능한 특징을 가졌다.

이런 특징들 덕에 현 인터넷 통신망을 점령하게 되었다.