HTTP

HTTP

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다.

HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며 클라이언트-서버 프로토콜이기도 합니다.

※ 클라이언트-서버 프로토콜 : 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다. 하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지 등 불러온 하위문서들로 재구성됩니다.

클라이언트와 서버들은 개별적인 메시지 교환에 의해 통신됩니다.

브라우저인 클라이언트에서 전송된 메시지를 요청입니다.

서버는 그 요청에 의해 메시지를 응답합니다.

HTTP는 애플리케이션 계층의 프로토콜로 신뢰 가능한 전송 프로토콜인 경우 이론으로 무엇이듯 사용가능하나 TCP, 암호화된 TCP 연결인 TLS를 통해 전송됩니다.

특징

 

1. 클라이언트 서버구조

─ 클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있습니다.

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

 

1. 무상태 프로토콜

─ HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜입니다.

• 서버가 클라이언트 상태를 보존하지 않음
• 장점으로 서버 확장성이 높습니다. (스케일 아웃)
• 단점으로 클라이언트 추가 데이터 전송됩니다.

 

비 연결성

─ HTTP는 기본 연결을 유지하지 않는 모델입니다.

• HTTP 1.0 기준으로 HTTP는 연결을 유지하지 않는 모델입니다.

 

─ 일반적으로 초 단위 이하의 빠른 속도로 응답됩니다.

• 트래픽이 많지 않고 빠른 응답을 제공할 수 있는 경우에 비 연결성의 특징은 효율적으로 작동됩니다.
• 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시 처리하는 요청은 수십 개로 매우 작습니다.

 

─ 트래픽이 많고 큰 규모의 서비스를 운영할 때는 비 연결성은 한계를 보입니다.

동작

클라이언트 브라우저를 통해서 어떠한 서비스를 url를 통하거나 다른 것을 통해 요청을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답하는 형태로 동작합니다.

정보 통신 문서로 Plain text, json, xml 같은 형태의 정보도 주고받을 수 있으며 보통 클라이언트가 어떤 정보를 형태를 명시해 주는 경우가 많습니다.

구성

요청은 하나의 개체, 사용자 에이전트(프락시)에 의해 전송됩니다.

대부분 사용자 에이전트는 브라우저이지만, 무엇이든 상관없습니다.

각각의 개별적인 요청들은 서버로 보내지며 서버는 요청을 처리하고 response라고 불리는 응답을 제공합니다.

클라이언트 : 사용자 에이전트

사용자를 대신해 동작하는 모든 도구입니다.

주로 브라우저에 의해 수행되며 엔지니어들과 자신들의 애플리케이션을 디버그 하는 웹 개발자들이 사용하는 프로그램들은 예외입니다.

브라우저는 항상 요청을 보내는 개체입니다.

웹 서버

통신 채널의 반대에는 클라이언트에 의한 요청에 대한 문서를 제공하는 서버가 존재합니다.

서버는 논리적인 단일 기계입니다.

서버는 반드시 단일 머신일 필요는 없지만 다중 서버를 동일한 머신 위에서 호스팅은 가능합니다.

HTTP/1.1 host 헤더를 이용하여 동일한 IP주소를 공유할 수도 있습니다.

프락시

프로토콜에 있어서는 대리 응답 등에서 사용하는 개념입니다.

클라이언트와 서버 사이에 존재하며 중계기로써 대리로 통신을 수행하는 것을 프락시라 합니다.

그 중계 기능을 하는 주체를 ‘프락시 서버’ 라 합니다.

종류

 

포워드 프록시 :

특정 사이트로 접속하려는 경우 목적지 사이트의 주소를 직접 프록시 서버에 전달하며 프록시 서버가 해당 목적지 사이트의 내용을 받아와서 전달해 주는 개념입니다.

캐싱 기능이 존재하여 자주 사용되는 콘텐츠들이라면 성능 향상을 가져올 수 있습니다.

프락시에서 접속 사이트 제한도 가능합니다.

 

리버스 프락시 :

요청, 응답이 프록시 서버로 이동하는 데 포워드 프락시와 다르게 서비스들이 주로 내부망으로 구성되며 프락시에게만 연결을 허용합니다.

서비스를 위한 보안 채널을 구축하는 것입니다.

