[web server] HTTP 요청(1) - 웹서버와 HTTP, HTTP 메시지

2021. 6. 9. 03:12

웹 서버란?

1. 하드웨어 측면의 웹서버 - 웹서버의 소프트웨어와 웹사이트의 컴포넌트 파일(HTML, 이미지, CSS, javascript 등 파일)을 저장하는 컴퓨터

2. 소프트웨어 측면의 웹서버 - URL과 HTTP 요청 및 응답을 처리하는 서버. 가장 일반적인 HTTPD(HTTP daemon) 서버는 Apache, Nginx, IIS 등이 있다.

HTTP란?

브라우저와 서버가 서로 소통을 할 수 있도록 만들어진 규약.
IETF(인터넷국제표준화기구)에서 RFC 문서 채택을 통해 이루어진다.

HTTP의 특징

메세지 교환 형태의 프로토콜: 클라이언트가 보고 싶은 걸 서버에 요청하면 응답이 온다.
비연결성(Connectionless): 클라이언트와 서버가 한 번 연결을 맺은 후, 클라이언트의 요청을 서버가 응답하면 맺었던 연결을 끊는다. 불특정 다수의 통신을 줄여 더 많은 연결이 가능하지만, 동일한 요청을 해야할 시 새로 요청해야 한다.
무상태(Stateless): 이전 상태를 유지 하지 않는다. 상태를 기억하기 위해서 쿠키, 세션, 토큰 등을 사용하기도 한다.

토막 상식: RFC란?

IETF에서는 어떤 사람이 작성해 배포한 기술 표존에 대해, 서로 의견을 제시하며 토론하고 최종적으로 받아들여 지는 것을 인터넷 표준으로 채택한다. 이런 초안을 RFC(Request for Comments)라고 하며 ‘비평을 기다리는 문서’의 의미를 갖는다.

RFC 편집자는 매 문서에 일련번호와 함께 배포하며, 절대 폐지되거나 수정되지 않는다.
만약 어떤 RFC 문서의 수정이 필요하다면 수정된 문서를 다시 출판해야 한다.
이런 덮어쓰는 방식을 통해 RFC는 인터넷 표준의 역사를 나타내기도 한다.

현재 HTTP 버전은 HTTP/0.9, HTTP/1.0, HTTP/1.1을 넘어 2.0과 3.0까지 발전중이다.

우리가 보는 웹 페이지 = HTTP 요청에 따른 응답

사용자가 브라우저상에서 google.com으로 접속(URL 입력)할 때, google.com에는 HTTP 요청이 보내진다.
HTTP 요청을 받은 google.com의 웹서버는 HTTP 응답으로 브라우저에게 HTML 파일을 제공하고, 브라우저는 HTML파일을 렌더링 해 화면을 그려낸다.

HTTP 메시지

클라이언트와 서버 사이의 연결을 위해 규칙으로 정해진 메시지 양식.

HTTP의 메시지의 규칙

HTTP 메시지는 요청메시지와 응답메시지로 나뉜다.
HTTP 메시지의 시작줄은 항상 한 줄로 끝난다.
키: 밸류 형식을 가진 HTTP 헤더 세트가 들어간다. 여기에는 요청에 대한 설명, 혹은 body에 대한 설명, 서버에 대한 설명 등이 들어간다.
모든 줄의 마지막에는 개행 (\r\n - CRLF) 이 붙는다.
HTTP 헤더가 끝난 경우 빈 줄(\r\n - CRLF) 이 한 줄 붙고 그 다음에 body가 오게 된다.
요청과 관련된 내용이나, 응답과 관련된 문서가 body에 들어간다. body의 존재 유무 및 크기는 첫 줄과 HTTP 헤더에 명시된다.
body의 끝에는 개행(\r\n - CRLF)이 붙지 않는다.

HTTP 요청 메시지

HTTP 메시지는 시작줄, 헤더, 본문으로 구성된다.

시작줄

HTTP Request의 첫 줄은 보통 시작줄이라고 불리며, 아래와 같은 양식을 가지고 있다.

메소드 URL HTTP버전

세 가지 정보는 스페이스로 구분된다.
시작줄은 보통 다음과 같은 세 가지 정보(메소드, URL, HTTP 버전)를 담고 있다.

1. HTTP에서 지원하는 요청 메시지(메소드)

