처음부터 시작하는 개발자

[CS] HTTP의 개념 본문

CS

[CS] HTTP의 개념

hwcho0456 2023. 12. 10. 14:52

HTTP(Hypertext Transfer Protocol)

OSI 7계층 중 Application layer 에서 사용되는 프로토콜로, 주로 TCP/IP로 구성된 인터넷 망의 월드와이드웹(WWW)의 정보를 주고받는데 사용하는 프로토콜이다. 웹 브라우저는 HTTP 프로토콜을 이해하고 해석하는 소프트웨어이다. 사용자가 웹 브라우저를 통해 웹 사이트에 접속하려고 요청하면, HTTP 프로토콜을 이용해 해당 웹 사이트의 서버와 통신하고, 가져온 결과는 사용자가 이해할 수 있는 형태로 웹 페이지에 표시된다.

HTTP의 특성

1. 무상태성 (Stateless) - 서버는 클라이언트의 상태를 저장하지 않는다. 서버는 이전에 클라이언트가 무엇을 요청했는지, 어떤 동작을 수행했는지를 모르므로 이를 구분하여 응답할 수 없다. 곧, 동일한 요청에는 항상 동일한 응답이 반환된다. 

=> 각각의 요청을 독립적(병렬적)으로 처리할 수 있고, 클라이언트 상태 저장을 위한 추가적인 노력이 필요하지 않으므로 효율적이다.

# 순수함수(Pure function)의 조건
# 항상 동일한 요청(입력)에 대해 동일한 응답(출력)을 반환
# 함수 외부에 영향을 미치는 부수 효과(Side Effect)가 없다.
# 곧, HTTP 응답함수는 순수함수이다.
def handle_request(request):
    # ... response 처리 ...
    return response

 

* 무상태성을 극복하기 위한 방안 - 유저가 로그인 등을 수행한 경우, 서버는 로그인 상태를 인지하여 응답을 다르게 해주어야 한다. 이 경우, 클라이언트에 저장하는 쿠키(Cookie)나 서버에 저장하는 세션(Session) 등을 HTTP 헤더에 담아 요청한다. HTTP의 무상태성을 유지하면서도 필요한 상황에서는 클라이언트의 상태를 기억하고 처리할 수 있게 된다.

 

2. 비연결성 (Connectionless) - 서버는 클라이언트와 요청을 처리한 후 네트워크 연결을 즉시 종료한다. 곧, 서로의 연결상태를 확인하는 HandShake 및 한 번의 요청-응답이 완료되면 기본적으로 서버와 클라이언트 간의 연결이 끊어진다. 이러한 비연결성은 서버가 효율적으로 많은 수의 클라이언트와 통신할 수 있게 해준다.

 

* 비연결성을 극복하기 위한 방안 - 요즘의 웹페이지들은 단순히 HTML 파일 뿐만 아니라 CSS, JS 등의 추가적인 파일들도 필요하고 이들을 연속적인 HTTP 통신을 이용해 순차적으로 받아와야 한다. 하지만 매 파일을 주고 받을 때마다 통신을 끊는다면 다시 통신을 연결하기 위한 수고로움이 있으므로, 클라이언트에서 HTTP 헤더의 keep-alive 옵션을 이용하여 필요 시 통신을 끊지 않도록 서버에 요청할 수 있다.

서로의 상태를 확인하는 HandShake 이후 본격적인 HTTP 통신이 이루어진다. keep-alive 옵션을 통해 불필요한 HandShake를 줄일 수 있다.

 

참고 - TCP에서의 연결 생성과 해제

TCP에서의 연결 생성은 3-handshake, 연결 해제는 4-handshake로 이루어진다.

TCP 연결 생성
TCP 연결 해제

* HTTPS

HTTP는 데이터 전송이 평문 형태로 이루어지기 때문에, 만약 데이터가 탈취당하게 되면 해당 내용이 탈취자에게 쉽게 노출될 수 있다. 이러한 보안 문제를 해결하기 위해 TLS 암호화 기술을 활용하여 데이터를 암호화하여 전송하는 프로토콜이 HTTPS이다. 이를 통해 데이터의 안전한 전송을 보장하고, 탈취당한 데이터라 하더라도 그 내용을 파악하는 것을 어렵게 만든다.

HTTP의 역사

 

HTTP/0.9 (1991) - 최초의 HTTP 버전으로, 간단한 HTML 문서를 교환하기 위한 프로토콜로 사용되었다. 이 버전에서는 GET 메서드만 지원되었으며, 헤더, 상태 코드 등의 개념은 없었다.

 

HTTP/1.0 (1996) - POST, HEAD 메서드와 무상태성을 극복하기 위한 HTTP 헤더를 도입했다. 이를 통해 메타데이터를 전송하고, 캐싱, 연결 관리 등의 기능이 가능해졌다.

 

HTTP/1.1 (1997) - HTTP의 표준. 비연결성을 극복하기 위한 keep-alive 도입, 캐싱 개선, 콘텐츠 인코딩 지원 등 많은 향상을 이루었음. 이 버전에서 PUT, DELETE 등의 추가 메서드가 도입되어 현재의 HTTP의 메소드들이 정립.

 

HTTP/2.0 (2015) - HTTP/2.0은 HTTP/1.1의 대체가 아닌 성능 향상을 목표로 개발. (따라서 여전히 표준은 HTTP/1.1이다.) 단일 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있는 다중화(Multiplexing), 서버 푸시, 헤더 압축 등의 기능을 도입하였다.

 

