[브라우저] 인터넷 상의 클라이언트 - 서버 통신 과정

내가 개발하는 코드가 어떻게 서버와 통신하고 그 결과를 받아오는 지에 대해 전체적인 그림을 그리지 못하고 지금껏 개발해온 것 같아요. "브라우저는 HTTP 프로토콜 기반의 통신을 한다", "TCP 통신은 3way handshake로 신뢰성을 확보한다.", "브라우저는 TCP / IP 기반의 통신을 한다." 이런 말들 중 하나도 제대로 이해하고 있는 게 없더라구요.

 

그래서 네트워크에 대해 잘 모르는 웹 개발자(저)를 대상으로 클라이언트 - 서버 간의 통신 과정을 쉽게 이해하기 위한 글을 써보았어요 ✨

 

목차

1. 인터넷 상의 클라이언트 - 서버 통신 과정
   1. DNS : 주소를 IP 주소로 변환하기
   2. HTTP 요청 : 요청 메시지 전송 과정
   3. HTTPS
   4. URL 구성

추후 "브라우저 설계"와 "Chrome 개발자도구 기능" 등의 주제로 이어서 글을 작성해보려고 합니다.

 

네트워크 관점에서 클라이언트 - 서버 통신

 

우리가 컴퓨터로 어떤 웹 사이트를 접속할 때의 흐름을 천천히 들여다 보고자 합니다. chrome, safari 같은 브라우저 라는 프로그램을 열면, 공통적으로 주소창 UI가 표시됩니다. 우리는 이 주소창에 사이트 주소를 입력하고 이동버튼이나 엔터를 눌러 해당 사이트로 이동합니다.그 후, 서버에서 응답을 받아오기까지의 과정을 네트워크 관점에서 먼저 살펴보려고 합니다.

 

 

만약 서버 컴퓨터가 같은 공간에 있고 물리적인 케이블로 연결되어 있다면, 케이블을 통해 서버 컴퓨터에 있는 데이터를 내 컴퓨터로 바로 전송할 수 있을거에요. 하지만 실제로 서버 컴퓨터는 멀리 있기 때문에, 위의 그림과 같이 복잡한 과정으로 요청을 보내야 합니다. 이 과정을 하나씩 뜯어봅시다.

 

통신사에서 인터넷을 설치하러 오면 보통 2개의 기계를 제공하는데요. 하나는 라우터, 하나는 모뎀입니다. 라우터는 우리 집에 있는 여러 기기의 신호를 받아서 모뎀으로 전달해주는 역할을 합니다. 또한, 무선 통신의 기능도 제공해요. 모뎀만 있으면 오직 1개의 기기만 연결 가능하지만, 라우터가 있으면 여러 기기를 인터넷에 연결할 수 있어요.

 

 

모뎀은 라우터를 통해 전달받은 디지털 신호를 아날로그 신호로 변환하는 역할을 합니다. 기존에 이렇게 변환된 신호는 전화선을 통해서 전송되었어요.

 

하지만 요즘에는 빛 신호로 변환해서 광케이블을 이용하여 전송하고 있답니다.

 

Q. 그럼 아주 먼 다른 국가는 어떻게 연결하고 있을까요?
A. 궁금해서 찾아보니 대부분의 국가들이 해저 광케이블을 통해서 연결하고 있더라구요. (국제 인터넷 트래픽의 99% 이상) 해저 광케이블이 깔려있지 않은 국가나 인공위성끼리의 통신은 장거리 무선 통신을 이용하긴 하지만, 대부분은 물리적인 케이블이 깔려있다고 해요. 이유는 빛을 통한 데이터 전송이 전파보다 빠르고 안정적이기 때문이라네요.

 

 

케이블을 통해 이동한 신호가 전달되는 ISP(Internet service provider)는 쉽게 말해 우리가 생각하는 "통신사" 입니다. 다른 통신사로 신호를 보내야 하기 때문에, ISP는 다른 ISP 로 신호를 보냅니다. ISP 에서는 다시 모뎀 - 라우터를 거쳐 서버 컴퓨터에 도달합니다.

 

지금까지의 내용을 요약해보면, 내 컴퓨터에서 시작한 요청이 "라우터", "모뎀" 이라는 물리적 장치를 거쳐서 ISP(통신사)로 이동한 뒤 다른 ISP(통신사)를 거쳐서 역순으로 다시 신호를 변환하면 서버 컴퓨터에 도달하게 되는 것이죠. 이러한 과정을 통해서 내 컴퓨터에서 내가 누른 주소창 입력 요청이 서버에까지 도달하게 됩니다.

 

전체적인 흐름을 파악했으니 브라우저 프로그램이 요청을 보낼 때 발생하는 일을 자세히 설명해볼게요.

 

