[HTTP 완벽 가이드] TCP 성능 관련 중요 요소

사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.

(HTTP 완벽 가이드를 읽으며 기록을 남기고 싶은 내용에 대해서 정리한 글입니다.)

 

TCP의 특징으로 아래와 같은 사실들은 기존에 알고 있었던 지식이었다.

1. HandShake
2. Flow control
3. 신뢰 전송 및 순서 보장

TCP 가 이러이러한 기능을 제공한다는 것은 암기식으로 알고 있었지만, 구체적으로 어떤 과정을 통해 이러한 기능을 제공하는지까지는 알지 못했다.

해당 글에서는 위 내용에 대한 좀 더 심화된 내용을 살펴볼 수 있다.

 

1. TCP 커넥션의 핸드 셰이크 설정

Handshake는 TCP 연결을 맺고 끊기 위한 TCP 수준의 개념이다. (HTTP는 TCP 수준의 Handshake를 이용하는 것이다.)

HTTP는 매 요청과 응답마다 TCP의 Handshake 과정을 거친다.

즉, 매 요청과 응답마다 TCP 연결을 맺고 끊는다.

([TCP 연결을 생성하기 위한 Handshaking] => [실제 HTTP를 통해 원하는 데이터 통신] => [TCP 연결을 해제하기 위한 Handshaking])

 

따라서 [실제 HTTP를 통해 원하는 데이터 통신] 부분이 매우 작다면(다시 말해, 한 번의 HTTP 트랜젝션으로 통신하는 데이터 량이 작다면) 실제 통신 비용보다 TCP 연결을 맺고 끊는 비용이 더 커질 수 있다. 

 

따라서 적은 양의 HTTP 트랜젝션이 동시다발적으로 발생하는 경우, 일정량의 HTTP 트랜젝션을 묶어두었다가 한 번의 HTTP 트랜젝션으로 배치 처리한다던가, 여러 HTTP 트랜젝션을 하나의 TCP Connection을 재사용하여 처리하는 것이 TCP 구성을 위한 handshake 비용을 줄일 수 있기 때문에 유의미한 최적화 포인트라고 생각한다.

 

2. 인터넷의 혼잡을 제어하기 위한 TCP의 느린 시작

서두에 언급한 TCP의 Flow control 과 관련된 이야기다.

인터넷 환경에서 급작스러운 packet 유입 증가를 방지하기 위해 TCP는 처음에 보낼 수 있는 packet의 수를 제한한다.

간단히 말해서, 처음에는 최대 2개의 packet 만 보내는 것이 가능하고 packet 이 잘 전달 되었음을 확인하게 되면 그 후에는 4(2+2) 개의 packet을 보낼 수 있도록 허용하는 개념이다.(이를 혼잡 윈도를 연다라고 표현한다.)

지금 네트워크 상황을 간을 보면서  이정도를 보낼 수 있네? 그럼 담에는 조금 더 보내볼까? 느낌이다.

 

이러한 Flow control 기능 때문에 새로운 커넥션은 이미 튜닝된 커넥션 보다 느리다.

따라서, 이미 만들어져 있는 connection을 유지하고 재 사용하는 전략은 튜닝 포인트가 될 수 있다.

 

3. TCP의 편승 확인응답을 위한 확인 응답 지연 알고리즘

TCP의 신뢰 전송 및 순서 보장과 관련한 이야기다.

 

TCP가 신뢰 전송을 보장하는 방법은 아래와 같다.

각 TCP 세그먼트는 순번과 데이터 무결성 체크섬을 가진다.

각 세그먼트의 수신자는 세그먼트를 온전히 받으면 작은 확인 응답 패킷을 송신자에게 보낸다.

만약, 송신자가 특정 시간 안에 확인 응답 페킷을 받지 못하면 패킷이 파기되었거나 오류가 있는 것으로 판단 → 데이터를 다시 전송한다.

확인 응답은 그 크기가 작기 때문에, TCP는 확인 응답을 위한 별도의 페킷을 만들기보단 같은 방향으로 송출되는 데이터 패킷에 확인 응답을 편승시킨다.

 

확인 응답의 편승 비중을 늘리기 위해서 확인 응답이 필요한 순간마다 즉시 보내지 않고 확인 응답을 지연시키는 방법을 사용한다.

