developer h1 developer h1

HTTP는 클라이언트와 서버가 네트워크를 통해 데이터를 전송하는 애플리케이션 계층 프로토콜(규약) 이다 (https 는 http + 보안) HTTP는 무상태 프로토콜을 지향한다 최대한 무상태 프로토콜로 구현하고 (뷰 페이지 등), 상태 유지는 최소한만 사용하는 것을 권장한다 (로그인 등) 기본적으로 통신이 끝나도 연결을 유지하는 TCP/IP 와 다르게, HTTP는 비 연결성을 기본으로 한다 장점으로는 서버 자원을 효율적으로 사용할 수 있지만, 단점으로는 매번 연결을 새로 맺어야 하기에(3 way handsheke) 웹브라우저의 대기 시간이 길어진다 이 단점을 해결하기 위해 HTTP 지속 연결 이라는 방식을 사용한다 HTTP 지속 연결 : 일정 시간 연결을 유지하는 것 HTTP는 4파트로 분류된 메시지 형..

Cache-Control 확실한 캐시 무효화 응답 - Cache-Control: no-cache, no-store, must-revalidate - Pragma: no-cache - HTTP 1.0 하위 호환 확실하게 캐시를 무효화 하려면 위의 요소를 모두 넣어 주어야 한다 no-cache : 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용 (이름에 주의) no-store : 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제) must-revalidate : 캐시 만료후 최초 조회시 원 서버에 검증해야함 - 원 서버에 실패 시 반드시 오류가 발생해야 함 - 504(Gateway Timeout) - must-revalidate는 캐시 유효 시간이라면 캐시를 사용..

origin 서버(원 서버) : 실제 리소스를 제공하는 서버 -원 서버가 미국에 있고, 한국에 있는 웹 브라우저들이 수많은 요청을 하게되면 대기시간이 길어진다 - 프록시 캐시 서버를 통하여 원 서버와 웹 브라우저 사이를 중계한다 (요청받은 데이터를 원서버 > 프록시 캐시 서버 > 웹 브라우저 순으로 다운로드) - 동일한 데이터를 요청 받으면 원 서버에 접근할 필요 없이 프록시 캐시 서버로만 대응이 가능해 진다 (많은 사람이 찾는 데이터일 수록 속도가 빨라지고, 그 반대 또한 가능하다) 웹 브라우저를 private 캐시, 프록시 캐시 서버를 public 캐시 라고 부른다 Cache-Control 캐시 지시어 - 기타 - Cache-Control: public - 응답이 public 캐시에 저장되어도 됨 -..

캐시 제어 헤더 - Cache-Control: 캐시 제어 - Pragma: 캐시 제어(하위 호환) - Expires: 캐시 유효 기간(하위 호환) Cache-Control 캐시 제어 - Cache-Control: max-age - 캐시 유효 시간, 초 단위 - Cache-Control: no-cache - 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용 - Cache-Control: no-store - 데이터에 민감한 정보가 있으므로 저장하면 안됨 (메모리에서 사용하고 최대한 빨리 삭제) 원서버란, 이전에도 말했듯이 서버가 하나만 존재하는 것이 아니라 여러개의 노드처럼 구성되어 있을 수도 있다 중간에 캐시 서버에서 캐시를 하는 등의 역할이 나뉘어져 있는데, no-cache가 붙을 ..

이전 글에서 캐시란 무엇인가와 캐시 유효 시간이 지난 경우 데이터가 같더라도 결국 다시 다운받아야 하는 한계에 대해 정리했다 캐시 유효시간이 초과해서 서버에 다시 요청하면 다음 두 가지 상황이 나타난다 - 서버에서 기존 데이터를 변경함 - 서버에서 기존 데이터를 변경하지 않음 캐시 시간 초과 - 캐시 만료후에도 서버에서 데이터를 변경하지 않음 - 데이터를 전송하는 대신에 저장해 두었던 캐시를 재사용 할 수 있다 - 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다 (데이터가 변하지 않았다는 증거) 그 방법이 바로 검증 헤더이다 cache-control: max-age=60 Last-Modified: 2020년 11월 10일 10:00:00

캐시가 없을 때 - 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다 - 인터넷 네트워크는 매우 느리고 비싸다 - 브라우저 로딩 속도가 느리다 - 느린 사용자 경험 캐시를 적용하면 - cache-control: max-age=60 - 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다 - 비싼 네트워크 사용량을 줄일 수 있다 - 브라우저 로딩 속도가 매우 빠르다 - 빠른 사용자 경험 캐시 시간 초과 - 캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다 - 이때 다시 네트워크 다운로드가 발생한다

쿠키 - Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답) - Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달 HTTP는 무상태 프로토콜이기 때문에, 사용자 정보를 기억하지 못한다 때문에 모든 요청에 사용자 정보를 포함하여 보내는 대안이 있다 그것은 보안이나 개발하기가 어려워진다 때문에 쿠키가 등장하게 됐다 웹브라우저가 사용자 정보를 보내면, 서버는 응답 메시지에 쿠기에 유저 정보를 담아(Set-Cookie) 보낸다 웹브라우저에는 쿠키 저장소가 있기 때문에, 그곳에 보관한다 다음부터는 자동으로 웹브라우저가 서버에 요청을 보낼때마다 쿠키값을 꺼내서 함께 보낸다 '모든' 요청에 쿠기 정보 자동 포함 쿠키 - 예) set-cookie: sessionId=a..

Host: 요청한 호스트 정보(도메인) Location: 페이지 리다이렉션 Allow: 허용 가능한 HTTP 메서드 Retry-After: 유저 에이전트가 다음 요청을 하기까지 걸리는 시간 Host - 요청에서 사용 - 필수 - 하나의 서버가 여러 도메인을 처리해야 할 때 - 하나의 IP주소에 여러 도메인이 적용되어 있을 때 (어느 도메인으로 들어갈지) Location - 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 - 응답코드 3xx에서 설명 - 201 (Created) : Location 값은 요청에 의해 생성된 URI - 3xx (Redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴 Allow..