Hyper Text Transfer Protocol의 약어로 HTTP이며, 이는 문서를 전송하기 위한 약속이다.

이 HTTP는 Server와 Client가 어떻게 메세지를 교환할지를 정해놓은 규칙인것이다.
80번포트를 사용하여 HTTP의 구조는 Request 와 Response로 구성이 되어있다.

이는 보안이 되어있지 않아 TLS 를 통한 HTTPS통신이 존재하는데, 이는 뒤에서 다시 알아보자.

HTTP는 Request와 Response로 구성이 되어있다고 언급을 했다.

이는 더 자세히 보면 Client가 Request를 보내고, Server가 Request를 받아 Response 를 해주고, Client측에서 Response를 받는 구조로 되어있다.

FTP나 Telnet의 경우 비연결성이라 Server에 정보를 요청해도 Server가 Client의 요결을 끊어버릴 수 있지만, HTTP의 경우 Client가 Request를 보내면 Server에서 Response를 보내주고 연결을 끊는 방식이다.

그런데 Client가 Server에 어떻게 Request를 보내고, Response를 받을까??

HTTP Method

이는 한번 쯤 들어보았을 HTTP Method를 통해서 전달하기도 한다.

[POST] /user
[GET] /user

위 두 개의 Request가 같은 Response를 넘겨줄까?

동일 로직을 구현한것이 아니라면 다르다. 이는 같은 Path에 값을 보낸다고 한들, Method의 차이로 다른 Reposne를 받게 된다. Method의 차이로 인해 Request값도 달라질 수 있다.

이런 Method들은 CRUD(Create, Read, Update, Delete)에 따라서 다르게 사용되기도 한다.

각 Method의 용도는 아래와 같다.

• GET - 값을 단순히 받아올 때 사용
• POST - 새로운 값을 Body에 담아 저장을 할 때 사용
• DELET - 특정 정볼르 삭제할 때 사용
• PUT - 정보 전체를 Update할 때 사용
• PATCH - 정보 일부를 Update할 때 사용

HTTP Message

아래 이미지를 보면 Request와 Response는 startLine, Headers, emptyLine, body로 총 4등분이 된다.
이 4등분이 되는 내용들은 구성파일, API, 기타 인터페이스에서 HTTP Message를 자동으로 생성하여 보내기 때문에 개발자가 직접 작성할 필요가 없다.

• startLine
  • 요청이나 응답 상태를 나타낸다.
  • 섹션별로 Http Method / Path or Query / Http Version 으로 나뉜다.
• headers
  • 요청을 지정 or 메세지에 포함된 본문을 설명하는 헤더 집합
  • Request와 Reponse는 조금 다른 형태를 띄고있다.
• emptyLine
  • Header와 Body를 구분해주는 부분
• body
  • 요청관련 데이터 혹은 응답 관련 데이터를 포함한다.
  • 모든 요청에 body가 필요한것은 아니다

이처럼 총 4등분이 되어있고, 이러한 내용이 OSI계층을 타고 내려갔다가 다시 올라가는 흐름을 따라 Client와 Server가 서로 통신을 하게 된다.

Stateless

갑자기 뜬금없이 Stateless라는 단어가 튀어나왔다. 이는 무엇일까?
바로, HTTP의 특징 중 하나이다.

HTTP는 State를 유지하지 않는다. 즉, 목적을 다 한 통신이라면 해당 통신을 끊는다는것이다.
이를 좀 더 쉽게 말하면 서버가 Request를 받고, Response를 보냈다면 통신을 끊어버린다는것이다.

“그런데 우리는 로그인을 통해 계속 서버의 값을 가져와서 사용하지 않나요?”

맞다. 이 로그인을 통해 통신을 할 때 “나 여기 접속했던 유저야!” 라고 알려주게 되는데 이 과정을 설명하는게 바로 Cookie&Session이다.

Cookie & Session

Session

위에 언급한대로 세션이라는 효자같은놈이 해결을 해준다.
그런데 갑자기 쿠키라는 놈이 등장했다. 왜 등장하는것일까?

세션에 대해서 조금이라도 검색을 해봤다면 “세션 구현 시 쿠키를 사용한다” 라는 말을 들어보았을 것이다.

그러면 세션=쿠키 인가?
어떻게 보면 같고 어떻게 보면 다르다.

관점의 차이인데, 우선 아래 개념을 잡아두면 편하다

세션은 서버에 잠시 정보를 저장해 두는것이다.

잠시 저장해둔다 라는 말이 나왔는데, 이는 말 그대로 로그인을 한 정보를 서버에 잠시 저장을 한다는것이다.

그렇다면 세션에 대해서는 어느정도 감이 잡혔을텐데, 쿠키는 무엇일까?

Cookie

세션은 서버에 저장이 된다고 했다. 반대로 쿠키는 서버에서 만들어진 세션값이 클라이언트에 저장이 된다.

