oxdjww.log

Intro 본 포스팅에서는 프록시 캐시와 캐시 무효화에 대해 다룬다. 프록시 캐시 원(origin) 서버에 직접 접근 원 서버에 클라이언트가 직접 접근하여 리소스를 받게 되면 병목현상이 일어날 수 있다. 프록시 캐시 도입 첫 번째 요청 첫 번째 요청에는 프록시 서버를 거쳐서 원 서버로 요청이 가게 된다. 첫 요청에는 프록시 서버에 리소스가 없으므로 당연한 결과이다. 그리고 원 서버로부터 응답이 오게 되면, 캐시 서버는 이를 캐시로 저장한다. 두 번째 요청 두 번째 요청 시에는 프록시 캐시 서버가 클라이언트들에게 응답을 함으로서 더 빠른 속도로 응답할 수 있다. 이렇게 프록시 캐시 서버에서 저장할 수 있는 캐시를 public 캐시라고 한다. 반면에 클라이언트가 보유하고 있는 캐시는 private 캐시이다...

Intro 본 포스팅에서는 검증 헤더와 조건부 요청에 대해 다룬다. 검증 헤더와 조건부 요청이란? 검증 헤더 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 Last-Modified , ETag 조건부 요청 헤더 검증 헤더로 조건에 따른 분기 If-Modified-Since: Last-Modified 사용 If-None-Match: ETag 사용 조건이 만족하면 200 OK 조건이 만족하지 않으면 304 Not Modified 예시 If-Modified-Since: 이후에 데이터가 수정되었으면? 데이터 미변경 예시 캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00 304 Not Modified, 헤더 데이터만 전송(BODY 미포함) 전송 용량 0.1..

Intro 본 포스팅에서는 검증 헤더와 조건부 요청에 대해 다룬다. 캐시 시간 초과 캐시 유효 시간이 초과해서 서버에 다시 리소스를 요청하면 다음 두 가지 상황이 나타난다. 서버에서 기존 데이터를 변경하지 않은 경우 서버에서 기존 데이터를 변경한 경우 서버에서 데이터를 변경하지 않은 경우 그렇다면, 데이터를 전송해서 새로 받는 대신에 저장해 두었던 캐시를 재사용 할 수 있다. 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 식별자가 필요할 것이다. 첫 번째 요청 첫 번째 요청을 받은 서버는 클라이언트에게 리소스를 보낸다. 이 때, Last-Modified라는 필드에 날짜 값을 넣어서 보내게 된다. 이 값을 통해 해당 리소스의 최종 수정일을 알 수 있다. 웹 브라우저는 수신한 리소..

Intro 본 포스팅에서는 캐시 기본 동작에 대해 다룬다. 캐시의 필요성 클라이언트는 웹 서버에 다양한 리소스를 요청하고, 이를 요청하는 클라이언트는 다수이다. 이 때 캐시가 있는 상황과 없는 상황을 가정하고 캐시가 필요한 이유에 대해 학습할 수 있다. 캐시가 없을 때 첫 번째 요청 캐시가 없는 상황에서, 클라이언트가 star.jpg라는 이미지 파일을 서버에 요청해서 받아오는 상황이다. 서버가 클라이언트로부터 GET요청을 받고 이미지 리소스를 돌려주는데 이 때 데이터의 크기는 1.1M로, 헤더 0.1M과 이미지 파일 본체인 바디는 1.0M로 이루어져있다. 두 번째 요청 클라이언트로부터 몇번의 요청이 오든 서버에서는 같은 1.1M 크기의 파일을 전송한다. 데이터가 변경되지 않아도 계속 네트워크를 통해 데이..

