Doctor Pepper

[응용 계층] HTTP(Hypertext Transfer Protocol) 본문

네트워크/응용 계층

[응용 계층] HTTP(Hypertext Transfer Protocol)

Doctor Pepper 2024. 11. 10. 10:34
728x90

 

 우리가 인터넷을 사용할 때 가장 중요한 프로토콜 중 하나로, 웹 브라우저와 서버 간의 데이터 전송을 담당한다. HTTP는 문서, 이미지, 동영상 등 다양한 웹 리소스를 사용자에게 전달하는 역할을 하며, 웹의 근간이 되는 기술이다. 

 

1. HTTP(Hypertext Transfer Protocol)

 

 HTTP(Hypertext Transfer Protocol)는 웹 브라우저와 서버가 정보를 주고받을 수 있게 해주는 요청-응답 기반 프로토콜로, 인터넷 상에서 웹 페이지를 로드하거나 다양한 웹 리소스를 전달하는 데 필수적인 역할을 한다. HTTP는 비연결형 구조와 무상태성 등의 특징을 통해 효율적으로 동작하며, 다양한 미디어를 전송할 수 있는 미디어 독립적 특성을 가지고 있다. 

비연결성(Connectionless) HTTP는 요청과 응답 후 연결이 종료되는 비연결형임.
무상태성(Stateless) HTTP는 상태를 저장하지 않는 프로토콜로써 각 요청은 독립적이고, 서버는 클라이언트의 이전 요청 정보를 기억하지 않음.

 

 - 요청-응답 기반 프로토콜

 HTTP는 클라이언트가 서버에 특정 리소스나 데이터를 요청하면, 서버는 요청에 응답하여 데이터를 전송하는 방식이다. 이러한 구조는 HTTP의 핵심 원리로, 클라이언트는 요청 메시지를 보내고 서버는 응답 메시지로 답변하는 형태이다. 이 과정에서 요청과 응답은 독립적으로 작동하며, 각각의 HTTP 요청은 서버의 상태나 이전 요청에 영향을 주지 않는 방식으로 처리된다.

 

 - 스테이트리스 프로토콜

 각각의 요청이 독립적으로 처리되며, 서버는 클라이언트의 이전 요청이나 상태를 기억하지 않는다. 예를 들어, 클라이언트가 특정 웹 페이지를 요청한 후 다른 페이지를 요청할 때, 서버는 첫 번째 요청과 두 번째 요청 간의 관계를 알지 못한다. 이러한 무상태성은 서버의 자원 소모를 줄이고, 확장성을 높이는 장점이 있지만, 상태 정보가 필요한 경우에는 쿠키(Cookie)나 세션(Session)을 사용하여 상태를 관리한다.

 

 - 지속 연결 프로토콜(Persistent Connection)

 초기 HTTP/1.0에서는 클라이언트가 서버에 요청을 보낼 때마다 새로운 연결을 생성하고 응답 후에는 연결을 끊는 비연결성(Connectionless) 방식이 사용되었다. 이는 웹 페이지를 로드하는 데 많은 연결이 필요하여 속도가 느려지는 문제가 있었다.

 이를 해결하기 위해 HTTP/1.1에서는 지속 연결(Persistent Connection)이 도입되었다. 지속 연결에서는 클라이언트와 서버 간에 하나의 연결을 유지한 상태에서 여러 요청과 응답을 주고받을 수 있다. 이렇게 연결을 재사용하면 페이지 로딩 속도가 개선되며, 자원을 절약할 수 있다. 예를 들어, 클라이언트가 한 번의 연결로 HTML, CSS, 이미지 파일 등 여러 자원을 한꺼번에 요청하고 응답받을 수 있다.

 

