HTTP 기초 정리

HTTP란?

HTTP(HyperText Transfer Protocol)란 클라이언트와 서버가 원활하게 데이터를 교환할 수 있는 규칙이라고 볼 수 있다.MDN에는 간단하게 클라이언트-서버 프로토콜이라고 설명한다. 

 

HTTP약자에서 HyperText는 여러 기능이 들어간 HTML등의 문서(데이터)등을 일컫고, Protocol이란 컴퓨터 사이에서 데이터를 교환할 수 있는 방식을 정의한 규칙을 의미한다. 이 프로토콜에 의해 클라이언트와 서버는 일정한 규칙으로 데이터를 교환할 수 있다.   

 

API?

일반적으로 데이터의 교환은 클라이어트의 요청(Request)과 서버의 응답(Response)의로 정의된다.

단지 HTTP프로토콜 만으로 클라이언트가 요청을 보내 올바른 응답을 얻을 수 있는 것은 아니다. 클라이언트는 서버에서 제공해주는 API(Application Programming Interface)정보를 참고해서 규칙에 맞게 요청을 보내야 원하는 응답을 받을 수 있다.

 

API약자에서 Interface는 "의사소통이 가능하도록 만들어진 접점"을 의미한다.

 

즉, API는 클라이언트와 서버가 소통하기 위해 서로 공통되게 필요한 접점을 의미한다. 서버는 반드시 API를 구축해 놓아야 한다. 듣기론, 프로젝트를 진행할 때 백엔드 엔지니어가 API를 문서화해서 프론트엔드 엔지니어에게 제공하면 프론트 엔지니어는 문서를 참고해서 올바른 요청을 작성해서 서버의 리소스를 불러올 수 있다고 한다. 

 

HTTP의 특성

HTTP는 다음과 같은 두 가지 중요한 특성을 가지고 있다. 

1) Connectionless 

 클라이언트와 서버는 데이터 교환이 이루어지지 않은 상황일때는 항상 연결이 끊어져 있는 상태다. 클라이언트가 요청을 보낼때마다 매번 새로운 연결이 생성되고 서버가 응답을 하고나면 그 연결은 즉시 끊어진다. 즉, 클라이언트와 서버는 매번 초면이다. 

 

2) Stateless

HTTP의 특성인 Connectinoless의 결과로 HTTP는 Stateless하다. 매 연결마다 서로 초면이기 때문에, 전에 통신을 한적이 있더라도 그 통신했던 내용에 대해서는 전혀 모른다.

 예를 들면, 클라이언트가 "좀 있다 뭐 먹을거야? " 라고 서버에 응답을 보낸다면 서버는 "순대국밥"이라고 응답을 할 것이다. 이 연결이 끊어진 후, 다시 클라이언트가 "아까 뭐 먹는다고 했었지?"라고 다시 요청을 보낸다면 서버는 "?? 뭔 말이야?" 라고 전에 응답했던 내용을 기억하지 못할 것이다.

이것이 바로 Stateless다. Stateless는 일관된 방식으로 사용자가 페이지와 상호작용하길 원할 때, 결함이 될 수 있다. 만약 어떤 사이트에 로그인을 하고 그 사이트의 다른 페이지로 이동할때 로그인이 상태가 풀리는 경우가 그것이다. 그럼 이럴때마다 매번 로그인을 해주어야 할까? 지금 우리가 쓰는 사이트들을 보면 그렇지 않은 것을 볼 수 있는데, 그 이유는 상태를 저장할 수 있는 도구인 cookie나 session을 이용하면 상태를 저장할 수 있다. 

 

HTTP의 연결

좀 더 깊이 들어가면,

HTTP는 클라이언트와 서버의 '연결'을 담당하진 않는다. 그 이유는 OSI 7계층에서 HTTP는 application(응용)계층에 속하는데, '연결'은 Transfer(전송)계층에서 담당하고 있기 때문이다. 즉, HTTP는 연결을 요구만 할 뿐 실제 연결은 Transfer계층에서 담당한다.

 

OSI 계층모델 : OSI 모형은 국제표준화기구에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다. 일반적으로 OSI 7 계층이라고 한다 

 

전송계층에는 TCP 그리고 UDP프로토콜이 있다. TCP는 양방향 통신을 지원하면서 속도는 UDP에 비해 느리지만 신뢰성이 있고 UDP는 단방향 통신을 지원하면서 신뢰성이 낮지만, 속도는 TCP보다 빠르다. HTTP는 클라이언트/서버 양방향 통신을 해야하기 때문에 TCP통신을 채택하고 있다. 

 

이를 통해 HTTP 연결의 Flow를 보면 

1. 클라이언트는 TCP 연결을 이용해서 HTTP규칙에 맞게 서버로 요청을 보낸다. 이때, 요청 메시지는 HTTP/1.0버전에서는 누구나 읽을 수 있지만 HTTP/2.0에서는 읽을 수 없다. 

2. 서버는 그 요청에 맞는 응답을 보낸다. 

3. 클라이언트는 응답을 읽고 연결을 닫거나 재사용한다. 

 

여기서 재사용된다는 말이 HTTP의 특성에 위배되는 말이 아닌가? 하는 의문이 있었는데, 만약 클라이언트가 요청을 재사용해도 서버는 그 요청을 기억하지 못하기 때문에 HTTP특성에 위배되지 않는다고 볼 수 있다. 

 

HTTP 메소드

HTTP 메소드 정리 

클라이언트는 서버에 요청할 때 메소드를 통해 요청을 조금 더 구체화 할 수 있다.

 

GET	GET 메소드는 특정 데이터를 서버로 부터 요청할 때 사용한다.
POST	POST 메소드는 특정 데이터를 서버에 저장할 때 사용한다. 서버 상태의 변화를 일으킨다.
PUT	PUT 메소드는 서버에 있는 데이터 전체를 수정한다. 요청 시 교체할 모든 필드가 필요한데, 만약 특정 필드가 누락되어 요청된다면 그 필드는 초기값으로 처리된다.
PATCH	PATCH 메소드는 PUT메소드와는 달리 서버 데이터 일부만을 수정한다. 요청 시 수정할 부분의 필드만 body에 담아 요청하면 된다.
DELETE	DELETE 메소드는 특정 리소스를 삭제한다.
CONNECT	CONNECT 메서드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다. (MDN설명)
OPTIONS	OPTIONS 메서드는 목적 리소스의 통신을 설정하는 데 쓰입니다. (MDN설명) => CORS 요청시

 

HTTP 상태코드

HTTP 상태 코드 정리 

상태코드는 요청에 대한 서버의 응답을 번호를 정해서 의미를 부여한 것이다. 100번대부터 500번대까지 있는데, 번호대별로 정말 많은 의미의 상태코드가 정의되어 있다. 이것을 다 정리하진 않고, 요약한다.

 

100번대 : 첫번째 요청을 받았고, 나머지 요청을 기다림을 의미한다.  

200번대 : 요청이 성공적으로 수행됬음을 의미한다. 

300번대 : 요청을 받았지만, 클라이언트에게 추가적인 작업이 필요함을 알리는 것을 의미한다. 

400번대 : 요청이 실패했음을 의미한다. (클라이언트의 잘못된 요청) 

500번대 : 요청이 실패했음을 의미한다. (서버의 오작동)

 

 

HTTP 개념하나로 정리할 것이 너무 많다. 이 방대한 개념이 머릿속에 쏙쏙 들어왔으면 좋겠다.