요청 하나의 186ms

요즘 폰 화면은 대부분 정전식 터치 센서예요. 유리 아래에 가는 전극이 격자로 깔려 있고, 손가락이 닿으면 그 지점의 전기적 성질이 살짝 달라져요. 터치 컨트롤러 칩이 격자를 계속 훑다가 변화가 생긴 위치를 계산해 프로세서(AP)에 알려요.

프로세서에서는 OS가 이 입력을 받아 지금 화면 앞에 있는 앱, 여기서는 브라우저에 넘겨요. 브라우저는 화면 좌표와 페이지 요소들의 위치를 맞춰 보는 hit test화면의 어느 좌표를 눌렀을 때 그 자리에 있는 요소가 무엇인지 찾아내는 계산이에요.로 눌린 버튼을 찾아요.

이 단계는 전부 폰 안에서 일어나요. 프로세서가 주소 문자열을 해석하고, 캐시와 이미 열려 있는 연결 목록을 메모리(RAM)에서 찾아봐요. 그래서 시간이 아주 조금 걸려요.

페이지와 API의 도메인이 다르면 브라우저는 본 요청 전에 "이런 요청을 보내도 되나요?"라고 묻는 preflight다른 도메인으로 특별한 요청을 보내기 전에 브라우저가 OPTIONS 요청으로 먼저 허락을 묻는 절차예요. 요청을 하나 더 보내요. JSON을 POST하는 요청이 대표적이에요. 이 시나리오는 페이지와 API가 같은 도메인이라 그 왕복이 없어요.

통신사 resolver도 답을 모르면 대신 찾아 나서요. 루트 서버에 .com을 맡은 서버가 어디인지 묻고, 그 서버에 example.com을 맡은 서버를 묻고, 마지막으로 그 도메인을 관리하는 서버(예: Route 53)에게서 실제 주소를 받아요.

받은 답에는 TTLTime To LiveDNS 답을 몇 초 동안 기억해 둬도 되는지 알려 주는 값이에요.이 붙어 있어서 그 시간 동안은 resolver, OS, 브라우저가 답을 기억해 둬요. 그래서 실제로는 이 단계가 몇 ms 만에 끝나거나 아예 생략되는 경우가 많아요.

물리적으로는 질문 패킷이 폰 modem에서 전파가 되어 기지국까지 가고, 통신사 망 안의 DNS 서버까지만 다녀와요. 아직 AWS까지는 가지 않아요.

물리적으로 따라가 보면, SYNSynchronize"연결하고 싶어요"라는 뜻으로 처음 보내는 TCP 신호예요. 하나는 폰 modem에서 전파가 되어 가까운 기지국으로 날아가요. 기지국부터는 유선이에요. 통신사 코어망을 지나 광케이블로 된 인터넷 백본을 타고 AWS 서울 리전의 데이터센터로 들어가요.

같은 도시 안이라도 무선 구간에서 순서를 기다리는 시간과 여러 장비를 거치는 시간이 쌓여요. 그래서 모바일에서는 이 왕복 한 번에 수십 ms가 걸리는 일이 흔해요.

목적지는 443번 port한 컴퓨터 안에서 어느 프로그램에게 온 데이터인지 가르는 번호예요. https는 보통 443번을 써요.예요. 그 port에서는 ALBApplication Load BalancerAWS의 load balancer예요. 들어온 요청을 뒤에 있는 여러 서버에 나눠 줘요.가 연결을 기다리고 있다가 SYN-ACKSynchronize-Acknowledge"좋아요, 나도 준비됐어요"라고 서버가 돌려주는 TCP 신호예요.를 돌려줘요.

HTTP/3Hypertext Transfer Protocol version 3TCP 대신 QUIC 위에서 동작하는 최신 HTTP 버전이에요.는 TCPTransmission Control Protocol데이터가 빠짐없이, 보낸 순서대로 도착하도록 책임지는 전송 규칙이에요. 대신 QUICUDP 위에서 연결 수립과 암호화를 한 번에 처리하는 전송 규칙이에요. HTTP/3가 이걸 써요.을 써요. TCP 인사와 다음 단계의 TLSTransport Layer Security주고받는 내용을 암호화하고 상대 서버가 진짜인지 확인하는 보안 규칙이에요. https의 s가 이것이에요. 인사를 따로 하면 왕복이 두 번 필요한데, QUIC은 둘을 묶어 한 번에 끝내요.

신기한 점은 암호화에 쓸 키가 네트워크로 한 번도 오가지 않는다는 거예요. 양쪽이 각자 만든 값의 일부만 교환하고, 같은 계산을 해서 같은 비밀 키에 도착해요. 이 방식을 ECDHEElliptic Curve Diffie-Hellman Ephemeral양쪽이 일부 값만 교환하고도 같은 비밀 키를 계산해 내는 키 교환 방식이에요.라고 해요.

