💡 프록시(Proxy) : '대리', '대신' 이라는 뜻을 가지며, 프로토콜에 있어서는 대리 응답 등에서 사용하는 개념이다. 💡 프록시서버 : 클라이언트와 서버 사이에 존재하며, 중계기로서 대리로 통신을 수행하는 것을 Proxy라고 하며, 그 중계 기능을 하는 주체를 Proxy Server라고 한다. 💛 프록시 서버 종류 포워드 프록시 : Client 와 Server 사이에 위치하여 요청을 중계하며, 요청과 응답은 Proxy Server를 거친다. 클라이언트를 감추는 효과가 있다. 💛 리버스 프록시 : 포워드 프록시와 마찬가지로 요청과 응답이 Proxy Server로 이동하는데, 포워드 프록시와 다르게 Server들이 주로 내부망으로 구성되며 프록시에게만 연결을 허용한다. 즉 서비스를 위한 보안 채널을 ..
💡 웹 서버 : 정적인 컨텐츠 (html, css, js)를 제공하는 서버이다. ex) Apache, Nginx 💛 역할 HTTP 프로토콜을 기반으로 하여 클라이언트(웹 브라우저 또는 웹 크롤러)의 요청을 서비스하는 기능을 담당한다. 요청에 따라 아래의 두 가지 기능 중 적절하게 선택하여 수행한다. 기능 1) 정적인 컨텐츠 제공 WAS를 거치지 않고 바로 자원을 제공 기능 2) 동적인 컨텐츠 제공을 위한 요청 전달 클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다. 클라이언트는 일반적으로 웹 브라우저를 의미한다. 💡 WAS(Web Application Server) : DB 조회나, 어떤 로직을 처리해야 하는 동적인 컨텐츠를 제공..
💡 SSL(Secure Socket Layer) 이란? : SSL은 Certificate Authority(CA)라고 불리는 곳에서 서버와 클라이언트의 인증을 하는데 사용됨. 즉 웹 서버와 클라이언트의 통신 암호화 프로토콜이다. HTTP 프로토콜 상위에 통신 시 보안을 위한 SSL 관련 프로토콜이 있는 방식이다. SSL이 적용되지 않은 통신의 경우, 위 그림과 같이 평문(Plain Text)가 그대로 전송된다. 만약 제 3자가 어떠한 방식으로든 통신 패킷을 탈취할 경우, 그 내용을 쉽게 확인할 수 있다. SSL을 적용할 경우 요청을 암호화해서 보내므로 통신 패킷이 탈취되도 복호화 키가 없으면 원래 내용을 알 수 없기 때문에 이러한 부분이 기술적으로 해결된다. 👉 HTTPS VS HTTP : HTTP는 H..
💡 학습 내용 정리 인터넷 네트워크 인터넷 통신 IP(인터넷 프로토콜) TCP, UDP PORT DNS URI와 웹 브라우저 요청 흐름 URI 웹 브라우저 요청 흐름 HTTP 모든 것이 HTTP 클라이언트 서버 구조 Stateful, Stateless 비 연결성(connectionless) HTTP 메시지 HTTP 메서드 HTTP API를 만들어보자 -> HTTP API 만들기 첫 시도 HTTP 메서드 - GET, POST HTTP 메서드 - PUT, PATCH, DELETE HTTP 메서드 속성 HTTP 메서드 활용 클라이언트에서 서버로 데이터 전송 HTTP API설계 예시 HTTP 상태 코드 HTTP 상태코드 소개 2XX 성공 3XX 리다이렉션1 - 영구 리다이렉션 3XX 리다이렉션2 - 일시 리다이..
💡 캐시 무효화 Cache-Control 확실한 캐시 무효화 응답 Cache-Control:no-cache, no-store, must-revalidate Pragma : no-cache HTTP 1.0 하위 호환 👉 Cache-Control 캐시 지시어(directives) - 확실한 캐시 무효화 Cache-Control : no-cache 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!) Cache-Control : no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제) Cache-Control : must-revalidate 캐시 만료 후 최초 조회 시 원 서버에 검증해야 함. 원 서버 접근 실패 시 반드시 오류가 발생해야 함 -..
💡 프록시 캐시 👉 Cache-Control 캐시 지시어(directives) - 기타 Cache-Control : public 응답이 public 캐시에 저장되어도 됨 Cache-Control : private 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값) Cache-Control : s-maxage 프록시 캐시에만 적용되는 max-age Age : 60 (HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
💡 캐시와 조건부 요청 헤더 * 캐시 : 자주 사용하는 데이터나 값을 미리 복사해 놓는 임시 장소 Cache-Control : 캐시 제어 Pragma : 캐시 제어(하위 호환) Expires : 캐시 유효 기간(하위 호환) 👉 Cache-Control 캐시 지시어(directives) Cache-Control : max-age 캐시 유효 시간, 초 단위 Cache-Control : no-cache 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용 Cache-Control : no-store 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제) 👉 Pragma 캐시 제어(하위 호환) Pragam : no-cache HTTP 1.0 하위 호환 👉 Expi..
💡 검증 헤더와 조건부 요청2 검증 헤더 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 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.1M (헤더 0.1M, 바디 0M) 데이터 변경 예시 캐시 : 2..
💡 검증 헤더와 조건부 요청1 👉 캐시 시간 초과 캐시 만료 후에도 서버에서 데이터를 변경하지 않음 생각해보면 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다. 단 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법 필요 👉 검증 헤더 추가 - 304 Not Modified : 수정된게 없다. - HTTP Body 전송 안하므로 부하 줄일 수 있다. 👉 검증 헤더와 조건부 요청 정리 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답 (바디X) 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신 클라이언트는 캐시에 저장되어 있는 데이터 재활용 결과적으로 네트워크 다운로드가 발생하지만 ..
💡 캐시 기본 동작 👉 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 매우 느리고 비싸다. 브라우저 로딩 속도가 느리다. 느린 사용자 경험 👉 캐시 적용 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다. 이때 다시 네트워크 다운로드가 발생한다. ✔ 이때 캐시가 가지고있던 데이터와 서버가 가지고 있던 데이터가 일치한다면 굳이 다시 불러올 필요가 있을까?
