본문 바로가기
Computer Science/Network

[네트워크] "www.google.com"을 입력하면 어떻게 되나? 5편 HTTP

by whatamigonnabe 2022. 8. 10.

이전 글

"www.google.com"을 입력하면 어떻게 되나? 1편 - LAN/WAN, TCP/IP 4 계층, 패킷 교환 방식

"www.google.com"을 입력하면 어떻게 되나? 2편 DNS

"www.google.com"을 입력하면 어떻게 되나? 3편 Port(포트), Socket(소켓)

"www.google.com"을 입력하면 어떻게 되나? 4편 SSL (TLS)

 

드디어 구글 서버와 연결에 성공했습니다. 이제 우리가 사용하는 프로세스끼리 통신하고 싶은 내용을 작성하여 패킷을 구성해야합니다.

HTTP: 인터넷을 통해 데이터를 주고 받는 규약

대게 어떤한 개념을 이해하기 위해서는 그 단어의 뜻을 이해하는 것이 도움이 되곤합니다. 그래서 HTTP도 단어의 뜻부터 알아보겠습니다.

그래서 우선 HTTP는 Hyper Text Transfer Protocol의 약자입니다.

그럼 우선 Hyper Text는 무엇일까요? 위키피디아의 정의를 가져왔습니다.

Hypertext is text displayed on a computer display or other electronic devices with references (hyperlinks) to other text that the reader can immediately access

사실 거의 모든 인터넷 페이지들은 어떤 다른 페이지로 이어지는 링크(하이퍼링크)들로 있기 때문에, 하이퍼텍스트는 인터넷 페이지라고 이해해도 좋을 것 같습니다.

그리고 뒤에 쓰여진 Transfer를 보아하니 우선 HTTP는 인터넷 페이지를 주고 받는 것 같습니다. 사실 초기의 인터넷 통신은 단순한 텍스트 기반이었기에 하이퍼텍스트를 주고 받는 것이 주 목적이었지만, 지금은 인터넷 문서를 포함하여 기타 이미지나 영상 등 여러 데이터를 주고 받는 데 쓰이고 있습니다.

 

다시 말하면, HTTP란 인터넷을 통해 데이터를 주고 받는 약속된 규약입니다. 우리가 정확히 알지는 못해도 이렇게 엄격히 정해진 규칙을 가진 데이터를 보내고 받으면서 인터넷을 사용하고 있습니다. 실제로 크롬과 같은 브라우저가 이 통신규약을 따른 정보를 받아서 알아서 해석한다음 화면에 이쁘게 표시하는 역할을 하고 있습니다.

 

HTTP 특징 - 무상태성(stateless)

HTTP는 무상태성이라는 특징을 가지고 있습니다. http 통신은 이전에 이뤄졌던 통신와 항상 독립적이고 세션 정보를 따로 저장하지 않습니다. 이 덕분에 가시성(Visibility), 신뢰성(Reliability), 확장성(Scalability)를 높일 수 있습니다.

 

1. 가시성: 하나의 통신의 전체적인 내용을 확실하게 이해하기 위해서 이전의 통신을 살필 필요가 없습니다.

2. 신뢰성: 부분적인 실패에서 빠르게 회복할 수 있습니다.

3. 확장성: 서버의 자원을 더 효율적으로 활용할 수 있고, 실행이 더 간단합니다.

 

HTTP의 구성: Requset와 Respons

http통신은 기본적으로 요청과 응답으로 이뤄져있고, 약속된 양식에 맞게 각 메시지를 작성하게 됩니다. 그러니까 주소창에 'www.google.com'을 입력하면, http request를 약식에 맞게 작성하여 구글 서버에 보내고, 구글 서버는 http response를 양식에 맞게 작성하여 클라이언트로 보냅니다. 그러면 이 정보를 브라우저가 해석하여 이쁘게 화면에 출력하는 식입니다.

HTTP Request

우선 Request의 구성에 대해 알아보겠습니다. 위의 그림처럼, Request는 크게 세 부분으로 나눠집니다. 

 

1. Request Line: requset 메서드 정보, 요청 타겟(URI 등), http 버전 정보를 담고 있습니다.

2. Header: 요청에 대한 여러 정보를 담고 있습니다. 여러 제약 조건이나, 컨텍스나, 바디의 길이를 나타내는 정보 등을 담습니다 .

3. Body: 실제로 보내는 데이터를 담습니다. 모든 메서드에서 필요한 것은 아니고, 일부 메서드에서 필요합니다. 

 

