HTTP(2) - HTTP의 기본 - URI, HTTP의 특징, HTTP 메세지 (2025)

김영한 강사님의 HTTP 웹 기본지식 강의 내용과 자료를 이용했음을 밝힙니다.

URI, URL, URN이라는 개념이 있다.

URI, URL은 들어봤는데, URN은 생소할 것이다. (사실 난 URI도 생소하다..)

URI = URL + URN으로 보면 되는데

각각 뜻을 보면

URI - Uniform Resource Identifier
URL - Uniform Resource Locater
URN - Uniform Resource Name

의 의미다.

즉 인식자인데 URL은 위치를 나타내는 인식자이고 URN은 이름을 나타내는 인식자 그리고 URI는 이 두개의 개념을 포함하는 인식자라고 생각하면 되겠다.

예시를 통해서 보면
URL는
foo://example.com:8042/over/there?name=ferret#nose

URN은
urn:example:animal:ferret:nose

이렇게 보면 확실히 위치와 이름을 나타낸 것을 알 수 있다.

그러면 우리는 왜 URL은 잘 들었고 사용하면서 URN은 사용하지 않을까?

바로 URN, 즉 이름으로 실제 리소스를 찾을 수 있게 하는 방법이 보편화되지 않았다.

URL은 리소스들과 맵핑되어 있지만 URN은 그렇지 않기에 URN은 사용하지 않는다.

URL의 구성에 대해 알아보자.

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

위의 URL 예시들을 보자.
첫 번째 URL은 구성을 나타낸 것이고 밑은 실제 구글에서 hello를 검색했을 때의 URL이다.

URL의 구성은

프로토콜(https)
호스트명(www.google.com)
포트 번호(443)
패트(/search)
쿼리 파라미터(?q=hello&hl=ko)

이렇게 구성되어 있다.

자세히 알아보자.

1. scheme

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

주로 프로토콜을 사용한다 like http, https, ftp ...
참고로 https는 http에 secure(보안)을 추가한 것이다.

2. userinfo

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

URL에 사용자 정보를 넣는 것인데, 특수한 경우들을 제외하고는 거의 사용하지 않는다.

3. host

HTTP는 모든 것을 전송할 수 있다.

일단 위에서 웹 브라우저 요청 흐름을 보면 HTML만 주고 받는 것처럼 보일테고 실제로 옛날에는 그랬지만 이제는 이미지, 음성, 영상, xml 모든 것을 주고 받을 수 있다.

HTTP 역사

HTTP는 1990년대 부터 존재했지만 우리가 알아야 하는 버전은 1997년에 나온 1.1 버전으로 가장 많이 사용되고 가장 중요한 버전이다.

그 이후로 2, 3 버전이 나왔으며

1.1과 2는 TCP를 기반 프로토콜로 사용하는 반면에 3은 TCP의 속도가 느린 단점을 해결하기 위해 UDP를 기반 프로토콜로 사용한다.

1.1 버전이 가장 많이 사용되고 있으며 2, 3 버전도 점차 많이 사용되고 있는 추세이다.

1. 클라이언트 서버 구조

원래 HTTP가 있기 전에는 클라이언트와 서버가 분리되어 있지 않았다.

하지만 HTTP가 클라이언트가 서버에 요청을 보내고 응답을 대기하면 서버가 요청을 받고 응답하는 Request Response 구조를 만들었다.

이것이
서버는 비지니스 로직과 데이터를
클라이언트는 ui에
집중하게 하면서 클라이언트, 서버가 개념적으로 분리되게 만들었다.

결과적으로 클라이언트, 서버가 독립적으로 발달할 수 있게 만들었다.

2. 무상태 프로토콜(stateless)

무상태, 영어로는 stateless이다.

무상태라는 것은 상대방(서버)가 요청자(클라이언트)의 정보를 가지고 있지 않는 것이다.

요청자 A가 점원 B와 아이유에 대해 이야기를 하고 있다가
"암튼 그 사람 앨범 주세요"
라고 말했다고 하자.

유상태(stateful)라고 하면 상대방은 요청자가 아이유에 대해 말하고 있었다는 정보를 가지고 있기에 요청에 받는 답을 줄 수 있다.

하지만 무상태(stateless)라고 하면 상대방은 아무 정보가 없기에 방금까지 대화를 했더라도 누구의 앨범을 말하는지 알 수가 없다.

그래서 무상태에서는 요청자는
"아이유 앨범 주세요"
이런 식으로 처음 듣는 사람도 알 수 있게 말을 해야한다.

그럼 이게 어떤 장점을 가지고 있을까?

어떠한 이유로 인해서 점원 B가 가고 C가 왔다.

이런 경우에 유상태 방식으로 말하면 C는 알아들을 수 없겠지만 무상태 방식으로 말하면 C는 바로 아이유의 앨범을 A에게 가져다 줄 것이다.

즉 서버가 교체되도 요청을 받는데 아무 문제가 없다는 것이다.

그래서 서버가 문제가 생겨도, 클라이언트들이 많이 들어와서 서버들이 여러 클라이언트들을 왔다 갔다 해야해도 괜찮은 것이다.

