[Network] 서버의 패킷 수신 동작 알아보기

🌱 들어가기 전

드디어 기나긴 패킷 여행의 마지막이다.

이번 포스팅에서는 웹 서버측에서 어떤 식으로 패킷을 받아오는지 알아볼 것이다!

클라이언트에서 패킷을 전송하는 단계를 반대로 뒤집은 것과 동일하기 때문에 크게 어렵지 않을 것이다.

 

---

 

🌱 클라이언트가 보낸 패킷이 서버로 도착한 직후

다시 돌아와서, 클라이언트에서 보낸 패킷이 서버로 도착한 직후 어떤 일이 발생하는지 간단하게만 알아보자.

(이 부분은 크게 중요한 건 아니라서 간단하게 짚고 넘어가고자 한다.)

 

우선, 서버 측으로 들어온 패킷의 경우 사실 '전기 신호'의 형태로 들어온다.

전기 신호는 LAN 어댑터에서 수신되며, 여기서 1과 0의 디지털 데이터로 바뀌게 된다.

위 그림은 전기 신호에서 디지털 데이터로 변환되었을 때 패킷의 형태이다.

변경된 디지털 데이터에서 패킷의 가장 마지막단에 있는 FCS (Frame Check Sequence, 오류 검사용 데이터)를 통해 오류의 유무를 검사하게 되고, 데이터가 무결하다면 맨 앞에 있는 MAC 헤더에 있는 수신처의 MAC 주소를 확인해서 본인에게 온 데이터인지 체크한다.

이는, 전기 신호가 LAN 전체로 흘러가고 해당하는 것만 신호를 수신하기 때문에 다른 기기로 가야 하는 패킷이 들어올 수도 있기 때문이다.

 

이후 LAN 어댑터 내부의 버퍼에 저장해두고, 인터럽트를 통해서 CPU에게 패킷이 도착했음을 알린다.

그럼 CPU는 하던 작업을 중단하고 LAN 드라이버를 통해 LAN 어댑터의 버퍼 메모리에서 수신한 패킷을 추출하고, MAC 헤더의 타입 필드를 통해 프로토콜을 판별하고, 해당 프로토콜을 처리할 수 있는 소프트웨어를 호출한다. 

보통 해당 타입 필드 값은 IP 프로토콜을 나타내는 값이기 때문에 TCP / IP의 프로토콜 스택을 호출 후 패킷을 건네준다.

 

---

 

🌱 프로토콜 스택과 IP 담당 부분

프로토콜 스택까지 패킷이 오게 되면 IP 담당 부분이 IP 헤더를 점검한다.

MAC 헤더와 마찬가지로 IP 헤더에서 수신처 IP 주소를 통해 본인에게 보내는 패킷인지 체크한다.

이는 OS 내부에서 패킷 중계 시 예상치 못하게 다른 패킷이 들어올 수도 있기 때문이다.

이후, 패킷이 잘 분할되었는지 체크하고 (IP 헤더의 플래그 값을 통해 확인) 분할된 패킷이 모두 도착할 때까지 메모리에 저장한다.

전부 도착하게 되면 재조립하여 원래의 패킷으로 복원을 하고, 프로토콜 번호 항목에 따라서 TCP or UDP or ICMP 담당 부분에게 패킷을 건네준다.

 

---

 

 

🌱 서버에서 소켓을 받는 과정 - 소켓 메서드로 분석하기

보통 서버와 클라이언트는 1:1로 접속하여 대화하는 것이 일반적이다. 보통 멀티스레드를 통해서 작동하게 되기 때문에, 클라이언트의 접속을 대기할 때 새로운 스레드를 생성하고 접속 시 새로 생성한 소켓을 건네주게 된다. 보통 운영체제의 커널 내부에 소켓을 관리하는 정보가 담겨있기 때문에, 해당 정보를 바탕으로 클라이언트에게 소켓 정보가 분배된다.

 

이전에 프로토콜 스택과 메시지 송신 과정에 관한 포스팅에서 클라이언트의 데이터 송-수신 과정을 다음과 같이 정의하였다.

1. 소켓 작성
2. 서버의 소켓과 파이프로 연결 (접속)
3. 데이터 송-수신
4. 파이프 분리 후 소켓 말소 (연결 끊기)

 

하지만, 서버의 입장에서는 조금 다르다.

1. 소켓 작성
2-1. 소켓을 접속 대기 상태로 만들기
2-2. 소켓 접속에 대해 접수 
3. 데이터 송-수신
4. 파이프 분리 후 소켓 말소

 

구체적인 코드상으로 어떻게 동작하는지 살펴보자.

클라이언트의 소켓 연결 프로세스와 비슷하지만, 추가적으로 bind, listen, accept 같은 코드가 생긴 것을 볼 수 있다.

 

 

 

1. bind : 소켓에 주소를 할당하기

int bind(int sockfd, struct sockaddr *addr, socklen_t addrlen);

bind 메서드의 경우 총 3개의 인자를 받는다.

첫 번째 인자의 경우 socket()을 통해 받아오는 디스크립터이며, 두 번째 인자의 경우 IP 주소와 포트 번호를 담고 있는 구조체이다.