2. HTTP 메시지 구조

 HTTP 메시지는 클라이언트의 요청(Request) 메시지와 서버의 응답(Response) 메시지로 나뉘며, 각각 요청과 응답의 목적에 맞는 구조를 가지고 있다. HTTP 메시지의 주요 구성 요소로는 시작 줄(Start Line), 헤더(Header), 본문(Body)이 있으며, 메시지마다 역할에 따라 조금씩 다르게 구성된다.

 

- HTTP 요청 메시지 구조

 HTTP 요청 메시지는 클라이언트가 서버에 특정 리소스를 요청할 때 사용하는 메시지이다. 

요청 줄
(Request Line)		 요청의 기본 정보를 포함함
 - 메서드(Method) : 클라이언트가 서버에 요청하는 작업의 종류를 나타냄(GET, POST, PUT, DELECTE 등)
 - URL : 요청할 리소스의 경로임
 - HTTP 버전 : 요청에 사용된 HTTP 프로토콜 버전을 명시함
헤더(Header) 요청의 메타데이터를 포함하여, 여러 개의 필드로 이루어짐. 각각의 필드는 키: 값 형식으로 표현됨
 - Host : 요청을 보낼 서버의 호스트 주소를 지정함
 - User-Agent : 클라이언트의 소프트웨어 정보를 전달하며, 브라우저와 버전 정보 등을 포함함
 - Accept : 클라이언트가 서버에 요청하는 데이터 형식임
 - Content-Type : 본문에 포함된 데이터 형식을 지정함
본문(Body) 요청할 실제 데이터를 포함하는 부분으로, POST, PUT 메서드에서 주로 사용됨
ex) 사용자 입력 데이터나 파일 전송데이터를 본문에 포함시킬 수 있음
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html

 

- HTTP 응답 메시지 구조

 HTTP 응답 메시지는 서버가 클라이언트의 요청에 대해 전송하는 응답 메시지이다. 

상태 줄
(Status Line)		 응답의 상태를 설명하는 줄임
 - HTTP 버전 : 서버가 사용하는 HTTP 프로토콜 버전임
 - 상태 코드(Status Code) : 요청의 처리 결과를 나타내는 코드임
 - 상태 설명(Status Text) : 상태 코드의 설명 문구임
헤더(Header) 응답에 대한 메타데이터를 포함하며, 키: 값 형식으로 구성됨
 - Content-Type : 응답 본문에 포함된 데이터 형식을 명시함
 - Content-Length : 응답 본문의 크기를 바이트 단위로 명시함
 - Server : 응답을 제공하는 서버의 소프트웨어 정보를 전달함
 - Set-Cookie : 클라이언트에 쿠키를 저장하도록 지시하는 필드임
 본문(Body) 서버가 클라이언트에 전달할 실제 데이터를 포함하는 부분임. HTML 문서, 이미지, JSON 데이터 등이 본문에 포함될 수 있으며, 상태 코드가 '200 OK' 인 경우 본문을 통해 요청한 리소스를 전달함
HTTP/1.1 200 OK
Content-Type : text/html
Content-Length : 137
Server : Apache/2.4.1 (Unix)

<html>
    <body>
        <h1>Welcome to Example</h1>
    </body>
</html>

 

3. HTTP 메서드

 HTTP 메서드는 클라이언트가 서버에 요청할 작업의 종류를 정의하는 역할을 하며, 특정 리소스에 대해 어떤 조치를 취할지 서버에 지시한다. HTTP 메서드는 다양한 작업을 수행할 수 있는 여러 가지 유형이 있으며, 그중 가장 일반적으로 사용되는 메서드는 GET, POST, PUT, DELETE, PATCH 등이 있다. 각 메서드마다 고유한 기능이 있으며, 이를 통해 HTTP 프로토콜에서 클라이언트와 서버 간의 상호작용이 가능하다.

