네트워크 프로그램을 개발할 일은 아주 가끔 있지만, 대부분 원격의 서버와 통신하는 경우가 대부분이라서 

테스트하기도 힘들고, 운영 중이라면 언제 어떤 문제가 발생할지 예측할 수가 없다.

그래서, 각 오류별로 발생하는 문제와 이 문제의 원인을 미리 파악하고 있으면 신속한 대응이 가능하다.

네트워크 프로그램

간단하게 구성하자면 원격에서 클라이언트와 서버가 통신하는 것이라고 할 수 있다.

서버는 데몬 형태로 항상 떠 있으면서 클라이언트의 요청이나 데이터를 받고, 그에 대한 응답을 주는 역할이고,

클라이언트는 서버와 통신할 필요가 있을 경우에 객체, 프로세스, 스레드 등을 생성해서 서버에 요청을 보내고 응답을 받거나, 데이터를 보내고 ACK를 받은 후에 종료되는 형태이다.

웹을 예로 들면, 웹브라우저가 클라이언트가 되고 웹서버나 WAS는 서버의 역할을 한다.

네트워크 통신 과정

1. 연결

   클라이언트와 서버간에 커넥션을 생성하는 과정이다.

   클라이언트가 서버에 연결을 요청하고, 서버가 연결을 수락한다는 답을 보내면 커넥션 생성이 완료된다.

2. 데이터 송수신

   커넥션이 생성된 후에는 클라이언트가 서버에 요청이나 데이터를 전송한다.

   서버는 수신한 요청에 대한 응답을 생성해서 클라이언트로 전송하거나, 단순히 ACK를 전송한다.

   클라이언트가 정상적으로 응답이나 ACK를 정상적으로 수신했다고 판단되면 커넥션을 종료하거나, 다음 요청을 보내는 식의 작업이 이어진다.

동기/비동기 방식

(이 포스트와의 큰 관련이 없어 보이지만, 헷갈려 하는 분들이 많아 간단하게 언급하려고 한다)

- 동기

클라이언트가 서버에 요청을 보내고 연결이 유지된 상태에서 응답을 기다리다가, 서버에서 응답을 받은 후에 커넥션을 종료하는 형태이다.

한 개의 연결로 요청 및 응답이 모두 처리되는 형태로, 가장 일반적인 형태이다.

- 비동기

A시스템의 클라이언트가 B시스템의 서버에 요청을 보내면 그 내용을 저장한 후에 잘 받았다는 의미의 ACK만을 클라이언트에 전송하고 커넥션이 종료된다.

그 이후에, B시스템에 저장된 요청에 대한 처리가 끝나면 클라이언트를 생성하여 A시스템의 서버에 접속해 응답을 보내고, A시스템의 서버는 잘 받았다는 ACK를 전송하고 커넥션이 종료된다.

결과적으로 A와 B 시스템에 각각 클라이언트/서버가 모두 존재해야 하고, A시스템이 받은 응답이 어떤 요청에 대한 것인지를 판단하기 위해 추가로 ID값을 요청, 응답, ACK에 달고 다녀야 한다.

비동기는 구현이나 관리가 복잡해지는 단점이 있어, 동기식으로 처리할 경우 응답을 기다리다가 타임아웃이 발생할 정도로 오래 걸리는 경우에 주로 사용한다.

네트워크 프로그램 오류의 종류

- 커넥션 타임아웃

클라이언트에서 서버로 커넥션 요청을 보냈는데 지정된 시간동안 그에 대한 응답이 없을 경우에 발생한다.

(참고로, 보통 API에서 커넥션 타임아웃에 대한 값을 지정할 수 있으니, 프로그램이나 서버 환경에 맞게 적절히 세팅해 사용한다.)

거의 방화벽이 막혀 있어서 발생한다.

-> 보통 2개의 방화벽이 있을 수 있는데, 클라이언트단에 있는 방화벽에 클라이언트에서 서버가 가는 방화벽이 열려 있는지 확인하고, 서버단에 있는 방화벽에 클라이언트로부터 서버로 들어오는 방화벽이 열려 있는지 확인해야 한다.

네트워크 전문가가 아니라서 잘은 모르지만, 대부분 방화벽은 금지된 통로로 오가는 패킷들은 그냥 받아서 없애 버리는 것 같다. 그래서, 커넥션 요청을 보내 놓고 마냥 기다리다가 커넥션 타임아웃이 발생하는 것으로 보인다.

- Read Timeout

이 오류가 발생하는 것은 이미 커넥션은 생성되어 있다는 의미이다.

커넥션이 생성된 후에 클라이언트가 서버로 요청을 보내고 응답을 기다리다가 타임아웃이 발생한 것이다. 즉, 서버가 지정된 시간 안에 응답을 주지 않았다는 것이다.

클라이언트의 문제일 가능성은 적고, 서버에 문제가 생겨 응답을 주지 못 하는 경우가 많으므로, 서버단 담당자에게 확인을 요청해야 한다.

- Too Many Open Files

파일을 열 때 뿐만 아니라, 소켓을 열 때도 서버의 File Descriptor를 사용한다. 

즉, 소켓도 사용 후에 잘 닫아 줘야 이런 오류가 발생하지 않는다.

일단, 현재 열려 있는 파일과 소켓을 보고 싶으면 lsof나 pfiles 명령을 이용해서 확인한다.

가끔씩 잘 닫아 줘도 이런 문제가 발생하는 경우가 있다.

서버는 WAS의 서블릿을 만들어 두고, HttpClient를 사용해 클라이언트를 만들어 통신한 후에 클라이언트를 종료하도록 구성했다.

그런데, HTTP의 특성상 API로 커넥션을 종료시켜도 한동안 TIME_WAIT 상태로 커넥션이 머물러 있다가 잠시 후에 진짜 커넥션이 종료되는 것이었다. 단시간에 많은 통신을 수행한 경우 이런 TIME_WAIT이 미처 풀리지 않고 많이 쌓여 있다가 더 이상 커넥션을 생성하지 못 해 Too Many Open Files가 발생한다.

이런 경우는 Connection Pool을 사용해 일정한 수의 커넥션들을 생성해 놓고 재사용하도록 하면, 커넥션이 늘어나지 않아 Too Many Open Files를 막을 수 있고, 매번 커넥션을 생성하는 데 소요되는 시간을 절약하여 성능을 향상시킬 수 있다.

Apache HttpClient의 Connection Pool 사용법은 여기를 클릭하면 확인할 수 있다.