- 1999년에 rfc2616 버전이 나왔고, 2014년에 rfc7230~7235의 등장으로 인해 폐기됨
예시의 표현 데이터는 회원 정보를 html로 표현함
2. 표현
자연 언어는 한국어인지 영어인지 등을 뜻함application/json 은 기본이 utf-8큰 규모의 사이트(ex: 애플) 접속시 한국쪽에서 접속시 영어가 뜨면 한국어로 변환할지 등 클라이언트에서 부가적인 작업을 하도록 할 수 있다
3. 콘텐츠 협상
클라이언트가 영어를 사용하는지 한국어를 사용하는지에 대한 정보 없음, 서버는 기본값인 영어로 응답함헤더로 처리but 클라이언트는 독일어보단 영어를 원함ko-KR은 퀄리티 값이 생략되어 있음클라이언트는 독일어보다 영어를 선호함(우선순위 통해 알아낸 것)
4. 전송 방식
한 번에 요청하고 한 번에 받는 것무엇으로 압축되었는지 알리기 위해 Content-Encoding 사용나눠진것을 먼저 보낼 수 있음, 마지막엔 0 \r\n 으로 표현, 분할을 통해 오는대로 바로바로 표시할 수 있는 이점이 있음, Content-length 사용 불가 > 예상이 안되기 때문, 분할된 것마다 길이가 따로 표시됨절반정도 받고 끊겼을 때 다시 요청할 때 처음부터 다시 받는것이 아닌 일정 범위만 받음, Content-Range 사용
5. 일반 정보
ex: 구글을 통해 위키백과를 들어가면 referer에 구글이 표시됨, referrer의 오타임을 알기개발자 모드의 network의 name의 header에서 확인 가능origin 서버 >> http 요청을 보내면 중간에 여러 프록시 서버들을 거치는데, 실제 http 요청이 도착해서 응답을 해주는 서버
6.
매우 중요서버는 요청이 aaa.com / bbb.com / ccc.com 중 어디 들어갈지 판단 불가host 헤더 필드로 위의 문제 해결url 경로는 있는데, 위 예시에는 post 가 제공 안됨, 응답에 나머지 3가지 메서드를 지원한다는 내용을 포함시켜야 함, 사용을 많이 하지는 않기에 참고 수준으로만 보기실제로 사용하기 쉽지 않음, 복구 시간 예측이 쉽기 않기 때문
7. 인증
인증마다 헤더의 값이 다름, http 관련된 Authorization 헤더는 어떤 메커니즘인지는 상관없이 일단 헤더를 제공공홈 예제: 인증을 하려면 www-Authentication(401 오류이 이 헤더 이용)의 값을 이용해야 함
8. 쿠키
웹브라우저는 '안녕하세요 홍길동님'을 기대했지만 but 손님으로 응답, 서버 입장에서는 요청으로 로그인한 사용자인지 아닌지 구분 불가
- http는 기본적으로 무상태 프로토콜 >> 클라이언트와 서버가 요청과 응답을 주고받으면 연결이 끊어짐 (물론 지속연결을 통해 어느정도 유지도 가능), 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못함
- 위 문제는 stateless 와 관련된 문제
모든 요청에 사용자 정보 포함하면 개발이 불편해짐웹 브라우저 내부에 쿠키 저장소가 있음, 키 user 값 홍길동을 저장, 홍길동에 대한 정보를 쿠키 값으로 그대로 넘기진 않고 세션키를 서버에서 만들어 서버db에 저장하고 이것을 쿠키로 클라이언트에게 반환로그인 이후에 웹 브라우저가 welcome 페이지에 들어가면 자동으로 저장된 쿠키 값 이용해 서버에 보냄(Cookie 헤더를 생성)쿠키는 세팅되면 계속 서버에 보내지게 됨, 이를 방지하려면 웹 스토리지 참고세션 쿠키의 예시: 웹브라우저 종료했다가 다시 접속했을 때 재 로그인 하는 경우생성한 쿠키가 아무 사이트 들어갈 때마다 생성되는 것을 방지하기 위함js에서 원래 쿠키 접근 가능 >> HttpOnly 통해 전송시에만 사용 가능하게 함
- Samesite 는 아직 적용된지 오래된지 않아 브라우저에서 어느정도까지 지원하는지 확인하고 사용해야 함
2-1. 캐시 기본 동작
위 세줄은 헤더, 아래는 이미지와 관련된 바이트 코드cache-control은 캐시가 유효한 시간(예제는 60초 동안 유효)
- ex: 두번째 요청은 캐시 유효 시간을 검증하고 유효하면 캐시에서 조회함(네트워크 필요x)
웹 브라우저 한 번 들어갔던 곳을 다시 들어갔을 때 빨리 열림 >> 캐시가 적용되었기 때문
- ex: 세번째 요청은 캐시 유효시간이 초과됨 >> 재 요청 필요
유효 시간 이후에는 서버가 가지고 있는 데이터와 캐시가 가진 데이터가 다를 수도 있음
- ex: 클라이언트가 보유한 캐시가 만료됨, 클라이언트와 서버가 보유한 데이터가 동일함, 그런데도 다시 다운받는것은 비효율적
>> 아래에서 설명
2-2 검증 헤더와 조건부 요청
초록색 별은 데이터 변경을 뜻함Last-Modified 헤더 추가됨, 예제는 편의상 한글로 적었고 원래는 UTC표기법 사용2-12-2 서버에서 데이터 변경 여부를 검증 가능2-3 수정된게 없기에 body 제외한 start line과 header 이용해 응답 생성해 전달2-42-5 캐시에서 데이터 불러와 사용웹 브라우저는 대부분 이 메커니즘 채용
기존 데이터가 a 일 때, a > b > a 로 변경하면 결과는 같지만 날짜 정보가 변경됨파일을 해쉬 알고리즘에 넣어 해쉬 결과를 받을 수 있음(해쉬 알고리즘은 파일이 동일하면 똑같은 결과값), a>b>a는 같은 해쉬값임, 이 값으로만 판단1 - 서버에서 eTag를 내려줌2 - eTag값을 저장2-12-2 기존값과 다르면 이라는 요청을 보냄2-3 기존값과 같음(매치 됨) >>실패 (매치가 안될때 요청인데 매치가 되었기에 실패)2-4 데이터가 변경되지 않았기에 304 상태코드 를 보내고, body는 보내지 않음2-5 기존 캐시 재활용2-6
2-3 캐시와 조건부 요청 헤더
지금은 거의 사용하지 않음만료일 보다는 초단위 설정이 더 유연한 설정 가능
2-4 프록시 헤더
사용자의 요청시간이 오래걸릴 수 있는 원 서버의 경우(국가가 미국이라 멀다) 프록시 캐시 서버를 한국에서 설치하고 이것을 거쳐 연결이 되도록 함 > 시간 단축
- 프록시 캐시 서버 덕에 해외 영상 유튜브를 빠르게 볼 수 있음
첫번째 유저는 느리지만, 한번 다운받으면 두번째 유저부터는 빠르게 접근 가능
- 원 서버: 진짜 자원과 리소스가 있는 서버
- public 캐시: 중간에서 공용으로 사용하는 캐시 서버
- private 캐시: 웹 브라우저나 로컬에 저장되는 캐시
private 캐시에 저장해야 되는것은 프록시 캐시가 되면 안됨 (로그인 후 사용자 정보는 캐시가 되면 안됨, 공용으로 사용하는 이미지등은 가능)
