HTTP 웹 기본 지식 (3) - Stateless, Connectionless, http메세지

김영한님의 HTTP 웹 기본지식을 들으며 정리하였습니다.

 

웹 브라우저 요청 흐름

EX) 다음과 같이 요청 날림 https://www.google.com/search?q=Hello&hl=ko

1. IP랑 PORT 정보 찾아내고, 이를 토대로 요청 보냄.
2. HTTP 버전 정보와 호스트 정보, 쿼리 정보 등을 GET 요청 보냄
3. 그 요청이 Socket 라이브러리 통해서 TCP/IP로 전달되고, 패킷이 생성됨.
4. 호스트 서버에서 받아서 패킷 까서 HTTP 메세지 분석
5. 응답패킷 생성해서 보냄. 데이터 타입 정보, HTTP 버전, 상태정보(200, 400 등), HTML 길이정보, BODY 내용 등 ...

HTTP (Hyper Text Transfer Protocol)

• 모든 것을 담아 전송한다. HTML, 이미지, 음성, 파일, JSON, XML 등
• 거의 모든 형태의 데이터 전송 가능
• 심지어 서버간 데이터 통신에서도 대부분 HTTP 사용
• HTTP/1.1 : 대부분의 스펙이 1.1에 들어가 있고, 2, 3버전은 이를 개선한 정도라서 1.1버전이 가장 중요. 

HTTP의 특징

• 1. 클라이언트-서버 구조 : Request와 Response 구조라고 할 수 있다. 클라는 서버에 요청 보내고 대기, 서버는 요청에 대한 결과 보내서 응답
• 2. Stateless & Connectionless 구조 : 서버가 클라이언트의 상태를 보존하지 않음.
• 3. HTTP 메세지 : HTTP 메세지에 거의 모든 것을 담아 전달할 수 있다.

2-1. Stateful , Stateless (치킨 전화주문)

• Stateful : Stateful은 기본적으로 A, B 대화하는데 사람이 바뀌면 안됨. 근데 사람이 바뀐다면? 치킨 시키는데 사장이 전화 받았다가 잠깐 알바에게 바꿔준다면 이때 알바한테 "후라이드 2마리 순살로 시키신다고 한다. 주소만 물어봐라" 라고 정보를 미리 알려주는 게 Stateful이다.
  • 물론, 로그인은 상태유지가 필수니까 Stateful이고 쿠키나 세션 등으로 상태 유지하게 됨. 하지만 로그인 필요없는 네이버 메인화면 같은 것은 무상태로 둘 수 있음. 다만 Stateful은 최소한만 사용하겠다는 것.
• Stateless : 중간에 사람이 바뀌어도 상관 없음. 대신 손님은 계속 똑같은 말 반복함.
  • A (손님), B(사장) 대화 : "후라이드 2마리 순살로 101동 101호로 배달해주세요."
  • A (손님), C(알바) 대화 : "후라이드 2마리 순살로 101동 101호로 배달해주세요."
  • 하지만 전화 받는 사람이 바뀌어도 상관이 없다면? (전화를 꼭 사장이 안받아도 됨) 치킨 전화주문이 증가해도 직원을 대거 투입해서 대응 가능.(서버 늘리기)
  • ++ 이를 더 이야기해보면, Stateful은 중간에 서버가 고장났을 때 그 요청을 받을 수 있는 서버는 없음. 왜냐면 대화하는 사람이 바뀌면 안되는 게 Stateful이니깐. / 그런데 Stateless는 사람 바뀌어도 상관 없으니 중간에 서버 고장나면 그냥 아무 서버나 다시 연결해주면 됨. 어차피 이 서버나 저 서버나 같은 기능을 하고, 상태 저장 안하는 건 똑같음.
  • ++ 동일한 기능을 하는 서버군을 형성하는 등 수평 확장에 유리함.  그리고 사용자는 어차피 프록시 서버 IP만 알면 되고 이 중계 서버가 서버에 요청하고 응답 받아서 사용자에게 전달할 것이라서 클라이언트는 신경쓸 것 없음.
• 그래서 중요한 점 : 선착순 이벤트, 수강신청 등 동시에 여러 요청이 들어오는 경우를 대비하기 위해 서버를 확 늘리는 상황을 고려한다면 최대한 Stateless로 설계하는 게 좋다는 것.

2-2. Connectionless (비연결성)

• 장점
  • HTTP는 디폴트가 비연결 모델이다. 왜냐하면 아무리 수천명이 쓰는 서비스라도 "동시에" 처리하는 요청은 수십개 미만으로 적다.(모든 사람들이 검색할 때 엔터 연속으로 누르는거 아니니까)
  • 따라서 비연결로 해놔야 서버 자원을 효율적으로 쓸 수 있음.
• 단점
  • 연결 끊었으니 TCP/IP를 다시 맺어야해서 3way handshake 시간이 또 소요됨.
  • 요청할 때 HTML 말고도 CSS, JS, 이미지 등 여러 자원이 함께 (다시) 다운로드 됨.
• 개선된 점
  • 자원요청 - 3way handshake - 응답주고 연결끊음 - 다시 자원요청 - 3way handshake - 응답주고 연결끊음 - 다시 자연요청 ..... 이게 비효율적이니 지금은 연결하고 잠깐 기다려주는 매커니즘(HTTP Persistent Connection)이 추가됐음. 그래서 웬만하면 요청을 다 받고, 응답해줄때까지 다 연결된 상태로 둠.

3. HTTP 메세지

• HTTP 메세지 구조

start-line

header

empty line (CRLF)

message body

• 요청 메세지 : 첫줄에 GET요청(GET /search?q=Hello&hl=ko HTTP/1.1 ), 헤더에 URL, Body는 비워도 상관 없음.
• 응답 메세지 : 첫줄에 HTTP/1.1 상태(200, 400, 500), 헤더에 Content Type과 length, Body에는 html 내용

3-1. Start-Line

• 요청 메세지 : HTTP 메소드, 요청 대상, HTTP 버전이 들어감.
  • HTTP 메소드 : GET, POST, PUT, DELETE ...
  • 요청 대상 : 절대경로 ("/")로 시작하는 경로.
  • HTTP 버전 : 1.1 등
• 응답 메세지 : HTTP-version SP status-code SP reason-phrase CRLF
  • status-code : 200, 400, 500 등
  • reason-phrase : 사람이 이해할 수 있는 짧은 설명 글 (200 OK 할때 OK를 말하는 거임)

3-2. Header

• 기본 포멧 :      field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)
  • ex) Host: www.google.com
  • field name은 대소문자 구분 안함. (host, HOST)
• Html 전송에 필요한 모든 부가정보 들어가있음. ex) message body 내용과 크기, 압축, 인증, 요청 클라이언트정보 (브라우저), 서버 애플리케이션 정보, 캐시정보 등.

3-3. Empty line

• 무조건 있어야함.

3-4. Message Body

• 실제 전송할 데이터가 담겨있음.
• HTML, 이미지, 영상, json 등 byte로 표현할 수 있는 모든 데이터 전송 가능.