Study · 운영체제 · 연결 받기 · 네트워크

연결은 프로그램이 받기 전에 커널이 이미 다 만들어 둔다

장면

accept() 가 돌려주는 연결은 그 순간 만들어진 것일까, 아니면 이미 만들어져 기다리고 있던 것일까?

$ ss -lnt
State   Recv-Q  Send-Q  Local Address:Port
LISTEN  0       128           0.0.0.0:22
# ss 는 지금 열려 있는 연결을 보여 주는 명령이다
# -lnt 는 「듣고 있는 것만(l) · 이름으로 바꾸지 말고 번호 그대로(n) · TCP 만(t)」이라는 뜻이다
# 0.0.0.0 은 이 기계의 어느 주소로 와도 받는다는 뜻이고, 22 는 ssh 가 쓰는 포트 번호다
# Recv-Q 와 Send-Q 는 LISTEN 줄에서 뜻이 뒤집힌다 — 이름만 보고 읽으면 틀린다. 장면 마지막 스텝에서 푼다

먼저 알아야 할 말

커널: 컴퓨터가 켜져 있는 동안 늘 돌고 있는 프로그램 하나다. 파일을 만들고 지우는 일, 프로그램을 띄우는 일은 내 프로그램이 직접 못 하고 전부 커널에 부탁한다. 터미널에 친 명령이 실제로 무언가를 하는 순간은 늘 커널 안이다.
accept 큐: 악수가 끝난 연결들이 accept() 로 꺼내지기를 기다리는 줄이다. 서버 프로그램이 바빠서 늦게 꺼내 가면 여기에 쌓인다.
큐: 먼저 넣은 것이 먼저 나오는 자료구조다(FIFO, First In First Out). 줄을 서는 것과 같다 — 먼저 줄을 선 사람이 먼저 나간다. 나중에 넣은 것을 먼저 꺼내는 스택과 반대 순서다.
구조체: 값 여러 개를 한 덩어리로 묶어 둔 것이다. C 에는 클래스가 없어서 이렇게 쓴다 — 메서드 없이 필드만 있는 자바 클래스라고 보면 된다. C 에서 a->b 는 자바의 a.b 와 같다(안에 든 것을 꺼낸다).
필드: 객체나 구조체 안에 든 변수 하나다. 자바에서는 객체의 필드, C(리눅스 커널)에서는 구조체의 필드라고 부른다.
3-way handshake: TCP 연결을 열 때 주고받는 세 번의 인사다(SYN → SYN+ACK → ACK). 이 셋이 끝나야 연결이 선다.
해시: 비밀번호를 그대로 적지 않고 되돌릴 수 없게 뭉개 놓은 글자 덩어리다. 맞는지 보려면 들어온 비밀번호를 같은 방법으로 뭉개서 견준다 — 그래서 파일을 훔쳐도 원래 비밀번호는 안 나온다.
백로그: accept 큐에 쌓일 수 있는 연결 수의 상한이다. 넘치면 새 연결이 거절되거나 버려진다. 주의 — 연결 하나하나에도 「백로그」라는 이름의 임시 대기 줄이 따로 있는데, 이름만 같고 다른 것이다.
파일 디스크립터: 프로세스가 무언가를 열고 받는 번호표다. 프로세스마다 따로 있는 표의 몇 번째 칸인지를 뜻한다 — ls -l /proc/self/fd 로 그 표가 보인다. 파일만의 것이 아니다. 소켓도 파이프도 같은 표에 걸리고, 그래서 read · write 가 셋 모두에 똑같이 통한다.
소켓: 두 프로그램이 네트워크로 연결됐을 때 그 연결의 양쪽 끝이다. 프로그램은 이 손잡이를 붙잡고 바이트를 주고받는다. 자바의 Socket 객체 뒤에 커널의 소켓이 있다.
포트: 한 컴퓨터 안에서 어느 프로그램에게 줄지 가르는 번호다. 주소가 건물이라면 포트는 호수다. ssh 는 22번, 웹은 보통 80·443번을 쓴다. Spring Boot 실측에서는 8080을 다른 프로그램이 이미 쓰고 있어서 --server.port=18080 으로 18080을 썼다.
클라이언트: 연결을 거는 쪽이다. 받는 쪽은 서버라고 부른다.
신호: 커널이 프로세스에게 보내는 짧은 알림이다. SIGKILL 은 「지금 죽어라」이고 프로세스가 거절할 수 없다. SIGSEGV 는 「잘못된 주소를 건드렸다」다. 터미널에서 Ctrl+C 를 누르는 것도 신호 하나를 보내는 일이다.
서버: 요청을 받아서 처리해 주는 쪽이다. 클라이언트가 「이거 해줘」라고 요청을 보내면, 서버는 그 일을 처리하고 결과를 응답으로 돌려준다. 식당으로 치면 손님이 클라이언트, 주방이 서버다.
TCP: 끊기지 않고 순서가 지켜지는 연결을 만들어 주는 규약이다. HTTP 가 그 위에서 돈다.
계층: 받은 바이트를 순서대로 처리하는 단계들이다. 아래층이 자기 머리말을 떼고 나서야 위층이 본다 — 랜 카드 → IP → TCP → 소켓 차례로 넷이다.
디스크: 전원을 꺼도 내용이 남는 저장 장치다. 대신 메모리보다 훨씬 느리다.
바이트: 컴퓨터가 다루는 가장 작은 덩어리 단위로, 0부터 255 사이의 숫자 하나다. 파일도, 네트워크로 오가는 글자도 결국 바이트의 나열이다. B는 바이트, KB는 약 1,000바이트, MB는 약 100만 바이트다. 「바이트가 도착했다」는 아직 글자로 읽기 전, 숫자 덩어리 상태로 도착했다는 뜻이다.