세 번째 인자의 경우 주소 정보를 담은 변수의 길이이며, 바인딩이 성공하면 0을, 실패하면 -1을 반환한다.

 

 

2. listen: 연결 요청을 대기하기

int listen(int sock, int backlog);

bind 메서드를 통해서 하나의 소켓에 ip 주소와 포트 번호를 할당했다.

이제, 클라이언트가 해당 소켓에 연결할 수 있도록 해당 요청을 대기하는 상태로 만들어줘야 한다.

listen이 호출된 이후부터 클라이언트는 connect를 통해서 서버로 연결을 요청할 수 있게 된다.

 

첫 번째 인자는 소켓 디스크립터의 번호를, 두 번째 인자는 연결 요청을 대기하고 있는 큐의 크기이다.

여기서 말하는 큐는, 클라이언트가 연결을 요청했을 때 요청이 온 순서대로 처리할 수 있도록 클라이언트를 큐에 담아두고 모아둔 곳이다.

 

 

3. accept: 연결 요청 수락하기

int accept(int sock, struct sockaddr*addr, socklen_t *addrlen);

대기 중인 클라이언트의 요청을 차례대로 수락할 수 있다.

첫 번째 인자는 기존의 디스크립터 번호, 두 번째 인자는 대기 큐에서 얻어온 클라이언트의 주소 정보, 세 번째 인자는 addr 변수의 크기를 의미한다. 만약, 대기 큐가 비어있다면 accept은 반환되지 않고 새로운 요청이 올 때까지 blocking 상태가 된다.

 

여기서 accept은 기존의 디스크립터가 아닌, 새로운 디스크립터를 (디스크립터 2) 반환한다.

앞에서 사용했던 디스크립터는 연결 요청에 대한 대기까지만 진행하고, accept을 통해 새롭게 할당받은 디스크립터를 통해 실제 클라이언트와 데이터 송-수신 과정을 진행할 수 있음을 의미한다.

 

기존에 사용했던 디스크립터의 경우 계속 접속 대기인 상태로 존재하게 된다. 만약, 새롭게 할당받은 디스크립터 대신 기존의 디스크립터를 사용하게 된다면 접속 대기 소켓이 사라지게 되어서 다음에 다른 클라이언트가 접속하게 된다면 이미 소켓이 연결된 상태니까 해당 요청을 처리할 수 없게 되어 곤란해진다. 그래서, 클라이언트의 요청이 올 때마다 새로운 소켓을 생성하여 해당 클라이언트의 통신과를 담당하도록 만든다고 이해하면 된다.

 

하지만, 새로운 소켓을 만들 때 포트 번호는 그대로 유지한다. 이는 접속 패킷을 보냈을 때 다른 포트 번호에서 답변이 돌아오는 일을 막기 위해서이다. 만약 다른 포트 번호로부터 답이 온다면, 접속 패킷을 보낸 상대로부터 온 것인지, 아니면 다른 상대로부터 온 것인지 알 수가 없기 때문이다.

 

근데 포트 번호를 그대로 유지하게 된다면 하나의 포트 번호에 여러 개의 소켓이 존재할 수도 있는 것이다. (접속 대기 용도 / 데이터 송-수신 용도) 클라이언트에서 패킷이 도착했을 때 단순히 포트 번호로 어떤 소켓이랑 대화하고 있는지 알 수 없기 때문에, 추가적으로 아래와 같은 정보들을 통해 소켓을 식별한다.

- 클라이언트의 IP 주소
- 클라이언트의 포트 번호
- 서버측의 IP 주소
- 서버측의 포트 번호

 

이 덕분에 서버측에 같은 포트 번호를 가진 소켓이 여러 개이더라도, 클라이언트 측은 모두 다른 포트 번호를 할당하기 때문에 각 소켓들이 충분히 식별된다. 하지만, 클라이언트와 서버의 포트 번호만 가지고 식별은 불가능하다. 왜냐하면, 여러 클라이언트가 접속하게 된다면 클라이언트의 포트 번호 역시 중복될 수 있기 때문이다. 그래서 추가적으로 클라이언트의 IP 주소까지 합하여 완전하게 소켓을 식별하게 된다!

 

그렇다면, 굳이 소켓 디스크립터라는 것을 사용할 필요가 있을까?

이는, 소켓을 만든 직후 접속 동작을 하기 전에는 클라이언트의 IP, 포트 번호를 알 수 없기 때문이다.

또한 4가지 정보보다는 디스크립터 하나로 식별하는 게 더 간단하고 (메모리 공간도 적게 차지하니까 성능 개선 가능), 표준 인터페이스인 만큼 프로그램과 OS 사이의 원활한 통신을 지원하게 된다.

 

---

 

🌱 서버에서 소켓을 받는 과정 - TCP 헤더의 관점에서 분석하기

 

바로 앞서 말한 내용과 비슷하지만, TCP 헤더가 하는 일을 위주로 되새겨보자.

 

 

💬 소켓 접속 동작

