Connection Timeout과 Read Timeout + (멱등성, RFC 표준)

네트워크 타임아웃 발생 시점: 서버로 요청을 보냈지만 일정 시간 동안 답변을 받지 못하면 발생

 

Connection Timeout (커넥션 타임아웃)

개발자 기술질문 Q: 커넥션 타임아웃은 뭔가요?

개발자 기술질문 A: 3-way 핸드쉐이크가 정상적으로 수행되기까지 소요되는 시간이다. 

 3-Way handshake: TCP 통신에서 클라이언트와 서버가 연결되는 과정

 

발생이유: 클라이언트에서 설정한 시간까지 서버에 연결되지 않으면 발생

 

발생원인들

- 네트워크 문제가 있는 경우 

Connection Timeout을 해결하려면 방화벽 설정을 확인해야 한다.

대부분의 Connection Timeout 원인은 방화벽 문제입니다.

 

*개발자는 Connection Timeout을 왜 알아야 할까요?

클라이언트가 계속 멈춰 있으면 안 되기 때문입니다.

적절한 커넥션 타임아웃 설정이 중요함.

클라이언트가 서버 응답을 무기한 기다리면 애플리케이션 성능이 저하됨.

---

Read Timeout (리드 타임아웃)

발생원인: 클라이언트에서 설정한 시간까지 서버에서 응답이 오지 않으면 발생

클라이언트와 서버가 연결은 됐지만, 서버가 클라이언트 요청을 정상적으로 처리 못 했을 때 일어남.

<도식화> 응답이 오지않고 서버에서 무한 waiting

 

[보편적으로 일어나는 상황]

• 클라이언트에서 너무 많은 데이터를 조회
• 서버가 요청을 처리하는데 시간이 오래 걸림

Q: 결제 같은 중요 API가 Read Timeout 때문에 두 번 호출되지는 않을까요?

A: 타임아웃 이후에 결제 승인과 같이 민감한 API가 두 번 호출되는 게 걱정된다면 멱등키로 안전하게 같은 요청을 다시 보낼 수 있음

 

*멱등키: 연산을 여러 번 하더라도 결과가 달라지지 않는 성질

기대효과: 민감한 API 반복적인 요청 문제 막을 수 있음  

 

# 멱등성이 뭔가요? (토스 기술블로그 참고)

https://docs.tosspayments.com/blog/what-is-idempotency

멱등성이 뭔가요? | 토스페이먼츠 개발자센터

 

 

---

멱등성(Idempotent)

멱등성의 대표적인 HTTP 요청

PATCH, PUT이 대표적인 예시이다.

PUT: 멱등성 보장 

PATCH: 멱등성 보장 X

 

RFC9110란??

https://www.rfc-editor.org/rfc/rfc9110.html

*RFC9110: HTTP/1.1 사양을 정의한 IETF 표준 문서: HTTP가 어떻게 동작해야 하는가? 중심의 문서

IETF(Internet Engineering Task Force): 국제 인터넷 표준화 기구 -> 인터넷의 운영, 관리, 개발에 대해 협의하고 프로토콜과 구조적인 사안들을 분석하는 인터넷 표준화 기구

RFC: 인터넷 표준과 프로토콜, 기술 등을 정의하고 기술하는 문서를 통칭

-> TCP/IP, HTTP, SMTP, DNS, TLS 등 우리가 쓰는 핵심 인터넷 기술은 대부분 RFC로 정의되어 있음.

 

 

POST

RFC문서에서 POST를 다음과 같이 정의하고 있어요.

The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.  

한국어: POST 요청의 요청 본문은 타깃 리소스의 정의대로 처리된다.

클라이언트가 요청을 보내면 서버에서 모든 걸 알아서 처리해야 된다는 뜻이다.

 

이 특징은 POST는 멱등성 보장이 안된다는 것입니다.

같은 POST 요청을 여러 번 보내면 여러 개의 리소스가 생성돼요.

 

예시: /payment로 3번 요청 보내면?

/payment/1

/payment/2

/payment/3

와 같이 똑같은 데이터를 가진 리소스 3개가 생성된다.

 

PUT

RFC 문서

The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource.

 

PUT 요청에서는 클라이언트가 리소스의 정확한 URI를 알아야 됩니다.

PUT요청은 /payment로 요청을 보내면 /payment/1와 같은 리소스가 생성되지 않아요.

/payment/1와 같은 특정 리소스로 URL로 요청을 보내야 리소스가 생성돼요.

 

그래서 PUT은 주로 리소스를 업데이트할 때 사용해요.

1) 이미 생성된 리소스의 정확한 URI를 알고 있고

2) 안전하게 멱등한 요청을 보내고 싶기 때문이다.

 

PATCH

PATCH 메서드는 RFC 5789에 정의

The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI.

PATCH 요청은 리소스를 부분 업데이트 할 때 사용합니다.

PATCH 메서드는 RFC 2616에 정의된 기준으로 멱등하지 않고 안전하지 않아요.

*PATCH 메서드가 동시에 호출되면 리소스의 데이터가 손실될 수 있고 클라이언트가 원하지 않는 결과가 나올 수 있어요.

 

사실 PUT PATCH의 가장 중요한 차이점은

전체 교체, 일부 교체 행위가 아니라

- PUT은 반드시 멱등 보장

- PATCH는 멱등성 보장하지 않을 수도 있다.