GET 기능 : 서버에서 리소스를 요청하여 데이터를 가져올 때 사용되며, URL을 통해 서버에 요청하고 서버는 요청한 리소스를 응답에 포함해 반환함
특징
 - 데이터를 요청하는 메서드이므로, 서버 상태나 리소스에 영향을 주지 않음
 - 요청의 파라미터는 URL의 쿼리 문자열에 포함되므로, 보안이 중요한 데이터에는 적합하지 않음
 - 캐시 가능 : GET 요청은 서버에서 캐싱되기 때문에 성능을 개선할 수 있음
ex) 웹 페이지의 HTML 콘텐츠를 가져오거나, 특정 데이터를 조회할 때 주로 사용됨 
POST 기능 : 서버에 데이터를 전송하여 리소스를 생성하거나 데이터를 처리할 때 사용되며, 주로 폼 데이터 전송이나 파일 업로드 등에서 활용됨
특징
 - 서버에 데이터를 전달하며, 서버 상태나 데이터베이스에 변화를 일으킬 수 있음
 - 캐시 불가능 : POST 요청은 일반적으로 캐싱되지 않음
 - 요청 데이터는 HTTP 본문(Body)에 포함되므로, GET과 달리 대용량 데이터를 안전하게 전송할 수 있음
ex) 회원 가입 폼 데이터를 서버로 전송하여 새로운 사용자를 생성할 때 사용됨
PUT 기능 : 서버의 특정 리소스를 업데이트하거나, 리소스가 없다면 새로 생성함
특징
 - 서버의 기존 리소스를 수정하거나 새로운 리소스를 추가하는 데 사용됨
 - 요청 본문에 수정하거나 추가할 데이터를 포함함
 - 멱등성 : 동일한 요청을 여러 번 보내도 결과가 변하지 않는 특성이 있어, 여러 번 요청해도 동일한 결과를 보장함
ex) 사용자 프로필 정보를 수정할 때 사용됨
DELETE 기능 : 서버에서 특정 리소스를 삭제할 때 사용됨
특징
 - 서버의 특정 리소스를 삭제 요청함
 - 멱등성 : 동일한 DELETE 요청을 여러 번 보내더라도 서버 상태에 영향을 주지 않으며, 항상 동일한 결과를 반환함
ex) 특정 게시물을 삭제하거나 파일을 제거할 때 사용됨
PATCH 기능 : 리소스의 일부를 업데이트할 때 사용되며, PUT 메서드가 전체 리소스를 업데이트하는 반면, PATCH는 일부만 수정할 수 있음
특징
 - 서버의 리소스 중 일부 필드만 수정할 때 효율적으로 사용할 수 있음
 - 멱등성 여부는 구현에 따라 다름 : 요청을 반복할 때 서버 상태가 달라질 수 있으므로 주의해야 함
ex) 사용자의 이메일 주소나 전화번호와 같은 특정 필드만 변경할 때 사용됨
기타 메서드 HEAD : GET과 유사하지만, 응답 본문 없이 응답 헤더만 반환함. 주로 리소스의 메타정보만 필요할 때 사용함
OPTIONS : 서버에서 지원하는 HTTP 메서드를 요청함. 주로 클라이언트가 서버와의 통신 옵션을 확인할 때 사용함
CONNECT : 주로 HTTPS를 위한 프록시 서버와의 터널 연결을 설정하는 데 사용됨
TRACE : 요청이 서버로 어떻게 도달하는지 경로를 추적하는 데 사용됨

 

4. HTTP 상태 코드

 상태 코드는 서버가 클라이언트의 요청을 처리한 결과를 나타내는 3자리 숫자 코드이다. 상태 코드는 클라이언트가 요청을 성공적으로 처리했는지, 오류가 발생했는지, 추가 작업이 필요한지를 쉽게 이해할 수 있도록 도와준다. 상태 코드는 크게 다섯 가지 범주로 나뉘며, 각 범주는 숫자의 첫 번째 자리로 구분된다.

