카테고리 없음

HTTP 간단 총 정리( 프로토콜, HTTP METHOD, 상태코드, Header, body, 캐쉬 값)

진짠 2024. 6. 21. 17:19
728x90

들어가며

 HTTP는 웹 개발자 중 백엔드 개발자는 물론 프론트엔드 개발자에게도 필수적으로 알아야할 지식 중 하나라고 생각합니다. 웹을 사용하려면 웹 브라우저를 사용하고 이 웹 브라우저에서 일어나는 일련의 과정들에 HTTP가 필수적인 요소이기 때문입니다. 저는 이 HTTP의 개념에 대해 대강 알고 있는 수준이었습니다. 실무에서 필요한 부분만 그때그때 익혀 사용하는 수준이었어요. 그래서 이번 기회에 총 정리하는 느낌으로 개념을 잡아놓으면 업무에 큰 도움이 될 것이라 판단했습니다. 사실 왜 미리 하지 않았을까 하는 후회가 더 큽니다. 참고로 공부는 인프런의 김영한 선생님의 강의를 들었습니다. 어떤 기술에 대한 설명을 스토리처럼 이해하기 쉽게 설명해주셔서 추천하는 강의입니다!

 

 말그대로 넓은 범위의 과목을 간단 정리한 것이라 가독성이 매우 떨어지는 것 같습니다.(다시 읽어보는데 저야 강의를 들은지 얼마 안돼서 괜찮은데 처음 보신 분들은 혼란 그 자체일듯..) 공부한 내용을 상기시키는 목적으로 작성하였으니 만약 아래 내용을 읽으신다면 가볍게 흐름을 훑는 정도로 보시는 것을 추천합니다..

 

TCP

 

TCP 특징은 다음과 같은 특징을 가집니다.

  1. 연결지향 - TCP 3 way handshake : 상대방과 연결이 되어있는지 확인함.
  2. 데이터 전달 보증 - 메시지 전달이 안되면 알 수 있게 해줌
  3. 순서 보장
  • TCP 3 way handshake
    1. SYN
    • ‘야 너 잘 있냐, 연결해도 되냐?(connect, 연결 과정 정보)’
    1. SYN + ACK
      • ‘어 잘 있다, 연결할게~’
    2. ACK
      • ‘어 알았다, 나도 연결할게~’
    3. 데이터 전송( 요새는 3과4 동시에)
      • 잘못된 순서가 있으면 다시 보내라고 요청해서 순서 보증

