HTTP 웹 개발 스터디

김유상·2023년 8월 10일
0

인터넷 통신

IP Address

비연결성

  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

비신뢰성

  • 패킷 손실
  • 순서 문제

프로그램 구분

  • 같은 IP 내 통신 프로그램이 다수 존재할 수도

TCP + UDP

인터넷 프로토콜 계층을 내려갈 때마다 실제 데이터(페이로드) 뿐만이 아니라 각종 계층의 헤더를 계속해서 붙여 내려가게 된다.

TCP 특징

  • 연결지향 - 3way handshake(가상 연결)
  • 데이터 전달 보증
  • 순서 보장
  • 신뢰할 수 있는 프로토콜, 가장 일반적인 통신 방법

3way handshake


일종의 가상 연결 방법, 각 노드의 논리적인 연결을 약속
따라서 물리적으로 맞닿는 것은 아님

데이터 전달 보증

순서 보장

UDP(User Datagram Protocol)

  • 연결 지향 - 3 way handshake X
  • 데이터 전달 보증 x
  • 순서 보장 x
  • IP + Port + checksum
  • 애플리케이션 추가 작업 필요

하지만 단순하기 때문에 빠르다는 장점이 있음

Port

한 번에 둘 이상의 통신을 수행하려면 IP만으로 연결을 특정할 수 없음
따라서 무언가 통신을 특정할 id가 필요함 이때 사용하는 것이 Port


노란색 - IP헤더
초록색 - TCP세그먼트

well known port: 0 ~ 1023

DNS(Domain Name System)

사용 배경

  • IP는 기억하기 어려움
  • IP는 서버 사정에 의해 변경될 수 있음

DNS 서버는 도메인 명과 IP를 key-value와 같이 저장해놓고 도메인 명으로 요청이 오면 IP 주소를 반환해준다.

URI(Uniform Resource Identifier)


URI는 Locator, name 또는 둘다 추가로 분류될 수 있다.

의미

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

URL: 리소스가 있는 위치
URN: 리소스에 이름을 부여

위치는 바뀔 수 있지만, 이름은 바뀌지 않음

웹 브라우저 요청 흐름

HTTP 메시지 전송

HTTP(Hyper Text Transfer Protocol)

특징

  • HTML, TEXT
  • IMAGE, 음성, 영상, 파일
  • JSON, XML
  • 거의 모든 형태의 데이터 전송 가능

클라이어트 서버 구조

  • Request Response 구조
  • 클라이언트는 요청 보내고, 응답 대기
  • 서버는 요청에 대한 결과 만들어 응답

무상태 프로토콜

stateless

  • 서버가 클라이언트의 상태를 보존하지 않음
  • 서버 확장성 높음 -> 이전 컨텍스트가 필요하지 않기 때문에 중간에 서버가 달라져도 응답할 수 있음 = 아무 서버든 요청 응답 가능
  • 클라이언트 추가 정보 전송 -> 이전 컨텍스트를 서버에서 저장하지 않기 때문에 그만큼 클라이언트에서 저장하지 않으면 적절한 통신을 할 수 없게 됨

stateful

  • 항상 같은 서버가 유지되어야 함
  • 통신 도중 서버가 다운되면 기존 컨텍스트를 보장할 수 없음

stateless 실무 한계

  • 무상태: 로그인 필요가 없는 단순 서비스 화면
  • 상태 유지: 로그인
  • 브라우저 쿠키와 서버 세션을 통해 로그인 유지
  • 상태 유지 최소화

비연결성

장점

  • HTTP는 기본적으로 연결을 유지하지 않는 모델
    -> 최소 연결을 통해 리소스를 관리, 덕분에 빠른 응답이 가능

단점

  • TCP/IP 연결마다 3 way handshake 새로 연결해야함
  • 웹사이트 요청 시 JS, CSS, 이미지, 등 많은 자원 재전송
    -> 지금은 HTTP 지속연결로 해결함

HTTP 메시지

시작 라인

GET /search?q=hello&hl=ko HTTP/1.1
HTTP 메서드 + 요청 대상 + HTTP 버전

헤더

Host: www.google.com
field-name ":" OWS field-value OWS

  • 전송에 필요한 모든 부가 정보

메시지 바디

  • 실제 전송할 데이터
  • HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP API

회원 정보 관리 API 예시

요구사항

  • 회원 목록 조회/members
  • 회원 조회
  • 회원 등록
  • 회원 수정
  • 회원 삭제

나머지 API URL 어떻게?

  • 리소스와 행위를 분리
  • URI는 리소스만 식별

HTTP 메서드

메서드 종류

GET: 리소스 조회

  • 쿼리를 통해 서버에 데이터 전달
  • 메시지 바디로 데이터 전송하는 것은 권장하지 않음

POST: 요청 데이터 처리

  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버는 요청 데이터를 처리, 주로 리소스 등록, 프로세스 처리에 사용

대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.
리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할 지 리소스마다 따로 정해야 함.

컨트롤 URI: 행위를 URI로 설계하는 경우
JSON 조회의 경우 GET메서드를 사용하기 어려워 POST로 처리할 수도 있음.

PUT: 리소스를 대체, 해당 리소스가 없으면 생성

  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제
profile
continuous programming

0개의 댓글