HTTP(HyperText Transfer Protocol)
- 웹에서 클라이언트에서 서버까지 일련의 흐름을 결정하는 프로토콜
- 웹에서 이루어지는 모든 데이터 교환의 기초
TCP/IP 모델
- 인터넷과 관련된 프로토콜들을 모은 것
- HTTP도 TCP/IP 모델 중 Application Layer에 속한다.
TCP/IP Updated 계층

- Application Layer
- 사용자가 네트워크와 상호작용할 수 있는 최상위 계층으로 네트워크 애플리케이션이 실행되는 계층
- 프로토콜을 통해 클라이언트와 서버 간의 데이터 교환을 처리한다.
- Transport Layer
- 애플리케이션 계층에 네트워크로 접속되어 있는 컴퓨터 사이의 데이터 흐름을 제공한다.
- Network Layer
- 네트워크 상 패킷(전송하는 데이터의 최소 단위)의 이동을 다룬다.
- 어떤 경로로 패킷을 보낼지 결정한다.
- Data Link Layer
- 상위 계층에서 받은 데이터를 프레임(frame, 네트워크로 전송하기 위한 최소 전송 단위) 단위로 나눈다.
- Media Access Controller (MAC)를 사용해 프레임을 생성한다.
- Physical Layer
- 실제 데이터 전송을 담당하는 계층
- 데이터를 전기 신호, 빛 신호, 무선 신호 등의 형태로 변환하여 네트워크 매체(케이블, 광섬유, 무선 등)를 통해 전송한다.
- 물리 계층은 네트워크 장치 간에 신호를 주고받는 하드웨어적인 측면을 다룬다.
HTTP 메시지
HTTP request

- 서버가 특정 동작을 취하게끔 만들기 위해 클라이언트에서 전송하는 메시지
HTTP response

HTTP 버전
HTTP/0.9
- 원-라인 프로토콜 : 요청이 단일 라인으로 구성된다.
GET /mypage.html
- 가능한 메서드는
GET이 유일하다.
- 서버에 TCP 연결되면 서버 및 포트가 필요하지 않으므로 전체 URL은 포함되지 않았다.
- 요청하려는 리소스의 경로(/mypage.html)만 보낸다.
- 응답도 파일 내용 자체로 구성되며 HTTP 헤더가 없다
- HTML 파일만 전송될 수 있고 다른 유형의 문서는 전송될 수 없다.
<html>
A very simple HTML page
</html>
HTTP/1.0
- request : 각 요청 안에 버전 정보가 포함되어 전송된다.
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
- response : 상태 코드가 추가되어 브라우저가 요청 성공, 실패를 알 수 있게 되었다.
- HTTP 헤더를 통해 HTML 파일 외에 메타데이터를 전송할 수 있다.
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
HTTP/1.1 - 표준 프로토콜
- 연결을 재사용 할 수 있다.(Persistent Connections, keep-alive)
- TCP 연결을 여러 HTTP 요청과 응답에 재사용할 수 있어서 여러 개의 요청을 보내기 위해 매번 새로운 TCP 연결을 설정할 필요가 없다.
- 기본적으로 Persistent Connections를 지원하여
Connection: close를 명시하지 않으면 요청 후 연결을 유지한다. (1.0은 기본적으로 종료)
- 청크된 응답 지원
- 서버가 응답을 여러 조각으로 나누어 전송하고 클라이언트가 차례로 처리할 수 있도록 함
- 동적 콘텐츠를 전송
- 서버가 전체 응답을 메모리에 저장하지 않고 청크 단위로 데이터를 전송할 수 있다. (메모리 최적화)
- 콘텐츠 협상(Content Negotiation)
- 클라리언트와 서버 간 가장 적합한 콘텐츠를 선택하고 교환할 수 있는 기능 제공
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html, application/xhtml+xml
Accept-Language: en-US, en
Accept-Encoding: gzip, deflate
Host 헤더
- 동일한 IP 주소에 다른 도메인을 호스트할 수 있다.
HTTP/2
- 성능 개선 및 사용자 경험 향상을 위해 설계되었다.
- 이진 프로토콜
- 사람이 읽을 수 없고 수동으로 만들 수 없다.
- 구문 분석과 처리에서 더 효율적이며 파싱이 더 빠르고 오류 가능성이 적다.
- 다중화(Multiplexing)
- HTTP/1.x에서는 각 요청이 순차적으로 처리되어야 했지만 HTTP/2에서는 병렬 처리가 가능하다.
- 데이터를 여러개의 스트림으로 나누어 전송하고 스트림은 독립적으로 처리된다.
- 헤더 압축(Header Compression)
- 요청과 응답의 헤더 정보를 압축해서 데이터 중복과 오버헤드를 줄인다.
- 서버 푸시(Server Push)
- 서버가 클라이언트의 요청을 기다리지 않고 클라이언트가 필요할 것으로 예상되는 리소스를 미리 전송할 수 있다.
- 필요한 정보를 선제적으로 전송함으로써 페이지 로딩 시간을 줄여 사용자 경험을 개선할 수 있다.
HTTP 통신 흐름

1 TCP 연결 열기
2 HTTP 요청 메시지 전송
3 서버에 의해 전송된 응답 읽어들임
4 TCP 연결 해제
4-way handshake
- FIN (Client → Server): 클라이언트는 서버에게 더 이상 데이터를 전송하지 않겠다는 의사를 나타내기 위해 FIN 패킷을 보낸다.
- ACK (Server → Client): 서버는 클라이언트의 FIN 패킷을 받았음을 확인하고, ACK 패킷을 클라이언트에게 보낸다. 이때 서버는 여전히 데이터를 보낼 수 있다.
- FIN (Server → Client): 서버도 데이터 전송을 종료할 준비가 되면, 클라이언트에게 FIN 패킷을 보낸다.
- ACK (Client → Server): 클라이언트는 서버의 FIN 패킷을 받았음을 확인하고, ACK 패킷을 서버에 보낸다. 이로써 연결 종료 과정이 완료된다.
- 클라이언트의
TIME-WAIT 상태
- 클라이언트가 마지막 ACK 패킷을 보낸 후에 즉시 연결을 닫지 않고 2MSL(Maximum Segment Lifetime, MSL: 패킷이 네트워크 상에서 유효하게 남아 있을 수 있는 최대 시간) 동안 TIME-WAIT 상태를 유지한다.
- 서버가 클라이언트가 보낸 마지막 ACK 패킷을 받지 못하면 FIN 패킷을 재전송 한다. ➡️ 클라이언트가 재전송 받은 FIN 패킷을 처리하고 다시 ACK 패킷을 보낼 수 있도록 대기한다.
- 단, 바로 해제하지 않고 2, 3을 더 반복한 뒤 해제할 수 있다.(연결 재사용)
🔗 References