728x90
HTTP(Hyper Text Transfer Protocol)
- WWW 적용을 위해 단순함을 염두해두고 디자인됨
- 과거에는 문서 간 링크 통해 HTML 전송 위해 시작
- 현재는 이미지, 영상, JSON, XML 등 거의 모든 형태 데이터 전송
- 서버 간 데이터를 주고 받을 때도 사용
- 인터넷에서 데이터를 주고 받기 위한 프로토콜
- Application 계층에서 동작
- HTTP/3 - UDP / 하위 HTTP - TCP
URL 컴포넌트 구조
- http
- Protocol(=액세스 프로토콜)
- example.com
- Host(Domain) (=액세스할 웹 서버에 대한 도메인 혹은 호스트 IP 정보)
- 8080
- Port
- path
- 계층적인 디렉토리 형태로 응답을 받을 리소스에 대한 경로
- id=doa&pw=1234
- Query String (Key=Value 형태로 구성)
HTTP 트랜잭션 과정
- 사용자가 브라우저 통해 URL 입력
- 사용자가 도메인을 입력하면 로컬 호스트의 Hosts 파일 참조
- 도메인에 대한 정보가 없으면, 도메인에 대한 리소스 레코드 정보가 기록된 DNS 서버를 경유하여 도메인에 대응하는 주소 정보 조회
- 브라우저에서는 사용자가 요청한 프로토콜 규격에 알맞게 서버로 전달할 요청 메시지를 생성
- 이 요청 메시지에서는 서버가 수행할 동작을 의미하는 메서드 정보 & HTTP 버전 정보, 웹 서버 호스트 정보 등을 포함
- 생성된 요청 메시지는 인터넷망을 통해 서버측으로 정보 전달
- 요청을 받은 웹 서버는 해당 메시지 정보를 해석하여 응답 메시지를 만들어 회신
- 웹 브라우저는 서버에게 받은 메시지를 화면에 렌더링하여 사용자에게 시각화된 정보를 제공
HTTP 메시지 구조(규격) - RFC 7230
- HTTP의 메시지 규격은 start-line 으로 시작하여 메시지 헤더와 바디로 구성
- Request Line (요청 메시지의 Start Line)
- 서버가 수행해야 할 동작을 의미하는 GET, POST, PUT, DELETE, OPTIONS와 같은 메서드에 대한 정보와 요청 대상 리소스의 경로를 표현
- HTTP 버전 정보 포함
- Status Line (응답 메시지의 Start Line)
- HTTP 버전 정보와 상태 코드, 사유가 포함
HTTP 메시지 구조
- Request Header
- 사용자 소프트웨어를 의미하는 User-Agent 정보, 요청 대상 정보인 Host, 클라이언트측에서 콘텐츠 협상을 위한 Accept 등 포함
- Response Header
- 응답에 대한 정보를 포함하는 고유 식별 번호를 포함하는 ETag와 Apache 혹은 Nginx와 같은 서버측의 소프트웨어 정보와 요청 메시지에 대한 응답 시간 등 포함
- General Header
- 요청과 응답 메시지에 공통으로 포함되는 헤더 필드인 TCP Connection 방식 등 포함
- Representation Header(Entity Header)에 포함된 헤더 필드 - 해당 정보를 참조하여 페이로드(본문)을 해석
- Content-Type(데이터 유형)
- Content-Length(데이터 길이)
- Content-Encoding(압축 정보)
- Content-Language(언어 표현)
- 헤더 내에서는 ‘field-name’ 과 ‘field-value’ 형태로 구성이 되어 HTTP 전송에 필요한 모든 부가 정보 포함
HTTP 추가 내용
- HTTP/1.1 부터는 명시적으로 캐시와 관련된 부분을 제어하기 위한 Cache-Control 헤더 필드 추가
- 완전한 콘텐츠 응답에 대한 요청 수와 불필요한 전송을 최소화하기 위한 목적으로 Cache-Control 필드가 추가
- 보안 헤더를 통해서 웹 취약점 보안을 강화하기 위한 목적으로 암호화된 패킷으로 전송하기 위한 Secure 필드 제공
- XSS 공격 방지를 위한 HttpOnly와 같은 다양한 헤더 필드 제공
- Set-Cookie, 리다이렉트와 관련된 Location, 이전 요청 주소를 의미하는 Referer 등의 다양한 정보를 담아 전송
- 메시지 바디인 표현 데이터에서는 HTML 문서, 이미지, 영상, JSON 등의 Byte 단위로 표현할 수 있는 모든 데이터가 포함
REST API 제약 조건 대표적 메서드
- GET
- 주로 정적 데이터를 조회하거나, 쿼리 파라미터를 기반으로 특정한 게시글 (ex. /posts?title=doa) 등과 같이 동적 데이터 조회 할 때 활용
- POST
- 내부적으로 처리 필요할 때 활용
- HTML 폼에 입력한 데이터를 전달하는 경우, 메시지 바디 통해 서버로 데이터 전달
- Ex) 회원 가입, 상품 주문, 상품 등록, 변경
- PUT
- 클라이언트에서 서버로 데이터를 보내는데 해당하는 리소스가 이미 존재한다면 대체하고, 없으면 새롭게 생성
- DELETE
- 리소스를 삭제하도록 활용
HTTP 상태 코드
- 1xx - 정보성 상태 코드에 해당, 처리가 되면 다음으로 넘어감
- 2xx - 요청에 대한 정상 처리
- 3xx - 리다이렉션과 같은 요청
- 4xx - 클라이언트에 대한 오류에 해당
- 5xx - 서버에 대한 오류
HTTP 특징
- 무상태 프로토콜
- C/S간 요청과 응답을 주고 받으면, 연결이 끊어짐
- 일관된 방식으로 상호작용하기 어러움
- 비연결성
- HTTP는 TCP 기반으로 동작
- 여러개의 객체를 로드 시, 단일 객체마다 모두 별개의 객체로 판단하여 객체마다 지속적인 핸드셰이크 과정 성립
- Keep Alive (HTTP/1.1부터 기본 활성화)
- 반복적인 연결을 맺는 문제점 해소 위해 일정 시간동안 ESTABLISH 연결 유지, 이후 능동적으로 Close
- 해당 프로세스 수가 설정한 시간 동안 유지되기 때문에 서버에서 제한된 MAXConnection 값을 초과할 수 있음
- 메모리 사용률을 초과하는 문제점이 생길 수 있음
- Content-Length 가 명확한 경우에만 가능
FIFO 방식의 HTTP/1 - HOLB 현상과 파이프라이닝
- HTTP/1 버전에서 HTTP에서의 블로킹으로 인한 문제점 존재
- HTTP요청은 순차적으로 처리가 되기 때문에 네트워크 지연과 대역폭 제한 등의 이유로 다음 요청을 보내는 데까지 상당한 딜레이가 발생할 수 있음
- 개선 방안 - 영속적인 커넥션을 통한 파이프라이닝
- 여러 개 리소스 요청시, 이전 요청에 대한 응답을 완전하게 받지 않더라도 지속적 연결로 확보한 TCP 연결 내에서 미리 다음 요청에 대한 처리를 시작하면서 전체적인 전달 시간을 최소화하는 방식
- 여전히 FIFO 방식으로 처리하기에 한계 존재
- GET, HEAD, PUT과 같은 멱등성을 가진 메서드만 가능
- 멀티플렉싱으로 대체 (HTTP/2)
HTTP/2
- 바이너리 프레임 포맷으로 변화, 헤더 압축 가능
- 멀티플렉싱 - 하나의 TCP 연결 상에서 다수의 클라이언트 요청과 서버의 응답이 비동기 방식으로 이루어짐
- HTTP 하위 버전에서 발생했던 HOLB 현상은 해소 가능
- HTTP 프로토콜이 동작하는 하위 계층의 TCP에 대한 HOLB 현상은 해소되지 않음
- 사전 조건 - HTTP/2는 HTTPS만을 지원하기 때문에 SSL/TLS 인증서를 발급 받아야 함
HTTP/3
- QUIC이라는 UDP 기반의 프로토콜 사용 (핸드셰이크 과정 생략)
- 첫번째 핸드셰이크 과정을 거칠 때에 연결 설정에 필요한 정보들도 모두 포함하여 데이터도 함께 보냄
- UDP 프로토콜은 TCP 헤더와 비교해보면 확실히 가벼운 구조로 구성
- TCP 프로토콜은 신뢰성을 확보하기 위해서 다양한 기능을 제공해주기 때문에, 빠른 데이터 전송 자체에만 초점을 둔 UDP에 비해서는 복잡한 구조를 지님
- HTTP/3에서는 TCP 특성으로 인한 한계를 극복하고자 UDP 기반의 QUIC 위에 얹어 성능 개선에 초점을 둠
인터넷에서 정보를 주고 받기 위한 HTTP에 대해서 알아보자
개요
medium.com
728x90