HTTP

HTTP

- 웹 상에서 데이터를 교환하기 위해 사용되는 프로토콜

HTTP(HyperText Transfer Protocol)는 웹 애플리케이션에 사용되는 애플리케이션 계층 프로토콜입니다.
클라이언트(브라우저)가 요청을 보내고 서버(웹 서버)가응답을 보내는 클라이언트/서버 모델에서 작동합니다.

HTTP의 배경
HTTP는 HTML 파일, JPEG와 같은 형식의 이미지 또는 웹 페이지의 일부인 기타 파일 유형이 될 수 있는 웹 개체의 전송을 용이하게 하기 위해 World Wide Web용으로 설계되었습니다.
이러한 각 웹 개체는 URL(Uniform Resource Locator)로 식별됩니다.

HTTP Request and Response

HTTP는 데이터 전송에 TCP(전송 제어 프로토콜)를 사용합니다.
클라이언트는 TCP 연결을 시작하고 서버는 이를 수락합니다. 연결이 설정되면 클라이언트와 서버 간에 HTTP 메시지가 교환됩니다.
각 HTTP 메시지는 클라이언트에서 서버로의 요청 또는 서버에서 클라이언트로의 응답으로 구성됩니다.

요청 메시지는 요청 라인, 헤더 라인 및 본문으로 구성됩니다.
요청 라인에는 HTTP 메서드(GET, POST, HEAD, PUT 등)가 포함되며 헤더 라인은 요청에 대한 추가 세부 정보를 제공합니다. 요청 본문에는 특히 POST 요청의 경우 서버로 전송되는 데이터가 포함됩니다.

서버는 상태 코드(성공의 경우 200, 찾을 수 없는 경우 404 등), 헤더 및 요청된 리소스를 포함하는 메시지 본문으로 응답합니다.

GET vs POST

GET 및 POST는 가장 일반적인 HTTP 메서드 중 두 가지입니다.
GET은 서버에서 데이터를 요청하는 데 사용되는 반면 POST는 서버로 데이터를 보내는 데 사용됩니다.

GET 요청은 이름/값 쌍의 URL에 데이터를 추가하고 문서를 가져오는 데 사용됩니다.
이러한 요청은 캐시될 수 있으며 브라우저 기록에 남아 있습니다.

반면에 POST 요청은 HTTP 요청 본문 내에서 데이터를 제출합니다.
이 방법은 파일을 업로드하거나 양식 데이터를 제출하는 데 사용됩니다.
POST 요청은 매개변수가 브라우저 기록이나 웹 서버 로그에 저장되지 않기 때문에 안전한 데이터 전송 방법을 제공합니다.

Statelessness Of HTTP

HTTP는 상태 비저장 프로토콜입니다.
즉, 서버는 과거 클라이언트 요청에 대한 정보를 저장하지 않습니다.
이 상태 비저장 특성은 각 요청을 독립적으로 처리할 수 있으므로 데이터 교환을 단순화하지만 애플리케이션이 여러 요청에서 상태 정보를 유지 관리해야 하는 경우 쿠키와 같은 추가 조치를 취해야 함을 의미합니다.

Non-Persistent HTTP Vs Persistent HTTP

비영구 HTTP는 각 요청/응답 쌍에 대해 새 TCP 연결을 엽니다.
즉, 웹 페이지가 여러 개체(예: 이미지)로 구성된 경우 각 개체에 별도의 연결이 필요합니다.
이 접근 방식은 서버와 네트워크에 부담을 줄 수 있습니다.

HTTP/1.1에 도입된 영구 HTTP를 사용하면 단일 연결을 통해 여러 개체를 보낼 수 있으므로 연결을 설정하고 닫는 오버헤드가 줄어듭니다.

쿠키 사용