DNS : 주소를 IP 주소로 변환하기

"주소창에 사이트 주소를 입력하고 엔터를 눌러 해당 사이트로 이동합니다." 에서 일어나는 일 중, 주소창에 입력한 사이트 주소를 이용해 실제 서버 컴퓨터 주소를 찾는 과정을 설명해보려고 합니다. 

 

먼저 주소창에 입력된 사이트 주소를 네트워크 상의 주소인 IP 주소로 변환해야 합니다. IP 주소는 0~255 사이에 있는 숫자 4개와 dot(.) 3개의 조합으로 이루어져 있습니다. 문자를 숫자로 바꾸기 위해 브라우저는 다음과 같은 과정을 거칩니다.

 

1. 먼저 내 컴퓨터의 hosts 파일을 참조하여 도메인과 연결된 IP 주소가 저장되어 있나 확인합니다.

  종종 개발 예제에서 /etc/hosts 파일을 수정하여 127.0.0.1 localhost 라인을 추가하면, 로컬에서 켠 서버를 켜기 위해 주소 창에 127.0.0.1 이 아닌 localhost 라는 문자열을 입력하면 된다는 안내를 보게 됩니다. 이 hosts 파일이 도메인 변환 시 가장 먼저 참조하게 되는 파일입니다.

 

2. 브라우저 캐시를 참조해서 도메인이 있나 확인합니다.

1번에서 hosts 파일을 참조하였으나, 요청하고자 하는 도메인의 IP 정보가 없다면 브라우저 캐시를 참조해서 이전에 해당 도메인을 통해 이동한 적이 있나 확인합니다. 있다면 해당 IP 주소를 사용합니다.

 

chrome 브라우저를 사용하고 있다면, 주소창에 chrome://net-internals/#dn 를 치고 들어가면 브라우저에 캐싱되어 있는 도메인의 IP 주소를 확인할 수 있어요.

 

3. localDNS (ISP의 DNS)를 참조해서 도메인이 있나 확인합니다.

ISP(통신사)들은 각자 Domain Name System 을 가지고 있습니다. 이 시스템을 이용하여 현재 입력한 도메인이 있는지 확인합니다.

 

4. 재귀적으로 Root DNS 를 찾아갑니다.

 

                               (Root)
                                    │
    ┌───────┼────────┐
     │                              │                                 │
  .com                       .org                           .net
     │                              │                                 │
 google.com     wikipedia.org           example.net
     │
 http://www.google.com

 

DNS는 계층적인 tree 구조로 되어 있습니다. 도메인의 IP 정보를 발견하지 못했다면, 계속 상위 DNS 로 올라가면서 도메인의 정보를 찾습니다.

 

이제 브라우저는 서버의 인터넷 상 주소를 획득하여 어디로 요청을 보내야 할지 파악했습니다. 그럼 이제 이 요청을 어떤 형태로 어떻게 보낼 건지에 대해 알아봅시다!

 

HTTP 요청 :  요청 메시지 전송 과정

브라우저에서 서버에 보내는 요청은 어떤 형태로 서버에 전송될까요?

 

브라우저에서 가능한 통신의 형식은 위와 같이 다양합니다. 하지만 주로 HTTP 방식을 사용하기 때문에 HTTP 통신에 대해서 살펴보려 합니다.

 

 

먼저 브라우저는 보내고 싶은 데이터를 HTTP 요청의 형태로 만듭니다. 그리고는 운영체제 프로그램이 다루는 네트워크 서비스를 이용하기 위해 운영체제가 제공하는 소켓의 인터페이스를 사용합니다. 브라우저는 운영체제에서 제공하는 소켓 인터페이스 중 send 라는 함수를 호출해서 만들어둔 HTTP 요청을 운영체제로 보냅니다. 운영체제의 네트워크 파트 중 TCP 스택이 소켓으로부터 해당 요청을 전달받습니다. TCP 스택은 전달받은 HTTP 요청 데이터에 다른 정보를 조금 더 추가해서 캡슐화 한 다음 IP 스택으로 보냅니다. IP 스택에서는 전달받은 데이터에 또 한번 다른 정보를 추가해서 캡슐화 한 다음 NIC(Network Interface Controller) 라는 물리적인 통신 장치로 요청을 보냅니다. NIC 는 이제 라우터로 신호를 전송하고 그 다음부터는 앞서 배웠던 흐름으로 신호가 전달됩니다.

 

TCP 에서의 캡슐화를 먼저 살펴봅시다. TCP 는 데이터의 신뢰성을 보장하면서 데이터를 쪼개고 헤더를 붙여 세그먼트라는 단위로 만듭니다. IP는 세그먼트를 받아 헤더를 붙이고 패킷이라는 단위로 만듭니다.

 

 