100번대(100~199) 정보성 상태 코드
200번대(200~299) 성공 상태 코드
300번대(300~399) 리다이렉션 상태 코드
400번대(400~499) 클라이언트 에러 상태 코드
500번대(500~599) 서버 에러 상태 코드

 

 - 100번대 : 정보성 상태 코드

 100번대 코드는 요청을 처리 중이라는 의미로, 클라이언트에게 요청이 수신되어 처리 중임을 알리는 상태이다. 이 범주의 상태 코드는 주로 HTTP/2 및 웹 프로토콜에서 쓰이며, 일반적으로 사용 빈도가 낮다.

100 Continue 클라이언트의 요청이 일부분 수신되었으며, 나머지 요청을 계속 전송해도 된다는 의미
101 Switching Protocols 서버가 클라이언트 요청에 따라 프로토콜 전환을 시작했음을 나타냄
102 Processing 서버가 요청을 수신하고 처리 중이지만, 아직 완료되지 않았음을 나타냄. WebDAV 요청과 같이 시간이 오래 걸리는 작업에 사용됨.
103 Early Hints 클라이언트가 리소스를 완전히 로드하기 전에 일부 리소스에 대한 정보를 미리 제공함으로써 초기 로딩 성능을 향상시키기 위해 사용됨.

 

 - 200번대 : 성공 상태 코드

 200번대 코드는 클라이언트의 요청이 성공적으로 처리되었음을 나타낸다.

200 OK 요청이 성공적으로 처리되어 응답 본문에 요청한 리소스가 포함되어 반환됨
201 Created 요청이 성공적으로 처리되었고, 새로운 리소스가 생성되었음을 나타냄.
주로 POST 요청 후 사용됨
202 Accepted 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음을 나타냄
203 Non-Authoritative Information 요청이 성공적으로 수행되었으나, 응답 데이터가 원본 서버가 아닌 다른 소스에서 제공된 비공식 정보를 포함하고 있음을 나타냄.
204 No Content 요청이 성공적으로 처리되었으나 반환할 내용이 없음을 나타냄.
예를 들어, DELETE 요청이 성공한 경우 이 상태 코드가 사용될 수 있음
205 Reset Content
요청이 성공적으로 수행되었으며, 클라이언트가 현재 화면을 새로 고침하거나 폼 입력을 초기화해야 함을 나타냄.
206 Partial Content 클라이언트가 요청한 리소스의 일부 범위만을 서버가 성공적으로 반환했음을 나타냄. 주로 파일 다운로드 시 특정 범위의 데이터 요청에 사용됨.
207 Multi-Status 여러 개의 개별 작업에 대한 결과를 포함하는 다중 상태 응답으로, 각 항목에 대한 성공 또는 실패 상태가 함께 반환됨.
208 Already Reported
DAV(Dynamic Authorization Validation)에서 사용되며, 이전 요청에서 이미 멀티-상태 응답으로 보고된 리소스를 다시 보고할 필요가 없음을 나타냄.
226 IM Used 서버가 GET 요청에 대해 IM(Instance Manipulations) 헤더를 사용하여 리소스에 대해 하나 이상의 인스턴스 조작을 성공적으로 수행했음을 나타냄.

 

 - 300번대 : 리다이렉션 상태 코드

 300번대 코드는 클라이언트가 요청한 리소스가 다른 위치로 이동했음을 나타내며, 클라이언트가 리소스를 가져오기 위해 추가 조치를 취해야 함을 의미한다.