Request Methods

request line에 들어가는 메서드에 대해 알아보겠습니다. 

출처: 위키피디아

 

자주 사용하는 메서드는 아래와 같습니다.

1. GET: 주로 데이터를 요청할 때 사용하는 메서드입니다. 보통 어떤 홈페이지에 접근하기 위해서 브라우저 주소창에 주소를 입력하고 엔터를 치면 이뤄지는 메서드입니다.

2. POST: 새로운 자원을 생성할 때 사용하는 메서드입니다.

3. PUT: 자원을 수정할 때 사용합니다.

4. DELETE: 자원을 삭제할 때 사용합니다.

 

왜 이렇게 다양한 메소드를 사용할까요? 우선, '멱등성(idempotence)'이라는 개념이 있습니다. 이는 어떤 요청이 있더라도 서버의 상태가 바뀌지 않는 성질입니다. 예를 들어 'ID를 10으로 설정해줘'와 'ID를 1씩 늘려줘'를 비교해보면, 전자는 계속 같은 요청을 하더라도 ID는 10입니다. 원래 있던 값에 다른 값으로 '대체'하는 것이죠. 원래의 값이 바뀔 수는 있어도 더 추가되거나 삭제되지 않는, 즉 상태가 일정합니다. 따라서 이 요청은 멱등성은 있지만 안전성이 없죠. 메소드에 따라 멱등성이 있는지 여부를 판단할 수 있고, 이에 따라 에러에 대처하는 방법이 달라집니다. 

그리고 이 멱등성에 따라서, 1) 오류에 대처하는 방법을 쉽게 판단할 수 있고, 2)캐슁(Caching)여부를 판단할 수 있습니다. 예를들어 리소스를 조회하는 데에 사용하는 GET 메서드는, 아무리 많은 조회를 하더라도 서버에 있는 리소스의 상태가 변하지 않습니다. 달리말해 멱등성이 있습니다. 따라서 사용자가 GET 요청을 했고 서버에서는 처리됐지만 Response를 보내는 과정에서 오류가 생겼습니다. 이때 사용자는 메서드가 GET인것을 보고 제대로 응답이 올 때까지 요청을 반복하면 그만입니다. 반면에 멱등성이 없는 메서드의 경우는 서버와 함께 오류를 해결해야겠지요. 또한 항상 같은 값을 리턴하는 요청에 대해서는 캐슁을 할 수 있겠죠.

 

HTTP RESPONSE

Response 또한 3 부분으로 구성됩니다.

1. Status Line: 프로토콜 버전, 통신의 성공이나 실패 등 상태코드, 상태 메시지를 담습니다.

  상태코드와 의미는 아래와 같습니다.

1XX (informational)The request was received, continuing process.
2XX (successful)The request was successfully received, understood, and accepted.
3XX (redirection)Further action needs to be taken in order to complete the request.
4XX (client error)The request contains bad syntax or cannot be fulfilled.
5XX (server error)The server failed to fulfill an apparently valid request.
      - 출처: 위키피디아

2. Header: 요청 메시지와 마찬가지로, 요청 자체에 대한 정보들이 담깁니다. 

3. Body: 요청의 주요 정보들을 담습니다. 위의 첨부한 사진처럼 일부 메서드만 Body를 필요로합니다.

 

How it works?

그래서 주소창에 www.google.com을 입력하면 어떻게 될까요? 브라우저가 HTTP REQUEST를 만듭니다.

Request Line에 Method로는 'GET'을 사용하고

URL로는 https:www.google.com이 들어갈 겁니다.

그리고 header에는 아래와 같은 정보들이 들어갑니다.(크롬 개발자 도구 사용)

그리고 body의 경우는 get 메서드는 body가 필요없기 때문에 빈칸으로 만들어집니다.

 

이렇게 만들어진 HTTP REQUEST를 앞 편에서 알아보았던 SSL 프로토콜로 넘어가서 암호화하는 작업을 진행하게 됩니다.

 

다음편에는 SSL 프로토콜고 TCP/IP 를 다뤄보겠습니다.

 

참고

https://blog.cordelia273.space/11

https://velog.io/@sdc337dc/%EC%9B%B9-%EA%B0%9C%EB%85%90-Http-%ED%86%B5%EC%8B%A0

https://velog.io/@rimu/%EC%9B%B9%EA%B3%BC-%EC%84%9C%EB%B2%84%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B8%B0%EC%B4%88%EC%A7%80%EC%8B%9D-HTTP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Response_status_codes

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages