본문 바로가기
서버/SPRING

http 네트워크 정리

by HDobby 2023. 7. 18.

김영한님 강의 http 정리입니다.

 

목차

     

    http란?

    • HTTP - HyperText Transfer Protocol
    • 거의 모든 형태의 데이터 전송 가능 - HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML
    • 클라이언트 서버 구조
      1. Request Reponse 구조
      2. 클라이언트 -> 서버 = 요청 및 응답 대기
      3. 서버 -> 클라이언트 - 응답
    • 무상태 프로토콜(Stateless)
      • 서버가 클라이언트의 상태를 보존X
      • 장점: 서버 확장성이 높음
      • 단점: 클라이언트가 추가 데이터 전송
      • 가게의 점원이 지속적으로 바뀜 - 무엇을 얼만큼 구매하는지 매번 설명 해야함
      • 응답 서버를 쉽게 교체 가능 -> 무한한 서버 증설(스케일 아웃)
      • 로그인이 필요 없는 단순한 서비스만 가능
      • 일반적으로 로그인의 경우 쿠키와 서버 세션등을 사용하여 상태 유지
    • 비연결성
      • 기본이 연결을 유지하지 않는 모델
      • 일반적으로 초 단위 이하의 빠른 속도로 응답
      • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
      • 수 많은 자원이 함께 다운로드
      • HTTP 지속 연결(Persistent Connections)로 문제 해결
    • 단순함, 확장 가능

     

    네트워크 용어들 정리

    • 인터넷 프로토콜 스택의 4계층
      • 애플리케이션 계층 - HTTP, FTP
      • 전송 계층 - TCP, UDP
      • 인터넷 계층 - IP
      • 네트워크 인터페이스 계층
    • IP(복잡한 인터넷 망에서 데이터를 전달하기 위한 목적지를 지정하기 위함 - 인터넷 주소)
      • 지정한 ip 주소에 데이터 전달
      • 패킷이라는 통신 단위로 데이터 전달
      • 비연결성(패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송)
      • 비신뢰성(중간에 패킷이 손실 가능, 패킷이 순차적으로 전송이 안될 수 있음)
      • 같인 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상시 문제
    • TCP - 전송 제어 프로토콜(Transmission Control Protocol)
      • 연결지향 - TCP 3 way handshake (가상 연결)
        1. 클라이언트 -> 서버 = SYN - 접속 요청 (서버가 살아 있는지 확인)
        2. 서버 -> 클라이언트 = SYN + ACK - 요청 수락
        3. 클라이언트 -> 서버 = ACK + 데이터 전송 or ACK
      • 데이터 전달 보증
        1. 클라 -> 서버 = 데이터 전송
        2. 서버 -> 클라 = 데이터 잘 받았다는 응답
      • 순서 보장
        1. 클라 -> 서버 = 패킷 1, 2, 3 순서로 전송
        2. 서버 = 패킷 1, 3, 2 순서로 도착
        3. 서버 -> 클라 = 패킷 2부터 재전송 요청
      • 신뢰할 수 있는 프로토콜
    • UDP
      • 하얀 도화지에 비유(기능이 거의 없음)
      • 연결지향 X
      • 데이터 전달 보증 X
      • 순서 보장 X
      • IP와 거의 유사 + PORT + 체크섬만 추가
      • 애플리케이션에서 추가 작업 필요
      • HTTP3로 인해 각광 받는 중!
    • PORT
      • 같은 IP 내에서 프로세스 구분
      • 100.100.100.1:10010
      • IP - 아파트, PORT - 101동 1010호
      • 0~65535 할당 가능
      • 0~1023 잘 알려진 포트, 사용하지 않는 것이 좋음
        • FTP - 20, 21
        • TELNET - 23
        • HTTP - 80
        • HTTPS - 443
    • DNS
      • 200.200.200.2 - IP는 외우기 힘들고 변동이 가능.
      • 전화번호 부와 같은 역할
    • URI, URL, URN
      • Uniform Resource Identifier - 소스를 식별하는 통합된 방법
        • Uniform - 리소스 식별하는 통일된 방식
        • Resource - 자원, URI로 식별할 수 있는 모든 것(제한 없음) : 데이터, html 등
        • Identifier - 다른 항목과 구분하는데 필요한 정보
      • 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.
      • URL - foo://example.com:8042/over/there?name=ferret#nose 리소스가 있는 위치를 지정
      • URN - urn:example:animal:ferret:nose 리소스에 이름을 부여
        • urn:isbn:8960777331 어떤 책의 isbn URN
        • 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
      • https://www.google.com/search?q=hello&hl=ko
        • scheme://[userinfo@]host[:port][/path][?query][#fragment] 
        • 프로토콜 - https
        • 호스트명 - www.google.com
        • 포트 번호 - 443, 포트는 생략 가능
        • 패스 - /search, 리소스 경로 /home/file1.jpg
        • 쿼리 파라미터 - (q=hello&hl-ko) key=value 형태, ?로 시작, &로 추가 가능
        • fragment - html 내부 북마크 등에 사용, 서버에 전송하는 정보가 아님
    • 웹 브라우저 요청 흐름
      • HTTP 메시지 전송 
        1. 웹 브라우저가 HTTP 메시지 생성
        2. SOCKET 라이브러리를 통해 전달
        3. TCP/IP 패킷 생성, HTTP 메시지 포함

     

     

     

    HTTP 메서드 및 설계

    • 리소스 식별을 중심으로 설계 해야 한다.
      • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
      • 회원이라는 리소스만 식별 -> 회원 리소스를 URI에 매핑
        • 회원 목록 조회 /members -  GET
        • 회원 조회 /members/{id} - GET
        • 회원 등록 /members - POST
        • 회원 수정 /members/{id} - PATCH, PUT, POST
        • 회원 삭제 /members/{id} -DELETE
        • 복수단어 사용
        • 행위를 분리
    • GET - 리소스 조회
      • 서버에 전달하고 싶은 데이터는 query를 통해서 전달
      • 메시지 바디를 사용할 수 있으나, 지원하지 않는 곳이 많아 권장 X
      • GET /members/100 HTTP/1.1 HOST: localhost:8080 -> 100번 멤버 전달 요청
    • POST - 요청 데이터 처리, 주로 등록에 사용
      • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
      • 주로 신규 리소스 등록, 프로세스 처리에 사용
      • 정해진 것이 없어 여러가지 기능에 사용
        • HTML FORM에 입력한 정보로 회원 가입, 주문 등
        • 게시판 글쓰기, 댓글 달기
        • 신규 주문 생성
        • 한 문서 끝에 내용 추가하기
        • 애매하면 무조건 POST
    • PUT - 리소스를 대체, 해당 리소스가 없으면 생성 INSERT ON DUPLICATE KEY UPDATE
      • 클라이언트가 리소스를 식별!
      • 클라이언트가 리소스 위치를 알고 URI를 지정
    • PATCH - 리소스 부분 변경(종종 지원이 안되는 경우가 있음 -> POST)
    • DELETE - 리소스 삭제
    • HEAD - GET과 동일하지만 메시지 부분을 제외, 상태 줄과 헤더만 반화
    • OPTIONS - 대상 리소스에 대한 통신 가능 옵션(주로 CORS에서 사용)
    • 속성
      • 안전(Safe Methods)
        • 호출해도 리소스를 변경하지 않는다.
        • GET, HEAD, OPTIONS
      • 멱등(Idempotent Methos)
        • 한 번 호출하든, 두 번 호출하든 100번 호출하든 결과가 똑같다.
        • GET, PUT(결과를 대체한다. 최종 결과는 같다.), DELETE(삭제된 결과는 같다.)
        • 자동 복구 메커니즘
        • 같은 요청을 다시 해도 되는가? 판단 근거
        • 다른 곳에서 리소스를 변경하는 것 까지는 고려하지 않음.
      • 캐시가능(Cacheable Methods)
        • GET, HEAD 정도만 캐시로 사용

     

     

    HTTP API 설계

    • 쿼리 파라미터를 통한 데이터 전송
      • GET
      • 주로 정렬, 필터
    • 메시지 바디를 통한 데이터 전송
      • POST, PUT, PATCH
      • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경
    • 정적 데이터 조회
      • 쿼리 파라미터 미사용
      • 이미지, 정적 테스트 문서
      • 조회는 GET 사용
      • 리소스 경로로 단순하게 조회 가능
    • 동적 데이터 조회
      • 쿼리 파라미터 사용
      • 검색, 게시판 목록에서 정렬, 필터
      • 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
      • 조회는 GET 사용
    • HTML Form 데이터 전송
      • POST, GET(단, 변경이 발생하는 작업은 불가)
      • 이미지 전송 - multipart/form-data라는 Content-Type으로 사용
      • AJAX 같은 기술을 사용해서 해결 가능
      • 컨트롤 URI
      • POST의 /new, /edit, /delete가 컨트롤 
        • 회원 목록 /members -> GET
        • 회원 등록 폼 /members/new -> GET
        • 회원 등록 /members/new, /members -> POST
        • 회원 조회 /members/{id} -> GET
        • 회원 수정 폼 /members/{id}/edit -> GET
        • 회원 수정 /members/{id}/edit, /members/{id} -> POST
        • 회원 삭제 /members/{id}/delete -> POST 
    • HTTP API 데이터 전송
      • POST, PUT, PATCH, GET
      • 서버 to 서버, 앱 클라이언트, 웹 클라이언트
      • application/json을 주로 사용
    • 컬렉션(collection)
      • 서버가 관리하는 리소스 디렉토리
      • 서버가 리소스의 URI를 생성하고 관리
      • /members
    • 스토어(store)
      • 클라이언트가 관리하는 리소스 저장소
      • 클라이언트가 리소스의 URI를 알고 관리
      • 여기서 스토어는 /files
      • 파일 목록 /files -> GET
      • 파일 조회 /files/{filename} -> GET
      • 파일 등록 /files/{filename} -> PUT(기존 파일을 덮어 씀)
      • 파일 삭제 /files/{filename} -> DELETE
      • 파일 대량 등록 /files -> POST
    • 문서(document)
      • 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row
      • /members/100, /files/star.jpg
    • 컨트롤러(controller), 컨트롤 URI
      • 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
      • 동사를 직접 사용
      • /orders/{id}/delievery
    • 참고하면 좋은 곳 - https://restfulapi.net/resource-naming

     

     

     

     

    HTTP 상태코드

    • 1XX (Informational) - 처리중
      • 거의 사용하지 않음
    • 2XX (Successful) - 성공
      • 200 - OK
      • 201 - Created
        • 새로운 리소스가 생성됨
      • 202 - Accepted
        • 요청이 접수되었으나 처리가 완료되지 않았음
        • 배치 처리
        • 1시간 뒤에 배치 프로세스가 처리
      • 204 - No Content
        • 서버가 요청을 성공적으로 수행했지만, 응답 페이로드에 내보낼 데이터가 없음
        • 웹 문서 편집기 save
        • 결과 내용이 없어도 204로 성공 인식
    • 3XX (Redirection) - 리다이렉트
      • Location 헤더가 있으면, Location 위치로 자동 이동
      • 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
        • 원래의 URL를 사용 X, 검색 엔진 등에서도 변경 인지
        • /members -> /users
        • 301 - Moved Premanently
          • 리다이렉트시 요청 메서드가 GET으로 변화, 본문이 제거될 수 있음
          • 옛날 주소 입력시 발생 가능
          • /event -> /new-event
        • 308 - Premanent Redirect
          • 301과 기능은 동일
          • 요청 메서드와 본문 유지
      • 일시 리다이렉션 - 일시적인 변경
        • 주문 완료 후 주문 내역 화면으로 이동
        • PRG: Post/Redirect/Get
          • Post로 주문후에 웹 브라우저를 새로고침하면?
          • 새로고침은 다시 요청
          • 중복 주문이 될 수 있다.
          • Post로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
          • 요청: POST /order -> 반환: 302 FOUND Location:/order-result/19
        • 302 - Found
          • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
        • 307 - Temporary Redirect
          • 302와 기능은 같음
          • 요청 메서드와 본문 유지
        • 303 - See Other
          • 302와 기능은 같음
          • 리다이렉트시 요청 메서드가 GET으로 변경
      • 특수 리다이렉션
        • 300 - Multiple Choices
          • 안씀. 
        • 304 - Not Modified
          • 결과 대신 캐시를 사용
          • 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
          • 응답에 메시지 바디를 포함하면 안된다.
          • GET, HEAD 요청시 사용
    • 4XX (Client Error) - 클라이언트 오류
      • 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함
      • 400 - Bad Request
        • 요청 구문, 메시지 등등 오류
        • 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
      • 401 - Unauthorized
        • 인증(Authentication) 되지 않음
        • 인증(Authentication): 본인이 누구인지 확인, 로그인
        • 인가(Authorization): 권한부여, ADMIN
      • 403 - Forbidden
        • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
        • 어드민 등급이 아닌 사용자가 어드민 등급의 리소스에 접근
      • 404 - Not Found
        • 요청 리소스가 서버에 없음
        • 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 숨기고 싶을 때
    • 5XX (Server Error) - 서버 오류
      • 재시도 하면 성공할 수도 있음 
      • 500 - Internal Server
        • 서버 내부 문제로 오류 발생
        • 애매하면 500 오류
      • 503 - Service Unavailable
        • 서비스 이용 불가
        • 서버가 일시적인 과부하 또는 예정된 작업으로 요청 처리 불가
        • Retry-After 헤더 필드로 얼마뒤에 복구되는지도 보낼 수 있음
    • 인식 하지 못하는 경우
      • 상위 상태코드로 해석해서 처리  
      • 299 ??? -> 2xx (Successful)

     

     

    HTTP 헤더

    • 메시지 본문 = 페이로드(payload)
    • 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
    • HTTP 전송에 필요한 모든 부가정보
      • 메시지 바디의 내용
      • 메시지 바디의 크기, 압축
      • 인증
      • 요청 클라이언트 정보
      • 서버 애플리케이션 정보
      • 캐시 관리 정보 등
    • 표현
      • Content-Type: 표현 데이터의 형식
        • 미디어 타입, 문자 인코딩
        • text/html; charset=utf-8
        • application/json
        • impage/png
      • Content-Encoding: 표현 데이터의 압축 방식
        • 표현 데이터를 압축하기 위해 사용
        • 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
        • gzip
        • deflate
        • identity
      • Content-Language: 표현 데이터의 자연 언어
        • ko
        • en
        • en-US
      • Content-Length: 표현 데이터의 길이
        • 바이트 단위
        • Transfer-Encoding(전송 코딩)을 사용하면 사용 X
      • 표현 헤더는 전송, 응답 둘다 사용
    • 협상(콘텐츠 네고시에이션)
      • Accept: 클라이언트가 선호하는 미디어 타입 전달
      • Accept-Charset: 클라이언트가 선호하는 문자 인코딩
      • Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
      • Accept-Language: 클라이언트가 선호하는 자연 언어
      • 우선순위
        • Quality Values 값 사용
        • 0~1, 클수록 높은 우선순위
        • 생략하면 1
        • Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
          • ko-KR = 1
          • ko = 0.9
        • 구체적인 것이 우선
        • Accept: text/*, text/plain, text/plain;format=flowed, */*
          • textplain;format=flowed
          • text/plain
        • 구체적인 것을 기준으로 미디어 타입을 맞춘다.
    • 전송 방식
      • 단순 전송
        • <html><body>...</body></html>
      • 압축 전송
        • Content-Encoding: gzip
        • lkj123kljoiasudlkjaweioluywlnfdo912u34ljko98udjkl
      • 분할 전송
        • Content-Length는 보내선 안됨. 
        • 5
        • Hello
        • 5
        • World
      • 범위 전송
        • Content-Range: bytes 1001-2000 / 2000
        • qweqwe1l2iu3019u2oehj1987askjh3q98y
    • 일반 정보
      • From
        • 일반적으로 잘 사용되지 않음 
        • 유저 에이전트의 이메일 정보
        • 검색엔진 같은 곳에서, 주로 사용
      • Referer
        • 이전 웹 페이지 주소
        • 유입 경로 분석 가능
        • 요청에서 사용
        • referrer의 오타
      • User-Agent
        • 유저 에이전트 애플리케이션 정보
        • 웹 브라우저의 정보
        • 통계 정보
        • 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
        • 요청에서 사용
      • Server
        • 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보 (중간 경유 서버가 아닌 응답을 보내는 서버)
        • server: Apache/2.2.22(Debian)
        • server: nginx
        • 응답에서 사용
      • Date
        • 메시지가 발생한 날짜와 시간
        • 응답에서 사용
    • 특별한 정보
      • Host
        • 요청한 호스트 정보(도메인)
        • 필수
        • 하나의 서버가 여러 도메인을 처리해야 할 때
        • 하나의 IP 주소에 여러 도메인이 적용되어 있을 때
        • 요청에서 사용
      • Location
        • 페이지 리다이렉션
        • 3xx 응답의 결과에 Location 헤더가 있으면 자동 이동
        • 201 (Created): Location 값은 요청에 의해 생성도니 리소스 URI
      • Allow
        • 허용 가능한 HTTP 메서드
        • 405 (Method Not Allowed) 에서 응답에 포함해야함
        • Allow: GET, HEAD, PUT
      • Retry-After
        • 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
        • 503: 서비스가 언제까지 불능인지 알려줄 수 있음
        • 날짜, 초단위 표기 가능
    • 인증
      • Authorization
        • 클라이언트 인증 정보를 서버에 전달
        • Authorization: Basic xxxxxxxxxxxxxxxx
      • WWW-Authenticate
        • 리소스 접근시 필요한 인증 방법 정의
        • 401 Unauthorized 응답과 함께 사용
        • https://tools.ietf.org/html/rfc7235 참고
    • 쿠키
      • 사용자 로그인 세션 관리
      • 광고 저보 트래킹
      • 항상 서버에 전달됨
      • 최소한의 정보만 사용
      • 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 사용
      • expires: 만료일이 되면 삭제
        • 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
        • 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지
      • max-age: 0이나 음수를 지정하면 쿠키 삭제(초단위 세팅)
      • domain
        • 명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
          • domain=example.org
          • example.org, dev.example.org
        • 생략: 현재 문서 기준 도메인만 적용
          • example.org만 가능
      • path
        • 경로
        • path=/home
        • 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
        • 일반적으로 path=/ 루트로 지정
      • 보안
        • Secure
          • https인 경우에만 전송
        • HttpOnly
          • XSS 공격 방지
          • 자바스크립트에서 접근 불가
          • HTTP 전송에만 사용
        • SameSite
          • XSRF 공격 방지
          • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송
      • Set-Cookie
        • 서버에서 클라이언트로 쿠키 전달
      • Cookie
        • 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
    • 필요 시 임의의 헤더 추가 가능

     

     

    HTTP 캐시

    • 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
    • 비싼 네트워크 사용량을 줄일 수 있다.
    • 브라우저 로딩 속도가 매우 빠르다.
    • 빠른 사용자 경험
    • 시간 초과
      • 서버를 통해 데이터를 다시 조회, 캐시를 갱신
      • 네트워크 다운로드가 발생
    • If-Modified-Since: 이후에 데이터가 수정되었으면?
    • 검증 헤더 추가 Last-Modified
      • 304 Not Modified Body를 떼고 헤더만 전송
    • 검증 헤더와 조건부 요청
      • 1초 미만 단위로 캐시 조정이 불가능
      • 날짜 기반의 로직 사용
      • 같은 데이터를 수적해서 데이터 결과가 똑같은 경우
      • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
    • ETag
      • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
      • Hash를 다시 생성 - 같으면 유지, 다르면 다시 받기
    • Cache-Control: 캐시 지시어(directives)
      • max-age
        • 캐시 유효 시간, 초 단위
      • no-cache
        • 데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용
      • no-state
        • 데이터에 민감한 정보가 있으므로 저장 X
      • must-revalidate
        • 캐시 만료후 최초 조회시 원 서버에 검증해야함
        • 원 서버 접근 실패시 반드시 오류 발생해야함
        • 유효 시간이라면 캐시를 사용
      • Expires
        • 캐시 만료일 지정(하위 호환)
        • 정확한 날짜로 지정
        • max-age와 힘께 사용하면 무시 당함
      • 검증 헤더 
        • ETag
        • Last-Modified
      • 조건부 요청 헤더
        • If-Match, If-None-Match: ETag 값 사용
        • If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용
      • public
        • 응답이 public 캐시에 저장되어도 됨(프록시 캐시로 저장하면 안됨)
      • private
        • 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본값)
      • s-maxage
        • 프록시 캐시에만 적용 되는 시간
      • 확실한 캐시 무효화 응답
        • Cache-Control: no-cache, no-store, must-revalidate
        • Pragma: no-cache
    • 프록시 캐시
      • 원 서버가 먼 경우 응답 속도가 느리다!
      • 세계 중간 중간 프록시 캐시 서버를 만들어 두고 그 곳에서 데이터를 가져온다. 

     

     

    728x90

    '서버 > SPRING' 카테고리의 다른 글

    싱글톤  (0) 2023.07.13
    [Boostcourse] 이클립스와 MongoDB Backend - Project1 명함만들기  (0) 2022.10.02
    [Boostcourse] 이클립스와 MongoDB Template 사용 및 JDBC3 실습  (0) 2022.09.30
    [Boostcourse] 이클립스와 MongoDB Insert 및 JDBC2 실습  (0) 2022.09.30
    [Boostcourse] 이클립스와 MongoDB 연결 방법 및 JDBC1 실습  (0) 2022.09.28

    관련글

    댓글

    티스토리툴바