기반 프로토콜
• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용
• HTTP/2, HTTP/3 도 점점 증가
HTTP 특징
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능
HTTP(HyperText Transfer Protocol)는 웹에서 데이터를 교환하는 데 사용되는 프로토콜이다. 웹에서 클라이언트(주로 웹 브라우저)와 서버 간에 커뮤니케이션을 가능하게 하며, HTML 문서나 이미지와 같은 리소스를 요청하고 전송하는 데 사용된다.
- 작동 원리: 클라이언트는 서버에 특정 리소스를 요청하는 HTTP 요청을 보내고, 서버는 요청을 받아 처리한 후 요청된 리소스와 함께 HTTP 응답을 클라이언트에게 보낸다. 이 과정은 상태를 유지하지 않는 비연결형 프로토콜이기 때문에 각 요청은 독립적이다.
- 주요 메소드: HTTP는 여러 가지 메소드를 제공한다. 가장 흔히 사용되는 메소드는 GET (리소스를 요청할 때 사용), POST (새로운 데이터를 서버에 제출할 때 사용), PUT (리소스를 업데이트할 때 사용), DELETE (리소스를 삭제할 때 사용) 등이 있다.
- 상태 코드: 서버는 요청의 결과를 나타내는 상태 코드를 응답에 포함시킨다. 예를 들어 200 OK는 요청이 성공적으로 처리되었다는 것을 의미하고, 404 Not Found는 요청한 리소스를 찾을 수 없다는 것을 나타낸다.
- 버전: HTTP 프로토콜은 여러 버전이 있으며, 현재 가장 널리 사용되는 버전은 HTTP/1.1과 HTTP/2이다. HTTP/2는 성능 개선을 위해 도입되었으며, 여러 요청과 응답을 동시에 처리할 수 있는 멀티플렉싱 기능을 제공한다.
HTTP의 클라이언트-서버 구조는 웹의 기본적인 작동 방식을 설명하는 모델이다. 이 구조에서 데이터와 리소스는 클라이언트와 서버 간에 교환된다. 클라이언트는 서버에 데이터를 요청하고 서버는 이러한 요청에 응답한다.
- 클라이언트: 클라이언트는 서버에 서비스나 데이터를 요청하는 역할을 하는 웹 브라우저, 모바일 애플리케이션 또는 다른 종류의 클라이언트 소프트웨어를 말한다. 예를 들어, 웹 브라우저가 클라이언트가 되어 사용자가 입력한 URL에 해당하는 웹페이지 데이터를 서버에 요청한다.
- 서버: 서버는 클라이언트의 요청을 받아 처리하고 필요한 데이터나 서비스를 제공하는 시스템이다. 웹 서버는 HTML 문서, 스타일 시트(CSS), 이미지 파일, 비디오 등 다양한 형태의 콘텐츠를 저장하고 관리한다. 클라이언트의 요청에 따라 이러한 리소스를 네트워크를 통해 클라이언트에 전송한다.
- HTTP 요청과 응답 과정:
- 요청: 클라이언트는 웹 서버에 특정 리소스를 요청하는 HTTP 요청 메시지를 보낸다. 이 메시지는 요청 메소드(GET, POST 등), 요청하는 리소스의 URI, 프로토콜 버전, 필요한 경우 추가 헤더를 포함할 수 있다.
- 응답: 서버는 요청을 처리한 후 클라이언트에 HTTP 응답 메시지를 보낸다. 응답 메시지에는 상태 코드(200 OK, 404 Not Found 등), 프로토콜 버전, 응답에 포함된 데이터, 응답 헤더 등이 포함된다.
- 비연결성과 무상태성:
- 비연결성: HTTP는 기본적으로 연결을 유지하지 않는 프로토콜이다. 즉, 클라이언트와 서버 사이의 연결은 요청과 응답 과정이 끝나면 즉시 종료된다. 이는 서버 자원을 효율적으로 사용할 수 있도록 해준다.
- 무상태성: HTTP는 무상태 프로토콜이므로 서버는 클라이언트의 이전 요청을 기억하지 않는다. 상태 정보가 필요한 경우, 쿠키나 세션과 같은 기술을 사용하여 클라이언트의 상태를 관리한다.
무상태 프로토콜(stateless protocol)은 통신 프로토콜에서 클라이언트와 서버 간의 통신이 일어날 때 이전의 상호작용을 기억하지 않는 특성을 말한다. 즉, 각 통신 요청은 서로 독립적으로 처리되며, 이전 요청의 정보가 후속 요청에 영향을 주지 않는다.
무상태 프로토콜의 특징
- 독립적인 요청 처리: 각 요청은 서버에 의해 별개로 처리되며, 요청 간에 정보가 공유되지 않는다.
- 서버 자원의 효율적 사용: 서버는 각 요청을 처리한 후 즉시 그 요청에 대한 모든 정보를 삭제할 수 있으므로, 메모리와 같은 자원을 더 효율적으로 관리할 수 있다.
- 확장성: 무상태 프로토콜은 서버의 부하를 줄이고 다수의 서버로 요청을 쉽게 분산시킬 수 있어 확장성이 높다.
상태 프로토콜(stateful protocol)과의 차이
상태 프로토콜은 클라이언트와 서버가 통신하는 동안 클라이언트의 상태 정보를 유지하며, 이 정보를 기반으로 통신이 진행된다. 즉, 서버는 클라이언트의 이전 행동을 기억하고, 그 상태 정보를 이용해 서비스를 제공한다.
- 상태 정보 유지: 상태 프로토콜에서는 클라이언트의 연결 상태를 계속해서 추적하며, 요청 간에 발생한 변화를 기반으로 추가 작업을 수행할 수 있다.
- 자원 사용: 서버는 클라이언트의 상태를 유지하기 위해 추가적인 자원(메모리, 데이터베이스 연결 등)을 사용해야 한다.
- 응답성: 상태 정보를 바탕으로 더 정확하거나 개인화된 응답을 제공할 수 있으며, 사용자 경험을 향상시킬 수 있다.
예시
- 무상태 프로토콜: HTTP는 대표적인 무상태 프로토콜로, 서버는 클라이언트의 이전 웹 페이지 요청을 기억하지 않는다.
- 상태 프로토콜: FTP(File Transfer Protocol)은 클라이언트와 서버 간의 연결 상태를 유지하면서 파일 전송 상태를 관리하는 상태 프로토콜의 예이다.
HTTP의 비연결성(connectionless)은 이 프로토콜이 클라이언트와 서버 간의 통신을 단기적으로만 유지하는 특성을 말한다. 즉, 클라이언트가 서버에 요청을 보내고 서버가 그 요청에 응답하면, 그 즉시 연결이 종료된다. 이러한 특성은 웹 통신에서 중요한 역할을 하며, 여러 가지 장단점이 있다.
비연결성의 주요 특징
- 연결 속도와 자원: 각 요청이 처리된 후 연결을 바로 끊기 때문에, 서버는 연결을 유지하기 위해 자원을 계속 소비할 필요가 없다. 이는 서버가 동시에 많은 클라이언트의 요청을 처리할 수 있게 해주어 효율성을 높인다.
- 서버 부하 감소: 연결을 유지할 필요가 없기 때문에, 서버의 부하가 줄어들고, 이는 더 많은 클라이언트의 요청을 처리할 수 있도록 한다.
- 단순성: 서버는 각 요청을 개별적으로 처리하며, 이전 요청과의 연결 상태를 관리할 필요가 없다. 이로 인해 프로토콜의 구현이 간단해지고, 오류의 가능성이 줄어든다.
비연결성의 단점
- 재연결 비용: 클라이언트가 같은 서버에 여러 요청을 보낼 경우, 매번 새로운 연결을 설정해야 하므로, 이로 인한 지연 시간이 발생할 수 있다.
- 성능 문제: 일부 애플리케이션에서는 서버와 지속적인 연결을 유지하는 것이 더 효율적일 수 있다. 예를 들어, 실시간 통신이 필요한 애플리케이션에서는 비연결성 프로토콜이 성능 저하를 초래할 수 있다.
HTTP/1.1과 비연결성
HTTP/1.1에서는 비연결성의 단점을 완화하기 위해 지속 연결(persistent connections)이 도입되었다. 이는 클라이언트와 서버 간에 연결을 한 번 설정한 후 여러 요청과 응답을 주고받을 수 있게 해준다. 하지만 기본적으로 각 요청은 여전히 독립적으로 처리되며, 연결은 설정된 시간이 지나거나 명시적으로 종료되지 않는 한 유지된다.
비연결성은 웹 서버의 확장성을 크게 향상시키는 중요한 특성이지만, 애플리케이션의 요구에 따라 적절한 프로토콜을 선택하는 것이 중요하다.
HTTP 지속 연결(persistent connection)은 클라이언트와 서버 간에 설정된 연결을 여러 HTTP 요청과 응답에 걸쳐 유지하는 기능을 말한다. 이는 HTTP/1.1 프로토콜에서 표준으로 도입되었으며, 연결의 재설정 비용과 시간을 줄여 성능을 향상시키는 데 도움을 준다.
지속 연결의 주요 특징
- 연결의 재사용: 한 번의 TCP 연결을 통해 여러 HTTP 요청과 응답을 처리할 수 있다. 이는 연결 설정에 드는 시간과 자원을 절약할 수 있게 해주며, 네트워크 지연을 감소시킨다.
- 파이프라이닝: HTTP/1.1의 지속 연결에서는 파이프라이닝을 사용할 수 있다. 파이프라이닝을 통해 클라이언트는 여러 요청을 한 번에 보내고, 서버는 받은 순서대로 요청을 처리한 후 응답을 보낼 수 있다. 이 기법은 네트워크 대기 시간을 최소화하고 통신 효율을 높인다.
- 헤더 최적화: 지속 연결을 사용하면 클라이언트와 서버는 연결 초기에만 일부 설정을 교환하고, 이후 요청에서는 불필요한 헤더를 생략할 수 있다. 이는 전송 데이터의 크기를 줄여 추가적인 성능 향상을 가능하게 한다.
지속 연결의 설정과 종료
- 설정: 클라이언트는 HTTP 요청 헤더에 Connection: keep-alive를 포함시켜 서버에 지속 연결을 요청한다. 서버 역시 이를 지원하는 경우, 응답 헤더에 동일한 값을 포함시켜 지속 연결을 확립한다.
- 종료: 지속 연결을 종료하려면 클라이언트나 서버 중 하나가 Connection: close 헤더를 요청이나 응답에 포함시켜 연결 종료 의사를 명시해야 한다. 이후 해당 연결은 모든 대기 중인 요청이 처리되면 종료된다.
HTTP 지속 연결은 특히 웹 페이지가 다수의 리소스를 로드해야 하는 상황에서 유용하다. 여러 개의 이미지, 스크립트, 스타일 시트 등을 요청할 때 매번 새로운 연결을 설정하지 않고, 하나의 연결을 통해 이들을 빠르게 로드할 수 있기 때문이다.
HTTP 메시지는 클라이언트와 서버 간의 데이터 교환을 위해 사용되는 포맷으로, 크게 요청 메시지와 응답 메시지 두 가지 유형이 있다. 이 메시지들은 시작 줄, 헤더, 그리고 본문으로 구성되어 있다. 각 부분은 HTTP 통신의 특정 정보를 담당하며, 이 구조는 웹 통신의 효율성과 명확성을 보장한다.
1. 요청 메시지 구조
요청 메시지는 클라이언트가 서버에게 어떤 작업을 수행하도록 요청할 때 사용된다.
- 시작 줄(Start Line): 이 줄에는 요청을 수행하는데 사용되는 메소드(GET, POST 등), 요청 대상의 URI, 그리고 HTTP 버전이 포함된다.
- 헤더(Headers): 요청에 대한 추가적인 정보를 제공하는 여러 헤더가 포함된다. 예를 들어, User-Agent 헤더는 요청을 보내는 클라이언트의 정보를 제공하고, Accept 헤더는 클라이언트가 처리할 수 있는 컨텐츠 유형을 명시한다.
- 빈 줄(Empty Line): 헤더와 본문 사이에는 빈 줄이 있어 헤더의 끝과 본문의 시작을 구분한다.
- 본문(Body): (선택적) 본문은 데이터를 포함하며, 주로 POST나 PUT 요청에서 서버로 보내지는 데이터를 담는다.
2. 응답 메시지 구조
응답 메시지는 서버가 클라이언트의 요청에 대해 어떻게 처리했는지를 알려줄 때 사용된다.
- 시작 줄(Start Line): 이 줄에는 사용된 HTTP 버전, 상태 코드(예: 200 OK, 404 Not Found), 그리고 상태 코드의 짧은 설명이 포함된다.
- 헤더(Headers): 응답에 대한 추가적인 정보를 제공하는 헤더들이 포함된다. 예를 들어, Content-Type 헤더는 응답 본문의 미디어 유형을 명시하고, Content-Length는 본문의 길이를 바이트 단위로 제공한다.
- 빈 줄(Empty Line): 이 또한 헤더와 본문을 구분한다.
- 본문(Body): (선택적) 응답의 실제 데이터를 포함하며, 요청된 리소스의 내용이나, 요청 처리에 대한 추가 정보를 포함할 수 있다.
'CS' 카테고리의 다른 글
[HTTP | HTTP 웹 기본지식 | HTTP 메서드 활용] HTTP API 설계 예시 (0) | 2024.05.22 |
---|---|
[HTTP | HTTP 웹 기본지식 | HTTP 메서드] HTTP 메서드 (0) | 2024.05.21 |
[HTTP | HTTP 웹 기본지식 | URI와 웹 브라우저 요청 흐름]URI (0) | 2024.05.21 |
[HTTP | HTTP 웹 기본지식 | 인터넷 네트워크] TCP, UDP (0) | 2024.05.21 |
[HTTP | HTTP 웹 기본지식 | 인터넷 네트워크] IP, PORT, DNS (0) | 2024.05.09 |