클라이언트가 서비스에 직접 접근이 불가하여 리버스 프락시에서 요청을 적극적으로 중계하는

내부망의 역할을 수행하여 서버를 감추는 효과가 있습니다.

사용 목적

보안 : 서버의 주소가 쉽게 노출되는 경우 다른 익명의 사용자가 서버로 접근하기 쉬워지게 됩니다.

프락시 서버를 이용하는경우 다른 익명의 사용자는 서버의 위치를 알기 힘들어 서버의 IP를 숨기는 것이 가능하고 외부로부터 위험을 막아주는 역할을 합니다.

캐시를 사용한 속도 향상 : 프록시 서버는 웹페이지를 가져올 때 자신의 DB에 최근 데이터를 저장하고 이것을 캐시라고 합니다.

캐시에 저장되는 경우 동일한 요청이 올 때 캐시자원을 반환하여 서비스의 속도가 높아지고 대역폭도 줄일 수 있습니다.

로그 기록, 관리 가능 : 프락시 서버에는 클라이언트의 기록이 남습니다.

해당 기록은 분석하면 어떤 IP에 어떤 IP로 얼마나 접속 정보를 확인 가능하고 특정 IP가 방문할 수 있는 웹사이트 제한이 가능합니다.

접속 우회 가능 : 다른 나라에서 접속한 것처럼 우회가 가능합니다.

HTTP 메서드

주어진 리소스에 수행하길 원하는 행동을 나타내며 요청 메서드를 HTTP 동사라고 불립니다.

각각의 메서드는 서로 다른 의미를 구현하지만 일부 기능은 메서드 집합 간에 서로 고유합니다.

 

GET 리소스 조회

─ 만일 틀서버에 전달하고 싶은 데이터는 쿼리스트링을 통해 전달

─ 쿼리스트링 외에 메시지 바디를 사용해서 데이터를 전달할 수 있지만 서버에서 따로 구성해야 되기 때문에 지원하지 않는 곳이 많아서 권장하지 않습니다.

─ 캐싱이 가능합니다.

 

POST 요청 데이터 처리, 주로 등록에 사용

─ 전달한 데이터 처리/생성 요청 메서드

─ 메시지 바디를 통해 서버로 요청 데이터 전달하면 서버는 요청 데이터를 처리하여 업데이트합니다.

─ 전달된 데이터는 주로 신규 리소스 등록, 프로세스 처리에 사용됩니다.

─ 만일 데이터를 GET 하는데 JSON으로 조회 데이터를 넘겨야 하는 경우 POST 사용

 

PUT 리소스를 대체(덮어쓰기), 해당 리소스가 없으면 생성

─ 리소스를 대체(수정)하는 메서드

─ 요청 메시지에 리소스가 있으면 수정, 없으면 신규 생성 합니다.

─ 데이터를 대체해야 하나, 클라이언트가 리소스의 구체적인 전체 경로를 지정해 보내주어야 합니다.

 

PATCH : 리소스 일부 부분 변경

─ 리소스 일부 분을 변경하는 메서드

─ 만일 지원하지 않는 서버에서는 POST를 사용할 수 있습니다.

 

DELETE 리소스 삭제

─ 리소스 제거하는 메서드

─ 상태코드는 거의 200을 사용하며 상황에 따라 204를 사용합니다.

HTTP 메서드의 속성

1. 안전

지속적으로 메서드를 호출해도 리소스를 변경하지 않는다는 뜻입니다.

주요 메서드 중에는 GET 메서드가 안전하다 할 수 있습니다.

1. 멱등성

메서드를 계속 호출해도 결과가 동일하다는 의미입니다.

GET, PUT, DELETE는 멱등하지만 POST, PATCH는 아닙니다.

1. 캐시가능

캐싱을 해서 데이터를 효율적으로 가져올 수 있다는 뜻입니다.

주로 GET, HEAD만 주로 캐싱이 쓰입니다.

HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능입니다.

1XX : 요청이 수신되어 처리 중

2XX : 요청 정상 처리

3XX : 요청을 완료하려면 추가 행동일 필요

4XX : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

5XX : 서버 오류, 서버가 정상 요청을 처리하지 못함