[문과 코린이의 IT 기록장] HTTP - HTTP (HTTP란?, 클라이어트 - 서버 구조, 무상태 프로토콜 (스테이스리스(Stateless)), 비연결성 (Connectionless), HTTP 메시지)
모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의
실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTTP API 설계 방법을 학습합니다., - 강의 소개 | 인프런...
www.inflearn.com
[문과 코린이의 IT 기록장] HTTP - 인터넷 네트워크 (인터넷 통신, IP, TCP/UDP, PORT, DNS)
[문과 코린이의 IT 기록장] HTTP - 인터넷 네트워크 (인터넷 통신, IP, TCP/UDP, PORT, DNS) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HTTP 핵심 기능과 올바른 HTT..
vansoft1215.tistory.com
[문과 코린이의 IT 기록장] HTTP - URI와 웹 브라우저 요청 흐름 (URI, 웹 브라우저 요청 흐름)
[문과 코린이의 IT 기록장] HTTP - URI와 웹 브라우저 요청 흐름 (URI, 웹 브라우저 요청 흐름) 모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의 실무에 꼭 필요한 HTTP 핵심 기능과 올바
vansoft1215.tistory.com
1. HTTP란?
1) HTTP : HyperText Transfer Protocol
* HyperText : 한 문서에서 다른 문서로 즉시 접근 가능한 텍스트 (html 전송)
- 그러나 현재는, HTTP를 통해 HyperText뿐만 아니라, 모든 것을 전송할 수 있다.
=> HyperText + 이미지 + 영상 + 음성 + 파일, +서버끼리 통신(데이터 전송)할 때 사용하는 JSON/XML 등
- 실무에서 서버끼리 통신할 경우, TCP만을 통해 전송하는 경우는 거의 존재하지 않는다. 대부분 HTTP 프로토콜로 연결하며, TCP만으로 직접 연결하는 것은 게임 정도로 한정된 분야에서 사용된다.
2) HTTP 역사
- HTTP/0.9 (1991년) : GET 메서드만 지원, HTTP 헤더 X
- HTTP/1.0 (1996년) : 메서드, 헤더 추가
- HTTP/1.1 (1997년) : 현재 가장 많이 사용하며, 가장 중요하게 다뤄야 할 버전임. (TCP 프로토콜 위에서 동작)
* 현재 사용하는 거의 모든 기능이 들어있다.
* HTTP1.1의 개선 과정 : RFC2068 (1997년) -> RFC2616 (1999년) -> RFC7230-7235 (2014년)
- HTTP/2 (2015년) : 성능 개선 (TCP 프로토콜 위에서 동작)
- HTTP/3 (-ing) : TCP 대신에 UDP 사용, 성능 개선 (UDP 프로토콜 위에서 동작)
3) 실제 HTTP 사용 확인
- 크롬, 엣지 등 들어간 후 F12버튼 누르기
- 해당 화면에서 오른쪽 마우스를 클릭해, Protocol이라는 것을 클릭하면, 특정 자료들이 어떤 HTTP를 활용하고 있는지 확인 가능 ex. h2 -> HTTP2
4) HTTP 특징
a. 클라이언트 - 서버 구조로 동작하게 된다.
b. 무상태 프로토콜(스테이스리스)를 지향한다.
c. 비연결성이라는 특징이 존재한다.
d. HTTP 메시지를 통해 통신한다.
e. HTTP는 굉장히 단순하고 확장 가능하다.
2. 클라이어트 - 서버 구조
* 클라이언트 : HTTP 메시지를 통해 서버 요청(quest)를 보낸다. 이후 서버의 응답(response)가 올 때까지 대기한다. 응답이 오게 되면, 이 결과를 보고 클라이언트가 동작하게 된다.
* 서버 : 응답 결과를 만들어서 응답한다.
- 이와 같이 서버와 클라이언트를 구분하는 것은 굉장히 중요하다.
- 과거에는 이 둘이 하나로 묶여 있었지만, 현대에는 개념적으로 이 둘을 분리시켰다.
- 서버 : 비즈니스 로직 + 데이터 등 집중 / 클라이언트 : UI + 사용성 등 집중
- 이와 같이 관리하게 되면, 클라이언트와 서버가 각각 독립적으로 진화할 수 있게 되며, 문제가 발생했을 경우 특정 부분만 찾아서 수정 가능하다.
ex. 비즈니스가 갑자기 잘 되어, 트래픽이 100배 이상 폭주할 경우, 클라이언트는 건들지 않고 서버의 아키텍처를 어떻게 고도화 및 진화시킬지만 고민하면 된다. (PHP를 JAVA로 바꾸는 등의 방안으로 해결 가능)
3. 무상태 프로토콜 (스테이스리스(Stateless))
* Stateful : 상태를 유지한다는 것 / Stateless : 상태를 유지하지 않는다는 것.
- Stateless는 서버가 클라이언트의 상태를 보존하지 않는다는 것이다.
- 장점 : 서버 확장성이 높다. (스케일 아웃) * 즉 무한한 서버 증설이 가능하다.
- 단점 : 클라이언트가 추가 데이터를 매번 전송해야 한다.
1) 상태 유지 (Stateful)
- 항상 같은 서버가 유지되어야 한다.
2) 무상태 (Stateless)
- 아무 서버나 호출해도 된다.
3) 무상태 (Stateless) 실무 한계
- 모든 것을 무상태로 설계할 수 있는 경우도 있지만, 없는 경우도 있다. 무상태로 설계할 수 있는 경우에는 무상태로 최대한 사용하고, 어쩔 수 없는 경우에만 상태유지로 설계해야 한다.
ex. 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면 / 상태 유지 : 로그인 (브라우저 쿠키와 서버의 세션을 조합해서 상태를 유지하는 기능 사용)
4. 비연결성 (Connectionless)
1) 연결을 유지하는 모델이란?
- TCP/IP는 기본적으로 연결을 유지하는 모델이다.
- 한번 요청-응답이 이루어진 관계는, 지속적으로 연결이 유지된다.
- 이 경우, 서버는 요청 및 응답이 끝난 관계여도 연결을 계속 유지하므로, 서버 자원이 지속적으로 소모된다.
2) 연결을 유지하지 않는 모델
- HTTP는 기본이 연결을 유지하지 않는 모델이다.
- 실제 1시간동안 수천명이 하나의 서비스를 사용하더라도, 동시에 처리하는 요청은 수십개 이하로 매우 작다. 더불어 일반적으로 초단위의 굉장히 빠른 속도로 요청-응답이 이루어지므로, 클라이언트 측면에서도 큰 문제가 없다. 따라서 이 모델을 사용하면 서버 자원을 굉장히 효율적으로 사용할 수 있다.
ex. 수천명이 동시에 하나의 버튼을 같은 시간에 누르는 것이 흔하지는 않는다.
3) 비연결성의 한계 및 해결방안
- 한계
: HTTP를 사용할 때마다, TCP/IP연결을 새로 맺어야 한다. 따라서 3 way handshake의 시간이 매번 추가된다.
: 웹 브라우저로 사이트를 요청하게 된다면, HTML뿐만 아니라 Javascript css 추가 이미지 등 수 많은 자원이 한번에 다운로드 되는데, 자원을 받을 때마다 하나씩 요청하고 끊는 것을 반복하게 되는 것은 굉장히 비효율적이다.
- 해결방안
: HTTP 지속연결 (Persistent Connections)로 위의 문제를 해결한다.
* 지속연결 : 요청-응답과정이 HTML 한페이지를 다 받을 때까지 지속된 이후, 종료를 시킨다.
: 현재 HTTP/2 HTTP/3에서는 이것이 더욱 더 발전되었으며, 현재는 굉장히 많이 최적화되었다.
5. HTTP 메시지
[ HTTP 메시지 구조 ]
| start-line 시작 라인 |
| header 헤더 (header-field CRLF) |
| empty line 공백 라인 (CRLF) |
| message body |
[ HTTP 요청 메시지 ]
| GET / search ? q=hello&hl=ko HTTP/1.1 |
| Host : www.google.com |
* 요청 메시지도 body 본문을 가질 수 있음
[ HTTP 응답 메시지 ]
| HTTP/1.1 200 OK |
| Content-Type : text/html; charset=UTF-8 Content-Length : 3423 |
| <html> <body>....</body> </html> |
1) 시작 라인(start-line) = request-line / status-line
[ 요청 메시지 ]
| GET / search ? q=hello&hl=ko HTTP/1.1 |
request-line = method SP(공백) request SP HTTP-version CRLF(엔터)
a. method : 서버가 수행해야 할 동작 지정 (GET / POST / PUT / DELETE 등)
* GET : 서버에게 이 리소스를 달라고 요청하는 것 (리소스 조회)
* POST : 이 리소스의 데이터를 줄테니 상대가 처리해달라고 요청하는 것 (요청 내역 처리)
b. request(요청대상) : 일반적으로 절대경로[?쿼리문] 의 형태로 구성되어 있음.
* 절대경로 = "/"로 시작하는 경로
c. HTTP 버전
[ 응답 메시지 ]
| HTTP/1.1 200 OK |
status-line = HTTP-version SP status-code SP reason-phrase CRLF
a. HTTP 버전
b. HTTP 상태코드 : 요청 성공 및 실패를 나타냄 (200 / 400 / 500)
* 200 : 클라이언트가 보낸 요청이 성공
* 400 : 클라이언트 요청 오류
* 500 : 서버 내부 오류
c. 이유 문구 (OK) : 상태코드에 대해 사람이 이해할 수 있도록 짧게 표현한 글
2) HTTP 헤더 = header
[ 요청 메시지 ]
| Host : www.google.com |
[ 응답 메시지 ]
| Content-Type : text/html; charset=UTF-8 Content-Length : 3423 |
header-field = field-name ":" OWS field-value OWS
* OWS : 띄어쓰기를 허용한다는 것
- HTTP 전송에 필요한 모든 부가정보들을 담는 부분이다. 즉, message body 제외한 모든 메타 데이터 종류가 들어간다.
ex. message body의 내용, messsage body의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등...
- 위와 같은 표준 헤더의 종류는 굉장히 많다.
- 필요시 임의의 헤더를 추가할 수 있다.
* 임의의 헤더는, 약속한 클라이언트-서버만 이해할 수 있다.
3) HTTP 메시지 바디
| <html> <body>....</body> </html> |
- 실제 전송할 데이터를 담는다.
ex. HTML 문서, 이미지, 영상, JSON 등 => byte로 표현할 수 있는 모든 데이터를 전송할 수 있다.
| * 유의사항 - 아직 공부하고 있는 문과생 코린이가, 정리해서 남겨놓은 정리 및 필기노트입니다. - 정확하지 않거나, 틀린 점이 있을 수 있으니, 유의해서 봐주시면 감사하겠습니다. - 혹시 잘못된 점을 발견하셨다면, 댓글로 친절하게 남겨주시면 감사하겠습니다 :) |