GET: 클라이언트가 서버에게 URL에 해당하는 자료의 전송을 요청한다.
HEAD: 클라이언트가 서버에게 GET 요청으로 반환될 데이터 중 헤더에 해당하는 데이터만 전송해주길 요청한다.
POST: 클라이언트가 서버로 자료를 보낸다. 예를 들어, 게시판에 글을 쓸 때 클라이언트의 문서가 서버로 전송되어야 한다.
PATCH: 클라이언트가 서버에게 지정한 URL의 데이터를 부분적으로 수정할 것을 요청한다.
PUT: 클라이언트가 서버에게 지정한 URL에 지정한 데이터를 저장할 것을 요청한다.
DELETE: 클라이언트가 서버에게 지정한 URL의 정보를 제거할 것을 요청한다.
TRACE: 클라이언트가 서버에게 송신한 요청 내용을 그대로 반환해 줄 것을 요청한다.
CONNECT: 클라이언트가 특정 종류의 프록시 서버로 연결을 요청한다.
OPTIONS: 해당 URL이 지원하는 요청 메세지의 목록을 요청한다.

2. URL, 프로토콜, 포트, 도메인 등

주로 요청 메소드에 따라 종류가 갈리게 된다.

origin 형식: 끝에 '?'와 쿼리 문자열이 붙는 절대 경로. 가장 많이 쓰이며 GET, POST, HEAD, OPTIONS 메서드와 함께 사용된다.
```
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
```
absolute 형식: 완전한 URL 형식. 프록시에 연결하는 경우 대부분 GET과 함께 사용된다.
```
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
```
authority 형식: 도메인 이름 및 옵션 포트(':'가 앞에 붙는다.)로 이루어진 URL의 authority component 이다. HTTP 터널을 구축하는 경우에만 CONNECT와 함께 사용된다.
```
CONNECT developer.mozilla.org:80 HTTP/1.1
```
asterisk 형식: OPTIONS와 함께 별표('*') 하나로 간단하게 서버 전체를 나타낸다.
```
OPTIONS * HTTP/1.1
```

3. HTTP 버전

메시지의 양식을 가름짓는 HTTP 버전을 명시한다.

헤더 (header)

HTTP Request에서 헤더는 시작줄 바로 다음에 위치하게 된다.
헤더는 대소문자 구분없는 문자열 다음에 콜론이 붙으며, 그 뒤에 값이 붙게 된다.
헤더 한 줄의 마지막에는 개행 (\r\n - CRLF) 이 붙는다.
예시 :

Connection: keep-alive

HTTP 리퀘스트 상에서 헤더는 크게 네 가지 종류로 나뉜다.

일반 헤더(General Header)
- 요청과 응답 모두에서 사용될 수 있지만, 컨텐츠 자체와는 관련이 없는 헤더.
- 일반 헤더는 응답 헤더이면서 동시에 요청 헤더일 수 있다.
- 예시 : Date(메시지가 만들어진 날짜와 시간을 표시하는 헤더), Transfer-Encoding(entity의 인코딩 형식을 표시하는 헤더) 등
엔티티 헤더(Entity Header)
- HTTP 메시지에 body 컨텐츠가 존재할 때 사용하게 되는 헤더. 요청 및 응답 모두에서 사용이 된다.
- HTTP 메시지를 인터넷 운송 시스템의 컨테이너라고 생각한다면 엔티티는 HTTP 메시지의 본문, 즉 실질적인 화물이다.
- 실제 메시지 또는 전송중인 HTTP body의 의미에 대해 설명해준다. body는 가공되지 않은 단독의 raw데이터이기 때문에 엔티티 헤더에서 이를 설명해준다.
- 컨텐츠 길이, 컨텐츠 언어, 인코딩, 만료날짜 및 기타 중요한 정보를 담게 된다.
- request에 body가 없는 경우 엔티티 헤더는 전송되지 않는다.
- 예시 : Content-Language(사용자를 위한 언어를 표시하는 헤더), Content-Length(컨텐츠의 크기를 표시하는 헤더) 등
요청 헤더(Request Header)
- HTTP 요청에서 사용되지만 메시지의 컨텐츠와는 관련이 없는 헤더.
- 클라이언트의 정보를 서버로 보내주는 경우가 많다.
- 예시 : Host(클라이언트가 서버의 포트를 특정하는 헤더), Referer(현재 페이지 이전 웹 페이지의 주소를 표시하는 헤더) 등
응답 헤더(Response Header)
- HTTP 응답에서 사용되지만 메시지의 컨텐츠와는 관련이 없는 헤더.
- 위치 또는 서버 자체에 대한 정보와 같이, 응답의 부가적인 정보를 보내주는 경우가 많다.
- 예시 : Server(서버의 이름과 버전을 표시하는 헤더) 등