기본적으로 TCP 헤더의 SYN 컨트롤 비트가 1로 패킷이 들어왔다면, 해당 패킷은 접속 동작의 패킷이 된다.

해당 패킷이 들어오면 패킷의 수신처 포트 번호를 조사하여 해당 번호와 같은 포트 번호를 할당한 접속 대기 상태의 소켓이 있는지 확인한다. 이 과정에서 존재하는 패킷이 없다면, 오류 통지 패킷을 반송한다. 

 

해당하는 접속 대기 패킷이 있다면 복사하여 새로운 소켓을 만들고 (위에서 봤던 디스크립터2에 대한 부분) 송신처의 IP 주소, 포트 번호, 시퀀스 번호의 초기값, 윈도우 값 등의 정보를 기록한다. 또한, 송-수신 버퍼로 사용하는 메모리 영역을 확보한 다음, ACK 번호, 서버에서 클라이언트에 보내는 데이터에 대한 시퀀스 번호의 초기값, 클라이언트에서 서버로 보낸 데이터를 받기 위해 수신 버퍼의 빈 용량을 나타내는 윈도우 값 등을 기록한 TCP 헤더를 만들어서 IP 담당 부분에게 의뢰하여 클라이언트에게 반송한다.

 

결과적으로 해당 패킷이 클라이언트에게 도착하면, 클라이언트는 패킷을 받았다는 ACK를 보낼 것이구, 해당 패킷을 받게 되면 소켓의 접속 동작이 완료된다. accept을 통해 쉬고 있던 서버는 새로 만든 소켓의 디스크립터를 전달하여 다시 동작을 재개하게 된다.

1. TCP 헤더의 SYN 컨트롤 비트 확인
2. 수신처 포트 번호 조사
3. 해당 포트 번호와 동일한 번호를 가진 접속 대기 소켓 복사 후 새 소켓 생성
4. 송신처의 IP / 포트 번호 등 기록

 

 

💬 데이터 송-수신 동작

접속이 완료되면 데이터 송-수신 단계를 들어갈 텐데, 먼저 도착한 패킷이 어느 소켓에 해당하는지 조사한다.

새로운 소켓이 복사되면서 동일한 포트 번호를 가진 소켓이 여러 개가 될 수 있기 때문에 송-수신처의 IP, 포트 번호 모두를 조합하여 소켓을 찾는다. 이후, 소켓에 기록된 시퀀스 번호나 이전에 온 데이터 조각의 길이로부터 다음 시퀀스 번호 값을 계산하여, TCP 헤더에 기록된 시퀀스 번호와 일치하는지 확인하여 도중에 유실된 패킷이 없는지 확인한다.

 

💡 이때, 분할된 패킷을 원래로 복원하기 위해서 새로운 패킷이 도착할 때마다 데이터 조각들을 연결한다.

 

수신한 데이터를 수신 버퍼에 저장하면 응답용 TCP 헤더에 수신 패킷의 시퀀스 번호와 데이터 조각으로부터 계산한 ACK 번호를 기록한 뒤, IP 담당 부분에게 의뢰하여 클라이언트에게 다시 반송한다. 이후 애플리케이션의 필요에 따라서 버퍼에 저장된 데이터를 건네주게 된다.

1. 도착한 패킷의 송-수신처 IP / 포트 번호를 통해 소켓 식별
2. 데이터 조각들을 연결하여 수신 버퍼에 보관
3. 클라이언트에게 ACK 되돌려줌

 

 

💬 접속 끊기 동작

클라이언트든 서버든 close 호출하고, FIN=1을 IP 담당 부분에게 의뢰한다.

이를 받은 수신측은 ACK 번호를 반송하고, 또 다시 FIN=1을 보내고, 다시 ACK를 보내고 연결이 끊긴다.

이후 연결이 끊기면 잠시 후 소켓이 말소하게 된다!

 

흔히 생각하는 4-way handshake 과정이기 때문에 자세한 내용은 생략하겠다.

이 포스팅에서 연결 끊기 동작에 대한 그림을 그려두었다 😶

 

---

 

이렇게 대략적인 클라이언트 <-> 서버 간의 통신 과정을 알아보았다.

사실 중간중간 생략한 내용도 있고, 특히 리퀘스트 메시지 해석하는 부분은 책 한 권으로 쓰일 수 있을 만큼 내용이 많아서 따로 정리하지는 않았다. 정말 간단하게 줄인다면, 다음과 같다.

1. 리퀘스트 메시지를 파싱하여 액세스 제어에 따른 검증 절차 진행
2. 리퀘스트 메시지 처리
3. 응답 메시지 생성 후 클라이언트로 반송 (클라이언트가 받을 때는 다수의 패킷으로 받음)
4. 클라이언트를 이를 받아 전기 신호 -> 디지털 데이터 -> 분할된 패킷 모으기 -> 메시지로 변환 -> 브라우저에게 전송
5. 브라우저는 Content-Type 같은 헤더 값에 따라서 어떤 식으로 렌더링할지 정함

 

아무튼 끝!

나중에 한 번 더 공부해봐야겠다... 지금은 머리에 남은 게 없다 🥹