HTTP의 특징
무상태 프로토콜
- stateful : 서버가 클라이언트의 상태를 보존하기 때문에 중간에 다른 서버로 변경이 불가능하다.
- Stateless : 서버가 클라이언트의 상태를 보존하지 않아 중간에 다른 서버로 변경 가능하다 -> 갑자기 클라이언트가 증가해도 서버를 대거 투입할 수 있다.
- Stateful은 로그인과 같은 상황에서 최소한으로 사용해야 확장성이 좋다.
비연결성
- HTTP는 클라이언트와 서버간의 연결을 유지하지 않는 모델이다. 이를 통해 서버 자원을 효율적으로 사용 가능하다.
- 한계
- 연결을 매번 새로 맺으면 3 Way handshake 시간이 계속 추가된다. 이를 HTTP 지속연결로 문제를 해결한다. - 지속연결 : 클라이언트 서버간 1번의 TCP연결을 통해 여러개의 request와 response를 주고 받을 수 있는 방법
HTTP API
API URI 설계
- 리소스 식별: 가장중요한 고려사항이다.
-ex) "회원을 등록해라"에서 리소스는 회원이다.우리는 회원 리소스를 URI에 매핑하면 된다.
• 회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id}
각각을 구분하기 위해 HTTP 메서드를 사용한다.
HTTP 메서드
• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성 (덮어쓰기)
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
PUT 은 클라이언트가 리소스를 식별한다. 즉, 클라이언트가 리소스 위치를 알고 URI를 지정한다. 이는 POST와는 다른 점이다.
HTTP 메서드의 속성
- 안전 : request로 호출해도 리소스를 변경하지 않는다.
- 멱등 : f(f(x))=f(x), 1번 호출한 결과와 100번 호출한 결과값이 같을때 - GET,PUT,DELETE 메서드 -> 자동복구 매커니즘에서 주로 활용된다.
- 캐시가능 : 응답결과 리소스를 캐시해서 사용해도 되는 여부
- '캐시해서' 의미: 응답이 클라이언트나 중간 캐시 서버에 의해 저장되어 후속 요청에 재사용 될 수 있다.
HTTP 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함
쿠키(Cookies)
- 쿠키는 클라이언트 측에 저장되는 작은 데이터로, 웹 서버에서 클라이언트로 전송됩니다. 쿠키는 클라이언트의 브라우저에 저장되며, 이후에 서버로의 요청 시에 함께 전송
- 사용자 세션 관리, 사용자 환경 설정 등을 위해 사용
- 특징
- 상태를 유지: 쿠키는 클라이언트 측에 저장되므로, 서버와 클라이언트 간의 상태를 유지할 수 있습니다.
- 유효기간 설정 가능: 쿠키는 만료 날짜를 설정하여 특정 시간 동안 유효할 수 있습니다.
- 보안 이슈: 쿠키는 클라이언트 측에 저장되므로 보안 상의 위험이 있을 수 있습니다. 따라서 중요한 정보는 쿠키에 저장하지 않는 것이 좋습니다.
캐시 (Cache)
- 캐시는 이전에 검색한 데이터의 사본을 저장하는 임시 저장소로, 이를 통해 이전에 받은 데이터를 재사용하여 웹 페이지 로드 속도를 향상시킴
- 성능 향상, 네트워크 부하 감소 등을 위해 사용
- 특징
- 캐시 제어: 캐시는 HTTP 헤더를 통해 제어됩니다. 서버는 캐시 지시자를 사용하여 클라이언트와 캐시 사이의 동작을 제어할 수 있습니다.
- 캐시 무효화: 서버가 데이터를 업데이트하면 캐시된 데이터를 무효화하여 새로운 데이터를 가져와야 합니다. 이를 위해 보통 캐시 제어 헤더를 사용합니다.
프록시 캐시 (Proxy Cache)
- 프록시 캐시는 클라이언트와 원격 서버 간의 중간에 위치한 프록시 서버에서 관리되는 캐시 시스템이다. 클라이언트가 요청하는 자원에 대한 사본을 프록시 캐시에 저장하고, 이후 동일한 요청이 있을 때는 원격 서버로부터 다시 요청하는 대신에 캐시된 자원을 제공
- 응답 시간 단축, 웹 페이지 로딩 속도 향상 등을 위해 사용
- 성능 향상: 프록시 캐시를 사용하면 클라이언트의 요청에 빠르게 응답하여 웹 페이지 로딩 시간을 단축시킬 수 있습니다.
- 네트워크 부하 감소: 캐시된 자원을 재사용함으로써 원격 서버로의 요청을 줄여 네트워크 부하를 감소시킵니다.
- 웹 서버 부하 분산: 프록시 캐시를 통해 요청의 일부를 처리하므로 웹 서버의 부하를 분산할 수 있습니다.
캐시 무효화
- 캐시 지시어(directives) - 확실한 캐시 무효화
- Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!) - Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨 - Cache-Control: must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증해야함
- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함 - Pragma: no-cache
- HTTP 1.0 하위 호환
no-cache vs must-revalidate
no-cache
ORIGIN 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라서 캐시 데이터를 반환할 수 있음
Error or 200 OK
(오류 보다는 오래된 데이터라도 보여주자)
must-revalidate
ORIGIN 서버에 접근할 수 없는 경우, 항상 오류가 발생해야 함
504 Gateway Timeout
(매우 중요한 돈과 관련된 결과로 생각해보자)
