[김영한 HTTP] HTTP 기본

• 모든 것이 HTTP
• 클라이언트 서버 구조
• Stateful, Stateless
• 비 연결성(connectionless)
• HTTP메시지(★)

 

모든 것이 HTTP

 

1)HTTP 메시지에 모든 것을 전송

HTTP ; Hyper Text Transfer Protocol

문서간의 링크를 통해서 연결할 수 있는, 하이퍼텍스트 문서를 통해서 연결할 수 있는 (html)

을 전송하는 프로토콜로 처음에 시작이 됨, 그런데 지금은 모든것을 전송할때 쓰는 중 ! 

 

• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML(API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• 지금은 HTTP 시대 !

+실무에서 서버간 통신할때 TCP 프로토콜 직접 이용해서 데이터 전송하는 경우 잘 없음

 

2) HTTP 역사

• HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더 X
• HTTP/1.0 1996년 : 메서드, 헤더 추가
• HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
• HTTP/2 2015년 ; 성능 개선
• HTTP/3 진행중 : TCP 대신에 UDP 사용, 성능 개선

1.1에 거의 대부분의 기능이 있고 2,3은 성능개선에 초점이 맞춰져 있음

 

3) 기반 프로토콜

• TCP : HTTP/1.1 , HTTP/2 
• UDP : HTTP/3
• 현재 HTTP/1.1 주로 사용(HTTP/2, HTTP/3도 점점 증가)

 HTTP/1.1 HTTP/2 는 TCP 프로토콜 위에서 동작함

HTTP/3는 UDP 기반으로 개발됨

TCP는 3way handshake 해야하고, 데이터 많고, 메커니즘이 빠르진 않아서 

성능 최적화 해서 나온게 HTTP3 

 

+F12 누르면 바로 개발자도구 페이지 

h3 이 http3 

아래 네이버 페이지 h1, h2 다 쓰는거 확인 

 

4) HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스)을 지향, 비연결성
• HTTP 메시지를 통해 통신, 보낼때 받을때 모두 
• 단순함, 확장 가능

 

클라이언트 서버 구조 

 

• Request Response 구조
• 클라이언트는 서버에 요청을 보내고, 응답을 대기
• 서버가 요청에 대한 결과를 만들어서 응답

클라이언트가 http 메시지를 통해서 서버에 요청(Request)을 보냄, 

그리고 클라이언트는 서버응답 무작정 대기하고 서버가 응답하면 열어서 클라가 동작하게 됨

 

클라랑 서버랑 분리되어 있다는게 중요, 과거엔 그렇지 않았던 적도 있음 

서버에는 비즈니스 로직, 데이터 같은건 다 밀어 넣고 

클라이언트는 UI, 사용성에 집중 

이렇게 분리를 통해 각각 독립적으로 진화할 수 있었음

 

무상태 프로토콜 

1)스테이스리스(Stateless)를 지향

• 서버가 클라이언트의 상태를 보존하지 않는다는 뜻 
• 장점 : 서버 확장성 높음(스케일 아웃)
• 단점 : 클라이언트가 추가 데이터 전송 

2) Sateful. Stateless 차이

상태유지 - Stateful (문맥을 보존함)

 

고객 : 이 노트북 얼마?

점원 : 100만원이오(노트북 상태 유지)

 

고객: 2개 구매할게요

점원 : 200만원 입니다. 신용카드? 현금? 어떤걸로 해드릴까요?(노트북, 2개 상태유지)

 

고객 : 신용카드요

점원 : 200만원 결제 완료 됐어요(노트북, 2개, 신용카드 상태유지)

 

 

상태유지- Stateful 그런데 점원이 중간에 바뀌면? 

 

고객 : 이 노트북 얼마?

점원a : 100만원이오

 

고객: 2개 구매할게요

점원b : ? 뭔솔 뭘 2개 구매할거?

 

고객: 신용카드로 할게요

점원c : ? 뭔솔 무슨 제품 몇개를 신용카드로 구매할거? 

 

무상태 - Stateless

 

고객 : 이 노트북 얼마?

점원 : 100만원이오

 

고객: 노트북 2개 구매할게요

점원 : 노트북 2개는 200만원입니다. 신용카드 현금중에 어떤거?

 

고객: 노트북2개를 신용카드로 구매할게요

점원 : 200만원 결제 완료됐습니다.

 

점원은 마지막 대화만으로도 결제를 완료할 수 있음

 

무상태 - Stateless, 점원이 중간에 바뀌면?

 

고객 : 이 노트북 얼마?

점원A : 100만원이오

 

고객: 노트북 2개 구매할게요

점원B : 노트북 2개는 200만원입니다. 신용카드 현금중에 어떤거?

 

고객: 노트북2개를 신용카드로 구매할게요

점원C : 200만원 결제 완료됐습니다.

 

정리

 

• 상태유지 : 중간에 다른 점원으로 바뀌면 안된다.(중간에 다른 점원으로 바뀔 때 상태정보를 다른 점원에게 미리 알려줘야 한다.)
• 무상태 : 중간에 다른 점원으로 바뀌어도 된다.                                                                                                                       -갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.                                                                                                     -갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다. 
• 무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능 

 

상태유지에서는 중간에 다른점원으로 바뀌면 서비스장애가 일어남 다른점원으로 바뀌면 문맥이 사라짐,

그런데 무상태에서는 고객이 필요한 데이터를 그때그때 다 넘겨줌. 그래서 중간에 점원이 바뀌어도 문제 없음

위와 같은경우 클라이언트A는 서버1이랑만 통신해야 함. 서버1은 클라A 데이터 저장(상태보관)