Intro 본 포스팅에서는 인증(Authorization)과 쿠키(cookie)에 대해 다룬다. 인증이란? Authorization: 클라이언트 인증 정보를 서버에 전달하는 것이다. WWW-Authenticate: 리소스 접근시 필요한 인증 방법을 정의한다. Authorization 클라이언트측에서 클라이언트 인증 정보를 서버에 전달한다. 요청시 사용한다. Auth 등 다양한 인증 방식마다 value에 들어가는 값은 상이하다. WWW-Authenticate 서버측에서 리소스 접근시 필요한 인증 방법을 정의한다. 401 Unauthorized 응답시 함께 사용한다. WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basi..

Intro 본 포스팅에서는 HTTP의 일반 정보, 특별한 정보에 대해 다룬다. 일반 정보 일반적인 정보를 담은 헤더 필드들이다. From: 유저 에이전트의 이메일 정보 Referer: 이전 웹 페이지 주소 User-Agent: 유저 에이전트 애플리케이션 정보 Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보 Date: 메시지가 생성된 날짜 From 유저 에이전트의 이메일 정보이다. 일반적으로 잘 사용되지 않는다. 검색 엔진 등에서 주로 사용된다. 요청에서 사용한다. Referer 이전 웹 페이지의 주소이다. 현재 요청된 페이지의 이전 웹 페이지 주소 A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청 Referer를 사용해서 유입 경로 분석 가능 요청에서 사용 참..

Intro 본 포스팅에서는 HTTP의 전송 방식에 대해 다룬다. 전송 방식 HTTP 전송 시에는 다양한 전송 방식이 존재한다. 단순 전송 압축 전송 분할 전송 범위 전송 단순 전송 Content-Length로 길이를 명시하고, 단순히 전송한다. 압축 전송 Content-Encoding으로 압축 타입을 명시하고, 본문에는 압축된 데이터를 보낸다. 분할 전송 Transfer-Encoding필드에 chunked 값을 주고, 데이터를 분할하여 보낸다. 용량이 매우 큰 데이터를 보낼 때 사용한다. 총 크기를 예측할 수 없기에 Content-Length를 사용해선 안 된다. 범위 전송 범위를 지정해서 요청에 대한 응답을 받는 전송 방법이다. 데이터를 보내다가 모종의 이유로 중간에 끊겼을 경우, 처음부터 다시 받을 ..

Intro 본 포스팅에서는 표현(Representation)과 협상(Negotiation)에 대해 다룬다. 표현 즉, 표현 헤더는 다양한 http header로 이루어져 있는데 이는 header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) 위와 같은 형태를 띄고, 표현 헤더는 하단의 표현 데이터(==메시지 본문, 바디, 본문)를 해석할 수 있는 대표 정보라고 해석할 수 있다. 표현 헤더의 구조 Content-Type : 표현 데이터의 형식 Content-Encoding: 표현 데이터의 압축 방식 Content-Language: 표현 데이터의 자연 언어 Content-Length: 표현 데이터의 길이 표현 헤더는 HTTP 요청, 응답 둘다 사용 Co..

Intro 본 포스팅에서는 HTTP header의 개요에 대해 다룬다. HTTP Header란 header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용) 위와 같은 형식으로 구성되어 있으며, field-name에는 대소문자 구분을 하지 않는다. HTTP Header의 용도 HTTP 전송에 필요한 모든 부가정보 (start-line에서 명시된 정보를 제외하고) 메시지 바디의 내용, 메시지 바디의 크기, 압축 타입, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 ... 표준 헤더는 엄청 많다. ref : https://en.wikipedia.org/wiki/List_of_HTTP_header_fields 필요시 임의의 헤더를 추가할 수 있다. H..

Intro 본 포스팅에서는 HTTP 상태 코드에 대해 다룬다. HTTP Status Code Overview ref : https://forlater.tistory.com/371 상태 코드란? 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 1xx (Informational) : 요청이 수신되어 처리중 2xx (Successful) : 요청 정상 처리 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요 4xx (Client Error) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함 Unkown 상태코드가 나타나면? 클라이언트 입장에서는 상위 상태코드를 기반으로..