참고 강의
인터넷 네트워크
- ip 는 그냥 위치정보만 알려줌. 그래서 이것만으로는 너무 부실함
- tcp 는 전송방식, 순서, 검증 이런거 하게해줌.
- tcp / ip 꼴라보로 신뢰성있는 통신을 할 수 있게됨
- 3 way handshake (sync / sync ack / ack)
- udp 는 그냥 ip 위에다가 포트정보만 추가해서 빈 도화지에서 자유롭게 데이터 주고받기 -> 빠름
- 이미지나 동영상보낼떄 udp 쓰라고 그랬었는데, tcp 가 점유율 90% 넘어갔다가 http 3.0 나오면서 다시 주목받고있는 중
웹브라우저
- uri = url + urn : urn 은 걍 무시하자
- url 치면 http 로 변경 -> tcp / ip 랩핑 -> 보냄
http
- http 2,3 은 성능개선에 초점. 1.1 이 사실상 가장 중요한 버전
- 특징
- 클라이언트 서버 구조
- 무상태 프로토콜,
- 상태 유지가되면, 중간에 다른 서버로 바뀌면 안된다.
- 중간에 서버가 바뀌어도됨. 서버를 여러개 투입해서 서빙하는 이미지를 생각해.
- 모든걸 무상태로는 못함. 로그인 같은건 어떻게 해결할까? 브라우저 쿠키 Session?, 데이터를 많이 보내는 단점도 있음.
- 비연결성
- 3 way handshake 하는 시간이 매번 추가됨
- keep-alive(persistent connection) 으로 성능 개선함. 그럼 비연결성 이라고 장점이라고 쓰면 될까..?
- 메세지를 통해 주고 받음
- GET / POST
- 사실 POST 로 모든걸 다 할 수 있어보이지만, 조회는 GET 쓰는게 좋음. Caching 떄문
- 메서드 속성
- 안전 : 변경하는거면 안전하지않은거임…
- 멱등 : 몇번요청하든 결과가 똑같다. POST 는 아님! 결제 여러번할수도잇음. (중간에 데이터 변경되는것 까진 고려하지않음)
- 캐싱
- 401 Unauthorized
- 인증이 되지않은거임
- 401발생하면 WWW-Authenticate 에 헤더와함께 인증방법 설명해야함.
- 사실은 UnAuthenticated 가 되어야할거 같은데 이름이 너무 아쉽다.
- 402 Forbidden
- 진짜 Unauthorized 인 경우. 인가가 안되어있는 경우.
http 헤더
- 표현(Representation) 이라고 하는 이유는 결국 특정 정보가 json 이건 html 이건 결국 ‘표현’ 되기 떄문
- 표현 헤더는 전송, 응답에 둘다 사용함.
- Content-Length, Encoding, Language
- 협상(Accept) Header : 요청시에만 사용함. ‘클라가 선호’하는걸 서버에 보낼 때 씀.
- Accept: 클라가 선호하는 미디어 타입
- Accept-Language:
ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
1부터 우선순위, 생략하면 1 - 협상 우선순위
- 구체적일수록 우선순위가 높다.
- 전송
- 분할 전송 : Transfer-Encoding: chunk 서버가 일부분씩 짤라서 보내는거
- 범위 전송
- 일반 정보
- Referer: 어디서 들어왔는지 볼 , User-Agent
- Retry-after 라는것도 있음.
- 인증
- Authorization: 클라이언트에서 서버에 인증 정보 전달함.
- WWW-Authenticate: 뭔 정보 참고해서 똑바로 인증만들고와
- Cookie
- 서버가 쿠키 줄 떈 Set-Cookie 응답에 포함되어있음.
Set-Cookie: user=홍길동
- expire, path, domain 들로 제약을 해둠.
- Cookie 는 클라가 서버로 올릴때 사용.
- Secure(https 에서만), HttpOnly(js 접근금지)
- 서버가 쿠키 줄 떈 Set-Cookie 응답에 포함되어있음.
캐시
- cache-control 로 제어함
- 근데 캐시만료되었을때 서버가 데이터 안변경했으면 굳이 또 받을필요가?
- 검증헤더 활용함.
Last-Modified(응답할떄)
,if-modified-since(보낼때)
-> 304 Not Modified 받으면 재활용함.- 근데 1초미만 캐시 조정이 불가능해서 날짜기반은 아무래도 정확하지 않음.
ETag
,if-none-match
라는걸 활용하는 검증 방법도 있음. 해당 리소스의 hash key라고 생각하면 됨.
- 검증헤더 활용함.
pragma, expire
는 하위호환 떄문임, 걍 버리고 cache-control 만 알고있자.- 캐시지시어
- cache-control: max-age
- cache-control: no-cache = 캐시해도되긴하는데, 항상 원서버 가서 검증하고 써라
- cache-control: no-store
- Proxy-cache (CDN)
- cache-control: private, public(proxy 에 저장해도 됨), s-maxage(프록시캐시서버 저장시)
- Age: origin 서버에서 응답후 프록시 캐시내 머문 시간.
- must-revalidate : 혹시나 proxy cache 에서 origin 서버가는길에 네트워크가 단절되었을때 proxy-cache 서버가 멋대로 가라응답 주는거 방지하고 에러코드 뱉도록 정의함.