HTTP의 특징

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

---

 

 

HTTP 특징

1. 2대의 컴퓨터가 통신시 클라이언트와 서버의 역할로 나뉨

1. • 리퀘스트를 보내는 측이 클라이언트, 리퀘스트에 대한 리스폰스를 보내는 측이 서버

2. 리스폰스는 먼저 리퀘스트를 수신해야 발생함

3. HTTP는 상태를 유지하지 않는(stateless) 프로토콜

• 범위성(많은 데이터를 매우 빠르고 확실하게 처리하는 것)을 확보하기 위해
  • 똑같은 서버에 리퀘스트를 보내도 이전 리퀘스트의 정보를 유지하지 않음
• 웹이 발전함에 따라, 쇼핑 사이트에 로그인하는 과정에서 로그인 정보를 유지해야 하는 등의 경우가 생김
  • HTTP/1.1: 쿠키(Cookie) 기술 도입→상태 관리 가능

4. 리퀘스트 URI로 수신 측(서버)에 위치한 리소스를 식별

리소스 식별 방법

1. 모든 URI(도메인 이름+경로)를 리퀘스트 URI에 포함
2. Host 헤더 필드에 네트워크 로케이션(도메인 이름)을 포함

• • 자기 자신에게 리퀘스트를 송신→리퀘스트 URI를 [*]로 지정

 

 

---

 

 

HTTP 메소드

HTTP는 메소드를 통해 서버에게 임무를 부여

GET

• 리퀘스트 URI로 식별된 리소스를 요구→서버 측에서 리소스를 해석한 뒤 리스폰스 전달

POST

• 서버 측에 엔티티를 전송할 때 사용
  • GET으로도 엔티티 전송 가능하지만(쿼리 스트링), 일반적으로 POST 사용
• 리스폰스: 데이터의 처리 결과를 반환

PUT

• 파일 전송 목적으로 사용
• 리퀘스트 중에 포함된 엔티티를 리퀘스트 URI로 지정한 곳에 보존하도록 요구
• 인증 기능이 없어 누구나 파일 업로드 가능한 보안상 문제→인증 기능과 짝을 이루거나, REST와 같이 웹끼리 연계하는 설계 양식을 사용할 때 이용하는 경우 존재
• 리스폰스: 상태 코드 204(No Content) 리스폰스 반환

HEAD

• GET과 동일하게 리소스를 요청하지만, 메시지 바디(리소스 데이터)를 돌려주지 않음
• 사용 목적: URI 유효성, 리소스 갱신 시간 확인
• 리스폰스: 요청과 관련된 리스폰스 헤더만을 반환

DELETE

• 파일을 삭제하기 위해 사용
• PUT과 단점은 똑같음→인증기능 X, 인증 기능과 결합하거나 REST에서 사용, 응답 코드로 204 보내는 등

OPTIONS

• 리퀘스트 URI로 지정한 리소스가 제공하고 있는 메소드 종류를 조사하기 위해 사용
• 리스폰스: Allow 헤더 필드를 통해 서버가 제공하는 메소드 종류 반환

TRACE

• 웹서버에 접속해서 자신에게 통신을 되돌려 받는 루프 백(Loop Back) 발생
• 목적: 프록시 등을 중계하여 오리진 서버에 접속할 때 동작을 확인하기 위해
• Max-Forwards라는 헤더 필드에 수치를 포함시켜, 서버를 통과할 때마다 그 수치를 1씩 줄여나가고, 수치가 0이 된 곳에서 상태 코드 200 OK 리스폰스를 되돌려줌
• 크로스 사이트 트레이싱(XST)과 같은 공격을 일으키는 보안 상의 문제 존재→잘 사용되지 않음
• 리스폰스: 리퀘스트 내용을 리스폰스에 포함시켜 되돌려줌

CONNECT

• 원하는 서버와 TCP 연결을 프록시 서버에 요구→프록시가 클라이언트를 대신해 원하는 서버에 연결 생성 대신 진행(터널링)

프록시를 통한 터널링 방식

1. CONNECT 요청 전송
2. 443 포트로 TCP 커넥션 생성(프록시→서버)
3. 커넥션 생성을 알림(서버→프록시)
4. 커넥션 준비 메시지 반환: 리스폰스 내용은 200 OK
5. (커넥션 끊길 때까지) 모든 데이터가 클라이언트와 서버 사이에서 양방향으로 전달

<CONNECT 메소드의 양식>
CONNECT [프록시 서버] : [포트] [HTTP 버전]

 

HTTP 1.0 버전에는 LINK, UNLINK 메서드가 존재했지만, 1.1 이후로 폐기되어 지원 종료

 

 

---

 

 

HTTP가 접속량을 절약하는 방법

HTTP가 널리 보급되면서 컴퓨터 간 오고 가는 데이터량이 늘어남에 따라 접속량을 절약할 필요성이 생김

지속 연결(persistent Connections)

• TCP 커넥션을 명시적으로 종료하기 전까지는 TCP 연결을 계속 유지하는 방식→연결하고 종료하는 오버헤드를 줄여 서버 부하를 낮춤
• 개별 연결에 의한 여러 리퀘스트보다 빠르게 응답

파이프라인화(HTTP Pipelining)

• 클라이언트와 서버 간 파이프라인을 통해 리퀘스트 송신 후 리스폰스가 오지 않아도 바로 다음 리퀘스트를 병행해서 송신 가능
• 지속 연결보다 빠르게 응답

 

 

---

 

 

쿠키를 이용한 상태 관리

HTTP의 스테이스리스 프로토콜이라는 특성을 남겨둔 채 상태 저장 기능을 추가하기 위한 방법으로 쿠키가 고안

작동 방식

쿠키를 가지지 않은 상태

1. 리퀘스트 송신
2. 서버 측에서 쿠키 발행, 누구에게 무엇을 전달했는지 기록
3. 쿠키와 함께 리스폰스 전달

• Set-Cookie 헤더 필드를 통해 쿠키 전달

쿠키를 가진 경우(2회째 이후 리퀘스트)

1. 리퀘스트에 쿠키 붙여 송신

• Cookie 헤더 필드에 쿠키 정보 추가

2. 서버는 리퀘스트와 함께 전달된 쿠키를 통해 클라이언트 식별 후 리스폰스 가능