HTTP 특징

비 연결성(connectionless)

무상태 프로토콜

  • 서버가 클라이언트의 상태를 보존하지 않는다.
  • 장점: 서버 확장성 높음(스케일 아웃)
  • 단점: 클라이언트가 추가 데이터 전송

클라이언트 서버 구조(Request, Response)

거의 모든 형태의 데이터 전송 가능

 

 

HTTP 메시지 구조

https://developer.mozilla.org/ko/docs/Web/HTTP/Messages

start line, header, body 로 이뤄진다.

 

start line

요청과 응답은 살짝 다르다.

 

요청(request-line)은 HTTP 메서드와 HTTP버전이 나온다.

응답(status-line)은 HTTP버전과 HTTP 상태코드가 온다.

 

 

 

HTTP 헤더

HTTP 전송에 필요한 모든 부가정보가 들어간다.

표준헤더를 주로 사용하나 커스텀 헤더도 만들어 사용할 수 있다. 

 

 

HTTP 메시지 바디

html 문서일 수도, 이미지일 수도, JSON일 수도 사실상 거의 모든 데이터를 전송할 수 있다.

 

 

 

 

HTTP API 설계 예시

안좋은 예시

  • 회원 목록 조회 /read-member-list
  • 회원 조회 /read-member-by-id
  • 회원 등록 /create-member
  • 회원 수정 /update-member
  • 회원 삭제 /delete-member

문제는 location 위치에 의미를 부여했다.

location은 말그대로 리소스 위치만을 표현해야한다.

 

좋은 예시

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

계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장한다.

각 url 행동을 식별하는 것은 HTTP 메서드로 정한다.

GET 리소스 조회

POST  요청 데이터 처리, 주로 등록에 사용한다. 

PUT 리소스 대체, 없으면 생성

PATCH 리소스 부분 변경

DELETE 리소스 삭제

 

 

HTTP 주요 메서드 설명

GET

  • 리소스 조회 시 서버에 전달할 데이터를 쿼리 파라미터 형식으로 보낸다.
  • www.검색사이트.com?query=검색어

POST

  • 요청 데이터 처리, 상당히 애매한 표현일 수도 있으나, 실제로 애매하면 전부 POST로 처리한다. 실제로 삽입수정삭제 전부 POST로 처리하는 곳도 있다.
  • 메시지 바디를 통해 서버로 요청 데이터를 전달한다.

PUT

  • 리소스가 있으면 대체, 아니면 생성
  • POST로도 생성이 가능한데 차이는 PUT은 정확히 리소스 위치를 클라이언트가 정한다.

 

HTTP 메서드의 속성

안전(Safe Methods)

  • 리소스를 변경하는가

멱등(Idempotent Methods)

  • 언제나 몇 번을 호출해도 항상 동일한 결과를 도출하는지.
  • POST가 멱등성을 중족하지 않는다. 이 문제로 PRG(POST-Redirect-GET) 패턴이라는 것이 존재한다.
  • 예컨데 POST요청으로 주문하는데 클라이언트가 실수로 두 번 클릭했다. 주문이 두 번 처리된다.

캐시가능(Cacheable Methods)

  • 응답 결과를 캐시가 가능한지

 

 

 

 

 

 

 

IP(인터넷 프로토콜)

  • IP프로토콜의 한계 비연결성
    • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
  • 비신뢰성
    • 중간에 패킷 소실, 패킷 순서대로 안올 경우
  • 프로그램 구분
    • 같은 IP인 서버들 구분

 

 

TCP, UDP

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake

• 데이터 전달 보증

• 순서 보장

• 신뢰할 수 있는 프로토콜

 

UDP 특징

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

• 비연결 지향

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

• 정리

• IP와 거의 같다. +PORT +체크섬 정도만 추가

• TCP 같은 신뢰성을 유지하려면 어플리케이션에서 작업해야 함

 

 

Port

같은 IP 여러 연결 구분

총 길이는 16bit로 2의 16제곱인 0~ 65535 범위 번호를 가짐

0~1023 은  well-know 포트라 불리며, 미리 지정한 기능을 수행함(약속임)

20,21 FTP

23 telnet

80, 443  HTTP, HTTPS

 

DNS(Domain Name Server)

인간은 IP를 기억하기 어렵다. 규칙성이 없는 숫자 덩어리기 때문이다.

때문에 IP와 매핑된 이름을 부여

 

URI(Uniform Resource Identifier)

Uniform: 리소스 식별하는 통일된 방식

Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)

Identifier: 다른 항목과 구분하는데 필요한 정보

 

URL, URN 을 포괄하는 개념

URN은 거의 쓰이질 않음

 

URL(Uniform Resource Locator)

문법  scheme://[userinfo@]host[:port][/path][?query][#fragment]

  • 스키마
    • http, ftp 같은 프로토콜
  • userinfo@
    • 말그대로 인증 정보이다
    • 내가 직접 사용해본 건 ftp를 연결할 때 인증정보를 넣어서 야용해봤다.
  • host
    • IP주소 혹은 매핑된 name 주소이다.
    • www.naver.com
  • port 는 말그대로 port number가 들어간다. 단, well-know포트를 사용한다면 생략가능하다.
    • ftp:100.100.100.100     생략했으니 기본 포트번호인 21번 사용
    • ftp:100.100.100.100:2121       기본포트가 아닌 다른 포트 사용으로 생략 불가
  • path
    • 리소스 경로가 위치한다.
  • query
    • key=value 형태로 값을 넣어 서버에게 정보를 제공한다
  • fragment
    • html 내부 북마크 등에 사용

북마크 예시

 

 

 

 

 

 

 

+ Recent posts