컴퓨터공학의 기초가 되는 cs지식을 되새기면서 이 후 있을 기술면접을 대비 하고자한다.
초기에 Html과 같은 하이퍼미디어 문서를 주로 전송했지만, 최근에는 JSON,XML, 등 다양한 형태의 정보도 전송하는 애플리케이션 레이어 프로토콜이다.
또한 초기에 웹 브라우저와 웹 서버 간의 커뮤니케이션을 위해 디자인 되었지만 최근에는 모바일 애플리케이션 및 IoT 등과의 커뮤니케이션과 같이 다른 목적으로도 사용되고 있다고 한다.
HTTP는 클라이언트가 요청을 생성하기 위한 연결을 연 다음 응답을 받을 때까지 대기하는 전통적인 클라이언트-서버 모델을 따른다.
HTTP는 무상태 프로토콜이며, 이는 서버가 두 요청 간에 어떠한 상태나 데이터를 유지하지 않음을 의미한다. (상태를 유지하기 위한 노력으로 Cookie와 Session을 사용한다.)
일반적으로 안정적인 TCP/IP 레이어를 기반으로 사용하는 응용 프로토콜이다.
즉, 인터넷에서 데이터를 주고 받을 수 있도록 하는 프로토콜이다.
HTTP는 클라이언트-서버 프로토콜이다. 요청은 하나의 개체, 사용자 에이전트(또는 대신하는 프록시)에 의해 전송된다. 대부분의 경우 사용자 에이전트는 브라우저지만 무엇이든 될 수 있다.
Ex) 검색엔진 인덱스를 채워넣고 유지하기 위해 웹을 돌아다니는 로봇이 그러한 경우
각각의 개별적인 요청들은 서버로 보내지며, 서버는 요청(request)을 처리하고 응답(response)를 제공한다 이 요청과 응답 사이에는 여러 개체들이 존재한다
Ex) 다양한 작업을 수행하는 게이트 웨이, 캐시 역할의 프록시 등이 있다.
실제로는 브라우저와 요청을 처리하는 서버 사이에는 많은 컴퓨터들이 존재한다고 한다.
(라우터, 모뎀, 등이 해당) 웹의 계층적인 설계 덕분에, 이들은 네트워크와 전송 계층 내로 숨겨진다. HTTP는 애플리케이션 계층의 최상위에 있다. 네트워크 문제를 진단하는 것도 중요하지만, 기본 레이어들은 HTTP의 명세와는 거의 관련이 없다.
서버에게 요청을 보내는 리소스 사용자 (ex : 웹 브라우저 )
사용자 에이전트는 사용자를 대신하여 동작하는 모든 도구다. 이 역할은 주로 브라우저에 의해 수행된다 엔지니어들과 자신들의 애플리케이션을 디버그하는 웹 개발자들이 사용하는 프로그램들은 예외라고 생각하면 된다.
브라우저는 항상 요청을 보내는 개체다.수년에 걸쳐 서버 초기화된 메시지를 시뮬레이션하기 위해 몇 가지 메커니즘이 추가되어 왔지만 그것은 결코 서버가 될 수 없다
클라이언트에게 요청에 대한 응답을 제공하는 리소스 관리자
통신 채널의 반대편에는 클라이언트에 의한 요청에 대한 문서를 제공하는 서버가 존재한다. 서버는 사실 상 논리적으로 단일 기계다. 이는 로드(로드 밸런싱) 혹은 그때 그때 다른 컴퓨터(캐시, DB 서버, e-커머스 서버 등과 같은)들의 정보를 얻고 완전하게 혹은 부분적으로 문서를 생성하는 소프트웨어의 복잡한 부분을 공유하는 서버들의 집합이기 때문이다.
서버는 반드시 단일 머신일 필요는 없지만, 여러 개의 서버를 동일한 머신 위에서 호스팅 할 수는 있다. HTTP/1.1과 Host 헤더를 이용하여, 동일한 IP 주소를 공유할 수도 있다.
웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달한다. 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않는다.
이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시라고 부른다. 프록시는 눈에 보이거나 그렇지 않을 수도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있다.
즉, 프록시는 간단히 말해 클라이언트와 서버 사이의 중개인이다. 프록시는 클라이언트와 서버 중간에 위치하면서 클라이언트의 모든 HTTP 요청을 받아 서버에 전달하고 서버의 HTTP 응답을 클라이언트에게 전달한다.
클라이언트(웹 브라우저, 모바일 등)가 브라우저를 통해서 어떠한 서비스를 URI를 통해 서버에 요청(Request)하면 서버에서는 해당 요청에 대한 결과를 응답(Response)하는 형태로 동작한다.
GET
특정 리소스를 받기 위한 요청이다. 따라서, 리소스의 생성, 수정 및 삭제 등에 사용해서는 안된다.
POST
리소스를 생성하거나 컨트롤러를 실행하는 데 사용한다.
PUT
변경 가능한 리소스를 업데이트하는 데 사용되며 항상 리소스 식별 정보를 포함해야 한다.
PATCH
변경 가능한 리소스의 부분 업데이트에 사용되며 항상 리소스 식별 정보를 포함해야 한다.
PUT을 사용해 전체 객체를 업데이트하는 것이 관례여서 거의 사용되지 않는다.
DELETE
특정 리소스를 제거하는 데 사용한다.
일반적으로 Request body가 아닌 URI 경로에 제거하려는 리소스의 ID를 전달한다.
HEAD
클라이언트가 본문 없이 리소스에 대한 헤더만 검색하는 경우 사용한다.
일반적으로 클라이언트가 서버에 리소스가 있는 지 확인하거나 메타 데이터를 읽으려는 때만 GET 대신 사용한다.
OPTIONS
클라이언트가 서버의 리소스에 대해 수행 가능한 동작을 알아보기 위해 사용한다.
일반적으로 서버는 이 리소스에 대해 사용할 수 있는 HTTP 요청 메서드를 포함하는 Allow 헤더를 반환한다. (CORS에 사용)
요청(Request)
응답(Response)
HTTP는 중요한 정보를 주고 받을때 제 3자에 의해 조회될 수 있다.
이러한 문제를 해결하기 위해 HTTP에 암호화가 추가된 프로토콜인 HTTPS가 나온다.
여기서 HTTPS는 HTTP + SSL의 합성 개념이라고 생각하면된다.
SSL이란 인터넷을 통해 전달되는 정보를 보호하기 위해 개발된 통신 규약
HTTP는 원래 전송계층(TCP)을 통해 직접 통신했지만, HTTPS에서는 HTTP가 SSL과 통신하고 SSL이 전송계층(TCP)와 통신해서 더 안전하기 이용할 수 있게된다.
HTTP란 인터넷에서 데이터를 주고 받을 수 있도록 하는 프로토콜이다.
HTTP 기반의 시스템은 클라이언트(브라우저)- 프록시- 서버의 관계속에 있다.
여기서 프록시는 클라이언트와 서버의 요청 및 응답의 HTTP 메시지를 받아 넘겨주는 중개자 역할을 한다.
HTTP 메서드의 종류는 GET, POST,PUT, PATCH, DELETE, HEAD, OPTIONS 이 있다.
HEAD는 일반적으로 클라이언트가 서버에 리소스가 있는 지 확인하거나 메타 데이터를 읽으려는 때만 GET 대신 사용한다.
OPTIONS는 일반적으로 서버는 이 리소스에 대해 사용할 수 있는 HTTP 요청 메서드를 포함하는 Allow 헤더를 반환한다. (CORS에 사용)
메시지는 요청과 응답으로 나뉘는데
요청은 메소드,경로,프로토콜과 버전, 헤더
응답은 프로토콜과 버전, 상태코드, 상태메세지, 헤더
이처럼 나뉘게 된다.
References (참고 자료)