문제는 서버1이 장애가 발생한 경우 클라A는 처음부터 요청해야함

 

 

서버는 응답만 함 

좋은건 중간에 서버1이 장애가 나더라도 중계서버가 서버2로 연결해줘서 응답해줌

 

3) Stateless 실무한계

• 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.
• 무상태 예) 로그인 필요 없는 단순한 서비스 소개 화면
• 상태유지 예) 로그인
• 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
• 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
• 상태 유지는 최소한만 사용 

예를들어 이벤트 소개페이지, 단순 서비스 소개 페이지의 경우 로그인 할 필요도 없는 경우 상태유지 필요없음 무상태설계 쉬움. 장애도 잘 나지 않음

그런데 상태를 유지해야 하는 경우 예를들어 로그인해야 하는 경우에는 사용자가 로그인 했다는 상태를 

서버가 유지해 줘야함 그래서 브라우저에 있는 쿠키와 서버의 세션을 조합해서 상태유지기능을 씀 

서버에 세션이 날아가거나 죽으면 전체적으로 로그인 풀림 

어쩔 수 없이 한계가 있지만 최소한으로만 꼭 필요할경우만 사용해야 함 

stateless단점은 데이터 많이 보내야 함 

웹어플리케이션 설계시 최대한 무상태로 설계하고 어쩔수없는 경우 한해서만 상태유지를 함 ! 

 

비 연결성(connectionless)

TCP/IP 의 경우 기본적으로 연결을 유지함 

연결을 유지하는 경우 클라2랑 연결할때도 클라1은 접속상태. 클라3이랑 연결할때도 클라 1,2는 연결상태임

클라 1,2,3 이랑 다 연결을 유지해야 하니까 서버의 자원은 계속 더 소모되는 중

단점은 클라 2,3이 아무것도 안해도 연결 유지해야함

 

 

연결을 유지하지 않는 모델의 경우 서로 필요한것만 주고받은 즉시 연결 종료해버림

그러면 서버는 현재 요청을 주고받을때만 연결하고 끊어버려서 서버 유지하는 자원을 최소화 

클라에 또 다른 데이터 필요하면 요청할때 연결하고 응답보내고 해서

최소한의 자원으로 서버를 유지할 수 있음

 

비 연결성 특징

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음                           예를 들어 웹 브라우저에서 계속 연속해서 검색버튼을 누르지 않음
• 서버 자원을 매우 효율적으로 사용할 수 있음

연결을 유지하지 않는게 서버입장에서는 자원의 가용성을 높힘

 

비연경성 한계와 극복

• TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
• 웹브라우저로 사이트를 요청하면 html 뿐 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드
• 지금은 http 지속연결(persistent connections)로 문제 해결
• http/2, http/3 에서 더 많은 최적화

자원을 받을때마다 연결하고 받고 다시 끊고 다시 연결하고 너무 비효율적임

그래서 기본적으로 지속연결을 씀 

 

 

연결을 처음 하고 요청을 보내고 응답을 받음, 그다음 다 끝날때 까지 연결을 유지함. 그동안 요청 응답 반복

몇십초 유지 등 내부매커니즘이 존재함 , 웬만한 웹페이지 하나 받을때 까지 연결 유지 

요청하고 쭉 ~ 다 받고나서 종료

http3 는 UDP 쓰면서연결 속도도 줄임

 

스테이스리스를 기억하자~!

서버개발자들이 어려워하는 업무

• 정말 같은 시간에 딱 맞춰발생하는 대용량 트래픽
• 예를들어 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록
• 예를들어 저녁 6시 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청

이럴때는 비연결성 소용없어 진짜 다 몰려와서.... 그래도 최대한 스테이스리스하게 설계하는게 중요

보통 이벤트 설계할때 첫페이지 로그인 필요없는 정적 페이지에 참여버튼 누르게 하거나 하는 등

 

무상태로 할수있는거 최대화 하고 상태유지는 최소화 하도록 설계하는것 중요하다~!

 

★HTTP 메시지 

HTTP는 요청과 응답 메시지의 구조가 다름

공백 무조건 있어야 함

 

요청메시지에서 전송할 데이터 없으면 공백라인 넣고 끝내면 됨

시작라인은 크게 request line, status line 으로 구분

요청 라인에 method 는 GET 같은거, request-target은 path가 들어감 그리고 http version 총 3가지 들어감

 

GET ; 서버에게 이 리소스를 줘~ 하는거

POST ; 이 데이터 줄테니 처리해줘

DELETE ; 삭제해줘

 

보통 절대경로로 시작, 쿼리를 합쳐서 들어감

start-line에서 요청은 request line 응답은 status line

status-line은 http 버전, ★stateus 코드(상태코드, 클라가 보낸요청의 성공실패), 이유문구

400 : 클라요청 오류, 요청 잘못보냄

500 : 서버의 장애가 있어서 서버내부오류의 경우 

OK : 이유문구, 사람이 이해할 수 있는 짧은 설명글 

 

OWS ; 띄어쓰기 허용

Host 띄우고 ":" 은 불가

field-value 는 대소문자 구분

 

 html인지 xml 인지 등 설명, 인증정보 등 들어감

걍 메시지 바디 빼고 필요한 메타 데이터 다 들어가 있음 

 

HTTP 정리

 

• HTTP 메시지에 모든 것을 전송
• HTTP 역사 HTTP/1.1 기준으로 학습
• 클라이언트 서버구조
• 무상태 프로토콜(스테이스리스)
• HTTP 메시지
• 단순함, 확장 가능
• 지금은 HTTP 시대