[네트워크] 애플리케이션 계층 - HTTP, Cookie, Web Cache

🟩 01. HTTP (HyperText Transfer Protocol) 이란?

HTTP는 인터넷에서 웹 페이지 같은 문서를 전송하기 위해 사용하는 프로토콜이다.

클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하며 통신한다.

 

01-01. HTTP는 TCP를 전송 프로토콜로 사용한다.

클라이언트는 먼저 서버에 TCP 연결을 시작한다. (3-way-handshake)

브라우저와 서버 프로세스는 소켓 인터페이스를 통해서 TCP를 접속한다.

 

클라이언트 프로세스 측 소켓 인터페이스

클라이언트 프로세스와 TCP 연결 사이에서의 출입구이다.

즉, 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고 HTTP 응답 메시지를 받기도 한다.

 

서버 프로세스 측 소켓 인터페이스

서버 프로세스와 TCP 연결 사이에서의 출입구이다.

즉, 서버는 소켓 인터페이스로 HTTP 요청 메시지를 받고 HTTP 응답 메시지를 소켓 인터페이스로 보낸다.

 

 

01-02. 서버는 클라이언트에게 요청 파일을 보낸다고 해도, 서버는 클라이언트의 상태 정보를 모른다.

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않는 비상태 프로토콜(stateless protocol)이다.

 

 

 

 

🟩 02. 비지속 연결 HTTP, 지속 연결 HTTP

클라이언트-서버가 통신할 때 일정한 간격으로 요구가 계속될 수 있다.

이 때 애플리케이션 개발자는 통신 요구를 "분리된 TCP 연결"로 진행할지 "같은 TCP 연결"로 진행할지 선택해야 한다.

 

02-01. "분리된 TCP 연결"은 "비지속 연결 HTTP"를 의미한다.

비지속 연결 HTTP (non-persistent connection)

클라이언트가 서버에 요청을 보내면, 서버는 해당 요청에 대한 응답을 보내고 연결을 종료한다.

즉, 매번 요청할 때마다 새로운 TCP 연결(3-way-handshake)을 진행해야 한다.

 

이러한 비지속 연결 HTTP는 오버헤드가 발생할 수 있다는 단점이 있다.

매번 연결을 맺고 끊는 과정이 있어야 하므로 전체적인 성능이 떨어진다.

 

이러한 비지속 연결 HTTP는 HTTP/1.0 이하 버전이다.

 

지속 연결 HTTP (persistent connection)

지속 연결 HTTP를 이용한다면 클라이언트-서버 통신 간에 연결을 유지하므로 한 번의 연결로 여러 요청과 응답을 주고받을 수 있다.

지속 연결은 HTTP/1.1부터 기본적으로 사용되고 있고 파이프라이닝(pipelining)을 이용한다.

물론 HTTP/1.1이상이라고 해도 클라이언트가 요청 헤더에 "Connection" 필드에 "close"값을 포함시켜 비지속 연결을 요청할 수도 있다.

 

 

 

🟩 03. HTTP 포맷

HTTP 프로토콜은 클라이언트와 서버가 통신할 때 사용한다.

이 때 "클라이언트 -> 서버" 그리고 "서버 -> 클라이언트"와 같이 통신할 때 어떤 메시지를 보내는지 알아보자.

 

클라이언트가 서버에게 리퀘스트 메시지를 보냈을 때를 먼저 알아보자.

03-01.  요청 메시지 (Request Message)

요청 메시지 안에는 "무엇을", "어떻게" 라는 내용이 담겨있다.

이 때 "무엇을"은 URI(Uniform Resource Identifier)를 나타내고, "어떻게"는 HTTP Method를 말한다.

 

조금 더 자세하게 들여다보자.

왼쪽은 HTTP Request Message의 포맷을 보여주고 있고

오른쪽은 GET 요청 HTTP Request Message 포맷을 보여주고 있다.

(GET 요청에 메시지 본문이 있을 수도 있지만 RFC 기준으로 지양하고 있기 때문에 넣지 않았다.)

 

HTTP 메시지 포맷을 "요청 메시지, 메시지 헤더, 메시지 본문"으로 나눠서 부를 수 있다.

그림으로 보는게 편할거 같아 밑을 참고해주길 바란다.

요청 메시지 (Request Message)

•  요청 내용을 간단하게 알 수 있다.

