[네트워크] 모든 개발자를 위한 HTTP 웹 기본 지식 정리

김영한 강사님의 모든 개발자를 위한 HTTP 웹 기본 지식 정리를 완강 후 개념 위주로 재정리한 글입니다.

배운내용

1.internet-network

IP 인터넷 프로토콜 역할

• 지정한 IP 주소(IP Address)에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 프로토콜의 한계

• 비연결성
• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성
• 중간에 패킷이 사라지면?
• 패킷이 순서대로 안오면? 프로그램 구분
• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

TCP(전송 제어 프로토콜, Transmission Control Protocol) 특징

• 연결지향 - TCP 3 way handshake (가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜
• 현재는 대부분 TCP 사용

UDP(사용자 데이터그램 프로토콜, User Datagram Protocol) 특징

• 하얀 도화지에 비유(기능이 거의 없음)
• 연결지향 - TCP 3 way handshake X 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
• 정리
  • IP와 거의 같다. +PORT +체크섬 정도만 추가
  • 애플리케이션에서 추가 작업 필요

PORT

• 0 ~ 65535 할당 가능
• 0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

DNS (도메인 네임 시스템, Domain Name System)

• 전화번호부
• 도메인 명을 IP 주소로 변환

2.uri-web browser

"URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다"

URI 단어 뜻

• Uniform: 리소스 식별하는 통일된 방식
• Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier: 다른 항목과 구분하는데 필요한 정보

• URL: Uniform Resource Locator
• URN: Uniform Resource Name

URL, URN 단어 뜻

• URL - Locator: 리소스가 있는 위치를 지정
• URN - Name: 리소스에 이름을 부여
• 위치는 변할 수 있지만, 이름은 변하지 않는다.
• urn: 책의 isbn과 같다.
• URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음

URL 전체 문법

• scheme://[userinfo@]host[:port][/path][?query][#fragment]
• https://www.google.com:443/search?q=hello&hl=ko

• 프로토콜(https)
• 호스트명(www.google.com)
• 포트 번호(443)
• 패스(/search)
• 쿼리 파라미터(q=hello&hl=ko)

HTTP

HTTP (HyperText Transfer Protocol)

• 클라이언트 서버 구조
• Stateful, Stateless
• 비 연결성(connectionless)
• HTTP 메시지

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용
  • HTTP/2, HTTP/3 도 점점 증가

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능

HTTP 메서드

API URI 고민

• 리소스의 의미는 뭘까?
  • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다.
  • 예) 미네랄을 캐라 -> 미네랄이 리소스
  • 회원이라는 개념 자체가 리소스.
• 리소스를 어떻게 식별하는게 좋을까?
  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑

HTTP 메서드 종류 - 주요 메서드

• Representation 설명 전
• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

POST

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

HTTP 메서드의 속성

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

HTTP 메서드 활용

클라이언트에서 서버로 데이터 전송

• 쿼리 파라미터를 통한 데이터 전송
  • GET
  • 주로 정렬 필터(검색어)
• 메시지 바디를 통한 데이터 전송
  • POST, PUT, PATCH
  • 회원 가입, 상품 주문, 리소스 등록, 리소스 변경

정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 조회는 GET 사용
• 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

동적 데이터 조회

• 주로 검색, 게시판 목록에서 정렬 필터(검색어)
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
• 조회는 GET 사용
• GET은 쿼리 파라미터 사용해서 데이터를 전달

HTTP API 설계 예시

• HTTP API - 컬렉션
  • POST 기반 등록
  • 예) 회원 관리 API 제공
• HTTP API - 스토어
  • PUT 기반 등록
  • 예) 정적 컨텐츠 관리, 원격 파일 관리
• HTML FORM 사용
  • 웹 페이지 회원 관리
  • GET, POST만 지원

HTTP 상태코드

상태 코드: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

HTTP 헤더1 - 일반 헤더

HTTP 헤더의 용도

• HTTP 전송에 필요한 모든 부가정보
• 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보...
• 표준 헤더가 너무 많음
  • https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
• 필요시 임의의 헤더 추가 가능
  • helloworld: hihi

HTTP BODY - RFC7230(최신)

• 메시지 본문(message body)을 통해 표현 데이터 전달
• 메시지 본문 = 페이로드(payload)
• 표현은 요청이나 응답에서 전달할 실제 데이터
• 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
  • 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
• 참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

전송 방식

• 단순 전송
• 압축 전송
• 분할 전송
• 범위 전송

일반 정보

• From: 유저 에이전트의 이메일 정보
• Referer: 이전 웹 페이지 주소
• User-Agent: 유저 에이전트 애플리케이션 정보
• Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
• Date: 메시지가 생성된 날짜

특별한 정보

• Host: 요청한 호스트 정보(도메인)
• Location: 페이지 리다이렉션
• Allow: 허용 가능한 HTTP 메서드
• Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

쿠키

• Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
• Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

HTTP 헤더2 - 캐시와 조건부 요청

캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
• 인터넷 네트워크는 매우 느리고 비싸다.
• 브라우저 로딩 속도가 느리다.
• 느린 사용자 경험

캐시 적용

• 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
• 비싼 네트워크 사용량을 줄일 수 있다.
• 브라우저 로딩 속도가 매우 빠르다.
• 빠른 사용자 경험

검증 헤더와 조건부 요청 정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책