Contents

  1. SOAP
  2. WSDL
  3. 네트워크 장비
  4. TCP Keepalive
  5. Nagel 알고리즘
  6. SSL / TLS

SOAP [Bottom] [Top]

SOAP(Simple Object Access Protocol) 은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 사용하여 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜이다. SOAP 은 웹 서비스(Web Service) 에서 기본적인 메시지를 전달하는 기반이 된다. SOAP 에는 몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 원격 프로시져 호출(Remote Procedure Call:RPC) 패턴으로, 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)쪽으로 메시지를 요청 하고, 서버는 메시지를 즉시 응답하게 된다. SOAP 는 XML-RPC 와 WDDX 에서 envelope/header/body 로 이루어진 구조와 전송(transport) 와 상호 중립성(interaction neutrality) 의 개념을 가져왔다.

SOAP 은 XML 을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계되어 있다. 「헤더」는 선택사항으로 반복이나 보안 및 트랜젝션을 정보로 하는 메타 정보를 가지고 있다. 「바디」부분은 주요한 정보인 정보를 가지고 있다.

WSDL [Bottom] [Top]

WSDL(Web Services Description Language의 약자) 은 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로 XML 로 기술된다. 웹 서비스의 구체적 내용이 기술되어 있어 서비스 제공 장소, 서비스 메시지 포맷, 프로토콜 등이 기술된다.

네트워크 장비 [Bottom] [Top]

TCP Keepalive [Bottom] [Top]

Sun Microsystems 는 TCP keepalive 매개 변수 (tcp_keepalive_interval) 를 15분 미만으로 설정하는 것은 바람직하지 않다고 봅니다. 이제 TCP keepalive 를 설명한 후에, 왜 그것이 바람직하지 않은지 몇 가지 이유를 설명할 것입니다.

우선, keepalive 가 TCP 의 필수 요소가 아니라는 점을 말하고 싶습니다. keepalive 는 TCP 규격에 나오는 옵션 기능의 하나이며, 제조업체의 재량에 따라 포함시킬 수 있습니다. Sun은 TCP에 이 기능을 포함시키기로 결정했습니다. 하지만 TCP 규격에서는 keepalive 기능을 포함시키는 경우 간격을 최소한 2시간 이상으로 기본 설정해야 한다고 규정합니다. 뿐만 아니라 이 기능을 옵션 기능으로 만들어야 합니다. 바로 그 점 때문에 TCP keepalive 를 설정할 것인지 여부를 각 프로그램에게 맡기게 되는 것입니다. 프로그램이 TCP keepalive 를 명시적으로 실행하지 않으면, 탐색 패킷 (Probe) 을 보내지 않을 것입니다. TCP keepalive 는 setsockopt() 을 사용하여 소켓 옵션 (SO_KEEPALIVE) 을 설정하면 사용할 수 있게 됩니다.

소켓 옵션이 설정되면 tcp_keepalive_interval 로 지정된 시간 동안 연결이 유휴 상태가 되었을 때 keepalive 탐색 패킷을 보냅니다. 응답 메시지가 수신될 때까지 또는 tcp_ip_abort_interval 로 지정된 시간이 다 경과할 때까지 탐색 패킷을 보냅니다. 응답은 연결 상대측을 지연시키는 요소의 영향을 받습니다. 연결 상대측이 연결을 닫거나 다시 부팅을 하면 응답 메시지는 RST (reset packet) 가 됩니다. 수신 주소에 도달할 수 없다는 ICMP 메시지를 수신하게 될 가능성도 있습니다. 라우터가 고장나거나 케이블 연결이 끊긴 경우에 그런 상황이 발생합니다. 그 외에도 많은 가능한 상황이 있습니다. 탐색 패킷 자체는 tcp_rexmit_interval 로 지정된 간격으로 보내집니다.

keepalive 를 15분 미만으로 설정해서는 안된다고 제안하는 이유 중의 하나는 바로 이것입니다. 그렇게 설정하면 TCP 가 장애를 일으킬 가능성이 다분히 있습니다. tcp_rexmit_interval 의 값은 3초로 기본 설정됩니다. 20초 정도로 높게 설정할 수도 있습니다. 그런데, tcp_keepalive_interval 을 tcp_rexmit_interval 보다 작은 값으로 줄이면, 재전송하기 전에 keepalive 탐색 패킷을 보낼 것입니다. 하지만, 네트워크가 느리거나 팻 상태가 되면 재전송이 매우 중요합니다. 어쩌면 통신 상대측 시스템이 느려서 아직 응답하지 않은 것일 수도 있습니다. 재전송을 보내는 이유가 바로 이것입니다. 이것은 누군가에게 조금 전에 내가 한 말을 들었느냐고 묻는 것과 같습니다. 상대방이 없다고 판단되면 대화를 미리 중단하거나 상대방이 있는지 알아 보려고 시간을 낭비하게 될 것입니다. 상대측이 여전히 대화에 참여하고 있다면 그에게 직접 조금 전에 내가 한 말을 들었느냐고 다시 묻게 될 것입니다. 이렇게 되면 네트워크가 팻 상태가 됩니다. 네트워크가 팻 상태가 되면 될수록 제대로 작동이 되려면 재전송을 더 많이 해야 합니다. 그렇게 하여 TCP가 장애를 일으키게 됩니다. (이제 tcp_rexmit_interval 가 3개의 매개 변수, 즉 tcp_rexmit_interval_initial, tcp_rexmit_interval_max, 그리고 tcp_rexmit_interval_min 로 나누어져 있다는 점을 지적해야겠습니다. 이 점에 대한 해설은 keepalive 해설에서 벗어난 것입니다. 여기서 사용하는 예에서는 주로 tcp_rexmit_interval_initial 을 다룰 것입니다.)