UDP

  • UDP
    1. 기능 없음(IP와 거의 동일)
    2. 대신 포트가 추가됨(+체크섬)
      1. 포트 존재이유 : 하나의 IP로 여러개의 프로그램을 실행하기 위해 포트를 구분
      2. 체크섬은 메시지가 맞는지 검증해주는 데이터.
    3. 데이터 전달 및 순서가 보장되지 않지만 단순하고 빠름.
  • 대부분 TCP가 점유를 했는데 최적화를 진행하면서 빠르게 하기 위해 UDP를 쓰기도함.
  1. TCP 패킷 정보(출발, 도착 port 정보)
    • 0~1023 : 잘 알려진 포트로 사용하지 않은 것이 좋음
    • 65535가 최대
  2. DNS
    • IP는 외우기 어렵고 변경될 수 있다. 바뀌면 접근할 수 없음.
    • 그래서 DNS서버에서 도메인명을 등록해놓으면 아이피 주소가 바뀌거나 해도 찾아갈 수 있다.
  3. URI
    • resource locater와 name을 동시에 갖고 있음. 자원 자체를 식별
    • resource locater만 있는 것은 url
    • resource name만 있는 것은 urn
    • 프로토콜 : 어떤 방식으로 자원에 접근할 것인가 하는 약속, 규칙
    • ex) http, https, ftp …
    • 웹 브라우저에서 도메인 주소를 입력했을때
      1. DNS 조회
      2. IP와 PORT 조회
      3. HTTP 요청 메시지 생성
      4. socket 라이브러리로 전달(포트,ip 번호)
      5. tcp/ip에서 패킷 생성
      6. 서버에서 http 메시지 해석
      7. http 응답 메시지 생성(http status, content-type, content-length, content)
      8. tcp 패킷과 함께 전송
  • HTTP
    • html 전송하는 프로토콜로 처음에 시작했으나 이제는 모든 형태의 데이터를 전송하는 프로토콜을 사용
    • 1.1v를 가장 많이 사용하고 이후 2,3버전은 성능 개선용
    • 1, 1/2 - TCP, 3 - UDP
    • 클라이언트/서버 구조
      1. request/response 구조
      2. 클라이언트가 서버에 요청 보내고 응답을 대기
      3. 서버는 요청에 대한 결과를 만들어 응답
      4. 클라이언트는 UI대한 것만 집중, 서버는 비즈니스 로직에 대한 것으로 구분하는게 독립적으로 진화하는데 중요
    • 무상태 프로토콜
      1. 서버가 클라이언트의 상태를 유지하지 않음(stateless)
      2. 차이를 보면 과거의 문맥을 보존하는 것과 항상 처음보는 상태로 요청을 보내는 것
      3. stateful하게 되면 ‘점원’ 이 바꼈을 때 이해하지 못함. 그래서 다른 ‘점원’ 으로 바뀌면 안됨.(점원 a한테 가서 이거 주세요, 그리고 점원 b한테 가서 카드로 계산할게요, 하면 점원 b는 카드로 계산하는 거만 알고 뭘 사는지 모름)
      4. stateless하게 되면 ‘점원’ 이 바껴도 이해함. → 서버를 막 늘려도 관리가 가능.(점원 a한테 가서 이거 주세요, 점원 b한테 가서 이거 주시고 카드로 계산할게요, 하면 점원 b도 이해가능)
      5. 한계 : 모든 것을 무상태로 하기 힘들다, 데이터 전송량의 차이.
    • 비연결성
      • 장점
      1. 요청, 응답을 보낼때만 연결을 유지함. → 서버의 자원을 효율적으로 유지 가능
      2. 초 단위 이하의 빠른 속도로응답
      3. 수천명이 서비스를 이용해도 실제 서버의 처리 요청은 작을 수 있음.
      • 단점
      1. TCP 연결을 새로 맺어야 해서 3 way handshake 시간 추가
      2. 웹 브라우저로 사이트를 요청하면 html 뿐만 아니라 css, javascript, image등이 함께 다운로드됨.
      • 그래서 지속 연결로 문제 해결
        1. 연결 후 html 요청 응답하는 과정 계속 유지하다가 마지막에 종료
    • HTTP 메시지로 구성
      • 시작라인, 헤더, 공백라인, 메시지 바디로 구성
      • 시작라인
        1. request-line : 메서드(get/post), target, http version
        2. status-line : http version, status code, reason
        3. header-field : field-name : value(메시지 바디에 없는 메타데이터 정보), 임의로 추가가능
        4. message body : 실제 전송할 데이터(모든 종류 가능)
    • 단순함, 확장 가능
  • HTTP 메서드
    1. http api 만들기
      • 이름을 지을 때 - 리소스의 의미만 담아라.(회원 조회,등록,수정,삭제 - member로)
      • URI는 리소스만 식별하고 행위는 분리한다. 행위는 Http Method로(get,post,put,delete)
    2. GET
      • 리소스 조회
      • query 파라미터로 전달
    3. POST
      • 요청 데이터를 처리하는 역할
      • 주로 신규 데이터 등록, 프로세스 처리에 사용
      • 클라이언트가 메시지 바디에 담아 전달
      • 응답 데이터에 등록 결과와 어떤 경로에 등록했는지 정보를 담아 전달
      • 요청 데이터를 처리하는데(프로세스의 변화가 일어날때), 리소스가 생성되지 않아도 사용
      • uri는 리소스명만으로 하는 것이 좋지만 불가능한 경우 컨트롤 URI를 사용하기도 한다.
      • JSON으로 조회 데이터를 넘겨야 하는데 GET METHOD를 사용하기 어려운 경우
    4. PUT
      • 기존 리소스를 ‘완전히’ 대체
      • 리소스가 없으면 생성
      • 클라이언트가 리소스의 구체적 위치를 알고있음.( ex /members/100)
    5. PATCH
      • 기존 리소스를 부분만 대체
      • 지원이 안되는 서버가 있을 수 있음.(POST로 대체)
    6. DELETE
      • 제거
  • HTTP METHOD 속성
    • 안전 : 여러번 호출했을때 리소스 변경이 일어나면 안전하지 않다고 판단.
    • 멱등(Idempotent)멱등하지 않은 것은 POST METHOD. 따라서 두번 호출하면 안된다.
      • 활용
        • 자동 복구 매커니즘(장애 발생 시 똑같은 호출을 반복해도됨)
      멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.(즉 동일한 사용자가 똑같은 요청을 하는 것으로 판단)
    • : 1,2,100 호출하든 최종 결과는 항상 똑같은 것.
    • 캐시가능
      • 응답 결과 리소스를 캐시해서 사용해도 되나? GET, HEAD 정도만 캐시로 사용
      • POST, PATCH는 사용은 가능하지만 본문 내용까지 캐시 키로 고려해야 해서 구현이 쉽지 않음.
  • 클라이언트에서 서버로 데이터 전송
    1. 쿼리 파라미터로 전달해서 사용(GET)
      • 검색어에서 정렬 필터
    2. 메시지 바디를 통한 전송(POST, PUST, PATCH)
    • 정적 데이터 조회(image, text)
    • 쿼리 파라미터 미사용, 단순 조회
    • 동적 데이터 조회(쿼리 파라미터)
    • 파라미터 기반으로 동적 데이터를 조회해서 응답
    메시지 바디를 통해 GET을 전달하기도 하지만 지원하지 않는 서버도 있어 실무에서 권장하지 않음.
    • POST 전송 - 저장전송 데이터는 url encoding처리
    • Content-type form 설정 후 body 에 message request
    • 파일 전송(multipart/form-data)
    • 텍스트 뿐만 아니라 파일을 전송할때 Content-type을 바꾸고 각 파트의 경계를 자르고 각각의 데이터를 분리해서 넣어준다.
    • form data 전송은 get, post만
    HTTP API 전송
    • 서버 to 서버
    • 앱 클라이언트
    • 데이터 전달 표준은 json이다. 과거에는 xml이었으나 용량도 더 크고 보기 어려움

