2.6네트워크 흐름(예시)

사용자가 웹 사이트(이번 예시에선 www.google.com) 에 접속하기까지의 흐름을 따라가보자.

관련해서, 이 주제는 예전에 다른 글에서 다룬 적이 있었다. 당시에는 뭐가 뭔지도 모르고 검색해서 찾은 내용을 정리했던 것 같은데, 이번 기회에 네트워크의 기본 틀을 다지고 다시 정리해보니 훨씬 흐름이 명확해졌다고 느낀다.

36. 웹 사이트에 접속하기 위한 네트워크 흐름

송신자냐 수신자냐에 따라 OSI 7 계층 중 어디서 시작하는지가 달라진다. 송신자는 OSI 7 계층에서 시작해 데이터에 헤더를 하나씩 추가해 나가고, 수신자는 OSI 1 계층에서 전기 신호를 받아 헤더를 하나씩 벗겨내면서 최종적으로 데이터를 취득한다.

장비 측면에서, LAN 내부 통신은 스위치와 MAC 주소를 기반으로 동작하고, 서로 다른 네트워크끼리 통신하려면 라우터와 IP 주소를 이용한다.

37. 웹 브라우저에서 데이터 검색하기

37-1. 데이터를 보내는 송신자 관점에서 네트워크 이해하기

사용자는 웹 브라우저를 실행해 웹 사이트에 접속을 시도한다.

웹 브라우저는 응용 계층에 있는 애플리케이션이다. 인간의 언어인 한국어, 영어와 달리 컴퓨터는 0과 1만 인식하기에 컴퓨터와 상호 작용하기 위해 우리는 애플리케이션, 이 경우엔 웹 브라우저를 사용한다.

사용자는 웹 브라우저를 열어 http://www.google.com 을 입력한다. 이 주소는 컴퓨터 입장에선 알아들을 수 없는 도메인 주소이므로, IP 주소를 찾기 위해 DNS 질의를 거치는데, 보통 UDP로 이루어진다.

이렇게 해서 www.google.com 에 대응하는 IP 주소를 알아냈다면, 이제 그 IP와 통신하기 위해 TCP 3-Way Handshake를 수행한다. 클라이언트(사용자 PC)는 먼저 SYN 패킷을 서버의 443번 포트(HTTPS 기본 포트)로 보내고, 서버는 SYN+ACK로 응답한 뒤, 클라이언트가 마지막으로 ACK를 보내면 TCP 연결이 확립된다. 물론 이때 SYN, SYN+ACK, ACK는 모두 패킷이며, 각각이 전송될 때마다 1~4 계층을 모두 거쳐 내려가고, 반대편에서 다시 위로 올라온다.

TCP 연결이 준비되면, 그 위에서 TLS(HTTPS) 핸드셰이크가 진행된다. TLS Handshake는 아래와 같은 순서로 진행되는데, 사실 아래는 TLS 1.2 버전이고 요즘은 더 고도화된 TLS 1.3 버전을 쓴다.

아래의 HTTPS와 TLS/SSL에 대해선 이전에 찾아보고 정리한 다른 포스팅에서 보다 상세히 다루었다.

1. 브라우저는 ClientHello 메시지를 보내는데, 이 메시지엔 클라이언트가 지원하는 TLS 버전, 지원하는 암호 제품군, 그리고 클라이언트 무작위라고 불리는 무작위 바이트 문자열이 포함된다.
2. 서버는 이에 ServerHello라는 메시지를 보내는데, 이 메시지는 서버의 SSL 인증서, 서버에서 선택한 암호 제품군, 그리고 서버에서 생성한 또 다른 무작위 바이트 문자열인 서버 무작위를 포함한다.
3. 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증한다. 서버가 인증서에 명시된 서버인지, 그리고 클라이언트가 사용중인 서버가 실제 해당 도메인의 소유자인지를 확인한다.
4. 클라이언트는 예비 마스터 암호라고 불리는 무작위 바이트 문자열을 하나 더 전송하는데, 이 암호는 공개키로 암호화된 것이고 서버가 개인 키로만 해독할 수 있다. 클라이언트가 공개키로 암호화할 수 있는 것은, 서버의 SSL 인증서를 통해 공개키를 받기 때문이다.
5. 서버는 예비 마스터 암호를 자신의 개인 키로 해독하고, 클라이언트와 서버가 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 이용해 세션 키를 생성한다. 모두 같은 결과다.
6. 클라이언트는 이 세션 키로 암호화된 완료 메시지를 전송한다. 서버 역시 세션 키로 암호화된 완료 메시지를 전송한다.
7. 핸드셰이크는 완료되었다. 이제 이 세션 키로 이후 통신 내용을 암호화하여 진행한다.