쿠키는 사용자/서버 상태를 유지하는 데 사용됩니다.
사용자가 웹사이트를 처음 방문하면 웹사이트에서 사용자의 고유 ID를 생성하여 사용자 컴퓨터의 쿠키에 저장할 수 있습니다. 이후 방문 시 웹사이트는 쿠키를 읽어 사용자를 식별할 수 있습니다. 쿠키는 일반적으로 인증, 개인화 및 사용자 세션 추적에 사용됩니다.

웹 캐싱

웹 캐싱은 네트워크 트래픽을 줄이고 로드 시간을 개선하는 데 사용됩니다.
클라이언트가 캐시에 저장된 리소스를 요청하면 서버에서 가져오는 대신 캐시에서 직접 제공할 수 있습니다.
이렇게 하면 서버의 로드가 줄어들고 클라이언트의 응답 시간이 줄어듭니다.
웹 캐시는 브라우저에 위치하거나 별도의 프록시 서버로 위치할 수 있습니다.

HTTP 버전

HTTP/2 및 HTTP/3

HTTP/2는 여러 HTTP 요청의 대기 시간을 줄여 성능을 개선하도록 설계되었습니다.
클라이언트가 HTTP 요청의 우선 순위를 지정하고 개체를 프레임으로 나누어 차단을 방지할 수 있습니다.

HTTP/3

HTTP/2는 상당한 개선이 이루어졌지만 여전히 단일 TCP 연결에 의존했습니다.
패킷 손실이 발생하면 손실된 패킷이 데이터 스트림 중 하나에만 영향을 미치더라도 모든 데이터 스트림이 차단(또는 지연)될 수 있었습니다.

HTTP/3은 기본 전송 프로토콜을 TCP에서 QUIC으로 변경합니다.
QUIC(Quick UDP 인터넷 연결)은 UDP(사용자 데이터그램 프로토콜)의 속도와 TCP의 안정성 및 보안을 결합하기 위해 Google에서 개발한 프로토콜입니다.

QUIC의 주요 장점은 한 스트림에서 패킷이 손실되더라도 다른 스트림이 차단되지 않는 다중 동시 스트림이 가능하다는 것입니다.
이는 특히 패킷 손실이 빈번한 환경에서 처리량을 개선하고 지연 시간을 줄여줍니다.
또한 QUIC에는 암호화 기능이 내장되어 있어 이전 버전보다 더 안전합니다.

HTTP를 통한 보안

HTTP 프로토콜 자체는 암호화와 같은 보안 보호 기능을 제공하지 않습니다.
HTTP를 사용하여 전송된 데이터는 데이터 패킷에 액세스할 수 있는 사람이라면 누구나 가로채서 읽을 수 있습니다.

이 문제를 해결하기 위해 HTTPS(HTTP 보안)가 개발되었습니다.
HTTPS는 기본적으로 SSL(보안 소켓 계층) 또는 TLS(전송 계층 보안) 위에 HTTP를 계층화합니다.
이러한 추가 계층은 송수신되는 데이터를 암호화하여 가로채거나 변조되지 않도록 보호합니다.

사용자 이름, 비밀번호, 신용카드 번호와 같은 민감한 데이터를 클라이언트와 서버 간에 전송할 때는 HTTPS를 사용하는 것이 특히 중요합니다.

결론

HTTP는 웹 리소스를 검색하고 제출할 수 있는 월드와이드웹의 기본 프로토콜입니다.
HTTP는 상태가 없고 보안 기능을 제공하지 않지만 쿠키와 같은 메커니즘과 HTTPS와 같은 프로토콜은 상태 관리와 안전한 데이터 전송을 제공합니다.
비영구적 연결에서 QUIC을 사용한 HTTP/3에 이르기까지 HTTP의 진화는 웹 성능과 사용자 경험을 개선하기 위한 지속적인 노력을 보여줍니다.

Reference

• M - 2.2 HTTP- 필기

부족한 점이나 잘못 된 점을 알려주시면 시정하겠습니다 :>