아래 재생기의 ▶를 누르면 한 스텝씩 진행된다. 금색 테두리가 지금 이야기하는 곳이고, 캡션이 무슨 일이 일어났는지 말해 준다. 굵게 밑줄 친 말은 누르면 뜻이 나온다. 빨간 딱지는 그때 벌어지는 일의 이름이고, 캡션 바로 위 회색 글자는 지금 스텝이 속한 묶음의 이름이다.

카드 아래 회색 줄은 그 일이 실제로 적혀 있는 소스의 파일 이름 : 줄 번호와 함수 이름이다. 글 안에 (:669)처럼 줄 번호만 적힌 것은 바로 앞에 적은 파일의 그 줄이라는 뜻이다. 캡션 한가운데 박힌 긴 영어 이름과 괄호 속 파일 · 줄 번호도 같다 — 건너뛰고 한글만 읽어도 뜻이 통하게 써 두었다.

장면 · 연결은 프로그램이 받기 전에 커널이 이미 다 만들어 둔다 0 / 11

▶ 를 누르면 바깥에서 온 첫 인사가 서버 프로그램의 accept() 에 닿기까지를 따라간다. accept() 가 연결을 만드는 함수처럼 보이지만, 그 순간 커널이 하는 일은 이미 다 만들어 둔 것을 줄에서 꺼내 주는 것뿐이라는 게 이 장면의 요지다.

키보드 · ← → 한 스텝 · Space 재생/멈춤 · Home 처음

연결은 프로그램이 받기 전에 커널이 이미 다 만들어 둔다. accept 는 연결을 만드는 일이 아니라 쌓여 있는 줄에서 하나를 꺼내 가는 일이다.

어떻게 확인했나

소스 어디를 보고 적었는지와 무엇을 돌려서 쟀는지를 남긴 자리다. 처음 읽을 때는 건너뛰어도 된다.

accept 큐는 struct inet_connection_sock의 icsk_accept_queue 필드다(include/net/inet_connection_sock.h:84). 타입은 struct request_sock_queue(include/net/request_sock.h:177)이고, 그 안의 rskq_accept_head·rskq_accept_tail(185–186)이 외줄을 이룬다. listen이 reqsk_queue_alloc으로 비운다(net/ipv4/inet_connection_sock.c:1343).
SYN 큐는 그와 다른 줄이다 — tcp_conn_request가 inet_csk_reqsk_queue_hash_add(net/ipv4/tcp_input.c:7782)로 request_sock을 해시 표에 걸어 둔다(net/ipv4/inet_connection_sock.c:1176 → inet_ehash_insert 1154). accept 큐에 들어가는 것은 악수가 끝난 뒤다.
악수는 accept() 전에 커널이 끝낸다 — 마지막 ACK을 tcp_check_req(net/ipv4/tcp_minisocks.c:687)가 확인해 syn_recv_sock(934)으로 새 struct sock을 만들고, inet_csk_reqsk_queue_add(net/ipv4/inet_connection_sock.c:1393)가 큐 꼬리에 붙인다. inet_csk_accept(649)는 reqsk_queue_remove로 꺼내기만 한다.
ss -lnt의 두 칸은 이 줄의 값이다 — tcp_diag_get_info(net/ipv4/tcp_diag.c:26)가 LISTEN일 때 Recv-Q에 sk_ack_backlog(지금 쌓인 개수), Send-Q에 sk_max_ack_backlog(상한)를 넣는다. 상한은 __inet_listen_sk(net/ipv4/af_inet.c:206)가 적고, __sys_listen_socket(net/socket.c:1993)이 그 전에 somaxconn으로 깎는다.
넘치면 SYN을 대답 없이 버린다 — sk_acceptq_is_full(include/net/sock.h:1102)이 참이면 tcp_conn_request가 LISTENOVERFLOWS를 세고 goto drop한다(net/ipv4/tcp_input.c:7657).
백로그 3 으로 듣고 다섯 개를 붙였다. ss -lnt 의 Send-Q 는 줄곧 3(상한)이고 Recv-Q 가 0 에서 4 로 늘었으며, 다섯 번째 연결은 Connection timed out 으로 실패했다. 상한이 3 인데 4 까지 쌓이는 것은 sk_acceptq_is_full 의 비교가 「크거나 같다」가 아니라 「크다」라서다 — 상한과 같은 수까지는 받는다. accept 를 한 번 하니 Recv-Q 가 3 으로 줄었다 — 큐에서 하나를 꺼내 간 것이다.

‹ 이전 다음 항목 ›