컴퓨터가 서로 통신하는 방법을 직접 확인해보기 위해 포스팅을 작성한다.
TCP/IP model(5-layer)
Application Layer(L-5)
응용 계층은 사용자가 데이터를 전송 / 수신할 수 있는 수단을 제공하는 계층이다. 주요 프로토콜은 HTTP이고 데이터 단위는 메시지이다.Transport Layer(L-4)
전송 계층은 서로 다른 호스트에서 실행되는 애플리케이션을 설정한다. 포트 번호를 통해 전송된 데이터가 어느 프로세스로 전달이 되어야 하는지 확인한다. 주요 프로토콜은 TCP/UDP이고 데이터 단위는 세그먼트이다.Network Layer(L-3)
네트워크 계층은 네트워크를 통해 이동할 패킷을 생성하고 IP 주소를 통해 패킷의 목적지를 판단하는 계층이다.
주요 프로토콜은 IP, 데이터 단위는 패킷이다.Data Link Layer(L-2)
데이터 링크 계층은 네트워크를 통해 이동하는 프레임을 생성하는 역할을 담당하고 MAC 주소를 통해 목적지를 확인한다. 주요 프로토콜은 이더넷, 와이파이고 데이터 단위는 프레임이다.Physical Layer(L-1)
물리 계층은 프레임화된 데이터를 0,1 전기적 신호로 변환하여 네트워크로 전송되는 계층이다.
How does it works?
위 글만 보아서는 머릿속에 잘 그려지지 않았다. 그래서 이해한 내용들을 그림을 그리며 되새겨보았다.
위 그림처럼 사용자가 입력한 데이터에 여러 헤더가 붙고(캡슐화) 물리 계층에서 전기적 신호로 변환되어 광케이블 등을 통해 목적지로 도착한다. 그럼 목적지(서버)에서도 동일하게 전송하고자 하는 데이터에 또 헤더들을 붙여서 원하는 목적지로 데이터를 전송하는 것이다.
각 계층에서 붙는 헤더들은 다음과 같다.
메시지 헤더
메시지 헤더는 응용 계층에서 생성되는 헤더이다. HTTP를 예시로 들면 메시지 헤더에는 요청 URL, 요청 메서드 상태 코드, 쿠키, 캐시 정보 등이 포함되어 있다.
세그먼트 헤더
세그먼트 헤더는 TCP에서 사용되는 헤더로, 신뢰성 있는 데이터 전송을 위해 사용된다. 데이터의 출발 / 목적지 포트 번호와 확인 응답번호, 헤더의 길이 등이 포함된다. 이 헤더를 통해 받은 데이터가 어느 프로세스에 해당하는 데이터인지 확인할 수 있다.
패킷 헤더
패킷 헤더는 네트워크계층, IP에서 사용되는 헤더로서 데이터가 목적지로 전달되기 위한 정보를 가진 헤더이다.
출발 / 목적지 IP와 데이터의 총 길이, IP 버전, 헤더 길이 등을 포함하고 있으며 이 데이터를 통해 해당하는 IP 주소를 가진 서버나 클라이언트로 이동할 수 있게 되는 것이다. 데이터가 이동간 만나는 라우터에서 이 헤더를 확인하고 데이터의 목적지를 파악하여 다음 노드로 전달한다.
프레임 헤더
프레임 헤더는 데이터 링크에서 추가되는 헤더로서, 네트워크에서 데이터를 전송하는 과정에서 사용되는 헤더이다. 출발 / 목적지 MAC 주소와 프레임 시작표시(데이터 전송을 알리는 비트), 데이터 유형, 길이, 오류 검사 필드 등이 이 헤더에 담긴다. 이 헤더를 통해 네트워크에서 어느 장치가 이 정보를 수신 받아야 하는지 알 수 있고, 데이터의 오류 확인이 가능하며, 프레임 시작 표시를 통해 데이터들을 식별할 수 있다. 스위치에서 프레임 헤더의 MAC 주소를 보고 어느 장치로 가야하는지 확인하고 해당 장치로 전달한다.
Let me check
직접 육안으로 확인해보자.
메시지 헤더
메시지 헤더는 크롬의 개발자 도구에서 쉽게 확인이 가능하다.
구글에서 초밥을 검색하여 가장 맛있어 보이는 초밥의 메시지 헤더를 가져와보았다.
앞서 말했던 것처럼 URL, 상태코드, 쿠키, 캐시정보들을 확인할 수 있다.
나머지 헤더들
다른 데이터들은 와이어샤크라는 네트워크 분석 툴을 통해 확인할 수 있다.
위에서 언급했던 것처럼, 각 계층별 헤더에 들어가는 정보를 모두 확인할 수 있다.
세그먼트 헤더에서 출발 포트번호(443) 목적지 포트번호(57912) 윈도우 크기(562) 등을 확인할 수 있고
패킷 헤더에서 출발 / 목적지 IP주소와 헤더길이 checksum 등을 확인할 수 있다.
프레임 헤더에서는 MAC 주소를 확인할 수 있었다.
우측에 있는 16진수 숫자들은 네트워크에서 전송되는 전기적 신호이다. 저 신호들이 이진 표현으로, 전기적 신호로 랜선을 따라 오고 간다고 보면 되겠다.
구글에서 초밥 데이터를 요청한 아주 짧은 0.46초 동안 데이터를 끄집어낸 것뿐만 아니라, 위처럼 많은 내용들을 담아서 내 PC로 보내주었다. 사용자에게는 아주 간단한 작업처럼 보이지만 데이터를 주고 받기 위해 많은 작업들이 이루어졌음을 간접적으로 확인할 수 있었다.
自問自答
TCP 3-way handshake 발생 기준?
클라이언트가 서버에 연결할 때 각 프로세스별로 3-way handshake가 발생한다. 그렇다면 연결할 때마다 3-way handshake가 발생한다는건데 내가 인터넷을 사용할 때는 어떨까?
다시 연결을 하는 기준은 프로그램을 종료시켰거나, TCP 세션 타임아웃 기간이 지났을 때, 클라이언트나 서버가 연결을 자체종료하고 FIN을 보냈을 때이다. 세션 타임아웃 기간은 보통 2시간에서 4시간으로, 연결이 유지되는 시간이다.
TCP는 연결지향적인데, HTTP는 비연결지향적?
TCP는 3-way handshake를 통해 서로 연결을 한 상태에서 데이터를 주고 받게 함으로써 신뢰성을 보장받는다. 그런데 TCP 위에서 작동하는 HTTP는 비연결적인 특성에 따라 HTTP의 요청마다 TCP의 새로운 연결이 생성되었다. 수없이 많은 요청이 발생하는 현대 웹 환경에서 이러한 방식은 연결하는데에만 자원을 크게 소비하게 되어 비효율적이었다.
그래서 HTTP/1.1에서 Persistent connection, HTTP Pipelining이라는 두 모델이 추가되어 사용되고 있다. Persistent connection 모델은 연속적인 요청 중에는 연결을 유지하는 것이고, Pipelining은 요청에 대한 응답이 오기 전에 비동기적으로 데이터를 요청하는 모델이다.
Persistent connection에서는 서버가 Keep-Alive 헤더를 통해 연결 유지시간을 설정할 수 있다.
즉, HTTP는 기본적으로 비연결성의 특징에 따라 연결을 유지하는데 필요한 자원을 아낄 수는 있으나, 그로 인해 연결할 때마다 발생하는 자원의 소비도 불가피한 특징을 가지고 있다. 그래서 Persistent connection 모델 등 단점을 보완하려는 노력도 하고 있다.