이미지 출처 : #

브라우저는 이 암호화된 통로 위에서 HTTP 요청을 보낸다. 우리가 https://www.google.com 을 사용한다는 것은 HTTP 프로토콜을 사용하되, 이를 TLS로 감싼 HTTPS 형태로 443번 포트를 통해 통신한다는 의미다.

사용자는 데이터를 전송 계층으로 내려보내기 전에 응용 계층에서 먼저 HTTP 요청 메시지를 만든다. 여기서 데이터는 https://www.google.com 이라는 사이트의 첫 페이지를 보여달라는 요청이다. 이 첫 페이지는 관례적으로 index.html이며, 실제 https://www.google.com/index.html 은 index.html을 생략한 것과 동일한 화면이 나타난다. 이는 단지 주소를 보다 간단하게 보여주기 위해 생략된 결과다.

HTTP 요청은 HTTP 메서드, 경로, 그리고 버전을 사용한다. 우리의 예시에서 사용자는 데이터를 가져오므로 GET 메서드를 사용하고, 경로는 /index.html이다. 버전은 가장 많이 사용되는 2.0을 사용한다고 가정하자. HTTP 버전은 앞서 TLS 핸드셰이크 과정에서 ALPN이라는 확장 기능을 통해 이 연결에서는 h2(HTTP/2)를 쓰자고 협상한 결과다. 이렇게 응용 계층에서 요청할 데이터가 정의된다.

이렇게 응용 계층에서 요청할 데이터가 정의되면, 이 데이터는 전송 계층(TCP)으로 전달되어 헤더가 추가되고 세그먼트라고 불리게 된다. 이 TCP 헤더에는 출발지 포트(클라이언트에서 임의로 할당된 1024~49151 사이의 포트)와 목적지 포트(여기서는 HTTPS라서 443번), 그리고 순서 제어를 위한 시퀀스 번호, 재전송과 흐름 제어를 위한 각종 플래그와 윈도우 크기 정보가 포함된다.

세그먼트는 네트워크 계층으로 전달되어, IP 주소가 헤더로 붙어 패킷이라고 불리게 된다. 상대방의 IP 주소는 DNS를 통해 알아낸 주소이고, 라우터는 이 목적지 IP를 보고 라우팅 테이블에서 다음 경로(다음 라우터)를 결정한다. 패킷에는 송신자(클라이언트)의 IP 주소와 수신자(서버)의 IP 주소가 포함된다.

이 패킷은 데이터 링크 계층으로 보내져, 송신자와 수신자의 MAC 주소가 붙은 프레임이라는 단위가 된다. 서로 다른 네트워크 간 통신에선 최종 수신자의 MAC 주소를 모르는 대신, 먼저 내가 속한 네트워크의 기본 게이트웨이(라우터)의 MAC 주소를 목적지로 사용한다. 이렇게 하면 프레임은 라우터까지 전달되고, 이후 라우터들이 목적지 IP를 보고 다음 라우터 방향으로 MAC 주소를 바꿔가며 전달을 이어간다.

이 프레임은 마지막으로 물리 계층으로 전달된다. 프레임은 랜 카드를 통해 전기 신호로 변환된다.

37-2. 장비 관점에서 데이터 흐름 이해하기

