10월 27일 (수) 인터넷 프로토콜

남이섬·2021년 10월 27일
0

IP 와 IP Packet

(여기서 노드는 하나의 서버 컴퓨터를 의미한다)

IP 주소 부여

IP(인터넷 프로토콜) 주소를 컴퓨터에 부여하여 이를 이용해 통신한다

IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위 로 데이터 전달을 한다

IP 패킷 정보

IP 패킷에서 패킷은 pack과 bucket이 합쳐진 단어로 소포로 비유할 수 있다

IP 패킷은 이를 데이터 통신에 적용한 것이라고 보면 된다

IP 패킷은 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다

클라이언트 패킷 전달

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다

이를 통해 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있다

서버 패킷 전달

서버에서 무사히 데이터를 전송받는다면 서버도 이에 대한 응답을 돌려줘야한다

서버 역시 IP 패킷을 이용해 클라이언트에 응답을 전달한다

IP 프로토콜 한계

비연결성

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

비신뢰성

  • 중간에 패킷이 사라질 수 있음
  • 패킷의 순서를 보장할 수 없음

정확한 출발지와 목적지를 파악할 수 있다는 점에서 IP 프로토콜은 적절한 통신 방법으로 보이지만, 이러한 IP 프로토콜에도 이와같은 한계가 존재한다

비연결성

첫번째 비연결성

만약 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트서버의 상태를 파악할 방법이 없기 때문에 패킷을 그대로 전송하게 된다

비신뢰성

두번째 비신뢰성

중간에 있는 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트는 이를 파악할 방법이 없다

또한 전달 데이터의 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달하게 되는데, 이때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있다

이렇게 되면 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있다

TCP VS UDP

네트워크 프로토콜 계층은 다음과 같이 OSI 7계층TCP/IP 4 계층으로 나눌 수 있다

IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있다

  • TCP/IP 4 계층은 OSI 7 계층보다 먼저 개발되었으며 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지는 않는다

채팅 프로그램에서 메시지를 보낼 때 어떤 일이 일어나는 지 자세히 알아보자

  1. 먼저 HTTP 메시지가 생성되면 Socket 라이브러리를 통해 전달된다

프로그램이 네트워크에서 데이터를 송수신할 수 있도록, “네트워크 환경에 연결할 수 있게 만들어진 연결부“가 바로 네트워크 소켓(Socket)이다

  1. 그리고 IP 패킷을 생성하기 전 TCP 세그먼트를 생성

  2. 이렇게 생성된 TCP/IP 패킷은 LAN 카드와 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송된다

TCP/IP 패킷 정보

TCP 세그먼트에는
IP 패킷출발지 IP목적지 IP 정보를 보완할 수 있는
출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함한다

TCP 특징

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

  • 연결 지향 - TCP 3 way handshake(가상 연결)
  • 데이터 전달 보증
  • 순서 보장
  • 신뢰할 수 있는 프로토콜

TCP는 같은 계층에 속한 UDP에 비해 상대적으로 신뢰할 수 있는 프로토콜이다

TCP 3 way handshake

TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜이다

연결 방식

  1. 먼저 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보낸다

  2. 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACKSYN가 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다린다

  3. 클라이언트가 서버에게 ACK을 보내면 이 이후로부터 연결이 성립되며 데이터를 전송할 수 있다

  4. 만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 떄문에 데이터를 보내지 않는다

현재에는 최적화가 이루어져 3번 ACK을 보낼때 데이터를 함께 보내기도 한다

* SYN은 Syncronize, ACK는 Acknowledgment의 약자

데이터 전달 보증

또한 TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다

순서 보장

만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다

이를 통해 IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완할 수 있다

UDP 특징

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

  • 하얀 도화지에 비유(기능이 거의 없음)
  • 비 연결지향 - TCP 3way handshake X
  • 데이터 전달 보증 X
  • 순서 보장 X
  • 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
  • 신뢰성보다는 연속성이 중요한 서비스에 자주 사용됨

UDP는 IP 프로토콜PORT, 체크섬(checksum) 필드 정보만 추가된 단순한 프로토콜이다

앞서 TCP 특징과 비교해보면
신뢰성은 낮지만 3 way handshake 방식을 사용하지 않기 때문에,
TCP와 비교해 빠른 속도를 보장한다

HTTP3UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있다

아직 TCP와 UDP의 차이가 잘 와닿지 않는다면, 좋은 기능이 다 들어있는 무거운 라이브러리와 필요한 기능만 들어있는 가벼운 라이브러리로 비교할 수 있다

  • 체크섬(checksum)은 중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법