텔넷의 경우에는 더 인상적입니다. 시스템에 텔넷 방식으로 연결되면 로그인을 하여 필요한 모든 작업을 할 수 있습니다. 하지만, 종종 작업을 멈추고 생각하는 시간도 있습니다. 그렇게 생각하는 동안 원격 호스트는 대기합니다. 그렇게 기다리는 동안에는 keepalive 탐색 패킷이 도착할 때까지 로컬 시스템과 원격 시스템 사이에 전송되는 패킷이 전혀 없습니다. 원격 호스트로 로그인한 다음에 10분 이상 생각에 잠기는 경우도 종종 있습니다. 그 10분 간격 동안 라우터가 다운이 되어 다시 부팅하게 되는 일도 쉽게 일어납니다. keepalive 를 높은 값으로 설정하면 라우터 충돌을 느끼지 못하고 작업을 계속하게 될 것입니다. 하지만 1분 후에 keepalive 탐색 패킷를 보내면, 라우터는 다시 부팅할 시간이 없기 때문에 연결된 측이 준비가 되기 전에 연결이 닫히게 됩니다. 그러면 다시 로그인해야 합니다. 뿐만 아니라, 일단 연결이 닫히면 TIME_WAIT 상태로 유지된다는 점을 생각해야 합니다. TIME_WAIT 상태는 한쪽 호스트가 연결을 닫았는데, 늦게 도착한 패킷 때문에 다른 한 호스트에서는 연결을 계속 열어 두게 되는 상황을 방지하기 위해 사용합니다. 하지만, 이처럼 너무 일찍 연결을 종료시키면, 시스템에서 이용할 수 있는 모든 소켓이 닫히게 될 가능성이 있습니다. 그렇게 되면 전혀 연결이 되지 않을 것입니다. 이와 같은 시나리오에서는 15분이 훨씬 더 타당한 값입니다.

keepalive 를 사용하는 주된 이유는 종단 시스템 중의 하나가 다운될 때 발생할 수 있는 한쪽만 열린 연결 상태를 정리하는 것입니다. 로컬 시스템이 대화를 하고 있는 원격 시스템이 다운이 되면, 로컬 시스템은 여전히 연결을 열어두고 있을 것입니다. 하지만, 다운된 그 시스템은 그렇지 않습니다. 이것을 한쪽만 열린 연결 상태라고 합니다. 네트워크 응용 프로그램이 시간 종료값이나 TCP keepalive 소켓 옵션을 설정하지 않는 한, 그 한쪽만 열린 연결 상태는 시스템이 다시 부팅할 때까지 그대로 유지됩니다. keepalive 탐색 패킷은 한쪽만 열린 연결 상태인지 확인하는데 사용되며, 한쪽만 열린 연결 상태이면 그 연결을 닫습니다.

이상의 내용은 몇 가지 상황에 대한 해설에 불과합니다. 분명히 사용자의 현재 상황에 훨씬 더 어울리는 시나리오가 더 많이 있을 것입니다. 기본적으로 여기서 말한 내용은 TCP 규격 자체가 keepalive 의 기본 설정값이 최소한 두 시간이어야 한다고 규정한다는 점입니다. 더 나아가 Sun 이 제안하는 요점은 TCP 가 장애를 일으켜 네트워크를 팻 상태로 만드는 것을 방지하는 데 있습니다. 이것은 사용자가 수정하는 시스템과 네트워크의 다른 호스트에 그대로 적용됩니다. 문제의 네트워크에 전세계적인 인터넷이 포함되면 좀더 극적이 되는 것일 뿐입니다. 마지막 예에서는 keepalive 를 다소 낮게 설정했을 때 발생하는 문제의 유형을 사용자 수준에서 설명합니다.

참고> TCP keepalive 에 대한 자세한 사항은 RFC 1122 와 RFC 1123 를 참고 하거나 도서 "TCP/IP Illustrated, Volume 1" (0201633469) 를 참고 한다.

Nagel 알고리즘 [Bottom] [Top]

연결지향 (Connection-Oriented) 또는 스트림 중심 (Stream-Oriented) 의 프로토콜, 즉 TCP 프로토콜에 대하여 적용되는 알고리즘으로 1984 년에 제안되었다. 작은 크기의 데이타를 하나의 큰 패킷으로 병합하여 전송하며 이미 전송된 패킷에 대하여 ACK 를 받아야만 다음 패킷이 전송된다.

기본적으로 네트워크에서 전송되는 패킷은 데이타의 크기에 상관없이 최소한 40 바이트의 헤더가 붙는다. 따라서 Nagel 알고리즘이 적용되지 않을 경우 1 바이트의 데이타를 전송한다고 해도 최소 40 바이트의 오버헤드가 발생한다. 이러한 네트워크 트래픽을 줄일 목적으로 Nagel 알고리즘이 제안된 것이다.

SSL / TLS [Bottom] [Top]

용어 정리

용어 정리/네트워크 (last edited 2008-07-06 02:04:05 by viper)