Home 모든 개발자를 위한 HTTP 웹 기본 지식
Post
Cancel

모든 개발자를 위한 HTTP 웹 기본 지식

참고 강의

인터넷 네트워크

  • 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 접근금지)

캐시

  • 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 서버가 멋대로 가라응답 주는거 방지하고 에러코드 뱉도록 정의함.
This post is licensed under CC BY 4.0 by the author.

Flutter 초입문 왕초보편 (요약)

Spring boot 핵심 원리