HTTP 란?
HTTP(Hypertext Transfer Protocol)는 웹에서 데이터를 주고받기 위한 프로토콜입니다.
클라이언트(보통 웹 브라우저)와 서버 간의 통신을 정의하며, 웹 페이지와 리소스를 전송하는 데 사용됩니다.
HTTP 특징
1. 무상태성(Stateless):
HTTP는 상태를 유지하지 않는 프로토콜입니다. 클라이언트와 서버가 서로 통신할 때, 각 요청과 응답은 독립적으로 처리되며 이전 요청의 상태를 기억하지 않습니다. 예를 들어, 클라이언트가 서버에 페이지를 요청한 후, 서버는 이 요청을 처리하고 응답을 보낸 뒤 그 요청과 관련된 상태를 잊어버립니다. 따라서 서버는 클라이언트가 누구인지 식별하지 못합니다. 클라이언트가 누구인지 식별 해야하는 경우 상태유지기술인 쿠키와 세션을 사용합니다.
2. 요청-응답 모델:
HTTP는 클라이언트가 요청(request)을 보내면 서버가 이에 대한 응답(response)을 반환하는 구조입니다. 요청은 메서드, URL, 헤더, 바디 등의 요소로 구성되며, 응답도 상태 코드, 헤더, 바디 등으로 이루어집니다.
- HTTP Request Massage
- HTTP Response Massage
3. HTTP 메서드:
GET: 서버에서 데이터를 가져옵니다. 서버에게 데이터 전송을 요청하며, 주로 웹 페이지를 요청할 때 사용됩니다.
POST: 클라이언트에서 서버로 데이터를 전송합니다. 주로 폼 데이터를 전송할 때 사용됩니다.
PUT: 클라이언트에서 서버로 데이터 전체 갱신 요청하며, 서버에 자원을 생성하거나 업데이트합니다.
DELETE: 서버에서 데이터를 삭제합니다.
HEAD: GET과 유사하지만 응답에 바디가 포함되지 않으며, 헤더만을 받습니다.
PATCH: 클라이언트에서 서버로 데이터 일부 갱신을 요청합니다.
4. HTTP 상태 코드:
서버가 요청을 처리한 결과를 나타내는 3자리 숫자입니다.
2xx (성공): 요청이 성공적으로 처리되었음을 나타냅니다. (예: 200 OK)
3xx (리다이렉션): 요청된 자원이 다른 위치로 이동되었음을 나타냅니다. (예: 301 Moved Permanently)
4xx (클라이언트 오류): 클라이언트의 잘못된 요청으로 인해 오류가 발생했음을 나타냅니다. (예: 404 Not Found, 400 Bad Request)
5xx (서버 오류): 서버에서 요청을 처리하는 중에 오류가 발생했음을 나타냅니다. (예: 500 Internal Server Error, 505 HTTP Version Not Supported)
5. HTTP/2와 HTTP/3:
HTTP/1.1 이후, 더 빠르고 효율적인 통신을 위해 HTTP/2와 HTTP/3가 도입되었습니다.
HTTP/2: 멀티플렉싱, 헤더 압축, 서버 푸시 등의 기능을 통해 성능을 개선했습니다.
HTTP/3: UDP 기반의 새로운 전송 계층 프로토콜인 QUIC을 사용하여 더욱 빠른 연결 수립과 데이터 전송을 제공합니다.
HTTP 활용 예시
- 웹 브라우징:
사용자가 브라우저에서 URL을 입력하면, 브라우저는 해당 서버에 GET 요청을 보내고, 서버는 요청한 웹 페이지의 HTML 데이터를 응답으로 보냅니다. - API 호출:
클라이언트가 서버의 API에 데이터를 제출할 때, POST 요청을 사용하여 데이터를 전송합니다.
HTTP 헤더
HTTP 헤더는 HTTP 요청(Request) 또는 응답(Response) 메시지의 시작 부분에 위치하는 메타데이터입니다.
헤더는 클라이언트와 서버 간에 주고받는 데이터를 설명하거나 추가 정보를 전달하는 역할을 합니다.
헤더는 키-값 쌍의 형태로 이루어져 있으며, 요청 및 응답의 동작을 제어하거나 데이터에 대한 추가 정보를 제공합니다.
HTTP 헤더의 주요 역할
- 요청의 세부 정보 제공:
클라이언트가 서버에 요청을 보낼 때, 요청하는 리소스의 타입, 요청의 의도 등을 헤더를 통해 전달할 수 있습니다. - 응답의 세부 정보 제공:
서버가 클라이언트에 응답을 보낼 때, 응답의 상태, 데이터의 타입 등을 헤더를 통해 전달할 수 있습니다. - 보안 및 인증:
인증 정보, 쿠키 등을 헤더에 포함시켜 보안성을 제공합니다.
HTTP 헤더 예시
1. Host
- 설명:
요청을 보내는 대상 서버의 호스트명과 포트를 명시합니다. - 예시:
Host: www.example.com- 용도:
하나의 서버에서 여러 개의 도메인을 운영할 때, 어떤 도메인에 대한 요청인지를 명확히 하기 위해 사용됩니다.
2. Content-Type
- 설명:
요청 또는 응답의 본문에 포함된 데이터의 MIME 타입을 명시합니다. - 예시:
Content-Type: application/json- 용도:
서버나 클라이언트가 전달하는 데이터의 형식을 알려줍니다. 예를 들어, JSON, HTML, XML, Plain Text 등이 있습니다.
3. User-Agent
- 설명:
요청을 보내는 클라이언트의 소프트웨어 정보를 포함합니다. - 예시:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36- 용도:
서버가 클라이언트의 유형이나 브라우저 정보를 확인하여 맞춤형 응답을 제공하는 데 사용됩니다.
4. Authorization
- 설명:
클라이언트가 서버에 인증 정보를 제공하는 데 사용됩니다. - 예시:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l- 용도:
기본 인증, 토큰 인증 등의 방식을 사용해 보호된 리소스에 접근할 때 사용됩니다.
5. Cookie
- 설명:
클라이언트 측에서 서버로 전송하는 쿠키 데이터를 포함합니다. - 예시:
Cookie: sessionId=abc123;- 용도:
서버가 클라이언트의 상태를 기억하도록 하는 데 사용됩니다. 예를 들어, 사용자의 로그인 상태나 쇼핑 카트의 정보가 쿠키에 저장될 수 있습니다.
6. Accept
- 설명:
클라이언트가 서버로부터 받을 수 있는 콘텐츠 타입을 지정합니다. - 예시:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8- 용도:
클라이언트가 선호하는 콘텐츠 타입을 명시하여 서버가 적절한 형식으로 응답을 제공하도록 유도합니다.
7. Cache-Control
- 설명:
클라이언트와 서버 간의 캐싱 동작을 제어하는 데 사용됩니다. - 예시:
Cache-Control: no-cache- 용도:
데이터가 캐시되지 않도록 하거나, 캐시가 얼마나 오래 유지될지 등을 지정할 수 있습니다.
8. Location
- 설명:
서버가 클라이언트에 리다이렉션할 URL을 명시합니다. - 예시:
Location: https://www.example.com/new-page- 용도:
3xx 리다이렉션 응답에서 사용되며, 클라이언트를 다른 URL로 이동시키는 데 사용됩니다.
HTTP Keep-Alive
HTTP Keep-Alive는 HTTP 연결을 지속적으로 유지하여, 여러 요청과 응답을 동일한 TCP 연결에서 처리할 수 있도록 하는 기능입니다.
이 기능은 네트워크 성능을 향상시키고, 서버 및 클라이언트 간의 통신 효율성을 높이는 데 중요한 역할을 합니다.
HTTP Keep-Alive는 특히 HTTP/1.0 및 HTTP/1.1에서 중요한 역할을 하며, 오늘날 많은 웹 애플리케이션에서 기본적으로 사용되는 기능입니다.
HTTP/2와 같은 최신 프로토콜에서는 멀티플렉싱 등을 통해 이와 같은 기능을 더욱 효율적으로 처리하고 있습니다.
Keep-Alive의 필요성
HTTP/1.0에서는 기본적으로 하나의 요청-응답 사이클이 끝나면 TCP 연결이 종료되었습니다. 이는 새로운 요청을 보낼 때마다 새로운 연결을 열어야 함을 의미하며, 이 과정에서 추가적인 시간이 소요되었습니다. TCP 연결을 설정하고 해제하는 데 드는 시간이 커지면, 특히 여러 개의 리소스를 요청하는 웹 페이지에서 성능 저하가 발생할 수 있습니다.
Keep-Alive는 이러한 문제를 해결하기 위해 도입되었습니다. 이 기능을 사용하면 클라이언트가 여러 개의 요청을 동일한 TCP 연결을 통해 서버에 보낼 수 있으므로, 연결 설정에 따른 오버헤드를 줄일 수 있습니다.
Keep-Alive 장단점
Keep-Alive 장점
- 성능 향상:
새로운 TCP 연결을 설정하는 시간을 줄임으로써 웹 페이지 로딩 속도를 개선할 수 있습니다. - 네트워크 효율성:
동일한 연결을 재사용하기 때문에 네트워크 트래픽을 줄이고, 연결 설정/해제에 따른 오버헤드를 감소시킵니다. - 서버 부하 감소:
적은 수의 연결로 많은 요청을 처리할 수 있어 서버 리소스 사용을 최적화할 수 있습니다.
Keep-Alive의 단점
- 자원 점유:
연결을 장시간 유지하면 서버의 메모리 및 연결 슬롯을 지속적으로 사용하게 되어 자원이 낭비될 수 있습니다. 특히 클라이언트가 많을 경우 문제가 될 수 있습니다. - TCP 연결의 고갈:
장시간 연결이 유지되면 새로운 연결을 할당할 수 있는 자원이 고갈될 수 있습니다. 이는 서버의 성능 저하를 초래할 수 있습니다.
HTTP 파이프라이닝
HTTP 파이프라이닝(HTTP Pipelining)은 클라이언트가 서버에 여러 HTTP 요청을 동시에 보낼 수 있는 기술로, 각 요청에 대한 응답을 기다리지 않고 연속적으로 요청을 전송하는 방식입니다.
이 방법은 네트워크 대역폭을 더 효율적으로 사용하고, 웹 페이지 로딩 속도를 향상시키기 위해 설계되었습니다.
HTTP 파이프라이닝은 HTTP/1.1에서 클라이언트와 서버 간의 통신 효율을 높이기 위해 도입된 기술입니다.
그러나 여러 문제와 제한 사항으로 인해 널리 사용되지 않았고, 대부분의 경우 HTTP/2의 멀티플렉싱으로 대체되었습니다.
HTTP/2는 이 기술을 개선하여 보다 빠르고 안정적인 웹 통신을 제공하고 있습니다.
HTTP 파이프라이닝 장단점
HTTP 파이프라이닝의 장점
- 성능 향상:
응답을 기다리지 않고 여러 요청을 동시에 보낼 수 있어 전체 응답 시간을 줄입니다. - 네트워크 효율성:
여러 개의 요청과 응답을 단일 연결에서 처리하기 때문에, TCP 연결 설정 및 해제에 따른 오버헤드를 줄일 수 있습니다. - 리소스 로딩 속도 향상:
특히 웹 페이지를 로드할 때, 여러 리소스를 빠르게 가져와서 렌더링 시간을 단축할 수 있습니다.
HTTP 파이프라이닝의 단점
- 서버 지원 부족:
HTTP 파이프라이닝은 HTTP/1.1에서 도입되었으나, 많은 서버와 프록시가 이 기능을 제대로 지원하지 않았습니다. 이로 인해 클라이언트가 파이프라이닝 요청을 보냈을 때, 서버에서 예상치 못한 동작을 할 수 있습니다. - 헤드 오브 라인 블로킹(Head-of-line Blocking):
파이프라이닝에서 요청이 순서대로 처리되므로, 앞선 요청이 오래 걸리면 뒤따르는 모든 요청이 지연됩니다. 이 문제는 파이프라이닝의 성능 이점을 감소시킬 수 있습니다. - 브라우저 지원:
대부분의 현대 웹 브라우저는 HTTP 파이프라이닝을 기본적으로 비활성화하거나, 지원하지 않는 경우가 많습니다. 이는 안정성 문제 때문입니다.
HTTP 파이프라이닝과 HTTP/2의 비교
HTTP 파이프라이닝은 HTTP/1.1에서 성능 개선을 위해 도입되었지만, 한계가 존재합니다. 이를 극복하기 위해 HTTP/2에서는 멀티플렉싱(Multiplexing)이라는 기술을 도입했습니다.
멀티플렉싱: HTTP/2에서는 하나의 TCP 연결에서 여러 요청과 응답을 동시에 주고받을 수 있으며, 요청과 응답이 순서에 구애받지 않고 독립적으로 처리됩니다. 따라서, 파이프라이닝에서 발생하는 헤드 오브 라인 블로킹 문제가 해결됩니다.
참고자료
HTTP 참고영상 : https://www.akamai.com/ko/glossary/what-is-http
HTTP의 요청/응답 모델 : https://www.algoassembly.com/request-response-model-of-http/