정리 : 정적 데이터 조회(그냥 이미지같은), 동적 데이터 조회(쿼리 파라미터), 폼 데이터(회원가입, 상품주문, 데이터변경), HTTP API(회원가입, 상품주문, 데이터변경, 서버to서버, 앱,웹클라이언트(ajax, android)

  • 컬렉션
    1. 서버가 관리하는 디렉토리
    2. 서버가 리소스를 생성하고 관리
    3. 회원등록 시 POST /member로 API 보낼 경우 컬렉션은 /member가 된다.
    4. POST 등록의 경우 서버가 url을 관리하지만 PUT 등록의 경우 클라이언트가 url을 알고 관리해야한다.
  • 스토어
    1. 클라이언트가 url을 관리하는 것
  • URL 설계 개념
  • https://restfulapi.net/resource-naming
  • 상태코드
    • 1xx : 요청이 수신되어 처리중
    • 2xx: 요청 정상 처리
    • 3xx: 요청을 완료하려면 추가 행동 필요
      • 302,307,303 : 일시적 리다이렉션, new-url로 저장하지 않음
      • 300, 304 : 기타 리다이렉션, 304는 캐시에 있는 데이터를 쓰라고 알려주는 것(메시지 바디 포함 안함)
      • 301, 308 : 영구 리다이렉션, 301은 POST로 보내면 GET으로 바꾸고 본문을 지우지만 308은 POST로 하고 데이터 보존
      • 301 : url이 과거에서 바꼈을때 new-url과 301코드를 줘서 클라이언트가 다시 new-url로 보냄.
    • 4xx: 클라이언트 오류, 잘못된 문법으로 서버가 요청을 수행할 수 없을때
      • 401인증(Authentication) : 본인이 누구인지
      • 404 : 잘못되 url 호출
      • 403: 권한 오류 401은 미확인 사용자이고 403은 권한의 차이가 있음.
    • 5xx: 서버 오류, 정상 요청을 처리하지 못할 때
      • 500 서버 문제 오류PRG(POST-REDIRECT-GET) : POST로 프로세스 처리 후 GET으로 리다이렉트함
      • 503 서비스 이용불가(뭔가 점검이나 장애)
      • 재실행했을때 성공할 가능성이 있음.
  • HTTP 헤더
    • 표현 헤더
      1. content-type: 형식
      2. content-Encoding: 압축 방식(서버에서 해당 스펙으로 압축 해제)
      3. content-Language: 자연 언어
      4. content-Length: 길이
    • 컨텐츠 네고시에이션
      • 클라이언트가 선호하는 표현으로 요청
        1. Accept: 클라이언트가 선호하는 미디어 타입(xml, json..)
        2. Accept-Charset : 문자 인코딩
        3. Accept-Encoding: 압축 인코딩
        4. Accept-Language: 자연 언어
        협상 헤더는 요청 시에만 사용구체적인 것이 우선순위가 높다.
      • 우선순위의 배율을 맞춘다(1, 0.9, 0.8…)
      • 우선순위 : 원하는 것의 순서를 정해줌.(사이트 방문 시 사이트가 다중 언어를 지원하면 네고시에이션을 통해 1순위 한국어 2순위 영어를 판단)
    • 데이터를 전송하는법
      • 단순전송
      • 압축전송(content-encoding 필요)
      • 분할전송(transfer-encoding 필요, content-length 노필요)
      • 범위전송
    • From
      • 유저 에이전트의 이메일 정보(요청에서 사용)
    • Referer : 어디서 유입된건지 파악 가능
      • 현재 요청된 페이지의 이전 웹 페이지 주소(많이씀)
    • User-Agent : 어디서 장애가 발생하는지, 혹은 분석에 도움
      • 클라이언트의 애플리케이션 정보(web,app,android,…)
    • Server
      • 요청을 처리하는 origin 서버(데이터를 만들어주는 진짜 서버)의 소프트웨어 정보
    • Host(필수)
      • 도메인 정보를 입력(서버가 해당 호스트 정보를 확인할 수 있음)
    • Allow
      • 허용 가능한 HTTP 메서드(잘 쓰지 않음)
    • Retry-After
      • 유저 에이전트가 다음요청을 하기까지 기다리는 시간(서버 오류로 인해)
    • 인증
      • Authorization : 인증에 관련된 값을 전달(OAuth, jwt)
    • 캐시 
      • 캐시 적용 - 헤더에 cache-control(캐시 유효 시간)
      • 서버에 최초 요청 후 → 브라우저 캐시에 유효 시간만큼 저장 → 다음 요청 시 캐시 먼저 조회(네트워크 탈 필요 없음)→브라우저 로딩 속도 빠름, 빠른 사용자 경험
      • 캐시 시간 초과 되었을때는 서버 조회 후 시간 갱신.
      • Last-Modified : 최종 수정 시간을 기록.
        • 캐시가 만료된 경우 이 값을 헤더에 보내면 서버에서 자신이 갖고 있는 파일과 최종 수정 시간을 비교한다. 만약 이 값이 같다면 서버는 304응답값(수정 안됨)과 함께 바디 없이 보낸다. 클라이언트는 이 값을 받고 캐시 데이터를 사용한다. 이 경우 용량을 많이 줄일 수 있다.
        • 검증 헤더(Last-Modifed)와 조건부 요청(if-modifed-since)를 함께 사용
      • 조건부 요청 단점 : 데이터를 수정했는데 같은 데이터로 수정해서 데이터 자체는 똑같은 경우, 내가 임의로 캐시 로직을 짜고 싶을 경우 짤 수 없다.
      • if-modified-since - 변경이 안됐으면 304(캐시로 리다이렉션 해라.), 변경이 됐으면 200(모든 데이터 전송)
      • ETag - 캐시용 데이터에 임의의 고유한 버전 이름을 담음. 변경되면 이 이름을 바꿔 변경, Etag가 같은지 다른지 판단해서 조건부 요청(If-None-Match)
      • cache-controlno-cache : 데이터는 캐시해도 되지만 항상 origin 서버에 검증하고 사용
      • no-store : 데이터를 저장하지 않음(메모리에서 사용하고 최대한 빨리 삭제)
      • max-age : 캐시 유효 시간, 초단위
      • 프라그마, Expires - 캐쉬의 하위호환
    • 캐시가 없을때 - 똑같은 정보를 계속 서버에서 다운로드 받아야함.(느린 사용자 경험)
    • 캐시 컨트롤
      • 프록시 캐시
        • 웹 브라우저가 원 서버까지 도달하기 너무 머니까 프록시 캐시 서버를 두어 요청속도를 향상
        • 로컬 캐시는 private cash, proxy cash는 public cash
        • 개인적인 정보들은 프라이빗에다 저장
    • 확실한 캐시 무효화 응답
      • no-cache, no-store, must-revalidate
      • pragma : no-cache(옛날 브라우저에서 가끔사용해서 넣어줘야 확실하게 무효화 가능)

마치며

 넓은 범위이지만 HTTP의 전체적인 데이터 흐름을 파악할 수 있는 뜻깊은 시간이었습니다. 까먹기 쉬운 내용들이라 여러번 복습이 필요할 듯 하고 필요한 부분은 더 깊게 파서 볼 기회를 가져야겠다고 생각했습니다.(캐시, HTTP Method 라던가...)

 

 

728x90