이런 응답 서버를 쉽게 바꿀 수 있는 장점은 서버의 확장성을 높여 무한한 서버를 증설할 수 있게 해준다.

하지만 무상태인 만큼 서버가 아무 것도 모르기에 보내야할 정보가 많은 것이 단점이다.

하지만 백엔드 개발자로서 무상태로 개발하는 것을 지향해야 함을 명심하자.

3. 비 연결성(connectionless)

위에서 살짝 언급했는데

클라이언트들이 많이 들어와서 서버들이 여러 클라이언트들을 왔다 갔다 해야해도 괜찮은 것이다.

이 부분이다.

http에서 서버는 한 클라이언트와 1대 1로 계속 연결되어 있지 않다.

클라이언트1이랑 연결하고 요청 해결하고 연결 끊고
클라이언트2랑 연결하고 요청 해결하고
즉 연결을 유지하고 있지 않는다.

이렇게 하면 한명의 클라이언트와 연결하면서 그 클라이언트의 요청만 해결하는 것은 비효율적이다.
또한 서버는 초 단위로 요청을 해결하는데 수천명이 서비스를 이용해도 실제 서버에서 동시에 오는 요청은 수십개 이하여서 적은 서버로 효율적으로 요청들을 관리할 수 있다.

하지만 단점도 존재한다.

매번 연결을 끊고 연결하기에 TCP의 3 way handshake를 매번 해야해서 시간이 오래 걸린다.
html, css, javascript 등 많은 자원을 다운로드 해야한다.

하지만 지금은 http 2, 3에서 지속 연결(persistent connections)로 이 부분을 최적화 및 해결을 해나가고 있다.

예를 들어

연결
html 요청/ 응답
종료
연결
css 요청 / 응답
종료
연결
javascript 요청 / 응답
종료

와 같은 문제를 아예 몇 십초정도 연결을 유지하게 해서

연결
html 요청/ 응답
css 요청 / 응답
javascript 요청 / 응답
종료

이렇게 최적화한 것이다.

HTTP 요청, 응답 메세지는 특정 양식이 있다.

둘 다

start-line (시작 라인)
header (헤더)
empty line (공백 라인)(CRLF)
message body

의 형식이다.

예시를 보면

HTTP 요청 메세지

GET/search?q=hello&hl=ko HTTP/1.1 //start-lineHost: www.google.com //header//empty line

(요청 메세지에도 message body 넣을 수 있다)

HTTP 응답 메세지

HTTP/1.1 200 OK//start-lineContent-Type: text/html;charset=UTF-8//headerContent-Length:3423//header//empty line<html>//message body<body>...</body>//message body</html>//message body

이런 식이다.

그럼 하나씩 알아보자

1. start-line (시작 라인)

start-line은 요청 메세지는 request-line, 응답 메세지는 status-line이라고 해서 형식이 다르다.

요청 메세지 (request-line)

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

1-1). HTTP 메서드

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

HTTP 메소드를 적는 곳이다.
HTTP 메소드로는 GET(리소스 조회), POST(요청 내역 처리) 등이 있다.
서버가 수행해야할 동작을 지정해준다.

1-2).요청 대상

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

절대경로[?쿼리] 와 같은 형태
요청 메세지 내용으로 절대경로로 리소스 위치를, 쿼리로 요청 추가 정보를 전달한다.

1-3). HTTP 버전

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

말 그대로 HTTP의 버전을 적는 곳이다.

응답 메세지 (status-line)

HTTP/1.1 200 OK

status-line의 형식은 HTTP-version SP status-code SP reason-phrase CRLF 의 형태로 이뤄져있다.
(SP = 띄어쓰기(space))
status-code(HTTP 상태 코드): 요청 성공, 실패를 나타낸다.
밑과 같은 코드가 있다.
200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류
reason-phrase(이유 문구): 코드로만 보내면 잘 모르는 사람의 입장에서는 이해를 할 수 없으니 OK나 ERROR와 같이 이해할 수 있는 짧은 코드 설명 글이다.

2. HTTP 헤더

Content-Type: text/html;charset=UTF-8
Content-Length:3423

형식은 header-field=field-name":"OWS field-value OWS이다.
(OWS: 띄어쓰기 허용)
header-field, 즉 필드 이름(Content-Type, Content-Length)는 대문자로 시작하는 소문자로 시작하든 상관 없다.
HTTP에 전송에 필요한 부가정보를 담는 곳으로 메세지 바디의 내용, 압축, 인증 등등을 보낼 수 있다
필요시 임의의 헤더를 추가할 수 있다.

3. HTTP 메세지 바디

실제 전송할 데이터로 html, JSON, 영상 등 byte로 표현할 수 있는 모든 데이터를 전송 가능하다.

강의에서 크게 성공하는 기술은 HTTP처럼 단순하지만 확장 가능한 기술이라고 한다는 말에 많은 공감을 한다.

단순하지만 단순하지 않다.
단순하지만 가벼운, 하급 기술이 아니라는 뜻이다.

어떻게 복잡한 매커니즘으로 돌아가겠지라고만 생각하던 통신 부분을 알아갈 수록 지금 내가 현재 사용하고 있는 이 웹사이트 조차도 많은 패킷들과 요청, 응답이 오갈 걸 생각하니 신기할 따름이다.