300 Multiple Choices 요청한 리소스에 대해 여러 선택 사항이 있으며, 클라이언트가 여러 리소스 중 하나를 선택할 수 있음을 나타냄.
301 Moved Permanently 요청한 리소스가 영구적으로 다른 URL로 이동했으며, 이후 요청 시 새로운 URL을 사용해야 함을 나타냄.
302 Found 요청한 리소스가 일시적으로 다른 URL에 위치해 있으며, 임시로 새로운 URL을 사용해야 함을 나타냄.
303 See Other 클라이언트가 POST 등의 요청을 완료한 후, 결과를 확인하기 위해 다른 URL로 GET 요청을 보내야 함을 나타냄.
304 Not Modified 클라이언트가 캐시된 리소스를 가지고 있으며, 서버에서 해당 리소스가 수정되지 않았음을 나타냄. 캐시된 리소스를 재사용할 수 있음.
305 Use Proxy
(Deprecated)		 클라이언트가 요청을 프록시를 통해 전송해야 함을 나타냄. 현재는 보안상의 이유로 대부분의 브라우저에서 지원하지 않음.
307 Temporary Redirect 요청한 리소스가 일시적으로 다른 URL에 있으며, 클라이언트가 원래 요청한 HTTP 메서드를 유지한 채 새로운 URL로 요청해야 함을 나타냄.
308 Permanent Redirect 영구적 리다이렉션으로, 재요청 메서드 변경이 되지 않았음을 나타냄

 

 - 400번대 : 클라이언트 오류 상태 코드

400번대 코드는 클라이언트의 요청에 오류가 있음을 나타내며, 클라이언트가 요청을 수정해야 한다.