이렇게 보면 어느정도 이해가 갈 것이라고 생각이 든다.

그렇다면 동작 방식은 어떻게 되는것일까?

로그인

로그인을 한다고 가정을 해보자.

CL - 서버야 나 로그인 할게

SV - 잠시만.. 너 처음보는거같은데? 그럼 너를위한 공간을 잠시 만들어줄게! xx시간동안 사용할 수 있는 공간의 주소야!

CL - 고마워!

....

CL - 서버야 나 다시왔어! 내 공간의 주소는 이거야!

SV - 잠시만! ...(세션 id 존재하고, 시간 괜찮고) 아 여기있네 너의 정보를 줄게!

이 내용을 보게된다면 최초 로그인 시 서버에서 특정 클라이언트가 사용할 수 있도록 하는 저장소를 공간의 주소라고 언급을 했는데 그냥 당분간 값을 저장할 수 있는곳을 지정해준 것 이다.

여기서 단점이 있다. 임시로 저장을 하는것이기에 영구적이지 않다는 문제가 있는것이다.

또, 클라이언트의 연결이 많아질 때 임시로 저장을 하기 위해 공간을 낭비한다는 문제가 있다.

HTTP version

현재 우리가 사용하고있는 HTTP의 버전은 몇일까?
바로, HTTP/1.1 이다.

어? 그럼 이전 버전도 있겠네? 그러한 버전들은 무엇일까?

0.9 - 원 라인 프로토콜

원래 HTTP의 초기 버전에는 버전 번호가 존재하지 않았다. 이러한 버전 이름이 붙은 이유는 1.0이 발표된 이후 차별성을 두기 위해 0.9라는 버전 번호가 붙은것이다.

이 버전에서의 HTTP는 단일 라인으로만 구성이 되어 완전 정적인 페이지만 받을 수 있었으며, GET메서드만이 유일했다.

GET /page.html

1.0 - 확장성 만들기

0.9의 경우 너무 제한적이라는 문제가 있어 브라우저, 서버 모두 조금 더 융통성을 가지기로 했다.
이 때 부터 Header라는 개념이 생기게 되었다. 이 후 추가된 내용은 아래와 같다.

• startLine에 버전정보가 각 요청 사이에 전송되기 시작
• HTTP의 상태코드도 Response붙어 전송이 되기 시작하였고, 이로 인해서 통신 성공/실패의 결과를 알 수 있게됨.
• Content-Type의 등장으로 HTML외에도 다양한 문서들을 전송할 수 있게 되었다.

GET /page.html HTTP/1.0
User-Agent :
...등등

1.1 - 표준 프로토콜

현재 우리가 기본적으로 사용하는 프로토콜이다. 사실 1.0이 우리가 알고있는 형태와 많이 유사했지만, 아직 표준화가 덜 되어 표준화가 진행이 되었고, 이 과정을 통해 1.1이 발표 되었다.

개선 사항은 아래와 같다

• 자유로운 커넥션
• 파이프라이팅 추가로, 첫번째 요청 중 두번째 요청을 받아처리 할 수 있게 됨.(커뮤니케이션 레이턴시 감소)
• 청크된 응답 지원
• 추가적인 캐시 제어 메커니즘 도입
• 언어, 인코딩 혹은 타입 포함 컨텐츠 협상으로 Client와 Server간의 컨텐츠 교환 범위 확장
• Host의 추가로 동일 IP에서 다른 도메인을 호스팅하는 기능이 서버 코로케이션을 가능케 함

2.0 - 더 나은성능

1.1이 표준화 되어 약 15년간 지속이 되었는데, 이 사이 웹 페이지는 상당한 발전을 거쳐 매우 복잡해지며 애플리케이션화 되었다. 이렇게 되면서 스크립트의 양은 많아지고 더 많은 데이터들이 요청 너머로 전송되고 있다.

1.1의 경우 올바른 순서로 커넥션이 되어야 하며, 다양한 병렬 커넥션이 이론적으로 사용이 가능한 경우에도 많은 양의 오버헤드와 복잡도가 남아있다.

2.0으로 넘어오며 1.1과 차별화된 내용은 아래와 같다

• 텍스트 프로토콜 → 이진 프로토콜 (읽기 힘들며 수작업으로 제작이 불가하다. 또, 이러한 기능으로 인해 최적화 기술이 구현될 수 있다.)
• 병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜이다. 순서제거와 1.x 버전의 제약사항을 막아준다.
• 전송된 데이터의 분명한 중복을 제거하여 오버헤드를 줄이고, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 모두 압축시킨다.
• 서버 푸쉬라고 불리는 매커니즘으로 인해 필요하게 될(예측) 데이터를 채워넣도록 허용한다.

3.0 - 앞으로의 진화

HTTP 와 HTTPS의 TLS 대신 앞으로는 구글에서 제작한 QUIC라는 프로토콜이 사용된다.