최종 정리

HTTP는 클라이언트와 서버가 네트워크를 통해 데이터를 전송하는 애플리케이션 계층 프로토콜(규약) 이다
(https 는 http + 보안)

HTTP는 무상태 프로토콜을 지향한다
최대한 무상태 프로토콜로 구현하고 (뷰 페이지 등), 상태 유지는 최소한만 사용하는 것을 권장한다 (로그인 등)

기본적으로 통신이 끝나도 연결을 유지하는 TCP/IP 와 다르게,
HTTP는 비 연결성을 기본으로 한다
장점으로는 서버 자원을 효율적으로 사용할 수 있지만,
단점으로는 매번 연결을 새로 맺어야 하기에(3 way handsheke) 웹브라우저의 대기 시간이 길어진다
이 단점을 해결하기 위해 HTTP 지속 연결 이라는 방식을 사용한다
HTTP 지속 연결 : 일정 시간 연결을 유지하는 것

HTTP는 4파트로 분류된 메시지 형태로 통신한다 (시작라인, 헤더, 공백라인, 바디)
요청 메시지냐 응답 메시지냐에 따라 차이가 존재한다

시작라인 (요청)
- HTTP 메서드, 요청 대상

시작라인 (응답)
- HTTP 버전, HTTP 상태코드, 이유 문구

헤더
- HTTP 전송에 필요한 모든 정보

바디
- 실제 전송할 데이터 (모든 데이터 전송 가능)


HTTP API를 설계할 땐 리소스와 행위를 구분하는 것이 좋다
URI 에는 리소스로만 최대한 설계하고, 행위는 HTTP의 메서드를 사용하는 것이다
그걸로는 해결이 안된다면 컨트롤 URI를 사용한다

컨트롤 URI : 제약을 해결하기 위해 동사로 된 리소스 경로 사용 (POST의 /new, /edit, /delete 등)

메서드 종류는 기억에 너무 잘남아서 생략한다

HTTP 메서드의 속성은 안전, 멱등, 캐시가능 세가지가 있다
이 또한 기억에 잘남으니 생략

HTTP의 활용에 대해서는 개발 경험이 좀 쌓여야 제대로 된 이해가 가능할 것 같다

HTTP 상태 코드는 그것만 봐도 해당 메시지가 어떤 의미인지 알 수 있을 정도로 핵심적인 정보이다
1xx : 처리중
2xx : 성공
3xx : 추가 행동 요구
4xx : 클라이언트 오류
5xx : 서버 오류
이 정도만 정리하고, 자세한 내용은 생략한다
추가로 4xx 메시지를 보내는 상황에 대해서 잘 생각해야 5xx 메시지와 혼동하지 않을 것
(다양한 상황에서 올 수 있는 클라이언트의 오류를 서버 오류로 착각하면 삽질 시작...)

다음은 끔찍하게도 많은 정보가 들어가는 헤더를 정리해 보자
앞서 HTTP 메시지는 4파트로 분류된다고 했다
헤더는 그 자체만으로도 또 다시 4파트로 분류된다
- General 헤더 : 메시지 전체에 적용되는 정보    Connection : close
- Request 헤더 : 요청 정보  User-Agent: Mozilla/5.0 (Macintosh; ..)
- Response 헤더 : 응답 정보 Server: Apache
- Entity 헤더 : 엔티티 바디 정보 Content-Type: text/html, Content-Length: 3423

최신에 들어와서 Entity 헤더는 표현 헤더(Representation)라는 명칭으로 개정 됐다
표현 헤더 : 표현 데이터(Body)를 해석할 수 있는 정보 제공
- Type, Encoding(압축 정보), Language, Length 등이 있다

Request 헤더 : 클라이언트가 선호하는 정보
- 미디어 타입, 문자 인코딩, 압축 인코딩, 언어 등에 우선 순위를 매긴다
  (서버는 그 요청에 맞게 최선의 응답을 함)

전송 방식에는 단순 전송, 압축 전송, 분할 전송, 범위 전송 네가지 전송 방식이 있다
명칭을 제외하면 어려울 것 없기에 설명 생략

일반 정보, 특별한 정보, 인증 정보는 해당 카테고리로 이동해서 자세한 설명을 보자
요약하기 위한 본 글에서 풀기에는 힘들 듯
(실제 동작과 매우 밀접하기에 중요도는 결코 낮지 않음)


쿠키 : 기억하고자 하는 사용자 정보를 담는... 택배상자?

무상태 프로토콜의 성질을 가진 HTTP는 사용자 정보를 기억하지 못하기 때문에,
모든 요청에 사용자 정보를 보내지 않으면 기억하지 못할 것이다
예를들어 내가 로그인을 했다면,
비 로그인 상태와는 달리 사용자 정보가 유지되어야 웹브라우저를 이용할 수 있다
그 보완 방법으로 등장한 것이 쿠키이다


하지만 쿠키를 무제한으로 가지고 있다면 용량, 보안 등의 문제가 있을 것이다
그 때문에 쿠키에는 생명 주기 정보가 포함되어 있다
만료일이 되면 쿠키는 웹브라우저의 쿠키 저장소에서 삭제된다
- 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
- 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키의 도메인 정보와 경로 정보로 접근을 제한할 수 있다

쿠키의 보안에는 Secure, HttpOnly, SameSite 세가지가 있다
자세한 설명 생략... 하지만 대체로 이름 그대로의 의미이다
Secure이 https인 경우에만 전송한다는걸 제외하면... 그렇다

기본적으로 주민번호, 신용카드 등 민감한 데이터는 저장하면 안된다


캐시
한 화면에서 새로고침을 빠르게 반복한다고 생각해 보자
데이터는 전혀 변하지 않는데도 불구하고 서버는 항상 큰 용량을 차지하는 리소스(Body)를 내려주어야 한다
이를 해결하기 위해 사용하는 것이 캐시이다
웹 브라우저가 같은 요청을 한다면, 서버가 확인한 후 캐시 재사용을 지시한다면 Body의 전송 없이
비용과 시간을 절약할 수 있다

캐시 또한 쿠키와 마찬가지로 유효 시간이 있다
만료 되었다면 다시 서버에서 다운로드하게 된다
하지만, 여전히 웹브라우저의 캐시와 서버의 리소스가 동일하다면?
검증 헤더라는 것을 통해 웹 브라우저가 그것을 검증하고, 서버의 확인을 받았다면
캐시를 다시 세팅하여 재사용한다 (Body 다운로드 발생X)

검증 헤더는 두 가지가 있다
- Last-Modified, if-Modified-Since : 날짜 단위 검증
- ETag, if-None-Match : 고유 이름 검증
위 if... 를 조건부 요청이라고 부른다


캐시 또한 정보를 웹브라우저에 유지시키기 때문에 오류나 보안에 주의해야 한다
때문에 캐시 제어 헤더 라는 것을 통해 제어와 유효기간을 설정한다
총 세가지가 있지만, 실용적인 것만 뽑아본다
Cache-Control: max-age  유효시간
Cache-Control: no-cache 원 서버에서 검증
Cache-Control: no-store  저장 불가 (메모리에서만 사용하고 삭제)
Pragma : no-cache         원 서버에서 검증 (구버전 웹브라우저)

확실하게 캐시를 무효화 하려면 위 네가지 중, max-age를 제외하고 
Cache-Control: must-revalidate 를 추가하면 된다
그 이유는 캐시 무효화 태그에서 자세히 설명했다