HTTP(Hypertext Transfer Protocol)란?
웹에서 데이터를 주고받기 위한 서버-클라이언트의 프로토콜
HTTP의 특징
1. 상태가 없는(Stateless) 프로토콜
서버는 클라이언트의 상태나 정보를 따로 저장하지 않고, 각 요청(Request)을 독립적으로 처리한다.
2. TCP/IP 프로토콜을 기반으로 동작
http://로 시작하는 주소를 요청하면, 80번 포트로 접속한다.
3. 보안에 취약
HTTP는 평문을 전송하기 때문에, 통신 내용을 탈취할 수 있어 보안에 취약하다.
이를 보안하기 위해 HTTPS가 등장했다.
HTTPS
: HTTP에 SSL(Secure Socket Layer)/TLS(Transport Layer Security) 암호화 프로토콜을 적용
HTTP 통신 프로세스
1. 브라우저에 URL을 입력한 후, DNS 서버에서 IP주소를 조회
2. TCP 3-way handshake 과정을 통해 연결
3. 클라이언트의 HTTP 요청 메시지 전송
4. 서버의 HTTP 응답 메시지 수신
5. 클라이언트는 수신한 응답을 화면에 렌더링
6. 데이터 전송이 종료되면 TCP 연결을 끊거나 재사용(keep-alive)
※ DNS: 도메인 이름을 해당 웹 서버의 IP 주소로 변환해 주는 시스템
※ TCP 3-way handshake: SYN → SYN-ACK → ACK 순서로 패킷을 송수신하여 클라이언트와 서버가 통신할 준비가 되었는지 확인하는 과정.
HTTP 메시지 형식
HTTP 요청(Request) 헤더
GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
첫 번째 줄: GET 방식 요청, path: /index.html, HTTP 버전 명시
두 번째 줄: 요청을 보내는 도메인 이름
세 번째 줄: 서버에 전달할 클라이언트 정보
HTTP 응답(Response) 헤더
HTTP/1.1 200 OK
Date: Sat, 09 Oct 2023 14:28:02 GMT
Server: Apache
Content-Type: text/html
<html>
...
</html>
첫 번째 줄: HTTP 버전, 상태 코드, 상태 메시지
두 번째 줄: 응답이 생성된 날짜/시간
세 번째 줄: 서버의 소프트웨어 정보
네 번째 줄: body의 데이터 형식(예시는 HTML)
빈 줄: 헤더와 본문 구분하는 줄
html: 클라이언트가 요청한 데이터(이미지, JSON 객체 등이 담길 수 있음)
HTTP 요청 메소드
| 메소드 | 설명 |
| GET | 서버에서 리소스를 조회할 때 사용 |
| POST | 서버에 데이터를 생성하거나, 서버가 데이터를 처리하도록 요청할 때 사용 |
| PUT | 서버의 기존 리소스를 전체 수정하거나 없으면 새로 생성 |
| PATCH | 서버의 기존 리소스를 일부 수정할 때 사용 |
| DELETE | 서버의 리소스를 삭제할 때 사용 |
| HEAD | GET와 유사하지만, Body 없이 Header만 반환 |
| OPTIONS | 서버가 지원하는 리소스 목록 또는 리소스의 가능한 통신 옵션을 확인할 때 사용 |
| CONNECT | - 프록시 서버와 터널 연결을 할 때 사용 - 주로 HTTPS와 같은 암호화된 연결에 사용 |
| TRACE | 클라이언트에서 서버까지의 경로를 테스트할 때 사용 |
HTTP 버전
HTTP/1.0
- 초기 버전인 HTTP/0.9와 다르게 헤더가 도입되었으며,
다양한 형식(이미지, 텍스트 등)의 파일을 응답으로 받을 수 있다. (Content-Type)
- 클라이언트가 요청을 할 때마다 TCP 연결을 해야 한다.
따라서 매번 TCP 3-way handshake가 발생하여 RTT(Round Trip Time, 패킷 왕복 시간)가 반복적으로 소모되었고, 이는 서버에 부담이 커지는 단점으로 이어졌다.
HTTP/1.1
- 1.0 버전의 단점을 상쇄하는 1.1 버전의 대표적인 특징은 지속적 연결이다.
기존 1.0 버전에서 연결을 지속하기 위해서는 헤더에 keep-alive 속성을 명시적으로 추가해야 했다.
하지만 1.1은 keep-alive가 기본적으로 지원되어, 한 번의 연결로 여러 요청과 응답을 처리할 수 있다.
- 파이프라이닝 기능을 통해 여러 요청을 연속적으로 보내고 응답을 순차적으로 받을 수 있다.
이때, 클라이언트는 각 응답의 끝이 어디인지 알아야 다음 응답을 받을 수 있다.
따라서
1. Content-Length를 명시해서 응답 본문의 길이로 응답의 끝을 파악하거나
2. Chunked Transfer Encoding으로 데이터를 청크 단위로 나누어 마지막 청크로 응답의 끝을 파악해야 한다.
이는 응답 효율성을 높여준다.
HTTP/2
- 1.x 버전보다 성능을 향상시키기 위해 설계된 프로토콜
- 이진 프레임(Binary Frame) 형식을 채택하여 파싱 및 전송 속도를 높였다.
- Multiplexing을 통해 여러 요청과 응답(스트림)을 순서와 관계없이 주고받을 수 있다.
각 스트림은 고유 식별자로 구분되며, 스트림에 우선순위를 할당하여 중요한 데이터를 먼저 처리할 수 있다.
- Header Compression(HPACK)
: 같은 내용이 담긴 헤더에 대해 중복으로 전송하지 않고, 인덱스만 전송하는 방식 등으로 오버헤드를 감소시킨다.
- Server Push
: 서버가 클라이언트의 요청을 기다리지 않고, 웹에 필요한 리소스를 미리 클라이언트에 전송한다.
HTTP/3
- TCP 대신 QUIC 기반으로 동작한다.
※ QUIC
- UDP(User Datagram Protocol)를 기반으로 한 전송 계층 프로토콜
- Header Compression 또한 HPACK이 아닌 QPACK을 사용
- 여러 스트림을 실행하고 각 스트림의 패킷 손실을 독립적으로 감지하고 재전송
:)
출처
https://bruders.tistory.com/143
https://docs.tosspayments.com/resources/glossary/http-protocol
https://velog.io/@ajm0718/HTTP%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80
'Computer Science > 네트워크' 카테고리의 다른 글
| [Network] CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유) (0) | 2025.08.10 |
|---|---|
| [Network] REST / REST API / RESTful 이란? (1) | 2025.07.18 |
| [Network] HTTPS(HyperText Transfer Protocol Secure) (0) | 2025.06.15 |
| [Network] OSI 7계층, TCP/IP 4계층 (1) | 2025.06.09 |
| [Network] 로드밸런싱(Load Balancing) (0) | 2025.05.30 |