즉, 확인 응답을 편승시킬 패킷이 생길 때까지 일정 기간 쌓아두고 대기한다.(이렇게 하면 편승 비율을 높일 수 있다.)

만약, 일정 시간 동안 편승할 패킷을 찾지 못하면 모아둔 확인 응답을 별도의 패킷에 실어 보낸다.

 

HTTP 통신의 경우, 각 종단이 시시각각 통신을 하는 것이 아니라 요청과 응답이 분리된 구조이기 때문에 사실 확인 응답이 편승될 기회가 상대적으로 적은 구조이다.

이러한 이유로, 확인 응답 지연 알고리즘을 활성화한 경우 편승할 패킷을 찾느라 지연되는 시간이 많아지는 편이다.

즉, 확인 응답을 편승시키기 위해 0.1 초 동안 확인 응답을 보내지 않고 지연하는 경우 매번 0.1초라는 지연을 전송자는 경험하게 된다.

운영체제에 따라 다르지만, 지연의 원인이 되는 확인 응답 지연 관련 기능을 수정하거나 비활성화할 수 있다.

 

 

4. 데이터를 한데 모아 한 번에 전송하기 위한 네이글 알고리즘

TCP 세그먼트는 실제 전송하고자 하는 데이터와 별개로 TCP 관리를 위해 많은 데이터가 추가된다.(대략 40 바이트 정도의 부가적인 값들이 붙는다.)

따라서, 아주 작은 데이터를 여러 번 보내게 되면 (보내는 수) * (40 바이트) 만큼 부수적인 데이터를 보내게 된다.

이러한 측면에서, 작은 데이터를 여러번 보내게 되면 TCP 내부적으로 작은 데이터를 한대 모아 최소한의 패킷으로 구성해서 전송하는 것이 효율적일 것이다.

네이글 알고리즘은 패킷을 전송하기 전에 많은 양의 TCP 데이터를 한 개의 덩어리로 합치기 위한 알고리즘이다.

 

네이글 알고리즘의 동작 방식

• 기본적으로, TCP 세그먼트가 최대 크기가 되지 않으면 전송을 하지 않는다.
• 다만 다른 모든 패킷이 확인 응답을 받은 경우 최대 크키보다 작은 패킷의 전송을 허용

네이글 알고리즘의 단점

• 크기가 작은 HTTP 메시지는 패킷을 채우지 못해, 앞으로 생길지 생기지 않을지 모르는 추가적인 데이터를 기다리며 지연될 수 있다.
• 확인 응답 지연 알고리즘과 네이글 알고리즘을 같이 쓰면 형편없이 동작한다.
  • 네이글 알고리즘은 확인 응답이 도착할 때까지 전송하지 않고 기다리고, 확인응답 지연 알고리즘은 이러한 확인 응답을 지연시킨다.
  • 이 부분은 파이프라인 커넥션과 함께 사용되면 더 최악으로 동작한다.

HTTP 애플리케이션은 성능 향상을 위해 HTTP 스택에 TCP_NODELAY 파라미터 값을 설정해 네이글 알고리즘을 비활성화하기도 한다.(이 설정을 했다면, 작은 크기의 패킷이 너무 많이 생기지 않도록 큰 크기의 데이터 덩어리를 만들어야 한다.)

 

 

정리 및 주의 사항

지금까지 TCP 수준에서 기존에 알고 있었던 내용에 대해 심화 내용을 학습했다.

TCP 수준의 최적화 포인트는 아래와 같이 러프하게 정리가 가능할 것 같다.

• TCP Connection 효율적으로 재 사용 하기 위한 방법
  • Handshake 를 줄이기 위한 관점
  • 느린 시작을 고려한 관점
• 여러번 보낼 것을 모아서 한꺼번에 보내기
  • 확인 응답을 모아서 보내기 -> 확인 응답 지연 알고리즘
  • 통신 메시지를 모아서 보내기 -> 네이글 알고리즘

 

참고로, TCP 스택에 있는 매개변수를 수정할 때는, 지금 무엇을 하고 있는지 명확하게 알고 수정해야 한다.

TCP의 내부 알고리즘은 잘못 만들어진 애플리케이션으로부터 인터넷을 보호하도록 설계되어 있다.

TCP 설정을 수정하려고 한다면, TCP의 내부 알고리즘이 피하려고 하는 문제를 애플리케이션이 발생시키지 않을 것이라고 확신할 수 있어야 한다.