[HTTP 웹 기본 지식] 2 - URI, HTTP 기본

 

본 글은 김영한 님의

[모든 개발자를 위한 HTTP 웹 기본 지식] 강의를 듣고 정리한 내용입니다.

 

URI (Uniform Resource Identifier)

---

URI, URL, URN

URI는 리소스(자원)를 식별하는 통합된 방법이라는 뜻입니다.

URI의 개념에는 URL(Locator), URN(Name)이 포함되어 있습니다.

URL은 리소스가 있는 위치를 지정합니다.

ex) https://milku.tistory.com/manage/newpost/?type=post

URN은 리소스에 이름을 부여합니다.

ex) urn:example:animal:ferret:nose

URN의 단점은 이름을 부여하면 찾기가 어렵다는 것입니다. (리소스 매핑이 어려움)

그래서 거의 URL만 사용합니다.

 

URL 전체 문법

scheme://[userinfo@]host[:port][/path][?query][#fragment]

scheme: 주로 프로토콜을 사용합니다.

userinfo: 거의 사용하지 않습니다.

host: 도메인명 또는 IP 주소를 직접 사용합니다.

port: 포트, 일반적으로 생략하고 생략 시 http는 80, https는 443입니다.

path: 리소스 경로입니다.

query: 쿼리 스트링입니다.(key=value 형태)

fragment: html 내부 북마크에서 사용하고 서버로 전송되는 정보는 아닙니다.

 

웹 브라우저 요청 흐름

---

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

웹 브라우저 ↔ 구글 서버

1. DNS를 조회하여 IP 정보를 찾아냅니다.

2. PORT 정보를 찾아냅니다.

3. 웹 브라우저가 HTTP 요청 메시지를 생성하고 OS계층에서 TCP/IP 패킷을 씌웁니다.

4. 요청 패킷을 구글 서버에 전송합니다.

5. 구글 서버는 받은 패킷 내부의 메시지를 해석합니다.

6. 구글 서버는 HTTP 응답 메시지를 생성하고 똑같이 패킷을 씌워 웹 브라우저로 전송합니다.

7. 웹 브라우저는 받은 HTTP 응답 메시지의 HTML 데이터를 렌더링하여 화면에 보여줍니다.

 

HTTP 요청 메시지

 

HTTP 응답 메시지

 

HTTP 기본

---

HTTP (HyperText Transfer Protocol)

HTTP 메시지에 모든 것을 전송합니다.

HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML(API) 등 거의 모든 형태의 데이터 전송이 가능합니다.

서버 간에 데이터를 주고 받을 때도 대부분 HTTP를 사용합니다.

 

HTTP 버전

여러 버전이 있습니다. 그 중에 HTTP/1.1 을 주로 사용하며, 우리에게 가장 중요한 버전입니다.

HTTP/1.1, HTTP/2 : TCP 프로토콜 위에 동작합니다.

HTTP/3 : UDP 기반으로 개발이 되어 있습니다.

 

HTTP 특징

---

클라이언트 서버 구조

클라이언트와 서버를 분리합니다.

비지니스 로직과 데이터는 서버에서 관리하고, 클라이언트는 UI와 사용성에 집중합니다.

클라이언트는 서버에 요청을 보내고, 응답을 대기합니다.

서버는 요청에 대한 결과를 만들어서 응답을 보냅니다.

 

무상태 프로토콜 (Stateless)

상태 유지 (Stateful)

서버가 클라이언트의 정보를 유지합니다.

항상 같은 서버가 유지되어야 합니다.

서버 증설이 어렵습니다.

클라이언트는 통신하던 서버과 계속 통신해야 합니다.

중간에 통신하던 서버가 장애가 발생하면, 클라이언트는 다른 서버에 처음부터 요청을 다시 해야합니다.

 

무상태 (Stateless)

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

클라이언트가 애초에 요청할 때부터 필요한 데이터를 담아서 보냅니다.

중간에 다른 서버로 바꿀 수 있습니다.

무한한 서버 증설이 가능합니다.

아무 서버나 호출해도 됩니다.

 → 스케일 아웃으로 서버의 확장에 유리합니다.

 

무상태 (Stateless)의 한계

Stateless로 설계할 수 있는 경우도 있고, 없는 경우도 있습니다.

로그인이 필요한 서비스의 경우, Stateful을 사용해야 합니다.

일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태를 유지하는 기능을 구현합니다.

Stateful은 최소한으로, 꼭 필요한 경우에만 사용해야 합니다.

Stateless는 전송되는 데이터의 양이 많습니다.

 

비연결성 (connectionless)

연결을 유지하는 모델

기본적으로 TCP/IP 연결의 경우, 클라이언트와 서버의 연결을 유지합니다.

클라이언트와 서버가 통신을 하지 않을 때에도 연결을 유지하고 있고, 계속해서 서버의 자원을 소모합니다.

 

연결을 유지하지 않는 모델

요청을 주고 받을 때만 연결하여, 서버가 유지하는 자원을 최소한으로 줄일 수 있습니다.

 

HTTP는 기본적으로 연결을 유지하지 않는 모델입니다.

일반적으로 초 단위 이하의 빠른 속도로 응답합니다.

웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않으므로,

1시간 동안 수천 명이 서비스를 사용하더라도 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작습니다.

서버 자원의 가용성을 높이고, 자원을 효율적으로 사용할 수 있습니다.

 

비연결성의 한계와 극복

페이지 이동 시마다 TCP/IP 연결을 새로 맺어야 합니다. 이 경우 3 way handshake 시간이 계속 추가됩니다.

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드됩니다.

현재는 HTTP 지속 연결(Persistent Connections)로 문제를 해결합니다.

그리고 HTTP/2, HTTP/3에서는 더 많이 최적화가 되었습니다.

심지어 HTTP/3 에서는 UDP 프로토콜을 사용하여 연결 속도 자체를 줄였습니다.

 

HTTP 메시지

HTTP 메시지 구조

start-line 시작 라인

header 헤더

empty line 공백 라인(CRLF)

message body

 

start-line 시작 라인

요청 메시지

 HTTP 메서드 SP(공백) 요청 대상 SP HTTP 버전 CRLF(엔터)

 ex) GET /search?q=hello&hl=ko HTTP/1.1

응답 메시지

 HTTP 버전 SP HTTP 상태 코드 SP 이유 문구 CRLF

 ex) HTTP/1.1 200 OK

 

* HTTP 상태 코드 : 요청 성공, 실패를 나타냅니다.

• 200 : 성공
• 400 : 클라이언트 요청 오류
• 500 : 서버 내부 오류

header 헤더

헤더 필드 = 필드명 ":" OWS(띄어쓰기 허용) 필드값 OWS

ex)

Host: www.google.com

Content-Length: 3500

HTTP 전송에 필요한 모든 부가 정보가 포함되어 있습니다. (바디 내용, 크기, 압축, 요청 클라이언트 정보, ...)

 

message body

실제 전송할 데이터입니다.

HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터를 전송할 수 있습니다.

 

단순함, 확장 가능

 

 

References

인프런 강의 [모든 개발자를 위한 HTTP 웹 기본 지식]

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC