OSI 7계층과 TCP/IP 4계층
과거에는 통신용 규약이 표준화 되지 않았고 각 벤더에서 별도로 개발했기 때문에 호환되지 않는 시스템이나 애플리케이션이 많았으며 서로 통신하기에 어려움이 있었습니다. 이를 ARPANET에서 TCP/IP 4계층으로 정리하고, OSI 7계층으로 세분화 되면서 네트워크의 동작을 나누어 설명하고 있습니다.
뿐만 아니라 네트워크 프로토콜 전체를 개발하는 대신, 계층별로 프로토콜을 개발하여 네트워크 구성 요소들을 모듈처럼 사용할 수 있게 되었습니다.
OSI 7계층은 네트워크를 총 7개의 계층으로 나누며, TCP/IP 4계층의 경우는 이를 크게 4개 계층으로 나누었습니다. 이를 도식화 하면 아래의 그림과 같습니다.
OSI 7계층은 데이터 플로우 계층과 애플리케이션 계층으로 구분 할 수 있습니다. 이러한 구분은 데이터를 만드는 애플리케이션 부분과 이 데이터를 잘 전달하는데 집중하는 하부 계층으로 구분하는 것에 목적을 두었습니다. 그러나 현대의 네트워크는 대부분 기술 발전을 거쳐, 합리적이고 성능이 우수한 TCP/IP 프로토콜과 이더넷으로 이루어져있습니다. 그렇기 때문에 TCP/IP 4계층 모델은 이론보다는 실용성에 중점을 둔 프로토콜입니다.
두 계층 모델 모두 물리적인 계층에 가까운 부분을 하위 계층(Lower Layer)라고 부르며, 개발자가 직접 접하게 되는 애플리케이션에 가까운 부분을 상위 계층(Upper Layer)이라고 부릅니다. 따라서 애플리케이션을 개발하는 개발자는 하향식으로 네트워크를 바라보게 되며, 애플리케이션 계층을 OSI 7계층에서는 7계층, 물리 계층을 1계층으로 명명합니다.
OSI 7계층을 기준으로 각 계층을 간단하게 설명하자면 다음과 같습니다.
- 물리 계층 : 주로 물리적 연결과 관련된 정보를 정의합니다. 주로 전기 신호를 전달하는데 초점을 두고, 들어온 전기 신호를 그대로 잘 전달하는 것이 목적입니다.
- 데이터 링크 계층 : 물리 계층에서 들어온 전기 신호를 모아 알아 볼 수 있는 데이터 형태로 처리 합니다. 이 계층에서는 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행합니다.
- 네트워크 계층 : 이 계층에서는 IP주소와 같은 논리적인 주소를 정의합니다. 또한 라우터를 통해 정의한 IP주소를 이해하고, 이를 사용해 최적의 경로를 찾아 패킷을 전송합니다.
- 전송 계층 : 하위 계층에서 신호와 데이터를 올바른 위치로 보내고 신호를 만드는데 집중했다면, 전송 계층에서는 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 합니다. 네트워크 계층에서 사용되는 패킷은 유실되거나 순서가 바뀌는 경우가 있는 데, 이를 바로 잡아주는 역할도 담당합니다.
- 세션 계층 : 세션 계층은 양 끝 단의 프로세스가 연결을 성립하도록 도와주고, 작업을 마친 후에는 연결을 끊는 역할을 합니다.
- 프레젠테이션(표현) 계층 : 이 계층에서는 일종의 변역기 같은 역할을 수행합니다. MIME 인코딩이나 암호화, 압축, 코드 변환과 같은 동작이 이 계층에서 이루어집니다.
- 애플리케이션(응용) 계층 : 애플리케이션 프로세스를 정의하고, 애플리케이션 서비스를 수행합니다. 이 계층에서 사용되는 프로토콜은 다양한 종류가 있지만, 대표적인 프로토콜로는 HTTP, FTP, SMTP 등이 있습니다.
HTTP
HTTP 역사는 다음과 같습니다.
HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3는 UDP 기반 프로토콜입니다.
HTTP 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성(Connectionless)
- HTTP 메세지
- 단순함, 확장 가능
무상태 프로토콜
상태 유지가 되어야 하는 프로토콜이라면 클라이언트 A의 요청을 서버 1이 기억하고 있기 때문에 항상 서버 1이 응답해야합니다.
만약 서버 1이 장애가 난다면 유지되던 상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 합니다.
무상태 프로토콜이라면 클라이언트 A가 요청할 때 이미 필요한 데이터를 다 담아서 보내기 때문에 아무 서버나 호출해도 됩니다.
만약 서버 1에 장애가 생기더라도 다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없습니다.
무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능합니다.
무상태는 다음과 같은 한계를 가지고 있습니다.
로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만
로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지합니다.
HTTP stateless 최적화
HTTP 초기에는 각각의 자원을 다운로드하기 위해 연결과 종료를 반복해야 했습니다.
HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결을 종료합니다
