인터넷 프로토콜 4계층
IP 패킷
출발지 IP, 목적지 IP, 데이터, 기타.. 정보를 담고있다.
IP 프로토콜의 한계
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송 = 상대방의 컴퓨터가 꺼져있어도 그냥 보낸다.
- 비신뢰성
- 중간에 패킷이 사라질 수 있다.
- 패킷이 순서대로 도착한다는 보장은 없다.
- 프로그램 구분
- 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
TCP(Transmission Control Protocol)
출발지 Port, 목적지 Port, 전송 제어, 순서, 검증 정보...등을 가지고 있다.
아래와 같은 특징들로 IP 프로토콜의 한계를 해결해준다.
- 연결지향 - TCP 3 way handshake (가상 연결)
- 신뢰할 수 있는 프로토콜
- 데이터 전달 보증
- 순서 보장
- 현재는 대부분 TCP 사용
TCP 3 way handshake: 클라이언트와 서버가 통신하기 위해 먼저 연결하는 과정
[클라이언트]: 연결해도 돼? - > [서버]: ㅇㅇ 해도 돼, 나도 해도 돼? -> [클라이언트]: ㅇㅇ 해도 돼
PC와 PC 사이에 수 많은 노드들을 통해서 요청을 주고받으므로 연결이 됐는지는 알 수 없기 때문에 TCP 연결은 실제로 물리적으로 연결된 것이 아닌 논리적으로 연결된 것이다.
전달 보증
데이터를 보내면 받은 측에서 받았다는 메세지를 보내주기 때문에 데이터가 잘 보내졌는지 알 수 있다.
순서 보장
패킷이 랜덤하게 도착했다면 다양한 방법이 있지만, 기본적으로 잘못온 시점부터 다시 보내라고 요청한다.
1 - 3 - 2 순서로 도착했다면 2번부터 다시 보내도록 한다.
UDP (User Datagram Protocol)
- 기능이 거의없기 때문에 애플리케이션에서 추가 작업이 필요하다 => 자신이 프로토콜을 최적화 할 수 있을 때 사용할 수도 있다.
- 연결 지향 - TCP 3 way handshake x
- 데이터 전달 보증 x
- 순서 보장 x
- 신뢰성은 떨어지지만 빠르기 때문에 게임이나 미디어 데이터 전송에 적합하다.
- IP와 거의 같지만, Port 정보와 체크섬이 추가되었다.
PORT
한번에 여러 개의 프로그램을 사용할 때 여러 개의 패킷이 들어오게되는데, 이 때 해당 패킷을 적절한 애플리케이션으로 전송하기 위해 PORT가 사용된다. 따라서 TCP/IP 패킷에 PORT 정보를 담아서 보내게된다.
하나의 포트에서 두 가지 이상의 포트를 돌리는 것은 불가능하다. -> OOOO port already use 라는 에러를 자주 보았을 것이다.
0~65535까지 할당 가능하며 0~1023는 잘 알려진 포트로 사용하지 않는 것이 좋다.
DNS(Domain Name Service)
인터넷 주소는 123.123.123.123 처럼 숫자로 되어있어 다양한 서버가 있을 때 외우기가 힘들다.
DNS 서버에는 도메인 이름(google.com)과 IP(123.123.123.123) 정보를 가지고 전화번호부 같은 역할을 하는 서버이다.
HTTP (HyperText Transfer Protocol)
HTTP 요청은 TCP/IP 패킷 안에 담겨서 전송된다.
텍스트, HTML, 이미지, 음성, 영상, 파일, JSON 등 거의 모든 데이터를 전송한다.
HTTP의 종류
- TCP 기반: HTTP/1.1, HTTP/2
- UDP 기반: HTTP/3
1 .1과 2, 3의 차이는 성능 개선의 차이이며, 3은 UDP 기반이라 더욱 빨라졌다.
HTTP/3가 가장 최신 기술이라고 HTTP/3만 사용하는 것이 아니고 1, 2, 3 모두 사용되며, 1.1이 가장 많이 사용된다.
아래 네이버와 유튜브 접속 시 프로토콜 로그에서 3가지 HTTP 프로토콜을 전부 사용하는 것을 볼 수 있고, 특히 영상을 다루는 유튜브는 속도가 빠른 HTTP/3를 자주 사용하는 것을 확인할 수 있다.
클라이언트 서버 구조
HTTP 프로토콜은 클라이언트 서버 구조를 가지고 클라이언트는 서버에 요청을 보내고, 서버는 응답한다.
서버와 클라이언트 구조로 나눠 복잡한 비즈니스 로직은 서버에서 다 처리하도록하고, 클라이언트는 UI에 집중할 수 있다.
무상태(Stateless) 프로토콜
Stateful
Stateless
Stateful은 유저가 요청을 보낼 때 보내는 데이터의 양이 Stateless 보다 적지만, 점원이 바뀌는 상황(서버가 바뀌는 상황)에서 장애가 발생할 수 있다.
반면, Stateless는 서버가 바뀌는 상황에서도 전혀 문제가 없기 때문에 응답 서버를 쉽게 바꿀 수 있다는 장점을 가져 서버를 증설하기 쉽다즉, 수평 확장이 용이하다는 장점을 가진다. 이러한 특징 때문에 Stateless는 아주 중요한 개념이다.
Stateless의 한계
- stateful 보다 데이터를 더 많이 보내야한다.
- 로그인이 필요한 것처럼 상태를 유지해야하는 경우가 있다.
따라서 stateful은 어쩔 수 없이 필요한 경우에만 최소한으로 사용한다.
비 연결성(connectionless)
클라이언트와 서버가 TCP/IP 연결(3 way handshake)을 하고, 요청을 전송한 다음 응답을 받으면 연결을 끊어버린다.
웹에서는 보통 끊임없이 요청을 보내는 것 보다 페이지를 보다가 요청을 보내고, 또 보다가 요청을 보내는 방식이기 때문에 지속적인 연결을 통해 동시에 많은 수의 클라이언트와의 커넥션을 유지하는 것 보다 연결을 했다 끊었다 하는 것이 더 효율적이다.
하지만 지속적인 요청을 보내야하는 경우도 있는데, 최근에는 하나의 페이지에 접속할 때 HTML, CSS, JS 등 많은 데이터를 보내줘야하기 때문에 HTTP 지속 연결(Persistent Connections)을 사용해서 해결한다.
Persistent Connections는 HTML,CSS,JS 등 필요한 파일을 모두 보낸 후 연결을 종료하며, HTTP/2, 3에서 더 많이 최적화되어 사용되고 있다.
HTTP 메세지
시작 라인
요청 메세지 (GET /search?q=hello&hl=ko HTTP/1.1)
- HTTP 메서드 (GET, POST ...)
- 요청 대상: /search?q=hello&hl=ko (절대 경로)
- HTTP 버전: HTTP/1.1
응답 메시지 (HTTP/1.1 200 OK)
- HTTP 버전
- HTTP 상태 코드: 200, 400, 500
- 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글 = OK, CREATED ...
HTTP 헤더
HTTP 전송에 필요한 모든 부가 정보: body 내용, 메세지 크기, 압축, 인증, 요청 정보, 캐시 정보, 서버 정보 등등의 메타데이터
HTTP Body
실제 전송할 데이터 : HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능
HTTP API 설계 포인트
URI를 정할 때 가장 중요한 것은 리소스가 잘 식별 되어야한다.
단, 동사가 나올 수 밖에 없는 경우도 있다. 그럴 때도 무조건 리소스 명사형으로 쓰기보다는 최대한 리소스 위주로 작성하되 어쩔 수 없는 경우에는 해당 동작에 대한 명시를 사용해도된다.
아래 예시에서는 회원이라는 리소스가 잘 식별되고 있다. 하지만 각각의 URI가 똑같이 생겼기 때문에 구분을 하기가 쉽지않다.
이런 경우 HTTP 메서드를 통해 URI를 구분할 수 있다.
HTTP Method
GET은 캐싱을 통해 기록을 남길 수 있기 때문에 단순 조회에 대한 요청 시 사용하면 리소스를 효율적으로 사용할 수 있다.
캐싱 예시로는 이때까지 봤던 페이지들을 뒤로가기로 다시 돌아가서 볼 수 있다.
반대로 말하면, 기록이 남으면 안되는 요청에 대해서는 GET을 사용하지 않는 것이 좋다.
POST는 무조건 등록할 때만 사용하는 것이 아니라, 주로 등록할 때 쓰이지만, 요청 데이터를 처리할 때도 사용한다.
단순히 데이터를 생성하거나, 변경하는 것을 넘어 프로세스를 처리해야하는 경우 즉, 서버에서 새로운 리소스가 생성되지 않더라도 큰 변화가 일어나는 경우는 POST를 사용한다.
POST는 모든 경우에 다 사용할 수 있기 때문에 다른 메서드로 처리하기 애매할 때는 POST를 사용하면 된다.
PUT은 리소스를 대체한다. 그냥 대체하는 것이 아니라 완전히 대체한다 = 새로운 데이터로 덮어버린다.
리소스를 대체하기 위해서는 클라이언트가 리소스를 알고있어야한다.
예를 들어 age와 name 정보가 있는 객체의 name 값을 바꾸기 위해서 name 데이터만 전달한다면, 해당 객체의 처리 결과는 age가 없어진 name 필드만 있는 객체가 된다.
PUT이 리소스 전체를 바꾸는 방법이라면 PATCH는 부분적으로 데이터를 바꿀 수 있다.
위 예시를 똑같이 들었을 때 결과는 기존의 age와 새로운 name 값을 가진 객체가 된다.
DELETE는 말 그대로 리소스를 삭제할 때 사용한다.
Safe, Idempotent(멱등), 캐싱
GET은 변경이 일어나지 않는 요청이기 때문에 안전한 요청이다.
GET, PUT, DELETE: 몇번을 요청하든 결과가 같다(멱등성). 반면, POST는 같은 값이 2번 등록될 수 없는 경우 1번만 호출할 수 있다.
GET, POST, PATCH: 캐시가 가능하다. 하지만 POST와 PATCH는 본문 내용까지 캐시 키로 고려해야해서 캐싱을 잘 사용하지 않는다.
HTML FORM
html form에서는 GET, POST 두 가지 방법만 사용할 수 있다. 따라서 URI를 리소스만으로 표현하기에는 한계가 있다.
이런 경우 어쩔 수 없기 때문에 URI에 DELETE나 PUT 같은 요청 종류를 파악할 수 있는 control uri를 사용할 수 밖에 없다.
Reference
'개념 정리 > Network' 카테고리의 다른 글
| [Network] 네트워크 기초 개념 정리 (0) | 2023.12.01 |
|---|