장비 관점에서, 우선 송신자가 보낸 데이터는 스위치를 통한다. 목적지 IP는 외부 네트워크이기 때문에, 송신자는 목적지 MAC 주소를 우선 자신의 기본 게이트웨이(라우터)의 MAC 주소로 설정해 프레임을 만든다. 스위치는 이 프레임을 보고 라우터 쪽 포트로 그대로 전달한다.

라우터로 온 데이터는 수신자 IP를 확인하기 위해 헤더를 뜯어보는데, 먼저 라우터는 데이터 링크 계층에서 수신자의 MAC 주소를 자신의 주소와 비교한 후 라우팅 테이블에서 수신자 IP 주소가 등록되어 있는지 확인한다. 등록되어 있다면, 해당 주소를 찾아갈 경로를 설정하기 위해 먼저 송신자의 IP 주소를 자신의(라우터 + NAT) IP 주소로 바꾼다. 여기서, 바꾸는 IP 주소는 WAN 환경에서 사용할 수 있는 공인 IP 주소로, 다른 라우터와 통신하기 위함이다. 라우터는 2개의 IP 주소를 가지고 있는데, 하나는 네트워크 내부 컴퓨터들이 사용하는 라우터의 IP 주소이고, 다른 하나는 외부 네트워크들과 통신하기 위한 IP 주소이다.

라우터 간의 통신에서 라우터는 IP 헤더의 출발지·목적지 IP는 그대로 둔 채, 각 홉마다 "출발지·목적지 MAC 주소"는 자신과 다음 라우터의 것으로 바꿔서 전달한다. 이후, 해당 데이터는 데이터 링크 계층으로 보내져 이더넷 헤더가 다시 붙고 물리 계층으로 내려보내 데이터를 전기 신호로 바꾸어 다른 라우터로 전달된다.

라우터들을 거쳐 수신자 IP가 라우팅 테이블에 있는 최종 라우터에 도착하면, 해당 라우터는 Google 웹 서버의 공인 IP 주소인 142.xxx.xxx.xxx에 요청 데이터를 전송하는데, 이 때 요청자(송신자)의 IP 주소는 해당 라우터의 주소다.

요컨대, 장비 관점에서의 통신은 송신자에서 수신자까지 중간에 라우터를 만나면 MAC 주소와 IP 주소를 라우터 것으로 바꿔서 라우터 간 통신을 한다는 것이다.

37-3. 데이터를 받는 수신자 관점에서 네트워크 이해하기

웹 서버에 도착하는 것은 물리 계층의 전기 신호다. 전기 신호는 데이터 링크 계층에 전달되는데, 여기서 수신자 MAC 주소가 자신의 것과 같으면 MAC 정보가 든 이더넷 헤더를 분리시켜(역캡슐화) 네트워크 계층으로 보낸다.

네트워크 계층에선 수신자의 IP 주소를 확인하고, 해당 주소가 자신의 것과 같으면 IP 정보가 든 IP 헤더를 분리시켜 전송 계층으로 전달한다.

전송 계층에선 TCP 포트 번호를 확인하고, TCP 헤더를 분리해 응용 계층으로 보낸다.

응용 계층에선 최종적으로 송신자의 요청 데이터만 남는다. 웹 서버는 index.html을 응답하는데, 이 응답은 지금까지의 경로와 반대 방향으로 흐르며, 처음에 요청을 보냈던 송신자(사용자 PC)의 응용 계층까지 역캡슐화되어 도착한다.

이 모든 과정은 자동으로 이루어지는데, 우리가 일상에서 하는 웹 검색, 이메일 주고 받기 등 모든 행위는 이런 네트워크 과정의 반복이라고 할 수 있다.

🤠 개인 탐구

이후 헷갈릴때, 종종 이 포스팅을 보며 참고할 수 있도록 OSI 7계층 요약 표를 만들었다. 무선 AP나 Wi-fi(802.11)은 다음 포스팅에서 다룬다.