인증서는 "이 공개 키의 주인은 shop.example.com이 맞다"는 증명서예요. 폰은 인증서에 적힌 도메인이 접속한 주소와 같은지, 기간이 지나지 않았는지, 폰이 믿는 CACertificate Authority인증서에 서명해 주는 기관이에요. 기기와 브라우저는 믿을 수 있는 CA 목록을 미리 가지고 있어요.까지 서명이 이어지는지 확인해요.

이 시나리오에서는 ALBApplication Load BalancerAWS의 load balancer예요. 들어온 요청을 뒤에 있는 여러 서버에 나눠 줘요.가 인증서를 들고 있다가 암호화를 풀어요. ALB 뒤의 Node 서버는 같은 네트워크 안에서 평문 HTTP로 요청을 받아요.

ALB와 Node 서버 사이는 기본적으로 HTTP/1.1이에요. ALB는 서버와 맺은 연결을 열어 두고 여러 요청에 돌려 써요.

요청 패킷이 데이터센터 스위치를 거쳐 서버의 NICNetwork Interface Card서버를 네트워크에 연결하는 하드웨어예요. 들어온 신호를 데이터로 바꿔 메모리에 넣어요.에 도착하면, NIC는 데이터를 메모리에 직접 써 넣고 interrupt하드웨어가 "처리할 게 생겼어요"라고 CPU를 불러 세우는 신호예요.로 CPU를 불러요. CPU는 하던 일을 잠깐 멈추고 kernelOS의 핵심 부분이에요. 하드웨어를 직접 다루고 네트워크 데이터를 프로그램에 전해 줘요.의 네트워크 코드를 실행해서, 데이터를 해당 연결의 수신 버퍼에 쌓아 둬요.

여기까지 Node.js는 아무것도 하지 않았어요. 데이터는 kernel 안에서 누군가 가져가기를 기다리고 있어요.

리눅스 서버에서 libuv는 epoll리눅스에서 많은 연결 중 데이터가 도착한 것만 골라 알려 주는 OS 기능이에요.이라는 OS 기능으로 수많은 연결을 한꺼번에 지켜봐요. 연결마다 thread를 따로 두지 않아도 되는 이유예요.

핸들러 안에서 await로 DB를 기다리는 동안 main thread는 쉬지 않아요. 그 사이 다른 사용자의 요청을 처리하다가, DB 답이 오면 멈춰 두었던 핸들러를 이어서 실행해요.

물리적으로는 CPU core 하나가 이 main thread를 실행하고, 요청 데이터와 객체들은 메모리(RAM)를 오가요. JavaScript 코드가 아무리 많아도 한순간에 그 코드를 실행하는 core는 하나예요.

Postgres는 HTTP가 아니라 자기만의 wire protocol프로그램끼리 네트워크로 주고받는 메시지의 형식과 순서를 정한 규칙이에요.로 대화해요. 쿼리를 받으면 SQL을 해석하고, 실행 계획을 세우고, 실제로 실행하는 순서로 처리해요.

RDS의 디스크는 서버에 꽂힌 SSD가 아니라 네트워크로 연결된 EBSElastic Block StoreAWS가 네트워크로 연결해 주는 디스크예요. 서버에 직접 꽂힌 디스크처럼 쓸 수 있어요.예요. 그래서 "디스크에 썼다"는 확인에도 데이터센터 안의 네트워크 왕복이 들어가요. Multi-AZ DB 인스턴스로 구성했다면 다른 가용 영역의 대기 서버에도 기록된 뒤에 답이 와요.

서버가 요청을 처리하는 시간 중에서는 이 단계가 가장 긴 경우가 많아요. 쿼리 실행, 디스크 기록, 네트워크 왕복이 모두 겹치기 때문이에요.

화면을 다시 그리는 데도 순서가 있어요. 바뀐 DOMDocument Object Model브라우저가 페이지를 다루기 위해 만든 요소들의 트리 구조예요.에 스타일을 계산하고, 위치와 크기를 정하고(layout), 픽셀로 칠한 뒤(paint), 여러 층을 GPUGraphics Processing Unit화면에 그릴 픽셀 계산을 빠르게 처리하는 프로세서예요.에서 합쳐요(composite).

완성된 화면은 디스플레이가 다음에 새로 고쳐지는 순간에 보여요. 60Hz 화면이면 약 16.7ms마다, 120Hz 화면이면 약 8.3ms마다 기회가 와요. 그래서 계산이 끝나도 화면에 보이기까지 조금 기다릴 수 있어요.