반응형
📝HTTP 1.1
HTTP 요청은 TCP 프로토콜을 이용하기 때문에 요청을 전송하기 위해선 3-way-handshake 과정을 거쳐 연결을 설정하고 연결과 끊기를 반복합니다 이걸 개선 시켜서 keep-alive라는 기능으로 일정시간동안 커넥션을 유지할 수 있도록 할 수 있어서 자원 낭비를 최소화 시킵니다
📝HTTP 2.0
HTTP 2.0은 기존 HTTP 1.1 버전의 성능 향상에 초점을 맞춘 프로토콜로 HTTP 1.1의 성능 저하 부분과 비효율적인 것들이 개선되어 탄생한 것이라고 생각하면 된다
HTTP 1.1까지는 한번에 하나의 파일만 전송이 가능했고 여러 파일을 전송할 경우 지연시간이 생기기 시작했다 HTTP 2.0에서는 문제 해결을 위해 여러 파일을 한번에 병렬로 전송한다
📝HTTP 1.1 vs HTTP 2.0
그림을 보면 얼마나 속도 차이가 있는 지 알 수 있다 → 실제로 적용시켜보면 눈에 보일정도이다
📝RPC
RPC의 경우 자신과 다른 주소공간에서 동작하는 프로세스의 함수를 실행할 수 있게 해주는데 이는 네트워크를 통한 메시징을 수행한다 즉, Client와 Server는 각각 일반 메소드를 호출하는 것처럼 원격지의 프로시저를 호출할 수 있다
- Stub
- 프로시저 호출을 추상화하는 작은 코드 조각
Stub Interface
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Calculator extends Remote {
int add(int a, int b) throws RemoteException;
}
Stub 구현체
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
public class CalculatorImpl extends UnicastRemoteObject implements Calculator {
protected CalculatorImpl() throws RemoteException {
super();
}
@Override
public int add(int a, int b) throws RemoteException {
return a + b;
}
}
서버 설정
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class Server {
public static void main(String[] args) {
try {
Calculator calculator = new CalculatorImpl();
Registry registry = LocateRegistry.createRegistry(1099); // RPC 런타임 생성
registry.bind("CalculatorService", calculator); // RPC에 stub 적용
System.out.println("Server is ready.");
} catch (Exception e) {
e.printStackTrace();
}
}
}RPC를 생성하고 RPC에 stub(소스코드)를 적용시킵니다
클라이언트 설정
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
public class Client {
public static void main(String[] args) {
try {
// RMI 레지스트리에서 CalculatorService 조회
Registry registry = LocateRegistry.getRegistry("localhost", 1099); // RPC로 서버와 연결
Calculator calculator = (Calculator) registry.lookup("CalculatorService"); // stub 코드를 호출시켜서 사용합니다
// Stub을 통해 원격 메서드 호출
int result = calculator.add(5, 3);
System.out.println("Result: " + result);
} catch (Exception e) {
e.printStackTrace();
}
}
}
RPC로 서버와 연결한 뒤 stub 코드를 호출시켜서 사용합니다
📝RPC vs REST API
| 특성 | RPC | REST API |
| 접근 방식 | 메소드 호출 중심 | 자원 중심 (URI) |
| 데이터 포맷 | 이진 포맷 (Protocol Buffers, JSON 등) | 텍스트 포맷 (JSON, XML) |
| 프로토콜 | HTTP, TCP, UDP 등 다양한 프로토콜 사용 가능 | HTTP |
| 결합도 | 높은 결합도 | 느슨한 결합 |
| 인터페이스 정의 | 엄격한 인터페이스 정의 | 인터페이스 정의가 상대적 덜 엄격 |
| 설정 복잡도 | 초기 설정 복잡 | 상대적으로 설정이 간단 |
| 성능 | 높은 성능 (최적화된 직렬화 및 통신) | 성능이 상대적으로 낮음 (텍스트 포맷, HTTP) |
| 유연성 및 확장성 | 유연성 낮음, 변경시 양쪽(Server-Client) 모두 수정 필요 | 유연성 높음, 다양한 클라이언트와 수비게 통합 |
| 캐싱 | 캐싱 기능 부족 | HTTP 캐싱 매커니즘 지원 |
| 사용 환경 | 내부 마이크로서비스 간의 고성능 통신이 필요한 경우 RPC가 유리 | 외부 API와의 통합 및 웹 서비스 개발에는 REST가 더 적합 |
📝GRPC
gRPC는 Google이 개발한 오픈 소스 RPC 프레임워크로, 성능과 확장성을 염두에 두고 설계되었습니다
- HTTP/2 프로토콜 사용
- 데이터포맷은 Protocol Buffers (ProtoBuf)로 통신속도가 더 빠릅니다
- 다양한 언어(C++, Java, Python, Go 등)를 지원합니다
- HTTP/2로 양방향 통신이 가능(스트리밍)합니다
🔗 참고 및 출처
반응형