[Interview] - 네트워크(업데이트)

uHan2·2021년 4월 18일

back end interview network study

Interview

목록 보기

3/5

비록 시작은 코딩일기지만, 그 끝은 창대하게
어엿한 개발자 블로그로 성장할 수 있도록.

Interview :: 네트워크

네트워크의 기본적인 내용을 간단히 정리해보자

Internet Protocol (IP)

IP Protocol은 지정한 IP 주소(IP Address) 에 데이터를 전달한다. 이때 패킷(Packet) 이라는 통신 단위로 데이터를 전달한다. 패킷에 출발지 IP 주소와 목적지 IP 주소 를 적고 인터넷 망에 던지면 인터넷 망의 노드들을 타고 목적지에 도달하게 된다. 패킷을 받은 목적지는 제대로 받았다는 메시지를 같은 방식으로 출발지에 다시 보내게 된다.

이렇게 IP 주소와 패킷을 바탕으로 우린 다른 국가의 PC에도 데이터를 전송할 수 있다. 하지만, 이 IP 프로토콜만 사용하기에는 다음과 같은 한계가 있다.

비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 무조건 전송한다.
비신뢰성
중간에 패킷이 사라지거나 패킷이 순서대로 들어오지 않는 경우에 대한 처리가 없다.
프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 경우 구분할 수 있는 방법이 없다.

그래서 이를 보완하기 위해 등장한 프로토콜들이 바로 TCP & UDP 이다.

(참고) 인터넷 프로토콜 스택의 4계층

(참고) URI, URL, URN 개념도

TCP

우선 TCP 프로토콜을 포함한 전체적인 데이터 흐름을 살펴보자.

이렇게 low level 로 가면서 보내고자 하는 메시지에 추가적인 데이터가 붙게 된다.
앞서 IP 프로토콜은 출발지와 목적지의 IP 주소가 저장된다고 했다. 그러면 TCP는 어떤 데이터를 추가할까?

그림과 같이 출발지와 목적지의 Port 번호, 전송 제어, 순서, 검증 정보 등의 데이터가 추가된다. 이처럼 TCP는 IP 프로토콜의 한계였던 데이터의 신뢰와 순차적인 전달을 보완한다. 현재 대부분은 TCP 프로토콜을 사용하고 있으며 IP 프로토콜과 함께 TCP/IP 라고 불리운다.

모든 TCP 연결은 전이중(full-duplex), 점대점(point to point) 방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다. TCP 는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

(참고) TCP 는 3 Way Handshake 라는 방식을 통해 연결을 맺는다.

UDP

하지만 UDP 프로토콜은 TCP 와 달리 별다른 기능은 없다. 마치 하얀 도화지 같다. 기존 IP 프로토콜과 유사한데 여기에 출발지와 목적지의 Port 번호, 체크섬 정도의 기능이 추가된다. 그렇다면 왜 존재하는지 의문을 갖을 수 있지만, TCP의 3 Way Handshake나 신뢰 및 순서보장 같은 기능이 없는 만큼 빠르다.

앞서 도화지 같다고 표현하였는데, TCP 는 그 자체로 사용할 뿐 여기에 최적화 등 무언가 손을 댈 수가 없다. 하지만 UDP 는 애플리케이션 Level 에서 원하는 입맛대로 손을 댈 수가 있다. 이런 특징으로 현재는 TCP의 점유율이 압도적이지만 HTTP 3.0 에서 TCP의 3 Way Handshake Cost를 줄여보고자 UDP 기반으로 만들어지며 최근 각광을 받고 있다.

HTTP

현재 HTML, TEXT, JSON, XML, 등 거의 모든 형태의 데이터는 HTTP를 사용하여 전송된다. 우리가 가장 많이 사용하고 있는 버전이 1997년에 등장한 HTTP 1.1 이다. HTTP 2.0 이나 HTTP 3.0 의 경우는 HTTP 1.1의 성능을 개선하는데에 초점을 두고 있다.

HTTP 1.1 과 HTTP 2.0 은 TCP 를 기반으로 동작하고 HTTP 3.0 은 상기 서술한대로 UDP 를 기반으로 발전하고 있다. HTTP 의 기본적인 특징은 다음과 같다.

Client - Server 구조
Client와 Server 두 개의 큰 개념으로 나누고 Client가 요청(Request) 를 날리면 Server는 그에 맞는 응답(Response)를 날린다.
무상태 프로토콜 (Stateless)
- 상태(Stateful) ::
- 무상태(Stateless) ::

상태를 유지하지 않음으로써 점원(응답 서버)를 무한대로 증식시킬 수 있고 이에 따라 Scale Out (수평 확장) 하는데에 큰 이점이 있다.

비연결성
HTTP는 기본적으로 연결을 유지하지 않는다. 이유는 간단하다. 연결을 유지해버리면 Client의 요청이 없더라도 계속해서 연결을 유지해야 하고 이 과정에서 자원을 소모하기 때문이다. 하지만, 우리가 브라우저에서 계속 연속해서 검색버튼을 누르지는 않듯이 1시간 동안 수천명이 서비스를 사용해도 막상 실제 서버에서 동시에 처리하는 요청은 수십개에 불과하기 때문에 Client의 요청이 있을 때만 연결을 맺어 응답을 보내주고 바로 연결을 끊는 것이 서버의 자원을 굉장히 효율적으로 사용할 수 있는 합리적인 방법이다.

물론 모든 연결을 비연결로 하기에는 한계가 있다. 따라서 HTTP Persistent Connections (지속연결) 과 같은 기술로 한계를 해결하고 있다. HTTP 2.0, HTTP 3.0 에서 더 많은 최적화가 이루어 졌다.
HTTP 메시지
기본적인 구조는 다음과 같다.
요청 메시지 ::
응답 메시지 ::