본문 (body)

헤더와 body 사이는 공백 개행(\r\n - CRLF) 한 줄로 나뉘어 있다.
많은 요청은 대부분 body를 포함하지 않는다.
GET, HEAD, DELETE, OPTIONS처럼 서버로부터 리소스를 가져오는 Request는 대부분 body를 필요로 하지 않는다.
단, 컨텐츠 업데이트를 위한 Request인 경우 body에 리소스를 담아 서버에 데이터를 전송한다. (POST)
body의 끝에는 개행(\r\n) 이 붙지 않는다.

HTTP 응답 메시지

HTTP 응답 메시지는 상태줄, 헤더, 본문으로 구성된다.

모든 줄의 마지막에는 개행 (\r\n - CRLF) 이 붙는다.
헤더가 모두 끝난 경우, 헤더와 body 사이는 공백 개행(\r\n - CRLF) 한 줄로 구분된다.
body의 끝에는 개행(\r\n - CRLF)이 붙지 않는다.

상태 줄

HTTP 응답의 시작 줄은 상태 줄(status line)이라고 불리며, 일반적으로 아래와 같은 양식을 가지고 있다.

HTTP/1.1 404 Not Found.

상태 줄은 다음과 같은 정보를 가지고 있다.

프로토콜 버전
- 보통 HTTP/1.1이다.
상태 코드
- 요청의 성공 여부를 나타낸다.
- Request의 상태 코드 목록 https://developer.mozilla.org/ko/docs/Web/HTTP/Status
상태 텍스트
- 상태 코드와 짝을 이루는 텍스트로, 짧고 간결하게 상태 코드에 대한 설명을 나타낸다.

헤더 (header)

Request 메시지의 헤더 설명과 동일하다.

본문 (body)

Response의 바디는 파일이나 그림이나 동적 페이지일 수도 있다.
가장 중요한 것은 이곳에 위치한 것을 웹 브라우저가 화면 상에 출력한다는 것이다.
파일 요청(GET Request 등) 이 들어오면 이곳으로 파일을 반환해야한다.

넓게 보면 body는 세가지 종류로 나뉜다.
- 이미 길이가 알려진 단일 파일로 구성된 단일-리소스 본문: 헤더 두개(Content-Type와 Content-Length)로 정의.
- 길이를 모르는 단일 파일로 구성된 단일-리소스 본문: Transfer-Encoding가 chunked로 설정되어 있으며, 파일은 청크로 나뉘어 인코딩 되어 있다.
- 서로 다른 정보를 담고 있는 멀티파트로 이루어진 다중 리소스 본문: 이 경우는 상대적으로 위의 두 경우에 비해 보기 힘들다.

헤더와 body 사이는 공백 개행(\r\n - CRLF) 한 줄로 나뉘어 있다.
body의 끝에는 개행(\r\n) 이 붙지 않는다.

Ref

'웹개발 > 웹개발 개념' 카테고리의 다른 글

npm ERR! code ENOSPC 오류와 이를 해결하기 위한 방법 (0)	2021.11.29
[web server] 토막 상식 : GET과 POST에서 패러미터 넘겨주기 - 쿼리스트링, Content-Type (0)	2021.06.18
[web server] 토막 상식 : CRLF 캐리지 리턴, 라인 피드 (\r\n) (0)	2021.06.11
로그인 API 연동하기 - Oauth 2.0과 Access Token이란? (0)	2021.06.07

공부하는 블로그

[web server] HTTP 요청(1) - 웹서버와 HTTP, HTTP 메시지

웹 서버란?

HTTP란?

HTTP의 특징

토막 상식: RFC란?

우리가 보는 웹 페이지 = HTTP 요청에 따른 응답

HTTP 메시지

HTTP의 메시지의 규칙

HTTP 요청 메시지

시작줄

헤더 (header)

본문 (body)

HTTP 응답 메시지

상태 줄

헤더 (header)

본문 (body)

'웹개발 > 웹개발 개념' 카테고리의 다른 글

+ Recent posts

티스토리툴바