만약 IP 스택에 넘어 온 데이터가 하나의 패킷에 넣을 수 있는 데이터 단위인 MTU (Maximum Transmission Unit) 보다 크다면 어떻게 할까요? 우선 IP 스택은 패킷을 만들어서 보내려고 하고, 라우터 측에서 Fragment (패킷을 조각내는 것) 을 진행합니다. 따라서 라우터는 패킷을 전달하는 것 뿐만 아니라 계산을 추가로 해야하는 부담이 발생하고, 쪼개진 패킷 중 첫번째 패킷에 포트 정보가 담겨 있기 때문에 해당 패킷이 손실되면 전체 패킷을 다시 보내야 합니다. 이렇게 IP 계층은 신뢰성을 보장하지 않기 때문에, TCP 계층에서 이를 해결해야 합니다.

TCP 가 미리 MTU 에 들어갈 만한 크기로 데이터를 쪼개는 작업을 합니다. 이 때, MSS (Maximum Segment Size) 라는 최대 세그먼트 크기는 IP 헤더와 TCP 헤더의 크기를 모두 고려해서 MTU 가 넘지 않도록 데이터 크기를 조정하여 결정합니다. 미리 IP 계층에서 fragment를 하지 않을 법한 크기로 Data 를 쪼개서 세그먼트화 하는 것이죠.

 

 

TCP 에는 이런 헤더들을 붙여서 세그먼트를 만듭니다. 주요한 정보들만 표시해보았는데요.

 

먼저 요청을 보내는 출발지 주소와 요청이 도착해야 할 도착지 주소를 표시하고,

현재 보내는 세그먼트가 같은 요청의 몇번째 세그먼트인지를 나타내는 index를 표시합니다.

앞으로 설명할 3way handshake 라는 과정에 사용되는 flag bit 를 저장하는 공간도 있구요.

클라이언트가 한번에 받을 수 있는 데이터 크기를 알려주기 위한 데이터도 있고,

데이터가 손상없이 왔는지를 체크할 수 있는 데이터도 추가해줍니다. 

 

 

3way handshake는 전송된 데이터가 목적지까지 도달할 수 있을지에 관한 신뢰성을 보장하기 위한 과정입니다.

쉽게 SYN는 해줘. ACK는 확인. 이라고 생각하면 되는데요. 다음과 같은 과정을 거칩니다.

 

1. 클라이언트는 서버에 SYN, Seq = X 라는 요청을 보냅니다.

  연결을 요청하고, 데이터는 X 부터 시작할거라는 뜻입니다.

2. 서버는 클라이언트에 SYN, Seq = Y | ACK, Ack = X+1 을 보냅니다.

  X 부터 시작할거라는 연결 요청은 잘 받았고 (ACK), 나도 연결 요청하는데 데이터는 Y부터 시작할거 SYN)라는 뜻입니다.

3. 클라이언트는 서버에 ACK, Ack = Y + 1 을 보냅니다.

  Y 부터 시작할거라는 연결 요청 잘 받았어 라는 뜻입니다.

 

이렇게 3번의 요청을 주고 받으면 연결이 성사되고 데이터가 목적지까지 도달할 수 있다는 신뢰성을 확보하게 됩니다.

 

HTTPS 

HTTPS 는 HTTP + Secure(보안) 를 의미합니다. 여기서 보안이란 TLS(Transport Layer Security) 가 추가된 것으로,
예전에는 SSL(Secure Socket Layer) 을 사용했다가 보안상 취약점이 발견되어 현재는 TLS 가 최신 보안 표준입니다. TLS 암호화는 TCP계층에 의해 데이터가 세그먼트화 되기 전에 이루어집니다. 대칭키 암호화의 과정을 거치나, 이 글에서 자세히 다룰 정도로 중요한 내용은 아닌 것 같아서 따로 참고할 글을 첨부해둡니다.

 

https://docs.tosspayments.com/resources/glossary/tls

 

URL 구성

• 프로토콜 : 통신 규약 (e.g. http, https, ftp, file, mailto 등)
• 호스트 : 서버 컴퓨터 주소
• 경로 : 서버 컴퓨터 상의 리소스 위치
• 파라미터 : 추가적인 정보를 주기 위한 key=value 형태의 파라미터
• fragment (=anchor, hash) : 특정 위치로 이동하기 위한 책갈피

 

Appendix

https://algoroot.tistory.com/110

https://velog.io/@jeonbyeongmin/HTTP-%EB%81%9D%EC%9E%A5%EB%82%B4%EA%B8%B0

 

---

긴 글 끝까지 읽어주셔서 감사합니다. 틀린 내용이 있다면 가감없이 지적해주세요 🫡