HTTP

HTTP 역사

HTTP/1.1, HTTP/2TCP 기반 이며,
HTTP/3UDP 기반 프로토콜이다

HTTP 특징

  • 클라이언트 서버 구조
  • 무상태 프로토콜 (Stateless), 비연결성 (Connectionless)
  • HTTP 메세지
  • 단순함, 확장 가능

클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다

무상태 프로토콜 (Stateless)

서버가 클라이언트의 상태를 보존하지 않음

  • 장점: 서버 확장성 높음 (스케일 아웃)
  • 단점: 클라이언트가 추가 데이터 전송

HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜이다

Stateful vs Stateless

상태유지 (Stateful) 예


카페에서 아메리카노 2잔을 신용카드로 결제한다고 가정해보자

상태가 유지되는 때에는 점원 A가 고객의 주문 상태에 대해 기억하고 있다

만약 중간에 점원A가 아닌 점원B가 그대로 고객을 접객한다고 가정해보자

이 경우 점원A만 고객의 주문을 기억하고 있기 때문에 상태정보를 다른 점원B에게 미리 알려줘야 한다

이렇게 점원A가 고객의 상태를 기억하고 있는 것을 상태를 유지한다고 한다

무상태 (Stateless) 예

무상태에서는 고객이 자신의 주문을 기억하고 있다면 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다

만약 갑자기 고객이 증가하더라도 무상태에서는 점원을 대거 투입할 수 있다

Stateful vs Stateless

  • 상태유지: 중간에 다른 점원으로 바뀌면 안된다
    (중간에 다른 점원으로 바뀐 때 상태 정보를 다른 점원에게 미리 알려줘야 한다)

  • 무상태: 중간에 다른 점원으로 바뀌어도 된다

    • 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다
    • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다
  • 무상태는 응답서버를 쉽게 바꿀 수 있다 (무한한 서버 증설 가능)

상태유지 Stateful

앞서말한 예제처럼 상태 유지가 되어야하는 프로토콜이라면 클라이언트A의 요청을 서버1이 기억하고 있기 때문에 항상 서버1이 응답해야한다

만약 서버1이 장애가 난다면 유지되던 상태정보가 다 날아가버리므로 처음부터 다시 서버에 요청해야 한다

무상태 Statelss

무상태 프로토콜이라면 클라이언트A가 요청할 때 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 된다

만약 서버1에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없다

무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능하다

실무 한계

  • 모든것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다
  • 무상태
    • e.g. 로그인이 필요없는 단순한 서비스 소개 화면
  • 상태 유지
    • e.g 로그인
  • 로기인한 사용자의 경우 로그인했다는 상태를 서버에 유지(e.g. 브라우저 쿠키, 서버 세션)
  • 상태유지는 최소한만 사용

무상태는 다음과 같은 한계를 가지고 있다

로그인이 필요없는 단순한 서비스 소개 화면같은 경우엔 무상태로 설계할 수 있지만

로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰등을 이용해 상태를 유지한다

TCP/IP의 경우 기본적으로 연결을 유지한다

연결을 유지하는 모델에서는 클라이언트 1,2는 요청을 보내지 않더라도 계속 연결을 유지해야 한다

이러한 경우 연결을 유지하는 서버의 자원이 계속 소모가 된다

비 연결성을 가지는 HTTP에서는 실제로 요청을 주고 받을 때만 연결을 유지하고,
응답을 주고나면 TCP/IP 연결을 끊는다

이를 통해 최소한의 자원으로 서버 유지를 가능하게 한다

비연결성 Connectionless

  • HTTP는 기본이 연결을 유지하지 않는 모델
  • 일반적으로 초 단위 이하의 빠른 속도로 응답
  • 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
    • e.g. 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다

HTTP 1.0 기준으로, HTTP는 연결을 유지하지 않는 모델이다

트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동한다

예를 들어, 한시간동안 수천명이 서비스를 사용해도, 실제 서버에서는 초당 처리 요청갯수는 수십개에 불과하다

하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 비연결성은 한계를 보인다

비연결성 Connectionless - 한계와 극복

  • TCP/IP 연결을 새로 맺어야 할 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드
  • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
  • HTTP/2, HTTP/3에서 더 많은 최적화

비 연결성은 다음과 같은 한계를 가진다

웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드된다

해당 자원들을 각각 보낼때마다 연결끊고 다시 연결하고를 반복하는 것은 비효율적이기 때문에, 지금은 HTTP 지속 연결(Persistent Connections)로 문제를 해결한다

HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했다

HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다

profile
즐겁게 살자

0개의 댓글