HTTP/3.0 (2021) - HTTP/3.0은 새로운 전송 프로토콜인 QUIC을 도입하여 더 나은 성능과 효율성을 제공한다. QUIC은 TCP 대신 UDP를 기반으로 하여 다중 스트림을 사용, 통신 연결의 핸드셰이크 과정을 최소화하여 네트워크 지연을 줄이고, 각 스트림이 독립적이므로 하나의 연결이 실패해도 다른 연결에 영향을 주지 않는다.

HTTP/2와 HTTP/3의 통신비교

HTTP Request와 Response의 구조

1. HTTP Request

 

1) 시작줄(Request Line): HTTP 메서드, 요청 대상의 URL, 그리고 HTTP 버전을 포함한다.

GET /index.html HTTP/1.1

 

2) 헤더(Header): 요청에 대한 추가 정보를 포함하는 여러 행으로 구성되고, 각 헤더 필드는 이름과 값의 쌍으로 이루어져 있다.

User-Agent: Mozilla/5.0

 

3) 본문(Body): 실제로 서버에 전달하고자 하는 데이터를 담고 있다. GET 요청과 같이 별도의 데이터를 전송하지 않는 요청에서는 이 부분이 비어 있을 수 있다.

# HTTP Request example (각 개행은 \r\n을 사용한다.)
POST /signup HTTP/1.1\r # RequestLine
Host: www.example.com\r # Header
User-Agent: Mozilla/5.0\r
Content-Type: application/x-www-form-urlencoded\r
Content-Length: 27\r
\r # 빈 개행으로 header와 body를 구분한다.
username=test&email=test@example.com # Body

 

2. HTTP Response

 

1) 상태줄(Status Line): HTTP 버전, 상태 코드, 그리고 상태 메시지를 포함한다.

HTTP/1.1 200 OK

 

2) 헤더(Header): 응답에 대한 추가 정보를 포함하는 여러 행으로 구성되고, 각 헤더 필드는 이름과 값의 쌍으로 이루어져 있다.

Content-Type: text/html

 

3) 본문(Body): 실제로 클라이언트에게 전달하고자 하는 데이터를 담고 있다. 요청에 따라 이 부분이 비어 있을 수 있다.

# HTTP Response example (각 개행은 \r\n을 사용한다.)
HTTP/1.1 200 OK\r # Status Line
Date: Sat, 10 Dec 2023 16:43:58 GMT\r\n # Header
Server: Apache/2.2.14 (Win32)\r
Content-Length: 230\r
Content-Type: text/html\r
\r # 빈 개행으로 header와 body를 구분한다.
<html>\r # Body - 여기서는 HTML 파일을 전달받았다.
<head>\r
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">\r
<title>Welcome to www.example.com!</title>\r
</head>\r
<body>\r
Welcome to www.example.com!\r
Your account has been successfully created.\r
</body>\r
</html>

HTTP의 메소드

종류 목적 안정성  멱등성 캐싱가능
GET 특정 리소스의 표시를 요청 O O O
HEAD 응답 본문을 포함하지 않는 GET O O O
POST 특정 리소스에 객체를 제출할 때 X X X
PUT 소스 모든 현재 표시를 요청 페이로드로 바꿀 때 X O X
DELETE 특정 리소스를 삭제할 때 X O X
CONNECT 소스로 식별되는 서버로의 터널을 맺을 때 X X X
OPTIONS 목적 리소스의 통신을 설정할 때 O O X
TRACE 리소스의 경로를 따라 메시지 루프백 테스트할 때 O O X
PATCH 리소스의 부분만을 수정할 때 X X X

 

* 안정성 - 특정 메소드가 서버의 상태를 변화시키는지의 여부에 대한 것이다. GET 메소드의 경우 단순히 서버의 리소스를 표시하는 것이기 때문에 안전하다. POST의 경우 특정 리소스에 대해 객체가 생성되기 때문에 안전하지 않다.

 

* 멱등성 - 특정 HTTP 메소드는 규칙상 멱등성을 요구한다. 멱등성은 해당 메소드를 여러번 요청한 것이 한번 요청한 것과 같은 효과를 가져야 하는 것을 말한다. DELETE 메소드의 경우 객체가 이미 삭제되어 존재하지 않더라도 삭제가 이루어진 거서처럼 응답해주어야 한다.

# DELETE METHOD 처리예제
def handle_delete(request):
    if Objecct is None:
        return response
    # ... 객체 삭제 ...
    return response

HTTP의 상태코드

번호 내용
2XX 성공적인 응답. 요청이 성공적으로 이해되었고, 수락되었으며, 처리되었음을 의미.
3XX 리다이렉션. 이는 클라이언트로 하여금 추가적인 요청을 필요로 하는 상황. 
4XX 클라이언트 에러. 요청 자체에 문제가 있어 처리할 수 없을 때 
5XX 서버 에러. 서버가 요청을 올바르게 받았지만, 내부적인 문제로 인해 요청을 처리하지 못했을 때
저작자표시

'CS' 카테고리의 다른 글

[CS] AI를 위한 수학  (0) 2023.12.02
SQL for Data Analysis Cheat Sheet  (0) 2023.11.17
[CS] Apache Tomcat 개요  (0) 2023.11.09
[CS] Transformer 개요  (0) 2023.11.05
[CS] 객체지향 프로그래밍  (0) 2023.10.15
'CS' Related Articles more