Introduction
Web을 기반으로 현업을 진행하면서, 네트워크에 대한 지식이 부족하다고 느꼈습니다.
정확한 지식이 아닌, 아름아름 어찌저찌.. 일을 하고 있다고 느껴서, 개발의 많은 부분에서 개념들을 보충하고자 이전에 남겨두었던 HTTP 강의를 듣기로 했습니다.
강의를 듣고, 다시 리마인드 해야하는 것들을 차례로 적어보도록 하겠습니다.
HTTP 란?
Hyper Text Transfer Protocol의 줄임말로, 초기에는 Hyper Text(html) 문서를 전송하는 프로토콜로 시작되었고,
현재는 HTML뿐 아니라, 많은 데이터 정보(이미지,영상,음성)들을 HTTP를 활용해서 전송하는데 활용됩니다.
#cf) protocol이란?
프로토콜이란 말은 굉장히 많이 듣는데, 프로토콜이란 무엇일까?
HTTP의 역사
HTTP/0.9 1991년 : GET 메소드, HTTP 헤더 X
HTTP/1.0 1996년 : 메소드 추가, 헤더 추가
HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
대부분의 기능들이 이 때, 추가되었습니다. (RFC 2068,2616,7230~7235)
-> HTTP/1.1 버전을 토대로 지금 WEB에서 많이 사용하고 있고, HTTP/2,HTTP/3 주로 성능 개선을 위해 사용된다고 한다.
HTTP/2 2015년 : 성능개선
HTTP/3 진행중 : TCP 대신 UDP 사용, 성능개선
이 정도의 개념도 거의 없었는데, 지금이라도 버전에 대해 알 수 있어서 다행이다...
HTTP의 특징
HTTP의 특징으로는 Stateless,Connectionless를 이야기한다.
그렇다면 이런 개념들은 무엇인지 알아보자
Stateless (무상태)
HTTP Stateless 한 상태를 지향하는 프로토콜이다.
이 말인 즉슨, Server 가 Client의 상태를 갖고 있지 않는다는 것을 의미하며, 요청하는 Client 누구인지 알 필요가 없다는 것을 의미한다.
서버가 Stateless한 상태를 유지한다면 Scale out을 통한 서버확장에 용이하다는 큰 장점이 있다.
stateless 강의를 듣고 난 나의 생각정리
여기서 내가 유저정보를 담기 위해서 많이 사용했던 JWT 에 대한 개념이 생각났다.
이 JWT를 사용하는 궁극적인 이유가 아마 이 Stateless를 지향하기 위함이구나 라고 떠올랐다.
왜냐하면, client에게 로그인 성공했다는 것을 response로 jwt을 주고 그것을 요청 시마다 보내면,
서버는 client의 상태정보를 갖고 있지 않아도 되기 때문이다.
이렇게 되면 Server Scale out하는데 있어서 부담이 적어질 것이라고.. 아주 단순하게나마 떠올릴 수 있었다.
엄청나게 많은 인프라적 요소가 있지만, 그 중 매우 작은 단순한 일부분..
보통 JWT를 이용하면, refresh-Token을 같이 사용하는데 Redis 혹은 RDB에 refresh-token 값을 저장하니,
완벽한 stateless라고 보긴 힘드려나 하는 생각이 들었다.
application server 기준으로만 봤을 때는 DB가 분리되어 있기 때문에 stateless하다고 말할 수 는 있으나,
결국 client 에게 token을 받고 refresh할 경우 db에 가서 확인해야하니..
상태를 개념적으론 들고 있다고 생각해야할까..?
scale out 할 때 서버만 분산서버로 늘리고 rdb 혹은 redis에 외부로 띄어두면 stateless의 장점을 가져갈 수 있을거 같다. Connectionless (비연결성)
Http는 기본적으로 연결을 유지하지 않는 모델이다.
TCP는 연결을 계속해서 유지하는 프로토콜이다. three-way-handshake를 통해 통신을 유지하고, 데이터를 주고 받는다.
Http 는 tcp를 통해 서로의 연결을 확인하고, 데이터를 주고 받은 후, tcp 연결을 끊는다.
비연결성 특징을 사용함으로써의 장점은 서버 자원을 효율적으로 사용할 수 있다는 것이다.
연결을 유지하는 것 자체가 서버의 자원을 소모하는 것이기 때문이다.
비연결성으로써의 단점은 분명히 존재하는데, 연결을 끊고, 유저가 다시 요청을 하면 tcp의 three-way-handshake를 또 진행해야 한다는 것이다.
(Persistent Connections (이전의 keep-alive) ) 이다 얼마나 연결을 지속해서 유지할 것인가를 나타낸다.
keep-alive 옵션을 본적이 있는데.. 이게 무엇인지 이제서야 알다니..
서버자원의 효율성에 대해 이야기하다, 강의에서 이벤트 페이지같은 대용량 트레픽이 몰리는 경우에 대해 이야기 해주셔서
그에 대해 생각을 하게 되었다. 이전에도 몇번 들었던 내용이고, 이를 어떻게 처리해야할까..
아직까지도 정답을 찾지 못했다. (실험이라도 해봐야겠다. 추후에 실험을 통한 확인을 해봐야겟다.)
지금 드는 느낌은 traffic을 받는 서버가 용량이 부족해서 터지지 않을 정도로 spec이 좋거나,
무언가 요청들을 한 곳에 받아 빠르게 병렬적으로 처리하는 아키텍처가 필요할 것으로 생각된다.
병렬적으로 처리하면서 DB의 Transcation 관리도 해야하고.. 생각할게 정말 많을거 같다.
특히 선착순 이벤트 같은 경우는.. 누군가는 받고, 누군가는 받지 못하니 이에 대해 어디서 배울수 없나? ...
나만의 정답을 우선 찾고 답을 동냥하러 다녀보자..HTTP Method 특징
새로 알게된 내용 혹은 기억해야 될 내용 정리
강의를 지속해서 들어가나가면서, 정리할 부분입니다.
1. HTTP는 TCP를 기반으로 작동한다?
OSI 7계층에 관해 공부할 때 의문점이 였던 부분이다.
client-server가 통신할 때
client 쪽에서 데이터를 전송할 때, 상위 계층에서 하위 계층으로 내려가면서 packet에 해당 계층에 필요한 데이터들이 붙고, server에서 받은 패킷의 데이터를 하위계층에서 상위계층으로 올라가면서 packet에 해당 내용들을 추출해서 사용한다고 공부했다.
여기서 나온 말이 HTTP 는 TCP를 기반으로 작동한다 였는데, 전혀 도통 이해가 되지 않았다. HTTP는 연결이 유지가 되지 않는 것을 지향하고, TCP는 연결이 계속 유지되자나 이상한대? 라고 생각했다.
강의를 들으면서 알게 된 것인데,
우선 Socket 을 활용해 TCP를 통해 연결을 하고 서로 연결을 확인하고(three-way-handshake), 그 후 http message를 주고 받고 처리한 후 tcp 연결을 끊는다는 것이다.
듣고 나니 당연한 말 맨 처음 공부할 때는 왜 어렵게 생각했지..
아래의 주제들은 다음글에서 이어서 셜망하도록 하겠습니다 :)
2. HTTP Message 기본 스펙
3 IP, TCP 기본 개념
4 PUT,PATCH 차이 활용법
5 HTTP Post Method 컬렉션 방식, 스토어 방식
6 HTTP 상태코드 정리
7 HTTP 헤더별 정리
8 쿠기 개념 간단정리
Reference
김영한님의 HTTP 기본강의