400 Bad Request 서버가 요청을 이해할 수 없거나 구문 오류가 있어 요청을 처리할 수 없음을 나타냄. 클라이언트가 잘못된 요청을 보냈을 때 사용됨.
401 Unauthorized 요청이 인증되지 않았음을 나타냄. 클라이언트가 인증 자격 증명을 제공하지 않거나 제공된 자격 증명이 유효하지 않음.
402 Payment Required 결제 필요를 나타내며, 현재는 대부분의 시스템에서 사용되지 않음. 이 코드는 미래의 결제 관련 상태 코드로 예약됨.
403 Forbidden 서버가 요청을 이해했지만, 클라이언트가 해당 리소스에 접근할 권한이 없음을 나타냄. 일반적으로 인증이 되더라도 권한이 부족한 경우 사용됨.
404 Not Found 요청한 리소스를 서버에서 찾을 수 없음을 나타냄. URL이 잘못되었거나 리소스가 존재하지 않는 경우 사용됨.
405 Method Not Allowed 클라이언트가 요청한 HTTP 메서드(예: GET, POST 등)가 서버에서 지원되지 않음을 나타냄. 예를 들어, GET 요청을 사용해야 할 곳에 POST 요청을 보낸 경우 발생함.
406 Not Acceptable 클라이언트가 요청한 리소스의 형식을 서버가 제공할 수 없을 때 발생함. 예를 들어, 클라이언트가 특정 MIME 타입을 요청했으나 서버가 이를 제공하지 못하는 경우
407 Proxy Authentication
Required 		요청을 처리하려면 프록시 인증이 필요함을 나타냄. 클라이언트는 인증 자격 증명을 프록시 서버에 제공해야 함
408 Request Timeout 클라이언트가 서버로의 요청을 시간 내에 완료하지 못했을 때 발생함. 서버가 요청을 기다리는 동안 시간이 초과되었음을 나타냄
409 Conflict 요청이 서버의 현재 상태와 충돌하여 요청을 처리할 수 없음을 나타냄. 예를 들어, 자원의 상태 변경이 다른 요청과 충돌할 때 사용됨
410 Gone 요청한 리소스가 영구적으로 제거되었으며 더 이상 서버에서 사용할 수 없음을 나타냄. 404와 비슷하지만 리소스가 더 이상 존재하지 않음을 명시적으로 나타냄
411 Length Required 요청에 Content-Length 헤더가 누락되었을 때 발생함. 서버는 요청 본문의 길이를 알아야 한다는 것을 나타냄
412 Precondition Failed 클라이언트가 설정한 전제 조건이 서버에서 실패했음을 나타냄. 예를 들어, 특정 ETag가 맞지 않는 경우 사용됨
413 Payload Too Large 요청 본문의 크기가 서버가 처리할 수 있는 크기를 초과할 때 발생함
414 URI Too Long 요청된 URI가 서버에서 처리할 수 있는 길이를 초과했을 때 발생함.
415 Unsupported
Media Type 		서버가 요청한 미디어 타입을 지원하지 않음을 나타냄. 예를 들어, 서버가 처리할 수 없는 파일 형식이 전송된 경우 발생함.
416 Range Not Satisfiable 클라이언트가 요청한 범위가 유효하지 않거나 서버가 해당 범위를 제공할 수 없을 때 발생함.
417 Expectation Failed 서버가 클라이언트의 Expect 헤더에 지정된 요구 사항을 충족할 수 없을 때 발생함
418 I'm a teapot 이 코드는 원래 "Hyper Text Coffee Pot Control Protocol"이라는 농담에서 비롯된 것으로, 클라이언트가 차가운 커피를 만들려 시도할 때 서버가 "차가운 커피를 만들 수 없다"는 응답을 보내는 것을 나타냄. 실제로는 사용되지 않음
421 Misdirected Request 요청이 잘못된 서버로 전송되었을 때 발생함. 서버가 요청을 처리할 수 없는 경우 사용됨
422 Unprocessable Entity 요청은 잘 구성되었지만 서버가 처리할 수 없을 때 발생함. 보통 WebDAV에서 사용됨
423 Locked 요청한 리소스가 잠겨 있어 처리할 수 없음을 나타냄. WebDAV에서 사용됨
424 Failed Dependency 이전 요청이 실패하여 현재 요청을 처리할 수 없음을 나타냄. WebDAV에서 사용됨
425 Too Early 서버가 요청을 처리하기에 너무 이르다고 판단할 때 발생함. 이 코드는 현재 잘 사용되지 않음
426 Upgrade Required 클라이언트가 더 안전한 프로토콜로 업그레이드해야 함을 나타냄. 예를 들어, HTTP에서 HTTPS로의 전환이 필요할 때 사용됨
427 Unassigned 이 상태 코드는 아직 사용되지 않음.
428 Precondition Required 요청에 전제 조건이 필요함을 나타냄. 예를 들어, "If-Match"와 같은 헤더를 통해 특정 조건이 충족되어야 요청을 처리할 수 있는 경우 사용됨
429 Too Many Requests 클라이언트가 너무 많은 요청을 짧은 시간 안에 보냈을 때 발생함. 주로 Rate Limiting과 관련됨
431 Request Header
Fields Too Large 		요청 헤더가 너무 커서 서버에서 처리할 수 없을 때 발생함
451 Unavailable For
Legal Reasons 		요청한 리소스가 법적 이유로 사용할 수 없을 때 발생함. 예를 들어, 정부의 차단 정책 등이 있을 수 있음

 

 - 500번대 : 서버 에러 상태 코드

500번대 코드는 서버에서 요청을 처리하는 중에 오류가 발생했음을 나타낸다. 클라이언트의 요청은 유효하지만, 서버 문제로 인해 요청이 처리되지 않은 경우이다.