메시지 헤더 (Message Header)

• 한 행은 한 개의 헤더 필드를 의미한다.
• 요청의 부가적인 정보를 나타낸다.
• 행은 여러 행이 될 수 있기 때문에 고정적이지 않다.

헤더 필드의 종류	HTTP 버전		설명
	1.0	1.1
제네럴 헤더 : 요청, 응답 모두 사용하는 헤더 필드
Date	O	O	요청, 응답이 작성된 날짜
Pragma	O	O	데이터의 캐시를 허용할지의 여부를 나타내는 통신 옵션
Cache-Control		O	캐시를 제어하기 위한 정보
Connection		O	응답 송신 후에 TCP에 접속할지 연결을 끊을지 나타내는 통신 옵션
Transfer-Encoding		O	메시지 본문의 인코딩 방식을 나타낸다.
Via		O	도중에 경유한 프록시나 게이트웨이를 나태난다.
요청 헤더 : 요청 부가 정보로 사용하는 헤더 필드
Authorization	O	O	사용자 인증용 데이터
From	O	O	요청 발신자의 메일 주소
If-Modified-Since	O	O	지정한 날짜 이후 정보가 갱신된 경우에만 요청을 실행하기 위한 필드값. (클라이언트측에서 캐시에 저장한 정보를 비교하고, 새 정보를 받을 때 이용한다.)
Referer	O	O	하이퍼링크를 거쳐 어느 페이지를 읽은 경우 링크 대상 URI를 나타낸다.
User-Agent	O	O	클라이언트 소프트웨어의 명칭이나 버전에 관한 정보
Accept	▵	O	클라이언트측이 Content-Type으로 받는 데이터의 종류. MIME 사양의 데이터 타입으로 표현
Accept-Charset	▵	O	클라이언트측이 받은 문자 코드 세트
Accept-Encoding	▵	O	클라이언트측이 Content-Encoding으로 받은 인코딩 방식. 보통 데이터 압축 형식을 나타낸다.
Accept-Language	▵	O	클라이언트측이 받은 언어 종류.
Host		O	요청을 받은 서버의 IP 주소와 port 번호
If-Match		O	/* Etag */
If-None-Match		O	/* Etag */
If-Unmodified-Since		O	지정한 날짜 이후 갱신되지 않은 경우에만 요청을 실행한다.
Range		O	데이터의 전체가 아니라 일부만 읽을 때 범위를 지정한다.

메시지 본문 (Message Body)

• 클라이언트에서 서버에 송신하는 데이터를 의미한다.
• binary data로 취급한다.

 

03-02. 응답 메시지 (Response Message)

요청을 보냈다면 응답이 돌아온다.

응답 메시지는 요청 메시지의 포맷과 기본적인 개념은 같다.

다만 응답에는 실행 결과를 나타내는 스테이터스 코드(status code)와 응답 문구가 있다.

 

스테이터스 라인 (Status Line)

• 프로그램 등에 실행 결과를 알려준다.

코드값	설명
1xx	처리의 경과 상황 등을 통지한다.
2xx	정상 종료
3xx	무언가 다른 조치가 필요하다.
4xx	클라이언트측의 오류
5xx	서버측의 오류

메시지 헤더 (Message Header)

• 한 행은 한 개의 헤더 필드를 의미한다.
• 요청의 부가적인 정보를 나타낸다.
• 행은 여러 행이 될 수 있기 때문에 고정적이지 않다.

헤더 필드의 종류	HTTP 버전		설명
	1.0	1.1
