HTTP는 Hyper Text Transfer Protocol의 약자
- Request Response 구조를 의미하며, 클라이언트가 서버에 요청(request)을 하면 서버가 클라이언트에게 응답(Response)를 하는 방식을 의미한다
무상태 프로토콜(Stateless)
서버가 클라이언트의 상태를 보존하지 않는 경우
상태 유지(Stateful)
서버가 클라이언트의 상태를 보존하는 경우
- 항상 같은 서버가 유지 되어야함
클라이언트의 요청에 이전 상황에 대한 정보가 없기 때문에 계속 소통하던 서버와의 소통이 이루어져야함- ex) 로그인
- 어느 서버든 상관없음
클라이언트 요청에서 이전 상황에 대한 요청을 모두 보내기에 같은 기능을 한다면 어떤 서버로 보내든 상관 없음- 상태 유지보다 많은 데이터를 보내야함
- ex) 단순한 서비스 소개 화면
→ 중간에 프록시 서버와 원 서버의 연결이 끊길 경우, 무상태 프로토콜은 임의의 같은 기능을 가진 서버로 연결하면 되지만 상태 유지의 경우 작업이 불가함
일반적으로 클라이언트와 서버 구조는 한번 TCP/IP 연결시 연결을 유지함
하지만, 다수의 클라이언트가 하나의 서버와 연결 후 더 이상 소통하지 않음에도 연결돼있다면 자원이 낭비되므로 나온게 비 연결성이다.
비 연결성은 요청과 응답 후 TCP/IP 연결을 종료함으로써 서버 자원 낭비를 방지함
※ HTTP는 기본이 비 연결성이다
장점
- 수천명이 서비스를 사용해도 서버에서 동시 처리하는 요청은 수십개 이하
ex) 브라우저 검색시 연속으로 검색을 누르지 않음- 서버 자원 사용이 효율적
단점
- TCP/IP 재연결시 3 way handshake 시간이 추가됨
- 요청 시 다양한 자원을 함께 다운로드 해야함
ex) 연결 - HTML - 종료, 연결 - JS - 종료 ---
위 단점을 해결하기 위해 나온 방안이 지속 연결이다.
기존에 HTML, JS 및 데이터를 다운받을때 종류별로 연결과 종료를 했지만,
한 Task는 한번의 연결 싸이클에 다 응답받을 수 있도록 하는 방안을 의미
→ 연결 - HTML - JS - IMG - 종료
HTTP 메시지는 클라이언트의 요청 메시지, 서버의 응답 메시지로 나눌 수 있다
HTTP 메시지는 다음과 같은 형식을 가진다
시작 라인
헤더
공백라인(CRLF)
메세지 바디
HTTP 메시지는 request-line(요청) 과 status-line(응답) 두 가지로 나뉜다
request-line
1. 시작 라인 = method SP request-target SP HTTP-version CRLF**
2. 헤더 = field-name ":" OWS field-value OWS
request-line
Get /serach?q=hello&hl=ko HTTP/1.1 Host : www.google.com
status-line
1. 시작 라인 = HTTP-version SP status-code SP reason-phrase CRLF
2. 헤더 (metadata of message body)
2.1 Content-Type
2.2 Content-Length
3. CRLF
4. 메시지 바디 (실제로 전송할 데이터)
status-line
HTTP/1.1 200 OK Content-Type : text/html;charset=UTF-8 Content-Length : 3423 CRLF <html> <body>...</body> </html>