500 Internal Server Error 서버에서 요청을 처리하는 도중 예기치 않은 오류가 발생했음을 나타냄. 일반적으로 서버 측 문제로 클라이언트의 요청을 처리할 수 없음을 의미함.
501 Not Implemented 서버가 요청한 메서드를 지원하지 않거나 구현하지 않았음을 나타냄. 예를 들어, 클라이언트가 서버가 처리할 수 없는 HTTP 메서드를 요청한 경우 발생함.
502 Bad Gateway 서버가 게이트웨이 또는 프록시로서 작동할 때, 상위 서버로부터 유효한 응답을 받지 못한 경우 발생함. 즉, 서버가 다른 서버로부터 올바른 응답을 받지 못한 경우에 발생하는 오류임.
503 Service Unavailable 서버가 일시적으로 과부하되었거나 유지보수 중이어서 요청을 처리할 수 없음을 나타냄. 나중에 다시 시도해볼 수 있음을 의미하며, 일반적으로 서버가 일시적으로 사용할 수 없는 경우에 발생함.
504 Gateway Timeout 서버가 게이트웨이 또는 프록시로서 작동할 때, 상위 서버로부터 적시에 응답을 받지 못한 경우 발생함. 즉, 서버가 다른 서버와의 통신에서 시간 초과가 발생한 경우에 사용됨.
505 HTTP Version
Not Supported 		서버가 클라이언트가 요청한 HTTP 버전을 지원하지 않음을 나타냄. 요청에서 사용된 HTTP 버전이 서버에서 처리할 수 없는 경우에 발생함.
507 Insufficient Storage 서버가 요청을 처리하기 위해 필요한 저장 공간이 부족함을 나타냄. WebDAV에서 발생할 수 있는 오류로, 저장 용량 부족이 원인임.
508 Loop Detected 서버가 요청을 처리하는 중 무한 루프를 감지했음을 나타냄. 이는 주로 WebDAV에서 발생하며, 요청에 의해 무한 루프가 발생했을 때 사용됨.
510 Not Extended 요청된 기능을 처리하기 위한 추가 확장이 필요함을 나타냄. 요청에 필요한 기능이 서버에 의해 확장되지 않았을 때 발생함.
511 Network
Authentication Required 		요청을 처리하기 전에 네트워크 인증이 필요함을 나타냄. 사용자가 네트워크에 인증되지 않은 상태에서 접근하려 할 때 발생함.

 

5. HTTP의 발전 : HTTP/0.9에서 HTTP/3.0

HTTP는 다양한 버전이 발전하면서 웹의 성능과 보안, 효율성을 크게 개선해 왔다.

특징 0.9 1.0 1.1 2.0 3.0
요청 방식 단일 리소스 텍스트 리소스 전송 헤더 및 리소스 전송 멀티플렉싱 QUIC 기반
연결 방식 단일 요청 당 연결 매 요청마다 연결 연결 지속
(Keep-Alive)		 단일 연결 다중 요청 QUIC 연결
성능 낮음 낮음 개선된 대폭 개선됨 더 빠름
보안 없음 없음 선택적 보안 TLS 지원 필수 TLS 1.3
특징 단순 요청/응답 MIME 타입, 쿠키 등 파이프라인 처리 서버 푸시,
헤더 압축		 0-RTT 연결,
패킷 재전송 개선

 

- HTTP/0.9(1991년)

  • 특징: HTTP/0.9는 가장 초기의 HTTP 버전으로, 웹 페이지를 전송하는 데 사용되었다. 주로 텍스트 파일만을 전송할 수 있었고, 간단한 요청/응답 방식을 따랐다.
  • 동작: 클라이언트는 서버에 HTTP 요청을 보내면, 서버는 응답으로 HTML 파일을 반환했다. HTTP/0.9는 단일 리소스 요청만을 처리하며, 헤더 정보나 메타데이터를 지원하지 않았다.

 

- HTTP/1.0(1996년)

  • 특징: HTTP/1.0은 HTTP/0.9의 단점을 개선한 버전으로, 헤더 필드를 도입하여 요청 및 응답에 대한 추가 정보를 제공할 수 있게 되었다.
  • 동작: HTTP/1.0은 리소스를 전송할 때마다 새로운 연결을 설정하는 비연결형 연결을 사용했다. 이로 인해 다수의 리소스를 요청할 때마다 연결을 새로 설정해야 했고, 이로 인한 성능 저하가 있었다.
  • 기능: MIME 타입, 상태 코드, 쿠키 등의 개념을 추가하여, 웹에서 다양한 리소스를 처리할 수 있는 기능을 제공했다.

 

