HyperText Transfer Protocol
- HTML, TEXT 뿐만 아니라 이미지, 음성, 영상, 파일, JSON, XML(API) 모두 전송 가능
- 심지어 서버간에 데이터를 주고 받을 때도 사용
HTTP 역사
- HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 없음
- HTTP/1.0 1996년 : 메서드, 헤더 추가됨
- HTTP/1.1 1997년 : 모든 기능, 가장 많이 사용
RFC2016(1197) → RFC2616(1999) → RFC7230~7235(2014)
- HTTP/2 2015년 : 성능 개선
- HTTP/3 진행 중 : TCP 대신 UDP 사용, 성능 개선
HTTP 기반 프로토콜
- TCP : HTTP/1.1, HTTP/2
- UDP : HTTP/3
- 현재 1.1을 주로 사용하지만 2, 3도 점차 증가 중
HTTP 특징
- 클라이언트 & 서버 구조
- 무상태 프로토콜( Stateless )
- 비연결성
- HTTP 메시지
- 단순함, 확장 가능
(1) 클라이언트 서버 구조
- Request & Response 구조
- 클라이언트는 서버에 요청을 보내고 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답
- 클라이언트와 서버가 분리가 되면서
- 비즈니스 로직, 데이터는 서버에서 집중
- 클라이언트에는 ui, 사용성에 집중
그래서 클라이언트와 서버가 독립적으로 진화할 수 있게됨
(2) 무상태 프로토콜 (Stateless)
- 서버가 클라이언트의 상태를 보존하지 않음
- 장점 : 서버 확장성이 높음 (스케일 아웃, 무한한 서버 증설 )
- 단점 : 클라이언트가 추가 데이터 전송
상태유지 (Stateful)와의 비교
가게에서 닌텐도 2개 구매를 예시로 하면 ...
상태유지(Stateful)일때
닌텐도 선택 → 2개 → 결제수단 선택 → 결제
주문을 하는 점원이 계속 유지가 되어야 함
무상태(Stateless)일때
닌텐도 선택 → 닌텐도 + 2개 → 닌텐도 + 2개 + 결제수단
중간에 점원이 바뀌어도 무사히 요청이 가능!
즉, 클라이언트 요청이 증가해도 응답 서버를 쉽게 변경 가능하다
하지만 전송해야하는 데이터 양이 더 많음
서버 개발자들이 어려워하는 업무는 같은 시간 딱 맞추어 발생하는 대용량 트래픽 (수강신청, 선착순, 명절)
그러니까 애플리케이션 설계할땐 최대한 무상태로 해야하며, 상태유지는 최소한만 (로그인) 사용해야 한다.
(3) 비연결성(connectionless)
- TCP/IP 연결 후 계속 유지가 됨.. (서버는 자원을 계속 소모)
- 필요한 것만 주고 받고 끊어버리면 서버는 최소한의 자원을 유지한다. 필요하면 또 연결하고...
- HTTP는 기본이 연결을 유지하지 않음
- 일반적으로 빠른 응답
- 수천명이 서비스를 사용해도 실제 서버에서 동시 처리하는 요청은 매우 작음
- 이렇게 연결이 유지되지 않는게 서버 자원을 매우 효율적으로 사용할 수 있음
- 단점은 TCP/IP 연결을 계속 새로 맺어야함 (3 way handshake 시간 추가)
- 웹 브라우저로 요청하면 html뿐만 아니라 js, css, 이미지 등 수많은 자원을 함께 다운로드
- 그래서 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
- 내부 메커니즘으로 다 받고 나서 종료하는 식임
- HTTP 2, 3 에서는 더 최적화
(4) HTTP 메시지
- HTTP 메시지 구조
| start-line | 시작라인 |
| header | 헤더 |
| empty line | 공백라인 (CRLF) |
| message body | 내용 |
- HTTP 요청 메시지 구조
| GET /search?q=hello&hl=ko HTTP/1.1 | 시작라인 |
| host: http://www.google.com | 헤더 |
| (가질수있긴함) | message body |
- HTTP 응답 메시지 구조
| HTTP/1.1 200 OK | 시작라인 |
| Content-type: text/html;charset=UTF-8 Content-Length:3423 |
헤더 |
| <html><body>...</body></html> | message body |
시작라인 (start-line)
- 요청은 request-line / 응답은 status-line
| request-line (요청 메시지) | status-line (응답 메시지) |
| http method SP(공백) request-target SP http-version CRLF(엔터) |
http-version SP status-code SP reason-phrase CRLF |
| - http method 는 서버가 수행해야 할 동작 지정 (GET, POST, PUT, DELETE ...) - 요청 대상 절대경로 = '/' 로 시작하는 경로 - http-version 은 그냥 버전 |
- http-version 은 그냥 버전 - HTTP 상태 코드는 요청 성공, 실패를 나타냄 (200:성공/ 400:클라이언트 요청 오류 / 500:서버 내부 오류) - 이유 문구 : 사람이 이해할 수 있게 짧은 상태 코드 설명 글 |
HTTP 헤더
- field-name":"OWS field-value OWS (OWS:띄어쓰기 허용이란 뜻)
- Host: http://www.google.com 이라든가 ..
- Content-Type: text/html;charset=UTF-8 이라든가
- HTTP 전송에 필요한 모든 부가 정보가 들어있음
(메시지 바디의 내용, 바디의 크기, 압축, 인증, 요청 클라 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등 ...)
- 표준 헤더가 너무 많음
- 임의의 헤더 추가 가능
HTTP 메시지 바디
- 실제 전송할 데이터
- 모든 데이터 전송 가능
참고 강의 : https://taylog.tistory.com/203
[강의리뷰] “모든 개발자를 위한 HTTP 웹 기본 지식” 후기 | 인프런
모든 개발자를 위한 HTTP 웹 기본 지식김영한님의 실무에 필요한 HTTP 핵심 기능에 대한 강의다. 강의의 총 길이는 5시간 40분, 강의 구성은 아래와 같다.인터넷 네트워크URI와 웹 브라우저 요청 흐
taylog.tistory.com
'🧠 저장 > Http' 카테고리의 다른 글
| HTTP 상태코드 간단 정리 (0) | 2024.02.20 |
|---|---|
| HTTP API 설계 개념 간단 정리 (0) | 2024.02.17 |
| HTTP 메서드 종류, 속성 간단 정리 (0) | 2024.02.14 |
| 웹 브라우저 요청 흐름 간단 정리 (0) | 2024.02.08 |
| IP, TCP, UDP, URI 간단 정리 (0) | 2024.02.05 |