티스토리 뷰
인터넷 네트워크
IP(Internet Protocol, 인터넷 프로토콜)
IP 주소를 통해 데이터를 패킷이라는 통신 단위로 전달한다.
IP패킷의 구성요소 - 출발지 IP, 목적지 IP, 메세지 등..
IP의 한계?
비연결성 - 패킷을 받을 수 없는 상황임에도 패킷을 전송한다.
비신뢰성 - 패킷의 받는 순서, 받을 수 있다는 보장을 하지 못한다.
프로그램 구분 - 같은 IP를 사용한다면 어떻게 구분할 것인지 확정 못한다.
프로토콜 계층의 기본적인 동작 구조를 알아보자
인터넷 프로토콜 스택 - 애플리케이션 계층(HTTP, FTP), 전송 계층(TCP, UDP)
인터넷 계층(IP), 네트워크 인터페이스 계층
내가 무언가(메시지)를 전송하려 한다면
메시지가 애플리케이션 계층의 소켓 라이브러리를 통해 OS계층으로 전달되고
메세지에 TCP정보를 생성한다(TCP 패킷). 이후 IP패킷을 생성하고
네트워크 계층에서 이더넷 프레임을 추가하여 인터넷을 통하여 전달된다.
TCP(Transmission Control Protocol, 전송 제어 프로토콜)
TCP세그먼트의 구성요소 - 출발지 PORT, 목적지 PORT, 전송 제어, 순서 등...
-> IP패킷 안에 TCP 세그먼트 정보를 넣는 것이다. TCP/IP 패킷
TCP의 특징
데이터 전달 보증 - 받을 수 있음을 보장
순서 보장
요청(SYN)과 수락(ACK)의 가상으로 하여 연결이 되었다는 것을 서로에게 알린다.
UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)
TCP와 같은 계층(전송계층)에 존재
기능은 거의 없고, PORT를 통해 출발지 목적지를 알 수 있다.
별로인 것 같지만, TCP는 연결지향 때문에 매우 무겁다.
이 도화지 같은 UDP을 애플리케이션 계층에서 기능을 추가하여 빠르고, 가볍게 사용할 수 있다.
PORT
하나의 IP에서 여러 서버로 요청을 하고 있다면, 이 서로 다른 요청과 응답을 어떻게 구분한가
TCP의 출발지 PORT와 목적지 PORT를 통해 구분할 수 있게 되었다.
즉, 같은 IP 내에서 프로세스를 구분할 수 있다.
0~65535 사이의 값을 할당하여 사용한다.
+) IP를 아파트 101(클라이언트)동, PORT를 아파트의 1201호(프로세스) 처럼 생각하자
DNS(Domain Name System)
IP의 경우 기억하기 어렵고 변경될 수 있다. - 100.100.100.1 어려워 어려워
DNS서버에는 도메인명과 IP가 저장되어 있다.
그렇기에 우리는 100.200.100. 과 같은 어려운 주소가 아닌 ***.com과 같은 도메인으로
사이트에 접속할 수 있다.
URI와 웹 브라우저 요청 흐름
URI(Uniform Resource Identifier, 자원 식별 통합 방식)
URL - Locator : 리소스가 있는 위치를 지정
URN - Name : 리소스에 이름을 지정 (이름이 urn:isbn:~~~ 형식)
URL과 URI를 거의 같다 생각해도 무방하다. (URN이 어렵기에 거의 사용되지 않음..)
URL의 문법
scheme :// [userinfo@]host[:port][/path][?query][#fragment]
scheme : 주로 프로토콜(자원 접근 방식 규약)이 사용 http, https, ftp가 있다
userinfo : URL에 사용자정보를 포함해서 인증 시 사용, 거의 x
host : 도메인 명이나 IP 주소를 직접 사용 ( www.google.com같은 )
port : 접속 포트, 프로토콜에 따라 정해져 있기도 함, 생략가능
path : 리소스 경로, 계층적인 구조다. /market/device/iphone 같이
query : key=value 형태, ?시작 &로 추가 , query string이라 부른다.
fragment : html 내부 북마크, 서버로 전송되지 않음
웹 브라우저의 요청 흐름
웹 브라우저에서 "https://www.google.com:443/search?q=hello&hl=ko" 라는 요청을 보낸다면
www.google.com이라는 DNS를 조회하고, HTTP 요청 메세지를 생성한다.
이 메시지가 프로토콜 계층을 거쳐 TCP/IP 패킷으로 생성되어 목적지(구글 서버)IP로 전달된다.
목적지에서 패킷을 확인하고 메세지를 확인하여 HTTP 응답 메세지를 생성한다.
이 응답 메세지를 이전의 과정처럼 TCP/IP 패킷으로 만들어
클라이언트로 전송하여 페이지 렌더링을 완료한다.
HTTP
HyperText Transfer Protocol
기존에는 HyperText를 전송하기 위한 프로토콜이었지만, 현재 거의 모든 형태의 데이터를 전송
TCP 는 HTTP/1.1(가장 많이 사용)과 HTTP/2를 사용하고, UDP는 HTTP/3를 사용
HTTP의 특징
1. 클라이언트 서버 구조 (Request, Response)
클라이언트는 UI에 집중, 서버는 비즈니스 로직과 데이터 처리에 집중할 수 있다.
2. 무상태(Stateless) 프로토콜
stateful과 stateless
stateful 은 context가 사라질 수 있음 -> 이를 위해 응답서버는 context 처리를 해야 함
stateless 는 context가 사라지지 않음 -> 응답서버의 교체가 용이 -> 서버 확장이 가능함
stateless는 클라이언트가 요청 시 상태 정보를 메세지에 포함하여 전달하기 때문에 서버의 영향이 적다.
stateless로만 설계할 수 없는 경우가 있고, stateful이 필요한 상태도 있으니 적절하게 사용해야 한다.
3. 비 연결성(Conectionless)
여러 클라이언트들이 서버에 요청을하고 응답을 받는다면, 이는 연결되어 있어야 한다.
응답 후에 연결이 유지된다면 서버의 자원을 계속 소모될 것이다.
HTTP는 기본적으로 연결을 유지하지 않는 모델이다.
빠른 응답을 통해 연결을 해제하여 서버 자원을 효율적으로 사용한다.
연결을 해제하고 다시 요청을 받으면 3 way handshake를 다시 해야하는 시간과 자원의 소모를
현재는 HTTP 지속 연결(Persistant Connection)로 해결 가능하다.
HTTP 메세지
HTTP요청 메세지와 응답 메시지는 다른 형태를 띄지만, 구조는 아래와 같다.
HTTP 요청 메세지
시작 라인 : method request-target HTTP-version
method - GET, POST와 같은 서버의 수행 동작을 지정
request-target - 요청 대상, 절대 경로로 시작한다.
HTTP-version - 버전을 적는다.
HTTP 응답 메시지
시작 라인 : HTTP-version status-code reason-phrase
HTTP-version - 버전을 적는다.
status-code - 상태코드, 요청 성공이나 실패를 코드로 보낸다. (200, 404..)
reason-phrase - 이유 문구, 상태 코드를 간략하게 문구로 적는다.
공통
헤더 : field-name : field-value
HTTP 전송에 필요한 모든 부가정보가 헤더에 담긴다.
메세지 바디
실제 전송할 데이터를 담는다.
HTML, JSON 등 모든 데이터를 담을 수 있다.
HTTP 메서드
HTTP API를 만들어보자 - 회원 정보 관리 API
요구사항 - 회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제
먼저 API URI를 설계한다. 이때, 리소스에 집중해야 한다. - 요구사항의 리소스는 회원(members)
회원 목록 조회 - /members 회원 조회 - /members/{id} 회원 등록 - /members/{id}
그렇다면 회원 조회와 회원 등록, 나머지는 어떻게 구별할 것인가?
리소스와 행위를 분리하는 것이다. 리소스(members), 행위(조회, 등록, 삭제 수정)
이 행위를 도와주는 것이 HTTP 메서드이다.
GET: 리소스 조회
서버에 전달하고 싶은 데이터는 쿼리스트링을 통해서 전달한다.
POST: 요청 데이터 처리, 주로 등록에 사용
메세지 바디를 통해 서버로 데이터를 전달한다. 서버는 요청 데이터를 처리한다.
URI POST요청이 오면 요청 데이터를 어떻게 처리할 것인지 리소스마다 따로 정해야 한다.
-> 새 리소스를 생성(회원가입), 요청 데이터 처리( 데이터를 생성하거나, 프로세스를 처리해야 할 때)
-> 다른 메서드로 처리하기 애매한 경우, 일단 애매하면 POST쓰자
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
리소스를 대체한다. 이미 있으면 완전히 대체(덮어쓰기, 이름과 성별에서 이름만 될수도), 없으면 생성
클라이언트가 리소스의 위치를 정확히 알고있음 -> POST와의 차이점
PATCH: 리소스 부분 변경
PUT 메서드는 부분 변경이 되지 않고 완전히 바꿔버림 -> 부분 변경을 위한 PATCH 등장
+) 간혹 PATCH가 안되는 경우가 있음 -> 애매하면 POST!
DELETE: 리소스 삭제
리소스 위치에 있는 리소스를 삭제
HTTP 메서드 속성
1. 안전(Safe) - 호출해도 리소스를 변경하지 않는다는 점
GET은 조회만 하기에 안전하지만, POST PUT.. 등 안전하지 않다.
2. 멱등(Idempotent) - 몇 번을 호출해도 호출 결과가 같은 점.
GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
POST: 멱등이 아니다 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
어디서 사용하는가? -> 자동 복구 매커니즘, 재요청을 여러 번 해도 괜찮은 경우
또한, 외부 요인(자신이 아닌)으로 중간에 리소스가 변경되는 것은 고려하지 않는다.
3. 캐시가능(Cacheable) - 응답 결과 리소스를 캐시해서 사용해도 괜찮은지
GET, HEAD(GET에서 바디를 뺀 것), POST, PATCH는 사용 가능
실제로는 GET HEAD 정도만 사용 (GET이 주로 사용)
HTTP 메서드 활용
클라이언트에서 서버로 데이터 전송
데이터를 전송하는 방법
1. 쿼리 파라미터(쿼리 스트링)을 통한 데이터 전송
주로 GET을 사용하고, 정렬 필터(검색)를 사용할 때 사용된다.
2. 메세지 바디를 통한 데이터 전송
POST, PUT, PATCH를 사용, 회원 가입 리소스 등록 등을 위해 사용
1. 정적 데이터 조회 시
- 쿼리 파라미터를 사용하지 않는다. 리소스 경로로 단순하게 조회 가능(이미지, 파일 등)
2. 동적 데이터 조회 시
- 쿼리 파라미터 사용, 이를 사용해서 결과를 동적으로 생성
- 주로 검색, 정렬 필터를 사용 시 사용한다.
3. HTML Form 데이터 전송
- <form action = "" method="">
- POST는 회원 가입과 같은 행위 시 사용, GET 전송도 가능 조회시 사용
- 기본은 Content-Type: application/x-www-form-urlencoded
- 파일은 enctype="multipart/form-data" 추가, Content-Type: multipart/form-data
4. HTTP API 데이터 전송
- 서버 to 서버 통신 시 사용, HTML에서 Form 전송 대신 AJAX 이용 시 사용
- POST, PUT, PATCH 모두 메시지 바디를 통해 데이터를 전송하여 사용
- GET은 조회의 경우 사용, 꼭 쿼리 파라미터로 데이터 전송하기
- Content-Type :application/json 주로 사용한다.
HTTP API 설계 예시
POST를 통해 회원 등록을 한다면 리소스는 /members, 처리는 POST다.
클라이언트에서 POST로 요청하면, 서버에서 /members/2 와 같은 리소스 URI를 생성해준다.
이 생성된 리소스 URI를 관리하는 리소스 디렉토리를 컬렉션 이라 함
PUT을 통해 파일을 등록한다면 POST와 달리 클라이언트가 리소스 URI를 알아야 한다.
이는 클라이언트가 직접 리소스 URI를 지정해주는 것이다. PUT /files/star.jpg
클라이언트가 관리하는 이 리소스 저장소를 스토어 라 함
대부분 POST를 통한 신규 등록을 사용한다.
HTML FORM 을 사용한다면? -> GET, POST만 사용할 수 있다.
회원 삭제를 예로 들자면 DELETE 메서드를 사용하지 못한다.
이럴때 POST를 사용하고, URI를 수정하면 된다. /members/{id}/delete
이러한 URI를 컨트롤 URI 라 하고, 동사로 된 리소스 경로를 사용한다.
참고) URI 설계 개념 - https://restfulapi.net/resource-naming
REST API - URL Naming Conventions
In REST, having a strong and consistent REST resource naming strategy – will prove one of the best design decisions in the long term.
restfulapi.net
• 문서(document) - 정적
• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• 예) /members/100, /files/star.jpg
• 컬렉션(collection)
• 서버가 관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• 예) /members
• 스토어(store)
• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• 예) /files
• 컨트롤러(controller), 컨트롤 URI
• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예) /members/{id}/delete
본 포스팅은 인프런 강의 김영한님의
[ 모든 개발자를 위한 HTTP 웹 기본 지식 ] 을 수강하며 작성한 내용입니다.