- HTTP/1.1(1997년)

 

  • 특징: HTTP/1.1은 가장 널리 사용되는 HTTP 버전으로, HTTP/1.0의 여러 제한을 해결하고 성능을 향상시켰다.
  • 동작: HTTP/1.1에서는 연결 지속(Persistent Connection) 기능을 도입하여, 하나의 TCP 연결을 통해 여러 리소스를 요청하고 응답할 수 있게 되었다. 이를 통해 연결 설정과 해제에 드는 비용을 절감할 수 있었다.
  • 기능: 파이프라인 처리, 가상 호스팅, 캐싱 메커니즘 개선, 콘텐츠 압축 등을 도입하여 웹 성능을 개선했다.

 

- HTTP/2.0(2015년)

  • 특징: HTTP/2는 성능 최적화를 목표로 한 HTTP 버전으로, TCP 연결을 통해 여러 요청을 동시에 처리할 수 있게 해주는 멀티플렉싱 기능을 도입했다.
  • 동작: HTTP/2는 단일 연결에서 여러 요청을 동시에 처리할 수 있도록 하여, 대기 시간을 최소화하고 성능을 개선했다. 요청과 응답은 프레임으로 나누어져 전송되며, 우선순위를 설정할 수 있다.
  • 기능: 헤더 압축(HPACK), 서버 푸시(Server Push) 기능 등을 도입하여 효율적으로 데이터 전송을 할 수 있다. 또한 TLS(전송 계층 보안)를 필수로 사용하여 보안성도 높였다.

 

- HTTP/3.0(2022년)

 

  • 특징: HTTP/3는 QUIC(Quick UDP Internet Connections)라는 새로운 전송 프로토콜을 기반으로 설계되었다. QUIC은 UDP(사용자 데이터그램 프로토콜)를 이용하여 연결 지연을 최소화하고, TCP에서 발생할 수 있는 여러 문제를 해결했다.
  • 동작: HTTP/3는 QUIC을 사용하여 0-RTT 연결(zero-round-trip time) 기능을 도입하고, 여러 연결을 병렬로 처리할 수 있다. QUIC은 네트워크 장애나 지연을 효율적으로 처리할 수 있어 성능이 크게 향상되었다.
  • 기능: 연결 재설정 없이 데이터를 병렬로 전송할 수 있으며, 헤더 압축과 스트림 우선순위 등을 지원한다. 또한, 보안을 강화하기 위해 TLS 1.3을 사용하고, 연결 설정 시간을 줄이며 보다 빠른 웹 성능을 제공한다.

 

 

 HTTP는 웹에서 클라이언트와 서버 간의 효율적인 데이터 전송을 가능하게 하는 중요한 프로토콜로, 요청-응답 기반 구조와 다양한 HTTP 메서드를 통해 웹 리소스를 전달하고, 상태 코드를 통해 통신의 상태를 명확히 전달한다. 또한, 지속 연결, 비연결성, 무상태성 등의 특성을 통해 효율적인 웹 페이지 로딩과 리소스 관리를 지원하며, 다양한 메커니즘을 통해 확장성과 성능을 높일 수 있다. HTTP의 역할은 웹 개발에서 매우 중요하며, 이를 잘 이해하는 것은 웹 애플리케이션을 구축하고 최적화하는 데 중요한 기초가 된다.

 

 

 

728x90

'네트워크 > 응용 계층' 카테고리의 다른 글

[세션 계층] 4계층 장비  (4) 2024.11.12
[응용 계층] HTTP 헤더와 HTTP 기반 기술  (6) 2024.11.10
[응용 계층] NTP(Network Time Protocol)  (3) 2024.10.19
[응용 계층] SMTP(Simple Mail Transfer Protocol), POP & IMAP  (2) 2024.10.18
[응용 계층] DNS(Domian Name System)  (1) 2024.10.18
'네트워크/응용 계층' Related Articles more