HTTP
-
역사
- HTTP/0.9 1991년 : GET 메서드만 지원 HTTP 헤더 X
- HTTP/1.0 1996년 : 메서드, 헤더 추가
- HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
- HTTP/2 2015년 : 성능개선
- HTTP/3 진행 중 : TCP 대신 UDP 사용, 성능개선
-
특징
-
클라이언트 서버 구조 :
- Request(요청) Response(응답) 구조
- 클라이언트는 서버에 요청을 보내고, 응답을 대기
- 서버가 요청에 대한 결과를 만들어서 응답
-
무상태 프로토콜(스테이스리스)
- Stateless
- 서버가 클라이언트의 상태를 보존 X
- 장점 : 서버 확장성 높음 (스케일 아웃)
- 단점 : 클라이언트가 추가 데이터 전송
- Stateful 과 Stateless 차이
- 상태유지(Stateful) : 마트에서 물건을 살 때 다른 점원으로 바뀌면 안된다.
중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
- 무상태(Stateless) : 중간에 다른 점원으로 바뀌어도 된다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
- 무상태는 응답을 쉽게 바꿀 수 있다 => 무한한 서버 증설
- 실무 한계
- 모든 것을 무상태로 설계할 수 있는 경우가 있고 없는 경우도 있다.
- 무상태 ex) 로그인이 필요 없는 단순한 서비스 소개 화면
- 상태유지 ex) 로그인 서비스
- 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
- 상태 유지는 최소한만 사용한다.
-
비연결성
- 장점
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천 명이 서비스를 사용해도 실제 서버에서 동시에 (같은 시간) 처리하는 요청은 수십 개 이하로 매우 작음
- 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지 않는다
- 서버 자원을 매우 효율적으로 사용할 수 있음
- 단점
- TCP/IP 연결을 새로 맺어야 한다 => 3 way handshake 시간 추가
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 JS, CSS, 추가 이미지 등 수많은 자원이 함께 다운로드된다.
- 지금은 HTTP 지속 결로 문제를 해결함.
-
HTTP 메시지
HTTP 메시지 구조 |
---|
start-line 시작 라인 |
header 헤더 |
empty line 공백 라인 (CRLF) |
message body (생략) |
- start-line 시작 라인
- 요청 메시지
- HTTP 메서드 : 서버가 수행해야 할 동작 지정
- 요청 대상 : 절대경로 = "/" 로 시작하는 경로
- HTTP 버전
- 응답 메시지
- HTTP 버전
- HTTP 상태 코드 (성공 or 실패) : 200 = 성공, 400 = 클라이언트 요청 오류, 500 = 서버 내부 오류
- 상태에 대한 문구 : 사람이 이해할 수 있는 상태 코드 설명 글
- header 헤더
- 용도
- HTTP 전송에 필요한 모든 부가정보
- ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축여부, 인증여부, 요청 브라우저 정보 등등
- message body
- 실제 전송할 데이터
- HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송
-
단순함, 확장
- HTTP는 단순하다.
- HTTP 메시지도 단순하다.
- 크게 성공하는 표준 기술은 단순하지만 확장한 기술이다.
HTTP 메서드
- HTTP API
- 리소스 식별
- 리소스 === 개념
- ex) 회원 조회 => 회원이 리소스, 회원 추가 => 회원이 리소스, 회원 삭제 => 회원이 리소스
- 회원을 조회하고 추가하고 삭제하는 것을 모두 배제한다
- 회원이라는 리소스만 식별하면 된다 => 회원 리소스를 URI에 매핑
- 리소스 설계
- 리소스와 행위를 분리
- 리소스 : 회원 / 행위 : 조회, 추가, 삭제
- 리소스는 명사, 행위는 동사
- 행위는 HTTP메서드로 구분한다
- HTTP 메서드
- 주요 메서드
- GET : 리소스 조회
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다
- POST : 요청 데이터 처리, 주로 등록에 사용
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 서버는 요청 데이터 처리 (메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다)
- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
- PUT : 리소스를 대체, 해당 리소스가 없으면 생성
- 리소스가 있으면 대체하고, 리소스가 없으면 생성한다. 쉽게 이야기 해서 리소스를 덮어버림
- 클라이언트가 리소스를 식별하고 클라이언트가 리소스 위치를 알고 URI 지정
- PATCH : 리소스 부분 변경
- 부분적으로 리소스에 데이터를 바꾸고 싶을 때 사용한다.
- 만약 PATCH가 작동하지 않으면 POST 사용
- DELETE : 리소스 삭제
- 리소스 주소를 통해서 리소스를 삭제한다.
- 메서드 속성
- 안전 - 호출해도 리소스를 변경하지 않는다.
- 멱등 - 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 같다.
- 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지 고려 X
- 캐시 - 웹브라우저 내부에 저장 하는것
HTTP 메서드 | 안전 | 멱등 | 캐시 |
---|
GET | O | O | O |
POST | X | X | O |
PUT | X | O | X |
PATCH | X | X | O |
DELETE | X | O | X |
HTTP 메서드 활용
- 데이터 전달 방식
- 쿼리 파라미터를 통한 데이터 전송
- 메시지 바디를 통한 데이터 전송
- POST, PUT, PATCH
- 회원가입, 상품주문, 리소스 등록, 리소스 변경
- 정적 데이터 조회
- 이미지, 정적 텍스트 문서
- 조회는 GET 사용
- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회
- 동적 데이터 조회
- 주로 검색, 게시판 목록에서 정렬 필터(검색어)
- 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
- 조회는 GET 사용
- GET은 쿼리 파라미터 사용해서 데이터를 전달
- HTML Form을 통한 데이터 전송
- HTML Form submit시 POST 전송
- form의 내용을 메시지 바디를 통해서 전송 (key = value 형식, 쿼리 파라미터 형식)
- 전송 데이터를 url encoding 처리
- HTML Form은 GET 전송도 (조회만)
- HTTP API를 통한 데이터 전송
- 서버 to 서버
- 앱 클라이언트
- 웹 클라이언트
- HTML에서 Form 전송 대신 자바스크립트를 통한 통신에 사용(AJAX)
- ex) React, VueJs 같은 웹 클라이언트와 API 통신
- POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
- GET: 조회, 쿼리 파라미터로 데이터 전달
HTTP API 설계 예시
- POST 기반 데이터 등록 특징
- 클라이언트는 등록될 리소스의 URI를 모른다.
- 서버가 새로 등록된 리소스 URI를 생성해준다.
- 컬렉션
- 서버가 관리하는 리소스 디렉토리
- 서버가 리소스의 URI를 생성하고 관리한다.
- PUT 기반 데이터 등록 특징
- 클라이언트가 리소스 URI를 알고 있어야 한다
- 클라이언트가 직접 리소스의 URI를 지정한다.
- 스토어
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URI를 알고 관리한다.
- HTML FORM 사용
- HTML FORM은 GET, POST만 지원
- 컨트롤 URI
- GET, POST만 지원하므로 제약이 있음
- 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
- POST의 /new, /edit, /delete가 컨트롤 URI
- HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)
- 좋은 URI 설계 개념
- 문서(document)
- 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
- ex) /members/100, /files/star.jpg
- 컬렉션(collection)
- 서버가 관리하는 리소스 디렉터리
- 서버가 리소스의 URI를 생성하고 관리
- ex) /members
- 스토어(store)
- 클라이언트가 관리하는 자원 저장소
- 클라이언트가 리소스의 URI를 알고 관리
- ex) /files
- 컨트롤러(controller), 컨트롤 URI
- 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
- 동사를 직접 사용
- ex) /members/{id}/delete POST
- ex) /members/{id}/edit POST.
상태 코드
HTTP 헤더
- HTTP BODY
- 메시지 본문 (message body)을 통해 표현 데이터 전달
- 표현은 요청이나 응답에서 전달할 실제 데이터
- 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
- 표현
- Content-Type: 표현 데이터의 형식
- Content-Encoding: 표현 데이터의 압축 방식
- 표현 데이터를 압축하기 위해 사용
- 데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
- 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
- Content-Language: 표현 데이터의 자연 언어
- 표현 데이터의 자연 언어를 표현 (한국어 = ko, 영어 = en)
- Content-Length: 표현 데이터의 길이
참조
인프런 김영한님 강의
HTTP & Network Basic