제네럴 헤더 : 요청, 응답 모두 사용하는 헤더 필드
Date	O	O	요청, 응답이 작성된 날짜
Pragma	O	O	데이터의 캐시를 허용할지의 여부를 나타내는 통신 옵션
Cache-Control		O	캐시를 제어하기 위한 정보
Connection		O	응답 송신 후에 TCP에 접속할지 연결을 끊을지 나타내는 통신 옵션
Transfer-Encoding		O	메시지 본문의 인코딩 방식을 나타낸다.
Via		O	도중에 경유한 프록시나 게이트웨이를 나태난다.
응답 헤더 : 응답의 부가 정보로 사용되는 헤더 필드
Location	O	O	정보의 정확한 장소를 나타낸다.
Server	O	O	서버 소프트웨어의 명칭이나 버전에 관한 정보
WWW-Authenticate	O	O	요청 정보에 대한 액세스가 제한되어 있는 경우. 사용자 인증용 데이터를 반송한다.
Accept-Ranges		O	데이터의 일부만 요청하는 Range를 지정한 경우. 서버가 해당 기능을 가지고 있는지의 여부를 클라이언트에 통지한다.
엔티티 헤더 : 엔티티(메시지 본문)의 부가 정보로 사용하는 헤더 필드
Allow	O	O	지정한 URI로 사용 가능한 메서들르 나타낸다.
Content-Encoding	O	O	메시지 본문에 압축 등의 인코딩 처리가 되어 있는 경우 해당 방식을 나타낸다.
Content-Length	O	O	메시지 본문의 길이를 나타낸다.
Content-Type	O	O	메시지 본문이 어떤 데이터인지 종류를 나타낸다. MIME 사양으로 정의된 데이터 타입으로 데이터 종류를 나타낸다.
Expires	O	O	메시지 본문의 유효 기간을 나타낸다.
Last-Modified	O	O	정보를 최종 변경한 일시
Content-Language		O	메시지 본문의 언어를 나타낸다.
Content-Location		O	메시지 본문이 서버의 어디에 놓여있는지 위치를 URI로 나타낸다.
Content-Range		O	데이터의의 전체가 아니라 일부가 요청된 경우 메시지 본문에 어느 범위의 데이터가 포함되어 있는지 나타낸다.
Etag		O	이전 응답과 다음 요청을 관련시키기 위해 사용한다. 이전 응답에서 서버가 Etag에 따라 고유한 값을 클라이언트에 건네준다. 다음 요청에서 'if-Match', 'If-None-Match', 'If-Range' 필드에서 값을 서버에 통지하면 서버는 이전의 계속이라 인식한다. 쿠키와 비슷한 역할이지만 쿠키는 넷스케이프의 독자적인 사양이고 Etag는 표쥰화한 것이다.

메시지 본문 (Message Body)

• 서버에서 클라이언트에 송신하는 데이터, 파일이다.
• binary data로 취급한다.

 

 

 

🟩 04. 쿠키 (Cookie) : Stateless한 HTTP를 도와줄 수 있는 쿠키

HTTP는 Stateless하다.

이를 통해서 서버 설계가 간단해지고 훨씬 더 빠른 통신이 가능하다.

다만 사용자의 정보를 알지 못한다는 단점이 있다.

이 단점을 해소하기 위해서 "쿠키"라는 개념이 나왔다.

 

[RFC 6265]에 정의된 쿠키는 네 가지 기술 요소가 있다.

• HTTP 응답 메시지 쿠키 헤더 라인
• HTTP 요청 메시지 쿠키 헤더 라인
• 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
• 웹 사이트의 백엔드 데이터베이스

 

웹 사이트에서 쿠키를 많이 사용하고 있는데 이를 알아보도록 하자.

04-01. HTTP 응답 메시지 쿠키 헤더 라인

• 브라우저가 응답을 받았을 때 HTTP Response의 헤더에 <필드명>:<필드값>으로 "Set-cookie:식별번호"를 받게된다.

04-02. HTTP 요청 메시지 쿠키 헤더 라인

• 브라우저가 서버에 요청할 때 쿠키 헤더("cookie:식별번호")를 넣어보낸다.

04-03. 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일

• 백엔드 데이터베이스에서 브라우저의 쿠키에 관련된 정보를 저장한다.

04-04. 웹 사이트의 백엔드 데이터베이스

• 헤더로 받은 쿠키 식별번호로 사용자의 데이터를 전달한다.

 

 

 

🟩 05. 웹 캐싱(프록시 서버) : 웹 서버 대신 HTTP 요구를 충족 시키는 네트워크 개체

05-01. 웹 캐시

• 자체의 저장 디스크를 가진다.
• 최근 호출된 객체의 사본을 저장 및 보존한다.
• 브라우저는 사용자의 모든 HTTP 요청이 웹 캐시에 먼저 보내지도록 구성할 수 있다.

 

05-02. 웹 캐시를 이용하는 이유

• 클라이언트 요구에 대한 응답 시간을 줄일 수 있다.
• 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 줄일 수 있다.

간단하게 생각해보면 아래와 같은 상황에서 캐시로 요청을 보내는 편이 성능상 더 좋음을 알 수 있다.